From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 00:44:20 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52366106564A; Sun, 15 Feb 2009 00:44:20 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from proxy.meer.net (proxy.meer.net [64.13.141.13]) by mx1.freebsd.org (Postfix) with ESMTP id 15B5C8FC13; Sun, 15 Feb 2009 00:44:19 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by proxy.meer.net (8.14.3/8.14.3) with ESMTP id n1F0i1qL081468; Sat, 14 Feb 2009 16:44:01 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id n1F0hrDa095542; Sat, 14 Feb 2009 16:43:53 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (cpe-68-175-68-135.nyc.res.rr.com [68.175.68.135]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.3) with ESMTP id n1F0hrM0052902; Sat, 14 Feb 2009 16:43:53 -0800 (PST) (envelope-from gnn@neville-neil.com) Date: Sat, 14 Feb 2009 19:43:52 -0500 Message-ID: From: gnn@freebsd.org To: Andrew Gallatin In-Reply-To: <4996C62E.8090109@cs.duke.edu> References: <4995A792.5050003@cs.duke.edu> <4996C62E.8090109@cs.duke.edu> User-Agent: Wanderlust/2.15.6 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: undef - spam scanning disabled X-CanIt-Geo: No geolocation information available for 64.13.141.3 X-CanItPRO-Stream: default X-Canit-Stats-ID: Bayes signature not available X-Scanned-By: CanIt (www . roaringpenguin . com) on 64.13.141.13 Cc: Robert Watson , current@freebsd.org Subject: Re: Dtrace panic'ed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 00:44:20 -0000 At Sat, 14 Feb 2009 08:25:02 -0500, Andrew Gallatin wrote: > > Robert Watson wrote: > > > > On Fri, 13 Feb 2009, Andrew Gallatin wrote: > > > >> I was trying to run a simple dtrace profiling script, and panic'ed the > >> machine using today's -current on an 8-way opteron. > > > > Oh, you actually got a panic using the profile provider? For me the box > > appears to go into la-la land. I've also seen a few double faults using > > fbt a bit too gratuitously. Unfortunately, I haven't found time to > > debug it, but I wondered if perhaps DTrace is not recognizing its own > > functions (i.e., ones it shouldn't try to trace) properly and/or failing > > to disable interrupts or enter a critical section at important moments. > > I think that sounds like a likely hypothesis. It is a shame it doesn't > work. Dtrace's profile provider is so useful... > > BTW, did you see my next message where I was trying to > find the null pointer? It seemed almost as if the state saved > by the kernel crashdump was "correct" (eg, no NULL pointer), > but the code was executing with a different, corrupt register set. > It may just be my misunderstanding on amd64 asm though. > For me I get the same result as Robert. In particular it is ONLY with the profile provider but not the other timing provider (tick). And it is also, for me, only near the 100 Hz profile. > As another aside, what is up with kgdb & module debug these days? > It seems to load module symbols automagically these days, > which is very cool. But the modules themselves do not seem > to have symbols that gdb understands, even though I built > with 'makeoptions DEBUG=-g' This is a side effect of the ctfconvert. John Baldwin and I fixed this for the kernel, but I have not yet fixed it for modules. Best, George From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 08:28:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 96564106566B for ; Sun, 15 Feb 2009 08:28:20 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by mx1.freebsd.org (Postfix) with ESMTP id 6E9A08FC14 for ; Sun, 15 Feb 2009 08:28:20 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by wa-out-1112.google.com with SMTP id k34so908785wah.27 for ; Sun, 15 Feb 2009 00:28:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=EAQp2i/K2UK4iPnm4jRSzKoqRfVp2nMqBMArAbY5ewg=; b=f9L2mYrZK03tzyxP3W9aSF8E5xe5SLf6KzGdDsWxu/GLYuw+HwJNCsxUDAgzmAiHiI jfQZKfaesCeXP/oNZj3dhNOGSlOVIoue3SCTjmsamwfOCXx8EAYuIFMlq1bSfHioz33Z 2QNO81O4u+jKRy9XGPF1r3vOV4AF3aHl/Wig0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=oHy+vmnjk+vM71NP1ryUIbgPVsnIqPiusWlrFXsO8wvgQwI4Y0yVIoZAa9uBgXk3Je 88SXXN9UOyWFo29/V6Zx7hI5e7/DKKjjHcteNz85IhpWlZE3SxQ/X0JdjDILCjhJKdBs 2eiaoo1vWObj+xp1+atJDGYChBvRieqgUGzNY= MIME-Version: 1.0 Received: by 10.114.174.2 with SMTP id w2mr1583597wae.195.1234686500134; Sun, 15 Feb 2009 00:28:20 -0800 (PST) Date: Sun, 15 Feb 2009 00:28:20 -0800 Message-ID: <7d6fde3d0902150028n5f07ee55mc6026e1e4935eeb0@mail.gmail.com> From: Garrett Cooper To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: pyunyh@gmail.com Subject: Annoyance with recent parallelism in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 08:28:20 -0000 I just updated my world to a recent snapshot (a build from last week) and I'm noting some parallelism / backgrounding which is really causing issues with my NIC and NFS mounts. I had to hit CTRL-D 5 times in order to get the system to come up because it couldn't resolve my NFS server's hostname, because the NIC wasn't up and going yet (as it uses the DHCP client in background mode due to the new default). Now I realize that this all ties back into the issue with the NIC (which I've approached Pyun about, and which I appreciate his help is solving issues with this buggy chipset), but is there really a need for parallelism at startup rc.d it can't properly detect dependencies with some cases like NFS mounts? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 10:40:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2174106566C for ; Sun, 15 Feb 2009 10:40:15 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 234FD8FC1B for ; Sun, 15 Feb 2009 10:40:14 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA14864; Sun, 15 Feb 2009 12:40:08 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1] helo=edge.pp.kiev.ua) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1LYePv-0002qY-Pm; Sun, 15 Feb 2009 12:40:07 +0200 Message-ID: <4997F105.5020409@icyb.net.ua> Date: Sun, 15 Feb 2009 12:40:05 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090114) MIME-Version: 1.0 To: Andrew Reilly References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> In-Reply-To: <20090213231513.GA20223@duncan.reilly.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 10:40:16 -0000 on 14/02/2009 01:15 Andrew Reilly said the following: > On Fri, Feb 13, 2009 at 08:25:31PM +0200, Andriy Gapon wrote: >> Rationale: >> There are people who write FreeBSD drivers in C++, > > There are? I can't find any in /usr/src/sys by any of the usual > suffixes. Whatever would you want to do that for, anyway? That > would bring a whole extra language runtime support library into the > kernel, and complicate the boot process with constructors and > what-not. > > Seems like a backwards step, to me. Bait not taken, sorry :-) [*] > Not that this should stop you from de-keywording the include > files, if that takes your fancy, but permuting a variable > "class" into "clazz" is a bit gruesome, imo. Why not just comment > the argument name out altogether? It's not strictly needed in > the prototype. I am not particularly fond of "clazz" myself, but somehow it was the first thing that came to my mind and I didn't give it any further thought. So this was just an example, I am all ears for good suggestions like the the ones from you and Joseph. [*] I have some examples and arguments but I'd prefer to send them in private or in other thread. I think we've seen quite a few flames on the topic of C++ and kernel. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 10:41:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 359AB106566B for ; Sun, 15 Feb 2009 10:41:04 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 682FA8FC22 for ; Sun, 15 Feb 2009 10:41:03 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA14868; Sun, 15 Feb 2009 12:40:57 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1] helo=edge.pp.kiev.ua) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1LYeQj-0002qd-7T; Sun, 15 Feb 2009 12:40:57 +0200 Message-ID: <4997F137.50403@icyb.net.ua> Date: Sun, 15 Feb 2009 12:40:55 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090114) MIME-Version: 1.0 To: Joseph Koshy References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <84dead720902131945s11fc5949j7125bb28b030f055@mail.gmail.com> In-Reply-To: <84dead720902131945s11fc5949j7125bb28b030f055@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Reilly , freebsd-current@freebsd.org Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 10:41:04 -0000 on 14/02/2009 05:45 Joseph Koshy said the following: >> Not that this should stop you from de-keywording the include >> files, if that takes your fancy, but permuting a variable >> "class" into "clazz" is a bit gruesome, imo. Why not just comment >> the argument name out altogether? It's not strictly needed in >> the prototype. > > Prefixing parameter names in function prototypes with an underscore > should be enough. > > void function(int _fd); > > (Example taken from style(9)). Very good idea. Thank you. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 11:05:13 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD069106564A; Sun, 15 Feb 2009 11:05:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 56A6F8FC1A; Sun, 15 Feb 2009 11:05:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1FB5AFb035731; Sun, 15 Feb 2009 06:05:10 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1FB5A3S065413; Sun, 15 Feb 2009 06:05:10 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4F3B27302F; Sun, 15 Feb 2009 06:05:10 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090215110510.4F3B27302F@freebsd-current.sentex.ca> Date: Sun, 15 Feb 2009 06:05:10 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 11:05:14 -0000 TB --- 2009-02-15 09:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-15 09:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-02-15 09:40:00 - cleaning the object tree TB --- 2009-02-15 09:40:52 - cvsupping the source tree TB --- 2009-02-15 09:40:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-02-15 09:41:00 - building world TB --- 2009-02-15 09:41:00 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-15 09:41:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-15 09:41:00 - TARGET=amd64 TB --- 2009-02-15 09:41:00 - TARGET_ARCH=amd64 TB --- 2009-02-15 09:41:00 - TZ=UTC TB --- 2009-02-15 09:41:00 - __MAKE_CONF=/dev/null TB --- 2009-02-15 09:41:00 - cd /src TB --- 2009-02-15 09:41:00 - /usr/bin/make -B buildworld >>> World build started on Sun Feb 15 09:41:02 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries [...] cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 netnatm/*.h /obj/amd64/src/lib32/usr/include/netnatm cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 netncp/*.h /obj/amd64/src/lib32/usr/include/netncp cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 netsmb/*.h /obj/amd64/src/lib32/usr/include/netsmb cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 nfs/*.h /obj/amd64/src/lib32/usr/include/nfs cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 nfsclient/*.h /obj/amd64/src/lib32/usr/include/nfsclient cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 nfsserver/*.h /obj/amd64/src/lib32/usr/include/nfsserver cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 pccard/*.h /obj/amd64/src/lib32/usr/include/pccard install: pccard/*.h: No such file or directory *** Error code 71 Stop in /src/include. *** Error code 1 Stop in /src/include. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-15 11:05:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-15 11:05:10 - ERROR: failed to build world TB --- 2009-02-15 11:05:10 - 3992.06 user 389.40 system 5109.67 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 13:00:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBC66106564A for ; Sun, 15 Feb 2009 13:00:18 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id A07718FC19 for ; Sun, 15 Feb 2009 13:00:18 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 2B1B9295169; Sun, 15 Feb 2009 08:00:18 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 15 Feb 2009 08:00:18 -0500 X-Sasl-enc: G2b3HsCVTA6ZfFgpwJQ2WXcDDfXcSt5zdzsxFRRX2UEd 1234702817 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 6ECA132299; Sun, 15 Feb 2009 08:00:17 -0500 (EST) Message-ID: <499811DF.6030905@incunabulum.net> Date: Sun, 15 Feb 2009 13:00:15 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.19 (X11/20090125) MIME-Version: 1.0 To: Andriy Gapon References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> In-Reply-To: <4997F105.5020409@icyb.net.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Reilly , freebsd-current@freebsd.org Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 13:00:19 -0000 Andriy Gapon wrote: > on 14/02/2009 01:15 Andrew Reilly said the following: >> On Fri, Feb 13, 2009 at 08:25:31PM +0200, Andriy Gapon wrote: >>> Rationale: >>> There are people who write FreeBSD drivers in C++, >> >> There are? I can't find any in /usr/src/sys by any of the usual >> suffixes. Whatever would you want to do that for, anyway? That >> would bring a whole extra language runtime support library into the >> kernel, and complicate the boot process with constructors and >> what-not. >> >> Seems like a backwards step, to me. > > Bait not taken, sorry :-) [*] Please don't listen to the nay-sayers, and keep up the good work:- http://web.archive.org/web/20071222161357/http://netlab.ru.is/exception/LinuxCXX.shtml The figures re exception handling quoted sound extremely promising. Like any tool, C++ has its good sides and bad sides, and I suspect the people who are nay-saying got burned by the non-mindful deployment of this tool without sufficient support to "do it right", either from the project they are working in, management (if applicable), or from the tool chain. There are worthwhile projects which use C++ in the kernel, and whose progress has been impeded by the very problem which you are now helping to fix:- http://read.cs.ucla.edu/click/ Nay-sayers: All I ask is that you don't complain when someone who knows how to use the tool, and has the support, gets more working code written :^) cheers BMS From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 13:09:21 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 52ECB106567B for ; Sun, 15 Feb 2009 13:09:21 +0000 (UTC) (envelope-from zozo@q.gid0.org) Received: from smtpfb2-g21.free.fr (smtpfb2-g21.free.fr [212.27.42.10]) by mx1.freebsd.org (Postfix) with ESMTP id C863D8FC2C for ; Sun, 15 Feb 2009 13:09:19 +0000 (UTC) (envelope-from zozo@q.gid0.org) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by smtpfb2-g21.free.fr (Postfix) with ESMTP id 9210BD19D2E for ; Sun, 15 Feb 2009 12:16:38 +0100 (CET) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 61DF54C818B for ; Sun, 15 Feb 2009 12:16:31 +0100 (CET) Received: from q.gid0.org (s.gid0.org [88.163.116.140]) by smtp4-g21.free.fr (Postfix) with ESMTP id 2F8A84C812D for ; Sun, 15 Feb 2009 12:16:29 +0100 (CET) Received: (from zozo@localhost) by q.gid0.org (8.14.3/8.14.3/Submit) id n1FBGSPs045186 for current@freebsd.org; Sun, 15 Feb 2009 12:16:28 +0100 (CET) (envelope-from zozo) Date: Sun, 15 Feb 2009 12:16:28 +0100 From: Olivier Smedts To: current@freebsd.org Message-ID: <20090215111626.GA94483@q.gid0.org> References: <20090215110510.4F3B27302F@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: <20090215110510.4F3B27302F@freebsd-current.sentex.ca> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 13:09:21 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Feb 15, 2009 at 06:05:10AM -0500, FreeBSD Tinderbox wrote: > TB --- 2009-02-15 09:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca > TB --- 2009-02-15 09:40:00 - starting HEAD tinderbox run for amd64/amd64 > TB --- 2009-02-15 09:40:00 - cleaning the object tree > TB --- 2009-02-15 09:40:52 - cvsupping the source tree > TB --- 2009-02-15 09:40:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile > TB --- 2009-02-15 09:41:00 - building world > TB --- 2009-02-15 09:41:00 - MAKEOBJDIRPREFIX=/obj > TB --- 2009-02-15 09:41:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin > TB --- 2009-02-15 09:41:00 - TARGET=amd64 > TB --- 2009-02-15 09:41:00 - TARGET_ARCH=amd64 > TB --- 2009-02-15 09:41:00 - TZ=UTC > TB --- 2009-02-15 09:41:00 - __MAKE_CONF=/dev/null > TB --- 2009-02-15 09:41:00 - cd /src > TB --- 2009-02-15 09:41:00 - /usr/bin/make -B buildworld > >>> World build started on Sun Feb 15 09:41:02 UTC 2009 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > >>> stage 5.1: building 32 bit shim libraries > [...] > cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 netnatm/*.h /obj/amd64/src/lib32/usr/include/netnatm > cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 netncp/*.h /obj/amd64/src/lib32/usr/include/netncp > cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 netsmb/*.h /obj/amd64/src/lib32/usr/include/netsmb > cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 nfs/*.h /obj/amd64/src/lib32/usr/include/nfs > cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 nfsclient/*.h /obj/amd64/src/lib32/usr/include/nfsclient > cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 nfsserver/*.h /obj/amd64/src/lib32/usr/include/nfsserver > cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 pccard/*.h /obj/amd64/src/lib32/usr/include/pccard > install: pccard/*.h: No such file or directory > *** Error code 71 > > Stop in /src/include. > *** Error code 1 > > Stop in /src/include. > *** Error code 1 > > Stop in /src. > *** Error code 1 > > Stop in /src. > TB --- 2009-02-15 11:05:10 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2009-02-15 11:05:10 - ERROR: failed to build world > TB --- 2009-02-15 11:05:10 - 3992.06 user 389.40 system 5109.67 real > buildworld broken since @188634 : http://www.freebsd.org/cgi/getmsg.cgi?fetch=17928+0+current/cvs-src-old See attached patches. -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename=patch1 --- include/Makefile.orig 2009-02-15 12:08:01.000000000 +0100 +++ include/Makefile 2009-02-15 12:08:20.000000000 +0100 @@ -36,7 +36,7 @@ LDIRS= bsm cam geom net net80211 netatalk netgraph netinet netinet6 \ netipsec ${_netipx} netnatm ${_netncp} netsmb \ nfs nfsclient nfsserver \ - pccard sys vm + sys vm LSUBDIRS= cam/scsi \ dev/acpica dev/an dev/bktr dev/firewire dev/hwpmc \ --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename=patch2 --- sys/Makefile.orig 2009-02-15 12:06:26.000000000 +0100 +++ sys/Makefile 2009-02-15 12:06:34.000000000 +0100 @@ -12,7 +12,7 @@ geom gnu isa kern libkern modules net net80211 netatalk \ netgraph netinet netinet6 netipsec netipx netnatm netncp \ netsmb nfs nfs4client nfsclient nfsserver nlm opencrypto \ - pccard pci rpc security sys ufs vm xdr ${CSCOPE_ARCHDIR} + pci rpc security sys ufs vm xdr ${CSCOPE_ARCHDIR} .if defined(ALL_ARCH) CSCOPE_ARCHDIR ?= amd64 arm i386 ia64 mips pc98 powerpc sparc64 sun4v .else --gBBFr7Ir9EOA20Yy-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 14:13:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2B2B106570E for ; Sun, 15 Feb 2009 14:13:24 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout5.freenet.de (mout5.freenet.de [IPv6:2001:748:100:40::2:7]) by mx1.freebsd.org (Postfix) with ESMTP id 7842F8FC17 for ; Sun, 15 Feb 2009 14:13:24 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.16] (helo=6.mx.freenet.de) by mout5.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #76) id 1LYhkG-0001vi-FP; Sun, 15 Feb 2009 15:13:20 +0100 Received: from taa85.t.pppool.de ([89.55.170.133]:28179 helo=ernst.jennejohn.org) by 6.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #76) id 1LYhkG-0008Qz-83; Sun, 15 Feb 2009 15:13:20 +0100 Date: Sun, 15 Feb 2009 15:13:18 +0100 From: Gary Jennejohn To: Bruce Simpson Message-ID: <20090215151318.0d17bfb9@ernst.jennejohn.org> In-Reply-To: <499811DF.6030905@incunabulum.net> References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Andrew Reilly , freebsd-current@freebsd.org, Andriy Gapon Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 14:13:25 -0000 On Sun, 15 Feb 2009 13:00:15 +0000 Bruce Simpson wrote: > Please don't listen to the nay-sayers, and keep up the good work:- > > http://web.archive.org/web/20071222161357/http://netlab.ru.is/exception/LinuxCXX.shtml > It isn't exactly confidence building that all the links on this page are invalid. This is all from 2005 and AFAICT has languished since then. I'm not aware of any movement within the Linux community to bring C++ support into the kernel. > Nay-sayers: All I ask is that you don't complain when someone who knows > how to use the tool, and has the support, gets more working code written :^) > I haven't been paying much attention to this thread, but I can't recall having read any persuasive arguments for using C++ in the kernel. I personally get cold chills up and down my spine just thinking about it. Maybe I've been doing kernel development for too long. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 15:33:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C12041065670 for ; Sun, 15 Feb 2009 15:33:21 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 37C808FC15 for ; Sun, 15 Feb 2009 15:33:20 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 15 Feb 2009 15:33:19 -0000 Received: from p54A3DABF.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.218.191] by mail.gmx.net (mp058) with SMTP; 15 Feb 2009 16:33:19 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19d9ZFu6mtdNdVfxRLWJUV1Yzmtdeg4oQ5uv9DGWk N4/KdOtlJ/3bDr Message-ID: <499835BE.3000705@gmx.de> Date: Sun, 15 Feb 2009 16:33:18 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> In-Reply-To: <20090215151318.0d17bfb9@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.54 Cc: Andrew Reilly , Bruce Simpson , Andriy Gapon , freebsd-current@freebsd.org Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 15:33:22 -0000 Gary Jennejohn schrieb: > On Sun, 15 Feb 2009 13:00:15 +0000 > Bruce Simpson wrote: > >> Please don't listen to the nay-sayers, and keep up the good work:- >> >> http://web.archive.org/web/20071222161357/http://netlab.ru.is/exception/LinuxCXX.shtml >> > > It isn't exactly confidence building that all the links on this page > are invalid. > > This is all from 2005 and AFAICT has languished since then. I'm not aware of > any movement within the Linux community to bring C++ support into the kernel. > >> Nay-sayers: All I ask is that you don't complain when someone who knows >> how to use the tool, and has the support, gets more working code written :^) >> > > I haven't been paying much attention to this thread, but I can't recall > having read any persuasive arguments for using C++ in the kernel. More robust error handling and less tedious resouce management directly come to mind: Just look at normal C functions which allocate resources and have multiple points which can fail. They are the usual mess of if()s, goto error and lots of cleanup code. Further all this code looks pretty much the same in several modules. In C++ you write the resource handling code once (constructors/destructors) and then you cannot forget to clean up, because thanks to scoping and defined life ranges it happens automatically. Further return codes are ignored by default, which happens all too easily. Exceptions cause the normal code path to be aborted instead of limping further after failure probably with uninitialised data. Also exceptions which do not occure are faster than normal error code checking. Assume a chain of a dozen functions is called to handle something and the innermost can fail. Then every one of these functions has to have a return code to signal an error and every one of these functions has to check the one of its callee(s). This is not only tedious (see above), but it means a check on every level. With exceptions only the inner function throws an exception on failure and all the other functions do not have to check for failure - so there is no if() on the normal code path for all these calls. Exceptions cost nothing when they do not occure; a try {} block does not cause any code on the normal program path to be executed. These are two arguments for C++ which, I hope, are convincing to you. C++ adds more interesting aspects, but these two immediately come to mind when thinking about the usual stuff an OS does. > I personally get cold chills up and down my spine just thinking about it. Why? Do you have any arguments? > Maybe I've been doing kernel development for too long. Look a bit around. Modern languages try to make it easier to create robust code. I think C++ got some things right. Regards Christoph From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 15:35:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B3631065675 for ; Sun, 15 Feb 2009 15:35:34 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 15A958FC0A for ; Sun, 15 Feb 2009 15:35:33 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 86B11A06C7; Sun, 15 Feb 2009 16:35:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 79DA6A06C6; Sun, 15 Feb 2009 16:35:32 +0100 (CET) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 655FFA06A8; Sun, 15 Feb 2009 16:35:32 +0100 (CET) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2HF443) with ESMTP id 2009021516353147-69719 ; Sun, 15 Feb 2009 16:35:31 +0100 Received: by wep4035 (sSMTP sendmail emulation); Sun, 15 Feb 2009 16:35:31 +0100 From: "Alexey Shuvaev" Date: Sun, 15 Feb 2009 16:35:31 +0100 To: FreeBSD Current Message-ID: <20090215153531.GA36438@wep4035.physik.uni-wuerzburg.de> References: <7d6fde3d0902150028n5f07ee55mc6026e1e4935eeb0@mail.gmail.com> MIME-Version: 1.0 In-Reply-To: <7d6fde3d0902150028n5f07ee55mc6026e1e4935eeb0@mail.gmail.com> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.18 (2008-05-17) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 02/15/2009 04:35:31 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 02/15/2009 04:35:32 PM, Serialize complete at 02/15/2009 04:35:32 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: Garrett Cooper Subject: Re: Annoyance with recent parallelism in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 15:35:34 -0000 On Sun, Feb 15, 2009 at 12:28:20AM -0800, Garrett Cooper wrote: > I just updated my world to a recent snapshot (a build from last week) > and I'm noting some parallelism / backgrounding which is really > causing issues with my NIC and NFS mounts. I had to hit CTRL-D 5 times > in order to get the system to come up because it couldn't resolve my > NFS server's hostname, because the NIC wasn't up and going yet (as it > uses the DHCP client in background mode due to the new default). > > Now I realize that this all ties back into the issue with the NIC > (which I've approached Pyun about, and which I appreciate his help is > solving issues with this buggy chipset), but is there really a need > for parallelism at startup rc.d it can't properly detect dependencies > with some cases like NFS mounts? > Me too. I have ntpd failing to resolve dns names. I have noticed this since appr. 1.350 of etc/defaults/rc.conf (12 days ago). I was hoping this will go away... Commit log: SVN rev 188010 on 2009-02-02 15:38:24Z by mtm Since, rc.d/defaultroute has the ability to wait for a default route to show up we can turn this knob back on without screwing subsequent daemons that expect to be able to talk to the outside world. ^^^^^^^^^^^^^^^^^^^^^^^^^^^ Seems it is not the case... Interesting: setting background_dhclient="NO" does not solve the issue. Maybe something else was changed? My current 'workaroud' is synchronous_dhclient="YES" My hardware: ~> uname -a FreeBSD wep4035 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Sat Feb 14 01:29:05 CET 2009 root@wep4035:/usr/obj/usr/src/sys/NOUSB amd64 mskc0@pci0:1:0:0: class=0x020000 card=0x81f81043 chip=0x436411ab rev=0x12 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '88E8056 Yukon PCI-E Gigabit Ethernet Controller' class = network subclass = ethernet msk0: flags=8843 metric 0 mtu 1500 options=11a ether 00:1f:c6:89:83:ec [snip] media: Ethernet autoselect (100baseTX ) status: active Alexey. From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 15:38:33 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8551C1065670 for ; Sun, 15 Feb 2009 15:38:33 +0000 (UTC) (envelope-from root@dchagin.static.corbina.ru) Received: from contrabass.post.ru (contrabass.post.ru [85.21.78.5]) by mx1.freebsd.org (Postfix) with ESMTP id 072ED8FC1C for ; Sun, 15 Feb 2009 15:38:32 +0000 (UTC) (envelope-from root@dchagin.static.corbina.ru) Received: from corbina.ru (mail.post.ru [195.14.50.16]) by contrabass.post.ru (Postfix) with ESMTP id AFB7356B24; Sun, 15 Feb 2009 18:11:21 +0300 (MSK) X-Virus-Scanned: by cgpav Uf39PSi9pFi9oFi9 Received: from [10.208.17.3] (HELO dchagin.static.corbina.ru) by corbina.ru (CommuniGate Pro SMTP 5.1.14) with ESMTPS id 1624851619; Sun, 15 Feb 2009 18:11:21 +0300 Received: from dchagin.static.corbina.ru (localhost.chd.net [127.0.0.1]) by dchagin.static.corbina.ru (8.14.3/8.14.3) with ESMTP id n1FFBLS2002592; Sun, 15 Feb 2009 18:11:21 +0300 (MSK) (envelope-from root@dchagin.static.corbina.ru) Received: (from root@localhost) by dchagin.static.corbina.ru (8.14.3/8.14.3/Submit) id n1FFBEDF002591; Sun, 15 Feb 2009 18:11:14 +0300 (MSK) (envelope-from root) Date: Sun, 15 Feb 2009 18:11:14 +0300 From: Chagin Dmitry To: Andrew Gallatin Message-ID: <20090215151114.GA2422@dchagin.static.corbina.ru> References: <4995A792.5050003@cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4995A792.5050003@cs.duke.edu> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: current@freebsd.org Subject: Re: Dtrace panic'ed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 15:38:34 -0000 On Fri, Feb 13, 2009 at 12:02:10PM -0500, Andrew Gallatin wrote: > I was trying to run a simple dtrace profiling script, and > panic'ed the machine using today's -current on an 8-way opteron. > > I tried to run: > #!/usr/sbin/dtrace -s > > profile:::profile-997 > { > @a[stack(20)]=count(); > } > > END > { > trunc(@a, 20); > printa(@a); > } > > Everything was fine until I hit ^C. This appeared > on the tty (which I expected): > > dtrace: script '/nfs/home/gallatin/dtrace/profile_stack.d' matched 2 probes > ^C > CPU ID FUNCTION:NAME > 1 2 :END > > kernel`vm_page_splay+0x5b > kernel`trap+0x482 > kernel`0xffffffff807eb8f3 > 1 > > kernel`vm_fault+0x1e2 > 1 > > kernel`pagezero+0x17 > 1 > > kernel`cpu_idle+0x1 > 1 > > kernel`pmap_enter+0x6f > kernel`0xffffffff807eb8f3 > 1 > > 4 > > kernel`pagezero+0x11 > 4 > > kernel`acpi_cpu_c1+0x6 > kernel`0xffffffff807ebd4e > 14063 > > And then the machine fell over with this on console: > > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > cpuid = 7; apic id = 07 > fault virtual address = 0x20 > fault code = supervisor read data, page not present > instruction pointer = 0x8:0xffffffff80e33187 > stack pointer = 0x10:0xfffffffe4004aa70 > frame pointer = 0x10:0xfffffffe4004aa80 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = resume, IOPL = 0 > current process = 11 (idle: cpu7) > trap number = 12 > panic: page fault > cpuid = 7 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2a > panic() at panic+0x182 > trap_fatal() at trap_fatal+0x2ad > trap_pfault() at trap_pfault+0x294 > trap() at trap+0x38b > calltrap() at calltrap+0x8 > --- trap 0xc, rip = 0xffffffff80e33187, rsp = 0xfffffffe4004aa70, rbp = > 0xfffffffe4004aa80 --- > cyclic_disable_xcall() at cyclic_disable_xcall+0x7 > smp_rendezvous_action() at smp_rendezvous_action+0xb3 > Xrendezvous() at Xrendezvous+0x64 > --- interrupt, rip = 0xffffffff807e3cf6, rsp = 0xfffffffe4004ab70, rbp = > 0xfffffffe4004ab80 --- > acpi_cpu_c1() at acpi_cpu_c1+0x6 > acpi_cpu_idle() at acpi_cpu_idle+0x19c > sched_idletd() at sched_idletd+0x234 > fork_exit() at fork_exit+0x118 > fork_trampoline() at fork_trampoline+0xe > --- trap 0, rip = 0, rsp = 0xfffffffe4004ad40, rbp = 0 --- > Uptime: 5m14s > Physical memory: 8177 MB > Dumping 506 MB: 491 475 459 443 427 411 395 379 363 347 331 315 299 283 > 267 251 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11 > > hi, I have the same problem and found the hack "solution": dchagin# sysctl machdep.idle=hlt machdep.idle: acpi -> hlt thnx! -- Have fun! chd From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 15:44:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56100106566B for ; Sun, 15 Feb 2009 15:44:49 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 28A8C8FC18 for ; Sun, 15 Feb 2009 15:44:48 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 702F52959D9; Sun, 15 Feb 2009 10:44:48 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Sun, 15 Feb 2009 10:44:48 -0500 X-Sasl-enc: rwXkFqyZy3/eQ4owTENnPhGH+0dbZGtNSFAf2+VwMf7+ 1234712687 Received: from anglepoise.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 1E3532485E; Sun, 15 Feb 2009 10:44:47 -0500 (EST) Message-ID: <49983868.5010107@incunabulum.net> Date: Sun, 15 Feb 2009 15:44:40 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.19 (X11/20090125) MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> In-Reply-To: <20090215151318.0d17bfb9@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Reilly , freebsd-current@freebsd.org, Andriy Gapon Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 15:44:49 -0000 Gary Jennejohn wrote: ... > It isn't exactly confidence building that all the links on this page > are invalid. > I was able to access all of the links on that page without problems from archive.org. The original content has moved, this seems to be due to a re-organisation within the university concerned. Can you mention exactly which links were invalid for you? > This is all from 2005 and AFAICT has languished since then. I'm not aware of > any movement within the Linux community to bring C++ support into the kernel. > Not much changes in an established programming language in 3-4 years, unless it is still mutating (e.g. C#, Python). This is pure speculation on my part, however: I wager the patches had bit-rotted for no good reason other than lack of interest or ignorance, certainly not from active opposition, perhaps apart from Linus Torvalds who had weighed in against C++ in other threads. FreeBSD is not Linux, however, and the jury's still out on this one. > I haven't been paying much attention to this thread, but I can't recall > having read any persuasive arguments for using C++ in the kernel. > Kernel-like systems are built with C++, this is just a fact of life. Think games, think embedded systems. You personally may not be writing systems to run fast and low-level in C++, but I can think of at least 3 people I know personally who have done and continue to do so. Given, they are folk who have spent a long time learning C++ -- the tool has a steep learning curve, and Bjarne Stroustrup himself would no doubt be the first to admit this. Whilst code such as the Standard Template Library (STL) may not be an appropriate fit for all low-level uses, the fact of the matter is, something from has had many pairs of eyeballs on it. Having to hand-code stuff like set symmetric difference is tedious if you don't actually have to do it. If you do -- work smarter, not harder. I wonder if many of the objections raised against C++ have actually been considered in the light of the new C++0x spec. At the moment, there are several projects out there which don't even involve C++ in the *kernel*, which are directly impacted by the issues which Andriy is attempting to solve because they use the system headers; I therefore fully support what he is doing, as he is saving people a lot of hassle. It's time to get real, and admit that C++ is a very powerful tool that, whilst it can be misused in untrained hands, can be very powerful in skillful hands. Just because something isn't to one's personal tastes, doesn't mean it should be regarded as anathema or mandatory, IMHO. thanks, BMS From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 17:24:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BFD75106564A for ; Sun, 15 Feb 2009 17:24:29 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout0.freenet.de (mout0.freenet.de [IPv6:2001:748:100:40::2:2]) by mx1.freebsd.org (Postfix) with ESMTP id 4A0BF8FC16 for ; Sun, 15 Feb 2009 17:24:29 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.26] (helo=16.mx.freenet.de) by mout0.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #76) id 1LYkjB-0005XI-4Z; Sun, 15 Feb 2009 18:24:25 +0100 Received: from taa85.t.pppool.de ([89.55.170.133]:56050 helo=ernst.jennejohn.org) by 16.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #76) id 1LYkjA-0007NN-Sz; Sun, 15 Feb 2009 18:24:25 +0100 Date: Sun, 15 Feb 2009 18:24:20 +0100 From: Gary Jennejohn To: Bruce Simpson Message-ID: <20090215182420.774b90c3@ernst.jennejohn.org> In-Reply-To: <49983868.5010107@incunabulum.net> References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <49983868.5010107@incunabulum.net> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Andrew Reilly , freebsd-current@freebsd.org, Andriy Gapon Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 17:24:31 -0000 On Sun, 15 Feb 2009 15:44:40 +0000 Bruce Simpson wrote: > Gary Jennejohn wrote: > ... > > It isn't exactly confidence building that all the links on this page > > are invalid. > > > > I was able to access all of the links on that page without problems from > archive.org. > The original content has moved, this seems to be due to a > re-organisation within the university concerned. > Can you mention exactly which links were invalid for you? > Every one of them. Didn't think to try the wayback machine. > You personally may not be writing systems to run fast and low-level in > C++, but I can think of at least 3 people I know personally who have > done and continue to do so. Given, they are folk who have spent a long > time learning C++ -- the tool has a steep learning curve, and Bjarne > Stroustrup himself would no doubt be the first to admit this. > OT: Actually it has a flat learning curve which implies a longer time span. However, most people use steep incorrectly in this context, which I always find irksome. I've used C++ and hated it - mostly because the customer who required it had the most screwed up ideas regarding how to develop the application. He made the mistake of hiring an external "expert" to come up with classes, etc. The "expert" had no idea what he was doing in the context of the project and the customer eventually went belly up as a result. I personally see no benefit in using C++ in the kernel, but don't let my opinion stop progress from happening. I certainly have no intention of ever using it myself. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 17:48:45 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D30661065679 for ; Sun, 15 Feb 2009 17:48:45 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 846078FC1F for ; Sun, 15 Feb 2009 17:48:45 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n1FHm2rI076387; Sun, 15 Feb 2009 10:48:03 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 15 Feb 2009 10:48:06 -0700 (MST) Message-Id: <20090215.104806.84362163.imp@bsdimp.com> To: olivier@gid0.org From: "M. Warner Losh" In-Reply-To: <20090215111626.GA94483@q.gid0.org> References: <20090215110510.4F3B27302F@freebsd-current.sentex.ca> <20090215111626.GA94483@q.gid0.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 17:48:46 -0000 In message: <20090215111626.GA94483@q.gid0.org> Olivier Smedts writes: : On Sun, Feb 15, 2009 at 06:05:10AM -0500, FreeBSD Tinderbox wrote: : > TB --- 2009-02-15 09:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca : > TB --- 2009-02-15 09:40:00 - starting HEAD tinderbox run for amd64/amd64 : > TB --- 2009-02-15 09:40:00 - cleaning the object tree : > TB --- 2009-02-15 09:40:52 - cvsupping the source tree : > TB --- 2009-02-15 09:40:52 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile : > TB --- 2009-02-15 09:41:00 - building world : > TB --- 2009-02-15 09:41:00 - MAKEOBJDIRPREFIX=/obj : > TB --- 2009-02-15 09:41:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin : > TB --- 2009-02-15 09:41:00 - TARGET=amd64 : > TB --- 2009-02-15 09:41:00 - TARGET_ARCH=amd64 : > TB --- 2009-02-15 09:41:00 - TZ=UTC : > TB --- 2009-02-15 09:41:00 - __MAKE_CONF=/dev/null : > TB --- 2009-02-15 09:41:00 - cd /src : > TB --- 2009-02-15 09:41:00 - /usr/bin/make -B buildworld : > >>> World build started on Sun Feb 15 09:41:02 UTC 2009 : > >>> Rebuilding the temporary build tree : > >>> stage 1.1: legacy release compatibility shims : > >>> stage 1.2: bootstrap tools : > >>> stage 2.1: cleaning up the object tree : > >>> stage 2.2: rebuilding the object tree : > >>> stage 2.3: build tools : > >>> stage 3: cross tools : > >>> stage 4.1: building includes : > >>> stage 4.2: building libraries : > >>> stage 4.3: make dependencies : > >>> stage 4.4: building everything : > >>> stage 5.1: building 32 bit shim libraries : > [...] : > cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 netnatm/*.h /obj/amd64/src/lib32/usr/include/netnatm : > cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 netncp/*.h /obj/amd64/src/lib32/usr/include/netncp : > cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 netsmb/*.h /obj/amd64/src/lib32/usr/include/netsmb : > cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 nfs/*.h /obj/amd64/src/lib32/usr/include/nfs : > cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 nfsclient/*.h /obj/amd64/src/lib32/usr/include/nfsclient : > cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 nfsserver/*.h /obj/amd64/src/lib32/usr/include/nfsserver : > cd /src/include/../sys; sh /src/tools/install.sh -C -o root -g wheel -m 444 pccard/*.h /obj/amd64/src/lib32/usr/include/pccard : > install: pccard/*.h: No such file or directory : > *** Error code 71 : > : > Stop in /src/include. : > *** Error code 1 : > : > Stop in /src/include. : > *** Error code 1 : > : > Stop in /src. : > *** Error code 1 : > : > Stop in /src. : > TB --- 2009-02-15 11:05:10 - WARNING: /usr/bin/make returned exit code 1 : > TB --- 2009-02-15 11:05:10 - ERROR: failed to build world : > TB --- 2009-02-15 11:05:10 - 3992.06 user 389.40 system 5109.67 real : > : : buildworld broken since @188634 : : http://www.freebsd.org/cgi/getmsg.cgi?fetch=17928+0+current/cvs-src-old : : See attached patches. Yes. My bad. Just noticed this myself. Pass me the pointy hat. Warner From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 17:59:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6596106566B for ; Sun, 15 Feb 2009 17:59:41 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 3EC008FC16 for ; Sun, 15 Feb 2009 17:59:41 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id 13E606184; Sun, 15 Feb 2009 12:59:39 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1234720779; bh=0IJ0Tma9kJQSyZgQDq6IFyJb/YJqK211gtiY/+642bA=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=O/il5plISYAGqJMpYST1MUjbxkhivddmphkTiKw2Sh1RaxykEdmWJD0GNL/Mip/mE BuatujjSl6wACfKq4uvOw/FRSh9gTYs6+fn6PJq9g+g/9b2HKmFTgw8ub+QZgEt DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=UlsUm1N57oKslTLB9MQKuTzATjA95Rz/Z2h7/IMOyDzrlASk+7AkLqjHNJMHB3A9/ vs8mzKnue81sTbhgKFdPwKiKXDMlLbzMZGMXvfu8jlacTKEu4pEHd/iHlSuVzib Message-ID: <49985807.805@protected-networks.net> Date: Sun, 15 Feb 2009 12:59:35 -0500 From: Michael Butler User-Agent: Thunderbird 2.0.0.19 (X11/20090128) MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <49983868.5010107@incunabulum.net> <20090215182420.774b90c3@ernst.jennejohn.org> In-Reply-To: <20090215182420.774b90c3@ernst.jennejohn.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=0442D492 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Andrew Reilly , Bruce Simpson , Andriy Gapon , freebsd-current@freebsd.org Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 17:59:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I know that using a "wrapper", something like: #ifdef __cplusplus namespace __whatever { extern "C" { #endif [ .. bunch of C prototypes .. ] #ifdef __cplusplus } #endif .. stops C++ from mangling the prototyped functions so they'll link correctly but does it temporarily disable the "reserved word" tests? Should it? ;-) Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmYWAcACgkQQv9rrgRC1JKnnQCeNJSMhFvG0666r4e+HLXIle1q 0GgAoMqep9fprWjFUB4z0bV0CLuJEV5+ =vRe+ -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 18:01:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33E4310656CF for ; Sun, 15 Feb 2009 18:01:08 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E6C2A8FC16 for ; Sun, 15 Feb 2009 18:01:07 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n1FHwtrT076500; Sun, 15 Feb 2009 10:58:56 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 15 Feb 2009 10:58:59 -0700 (MST) Message-Id: <20090215.105859.-1615350567.imp@bsdimp.com> To: joseph.koshy@gmail.com From: "M. Warner Losh" In-Reply-To: <84dead720902131945s11fc5949j7125bb28b030f055@mail.gmail.com> References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <84dead720902131945s11fc5949j7125bb28b030f055@mail.gmail.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: andrew-freebsd@areilly.bpc-users.org, freebsd-current@freebsd.org, avg@icyb.net.ua Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 18:01:08 -0000 In message: <84dead720902131945s11fc5949j7125bb28b030f055@mail.gmail.com> Joseph Koshy writes: : > Not that this should stop you from de-keywording the include : > files, if that takes your fancy, but permuting a variable : > "class" into "clazz" is a bit gruesome, imo. Why not just comment : > the argument name out altogether? It's not strictly needed in : > the prototype. : : Prefixing parameter names in function prototypes with an underscore : should be enough. : : void function(int _fd); : : (Example taken from style(9)). I've gone ahead and committed this suggestion to sys/conf.h. Warner From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 18:12:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4AA4106566B for ; Sun, 15 Feb 2009 18:12:04 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 613988FC0C for ; Sun, 15 Feb 2009 18:12:02 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 15 Feb 2009 18:12:00 -0000 Received: from p54A3DABF.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.218.191] by mail.gmx.net (mp056) with SMTP; 15 Feb 2009 19:12:00 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX1+0tUdzj7O0+Qr2usE6MH/JI65ZALOydIqs/CcWJu y51iKnqwl1mZ5y Message-ID: <49985AEE.1010709@gmx.de> Date: Sun, 15 Feb 2009 19:11:58 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Michael Butler References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <49983868.5010107@incunabulum.net> <20090215182420.774b90c3@ernst.jennejohn.org> <49985807.805@protected-networks.net> In-Reply-To: <49985807.805@protected-networks.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 Cc: Andrew Reilly , Bruce Simpson , freebsd-current@freebsd.org, Andriy Gapon Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 18:12:05 -0000 Michael Butler schrieb: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I know that using a "wrapper", something like: > > #ifdef __cplusplus > namespace __whatever > { > extern "C" > { > #endif > > [ .. bunch of C prototypes .. ] > > #ifdef __cplusplus > } > #endif > > .. stops C++ from mangling the prototyped functions so they'll link > correctly but does it temporarily disable the "reserved word" tests? > Should it? ;-) No, it doesn't. extern $STRING (the standard only requires "C" and "C++", but there can be more) just changes the linkage of declarations (name mangling, calling convention). From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 18:21:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43B4B106566C for ; Sun, 15 Feb 2009 18:21:40 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 92B548FC14 for ; Sun, 15 Feb 2009 18:21:39 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 15 Feb 2009 18:21:37 -0000 Received: from p54A3DABF.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.218.191] by mail.gmx.net (mp069) with SMTP; 15 Feb 2009 19:21:37 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX18bralyhAcbla8XI99gCUDPXAjD7FHZSOttnC8joC eGsLmjXtxSghlR Message-ID: <49985D30.3050104@gmx.de> Date: Sun, 15 Feb 2009 19:21:36 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <49983868.5010107@incunabulum.net> <20090215182420.774b90c3@ernst.jennejohn.org> In-Reply-To: <20090215182420.774b90c3@ernst.jennejohn.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.65 Cc: Andrew Reilly , Bruce Simpson , Andriy Gapon , freebsd-current@freebsd.org Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 18:21:40 -0000 Gary Jennejohn schrieb: > On Sun, 15 Feb 2009 15:44:40 +0000 > Bruce Simpson wrote: > >> Gary Jennejohn wrote: >> ... >>> It isn't exactly confidence building that all the links on this page >>> are invalid. >>> >> I was able to access all of the links on that page without problems from >> archive.org. >> The original content has moved, this seems to be due to a >> re-organisation within the university concerned. >> Can you mention exactly which links were invalid for you? >> > > Every one of them. Didn't think to try the wayback machine. > >> You personally may not be writing systems to run fast and low-level in >> C++, but I can think of at least 3 people I know personally who have >> done and continue to do so. Given, they are folk who have spent a long >> time learning C++ -- the tool has a steep learning curve, and Bjarne >> Stroustrup himself would no doubt be the first to admit this. >> > > OT: Actually it has a flat learning curve which implies a longer time > span. However, most people use steep incorrectly in this context, which > I always find irksome. > > I've used C++ and hated it - mostly because the customer who required > it had the most screwed up ideas regarding how to develop the > application. He made the mistake of hiring an external "expert" to > come up with classes, etc. The "expert" had no idea what he was doing > in the context of the project and the customer eventually went belly > up as a result. This is no argument against C++. Just replace "C++" by any other language and later "classes" by some language feature of this language. This is an argument against idiots who have no clue but get paid lots of money and even bigger idiots paying them. I've seen abysmal code in Fortran, C, C++, Basic ... > I personally see no benefit in using C++ in the kernel, but don't let > my opinion stop progress from happening. I certainly have no intention > of ever using it myself. From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 18:30:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49AD7106566B for ; Sun, 15 Feb 2009 18:30:20 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id D31C48FC15 for ; Sun, 15 Feb 2009 18:30:19 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n1FIT4v7088063; Sun, 15 Feb 2009 12:29:04 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n1FIT4ZJ088062; Sun, 15 Feb 2009 12:29:04 -0600 (CST) (envelope-from brooks) Date: Sun, 15 Feb 2009 12:29:03 -0600 From: Brooks Davis To: Alexey Shuvaev Message-ID: <20090215182903.GB69320@lor.one-eyed-alien.net> References: <7d6fde3d0902150028n5f07ee55mc6026e1e4935eeb0@mail.gmail.com> <20090215153531.GA36438@wep4035.physik.uni-wuerzburg.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BwCQnh7xodEAoBMC" Content-Disposition: inline In-Reply-To: <20090215153531.GA36438@wep4035.physik.uni-wuerzburg.de> User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Sun, 15 Feb 2009 12:29:04 -0600 (CST) Cc: Garrett Cooper , FreeBSD Current Subject: Re: Annoyance with recent parallelism in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 18:30:20 -0000 --BwCQnh7xodEAoBMC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 15, 2009 at 04:35:31PM +0100, Alexey Shuvaev wrote: > On Sun, Feb 15, 2009 at 12:28:20AM -0800, Garrett Cooper wrote: > > I just updated my world to a recent snapshot (a build from last week) > > and I'm noting some parallelism / backgrounding which is really > > causing issues with my NIC and NFS mounts. I had to hit CTRL-D 5 times > > in order to get the system to come up because it couldn't resolve my > > NFS server's hostname, because the NIC wasn't up and going yet (as it > > uses the DHCP client in background mode due to the new default). > >=20 > > Now I realize that this all ties back into the issue with the NIC > > (which I've approached Pyun about, and which I appreciate his help is > > solving issues with this buggy chipset), but is there really a need > > for parallelism at startup rc.d it can't properly detect dependencies > > with some cases like NFS mounts? > >=20 > Me too. > I have ntpd failing to resolve dns names. > I have noticed this since appr. 1.350 of etc/defaults/rc.conf (12 days ag= o). > I was hoping this will go away... >=20 > Commit log: > SVN rev 188010 on 2009-02-02 15:38:24Z by mtm >=20 > Since, rc.d/defaultroute has the ability to wait for a > default route to show up we can turn this knob back on > without screwing subsequent daemons that expect to be > able to talk to the outside world. >=20 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Seems it is not the case... > Interesting: setting background_dhclient=3D"NO" does not > solve the issue. Maybe something else was changed? > My current 'workaroud' is synchronous_dhclient=3D"YES" The background flag as actually added locally to maintain compatibility with the ISC version. I'd argue it's pointless in the async world and should be ripped out of the client entirely rather than being enabled by default. -- Brooks --BwCQnh7xodEAoBMC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJmF7vXY6L6fI4GtQRAlBuAKC8JZyKBGusSTpSi92zt6slHIQ/AgCgik+7 YkXzp9Jh+6trd3z8A9GVZXM= =Khmo -----END PGP SIGNATURE----- --BwCQnh7xodEAoBMC-- From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 18:41:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17FC21065673 for ; Sun, 15 Feb 2009 18:41:48 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 481158FC17 for ; Sun, 15 Feb 2009 18:41:46 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA21412; Sun, 15 Feb 2009 20:41:37 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1] helo=edge.pp.kiev.ua) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1LYlvs-0003AZ-Pg; Sun, 15 Feb 2009 20:41:36 +0200 Message-ID: <499861DD.7010709@icyb.net.ua> Date: Sun, 15 Feb 2009 20:41:33 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090114) MIME-Version: 1.0 To: "M. Warner Losh" References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <84dead720902131945s11fc5949j7125bb28b030f055@mail.gmail.com> <20090215.105859.-1615350567.imp@bsdimp.com> In-Reply-To: <20090215.105859.-1615350567.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 18:41:48 -0000 on 15/02/2009 19:58 M. Warner Losh said the following: > In message: <84dead720902131945s11fc5949j7125bb28b030f055@mail.gmail.com> > Joseph Koshy writes: > : > Not that this should stop you from de-keywording the include > : > files, if that takes your fancy, but permuting a variable > : > "class" into "clazz" is a bit gruesome, imo. Why not just comment > : > the argument name out altogether? It's not strictly needed in > : > the prototype. > : > : Prefixing parameter names in function prototypes with an underscore > : should be enough. > : > : void function(int _fd); > : > : (Example taken from style(9)). > > I've gone ahead and committed this suggestion to sys/conf.h. Thank you. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 18:50:06 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 516181065678 for ; Sun, 15 Feb 2009 18:50:06 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by mx1.freebsd.org (Postfix) with ESMTP id 390B68FC1C for ; Sun, 15 Feb 2009 18:50:06 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from mbanic-mbp.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp020.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KF4004KJC7GT040@asmtp020.mac.com> for freebsd-current@freebsd.org; Sun, 15 Feb 2009 09:50:05 -0800 (PST) Message-id: <8EF8771C-76D8-4556-96B2-B97B35573CBD@mac.com> From: Marcel Moolenaar To: Christoph Mallon In-reply-to: <499835BE.3000705@gmx.de> Date: Sun, 15 Feb 2009 09:50:04 -0800 References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <499835BE.3000705@gmx.de> X-Mailer: Apple Mail (2.930.3) Cc: Andrew Reilly , Bruce Simpson , freebsd-current@freebsd.org, Andriy Gapon Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 18:50:06 -0000 On Feb 15, 2009, at 7:33 AM, Christoph Mallon wrote: > More robust error handling and less tedious resouce management > directly come to mind: > Just look at normal C functions which allocate resources and have > multiple points which can fail. They are the usual mess of if()s, > goto error and lots of cleanup code. Further all this code looks > pretty much the same in several modules. In C++ you write the > resource handling code once (constructors/destructors) and then you > cannot forget to clean up, because thanks to scoping and defined > life ranges it happens automatically. While on the surface this looks better, under the hood it's just the same. Worse in most likelihood, because with C the programmer writes the logic that is known to be needed (assuming no bugs). With C++ it's the compiler that generates code that handles all possible scenarios, and goes beyond what is strictly needed -- as such the cost tends to be higher, even when there are no errors or exceptions. I'm not saying this is a problem. All I'm saying is that you move responsibility from the programmer to the compiler and in general this comes at a (runtime_ cost. One we may very well accept, mind you... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 18:53:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94DD11065673 for ; Sun, 15 Feb 2009 18:53:41 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C10A88FC1D for ; Sun, 15 Feb 2009 18:53:40 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA21633; Sun, 15 Feb 2009 20:53:36 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1] helo=edge.pp.kiev.ua) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1LYm7U-0003BX-4j; Sun, 15 Feb 2009 20:53:36 +0200 Message-ID: <499864AD.8070105@icyb.net.ua> Date: Sun, 15 Feb 2009 20:53:33 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090114) MIME-Version: 1.0 To: Marcel Moolenaar References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <499835BE.3000705@gmx.de> <8EF8771C-76D8-4556-96B2-B97B35573CBD@mac.com> In-Reply-To: <8EF8771C-76D8-4556-96B2-B97B35573CBD@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 18:53:41 -0000 on 15/02/2009 19:50 Marcel Moolenaar said the following: > > On Feb 15, 2009, at 7:33 AM, Christoph Mallon wrote: >> More robust error handling and less tedious resouce management >> directly come to mind: >> Just look at normal C functions which allocate resources and have >> multiple points which can fail. They are the usual mess of if()s, goto >> error and lots of cleanup code. Further all this code looks pretty >> much the same in several modules. In C++ you write the resource >> handling code once (constructors/destructors) and then you cannot >> forget to clean up, because thanks to scoping and defined life ranges >> it happens automatically. > > While on the surface this looks better, under the hood > it's just the same. Worse in most likelihood, because > with C the programmer writes the logic that is known to > be needed (assuming no bugs). With C++ it's the compiler > that generates code that handles all possible scenarios, > and goes beyond what is strictly needed -- as such the > cost tends to be higher, even when there are no errors > or exceptions. Then maybe we should stick to assembly? Just thinking about how I have two use two operators "/", "%" where I can do with only one x86 assembly instruction makes me mad - not. I.e. this is not to say that I am against assembly - there are many places in our kernel that would be plain impossible to code with C. And not to say that I am against C. This is only to say that there are certain things that are much easier, and safer too, to code in C++ that in C. And that might be in kernel too. > I'm not saying this is a problem. All I'm saying is that > you move responsibility from the programmer to the compiler > and in general this comes at a (runtime_ cost. One we may > very well accept, mind you... > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 19:19:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A07081065672 for ; Sun, 15 Feb 2009 19:19:31 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id AD45C8FC14 for ; Sun, 15 Feb 2009 19:19:30 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 15 Feb 2009 19:19:27 -0000 Received: from p54A3DABF.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.218.191] by mail.gmx.net (mp058) with SMTP; 15 Feb 2009 20:19:27 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19u0VlS6uRuPfO2XWIEWqkCCCWkYOkpr1JVCAiGXg JECAT+aVPGGLYy Message-ID: <49986ABB.5040207@gmx.de> Date: Sun, 15 Feb 2009 20:19:23 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Marcel Moolenaar References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <499835BE.3000705@gmx.de> <8EF8771C-76D8-4556-96B2-B97B35573CBD@mac.com> In-Reply-To: <8EF8771C-76D8-4556-96B2-B97B35573CBD@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.58 Cc: Andrew Reilly , Bruce Simpson , freebsd-current@freebsd.org, Andriy Gapon Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 19:19:32 -0000 Marcel Moolenaar schrieb: > > On Feb 15, 2009, at 7:33 AM, Christoph Mallon wrote: >> More robust error handling and less tedious resouce management >> directly come to mind: >> Just look at normal C functions which allocate resources and have >> multiple points which can fail. They are the usual mess of if()s, goto >> error and lots of cleanup code. Further all this code looks pretty >> much the same in several modules. In C++ you write the resource >> handling code once (constructors/destructors) and then you cannot >> forget to clean up, because thanks to scoping and defined life ranges >> it happens automatically. > > While on the surface this looks better, under the hood > it's just the same. Worse in most likelihood, because Of course it's the same, all these languages are Turing-complete! > with C the programmer writes the logic that is known to > be needed (assuming no bugs). With C++ it's the compiler Assuming no bugs, the Ariane wouldn't have exploded, Sojourner would've worked perfectly from day one, Hubble wouldn't have needed a correcting lense, ... The whole idea is to lower the probability of making errors. The resource allocation scenario I sketched earlier is one example for that: Lots of tedious and very similar code, which makes the process of writing it error prone. > that generates code that handles all possible scenarios, > and goes beyond what is strictly needed -- as such the > cost tends to be higher, even when there are no errors > or exceptions. There is no fairy which magically makes code appear everywhere. All code which gets generated is clearly defined by the programmer: You write code for constructors and destructors. All inserted code is placed at the boundaries of life ranges of objects. When an object is created its constructor is called, when it is destroyed its destructor is called. The compiler keeps track where exactly the life ranges of objects begin and end and properly inserts the code there. The programmer determines the life ranges of the objects either by new/delete, aggregating objects in classes or creating local objects in function {} scope. in C you write something like that: typedef struct FOO { A* a; B* b; C* c; } FOO; FOO* Allocate_FOO() { FOO* f = malloc(*f); if (f == NULL) return NULL; lock(some_lock); f->a = allocate_A(); if (f->a == NULL) goto fail; f->b = allocate_B(); if (f->b == NULL) goto fail; f->c = allocate_C(); if (f->c == NULL) goto fail; unlock(some_lock); return f; fail: if (f->b) deallocate_B(f->b); if (f->a) deallocate_A(f->a); free(f); unlock(some_lock); return NULL; } or worse and more error prone but seen often: FOO* Allocate_FOO() { FOO* f = malloc(*f); if (f == NULL) return NULL; lock(some_lock); f->a = allocate_A(); if (f->a == NULL) { free(f); unlock(some_lock); return NULL; } f->b = allocate_B(); if (f->b == NULL) { deallocate_A(f->a); free(f); /* Nobody will notice this lock leak until allocating B * fails some day. */ return NULL; } f->c = allocate_C(); if (f->c == NULL) { /* Whoops, allocating resource B was added later and we * forgot to deallocate it here. */ deallocate_A(f->a); free(f); unlock(some_lock); return NULL; } unlock(some_lock); return f; } In C++ you write something like this: class FOO { public: FOO(); private: auto_ptr a; auto_ptr b; auto_ptr c; }; FOO::FOO() { LockHolder l(some_lock); a = new A(); b = new B(); c = new C(); } There is no way to have a resource leak here: No matter how the constructor is left (regular return or exception), the lock is released via the destructor of the LockHolder. Also if any of the constructors of A, B or C throws an exception all objects created till this point are properly destroyed by the destructors of the auto_ptr<>s (per language specification in the reverse order of declaration in the class). I consider this a improvement: The code is more concise and writing it is less error prone. Oh, let's not forget deallocating FOO: void deallocate_FOO(FOO* f) { deallocate_C(f->c); deallocate_B(f->b); deallocate_A(f->a); } and the C++ version: /* No code needed, the default destructor of FOO already does The Right * Thing(TM), i.e. destroys all subobjects in reverse order of * declaration */ > I'm not saying this is a problem. All I'm saying is that > you move responsibility from the programmer to the compiler > and in general this comes at a (runtime_ cost. One we may > very well accept, mind you... Writing the code correctly once is still in the hands of the programmer. Copying the code where it is needed now is the job of the compiler. The compiler can do the more tedious parts and in this way help the programmer. Whew, this got longer than intended. Hopefully I could point out one of the benefits of C++. Please bear in mind this is no anti-C campaign. I just want to point out that C++ provides mechanisms to help writing better code. From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 20:18:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E8F1106566C for ; Sun, 15 Feb 2009 20:18:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outU.internet-mail-service.net (outu.internet-mail-service.net [216.240.47.244]) by mx1.freebsd.org (Postfix) with ESMTP id 6D0BA8FC15 for ; Sun, 15 Feb 2009 20:18:18 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id 67BB1245A; Sun, 15 Feb 2009 12:18:18 -0800 (PST) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 4C9182D6017; Sun, 15 Feb 2009 12:18:17 -0800 (PST) Message-ID: <49987895.2010502@elischer.org> Date: Sun, 15 Feb 2009 12:18:29 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Bruce Simpson References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <49983868.5010107@incunabulum.net> In-Reply-To: <49983868.5010107@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrew Reilly , freebsd-current@freebsd.org, Andriy Gapon Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 20:18:18 -0000 Bruce Simpson wrote: > Gary Jennejohn wrote: > ... >> It isn't exactly confidence building that all the links on this page >> are invalid. >> > > I was able to access all of the links on that page without problems from > archive.org. > The original content has moved, this seems to be due to a > re-organisation within the university concerned. > Can you mention exactly which links were invalid for you? > >> This is all from 2005 and AFAICT has languished since then. I'm not >> aware of >> any movement within the Linux community to bring C++ support into the >> kernel. >> > Not much changes in an established programming language in 3-4 years, > unless it is still mutating (e.g. C#, Python). > > This is pure speculation on my part, however: I wager the patches had > bit-rotted for no good reason other than lack of interest or ignorance, > certainly not from active opposition, perhaps apart from Linus Torvalds > who had weighed in against C++ in other threads. > > FreeBSD is not Linux, however, and the jury's still out on this one. > >> I haven't been paying much attention to this thread, but I can't recall >> having read any persuasive arguments for using C++ in the kernel. >> > > Kernel-like systems are built with C++, this is just a fact of life. > Think games, think embedded systems. > > You personally may not be writing systems to run fast and low-level in > C++, but I can think of at least 3 people I know personally who have > done and continue to do so. Given, they are folk who have spent a long > time learning C++ -- the tool has a steep learning curve, and Bjarne > Stroustrup himself would no doubt be the first to admit this. > > Whilst code such as the Standard Template Library (STL) may not be an > appropriate fit for all low-level uses, the fact of the matter is, > something from has had many pairs of eyeballs on it. Having > to hand-code stuff like set symmetric difference is tedious if you don't > actually have to do it. If you do -- work smarter, not harder. > > I wonder if many of the objections raised against C++ have actually been > considered in the light of the new C++0x spec. > > At the moment, there are several projects out there which don't even > involve C++ in the *kernel*, which are directly impacted by the issues > which Andriy is attempting to solve because they use the system headers; > I therefore fully support what he is doing, as he is saving people a lot > of hassle. > > It's time to get real, and admit that C++ is a very powerful tool that, > whilst it can be misused in untrained hands, can be very powerful in > skillful hands. Just because something isn't to one's personal tastes, > doesn't mean it should be regarded as anathema or mandatory, IMHO. I've come to the conclusion that unembelished C is actually the wrong language for kernel development. I think that something a bit higher should be used as a framenwork for C-like processing segments. I should be able to specify that a entity is: * Mostly read from, rarely written to. * Has an LRU requirement * has to be looked up on some field * has to be connected to some other entities in some way * can be invalidated while other components hold references to it. etc. and The framework should handle all that, including adding the appropriate fields to the structs etc. I should only need to do code for teh specific things for that structure that the framenwork doesn't handle. There are some factors of C++ that allows SOME of this but I would like to go even further and make the framework actually generate the classes from which we derive the actual entity we use. In particular I think that locking should be automatic, and that while it can be "influenced" (i.e. telling the framework about access patterns) it should then be handled automatically. Modularization and dependencies should all be handled automaically. we have the basis of this technology but we still have to do much too much "by hand". I know its all very optimistic, but 35 years of programming tells me that eventually someone will get there and then all other OS kernels will become out of date over-night. > thanks, > BMS > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 22:34:34 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A069F106564A for ; Sun, 15 Feb 2009 22:34:34 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 66B128FC08 for ; Sun, 15 Feb 2009 22:34:34 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 61A57FF39 for ; Mon, 16 Feb 2009 11:34:33 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kgJkKNV5Bhw for ; Mon, 16 Feb 2009 11:34:29 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP for ; Mon, 16 Feb 2009 11:34:29 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id E25181142B; Mon, 16 Feb 2009 11:34:28 +1300 (NZDT) Date: Sun, 15 Feb 2009 14:34:28 -0800 From: Andrew Thompson To: current@freebsd.org Message-ID: <20090215223428.GA74071@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Subject: HEADSUP: USB2 now default in GENERIC kernels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 22:34:35 -0000 Hi, The GENERIC kernels for all architectures now default to the new USB2 stack. No kernel config options or code have been removed so if a problem arises please report it and optionally revert to the old USB stack. IMPORTANT NOTES: 1. If you are loading USB kernel modules then ensure that these are also changed over, eg uftdi.ko -> usb2_serial_ftdi.ko. You can not load oldUSB modules with the GENERIC kernels. 2. If you have a custom kernel that includes GENERIC as a base, you need to ensure that any additional usb devices that you specify are changed over. 3. The USB2 kernel options and module names are _temporary_. The next stage is to move the USB2 code into its permanent location in the source tree and at that point will take over the well established naming. (ie, usb, ehci, ohci, uftdi). There will be no changes going from FreeBSD 7.x -> 8.0 4. Once (3) is complete the oldUSB code will still be usable until much closer to the 8.0 branch. Please report any issues to the mailing lists. regards, Andrew From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 23:29:08 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 440201065675; Sun, 15 Feb 2009 23:29:08 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 043088FC15; Sun, 15 Feb 2009 23:29:08 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id EAA256111; Sun, 15 Feb 2009 18:29:06 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1234740547; bh=JpsyiOtAUG8yKklbotRAYGCheJNezKKATbrFlZBENeQ=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=NUuzvUy9B6DOvxfheQQ7JeTzrIut98UVvmjFYYF6Jx0FGvyQnXKpKXerhyzxmsBuo OPrc0UIe9iwTbGx7YvSQE1bmObLB8PjyPAWtAYZxmFuk4js0DlD569MNY+nZwQf DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=lHkTaowz3Cyh+UoPP/vBAOoe/mwSc0lwDQS/nAlmLfJc57/IyC5l1/AVlPVyPVx8G 9Lfh5gysAPjUaeZri0fmiW2ScfjQhl3IqF19gAngbYhHTeMr1e2BRhWx4uQaZrx Message-ID: <4998A53C.9040706@protected-networks.net> Date: Sun, 15 Feb 2009 18:29:00 -0500 From: Michael Butler User-Agent: Thunderbird 2.0.0.19 (X11/20090128) MIME-Version: 1.0 To: Andrew Thompson References: <20090215223428.GA74071@citylink.fud.org.nz> In-Reply-To: <20090215223428.GA74071@citylink.fud.org.nz> X-Enigmail-Version: 0.95.7 OpenPGP: id=0442D492 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: HEADSUP: USB2 now default in GENERIC kernels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 23:29:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andrew Thompson wrote: > The GENERIC kernels for all architectures now default to the new USB2 stack. No > kernel config options or code have been removed so if a problem arises please > report it and optionally revert to the old USB stack. usb2_serial_slcom seems not to have made it into the switch, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmYpTwACgkQQv9rrgRC1JL1EwCePY5KBGRjz4XU00fDhf9/y0bM 9QcAoKWhZd/WS3ekoic0wpKjG8MV4gnS =TOCQ -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Feb 15 23:41:00 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 347F71065670 for ; Sun, 15 Feb 2009 23:41:00 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id ECF938FC17 for ; Sun, 15 Feb 2009 23:40:59 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 2DC69FF39; Mon, 16 Feb 2009 12:40:59 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XG9hnAQgGvK0; Mon, 16 Feb 2009 12:40:55 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Mon, 16 Feb 2009 12:40:55 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id E780D1142F; Mon, 16 Feb 2009 12:40:54 +1300 (NZDT) Date: Sun, 15 Feb 2009 15:40:54 -0800 From: Andrew Thompson To: Michael Butler Message-ID: <20090215234054.GA3397@citylink.fud.org.nz> References: <20090215223428.GA74071@citylink.fud.org.nz> <4998A53C.9040706@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4998A53C.9040706@protected-networks.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: current@freebsd.org Subject: Re: HEADSUP: USB2 now default in GENERIC kernels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Feb 2009 23:41:00 -0000 On Sun, Feb 15, 2009 at 06:29:00PM -0500, Michael Butler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Andrew Thompson wrote: > > The GENERIC kernels for all architectures now default to the new USB2 stack. No > > kernel config options or code have been removed so if a problem arises please > > report it and optionally revert to the old USB stack. > > usb2_serial_slcom seems not to have made it into the switch, Fixed in r188665, thanks. From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 01:11:42 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 02439106566B for ; Mon, 16 Feb 2009 01:11:42 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id 52F188FC0A for ; Mon, 16 Feb 2009 01:11:41 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from phenom.cordula.ws (phenom [192.168.254.60]) by fw.farid-hajji.net (Postfix) with ESMTP id C9390325F1; Mon, 16 Feb 2009 01:52:36 +0100 (CET) Date: Mon, 16 Feb 2009 01:52:36 +0100 From: cpghost To: Marcel Moolenaar Message-ID: <20090216005236.GA1751@phenom.cordula.ws> References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <499835BE.3000705@gmx.de> <8EF8771C-76D8-4556-96B2-B97B35573CBD@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8EF8771C-76D8-4556-96B2-B97B35573CBD@mac.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 01:11:42 -0000 On Sun, Feb 15, 2009 at 09:50:04AM -0800, Marcel Moolenaar wrote: > On Feb 15, 2009, at 7:33 AM, Christoph Mallon wrote: > > More robust error handling and less tedious resouce management > > directly come to mind: > > Just look at normal C functions which allocate resources and have > > multiple points which can fail. They are the usual mess of if()s, > > goto error and lots of cleanup code. Further all this code looks > > pretty much the same in several modules. In C++ you write the > > resource handling code once (constructors/destructors) and then you > > cannot forget to clean up, because thanks to scoping and defined > > life ranges it happens automatically. > > While on the surface this looks better, under the hood > it's just the same. Worse in most likelihood, because > with C the programmer writes the logic that is known to > be needed (assuming no bugs). With C++ it's the compiler > that generates code that handles all possible scenarios, > and goes beyond what is strictly needed -- as such the > cost tends to be higher, even when there are no errors > or exceptions. > > I'm not saying this is a problem. All I'm saying is that > you move responsibility from the programmer to the compiler > and in general this comes at a (runtime_ cost. One we may > very well accept, mind you... You just have to know how to use C++ properly and avoid some constructs to create efficient code. Have a look at L4::Pistachio for an example: http://l4ka.org/projects/pistachio/ > Marcel Moolenaar > xcllnt@mac.com -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 01:22:27 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E653A1065672 for ; Mon, 16 Feb 2009 01:22:27 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id B2A698FC15 for ; Mon, 16 Feb 2009 01:22:27 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by wa-out-1112.google.com with SMTP id k34so1002933wah.27 for ; Sun, 15 Feb 2009 17:22:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EjvY5wf8FHSKma3mnXORDNjdSbCbn48OXzDBGv2Zk8g=; b=YaDmOpecjc1QLTkThyNDNPa9O+1276ATEbF7jKKCa3n7M9HnCNAZTrvd1eG32fUGqb 4pQZP+zvAgsCBYWz++WeoD8KnvCLCMyiHJsG7r8aAQ8pctimr42+8ZjBWSuOtOG9fuea eqGBQoOVA9F8nzAWaf4IJHfB0s+DALkjvmdGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=XoBEWxK8mBPWVIB6RpiRLZ940i0y2URnl7Rnm2fC54gb2tqKaVZ21kCVRTrZwT2DlL gwlprBbsahOWet2mJt+M1jlZ4tJoMCeJVNDKt7oVU6UQs91cvzbP/w8WgUQoXsVdEVM5 2xg0Bls0dRbbX1fnU+AsR1dBOC5XsvaTJDti8= MIME-Version: 1.0 Received: by 10.114.73.14 with SMTP id v14mr1890323waa.104.1234747347119; Sun, 15 Feb 2009 17:22:27 -0800 (PST) In-Reply-To: <442505824.71673.1234559053919.JavaMail.apache@mail53.abv.bg> References: <442505824.71673.1234559053919.JavaMail.apache@mail53.abv.bg> Date: Sun, 15 Feb 2009 17:22:27 -0800 Message-ID: <7d6fde3d0902151722x24aeed88na79ed5093f5d2569@mail.gmail.com> From: Garrett Cooper To: Mario Pavlov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dev@lists.pcbsd.org, kris@pcbsd.com, freebsd-current@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: [Fw: Re: [PC-BSD Dev] vmap()-like kernel interface ] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 01:22:28 -0000 On Fri, Feb 13, 2009 at 1:04 PM, Mario Pavlov wrote: > Hi, > please find the attached e-mail > > regards > mgp > > P.S. thanks, PC-BSD team I'm not a kernel dev, but I noted that pmap_unmapcontig doesn't take into consideration when va is NULL; I know it's bad driver programming if uncontig is implicitly called with NULL, but there should be some error handling or something here (a NULL deref will occur in pmap_qremove, which will cause a panic). Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 02:32:10 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 555DA106564A for ; Mon, 16 Feb 2009 02:32:10 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 160738FC19 for ; Mon, 16 Feb 2009 02:32:10 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Iain Michael Butler", Issuer "Protected Networks Certificate Authority" (verified OK)) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id 3B59460D2 for ; Sun, 15 Feb 2009 21:32:09 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1234751529; bh=05UwWt5j30F0xeRxT01sdL+CI5FGHk+QwnI1gvpjc8U=; h=Message-ID:Date:From:MIME-Version:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=C3Anx5k9yK5+lp1jtxeyK31BwGKGc3Yt8QZOblzQqbbdb1MSNXk3a7R7jHV+0b/mv KSR2LTiQBhXlQvFkUQ8M2EHPWSfLg4TRCLTQ6UTjmMs7T4pDauseJ7uHF8eHEQY DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=l8M7suZ68PQgnAow3i8UOslgilfEX4pAb8Mkhfqz0bCZAtKwgzMNmJ4nTy70FTFtz PK5H/DX1hqg/DlDvfCZWR/tiO3K361aOVzfCyQpXGvNX4k/mMbMSUM7gHdFsyhL Message-ID: <4998D027.5030501@protected-networks.net> Date: Sun, 15 Feb 2009 21:32:07 -0500 From: Michael Butler User-Agent: Thunderbird 2.0.0.19 (X11/20090128) MIME-Version: 1.0 References: <20090215223428.GA74071@citylink.fud.org.nz> In-Reply-To: <20090215223428.GA74071@citylink.fud.org.nz> X-Enigmail-Version: 0.95.7 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: USB2 and USB mice X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 02:32:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 dmesg says: ugen2.2: at usbus2 ums0: on usbus2 ums0: 3 buttons and [XYZ] coordinates Symlink: ums0 -> usb2.2.0.16 .. but ls -l /dev shows no such device .. imb@toshi:/home/imb> ls -al /dev/u* lrwxr-xr-x 1 root wheel 6 Feb 15 21:01 /dev/urandom -> random crw-rw-rw- 1 root operator 0, 74 Feb 15 21:01 /dev/usb With USB-1, hald would create two processes, one for each mouse (synaptics touchpad and usb mouse), but now I only see one even after relinking with libusb20: 35157 ?? Rs 12:30.22 /usr/local/sbin/hald 35158 ?? I 0:00.02 hald-runner 35164 ?? I 0:00.05 hald-addon-mouse-sysmouse: /dev/psm0 (hald-addon-mouse-sy) 35168 ?? S 0:00.12 hald-addon-storage: /dev/cd0 (hald-addon-storage) No amount of fiddling with usbconfig seems to make any difference. What am I missing here? Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmY0CcACgkQQv9rrgRC1JKrcwCgxNPZwgX7mB7RABXdf/s6Ffw9 40oAniKx11D2kATFsW188Fqn8QNqc7jO =aNcv -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 02:34:39 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F31E106566B for ; Mon, 16 Feb 2009 02:34:39 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id D55A88FC0C for ; Mon, 16 Feb 2009 02:34:38 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 1F2B1FF39; Mon, 16 Feb 2009 15:34:38 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANS8Oraiz5sG; Mon, 16 Feb 2009 15:34:33 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Mon, 16 Feb 2009 15:34:33 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 3DA8211428; Mon, 16 Feb 2009 15:34:33 +1300 (NZDT) Date: Sun, 15 Feb 2009 18:34:33 -0800 From: Andrew Thompson To: Michael Butler Message-ID: <20090216023433.GA3800@citylink.fud.org.nz> References: <20090215223428.GA74071@citylink.fud.org.nz> <4998D027.5030501@protected-networks.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4998D027.5030501@protected-networks.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: current@freebsd.org Subject: Re: USB2 and USB mice X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 02:34:40 -0000 On Sun, Feb 15, 2009 at 09:32:07PM -0500, Michael Butler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > dmesg says: > > ugen2.2: at usbus2 > ums0: rev 1.10/1.00, addr 2> on usbus2 > ums0: 3 buttons and [XYZ] coordinates > Symlink: ums0 -> usb2.2.0.16 > > .. but ls -l /dev shows no such device .. > > imb@toshi:/home/imb> ls -al /dev/u* > lrwxr-xr-x 1 root wheel 6 Feb 15 21:01 /dev/urandom -> > random > crw-rw-rw- 1 root operator 0, 74 Feb 15 21:01 /dev/usb > > With USB-1, hald would create two processes, one for each mouse > (synaptics touchpad and usb mouse), but now I only see one even after > relinking with libusb20: > > 35157 ?? Rs 12:30.22 /usr/local/sbin/hald > > > 35158 ?? I 0:00.02 hald-runner > > > 35164 ?? I 0:00.05 hald-addon-mouse-sysmouse: /dev/psm0 > (hald-addon-mouse-sy) > > 35168 ?? S 0:00.12 hald-addon-storage: /dev/cd0 > (hald-addon-storage) > > > No amount of fiddling with usbconfig seems to make any difference. > > What am I missing here? You are right on the button. There is a patch in progres to fix this and create device nodes. Should hopefully be in this week. Andrew From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 02:56:04 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99D90106564A for ; Mon, 16 Feb 2009 02:56:04 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 2F6CA8FC08 for ; Mon, 16 Feb 2009 02:56:04 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id n1G2v4u6088576; Sun, 15 Feb 2009 21:57:04 -0500 (EST) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Michael Butler In-Reply-To: <4998D027.5030501@protected-networks.net> References: <20090215223428.GA74071@citylink.fud.org.nz> <4998D027.5030501@protected-networks.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-6ISMG4IaZSYsDtpi3Amx" Organization: MarcusCom, Inc. Date: Sun, 15 Feb 2009 21:56:03 -0500 Message-Id: <1234752963.42927.171.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.4 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: current@freebsd.org Subject: Re: USB2 and USB mice X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 02:56:04 -0000 --=-6ISMG4IaZSYsDtpi3Amx Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2009-02-15 at 21:32 -0500, Michael Butler wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > dmesg says: >=20 > ugen2.2: at usbus2 > ums0: rev 1.10/1.00, addr 2> on usbus2 > ums0: 3 buttons and [XYZ] coordinates > Symlink: ums0 -> usb2.2.0.16 >=20 > .. but ls -l /dev shows no such device .. >=20 > imb@toshi:/home/imb> ls -al /dev/u* > lrwxr-xr-x 1 root wheel 6 Feb 15 21:01 /dev/urandom -> > random > crw-rw-rw- 1 root operator 0, 74 Feb 15 21:01 /dev/usb >=20 > With USB-1, hald would create two processes, one for each mouse > (synaptics touchpad and usb mouse), but now I only see one even after > relinking with libusb20: >=20 > 35157 ?? Rs 12:30.22 /usr/local/sbin/hald >=20 >=20 > 35158 ?? I 0:00.02 hald-runner >=20 >=20 > 35164 ?? I 0:00.05 hald-addon-mouse-sysmouse: /dev/psm0 > (hald-addon-mouse-sy) >=20 > 35168 ?? S 0:00.12 hald-addon-storage: /dev/cd0 > (hald-addon-storage) >=20 >=20 > No amount of fiddling with usbconfig seems to make any difference. >=20 > What am I missing here? Hal doesn't yet work with usb2. You will need to statically configure your input devices in xorg.conf until support is added. Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-6ISMG4IaZSYsDtpi3Amx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkmY1cIACgkQb2iPiv4Uz4dPngCggiLCqbKypGds1kEKdleaPXHE MssAnRQec+5Tli+ob3AZbkNVEWRW0B4D =kbh3 -----END PGP SIGNATURE----- --=-6ISMG4IaZSYsDtpi3Amx-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 05:00:52 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33AA11065670 for ; Mon, 16 Feb 2009 05:00:52 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id EA79D8FC0A for ; Mon, 16 Feb 2009 05:00:51 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from localhost (pool-141-151-14-70.phlapa.east.verizon.net [141.151.14.70]) by mail.asahi-net.or.jp (Postfix) with ESMTP id A28075D45E; Mon, 16 Feb 2009 14:00:47 +0900 (JST) Date: Mon, 16 Feb 2009 00:00:44 -0500 From: Yoshihiro Ota To: Xin LI , =?UTF-8?B?6KO05Zu95YW0?= Message-Id: <20090216000044.d77fec80.ota@j.email.ne.jp> In-Reply-To: <499531A4.3020308@delphij.net> References: <98869b7c0902100112s6dae54bm4c14487076ceb75c@mail.gmail.com> <20090212183440.GA1446@tops> <20090213001350.52470f39.ota@j.email.ne.jp> <499531A4.3020308@delphij.net> X-Mailer: Sylpheed 2.6.0 (GTK+ 2.12.11; i386-portbld-freebsd7.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Gleb Kurtsou , freebsd-current@freebsd.org, imura@FreeBSD.org Subject: RE: patch: let msdosfs(vfat)/ntfs to support UTF-8 locale well X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 05:00:52 -0000 FYI: This is another person who attempted the same or similar. It begins with the following one and got a couple of replies. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=262846+0+archive/2006/freebsd-hackers/20060813.freebsd-hackers Is anyone intend to work on this issue? Regards, Hiro On Fri, 13 Feb 2009 00:39:00 -0800 Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > (cc'ed to freebsd-fs@) > > I think it's important that someone familiar with the code review and > evaluate the current patches and commit it against -HEAD... > > MSDOSFS patch (against 7.1): > http://btload.googlegroups.com/web/msdosfs.patch?gda=MzIscT8AAABs_gmy4a1S9lRiXjEy-V5OpwtI67JnIGlz0zr18tjObOtoi5oIt3BJMRGeqGBbbj-ccyFKn-rNKC-d1pM_IdV0 > NTFS patch: > http://btload.googlegroups.com/web/ntfs.patch?gda=OqsHoDwAAABs_gmy4a1S9lRiXjEy-V5O7RN7t-m4MjZ-5dQn_EvaqDVCWO9_HyYEQJyRQYPtRCL9Wm-ajmzVoAFUlE7c_fAt > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.10 (FreeBSD) > > iEUEARECAAYFAkmVMaQACgkQi+vbBBjt66DN+wCghJbOUO7IfEwt5gFOB01uAAe1 > NLwAmOQXPJsB+lT7o5MMk16Ck6eUJrQ= > =ZGMA > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 05:56:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67ADC106564A for ; Mon, 16 Feb 2009 05:56:40 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntmtas01p.mx.bigpond.com (nskntmtas01p.mx.bigpond.com [61.9.168.137]) by mx1.freebsd.org (Postfix) with ESMTP id F38978FC0A for ; Mon, 16 Feb 2009 05:56:39 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntotgx03p.mx.bigpond.com ([124.188.162.219]) by nskntmtas01p.mx.bigpond.com with ESMTP id <20090216055638.GIJB6186.nskntmtas01p.mx.bigpond.com@nskntotgx03p.mx.bigpond.com> for ; Mon, 16 Feb 2009 05:56:38 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nskntotgx03p.mx.bigpond.com with ESMTP id <20090216055637.DVJ5528.nskntotgx03p.mx.bigpond.com@areilly.bpa.nu> for ; Mon, 16 Feb 2009 05:56:37 +0000 Received: (qmail 71147 invoked by uid 501); 16 Feb 2009 05:56:02 -0000 Date: Mon, 16 Feb 2009 16:56:02 +1100 From: Andrew Reilly To: Christoph Mallon Message-ID: <20090216055602.GA70145@duncan.reilly.home> References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <499835BE.3000705@gmx.de> <8EF8771C-76D8-4556-96B2-B97B35573CBD@mac.com> <49986ABB.5040207@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49986ABB.5040207@gmx.de> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150203.49990016.000A,ss=1,fgs=0 Cc: Marcel Moolenaar , Andriy Gapon , Bruce Simpson , freebsd-current@freebsd.org Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 05:56:40 -0000 On Sun, Feb 15, 2009 at 08:19:23PM +0100, Christoph Mallon wrote: > There is no fairy which magically makes code appear everywhere. All code > which gets generated is clearly defined by the programmer: You write > code for constructors and destructors. All inserted code is placed at > the boundaries of life ranges of objects. When an object is created its > constructor is called, when it is destroyed its destructor is called. > The compiler keeps track where exactly the life ranges of objects begin > and end and properly inserts the code there. The programmer determines > the life ranges of the objects either by new/delete, aggregating objects > in classes or creating local objects in function {} scope. The problem with C++ isn't really the functions that it provides, it's the functions that it doesn't. Personally, I'd like C++ a *lot* better if it required a garbage collecting runtime. The problem with the way it works at the moment is that object creation interacts with argument promotion and constructors (and C++'s ability to grab references inside the guts of objects, whch it inherited from C) in such a way that you can have temporary object creation inserted by the compiler in the middle of an expression, with no way to ensure that the resulting object is reaped at the right time. And that's because the compiler can't, in general, know what is the right thing to do: if the called function retains the reference in a long-lived structure then the temporary should be constructed on the heap, and explicitly freed somewhere else. If it isn't retained, then the temporary object should be collected as the expression scope is exited. Since there's no way for the compiler to make that call, you almost inevitably wind up with either memory leaks or you constrain yourself to operate with a restricted, not-quite-object-oriented style, which can't really be enforced by the compiler. I don't need to mention what a bad idea memory leaks are in kernel mode, right? > There is no way to have a resource leak here: No matter how the > constructor is left (regular return or exception), the lock is released > via the destructor of the LockHolder. Also if any of the constructors of > A, B or C throws an exception all objects created till this point are > properly destroyed by the destructors of the auto_ptr<>s (per language > specification in the reverse order of declaration in the class). > I consider this a improvement: The code is more concise and writing it > is less error prone. I'll admit that my working knowledge of C++ pre-dates auto_ptr<>s. (And they seem strangely absent from the C++ code that my coleagues write: not sure what that means.) It's possible that there is now enough runtime smarts to avoid the problems I mentioned, above. If so, I'd like to know about it (but not enough to actually go and look it up...) > Writing the code correctly once is still in the hands of the programmer. > Copying the code where it is needed now is the job of the compiler. The > compiler can do the more tedious parts and in this way help the programmer. The problem is that it is not always obvious (particualry when there can be promotion of arguments through non-default copy constructors) exactly where the compiler's magic is invoked in C++. Almost everything is always explicit in C, and IMO that's a significant benefit. > Whew, this got longer than intended. Hopefully I could point out one of > the benefits of C++. Please bear in mind this is no anti-C campaign. I > just want to point out that C++ provides mechanisms to help writing > better code. Frankly, I'd really quite like to see something like a Java subsystem built in. Sure, you don't want to pull in the whole huge standard library (restriction of subsetting by licencing has always been Java's main drawback, IMO), but as you say: there are often places where simpler construction of safe code is a benefit in and of itself. Maybe C++ is a useful step in that direction, but I just don't think so. The age and seeming dead-end-ness of the LinuxCXX project reference that was posted here would seem to argue so. On the other hand, both eCos and OK-L4 (and some other L4 implementations) are in C++, so clearly it can be made to work under some circumstances. On the other, other hand, Eiffel is a language with all of the safety and object-orientation (including multiple inheritance and generic containers) of C++. Device drivers and low-level code have been written for quite a few things (HP laser printers were the pin-up for a while). There are implementations that compile through C as an intermediate language, so integration and portability shouldn't be too much of a stretch. Importantly, Eiffel has always required garbage collection, so issues of collection responsilbility and leakage don't arise. If Eiffel seems too complicated (or ill, if not dead) then Modula3 has some history within FreeBSD and has most of the same plusses (but not multiple inheritance). [Sorry: I shouldn't have commented. I'm a bit of a language junkie. I just think that C++ was mostly a wrong turn in the language design space.] Cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 06:02:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E181A1065675 for ; Mon, 16 Feb 2009 06:02:32 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwmtas03p.mx.bigpond.com (nschwmtas03p.mx.bigpond.com [61.9.189.143]) by mx1.freebsd.org (Postfix) with ESMTP id 7B38B8FC12 for ; Mon, 16 Feb 2009 06:02:32 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwotgx03p.mx.bigpond.com ([124.188.162.219]) by nschwmtas03p.mx.bigpond.com with ESMTP id <20090216060216.LKPB16649.nschwmtas03p.mx.bigpond.com@nschwotgx03p.mx.bigpond.com> for ; Mon, 16 Feb 2009 06:02:16 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nschwotgx03p.mx.bigpond.com with ESMTP id <20090216060215.TVRL7357.nschwotgx03p.mx.bigpond.com@areilly.bpa.nu> for ; Mon, 16 Feb 2009 06:02:15 +0000 Received: (qmail 71265 invoked by uid 501); 16 Feb 2009 06:02:08 -0000 Date: Mon, 16 Feb 2009 17:02:08 +1100 From: Andrew Reilly To: Bruce Simpson Message-ID: <20090216060208.GB70145@duncan.reilly.home> References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <49983868.5010107@incunabulum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49983868.5010107@incunabulum.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, Andriy Gapon Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 06:02:33 -0000 On Sun, Feb 15, 2009 at 03:44:40PM +0000, Bruce Simpson wrote: > I wonder if many of the objections raised against C++ have actually been > considered in the light of the new C++0x spec. Has that been released yet? I thought it was still being worked-on. > At the moment, there are several projects out there which don't even > involve C++ in the *kernel*, which are directly impacted by the issues > which Andriy is attempting to solve because they use the system headers; > I therefore fully support what he is doing, as he is saving people a lot > of hassle. Me too. That's precicely why I didn't object to that work. I certainly don't consider myself to be an objector, and I hope that my comments weren't taken as such. > It's time to get real, and admit that C++ is a very powerful tool that, > whilst it can be misused in untrained hands, can be very powerful in > skillful hands. Just because something isn't to one's personal tastes, > doesn't mean it should be regarded as anathema or mandatory, IMHO. It's the "mandatory" that does worry me a little. Once the cammel has his nose inside the tent... everyone will want one. Cheers, Andrew. From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 06:07:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CE921065674 for ; Mon, 16 Feb 2009 06:07:55 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntmtas04p.mx.bigpond.com (nskntmtas04p.mx.bigpond.com [61.9.168.146]) by mx1.freebsd.org (Postfix) with ESMTP id 03D4B8FC19 for ; Mon, 16 Feb 2009 06:07:54 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntotgx01p.mx.bigpond.com ([124.188.162.219]) by nskntmtas04p.mx.bigpond.com with ESMTP id <20090216060740.RTNB1877.nskntmtas04p.mx.bigpond.com@nskntotgx01p.mx.bigpond.com> for ; Mon, 16 Feb 2009 06:07:40 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nskntotgx01p.mx.bigpond.com with ESMTP id <20090216060740.FLAA19114.nskntotgx01p.mx.bigpond.com@areilly.bpa.nu> for ; Mon, 16 Feb 2009 06:07:40 +0000 Received: (qmail 71394 invoked by uid 501); 16 Feb 2009 06:07:16 -0000 Date: Mon, 16 Feb 2009 17:07:16 +1100 From: Andrew Reilly To: Christoph Mallon Message-ID: <20090216060716.GC70145@duncan.reilly.home> References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <49983868.5010107@incunabulum.net> <20090215182420.774b90c3@ernst.jennejohn.org> <49985807.805@protected-networks.net> <49985AEE.1010709@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49985AEE.1010709@gmx.de> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150201.499902AC.00CD,ss=1,fgs=0 Cc: Michael Butler , Andriy Gapon , Bruce Simpson , freebsd-current@freebsd.org Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 06:07:58 -0000 On Sun, Feb 15, 2009 at 07:11:58PM +0100, Christoph Mallon wrote: > Michael Butler schrieb: > > .. stops C++ from mangling the prototyped functions so they'll link > >correctly but does it temporarily disable the "reserved word" tests? > >Should it? ;-) > > No, it doesn't. extern $STRING (the standard only requires "C" and > "C++", but there can be more) just changes the linkage of declarations > (name mangling, calling convention). I've always wondered: why does the extern "C" {} cruft have to be pushed into all C headers, rather than being wrapped around the #include <> lines in the C++ source that includes them? Then you wouldn't need the #ifdef __cplusplus conditional, because you already know that it's C++ code. Common usage seems to have it backwards, but I assume that there must be a reason. Cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 06:27:57 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A630106564A for ; Mon, 16 Feb 2009 06:27:57 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id E20FE8FC12 for ; Mon, 16 Feb 2009 06:27:56 +0000 (UTC) (envelope-from marcus@marcuscom.com) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id n1G6SxBX089792; Mon, 16 Feb 2009 01:28:59 -0500 (EST) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Andrew Reilly In-Reply-To: <20090216061856.GD70145@duncan.reilly.home> References: <20090215223428.GA74071@citylink.fud.org.nz> <4998D027.5030501@protected-networks.net> <1234752963.42927.171.camel@shumai.marcuscom.com> <20090216061856.GD70145@duncan.reilly.home> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-a5lDXAfVso8NDKaJElE8" Organization: MarcusCom, Inc. Date: Mon, 16 Feb 2009 01:27:58 -0500 Message-Id: <1234765678.42927.191.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.4 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: Michael Butler , current@freebsd.org Subject: Re: USB2 and USB mice X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 06:27:57 -0000 --=-a5lDXAfVso8NDKaJElE8 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2009-02-16 at 17:18 +1100, Andrew Reilly wrote: > On Sun, Feb 15, 2009 at 09:56:03PM -0500, Joe Marcus Clarke wrote: > > Hal doesn't yet work with usb2. You will need to statically configure > > your input devices in xorg.conf until support is added. >=20 > It seems that hal seems to be a vitally important part of most desktop sy= stems, > now. What's the best source of documentation on both the external whys a= nd > wherefores and the day-to-day care and feeding? The FreeBSD GNOME Team maintains a user-level hal FAQ at http://www.freebsd.org/gnome/docs/halfaq.html . We don't have any FreeBSD-specific development docs. However, the hal spec at http://people.freedesktop.org/~david/hal-spec/hal-spec.html is a good starting point. >=20 > Also, is there a FreeBSD hald-meister, whos job it is to ensure that hal > continues to reflect up-to-date FreeBSD capabilities and mechanisms? That's me. I'd really appreciate help as I don't have all of the requisite hardware or expertise in all of the subsystems. For instance, we're completely lacking SD/MMC, firewire, and printer functionality. Some of this has been posted on FreeBSD's idea page for some time. I asked Hans to add some additional functions to libusb20 to aid in hal porting, and he did quite quickly. I'm going to start working on the port. I will definitely have something by next week. Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-a5lDXAfVso8NDKaJElE8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkmZB20ACgkQb2iPiv4Uz4eqgACgpYj+U7LLXho0tAAhk8pKKcWk ElsAniaFzdwTaPpt+lpSITgaUAzMn/Ez =yTKk -----END PGP SIGNATURE----- --=-a5lDXAfVso8NDKaJElE8-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 08:12:10 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EDFF10656CE; Mon, 16 Feb 2009 08:12:10 +0000 (UTC) (envelope-from g.veniamin@googlemail.com) Received: from mail-ew0-f21.google.com (mail-ew0-f21.google.com [209.85.219.21]) by mx1.freebsd.org (Postfix) with ESMTP id 022088FC1D; Mon, 16 Feb 2009 08:12:07 +0000 (UTC) (envelope-from g.veniamin@googlemail.com) Received: by ewy14 with SMTP id 14so1989273ewy.19 for ; Mon, 16 Feb 2009 00:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type; bh=Szf8Hv5Zyn+43XFbTkSp+KYAUH+GqFFjzDyJI7JmkGo=; b=cdf2OVpqapNyjY8iXGzmsi4U7NiYsj8uPB3yxfL+z6MLB0mMNevTEhaTzDwHYPjZeF gGkgf5iS5y6pvmcj41GQS7QOu1xRYNxJE0X+KXnt9iRb9ds1oGuXRv9cQcCEV1cgVr8l eXS9WmrD6yyzBW1E1/HH/eB1Lvw2Z3VCsEIUY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; b=qOlVtjDMnUfNqCSopsG9jWufUaJNzKmErMCnp2KffS679da9SEd2O/toox4EnAF1e/ OiQpwwp2BdsT8qPHlY3KWR5hO2/9jMsCy+51+ks4b9XYabkGWyMqHF8E4nit8TlpJbrQ pIc3ABwqT1Ijz7B+Gcx8V+NZDDEYnui0cKmAY= Received: by 10.210.60.3 with SMTP id i3mr4158749eba.173.1234771926935; Mon, 16 Feb 2009 00:12:06 -0800 (PST) Received: from ss.su (zloidemon.kraslan.ru [94.78.205.21]) by mx.google.com with ESMTPS id d2sm1810823nfc.79.2009.02.16.00.12.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Feb 2009 00:12:05 -0800 (PST) Message-ID: <49991FCB.7020803@gmail.com> Date: Mon, 16 Feb 2009 15:11:55 +0700 From: Gvozdikov Veniamin User-Agent: Thunderbird 2.0.0.19 (X11/20090116) MIME-Version: 1.0 To: freebsd-x11@freebsd.org, Robert Noland , current@FreeBSD.org, kde@FreeBSD.org Content-Type: multipart/mixed; boundary="------------080002040604030602090705" Cc: Subject: completely stopped work wm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 08:12:12 -0000 This is a multi-part message in MIME format. --------------080002040604030602090705 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X server stops responding to any action. when you press backspace + ctrl + alt no reaction is also not rolled ctr + alt + F1. completely stopped work wm. I connected via ssh and watched what was happening at that time. #uname -a FreeBSD ss.su 8.0-CURRENT FreeBSD 8.0-CURRENT #1 r188603: Sat Feb 14 17:53:29 KRAT 2009 zloiadmin@ss.su:/home/repository/obj/home/repository/src/sys/zl0 i386 ss# gdb Xorg 1463 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Attaching to program: /usr/local/bin/Xorg, process 1463 Reading symbols from /usr/local/lib/libpciaccess.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpciaccess.so.0 Reading symbols from /usr/local/lib/libXfont.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXfont.so.1 Reading symbols from /usr/local/lib/libfreetype.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libfreetype.so.9 Reading symbols from /usr/local/lib/libXau.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXau.so.6 Reading symbols from /usr/local/lib/libfontenc.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libfontenc.so.1 Reading symbols from /lib/libz.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.4 Reading symbols from /usr/local/lib/libpixman-1.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpixman-1.so.9 Reading symbols from /usr/local/lib/libhal.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libhal.so.1 Reading symbols from /usr/local/lib/libdbus-1.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdbus-1.so.3 Reading symbols from /usr/local/lib/libXdmcp.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXdmcp.so.6 Reading symbols from /lib/libcrypto.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libcrypto.so.5 Reading symbols from /usr/lib/librpcsvc.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/librpcsvc.so.4 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. [New Thread 28701140 (LWP 100070)] Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/xorg/modules/extensions//librecord.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/xorg/modules/extensions//librecord.so Reading symbols from /usr/local/lib/xorg/modules/extensions//libxtrap.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/xorg/modules/extensions//libxtrap.so Reading symbols from /usr/local/lib/xorg/modules/extensions//libglx.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/xorg/modules/extensions//libglx.so Reading symbols from /usr/local/lib/xorg/modules/extensions//libdbe.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/xorg/modules/extensions//libdbe.so Reading symbols from /usr/local/lib/xorg/modules/extensions//libextmod.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/xorg/modules/extensions//libextmod.so Reading symbols from /usr/local/lib/xorg/modules/extensions//libdri.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/xorg/modules/extensions//libdri.so Reading symbols from /usr/local/lib/libdrm.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdrm.so.2 Reading symbols from /usr/local/lib/xorg/modules/fonts//libfreetype.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/xorg/modules/fonts//libfreetype.so Reading symbols from /usr/local/lib/xorg/modules/drivers//intel_drv.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/xorg/modules/drivers//intel_drv.so Reading symbols from /usr/local/lib/libdrm_intel.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdrm_intel.so.1 Reading symbols from /usr/local/lib/xorg/modules//libvgahw.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/xorg/modules//libvgahw.so Reading symbols from /usr/local/lib/xorg/modules/drivers//sil164.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/xorg/modules/drivers//sil164.so Reading symbols from /usr/local/lib/xorg/modules/drivers//ch7xxx.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/xorg/modules/drivers//ch7xxx.so Reading symbols from /usr/local/lib/xorg/modules/drivers//ivch.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/xorg/modules/drivers//ivch.so Reading symbols from /usr/local/lib/xorg/modules/drivers//tfp410.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/xorg/modules/drivers//tfp410.so Reading symbols from /usr/local/lib/xorg/modules/drivers//ch7017.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/xorg/modules/drivers//ch7017.so Reading symbols from /usr/local/lib/xorg/modules//libfb.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/xorg/modules//libfb.so Reading symbols from /usr/local/lib/xorg/modules//libexa.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/xorg/modules//libexa.so Reading symbols from /usr/local/lib/dri/i915_dri.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/dri/i915_dri.so Reading symbols from /usr/local/lib/libexpat.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libexpat.so.6 Reading symbols from /usr/local/lib/xorg/modules/input//kbd_drv.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/xorg/modules/input//kbd_drv.so Reading symbols from /usr/local/lib/xorg/modules/input//mouse_drv.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/xorg/modules/input//mouse_drv.so Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 [Switching to Thread 28701140 (LWP 100070)] 0x285f8c21 in ioctl () from /lib/libc.so.7 (gdb) bt 0x285f8c21 #0 0x285f8c21 in ioctl () from /lib/libc.so.7 #1 0x286bc84d in drmIoctl () from /usr/local/lib/libdrm.so.2 #2 0x286bc921 in drmCommandWrite () from /usr/local/lib/libdrm.so.2 #3 0x286c73ce in _fence_wait_internal () from /usr/local/lib/libdrm_intel.so.1 #4 0x286c849f in drm_intel_fake_reloc_and_validate_buffer () from /usr/local/lib/libdrm_intel.so.1 #5 0x286c879d in drm_intel_fake_bo_exec () from /usr/local/lib/libdrm_intel.so.1 #6 0x286c63de in drm_intel_bo_exec () from /usr/local/lib/libdrm_intel.so.1 #7 0x2894bbd5 in _intel_batchbuffer_flush () from /usr/local/lib/dri/i915_dri.so #8 0x28988d9e in intel_get_prim_space () from /usr/local/lib/dri/i915_dri.so #9 0x2898f36f in intel_draw_quad () from /usr/local/lib/dri/i915_dri.so #10 0x2898f6b5 in intel_render_quads_verts () from /usr/local/lib/dri/i915_dri.so #11 0x28a34f96 in run_render () from /usr/local/lib/dri/i915_dri.so #12 0x28a2c2a3 in _tnl_run_pipeline () from /usr/local/lib/dri/i915_dri.so #13 0x2897c369 in intelRunPipeline () from /usr/local/lib/dri/i915_dri.so #14 0x28a2d0c9 in _tnl_draw_prims () from /usr/local/lib/dri/i915_dri.so #15 0x28a2476c in vbo_exec_DrawArrays () from /usr/local/lib/dri/i915_dri.so #16 0x28673c06 in __glXDisp_DrawArrays () from /usr/local/lib/xorg/modules/extensions//libglx.so #17 0x2866dd70 in __glXDisp_Render () from /usr/local/lib/xorg/modules/extensions//libglx.so #18 0x28672026 in __glXDispatch () from /usr/local/lib/xorg/modules/extensions//libglx.so #19 0x08084f64 in Dispatch () #20 0x0806ba7a in main () (gdb) [13:56]zloiadmin@ss.su /home/admin #gdb kwin 1548 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Attaching to program: /usr/local/kde4/bin/kwin, process 1548 Reading symbols from /usr/local/kde4/lib/libkdeinit4_kwin.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkdeinit4_kwin.so Reading symbols from /usr/local/kde4/lib/libkdecorations.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkdecorations.so.5 Reading symbols from /usr/local/kde4/lib/libkwineffects.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkwineffects.so.1 Reading symbols from /usr/local/kde4/lib/libkdeui.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkdeui.so.7 Reading symbols from /usr/local/kde4/lib/libkdecore.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkdecore.so.7 Reading symbols from /usr/local/lib/qt4/libQtSvg.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtSvg.so.4 Reading symbols from /usr/local/kde4/lib/libkephal.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkephal.so.5 Reading symbols from /usr/local/lib/qt4/libQtGui.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtGui.so.4 Reading symbols from /usr/local/lib/qt4/libQtDBus.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtDBus.so.4 Reading symbols from /usr/local/lib/qt4/libQtCore.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtCore.so.4 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. [New Thread 29c01140 (LWP 100120)] Loaded symbols for /lib/libthr.so.3 Reading symbols from /usr/local/lib/libSM.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libSM.so.6 Reading symbols from /usr/local/lib/libICE.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libICE.so.6 Reading symbols from /usr/local/lib/libX11.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libX11.so.6 Reading symbols from /usr/local/lib/libXext.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXext.so.6 Reading symbols from /usr/local/lib/libXft.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXft.so.2 Reading symbols from /usr/local/lib/libXau.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXau.so.6 Reading symbols from /usr/local/lib/libXdmcp.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXdmcp.so.6 Reading symbols from /usr/local/lib/libXpm.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXpm.so.4 Reading symbols from /usr/local/lib/libGL.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libGL.so.1 Reading symbols from /usr/local/kde4/lib/libkwinnvidiahack.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkwinnvidiahack.so.5 Reading symbols from /usr/local/lib/libXrandr.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXrandr.so.2 Reading symbols from /usr/local/lib/libXcomposite.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXcomposite.so.1 Reading symbols from /usr/local/lib/libXdamage.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXdamage.so.1 Reading symbols from /usr/local/lib/libXrender.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXrender.so.1 Reading symbols from /usr/local/lib/libXfixes.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXfixes.so.3 Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/qt4/libQtXml.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtXml.so.4 Reading symbols from /usr/local/lib/libXtst.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXtst.so.6 Reading symbols from /usr/local/lib/libXcursor.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXcursor.so.1 Reading symbols from /usr/local/lib/qt4/libQtNetwork.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtNetwork.so.4 Reading symbols from /lib/libz.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.4 Reading symbols from /usr/lib/libbz2.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libbz2.so.3 Reading symbols from /usr/local/lib/libintl.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libintl.so.8 Reading symbols from /usr/local/lib/libpng.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpng.so.5 Reading symbols from /usr/local/lib/libXi.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXi.so.6 Reading symbols from /usr/local/lib/libfreetype.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libfreetype.so.9 Reading symbols from /usr/local/lib/libfontconfig.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libfontconfig.so.1 Reading symbols from /usr/local/lib/libgthread-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.0 Reading symbols from /usr/local/lib/libglib-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.0 Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/local/lib/libuuid.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libuuid.so.1 Reading symbols from /usr/local/lib/libxcb.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxcb.so.2 Reading symbols from /usr/lib/librpcsvc.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/librpcsvc.so.4 Reading symbols from /usr/local/lib/libXxf86vm.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXxf86vm.so.1 Reading symbols from /usr/local/lib/libX11-xcb.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libX11-xcb.so.1 Reading symbols from /usr/local/lib/libxcb-glx.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxcb-glx.so.0 Reading symbols from /usr/local/lib/libdrm.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdrm.so.2 Reading symbols from /usr/local/lib/libexpat.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libexpat.so.6 Reading symbols from /usr/local/lib/libpcre.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpcre.so.0 Reading symbols from /usr/local/lib/libXinerama.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXinerama.so.1 Reading symbols from /usr/local/lib/qt4/plugins/styles/libbespin.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/styles/libbespin.so Reading symbols from /usr/local/lib/qt4/libQt3Support.so.4...done. Loaded symbols for /usr/local/lib/qt4/libQt3Support.so.4 Reading symbols from /usr/local/lib/qt4/libQtSql.so.4...done. Loaded symbols for /usr/local/lib/qt4/libQtSql.so.4 Reading symbols from /usr/local/lib/libdbus-1.so.3...done. Loaded symbols for /usr/local/lib/libdbus-1.so.3 Reading symbols from /usr/local/kde4/lib/kde4/kwin3_deKorator.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/kwin3_deKorator.so Reading symbols from /usr/local/kde4/lib/libkde3support.so.5...done. Loaded symbols for /usr/local/kde4/lib/libkde3support.so.5 Reading symbols from /usr/local/lib/libqimageblitz.so.4...done. Loaded symbols for /usr/local/lib/libqimageblitz.so.4 Reading symbols from /usr/local/kde4/lib/libkio.so.7...done. Loaded symbols for /usr/local/kde4/lib/libkio.so.7 Reading symbols from /usr/local/kde4/lib/libkparts.so.5...done. Loaded symbols for /usr/local/kde4/lib/libkparts.so.5 Reading symbols from /usr/local/kde4/lib/libkpty.so.5...done. Loaded symbols for /usr/local/kde4/lib/libkpty.so.5 Reading symbols from /usr/local/kde4/lib/libkfile.so.5...done. Loaded symbols for /usr/local/kde4/lib/libkfile.so.5 Reading symbols from /usr/local/lib/libstreamanalyzer.so.0...done. Loaded symbols for /usr/local/lib/libstreamanalyzer.so.0 Reading symbols from /usr/local/lib/libstreams.so.0...done. Loaded symbols for /usr/local/lib/libstreams.so.0 Reading symbols from /usr/local/kde4/lib/libsolid.so.5...done. Loaded symbols for /usr/local/kde4/lib/libsolid.so.5 Reading symbols from /lib/libutil.so.7...done. Loaded symbols for /lib/libutil.so.7 Reading symbols from /usr/local/lib/libxml2.so.5...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /usr/local/lib/qt4/plugins/imageformats/libqgif.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/imageformats/libqgif.so Reading symbols from /usr/local/lib/qt4/plugins/imageformats/libqico.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/imageformats/libqico.so Reading symbols from /usr/local/lib/qt4/plugins/imageformats/libqjpeg.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/imageformats/libqjpeg.so Reading symbols from /usr/local/lib/libjpeg.so.9...done. Loaded symbols for /usr/local/lib/libjpeg.so.9 Reading symbols from /usr/local/lib/qt4/plugins/imageformats/libqmng.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/imageformats/libqmng.so Reading symbols from /usr/local/lib/libmng.so.1...done. Loaded symbols for /usr/local/lib/libmng.so.1 Reading symbols from /usr/local/lib/liblcms.so.1...done. Loaded symbols for /usr/local/lib/liblcms.so.1 Reading symbols from /usr/local/lib/qt4/plugins/imageformats/libqsvg.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/imageformats/libqsvg.so Reading symbols from /usr/local/lib/qt4/plugins/imageformats/libqtiff.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/imageformats/libqtiff.so Reading symbols from /usr/local/lib/libtiff.so.4...done. Loaded symbols for /usr/local/lib/libtiff.so.4 Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_dds.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_dds.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_eps.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_eps.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_exr.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_exr.so Reading symbols from /usr/local/lib/libImath.so.6...done. Loaded symbols for /usr/local/lib/libImath.so.6 Reading symbols from /usr/local/lib/libIlmImf.so.6...done. Loaded symbols for /usr/local/lib/libIlmImf.so.6 Reading symbols from /usr/local/lib/libIex.so.6...done. Loaded symbols for /usr/local/lib/libIex.so.6 Reading symbols from /usr/local/lib/libHalf.so.6...done. Loaded symbols for /usr/local/lib/libHalf.so.6 Reading symbols from /usr/local/lib/libIlmThread.so.6...done. Loaded symbols for /usr/local/lib/libIlmThread.so.6 Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_jp2.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_jp2.so Reading symbols from /usr/local/lib/libjasper.so.4...done. Loaded symbols for /usr/local/lib/libjasper.so.4 Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_pcx.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_pcx.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_psd.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_psd.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_rgb.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_rgb.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_tga.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_tga.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_xcf.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_xcf.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_xview.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_xview.so Reading symbols from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 [Switching to Thread 29c01140 (LWP 100120)] 0x2975bc03 in select () from /lib/libc.so.7 (gdb) bt 0x2975bc03 #0 0x2975bc03 in select () from /lib/libc.so.7 #1 0x293879d0 in select () from /lib/libthr.so.3 #2 0x29b613ff in _xcb_conn_wait () from /usr/local/lib/libxcb.so.2 #3 0x29b61a5b in _xcb_out_send () from /usr/local/lib/libxcb.so.2 #4 0x29b61e07 in xcb_writev () from /usr/local/lib/libxcb.so.2 #5 0x293f31c2 in _XSend () from /usr/local/lib/libX11.so.6 #6 0x293f3791 in return_socket () from /usr/local/lib/libX11.so.6 #7 0x29b61ec0 in get_socket_back () from /usr/local/lib/libxcb.so.2 #8 0x29b623a4 in xcb_send_request () from /usr/local/lib/libxcb.so.2 #9 0x29b8f5e2 in xcb_glx_render () from /usr/local/lib/libxcb-glx.so.0 #10 0x294f64a3 in __glXFlushRenderBuffer () from /usr/local/lib/libGL.so.1 #11 0x294f762d in __glXSetupForCommand () from /usr/local/lib/libGL.so.1 #12 0x294f4fbc in __glXBindTexImageEXT () from /usr/local/lib/libGL.so.1 #13 0x28122c0f in KWin::SceneOpenGL::Texture::bind () from /usr/local/kde4/lib/libkdeinit4_kwin.so #14 0x281263ff in KWin::SceneOpenGL::Window::performPaint () from /usr/local/kde4/lib/libkdeinit4_kwin.so #15 0x28118977 in KWin::Scene::finalDrawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #16 0x2812f44f in KWin::EffectsHandlerImpl::drawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #17 0x28185f3d in KWin::Effect::drawWindow () from /usr/local/kde4/lib/libkwineffects.so.1 #18 0x2812f3e8 in KWin::EffectsHandlerImpl::drawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #19 0x28185f3d in KWin::Effect::drawWindow () from /usr/local/kde4/lib/libkwineffects.so.1 #20 0x2812f3e8 in KWin::EffectsHandlerImpl::drawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #21 0x28185f3d in KWin::Effect::drawWindow () from /usr/local/kde4/lib/libkwineffects.so.1 #22 0x2812f3e8 in KWin::EffectsHandlerImpl::drawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #23 0x28185f3d in KWin::Effect::drawWindow () from /usr/local/kde4/lib/libkwineffects.so.1 #24 0x2812f3e8 in KWin::EffectsHandlerImpl::drawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #25 0x28185f3d in KWin::Effect::drawWindow () from /usr/local/kde4/lib/libkwineffects.so.1 #26 0x2812f3e8 in KWin::EffectsHandlerImpl::drawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #27 0x28185f3d in KWin::Effect::drawWindow () from /usr/local/kde4/lib/libkwineffects.so.1 #28 0x2812f3e8 in KWin::EffectsHandlerImpl::drawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so ---Type to continue, or q to quit--- #29 0x28185f3d in KWin::Effect::drawWindow () from /usr/local/kde4/lib/libkwineffects.so.1 #30 0x2812f3e8 in KWin::EffectsHandlerImpl::drawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #31 0x28185f3d in KWin::Effect::drawWindow () from /usr/local/kde4/lib/libkwineffects.so.1 #32 0x2812f3e8 in KWin::EffectsHandlerImpl::drawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #33 0x28185f3d in KWin::Effect::drawWindow () from /usr/local/kde4/lib/libkwineffects.so.1 #34 0x2812f3e8 in KWin::EffectsHandlerImpl::drawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #35 0x281180dd in KWin::Scene::finalPaintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #36 0x2812f5bf in KWin::EffectsHandlerImpl::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #37 0x2c37368f in KWin::PresentWindowsEffect::paintWindow () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #38 0x2812f558 in KWin::EffectsHandlerImpl::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #39 0x2c3646aa in KWin::DialogParentEffect::paintWindow () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #40 0x2812f558 in KWin::EffectsHandlerImpl::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #41 0x2c3adf72 in KWin::FlipSwitchEffect::paintWindow () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #42 0x2812f558 in KWin::EffectsHandlerImpl::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #43 0x2c36148f in KWin::DesktopGridEffect::paintWindow () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #44 0x2812f558 in KWin::EffectsHandlerImpl::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #45 0x2c36c705 in KWin::MagicLampEffect::paintWindow () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #46 0x2812f558 in KWin::EffectsHandlerImpl::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #47 0x2c36e3aa in KWin::MakeTransparentEffect::paintWindow () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #48 0x2812f558 in KWin::EffectsHandlerImpl::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #49 0x2c3bda5e in KWin::WobblyWindowsEffect::paintWindow () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #50 0x2812f558 in KWin::EffectsHandlerImpl::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #51 0x2c36b59a in KWin::LogoutEffect::paintWindow () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #52 0x2812f558 in KWin::EffectsHandlerImpl::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #53 0x2c36ae53 in KWin::LoginEffect::paintWindow () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #54 0x2812f558 in KWin::EffectsHandlerImpl::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #55 0x281194b5 in KWin::Scene::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #56 0x2811b131 in KWin::Scene::paintGenericScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #57 0x28123ecc in KWin::SceneOpenGL::paintGenericScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so ---Type to continue, or q to quit--- #58 0x28118194 in KWin::Scene::finalPaintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #59 0x2812f794 in KWin::EffectsHandlerImpl::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #60 0x2c3710c0 in KWin::PresentWindowsEffect::paintScreen () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #61 0x2812f731 in KWin::EffectsHandlerImpl::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #62 0x28186056 in KWin::Effect::paintScreen () from /usr/local/kde4/lib/libkwineffects.so.1 #63 0x2812f731 in KWin::EffectsHandlerImpl::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #64 0x2c3aeac5 in KWin::FlipSwitchEffect::paintScreen () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #65 0x2812f731 in KWin::EffectsHandlerImpl::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #66 0x2c362286 in KWin::DesktopGridEffect::paintScreen () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #67 0x2812f731 in KWin::EffectsHandlerImpl::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #68 0x28186056 in KWin::Effect::paintScreen () from /usr/local/kde4/lib/libkwineffects.so.1 #69 0x2812f731 in KWin::EffectsHandlerImpl::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #70 0x28186056 in KWin::Effect::paintScreen () from /usr/local/kde4/lib/libkwineffects.so.1 #71 0x2812f731 in KWin::EffectsHandlerImpl::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #72 0x28186056 in KWin::Effect::paintScreen () from /usr/local/kde4/lib/libkwineffects.so.1 #73 0x2812f731 in KWin::EffectsHandlerImpl::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #74 0x28186056 in KWin::Effect::paintScreen () from /usr/local/kde4/lib/libkwineffects.so.1 #75 0x2812f731 in KWin::EffectsHandlerImpl::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #76 0x28186056 in KWin::Effect::paintScreen () from /usr/local/kde4/lib/libkwineffects.so.1 #77 0x2812f731 in KWin::EffectsHandlerImpl::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #78 0x281197b2 in KWin::Scene::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #79 0x281270e5 in KWin::SceneOpenGL::paint () from /usr/local/kde4/lib/libkdeinit4_kwin.so #80 0x281139ce in KWin::Workspace::performCompositing () from /usr/local/kde4/lib/libkdeinit4_kwin.so #81 0x280a4282 in KWin::Workspace::qt_metacall () from /usr/local/kde4/lib/libkdeinit4_kwin.so #82 0x292edf8c in QMetaObject::activate () from /usr/local/lib/qt4/libQtCore.so.4 #83 0x292ee3c2 in QMetaObject::activate () from /usr/local/lib/qt4/libQtCore.so.4 #84 0x29327337 in QTimer::timeout () from /usr/local/lib/qt4/libQtCore.so.4 #85 0x292f6a8e in QTimer::timerEvent () from /usr/local/lib/qt4/libQtCore.so.4 #86 0x292ece34 in QObject::event () from /usr/local/lib/qt4/libQtCore.so.4 ---Type to continue, or q to quit--- #87 0x28b1544c in QApplicationPrivate::notify_helper () from /usr/local/lib/qt4/libQtGui.so.4 #88 0x28b1be0e in QApplication::notify () from /usr/local/lib/qt4/libQtGui.so.4 #89 0x2838a373 in KApplication::notify () from /usr/local/kde4/lib/libkdeui.so.7 #90 0x280bde7d in KWin::Application::notify () from /usr/local/kde4/lib/libkdeinit4_kwin.so #91 0x292dd9e9 in QCoreApplication::notifyInternal () from /usr/local/lib/qt4/libQtCore.so.4 #92 0x293066c8 in QTimerInfoList::activateTimers () from /usr/local/lib/qt4/libQtCore.so.4 #93 0x29304370 in timerSourceDispatch () from /usr/local/lib/qt4/libQtCore.so.4 #94 0x299e7256 in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.0 #95 0x299ea5f2 in g_main_context_check () from /usr/local/lib/libglib-2.0.so.0 #96 0x299eab75 in g_main_context_iteration () from /usr/local/lib/libglib-2.0.so.0 #97 0x293049fe in QEventDispatcherGlib::processEvents () from /usr/local/lib/qt4/libQtCore.so.4 #98 0x28b9a585 in QGuiEventDispatcherGlib::processEvents () from /usr/local/lib/qt4/libQtGui.so.4 #99 0x292dcb63 in QEventLoop::processEvents () from /usr/local/lib/qt4/libQtCore.so.4 #100 0x292dccf1 in QEventLoop::exec () from /usr/local/lib/qt4/libQtCore.so.4 #101 0x292deeda in QCoreApplication::exec () from /usr/local/lib/qt4/libQtCore.so.4 #102 0x28b149e7 in QApplication::exec () from /usr/local/lib/qt4/libQtGui.so.4 #103 0x280c00dd in kdemain () from /usr/local/kde4/lib/libkdeinit4_kwin.so #104 0x080487b2 in main () (gdb) [13:56]zloiadmin@ss.su /home/admin #gdb kwin 1548 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Attaching to program: /usr/local/kde4/bin/kwin, process 1548 Reading symbols from /usr/local/kde4/lib/libkdeinit4_kwin.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkdeinit4_kwin.so Reading symbols from /usr/local/kde4/lib/libkdecorations.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkdecorations.so.5 Reading symbols from /usr/local/kde4/lib/libkwineffects.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkwineffects.so.1 Reading symbols from /usr/local/kde4/lib/libkdeui.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkdeui.so.7 Reading symbols from /usr/local/kde4/lib/libkdecore.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkdecore.so.7 Reading symbols from /usr/local/lib/qt4/libQtSvg.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtSvg.so.4 Reading symbols from /usr/local/kde4/lib/libkephal.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkephal.so.5 Reading symbols from /usr/local/lib/qt4/libQtGui.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtGui.so.4 Reading symbols from /usr/local/lib/qt4/libQtDBus.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtDBus.so.4 Reading symbols from /usr/local/lib/qt4/libQtCore.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtCore.so.4 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. [New Thread 29c01140 (LWP 100120)] Loaded symbols for /lib/libthr.so.3 Reading symbols from /usr/local/lib/libSM.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libSM.so.6 Reading symbols from /usr/local/lib/libICE.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libICE.so.6 Reading symbols from /usr/local/lib/libX11.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libX11.so.6 Reading symbols from /usr/local/lib/libXext.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXext.so.6 Reading symbols from /usr/local/lib/libXft.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXft.so.2 Reading symbols from /usr/local/lib/libXau.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXau.so.6 Reading symbols from /usr/local/lib/libXdmcp.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXdmcp.so.6 Reading symbols from /usr/local/lib/libXpm.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXpm.so.4 Reading symbols from /usr/local/lib/libGL.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libGL.so.1 Reading symbols from /usr/local/kde4/lib/libkwinnvidiahack.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkwinnvidiahack.so.5 Reading symbols from /usr/local/lib/libXrandr.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXrandr.so.2 Reading symbols from /usr/local/lib/libXcomposite.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXcomposite.so.1 Reading symbols from /usr/local/lib/libXdamage.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXdamage.so.1 Reading symbols from /usr/local/lib/libXrender.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXrender.so.1 Reading symbols from /usr/local/lib/libXfixes.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXfixes.so.3 Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/qt4/libQtXml.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtXml.so.4 Reading symbols from /usr/local/lib/libXtst.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXtst.so.6 Reading symbols from /usr/local/lib/libXcursor.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXcursor.so.1 Reading symbols from /usr/local/lib/qt4/libQtNetwork.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtNetwork.so.4 Reading symbols from /lib/libz.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.4 Reading symbols from /usr/lib/libbz2.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libbz2.so.3 Reading symbols from /usr/local/lib/libintl.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libintl.so.8 Reading symbols from /usr/local/lib/libpng.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpng.so.5 Reading symbols from /usr/local/lib/libXi.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXi.so.6 Reading symbols from /usr/local/lib/libfreetype.so.9...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libfreetype.so.9 Reading symbols from /usr/local/lib/libfontconfig.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libfontconfig.so.1 Reading symbols from /usr/local/lib/libgthread-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.0 Reading symbols from /usr/local/lib/libglib-2.0.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.0 Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/local/lib/libuuid.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libuuid.so.1 Reading symbols from /usr/local/lib/libxcb.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxcb.so.2 Reading symbols from /usr/lib/librpcsvc.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/librpcsvc.so.4 Reading symbols from /usr/local/lib/libXxf86vm.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXxf86vm.so.1 Reading symbols from /usr/local/lib/libX11-xcb.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libX11-xcb.so.1 Reading symbols from /usr/local/lib/libxcb-glx.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libxcb-glx.so.0 Reading symbols from /usr/local/lib/libdrm.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libdrm.so.2 Reading symbols from /usr/local/lib/libexpat.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libexpat.so.6 Reading symbols from /usr/local/lib/libpcre.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpcre.so.0 Reading symbols from /usr/local/lib/libXinerama.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXinerama.so.1 Reading symbols from /usr/local/lib/qt4/plugins/styles/libbespin.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/styles/libbespin.so Reading symbols from /usr/local/lib/qt4/libQt3Support.so.4...done. Loaded symbols for /usr/local/lib/qt4/libQt3Support.so.4 Reading symbols from /usr/local/lib/qt4/libQtSql.so.4...done. Loaded symbols for /usr/local/lib/qt4/libQtSql.so.4 Reading symbols from /usr/local/lib/libdbus-1.so.3...done. Loaded symbols for /usr/local/lib/libdbus-1.so.3 Reading symbols from /usr/local/kde4/lib/kde4/kwin3_deKorator.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/kwin3_deKorator.so Reading symbols from /usr/local/kde4/lib/libkde3support.so.5...done. Loaded symbols for /usr/local/kde4/lib/libkde3support.so.5 Reading symbols from /usr/local/lib/libqimageblitz.so.4...done. Loaded symbols for /usr/local/lib/libqimageblitz.so.4 Reading symbols from /usr/local/kde4/lib/libkio.so.7...done. Loaded symbols for /usr/local/kde4/lib/libkio.so.7 Reading symbols from /usr/local/kde4/lib/libkparts.so.5...done. Loaded symbols for /usr/local/kde4/lib/libkparts.so.5 Reading symbols from /usr/local/kde4/lib/libkpty.so.5...done. Loaded symbols for /usr/local/kde4/lib/libkpty.so.5 Reading symbols from /usr/local/kde4/lib/libkfile.so.5...done. Loaded symbols for /usr/local/kde4/lib/libkfile.so.5 Reading symbols from /usr/local/lib/libstreamanalyzer.so.0...done. Loaded symbols for /usr/local/lib/libstreamanalyzer.so.0 Reading symbols from /usr/local/lib/libstreams.so.0...done. Loaded symbols for /usr/local/lib/libstreams.so.0 Reading symbols from /usr/local/kde4/lib/libsolid.so.5...done. Loaded symbols for /usr/local/kde4/lib/libsolid.so.5 Reading symbols from /lib/libutil.so.7...done. Loaded symbols for /lib/libutil.so.7 Reading symbols from /usr/local/lib/libxml2.so.5...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /usr/local/lib/qt4/plugins/imageformats/libqgif.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/imageformats/libqgif.so Reading symbols from /usr/local/lib/qt4/plugins/imageformats/libqico.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/imageformats/libqico.so Reading symbols from /usr/local/lib/qt4/plugins/imageformats/libqjpeg.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/imageformats/libqjpeg.so Reading symbols from /usr/local/lib/libjpeg.so.9...done. Loaded symbols for /usr/local/lib/libjpeg.so.9 Reading symbols from /usr/local/lib/qt4/plugins/imageformats/libqmng.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/imageformats/libqmng.so Reading symbols from /usr/local/lib/libmng.so.1...done. Loaded symbols for /usr/local/lib/libmng.so.1 Reading symbols from /usr/local/lib/liblcms.so.1...done. Loaded symbols for /usr/local/lib/liblcms.so.1 Reading symbols from /usr/local/lib/qt4/plugins/imageformats/libqsvg.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/imageformats/libqsvg.so Reading symbols from /usr/local/lib/qt4/plugins/imageformats/libqtiff.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/imageformats/libqtiff.so Reading symbols from /usr/local/lib/libtiff.so.4...done. Loaded symbols for /usr/local/lib/libtiff.so.4 Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_dds.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_dds.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_eps.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_eps.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_exr.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_exr.so Reading symbols from /usr/local/lib/libImath.so.6...done. Loaded symbols for /usr/local/lib/libImath.so.6 Reading symbols from /usr/local/lib/libIlmImf.so.6...done. Loaded symbols for /usr/local/lib/libIlmImf.so.6 Reading symbols from /usr/local/lib/libIex.so.6...done. Loaded symbols for /usr/local/lib/libIex.so.6 Reading symbols from /usr/local/lib/libHalf.so.6...done. Loaded symbols for /usr/local/lib/libHalf.so.6 Reading symbols from /usr/local/lib/libIlmThread.so.6...done. Loaded symbols for /usr/local/lib/libIlmThread.so.6 Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_jp2.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_jp2.so Reading symbols from /usr/local/lib/libjasper.so.4...done. Loaded symbols for /usr/local/lib/libjasper.so.4 Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_pcx.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_pcx.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_psd.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_psd.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_rgb.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_rgb.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_tga.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_tga.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_xcf.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_xcf.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_xview.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_xview.so Reading symbols from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 [Switching to Thread 29c01140 (LWP 100120)] 0x2975bc03 in select () from /lib/libc.so.7 (gdb) bt 0x2975bc03 #0 0x2975bc03 in select () from /lib/libc.so.7 #1 0x293879d0 in select () from /lib/libthr.so.3 #2 0x29b613ff in _xcb_conn_wait () from /usr/local/lib/libxcb.so.2 #3 0x29b61a5b in _xcb_out_send () from /usr/local/lib/libxcb.so.2 #4 0x29b61e07 in xcb_writev () from /usr/local/lib/libxcb.so.2 #5 0x293f31c2 in _XSend () from /usr/local/lib/libX11.so.6 #6 0x293f3791 in return_socket () from /usr/local/lib/libX11.so.6 #7 0x29b61ec0 in get_socket_back () from /usr/local/lib/libxcb.so.2 #8 0x29b623a4 in xcb_send_request () from /usr/local/lib/libxcb.so.2 #9 0x29b8f5e2 in xcb_glx_render () from /usr/local/lib/libxcb-glx.so.0 #10 0x294f64a3 in __glXFlushRenderBuffer () from /usr/local/lib/libGL.so.1 #11 0x294f762d in __glXSetupForCommand () from /usr/local/lib/libGL.so.1 #12 0x294f4fbc in __glXBindTexImageEXT () from /usr/local/lib/libGL.so.1 #13 0x28122c0f in KWin::SceneOpenGL::Texture::bind () from /usr/local/kde4/lib/libkdeinit4_kwin.so #14 0x281263ff in KWin::SceneOpenGL::Window::performPaint () from /usr/local/kde4/lib/libkdeinit4_kwin.so #15 0x28118977 in KWin::Scene::finalDrawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #16 0x2812f44f in KWin::EffectsHandlerImpl::drawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #17 0x28185f3d in KWin::Effect::drawWindow () from /usr/local/kde4/lib/libkwineffects.so.1 #18 0x2812f3e8 in KWin::EffectsHandlerImpl::drawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #19 0x28185f3d in KWin::Effect::drawWindow () from /usr/local/kde4/lib/libkwineffects.so.1 #20 0x2812f3e8 in KWin::EffectsHandlerImpl::drawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #21 0x28185f3d in KWin::Effect::drawWindow () from /usr/local/kde4/lib/libkwineffects.so.1 #22 0x2812f3e8 in KWin::EffectsHandlerImpl::drawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #23 0x28185f3d in KWin::Effect::drawWindow () from /usr/local/kde4/lib/libkwineffects.so.1 #24 0x2812f3e8 in KWin::EffectsHandlerImpl::drawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #25 0x28185f3d in KWin::Effect::drawWindow () from /usr/local/kde4/lib/libkwineffects.so.1 #26 0x2812f3e8 in KWin::EffectsHandlerImpl::drawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #27 0x28185f3d in KWin::Effect::drawWindow () from /usr/local/kde4/lib/libkwineffects.so.1 #28 0x2812f3e8 in KWin::EffectsHandlerImpl::drawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so ---Type to continue, or q to quit--- #29 0x28185f3d in KWin::Effect::drawWindow () from /usr/local/kde4/lib/libkwineffects.so.1 #30 0x2812f3e8 in KWin::EffectsHandlerImpl::drawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #31 0x28185f3d in KWin::Effect::drawWindow () from /usr/local/kde4/lib/libkwineffects.so.1 #32 0x2812f3e8 in KWin::EffectsHandlerImpl::drawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #33 0x28185f3d in KWin::Effect::drawWindow () from /usr/local/kde4/lib/libkwineffects.so.1 #34 0x2812f3e8 in KWin::EffectsHandlerImpl::drawWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #35 0x281180dd in KWin::Scene::finalPaintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #36 0x2812f5bf in KWin::EffectsHandlerImpl::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #37 0x2c37368f in KWin::PresentWindowsEffect::paintWindow () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #38 0x2812f558 in KWin::EffectsHandlerImpl::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #39 0x2c3646aa in KWin::DialogParentEffect::paintWindow () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #40 0x2812f558 in KWin::EffectsHandlerImpl::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #41 0x2c3adf72 in KWin::FlipSwitchEffect::paintWindow () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #42 0x2812f558 in KWin::EffectsHandlerImpl::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #43 0x2c36148f in KWin::DesktopGridEffect::paintWindow () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #44 0x2812f558 in KWin::EffectsHandlerImpl::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #45 0x2c36c705 in KWin::MagicLampEffect::paintWindow () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #46 0x2812f558 in KWin::EffectsHandlerImpl::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #47 0x2c36e3aa in KWin::MakeTransparentEffect::paintWindow () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #48 0x2812f558 in KWin::EffectsHandlerImpl::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #49 0x2c3bda5e in KWin::WobblyWindowsEffect::paintWindow () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #50 0x2812f558 in KWin::EffectsHandlerImpl::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #51 0x2c36b59a in KWin::LogoutEffect::paintWindow () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #52 0x2812f558 in KWin::EffectsHandlerImpl::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #53 0x2c36ae53 in KWin::LoginEffect::paintWindow () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #54 0x2812f558 in KWin::EffectsHandlerImpl::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #55 0x281194b5 in KWin::Scene::paintWindow () from /usr/local/kde4/lib/libkdeinit4_kwin.so #56 0x2811b131 in KWin::Scene::paintGenericScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #57 0x28123ecc in KWin::SceneOpenGL::paintGenericScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so ---Type to continue, or q to quit--- #58 0x28118194 in KWin::Scene::finalPaintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #59 0x2812f794 in KWin::EffectsHandlerImpl::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #60 0x2c3710c0 in KWin::PresentWindowsEffect::paintScreen () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #61 0x2812f731 in KWin::EffectsHandlerImpl::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #62 0x28186056 in KWin::Effect::paintScreen () from /usr/local/kde4/lib/libkwineffects.so.1 #63 0x2812f731 in KWin::EffectsHandlerImpl::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #64 0x2c3aeac5 in KWin::FlipSwitchEffect::paintScreen () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #65 0x2812f731 in KWin::EffectsHandlerImpl::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #66 0x2c362286 in KWin::DesktopGridEffect::paintScreen () from /usr/local/kde4/lib/kde4/kwin4_effect_builtins.so #67 0x2812f731 in KWin::EffectsHandlerImpl::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #68 0x28186056 in KWin::Effect::paintScreen () from /usr/local/kde4/lib/libkwineffects.so.1 #69 0x2812f731 in KWin::EffectsHandlerImpl::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #70 0x28186056 in KWin::Effect::paintScreen () from /usr/local/kde4/lib/libkwineffects.so.1 #71 0x2812f731 in KWin::EffectsHandlerImpl::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #72 0x28186056 in KWin::Effect::paintScreen () from /usr/local/kde4/lib/libkwineffects.so.1 #73 0x2812f731 in KWin::EffectsHandlerImpl::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #74 0x28186056 in KWin::Effect::paintScreen () from /usr/local/kde4/lib/libkwineffects.so.1 #75 0x2812f731 in KWin::EffectsHandlerImpl::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #76 0x28186056 in KWin::Effect::paintScreen () from /usr/local/kde4/lib/libkwineffects.so.1 #77 0x2812f731 in KWin::EffectsHandlerImpl::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #78 0x281197b2 in KWin::Scene::paintScreen () from /usr/local/kde4/lib/libkdeinit4_kwin.so #79 0x281270e5 in KWin::SceneOpenGL::paint () from /usr/local/kde4/lib/libkdeinit4_kwin.so #80 0x281139ce in KWin::Workspace::performCompositing () from /usr/local/kde4/lib/libkdeinit4_kwin.so #81 0x280a4282 in KWin::Workspace::qt_metacall () from /usr/local/kde4/lib/libkdeinit4_kwin.so #82 0x292edf8c in QMetaObject::activate () from /usr/local/lib/qt4/libQtCore.so.4 #83 0x292ee3c2 in QMetaObject::activate () from /usr/local/lib/qt4/libQtCore.so.4 #84 0x29327337 in QTimer::timeout () from /usr/local/lib/qt4/libQtCore.so.4 #85 0x292f6a8e in QTimer::timerEvent () from /usr/local/lib/qt4/libQtCore.so.4 #86 0x292ece34 in QObject::event () from /usr/local/lib/qt4/libQtCore.so.4 ---Type to continue, or q to quit--- #87 0x28b1544c in QApplicationPrivate::notify_helper () from /usr/local/lib/qt4/libQtGui.so.4 #88 0x28b1be0e in QApplication::notify () from /usr/local/lib/qt4/libQtGui.so.4 #89 0x2838a373 in KApplication::notify () from /usr/local/kde4/lib/libkdeui.so.7 #90 0x280bde7d in KWin::Application::notify () from /usr/local/kde4/lib/libkdeinit4_kwin.so #91 0x292dd9e9 in QCoreApplication::notifyInternal () from /usr/local/lib/qt4/libQtCore.so.4 #92 0x293066c8 in QTimerInfoList::activateTimers () from /usr/local/lib/qt4/libQtCore.so.4 #93 0x29304370 in timerSourceDispatch () from /usr/local/lib/qt4/libQtCore.so.4 #94 0x299e7256 in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.0 #95 0x299ea5f2 in g_main_context_check () from /usr/local/lib/libglib-2.0.so.0 #96 0x299eab75 in g_main_context_iteration () from /usr/local/lib/libglib-2.0.so.0 #97 0x293049fe in QEventDispatcherGlib::processEvents () from /usr/local/lib/qt4/libQtCore.so.4 #98 0x28b9a585 in QGuiEventDispatcherGlib::processEvents () from /usr/local/lib/qt4/libQtGui.so.4 #99 0x292dcb63 in QEventLoop::processEvents () from /usr/local/lib/qt4/libQtCore.so.4 #100 0x292dccf1 in QEventLoop::exec () from /usr/local/lib/qt4/libQtCore.so.4 #101 0x292deeda in QCoreApplication::exec () from /usr/local/lib/qt4/libQtCore.so.4 #102 0x28b149e7 in QApplication::exec () from /usr/local/lib/qt4/libQtGui.so.4 #103 0x280c00dd in kdemain () from /usr/local/kde4/lib/libkdeinit4_kwin.so #104 0x080487b2 in main () (gdb) gdb plasma 1557 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols found)... Attaching to program: /usr/local/kde4/bin/plasma, process 1557 Reading symbols from /usr/local/kde4/lib/libkdeinit4_plasma.so...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkdeinit4_plasma.so Reading symbols from /usr/local/kde4/lib/libplasma.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libplasma.so.3 Reading symbols from /usr/local/kde4/lib/libknewstuff2.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libknewstuff2.so.5 Reading symbols from /usr/local/kde4/lib/libkfile.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkfile.so.5 Reading symbols from /usr/local/kde4/lib/libkio.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkio.so.7 Reading symbols from /usr/local/lib/qt4/libQtNetwork.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtNetwork.so.4 Reading symbols from /usr/local/lib/qt4/libQtXml.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtXml.so.4 Reading symbols from /usr/local/kde4/lib/libkworkspace.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkworkspace.so.5 Reading symbols from /usr/local/kde4/lib/libkdeui.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkdeui.so.7 Reading symbols from /usr/local/kde4/lib/libkdecore.so.7...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkdecore.so.7 Reading symbols from /usr/local/lib/qt4/libQtSvg.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtSvg.so.4 Reading symbols from /usr/local/lib/libSM.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libSM.so.6 Reading symbols from /usr/local/lib/libICE.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libICE.so.6 Reading symbols from /usr/local/lib/libX11.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libX11.so.6 Reading symbols from /usr/local/lib/libXext.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXext.so.6 Reading symbols from /usr/local/lib/libXft.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXft.so.2 Reading symbols from /usr/local/lib/libXau.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXau.so.6 Reading symbols from /usr/local/lib/libXdmcp.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXdmcp.so.6 Reading symbols from /usr/local/lib/libXpm.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXpm.so.4 Reading symbols from /usr/local/lib/libXrender.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libXrender.so.1 Reading symbols from /usr/local/kde4/lib/libkephal.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libkephal.so.5 Reading symbols from /usr/local/lib/qt4/libQtGui.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtGui.so.4 Reading symbols from /usr/local/lib/qt4/libQtDBus.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtDBus.so.4 Reading symbols from /usr/local/lib/qt4/libQtCore.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtCore.so.4 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. [New Thread 37286c40 (LWP 100146)] [New Thread 36460e80 (LWP 100144)] [New Thread 2af01140 (LWP 100068)] Loaded symbols for /lib/libthr.so.3 Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/qt4/libQtWebKit.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtWebKit.so.4 Reading symbols from /usr/local/kde4/lib/libthreadweaver.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libthreadweaver.so.5 Reading symbols from /usr/local/kde4/lib/libsolid.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/kde4/lib/libsolid.so.5 Reading symbols from /usr/local/lib/qt4/libQtOpenGL.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/qt4/libQtOpenGL.so.4 Reading symbols from /usr/local/lib/libGL.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libGL.so.1 Reading symbols from /lib/libz.so.4...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.4 Reading symbols from /usr/local/lib/libstreams.so.0...done. Loaded symbols for /usr/local/lib/libstreams.so.0 Reading symbols from /usr/local/lib/libstreamanalyzer.so.0...done. Loaded symbols for /usr/local/lib/libstreamanalyzer.so.0 Reading symbols from /usr/local/lib/libgthread-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.0 Reading symbols from /usr/local/lib/libglib-2.0.so.0...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.0 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/local/lib/libXtst.so.6...done. Loaded symbols for /usr/local/lib/libXtst.so.6 Reading symbols from /usr/local/lib/libXcursor.so.1...done. Loaded symbols for /usr/local/lib/libXcursor.so.1 Reading symbols from /usr/local/lib/libXfixes.so.3...done. Loaded symbols for /usr/local/lib/libXfixes.so.3 Reading symbols from /usr/lib/libbz2.so.3...done. Loaded symbols for /usr/lib/libbz2.so.3 Reading symbols from /usr/local/lib/libintl.so.8...done. Loaded symbols for /usr/local/lib/libintl.so.8 Reading symbols from /usr/local/lib/libpng.so.5...done. Loaded symbols for /usr/local/lib/libpng.so.5 Reading symbols from /usr/local/lib/libXi.so.6...done. Loaded symbols for /usr/local/lib/libXi.so.6 Reading symbols from /usr/local/lib/libXrandr.so.2...done. Loaded symbols for /usr/local/lib/libXrandr.so.2 Reading symbols from /usr/local/lib/libfreetype.so.9...done. Loaded symbols for /usr/local/lib/libfreetype.so.9 Reading symbols from /usr/local/lib/libfontconfig.so.1...done. Loaded symbols for /usr/local/lib/libfontconfig.so.1 Reading symbols from /usr/local/lib/libuuid.so.1...done. Loaded symbols for /usr/local/lib/libuuid.so.1 Reading symbols from /usr/local/lib/libxcb.so.2...done. Loaded symbols for /usr/local/lib/libxcb.so.2 Reading symbols from /usr/lib/librpcsvc.so.4...done. Loaded symbols for /usr/lib/librpcsvc.so.4 Reading symbols from /usr/local/lib/libGLU.so.1...done. Loaded symbols for /usr/local/lib/libGLU.so.1 Reading symbols from /usr/local/lib/libXxf86vm.so.1...done. Loaded symbols for /usr/local/lib/libXxf86vm.so.1 Reading symbols from /usr/local/lib/libXdamage.so.1...done. Loaded symbols for /usr/local/lib/libXdamage.so.1 Reading symbols from /usr/local/lib/libX11-xcb.so.1...done. Loaded symbols for /usr/local/lib/libX11-xcb.so.1 Reading symbols from /usr/local/lib/libxcb-glx.so.0...done. Loaded symbols for /usr/local/lib/libxcb-glx.so.0 Reading symbols from /usr/local/lib/libdrm.so.2...done. Loaded symbols for /usr/local/lib/libdrm.so.2 Reading symbols from /usr/local/lib/libxml2.so.5...done. Loaded symbols for /usr/local/lib/libxml2.so.5 Reading symbols from /usr/local/lib/libpcre.so.0...done. Loaded symbols for /usr/local/lib/libpcre.so.0 Reading symbols from /usr/local/lib/libexpat.so.6...done. Loaded symbols for /usr/local/lib/libexpat.so.6 Reading symbols from /usr/local/lib/libdbus-1.so.3...done. Loaded symbols for /usr/local/lib/libdbus-1.so.3 Reading symbols from /usr/local/lib/libXinerama.so.1...done. Loaded symbols for /usr/local/lib/libXinerama.so.1 Reading symbols from /usr/local/lib/qt4/plugins/styles/libbespin.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/styles/libbespin.so Reading symbols from /usr/local/lib/qt4/libQt3Support.so.4...done. Loaded symbols for /usr/local/lib/qt4/libQt3Support.so.4 Reading symbols from /usr/local/lib/qt4/libQtSql.so.4...done. Loaded symbols for /usr/local/lib/qt4/libQtSql.so.4 Reading symbols from /usr/local/kde4/lib/kde4/plasma_containment_panel.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_containment_panel.so Reading symbols from /usr/local/kde4/lib/kde4/plasma_animator_default.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_animator_default.so Reading symbols from /usr/local/kde4/lib/kde4/plasma_applet_devicenotifier.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_applet_devicenotifier.so Reading symbols from /usr/local/kde4/lib/kde4/plasma_applet_pager.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_applet_pager.so Reading symbols from /usr/local/kde4/lib/libtaskmanager.so.5...done. Loaded symbols for /usr/local/kde4/lib/libtaskmanager.so.5 Reading symbols from /usr/local/lib/libXcomposite.so.1...done. Loaded symbols for /usr/local/lib/libXcomposite.so.1 Reading symbols from /usr/local/kde4/lib/kde4/plasma_applet_tasks.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_applet_tasks.so Reading symbols from /usr/local/kde4/lib/kde4/plasma_applet_systemtray.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_applet_systemtray.so Reading symbols from /usr/local/kde4/lib/kde4/plasma_applet_launcher.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_applet_launcher.so Reading symbols from /usr/local/kde4/lib/libsolidcontrol.so.5...done. Loaded symbols for /usr/local/kde4/lib/libsolidcontrol.so.5 Reading symbols from /usr/local/lib/libstrigiqtdbusclient.so.0...done. Loaded symbols for /usr/local/lib/libstrigiqtdbusclient.so.0 Reading symbols from /usr/local/kde4/lib/libsolidcontrolifaces.so.5...done. Loaded symbols for /usr/local/kde4/lib/libsolidcontrolifaces.so.5 Reading symbols from /usr/local/kde4/lib/kde4/plasma_applet_xbar.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_applet_xbar.so Reading symbols from /usr/local/kde4/lib/kde4/plasma_applet_battery.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_applet_battery.so Reading symbols from /usr/local/kde4/lib/kde4/plasma_applet_lockout.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_applet_lockout.so Reading symbols from /usr/local/kde4/lib/kde4/plasma_applet_dig_clock.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_applet_dig_clock.so Reading symbols from /usr/local/kde4/lib/libplasmaclock.so.5...done. Loaded symbols for /usr/local/kde4/lib/libplasmaclock.so.5 Reading symbols from /usr/local/kde4/lib/kde4/plasma_containment_desktop.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_containment_desktop.so Reading symbols from /usr/local/kde4/lib/kde4/plasma_wallpaper_image.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_wallpaper_image.so Reading symbols from /usr/local/kde4/lib/kde4/plasma_applet_rssnow.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_applet_rssnow.so Reading symbols from /usr/local/kde4/lib/kde4/plasma_applet_pastebin.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_applet_pastebin.so Reading symbols from /usr/local/kde4/lib/kde4/plasma_applet_notes.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_applet_notes.so Reading symbols from /usr/local/lib/qt4/plugins/imageformats/libqgif.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/imageformats/libqgif.so Reading symbols from /usr/local/lib/qt4/plugins/imageformats/libqico.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/imageformats/libqico.so Reading symbols from /usr/local/lib/qt4/plugins/imageformats/libqjpeg.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/imageformats/libqjpeg.so Reading symbols from /usr/local/lib/libjpeg.so.9...done. Loaded symbols for /usr/local/lib/libjpeg.so.9 Reading symbols from /usr/local/lib/qt4/plugins/imageformats/libqmng.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/imageformats/libqmng.so Reading symbols from /usr/local/lib/libmng.so.1...done. Loaded symbols for /usr/local/lib/libmng.so.1 Reading symbols from /usr/local/lib/liblcms.so.1...done. Loaded symbols for /usr/local/lib/liblcms.so.1 Reading symbols from /usr/local/lib/qt4/plugins/imageformats/libqsvg.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/imageformats/libqsvg.so Reading symbols from /usr/local/lib/qt4/plugins/imageformats/libqtiff.so...done. Loaded symbols for /usr/local/lib/qt4/plugins/imageformats/libqtiff.so Reading symbols from /usr/local/lib/libtiff.so.4...done. Loaded symbols for /usr/local/lib/libtiff.so.4 Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_dds.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_dds.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_eps.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_eps.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_exr.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_exr.so Reading symbols from /usr/local/lib/libImath.so.6...done. Loaded symbols for /usr/local/lib/libImath.so.6 Reading symbols from /usr/local/lib/libIlmImf.so.6...done. Loaded symbols for /usr/local/lib/libIlmImf.so.6 Reading symbols from /usr/local/lib/libIex.so.6...done. Loaded symbols for /usr/local/lib/libIex.so.6 Reading symbols from /usr/local/lib/libHalf.so.6...done. Loaded symbols for /usr/local/lib/libHalf.so.6 Reading symbols from /usr/local/lib/libIlmThread.so.6...done. Loaded symbols for /usr/local/lib/libIlmThread.so.6 Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_jp2.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_jp2.so Reading symbols from /usr/local/lib/libjasper.so.4...done. Loaded symbols for /usr/local/lib/libjasper.so.4 Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_pcx.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_pcx.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_psd.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_psd.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_rgb.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_rgb.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_tga.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_tga.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_xcf.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_xcf.so Reading symbols from /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_xview.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plugins/imageformats/kimg_xview.so Reading symbols from /usr/local/kde4/lib/kde4/plasma_applet_folderview.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_applet_folderview.so Reading symbols from /usr/local/kde4/lib/libkonq.so.7...done. Loaded symbols for /usr/local/kde4/lib/libkonq.so.7 Reading symbols from /usr/local/kde4/lib/libkparts.so.5...done. Loaded symbols for /usr/local/kde4/lib/libkparts.so.5 Reading symbols from /usr/local/kde4/lib/kde4/plasma_engine_hotplug.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_engine_hotplug.so Reading symbols from /usr/local/kde4/lib/kde4/plasma_engine_soliddevice.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_engine_soliddevice.so Reading symbols from /usr/local/kde4/lib/kde4/plasma_engine_applicationjobs.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_engine_applicationjobs.so Reading symbols from /usr/local/kde4/lib/kde4/plasma_engine_notifications.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_engine_notifications.so Reading symbols from /usr/local/kde4/lib/kde4/plasma_engine_powermanagement.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_engine_powermanagement.so Reading symbols from /usr/local/kde4/lib/kde4/plasma_engine_time.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_engine_time.so Reading symbols from /usr/local/kde4/lib/kde4/plasma_engine_rss.so...done. Loaded symbols for /usr/local/kde4/lib/kde4/plasma_engine_rss.so Reading symbols from /usr/local/kde4/lib/libsyndication.so.5...done. Loaded symbols for /usr/local/kde4/lib/libsyndication.so.5 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 [Switching to Thread 37286c40 (LWP 100146)] 0x29b7a137 in __error () from /lib/libthr.so.3 (gdb) bt 0x29b7a137 #0 0x29b7a137 in __error () from /lib/libthr.so.3 #1 0x29b79d18 in __error () from /lib/libthr.so.3 #2 0x36415f60 in ?? () #3 0x00000008 in ?? () #4 0x00000001 in ?? () #5 0x36415f40 in ?? () #6 0x00000000 in ?? () #7 0x00000003 in ?? () #8 0xbf8fdd14 in ?? () #9 0x29b7867f in pthread_setcancelstate () from /lib/libthr.so.3 #10 0x29b77f1e in pthread_cond_signal () from /lib/libthr.so.3 #11 0x299f4926 in QWaitCondition::wait () from /usr/local/lib/qt4/libQtCore.so.4 #12 0x367426e4 in RenderThread::run () from /usr/local/kde4/lib/kde4/plasma_wallpaper_image.so #13 0x299f4641 in QThreadPrivate::start () from /usr/local/lib/qt4/libQtCore.so.4 #14 0x29b6f70f in pthread_getprio () from /lib/libthr.so.3 #15 0x00000000 in ?? () (gdb) --------------080002040604030602090705 Content-Type: text/plain; name="pkg_info.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="pkg_info.txt" R3JhcGhpY3NNYWdpY2stMS4xLjE0XzEsMSBGYXN0IGltYWdlIHByb2Nlc3NpbmcgdG9vbHMg YmFzZWQgb24gSW1hZ2VNYWdpY2sKSW1hZ2VNYWdpY2stNi40LjguMyBJbWFnZSBwcm9jZXNz aW5nIHRvb2xzCk9SQml0Mi0yLjE0LjE2ICAgICAgSGlnaC1wZXJmb3JtYW5jZSBDT1JCQSBP UkIgd2l0aCBzdXBwb3J0IGZvciB0aGUgQyBsYW5ndWFnZQpPcGVuRVhSLTEuNi4xXzEgICAg IEEgaGlnaCBkeW5hbWljLXJhbmdlIChIRFIpIGltYWdlIGZpbGUgZm9ybWF0CmFhbGliLTEu NC5yNV80ICAgICAgQW4gYXNjaWkgYXJ0IGxpYnJhcnkKYWRucy0xLjRfMSAgICAgICAgICBF YXN5IHRvIHVzZSwgYXN5bmNocm9ub3VzLWNhcGFibGUgRE5TIGNsaWVudCBsaWJyYXJ5IGFu ZCB1dApha29uYWRpLTEuMS4xICAgICAgIFN0b3JhZ2Ugc2VydmVyIGZvciBrZGVwaW0KYWxs dHJheS0wLjY5XzQgICAgICBEb2NrIGFueSBhcHBsaWNhdGlvbiB3aXRoIG5vIG5hdGl2ZSB0 cmF5IGljb24KYW1zcHNmbnQtMS4wXzUgICAgICBBTVNGb250cyBQb3N0U2NyaXB0IEZvbnRz IChBZG9iZSBUeXBlIDEgZm9ybWF0KQphcGFjaGUtYW50LTEuNy4wXzIgIEphdmEtIGFuZCBY TUwtYmFzZWQgYnVpbGQgdG9vbCwgY29uY2VwdHVhbGx5IHNpbWlsYXIgdG8gbWFrCmFwcHJl cy0xLjAuMSAgICAgICAgUHJvZ3JhbSB0byBsaXN0IGFwcGxpY2F0aW9uJ3MgcmVzb3VyY2Vz CmFwci1nZGJtLWRiNDItMS4zLjMuMS4zLjRfMSBBcGFjaGUgUG9ydGFiaWxpdHkgTGlicmFy eQphcnBpbmctMi4wNiAgICAgICAgIEFSUCBsZXZlbCAicGluZyIgdXRpbGl0eQphc2NpaWRv Yy04LjMuNSAgICAgIEEgdGV4dCBkb2N1bWVudCBmb3JtYXQgZm9yIHdyaXRpbmcgc2hvcnQg ZG9jdW1lbnRzIGFuZCBtYW4gCmFzcGVsbC0wLjYwLjZfMiAgICAgU3BlbGxpbmcgY2hlY2tl ciB3aXRoIGJldHRlciBzdWdnZXN0aW9uIGxvZ2ljIHRoYW4gaXNwZWxsCmF0ay0xLjI0LjAg ICAgICAgICAgQSBHTk9NRSBhY2Nlc3NpYmlsaXR5IHRvb2xraXQgKEFUSykKYXR1bmVzLTEu MTEuMiAgICAgICBBIGZ1bGwtZmVhdHVyZWQgYXVkaW8gcGxheWVyIGFuZCBtYW5hZ2VyIGRl dmVsb3BlZCBpbiBKYXZhCmF1ZGFjaXR5LTEuMi40Yl80ICAgQXVkYWNpdHkgaXMgYSBHVUkg ZWRpdG9yIGZvciBkaWdpdGFsIGF1ZGlvIHdhdmVmb3JtcwphdXRvY29uZi0yLjEzLjAwMDIy N182IEF1dG9tYXRpY2FsbHkgY29uZmlndXJlIHNvdXJjZSBjb2RlIG9uIG1hbnkgVW4qeCBw bGF0Zm9ybXMgCmF1dG9jb25mLTIuNjIgICAgICAgQXV0b21hdGljYWxseSBjb25maWd1cmUg c291cmNlIGNvZGUgb24gbWFueSBVbip4IHBsYXRmb3JtcyAKYXV0b2NvbmYtd3JhcHBlci0y MDA3MTEwOSBXcmFwcGVyIHNjcmlwdCBmb3IgR05VIGF1dG9jb25mCmF1dG9tYWtlLTEuMTAu MSAgICAgR05VIFN0YW5kYXJkcy1jb21wbGlhbnQgTWFrZWZpbGUgZ2VuZXJhdG9yICgxLjEw KQphdXRvbWFrZS0xLjQuNl81ICAgIEdOVSBTdGFuZGFyZHMtY29tcGxpYW50IE1ha2VmaWxl IGdlbmVyYXRvciAoMS40KQphdXRvbWFrZS0xLjVfNSwxICAgIEdOVSBTdGFuZGFyZHMtY29t cGxpYW50IE1ha2VmaWxlIGdlbmVyYXRvciAoMS41KQphdXRvbWFrZS0xLjYuM18xICAgIEdO VSBTdGFuZGFyZHMtY29tcGxpYW50IE1ha2VmaWxlIGdlbmVyYXRvciAoMS42KQphdXRvbWFr ZS0xLjkuNl8zICAgIEdOVSBTdGFuZGFyZHMtY29tcGxpYW50IE1ha2VmaWxlIGdlbmVyYXRv ciAoMS45KQphdXRvbWFrZS13cmFwcGVyLTIwMDcxMTA5IFdyYXBwZXIgc2NyaXB0IGZvciBH TlUgYXV0b21ha2UKYXV0b21vYzQtMC45Ljg4ICAgICBBdXRvbWF0aWMgbW9jIGZvciBRdCA0 IHBhY2thZ2VzCmF2YWhpLTAuNi4yNCAgICAgICAgVGhlICJtZXRhLXBvcnQiIGZvciB0aGUg QXZhaGkgc2VydmljZSBkaXNjb3Zlcnkgc3VpdGUKYXZhaGktYXBwLTAuNi4yNCAgICBTZXJ2 aWNlIGRpc2NvdmVyeSBvbiBhIGxvY2FsIG5ldHdvcmsKYmFibC0wLjAuMjJfMSAgICAgICBE eW5hbWljIHBpeGVsIGZvcm1hdCBjb252ZXJzaW9uIGxpYnJhcnkKYmFzaC0zLjIuNDhfMSAg ICAgICBUaGUgR05VIFByb2plY3QncyBCb3VybmUgQWdhaW4gU0hlbGwKYmRmdG9wY2YtMS4w LjEgICAgICBDb252ZXJ0IFggZm9udCBmcm9tIEJERiB0byBQQ0YKYmVmb3JlbGlnaHQtMS4w LjNfMSBBIHNhbXBsZSBzY3JlZW4gc2F2ZXIgZm9yIFgKYmlncmVxc3Byb3RvLTEuMC4yICBC aWdSZXFzIGV4dGVuc2lvbiBoZWFkZXJzCmJpc29uLTIuM180LDEgICAgICAgQSBwYXJzZXIg Z2VuZXJhdG9yIGZyb20gRlNGLCAobW9zdGx5KSBjb21wYXRpYmxlIHdpdGggWWFjYwpiaXRt YXAtMS4wLjNfMSAgICAgIEJpdG1hcCBlZGl0b3IgYW5kIGNvbnZlcnRlciB1dGlsaXRpZXMg Zm9yIFgKYml0c3RyZWFtLXZlcmEtMS4xMF80IEJpdHN0cmVhbSBWZXJhIFRydWVUeXBlIGZv bnQgY29sbGVjdGlvbgpib29zdC1weXRob24tMS4zNC4xIEZyZWUgcGVlci1yZXZpZXdlZCBw b3J0YWJsZSBDKysgc291cmNlIGxpYnJhcmllcwpid2lkZ2V0LTEuOC4wXzEgICAgIEEgaGln aC1sZXZlbCB3aWRnZXQgc2V0IGZvciBUY2wvVGsKY2Ffcm9vdF9uc3MtMy4xMS45XzIgVGhl IHJvb3QgY2VydGlmaWNhdGUgYnVuZGxlIGZyb20gdGhlIE1vemlsbGEgUHJvamVjdApjYWJl eHRyYWN0LTEuMiAgICAgIEEgcHJvZ3JhbSB0byBleHRyYWN0IE1pY3Jvc29mdCBjYWJpbmV0 ICguQ0FCKSBmaWxlcwpjYWlyby0xLjguNiwxICAgICAgIFZlY3RvciBncmFwaGljcyBsaWJy YXJ5IHdpdGggY3Jvc3MtZGV2aWNlIG91dHB1dCBzdXBwb3J0CmNkaWZmLTEuNSAgICAgICAg ICAgRGlmZiByZWFkYWJpbGl0eSBlbmhhbmNoZXIgZm9yIGNvbG9yIHRlcm1pbmFscwpjZHBh cmFub2lhLTMuOS44XzggIEEgQ0REQSBleHRyYWN0aW9uIHRvb2wgKGFsc28ga25vd24gYXMg cmlwcGVyKQpjZHJ0b29scy0yLjAxXzcgICAgIENEL0NELVJbV10gYW5kIElTTy05NjYwIGlt YWdlIGNyZWF0aW9uIGFuZCBleHRyYWN0aW9uIHRvb2xzCmNobWxpYi0wLjM5XzIgICAgICAg QSBsaWJyYXJ5IGZvciBkZWFsaW5nIHdpdGggTWljcm9zb2Z0IElUU1MvQ0hNIGZvcm1hdCBm aWxlcwpjbHVjZW5lLTAuOS4yMSAgICAgIENMdWNlbmUgaXMgYSBDKysgcG9ydCBvZiBMdWNl bmUKY21ha2UtMi42LjIgICAgICAgICBBIGNyb3NzLXBsYXRmb3JtIG1ha2UKY21wc2ZvbnQt MS4wXzYgICAgICBDb21wdXRlciBNb2Rlcm4gUG9zdFNjcmlwdCBGb250cyAoQWRvYmUgVHlw ZSAxIGZvcm1hdCkKY29tcGF0NHgtaTM4Ni01LjNfOSBBIGNvbnZlbmllbmNlIHBhY2thZ2Ug dG8gaW5zdGFsbCB0aGUgY29tcGF0NHggbGlicmFyaWVzCmNvbXBhdDV4LWkzODYtNS40LjAu OF85IEEgY29udmVuaWVuY2UgcGFja2FnZSB0byBpbnN0YWxsIHRoZSBjb21wYXQ1eCBsaWJy YXJpZXMKY29tcGF0NngtaTM4Ni02LjQuNjA0MDAwLjIwMDgxMCBBIGNvbnZlbmllbmNlIHBh Y2thZ2UgdG8gaW5zdGFsbCB0aGUgY29tcGF0NnggbGlicmFyaWVzCmNvbXBvc2l0ZXByb3Rv LTAuNCAgQ29tcG9zaXRlIGV4dGVuc2lvbiBoZWFkZXJzCmNvbnNvbGVraXQtMC4zLjBfNCAg RnJhbWV3b3JrIGZvciBkZWZpbmluZyBhbmQgdHJhY2tpbmcgdXNlcnMKY29yZXV0aWxzLTYu OV8zICAgICBUaGUgRnJlZSBTb2Z0d2FyZSBGb3VuZGF0aW9uJ3MgY29yZSB1dGlsaXRpZXMK Y3JlYXRldG9ycmVudC0xLjEuNCBDcmVhdGUgQml0VG9ycmVudCBmaWxlcyBmcm9tIHRoZSBj b21tYW5kIGxpbmUKY3RvcnJlbnQtMy4zLjIgICAgICBCaXRUb3JyZW50IENsaWVudCB3cml0 dGVuIGluIEMgZm9yIEZyZWVCU0QgYW5kIExpbnV4CmN1cHMtYmFzZS0xLjMuOV8zICAgQ29t bW9uIFVOSVggUHJpbnRpbmcgU3lzdGVtCmN1cHMtcHN0b3Jhc3Rlci04LjE1LjRfMiBQb3N0 c2NyaXB0IGludGVycHJldGVyIGZvciBDVVBTIHByaW50aW5nIHRvIG5vbi1QUyBwcmludGVy cwpjdXJsLTcuMTkuMiAgICAgICAgIE5vbi1pbnRlcmFjdGl2ZSB0b29sIHRvIGdldCBmaWxl cyBmcm9tIEZUUCwgR09QSEVSLCBIVFRQKFMpCmN5cnVzLXNhc2wtMi4xLjIyXzIgUkZDIDIy MjIgU0FTTCAoU2ltcGxlIEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cml0eSBMYXllcikKZGFt YWdlcHJvdG8tMS4xLjBfMiBEYW1hZ2UgZXh0ZW5zaW9uIGhlYWRlcnMKZGI0MS00LjEuMjVf NCAgICAgICBUaGUgQmVya2VsZXkgREIgcGFja2FnZSwgcmV2aXNpb24gNC4xCmRiNDItNC4y LjUyXzUgICAgICAgVGhlIEJlcmtlbGV5IERCIHBhY2thZ2UsIHJldmlzaW9uIDQuMgpkYnVz LTEuMi40LjQgICAgICAgIEEgbWVzc2FnZSBidXMgc3lzdGVtIGZvciBpbnRlci1hcHBsaWNh dGlvbiBjb21tdW5pY2F0aW9uCmRidXMtZ2xpYi0wLjgwICAgICAgR0xpYiBiaW5kaW5ncyBm b3IgdGhlIEQtQlVTIG1lc3NhZ2luZyBzeXN0ZW0KZGNsaWItMC4zLjIyICAgICAgICBEaXJl Y3QgY29ubmVjdCBpbnRlcmZhY2UgbGlicmFyeSBmb3IgdmFsa251dApkZXNrdG9wLWZpbGUt dXRpbHMtMC4xNV8xIEEgY291cGxlIG9mIGNvbW1hbmQgbGluZSB1dGlsaXRpZXMgZm9yIHdv cmtpbmcgd2l0aCBkZXNrdG9wCmRpYWJsby1qZGstMS42LjAuMDcuMDJfMyBKYXZhIERldmVs b3BtZW50IEtpdCAxLjYuMF8wNy4wMgpkamJmZnQtMC43Nl8yICAgICAgIEFuIGV4dHJlbWVs eSBmYXN0IGxpYnJhcnkgZm9yIGZsb2F0aW5nLXBvaW50IGNvbnZvbHV0aW9uCmRqdnVsaWJy ZS1ub3gxMS0zLjUuMjFfMSBEalZ1IGJhc2UgbGlicmFyaWVzIGFuZCB1dGlsaXRpZXMKZG1p ZGVjb2RlLTIuMTAgICAgICBBIHRvb2wgZm9yIGR1bXBpbmcgRE1JIChTTUJJT1MpIGNvbnRl bnRzIGluIGh1bWFuLXJlYWRhYmxlIApkbXhwcm90by0yLjIuMiAgICAgIERNWCBleHRlbnNp b24gaGVhZGVycwpkb2Nib29rLTEuNCAgICAgICAgIE1ldGEtcG9ydCBmb3IgdGhlIGRpZmZl cmVudCB2ZXJzaW9ucyBvZiB0aGUgRG9jQm9vayBEVEQKZG9jYm9vay00LjFfMyAgICAgICBW NC4xIG9mIHRoZSBEb2NCb29rIERURCwgZGVzaWduZWQgZm9yIHRlY2huaWNhbCBkb2N1bWVu dGF0aQpkb2Nib29rLTQuMiAgICAgICAgIFY0LjIgb2YgdGhlIERvY0Jvb2sgRFRELCBkZXNp Z25lZCBmb3IgdGVjaG5pY2FsIGRvY3VtZW50YXRpCmRvY2Jvb2stNC4zICAgICAgICAgRG9j Qm9vay9TR01MIERURCBWNC4zLCBkZXNpZ25lZCBmb3IgdGVjaG5pY2FsIGRvY3VtZW50YXRp b24KZG9jYm9vay00LjQgICAgICAgICBEb2NCb29rL1NHTUwgRFREIFY0LjQsIGRlc2lnbmVk IGZvciB0ZWNobmljYWwgZG9jdW1lbnRhdGlvbgpkb2Nib29rLTQuNSAgICAgICAgIERvY0Jv b2svU0dNTCBEVEQgVjQuNSwgZGVzaWduZWQgZm9yIHRlY2huaWNhbCBkb2N1bWVudGF0aW9u CmRvY2Jvb2stNS4wXzEgICAgICAgRG9jQm9vayA1LjAsIGRlc2lnbmVkIGZvciB0ZWNobmlj YWwgZG9jdW1lbnRhdGlvbgpkb2Nib29rLXNrLTQuMS4yXzQgIFhNTCB2ZXJzaW9uIG9mIHRo ZSBEb2NCb29rIERURCB2ZXJzaW9uIGNvbnRyb2xsZWQgZm9yIFNjcm9sCmRvY2Jvb2steG1s LTQuMl8xICAgWE1MIHZlcnNpb24gb2YgdGhlIERvY0Jvb2sgRFRECmRvY2Jvb2steG1sLTQu MyAgICAgRG9jQm9vay9YTUwgRFREIFY0LjMsIGRlc2lnbmVkIGZvciB0ZWNobmljYWwgZG9j dW1lbnRhdGlvbgpkb2Nib29rLXhtbC00LjQgICAgIERvY0Jvb2svWE1MIERURCBWNC40LCBk ZXNpZ25lZCBmb3IgdGVjaG5pY2FsIGRvY3VtZW50YXRpb24KZG9jYm9vay14bWwtNC41ICAg ICBEb2NCb29rL1hNTCBEVEQgVjQuNSwgZGVzaWduZWQgZm9yIHRlY2huaWNhbCBkb2N1bWVu dGF0aW9uCmRvY2Jvb2steHNsLTEuNzQuMF8xIFhTTCBEb2NCb29rIHN0eWxlc2hlZXRzCmRy aS03LjMsMiAgICAgICAgICAgT3BlbkdMIGhhcmR3YXJlIGFjY2VsZXJhdGlvbiBkcml2ZXJz IGZvciB0aGUgRFJJCmRyaTJwcm90by0xLjk5LjMgICAgRFJJMiBwcm90b3R5cGUgaGVhZGVy cwpkcmljb25mLTAuOS4xXzIgICAgIENvbmZpZ3VyYXRpb24gcHJvZ3JhbSBmb3IgRFJJIGRy aXZlcnMKZHVwbWVyZ2UtMS43MyAgICAgICBTZWFyY2hlcyBmb3IgZmlsZXMgd2l0aCBlcXVh bCBjb250ZW50CmUyZnNwcm9ncy1saWJ1dWlkLTEuNDEuM18xIFVVSUQgbGlicmFyeSBmcm9t IGUyZnNwcm9ncyBwYWNrYWdlCmVib29rLXRvb2xzLTAuMS4xICAgQWNjZXNzaW5nIGFuZCBj b252ZXJ0aW5nIHZhcmlvdXMgZWJvb2sgZmlsZSBmb3JtYXRzCmVkaXRyZXMtMS4wLjNfMSAg ICAgRHluYW1pYyByZXNvdXJjZSBlZGl0b3IgZm9yIFggVG9vbGtpdCBBcHBsaWNhdGlvbnMK ZWlnZW4tMi4wLmIzICAgICAgICBMaWdodHdlaWdodCBsaWJyYXJ5IGZvciB2ZWN0b3IgYW5k IG1hdHJpeCBtYXRoCmVuY2hhbnQtMS40LjIgICAgICAgRGljdGlvbmFyeS9zcGVsbGNoZWNr aW5nIGZyYW1ld29yawplbmNvZGluZ3MtMS4wLjIsMSAgIFguT3JnIEVuY29kaW5nIGZvbnRz CmVzb3VuZC0wLjIuNDEgICAgICAgQSBzb3VuZCBsaWJyYXJ5IGZvciBlbmxpZ2h0ZW5tZW50 IHBhY2thZ2UKZXZpZWV4dC0xLjAuMiAgICAgICBYRVZJRSBleHRlbnNpb24gaGVhZGVycwpl eGl2Mi0wLjE2XzEsMSAgICAgIEV4aWYgYW5kIElwdGMgbWV0YWRhdGEgbWFuaXB1bGF0aW9u IGxpYnJhcnkgYW5kIHRvb2xzCmV4cGF0LTIuMC4xICAgICAgICAgWE1MIDEuMCBwYXJzZXIg d3JpdHRlbiBpbiBDCmZhYWQyLTIuNi4xXzEsMSAgICAgTVBFRy0yIGFuZCBNUEVHLTQgQUFD IGF1ZGlvIGRlY29kZXIKZmVzdGl2YWwtMS45Nl8xICAgICBNdWx0aS1saW5ndWFsIHNwZWVj aCBzeW50aGVzaXMgc3lzdGVtCmZmbXBlZy0yMDA4LjA3LjI3XzcgSHlwZXIgZmFzdCByZWFs dGltZSBhdWRpby92aWRlbyBlbmNvZGVyL2NvbnZlcnRlciwgc3RyZWFtaW4KZmZ0dzMtMy4x LjMgICAgICAgICBGYXN0IEMgcm91dGluZXMgdG8gY29tcHV0ZSB0aGUgRGlzY3JldGUgRm91 cmllciBUcmFuc2Zvcm0KZml4ZXNwcm90by00LjAgICAgICBGaXhlcyBleHRlbnNpb24gaGVh ZGVycwpmbGFjLTEuMi4xICAgICAgICAgIEZyZWUgbG9zc2xlc3MgYXVkaW8gY29kZWMKZmxl eC0yLjUuMzVfMSAgICAgICBGYXN0IGxleGljYWwgYW5hbHl6ZXIgZ2VuZXJhdG9yCmZvbnQt YWRvYmUtMTAwZHBpLTEuMC4wXzEgWC5PcmcgQWRvYmUgMTAwZHBpIGZvbnQKZm9udC1hZG9i ZS03NWRwaS0xLjAuMCBYLk9yZyBBZG9iZSA3NWRwaSBmb250CmZvbnQtYWRvYmUtdXRvcGlh LTEwMGRwaS0xLjAuMSBYLk9yZyBBZG9iZSBVdG9waWEgMTAwZHBpIGZvbnQKZm9udC1hZG9i ZS11dG9waWEtNzVkcGktMS4wLjEgWC5PcmcgQWRvYmUgVXRvcGlhIDc1ZHBpIGZvbnQKZm9u dC1hZG9iZS11dG9waWEtdHlwZTEtMS4wLjEgWC5PcmcgQWRvYmUgVXRvcGlhIFR5cGUxIGZv bnQKZm9udC1hbGlhcy0xLjAuMSAgICBYLk9yZyBGb250IGFsaWFzZXMKZm9udC1hcmFiaWMt bWlzYy0xLjAuMCBYLk9yZyBtaXNjZWxsYW5lb3VzIEFyYWJpYyBmb250cwpmb250LWJoLTEw MGRwaS0xLjAuMCBYLk9yZyBCaWdlbG93IEhvbG1lcyAxMDBkcGkgZm9udApmb250LWJoLTc1 ZHBpLTEuMC4wIFguT3JnIEJpZ2Vsb3cgSG9sbWVzIDc1ZHBpIGZvbnQKZm9udC1iaC1sdWNp ZGF0eXBld3JpdGVyLTEwMGRwaS0xLjAuMCBYLk9yZyBCaWdlbG93IEhvbG1lcyBMdWNpZGEg VHlwZVdyaXRlciAxMDBkcGkgZm9udApmb250LWJoLWx1Y2lkYXR5cGV3cml0ZXItNzVkcGkt MS4wLjAgWC5PcmcgQmlnZWxvdyBIb2xtZXMgTHVjaWRhIFR5cGVXcml0ZXIgNzVkcGkgZm9u dApmb250LWJoLXR0Zi0xLjAuMCAgIFguT3JnIEJpZ2Vsb3cgJiBIb2xtZXMgVFRGIGZvbnQK Zm9udC1iaC10eXBlMS0xLjAuMCBYLk9yZyBCaWdlbG93IEhvbG1lcyBUeXBlMSBmb250CmZv bnQtYml0c3RyZWFtLTEwMGRwaS0xLjAuMCBYLk9yZyBCaXRzdHJlYW0gVmVyYSAxMDBkcGkg Zm9udApmb250LWJpdHN0cmVhbS03NWRwaS0xLjAuMCBYLk9yZyBCaXRzdHJlYW0gVmVyYSA3 NWRwaSBmb250CmZvbnQtYml0c3RyZWFtLXR5cGUxLTEuMC4wIFguT3JnIEJpdHN0cmVhbSBW ZXJhIFR5cGUxIGZvbnQKZm9udC1jcm9ueXgtY3lyaWxsaWMtMS4wLjAgWC5PcmcgQ3Jvbnl4 IEN5cmlsbGljIGZvbnQKZm9udC1jdXJzb3ItbWlzYy0xLjAuMCBYLk9yZyBtaXNjZWxsYW5l b3VzIEN1cnNvciBmb250cwpmb250LWRhZXdvby1taXNjLTEuMC4wIFguT3JnIG1pc2NlbGxh bmVvdXMgRGFld29vIGZvbnRzCmZvbnQtZGVjLW1pc2MtMS4wLjAgWC5PcmcgbWlzY2VsbGFu ZW91cyBEZWMgZm9udHMKZm9udC1pYm0tdHlwZTEtMS4wLjAgWC5PcmcgSUJNIFR5cGUxIGZv bnQKZm9udC1pc2FzLW1pc2MtMS4wLjAgWC5PcmcgbWlzY2VsbGFuZW91cyBJU0FTIGZvbnRz CmZvbnQtamlzLW1pc2MtMS4wLjAgWC5PcmcgbWlzY2VsbGFuZW91cyBKSVMgZm9udHMKZm9u dC1taWNyby1taXNjLTEuMC4wIFguT3JnIG1pc2NlbGxhbmVvdXMgTWljcm8gZm9udHMKZm9u dC1taXNjLWN5cmlsbGljLTEuMC4wIFguT3JnIG1pc2NlbGxhbmVvdXMgQ3lyaWxsaWMgZm9u dApmb250LW1pc2MtZXRoaW9waWMtMS4wLjAgWC5PcmcgbWlzY2VsbGFuZW91cyBFdGhpb3Bp YyBmb250CmZvbnQtbWlzYy1tZWx0aG8tMS4wLjBfMSBYLk9yZyBtaXNjZWxsYW5lb3VzIE1l bHRobyBmb250CmZvbnQtbWlzYy1taXNjLTEuMC4wIFguT3JnIG1pc2NlbGxhbmVvdXMgTWlz YyBmb250cwpmb250LW11dHQtbWlzYy0xLjAuMCBYLk9yZyBtaXNjZWxsYW5lb3VzIE11dHQg Zm9udHMKZm9udC1zY2h1bWFjaGVyLW1pc2MtMS4wLjBfMSBYLk9yZyBtaXNjZWxsYW5lb3Vz IFNjaHVtYWNoZXIgZm9udHMKZm9udC1zY3JlZW4tY3lyaWxsaWMtMS4wLjEgWC5PcmcgU2Ny ZWVuIEN5cmlsbGljIGZvbnQKZm9udC1zb255LW1pc2MtMS4wLjAgWC5PcmcgbWlzY2VsbGFu ZW91cyBTb255IGZvbnRzCmZvbnQtc3VuLW1pc2MtMS4wLjAgWC5PcmcgbWlzY2VsbGFuZW91 cyBTdW4gZm9udHMKZm9udC11dGlsLTEuMC4xICAgICBDcmVhdGUgYW4gaW5kZXggb2YgWCBm b250IGZpbGVzIGluIGEgZGlyZWN0b3J5CmZvbnQtd2luaXR6a2ktY3lyaWxsaWMtMS4wLjAg WC5PcmcgV2luaXR6a2kgQ3lyaWxsaWMgZm9udApmb250LXhmcmVlODYtdHlwZTEtMS4wLjEg WC5PcmcgWEZyZWU4NiBUeXBlMSBmb250CmZvbnRjYWNoZXByb3RvLTAuMS4yIEZvbnRjYWNo ZSBleHRlbnNpb24gaGVhZGVycwpmb250Y29uZmlnLTIuNi4wLDEgIEFuIFhNTC1iYXNlZCBm b250IGNvbmZpZ3VyYXRpb24gQVBJIGZvciBYIFdpbmRvd3MKZm9udHNwcm90by0yLjAuMiAg ICBGb250cyBleHRlbnNpb24gaGVhZGVycwpmb250dG9zZm50LTEuMC4zICAgIFdyYXAgYSBi aXRtYXAgZm9udCBpbiBhIHNmdG4gd3JhcHBlcgpmcmVldHlwZTItMi4zLjcgICAgIEEgZnJl ZSBhbmQgcG9ydGFibGUgVHJ1ZVR5cGUgZm9udCByZW5kZXJpbmcgZW5naW5lCmZyaWJpZGkt MC4xMC45ICAgICAgQSBGcmVlIEltcGxlbWVudGF0aW9uIG9mIHRoZSBVbmljb2RlIEJpZGly ZWN0aW9uYWwgQWxnb3JpdGgKZnNsc2ZvbnRzLTEuMC4yICAgICBMaXN0IGZvbnRzIHNlcnZl ZCBieSB0aGUgWCBmb250IHNlcnZlcgpmc3RvYmRmLTEuMC4zICAgICAgIEdlbmVyYXRlIEJE RiBmb250IGZyb20gWCBmb250IHNlcnZlcgpmdXNlZnMta21vZC0wLjMuOS5wMS4yMDA4MDIw OF81IEtlcm5lbCBtb2R1bGUgZm9yIGZ1c2UKZnVzZWZzLWxpYnMtMi43LjQgICBGVVNFIGFs bG93cyBmaWxlc3lzdGVtIGltcGxlbWVudGF0aW9uIGluIHVzZXJzcGFjZQpmdXNlZnMtbnRm cy0yMDA5LjEuMSBNb3VudCBOVEZTIHBhcnRpdGlvbnMgKHJlYWQvd3JpdGUpIGFuZCBkaXNr IGltYWdlcwpnYW1pbi0wLjEuMTAgICAgICAgIEEgZmlsZSBhbmQgZGlyZWN0b3J5IG1vbml0 b3Jpbmcgc3lzdGVtCmdhd2stMy4xLjZfMSAgICAgICAgVGhlIEdOVSB2ZXJzaW9uIG9mIEF3 awpnY2NtYWtlZGVwLTEuMC4yICAgIENyZWF0ZSBkZXBlbmRlbmNpZXMgaW4gbWFrZWZpbGVz IHVzaW5nICdnY2MgLU0nCmdjb25mMi0yLjI0LjAgICAgICAgQSBjb25maWd1cmF0aW9uIGRh dGFiYXNlIHN5c3RlbSBmb3IgR05PTUUKZ2QtMi4wLjM1LDEgICAgICAgICBBIGdyYXBoaWNz IGxpYnJhcnkgZm9yIGZhc3QgY3JlYXRpb24gb2YgaW1hZ2VzCmdkYm0tMS44LjNfMyAgICAg ICAgVGhlIEdOVSBkYXRhYmFzZSBtYW5hZ2VyCmdlZ2wtMC4wLjIwXzEgICAgICAgQSBncmFw aCBiYXNlZCBpbWFnZSBwcm9jZXNzaW5nIGZyYW1ld29yawpnZXRvcHQtMS4xLjRfMSAgICAg IEEgZ2V0b3B0KDEpIHJlcGxhY2VtZW50IHRoYXQgc3VwcG9ydHMgR05VLXN0eWxlIGxvbmcg b3B0aW9uCmdldHRleHQtMC4xN18xICAgICAgR05VIGdldHRleHQgcGFja2FnZQpnaG9zdHNj cmlwdDgtOC42MyAgIEdob3N0c2NyaXB0IDgueCBQb3N0U2NyaXB0IGludGVycHJldGVyCmdp bXAtMi42LjQsMiAgICAgICAgVGhlICJtZXRhLXBvcnQiIGZvciBUaGUgR2ltcApnaW1wLWFw cC0yLjYuNF8yLDEgIEEgR05VIEltYWdlIE1hbmlwdWxhdGlvbiBQcm9ncmFtCmdpbXAtZGF0 YS1leHRyYXMtMi4wLjJfMSBDb2xsZWN0aW9uIG9mIGFkZGl0aW9uYWwgYnJ1c2hlcyBhbmQg cGF0dGVybnMgZmlsZXMgZm9yIEdJTQpnaW1wLWd1dGVucHJpbnQtNS4xLjdfMSBHdXRlblBy aW50IFByaW50ZXIgRHJpdmVyCmdpby1mYW0tYmFja2VuZC0yLjE4LjQgRkFNIGJhY2tlbmQg Zm9yIEdMaWIncyBHSU8gbGlicmFyeQpnbGV3LTEuNC4wXzIgICAgICAgIFRoZSBPcGVuR0wg RXh0ZW5zaW9uIFdyYW5nbGVyIExpYnJhcnkKZ2xpYi0xLjIuMTBfMTIgICAgICBTb21lIHVz ZWZ1bCByb3V0aW5lcyBvZiBDIHByb2dyYW1taW5nIChwcmV2aW91cyBzdGFibGUgdmVycwpn bGliLTIuMTguNCAgICAgICAgIFNvbWUgdXNlZnVsIHJvdXRpbmVzIG9mIEMgcHJvZ3JhbW1p bmcgKGN1cnJlbnQgc3RhYmxlIHZlcnNpCmdsaXR6LTAuNS42XzIgICAgICAgT3BlbkdMIGlt YWdlIGNvbXBvc2l0aW5nIGxpYnJhcnkKZ2xwcm90by0xLjQuOSAgICAgICBHTFggZXh0ZW5z aW9uIGhlYWRlcnMKZ21ha2UtMy44MV8zICAgICAgICBHTlUgdmVyc2lvbiBvZiAnbWFrZScg dXRpbGl0eQpnbW0rKy0zLjEgICAgICAgICAgIEEgZ2VuZXJpYyBtYXRyaXggdGVtcGxhdGUg bGlicmFyeQpnbm9tZS1kb2MtdXRpbHMtMC4xNC4yIEdOT01FIGRvYyB1dGlscwpnbm9tZS1r ZXlyaW5nLTIuMjQuMV8yIEEgcHJvZ3JhbSB0aGF0IGtlZXBzIHBhc3N3b3JkcyBhbmQgb3Ro ZXIgc2VjcmV0cwpnbm9tZS1taW1lLWRhdGEtMi4xOC4wXzMgQSBNSU1FIGFuZCBBcHBsaWNh dGlvbiBkYXRhYmFzZSBmb3IgR05PTUUKZ25vbWUtbW91bnQtMC44XzIgICBBIGZyb250LWVu ZCB0byBtb3VudCwgdW1vdW50LCBhbmQgZWplY3QgdXNpbmcgSEFMCmdub21lLXZmcy0yLjI0 LjAgICAgR05PTUUgVmlydHVhbCBGaWxlIFN5c3RlbQpnbm9tZV9zdWJyLTEuMCAgICAgIENv bW1vbiBzdGFydHVwIGFuZCBzaHV0ZG93biBzdWJyb3V0aW5lcyB1c2VkIGJ5IEdOT01FIHNj cmlwCmdub21laGllci0yLjNfMTEgICAgQSB1dGlsaXR5IHBvcnQgdGhhdCBjcmVhdGVzIHRo ZSBHTk9NRSBkaXJlY3RvcnkgdHJlZQpnbnVwZy0yLjAuMTBfMiAgICAgIFRoZSBHTlUgUHJp dmFjeSBHdWFyZApnbnV0bHMtMi42LjNfMSAgICAgIEdOVSBUcmFuc3BvcnQgTGF5ZXIgU2Vj dXJpdHkgbGlicmFyeQpncGFjLWxpYmdwYWMtMC40LjQsMSBHcGFjIE1QRUctNCBTeXN0ZW1z IGxpYnJhcnkgYW5kIGhlYWRlcnMKZ3BlcmYtMy4wLjMgICAgICAgICBHZW5lcmF0ZXMgcGVy ZmVjdCBoYXNoIGZ1bmN0aW9ucyBmb3Igc2V0cyBvZiBrZXl3b3JkcwpncGdtZS0xLjEuNV8x ICAgICAgIEEgbGlicmFyeSB0byBtYWtlIGFjY2VzcyB0byBHbnVQRyBlYXNpZXIKZ3J1Yi0w Ljk3XzMgICAgICAgICBHUmFuZCBVbmlmaWVkIEJvb3Rsb2FkZXIKZ3Nmb250cy04LjExXzQg ICAgICBGb250cyB1c2VkIGJ5IEdOVSBHaG9zdHNjcmlwdCAob3IgWCkKZ3NsLTEuMTIgICAg ICAgICAgICBUaGUgR05VIFNjaWVudGlmaWMgTGlicmFyeSAtIG1hdGhlbWF0aWNhbCBsaWJz CmdzbmFwc2hvdC0xLjBfMyAgICAgQSBndGsrIGJhc2VkIHNjcmVlbiBjYXB0dXJlCmdzdHJl YW1lci0wLjEwLjIyXzEgRGV2ZWxvcG1lbnQgZnJhbWV3b3JrIGZvciBjcmVhdGluZyBtZWRp YSBhcHBsaWNhdGlvbnMKZ3N0cmVhbWVyLWZmbXBlZy0wLjEwLjRfMSBHU3RyZWFtZXIgcGx1 Zy1pbiBmb3IgbWFuaXB1bGF0aW5nIE1QRUcgdmlkZW8gc3RyZWFtcwpnc3RyZWFtZXItcGx1 Z2lucy0wLjEwLjIyLDMgR1N0cmVhbWVyIHdyaXR0ZW4gY29sbGVjdGlvbiBvZiBwbHVnaW5z IGhhbmRsaW5nIHNldmVyYWwgbWUKZ3N0cmVhbWVyLXBsdWdpbnMtYTUyZGVjLTAuMTAuMTAs MyBHc3RyZWFtZXIgQVRTQyBBLzUyIHN0cmVhbSBha2EgQUMtMyAoZHZkIGF1ZGlvKSBwbHVn aW4KZ3N0cmVhbWVyLXBsdWdpbnMtYmFkLTAuMTAuMTAsMyBCYWQgZ3N0cmVhbWVyLXBsdWdp bnMKZ3N0cmVhbWVyLXBsdWdpbnMtY29yZS0wLjEwXzEwIENvcmUgc2V0IG9mIHR5cGljYWwg YXVkaW8gYW5kIHZpZGVvIGdzdHJlYW1lci1wbHVnaW5zCmdzdHJlYW1lci1wbHVnaW5zLWR0 cy0wLjEwLjEwXzEsMyBHc3RyZWFtZXIgZHRzIHBsdWdpbgpnc3RyZWFtZXItcGx1Z2lucy1k dmQtMC4xMC4xMCwzIEdzdHJlYW1lciBkdmQgcGx1Z2luIHNldApnc3RyZWFtZXItcGx1Z2lu cy1nbm9tZXZmcy0wLjEwLjIyXzEsMyBHc3RyZWFtZXIgZ25vbWV2ZnMgcGx1Z2luCmdzdHJl YW1lci1wbHVnaW5zLWdvb2QtMC4xMC4xMywzIEdvb2QgZ3N0cmVhbWVyLXBsdWdpbnMKZ3N0 cmVhbWVyLXBsdWdpbnMtbGlicG5nLTAuMTAuMTMsMyBHc3RyZWFtZXIgcG5nIHBsdWdpbgpn c3RyZWFtZXItcGx1Z2lucy1tYWQtMC4xMC4xMCwzIEdzdHJlYW1lciBtcDMgZGVjb2RlciBw bHVnaW4KZ3N0cmVhbWVyLXBsdWdpbnMtbXAzLTAuMTAuMF8xIEdzdHJlYW1lciBQbHVnaW5z IE1wMyBkZWNvZGVyIG1ldGEtcG9ydApnc3RyZWFtZXItcGx1Z2lucy1vZ2ctMC4xMC4yMl8x LDMgR3N0cmVhbWVyIE9nZyBiaXRzdHJlYW0gcGx1Z2luCmdzdHJlYW1lci1wbHVnaW5zLXBh bmdvLTAuMTAuMjJfMSwzIEdzdHJlYW1lciBwYW5nbyB0ZXh0b3ZlcmxheSBwbHVnaW4KZ3N0 cmVhbWVyLXBsdWdpbnMtcHVsc2UtMC45LjdfMSBHU3RyZWFtZXIgcGx1Z2luIGZvciBwdWxz ZWF1ZGlvCmdzdHJlYW1lci1wbHVnaW5zLXRoZW9yYS0wLjEwLjIyXzEsMyBHc3RyZWFtZXIg dGhlb3JhIHBsdWdpbgpnc3RyZWFtZXItcGx1Z2lucy11Z2x5LTAuMTAuMTAsMyBVZ2x5IGdz dHJlYW1lci1wbHVnaW5zCmdzdHJlYW1lci1wbHVnaW5zLXZvcmJpcy0wLjEwLjIyXzEsMyBH c3RyZWFtZXIgdm9yYmlzIGVuY29kZXIvZGVjb2RlciBwbHVnaW4KZ3N0cmVhbWVyLXBsdWdp bnMteHZpZC0wLjEwLjEwXzEsMyBHc3RyZWFtZXIgeHZpZCBwbHVnaW4KZ3RrLTEuMi4xMF8y MCAgICAgICBHaW1wIFRvb2xraXQgZm9yIFgxMSBHVUkgKHByZXZpb3VzIHN0YWJsZSB2ZXJz aW9uKQpndGstMi4xNC43ICAgICAgICAgIEdpbXAgVG9vbGtpdCBmb3IgWDExIEdVSSAoY3Vy cmVudCBzdGFibGUgdmVyc2lvbikKZ3RrLWVuZ2luZXMyLTIuMTYuMSBUaGVtZSBlbmdpbmUg Zm9yIHRoZSBHVEsrLTIuMCB0b29sa2l0Cmd0ay1xdDQtZW5naW5lLTEuMSAgR1RLLVFUIFRo ZW1lIEVuZ2luZSBhbGxvd3MgR1RLMiBhcHBzIHRvIHVzZSBRVC9LREUgdGhlbWVzCmd0a2No dGhlbWUtMC4zLjFfNiAgR1RLMiB0aGVtZSBjaGFuZ2VyCmd0a3NwZWxsLTIuMC4xNSAgICAg QSBHVEsrIDIgc3BlbGwgY2hlY2tpbmcgY29tcG9uZW50Cmd1dGVucHJpbnQtNS4xLjdfMSAg VGhlICJtZXRhLXBvcnQiIGZvciBHdXRlblByaW50Cmd1dGVucHJpbnQtYmFzZS01LjEuN18x IEd1dGVuUHJpbnQgUHJpbnRlciBEcml2ZXIKZ3V0ZW5wcmludC1panMtNS4xLjdfMSBHdXRl blByaW50IFByaW50ZXIgRHJpdmVyCmd2ZnMtMS4wLjMgICAgICAgICAgR05PTUUgdmlydHVh bCBmaWxlIHN5c3RlbQpoYWwtMC41LjExXzE2ICAgICAgIEhhcmR3YXJlIEFic3RyYWN0aW9u IExheWVyIGZvciBzaW1wbGlmeWluZyBkZXZpY2UgYWNjZXNzCmhlbHAybWFuLTEuMzYuNF8y ICAgQXV0b21hdGljYWxseSBnZW5lcmF0aW5nIHNpbXBsZSBtYW51YWwgcGFnZXMgZnJvbSBw cm9ncmFtIG8KaGljb2xvci1pY29uLXRoZW1lLTAuMTBfMiBBIGhpZ2gtY29sb3IgaWNvbiB0 aGVtZSBzaGVsbCBmcm9tIHRoZSBGcmVlRGVza3RvcCBwcm9qZWN0Cmh0b3AtMC44ICAgICAg ICAgICAgQSBiZXR0ZXIgdG9wKDEpIC0gaW50ZXJhY3RpdmUgcHJvY2VzcyB2aWV3ZXIKaHR0 cGVyZi0wLjkuMCAgICAgICBBIHRvb2wgZm9yIG1lYXN1cmluZyB3ZWJzZXJ2ZXIgcGVyZm9y bWFuY2UKaWNlYXV0aC0xLjAuMiAgICAgICBJQ0UgYXV0aG9yaXR5IGZpbGUgdXRpbGl0eSBm b3IgWAppY28tMS4wLjIgICAgICAgICAgIERpc3BsYXlzIGEgd2lyZS1mcmFtZSByb3RhdGlu ZyBwbHloZWRyb24KaWN1LTMuOC4xXzEgICAgICAgICBJbnRlcm5hdGlvbmFsIENvbXBvbmVu dHMgZm9yIFVuaWNvZGUgKGZyb20gSUJNKQppbG1iYXNlLTEuMC4xXzEgICAgIElMTSBCYXNl IGxpYnJhcmllcyBhLmsuYS4gSGFsZiwgSWxtVGhyZWFkLCBJbWF0aCBhbmQgSWV4CmltYWtl LTEuMC4yXzQsMSAgICAgSW1ha2UgYW5kIG90aGVyIHV0aWxpdGllcyBmcm9tIFguT3JnCmlu cHV0cHJvdG8tMS41LjAgICAgSW5wdXQgZXh0ZW5zaW9uIGhlYWRlcnMKaW50bHRvb2wtMC40 MC41ICAgICBUb29scyB0byBpbnRlcm5hdGlvbmFsaXplIHZhcmlvdXMga2luZHMgb2YgZGF0 YSBmaWxlcwppc28tY29kZXMtMy4yXzEgICAgIExpc3RzIG9mIHRoZSBjb3VudHJ5LCBsYW5n dWFnZSBhbmQgY3VycmVuY3kgaXNvIG5hbWVzCmlzbzg4NzktMTk4Nl8yICAgICAgQ2hhcmFj dGVyIGVudGl0eSBzZXRzIGZyb20gSVNPIDg4Nzk6MTk4NiAoU0dNTCkKaXctaHNwZWxsLTAu OCAgICAgICBIZWJyZXcgc3BlbGxjaGVja2VyIGFuZCBtb3JwaG9sb2d5IGVuZ2luZQpqYWNr aXQtMC4xMDkuMl8xICAgIEEgbG93LWxhdGVuY3kgYXVkaW8gc2VydmVyCmphc3Blci0xLjkw MC4xXzcgICAgQW4gaW1wbGVtZW50YXRpb24gb2YgdGhlIGNvZGVjIHNwZWNpZmllZCBpbiB0 aGUgSlBFRy0yMDAwIHMKamF2YXZtd3JhcHBlci0yLjMuMiBXcmFwcGVyIHNjcmlwdCBmb3Ig dmFyaW91cyBKYXZhIFZpcnR1YWwgTWFjaGluZXMKamJpZ2tpdC0xLjYgICAgICAgICBMb3Nz bGVzcyBjb21wcmVzc2lvbiBmb3IgYmktbGV2ZWwgaW1hZ2VzIHN1Y2ggYXMgc2Nhbm5lZCBw YQpqcGVnLTZiXzcgICAgICAgICAgIElKRydzIGpwZWcgY29tcHJlc3Npb24gdXRpbGl0aWVz CmticHJvdG8tMS4wLjMgICAgICAgS0IgZXh0ZW5zaW9uIGhlYWRlcnMKa2RlNC00LjIuMCAg ICAgICAgICBUaGUgIm1ldGEtcG9ydCIgZm9yIEtERQprZGU0LXNoYXJlZC1taW1lLWluZm8t MS4wIEhhbmRsZXMgc2hhcmVkIE1JTUUgZGF0YWJhc2UgdW5kZXIgJHtLREVfUFJFRklYfQpr ZGU0LXN0eWxlLWJlc3Bpbi0wLjEgVHJhbnNwYXJlbnQgS0RFNCBzdHlsZQprZGU0LXdpbmRl Y28tZGVrb3JhdG9yLTAuNC4wLjEgVHJhbnNwYXJlbnQgS0RFNCB3aW5kb3cgZGVjb3JhdGlv bgprZGU0LXhkZy1lbnYtMS4wICAgIFNjcmlwdCB3aGljaCBob29rcyBpbnRvIHN0YXJ0a2Rl IGFuZCBoZWxwcyBLREUgcGljayB1cCBYREcgCmtkZWFjY2Vzc2liaWxpdHktNC4yLjAgQWNj ZXNzaWJpbGl0eSBhcHBsaWNhdGlvbnMgZm9yIEtERTQKa2RlYWRtaW4tNC4yLjAgICAgICBL REUgQWRtaW4gYXBwbGljYXRpb25zCmtkZWJhc2UtNC4yLjAgICAgICAgQmFzaWMgYXBwbGlj YXRpb25zIGZvciB0aGUgS0RFIHN5c3RlbQprZGViYXNlLXJ1bnRpbWUtNC4yLjAgQmFzaWMg YXBwbGljYXRpb25zIGZvciB0aGUgS0RFIHN5c3RlbQprZGViYXNlLXdvcmtzcGFjZS00LjIu MCBCYXNpYyBhcHBsaWNhdGlvbnMgZm9yIHRoZSBLREUgc3lzdGVtCmtkZWdyYXBoaWNzLTQu Mi4wICAgR3JhcGhpY3MgdXRpbGl0aWVzIGZvciB0aGUgS0RFNCBpbnRlZ3JhdGVkIFgxMSBk ZXNrdG9wCmtkZWhpZXI0LTEuMC4zICAgICAgVXRpbGl0eSBwb3J0IHRoYXQgY3JlYXRlcyBo aWVyYXJjaHkgb2Ygc2hhcmVkIEtERTQgZGlyZWN0b3IKa2RlbGlicy00LjIuMCAgICAgICBC YXNlIHNldCBvZiBsaWJyYXJpZXMgbmVlZGVkIGJ5IEtERSBwcm9ncmFtcwprZGVtdWx0aW1l ZGlhLTQuMi4wIEtERSBNdWx0aW1lZGlhIGFwcGxpY2F0aW9ucwprZGVwaW0tNC4yLjAgICAg ICAgIExpYnJhcmllcyBmb3IgS0RFLVBJTSBhcHBsaWNhdGlvbnMKa2RlcGltbGlicy00LjIu MCAgICBMaWJyYXJpZXMgZm9yIEtERS1QSU0gYXBwbGljYXRpb25zCmtkZXBsYXNtYS1hZGRv bnMtNC4yLjAgRXh0cmEgcGxhc21vaWRzIGZvciBLREU0CmtkZXV0aWxzLTQuMi4wICAgICAg VXRpbGl0aWVzIGZvciB0aGUgS0RFNCBpbnRlZ3JhdGVkIFgxMSBEZXNrdG9wCmtncnViZWRp dG9yLTAuOC41ICAgS0dSVUJFZGl0b3IgaXMgYSBLREUgdXRpbGl0eSwgdGhhdCBlZGl0cyBH UlVCJ3MgY29uZmlndXJhdGkKa29mZmljZS1rZGU0LTEuOS45OC41IE9mZmljZSBzdWl0ZSBm b3IgS0RFCmxhbWUtMy45OC4yXzEgICAgICAgRmFzdCBNUDMgZW5jb2RlciBraXQKbGNtcy0x LjE3LDEgICAgICAgICBMaWdodCBDb2xvciBNYW5hZ2VtZW50IFN5c3RlbSAtLSBhIGNvbG9y IG1hbmFnZW1lbnQgbGlicmFyeQpsaWJGUy0xLjAuMSAgICAgICAgIFRoZSBGUyBsaWJyYXJ5 CmxpYkdMLTcuMyAgICAgICAgICAgT3BlbkdMIGxpYnJhcnkgdGhhdCByZW5kZXJzIHVzaW5n IEdMWCBvciBEUkkKbGliR0xVLTcuMyAgICAgICAgICBPcGVuR0wgdXRpbGl0eSBsaWJyYXJ5 CmxpYklDRS0xLjAuNF8xLDEgICAgSW50ZXIgQ2xpZW50IEV4Y2hhbmdlIGxpYnJhcnkgZm9y IFgxMQpsaWJJREwtMC44LjEyICAgICAgIEEgbGlicmFyeSBmb3IgY3JlYXRpbmcgdHJlZXMg b2YgQ09SQkEgSURMIGZpbGVzCmxpYlNNLTEuMS4wLDEgICAgICAgU2Vzc2lvbiBNYW5hZ2Vt ZW50IGxpYnJhcnkgZm9yIFgxMQpsaWJYMTEtMS4xLjk5LjIsMSAgIFgxMSBsaWJyYXJ5Cmxp YlhTY3JuU2F2ZXItMS4xLjMgVGhlIFhTY3JuU2F2ZXIgbGlicmFyeQpsaWJYVHJhcC0xLjAu MCAgICAgIFRoZSBYVHJhcCBsaWJyYXJ5CmxpYlhhdS0xLjAuNCAgICAgICAgQXV0aGVudGlj YXRpb24gUHJvdG9jb2wgbGlicmFyeSBmb3IgWDExCmxpYlhhdy0xLjAuNV8xLDEgICAgWCBB dGhlbmEgV2lkZ2V0cyBsaWJyYXJ5CmxpYlhjb21wb3NpdGUtMC40LjAsMSBYIENvbXBvc2l0 ZSBleHRlbnNpb24gbGlicmFyeQpsaWJYY3Vyc29yLTEuMS45XzEgIFggY2xpZW50LXNpZGUg Y3Vyc29yIGxvYWRpbmcgbGlicmFyeQpsaWJYZGFtYWdlLTEuMS4xICAgIFggRGFtYWdlIGV4 dGVuc2lvbiBsaWJyYXJ5CmxpYlhkbWNwLTEuMC4yXzEgICAgWCBEaXNwbGF5IE1hbmFnZXIg Q29udHJvbCBQcm90b2NvbCBsaWJyYXJ5CmxpYlhldmllLTEuMC4yICAgICAgVGhlIFhldmll IGxpYnJhcnkKbGliWGV4dC0xLjAuNSwxICAgICBYMTEgRXh0ZW5zaW9uIGxpYnJhcnkKbGli WGZpeGVzLTQuMC4zXzEgICBYIEZpeGVzIGV4dGVuc2lvbiBsaWJyYXJ5CmxpYlhmb250LTEu My40LDEgICAgWCBmb250IGxpYmFyeQpsaWJYZm9udGNhY2hlLTEuMC40IFRoZSBYZm9udGNh Y2hlIGxpYnJhcnkKbGliWGZ0LTIuMS4xMyAgICAgICBBIGNsaWVudC1zaWRlZCBmb250IEFQ SSBmb3IgWCBhcHBsaWNhdGlvbnMKbGliWGktMS4yLjAsMSAgICAgICBYIElucHV0IGV4dGVu c2lvbiBsaWJyYXJ5CmxpYlhpbmVyYW1hLTEuMC4zLDEgWDExIFhpbmVyYW1hIGxpYnJhcnkK bGliWG11LTEuMC40LDEgICAgICBYIE1pc2NlbGxhbmVvdXMgVXRpbGl0aWVzIGxpYnJhcmll cwpsaWJYcC0xLjAuMCwxICAgICAgIFggcHJpbnQgbGlicmFyeQpsaWJYcG0tMy41LjcgICAg ICAgIFggUGl4bWFwIGxpYnJhcnkKbGliWHByaW50QXBwVXRpbC0xLjAuMSBUaGUgWHByaW50 QXBwVXRpbCBsaWJyYXJ5CmxpYlhwcmludFV0aWwtMS4wLjEgVGhlIFhwcmludFV0aWwgbGli cmFyeQpsaWJYcmFuZHItMS4yLjMgICAgIFggUmVzaXplIGFuZCBSb3RhdGUgZXh0ZW5zaW9u IGxpYnJhcnkKbGliWHJlbmRlci0wLjkuNF8xICBYIFJlbmRlciBleHRlbnNpb24gbGlicmFy eQpsaWJYcmVzLTEuMC4zXzMgICAgIFggUmVzb3VyY2UgdXNhZ2UgbGlicmFyeQpsaWJYdC0x LjAuNV8xICAgICAgIFggVG9vbGtpdCBsaWJyYXJ5CmxpYlh0c3QtMS4wLjNfMSAgICAgWCBU ZXN0IGV4dGVuc2lvbgpsaWJYdi0xLjAuNCwxICAgICAgIFggVmlkZW8gRXh0ZW5zaW9uIGxp YnJhcnkKbGliWHZNQy0xLjAuNF8xICAgICBYIFZpZGVvIEV4dGVuc2lvbiBNb3Rpb24gQ29t cGVuc2F0aW9uIGxpYnJhcnkKbGliWHhmODZkZ2EtMS4wLjIgICBYIERHQSBFeHRlbnNpb24K bGliWHhmODZtaXNjLTEuMC4xICBYIFhGODYtTWlzYyBFeHRlbnNpb24KbGliWHhmODZ2bS0x LjAuMiAgICBYIFZpZG1vZGUgRXh0ZW5zaW9uCmxpYmE1Mi0wLjcuNF8yICAgICAgQSBmcmVl IGxpYnJhcnkgZm9yIGRlY29kaW5nIEFUU0MgQS81MiBzdHJlYW1zLCBha2EgQUMtMwpsaWJh by0wLjguOF8xICAgICAgIFBvcnRhYmxlIGF1ZGlvIG91dHB1dCBsaWJyYXJ5CmxpYmFydF9s Z3BsLTIuMy4yMCwxIExpYnJhcnkgZm9yIGhpZ2gtcGVyZm9ybWFuY2UgMkQgZ3JhcGhpY3MK bGliYXNzdWFuLTEuMC41ICAgICBJUEMgbGlicmFyeSB1c2VkIGJ5IEdudVBHIGFuZCBncGdt ZQpsaWJhdWRpb2ZpbGUtMC4yLjYgIEEgc291bmQgbGlicmFyeSBmb3IgU0dJIGF1ZGlvIGZp bGUKbGliY2RkYi0xLjMuMCAgICAgICBBIGxpYnJhcnkgdG8gYWNjZXNzIGRhdGEgb24gYSBD RERCIHNlcnZlcgpsaWJjZGlvLTAuNzguMl8yICAgIENvbXBhY3QgRGlzYyBJbnB1dCBhbmQg Q29udHJvbCBMaWJyYXJ5CmxpYmNoZWNrLTAuOS42ICAgICAgQSB1bml0IHRlc3QgZnJhbWV3 b3JrIGZvciBDCmxpYmNyb2NvLTAuNi4xXzEgICAgQ1NTMiBwYXJzaW5nIGxpYnJhcnkKbGli ZGFlbW9uLTAuMTIgICAgICBMaWdodHdlaWdodCBDIGxpYnJhcnkgdGhhdCBlYXNlcyB0aGUg d3JpdGluZyBvZiBVTklYIGRhZW1vbgpsaWJkY2EtMC4wLjUgICAgICAgIEZyZWUgRFRTIENv aGVyZW50IEFjb3VzdGljcyBkZWNvZGVyCmxpYmRteC0xLjAuMl8xICAgICAgRE1YIGV4dGVu c2lvbiBsaWJyYXJ5CmxpYmRuZXQtMS4xMV8yICAgICAgQSBzaW1wbGUgaW50ZXJmYWNlIHRv IGxvdyBsZXZlbCBuZXR3b3JraW5nIHJvdXRpbmVzCmxpYmRybS0yLjQuNCAgICAgICAgVXNl cnNwYWNlIGludGVyZmFjZSB0byBrZXJuZWwgRGlyZWN0IFJlbmRlcmluZyBNb2R1bGUgc2Vy dmkKbGliZHZkY3NzLTEuMi45XzIgICBQb3J0YWJsZSBhYnN0cmFjdGlvbiBsaWJyYXJ5IGZv ciBEVkQgZGVjcnlwdGlvbgpsaWJkdmRuYXYtMC4xLjEwXzMgIFRoZSBsaWJyYXJ5IGZvciB0 aGUgeGluZS1kdmRuYXYgcGx1Z2luCmxpYmR2ZHJlYWQtMC45LjdfMyAgVGhpcyBpcyBuZWVk ZWQgYnkgb2dsZSwgd2hpY2ggaXMgYSBEVkQgcGxheWVyIHRoYXQgc3VwcG9ydHMKbGliZXZl bnQtMS40LjkgICAgICBQcm92aWRlcyBhbiBBUEkgdG8gZXhlY3V0ZSBjYWxsYmFjayBmdW5j dGlvbnMgb24gY2VydGFpbiBldgpsaWJleGVjaW5mby0xLjFfMyAgIEEgbGlicmFyeSBmb3Ig aW5zcGVjdGluZyBwcm9ncmFtJ3MgYmFja3RyYWNlCmxpYmV4aWYtMC42LjE3ICAgICAgTGli cmFyeSB0byByZWFkIGRpZ2l0YWwgY2FtZXJhIGZpbGUgbWV0YS1kYXRhCmxpYmZhbWUtMC45 LjFfMiAgICAgQSB2aWRlbyBlbmNvZGluZyBsaWJyYXJ5CmxpYmZvbnRlbmMtMS4wLjQgICAg VGhlIGZvbnRlbmMgTGlicmFyeQpsaWJmcHgtMS4yLjAuMTJfMSAgIExpYnJhcnkgcm91dGlu ZXMgZm9yIHdvcmtpbmcgd2l0aCBGbGFzaHBpeCBpbWFnZXMKbGliZ2NyeXB0LTEuNC40ICAg ICBHZW5lcmFsIHB1cnBvc2UgY3J5cHRvIGxpYnJhcnkgYmFzZWQgb24gY29kZSB1c2VkIGlu IEdudVBHCmxpYmdsYWRlMi0yLjYuMyAgICAgR05PTUUgZ2xhZGUgbGlicmFyeQpsaWJnbHV0 LTcuM18xICAgICAgIE9wZW5HTCB1dGlsaXR5IHRvb2xraXQKbGliZ21wLTQuMi40ICAgICAg ICBBIGZyZWUgbGlicmFyeSBmb3IgYXJiaXRyYXJ5IHByZWNpc2lvbiBhcml0aG1ldGljCmxp YmdwZy1lcnJvci0xLjcgICAgQ29tbW9uIGVycm9yIHZhbHVlcyBmb3IgYWxsIEdudVBHIGNv bXBvbmVudHMKbGliZ3Bob3RvMi0yLjQuNCAgICBBIHVuaXZlcnNhbCBkaWdpdGFsIGNhbWVy YSBwaWN0dXJlIGNvbnRyb2wgdG9vbApsaWJnc2YtMS4xNC4xMSAgICAgIEFuIGV4dGVuc2li bGUgaS9vIGFic3RyYWN0aW9uIGZvciBkZWFsaW5nIHdpdGggc3RydWN0dXJlZCBmCmxpYmlj YWwtMC40MiAgICAgICAgQW4gaW1wbGVtZW50YXRpb24gb2YgdGhlIElFVEYncyBDYWxlbmRh cmluZyBhbmQgU2NoZWR1bGluZyAKbGliaWNvbnYtMS4xMV8xICAgICBBIGNoYXJhY3RlciBz ZXQgY29udmVyc2lvbiBsaWJyYXJ5CmxpYmlkM3RhZy0wLjE1LjFiICAgSUQzIHRhZ3MgbGli cmFyeSAocGFydCBvZiBNQUQgcHJvamVjdCkKbGliaWRuLTEuOSAgICAgICAgICBJbnRlcm5h dGlvbmFsaXplZCBEb21haW4gTmFtZXMgY29tbWFuZCBsaW5lIHRvb2wKbGliaWpzLTAuMzVf MSAgICAgICBDIGxpYnJhcnkgdGhhdCBzdXBwb3J0cyBwbHVnaW4gcHJpbnRlciBkcml2ZXIg Zm9yIEdob3N0c2NyaQpsaWJpbWctMS4yLjRfNCAgICAgIEEgbGlicmFyeSBvZiBpbWFnZSBm b3JtYXQgaGFuZGxlcnMgZm9yIFRrNC4xIGFuZCBsYXRlcgpsaWJrc2JhLTEuMC41ICAgICAg IEtTQkEgaXMgYW4gWC41MDkgTGlicmFyeQpsaWJsdGRsLTEuNS4yNiAgICAgIFN5c3RlbSBp bmRlcGVuZGVudCBkbG9wZW4gd3JhcHBlcgpsaWJtYWQtMC4xNS4xYl8yICAgIExpYm1hZCBs aWJyYXJ5IChwYXJ0IG9mIE1BRCBwcm9qZWN0KQpsaWJtYWwtMC40NCAgICAgICAgIEEgbGli cmFyeSBlbmNhcHN1bGF0aW5nIG1hbHN5bmMKbGlibW5nLTEuMC4xMCAgICAgICBNdWx0aXBs ZS1pbWFnZSBOZXR3b3JrIEdyYXBoaWNzIChNTkcpIHJlZmVyZW5jZSBsaWJyYXJ5CmxpYm1v ZHBsdWctMC44LjQgICAgTW9kUGx1ZyBtb2QtbGlrZSBtdXNpYyBzaGFyZWQgbGlicmFyaWVz CmxpYm1wY2RlYy0xLjIuNiAgICAgSGlnaCBxdWFsaXR5IGF1ZGlvIGNvbXByZXNzaW9uIGZv cm1hdApsaWJtc3BhY2stMC4wLjIwMDYwOTIwIEEgbGlicmFyeSBmb3IgTWljcm9zb2Z0IGNv bXByZXNzaW9uIGZvcm1hdHMKbGlibXVzaWNicmFpbnotMi4xLjUgMm5kIGdlbmVyYXRpb24g aW5jYXJuYXRpb24gb2YgdGhlIENEIEluZGV4IC0gYXVkaW8gbWV0YWRhdGEKbGlibmV0MTAt MS4wLjJhXzQsMSBBIEMgbGlicmFyeSBmb3IgY3JlYXRpbmcgSVAgcGFja2V0cwpsaWJuZXQx MS0xLjEuMi4xXzIsMSBBIEMgbGlicmFyeSBmb3IgY3JlYXRpbmcgSVAgcGFja2V0cwpsaWJu aWRzLTEuMjFfNCAgICAgIE5ldHdvcmsgbW9uaXRvcmluZyBsaWJyYXJ5IHdpdGggVENQL0lQ IHJlYXNzZW1ibHkKbGlibm90aWZ5LTAuNC41ICAgICBBIGxpYnJhcnkgZm9yIGRlc2t0b3Ag bm90aWZpY2F0aW9ucwpsaWJvZmEtMC45LjNfMiAgICAgIFRoZSBPcGVuIEZpbmdlcnByaW50 IEFyY2hpdGVjdHVyZSBMaWJyYXJ5CmxpYm9nZy0xLjEuMyw0ICAgICAgT2dnIGJpdHN0cmVh bSBsaWJyYXJ5CmxpYm9pbC0wLjMuMTUgICAgICAgTGlicmFyeSBvZiBvcHRpbWl6ZWQgaW5u ZXIgbG9vcHMKbGlib2xkWC0xLjAuMSAgICAgICBPbGQgWCBsaWJyYXJ5CmxpYm90ci0zLjIu MF8xICAgICAgVGhlIHBvcnRhYmxlIE9UUiBNZXNzYWdpbmcgTGlicmFyeSBhbmQgdG9vbGtp dApsaWJwYXBlci0xLjEuMjFfMyAgIEEgbGlicmFyeSBwcm92aWRpbmcgcm91dGluZXMgZm9y IHBhcGVyIHNpemUgbWFuYWdlbWVudApsaWJwY2FwLTAuOS43XzEgICAgIFViaXF1aXRvdXMg bmV0d29yayB0cmFmZmljIGNhcHR1cmUgbGlicmFyeQpsaWJwY2ktMi4yLjhfMSAgICAgIFBD SSBjb25maWd1cmF0aW9uIHNwYWNlIEkvTyBtYWRlIGVhc3kKbGlicGNpYWNjZXNzLTAuMTAu NV8yIEdlbmVyaWMgUENJIGFjY2VzcyBsaWJyYXJ5CmxpYnB0aHJlYWQtc3R1YnMtMC4xIFRo aXMgbGlicmFyeSBwcm92aWRlcyB3ZWFrIGFsaWFzZXMgZm9yIHB0aHJlYWQgZnVuY3Rpb25z CmxpYnB1cnBsZS0yLjUuNCAgICAgQmFja2VuZCBsaWJyYXJ5IGZvciB0aGUgUGlkZ2luIG11 bHRpLXByb3RvY29sIG1lc3NhZ2luZyBjbGkKbGlicnN2ZzItMi4yMi4zXzIgICBMaWJyYXJ5 IGZvciBwYXJzaW5nIGFuZCByZW5kZXJpbmcgU1ZHIHZlY3Rvci1ncmFwaGljIGZpbGVzCmxp YnNhbXBsZXJhdGUtMC4xLjQgU2VjcmV0IFJhYmJpdCBDb2RlOiBhIFNhbXBsZSBSYXRlIENv bnZlcnRlciBmb3IgYXVkaW8KbGlic2lnYysrLTIuMi4zICAgICBDYWxsYmFjayBGcmFtZXdv cmsgZm9yIEMrKwpsaWJzbGFuZzItMi4xLjQgICAgIFJvdXRpbmVzIGZvciByYXBpZCBhbHBo YS1udW1lcmljIHRlcm1pbmFsIGFwcGxpY2F0aW9ucyBkZXZlCmxpYnNtaS0wLjQuNyAgICAg ICAgQSBsaWJyYXJ5IHRvIGFjY2VzcyBTTUkgTUlCIGluZm9ybWF0aW9uCmxpYnNuZGZpbGUt MS4wLjE3XzIgUmVhZGluZyBhbmQgd3JpdGluZyBmaWxlcyBjb250YWluaW5nIHNhbXBsZWQg c291bmQgKGxpa2UgV0EKbGlic291cC0yLjI0LjMgICAgICBBIFNPQVAgKFNpbXBsZSBPYmpl Y3QgQWNjZXNzIFByb3RvY29sKSBpbXBsZW1lbnRhdGlvbiBpbiBDCmxpYnNwZWN0cmUtMC4y LjIgICAgQSBzbWFsbCBsaWJyYXJ5IGZvciByZW5kZXJpbmcgUG9zdHNjcmlwdCBkb2N1bWVu dHMKbGlidGFzbjEtMS44ICAgICAgICBBU04uMSBzdHJ1Y3R1cmUgcGFyc2VyIGxpYnJhcnkK bGlidGhlb3JhLTEuMC5iMiAgICBUaGVvcmEgdmlkZW8gY29kZWMgZm9yIHRoZSBPZ2cgbXVs dGltZWRpYSBzdHJlYW1pbmcgc3lzdGVtCmxpYnRvb2wtMS41LjI2ICAgICAgR2VuZXJpYyBz aGFyZWQgbGlicmFyeSBzdXBwb3J0IHNjcmlwdApsaWJ0b3JyZW50LWRldmVsLTAuMTIuNCBC aXRUb3JyZW50IExpYnJhcnkgd3JpdHRlbiBpbiBDKysgKGRldmVsb3BtZW50IHZlcnNpb24p CmxpYnR1bmVwaW1wLTAuNS4zXzMsMSBDbGllbnQgbGlicmFyeSBmb3IgbXVzaWNicmFpbnoK bGlidWJsaW8tMjAwNzAxMDMgICBVc2VyIHNwYWNlIGNhY2hpbmcgbGlicmFyeQpsaWJ1bmdp Zi00LjEuNF81ICAgIFRvb2xzIGFuZCBsaWJyYXJ5IHJvdXRpbmVzIGZvciB3b3JraW5nIHdp dGggR0lGIGltYWdlcwpsaWJ1c2ItMC4xLjEyXzQgICAgIExpYnJhcnkgZ2l2aW5nIHVzZXJs YW5kIHByb2dyYW1zIGFjY2VzcyB0byBVU0IgZGV2aWNlcwpsaWJ1dGVtcHRlci0xLjEuNV8x IEludGVyZmFjZSB0byByZWNvcmQgdXNlciBzZXNzaW9ucyB0byB1dG1wIGFuZCB3dG1wIGZp bGVzCmxpYnZvbHVtZV9pZC0wLjgxLjAgTGlicmFyeSB0byBwcm92aWRlIGZpbGUgc3lzdGVt IHR5cGUgaW5mb3JtYXRpb24KbGlidm9yYmlzLTEuMi4wXzIsMyBBdWRpbyBjb21wcmVzc2lv biBjb2RlYyBsaWJyYXJ5CmxpYndtZi0wLjIuOC40XzIgICAgVG9vbHMgYW5kIGxpYnJhcnkg Zm9yIGNvbnZlcnRpbmcgTWljcm9zb2Z0IFdNRiAod2luZG93cyBtZXQKbGlid25jay0yLjI0 LjIgICAgICBMaWJyYXJ5IHVzZWQgZm9yIHdyaXRpbmcgcGFnZXJzIGFuZCB0YXNrc2xpc3Rz CmxpYnd3dy01LjQuMF80ICAgICAgVGhlIFczQyBSZWZlcmVuY2UgTGlicmFyeQpsaWJ4Y2It MS4xLjkzICAgICAgIFRoZSBYIHByb3RvY29sIEMtbGFuZ3VhZ2UgQmluZGluZyAoWENCKSBs aWJyYXJ5CmxpYnhpbmUtMS4xLjE1XzMgICAgTGlicmFyaWVzIGZvciB4aW5lIG11bHRpbWVk aWEgcGxheWVyCmxpYnhrYmZpbGUtMS4wLjUgICAgWEtCIGZpbGUgbGlicmFyeQpsaWJ4a2J1 aS0xLjAuMl8xICAgIFRoZSB4a2J1aSBsaWJyYXJ5CmxpYnhrbGF2aWVyLTMuNywxICAgQW4g dXRpbGl0eSBsaWJyYXJ5IHRvIG1ha2UgWEtCIHN0dWZmIGVhc2llcgpsaWJ4bWwyLTIuNy4z ICAgICAgIFhNTCBwYXJzZXIgbGlicmFyeSBmb3IgR05PTUUKbGlieHNsdC0xLjEuMjRfMiAg ICBUaGUgWFNMVCBDIGxpYnJhcnkgZm9yIEdOT01FCmxpYnppcC0wLjggICAgICAgICAgQSBD IGxpYnJhcnkgZm9yIHJlYWRpbmcsIGNyZWF0aW5nLCBhbmQgbW9kaWZ5aW5nIHppcCBhcmNo aXYKbGludXgtT1JCaXQyLTIuMTQuMyBBIGhpZ2gtcGVyZm9ybWFuY2UgQ09SQkEgT2JqZWN0 IFJlcXVlc3QgQnJva2VyCmxpbnV4LWFsc2EtbGliLTEuMC4xMC4zIFRoZSBBZHZhbmNlZCBM aW51eCBTb3VuZCBBcmNoaXRlY3R1cmUgbGlicmFyaWVzCmxpbnV4LWF0ay0xLjkuMV8xICAg QWNjZXNzaWJpbGl0eSBUb29sa2l0LCBMaW51eC9pMzg2IGJpbmFyeQpsaW51eC1jYWlyby0x LjAuMiAgIExpbnV4IGNhaXJvIGJpbmFyeQpsaW51eC1leHBhdC0xLjk1LjggIExpbnV4L2kz ODYgYmluYXJ5IHBvcnQgb2YgRXhwYXQgWE1MLXBhcnNpbmcgbGlicmFyeQpsaW51eC1mb250 Y29uZmlnLTIuMi4zXzcgTGludXgvaTM4NiBiaW5hcnkgb2YgRm9udGNvbmZpZwpsaW51eC1n Y29uZjItMi4xNCAgIEEgcHJvY2Vzcy10cmFuc3BhcmVudCBjb25maWd1cmF0aW9uIHN5c3Rl bQpsaW51eC1ndGsyLTIuMTAuMTNfMSBHVEsrIGxpYnJhcnksIHZlcnNpb24gMi5YLCBMaW51 eCBiaW5hcnkKbGludXgtanBlZy02Yi4zNCAgICBSUE0gb2YgdGhlIEpQRUcgbGliCmxpbnV4 LWxpYmNhcC0xLjEwICAgTGlicmFyeSBmb3IgZ2V0dGluZyBhbmQgc2V0dGluZyBQT1NJWC4x ZSBjYXBhYmlsaXRpZXMKbGludXgtbGlic2lnYy0yLjAuMTcgQ2FsbGJhY2sgRnJhbWV3b3Jr IGZvciBDKysgKGxpbnV4IHZlcnNpb24pCmxpbnV4LWxpYnhtbDItMi42LjE5IFJQTSBvZiBs aWJ4bWwyCmxpbnV4LW5zcHItNC42LjcgICAgQSBwbGF0Zm9ybS1uZXV0cmFsIEFQSSBmb3Ig c3lzdGVtIGxldmVsIGFuZCBsaWJjIGxpa2UgZnVuY3QKbGludXgtbnNzLTMuMTEuNyAgICBM aWJyYXJpZXMgdG8gc3VwcG9ydCBkZXZlbG9wbWVudCBvZiBzZWN1cml0eS1lbmFibGVkIGFw cGxpYwpsaW51eC1wYW5nby0xLjEwLjJfMSBMaW51eCBwYW5nbyBiaW5hcnkKbGludXgtcG5n LTEuMi44XzIgICBSUE0gb2YgdGhlIFBORyBsaWIKbGludXgtcHVsc2VhdWRpby1saWItMC45 LjYgTGlicmFyaWVzIGZvciBQdWxzZUF1ZGlvIGNsaWVudHMKbGludXgtc3VuLWpkay0xLjYu MC4xMCBTdW4gSmF2YSBEZXZlbG9wbWVudCBLaXQgMS42IGZvciBMaW51eApsaW51eC10aWZm LTMuNy4xICAgIFRJRkYgbGlicmFyeSwgTGludXgvaTM4NiBiaW5hcnkKbGludXgteG9yZy1s aWJzLTYuOC4yXzUgWG9yZyBsaWJyYXJpZXMsIGxpbnV4IGJpbmFyaWVzCmxpbnV4X2Jhc2Ut ZmM2LTZfNSAgQmFzZSBzZXQgb2YgcGFja2FnZXMgbmVlZGVkIGluIExpbnV4IG1vZGUgKGZv ciBpMzg2L2FtZDY0KQpsaW51eF9kcmktNy4wICAgICAgIEJpbmFyeSBMaW51eCBEUkkgbGli cmFyaWVzIGZvciAzRCBoYXJkd2FyZSBhY2NlbGVyYXRpb24gb2YgCmxpc3RyZXMtMS4wLjFf MSAgICAgTGlzdCByZXNvdXJjZXMgaW4gd2lkZ2V0cwpsb2NhbGVkYXRhLTUuNCAgICAgIExl Z2FjeSBsb2NhbGUgZGF0YSBmb3IgRnJlZUJTRCA2KwpsdWEtNS4xLjNfMyAgICAgICAgIFNt YWxsLCBjb21waWxhYmxlIHNjcmlwdGluZyBsYW5ndWFnZSBwcm92aWRpbmcgZWFzeSBhY2Nl c3MgCmx1aXQtMS4wLjMgICAgICAgICAgTG9jYWxlIGFuZCBJU08gMjAyMiBzdXBwb3J0IGZv ciBVbmljb2RlIHRlcm1pbmFscwptNC0xLjQuMTEsMSAgICAgICAgIEdOVSBtNAptRE5TUmVz cG9uZGVyLTEwOCAgIEFwcGxlJ3MgbUROU1Jlc3BvbmRlcgptYWtlZGVwZW5kLTEuMC4xLDEg IEEgZGVwZW5kZW5jeSBnZW5lcmF0b3IgZm9yIG1ha2VmaWxlcwptYy00LjYuMiAgICAgICAg ICAgIE1pZG5pZ2h0IENvbW1hbmRlciwgYSBmcmVlIE5vcnRvbiBDb21tYW5kZXIgQ2xvbmUK bWNhYmJlci0wLjkuOSAgICAgICBTbWFsbCBKYWJiZXIgY29uc29sZSBjbGllbnQKbWVzYS1k ZW1vcy03LjMgICAgICBPcGVuR0wgZGVtb3MgZGlzdHJpYnV0ZWQgd2l0aCBNZXNhCm1pbmd3 MzItYmluLW1zdmNydC1yMy4xNS5hMy4xMiBIZWFkZXJzIGFuZCBMaWJyYXJpZXMgZm9yIFdp bmRvd3MgY3Jvc3MtZGV2ZWxvcG1lbnQKbWluZ3czMi1iaW51dGlscy0yLjE4LDEgR05VIEJp bnV0aWxzIGZvciBXaW5kb3dzIGNyb3NzLWRldmVsb3BtZW50Cm1pbmd3MzItZ2NjLTQuMi4x LDEgRlNGIGdjYy00LjIgZm9yIFdpbmRvd3MgY3Jvc3MtZGV2ZWxvcG1lbnQKbWluZ3czMi1w dGhyZWFkcy0yLjguMCBQT1NJWCB0aHJlYWRzIGxpYnJhcnkgZm9yIFdpbmRvd3MgY29tcGls ZWQgd2l0aCBNaW5HVzMyCm1rY29tcG9zZWNhY2hlLTEuMl8xIFByb2dyYW0gdG8gY3JlYXRl IENvbXBvc2UgY2FjaGUgZmlsZXMKbWtmb250ZGlyLTEuMC40ICAgICBDcmVhdGUgYW4gaW5k ZXggb2YgWCBmb250IGZpbGVzIGluIGEgZGlyZWN0b3J5Cm1rZm9udHNjYWxlLTEuMC42ICAg Q3JlYXRlcyBhbiBpbmRleCBvZiBzY2FsYWJsZSBmb250IGZpbGVzIGZvciBYCm1wZWc0aXAt bGlibXA0djItMS42LjEgTXBlZy00IGxpYnJhcnkgYW5kIHRvb2xzIGZyb20gbXBlZzRpcApt cGxheWVyLTAuOTkuMTFfMTEgIEhpZ2ggcGVyZm9ybWFuY2UgbWVkaWEgcGxheWVyIHN1cHBv cnRpbmcgbWFueSBmb3JtYXRzCm1wbGF5ZXItc2tpbnMtMS4xLjJfNiBTa2lucyBmb3IgTVBs YXllcidzIEdyYXBoaWNhbCBVc2VyIEludGVyZmFjZSAoR1VJKQpteXNxbC1jbGllbnQtNS4w Ljc1IE11bHRpdGhyZWFkZWQgU1FMIGRhdGFiYXNlIChjbGllbnQpCm15c3FsLXNlcnZlci01 LjAuNzUgTXVsdGl0aHJlYWRlZCBTUUwgZGF0YWJhc2UgKHNlcnZlcikKbmFzLTEuOS4xXzMg ICAgICAgICBOZXR3b3JrIEF1ZGlvIFN5c3RlbQpuYXNtLTIuMDUuMDEsMSAgICAgIEdlbmVy YWwtcHVycG9zZSBtdWx0aS1wbGF0Zm9ybSB4ODYgYW5kIHg4Ni02NCBhc3NlbWJsZXIKbmVv bjI4LTAuMjguMyAgICAgICBBbiBIVFRQIGFuZCBXZWJEQVYgY2xpZW50IGxpYnJhcnkgZm9y IFVuaXggc3lzdGVtcwpuZXQtc25tcC01LjQuMi4xXzEgIEFuIGV4dGVuZGFibGUgU05NUCBp bXBsZW1lbnRhdGlvbgpuZXRwYm0tMTAuMjYuNTkgICAgIEEgdG9vbGtpdCBmb3IgY29udmVy c2lvbiBvZiBpbWFnZXMgYmV0d2VlbiBkaWZmZXJlbnQgZm9ybWF0Cm5ld2ZpbGUtMS4wLjE0 XzIgICAgQSB0b29sIGZvciBjcmVhdGluZyBzdGFydGVyIGZpbGVzIGluIHZhcmlvdXMgbGFu Z3VhZ2VzCm5tYXAtNC43NiAgICAgICAgICAgUG9ydCBzY2FubmluZyB1dGlsaXR5IGZvciBs YXJnZSBuZXR3b3Jrcwpuc3ByLTQuNyAgICAgICAgICAgIEEgcGxhdGZvcm0tbmV1dHJhbCBB UEkgZm9yIHN5c3RlbSBsZXZlbCBhbmQgbGliYyBsaWtlIGZ1bmN0Cm5zcy0zLjExLjlfMiAg ICAgICAgTGlicmFyaWVzIHRvIHN1cHBvcnQgZGV2ZWxvcG1lbnQgb2Ygc2VjdXJpdHktZW5h YmxlZCBhcHBsaWMKb2Nsb2NrLTEuMC4xICAgICAgICBSb3VuZCBjbG9jayBhcHBsaWNhdGlv biBmb3IgWApvcGVubGRhcC1jbGllbnQtMi40LjEzIE9wZW4gc291cmNlIExEQVAgY2xpZW50 IGltcGxlbWVudGF0aW9uCm9wZXJhLTkuNjMuMjAwODEyMTVfMSBCbGF6aW5nbHkgZmFzdCwg ZnVsbC1mZWF0dXJlZCwgc3RhbmRhcmRzLWNvbXBsaWFudCBicm93c2VyLApwNS1BcmNoaXZl LVppcC0xLjI2IFBlcmwgbW9kdWxlIHRvIGNyZWF0ZSwgbWFuaXB1bGF0ZSwgcmVhZCwgYW5k IHdyaXRlIFppcCBhcmNoCnA1LUNvbXByZXNzLVJhdy1abGliLTIuMDE1IExvdy1MZXZlbCBJ bnRlcmZhY2UgdG8gemxpYiBjb21wcmVzc2lvbiBsaWJyYXJ5CnA1LUNvbXByZXNzLVpsaWIt Mi4wMTUgUGVybDUgaW50ZXJmYWNlIHRvIHpsaWIgY29tcHJlc3Npb24gbGlicmFyeQpwNS1G aWxlLVRlbXAtMC4yMSAgIFBlcmw1IG1vZHVsZSB0byBnZW5lcmF0ZSB0ZW1wb3JhcnkgZmls ZXMgb3IgZGlyZWN0b3JpZXMgc2FmCnA1LUZpbGUtV2hpY2gtMC4wNSAgUG9ydGFibGUgaW1w bGVtZW50YXRpb24gb2YgYHdoaWNoJyBpbiBQZXJsCnA1LUlPLUNvbXByZXNzLUJhc2UtMi4w MTUgQmFzZSBDbGFzcyBmb3IgSU86OlVuY29tcHJlc3MgbW9kdWxlcwpwNS1JTy1Db21wcmVz cy1abGliLTIuMDE1IFBlcmw1IGludGVyZmFjZSBmb3IgcmVhZGluZyBhbmQgd3JpdGluZyBv ZiAoZyl6aXAgZmlsZXMKcDUtUGF0aFRvb2xzLTMuMjkwMCBBIFBlcmwgbW9kdWxlIGZvciBw b3J0YWJseSBtYW5pcHVsYXRpbmcgZmlsZSBzcGVjaWZpY2F0aW9ucwpwNS1YTUwtUGFyc2Vy LTIuMzYgIFBlcmwgZXh0ZW5zaW9uIGludGVyZmFjZSB0byBKYW1lcyBDbGFyaydzIFhNTCBw YXJzZXIsIGV4cGF0CnA1LWdldHRleHQtMS4wNV8yICAgTWVzc2FnZSBoYW5kbGluZyBmdW5j dGlvbnMKcDUtdHlwZTFpbnN0LTAuNi4xXzUgQSBzY3JpcHQgdGhhdCBoZWxwcyBpbnN0YWxs IFBvc3RzY3JpcHQgZm9udHMgaW4gWCBXaW5kb3cgU3kKcGFuZ28tMS4yMi40ICAgICAgICBB biBvcGVuLXNvdXJjZSBmcmFtZXdvcmsgZm9yIHRoZSBsYXlvdXQgYW5kIHJlbmRlcmluZyBv ZiBpMQpwYXRjaC0yLjUuNCAgICAgICAgIEdOVSBwYXRjaCB1dGlsaXR5CnBjaWlkcy0yMDA4 MTAxMiAgICAgRGF0YWJhc2Ugb2YgYWxsIGtub3duIElEJ3MgdXNlZCBpbiBQQ0kgZGV2aWNl cwpwY3JlLTcuOCAgICAgICAgICAgIFBlcmwgQ29tcGF0aWJsZSBSZWd1bGFyIEV4cHJlc3Np b25zIGxpYnJhcnkKcGRmZWRpdC0wLjQuMV8xICAgICBGcmVlIGVkaXRvciBmb3IgbWFuaXB1 bGF0aW5nIFBERiBkb2N1bWVudHMgKFFUMyBHVUkgYW5kIENMSQpwZXJsLTUuOC45ICAgICAg ICAgIFByYWN0aWNhbCBFeHRyYWN0aW9uIGFuZCBSZXBvcnQgTGFuZ3VhZ2UKcGhvbm9uLTQu My4wICAgICAgICBLREU0IHBob25vbiBhcHBsaWNhdGlvbnMKcGlkZ2luLTIuNS40ICAgICAg ICBQaWRnaW4gbXVsdGktcHJvdG9jb2wgbWVzc2FnaW5nIGNsaWVudCAoR1RLKyBVSSkKcGls b3QtbGluay0wLjEyLjMsMSBTdWl0ZSBvZiB0b29scyB1c2VkIHRvIGNvbm5lY3QgYW5kIHN5 bmMgeW91ciBQYWxtIGhhbmRsZWQKcGluZW50cnktMC43LjVfMSAgICBBIGNvbGxlY3Rpb24g b2Ygc2ltcGxlIFBJTiBvciBwYXNzcGhyYXNlIGVudHJ5IGRpYWxvZ3MKcGl4bWFuLTAuMTMu MiAgICAgICBMb3ctbGV2ZWwgcGl4ZWwgbWFuaXB1bGF0aW9uIGxpYnJhcnkKcGtnLWNvbmZp Zy0wLjIzXzEgICBBIHV0aWxpdHkgdG8gcmV0cmlldmUgaW5mb3JtYXRpb24gYWJvdXQgaW5z dGFsbGVkIGxpYnJhcmllcwpwbmctMS4yLjM0ICAgICAgICAgIExpYnJhcnkgZm9yIG1hbmlw dWxhdGluZyBQTkcgaW1hZ2VzCnBvbGljeWtpdC0wLjlfMiAgICAgRnJhbWV3b3JrIGZvciBj b250cm9sbGluZyBhY2Nlc3MgdG8gc3lzdGVtLXdpZGUgY29tcG9uZW50cwpwb2xpY3lraXQt Z25vbWUtMC45LjIgR05PTUUgZnJvbnRlbmQgdG8gdGhlIFBvbGljS2l0IGZyYW1ld29yawpw b3BwbGVyLTAuOC43XzEgICAgIEEgUERGIHJlbmRlcmluZyBsaWJyYXJ5CnBvcHBsZXItZGF0 YS0wLjIuMSAgUG9wcGxlciBlbmNvZGluZyBkYXRhCnBvcHBsZXItZ3RrLTAuOC43ICAgR3Rr IGJpbmRpbmdzIHRvIHBvcHBsZXIKcG9wcGxlci1xdDQtMC44LjcgICBRdDQgYmluZGluZ3Mg dG8gcG9wcGxlcgpwb3B0LTEuN181ICAgICAgICAgIEEgZ2V0b3B0KDMpIGxpa2UgbGlicmFy eSB3aXRoIGEgbnVtYmVyIG9mIGVuaGFuY2VtZW50cywgZnJvCnBvcnRhdWRpby0xOC4xXzIg ICAgUG9ydGFibGUgY3Jvc3MtcGxhdGZvcm0gQXVkaW8gQVBJCnBvcnRsaW50LTIuMTAuMl8x ICAgQSB2ZXJpZmllciBmb3IgRnJlZUJTRCBwb3J0IGRpcmVjdG9yeQpwb3J0bWFzdGVyLTIu NiAgICAgIE1hbmFnZSB5b3VyIHBvcnRzIHdpdGhvdXQgZXh0ZXJuYWwgZGF0YWJhc2VzIG9y IGxhbmd1YWdlcwpwb3J0dG9vbHMtMC43N18zICAgIFRvb2xzIGZvciB0ZXN0aW5nIGFuZCBz dWJtaXR0aW5nIHBvcnQgdXBkYXRlcyBhbmQgbmV3IHBvcnRzCnBvcnR1cGdyYWRlLTIuNC42 LDIgRnJlZUJTRCBwb3J0cy9wYWNrYWdlcyBhZG1pbmlzdHJhdGlvbiBhbmQgbWFuYWdlbWVu dCB0b29sIHMKcG9zdGdyZXNxbC1jbGllbnQtOC4zLjUgUG9zdGdyZVNRTCBkYXRhYmFzZSAo Y2xpZW50KQpwcmludHByb3RvLTEuMC40ICAgIFByaW50IGV4dGVuc2lvbiBoZWFkZXJzCnBy aW50c2NyZWVuLTEuMCAgICAgU2ltcGxlIHNjcmVlbnNob3QgcHJvZ3JhbSBmb3IgWDExCnBy aXZveHktMy4wLjEwICAgICAgUHJpdm94eSBpcyBhIHdlYiBwcm94eSB3aXRoIGFkdmFuY2Vk IGZpbHRlcmluZyBjYXBhYmlsaXRpZXMKcHRoLTIuMC43ICAgICAgICAgICBHTlUgUG9ydGFi bGUgVGhyZWFkcwpwdWxzZWF1ZGlvLTAuOS4xNCAgIFNvdW5kIHNlcnZlciBmb3IgVU5JWApw eTI1LUltcGFja2V0LTAuOS42LjAgQ29sbGVjdGlvbiBvZiBQeXRob24gY2xhc3NlcyBwcm92 aWRpbmcgYWNjZXNzIHRvIG5ldHdvcmsgcGEKcHkyNS1jYWlyby0xLjguMiAgICBQeXRob24g YmluZGluZ3MgZm9yIENhaXJvCnB5MjUtY3J5cHRraXQtMC45ICAgQSBDcnlwdG9ncmFwaGlj IFRvb2xraXQgZm9yIFB5dGhvbgpweTI1LWRidXMtMC44My4wXzEgIFB5dGhvbiBiaW5kaW5n cyBmb3IgdGhlIEQtQlVTIG1lc3NhZ2luZyBzeXN0ZW0KcHkyNS1leWVkMy0wLjYuMTYgICBQ eXRob24gbW9kdWxlIGZvciBwcm9jZXNzaW5nIElEMyB0YWdzCnB5MjUtZ29iamVjdC0yLjE2 LjAgUHl0aG9uIGJpbmRpbmdzIGZvciBHT2JqZWN0CnB5MjUtZ3RrLTIuMTMuMF8xICAgQSBz ZXQgb2YgUHl0aG9uIGJpbmRpbmdzIGZvciBHVEsrCnB5MjUtaW1hZ2luZy0xLjEuNl8yIFRo ZSBQeXRob24gSW1hZ2luZyBMaWJyYXJ5CnB5MjUtbGlieG1sMi0yLjcuMiAgUHl0aG9uIGlu dGVyZmFjZSBmb3IgWE1MIHBhcnNlciBsaWJyYXJ5IGZvciBHTk9NRQpweTI1LW11dGFnZW4t MS4xMiAgIEEgUHl0aG9uLWJhc2VkIGF1ZGlvIG1ldGFkYXRhIHRhZyByZWFkZXIgYW5kIHdy aXRlcgpweTI1LW51bWVyaWMtMjQuMl8zIFRoZSBOdW1lcmljIEV4dGVuc2lvbiB0byBQeXRo b24KcHkyNS1vcGVuZ2wtMy4wLjAuYjhfMSBBbiBPcGVuR0wgKGFuZCByZWxhdGVkIGxpYnJh cnkpIGludGVyZmFjZSBmb3IgUHl0aG9uCnB5MjUtcGNhcHktMC4xMC41ICAgUHl0aG9uIGV4 dGVuc2lvbiBtb2R1bGUgdG8gY2FwdHVyZSBwYWNrZXRzIG9uIHRoZSBuZXR3b3JrCnB5MjUt cHljcnlwdG8tMi4wLjFfMSBUaGUgUHl0aG9uIENyeXB0b2dyYXBoeSBUb29sa2l0CnB5MjUt c2lwLTQuNy45LDEgICAgUHl0aG9uIHRvIEMgYW5kIEMrKyBiaW5kaW5ncyBnZW5lcmF0b3IK cHkyNS1zcWxpdGUzLTIuNS4yXzEgU3RhbmRhcmQgUHl0aG9uIGJpbmRpbmcgdG8gdGhlIFNR TGl0ZTMgbGlicmFyeQpweTI1LXRraW50ZXItMi41LjJfMiBQeXRob24gYmluZGluZ3MgdG8g dGhlIFRrIHdpZGdldCBzZXQKcHkyNS13eFB5dGhvbi1jb21tb24tMi44LjcuMV8xIFB5dGhv biBiaW5kaW5ncyBmb3IgdGhlIHd4V2lkZ2V0cy9HVEsgR1VJIHRvb2xraXQKcHkyNS13eFB5 dGhvbi11bmljb2RlLTIuOC43LjFfMSBQeXRob24gYmluZGluZ3MgZm9yIHRoZSB3eFdpZGdl dHMvR1RLIEdVSSB0b29sa2l0CnB5MjUteG1sLTAuOC40ICAgICAgUHlYTUw6IFB5dGhvbiBY TUwgbGlicmFyeSBlbmhhbmNlbWVudHMKcHl0aG9uMjUtMi41LjJfMyAgICBBbiBpbnRlcnBy ZXRlZCBvYmplY3Qtb3JpZW50ZWQgcHJvZ3JhbW1pbmcgbGFuZ3VhZ2UKcWNhLTIuMC4wICAg ICAgICAgICBDcm9zcy1wbGF0Zm9ybSBjcnlwdG8gQVBJIGZvciBRVApxaW1hZ2VibGl0ei0w LjAuNF8xIEtERSA0IGludGVncmF0ZWQgWDExIGRlc2t0b3AKcW1ha2UtMy4zLjhfMSAgICAg ICBUaGUgYnVpbGQgdXRpbGl0eSBvZiB0aGUgUXQgcHJvamVjdApxc2NpbnRpbGxhMi0yLjMu MiwxIFF0NCBwb3J0IG9mIHRoZSBTY2ludGlsbGEgQysrIGVkaXRvciBjbGFzcwpxc3ZuLTAu OC4wICAgICAgICAgIFF0IGJhc2VkIEdVSSBmcm9udGVuZCBmb3IgU3VidmVyc2lvbgpxdC0z LjMuOF85ICAgICAgICAgIE11bHRpcGxhdGZvcm0gQysrIGFwcGxpY2F0aW9uIGZyYW1ld29y awpxdDQtNC40LjMgICAgICAgICAgIE11bHRpcGxhdGZvcm0gQysrIGFwcGxpY2F0aW9uIGZy YW1ld29yayAobWV0YXBvcnQpCnF0NC1hY2Nlc3NpYmxlLTQuNC4zIFF0IGFjY2Vzc2liaWxp dHkgd2lkZ2V0cwpxdDQtYXNzaXN0YW50LTQuNC4zIFF0IGRvY3VtZW50YXRpb24gYnJvd3Nl cgpxdDQtYXNzaXN0YW50LWFkcC00LjQuMyBRdCBkb2N1bWVudGF0aW9uIGJyb3dzZXIsIGFk cCBjb21wYXQgdmVyc2lvbgpxdDQtY2x1Y2VuZS00LjQuMyAgIFF0Q0x1Y2VuZSBmdWxsIHRl eHQgc2VhcmNoIGxpYnJhcnkgd3JhcHBlcgpxdDQtY29yZWxpYi00LjQuMyAgIFF0IGNvcmUg bGlicmFyeQpxdDQtZGJ1cy00LjQuMyAgICAgIFF0NCBiaW5kaW5ncyBmb3IgdGhlIEQtQlVT IG1lc3NhZ2luZyBzeXN0ZW0KcXQ0LWRlc2lnbmVyLTQuNC4zICBRdCB1aSBlZGl0b3IKcXQ0 LWRvYy00LjQuMyAgICAgICBNdWx0aXBsYXRmb3JtIEMrKyBhcHBsaWNhdGlvbiBmcmFtZXdv cmsKcXQ0LWd1aS00LjQuMyAgICAgICBRdCBncmFwaGljYWwgdXNlciBpbnRlcmZhY2UgbGli cmFyeQpxdDQtaGVscC00LjQuMyAgICAgIFF0SGVscCBtb2R1bGUgcHJvdmlkZXMgUUhlbHBF bmdpbmUgQVBJIGFuZCBpcyB1c2VkIGJ5IEFzc2lzCnF0NC1pY29uZW5naW5lcy00LjQuMyBR dCBTVkcgaWNvbiBlbmdpbmUgcGx1Z2luCnF0NC1pbWFnZWZvcm1hdHMtNC40LjMgUXQgaW1h Z2Vmb3JtYXQgcGx1Z2lucyBmb3IgR0lGLCBKUEVHLCBNTkcgYW5kIFNWRwpxdDQtaW5wdXRt ZXRob2RzLTQuNC4zIFF0IGlucHV0IG1ldGhvZCBwbHVnaW5zCnF0NC1sMTBuLTQuNC4zICAg ICAgUXQgdHJhbnNsYXRpb25zIG1lc3NhZ2VzCnF0NC1saWJRdEFzc2lzdGFudENsaWVudC00 LjQuMyBRdCBkb2N1bWVudGF0aW9uIGJyb3dzZXIgaW50ZWdyYXRpb24gbGlicmFyeQpxdDQt bGluZ3Vpc3QtNC40LjMgIFF0IGxvY2FsaXNhdGlvbiB0b29sCnF0NC1tYWtlcXBmLTQuNC4z ICAgUXQgcXRvcGlhIGZvbnQgY3JlYXRvcgpxdDQtbW9jLTQuNC4zICAgICAgIFF0IG1ldGEg b2JqZWN0IGNvbXBpbGVyCnF0NC1teXNxbC1wbHVnaW4tNC40LjMgUXQgTXlTUUwgZGF0YWJh c2UgcGx1Z2luCnF0NC1uZXR3b3JrLTQuNC4zICAgUXQgbmV0d29yayBsaWJyYXJ5CnF0NC1v cGVuZ2wtNC40LjMgICAgUXQgT3BlbkdMIGxpYnJhcnkKcXQ0LXBpeGVsdG9vbC00LjQuMyBR dCBzY3JlZW4gbWFnbmlmaWNhdGlvbiB1dGlsaXR5CnF0NC1wb3J0aW5nLTQuNC4zICAgUXQg dXRpbGl0eSB0byBhc3Npc3Qgd2l0aCBwb3J0aW5nIFF0MyBhcHBsaWNhdGlvbnMgdG8gUXQ0 CnF0NC1xZGJ1c3ZpZXdlci00LjQuMyBRdDQgRC1CVVMgdmlld2VyCnF0NC1xbWFrZS00LjQu MyAgICAgVGhlIGJ1aWxkIHV0aWxpdHkgb2YgdGhlIFF0IHByb2plY3QKcXQ0LXF0M3N1cHBv cnQtNC40LjMgUXQzIGNvbXBhdGliaWxpdHkgbGlicmFyeQpxdDQtcXRlc3RsaWItNC40LjMg IFF0IHVuaXQgdGVzdGluZyBsaWJyYXJ5CnF0NC1xdmZiLTQuNC4zICAgICAgUXQgdmlydHVh bCBmcmFtZWJ1ZmZlciB1dGlsaXR5CnF0NC1yY2MtNC40LjMgICAgICAgUXQgcmVzb3VyY2Ug Y29tcGlsZXIKcXQ0LXNjcmlwdC00LjQuMyAgICBRdCBzY3JpcHQKcXQ0LXNxbC00LjQuMyAg ICAgICBRdCBTUUwgbGlicmFyeQpxdDQtc3FsaXRlLXBsdWdpbi00LjQuMyBRdCBTUUxpdGUg My54IGRhdGFiYXNlIHBsdWdpbgpxdDQtc3ZnLTQuNC4zICAgICAgIFF0IFNWRyBsaWJyYXJ5 CnF0NC11aWMtNC40LjMgICAgICAgUXQgdXNlciBpbnRlcmZhY2UgY29tcGlsZXIKcXQ0LXVp YzMtNC40LjMgICAgICBRdCBiYWNrd2FyZHMtY29tcGF0aWJsZSB1c2VyIGludGVyZmFjZSBj b21waWxlcgpxdDQtd2Via2l0LTQuNC4zICAgIFF0NCB3ZWJraXQgZW5naW5lCnF0NC14bWwt NC40LjMgICAgICAgUXQgWE1MIGxpYnJhcnkKcXQ0LXhtbHBhdHRlcm5zLTQuNC4zIFhRdWVy eSAxLjAgYW5kIFhQYXRoIDIuMCBzdXBwb3J0IGZvciBRdDQKcXQ0LXhtbHBhdHRlcm5zLXRv b2wtNC40LjMgUXQ0IGNvbW1hbmQgbGluZSB1dGlsaXR5IGZvciBydW5uaW5nIFhRdWVyaWVz CnJhbmRycHJvdG8tMS4yLjEgICAgUmFuZHIgZXh0ZW5zaW9uIGhlYWRlcnMKcmFwdG9yLTEu NC4xNl8xICAgICBSREYgUGFyc2VyIFRvb2xraXQgZm9yIFJlZGxhbmQKcmFyaWFuLTAuOC4x ICAgICAgICBBbiBPTUYgaGVscCBzeXN0ZW0gYmFzZWQgb24gdGhlIEZyZWVkZXNrdG9wIHNw ZWNpZmljYXRpb24KcmVjb3JkcHJvdG8tMS4xMy4yICBSRUNPUkQgZXh0ZW5zaW9uIGhlYWRl cnMKcmVkbGFuZC0xLjAuN18xICAgICBBIGhpZ2gtbGV2ZWwgaW50ZXJmYWNlIGZvciBSREYK cmVuZGVycHJvdG8tMC45LjMgICBSZW5kZXJQcm90byBwcm90b2NvbCBoZWFkZXJzCnJlc291 cmNlcHJvdG8tMS4wLjIgUmVzb3VyY2UgZXh0ZW5zaW9uIGhlYWRlcnMKcmdiLTEuMC4xICAg ICAgICAgICBVbmNvbXBpbGUgYW4gcmdiIGNvcmwtbmFtZSBkYXRhYmFzZQpycG0tMy4wLjZf MTQgICAgICAgIFRoZSBSZWQgSGF0IFBhY2thZ2UgTWFuYWdlcgpyc3RhcnQtMS4wLjIgICAg ICAgIFNhbXBsZSBpbXBsZW1lbnRhdGlvbiBvZiBhIFJlbW90ZSBTdGFydCBjbGllbnQKcnRv cnJlbnQtZGV2ZWwtMC44LjQgQml0VG9ycmVudCBDbGllbnQgd3JpdHRlbiBpbiBDKysgKGRl dmVsb3BtZW50IHZlcnNpb24pCnJ1LWtkZS1sMTBuLTQuMi4wICAgUnVzc2lhbiBtZXNzYWdl cyBhbmQgZG9jdW1lbnRhdGlvbiBmb3IgS0RFNApydS1vcGVub2ZmaWNlLm9yZy0zLjAuMSBJ bnRlZ3JhdGVkIHdvcmRwcm9jZXNzb3IvZGJhc2Uvc3ByZWFkc2hlZXQvZHJhd2luZy9jaGFy dC9icgpydWJ5LTEuOC42LjI4NywxICAgIEFuIG9iamVjdC1vcmllbnRlZCBpbnRlcnByZXRl ZCBzY3JpcHRpbmcgbGFuZ3VhZ2UKcnVieTE4LWJkYi0wLjYuNCAgICBSdWJ5IGludGVyZmFj ZSB0byBTbGVlcHljYXQncyBCZXJrZWxleSBEQiByZXZpc2lvbiAyIG9yIGxhdApydWJ5MTgt ZGVwbGF0ZS0wLjguNCBSdWJ5IHRvb2wgZm9yIGNvbnZlcnRpbmcgd2lraS1saWtlIG1hcmt1 cApzYW1iYS0zLjAuMzQsMSAgICAgIEEgZnJlZSBTTUIgYW5kIENJRlMgY2xpZW50IGFuZCBz ZXJ2ZXIgZm9yIFVOSVgKc2FtYmEtbGlic21iY2xpZW50LTMuMC4zNF8xIFNoYXJlZCBsaWJz IGZyb20gdGhlIHNhbWJhIHBhY2thZ2UKc2FuZS1iYWNrZW5kcy0xLjAuMTlfMSBBUEkgZm9y IGFjY2VzcyB0byBzY2FubmVycywgZGlnaXRhbHMgY2FtZXJhLCBmcmFtZSBncmFiYmVycwpz Y3JlZW4tNC4wLjNfNSAgICAgIEEgbXVsdGktc2NyZWVuIHdpbmRvdyBtYW5hZ2VyCnNjcmlw dHMtMS4wLjEgICAgICAgVmFyaW91cyBYIHJlbGF0ZWQgc2NyaXB0cwpzY3Juc2F2ZXJwcm90 by0xLjEuMCBTY3JuU2F2ZXIgZXh0ZW5zaW9uIGhlYWRlcnMKc2RsLTEuMi4xM18yLDIgICAg ICBDcm9zcy1wbGF0Zm9ybSBtdWx0aW1lZGlhIGRldmVsb3BtZW50IEFQSQpzZG9jYm9vay14 bWwtMS4xLDEgICJTaW1wbGlmaWVkIiBEb2NCb29rIFhNTCBEVEQKc2Vzc3JlZy0xLjAuNCAg ICAgICBNYW5hZ2UgdXRtcC93dG1wIGVudHJpZXMgZm9yIG5vbi1pbml0IFggY2xpZW50cwpz ZXR4a2JtYXAtMS4wLjQgICAgIFNldCB0aGUga2V5Ym9hcmQgdXNpbmcgdGhlIFggS2V5Ym9h cmQgRXh0ZW5zaW9uCnNoYXJlZC1taW1lLWluZm8tMC41MSBBIE1JTUUgdHlwZSBkYXRhYmFz ZSBmcm9tIHRoZSBGcmVlRGVza3RvcCBwcm9qZWN0CnNob3dmb250LTEuMC4yICAgICAgRm9u dCBkdW1wZXIgZm9yIHRoZSBYIGZvbnQgc2VydmVyCnNpbGMtdG9vbGtpdC0xLjEuNyAgU2Vj dXJlIEludGVybmV0IExpdmUgQ29uZmVyZW5jaW5nIChTSUxDKSBuZXR3b3JrIHRvb2xraXQK c2ltZG9jay0xLjJfMSAgICAgICBBIGZhc3QgYW5kIGN1c3RvbWl6YWJsZSBkb2NrYmFyCnNr eXBlLTIuMC4wLjcyLDEgICAgUDJQIFZvSVAgc29mdHdhcmUKc21wcm94eS0xLjAuMiAgICAg ICBTZXNzaW9uIE1hbmFnZXIgUHJveHkKc25vcnQtMi44LjIuMl8yICAgICBMaWdodHdlaWdo dCBuZXR3b3JrIGludHJ1c2lvbiBkZXRlY3Rpb24gc3lzdGVtCnNvcHJhbm8tMi4xLjY3ICAg ICAgUVQ0IFJERiBmcmFtZXdvcmsKc3BlZXgtMS4yLnIxXzEsMSAgICBBbiBvcGVuLXNvdXJj ZSBwYXRlbnQtZnJlZSB2b2ljZSBjb2RlYwpzcWxpdGUzLTMuNi4xMCAgICAgIEFuIFNRTCBk YXRhYmFzZSBlbmdpbmUgaW4gYSBDIGxpYnJhcnkgdy8gVGNsIHdyYXBwZXIKc3RhcnR1cC1u b3RpZmljYXRpb24tMC45XzIgTGlicmFyeSB0aGF0IHN1cHBvcnRzIHN0YXJ0dXAgbm90aWZp Y2F0aW9uIHNwZWMgZnJvbSBmcmVlZGUKc3RyaWdpLTAuNi4zICAgICAgICBEZXNrdG9wIHNl YXJjaGluZyBwcm9ncmFtCnN1YnZlcnNpb24tMS41LjVfMSAgVmVyc2lvbiBjb250cm9sIHN5 c3RlbQpzdWRvLTEuNi45LjE3ICAgICAgIEFsbG93IG90aGVycyB0byBydW4gY29tbWFuZHMg YXMgcm9vdApzdnI0X2Jhc2UtMi42ICAgICAgIENvbXBhdGliaWxpdHkgZnJhbWV3b3JrIG5l Y2Vzc2FyeSBmb3IgU1ZSNCBlbXVsYXRpb24KdDFsaWItNS4xLjJfMSwxICAgICBBIFR5cGUg MSBSYXN0ZXJpemVyIExpYnJhcnkgZm9yIFVOSVgvWDExCnRhZ2xpYi0xLjUgICAgICAgICAg TGlicmFyeSBmb3IgbWFuaXB1bGF0aW5nIElEMyB0YWdzIGFuZCBPZ2cgY29tbWVudHMKdGNs LTguNC4xOSwxICAgICAgICBUb29sIENvbW1hbmQgTGFuZ3VhZ2UKdGNsbGliLTEuMTBfMSAg ICAgICBBIGNvbGxlY3Rpb24gb2YgdXRpbGl0eSBtb2R1bGVzIGZvciBUY2wKdGNsbW9yZS0w LjdiMSAgICAgICBNb3JlIFRDTCBjb21tYW5kcwp0Y2x0bHMtMS42ICAgICAgICAgIFNTTCBl eHRlbnNpb25zIGZvciBUQ0w7IGR5bmFtaWNseSBsb2FkYWJsZQp0ZVRlWC1iYXNlLTMuMF8x NCAgIFRob21hcyBFc3NlcidzIGRpc3RyaWJ1dGlvbiBvZiBUZVggJiBmcmllbmRzIChiaW5h cmllcykKdGVUZVgtdGV4bWYtMy4wXzUgICBUaG9tYXMgRXNzZXIncyBkaXN0cmlidXRpb24g b2YgVGVYICYgZnJpZW5kcyAodGV4bWYgdHJlZSkKdGV4LXRleG1mbG9jYWwtMS45ICBNZXRh LXBvcnQgdGhhdCBjcmVhdGVzIGEgc2l0ZS1sb2NhbCAkVEVYTUYgZGlyZWN0b3J5CnRleGky aHRtbC0xLjc2XzEsMSAgVGV4aW5mbyB0byBIVE1MIGNvbnZlcnRlcgp0aHVuZGVyYmlyZC0y LjAuMC4xOV8xIE1vemlsbGEgVGh1bmRlcmJpcmQgaXMgc3RhbmRhbG9uZSBtYWlsIGFuZCBu ZXdzIHRoYXQgc3RhbmRzCnRodW5kZXJiaXJkLWkxOG4tMi4wLjAuMTggTG9jYWxpemVkIGlu dGVyZmFjZSBmb3IgVGh1bmRlcmJpcmQKdGlmZi0zLjguMl8zICAgICAgICBUb29scyBhbmQg bGlicmFyeSByb3V0aW5lcyBmb3Igd29ya2luZyB3aXRoIFRJRkYgaW1hZ2VzCnRrLTguNC4x OV8xLDIgICAgICAgR3JhcGhpY2FsIHRvb2xraXQgZm9yIFRDTAp0a1h3aW4tMS4wXzMgICAg ICAgIFRjbC9UayBsaWJyYXJ5IHRvIGRldGVjdCBpZGxlIHBlcmlvZHMgb2YgYW4gWCBzZXNz aW9uCnRrYWJiZXItZGV2ZWwtMC4xMS4xLmEuMjAwODEwMjMgVGNsL1RrIGJhc2VkIGphYmJl ciBjbGllbnQsIGRldmVsb3BtZW50IHZlcnNpb24KdGthYmJlci1wbHVnaW5zLTIwMDgxMDIz IEV4dGVybmFsIFBsdWdpbnMgZm9yIFRrYWJiZXIKdG9yLTAuMi4wLjMzICAgICAgICBBbiBh bm9ueW1pemluZyBvdmVybGF5IG5ldHdvcmsgZm9yIFRDUAp0cmFwcHJvdG8tMy40LjMgICAg IERFQy1YVFJBUCBleHRlbnNpb24gaGVhZGVycwp0c29ja3MtMS44LmI1XzQgICAgIEFsbG93 IG5vbiBTT0NLUyBhd2FyZSBhcHBsaWNhdGlvbnMgdG8gdXNlIFNPQ0tTIHdpdGhvdXQgbW9k CnR3bS0xLjAuNCAgICAgICAgICAgVGFiIFdpbmRvdyBNYW5hZ2VyIGZvciB0aGUgWCBXaW5k b3cgU3lzdGVtCnVucmFyLWljb252LTMuODAsNSAgRXh0cmFjdCwgdmlldyAmIHRlc3QgUkFS IGFyY2hpdmVzCnVuemlwLTUuNTJfNSAgICAgICAgTGlzdCwgdGVzdCBhbmQgZXh0cmFjdCBj b21wcmVzc2VkIGZpbGVzIGluIGEgWklQIGFyY2hpdmUKdjRsX2NvbXBhdC0xLjAuMjAwNjA4 MDEgVmlkZW80TGludXggY29tcGF0aWJpbGl0eSBoZWFkZXIKdmFsa251dC0wLjQuOCAgICAg ICBBIERpcmVjdCBDb25uZWN0IGNsaWVudCBRVCBHVUkKdmNkaW1hZ2VyLTAuNy4yM181ICBH TlUgVkNESW1hZ2VyL1ZDRFJpcCAtLSBUaGUgR05VIFZpZGVvQ0QgSW1hZ2UgTWFrZXIvUmlw cGluZwp2aWRhbGlhLTAuMS4xMCAgICAgIEEgZ3JhcGhpY2FsIFRvciBjb250cm9sbGVyIGJh c2VkIG9uIFF0IDQueAp2aWRlb3Byb3RvLTIuMi4yICAgIFZpZGVvIGV4dGVuc2lvbiBoZWFk ZXJzCnZpZXdyZXMtMS4wLjFfMSAgICAgR3JhcGhpY2FsIGNsYXNzIGJyb3dzZXIgZm9yIFh0 CnZvcmJpcy10b29scy0xLjIuMF80LDMgUGxheSwgZW5jb2RlLCBhbmQgbWFuYWdlIE9nZyBW b3JiaXMgZmlsZXMKd2F2cGFjay00LjUwLjEgICAgICBBdWRpbyBjb2RlYyBmb3IgbG9zc2xl c3MsIGxvc3N5IGFuZCBoeWJyaWQgY29tcHJlc3Npb24Kd2ViZm9udHMtMC4zMF82ICAgICBU cnVlVHlwZSBjb3JlIGZvbnRzIGZvciB0aGUgV2ViCndlYmtpdC1ndGsyLTEuMC4xXzQgQW4g b3BlbnNvdXJjZSBicm93c2VyIGVuZ2luZQp3Z2V0LTEuMTEuNCAgICAgICAgIFJldHJpZXZl IGZpbGVzIGZyb20gdGhlIE5ldCB2aWEgSFRUUChTKSBhbmQgRlRQCndpbjMyLWNvZGVjcy0z LjEuMC5yMSwxIEh1Z2UgY29tcGlsYXRpb24gb2YgV2luMzIgYmluYXJ5IHZpZGVvIGNvZGVj cwp3aW5lLTEuMS4xNCwxICAgICAgIE1pY3Jvc29mdCBXaW5kb3dzIGNvbXBhdGliaWxpdHkg bGF5ZXIgZm9yIFVuaXgtbGlrZSBzeXN0ZW1zCndpcmVzaGFyay0xLjAuNSAgICAgQSBwb3dl cmZ1bCBuZXR3b3JrIGFuYWx5emVyL2NhcHR1cmUgdG9vbAp3djItMC4yLjNfMiAgICAgICAg IEEgbGlicmFyeSBwcm92aWRpbmcgcm91dGluZXMgdG8gYWNjZXNzIE1pY3Jvc29mdCBXb3Jk IGZpbGVzCnd4Z3RrMi0yLjYuM181ICAgICAgVGhlIHd4V2lkZ2V0cyBHVUkgdG9vbGtpdCB3 aXRoIEdUSysgYmluZGluZ3MKd3hndGsyLTIuOC45ICAgICAgICBUaGUgd3hXaWRnZXRzIEdV SSB0b29sa2l0IHdpdGggR1RLKyBiaW5kaW5ncwp3eGd0azItY29tbW9uLTIuNi4zXzQgVGhl IHd4V2lkZ2V0cyBHVUkgdG9vbGtpdCAoY29tbW9uIGZpbGVzKQp3eGd0azItY29tbW9uLTIu OC45IFRoZSB3eFdpZGdldHMgR1VJIHRvb2xraXQgKGNvbW1vbiBmaWxlcykKd3hndGsyLWNv bnRyaWItMi44LjkgVGhlIHd4V2lkZ2V0cyBHVUkgdG9vbGtpdCBjb250cmlidXRlZCBsaWJy YXJpZXMKd3hndGsyLWNvbnRyaWItY29tbW9uLTIuOC45IFRoZSB3eFdpZGdldHMgR1VJIHRv b2xraXQgY29udHJpYnV0ZWQgbGlicmFyaWVzIChjb21tb24gZmlsCnd4Z3RrMi11bmljb2Rl LTIuOC45IFRoZSB3eFdpZGdldHMgR1VJIHRvb2xraXQgKFVuaWNvZGUpCnd4Z3RrMi11bmlj b2RlLWNvbnRyaWItMi44LjkgVGhlIHd4V2lkZ2V0cyBHVUkgdG9vbGtpdCBjb250cmlidXRl ZCBsaWJyYXJpZXMgKFVuaWNvZGUpCngxMXBlcmYtMS41ICAgICAgICAgWDExIHNlcnZlciBw ZXJmb3JtYW5jZSB0ZXN0IHByb2dyYW0KeDI2NC0wLjAuMjAwODA0MDlfMiBNdWx0aW1lZGlh IGxpYnJhcnkgYW5kIHRvb2wgZm9yIGVuY29kaW5nIEguMjY0L0FWQyB2aWRlbyBzdAp4YXV0 aC0xLjAuMyAgICAgICAgIFggYXV0aG9yaXR5IGZpbGUgdXRpbGl0eQp4YmFja2xpZ2h0LTEu MSAgICAgIFByb2dyYW0gdG8gYWRqdXN0IGJhY2tsaWdodCBicmlnaHRuZXNzCnhiaWZmLTEu MC4xXzEgICAgICAgTWFpbGJveCBmbGFnIGZvciBYCnhiaW5ka2V5cy0xLjguMyAgICAgQWxs b3dzIHlvdSB0byBsYXVuY2ggc2hlbGwgY29tbWFuZHMgdW5kZXIgWCB3aXRoIHlvdXIga2V5 Ym8KeGJpbmRrZXlzX2NvbmZpZy0wLjEuM182IEFuIGVhc3kgdG8gdXNlIGd0ayBwcm9ncmFt IGZvciBjb25maWd1cmluZyBYYmluZGtleXMKeGJpdG1hcHMtMS4wLjEgICAgICBYLk9yZyBi aXRtYXBzIGRhdGEKeGNhbGMtMS4wLjJfMSAgICAgICBTY2llbnRpZmljIGNhbGN1bGF0b3Ig Zm9yIFgKeGNiLXByb3RvLTEuMyAgICAgICBUaGUgWCBwcm90b2NvbCBDLWxhbmd1YWdlIEJp bmRpbmcgKFhDQikgcHJvdG9jb2wKeGNiLXV0aWwtMC4zLjIgICAgICBBIG1vZHVsZSB3aXRo IGxpYnhjYi9saWJYMTEgZXh0ZW5zaW9uL3JlcGxhY2VtZW50IGxpYnJhcmllcwp4Y2xpcGJv YXJkLTEuMC4xXzEgIFggY2xpcGJvYXJkIGNsaWVudAp4Y2xvY2stMS4wLjNfMSAgICAgIEFu YWxvZyBhbmQgZGlnaXRhbCBjbG9jayBmb3IgWAp4Y21pc2Nwcm90by0xLjEuMiAgIFhDTWlz YyBleHRlbnNpb24gaGVhZGVycwp4Y21zZGItMS4wLjEgICAgICAgIERldmljZSBDb2xvciBD aGFyYWN0ZXJpemF0aW9uIHV0aWxpdHkgZm9yIFgKeGNvbnNvbGUtMS4wLjNfMSAgICBNb25p dG9yIHN5c3RlbSBjb25zb2xlIG1lc3NhZ2VzIHdpdGggWAp4Y3Vyc29yLXRoZW1lcy0xLjAu MV8xIFgub3JnIGN1cnNvcnMgdGhlbWVzCnhjdXJzb3JnZW4tMS4wLjIgICAgQ3JlYXRlIGFu IFggY3Vyc29yIGZpbGUgZnJvbSBhIGNvbGxlY3Rpb24gb2YgUE5HIGltYWdlcwp4ZGJlZGl6 enktMS4wLjIgICAgIERlbW8gb2YgREJFIGNyZWF0aW5nIGEgZG91YmxlIGJ1ZmZlcmVkIHNw aW5uaW5nIHNjZW5lCnhkaXR2aWV3LTEuMC4xXzEgICAgRGlzcGxheSBkaXRyb2ZmIG91dHB1 dAp4ZG0tMS4xLjhfMSAgICAgICAgIFguT3JnIFggZGlzcGxheSBtYW5hZ2VyCnhkcHlpbmZv LTEuMC4zICAgICAgRGlzcGxheSBpbmZvcm1hdGlvbiB1dGlsaXR5IGZvciBYCnhkcmlpbmZv LTEuMC4yICAgICAgUXVlcnkgY29uZmlndXJhdGlvbiBpbmZvcm1hdGlvbiBvZiBEUkkgZHJp dmVycwp4ZWRpdC0xLjEuMiAgICAgICAgIFNpbXBsZSB0ZXh0IGVkaXRvciBmb3IgWAp4ZXYt MS4wLjMgICAgICAgICAgIFByaW50IGNvbnRlbnRzIG9mIFggZXZlbnRzCnhleHRwcm90by03 LjAuNSAgICAgWEV4dCBleHRlbnNpb24gaGVhZGVycwp4ZXllcy0xLjAuMSAgICAgICAgIEEg Zm9sbG93IHRoZSBtb3VzZSBYIGRlbW8KeGY4Ni1pbnB1dC1rZXlib2FyZC0xLjMuMiBYLk9y ZyBrZXlib2FyZCBpbnB1dCBkcml2ZXIKeGY4Ni1pbnB1dC1tb3VzZS0xLjQuMF8xIFguT3Jn IG1vdXNlIGlucHV0IGRyaXZlcgp4Zjg2LXZpZGVvLWludGVsLTIuNS4xIERyaXZlciBmb3Ig SW50ZWwgaW50ZWdyYXRlZCBncmFwaGljcyBjaGlwc2V0cwp4Zjg2YmlnZm9udHByb3RvLTEu MS4yIFhGcmVlODYtQmlnZm9udCBleHRlbnNpb24gaGVhZGVycwp4Zjg2ZGdhLTEuMC4yXzEg ICAgIFRlc3QgcHJvZ3JhbSBmb3IgdGhlIFhGcmVlODYtREdBIGV4dGVuc2lvbgp4Zjg2ZGdh cHJvdG8tMi4wLjMgIFhGcmVlODYtREdBIGV4dGVuc2lvbiBoZWFkZXJzCnhmODZkcmlwcm90 by0yLjAuNCAgWEZyZWU4Ni1EUkkgZXh0ZW5zaW9uIGhlYWRlcnMKeGY4Nm1pc2Nwcm90by0w LjkuMiBYRnJlZTg2LU1pc2MgZXh0ZW5zaW9uIGhlYWRlcnMKeGY4NnJ1c2hwcm90by0xLjEu MiBYRnJlZTg2LVJ1c2ggZXh0ZW5zaW9uIGhlYWRlcnMKeGY4NnZpZG1vZGVwcm90by0yLjIu MiBYRnJlZTg2LVZpZE1vZGVFeHRlbnNpb24gZXh0ZW5zaW9uIGhlYWRlcnMKeGZkLTEuMC4x XzEgICAgICAgICBEaXNwbGF5IGFsbCBjaGFyYWN0ZXJzIGluIGFuIFggZm9udAp4ZmluZHBy b3h5LTEuMC4xICAgIExvY2F0ZSBhdmFpbGFibGUgcHJveHkgc2VydmljZXMKeGZvbnRzZWwt MS4wLjJfMSAgICBQb2ludCBhbmQgY2xpY2sgc2VsZWN0aW9uIG9mIFgxMSBmb250IG5hbWVz Cnhmcy0xLjAuOF8xLDEgICAgICAgWC5PcmcgZm9udCBzZXJ2ZXIKeGZzaW5mby0xLjAuMiAg ICAgICBYIGZvbnQgc2VydmVyIGluZm9ybWF0aW9uIHV0aWxpdHkKeGZ3cC0xLjAuMSAgICAg ICAgICBYIGZpcmV3YWxsIHByb3h5CnhnYW1tYS0xLjAuMiAgICAgICAgR2FtbWEgY29ycmVj dGlvbiB0aHJvdWdoIHRoZSBYIHNlcnZlci4KeGdjLTEuMC4xXzEgICAgICAgICBYIGdyYXBo aWNzIGRlbW8KeGhvc3QtMS4wLjIgICAgICAgICBTZXJ2ZXIgYWNjZXNzIGNvbnRyb2wgcHJv Z3JhbSBmb3IgWAp4aW5lLTAuOTkuNV8zICAgICAgIEFuIFgxMSBtdWx0aW1lZGlhIHBsYXll cgp4aW5lcmFtYXByb3RvLTEuMS4yIFhpbmVyYW1hIGV4dGVuc2lvbiBoZWFkZXJzCnhpbml0 LTEuMS4xICAgICAgICAgWCBXaW5kb3cgU3lzdGVtIGluaXRpYWxpemVyCnhrYmNvbXAtMS4w LjUgICAgICAgQ29tcGlsZSBYS0Iga2V5Ym9hcmQgZGVzY3JpcHRpb24KeGtiZXZkLTEuMC4y ICAgICAgICBYS0IgZXZlbnQgZGFlbW9uCnhrYnByaW50LTEuMC4xICAgICAgVXRpbGl0eSBm b3IgcHJpbnRpbmcgYW4gWEtCIGtleWJvYXJkIGRlc2NyaXB0aW9uCnhrYnV0aWxzLTEuMC4x XzIgICAgWEtCIHV0aWxpdHkgZGVtb3MKeGtleWJvYXJkLWNvbmZpZy0xLjQgWCBLZXlib2Fy ZCBDb25maWd1cmF0aW9uIERhdGFiYXNlCnhraWxsLTEuMC4xICAgICAgICAgVXRpbGl0eSBm b3Iga2lsbGluZyBhIGNsaWVudCBieSBpdHMgWCByZXNvdXJjZQp4bG9hZC0xLjAuMl8xICAg ICAgIFN5c3RlbSBsb2FkIGF2ZXJhZ2UgZGlzcGxheSBmb3IgWAp4bG9nby0xLjAuMV8xICAg ICAgIERpc3BsYXlzIHRoZSBYIFdpbmRvdyBTeXN0ZW0gbG9nby4KeGxzYXRvbXMtMS4wLjEg ICAgICBMaXN0IGludGVybmVkIGF0b21zIGRlZmluZWQgb24gYSBzZXJ2ZXIKeGxzY2xpZW50 cy0xLjAuMSAgICBMaXN0IGNsaWVudCBhcHBsaWNhdGlvbnMgcnVubmluZyBvbiBhIGRpc3Bs YXkKeGxzZm9udHMtMS4wLjIgICAgICBTZXJ2ZXIgZm9udCBsaXN0IGRpc3BsYXllciBmb3Ig WAp4bWFnLTEuMC4yXzEgICAgICAgIFggYXBwbGljYXRpb24gZm9yIHNjcmVlbiBtYWduaWZ5 aW5nCnhtYW4tMS4wLjNfMSAgICAgICAgTWFudWFsIHBhZ2UgZGlzcGxheSBwcm9ncmFtIGZv ciBYCnhtZXNzYWdlLTEuMC4yXzEgICAgRGlzcGxheSBtZXNzYWdlIG9yIHF1ZXJ5IGluIGEg WCB3aW5kb3cKeG1sY2F0bWdyLTIuMiAgICAgICBTR01MIGFuZCBYTUwgY2F0YWxvZyBtYW5h Z2VyCnhtbGNoYXJlbnQtMC4zXzIgICAgWE1MIGNoYXJhY3RlciBlbnRpdGllcwp4bWxycGMt Yy1kZXZlbC0xLjExLjAwXzMgWE1MLVJQQyBsaWJyYXJ5IGZvciBDIGFuZCBDKysKeG1vZG1h cC0xLjAuMyAgICAgICBVdGlsaXR5IGZvciBtb2RpZnlpbmcga2V5bWFwcyBhbmQgcG9pbnRl ciBidXR0b24gbWFwcGluZ3MgaQp4bW9yZS0xLjAuMV8xICAgICAgIFBsYWluIHRleHQgZGlz cGxheSBwcm9ncmFtIGZvciBYCnhvcmctNy40ICAgICAgICAgICAgWC5PcmcgY29tcGxldGUg ZGlzdHJpYnV0aW9uIG1ldGFwb3J0CnhvcmctYXBwcy03LjRfMSAgICAgWC5vcmcgYXBwcyBt ZXRhLXBvcnQKeG9yZy1jZi1maWxlcy0xLjAuMl8zIFgub3JnIGNmIGZpbGVzIGZvciB1c2Ug d2l0aCBpbWFrZSBidWlsZHMKeG9yZy1kb2NzLTEuNCwxICAgICBYLm9yZyBkb2N1bWVudGF0 aW9uIGZpbGVzCnhvcmctZHJpdmVycy03LjQgICAgWC5vcmcgZHJpdmVycyBtZXRhLXBvcnQK eG9yZy1mb250cy0xMDBkcGktNy40IFguT3JnIDEwMGRwaSBiaXRtYXAgZm9udHMKeG9yZy1m b250cy03LjQgICAgICBYLm9yZyBmb250cyBtZXRhLXBvcnQKeG9yZy1mb250cy03NWRwaS03 LjQgWC5PcmcgNzVkcGkgYml0bWFwIGZvbnRzCnhvcmctZm9udHMtY3lyaWxsaWMtNy40IFgu T3JnIEN5cmlsbGljIGJpdG1hcCBmb250cwp4b3JnLWZvbnRzLW1pc2NiaXRtYXBzLTcuNCBY Lk9yZyBtaXNjZWxsYW5lb3VzIGJpdG1hcCBmb250cwp4b3JnLWZvbnRzLXRydWV0eXBlLTcu NCBYLk9yZyBUcnVlVHlwZSBmb250cwp4b3JnLWZvbnRzLXR5cGUxLTcuNCBYLk9yZyBUeXBl MSBmb250cwp4b3JnLWxpYnJhcmllcy03LjQgIFgub3JnIGxpYnJhcmllcyBtZXRhLXBvcnQK eG9yZy1zZXJ2ZXItMS41LjNfMiwxIFguT3JnIFggc2VydmVyIGFuZCByZWxhdGVkIHByb2dy YW1zCnhwaS1xdWljay1sb2NhbGUtc3dpdGNoZXItMS42LjUuMSBRdWlja2x5IGNoYW5nZSBh bmQgYXBwbHkgYSBkaWZmZXJlbnQgbG9jYWxlIGZyb20gdGhlIHRvb2xzIAp4cGkteHBjb20t Y29tcG9uZW50LXZpZXdlci0wLjcuMCBYUENPTSBDb21wb25lbnQgVmlld2VyCnhwbHNwcmlu dGVycy0xLjAuMSAgU2hvd3MgYSBsaXN0IG9mIFhwcmludCBwcmludGVycwp4cHItMS4wLjIg ICAgICAgICAgIFV0aWxpdHkgZm9yIHByaW50aW5nIGFuIFggd2luZG93IGR1bXAKeHByZWhh c2hwcmludGVybGlzdC0xLjAuMSBSZWNvbXB1dGVzIHRoZSBsaXN0IG9mIGF2YWlsYWJsZSBw cmludGVycy4KeHByb3AtMS4wLjQgICAgICAgICBQcm9wZXJ0eSBkaXNwbGF5ZXIgZm9yIFgK eHByb3RvLTcuMC4xNCAgICAgICBYMTEgcHJvdG9jb2wgaGVhZGVycwp4cHJveHltYW5hZ2Vt ZW50cHJvdG9jb2wtMS4wLjIgWCBQcm94eSBNYW5hZ2VtZW50IFByb3RvY29sIGhlYWRlcnMK eHJhbmRyLTEuMi4zICAgICAgICBQcmltaXRpdmUgY29tbWFuZCBsaW5lIGludGVyZmFjZSB0 byB0aGUgUmFuZFIgZXh0ZW5zaW9uCnhyZGItMS4wLjUgICAgICAgICAgWCBzZXJ2ZXIgcmVz b3VyY2UgZGF0YWJhc2UgdXRpbGl0eQp4cmVmcmVzaC0xLjAuMiAgICAgIFJlZnJlc2ggYWxs IG9yIHBhcnQgb2YgYW4gWCBzY3JlZW4KeHJ4LTEuMC4xXzIgICAgICAgICBSWCBoZWxwZXIg cHJvZ3JhbQp4c2V0LTEuMC40ICAgICAgICAgIFVzZXIgcHJlZmVyZW5jZSB1dGlsaXR5IGZv ciBYCnhzZXRtb2RlLTEuMC4wICAgICAgU2V0IHRoZSBtb2RlIGZvciBhbiBYIElucHV0IERl dmljZQp4c2V0cG9pbnRlci0xLjAuMSAgIFNldCBhbiBYIElucHV0IGRldmljZSBhcyB0aGUg bWFpbiBwb2ludGVyCnhzZXRyb290LTEuMC4yICAgICAgcm9vdCB3aW5kb3cgcGFyYW1ldGVy IHNldHRpbmcgdXRpbGl0eSBmb3IgWAp4c20tMS4wLjFfMSAgICAgICAgIFggU2Vzc2lvbiBN YW5hZ2VyCnhzdGRjbWFwLTEuMC4xICAgICAgWCBzdGFuZGFyZCBjb2xvcm1hcCB1dGlsaXR5 Cnh0ZXJtLTIzOF8xICAgICAgICAgVGVybWluYWwgZW11bGF0b3IgZm9yIHRoZSBYIFdpbmRv dyBTeXN0ZW0KeHRyYW5zLTEuMi4zICAgICAgICBBYnN0cmFjdCBuZXR3b3JrIGNvZGUgZm9y IFgKeHRyYXAtMS4wLjIgICAgICAgICBYVHJhcCBzYW1wbGUgY2xpZW50cyBmb3IgWAp4dWxy dW5uZXItMS44LjAuNF8xNCBNb3ppbGxhIHJ1bnRpbWUgcGFja2FnZSB0aGF0IGNhbiBiZSB1 c2VkIHRvIGJvb3RzdHJhcCBYVUwrWAp4dmlkLTEuMi4xLDEgICAgICAgIEFuIG9wZW5zb3Vy Y2UgTVBFRy00IGNvZGVjLCBiYXNlZCBvbiBPcGVuRGl2eAp4dmlkY2FwLTEuMS40LnAxXzMs MSBDYXB0dXJlIHlvdXIgWCBkaXNwbGF5IHRvIGluZGl2aWR1YWwgZnJhbWVzIG9yIE1QRUcg dmlkZW8KeHZpZHR1bmUtMS4wLjFfMSAgICBWaWRlbyBtb2RlIHR1bmVyIGZvciBYCnh2aW5m by0xLjAuMiAgICAgICAgUHJpbnQgb3V0IFgtVmlkZW8gZXh0ZW5zaW9uIGFkYXB0b3IgaW5m b3JtYXRpb24KeHdkLTEuMC4yICAgICAgICAgICBEdW1wIGFuIGltYWdlIG9mIGFuIFggd2lu ZG93Cnh3aW5pbmZvLTEuMC40ICAgICAgV2luZG93IGluZm9ybWF0aW9uIHV0aWxpdHkgZm9y IFgKeHd1ZC0xLjAuMSAgICAgICAgICBJbWFnZSBkaXNwbGF5ZXIgZm9yIFgKeWFrdWFrZS1r ZGU0LTIuOS40XzIgRHJvcC1kb3duIHRlcm1pbmFsIGVtdWxhdG9yIGJhc2VkIG9uIEtERSdz IEtvbnNvbGUKeWFzbS0wLjcuMiAgICAgICAgICBBIGNvbXBsZXRlIHJld3JpdGUgb2YgdGhl IE5BU00gYXNzZW1ibGVyCnppcC0zLjAgICAgICAgICAgICAgQ3JlYXRlL3VwZGF0ZSBaSVAg ZmlsZXMgY29tcGF0aWJsZSB3aXRoIHBremlwCnp0Y2wtMS4wLmI0ICAgICAgICAgQSB6bGli IGV4dGVuc2lvbiBsaWJyYXJ5IGZvciB0aGUgVGNsCg== --------------080002040604030602090705 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="dmesg.txt" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDkgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0 IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAx OTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlh LiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1h cmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCA4LjAtQ1VSUkVOVCAjMSBy MTg4NjAzOiBTYXQgRmViIDE0IDE3OjUzOjI5IEtSQVQgMjAwOQogICAgemxvaWFkbWluQHNz LnN1Oi9ob21lL3JlcG9zaXRvcnkvb2JqL2hvbWUvcmVwb3NpdG9yeS9zcmMvc3lzL3psMApU aW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMApDUFU6 IEludGVsKFIpIFBlbnRpdW0oUikgTSBwcm9jZXNzb3IgMS41MEdIeiAoMTQ5Ni4yNi1NSHog Njg2LWNsYXNzIENQVSkKICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweDZkOCAg U3RlcHBpbmcgPSA4CiAgRmVhdHVyZXM9MHhhZmU5ZmJmZjxGUFUsVk1FLERFLFBTRSxUU0Ms TVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxDTEZMVVNI LERUUyxBQ1BJLE1NWCxGWFNSLFNTRSxTU0UyLFNTLFRNLFBCRT4KICBGZWF0dXJlczI9MHgx ODA8RVNULFRNMj4KcmVhbCBtZW1vcnkgID0gMjExMjc0OTU2OCAoMjAxNCBNQikKYXZhaWwg bWVtb3J5ID0gMjA2MDEyNDE2MCAoMTk2NCBNQikKQUNQSSBBUElDIFRhYmxlOiA8SFAgICAg IDA5QjggICAgPgppb2FwaWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9uIG1vdGhlcmJv YXJkCmtiZDEgYXQga2JkbXV4MApjcnlwdG9zb2Z0MDogPHNvZnR3YXJlIGNyeXB0bz4gb24g bW90aGVyYm9hcmQKYWNwaTA6IDxIUCAwOUI4PiBvbiBtb3RoZXJib2FyZAphY3BpMDogW0lU SFJFQURdCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQpUaW1lY291bnRlciAiQUNQSS1m YXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDEwMDAKYWNwaV90aW1lcjA6IDwy NC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHgxMDA4LTB4MTAwYiBvbiBhY3Bp MAphY3BpX2VjMDogPEVtYmVkZGVkIENvbnRyb2xsZXI6IEdQRSAweDFkPiBwb3J0IDB4NjIs MHg2NiBvbiBhY3BpMAphY3BpX2hwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGltZXI+ IGlvbWVtIDAtMHgzZmYgb24gYWNwaTAKZGV2aWNlX2F0dGFjaDogYWNwaV9ocGV0MCBhdHRh Y2ggcmV0dXJuZWQgMTIKYWNwaV9hY2FkMDogPEFDIEFkYXB0ZXI+IG9uIGFjcGkwCmJhdHRl cnkwOiA8QUNQSSBDb250cm9sIE1ldGhvZCBCYXR0ZXJ5PiBvbiBhY3BpMAphY3BpX2xpZDA6 IDxDb250cm9sIE1ldGhvZCBMaWQgU3dpdGNoPiBvbiBhY3BpMAphY3BpX2J1dHRvbjA6IDxT bGVlcCBCdXR0b24+IG9uIGFjcGkwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBv cnQgMHhjZjgtMHhjZmYgb24gYWNwaTAKcGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjAK cGNpMDogPGJhc2UgcGVyaXBoZXJhbD4gYXQgZGV2aWNlIDAuMSAobm8gZHJpdmVyIGF0dGFj aGVkKQpwY2kwOiA8YmFzZSBwZXJpcGhlcmFsPiBhdCBkZXZpY2UgMC4zIChubyBkcml2ZXIg YXR0YWNoZWQpCnZnYXBjaTA6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5PiBwb3J0IDB4MTgw MC0weDE4MDcgbWVtIDB4ZTgwMDAwMDAtMHhlZmZmZmZmZiwweGUwMDAwMDAwLTB4ZTAwN2Zm ZmYgaXJxIDE2IGF0IGRldmljZSAyLjAgb24gcGNpMAphZ3AwOiA8SW50ZWwgODI4NXhNICg4 NXhHTSBHTUNIKSBTVkdBIGNvbnRyb2xsZXI+IG9uIHZnYXBjaTAKYWdwMDogZGV0ZWN0ZWQg MzI2MzZrIHN0b2xlbiBtZW1vcnkKYWdwMDogYXBlcnR1cmUgc2l6ZSBpcyAxMjhNCmRybTA6 IDxJbnRlbCBpODUyR00vaTg1NUdNIEdNQ0g+IG9uIHZnYXBjaTAKdmdhcGNpMDogY2hpbGQg ZHJtMCByZXF1ZXN0ZWQgcGNpX2VuYWJsZV9idXNtYXN0ZXIKaW5mbzogW2RybV0gQUdQIGF0 IDB4ZTgwMDAwMDAgMTI4TUIKaW5mbzogW2RybV0gSW5pdGlhbGl6ZWQgaTkxNSAxLjYuMCAy MDA4MDczMAp2Z2FwY2kxOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gbWVtIDB4ZjAwMDAw MDAtMHhmN2ZmZmZmZiwweGUwMDgwMDAwLTB4ZTAwZmZmZmYgYXQgZGV2aWNlIDIuMSBvbiBw Y2kwCnVoY2kwOiA8SW50ZWwgODI4MDFEQiAoSUNINCkgVVNCIGNvbnRyb2xsZXIgVVNCLUE+ IHBvcnQgMHgxODIwLTB4MTgzZiBpcnEgMTYgYXQgZGV2aWNlIDI5LjAgb24gcGNpMAp1aGNp MDogW0dJQU5ULUxPQ0tFRF0KdWhjaTA6IFtJVEhSRUFEXQp1c2IwOiA8SW50ZWwgODI4MDFE QiAoSUNINCkgVVNCIGNvbnRyb2xsZXIgVVNCLUE+IG9uIHVoY2kwCnVzYjA6IFVTQiByZXZp c2lvbiAxLjAKdWh1YjA6IDxJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAx LjAwLzEuMDAsIGFkZHIgMT4gb24gdXNiMAp1aHViMDogMiBwb3J0cyB3aXRoIDIgcmVtb3Zh YmxlLCBzZWxmIHBvd2VyZWQKdWhjaTE6IDxJbnRlbCA4MjgwMURCIChJQ0g0KSBVU0IgY29u dHJvbGxlciBVU0ItQj4gcG9ydCAweDE4NDAtMHgxODVmIGlycSAxOSBhdCBkZXZpY2UgMjku MSBvbiBwY2kwCnVoY2kxOiBbR0lBTlQtTE9DS0VEXQp1aGNpMTogW0lUSFJFQURdCnVzYjE6 IDxJbnRlbCA4MjgwMURCIChJQ0g0KSBVU0IgY29udHJvbGxlciBVU0ItQj4gb24gdWhjaTEK dXNiMTogVVNCIHJldmlzaW9uIDEuMAp1aHViMTogPEludGVsIFVIQ0kgcm9vdCBodWIsIGNs YXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IxCnVodWIxOiAyIHBvcnRz IHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1aGNpMjogPEludGVsIDgyODAxREIg KElDSDQpIFVTQiBjb250cm9sbGVyIFVTQi1DPiBwb3J0IDB4MTg2MC0weDE4N2YgaXJxIDE4 IGF0IGRldmljZSAyOS4yIG9uIHBjaTAKdWhjaTI6IFtHSUFOVC1MT0NLRURdCnVoY2kyOiBb SVRIUkVBRF0KdXNiMjogPEludGVsIDgyODAxREIgKElDSDQpIFVTQiBjb250cm9sbGVyIFVT Qi1DPiBvbiB1aGNpMgp1c2IyOiBVU0IgcmV2aXNpb24gMS4wCnVodWIyOiA8SW50ZWwgVUhD SSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjIK dWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCmVoY2kwOiA8 SW50ZWwgODI4MDFEQi9ML00gKElDSDQpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZTAx MDAwMDAtMHhlMDEwMDNmZiBpcnEgMjMgYXQgZGV2aWNlIDI5Ljcgb24gcGNpMAplaGNpMDog W0dJQU5ULUxPQ0tFRF0KZWhjaTA6IFtJVEhSRUFEXQp1c2IzOiBFSENJIHZlcnNpb24gMS4w CnVzYjM6IGNvbXBhbmlvbiBjb250cm9sbGVycywgMiBwb3J0cyBlYWNoOiB1c2IwIHVzYjEg dXNiMgp1c2IzOiA8SW50ZWwgODI4MDFEQi9ML00gKElDSDQpIFVTQiAyLjAgY29udHJvbGxl cj4gb24gZWhjaTAKdXNiMzogVVNCIHJldmlzaW9uIDIuMAp1aHViMzogPEludGVsIEVIQ0kg cm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IzCnVo dWIzOiA2IHBvcnRzIHdpdGggNiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZApwY2liMTogPEFD UEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAzMC4wIG9uIHBjaTAKcGNpMjogPEFDUEkg UENJIGJ1cz4gb24gcGNpYjEKcmwwOiA8UmVhbFRlayA4MTM5IDEwLzEwMEJhc2VUWD4gcG9y dCAweDMwMDAtMHgzMGZmIG1lbSAweGUwMjA3ODAwLTB4ZTAyMDc4ZmYgaXJxIDE2IGF0IGRl dmljZSAwLjAgb24gcGNpMgptaWlidXMwOiA8TUlJIGJ1cz4gb24gcmwwCnJscGh5MDogPFJl YWxUZWsgaW50ZXJuYWwgbWVkaWEgaW50ZXJmYWNlPiBQSFkgMCBvbiBtaWlidXMwCnJscGh5 MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIGF1 dG8KcmwwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMDpjMDo5Zjo2Yjo3YjpkYQpybDA6IFtJVEhS RUFEXQppd2kwOiA8SW50ZWwoUikgUFJPL1dpcmVsZXNzIDIyMDBCRz4gbWVtIDB4ZTAyMDYw MDAtMHhlMDIwNmZmZiBpcnEgMTggYXQgZGV2aWNlIDYuMCBvbiBwY2kyCml3aTA6IFtJVEhS RUFEXQpjYmIwOiA8VEk2NDExIFBDSS1DYXJkQnVzIEJyaWRnZT4gYXQgZGV2aWNlIDkuMCBv biBwY2kyCmNhcmRidXMwOiA8Q2FyZEJ1cyBidXM+IG9uIGNiYjAKcGNjYXJkMDogPDE2LWJp dCBQQ0NhcmQgYnVzPiBvbiBjYmIwCmNiYjA6IFtGSUxURVJdCmZ3b2hjaTA6IDwxMzk0IE9w ZW4gSG9zdCBDb250cm9sbGVyIEludGVyZmFjZT4gbWVtIDB4ZTAyMDcwMDAtMHhlMDIwNzdm ZiwweGUwMjAwMDAwLTB4ZTAyMDNmZmYgaXJxIDIyIGF0IGRldmljZSA5LjIgb24gcGNpMgpm d29oY2kwOiBbSVRIUkVBRF0KZndvaGNpMDogT0hDSSB2ZXJzaW9uIDEuMTAgKFJPTT0xKQpm d29oY2kwOiBOby4gb2YgSXNvY2hyb25vdXMgY2hhbm5lbHMgaXMgNC4KZndvaGNpMDogRVVJ NjQgMDA6YzA6OWY6MDA6MDA6MzI6YWM6MGMKZndvaGNpMDogUGh5IDEzOTRhIGF2YWlsYWJs ZSBTNDAwLCAyIHBvcnRzLgpmd29oY2kwOiBMaW5rIFM0MDAsIG1heF9yZWMgMjA0OCBieXRl cy4KZmlyZXdpcmUwOiA8SUVFRTEzOTQoRmlyZVdpcmUpIGJ1cz4gb24gZndvaGNpMApmd2lw MDogPElQIG92ZXIgRmlyZVdpcmU+IG9uIGZpcmV3aXJlMApmd2lwMDogRmlyZXdpcmUgYWRk cmVzczogMDA6YzA6OWY6MDA6MDA6MzI6YWM6MGMgQCAweGZmZmUwMDAwMDAwMCwgUzQwMCwg bWF4cmVjIDIwNDgKc2JwMDogPFNCUC0yL1NDU0kgb3ZlciBGaXJlV2lyZT4gb24gZmlyZXdp cmUwCmRjb25zX2Nyb20wOiA8ZGNvbnMgY29uZmlndXJhdGlvbiBST00+IG9uIGZpcmV3aXJl MApkY29uc19jcm9tMDogYnVzX2FkZHIgMHgxMGE0MDAwCmZ3ZTA6IDxFdGhlcm5ldCBvdmVy IEZpcmVXaXJlPiBvbiBmaXJld2lyZTAKaWZfZndlMDogRmFrZSBFdGhlcm5ldCBhZGRyZXNz OiAwMjpjMDo5ZjozMjphYzowYwpmd2UwOiBFdGhlcm5ldCBhZGRyZXNzOiAwMjpjMDo5Zjoz MjphYzowYwpmd29oY2kwOiBJbml0aWF0ZSBidXMgcmVzZXQKZndvaGNpMDogZndvaGNpX2lu dHJfY29yZTogQlVTIHJlc2V0CmZ3b2hjaTA6IGZ3b2hjaV9pbnRyX2NvcmU6IG5vZGVfaWQ9 MHgwMDAwMDAwMCwgU2VsZklEIENvdW50PTIsIENZQ0xFTUFTVEVSIG1vZGUKcGNpMjogPG1h c3Mgc3RvcmFnZT4gYXQgZGV2aWNlIDkuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kyOiA8 YmFzZSBwZXJpcGhlcmFsLCBTRCBob3N0IGNvbnRyb2xsZXI+IGF0IGRldmljZSA5LjQgKG5v IGRyaXZlciBhdHRhY2hlZCkKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDMx LjAgb24gcGNpMAppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjAKYXRhcGNpMDogPEludGVsIElD SDQgVURNQTEwMCBjb250cm9sbGVyPiBwb3J0IDB4MWYwLTB4MWY3LDB4M2Y2LDB4MTcwLTB4 MTc3LDB4Mzc2LDB4MTgxMC0weDE4MWYgYXQgZGV2aWNlIDMxLjEgb24gcGNpMAphdGEwOiA8 QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMAphdGEwOiBbSVRIUkVBRF0KYXRhMTogPEFUQSBj aGFubmVsIDE+IG9uIGF0YXBjaTAKYXRhMTogW0lUSFJFQURdCmljaHNtYjA6IDxJbnRlbCA4 MjgwMURDIChJQ0g0KSBTTUJ1cyBjb250cm9sbGVyPiBwb3J0IDB4MTg4MC0weDE4OWYgaXJx IDE3IGF0IGRldmljZSAzMS4zIG9uIHBjaTAKaWNoc21iMDogW0lUSFJFQURdCnNtYnVzMDog PFN5c3RlbSBNYW5hZ2VtZW50IEJ1cz4gb24gaWNoc21iMApzbWIwOiA8U01CdXMgZ2VuZXJp YyBJL08+IG9uIHNtYnVzMApwY20wOiA8SW50ZWwgSUNINCAoODI4MDFEQik+IHBvcnQgMHgx YzAwLTB4MWNmZiwweDE4YzAtMHgxOGZmIG1lbSAweGUwMTAwYzAwLTB4ZTAxMDBkZmYsMHhl MDEwMDgwMC0weGUwMTAwOGZmIGlycSAxNyBhdCBkZXZpY2UgMzEuNSBvbiBwY2kwCnBjbTA6 IFtJVEhSRUFEXQpwY20wOiA8Q29uZXhhbnQgQ1gyMDQ2OC0yMSBBQzk3IENvZGVjPgpwY2kw OiA8c2ltcGxlIGNvbW1zLCBnZW5lcmljIG1vZGVtPiBhdCBkZXZpY2UgMzEuNiAobm8gZHJp dmVyIGF0dGFjaGVkKQphY3BpX3R6MDogPFRoZXJtYWwgWm9uZT4gb24gYWNwaTAKYXRydGMw OiA8QVQgcmVhbHRpbWUgY2xvY2s+IHBvcnQgMHg3MC0weDc3IGlycSA4IG9uIGFjcGkwCmF0 a2JkYzA6IDxLZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IHBvcnQgMHg2MCwweDY0IGly cSAxIG9uIGFjcGkwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwCmti ZDAgYXQgYXRrYmQwCmF0a2JkMDogW0dJQU5ULUxPQ0tFRF0KYXRrYmQwOiBbSVRIUkVBRF0K cHNtMDogPFBTLzIgTW91c2U+IGlycSAxMiBvbiBhdGtiZGMwCnBzbTA6IFtHSUFOVC1MT0NL RURdCnBzbTA6IFtJVEhSRUFEXQpwc20wOiBtb2RlbCBJbnRlbGxpTW91c2UsIGRldmljZSBJ RCAzCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTAKZXN0MDogPEVuaGFuY2VkIFNwZWVkU3Rl cCBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MApwNHRjYzA6IDxDUFUgRnJlcXVlbmN5IFRo ZXJtYWwgQ29udHJvbD4gb24gY3B1MAphY3BpX2hwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZl bnQgVGltZXI+IGlvbWVtIDAtMHgzZmYgb24gYWNwaTAKZGV2aWNlX2F0dGFjaDogYWNwaV9o cGV0MCBhdHRhY2ggcmV0dXJuZWQgMTIKcG10aW1lcjAgb24gaXNhMApvcm0wOiA8SVNBIE9w dGlvbiBST01zPiBhdCBpb21lbSAweGNkMDAwLTB4Y2RmZmYsMHhkZjAwMC0weGRmZmZmLDB4 ZTAwMDAtMHhlM2ZmZiBwbnBpZCBPUk0wMDAwIG9uIGlzYTAKc2MwOiA8U3lzdGVtIGNvbnNv bGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZpcnR1YWwgY29uc29s ZXMsIGZsYWdzPTB4MzAwPgp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBhdCBwb3J0IDB4M2Mw LTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwClRpbWVjb3VudGVyICJUU0Mi IGZyZXF1ZW5jeSAxNDk2MjU2MDE2IEh6IHF1YWxpdHkgODAwClRpbWVjb3VudGVycyB0aWNr IGV2ZXJ5IDEuMDAwIG1zZWMKZmlyZXdpcmUwOiAxIG5vZGVzLCBtYXhob3AgPD0gMCwgY2Fi bGUgSVJNID0gMCAobWUpCmZpcmV3aXJlMDogYnVzIG1hbmFnZXIgMCAobWUpCmZ3b2hjaTA6 IHBoeSBpbnQKYWQwOiA1NzIzMU1CIDxUT1NISUJBIE1LNjAyNUdBUyBLQTIwMUE+IGF0IGF0 YTAtbWFzdGVyIFVETUExMDAKR0VPTTogYWQwczE6IGdlb21ldHJ5IGRvZXMgbm90IG1hdGNo IGxhYmVsICgyNTVoLDYzcyAhPSAxNmgsNjNzKS4KR0VPTTogYWQwczI6IGdlb21ldHJ5IGRv ZXMgbm90IG1hdGNoIGxhYmVsICgyNTVoLDYzcyAhPSAxNmgsNjNzKS4KYWNkMDogRFZEUiA8 TkVDIERWRCsvLVJXIE5ELTY0NTBBLzIuMzY+IGF0IGF0YTEtbWFzdGVyIFBJTzQKVHJ5aW5n IHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9hZDBzMWEKd2xhbjA6IGJwZiBhdHRhY2hl ZAp3bGFuMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MGU6MzU6YjA6MzE6YmQKd2xhbjA6IGJw ZiBhdHRhY2hlZAppd2kwOiBuZWVkIG11bHRpY2FzdCB1cGRhdGUgY2FsbGJhY2sKaXdpMDog bmVlZCBtdWx0aWNhc3QgdXBkYXRlIGNhbGxiYWNrCml3aTA6IG5lZWQgbXVsdGljYXN0IHVw ZGF0ZSBjYWxsYmFjawp0c190b19jdCgxMjM0NzY4MDkxLjUxNTg1MTExNykgPSBbMjAwOS0w Mi0xNiAwNzowODoxMV0KZnVzZTRic2Q6IHZlcnNpb24gMC4zLjktcHJlMSwgRlVTRSBBQkkg Ny44CmRybTA6IFtNUFNBRkVdCmRybTA6IFtJVEhSRUFEXQo= --------------080002040604030602090705 Content-Type: text/plain; name="Xorg.0.log.old" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="Xorg.0.log.old" ClguT3JnIFggU2VydmVyIDEuNS4zClJlbGVhc2UgRGF0ZTogNSBOb3ZlbWJlciAyMDA4Clgg UHJvdG9jb2wgVmVyc2lvbiAxMSwgUmV2aXNpb24gMApCdWlsZCBPcGVyYXRpbmcgU3lzdGVt OiBGcmVlQlNEIDguMC1DVVJSRU5UIGkzODYgCkN1cnJlbnQgT3BlcmF0aW5nIFN5c3RlbTog RnJlZUJTRCBzcy5zdSA4LjAtQ1VSUkVOVCBGcmVlQlNEIDguMC1DVVJSRU5UICMxIHIxODg2 MDM6IFNhdCBGZWIgMTQgMTc6NTM6MjkgS1JBVCAyMDA5ICAgICB6bG9pYWRtaW5Ac3Muc3U6 L2hvbWUvcmVwb3NpdG9yeS9vYmovaG9tZS9yZXBvc2l0b3J5L3NyYy9zeXMvemwwIGkzODYK QnVpbGQgRGF0ZTogMDIgRmVicnVhcnkgMjAwOSAgMDk6Mzk6MjZQTQogCglCZWZvcmUgcmVw b3J0aW5nIHByb2JsZW1zLCBjaGVjayBodHRwOi8vd2lraS54Lm9yZwoJdG8gbWFrZSBzdXJl IHRoYXQgeW91IGhhdmUgdGhlIGxhdGVzdCB2ZXJzaW9uLgpNYXJrZXJzOiAoLS0pIHByb2Jl ZCwgKCoqKSBmcm9tIGNvbmZpZyBmaWxlLCAoPT0pIGRlZmF1bHQgc2V0dGluZywKCSgrKykg ZnJvbSBjb21tYW5kIGxpbmUsICghISkgbm90aWNlLCAoSUkpIGluZm9ybWF0aW9uYWwsCgko V1cpIHdhcm5pbmcsIChFRSkgZXJyb3IsIChOSSkgbm90IGltcGxlbWVudGVkLCAoPz8pIHVu a25vd24uCig9PSkgTG9nIGZpbGU6ICIvdmFyL2xvZy9Yb3JnLjAubG9nIiwgVGltZTogTW9u IEZlYiAxNiAxMzoxNDoyMCAyMDA5Cig9PSkgVXNpbmcgY29uZmlnIGZpbGU6ICIvZXRjL1gx MS94b3JnLmNvbmYiCig9PSkgU2VydmVyTGF5b3V0ICJYLm9yZyBDb25maWd1cmVkIgooKiop IHwtLT5TY3JlZW4gIlNjcmVlbjAiICgwKQooKiopIHwgICB8LS0+TW9uaXRvciAiTW9uaXRv cjAiCigqKikgfCAgIHwtLT5EZXZpY2UgIkNhcmQwIgooKiopIE9wdGlvbiAiQUlHTFgiICJ0 cnVlIgooPT0pIEF1dG9tYXRpY2FsbHkgYWRkaW5nIGRldmljZXMKKD09KSBBdXRvbWF0aWNh bGx5IGVuYWJsaW5nIGRldmljZXMKKD09KSBJbmNsdWRpbmcgdGhlIGRlZmF1bHQgZm9udCBw YXRoIC91c3IvbG9jYWwvbGliL1gxMS9mb250cy9taXNjLywvdXNyL2xvY2FsL2xpYi9YMTEv Zm9udHMvVFRGLywvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvT1RGLC91c3IvbG9jYWwvbGli L1gxMS9mb250cy9UeXBlMS8sL3Vzci9sb2NhbC9saWIvWDExL2ZvbnRzLzEwMGRwaS8sL3Vz ci9sb2NhbC9saWIvWDExL2ZvbnRzLzc1ZHBpLy4KKCoqKSBGb250UGF0aCBzZXQgdG86Cgkv dXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvbWlzYy8sCgkvdXNyL2xvY2FsL2xpYi9YMTEvZm9u dHMvVFRGLywKCS91c3IvbG9jYWwvbGliL1gxMS9mb250cy9PVEYsCgkvdXNyL2xvY2FsL2xp Yi9YMTEvZm9udHMvVHlwZTEvLAoJL3Vzci9sb2NhbC9saWIvWDExL2ZvbnRzLzEwMGRwaS8s CgkvdXNyL2xvY2FsL2xpYi9YMTEvZm9udHMvNzVkcGkvLAoJL3Vzci9sb2NhbC9saWIvWDEx L2ZvbnRzL21pc2MvLAoJL3Vzci9sb2NhbC9saWIvWDExL2ZvbnRzL1RURi8sCgkvdXNyL2xv Y2FsL2xpYi9YMTEvZm9udHMvT1RGLAoJL3Vzci9sb2NhbC9saWIvWDExL2ZvbnRzL1R5cGUx LywKCS91c3IvbG9jYWwvbGliL1gxMS9mb250cy8xMDBkcGkvLAoJL3Vzci9sb2NhbC9saWIv WDExL2ZvbnRzLzc1ZHBpLwooKiopIE1vZHVsZVBhdGggc2V0IHRvICIvdXNyL2xvY2FsL2xp Yi94b3JnL21vZHVsZXMiCigqKikgRXh0ZW5zaW9uICJDb21wb3NpdGUiIGlzIGVuYWJsZWQK KElJKSBDYW5ub3QgbG9jYXRlIGEgY29yZSBwb2ludGVyIGRldmljZS4KKElJKSBDYW5ub3Qg bG9jYXRlIGEgY29yZSBrZXlib2FyZCBkZXZpY2UuCihJSSkgVGhlIHNlcnZlciByZWxpZXMg b24gSEFMIHRvIHByb3ZpZGUgdGhlIGxpc3Qgb2YgaW5wdXQgZGV2aWNlcy4KCUlmIG5vIGRl dmljZXMgYmVjb21lIGF2YWlsYWJsZSwgcmVjb25maWd1cmUgSEFMIG9yIGRpc2FibGUgQWxs b3dFbXB0eUlucHV0LgooSUkpIExvYWRlciBtYWdpYzogMHg4MWJjM2MwCihJSSkgTW9kdWxl IEFCSSB2ZXJzaW9uczoKCVguT3JnIEFOU0kgQyBFbXVsYXRpb246IDAuNAoJWC5PcmcgVmlk ZW8gRHJpdmVyOiA0LjEKCVguT3JnIFhJbnB1dCBkcml2ZXIgOiAyLjEKCVguT3JnIFNlcnZl ciBFeHRlbnNpb24gOiAxLjEKCVguT3JnIEZvbnQgUmVuZGVyZXIgOiAwLjYKKElJKSBMb2Fk ZXIgcnVubmluZyBvbiBmcmVlYnNkCigtLSkgVXNpbmcgc3lzY29ucyBkcml2ZXIgd2l0aCBY IHN1cHBvcnQgKHZlcnNpb24gMi4wKQooLS0pIHVzaW5nIFZUIG51bWJlciA5CgooLS0pIFBD SToqKDBAMDoyOjApIEludGVsIENvcnBvcmF0aW9uIDgyODUyLzg1NUdNIEludGVncmF0ZWQg R3JhcGhpY3MgRGV2aWNlIHJldiAyLCBNZW0gQCAweGU4MDAwMDAwLzAsIDB4ZTAwMDAwMDAv MCwgSS9PIEAgMHgwMDAwMTgwMC8wLCBCSU9TIEAgMHg/Pz8/Pz8/Py82NTUzNgooLS0pIFBD STogKDBAMDoyOjEpIEludGVsIENvcnBvcmF0aW9uIDgyODUyLzg1NUdNIEludGVncmF0ZWQg R3JhcGhpY3MgRGV2aWNlIHJldiAyLCBNZW0gQCAweGYwMDAwMDAwLzAsIDB4ZTAwODAwMDAv MAooSUkpIFN5c3RlbSByZXNvdXJjZSByYW5nZXM6CglbMF0gLTEJMAkweDAwMTAwMDAwIC0g MHgzZmZmZmZmZiAoMHgzZmYwMDAwMCkgTVhbQl1FKEIpCglbMV0gLTEJMAkweDAwMGYwMDAw IC0gMHgwMDBmZmZmZiAoMHgxMDAwMCkgTVhbQl0KCVsyXSAtMQkwCTB4MDAwYzAwMDAgLSAw eDAwMGVmZmZmICgweDMwMDAwKSBNWFtCXQoJWzNdIC0xCTAJMHgwMDAwMDAwMCAtIDB4MDAw OWZmZmYgKDB4YTAwMDApIE1YW0JdCglbNF0gLTEJMAkweDAwMDBmZmZmIC0gMHgwMDAwZmZm ZiAoMHgxKSBJWFtCXQoJWzVdIC0xCTAJMHgwMDAwMDAwMCAtIDB4MDAwMDAwZmYgKDB4MTAw KSBJWFtCXQooSUkpICJleHRtb2QiIHdpbGwgYmUgbG9hZGVkLiBUaGlzIHdhcyBlbmFibGVk IGJ5IGRlZmF1bHQgYW5kIGFsc28gc3BlY2lmaWVkIGluIHRoZSBjb25maWcgZmlsZS4KKElJ KSAiZGJlIiB3aWxsIGJlIGxvYWRlZC4gVGhpcyB3YXMgZW5hYmxlZCBieSBkZWZhdWx0IGFu ZCBhbHNvIHNwZWNpZmllZCBpbiB0aGUgY29uZmlnIGZpbGUuCihJSSkgImdseCIgd2lsbCBi ZSBsb2FkZWQuIFRoaXMgd2FzIGVuYWJsZWQgYnkgZGVmYXVsdCBhbmQgYWxzbyBzcGVjaWZp ZWQgaW4gdGhlIGNvbmZpZyBmaWxlLgooSUkpICJmcmVldHlwZSIgd2lsbCBiZSBsb2FkZWQu IFRoaXMgd2FzIGVuYWJsZWQgYnkgZGVmYXVsdCBhbmQgYWxzbyBzcGVjaWZpZWQgaW4gdGhl IGNvbmZpZyBmaWxlLgooSUkpICJyZWNvcmQiIHdpbGwgYmUgbG9hZGVkLiBUaGlzIHdhcyBl bmFibGVkIGJ5IGRlZmF1bHQgYW5kIGFsc28gc3BlY2lmaWVkIGluIHRoZSBjb25maWcgZmls ZS4KKElJKSAiZHJpIiB3aWxsIGJlIGxvYWRlZC4gVGhpcyB3YXMgZW5hYmxlZCBieSBkZWZh dWx0IGFuZCBhbHNvIHNwZWNpZmllZCBpbiB0aGUgY29uZmlnIGZpbGUuCihJSSkgTG9hZE1v ZHVsZTogInJlY29yZCIKCihJSSkgTG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVs ZXMvZXh0ZW5zaW9ucy8vbGlicmVjb3JkLnNvCihJSSkgTW9kdWxlIHJlY29yZDogdmVuZG9y PSJYLk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDEuNS4zLCBtb2R1bGUgdmVyc2lv biA9IDEuMTMuMAoJTW9kdWxlIGNsYXNzOiBYLk9yZyBTZXJ2ZXIgRXh0ZW5zaW9uCglBQkkg Y2xhc3M6IFguT3JnIFNlcnZlciBFeHRlbnNpb24sIHZlcnNpb24gMS4xCihJSSkgTG9hZGlu ZyBleHRlbnNpb24gUkVDT1JECihJSSkgTG9hZE1vZHVsZTogInh0cmFwIgoKKElJKSBMb2Fk aW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxlcy9leHRlbnNpb25zLy9saWJ4dHJhcC5z bwooSUkpIE1vZHVsZSB4dHJhcDogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJY29tcGls ZWQgZm9yIDEuNS4zLCBtb2R1bGUgdmVyc2lvbiA9IDEuMC4wCglNb2R1bGUgY2xhc3M6IFgu T3JnIFNlcnZlciBFeHRlbnNpb24KCUFCSSBjbGFzczogWC5PcmcgU2VydmVyIEV4dGVuc2lv biwgdmVyc2lvbiAxLjEKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBERUMtWFRSQVAKKElJKSBM b2FkTW9kdWxlOiAiZ2x4IgoKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9k dWxlcy9leHRlbnNpb25zLy9saWJnbHguc28KKElJKSBNb2R1bGUgZ2x4OiB2ZW5kb3I9Ilgu T3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3IgMS41LjMsIG1vZHVsZSB2ZXJzaW9uID0g MS4wLjAKCUFCSSBjbGFzczogWC5PcmcgU2VydmVyIEV4dGVuc2lvbiwgdmVyc2lvbiAxLjEK KCoqKSBBSUdMWCBlbmFibGVkCigqKikgRXhwb3J0aW5nIHR5cGljYWwgc2V0IG9mIEdMWCB2 aXN1YWxzCihJSSkgTG9hZGluZyBleHRlbnNpb24gR0xYCihJSSkgTG9hZE1vZHVsZTogImRi ZSIKCihJSSkgTG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMvZXh0ZW5zaW9u cy8vbGliZGJlLnNvCihJSSkgTW9kdWxlIGRiZTogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9u IgoJY29tcGlsZWQgZm9yIDEuNS4zLCBtb2R1bGUgdmVyc2lvbiA9IDEuMC4wCglNb2R1bGUg Y2xhc3M6IFguT3JnIFNlcnZlciBFeHRlbnNpb24KCUFCSSBjbGFzczogWC5PcmcgU2VydmVy IEV4dGVuc2lvbiwgdmVyc2lvbiAxLjEKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBET1VCTEUt QlVGRkVSCihJSSkgTG9hZE1vZHVsZTogImV4dG1vZCIKCihJSSkgTG9hZGluZyAvdXNyL2xv Y2FsL2xpYi94b3JnL21vZHVsZXMvZXh0ZW5zaW9ucy8vbGliZXh0bW9kLnNvCihJSSkgTW9k dWxlIGV4dG1vZDogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDEu NS4zLCBtb2R1bGUgdmVyc2lvbiA9IDEuMC4wCglNb2R1bGUgY2xhc3M6IFguT3JnIFNlcnZl ciBFeHRlbnNpb24KCUFCSSBjbGFzczogWC5PcmcgU2VydmVyIEV4dGVuc2lvbiwgdmVyc2lv biAxLjEKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBTSEFQRQooSUkpIExvYWRpbmcgZXh0ZW5z aW9uIE1JVC1TVU5EUlktTk9OU1RBTkRBUkQKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBCSUct UkVRVUVTVFMKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBTWU5DCihJSSkgTG9hZGluZyBleHRl bnNpb24gTUlULVNDUkVFTi1TQVZFUgooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIFhDLU1JU0MK KElJKSBMb2FkaW5nIGV4dGVuc2lvbiBYRnJlZTg2LVZpZE1vZGVFeHRlbnNpb24KKElJKSBM b2FkaW5nIGV4dGVuc2lvbiBYRnJlZTg2LU1pc2MKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBY RnJlZTg2LURHQQooSUkpIExvYWRpbmcgZXh0ZW5zaW9uIERQTVMKKElJKSBMb2FkaW5nIGV4 dGVuc2lvbiBUT0ctQ1VQCihJSSkgTG9hZGluZyBleHRlbnNpb24gRXh0ZW5kZWQtVmlzdWFs LUluZm9ybWF0aW9uCihJSSkgTG9hZGluZyBleHRlbnNpb24gWFZpZGVvCihJSSkgTG9hZGlu ZyBleHRlbnNpb24gWFZpZGVvLU1vdGlvbkNvbXBlbnNhdGlvbgooSUkpIExvYWRpbmcgZXh0 ZW5zaW9uIFgtUmVzb3VyY2UKKElJKSBMb2FkTW9kdWxlOiAiZHJpIgoKKElJKSBMb2FkaW5n IC91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxlcy9leHRlbnNpb25zLy9saWJkcmkuc28KKElJ KSBNb2R1bGUgZHJpOiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3Ig MS41LjMsIG1vZHVsZSB2ZXJzaW9uID0gMS4wLjAKCUFCSSBjbGFzczogWC5PcmcgU2VydmVy IEV4dGVuc2lvbiwgdmVyc2lvbiAxLjEKKElJKSBMb2FkaW5nIGV4dGVuc2lvbiBYRnJlZTg2 LURSSQooSUkpIExvYWRNb2R1bGU6ICJmcmVldHlwZSIKCihJSSkgTG9hZGluZyAvdXNyL2xv Y2FsL2xpYi94b3JnL21vZHVsZXMvZm9udHMvL2xpYmZyZWV0eXBlLnNvCihJSSkgTW9kdWxl IGZyZWV0eXBlOiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24gJiB0aGUgQWZ0ZXIgWC1UVCBQ cm9qZWN0IgoJY29tcGlsZWQgZm9yIDEuNS4zLCBtb2R1bGUgdmVyc2lvbiA9IDIuMS4wCglN b2R1bGUgY2xhc3M6IFguT3JnIEZvbnQgUmVuZGVyZXIKCUFCSSBjbGFzczogWC5PcmcgRm9u dCBSZW5kZXJlciwgdmVyc2lvbiAwLjYKKElJKSBMb2FkaW5nIGZvbnQgRnJlZVR5cGUKKElJ KSBMb2FkTW9kdWxlOiAiaW50ZWwiCgooSUkpIExvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9y Zy9tb2R1bGVzL2RyaXZlcnMvL2ludGVsX2Rydi5zbwooSUkpIE1vZHVsZSBpbnRlbDogdmVu ZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDEuNS4zLCBtb2R1bGUgdmVy c2lvbiA9IDIuNS4xCglNb2R1bGUgY2xhc3M6IFguT3JnIFZpZGVvIERyaXZlcgoJQUJJIGNs YXNzOiBYLk9yZyBWaWRlbyBEcml2ZXIsIHZlcnNpb24gNC4xCihJSSkgaW50ZWw6IERyaXZl ciBmb3IgSW50ZWwgSW50ZWdyYXRlZCBHcmFwaGljcyBDaGlwc2V0czogaTgxMCwKCWk4MTAt ZGMxMDAsIGk4MTBlLCBpODE1LCBpODMwTSwgODQ1RywgODUyR00vODU1R00sIDg2NUcsIDkx NUcsCglFNzIyMSAoaTkxNSksIDkxNUdNLCA5NDVHLCA5NDVHTSwgOTQ1R01FLCA5NjVHLCBH MzUsIDk2NVEsIDk0NkdaLAoJOTY1R00sIDk2NUdNRS9HTEUsIEczMywgUTM1LCBRMzMsCglN b2JpbGUgSW50ZWzCriBHTTQ1IEV4cHJlc3MgQ2hpcHNldCwKCUludGVsIEludGVncmF0ZWQg R3JhcGhpY3MgRGV2aWNlLCBHNDUvRzQzLCBRNDUvUTQzLCBHNDEKKElJKSBQcmltYXJ5IERl dmljZSBpczogUENJIDAwQDAwOjAyOjAKKElJKSByZXNvdXJjZSByYW5nZXMgYWZ0ZXIgeGY4 NkNsYWltRml4ZWRSZXNvdXJjZXMoKSBjYWxsOgoJWzBdIC0xCTAJMHgwMDEwMDAwMCAtIDB4 M2ZmZmZmZmYgKDB4M2ZmMDAwMDApIE1YW0JdRShCKQoJWzFdIC0xCTAJMHgwMDBmMDAwMCAt IDB4MDAwZmZmZmYgKDB4MTAwMDApIE1YW0JdCglbMl0gLTEJMAkweDAwMGMwMDAwIC0gMHgw MDBlZmZmZiAoMHgzMDAwMCkgTVhbQl0KCVszXSAtMQkwCTB4MDAwMDAwMDAgLSAweDAwMDlm ZmZmICgweGEwMDAwKSBNWFtCXQoJWzRdIC0xCTAJMHgwMDAwZmZmZiAtIDB4MDAwMGZmZmYg KDB4MSkgSVhbQl0KCVs1XSAtMQkwCTB4MDAwMDAwMDAgLSAweDAwMDAwMGZmICgweDEwMCkg SVhbQl0KKElJKSByZXNvdXJjZSByYW5nZXMgYWZ0ZXIgcHJvYmluZzoKCVswXSAtMQkwCTB4 MDAxMDAwMDAgLSAweDNmZmZmZmZmICgweDNmZjAwMDAwKSBNWFtCXUUoQikKCVsxXSAtMQkw CTB4MDAwZjAwMDAgLSAweDAwMGZmZmZmICgweDEwMDAwKSBNWFtCXQoJWzJdIC0xCTAJMHgw MDBjMDAwMCAtIDB4MDAwZWZmZmYgKDB4MzAwMDApIE1YW0JdCglbM10gLTEJMAkweDAwMDAw MDAwIC0gMHgwMDA5ZmZmZiAoMHhhMDAwMCkgTVhbQl0KCVs0XSAwCTAJMHgwMDBhMDAwMCAt IDB4MDAwYWZmZmYgKDB4MTAwMDApIE1TW0JdCglbNV0gMAkwCTB4MDAwYjAwMDAgLSAweDAw MGI3ZmZmICgweDgwMDApIE1TW0JdCglbNl0gMAkwCTB4MDAwYjgwMDAgLSAweDAwMGJmZmZm ICgweDgwMDApIE1TW0JdCglbN10gLTEJMAkweDAwMDBmZmZmIC0gMHgwMDAwZmZmZiAoMHgx KSBJWFtCXQoJWzhdIC0xCTAJMHgwMDAwMDAwMCAtIDB4MDAwMDAwZmYgKDB4MTAwKSBJWFtC XQoJWzldIDAJMAkweDAwMDAwM2IwIC0gMHgwMDAwMDNiYiAoMHhjKSBJU1tCXQoJWzEwXSAw CTAJMHgwMDAwMDNjMCAtIDB4MDAwMDAzZGYgKDB4MjApIElTW0JdCihJSSkgTG9hZGluZyBz dWIgbW9kdWxlICJ2Z2FodyIKKElJKSBMb2FkTW9kdWxlOiAidmdhaHciCgooSUkpIExvYWRp bmcgL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVzLy9saWJ2Z2Fody5zbwooSUkpIE1vZHVs ZSB2Z2FodzogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDEuNS4z LCBtb2R1bGUgdmVyc2lvbiA9IDAuMS4wCglBQkkgY2xhc3M6IFguT3JnIFZpZGVvIERyaXZl ciwgdmVyc2lvbiA0LjEKKCoqKSBpbnRlbCgwKTogRGVwdGggMjQsICgtLSkgZnJhbWVidWZm ZXIgYnBwIDMyCig9PSkgaW50ZWwoMCk6IFJHQiB3ZWlnaHQgODg4Cig9PSkgaW50ZWwoMCk6 IERlZmF1bHQgdmlzdWFsIGlzIFRydWVDb2xvcgooKiopIGludGVsKDApOiBPcHRpb24gIkFj Y2VsTWV0aG9kIiAiRVhBIgooKiopIGludGVsKDApOiBPcHRpb24gIk5vQWNjZWwiICJmYWxz ZSIKKCoqKSBpbnRlbCgwKTogT3B0aW9uICJEUkkiCigqKikgaW50ZWwoMCk6IE9wdGlvbiAi VGlsaW5nIiAib2ZmIgooKiopIGludGVsKDApOiBPcHRpb24gIkZvcmNlRW5hYmxlUGlwZUEi ICJ0cnVlIgooSUkpIGludGVsKDApOiBJbnRlZ3JhdGVkIEdyYXBoaWNzIENoaXBzZXQ6IElu dGVsKFIpIDg1NUdNCigtLSkgaW50ZWwoMCk6IENoaXBzZXQ6ICI4NTJHTS84NTVHTSIKKC0t KSBpbnRlbCgwKTogTGluZWFyIGZyYW1lYnVmZmVyIGF0IDB4RTgwMDAwMDAKKC0tKSBpbnRl bCgwKTogSU8gcmVnaXN0ZXJzIGF0IGFkZHIgMHhFMDAwMDAwMAooKiopIGludGVsKDApOiBV c2luZyBFWEEgZm9yIGFjY2VsZXJhdGlvbgooSUkpIGludGVsKDApOiAyIGRpc3BsYXkgcGlw ZXMgYXZhaWxhYmxlLgooSUkpIExvYWRpbmcgc3ViIG1vZHVsZSAiZGRjIgooSUkpIExvYWRN b2R1bGU6ICJkZGMiCihJSSkgTW9kdWxlICJkZGMiIGFscmVhZHkgYnVpbHQtaW4KKElJKSBM b2FkaW5nIHN1YiBtb2R1bGUgImkyYyIKKElJKSBMb2FkTW9kdWxlOiAiaTJjIgooSUkpIE1v ZHVsZSAiaTJjIiBhbHJlYWR5IGJ1aWx0LWluCihJSSkgaW50ZWwoMCk6IE91dHB1dCBWR0Eg dXNpbmcgbW9uaXRvciBzZWN0aW9uIE1vbml0b3IwCihJSSkgaW50ZWwoMCk6IE91dHB1dCBM VkRTIGhhcyBubyBtb25pdG9yIHNlY3Rpb24KKElJKSBpbnRlbCgwKTogSTJDIGJ1cyAiTFZE U0REQ19DIiBpbml0aWFsaXplZC4KKElJKSBpbnRlbCgwKTogQXR0ZW1wdGluZyB0byBkZXRl cm1pbmUgcGFuZWwgZml4ZWQgbW9kZS4KKElJKSBpbnRlbCgwKTogSTJDIGRldmljZSAiTFZE U0REQ19DOmRkYzIiIHJlZ2lzdGVyZWQgYXQgYWRkcmVzcyAweEEwLgooSUkpIGludGVsKDAp OiBFRElEIHZlbmRvciAiU0VDIiwgcHJvZCBpZCAyMjA4MgooSUkpIGludGVsKDApOiBJMkMg YnVzICJEVk9ERENfRCIgaW5pdGlhbGl6ZWQuCihJSSkgTG9hZGluZyBzdWIgbW9kdWxlICJz aWwxNjQiCihJSSkgTG9hZE1vZHVsZTogInNpbDE2NCIKCihJSSkgTG9hZGluZyAvdXNyL2xv Y2FsL2xpYi94b3JnL21vZHVsZXMvZHJpdmVycy8vc2lsMTY0LnNvCihJSSkgTW9kdWxlIHNp bDE2NDogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDEuNS4zLCBt b2R1bGUgdmVyc2lvbiA9IDEuMC4wCglBQkkgY2xhc3M6IFguT3JnIFZpZGVvIERyaXZlciwg dmVyc2lvbiA0LjEKKElJKSBpbnRlbCgwKTogSTJDIGJ1cyAiRFZPSTJDX0UiIGluaXRpYWxp emVkLgooSUkpIExvYWRpbmcgc3ViIG1vZHVsZSAiY2g3eHh4IgooSUkpIExvYWRNb2R1bGU6 ICJjaDd4eHgiCgooSUkpIExvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVzL2Ry aXZlcnMvL2NoN3h4eC5zbwooSUkpIE1vZHVsZSBjaDd4eHg6IHZlbmRvcj0iWC5PcmcgRm91 bmRhdGlvbiIKCWNvbXBpbGVkIGZvciAxLjUuMywgbW9kdWxlIHZlcnNpb24gPSAxLjAuMAoJ QUJJIGNsYXNzOiBYLk9yZyBWaWRlbyBEcml2ZXIsIHZlcnNpb24gNC4xCihJSSkgaW50ZWwo MCk6IEkyQyBidXMgIkRWT0kyQ19FIiByZW1vdmVkLgooSUkpIGludGVsKDApOiBJMkMgYnVz ICJEVk9JMkNfRSIgaW5pdGlhbGl6ZWQuCihJSSkgTG9hZGluZyBzdWIgbW9kdWxlICJpdmNo IgooSUkpIExvYWRNb2R1bGU6ICJpdmNoIgoKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwvbGli L3hvcmcvbW9kdWxlcy9kcml2ZXJzLy9pdmNoLnNvCihJSSkgTW9kdWxlIGl2Y2g6IHZlbmRv cj0iWC5PcmcgRm91bmRhdGlvbiIKCWNvbXBpbGVkIGZvciAxLjUuMywgbW9kdWxlIHZlcnNp b24gPSAxLjAuMAoJQUJJIGNsYXNzOiBYLk9yZyBWaWRlbyBEcml2ZXIsIHZlcnNpb24gNC4x CihJSSkgaW50ZWwoMCk6IEkyQyBidXMgIkRWT0kyQ19FIiByZW1vdmVkLgooSUkpIGludGVs KDApOiBJMkMgYnVzICJEVk9JMkNfQiIgaW5pdGlhbGl6ZWQuCihJSSkgTG9hZGluZyBzdWIg bW9kdWxlICJ0ZnA0MTAiCihJSSkgTG9hZE1vZHVsZTogInRmcDQxMCIKCihJSSkgTG9hZGlu ZyAvdXNyL2xvY2FsL2xpYi94b3JnL21vZHVsZXMvZHJpdmVycy8vdGZwNDEwLnNvCihJSSkg TW9kdWxlIHRmcDQxMDogdmVuZG9yPSJYLk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9y IDEuNS4zLCBtb2R1bGUgdmVyc2lvbiA9IDEuMC4wCglBQkkgY2xhc3M6IFguT3JnIFZpZGVv IERyaXZlciwgdmVyc2lvbiA0LjEKKElJKSBpbnRlbCgwKTogSTJDIGJ1cyAiRFZPSTJDX0Ii IHJlbW92ZWQuCihJSSkgaW50ZWwoMCk6IEkyQyBidXMgIkRWT0kyQ19FIiBpbml0aWFsaXpl ZC4KKElJKSBMb2FkaW5nIHN1YiBtb2R1bGUgImNoNzAxNyIKKElJKSBMb2FkTW9kdWxlOiAi Y2g3MDE3IgoKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxlcy9kcml2 ZXJzLy9jaDcwMTcuc28KKElJKSBNb2R1bGUgY2g3MDE3OiB2ZW5kb3I9IlguT3JnIEZvdW5k YXRpb24iCgljb21waWxlZCBmb3IgMS41LjMsIG1vZHVsZSB2ZXJzaW9uID0gMS4wLjAKCUFC SSBjbGFzczogWC5PcmcgVmlkZW8gRHJpdmVyLCB2ZXJzaW9uIDQuMQooSUkpIGludGVsKDAp OiBJMkMgYnVzICJEVk9JMkNfRSIgcmVtb3ZlZC4KKElJKSBpbnRlbCgwKTogSTJDIGJ1cyAi RFZPSTJDX0UiIGluaXRpYWxpemVkLgooRUUpIGludGVsKDApOiBjaDcwMXggbm90IGRldGVj dGVkLCBnb3QgMjk6IGZyb20gRFZPSTJDX0UgU2xhdmUgMjM0LgooSUkpIGludGVsKDApOiBJ MkMgYnVzICJEVk9JMkNfRSIgcmVtb3ZlZC4KKElJKSBpbnRlbCgwKTogSTJDIGJ1cyAiRFZP RERDX0QiIHJlbW92ZWQuCig9PSkgaW50ZWwoMCk6IFdyaXRlLWNvbWJpbmluZyByYW5nZSAo MHhhMDAwMCwweDEwMDAwKSB3YXMgYWxyZWFkeSBjbGVhcgooSUkpIGludGVsKDApOiBJMkMg YnVzICJDUlRERENfQSIgaW5pdGlhbGl6ZWQuCihJSSkgaW50ZWwoMCk6IEkyQyBidXMgIkNS VEREQ19BIiByZW1vdmVkLgooSUkpIGludGVsKDApOiBFRElEIHZlbmRvciAiU0VDIiwgcHJv ZCBpZCAyMjA4MgooSUkpIGludGVsKDApOiBPdXRwdXQgVkdBIGRpc2Nvbm5lY3RlZAooSUkp IGludGVsKDApOiBPdXRwdXQgTFZEUyBjb25uZWN0ZWQKKElJKSBpbnRlbCgwKTogVXNpbmcg dXNlciBwcmVmZXJlbmNlIGZvciBpbml0aWFsIG1vZGVzCihJSSkgaW50ZWwoMCk6IE91dHB1 dCBMVkRTIHVzaW5nIGluaXRpYWwgbW9kZSAxMjgweDc2OAooPT0pIGludGVsKDApOiBXcml0 ZS1jb21iaW5pbmcgcmFuZ2UgKDB4YTAwMDAsMHgxMDAwMCkgd2FzIGFscmVhZHkgY2xlYXIK KElJKSBpbnRlbCgwKTogTW9uaXRvcmluZyBjb25uZWN0ZWQgZGlzcGxheXMgZW5hYmxlZAoo SUkpIGludGVsKDApOiBkZXRlY3RlZCAxMjgga0IgR1RULgooSUkpIGludGVsKDApOiBkZXRl Y3RlZCAzMjYzNiBrQiBzdG9sZW4gbWVtb3J5LgooPT0pIGludGVsKDApOiB2aWRlbyBvdmVy bGF5IGtleSBzZXQgdG8gMHgxMDFmZQooPT0pIGludGVsKDApOiBJbnRlbCBYdk1DIGRlY29k ZXIgZGlzYWJsZWQKKD09KSBpbnRlbCgwKTogV2lsbCBub3QgdHJ5IHRvIGVuYWJsZSBwYWdl IGZsaXBwaW5nCig9PSkgaW50ZWwoMCk6IFRyaXBsZSBidWZmZXJpbmcgZGlzYWJsZWQKKD09 KSBpbnRlbCgwKTogVXNpbmcgZ2FtbWEgY29ycmVjdGlvbiAoMS4wLCAxLjAsIDEuMCkKKD09 KSBpbnRlbCgwKTogRFBJIHNldCB0byAoOTYsIDk2KQooSUkpIExvYWRpbmcgc3ViIG1vZHVs ZSAiZmIiCihJSSkgTG9hZE1vZHVsZTogImZiIgoKKElJKSBMb2FkaW5nIC91c3IvbG9jYWwv bGliL3hvcmcvbW9kdWxlcy8vbGliZmIuc28KKElJKSBNb2R1bGUgZmI6IHZlbmRvcj0iWC5P cmcgRm91bmRhdGlvbiIKCWNvbXBpbGVkIGZvciAxLjUuMywgbW9kdWxlIHZlcnNpb24gPSAx LjAuMAoJQUJJIGNsYXNzOiBYLk9yZyBBTlNJIEMgRW11bGF0aW9uLCB2ZXJzaW9uIDAuNAoo SUkpIExvYWRpbmcgc3ViIG1vZHVsZSAiZXhhIgooSUkpIExvYWRNb2R1bGU6ICJleGEiCgoo SUkpIExvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9yZy9tb2R1bGVzLy9saWJleGEuc28KKElJ KSBNb2R1bGUgZXhhOiB2ZW5kb3I9IlguT3JnIEZvdW5kYXRpb24iCgljb21waWxlZCBmb3Ig MS41LjMsIG1vZHVsZSB2ZXJzaW9uID0gMi40LjAKCUFCSSBjbGFzczogWC5PcmcgVmlkZW8g RHJpdmVyLCB2ZXJzaW9uIDQuMQooSUkpIExvYWRpbmcgc3ViIG1vZHVsZSAicmFtZGFjIgoo SUkpIExvYWRNb2R1bGU6ICJyYW1kYWMiCihJSSkgTW9kdWxlICJyYW1kYWMiIGFscmVhZHkg YnVpbHQtaW4KKElJKSBpbnRlbCgwKTogQ29tcGFyaW5nIHJlZ3MgZnJvbSBzZXJ2ZXIgc3Rh cnQgdXAgdG8gQWZ0ZXIgUHJlSW5pdAooV1cpIGludGVsKDApOiBSZWdpc3RlciAweDYxMjAw IChQUF9TVEFUVVMpIGNoYW5nZWQgZnJvbSAweGMwMDAwMDA4IHRvIDB4ZDAwMDAwMDkKKFdX KSBpbnRlbCgwKTogUFBfU1RBVFVTIGJlZm9yZTogb24sIHJlYWR5LCBzZXF1ZW5jaW5nIGlk bGUKKFdXKSBpbnRlbCgwKTogUFBfU1RBVFVTIGFmdGVyOiBvbiwgcmVhZHksIHNlcXVlbmNp bmcgb24KKFdXKSBpbnRlbCgwKTogUmVnaXN0ZXIgMHg3MTAyNCAoUElQRUJTVEFUKSBjaGFu Z2VkIGZyb20gMHg4MDAwMDIwMiB0byAweDAwMDAwMjAyCihXVykgaW50ZWwoMCk6IFBJUEVC U1RBVCBiZWZvcmU6IHN0YXR1czogRklGT19VTkRFUlJVTiBWU1lOQ19JTlRfU1RBVFVTIFZC TEFOS19JTlRfU1RBVFVTCihXVykgaW50ZWwoMCk6IFBJUEVCU1RBVCBhZnRlcjogc3RhdHVz OiBWU1lOQ19JTlRfU1RBVFVTIFZCTEFOS19JTlRfU1RBVFVTCihJSSkgTG9hZGluZyBzdWIg bW9kdWxlICJkcmkiCihJSSkgTG9hZE1vZHVsZTogImRyaSIKCihJSSkgUmVsb2FkaW5nIC91 c3IvbG9jYWwvbGliL3hvcmcvbW9kdWxlcy9leHRlbnNpb25zLy9saWJkcmkuc28KKD09KSBE ZXB0aCAyNCBwaXhtYXAgZm9ybWF0IGlzIDMyIGJwcAooSUkpIGRvIEkgbmVlZCBSQUM/ICBO bywgSSBkb24ndC4KKElJKSByZXNvdXJjZSByYW5nZXMgYWZ0ZXIgcHJlSW5pdDoKCVswXSAt MQkwCTB4MDAxMDAwMDAgLSAweDNmZmZmZmZmICgweDNmZjAwMDAwKSBNWFtCXUUoQikKCVsx XSAtMQkwCTB4MDAwZjAwMDAgLSAweDAwMGZmZmZmICgweDEwMDAwKSBNWFtCXQoJWzJdIC0x CTAJMHgwMDBjMDAwMCAtIDB4MDAwZWZmZmYgKDB4MzAwMDApIE1YW0JdCglbM10gLTEJMAkw eDAwMDAwMDAwIC0gMHgwMDA5ZmZmZiAoMHhhMDAwMCkgTVhbQl0KCVs0XSAwCTAJMHgwMDBh MDAwMCAtIDB4MDAwYWZmZmYgKDB4MTAwMDApIE1TW0JdKE9wckQpCglbNV0gMAkwCTB4MDAw YjAwMDAgLSAweDAwMGI3ZmZmICgweDgwMDApIE1TW0JdKE9wckQpCglbNl0gMAkwCTB4MDAw YjgwMDAgLSAweDAwMGJmZmZmICgweDgwMDApIE1TW0JdKE9wckQpCglbN10gLTEJMAkweDAw MDBmZmZmIC0gMHgwMDAwZmZmZiAoMHgxKSBJWFtCXQoJWzhdIC0xCTAJMHgwMDAwMDAwMCAt IDB4MDAwMDAwZmYgKDB4MTAwKSBJWFtCXQoJWzldIDAJMAkweDAwMDAwM2IwIC0gMHgwMDAw MDNiYiAoMHhjKSBJU1tCXShPcHJVKQoJWzEwXSAwCTAJMHgwMDAwMDNjMCAtIDB4MDAwMDAz ZGYgKDB4MjApIElTW0JdKE9wclUpCihJSSkgaW50ZWwoMCk6IEtlcm5lbCByZXBvcnRlZCA0 OTE1MjAgdG90YWwsIDAgdXNlZAooSUkpIGludGVsKDApOiBJODMwQ2hlY2tBdmFpbGFibGVN ZW1vcnk6IDE5NjYwODAga0IgYXZhaWxhYmxlCmRybU9wZW5EZXZpY2U6IG5vZGUgbmFtZSBp cyAvZGV2L2RyaS9jYXJkMApkcm1PcGVuRGV2aWNlOiBvcGVuIHJlc3VsdCBpcyA5LCAoT0sp CmRybU9wZW5EZXZpY2U6IG5vZGUgbmFtZSBpcyAvZGV2L2RyaS9jYXJkMApkcm1PcGVuRGV2 aWNlOiBvcGVuIHJlc3VsdCBpcyA5LCAoT0spCmRybU9wZW5CeUJ1c2lkOiBTZWFyY2hpbmcg Zm9yIEJ1c0lEIHBjaTowMDAwOjAwOjAyLjAKZHJtT3BlbkRldmljZTogbm9kZSBuYW1lIGlz IC9kZXYvZHJpL2NhcmQwCmRybU9wZW5EZXZpY2U6IG9wZW4gcmVzdWx0IGlzIDksIChPSykK ZHJtT3BlbkJ5QnVzaWQ6IGRybU9wZW5NaW5vciByZXR1cm5zIDkKZHJtT3BlbkJ5QnVzaWQ6 IGRybUdldEJ1c2lkIHJlcG9ydHMgcGNpOjAwMDA6MDA6MDIuMAooSUkpIFtkcm1dIERSTSBp bnRlcmZhY2UgdmVyc2lvbiAxLjIKKElJKSBbZHJtXSBEUk0gb3BlbiBtYXN0ZXIgc3VjY2Vl ZGVkLgooSUkpIGludGVsKDApOiBbZHJtXSBVc2luZyB0aGUgRFJNIGxvY2sgU0FSRUEgYWxz byBmb3IgZHJhd2FibGVzLgooSUkpIGludGVsKDApOiBbZHJtXSBmcmFtZWJ1ZmZlciBtYXBw ZWQgYnkgZGR4IGRyaXZlcgooSUkpIGludGVsKDApOiBbZHJtXSBhZGRlZCAxIHJlc2VydmVk IGNvbnRleHQgZm9yIGtlcm5lbAooSUkpIGludGVsKDApOiBYIGNvbnRleHQgaGFuZGxlID0g MHgxCihJSSkgaW50ZWwoMCk6IFtkcm1dIGluc3RhbGxlZCBEUk0gc2lnbmFsIGhhbmRsZXIK KCoqKSBpbnRlbCgwKTogRnJhbWVidWZmZXIgY29tcHJlc3Npb24gZGlzYWJsZWQKKCoqKSBp bnRlbCgwKTogVGlsaW5nIGRpc2FibGVkCig9PSkgaW50ZWwoMCk6IFZpZGVvUmFtOiAxMzEw NzIgS0IKKElJKSBpbnRlbCgwKTogQXR0ZW1wdGluZyBtZW1vcnkgYWxsb2NhdGlvbiB3aXRo IHVudGlsZWQgYnVmZmVycy4KKElJKSBpbnRlbCgwKTogVW50aWxlZCBhbGxvY2F0aW9uIHN1 Y2Nlc3NmdWwuCihJSSkgaW50ZWwoMCk6IFtkcm1dIFJlZ2lzdGVycyA9IDB4ZTAwMDAwMDAK KElJKSBpbnRlbCgwKTogW2RybV0gcmluZyBidWZmZXIgPSAweGU4MDAwMDAwCihJSSkgaW50 ZWwoMCk6IFtkcm1dIG1hcHBlZCBmcm9udCBidWZmZXIgYXQgMHhlODEzMDAwMCwgaGFuZGxl ID0gMHhlODEzMDAwMAooSUkpIGludGVsKDApOiBbZHJtXSBtYXBwZWQgYmFjayBidWZmZXIg YXQgMHhlOWZlYTAwMCwgaGFuZGxlID0gMHhlOWZlYTAwMAooSUkpIGludGVsKDApOiBbZHJt XSBtYXBwZWQgZGVwdGggYnVmZmVyIGF0IDB4ZWE2MmEwMDAsIGhhbmRsZSA9IDB4ZWE2MmEw MDAKKElJKSBpbnRlbCgwKTogW2RybV0gbWFwcGVkIGNsYXNzaWMgdGV4dHVyZXMgYXQgMHhl YWM2YTAwMCwgaGFuZGxlID0gMHhlYWM2YTAwMAooSUkpIGludGVsKDApOiBbZHJtXSBJbml0 aWFsaXplZCBrZXJuZWwgYWdwIGhlYXAgbWFuYWdlciwgMzM1NTQ0MzIKKElJKSBpbnRlbCgw KTogW2RyaV0gdmlzdWFsIGNvbmZpZ3MgaW5pdGlhbGl6ZWQKKElJKSBpbnRlbCgwKTogUGFn ZSBGbGlwcGluZyBkaXNhYmxlZAooSUkpIGludGVsKDApOiB2Z2FIV0dldElPQmFzZTogaHdw LT5JT0Jhc2UgaXMgMHgwM2QwLCBod3AtPlBJT09mZnNldCBpcyAweDAwMDAKKD09KSBpbnRl bCgwKTogV3JpdGUtY29tYmluaW5nIHJhbmdlICgweGEwMDAwLDB4MTAwMDApIHdhcyBhbHJl YWR5IGNsZWFyCigqKikgaW50ZWwoMCk6IE9wdGlvbiAiRVhBTm9Db21wb3NpdGUiICJmYWxz ZSIKKCoqKSBpbnRlbCgwKTogT3B0aW9uICJFWEFOb1VwbG9hZFRvU2NyZWVuIiAidHJ1ZSIK KCoqKSBpbnRlbCgwKTogRVhBOiBEaXNhYmxpbmcgVXBsb2FkVG9TY3JlZW4KKElJKSBFWEEo MCk6IE9mZnNjcmVlbiBwaXhtYXAgYXJlYSBvZiAxOTY2MDgwMCBieXRlcwooSUkpIEVYQSgw KTogRHJpdmVyIHJlZ2lzdGVyZWQgc3VwcG9ydCBmb3IgdGhlIGZvbGxvd2luZyBvcGVyYXRp b25zOgooSUkpICAgICAgICAgU29saWQKKElJKSAgICAgICAgIENvcHkKKElJKSAgICAgICAg IENvbXBvc2l0ZSAoUkVOREVSIGFjY2VsZXJhdGlvbikKKD09KSBpbnRlbCgwKTogQmFja2lu ZyBzdG9yZSBkaXNhYmxlZAooPT0pIGludGVsKDApOiBTaWxrZW4gbW91c2UgZW5hYmxlZAoo SUkpIGludGVsKDApOiBJbml0aWFsaXppbmcgSFcgQ3Vyc29yCihJSSkgaW50ZWwoMCk6IFtE UkldIGluc3RhbGxhdGlvbiBjb21wbGV0ZQooSUkpIGludGVsKDApOiB4Zjg2QmluZEdBUlRN ZW1vcnk6IGJpbmQga2V5IDEgYXQgMHgwMWZkZjAwMCAocGdvZmZzZXQgODE1OSkKKElJKSBp bnRlbCgwKTogeGY4NkJpbmRHQVJUTWVtb3J5OiBiaW5kIGtleSAyIGF0IDB4MDFmZTkwMDAg KHBnb2Zmc2V0IDgxNjkpCihJSSkgaW50ZWwoMCk6IHhmODZCaW5kR0FSVE1lbW9yeTogYmlu ZCBrZXkgMyBhdCAweDAxZmVhMDAwIChwZ29mZnNldCA4MTcwKQooSUkpIGludGVsKDApOiB4 Zjg2QmluZEdBUlRNZW1vcnk6IGJpbmQga2V5IDQgYXQgMHgwMjYyYTAwMCAocGdvZmZzZXQg OTc3MCkKKElJKSBpbnRlbCgwKTogeGY4NkJpbmRHQVJUTWVtb3J5OiBiaW5kIGtleSA1IGF0 IDB4MDJjNmEwMDAgKHBnb2Zmc2V0IDExMzcwKQooSUkpIGludGVsKDApOiBGaXhlZCBtZW1v cnkgYWxsb2NhdGlvbiBsYXlvdXQ6CihJSSkgaW50ZWwoMCk6IDB4MDAwMDAwMDAtMHgwMDAx ZmZmZjogcmluZyBidWZmZXIgKDEyOCBrQikKKElJKSBpbnRlbCgwKTogMHgwMDAyMDAwMC0w eDAwMDI3ZmZmOiBsb2dpY2FsIDNEIGNvbnRleHQgKDMyIGtCKQooSUkpIGludGVsKDApOiAw eDAwMDI4MDAwLTB4MDAxMjdmZmY6IGZha2UgYnVmbWdyICgxMDI0IGtCKQooSUkpIGludGVs KDApOiAweDAwMTMwMDAwLTB4MDA3NmZmZmY6IGZyb250IGJ1ZmZlciAoNjQwMCBrQikKKElJ KSBpbnRlbCgwKTogMHgwMDc3MDAwMC0weDAxYTJmZmZmOiBleGEgb2Zmc2NyZWVuICgxOTIw MCBrQikKKElJKSBpbnRlbCgwKTogMHgwMWZkZjAwMDogICAgICAgICAgICBlbmQgb2Ygc3Rv bGVuIG1lbW9yeQooSUkpIGludGVsKDApOiAweDAxZmRmMDAwLTB4MDFmZThmZmY6IEhXIGN1 cnNvcnMgKDQwIGtCLCAweDAwMDAwMDAwMmJjMzAwMDAgcGh5c2ljYWwKKQooSUkpIGludGVs KDApOiAweDAxZmU5MDAwLTB4MDFmZTlmZmY6IG92ZXJsYXkgcmVnaXN0ZXJzICg0IGtCLCAw eDAwMDAwMDAwMmJjMjMwMDAgcGh5c2ljYWwKKQooSUkpIGludGVsKDApOiAweDAxZmVhMDAw LTB4MDI2MjlmZmY6IGJhY2sgYnVmZmVyICg2NDAwIGtCKQooSUkpIGludGVsKDApOiAweDAy NjJhMDAwLTB4MDJjNjlmZmY6IGRlcHRoIGJ1ZmZlciAoNjQwMCBrQikKKElJKSBpbnRlbCgw KTogMHgwMmM2YTAwMC0weDA0YzY5ZmZmOiBjbGFzc2ljIHRleHR1cmVzICgzMjc2OCBrQikK KElJKSBpbnRlbCgwKTogMHgwODAwMDAwMDogICAgICAgICAgICBlbmQgb2YgYXBlcnR1cmUK KElJKSBpbnRlbCgwKTogdXNpbmcgU1NDIHJlZmVyZW5jZSBjbG9jayBvZiA2NiBNSHoKKElJ KSBpbnRlbCgwKTogU2VsZWN0aW5nIHN0YW5kYXJkIDE4IGJpdCBUTURTIHBpeGVsIGZvcm1h dC4KKElJKSBpbnRlbCgwKTogT3V0cHV0IGNvbmZpZ3VyYXRpb246CihJSSkgaW50ZWwoMCk6 ICAgUGlwZSBBIGlzIG9mZgooSUkpIGludGVsKDApOiAgIERpc3BsYXkgcGxhbmUgQSBpcyBu b3cgZGlzYWJsZWQgYW5kIGNvbm5lY3RlZCB0byBwaXBlIEEuCihXVykgaW50ZWwoMCk6ICAg SGFyZHdhcmUgY2xhaW1zIHBpcGUgQSBpcyBvbiB3aGlsZSBzb2Z0d2FyZSBiZWxpZXZlcyBp dCBpcyBvZmYKKElJKSBpbnRlbCgwKTogICBQaXBlIEIgaXMgb24KKElJKSBpbnRlbCgwKTog ICBEaXNwbGF5IHBsYW5lIEIgaXMgbm93IGVuYWJsZWQgYW5kIGNvbm5lY3RlZCB0byBwaXBl IEIuCihJSSkgaW50ZWwoMCk6ICAgT3V0cHV0IFZHQSBpcyBjb25uZWN0ZWQgdG8gcGlwZSBu b25lCihJSSkgaW50ZWwoMCk6ICAgT3V0cHV0IExWRFMgaXMgY29ubmVjdGVkIHRvIHBpcGUg QgooSUkpIGludGVsKDApOiBbZHJtXSBkbWEgY29udHJvbCBpbml0aWFsaXplZCwgdXNpbmcg SVJRIDE2CihJSSkgaW50ZWwoMCk6IFJhbmRSIDEuMiBlbmFibGVkLCBpZ25vcmUgdGhlIGZv bGxvd2luZyBSYW5kUiBkaXNhYmxlZCBtZXNzYWdlLgooSUkpIGludGVsKDApOiBEUE1TIGVu YWJsZWQKKElJKSBpbnRlbCgwKTogU2V0IHVwIG92ZXJsYXkgdmlkZW8KKElJKSBpbnRlbCgw KTogZGlyZWN0IHJlbmRlcmluZzogRW5hYmxlZAooLS0pIFJhbmRSIGRpc2FibGVkCihJSSkg SW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVuc2lvbiBNSVQtU0hNCihJSSkgSW5pdGlhbGl6 aW5nIGJ1aWx0LWluIGV4dGVuc2lvbiBYSW5wdXRFeHRlbnNpb24KKElJKSBJbml0aWFsaXpp bmcgYnVpbHQtaW4gZXh0ZW5zaW9uIFhURVNUCihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWlu IGV4dGVuc2lvbiBYS0VZQk9BUkQKKElJKSBJbml0aWFsaXppbmcgYnVpbHQtaW4gZXh0ZW5z aW9uIFhJTkVSQU1BCihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVuc2lvbiBYRklY RVMKKElJKSBJbml0aWFsaXppbmcgYnVpbHQtaW4gZXh0ZW5zaW9uIFJFTkRFUgooSUkpIElu aXRpYWxpemluZyBidWlsdC1pbiBleHRlbnNpb24gUkFORFIKKElJKSBJbml0aWFsaXppbmcg YnVpbHQtaW4gZXh0ZW5zaW9uIENPTVBPU0lURQooSUkpIEluaXRpYWxpemluZyBidWlsdC1p biBleHRlbnNpb24gREFNQUdFCihJSSkgSW5pdGlhbGl6aW5nIGJ1aWx0LWluIGV4dGVuc2lv biBYRVZJRQpkcm1PcGVuRGV2aWNlOiBub2RlIG5hbWUgaXMgL2Rldi9kcmkvY2FyZDAKZHJt T3BlbkRldmljZTogb3BlbiByZXN1bHQgaXMgMTAsIChPSykKZHJtT3BlbkJ5QnVzaWQ6IFNl YXJjaGluZyBmb3IgQnVzSUQgcGNpOjAwMDA6MDA6MDIuMApkcm1PcGVuRGV2aWNlOiBub2Rl IG5hbWUgaXMgL2Rldi9kcmkvY2FyZDAKZHJtT3BlbkRldmljZTogb3BlbiByZXN1bHQgaXMg MTAsIChPSykKZHJtT3BlbkJ5QnVzaWQ6IGRybU9wZW5NaW5vciByZXR1cm5zIDEwCmRybU9w ZW5CeUJ1c2lkOiBkcm1HZXRCdXNpZCByZXBvcnRzIHBjaTowMDAwOjAwOjAyLjAKKElJKSBB SUdMWDogZW5hYmxlZCBHTFhfTUVTQV9jb3B5X3N1Yl9idWZmZXIKKElJKSBBSUdMWDogZW5h YmxlZCBHTFhfU0dJX3N3YXBfY29udHJvbCBhbmQgR0xYX01FU0Ffc3dhcF9jb250cm9sCihJ SSkgQUlHTFg6IGVuYWJsZWQgR0xYX3RleHR1cmVfZnJvbV9waXhtYXAgd2l0aCBkcml2ZXIg c3VwcG9ydAooSUkpIEFJR0xYOiBMb2FkZWQgYW5kIGluaXRpYWxpemVkIC91c3IvbG9jYWwv bGliL2RyaS9pOTE1X2RyaS5zbwooSUkpIEdMWDogSW5pdGlhbGl6ZWQgRFJJIEdMIHByb3Zp ZGVyIGZvciBzY3JlZW4gMAooSUkpIGludGVsKDApOiBTZXR0aW5nIHNjcmVlbiBwaHlzaWNh bCBzaXplIHRvIDMwNSB4IDE4MwooRUUpIGludGVsKDApOiB1bmRlcnJ1biBvbiBwaXBlIEIh CihJSSkgY29uZmlnL2hhbDogQWRkaW5nIGlucHV0IGRldmljZSBBVCBLZXlib2FyZAooSUkp IExvYWRNb2R1bGU6ICJrYmQiCgooSUkpIExvYWRpbmcgL3Vzci9sb2NhbC9saWIveG9yZy9t b2R1bGVzL2lucHV0Ly9rYmRfZHJ2LnNvCihJSSkgTW9kdWxlIGtiZDogdmVuZG9yPSJYLk9y ZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDEuNS4zLCBtb2R1bGUgdmVyc2lvbiA9IDEu My4yCglNb2R1bGUgY2xhc3M6IFguT3JnIFhJbnB1dCBEcml2ZXIKCUFCSSBjbGFzczogWC5P cmcgWElucHV0IGRyaXZlciwgdmVyc2lvbiAyLjEKKCoqKSBBVCBLZXlib2FyZDogYWx3YXlz IHJlcG9ydHMgY29yZSBldmVudHMKKCoqKSBPcHRpb24gIlByb3RvY29sIiAic3RhbmRhcmQi CigqKikgQVQgS2V5Ym9hcmQ6IFByb3RvY29sOiBzdGFuZGFyZAooKiopIE9wdGlvbiAiQXV0 b1JlcGVhdCIgIjUwMCAzMCIKKCoqKSBPcHRpb24gIlhrYlJ1bGVzIiAieG9yZyIKKCoqKSBB VCBLZXlib2FyZDogWGtiUnVsZXM6ICJ4b3JnIgooKiopIE9wdGlvbiAiWGtiTW9kZWwiICJw YzEwNSIKKCoqKSBBVCBLZXlib2FyZDogWGtiTW9kZWw6ICJwYzEwNSIKKCoqKSBPcHRpb24g IlhrYkxheW91dCIgInVzLHJ1IgooKiopIEFUIEtleWJvYXJkOiBYa2JMYXlvdXQ6ICJ1cyxy dSIKKCoqKSBPcHRpb24gIlhrYlZhcmlhbnQiICIsd2lua2V5cyIKKCoqKSBBVCBLZXlib2Fy ZDogWGtiVmFyaWFudDogIix3aW5rZXlzIgooKiopIE9wdGlvbiAiWGtiT3B0aW9ucyIgImdy cDphbHRfc2hpZnRfdG9nZ2xlLGdycF9sZWQ6bnVtLGdycDpzd2l0Y2giCigqKikgQVQgS2V5 Ym9hcmQ6IFhrYk9wdGlvbnM6ICJncnA6YWx0X3NoaWZ0X3RvZ2dsZSxncnBfbGVkOm51bSxn cnA6c3dpdGNoIgooKiopIE9wdGlvbiAiQ3VzdG9tS2V5Y29kZXMiICJvZmYiCigqKikgQVQg S2V5Ym9hcmQ6IEN1c3RvbUtleWNvZGVzIGRpc2FibGVkCihJSSkgWElOUFVUOiBBZGRpbmcg ZXh0ZW5kZWQgaW5wdXQgZGV2aWNlICJBVCBLZXlib2FyZCIgKHR5cGU6IEtFWUJPQVJEKQoo SUkpIGNvbmZpZy9oYWw6IEFkZGluZyBpbnB1dCBkZXZpY2UgUFMvMiBNb3VzZQooSUkpIExv YWRNb2R1bGU6ICJtb3VzZSIKCihJSSkgTG9hZGluZyAvdXNyL2xvY2FsL2xpYi94b3JnL21v ZHVsZXMvaW5wdXQvL21vdXNlX2Rydi5zbwooSUkpIE1vZHVsZSBtb3VzZTogdmVuZG9yPSJY Lk9yZyBGb3VuZGF0aW9uIgoJY29tcGlsZWQgZm9yIDEuNS4zLCBtb2R1bGUgdmVyc2lvbiA9 IDEuNC4wCglNb2R1bGUgY2xhc3M6IFguT3JnIFhJbnB1dCBEcml2ZXIKCUFCSSBjbGFzczog WC5PcmcgWElucHV0IGRyaXZlciwgdmVyc2lvbiAyLjEKKCoqKSBPcHRpb24gIlByb3RvY29s IiAiYXV0byIKKCoqKSBQUy8yIE1vdXNlOiBEZXZpY2U6ICIvZGV2L3BzbTAiCigqKikgUFMv MiBNb3VzZTogUHJvdG9jb2w6ICJhdXRvIgooKiopIFBTLzIgTW91c2U6IGFsd2F5cyByZXBv cnRzIGNvcmUgZXZlbnRzCigqKikgT3B0aW9uICJEZXZpY2UiICIvZGV2L3BzbTAiCig9PSkg UFMvMiBNb3VzZTogRW11bGF0ZTNCdXR0b25zLCBFbXVsYXRlM1RpbWVvdXQ6IDUwCigqKikg T3B0aW9uICJaQXhpc01hcHBpbmciICI0IDUgNiA3IgooKiopIFBTLzIgTW91c2U6IFpBeGlz TWFwcGluZzogYnV0dG9ucyA0LCA1LCA2IGFuZCA3CigqKikgUFMvMiBNb3VzZTogQnV0dG9u czogMTEKKCoqKSBQUy8yIE1vdXNlOiBTZW5zaXRpdml0eTogMQooSUkpIFhJTlBVVDogQWRk aW5nIGV4dGVuZGVkIGlucHV0IGRldmljZSAiUFMvMiBNb3VzZSIgKHR5cGU6IE1PVVNFKQoo SUkpIFBTLzIgTW91c2U6IFNldHVwQXV0bzogaHcuaWZ0eXBlIGlzIDMsIGh3Lm1vZGVsIGlz IDQKKElJKSBQUy8yIE1vdXNlOiBTZXR1cEF1dG86IHByb3RvY29sIGlzIElNUFMvMgooSUkp IFBTLzIgTW91c2U6IHBzMkVuYWJsZURhdGFSZXBvcnRpbmc6IHN1Y2NlZWRlZAooV1cpIGZj bnRsKDEyLCBPX0FTWU5DKTogSW5hcHByb3ByaWF0ZSBpb2N0bCBmb3IgZGV2aWNlCihJSSkg aW50ZWwoMCk6IEkyQyBidXMgIkNSVEREQ19BIiBpbml0aWFsaXplZC4KKElJKSBpbnRlbCgw KTogSTJDIGJ1cyAiQ1JURERDX0EiIHJlbW92ZWQuCihJSSkgaW50ZWwoMCk6IEVESUQgdmVu ZG9yICJTRUMiLCBwcm9kIGlkIDIyMDgyCihJSSkgaW50ZWwoMCk6IFByaW50aW5nIEREQyBn YXRoZXJlZCBNb2RlbGluZXM6CihJSSkgaW50ZWwoMCk6IE1vZGVsaW5lICIxMjgweDc2OCJ4 MC4wICAgNjguOTMgIDEyODAgMTI5NiAxMzQ0IDE0MDggIDc2OCA3NzEgNzc3IDgxNiAtaHN5 bmMgLXZzeW5jICg0OS4wIGtIeikKKElJKSBpbnRlbCgwKTogRURJRCB2ZW5kb3IgIlNFQyIs IHByb2QgaWQgMjIwODIKKEVFKSBpbnRlbCgwKTogdW5kZXJydW4gb24gcGlwZSBCIQooSUkp IGludGVsKDApOiBJMkMgYnVzICJDUlRERENfQSIgaW5pdGlhbGl6ZWQuCihJSSkgaW50ZWwo MCk6IEkyQyBidXMgIkNSVEREQ19BIiByZW1vdmVkLgooSUkpIGludGVsKDApOiBFRElEIHZl bmRvciAiU0VDIiwgcHJvZCBpZCAyMjA4MgooSUkpIGludGVsKDApOiBQcmludGluZyBEREMg Z2F0aGVyZWQgTW9kZWxpbmVzOgooSUkpIGludGVsKDApOiBNb2RlbGluZSAiMTI4MHg3Njgi eDAuMCAgIDY4LjkzICAxMjgwIDEyOTYgMTM0NCAxNDA4ICA3NjggNzcxIDc3NyA4MTYgLWhz eW5jIC12c3luYyAoNDkuMCBrSHopCihJSSkgaW50ZWwoMCk6IEVESUQgdmVuZG9yICJTRUMi LCBwcm9kIGlkIDIyMDgyCihJSSkgaW50ZWwoMCk6IEkyQyBidXMgIkNSVEREQ19BIiBpbml0 aWFsaXplZC4KKElJKSBpbnRlbCgwKTogSTJDIGJ1cyAiQ1JURERDX0EiIHJlbW92ZWQuCihJ SSkgaW50ZWwoMCk6IEVESUQgdmVuZG9yICJTRUMiLCBwcm9kIGlkIDIyMDgyCihJSSkgaW50 ZWwoMCk6IFByaW50aW5nIEREQyBnYXRoZXJlZCBNb2RlbGluZXM6CihJSSkgaW50ZWwoMCk6 IE1vZGVsaW5lICIxMjgweDc2OCJ4MC4wICAgNjguOTMgIDEyODAgMTI5NiAxMzQ0IDE0MDgg IDc2OCA3NzEgNzc3IDgxNiAtaHN5bmMgLXZzeW5jICg0OS4wIGtIeikKKElJKSBpbnRlbCgw KTogRURJRCB2ZW5kb3IgIlNFQyIsIHByb2QgaWQgMjIwODIKKElJKSBpbnRlbCgwKTogSTJD IGJ1cyAiQ1JURERDX0EiIGluaXRpYWxpemVkLgooSUkpIGludGVsKDApOiBJMkMgYnVzICJD UlRERENfQSIgcmVtb3ZlZC4KKElJKSBpbnRlbCgwKTogRURJRCB2ZW5kb3IgIlNFQyIsIHBy b2QgaWQgMjIwODIKKElJKSBpbnRlbCgwKTogUHJpbnRpbmcgRERDIGdhdGhlcmVkIE1vZGVs aW5lczoKKElJKSBpbnRlbCgwKTogTW9kZWxpbmUgIjEyODB4NzY4IngwLjAgICA2OC45MyAg MTI4MCAxMjk2IDEzNDQgMTQwOCAgNzY4IDc3MSA3NzcgODE2IC1oc3luYyAtdnN5bmMgKDQ5 LjAga0h6KQooSUkpIGludGVsKDApOiBFRElEIHZlbmRvciAiU0VDIiwgcHJvZCBpZCAyMjA4 Mgo= --------------080002040604030602090705-- From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 08:23:37 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC333106566C for ; Mon, 16 Feb 2009 08:23:37 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 949E78FC13 for ; Mon, 16 Feb 2009 08:23:37 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 4C2E33F129; Mon, 16 Feb 2009 08:23:36 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n1G8Nb3F014699; Mon, 16 Feb 2009 08:23:37 GMT (envelope-from phk@critter.freebsd.dk) To: Gvozdikov Veniamin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 16 Feb 2009 15:11:55 +0700." <49991FCB.7020803@gmail.com> Date: Mon, 16 Feb 2009 08:23:37 +0000 Message-ID: <14695.1234772617@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-x11@freebsd.org, kde@freebsd.org, current@freebsd.org, Robert Noland Subject: Re: completely stopped work wm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 08:23:38 -0000 In message <49991FCB.7020803@gmail.com>, Gvozdikov Veniamin writes: >X server stops responding to any action. when you press backspace >+ ctrl + alt no reaction is also not rolled ctr + alt + F1. completely >stopped work wm. I connected via ssh and watched what was happening >at that time. Put this in your xorg.conf: Section "ServerFlags" Option "AllowEmptyInput" "off" EndSection -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 08:24:08 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7884A106564A for ; Mon, 16 Feb 2009 08:24:08 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwmtas06p.mx.bigpond.com (nschwmtas06p.mx.bigpond.com [61.9.189.152]) by mx1.freebsd.org (Postfix) with ESMTP id EE3888FC1A for ; Mon, 16 Feb 2009 08:24:07 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwotgx03p.mx.bigpond.com ([124.188.162.219]) by nschwmtas06p.mx.bigpond.com with ESMTP id <20090216082406.THCK3101.nschwmtas06p.mx.bigpond.com@nschwotgx03p.mx.bigpond.com> for ; Mon, 16 Feb 2009 08:24:06 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nschwotgx03p.mx.bigpond.com with ESMTP id <20090216082401.DSEF7357.nschwotgx03p.mx.bigpond.com@areilly.bpa.nu> for ; Mon, 16 Feb 2009 08:24:01 +0000 Received: (qmail 76721 invoked by uid 501); 16 Feb 2009 08:23:32 -0000 Date: Mon, 16 Feb 2009 19:23:31 +1100 From: Andrew Reilly To: Joe Marcus Clarke Message-ID: <20090216082331.GA74847@duncan.reilly.home> References: <20090215223428.GA74071@citylink.fud.org.nz> <4998D027.5030501@protected-networks.net> <1234752963.42927.171.camel@shumai.marcuscom.com> <20090216061856.GD70145@duncan.reilly.home> <1234765678.42927.191.camel@shumai.marcuscom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1234765678.42927.191.camel@shumai.marcuscom.com> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150202.499922A1.006D,ss=1,fgs=0 Cc: Michael Butler , current@freebsd.org Subject: hal care, feeding and integration (was Re: USB2 and USB mice) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 08:24:08 -0000 On Mon, Feb 16, 2009 at 01:27:58AM -0500, Joe Marcus Clarke wrote: > The FreeBSD GNOME Team maintains a user-level hal FAQ at > http://www.freebsd.org/gnome/docs/halfaq.html . We don't have any I've found that one, and must read it again, as reading it did not result in me being able to mount a CD-ROM (I have submitted a PR with the copious output requested on that page). The caveat about GEOM labels with spaces: does that apply to CD-ROM images with a space in the label name? That appears to have been squashed out at the GEOM Label stage, but it's not something that I can do anything about: the CD-ROM is what it is. > FreeBSD-specific development docs. However, the hal spec at > http://people.freedesktop.org/~david/hal-spec/hal-spec.html is a good > starting point. That looks like exactly what I was looking for, thanks! I'll give it a good read. > > Also, is there a FreeBSD hald-meister, whos job it is to ensure that hal > > continues to reflect up-to-date FreeBSD capabilities and mechanisms? > > That's me. I'd really appreciate help as I don't have all of the > requisite hardware or expertise in all of the subsystems. For instance, > we're completely lacking SD/MMC, firewire, and printer functionality. I've got a firewire external drive and a firewire cardbus reader, which could be useful for testing? The drive seems to work fine from /etc/fstab. Haven't tried to get hal to use it, yet. Haven't tried the cardbus reader (mostly use that on my MacBook.) > Some of this has been posted on FreeBSD's idea page for some time. I'll have a look, thanks. >From an overall philosiphical perspective, is hal something that we're going to be able to get comfortable with, as Unix admins? Is it a piece of infrastructure that has just been missing from traditional Unix, or does the move for Xorg and Gnome to require it mean that those projects are "doing it wrong"? If the former, do you see a time when we'll want a pure-BSD version that just ships as a standard part of the base system, or will it always be a port? Cheers, Andrew. From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 08:42:34 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D817106564A for ; Mon, 16 Feb 2009 08:42:34 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 71CE68FC1A for ; Mon, 16 Feb 2009 08:42:33 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA03204; Mon, 16 Feb 2009 10:42:15 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1] helo=edge.pp.kiev.ua) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1LYz3P-0005bf-Bl; Mon, 16 Feb 2009 10:42:15 +0200 Message-ID: <499926E4.3060207@icyb.net.ua> Date: Mon, 16 Feb 2009 10:42:12 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090114) MIME-Version: 1.0 To: Andrew Reilly References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <49983868.5010107@incunabulum.net> <20090215182420.774b90c3@ernst.jennejohn.org> <49985807.805@protected-networks.net> <49985AEE.1010709@gmx.de> <20090216060716.GC70145@duncan.reilly.home> In-Reply-To: <20090216060716.GC70145@duncan.reilly.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Christoph Mallon , Michael Butler , Bruce Simpson , freebsd-current@freebsd.org Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 08:42:34 -0000 on 16/02/2009 08:07 Andrew Reilly said the following: > On Sun, Feb 15, 2009 at 07:11:58PM +0100, Christoph Mallon wrote: >> Michael Butler schrieb: >>> .. stops C++ from mangling the prototyped functions so they'll link >>> correctly but does it temporarily disable the "reserved word" tests? >>> Should it? ;-) >> No, it doesn't. extern $STRING (the standard only requires "C" and >> "C++", but there can be more) just changes the linkage of declarations >> (name mangling, calling convention). > > I've always wondered: why does the extern "C" {} cruft have to > be pushed into all C headers, rather than being wrapped around > the #include <> lines in the C++ source that includes them? > Then you wouldn't need the #ifdef __cplusplus conditional, > because you already know that it's C++ code. Common usage seems > to have it backwards, but I assume that there must be a reason. > Since this thread has already strayed beyond the original topic, I now feel free to participate in it again. I think that there are two approaches. Current C++ code for our kernel does exactly what you say - puts extern C around inclusion of system headers. But if someone decides to purposefully provide C headers that are both C and C++ -friendly, then they typically put conditional extern into the headers. I wouldn't suggest doing that to FreeBSD headers though (yet). -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 08:57:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DE9C3106566B for ; Mon, 16 Feb 2009 08:57:26 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 148658FC13 for ; Mon, 16 Feb 2009 08:57:25 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA03708; Mon, 16 Feb 2009 10:57:14 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1] helo=edge.pp.kiev.ua) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1LYzHu-0005cD-5G; Mon, 16 Feb 2009 10:57:14 +0200 Message-ID: <49992A68.8010702@icyb.net.ua> Date: Mon, 16 Feb 2009 10:57:12 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090114) MIME-Version: 1.0 To: Andrew Reilly References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <499835BE.3000705@gmx.de> <8EF8771C-76D8-4556-96B2-B97B35573CBD@mac.com> <49986ABB.5040207@gmx.de> <20090216055602.GA70145@duncan.reilly.home> In-Reply-To: <20090216055602.GA70145@duncan.reilly.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Christoph Mallon , Marcel Moolenaar , Bruce Simpson , freebsd-current@freebsd.org Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 08:57:27 -0000 on 16/02/2009 07:56 Andrew Reilly said the following: > The problem with C++ isn't really the functions that it > provides, it's the functions that it doesn't. Personally, I'd > like C++ a *lot* better if it required a garbage collecting > runtime. The problem with the way it works at the moment is > that object creation interacts with argument promotion and > constructors (and C++'s ability to grab references inside the > guts of objects, whch it inherited from C) in such a way that > you can have temporary object creation inserted by the compiler > in the middle of an expression, with no way to ensure that > the resulting object is reaped at the right time. And that's > because the compiler can't, in general, know what is the right > thing to do: if the called function retains the reference in a > long-lived structure then the temporary should be constructed > on the heap, and explicitly freed somewhere else. If it isn't > retained, then the temporary object should be collected as > the expression scope is exited. Since there's no way for the > compiler to make that call, you almost inevitably wind up with > either memory leaks or you constrain yourself to operate with a > restricted, not-quite-object-oriented style, which can't really > be enforced by the compiler. I don't need to mention what a bad > idea memory leaks are in kernel mode, right? This is the first time in my life that I hear about temporary objects on the heap and/or memory leaks through temporary objects. Either you are remembering a bug in some ancient C++ compiler or you are referring to some buggy code. As to the conversions through constructors, conversion operators and implicit type promotions - I personally had much less incidents because of that than I had incidents in C with passing/casting something incorrect via void*. This is to say that C++ is far from perfect and there are languages that are much better than it, but C is even (much) less perfect. And of all languages out there, I think, that C++ comes closest to a definition of "enriched", "better", "fortified" C. Which implies much lower entry barrier (and possibility for limited/gradual introduction). -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 09:02:59 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A762D106566B for ; Mon, 16 Feb 2009 09:02:59 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntqsrv02p.mx.bigpond.com (nskntqsrv02p.mx.bigpond.com [61.9.168.234]) by mx1.freebsd.org (Postfix) with ESMTP id B8C8D8FC18 for ; Mon, 16 Feb 2009 09:02:54 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntotgx02p.mx.bigpond.com ([124.188.162.219]) by nskntmtas06p.mx.bigpond.com with ESMTP id <20090216061915.MPHZ17301.nskntmtas06p.mx.bigpond.com@nskntotgx02p.mx.bigpond.com> for ; Mon, 16 Feb 2009 06:19:15 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nskntotgx02p.mx.bigpond.com with ESMTP id <20090216061914.BJCS12531.nskntotgx02p.mx.bigpond.com@areilly.bpa.nu> for ; Mon, 16 Feb 2009 06:19:14 +0000 Received: (qmail 72004 invoked by uid 501); 16 Feb 2009 06:18:56 -0000 Date: Mon, 16 Feb 2009 17:18:56 +1100 From: Andrew Reilly To: Joe Marcus Clarke Message-ID: <20090216061856.GD70145@duncan.reilly.home> References: <20090215223428.GA74071@citylink.fud.org.nz> <4998D027.5030501@protected-networks.net> <1234752963.42927.171.camel@shumai.marcuscom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1234752963.42927.171.camel@shumai.marcuscom.com> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150202.49990563.0086,ss=1,fgs=0 Cc: Michael Butler , current@freebsd.org Subject: Re: USB2 and USB mice X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 09:03:00 -0000 On Sun, Feb 15, 2009 at 09:56:03PM -0500, Joe Marcus Clarke wrote: > Hal doesn't yet work with usb2. You will need to statically configure > your input devices in xorg.conf until support is added. It seems that hal seems to be a vitally important part of most desktop systems, now. What's the best source of documentation on both the external whys and wherefores and the day-to-day care and feeding? Also, is there a FreeBSD hald-meister, whos job it is to ensure that hal continues to reflect up-to-date FreeBSD capabilities and mechanisms? Cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 12:48:01 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B14E8106566C; Mon, 16 Feb 2009 12:48:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 8D2018FC0A; Mon, 16 Feb 2009 12:48:01 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 2F2A546B32; Mon, 16 Feb 2009 07:48:01 -0500 (EST) Date: Mon, 16 Feb 2009 12:48:01 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: current@FreeBSD.org, net@FreeBSD.org In-Reply-To: <20080526110543.J26343@fledge.watson.org> Message-ID: References: <20080526110543.J26343@fledge.watson.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Subject: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed (was: Re: Wiki page for non-MPSAFE network stack de-orbit scheduling) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 12:48:02 -0000 (Bcc to arch@) On Mon, 26 May 2008, Robert Watson wrote: > Just to keep track of things: > > http://wiki.freebsd.org/NONMPSAFE_DEORBIT Delayed by about six months, the merge and switch to the new USB stack in 8.x means that we're now fairly close to being able to pick up this project again. The goal remains to eliminate IFF_NEEDSGIANT, which is (mostly) the last piece of non-MPSAFE compatibility infrastructure in the network stack in -CURRENT. I removed support for non-MPSAFE network protocols before 7.0, and this is the support for non-MPSAFE network device drivers. As of the current moment in HEAD, the following drivers are flagged wth IFF_NEEDSGIANT: General network device drivers that still require Giant: if_ar if_ray if_sl if_sr Old USB network device drivers: if_axe if_cdce if_cue if_kue if_rue if_rum if_udav if_upgt if_ural if_urtw if_zyd Network device drivers intimately tangled with the old TTY code: if_cx if_ppp lf_sl A network device driver that appears to conditionally use IFF_NEEDSGIANT for the purposes of (sometimes) interacting with the old USB code: if_ndis The following schedule is proposed, assuming nothing goes horribly wrong with the new USB code in the next few weeks, and remaining nits relating to USB network and 802.11 drivers are handled: 16 February 2009 HEADS UP to lists (this e-mail) 01 March 2009 Disable build of all IFF_NEEDSGIANT drivers in 8.x 01 April 2009 Remove all IFF_NEEDSGIANT drivers from 8.x In the next couple of weeks, I'd like to resolve the status of (and eliminate) the if_ndis conditional use of IFF_NEEDSGIANT. There's also a chance that if_sl will get updated by Ed and myself to work with the new locking and TTY world orders -- the lock is easy, but the TTY update takes a bit of work. Perhaps someone will feel moved to do this for if_ppp and possibly if_cx as well. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 14:25:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B91D106566B for ; Mon, 16 Feb 2009 14:25:48 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id A69058FC13 for ; Mon, 16 Feb 2009 14:25:47 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl109-226.kln.forthnet.gr [77.49.228.226]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id n1GEPe2j015790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Feb 2009 16:25:45 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n1GEPdLN002876; Mon, 16 Feb 2009 16:25:39 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n1GEPd4F002875; Mon, 16 Feb 2009 16:25:39 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: freebsd-current@freebsd.org Date: Mon, 16 Feb 2009 16:25:39 +0200 Message-ID: <87mycme9wc.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: n1GEPe2j015790 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.874, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.53, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: Hans Petter Selasky , Andrew Thompson Subject: usb2 moused issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 14:25:48 -0000 I just rebuild my kernel after flipping the switch to usb2 in my kernel config file: diff -r 657f71f9e39c -r 82c23c5ef94e sys/i386/conf/KOBE --- a/sys/i386/conf/KOBE Mon Feb 16 02:52:01 2009 +0200 +++ b/sys/i386/conf/KOBE Mon Feb 16 03:01:42 2009 +0200 @@ -179,17 +179,18 @@ #options ALTQ_NOPCC # Required if the TSC is unusable #options ALTQ_DEBUG -# USB support -device uhci # UHCI PCI->USB interface -device ohci # OHCI PCI->USB interface -device ehci # EHCI PCI->USB interface (USB 2.0) -device usb # USB Bus (required) -#device udbp # USB Double Bulk Pipe devices -device ugen # Generic -device uhid # "Human Interface Devices" -device ukbd # Keyboard -device umass # Disks/Mass storage - Requires scbus and da -device ums # Mouse -# USB Serial devices -device ucom # Generic com ttys -device u3g # USB-based 3G modems (Option, Huawei, Sierra) +# USB core support +device usb2_core +# USB controller support +device usb2_controller +device usb2_controller_ehci +device usb2_controller_ohci +device usb2_controller_uhci +# USB mass storage support +device usb2_storage +device usb2_storage_mass +# USB input device support +device usb2_input +device usb2_input_hid +device usb2_input_kbd +device usb2_input_ms The external USB mouse seems to be recognized file: [ dmesg output with hw.usb2.ums.debug=1 ] Feb 16 16:19:00 kobe kernel: ugen4.2: at usbus4 Feb 16 16:19:00 kobe kernel: ums0: on usbus4 Feb 16 16:19:00 kobe kernel: ums0: 5 buttons and [XYZ] coordinates Feb 16 16:19:00 kobe kernel: ums_attach:582: sc=0xc63c7000 Feb 16 16:19:00 kobe kernel: ums_attach:583: X 48/8 Feb 16 16:19:00 kobe kernel: ums_attach:584: Y 56/8 Feb 16 16:19:00 kobe kernel: ums_attach:585: Z 64/8 Feb 16 16:19:00 kobe kernel: ums_attach:586: T 0/0 Feb 16 16:19:00 kobe kernel: ums_attach:587: W 0/0 Feb 16 16:19:00 kobe kernel: ums_attach:591: B1 40/1 Feb 16 16:19:00 kobe kernel: ums_attach:591: B2 41/1 Feb 16 16:19:00 kobe kernel: ums_attach:591: B3 42/1 Feb 16 16:19:00 kobe kernel: ums_attach:591: B4 43/1 Feb 16 16:19:00 kobe kernel: ums_attach:591: B5 44/1 Feb 16 16:19:00 kobe kernel: ums_attach:593: size=2, id=19 Feb 16 16:19:00 kobe kernel: Symlink: ums0 -> usb4.2.0.16 I have enabled `moused_nondefault_enable' in my rc.conf too, and I see that moused is launched for the external usb mouse: [rc.conf] moused_nondefault_enable="YES" moused_enable="YES" moused_flags="-3" moused_ums0_flags="" moused_port="/dev/psm0" moused_type="auto" [processes running] # ps xauww | sed -n -e 1p -e '/ sed/d' -e /moused/p USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 1309 0.0 0.0 3376 1484 ?? Ss 3:54PM 0:05.01 /usr/sbin/moused -3 -p /dev/psm0 -t auto root 1773 0.0 0.0 3376 1492 ?? Is 3:59PM 0:00.00 /usr/sbin/moused -p /dev/ums0 -t auto -I /var/run/moused.ums0.pid But moving the usb mouse doesn't result in any pointer movement, either in a console tty or under X11. Is this a known bug of usb2 mouse support, or just a local config error? From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 14:29:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 248EB10656C1 for ; Mon, 16 Feb 2009 14:29:35 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 731338FC17 for ; Mon, 16 Feb 2009 14:29:34 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl109-226.kln.forthnet.gr [77.49.228.226]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id n1GETPOK015972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Feb 2009 16:29:30 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n1GETPh6002896; Mon, 16 Feb 2009 16:29:25 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n1GETPbK002895; Mon, 16 Feb 2009 16:29:25 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: freebsd-current@freebsd.org References: <87mycme9wc.fsf@kobe.laptop> Date: Mon, 16 Feb 2009 16:29:24 +0200 In-Reply-To: <87mycme9wc.fsf@kobe.laptop> (Giorgos Keramidas's message of "Mon, 16 Feb 2009 16:25:39 +0200") Message-ID: <87ab8me9q3.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: n1GETPOK015972 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.874, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.53, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: Hans Petter Selasky , Andrew Thompson Subject: Re: usb2 moused issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 14:29:35 -0000 On Mon, 16 Feb 2009 16:25:39 +0200, Giorgos Keramidas wrote: > But moving the usb mouse doesn't result in any pointer movement, either > in a console tty or under X11. > > Is this a known bug of usb2 mouse support, or just a local config error? I should have added that the touchpad of the same laptop works fine, and that's what I am using now. From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 15:09:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48395106566C; Mon, 16 Feb 2009 15:09:39 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id D5C668FC08; Mon, 16 Feb 2009 15:09:38 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n1GF9ZPi090212; Mon, 16 Feb 2009 08:09:35 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <499981AF.9030204@samsco.org> Date: Mon, 16 Feb 2009 08:09:35 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: scsi@freebsd.org, FreeBSD Current , FreeBSD Stable X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: Subject: HEADS UP: More CAM fixes. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 15:09:40 -0000 FWI. I need lots of testing on this. Only real SCSI controllers, please, not RAID controllers (except for MPT-SCSI with integrated mirroring). So Adaptec, LSI, Symbios, Buslogic, Tekram, SME, etc, users, please try this and get back to me. The patch should apply to FreeBSD 7 as well. FreeBSD 6 is only affected by this problem when CAM_NEW_TRAN_CODE is enabled. Scott -------- Original Message -------- Subject: svn commit: r188671 - head/sys/cam Date: Mon, 16 Feb 2009 14:57:15 +0000 (UTC) From: Scott Long To: src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, svn-src-head@FreeBSD.org Author: scottl Date: Mon Feb 16 14:57:15 2009 New Revision: 188671 URL: http://svn.freebsd.org/changeset/base/188671 Log: Fix parallel SCSI negotiation in the CAM_NEW_TRAN_CODE world order. Overzealous sanity checks were locking the sync_rate and offset values to zero, thanks to a twisty maze of recursive code. Modified: head/sys/cam/cam_xpt.c Modified: head/sys/cam/cam_xpt.c ============================================================================== --- head/sys/cam/cam_xpt.c Mon Feb 16 14:38:52 2009 (r188670) +++ head/sys/cam/cam_xpt.c Mon Feb 16 14:57:15 2009 (r188671) @@ -6679,9 +6679,7 @@ xpt_set_transfer_settings(struct ccb_tra if (((device->flags & CAM_DEV_INQUIRY_DATA_VALID) != 0 && (inq_data->flags & SID_Sync) == 0 && cts->type == CTS_TYPE_CURRENT_SETTINGS) - || ((cpi.hba_inquiry & PI_SDTR_ABLE) == 0) - || (spi->sync_offset == 0) - || (spi->sync_period == 0)) { + || ((cpi.hba_inquiry & PI_SDTR_ABLE) == 0)) { /* Force async */ spi->sync_period = 0; spi->sync_offset = 0; @@ -6729,7 +6727,8 @@ xpt_set_transfer_settings(struct ccb_tra if (spi->bus_width == 0) spi->ppr_options = 0; - if ((spi->flags & CTS_SPI_FLAGS_DISC_ENB) == 0) { + if ((spi->valid & CTS_SPI_VALID_DISC) + && ((spi->flags & CTS_SPI_FLAGS_DISC_ENB) == 0)) { /* * Can't tag queue without disconnection. */ From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 16:46:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2755E1065675; Mon, 16 Feb 2009 16:46:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id F13FD8FC0A; Mon, 16 Feb 2009 16:46:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1GGkFMf014901; Mon, 16 Feb 2009 11:46:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1GGkE2s014822; Mon, 16 Feb 2009 11:46:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 106537302F; Mon, 16 Feb 2009 11:46:12 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090216164613.106537302F@freebsd-current.sentex.ca> Date: Mon, 16 Feb 2009 11:46:12 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 16:46:19 -0000 TB --- 2009-02-16 14:53:27 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-16 14:53:27 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-02-16 14:53:27 - cleaning the object tree TB --- 2009-02-16 14:53:57 - cvsupping the source tree TB --- 2009-02-16 14:53:57 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-02-16 14:54:05 - building world TB --- 2009-02-16 14:54:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-16 14:54:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-16 14:54:05 - TARGET=pc98 TB --- 2009-02-16 14:54:05 - TARGET_ARCH=i386 TB --- 2009-02-16 14:54:05 - TZ=UTC TB --- 2009-02-16 14:54:05 - __MAKE_CONF=/dev/null TB --- 2009-02-16 14:54:05 - cd /src TB --- 2009-02-16 14:54:05 - /usr/bin/make -B buildworld >>> World build started on Mon Feb 16 14:54:07 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Feb 16 16:14:26 UTC 2009 TB --- 2009-02-16 16:14:26 - generating LINT kernel config TB --- 2009-02-16 16:14:26 - cd /src/sys/pc98/conf TB --- 2009-02-16 16:14:26 - /usr/bin/make -B LINT TB --- 2009-02-16 16:14:26 - building LINT kernel TB --- 2009-02-16 16:14:26 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-16 16:14:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-16 16:14:26 - TARGET=pc98 TB --- 2009-02-16 16:14:26 - TARGET_ARCH=i386 TB --- 2009-02-16 16:14:26 - TZ=UTC TB --- 2009-02-16 16:14:26 - __MAKE_CONF=/dev/null TB --- 2009-02-16 16:14:26 - cd /src TB --- 2009-02-16 16:14:26 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Feb 16 16:14:26 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon Feb 16 16:42:47 UTC 2009 TB --- 2009-02-16 16:42:47 - building GENERIC kernel TB --- 2009-02-16 16:42:47 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-16 16:42:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-16 16:42:47 - TARGET=pc98 TB --- 2009-02-16 16:42:47 - TARGET_ARCH=i386 TB --- 2009-02-16 16:42:47 - TZ=UTC TB --- 2009-02-16 16:42:47 - __MAKE_CONF=/dev/null TB --- 2009-02-16 16:42:47 - cd /src TB --- 2009-02-16 16:42:47 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Feb 16 16:42:47 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/cam/cam_xpt.c:6064: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6129: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6174: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6285: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6318: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6356: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6359: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6368: warning: unused variable 'text' *** Error code 1 Stop in /obj/pc98/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-16 16:46:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-16 16:46:12 - ERROR: failed to build GENERIC kernel TB --- 2009-02-16 16:46:12 - 5440.60 user 511.27 system 6765.23 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 17:22:41 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB62F10656F5; Mon, 16 Feb 2009 17:22:41 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id AF8F28FC14; Mon, 16 Feb 2009 17:22:41 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id E63B6FF34; Tue, 17 Feb 2009 06:22:40 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8z95NqqBFjd; Tue, 17 Feb 2009 06:22:37 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Tue, 17 Feb 2009 06:22:37 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 6BADD1142A; Tue, 17 Feb 2009 06:22:37 +1300 (NZDT) Date: Mon, 16 Feb 2009 09:22:37 -0800 From: Andrew Thompson To: current@freebsd.org Message-ID: <20090216172237.GD4723@citylink.fud.org.nz> References: <20090215223428.GA74071@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090215223428.GA74071@citylink.fud.org.nz> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: usb@freebsd.org Subject: Re: HEADSUP: USB2 now default in GENERIC kernels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 17:22:43 -0000 On Sun, Feb 15, 2009 at 02:34:28PM -0800, Andrew Thompson wrote: > Hi, > > > The GENERIC kernels for all architectures now default to the new USB2 stack. No > kernel config options or code have been removed so if a problem arises please > report it and optionally revert to the old USB stack. > > IMPORTANT NOTES: > > 1. If you are loading USB kernel modules then ensure that these are also > changed over, eg uftdi.ko -> usb2_serial_ftdi.ko. You can not load oldUSB > modules with the GENERIC kernels. > > 2. If you have a custom kernel that includes GENERIC as a base, you need to > ensure that any additional usb devices that you specify are changed over. > > 3. The USB2 kernel options and module names are _temporary_. The next stage is > to move the USB2 code into its permanent location in the source tree and at > that point will take over the well established naming. (ie, usb, ehci, ohci, > uftdi). There will be no changes going from FreeBSD 7.x -> 8.0 > > 4. Once (3) is complete the oldUSB code will still be usable until much closer > to the 8.0 branch. 5. Some people have noted that the latest xorg 7.4 requires the hal daemon to enumerate the input devices. hal does not (yet) work with USB2 so if you find that the keyboard/mouse are not working in X then try adding the following line to the ServerLayout section in xorg.conf Option "AllowEmptyInput" "off" regards, Andrew From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 17:50:33 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CA493106566B for ; Mon, 16 Feb 2009 17:50:33 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe10.swipnet.se [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id 61C5F8FC1F for ; Mon, 16 Feb 2009 17:50:33 +0000 (UTC) (envelope-from hselasky@freebsd.org) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=zl5XP_tDmJZPdJmkyEIA:9 a=PJBV58NlGC-994YECO4A:7 a=RQ04kOghs4JbBCsJ43ohSRulbI0A:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe10.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1027787221; Mon, 16 Feb 2009 17:50:29 +0100 From: Hans Petter Selasky To: Giorgos Keramidas Date: Mon, 16 Feb 2009 17:52:56 +0100 User-Agent: KMail/1.9.7 References: <87mycme9wc.fsf@kobe.laptop> In-Reply-To: <87mycme9wc.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902161752.56998.hselasky@freebsd.org> Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: usb2 moused issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 17:50:34 -0000 On Monday 16 February 2009, Giorgos Keramidas wrote: > I just rebuild my kernel after flipping the switch to usb2 in my kernel > config file: > > [ dmesg output with hw.usb2.ums.debug=1 ] > Feb 16 16:19:00 kobe kernel: ugen4.2: at usbus4 > Feb 16 16:19:00 kobe kernel: ums0: (Model 1056), class 0/0, rev 2.00/0.07, addr 2> on usbus4 Feb 16 16:19:00 > kobe kernel: ums0: 5 buttons and [XYZ] coordinates Feb 16 16:19:00 kobe > kernel: ums_attach:582: sc=0xc63c7000 If you "cat /dev/ums0" while having the debugging on, do you see anything? > > I have enabled `moused_nondefault_enable' in my rc.conf too, and I see > that moused is launched for the external usb mouse: > > [rc.conf] > moused_nondefault_enable="YES" > moused_enable="YES" > moused_flags="-3" > moused_ums0_flags="" > moused_port="/dev/psm0" ^^^/dev/ums0 > moused_type="auto" > > [processes running] > # ps xauww | sed -n -e 1p -e '/ sed/d' -e /moused/p > USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND > root 1309 0.0 0.0 3376 1484 ?? Ss 3:54PM 0:05.01 > /usr/sbin/moused -3 -p /dev/psm0 -t auto root 1773 0.0 0.0 3376 > 1492 ?? Is 3:59PM 0:00.00 /usr/sbin/moused -p /dev/ums0 -t auto -I > /var/run/moused.ums0.pid > > But moving the usb mouse doesn't result in any pointer movement, either > in a console tty or under X11. > > Is this a known bug of usb2 mouse support, or just a local config error? --HPS From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 18:00:48 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D82D106566B; Mon, 16 Feb 2009 18:00:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 23F1C8FC0C; Mon, 16 Feb 2009 18:00:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1GI0iqd072010; Mon, 16 Feb 2009 13:00:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1GI0i5D046718; Mon, 16 Feb 2009 13:00:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DCFE17302F; Mon, 16 Feb 2009 13:00:43 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090216180043.DCFE17302F@freebsd-current.sentex.ca> Date: Mon, 16 Feb 2009 13:00:43 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 18:00:49 -0000 TB --- 2009-02-16 15:32:49 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-16 15:32:49 - starting HEAD tinderbox run for ia64/ia64 TB --- 2009-02-16 15:32:49 - cleaning the object tree TB --- 2009-02-16 15:33:29 - cvsupping the source tree TB --- 2009-02-16 15:33:29 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/ia64/ia64/supfile TB --- 2009-02-16 15:33:36 - building world TB --- 2009-02-16 15:33:36 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-16 15:33:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-16 15:33:36 - TARGET=ia64 TB --- 2009-02-16 15:33:36 - TARGET_ARCH=ia64 TB --- 2009-02-16 15:33:36 - TZ=UTC TB --- 2009-02-16 15:33:36 - __MAKE_CONF=/dev/null TB --- 2009-02-16 15:33:36 - cd /src TB --- 2009-02-16 15:33:36 - /usr/bin/make -B buildworld >>> World build started on Mon Feb 16 15:33:39 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Feb 16 17:21:00 UTC 2009 TB --- 2009-02-16 17:21:00 - generating LINT kernel config TB --- 2009-02-16 17:21:00 - cd /src/sys/ia64/conf TB --- 2009-02-16 17:21:00 - /usr/bin/make -B LINT TB --- 2009-02-16 17:21:00 - building LINT kernel TB --- 2009-02-16 17:21:00 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-16 17:21:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-16 17:21:00 - TARGET=ia64 TB --- 2009-02-16 17:21:00 - TARGET_ARCH=ia64 TB --- 2009-02-16 17:21:00 - TZ=UTC TB --- 2009-02-16 17:21:00 - __MAKE_CONF=/dev/null TB --- 2009-02-16 17:21:00 - cd /src TB --- 2009-02-16 17:21:00 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Feb 16 17:21:01 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon Feb 16 17:57:56 UTC 2009 TB --- 2009-02-16 17:57:56 - building GENERIC kernel TB --- 2009-02-16 17:57:56 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-16 17:57:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-16 17:57:56 - TARGET=ia64 TB --- 2009-02-16 17:57:56 - TARGET_ARCH=ia64 TB --- 2009-02-16 17:57:56 - TZ=UTC TB --- 2009-02-16 17:57:56 - __MAKE_CONF=/dev/null TB --- 2009-02-16 17:57:56 - cd /src TB --- 2009-02-16 17:57:56 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Feb 16 17:57:56 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/cam/cam_xpt.c:6064: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6129: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6174: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6285: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6318: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6356: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6359: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6368: warning: unused variable 'text' *** Error code 1 Stop in /obj/ia64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-16 18:00:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-16 18:00:43 - ERROR: failed to build GENERIC kernel TB --- 2009-02-16 18:00:43 - 7382.50 user 504.55 system 8874.45 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 18:08:23 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C5E5106566C for ; Mon, 16 Feb 2009 18:08:23 +0000 (UTC) (envelope-from marcus@freebsd.org) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by mx1.freebsd.org (Postfix) with ESMTP id 050BC8FC1D for ; Mon, 16 Feb 2009 18:08:22 +0000 (UTC) (envelope-from marcus@freebsd.org) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n1GHo9rp005473; Mon, 16 Feb 2009 12:50:09 -0500 (EST) Received: from [64.102.221.205] (dhcp-64-102-221-205.cisco.com [64.102.221.205]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n1GHnqSh002012; Mon, 16 Feb 2009 12:50:03 -0500 (EST) Message-ID: <4999A746.60009@freebsd.org> Date: Mon, 16 Feb 2009 12:49:58 -0500 From: Joe Marcus Clarke Organization: FreeBSD, Inc. User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Andrew Reilly References: <20090215223428.GA74071@citylink.fud.org.nz> <4998D027.5030501@protected-networks.net> <1234752963.42927.171.camel@shumai.marcuscom.com> <20090216061856.GD70145@duncan.reilly.home> <1234765678.42927.191.camel@shumai.marcuscom.com> <20090216082331.GA74847@duncan.reilly.home> In-Reply-To: <20090216082331.GA74847@duncan.reilly.home> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Michael Butler , current@freebsd.org Subject: Re: hal care, feeding and integration (was Re: USB2 and USB mice) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 18:08:23 -0000 Andrew Reilly wrote: > On Mon, Feb 16, 2009 at 01:27:58AM -0500, Joe Marcus Clarke wrote: >> The FreeBSD GNOME Team maintains a user-level hal FAQ at >> http://www.freebsd.org/gnome/docs/halfaq.html . We don't have any > > I've found that one, and must read it again, as reading it did > not result in me being able to mount a CD-ROM (I have submitted > a PR with the copious output requested on that page). The > caveat about GEOM labels with spaces: does that apply to CD-ROM > images with a space in the label name? That appears to have > been squashed out at the GEOM Label stage, but it's not > something that I can do anything about: the CD-ROM is what it > is. If the output of sysctl -b kern.geom.conftxt produces names with spaces, then hal will not be able to mount the volume. > >> FreeBSD-specific development docs. However, the hal spec at >> http://people.freedesktop.org/~david/hal-spec/hal-spec.html is a good >> starting point. > > That looks like exactly what I was looking for, thanks! I'll > give it a good read. > >>> Also, is there a FreeBSD hald-meister, whos job it is to ensure that hal >>> continues to reflect up-to-date FreeBSD capabilities and mechanisms? >> That's me. I'd really appreciate help as I don't have all of the >> requisite hardware or expertise in all of the subsystems. For instance, >> we're completely lacking SD/MMC, firewire, and printer functionality. > > I've got a firewire external drive and a firewire cardbus > reader, which could be useful for testing? The drive seems to > work fine from /etc/fstab. Haven't tried to get hal to use it, > yet. Haven't tried the cardbus reader (mostly use that on my > MacBook.) Unless people are willing to ship me hardware, I will have to rely on them for developing the underlying support code in hal. > >> Some of this has been posted on FreeBSD's idea page for some time. > > I'll have a look, thanks. > >>From an overall philosiphical perspective, is hal something that > we're going to be able to get comfortable with, as Unix admins? > Is it a piece of infrastructure that has just been missing from > traditional Unix, or does the move for Xorg and Gnome to require > it mean that those projects are "doing it wrong"? If the > former, do you see a time when we'll want a pure-BSD version > that just ships as a standard part of the base system, or will > it always be a port? Hal (of the upcoming DeviceKit) will always be a port. Joe > > Cheers, > > Andrew. > -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 18:14:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AF9B1065672; Mon, 16 Feb 2009 18:14:24 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 73A728FC08; Mon, 16 Feb 2009 18:14:23 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl109-226.kln.forthnet.gr [77.49.228.226]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-5) with ESMTP id n1GIECOr003630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Feb 2009 20:14:18 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n1GIEBE8006334; Mon, 16 Feb 2009 20:14:11 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n1GIEBCN006333; Mon, 16 Feb 2009 20:14:11 +0200 (EET) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Hans Petter Selasky References: <87mycme9wc.fsf@kobe.laptop> <200902161752.56998.hselasky@freebsd.org> Date: Mon, 16 Feb 2009 20:14:11 +0200 In-Reply-To: <200902161752.56998.hselasky@freebsd.org> (Hans Petter Selasky's message of "Mon, 16 Feb 2009 17:52:56 +0100") Message-ID: <87wsbqmeq4.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: n1GIECOr003630 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.494, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL -0.10, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: usb2 moused issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 18:14:24 -0000 On Mon, 16 Feb 2009 17:52:56 +0100, Hans Petter Selasky wrote: > On Monday 16 February 2009, Giorgos Keramidas wrote: >> I just rebuild my kernel after flipping the switch to usb2 in my kernel >> config file: > >> >> [ dmesg output with hw.usb2.ums.debug=1 ] >> Feb 16 16:19:00 kobe kernel: ugen4.2: at usbus4 >> Feb 16 16:19:00 kobe kernel: ums0: > (Model 1056), class 0/0, rev 2.00/0.07, addr 2> on usbus4 Feb 16 16:19:00 >> kobe kernel: ums0: 5 buttons and [XYZ] coordinates Feb 16 16:19:00 kobe >> kernel: ums_attach:582: sc=0xc63c7000 > > If you "cat /dev/ums0" while having the debugging on, do you see anything? Hmm, there's a dmesg line saying that: Feb 16 20:09:51 kobe kernel: Symlink: ums0 -> usb4.2.0.16 but there is no ums0 symlink in /dev: # ls -ld ums* ls: ums*: No such file or directory # Maybe this is why moused fails to work when it is launched from devd. >> I have enabled `moused_nondefault_enable' in my rc.conf too, and I see >> that moused is launched for the external usb mouse: >> >> [rc.conf] >> moused_nondefault_enable="YES" >> moused_enable="YES" >> moused_flags="-3" >> moused_ums0_flags="" >> moused_port="/dev/psm0" > > ^^^/dev/ums0 That's the device name for the touchpad port. The default devd.conf file passes `ums0' to /etc/rc.d/moused start ... so it shouldn't matter. From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 18:28:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3ECCD1065769; Mon, 16 Feb 2009 18:28:00 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.freebsd.org (Postfix) with ESMTP id 71C6C8FC1E; Mon, 16 Feb 2009 18:27:59 +0000 (UTC) (envelope-from hselasky@freebsd.org) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=6I5d2MoRAAAA:8 a=oMb63xJ287YHEnRK-VwA:9 a=4J6AYEB33BvVxGokvnQA:7 a=H9h2D9fkYQfCae59Q-LPVA7avZEA:4 a=LY0hPdMaydYA:10 a=SV7veod9ZcQA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe05.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1094564586; Mon, 16 Feb 2009 19:27:57 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Mon, 16 Feb 2009 19:30:24 +0100 User-Agent: KMail/1.9.7 References: <87mycme9wc.fsf@kobe.laptop> <200902161752.56998.hselasky@freebsd.org> <87wsbqmeq4.fsf@kobe.laptop> In-Reply-To: <87wsbqmeq4.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902161930.25235.hselasky@freebsd.org> Cc: Giorgos Keramidas , Andrew Thompson Subject: Re: usb2 moused issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 18:28:01 -0000 On Monday 16 February 2009, Giorgos Keramidas wrote: > On Mon, 16 Feb 2009 17:52:56 +0100, Hans Petter Selasky wrote: > > On Monday 16 February 2009, Giorgos Keramidas wrote: > >> I just rebuild my kernel after flipping the switch to usb2 in my kernel > >> config file: > >> > >> > >> [ dmesg output with hw.usb2.ums.debug=1 ] > >> Feb 16 16:19:00 kobe kernel: ugen4.2: at usbus4 > >> Feb 16 16:19:00 kobe kernel: ums0: >> 3000 (Model 1056), class 0/0, rev 2.00/0.07, addr 2> on usbus4 Feb 16 > >> 16:19:00 kobe kernel: ums0: 5 buttons and [XYZ] coordinates Feb 16 > >> 16:19:00 kobe kernel: ums_attach:582: sc=0xc63c7000 > > > > If you "cat /dev/ums0" while having the debugging on, do you see > > anything? > > Hmm, there's a dmesg line saying that: > > Feb 16 20:09:51 kobe kernel: Symlink: ums0 -> usb4.2.0.16 > > but there is no ums0 symlink in /dev: > > # ls -ld ums* > ls: ums*: No such file or directory > # Hi, The device is invisible. You should be able to cat it, if it's not already opened. --HPS From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 18:31:44 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4039410657AC for ; Mon, 16 Feb 2009 18:31:44 +0000 (UTC) (envelope-from haro@kgt.co.jp) Received: from smtp1.dcns.ne.jp (smtp1.dcns.ne.jp [203.178.100.134]) by mx1.freebsd.org (Postfix) with SMTP id C1ED78FC0A for ; Mon, 16 Feb 2009 18:31:43 +0000 (UTC) (envelope-from haro@kgt.co.jp) Received: (qmail 30042 invoked from network); 17 Feb 2009 03:05:03 +0900 Received: from unknown (HELO localhost) (210.238.26.2) by smtp1.dcns.ne.jp with SMTP; 17 Feb 2009 03:05:03 +0900 Date: Tue, 17 Feb 2009 03:05:01 +0900 (JST) Message-Id: <20090217.030501.240656213.haro@h4.dion.ne.jp> To: thompsa@FreeBSD.org From: Munehiro Matsuda In-Reply-To: <20090216172237.GD4723@citylink.fud.org.nz> References: <20090215223428.GA74071@citylink.fud.org.nz> <20090216172237.GD4723@citylink.fud.org.nz> X-Mailer: Mew version 5.2 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: usb@freebsd.org, current@freebsd.org Subject: Re: HEADSUP: USB2 now default in GENERIC kernels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 18:31:46 -0000 From: Andrew Thompson Date: Mon, 16 Feb 2009 09:22:37 -0800 ::On Sun, Feb 15, 2009 at 02:34:28PM -0800, Andrew Thompson wrote: ::> Hi, ::> ::> ::> The GENERIC kernels for all architectures now default to the new USB2 stack. No ::> kernel config options or code have been removed so if a problem arises please ::> report it and optionally revert to the old USB stack. ::> ::> IMPORTANT NOTES: ::> ::> 1. If you are loading USB kernel modules then ensure that these are also ::> changed over, eg uftdi.ko -> usb2_serial_ftdi.ko. You can not load oldUSB ::> modules with the GENERIC kernels. ::> ::> 2. If you have a custom kernel that includes GENERIC as a base, you need to ::> ensure that any additional usb devices that you specify are changed over. ::> ::> 3. The USB2 kernel options and module names are _temporary_. The next stage is ::> to move the USB2 code into its permanent location in the source tree and at ::> that point will take over the well established naming. (ie, usb, ehci, ohci, ::> uftdi). There will be no changes going from FreeBSD 7.x -> 8.0 ::> ::> 4. Once (3) is complete the oldUSB code will still be usable until much closer ::> to the 8.0 branch. :: ::5. Some people have noted that the latest xorg 7.4 requires the hal ::daemon to enumerate the input devices. hal does not (yet) work with USB2 ::so if you find that the keyboard/mouse are not working in X then try ::adding the following line to the ServerLayout section in xorg.conf :: :: Option "AllowEmptyInput" "off" Hi Andrew, As I wrote in other thread, the description in /usr/ports/UPDATING is wrong. It's not "ServerLayout" section, but shuold be "ServerFlags" section as follows: Section "ServerFlags" Option "AllowEmptyInput" "off" EndSection Hope this helps, Haro =------------------------------------------------------------------------------ _ _ Munehiro (haro) Matsuda -|- /_\ |_|_| Internet Solution Dept., KGT Inc. /|\ |_| |_|_| From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 18:37:00 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1ECD9106564A; Mon, 16 Feb 2009 18:37:00 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id E820B8FC16; Mon, 16 Feb 2009 18:36:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1GIavLn029324; Mon, 16 Feb 2009 13:36:57 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1GIavh4060497; Mon, 16 Feb 2009 13:36:57 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DFDB77302F; Mon, 16 Feb 2009 13:36:56 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090216183656.DFDB77302F@freebsd-current.sentex.ca> Date: Mon, 16 Feb 2009 13:36:56 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 18:37:01 -0000 TB --- 2009-02-16 16:46:14 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-16 16:46:14 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-02-16 16:46:14 - cleaning the object tree TB --- 2009-02-16 16:46:45 - cvsupping the source tree TB --- 2009-02-16 16:46:45 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-02-16 16:46:53 - building world TB --- 2009-02-16 16:46:53 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-16 16:46:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-16 16:46:53 - TARGET=powerpc TB --- 2009-02-16 16:46:53 - TARGET_ARCH=powerpc TB --- 2009-02-16 16:46:53 - TZ=UTC TB --- 2009-02-16 16:46:53 - __MAKE_CONF=/dev/null TB --- 2009-02-16 16:46:53 - cd /src TB --- 2009-02-16 16:46:53 - /usr/bin/make -B buildworld >>> World build started on Mon Feb 16 16:46:54 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Feb 16 18:10:09 UTC 2009 TB --- 2009-02-16 18:10:09 - generating LINT kernel config TB --- 2009-02-16 18:10:09 - cd /src/sys/powerpc/conf TB --- 2009-02-16 18:10:09 - /usr/bin/make -B LINT TB --- 2009-02-16 18:10:10 - building LINT kernel TB --- 2009-02-16 18:10:10 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-16 18:10:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-16 18:10:10 - TARGET=powerpc TB --- 2009-02-16 18:10:10 - TARGET_ARCH=powerpc TB --- 2009-02-16 18:10:10 - TZ=UTC TB --- 2009-02-16 18:10:10 - __MAKE_CONF=/dev/null TB --- 2009-02-16 18:10:10 - cd /src TB --- 2009-02-16 18:10:10 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Feb 16 18:10:10 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon Feb 16 18:34:32 UTC 2009 TB --- 2009-02-16 18:34:32 - building GENERIC kernel TB --- 2009-02-16 18:34:32 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-16 18:34:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-16 18:34:32 - TARGET=powerpc TB --- 2009-02-16 18:34:32 - TARGET_ARCH=powerpc TB --- 2009-02-16 18:34:32 - TZ=UTC TB --- 2009-02-16 18:34:32 - __MAKE_CONF=/dev/null TB --- 2009-02-16 18:34:32 - cd /src TB --- 2009-02-16 18:34:32 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Feb 16 18:34:32 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/cam/cam_xpt.c:6064: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6129: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6174: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6285: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6318: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6356: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6359: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6368: warning: unused variable 'text' *** Error code 1 Stop in /obj/powerpc/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-16 18:36:56 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-16 18:36:56 - ERROR: failed to build GENERIC kernel TB --- 2009-02-16 18:36:56 - 5418.35 user 463.61 system 6642.12 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 18:41:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A6491065676; Mon, 16 Feb 2009 18:41:21 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mx1.freebsd.org (Postfix) with ESMTP id DE5EA8FC4E; Mon, 16 Feb 2009 18:41:19 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so1117859ywt.13 for ; Mon, 16 Feb 2009 10:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7gDw1X/tFo4Xs/UJTH6Lc26C2JnyK5HpP/Mu4I5zpBc=; b=ssAEVDld+GA+g8pf7ZsIfPZ4wZvZtGmuSm8U2Cfn5KBZXY9ma/YDDrt4bs7+udgAf9 sDuidWh7WyiOEMBW0gffy4RfT5E3r3JTzfhElFun7lJkndLbDYBDWzb9AgGYkf8c7gDu gZ4qla0NxgO6xyuY7E8kG32wv5jzOrWiUGauE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wHQDwURDDhD1Fz6vOrnjB1nVaooz+Sq3AJhSmtTPqa/xM1PNZrTcxkYjZ8rgVacLrm 0o+5M/xitosqgIH9LGi1u2JX5hPWOes4LqOYQ8Iq9HVTzBouHrs2TcRD17nj7nie8Mq+ bIiGvWygjdVunODB8N1nzHacxOxMqJSraH0IM= MIME-Version: 1.0 Received: by 10.151.44.14 with SMTP id w14mr366750ybj.111.1234809679385; Mon, 16 Feb 2009 10:41:19 -0800 (PST) In-Reply-To: <200902161930.25235.hselasky@freebsd.org> References: <87mycme9wc.fsf@kobe.laptop> <200902161752.56998.hselasky@freebsd.org> <87wsbqmeq4.fsf@kobe.laptop> <200902161930.25235.hselasky@freebsd.org> Date: Mon, 16 Feb 2009 10:41:19 -0800 Message-ID: From: Maksim Yevmenkin To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Giorgos Keramidas , Andrew Thompson Subject: Re: usb2 moused issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 18:41:22 -0000 On Mon, Feb 16, 2009 at 10:30 AM, Hans Petter Selasky wrote: > On Monday 16 February 2009, Giorgos Keramidas wrote: >> On Mon, 16 Feb 2009 17:52:56 +0100, Hans Petter Selasky > wrote: >> > On Monday 16 February 2009, Giorgos Keramidas wrote: >> >> I just rebuild my kernel after flipping the switch to usb2 in my kernel >> >> config file: >> >> >> >> >> >> [ dmesg output with hw.usb2.ums.debug=1 ] >> >> Feb 16 16:19:00 kobe kernel: ugen4.2: at usbus4 >> >> Feb 16 16:19:00 kobe kernel: ums0: > >> 3000 (Model 1056), class 0/0, rev 2.00/0.07, addr 2> on usbus4 Feb 16 >> >> 16:19:00 kobe kernel: ums0: 5 buttons and [XYZ] coordinates Feb 16 >> >> 16:19:00 kobe kernel: ums_attach:582: sc=0xc63c7000 >> > >> > If you "cat /dev/ums0" while having the debugging on, do you see >> > anything? >> >> Hmm, there's a dmesg line saying that: >> >> Feb 16 20:09:51 kobe kernel: Symlink: ums0 -> usb4.2.0.16 >> >> but there is no ums0 symlink in /dev: >> >> # ls -ld ums* >> ls: ums*: No such file or directory >> # > > Hi, > > The device is invisible. You should be able to cat it, if it's not already > opened. yeah, i've been bitten by the same "invisible device node" problem while converting ubtbcmfw(4) to usb2. for example, Feb 16 10:35:19 yak kernel: ugen0.2: at usbus0 Feb 16 10:35:19 yak kernel: ubtbcmfw0: on usbus0 Feb 16 10:35:19 yak kernel: Symlink: ubtbcmfw0 -> usb0.2.0.16 Feb 16 10:35:19 yak kernel: Symlink: ubtbcmfw0.1 -> usb0.2.0.16 Feb 16 10:35:19 yak kernel: Symlink: ubtbcmfw0.2 -> usb0.2.0.16 and > pwd /dev > ls -la usb0.2.* ls: No match. > ls -la usb0.2.0.16 crwxrwxrwx 1 root operator 0, 68 Feb 5 10:19 usb0.2.0.16 > ls -la ubtbcmfw* ls: No match. > ls -la ubtbcmfw0 crwxrwxrwx 1 root operator 0, 68 Feb 5 10:19 ubtbcmfw0 > ls -la ubtbcmfw0.* ls: No match. > ls -la ubtbcmfw0.1 crwxrwxrwx 1 root operator 0, 68 Feb 5 10:19 ubtbcmfw0.1 > ls -la ubtbcmfw0.2 crwxrwxrwx 1 root operator 0, 68 Feb 5 10:19 ubtbcmfw0.2 i suspect it probably has something to do with the way devfs cloning works (for example, i think, somewhat similar problem exists with /dev/tap, /dev/tun device nodes). of course, if one does not know that, the first reaction would be - wtf? where is my device nodes?! :) i wonder if there is any way to "fix" it... thanks, max From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 18:42:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F25A71065677; Mon, 16 Feb 2009 18:42:34 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 8957B8FC08; Mon, 16 Feb 2009 18:42:34 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id D1219FF32; Tue, 17 Feb 2009 07:42:33 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhSLPm+JF9iy; Tue, 17 Feb 2009 07:42:30 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Tue, 17 Feb 2009 07:42:30 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id C123B1142F; Tue, 17 Feb 2009 07:42:29 +1300 (NZDT) Date: Mon, 16 Feb 2009 10:42:29 -0800 From: Andrew Thompson To: Maksim Yevmenkin Message-ID: <20090216184229.GA12555@citylink.fud.org.nz> References: <87mycme9wc.fsf@kobe.laptop> <200902161752.56998.hselasky@freebsd.org> <87wsbqmeq4.fsf@kobe.laptop> <200902161930.25235.hselasky@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org, Hans Petter Selasky , Giorgos Keramidas Subject: Re: usb2 moused issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 18:42:35 -0000 On Mon, Feb 16, 2009 at 10:41:19AM -0800, Maksim Yevmenkin wrote: > On Mon, Feb 16, 2009 at 10:30 AM, Hans Petter Selasky > wrote: > > The device is invisible. You should be able to cat it, if it's not already > > opened. > > yeah, i've been bitten by the same "invisible device node" problem > while converting ubtbcmfw(4) to usb2. for example, > > Feb 16 10:35:19 yak kernel: ugen0.2: at usbus0 > Feb 16 10:35:19 yak kernel: ubtbcmfw0: dongle, class 224/1, rev 1.01/0.a0, addr 2> on usbus0 > Feb 16 10:35:19 yak kernel: Symlink: ubtbcmfw0 -> usb0.2.0.16 > Feb 16 10:35:19 yak kernel: Symlink: ubtbcmfw0.1 -> usb0.2.0.16 > Feb 16 10:35:19 yak kernel: Symlink: ubtbcmfw0.2 -> usb0.2.0.16 > > and > > > pwd > /dev > > > ls -la usb0.2.* > ls: No match. > > ls -la usb0.2.0.16 > crwxrwxrwx 1 root operator 0, 68 Feb 5 10:19 usb0.2.0.16 > > > ls -la ubtbcmfw* > ls: No match. > > ls -la ubtbcmfw0 > crwxrwxrwx 1 root operator 0, 68 Feb 5 10:19 ubtbcmfw0 > > > ls -la ubtbcmfw0.* > ls: No match. > > > ls -la ubtbcmfw0.1 > crwxrwxrwx 1 root operator 0, 68 Feb 5 10:19 ubtbcmfw0.1 > > ls -la ubtbcmfw0.2 > crwxrwxrwx 1 root operator 0, 68 Feb 5 10:19 ubtbcmfw0.2 > > i suspect it probably has something to do with the way devfs cloning > works (for example, i think, somewhat similar problem exists with > /dev/tap, /dev/tun device nodes). of course, if one does not know > that, the first reaction would be - wtf? where is my device nodes?! :) > > i wonder if there is any way to "fix" it... A fix is in progress. Andrew From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 18:53:52 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5411C1065673; Mon, 16 Feb 2009 18:53:52 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 165398FC12; Mon, 16 Feb 2009 18:53:52 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 6670AFF3B; Tue, 17 Feb 2009 07:53:51 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Md2FmJEMSkun; Tue, 17 Feb 2009 07:53:47 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Tue, 17 Feb 2009 07:53:47 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 3F0D71142B; Tue, 17 Feb 2009 07:53:47 +1300 (NZDT) Date: Mon, 16 Feb 2009 10:53:47 -0800 From: Andrew Thompson To: Munehiro Matsuda Message-ID: <20090216185347.GB12555@citylink.fud.org.nz> References: <20090215223428.GA74071@citylink.fud.org.nz> <20090216172237.GD4723@citylink.fud.org.nz> <20090217.030501.240656213.haro@h4.dion.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090217.030501.240656213.haro@h4.dion.ne.jp> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: usb@freebsd.org, current@freebsd.org Subject: Re: HEADSUP: USB2 now default in GENERIC kernels X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 18:53:52 -0000 On Tue, Feb 17, 2009 at 03:05:01AM +0900, Munehiro Matsuda wrote: > ::5. Some people have noted that the latest xorg 7.4 requires the hal > ::daemon to enumerate the input devices. hal does not (yet) work with USB2 > ::so if you find that the keyboard/mouse are not working in X then try > ::adding the following line to the ServerLayout section in xorg.conf > :: > :: Option "AllowEmptyInput" "off" > > Hi Andrew, > > As I wrote in other thread, the description in /usr/ports/UPDATING is wrong. > It's not "ServerLayout" section, but shuold be "ServerFlags" section as > follows: > > Section "ServerFlags" > Option "AllowEmptyInput" "off" > EndSection Actually if you look at xorg.conf(5) it can be either. I'll keep the same as the ports UPDATING file for consistency. Andrew From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 19:48:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E07F1065672; Mon, 16 Feb 2009 19:48:28 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id D8A7A8FC12; Mon, 16 Feb 2009 19:48:27 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl109-226.kln.forthnet.gr [77.49.228.226]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-6) with ESMTP id n1GJmJLA018270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Feb 2009 21:48:24 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n1GJmJg0007600; Mon, 16 Feb 2009 21:48:19 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n1GJmIbT007599; Mon, 16 Feb 2009 21:48:18 +0200 (EET) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Hans Petter Selasky References: <87mycme9wc.fsf@kobe.laptop> <200902161752.56998.hselasky@freebsd.org> <87wsbqmeq4.fsf@kobe.laptop> <200902161930.25235.hselasky@freebsd.org> Date: Mon, 16 Feb 2009 21:48:18 +0200 In-Reply-To: <200902161930.25235.hselasky@freebsd.org> (Hans Petter Selasky's message of "Mon, 16 Feb 2009 19:30:24 +0100") Message-ID: <87tz6u6u4d.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: n1GJmJLA018270 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.49, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL -0.09, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: usb2 moused issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 19:48:28 -0000 On Mon, 16 Feb 2009 19:30:24 +0100, Hans Petter Selasky wrote: >On Monday 16 February 2009, Giorgos Keramidas wrote: >>On Mon, 16 Feb 2009 17:52:56 +0100, Hans Petter Selasky wrote: >>> On Monday 16 February 2009, Giorgos Keramidas wrote: >>>> I just rebuild my kernel after flipping the switch to usb2 in my kernel >>>> config file: >>>> >>>> [ dmesg output with hw.usb2.ums.debug=1 ] >>>> Feb 16 16:19:00 kobe kernel: ugen4.2: at usbus4 >>>> Feb 16 16:19:00 kobe kernel: ums0: >>> 3000 (Model 1056), class 0/0, rev 2.00/0.07, addr 2> on usbus4 Feb 16 >>>> 16:19:00 kobe kernel: ums0: 5 buttons and [XYZ] coordinates Feb 16 >>>> 16:19:00 kobe kernel: ums_attach:582: sc=0xc63c7000 >>> >>> If you "cat /dev/ums0" while having the debugging on, do you see >>> anything? >> >> Hmm, there's a dmesg line saying that: >> >> Feb 16 20:09:51 kobe kernel: Symlink: ums0 -> usb4.2.0.16 >> >> but there is no ums0 symlink in /dev: >> >> # ls -ld ums* >> ls: ums*: No such file or directory >> # > > Hi, The device is invisible. You should be able to cat it, if it's not > already opened. It was opened by moused, so I killed it. There's no output when I attach and move the mouse, other than the following in syslog: Feb 16 21:37:45 kobe kernel: ugen4.2: at usbus4 Feb 16 21:37:45 kobe kernel: ums0: on usbus4 Feb 16 21:37:45 kobe kernel: ums0: 5 buttons and [XYZ] coordinates Feb 16 21:37:45 kobe kernel: ums_attach:582: sc=0xc63cd800 Feb 16 21:37:45 kobe kernel: ums_attach:583: X 48/8 Feb 16 21:37:45 kobe kernel: ums_attach:584: Y 56/8 Feb 16 21:37:45 kobe kernel: ums_attach:585: Z 64/8 Feb 16 21:37:45 kobe kernel: ums_attach:586: T 0/0 Feb 16 21:37:45 kobe kernel: ums_attach:587: W 0/0 Feb 16 21:37:45 kobe kernel: ums_attach:591: B1 40/1 Feb 16 21:37:45 kobe kernel: ums_attach:591: B2 41/1 Feb 16 21:37:45 kobe kernel: ums_attach:591: B3 42/1 Feb 16 21:37:45 kobe kernel: ums_attach:591: B4 43/1 Feb 16 21:37:45 kobe kernel: ums_attach:591: B5 44/1 Feb 16 21:37:45 kobe kernel: ums_attach:593: size=2, id=19 Feb 16 21:37:45 kobe kernel: Symlink: ums0 -> usb4.2.0.16 When I kill the moused instance that is launched on attach by devd, start a `cat /dev/ums0' command and move the mouse, click a few buttons, etc. there is no output at all. From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 19:51:23 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 483AA106564A; Mon, 16 Feb 2009 19:51:23 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 1D7CF8FC16; Mon, 16 Feb 2009 19:51:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1GJpL1P091321; Mon, 16 Feb 2009 14:51:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1GJpKlZ006497; Mon, 16 Feb 2009 14:51:20 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D8B747302F; Mon, 16 Feb 2009 14:51:20 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090216195120.D8B747302F@freebsd-current.sentex.ca> Date: Mon, 16 Feb 2009 14:51:20 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 19:51:23 -0000 TB --- 2009-02-16 18:00:43 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-16 18:00:43 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-02-16 18:00:43 - cleaning the object tree TB --- 2009-02-16 18:01:23 - cvsupping the source tree TB --- 2009-02-16 18:01:23 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-02-16 18:01:32 - building world TB --- 2009-02-16 18:01:32 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-16 18:01:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-16 18:01:32 - TARGET=sparc64 TB --- 2009-02-16 18:01:32 - TARGET_ARCH=sparc64 TB --- 2009-02-16 18:01:32 - TZ=UTC TB --- 2009-02-16 18:01:32 - __MAKE_CONF=/dev/null TB --- 2009-02-16 18:01:32 - cd /src TB --- 2009-02-16 18:01:32 - /usr/bin/make -B buildworld >>> World build started on Mon Feb 16 18:01:34 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Feb 16 19:20:28 UTC 2009 TB --- 2009-02-16 19:20:28 - generating LINT kernel config TB --- 2009-02-16 19:20:28 - cd /src/sys/sparc64/conf TB --- 2009-02-16 19:20:28 - /usr/bin/make -B LINT TB --- 2009-02-16 19:20:28 - building LINT kernel TB --- 2009-02-16 19:20:28 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-16 19:20:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-16 19:20:28 - TARGET=sparc64 TB --- 2009-02-16 19:20:28 - TARGET_ARCH=sparc64 TB --- 2009-02-16 19:20:28 - TZ=UTC TB --- 2009-02-16 19:20:28 - __MAKE_CONF=/dev/null TB --- 2009-02-16 19:20:28 - cd /src TB --- 2009-02-16 19:20:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Feb 16 19:20:28 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon Feb 16 19:48:16 UTC 2009 TB --- 2009-02-16 19:48:16 - building GENERIC kernel TB --- 2009-02-16 19:48:16 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-16 19:48:16 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-16 19:48:16 - TARGET=sparc64 TB --- 2009-02-16 19:48:16 - TARGET_ARCH=sparc64 TB --- 2009-02-16 19:48:16 - TZ=UTC TB --- 2009-02-16 19:48:16 - __MAKE_CONF=/dev/null TB --- 2009-02-16 19:48:16 - cd /src TB --- 2009-02-16 19:48:16 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Feb 16 19:48:16 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/cam/cam_xpt.c:6064: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6129: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6174: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6285: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6318: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6356: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6359: warning: unused variable 'text' /src/sys/cam/cam_xpt.c:6368: warning: unused variable 'text' *** Error code 1 Stop in /obj/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-16 19:51:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-16 19:51:20 - ERROR: failed to build GENERIC kernel TB --- 2009-02-16 19:51:20 - 5350.48 user 474.51 system 6636.71 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 20:27:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1179F1065670; Mon, 16 Feb 2009 20:27:14 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id 400568FC1D; Mon, 16 Feb 2009 20:27:12 +0000 (UTC) (envelope-from hselasky@freebsd.org) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=6I5d2MoRAAAA:8 a=2qcBMZvGxZzZHGKL2pAA:9 a=xfmUQjtEfAw12lHetywA:7 a=MrA0QhdlrXxBfvkNIAZR4qlyjycA:4 a=LY0hPdMaydYA:10 a=SV7veod9ZcQA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 146257774; Mon, 16 Feb 2009 21:27:11 +0100 From: Hans Petter Selasky To: Giorgos Keramidas Date: Mon, 16 Feb 2009 21:29:38 +0100 User-Agent: KMail/1.9.7 References: <87mycme9wc.fsf@kobe.laptop> <200902161930.25235.hselasky@freebsd.org> <87tz6u6u4d.fsf@kobe.laptop> In-Reply-To: <87tz6u6u4d.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902162129.39156.hselasky@freebsd.org> Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: usb2 moused issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 20:27:14 -0000 On Monday 16 February 2009, Giorgos Keramidas wrote: > On Mon, 16 Feb 2009 19:30:24 +0100, Hans Petter Selasky wrote: > >On Monday 16 February 2009, Giorgos Keramidas wrote: > >>On Mon, 16 Feb 2009 17:52:56 +0100, Hans Petter Selasky wrote: > >>> On Monday 16 February 2009, Giorgos Keramidas wrote: > >>>> I just rebuild my kernel after flipping the switch to usb2 in my > >>>> kernel config file: > >>>> > >>>> [ dmesg output with hw.usb2.ums.debug=1 ] > >>>> Feb 16 16:19:00 kobe kernel: ugen4.2: at usbus4 > >>>> Feb 16 16:19:00 kobe kernel: ums0: >>>> 3000 (Model 1056), class 0/0, rev 2.00/0.07, addr 2> on usbus4 Feb 16 > >>>> 16:19:00 kobe kernel: ums0: 5 buttons and [XYZ] coordinates Feb 16 > >>>> 16:19:00 kobe kernel: ums_attach:582: sc=0xc63c7000 > >>> > >>> If you "cat /dev/ums0" while having the debugging on, do you see > >>> anything? > >> > >> Hmm, there's a dmesg line saying that: > >> > >> Feb 16 20:09:51 kobe kernel: Symlink: ums0 -> usb4.2.0.16 > >> > >> but there is no ums0 symlink in /dev: > >> > >> # ls -ld ums* > >> ls: ums*: No such file or directory > >> # > > > > Hi, The device is invisible. You should be able to cat it, if it's not > > already opened. > > It was opened by moused, so I killed it. There's no output when I > attach and move the mouse, other than the following in syslog: > Hi, What is "usbconfig" saying about your mouse? How is your mouse connected to the PC? Directly or through a USB HUB? --HPS From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 20:33:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12B4610657C1; Mon, 16 Feb 2009 20:33:31 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 728EA8FC1A; Mon, 16 Feb 2009 20:33:30 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl109-226.kln.forthnet.gr [77.49.228.226]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-6) with ESMTP id n1GKXKBk021893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Feb 2009 22:33:26 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n1GKXKRj008121; Mon, 16 Feb 2009 22:33:20 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n1GKXKsa008120; Mon, 16 Feb 2009 22:33:20 +0200 (EET) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Hans Petter Selasky References: <87mycme9wc.fsf@kobe.laptop> <200902161930.25235.hselasky@freebsd.org> <87tz6u6u4d.fsf@kobe.laptop> <200902162129.39156.hselasky@freebsd.org> Date: Mon, 16 Feb 2009 22:33:20 +0200 In-Reply-To: <200902162129.39156.hselasky@freebsd.org> (Hans Petter Selasky's message of "Mon, 16 Feb 2009 21:29:38 +0100") Message-ID: <877i3qunov.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: n1GKXKBk021893 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.489, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL -0.09, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: usb2 moused issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 20:33:31 -0000 On Mon, 16 Feb 2009 21:29:38 +0100, Hans Petter Selasky wrote: >> It was opened by moused, so I killed it. There's no output when I >> attach and move the mouse, other than the following in syslog: > What is "usbconfig" saying about your mouse? > How is your mouse connected to the PC? Directly or through a USB HUB? Directly connected to one of the USB ports of my laptop. usbconfig output is: $ sudo usbconfig Password: ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen2.1: at usbus2, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen3.1: at usbus3, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen4.1: at usbus4, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen5.1: at usbus5, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen6.1: at usbus6, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen4.2: at usbus4, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON usbus4 is attached as: usbus4: on uhci3 usbus4: 12Mbps Full Speed USB v1.0 From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 21:01:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 63D8B1065670 for ; Mon, 16 Feb 2009 21:01:22 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id DCE088FC13 for ; Mon, 16 Feb 2009 21:01:21 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 3776AA0716; Mon, 16 Feb 2009 22:01:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 2AD4FA0708; Mon, 16 Feb 2009 22:01:19 +0100 (CET) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 1753EA0700; Mon, 16 Feb 2009 22:01:19 +0100 (CET) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2HF443) with ESMTP id 2009021622011873-75034 ; Mon, 16 Feb 2009 22:01:18 +0100 Received: by wep4035 (sSMTP sendmail emulation); Mon, 16 Feb 2009 22:01:18 +0100 From: "Alexey Shuvaev" Date: Mon, 16 Feb 2009 22:01:18 +0100 To: Mike Makonnen Message-ID: <20090216210118.GA85984@wep4035.physik.uni-wuerzburg.de> References: <7d6fde3d0902150028n5f07ee55mc6026e1e4935eeb0@mail.gmail.com> <20090215153531.GA36438@wep4035.physik.uni-wuerzburg.de> <49998707.40205@gmail.com> MIME-Version: 1.0 In-Reply-To: <49998707.40205@gmail.com> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.18 (2008-05-17) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 02/16/2009 10:01:18 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 02/16/2009 10:01:19 PM, Serialize complete at 02/16/2009 10:01:19 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: Garrett Cooper , FreeBSD Current Subject: Re: Re: Annoyance with recent parallelism in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 21:01:22 -0000 On Mon, Feb 16, 2009 at 06:32:23PM +0300, Mike Makonnen wrote: > Alexey Shuvaev wrote: >> I have ntpd failing to resolve dns names. >> I have noticed this since appr. 1.350 of etc/defaults/rc.conf (12 days ago). >> I was hoping this will go away... >> >> [snip] >> >> Since, rc.d/defaultroute has the ability to wait for a >> default route to show up we can turn this knob back on >> without screwing subsequent daemons that expect to be >> able to talk to the outside world. >> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> Seems it is not the case... >> Interesting: setting background_dhclient="NO" does not >> solve the issue. Maybe something else was changed? >> My current 'workaroud' is synchronous_dhclient="YES" > > Please see my reply to the previous email in this thread. The problem > was not this commit, but the one before it. Your setup used to work as > a side-effect of rc.d/defaultroute's previous behavior. > Rev. 1.4 of rc.d/defaultroute. Ok, what should I do to have network daemons happy on startup? I am on a LAN so always have plugged-in cable. I do see on the console: msk0: link state changed to DOWN msk0: link state changed to UP got link msk0: link state changed to DOWN Starting Network: lo0 msk0. msk0: link state changed to UP msk0: link state changed to DOWN AFAIK some NIC (or PHY-s?) require some sort of reset to handle some events. Should I live with synchronous_dhclient="YES" or something else? Thanks, Alexey. From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 21:10:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0622106566B; Mon, 16 Feb 2009 21:10:11 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id E3B1F8FC20; Mon, 16 Feb 2009 21:10:10 +0000 (UTC) (envelope-from hselasky@freebsd.org) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=v1l4sCoM7rMA:10 a=-QvcQp4i0RcA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=6I5d2MoRAAAA:8 a=RZiKWns4g5JlHAIvUQoA:9 a=AnDaphoeXGsBqs3tIfIA:7 a=6Z4eNdd6jdU5p4871Nb5TRsIBvsA:4 a=LY0hPdMaydYA:10 a=SV7veod9ZcQA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 146274147; Mon, 16 Feb 2009 22:10:09 +0100 From: Hans Petter Selasky To: Giorgos Keramidas Date: Mon, 16 Feb 2009 22:12:36 +0100 User-Agent: KMail/1.9.7 References: <87mycme9wc.fsf@kobe.laptop> <200902161930.25235.hselasky@freebsd.org> <87tz6u6u4d.fsf@kobe.laptop> In-Reply-To: <87tz6u6u4d.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902162212.37027.hselasky@freebsd.org> Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: usb2 moused issue (Microsoft Wireless Optical) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 21:10:12 -0000 On Monday 16 February 2009, Giorgos Keramidas wrote: > On Mon, 16 Feb 2009 19:30:24 +0100, Hans Petter Selasky wrote: > >On Monday 16 February 2009, Giorgos Keramidas wrote: > >>On Mon, 16 Feb 2009 17:52:56 +0100, Hans Petter Selasky wrote: > >>> On Monday 16 February 2009, Giorgos Keramidas wrote: > >>>> I just rebuild my kernel after flipping the switch to usb2 in my > >>>> kernel config file: > >>>> > >>>> [ dmesg output with hw.usb2.ums.debug=1 ] > >>>> Feb 16 16:19:00 kobe kernel: ugen4.2: at usbus4 > >>>> Feb 16 16:19:00 kobe kernel: ums0: >>>> 3000 (Model 1056), class 0/0, rev 2.00/0.07, addr 2> on usbus4 Feb 16 > >>>> 16:19:00 kobe kernel: ums0: 5 buttons and [XYZ] coordinates Feb 16 > >>>> 16:19:00 kobe kernel: ums_attach:582: sc=0xc63c7000 > >>> > >>> If you "cat /dev/ums0" while having the debugging on, do you see > >>> anything? > >> > >> Hmm, there's a dmesg line saying that: > >> > >> Feb 16 20:09:51 kobe kernel: Symlink: ums0 -> usb4.2.0.16 > >> > >> but there is no ums0 symlink in /dev: > >> > >> # ls -ld ums* > >> ls: ums*: No such file or directory > >> # > > > > Hi, The device is invisible. You should be able to cat it, if it's not > > already opened. > > It was opened by moused, so I killed it. There's no output when I > attach and move the mouse, other than the following in syslog: > > Feb 16 21:37:45 kobe kernel: ugen4.2: at usbus4 > Feb 16 21:37:45 kobe kernel: ums0: (Model 1056), class 0/0, rev 2.00/0.07, addr 2> on usbus4 Feb 16 21:37:45 > kobe kernel: ums0: 5 buttons and [XYZ] coordinates Feb 16 21:37:45 kobe > kernel: ums_attach:582: sc=0xc63cd800 > Feb 16 21:37:45 kobe kernel: ums_attach:583: X 48/8 > Feb 16 21:37:45 kobe kernel: ums_attach:584: Y 56/8 > Feb 16 21:37:45 kobe kernel: ums_attach:585: Z 64/8 > Feb 16 21:37:45 kobe kernel: ums_attach:586: T 0/0 > Feb 16 21:37:45 kobe kernel: ums_attach:587: W 0/0 > Feb 16 21:37:45 kobe kernel: ums_attach:591: B1 40/1 > Feb 16 21:37:45 kobe kernel: ums_attach:591: B2 41/1 > Feb 16 21:37:45 kobe kernel: ums_attach:591: B3 42/1 > Feb 16 21:37:45 kobe kernel: ums_attach:591: B4 43/1 > Feb 16 21:37:45 kobe kernel: ums_attach:591: B5 44/1 > Feb 16 21:37:45 kobe kernel: ums_attach:593: size=2, id=19 > Feb 16 21:37:45 kobe kernel: Symlink: ums0 -> usb4.2.0.16 > > When I kill the moused instance that is launched on attach by devd, > start a `cat /dev/ums0' command and move the mouse, click a few buttons, > etc. there is no output at all. Hi, I found a bug in the HID library: Can you try the following patch: http://perforce.freebsd.org/chv.cgi?CH=157814 You need to recompile usb2_core after this patch. At the same time: Can the ones that submitted the following to the mouse driver test with the patch above instead. I want to remove the following from "ums2.c": /* * The Microsoft Wireless Notebook Optical Mouse 3000 Model 1049 has * five Report IDs: 19 23 24 17 18 (in the order they appear in report * descriptor), it seems that report id 17 contains the necessary * mouse information(3-buttons,X,Y,wheel) so we specify it manually. */ if ((uaa->info.idVendor == USB_VENDOR_MICROSOFT) && (uaa->info.idProduct == USB_PRODUCT_MICROSOFT_WLNOTEBOOK3)) { sc->sc_flags = (UMS_FLAG_X_AXIS | UMS_FLAG_Y_AXIS | UMS_FLAG_Z_AXIS); sc->sc_buttons = 3; isize = 5; sc->sc_iid = 17; sc->sc_loc_x.pos = 8; sc->sc_loc_y.pos = 16; sc->sc_loc_z.pos = 24; sc->sc_loc_btn[0].pos = 0; sc->sc_loc_btn[1].pos = 1; sc->sc_loc_btn[2].pos = 2; } --HPS From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 21:18:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F8AE106566C; Mon, 16 Feb 2009 21:18:35 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id E838E8FC21; Mon, 16 Feb 2009 21:18:34 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl109-226.kln.forthnet.gr [77.49.228.226]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-6) with ESMTP id n1GLIO03025932 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Feb 2009 23:18:30 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n1GLIOWF018801; Mon, 16 Feb 2009 23:18:24 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n1GLIOcq018800; Mon, 16 Feb 2009 23:18:24 +0200 (EET) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Hans Petter Selasky References: <87mycme9wc.fsf@kobe.laptop> <200902161930.25235.hselasky@freebsd.org> <87tz6u6u4d.fsf@kobe.laptop> <200902162212.37027.hselasky@freebsd.org> Date: Mon, 16 Feb 2009 23:18:24 +0200 In-Reply-To: <200902162212.37027.hselasky@freebsd.org> (Hans Petter Selasky's message of "Mon, 16 Feb 2009 22:12:36 +0100") Message-ID: <87r61ynkrj.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: n1GLIO03025932 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.488, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL -0.09, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: usb2 moused issue (Microsoft Wireless Optical) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 21:18:36 -0000 On Mon, 16 Feb 2009 22:12:36 +0100, Hans Petter Selasky wrote: > On Monday 16 February 2009, Giorgos Keramidas wrote: >> It was opened by moused, so I killed it. There's no output when I >> attach and move the mouse, other than the following in syslog: >> >> Feb 16 21:37:45 kobe kernel: ugen4.2: at usbus4 >> Feb 16 21:37:45 kobe kernel: ums0: > (Model 1056), class 0/0, rev 2.00/0.07, addr 2> on usbus4 Feb 16 21:37:45 >> kobe kernel: ums0: 5 buttons and [XYZ] coordinates Feb 16 21:37:45 kobe >> kernel: ums_attach:582: sc=0xc63cd800 >> Feb 16 21:37:45 kobe kernel: ums_attach:583: X 48/8 >> Feb 16 21:37:45 kobe kernel: ums_attach:584: Y 56/8 >> Feb 16 21:37:45 kobe kernel: ums_attach:585: Z 64/8 >> Feb 16 21:37:45 kobe kernel: ums_attach:586: T 0/0 >> Feb 16 21:37:45 kobe kernel: ums_attach:587: W 0/0 >> Feb 16 21:37:45 kobe kernel: ums_attach:591: B1 40/1 >> Feb 16 21:37:45 kobe kernel: ums_attach:591: B2 41/1 >> Feb 16 21:37:45 kobe kernel: ums_attach:591: B3 42/1 >> Feb 16 21:37:45 kobe kernel: ums_attach:591: B4 43/1 >> Feb 16 21:37:45 kobe kernel: ums_attach:591: B5 44/1 >> Feb 16 21:37:45 kobe kernel: ums_attach:593: size=2, id=19 >> Feb 16 21:37:45 kobe kernel: Symlink: ums0 -> usb4.2.0.16 >> >> When I kill the moused instance that is launched on attach by devd, >> start a `cat /dev/ums0' command and move the mouse, click a few buttons, >> etc. there is no output at all. > > Hi, > > I found a bug in the HID library: > > Can you try the following patch: > > http://perforce.freebsd.org/chv.cgi?CH=157814 This looks ok. I'll give it a run in a few minutes, thanks :-) From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 21:48:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEBEE106564A; Mon, 16 Feb 2009 21:48:35 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 5D60F8FC15; Mon, 16 Feb 2009 21:48:34 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl109-226.kln.forthnet.gr [77.49.228.226]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-6) with ESMTP id n1GLmKeF027896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Feb 2009 23:48:26 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n1GLmIuA028377; Mon, 16 Feb 2009 23:48:19 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n1GLf9Ym009193; Mon, 16 Feb 2009 23:41:09 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Hans Petter Selasky References: <87mycme9wc.fsf@kobe.laptop> <200902161930.25235.hselasky@freebsd.org> <87tz6u6u4d.fsf@kobe.laptop> <200902162212.37027.hselasky@freebsd.org> <87r61ynkrj.fsf@kobe.laptop> Date: Mon, 16 Feb 2009 23:41:09 +0200 In-Reply-To: <87r61ynkrj.fsf@kobe.laptop> (Giorgos Keramidas's message of "Mon, 16 Feb 2009 23:18:24 +0200") Message-ID: <874oyut5ze.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: n1GLmKeF027896 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.874, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.53, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: usb2 moused issue (Microsoft Wireless Optical) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 21:48:36 -0000 On Mon, 16 Feb 2009 23:18:24 +0200, Giorgos Keramidas wrote: > On Mon, 16 Feb 2009 22:12:36 +0100, Hans Petter Selasky wrote: >> On Monday 16 February 2009, Giorgos Keramidas wrote: >>> It was opened by moused, so I killed it. There's no output when I >>> attach and move the mouse, other than the following in syslog: >>> >>> Feb 16 21:37:45 kobe kernel: ugen4.2: at usbus4 >>> Feb 16 21:37:45 kobe kernel: ums0: >> (Model 1056), class 0/0, rev 2.00/0.07, addr 2> on usbus4 Feb 16 21:37:45 >>> kobe kernel: ums0: 5 buttons and [XYZ] coordinates Feb 16 21:37:45 kobe >>> kernel: ums_attach:582: sc=0xc63cd800 >>> Feb 16 21:37:45 kobe kernel: ums_attach:583: X 48/8 >>> Feb 16 21:37:45 kobe kernel: ums_attach:584: Y 56/8 >>> Feb 16 21:37:45 kobe kernel: ums_attach:585: Z 64/8 >>> Feb 16 21:37:45 kobe kernel: ums_attach:586: T 0/0 >>> Feb 16 21:37:45 kobe kernel: ums_attach:587: W 0/0 >>> Feb 16 21:37:45 kobe kernel: ums_attach:591: B1 40/1 >>> Feb 16 21:37:45 kobe kernel: ums_attach:591: B2 41/1 >>> Feb 16 21:37:45 kobe kernel: ums_attach:591: B3 42/1 >>> Feb 16 21:37:45 kobe kernel: ums_attach:591: B4 43/1 >>> Feb 16 21:37:45 kobe kernel: ums_attach:591: B5 44/1 >>> Feb 16 21:37:45 kobe kernel: ums_attach:593: size=2, id=19 >>> Feb 16 21:37:45 kobe kernel: Symlink: ums0 -> usb4.2.0.16 >>> >>> When I kill the moused instance that is launched on attach by devd, >>> start a `cat /dev/ums0' command and move the mouse, click a few buttons, >>> etc. there is no output at all. >> >> Hi, >> >> I found a bug in the HID library: >> >> Can you try the following patch: >> >> http://perforce.freebsd.org/chv.cgi?CH=157814 > > This looks ok. I'll give it a run in a few minutes, thanks :-) A quick 'buildkernel' with -DNO_CLEAN and a reboot just finished. The patch doesn't seem to have changed anything, but I started a full buildkernel without -DNO_CLEAN too. I'll report back in ~= 1 hour. From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 22:38:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BB161065818; Mon, 16 Feb 2009 22:38:24 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id E95FA8FC1D; Mon, 16 Feb 2009 22:38:23 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl109-226.kln.forthnet.gr [77.49.228.226]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-6) with ESMTP id n1GMcFnP032008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Feb 2009 00:38:20 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n1GMcFUs002400; Tue, 17 Feb 2009 00:38:15 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n1GMcEp9002399; Tue, 17 Feb 2009 00:38:14 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Hans Petter Selasky References: <87mycme9wc.fsf@kobe.laptop> <200902161930.25235.hselasky@freebsd.org> <87tz6u6u4d.fsf@kobe.laptop> <200902162212.37027.hselasky@freebsd.org> <87r61ynkrj.fsf@kobe.laptop> <874oyut5ze.fsf@kobe.laptop> Date: Tue, 17 Feb 2009 00:38:14 +0200 In-Reply-To: <874oyut5ze.fsf@kobe.laptop> (Giorgos Keramidas's message of "Mon, 16 Feb 2009 23:41:09 +0200") Message-ID: <873aee0zzd.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: n1GMcFnP032008 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.874, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.53, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: usb2 moused issue (Microsoft Wireless Optical) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 22:38:30 -0000 On Mon, 16 Feb 2009 23:41:09 +0200, Giorgos Keramidas wrote: >>> Can you try the following patch: >>> http://perforce.freebsd.org/chv.cgi?CH=157814 >> >> This looks ok. I'll give it a run in a few minutes, thanks :-) > > A quick 'buildkernel' with -DNO_CLEAN and a reboot just finished. > > The patch doesn't seem to have changed anything, but I started a full > buildkernel without -DNO_CLEAN too. I'll report back in ~= 1 hour. No luck either. I finished a full buildkernel & reboot, but moused still has a bit of a problem reading movement events. Trying hd(1) on /dev/ums0 shows no data either as I move the mouse. The good news is that *other* USB mice I have work fine :-))) This one, for instance, works without any issues: kernel: ugen4.2: at usbus4 kernel: ums0: on usbus4 kernel: ums0: 3 buttons and [XYZ] coordinates kernel: ums_attach:582: sc=0xc6336000 kernel: ums_attach:583: X 8/8 kernel: ums_attach:584: Y 16/8 kernel: ums_attach:585: Z 24/8 kernel: ums_attach:586: T 0/0 kernel: ums_attach:587: W 0/0 kernel: ums_attach:591: B1 0/1 kernel: ums_attach:591: B2 1/1 kernel: ums_attach:591: B3 2/1 kernel: ums_attach:593: size=4, id=0 kernel: Symlink: ums0 -> usb4.2.0.16 A third, tiny wired USB mouse (labelled 'Samsung' but reporting as 'Creative Labs' in dmesg) works fine too: kernel: ugen4.2: at usbus4 kernel: ums0: on usbus4 kernel: ums0: 5 buttons and [XYZ] coordinates kernel: ums_attach:582: sc=0xc65ba000 kernel: ums_attach:583: X 8/8 kernel: ums_attach:584: Y 16/8 kernel: ums_attach:585: Z 24/8 kernel: ums_attach:586: T 0/0 kernel: ums_attach:587: W 0/0 kernel: ums_attach:591: B1 0/1 kernel: ums_attach:591: B2 1/1 kernel: ums_attach:591: B3 2/1 kernel: ums_attach:591: B4 3/1 kernel: ums_attach:591: B5 4/1 kernel: ums_attach:593: size=4, id=0 kernel: Symlink: ums0 -> usb4.2.0.16 It's only my wireless USB mouse [Microsoft Wireless Optical Mouse 3000 (Model 1056)] that seems to have issues with the new USB stack. I just changed its battery, but that doesn't seem to have helped much either. From owner-freebsd-current@FreeBSD.ORG Mon Feb 16 23:47:13 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C20DD106566B; Mon, 16 Feb 2009 23:47:13 +0000 (UTC) (envelope-from prvs=julian=2911c668e@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id A73308FC0A; Mon, 16 Feb 2009 23:47:13 +0000 (UTC) (envelope-from prvs=julian=2911c668e@elischer.org) Received: from jelischer-laptop.sfo.ironport.com (HELO julian-mac.elischer.org) ([10.251.22.38]) by smtp-outbound.ironport.com with ESMTP; 16 Feb 2009 15:34:00 -0800 Message-ID: <4999F7F9.4030204@elischer.org> Date: Mon, 16 Feb 2009 15:34:17 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Robert Watson References: <20080526110543.J26343@fledge.watson.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org, net@FreeBSD.org Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2009 23:47:14 -0000 Robert Watson wrote: > > (Bcc to arch@) > > On Mon, 26 May 2008, Robert Watson wrote: > >> Just to keep track of things: >> >> http://wiki.freebsd.org/NONMPSAFE_DEORBIT > > Delayed by about six months, the merge and switch to the new USB stack > in 8.x means that we're now fairly close to being able to pick up this > project again. The goal remains to eliminate IFF_NEEDSGIANT, which is > (mostly) the last piece of non-MPSAFE compatibility infrastructure in > the network stack in -CURRENT. I removed support for non-MPSAFE network > protocols before 7.0, and this is the support for non-MPSAFE network > device drivers. As of the current moment in HEAD, the following drivers > are flagged wth IFF_NEEDSGIANT: > > General network device drivers that still require Giant: > > if_ar > if_ray > if_sl > if_sr if_sr and if_ar are really simple and could probably be converted "trivially".. especially if their netgraph code is used. however I wonder if anyone still has that hardware (they are drivers for two sync serial cards). John Hay must have had some when he wrote the driver... > > Old USB network device drivers: > > if_axe > if_cdce > if_cue > if_kue > if_rue > if_rum > if_udav > if_upgt > if_ural > if_urtw > if_zyd > > Network device drivers intimately tangled with the old TTY code: > > if_cx > if_ppp > lf_sl > > A network device driver that appears to conditionally use IFF_NEEDSGIANT > for the purposes of (sometimes) interacting with the old USB code: > > if_ndis > > The following schedule is proposed, assuming nothing goes horribly wrong > with the new USB code in the next few weeks, and remaining nits relating > to USB network and 802.11 drivers are handled: > > 16 February 2009 HEADS UP to lists (this e-mail) > 01 March 2009 Disable build of all IFF_NEEDSGIANT drivers in 8.x > 01 April 2009 Remove all IFF_NEEDSGIANT drivers from 8.x > > In the next couple of weeks, I'd like to resolve the status of (and > eliminate) the if_ndis conditional use of IFF_NEEDSGIANT. There's also > a chance that if_sl will get updated by Ed and myself to work with the > new locking and TTY world orders -- the lock is easy, but the TTY update > takes a bit of work. Perhaps someone will feel moved to do this for > if_ppp and possibly if_cx as well. > > Robert N M Watson > Computer Laboratory > University of Cambridge > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 00:18:31 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D00E81065673; Tue, 17 Feb 2009 00:18:31 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 743EC8FC21; Tue, 17 Feb 2009 00:18:31 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [202.12.127.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id 309D76106; Mon, 16 Feb 2009 19:18:29 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1234829909; bh=TVK4SiWE2nGjjwD4VYWIKQXt50JE+BVSq/92n8YeA/8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Mk/nKC6n3oJQlxz1oP5cuwY6QMgnXmMWhEtdJ2RXicCPEJw5CooEcmHHmc2LDtVB7 uneTpaBjneFSbYcSjGjdwAMzL9hWpDE+vJn9flFrApHEpAr8Fvshbzf9yotWLlY DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=JfmAOKTDehqFSUcPJQo13LazaQrgJYgTJNwkHRKUrHQWCQvHLwq7B0shpabvvJnY5 VjbKTgX3UlmuroLYDM/3Wfefi/oTjzaiYa0F+9uhPxdtkzVzHRRS4Wd0GJhxJeZ Message-ID: <499A024A.60209@protected-networks.net> Date: Mon, 16 Feb 2009 19:18:18 -0500 From: Michael Butler User-Agent: Thunderbird 2.0.0.19 (X11/20090128) MIME-Version: 1.0 To: Robert Watson References: <20080526110543.J26343@fledge.watson.org> <4999F7F9.4030204@elischer.org> In-Reply-To: <4999F7F9.4030204@elischer.org> X-Enigmail-Version: 0.95.7 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org, net@FreeBSD.org Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 00:18:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Watson wrote: > Network device drivers intimately tangled with the old TTY code: > > if_cx > if_ppp > lf_sl The old TTY code appears to be the reason that the bluetooth/ng_h4 driver was "abandoned". Not having investigated further, I do not know if it is practical to restore to functionality. Since I can no longer use my compact-flash adapted pcmcia card for the lack of the H4 driver in -current, I use a USB dongle .. as follows: The usage of rfcomm_sppd as documented in the handbook results in .. Feb 16 19:12:57 toshi kernel: ugen1.2: at usbus1 Feb 16 19:12:57 toshi kernel: ubt0: on usbus1 Feb 16 19:13:31 toshi kernel: pid 50258 (rfcomm_sppd) is using legacy pty devices .. when connecting to my GPS. Is this functionality to be impacted? Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmaAkkACgkQQv9rrgRC1JK5rgCeM25FjOcNp/XHc5HuWV9yBSq8 IqMAmwVLP0QDIKMn5kDJhEa7gJN9mmq7 =sLMJ -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 00:19:31 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 867BF1065670 for ; Tue, 17 Feb 2009 00:19:31 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntmtas05p.mx.bigpond.com (nskntmtas05p.mx.bigpond.com [61.9.168.149]) by mx1.freebsd.org (Postfix) with ESMTP id 1A0398FC08 for ; Tue, 17 Feb 2009 00:19:30 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nskntotgx02p.mx.bigpond.com ([124.188.162.219]) by nskntmtas05p.mx.bigpond.com with ESMTP id <20090217001929.YQAG3098.nskntmtas05p.mx.bigpond.com@nskntotgx02p.mx.bigpond.com> for ; Tue, 17 Feb 2009 00:19:29 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nskntotgx02p.mx.bigpond.com with ESMTP id <20090217001928.JHEB12531.nskntotgx02p.mx.bigpond.com@areilly.bpa.nu> for ; Tue, 17 Feb 2009 00:19:28 +0000 Received: (qmail 22725 invoked by uid 501); 17 Feb 2009 00:19:14 -0000 Date: Tue, 17 Feb 2009 11:19:14 +1100 From: Andrew Reilly To: Joe Marcus Clarke Message-ID: <20090217001914.GB21644@duncan.reilly.home> References: <20090215223428.GA74071@citylink.fud.org.nz> <4998D027.5030501@protected-networks.net> <1234752963.42927.171.camel@shumai.marcuscom.com> <20090216061856.GD70145@duncan.reilly.home> <1234765678.42927.191.camel@shumai.marcuscom.com> <20090216082331.GA74847@duncan.reilly.home> <4999A746.60009@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4999A746.60009@freebsd.org> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150203.499A0291.003D,ss=1,fgs=0 Cc: Michael Butler , current@freebsd.org Subject: Re: hal care, feeding and integration (was Re: USB2 and USB mice) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 00:19:31 -0000 On Mon, Feb 16, 2009 at 12:49:58PM -0500, Joe Marcus Clarke wrote: > If the output of sysctl -b kern.geom.conftxt produces names with spaces, > then hal will not be able to mount the volume. Well that's kind of odd. I don't know what the significance is, but that sysctl knob doesn't mention acd-anything, even when the disk is mounted (manually). Is that a 7 vs 8 change? > Unless people are willing to ship me hardware, I will have to rely on > them for developing the underlying support code in hal. You never know: either of those could happen... > Hal (of the upcoming DeviceKit) will always be a port. Good-oh. Cheers, -- Andrew From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 01:10:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A81C106567D for ; Tue, 17 Feb 2009 01:10:20 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.234]) by mx1.freebsd.org (Postfix) with ESMTP id 347A18FC25 for ; Tue, 17 Feb 2009 01:10:20 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: by rv-out-0506.google.com with SMTP id f6so1960056rvb.43 for ; Mon, 16 Feb 2009 17:10:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=LLKbuI00ena73YqZ71CDYo3KTXhTfwsBiRmuQmdI8jc=; b=awH0viMgTCMJQer4yoO5L7NNMICF8HS/gPGOVzgWAMmKaetHL3VYU7prfiIz2JbbbX 0vRt/FY33W1EbLyiyFPthc6526e3dEs/knQihQIk2cEXF5pIbtgUPe/8l17+Z6tKgniY 9v4v5oSqKR3sSIXv4MDMB1Ej6FZDehK/YWPDk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=n+40lGDu2hw78JVyg9rF22zYeQhZi322fgCQ7u+6RiVScpAwqM3P4Furp5Hydap3G6 PCXiIhB7JeteJCzs89mSZAYJ8TfQ3+7Z8KYLletT2gCTw76vvFVCrNRClmptp4FUeILn UqC4aWTqvh3Q//7klrMHLOtQy0sG1WoOYEU3w= Received: by 10.141.28.2 with SMTP id f2mr1788489rvj.170.1234833019847; Mon, 16 Feb 2009 17:10:19 -0800 (PST) Received: from michelle.cdnetworks.co.kr ([114.111.62.249]) by mx.google.com with ESMTPS id b39sm5325527rvf.9.2009.02.16.17.10.17 (version=SSLv3 cipher=RC4-MD5); Mon, 16 Feb 2009 17:10:18 -0800 (PST) Received: by michelle.cdnetworks.co.kr (sSMTP sendmail emulation); Tue, 17 Feb 2009 10:13:58 +0900 From: Pyun YongHyeon Date: Tue, 17 Feb 2009 10:13:58 +0900 To: Garrett Cooper Message-ID: <20090217011358.GC23900@michelle.cdnetworks.co.kr> References: <7d6fde3d0902150028n5f07ee55mc6026e1e4935eeb0@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="SLDf9lqlvOQaIe6s" Content-Disposition: inline In-Reply-To: <7d6fde3d0902150028n5f07ee55mc6026e1e4935eeb0@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Current Subject: Re: Annoyance with recent parallelism in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 01:10:21 -0000 --SLDf9lqlvOQaIe6s Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Feb 15, 2009 at 12:28:20AM -0800, Garrett Cooper wrote: > I just updated my world to a recent snapshot (a build from last week) > and I'm noting some parallelism / backgrounding which is really > causing issues with my NIC and NFS mounts. I had to hit CTRL-D 5 times > in order to get the system to come up because it couldn't resolve my > NFS server's hostname, because the NIC wasn't up and going yet (as it > uses the DHCP client in background mode due to the new default). > > Now I realize that this all ties back into the issue with the NIC > (which I've approached Pyun about, and which I appreciate his help is > solving issues with this buggy chipset), but is there really a need Would you try attached patch? I don't like the patch but it may reduce number of link state change message generated by dhclient. > for parallelism at startup rc.d it can't properly detect dependencies > with some cases like NFS mounts? > > Thanks, > -Garrett --SLDf9lqlvOQaIe6s Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="msk.link.diff" Index: sys/dev/msk/if_msk.c =================================================================== --- sys/dev/msk/if_msk.c (revision 188700) +++ sys/dev/msk/if_msk.c (working copy) @@ -943,8 +943,11 @@ else { MSK_IF_LOCK(sc_if); ifp->if_mtu = ifr->ifr_mtu; - if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) + if ((ifp->if_drv_flags & + IFF_DRV_RUNNING) != 0) { + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; msk_init_locked(sc_if); + } MSK_IF_UNLOCK(sc_if); } } @@ -2726,6 +2729,7 @@ if_printf(sc_if->msk_ifp, "watchdog timeout " "(missed link)\n"); ifp->if_oerrors++; + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; msk_init_locked(sc_if); return; } @@ -2750,6 +2754,7 @@ if_printf(ifp, "watchdog timeout\n"); ifp->if_oerrors++; + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; msk_init_locked(sc_if); if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) taskqueue_enqueue(taskqueue_fast, &sc_if->msk_tx_task); @@ -2828,8 +2833,10 @@ mskc_reset(sc); for (i = 0; i < sc->msk_num_port; i++) { if (sc->msk_if[i] != NULL && sc->msk_if[i]->msk_ifp != NULL && - ((sc->msk_if[i]->msk_ifp->if_flags & IFF_UP) != 0)) + ((sc->msk_if[i]->msk_ifp->if_flags & IFF_UP) != 0)) { + sc->msk_if[i]->msk_ifp->if_drv_flags &= ~IFF_DRV_RUNNING; msk_init_locked(sc->msk_if[i]); + } } sc->msk_suspended = 0; @@ -3515,6 +3522,9 @@ sc = sc_if->msk_softc; mii = device_get_softc(sc_if->msk_miibus); + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) + return; + error = 0; /* Cancel pending I/O and free all Rx/Tx buffers. */ msk_stop(sc_if); --SLDf9lqlvOQaIe6s-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 01:53:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F00B2106566B for ; Tue, 17 Feb 2009 01:53:05 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwmtas03p.mx.bigpond.com (nschwmtas03p.mx.bigpond.com [61.9.189.143]) by mx1.freebsd.org (Postfix) with ESMTP id 826388FC12 for ; Tue, 17 Feb 2009 01:53:05 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwotgx03p.mx.bigpond.com ([124.188.162.219]) by nschwmtas03p.mx.bigpond.com with ESMTP id <20090217015253.QSAS16649.nschwmtas03p.mx.bigpond.com@nschwotgx03p.mx.bigpond.com> for ; Tue, 17 Feb 2009 01:52:53 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nschwotgx03p.mx.bigpond.com with ESMTP id <20090217015249.YVU7357.nschwotgx03p.mx.bigpond.com@areilly.bpa.nu> for ; Tue, 17 Feb 2009 01:52:49 +0000 Received: (qmail 25618 invoked by uid 501); 17 Feb 2009 01:52:48 -0000 Date: Tue, 17 Feb 2009 12:52:48 +1100 From: Andrew Reilly To: Andriy Gapon Message-ID: <20090217015248.GC21644@duncan.reilly.home> References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <499835BE.3000705@gmx.de> <8EF8771C-76D8-4556-96B2-B97B35573CBD@mac.com> <49986ABB.5040207@gmx.de> <20090216055602.GA70145@duncan.reilly.home> <49992A68.8010702@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49992A68.8010702@icyb.net.ua> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150204.499A1871.009C,ss=1,fgs=0 Cc: Christoph Mallon , Marcel Moolenaar , Bruce Simpson , freebsd-current@freebsd.org Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 01:53:06 -0000 Hi Andriy, I'm responding to this again in the hope that someone with a better grasp of C++ than me will be able to explain to me how this situation is avoided. This is one of the big reasons why I rejected C++ after some seven or so years of exclusive use. That was back in about 1996 or so, so I admit that things might have changed or improved in the meantime.) This is almost certainly off-topic for -current, so please ignore the rest of this thread if it doesn't interest you... On Mon, Feb 16, 2009 at 10:57:12AM +0200, Andriy Gapon wrote: > on 16/02/2009 07:56 Andrew Reilly said the following: > This is the first time in my life that I hear about temporary objects on > the heap and/or memory leaks through temporary objects. Either you are > remembering a bug in some ancient C++ compiler or you are referring to > some buggy code. Well, code that results in a memory leak (or dangling reference) is buggy by definition, but how to avoid it, in general? I'm not about to write some examples for the purpose of this discussion, so google searches will have to do. The first google search that I did for "C++ argument promotion temporary objects" came up with this link: http://www.icce.rug.nl/documents/cplusplus/cplusplus09.html If you skip down to the StringArray example, you can see that a new String object is automatically constructed to cast the char* to fit the String &operator[](size_t idx) method. Now, in this instance the constructed object has somewhere to go: a reference is being stored in the array. So the temporary object must have been constructed on the heap. But other methods on other objects may require String arguments, invoking the same constructor, but they might not record the reference and so it won't be cleaned up later. Or will it? Conversely (and perhaps you will see my confusion): this other paper: http://codewrangler.home.comcast.net/~codewrangler/tech_info/cpp_compiler_tips.html Under the section "Lifetime of Temporary Unnamed Objects" there is a discussion about such temporary objects being reclaimed by the language runtime as they go out of scope of the expression in which they were created. So that sounds like either stack allocation or heap allocation with explicit destructors inserted when leaving scope. Either way, that would appear to render the StringArray example above comprehensively broken, no? (The array would contain a dangling reference when the temporary String object is reclaimed at the end of the expression scope.) This issue is, I believe, undecidable at compile time, and goes by the name "escape detection". It is why *all* modern object-oriented languages require garbage collection. Some recent JIT runtime systems go to a great deal of effort to prove that references to some objects do not "escape" the block, and so can be stack-allocated and eagerly collected. That requires whole-program analysis, which is something that a JIT can fudge, but which a C++ compiler doing separate-compilation can't. > As to the conversions through constructors, conversion operators and > implicit type promotions - I personally had much less incidents because > of that than I had incidents in C with passing/casting something > incorrect via void*. This is to say that C++ is far from perfect and > there are languages that are much better than it, but C is even (much) > less perfect. > And of all languages out there, I think, that C++ comes closest to a > definition of "enriched", "better", "fortified" C. Which implies much > lower entry barrier (and possibility for limited/gradual introduction). I think that C++ was a noble try at an improvement in 1985, but has far too many warts and sharp edges for general use, and has been comprehensively superceded by languages that use garbage collection. Yes, C has sharp edges too, but it also has less magic: it is much (much) closer to assembly language in that regard. Sometimes that is appropriate (I think that it is, where operating systems are concerned), and sometimes not. When I'm not writing in C, I use python or scheme (or Matlab), not C++. Luckily, hardly anyone cares what I think :-) Cheers, -- Andrew From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 06:48:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62B041065670; Tue, 17 Feb 2009 06:48:56 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.com) Received: from mx2.gfk.ru (mx2.gfk.ru [84.21.231.139]) by mx1.freebsd.org (Postfix) with ESMTP id 979D18FC12; Tue, 17 Feb 2009 06:48:55 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.com) Received: from ex.hhp.local by mx2.gfk.ru (MDaemon PRO v9.6.0) with ESMTP id md50002898542.msg; Tue, 17 Feb 2009 09:49:34 +0300 Received: from ex-be-1.hhp.local ([10.0.0.31]) by ex.hhp.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Feb 2009 09:48:37 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Feb 2009 09:49:31 +0300 Message-ID: In-Reply-To: <3c1674c90901151848y7ea905f0l190d549f8b6c8609@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: _rw_wlock_hard: recursing but non-recursive rw radix node head @ /usr/src/sys/net/route.c:831 Thread-Index: Acl3hOy15Ggd4PRaT6yqlWsc4cXepAZRXwNA References: <3a142e750901140435m58c067c5t5cb100518f882f23@mail.gmail.com> <3a142e750901140905j7fe74944wcf96969a79ccc017@mail.gmail.com> <3c1674c90901151848y7ea905f0l190d549f8b6c8609@mail.gmail.com> From: "Yuriy Tsibizov" To: "Kip Macy" , "Paul B. Mahol" X-OriginalArrivalTime: 17 Feb 2009 06:48:37.0659 (UTC) FILETIME=[C2BB5EB0:01C990CB] X-Spam-Processed: mx2.gfk.ru, Tue, 17 Feb 2009 09:49:34 +0300 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.30 X-Return-Path: Yuriy.Tsibizov@gfk.com X-Envelope-From: Yuriy.Tsibizov@gfk.com X-MDAV-Processed: mx2.gfk.ru, Tue, 17 Feb 2009 09:49:36 +0300 Cc: freebsd-current@freebsd.org Subject: RE: _rw_wlock_hard: recursing but non-recursive rw radix node head @ /usr/src/sys/net/route.c:831 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 06:48:56 -0000 > From: mat.macy@gmail.com [mailto:mat.macy@gmail.com] On=20 > Behalf Of Kip Macy > I need a full backtrace in order to fix. I had the same panic (with kernel from Jan, 26th; not with the up-to-date one) and have textdump available, if you are still interested in it: http://chibis.persons.gfk.ru/freebsd/panic/ Yuriy. From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 06:56:14 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E01E106564A for ; Tue, 17 Feb 2009 06:56:14 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by mx1.freebsd.org (Postfix) with ESMTP id 69F118FC16 for ; Tue, 17 Feb 2009 06:56:14 +0000 (UTC) (envelope-from mat.macy@gmail.com) Received: by rv-out-0506.google.com with SMTP id f6so2073516rvb.43 for ; Mon, 16 Feb 2009 22:56:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=Oo9EvzaMY2l2oqsPN2iXieykwcJoXQxUed/m6Rk6MMQ=; b=QIs0DST/Rjzut4cuUffR/K6S5ahERB14dMwIqIk2/MkpqiWHjMg0ED6G8kAbJRbOEL XNEarRp5kiqfNBBMCM7TTM0h/iURmLM8ZXyV6/vHz7AHVC71t3myhvXxNecPF+sND98g CjVloy95TZPAnOJ5xgkBOs8B6LLigMtWrLSTs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=M5MDNoLNVtbFqrGDySyMFlxavkPlkwRaNlCroUS8Q3viERBZ24TLdNWHLg7rTTtdL/ D4Yg54jTp4yQqUd2yBpwgMWOukEEsD+8UBXBSbKBP6aURsd9o6a50HrFYSkk1FCByyzA hzS1O8ezY9Q+pffOYR5uYNPJxU4d6HJj6Ka3A= MIME-Version: 1.0 Sender: mat.macy@gmail.com Received: by 10.141.142.15 with SMTP id u15mr3121279rvn.16.1234853773214; Mon, 16 Feb 2009 22:56:13 -0800 (PST) In-Reply-To: References: <3a142e750901140435m58c067c5t5cb100518f882f23@mail.gmail.com> <3a142e750901140905j7fe74944wcf96969a79ccc017@mail.gmail.com> <3c1674c90901151848y7ea905f0l190d549f8b6c8609@mail.gmail.com> Date: Mon, 16 Feb 2009 22:56:13 -0800 X-Google-Sender-Auth: 660895b7aaeca47b Message-ID: <3c1674c90902162256h7c91f1a6w7549ce192b9e392@mail.gmail.com> From: Kip Macy To: Yuriy Tsibizov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: _rw_wlock_hard: recursing but non-recursive rw radix node head @ /usr/src/sys/net/route.c:831 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 06:56:14 -0000 If I'm around later in the week I will fix it then. Cheers, Kip On Mon, Feb 16, 2009 at 10:49 PM, Yuriy Tsibizov wrote: >> From: mat.macy@gmail.com [mailto:mat.macy@gmail.com] On >> Behalf Of Kip Macy >> I need a full backtrace in order to fix. > > I had the same panic (with kernel from Jan, 26th; not with the > up-to-date one) and have textdump available, if you are still interested > in it: > http://chibis.persons.gfk.ru/freebsd/panic/ > > > Yuriy. > > From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 07:46:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E95741065675; Tue, 17 Feb 2009 07:46:02 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe03.swip.net [212.247.154.65]) by mx1.freebsd.org (Postfix) with ESMTP id 260558FC0C; Tue, 17 Feb 2009 07:46:01 +0000 (UTC) (envelope-from hselasky@freebsd.org) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=v1l4sCoM7rMA:10 a=-QvcQp4i0RcA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=6I5d2MoRAAAA:8 a=4EkcbnRLABMPvti_QW8A:9 a=sob0tMTxoIEBWz2kiF4A:7 a=8AQnFqadDXHFqq2eOLyHS1qD4bMA:4 a=LY0hPdMaydYA:10 a=SV7veod9ZcQA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe03.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1201655656; Tue, 17 Feb 2009 08:46:00 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 17 Feb 2009 08:48:27 +0100 User-Agent: KMail/1.9.7 References: <87mycme9wc.fsf@kobe.laptop> <87r61ynkrj.fsf@kobe.laptop> <874oyut5ze.fsf@kobe.laptop> In-Reply-To: <874oyut5ze.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902170848.28659.hselasky@freebsd.org> Cc: Giorgos Keramidas , Andrew Thompson Subject: Re: usb2 moused issue (Microsoft Wireless Optical) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 07:46:03 -0000 On Monday 16 February 2009, Giorgos Keramidas wrote: > On Mon, 16 Feb 2009 23:18:24 +0200, Giorgos Keramidas wrote: > > On Mon, 16 Feb 2009 22:12:36 +0100, Hans Petter Selasky wrote: > >> On Monday 16 February 2009, Giorgos Keramidas wrote: > >>> It was opened by moused, so I killed it. There's no output when I > >>> attach and move the mouse, other than the following in syslog: > >>> > >>> Feb 16 21:37:45 kobe kernel: ugen4.2: at usbus4 > >>> Feb 16 21:37:45 kobe kernel: ums0: >>> 3000 (Model 1056), class 0/0, rev 2.00/0.07, addr 2> on usbus4 Feb 16 > >>> 21:37:45 kobe kernel: ums0: 5 buttons and [XYZ] coordinates Feb 16 > >>> 21:37:45 kobe kernel: ums_attach:582: sc=0xc63cd800 > >>> Feb 16 21:37:45 kobe kernel: ums_attach:583: X 48/8 > >>> Feb 16 21:37:45 kobe kernel: ums_attach:584: Y 56/8 > >>> Feb 16 21:37:45 kobe kernel: ums_attach:585: Z 64/8 > >>> Feb 16 21:37:45 kobe kernel: ums_attach:586: T 0/0 > >>> Feb 16 21:37:45 kobe kernel: ums_attach:587: W 0/0 > >>> Feb 16 21:37:45 kobe kernel: ums_attach:591: B1 40/1 > >>> Feb 16 21:37:45 kobe kernel: ums_attach:591: B2 41/1 > >>> Feb 16 21:37:45 kobe kernel: ums_attach:591: B3 42/1 > >>> Feb 16 21:37:45 kobe kernel: ums_attach:591: B4 43/1 > >>> Feb 16 21:37:45 kobe kernel: ums_attach:591: B5 44/1 > >>> Feb 16 21:37:45 kobe kernel: ums_attach:593: size=2, id=19 > >>> Feb 16 21:37:45 kobe kernel: Symlink: ums0 -> usb4.2.0.16 > >>> > >>> When I kill the moused instance that is launched on attach by devd, > >>> start a `cat /dev/ums0' command and move the mouse, click a few > >>> buttons, etc. there is no output at all. > >> > >> Hi, > >> > >> I found a bug in the HID library: > >> > >> Can you try the following patch: > >> > >> http://perforce.freebsd.org/chv.cgi?CH=157814 > > > > This looks ok. I'll give it a run in a few minutes, thanks :-) > > A quick 'buildkernel' with -DNO_CLEAN and a reboot just finished. > > The patch doesn't seem to have changed anything, but I started a full > buildkernel without -DNO_CLEAN too. I'll report back in ~= 1 hour. Could you enable ums0 debugging output after the changes, when you plug the device? I just want to see that the isize has changed. --HPS > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 07:51:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AFB3C106566B; Tue, 17 Feb 2009 07:51:39 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.9.129]) by mx1.freebsd.org (Postfix) with ESMTP id 715B48FC18; Tue, 17 Feb 2009 07:51:39 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id BEA7F73098; Tue, 17 Feb 2009 08:57:42 +0100 (CET) Date: Tue, 17 Feb 2009 08:57:42 +0100 From: Luigi Rizzo To: Scott Long Message-ID: <20090217075742.GA69308@onelab2.iet.unipi.it> References: <499551B9.7050805@samsco.org> <4995DFE5.1020205@samsco.org> <9bbcef730902131421r53efa13dq371658888747f387@mail.gmail.com> <4996D635.3000802@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4996D635.3000802@samsco.org> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, Ivan Voras Subject: Re: HEADS UP: Major CAM performance regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 07:51:40 -0000 On Sat, Feb 14, 2009 at 07:33:25AM -0700, Scott Long wrote: ... > >I'll try your suggestion if you have one. > > I don't have a magic universal testing suite in my back pocket, sorry. > You need to look at your expected workload and develop tests to simulate > it. When I do testing during driver development, I try a lot of > different parallel, sequential, large i/o, and small i/o combinations. i just committed a port sysutils/fio that perhaps can help testing IO performance with various patterns. cheers luigi From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 08:29:05 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 109E9106566B for ; Tue, 17 Feb 2009 08:29:05 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id BE35D8FC17 for ; Tue, 17 Feb 2009 08:29:04 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 7136D9CB068 for ; Tue, 17 Feb 2009 09:26:04 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIHXDtwSL6vJ for ; Tue, 17 Feb 2009 09:25:52 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 62C1E9CB0F6 for ; Tue, 17 Feb 2009 09:25:52 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n1H8Pq0j055675 for current@freebsd.org; Tue, 17 Feb 2009 09:25:52 +0100 (CET) (envelope-from rdivacky) Date: Tue, 17 Feb 2009 09:25:52 +0100 From: Roman Divacky To: current@freebsd.org Message-ID: <20090217082552.GA54893@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: [PATCH]: type promotion prototypes fixes - NDIS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 08:29:05 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline hi can you please test/review this patch: www.vlakno.cz/~rdivacky/int-promotion.patch it fixes wrong type promotion prototypes in the cases where there is a ANSI prototype and K&R function where the default promotion to int is not satisfied. ie. void foo(uint16_t); void foo(x) uint16_t x; { return; } the uint16_t x in the K&R function is promoted to int so the prototype and function does not match. most of the fixes in the patch does not change ABI but the NDIS does, so please someone test this as I dont have the HW thnx! roman --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmadI8ACgkQLVEj6D3CBEz52wCeKhx47HvggjCIU1/UX/XPjMK7 Qc0AmwaH64uhvi7tqzntVX+/exlpIVGd =iDSn -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 09:10:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56AAC10656DB; Tue, 17 Feb 2009 09:10:18 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id BB9008FC22; Tue, 17 Feb 2009 09:10:17 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl126-61.kln.forthnet.gr [77.49.245.61]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-6) with ESMTP id n1H9A6NK015109 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Feb 2009 11:10:11 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n1H9A5gb010311; Tue, 17 Feb 2009 11:10:05 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n1H9A56n010310; Tue, 17 Feb 2009 11:10:05 +0200 (EET) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Hans Petter Selasky References: <87mycme9wc.fsf@kobe.laptop> <87r61ynkrj.fsf@kobe.laptop> <874oyut5ze.fsf@kobe.laptop> <200902170848.28659.hselasky@freebsd.org> Date: Tue, 17 Feb 2009 11:10:05 +0200 In-Reply-To: <200902170848.28659.hselasky@freebsd.org> (Hans Petter Selasky's message of "Tue, 17 Feb 2009 08:48:27 +0100") Message-ID: <87eixxpgya.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-MailScanner-ID: n1H9A6NK015109 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.486, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL -0.09, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: usb2 moused issue (Microsoft Wireless Optical) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 09:10:18 -0000 On Tue, 17 Feb 2009 08:48:27 +0100, Hans Petter Selasky wrote: > Could you enable ums0 debugging output after the changes, when you > plug the device? I just want to see that the isize has changed. Sure. Here's the output before the patch: kernel: ugen4.2: at usbus4 kernel: ums0: on usbus4 kernel: ums0: 5 buttons and [XYZ] coordinates Feb 16 kernel: ums_attach:582: sc=0xc63cd800 kernel: ums_attach:583: X 48/8 kernel: ums_attach:584: Y 56/8 kernel: ums_attach:585: Z 64/8 kernel: ums_attach:586: T 0/0 kernel: ums_attach:587: W 0/0 kernel: ums_attach:591: B1 40/1 kernel: ums_attach:591: B2 41/1 kernel: ums_attach:591: B3 42/1 kernel: ums_attach:591: B4 43/1 kernel: ums_attach:591: B5 44/1 kernel: ums_attach:593: size=2, id=19 kernel: Symlink: ums0 -> usb4.2.0.16 and the output after the patch: kernel: ugen4.2: at usbus4 kernel: ums0: on usbus4 kernel: ums0: 5 buttons and [XYZ] coordinates kernel: ums_attach:582: sc=0xc627dc00 kernel: ums_attach:583: X 48/8 kernel: ums_attach:584: Y 56/8 kernel: ums_attach:585: Z 64/8 kernel: ums_attach:586: T 0/0 kernel: ums_attach:587: W 0/0 kernel: ums_attach:591: B1 40/1 kernel: ums_attach:591: B2 41/1 kernel: ums_attach:591: B3 42/1 kernel: ums_attach:591: B4 43/1 kernel: ums_attach:591: B5 44/1 kernel: ums_attach:593: size=2, id=19 kernel: Symlink: ums0 -> usb4.2.0.16 From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 09:14:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 657891065670 for ; Tue, 17 Feb 2009 09:14:00 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id A98798FC13 for ; Tue, 17 Feb 2009 09:13:59 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA07675; Tue, 17 Feb 2009 11:13:45 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1] helo=edge.pp.kiev.ua) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1LZM1Q-0009gN-Un; Tue, 17 Feb 2009 11:13:45 +0200 Message-ID: <499A7FC6.40502@icyb.net.ua> Date: Tue, 17 Feb 2009 11:13:42 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.19 (X11/20090114) MIME-Version: 1.0 To: Andrew Reilly References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <499835BE.3000705@gmx.de> <8EF8771C-76D8-4556-96B2-B97B35573CBD@mac.com> <49986ABB.5040207@gmx.de> <20090216055602.GA70145@duncan.reilly.home> <49992A68.8010702@icyb.net.ua> <20090217015248.GC21644@duncan.reilly.home> In-Reply-To: <20090217015248.GC21644@duncan.reilly.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Christoph Mallon , Marcel Moolenaar , Bruce Simpson , freebsd-current@freebsd.org Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 09:14:01 -0000 on 17/02/2009 03:52 Andrew Reilly said the following: > Well, code that results in a memory leak (or dangling reference) > is buggy by definition, but how to avoid it, in general? I'm > not about to write some examples for the purpose of this > discussion, so google searches will have to do. > > The first google search that I did for "C++ argument promotion > temporary objects" came up with this link: > http://www.icce.rug.nl/documents/cplusplus/cplusplus09.html > > If you skip down to the StringArray example, you can see that > a new String object is automatically constructed to cast the > char* to fit the String &operator[](size_t idx) method. Now, > in this instance the constructed object has somewhere to go: a > reference is being stored in the array. So the temporary object > must have been constructed on the heap. But other methods on > other objects may require String arguments, invoking the same > constructor, but they might not record the reference and so it > won't be cleaned up later. Or will it? Actually in that I example I see only definition of the interface and nothing about its implementation. The fact that that "String &operator[](size_t idx)" operator returns a reference to String doesn't mean that the class stores references. In fact, if return type of this operator was just "String" then it would mean that it returns a copy of a String. So it's impossible to judge what "the code that isn't there" would do. We could consider how vector works, which is very close to that interface (mucho simplified). First of all, actual array of string objects is stored in the vector. Then, in this case no temporary object is needed at all, because string has an assignment operator from const char *, which means that a string object knows how update itself when it is being assigned a const char * value. Also please see here: http://www.parashift.com/c++-faq-lite/references.html Section 8.3. > Conversely (and perhaps you will see my confusion): this other > paper: > http://codewrangler.home.comcast.net/~codewrangler/tech_info/cpp_compiler_tips.html > Under the section "Lifetime of Temporary Unnamed Objects" there > is a discussion about such temporary objects being reclaimed by > the language runtime as they go out of scope of the expression > in which they were created. So that sounds like either stack > allocation or heap allocation with explicit destructors inserted > when leaving scope. Either way, that would appear to render the > StringArray example above comprehensively broken, no? (The > array would contain a dangling reference when the temporary > String object is reclaimed at the end of the expression scope.) In general the following hold true: 1. temporary objects always have automatic scope which means that they are destroyed as soon as a scope where they were needed is left; compiler generates that code; 2. compiler would not allow to assign a pointer to a temporary object; it only allows to initialize a const reference with a temporary object, in which case the scope of the temporary is extended to be the same as the scope of that reference variable. 3. constructor of a temporary variable can, of course, allocate something on the heap (e.g. some sort of a buffer); its destructor must deallocate that memory; if it doesn't, then this just buggy code, nothing to do with temporaries. > This issue is, I believe, undecidable at compile time, and > goes by the name "escape detection". It is why *all* modern > object-oriented languages require garbage collection. Some > recent JIT runtime systems go to a great deal of effort to prove > that references to some objects do not "escape" the block, and > so can be stack-allocated and eagerly collected. That requires > whole-program analysis, which is something that a JIT can fudge, > but which a C++ compiler doing separate-compilation can't. No, no. C++ has stricter and simpler rules. It tries very hard to not allow a programmer to let any pointers/references to temporary objects escape. Of course, a sufficiently good programmer can still manage to make it happen, but then it's a programmer's problem - the temporary object would still not escape and be destroyed, the pointer/reference would point to garbage. It's like in C - you can return a pointer to a struct on stack, but that wouldn't make that struct magically be transfered to heap and persist, it would just make the returned pointer point to bad data. You might be also confused about what 'reference' in C++ is. In fact, Java references are very much alike C++ pointers (e.g. can be null, can be re-pointed). C++ references (when not abused through nasty tricks possible due to C compatibility) are just permanently-bound aliases. http://en.wikipedia.org/wiki/Reference_(C%2B%2B) I hope I managed to explain at least something, not made too many mistakes (I am not a big C++ expert recently) and not added to the confusion :-) -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 09:26:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A764106566C for ; Tue, 17 Feb 2009 09:26:58 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id BE8698FC0A for ; Tue, 17 Feb 2009 09:26:57 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 17 Feb 2009 09:26:55 -0000 Received: from p54A3F33E.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.243.62] by mail.gmx.net (mp008) with SMTP; 17 Feb 2009 10:26:55 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX19BTDgiinNBkJRxV1LA9byWWNrxMuIuAciW4M1NA2 KWYidTlxdTZXfU Message-ID: <499A82DE.3080701@gmx.de> Date: Tue, 17 Feb 2009 10:26:54 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Andrew Reilly References: <4995BB1B.7060201@icyb.net.ua> <20090213231513.GA20223@duncan.reilly.home> <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <499835BE.3000705@gmx.de> <8EF8771C-76D8-4556-96B2-B97B35573CBD@mac.com> <49986ABB.5040207@gmx.de> <20090216055602.GA70145@duncan.reilly.home> <49992A68.8010702@icyb.net.ua> <20090217015248.GC21644@duncan.reilly.home> In-Reply-To: <20090217015248.GC21644@duncan.reilly.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.55 Cc: Marcel Moolenaar , Andriy Gapon , Bruce Simpson , freebsd-current@freebsd.org Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 09:26:58 -0000 Andrew Reilly schrieb: > On Mon, Feb 16, 2009 at 10:57:12AM +0200, Andriy Gapon wrote: >> on 16/02/2009 07:56 Andrew Reilly said the following: >> This is the first time in my life that I hear about temporary objects on >> the heap and/or memory leaks through temporary objects. Either you are >> remembering a bug in some ancient C++ compiler or you are referring to >> some buggy code. > > Well, code that results in a memory leak (or dangling reference) > is buggy by definition, but how to avoid it, in general? I'm > not about to write some examples for the purpose of this > discussion, so google searches will have to do. > > The first google search that I did for "C++ argument promotion > temporary objects" came up with this link: > http://www.icce.rug.nl/documents/cplusplus/cplusplus09.html > > If you skip down to the StringArray example, you can see that > a new String object is automatically constructed to cast the > char* to fit the String &operator[](size_t idx) method. Now, > in this instance the constructed object has somewhere to go: a > reference is being stored in the array. So the temporary object > must have been constructed on the heap. But other methods on > other objects may require String arguments, invoking the same > constructor, but they might not record the reference and so it > won't be cleaned up later. Or will it? Uh, your observation is wrong. I guess you talk about the line sa[3] = "hello world"; because this is the only line, which includes vaguely something like a char*[0]. The text describes in detail what happens. Actually there are no temporary objects involved. First sa[3] is evaluated. The left hand side of the [] operator is a StringArray and the right hand side is an integer literal. The overloaded [] operator in class StringArray fits here, so we get a reference to a String, i.e. a String&, as result. Then there is the = operator. On the left side is a String& and on the right side (after default conversion) a const char*. We look in class String and find an overloaded = operator, which takes a const char* as second argument, so this one is called. The sa[3] part knows nothing at all about the string literal later. The string literal knows nothing about the sa[3] either. Their only connection is the = operator, which knows both its operands, of course. End of story. [0] A string literal is of type const char[] and there is a deprectaed conversion from string literals to char*, but this is not necessary here, because we only need a const char* which is fine. From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 10:21:46 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E63691065675; Tue, 17 Feb 2009 10:21:46 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from mx.bulinfo.net (mx.bulinfo.net [193.194.156.1]) by mx1.freebsd.org (Postfix) with ESMTP id 5CEF98FC24; Tue, 17 Feb 2009 10:21:46 +0000 (UTC) (envelope-from krassi@bulinfo.net) Received: from localhost (localhost [127.0.0.1]) by mx.bulinfo.net (Postfix) with ESMTP id 58B89C7F9; Tue, 17 Feb 2009 11:50:08 +0200 (EET) Received: from mx.bulinfo.net ([127.0.0.1]) by localhost (mx.bulinfo.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15078-08; Tue, 17 Feb 2009 11:50:05 +0200 (EET) Received: from [192.168.2.188] (pythia.bulinfo.net [212.72.195.5]) by mx.bulinfo.net (Postfix) with ESMTP id DDEE6C7F2; Tue, 17 Feb 2009 11:50:04 +0200 (EET) Message-ID: <499A884A.4040408@bulinfo.net> Date: Tue, 17 Feb 2009 11:50:02 +0200 From: Krassimir Slavchev User-Agent: Thunderbird 2.0.0.14 (X11/20080616) MIME-Version: 1.0 To: Julian Elischer References: <20080526110543.J26343@fledge.watson.org> <4999F7F9.4030204@elischer.org> In-Reply-To: <4999F7F9.4030204@elischer.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at mx.bulinfo.net Cc: Robert Watson , current@FreeBSD.org, net@FreeBSD.org Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 10:21:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Julian Elischer wrote: > Robert Watson wrote: >> >> (Bcc to arch@) >> >> On Mon, 26 May 2008, Robert Watson wrote: >> >>> Just to keep track of things: >>> >>> http://wiki.freebsd.org/NONMPSAFE_DEORBIT >> >> Delayed by about six months, the merge and switch to the new USB stack >> in 8.x means that we're now fairly close to being able to pick up this >> project again. The goal remains to eliminate IFF_NEEDSGIANT, which is >> (mostly) the last piece of non-MPSAFE compatibility infrastructure in >> the network stack in -CURRENT. I removed support for non-MPSAFE >> network protocols before 7.0, and this is the support for non-MPSAFE >> network device drivers. As of the current moment in HEAD, the >> following drivers are flagged wth IFF_NEEDSGIANT: >> >> General network device drivers that still require Giant: >> >> if_ar >> if_ray >> if_sl >> if_sr > > if_sr and if_ar are really simple and could probably > be converted "trivially".. especially if > their netgraph code is used. > > however I wonder if anyone still has that hardware (they are > drivers for two sync serial cards). I still have such Digi/Arnet SYNC/570i PCI card and I used to use it for a long time with 4.x and if_ar driver without any problems. Thanks to John Hay for well written driver! > > John Hay must have had some when he wrote the driver... > >> >> Old USB network device drivers: >> >> if_axe >> if_cdce >> if_cue >> if_kue >> if_rue >> if_rum >> if_udav >> if_upgt >> if_ural >> if_urtw >> if_zyd >> >> Network device drivers intimately tangled with the old TTY code: >> >> if_cx >> if_ppp >> lf_sl >> >> A network device driver that appears to conditionally use >> IFF_NEEDSGIANT for the purposes of (sometimes) interacting with the >> old USB code: >> >> if_ndis >> >> The following schedule is proposed, assuming nothing goes horribly >> wrong with the new USB code in the next few weeks, and remaining nits >> relating to USB network and 802.11 drivers are handled: >> >> 16 February 2009 HEADS UP to lists (this e-mail) >> 01 March 2009 Disable build of all IFF_NEEDSGIANT drivers in 8.x >> 01 April 2009 Remove all IFF_NEEDSGIANT drivers from 8.x >> >> In the next couple of weeks, I'd like to resolve the status of (and >> eliminate) the if_ndis conditional use of IFF_NEEDSGIANT. There's >> also a chance that if_sl will get updated by Ed and myself to work >> with the new locking and TTY world orders -- the lock is easy, but the >> TTY update takes a bit of work. Perhaps someone will feel moved to do >> this for if_ppp and possibly if_cx as well. >> >> Robert N M Watson >> Computer Laboratory >> University of Cambridge >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to >> "freebsd-current-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFJmohKxJBWvpalMpkRAh44AJ4pmnYdK3XApm8FoVpWfHsqZIZF3gCdHKGZ 3V5VDG8kKg5OVkColCUu9cA= =0oAM -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 10:26:06 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6530D1065712; Tue, 17 Feb 2009 10:26:06 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3F47C8FC1C; Tue, 17 Feb 2009 10:26:06 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id D048446B35; Tue, 17 Feb 2009 05:26:05 -0500 (EST) Date: Tue, 17 Feb 2009 10:26:05 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Krassimir Slavchev In-Reply-To: <499A884A.4040408@bulinfo.net> Message-ID: References: <20080526110543.J26343@fledge.watson.org> <4999F7F9.4030204@elischer.org> <499A884A.4040408@bulinfo.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: net@FreeBSD.org, Julian Elischer , current@FreeBSD.org Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 10:26:08 -0000 On Tue, 17 Feb 2009, Krassimir Slavchev wrote: >> if_sr and if_ar are really simple and could probably be converted >> "trivially".. especially if their netgraph code is used. >> >> however I wonder if anyone still has that hardware (they are drivers for >> two sync serial cards). > > I still have such Digi/Arnet SYNC/570i PCI card and I used to use it for a > long time with 4.x and if_ar driver without any problems. > > Thanks to John Hay for well written driver! I would be quite happy to see the remaining drivers be converted over -- when using IFF_NEEDSGIANT, they do potentially see a significant performance loss as a result of having to defer execution to Giant-holding contexts. However, the sooner the better, as stripping the Giant compat stuff will allow us to clean up the compat shims, in turn removing the need for deferred execution to avoid calling those shims in unfortunate contexts for multicast, and simplifies the forthcoming address list locking work. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 11:05:25 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8CB71065670 for ; Tue, 17 Feb 2009 11:05:25 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 7BA818FC16 for ; Tue, 17 Feb 2009 11:05:25 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 1228F1CE40; Tue, 17 Feb 2009 12:05:24 +0100 (CET) Date: Tue, 17 Feb 2009 12:05:24 +0100 From: Ed Schouten To: Michael Butler Message-ID: <20090217110524.GC79178@hoeg.nl> References: <20080526110543.J26343@fledge.watson.org> <4999F7F9.4030204@elischer.org> <499A024A.60209@protected-networks.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a6YTfLRor63AaheO" Content-Disposition: inline In-Reply-To: <499A024A.60209@protected-networks.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: current@FreeBSD.org Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 11:05:26 -0000 --a6YTfLRor63AaheO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Michael Butler wrote: > The usage of rfcomm_sppd as documented in the handbook results in .. >=20 > Feb 16 19:12:57 toshi kernel: ugen1.2: at usbus1 > Feb 16 19:12:57 toshi kernel: ubt0: Bluetooth, class 224/1, rev 1.10/5.25, addr 2> on usbus1 > Feb 16 19:13:31 toshi kernel: pid 50258 (rfcomm_sppd) is using legacy > pty devices >=20 > .. when connecting to my GPS. Is this functionality to be impacted? No, it shouldn't, but there's still something wrong with rfcomm_sppd, because it doesn't use proper libc functions to allocate pseudo-terminals. How did you start the application? --=20 Ed Schouten WWW: http://80386.nl/ --a6YTfLRor63AaheO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmamfQACgkQ52SDGA2eCwVrlgCfbxiOIPyFnpn7+Euw5qo1ipQv aaoAniKvClKBaP8Q+BxNCyPQ+P+MqpBr =4ZeA -----END PGP SIGNATURE----- --a6YTfLRor63AaheO-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 11:16:49 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3472F1065727 for ; Tue, 17 Feb 2009 11:16:49 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from sarah.protected-networks.net (sarah.protected-networks.net [IPv6:2001:470:1f07:4e1::1]) by mx1.freebsd.org (Postfix) with ESMTP id E6D578FC08 for ; Tue, 17 Feb 2009 11:16:48 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from toshi.auburn.protected-networks.net (toshi.auburn.protected-networks.net [IPv6:2001:470:1f07:4e1::4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: imb) by sarah.protected-networks.net (Postfix) with ESMTPSA id 64BC26148; Tue, 17 Feb 2009 06:16:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=protected-networks.net; s=200705; t=1234869407; bh=EScp7SKi7Wx+JplQnUTXcorm/+t9acUvjvfgokOGmWA=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=c1pgyVSqdiw4uhmqeRbrI8jjhaFnNj0ghB7sxZbi9eyD8KkN5uRTGxd66zPpz+uv4 1Z/GTtPIYhjQOlcYozT/4gPWtdxktogp+N7RgAKk14AlD7aRlPgNR15WKQk8oG7 DomainKey-Signature: a=rsa-sha1; s=200509; d=protected-networks.net; c=nofws; q=dns; h=message-id:date:from:user-agent:mime-version:to:cc:subject: references:in-reply-to:x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=bhk/7zqdd+UB3o4E9lCFD6IGMnMi0NkfblQiAhxDhmAuMtZ/AZDspuDHGo5Sg6QCO XFQjd3tKLYRGo4ZpmFZG1yU4Ich8Cjp0LHZruUTy8TNEiqPNuw2Je4WIcpO47Ma Message-ID: <499A9C9D.3000403@protected-networks.net> Date: Tue, 17 Feb 2009 06:16:45 -0500 From: Michael Butler User-Agent: Thunderbird 2.0.0.19 (X11/20090128) MIME-Version: 1.0 To: Ed Schouten References: <20080526110543.J26343@fledge.watson.org> <4999F7F9.4030204@elischer.org> <499A024A.60209@protected-networks.net> <20090217110524.GC79178@hoeg.nl> In-Reply-To: <20090217110524.GC79178@hoeg.nl> X-Enigmail-Version: 0.95.7 OpenPGP: id=0442D492 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 11:16:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ed Schouten wrote: > * Michael Butler wrote: >> Feb 16 19:13:31 toshi kernel: pid 50258 (rfcomm_sppd) is using legacy >> pty devices >> >> .. when connecting to my GPS. Is this functionality to be impacted? > No, it shouldn't, but there's still something wrong with rfcomm_sppd, > because it doesn't use proper libc functions to allocate > pseudo-terminals. > How did you start the application? I have NETGRAPH_BLUETOOTH et al defined in my kernel which automagically creates /dev/ubt0. With the appropriate entries in /etc/bluetooth/[hosts|hcsecd.conf], I simply do .. imb@toshi:/home/imb> less bin/gps-connect.sh #!/bin/sh /usr/bin/rfcomm_sppd -b -a QstarzGPS -t /dev/ttyp9 .. to bring it out to a device where roadnav or gspdrive can read it. Should I be doing something else in this script now? Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmanJ0ACgkQQv9rrgRC1JJ4kACfTWg9rKkOExk3iilTDBcOF6dZ cuEAn3h+D5/o8Kj8YSzHeWa1k3NYM4KW =Q8jG -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 11:50:09 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8136B10656C0 for ; Tue, 17 Feb 2009 11:50:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 390CD8FC0C for ; Tue, 17 Feb 2009 11:50:09 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 8333F41C67E; Tue, 17 Feb 2009 12:50:07 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id AgtXleqdtUFL; Tue, 17 Feb 2009 12:50:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 2402741C678; Tue, 17 Feb 2009 12:50:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 27B924448E6; Tue, 17 Feb 2009 11:46:20 +0000 (UTC) Date: Tue, 17 Feb 2009 11:46:20 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: FreeBSD current mailing list Message-ID: <20090217113718.N53478@maildrop.int.zabbadoz.net> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Marcel Moolenaar Subject: boot0cfg -s vs. GEOM_PART_*? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 11:50:09 -0000 Hi, with a fresh kernel and world from last night I get: dopt# boot0cfg -s 3 ad4 boot0cfg: /dev/ad4: ad4 boot0cfg: /dev/ad4: ioctl DIOCSMBR: Inappropriate ioctl for device is this GEOM_PART_* fallout and can it be fixed? I am wondering how to change it from a rnning system now, as dopt# gpart set -a active -i 3 ad4 gpart: pre-check failed: Device not configured I guess this may help you to see if what I am doing is correct: dopt# gpart show ad4 => 63 390721905 ad4 MBR (186G) 63 256977 1 !6 (125M) 257040 83875365 2 freebsd [active] (40G) 84132405 83875365 3 freebsd (40G) 168007770 222709095 4 freebsd (106G) 390716865 5103 - free - (2.5M) Oh, and how does one set the boot0cfg -s 5 (next disk) now? /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 11:56:51 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E2413106566C for ; Tue, 17 Feb 2009 11:56:51 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id A2F638FC15 for ; Tue, 17 Feb 2009 11:56:51 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 09EBD1CE40; Tue, 17 Feb 2009 12:56:51 +0100 (CET) Date: Tue, 17 Feb 2009 12:56:51 +0100 From: Ed Schouten To: Michael Butler Message-ID: <20090217115651.GE79178@hoeg.nl> References: <20080526110543.J26343@fledge.watson.org> <4999F7F9.4030204@elischer.org> <499A024A.60209@protected-networks.net> <20090217110524.GC79178@hoeg.nl> <499A9C9D.3000403@protected-networks.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qpqR4wE1CEr+Roqx" Content-Disposition: inline In-Reply-To: <499A9C9D.3000403@protected-networks.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: current@FreeBSD.org Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 11:56:52 -0000 --qpqR4wE1CEr+Roqx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Michael, * Michael Butler wrote: > I have NETGRAPH_BLUETOOTH et al defined in my kernel which automagically > creates /dev/ubt0. With the appropriate entries in > /etc/bluetooth/[hosts|hcsecd.conf], I simply do .. >=20 > imb@toshi:/home/imb> less bin/gps-connect.sh > #!/bin/sh > /usr/bin/rfcomm_sppd -b -a QstarzGPS -t /dev/ttyp9 >=20 > .. to bring it out to a device where roadnav or gspdrive can read it. >=20 > Should I be doing something else in this script now? Well, this is not related to IFF_NEEDSGIANT and everything's fine, but there is something else I don't like about this approach in general (the way rfcomm_sppd works), namely that you `hardcode' a PTY name on the command line. There is never a guarantee ttyp9 is available for use, because another user can use it to log in with SSH, for example. Can you try this patch? http://80386.nl/pub/rfcomm_sppd.diff This changes the -t switch to take no argument and let the pseudo- terminal be allocated with posix_openpt(). Unfortunately I don't know how practical this is for rfcomm_sppd. So let me get this straight: when you use rfcomm_sppd -t, the application itself will not give any output and will close immediately (because it is run in the background). Maybe we could change it to just printf() the pseudo-terminal name, so you can do something like this: TTYNAME=3D"`rfcomm_sppd -b -a QstarzGPS -t`" # Use $TTYNAME here Any opinions on the subject? (Other people as well?) --=20 Ed Schouten WWW: http://80386.nl/ --qpqR4wE1CEr+Roqx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmapgIACgkQ52SDGA2eCwXHBwCeKziyCvBNJvO/g1FWCn7CnUvH UNkAoICC2Ctn3uyTtwkgJM51A/cQiYQJ =DAZ4 -----END PGP SIGNATURE----- --qpqR4wE1CEr+Roqx-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 06:15:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00C03106566C for ; Tue, 17 Feb 2009 06:15:51 +0000 (UTC) (envelope-from mmakonnen@gmail.com) Received: from mail-gx0-f224.google.com (mail-gx0-f224.google.com [209.85.217.224]) by mx1.freebsd.org (Postfix) with ESMTP id 94A208FC14 for ; Tue, 17 Feb 2009 06:15:50 +0000 (UTC) (envelope-from mmakonnen@gmail.com) Received: by gxk24 with SMTP id 24so4882385gxk.19 for ; Mon, 16 Feb 2009 22:15:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=1qZl1BTHJZZGbOlMdgZwTJlrk3tN0dwsaYttxHbK0ZQ=; b=KSbH7h9s8dtdwZVBHP32inI4+TJR6r2dxRSRyYukzYwym0jKbMmKqy6RfQEc4SWVWL Q4ZVlSDUSYenk1Pta2kZk/RZeNd1YjQfUcHVBA5D6OYQHvVFIP1FGQeIL7P/G3r15XTb FQKPNn2Ars0PCjsl8T4RCg9xbVpIrKGt3faWo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=AdtXjjyx4VjcI8l3SVfxKyagY3omYPAsD6+C7LtHxiVulA9XYzusEgI3wTqhVyvM4m 61kC8C44RTrXADCE07Qrp39Jn6yAeQSf6xmo7dSZ7z5F1L9D9cPU7j7Axl4BH2DdD+hi ODcrjqjbakYzI6TbKQMXrawY95w6U9i0YzJPU= Received: by 10.100.134.10 with SMTP id h10mr5631014and.68.1234851350029; Mon, 16 Feb 2009 22:15:50 -0800 (PST) Received: from storm.mike.lan ([213.55.68.145]) by mx.google.com with ESMTPS id d24sm12091153and.50.2009.02.16.22.15.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 16 Feb 2009 22:15:49 -0800 (PST) Message-ID: <499A55AB.9080606@gmail.com> Date: Tue, 17 Feb 2009 09:14:03 +0300 From: Mike Makonnen User-Agent: Thunderbird 2.0.0.19 (X11/20090201) MIME-Version: 1.0 To: Alexey Shuvaev References: <7d6fde3d0902150028n5f07ee55mc6026e1e4935eeb0@mail.gmail.com> <20090215153531.GA36438@wep4035.physik.uni-wuerzburg.de> <49998707.40205@gmail.com> <20090216210118.GA85984@wep4035.physik.uni-wuerzburg.de> In-Reply-To: <20090216210118.GA85984@wep4035.physik.uni-wuerzburg.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 17 Feb 2009 12:20:51 +0000 Cc: Garrett Cooper , FreeBSD Current Subject: Re: Annoyance with recent parallelism in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 06:15:51 -0000 Alexey Shuvaev wrote: > Rev. 1.4 of rc.d/defaultroute. > Ok, what should I do to have network daemons happy on startup? > I am on a LAN so always have plugged-in cable. > I do see on the console: > msk0: link state changed to DOWN > msk0: link state changed to UP > got link > msk0: link state changed to DOWN > Starting Network: lo0 msk0. > msk0: link state changed to UP > msk0: link state changed to DOWN > > AFAIK some NIC (or PHY-s?) require some sort of reset to handle some > events. > Should I live with synchronous_dhclient="YES" or something else? This seems to be an issue with the driver for the network card. No special handling needs to take place in rc.d. So, yes, synchronous_dhclient=yes should be the appropriate work-around. Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 06:21:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 358AC1065674 for ; Tue, 17 Feb 2009 06:21:21 +0000 (UTC) (envelope-from janm@transactionware.com) Received: from mail.transactionware.com (mail.transactionware.com [203.14.245.7]) by mx1.freebsd.org (Postfix) with SMTP id 657168FC14 for ; Tue, 17 Feb 2009 06:21:20 +0000 (UTC) (envelope-from janm@transactionware.com) Received: (qmail 25323 invoked from network); 17 Feb 2009 05:54:59 -0000 Received: from midgard.transactionware.com (192.168.1.55) by dm.transactionware.com with SMTP; 17 Feb 2009 05:54:59 -0000 Received: (qmail 1668 invoked by uid 907); 17 Feb 2009 05:54:36 -0000 Received: from jmdesktop.transactionware.com (HELO [192.168.1.32]) (192.168.1.32) by midgard.transactionware.com (qpsmtpd/0.40) with ESMTP; Tue, 17 Feb 2009 16:54:36 +1100 Message-ID: <499A5122.1070605@transactionware.com> Date: Tue, 17 Feb 2009 16:54:42 +1100 From: Jan Mikkelsen User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Scott Long References: <499551B9.7050805@samsco.org> In-Reply-To: <499551B9.7050805@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 17 Feb 2009 12:26:16 +0000 Cc: FreeBSD Current , FreeBSD Stable Subject: Re: HEADS UP: Major CAM performance regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 06:21:21 -0000 Hi Scott, I just tried this on 7.1-p2 with an Areca (arcmsr) controller with SATA drives attached to see if it fixed the performance problem I noticed back in December 2008. See: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=43971+0+archive/2008/freebsd-stable/20081207.freebsd-stable The performance is still terrible. Interestingly, running your camcontrol command returns "device openings" of 1 on 7.1, and 255 on 6.4, so it seems to be the same underlying problem. I am happy to try other patches. Thanks, Jan Mikkelsen Scott Long wrote: > All, > > A major performance regression was introduced to the CAM subsystem in > FreeBSD 7.1. The following configurations are known to be affected: > > VMWare ESX > VMWare Fusion > (using bt or lsilogic controller options) > HP CISS RAID > Some MPT-SAS combinations with SATA drives attached > (Includes Dell SAS5/ir, but not PERC5/PERC6). > > Pure SCSI and SAS subsystems likely are NOT affected. Any hardware > that uses the 'ata' driver is also definitely NOT affected. To > determine if your installation is affected, run the following command as > root: > > camcontrol tags da0 > > Substitute 'da0' with another appropriate drive device number, if > needed. Note that this ONLY AFFECTS 'da' DEVICES. If your disks are > 'ad' devices, they are NOT affected. > > The result from running this command should be an output similar to the > following: > > (pass0:mpt0:0:8:0): device openings: 255 > > If, instead, it reports a value of '1', you are likely affected. Note > that it may be normal for USB memory devices to report a low number. > Also, many legacy SCSI disks, and devices that are not disks, may also > be expected to report a low number. > > The effect of this problem is that only one I/O command will be issued > to the controller and disk at a time, instead of overlapping multiple > commands in parallel. This causes significantly higher latency in > servicing moderate and heavy I/O workloads, leading to very poor > performance. Performance can be easily compared by downgrading to > FreeBSD 7.0. > > I have committed a fix for this problem for FreeBSD 8-CURRENT as of SVN > revision 188570. FreeBSD 7-STABLE will be updated with the fix in a few > days once I've gotten confirmation that the fix works and doesn't cause > any adverse side-effects. Anyone wanting to help in this validation > effort should apply the attached patch to their kernel source tree and > recompile. Please contact me directly by email to report if the problem > is fixed for you. > > If the validation process goes smoothly, I will work with the release > engineering team to turn this fix into an official errata update for > FreeBSD 7.1. > > Thanks in advance for your help. > > Scott > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 13:34:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E93C31065674; Tue, 17 Feb 2009 13:34:32 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe10.tele2.se [212.247.155.33]) by mx1.freebsd.org (Postfix) with ESMTP id EEE0D8FC12; Tue, 17 Feb 2009 13:34:31 +0000 (UTC) (envelope-from hselasky@freebsd.org) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=v1l4sCoM7rMA:10 a=-QvcQp4i0RcA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=6I5d2MoRAAAA:8 a=37C_SMnpqsMWptgMDZsA:9 a=2plVApItBX5ctmSMZtmCfezVR3sA:4 a=LY0hPdMaydYA:10 a=SV7veod9ZcQA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe10.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1028233066; Tue, 17 Feb 2009 14:34:30 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 17 Feb 2009 14:36:57 +0100 User-Agent: KMail/1.9.7 References: <87mycme9wc.fsf@kobe.laptop> <200902170848.28659.hselasky@freebsd.org> <87eixxpgya.fsf@kobe.laptop> In-Reply-To: <87eixxpgya.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902171436.58658.hselasky@freebsd.org> Cc: Giorgos Keramidas , Andrew Thompson Subject: Re: usb2 moused issue (Microsoft Wireless Optical) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 13:34:33 -0000 On Tuesday 17 February 2009, Giorgos Keramidas wrote: > On Tue, 17 Feb 2009 08:48:27 +0100, Hans Petter Selasky wrote: > > Could you enable ums0 debugging output after the changes, when you > > plug the device? I just want to see that the isize has changed. > > Sure. Here's the output before the patch: > > kernel: ugen4.2: at usbus4 > kernel: ums0: 0/0, rev 2.00/0.07, addr 2> on usbus4 kernel: ums0: 5 buttons and [XYZ] > coordinates Feb 16 > kernel: ums_attach:582: sc=0xc63cd800 > kernel: ums_attach:583: X 48/8 > kernel: ums_attach:584: Y 56/8 > kernel: ums_attach:585: Z 64/8 > kernel: ums_attach:586: T 0/0 > kernel: ums_attach:587: W 0/0 > kernel: ums_attach:591: B1 40/1 > kernel: ums_attach:591: B2 41/1 > kernel: ums_attach:591: B3 42/1 > kernel: ums_attach:591: B4 43/1 > kernel: ums_attach:591: B5 44/1 > kernel: ums_attach:593: size=2, id=19 > kernel: Symlink: ums0 -> usb4.2.0.16 > > and the output after the patch: > > kernel: ugen4.2: at usbus4 > kernel: ums0: 0/0, rev 2.00/0.07, addr 2> on usbus4 kernel: ums0: 5 buttons and [XYZ] > coordinates > kernel: ums_attach:582: sc=0xc627dc00 > kernel: ums_attach:583: X 48/8 > kernel: ums_attach:584: Y 56/8 > kernel: ums_attach:585: Z 64/8 > kernel: ums_attach:586: T 0/0 > kernel: ums_attach:587: W 0/0 > kernel: ums_attach:591: B1 40/1 > kernel: ums_attach:591: B2 41/1 > kernel: ums_attach:591: B3 42/1 > kernel: ums_attach:591: B4 43/1 > kernel: ums_attach:591: B5 44/1 > kernel: ums_attach:593: size=2, id=19 > kernel: Symlink: ums0 -> usb4.2.0.16 Can you send me the patched file "sys/dev/usb2/core/usb2_hid.c" ? I cannot see that "size=2" has changed. It's wrong size information that causes your mouse problem. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 15:42:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 89BD0106566B; Tue, 17 Feb 2009 15:42:07 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout2.freenet.de (mout2.freenet.de [IPv6:2001:748:100:40::2:4]) by mx1.freebsd.org (Postfix) with ESMTP id 212918FC1D; Tue, 17 Feb 2009 15:42:07 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.18] (helo=8.mx.freenet.de) by mout2.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #76) id 1LZS5F-0004EI-9z; Tue, 17 Feb 2009 16:42:05 +0100 Received: from tfe29.t.pppool.de ([89.55.254.41]:51980 helo=ernst.jennejohn.org) by 8.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #76) id 1LZS5F-0007Kd-2g; Tue, 17 Feb 2009 16:42:05 +0100 Date: Tue, 17 Feb 2009 16:42:03 +0100 From: Gary Jennejohn To: Scott Long Message-ID: <20090217164203.4c586f48@ernst.jennejohn.org> In-Reply-To: <499981AF.9030204@samsco.org> References: <499981AF.9030204@samsco.org> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Stable , FreeBSD, scsi@freebsd.org Subject: Re: HEADS UP: More CAM fixes. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 15:42:08 -0000 On Mon, 16 Feb 2009 08:09:35 -0700 Scott Long wrote: > FWI. I need lots of testing on this. Only real SCSI controllers, > please, not RAID controllers (except for MPT-SCSI with integrated > mirroring). So Adaptec, LSI, Symbios, Buslogic, Tekram, SME, etc, > users, please try this and get back to me. The patch should apply > to FreeBSD 7 as well. FreeBSD 6 is only affected by this problem > when CAM_NEW_TRAN_CODE is enabled. > I tested this with an Adaptec 29160. I saw no real improvement in performance, but also no regressions. I suspect that the old disk I had attached just didn't have enough performance reserves to show an improvement. My test scenario was buildworld. Since /usr/src and /usr/obj were both on the one disk it got a pretty good workout. AMD64 X2 (2.5 GHz) with 4GB of RAM. BTW under a very fresh 8.0-current. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 16:02:29 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A8511065676; Tue, 17 Feb 2009 16:02:29 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe14.swip.net [212.247.155.161]) by mx1.freebsd.org (Postfix) with ESMTP id 8CB968FC22; Tue, 17 Feb 2009 16:02:28 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=q9aMRUVe28QA:10 a=Tt-RQtgY3TAA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=bCvvmm9C1JGzoZ3TFlgA:9 a=i-owtd1LMAKyLyGElVIA:7 a=Lq5oy7pyXRO6pxnerIMogtDI2L4A:4 a=50e4U0PicR4A:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe14.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 454740320; Tue, 17 Feb 2009 17:02:26 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org, Andrew Thompson Date: Tue, 17 Feb 2009 17:04:47 +0100 User-Agent: KMail/1.9.7 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902171704.48860.hselasky@c2i.net> Cc: Subject: USB2 + kdb support (UMASS disk dump + USB keyboard) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 16:02:29 -0000 Hi, With USB1 it was possible to use the USB keyboard in the debugger. With USB2 this is also possible, but not as long as the keyboard driver is using Giant. Currently USB2 supports a special mode called polling mode, which is going to be removed, because even on a micro embedded system polling mode is not useful, which was my thought keeping this behaviour. Instead I want to enforce normal running mode where USB and timer callbacks are handled like normal when in the kernel debugger. Question: When the CPU is in the debugger and is asking for USB devices to be polled, is there a way to get the USB threads running again so that callbacks can be handled? --HPS From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 17:41:42 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 889FE106566C for ; Tue, 17 Feb 2009 17:41:42 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout014.mac.com (asmtpout014.mac.com [17.148.16.89]) by mx1.freebsd.org (Postfix) with ESMTP id 743B18FC1C for ; Tue, 17 Feb 2009 17:41:42 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from roque-dt.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp014.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KF8009JX0Z8FI00@asmtp014.mac.com>; Tue, 17 Feb 2009 09:41:42 -0800 (PST) Message-id: <725CDB16-7D31-42C9-924E-DB6B595BF071@mac.com> From: Marcel Moolenaar To: "Bjoern A. Zeeb" In-reply-to: <20090217113718.N53478@maildrop.int.zabbadoz.net> Date: Tue, 17 Feb 2009 09:37:54 -0800 References: <20090217113718.N53478@maildrop.int.zabbadoz.net> X-Mailer: Apple Mail (2.930.3) Cc: Marcel Moolenaar , FreeBSD current mailing list Subject: Re: boot0cfg -s vs. GEOM_PART_*? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 17:41:42 -0000 On Feb 17, 2009, at 3:46 AM, Bjoern A. Zeeb wrote: > dopt# gpart set -a active -i 3 ad4 > gpart: pre-check failed: Device not configured Oops. This is a bug. The pre-check is not implemented for the MBR scheme and should succeed. I seem to have forgotten about the error that unimplemented methods return (KOBJ default). I'll fix this right away... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 17:50:50 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56245106576D for ; Tue, 17 Feb 2009 17:50:50 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f224.google.com (mail-gx0-f224.google.com [209.85.217.224]) by mx1.freebsd.org (Postfix) with ESMTP id DEF468FC23 for ; Tue, 17 Feb 2009 17:50:49 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk24 with SMTP id 24so5544894gxk.19 for ; Tue, 17 Feb 2009 09:50:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=c4vfJFy+zGkLqP2KJnaUpIvzBaqaDo4y7jaEbQDAikc=; b=H33Ioq4Twuaf9qV+nYqtXIh1LOhByaLMdI12K0vCXLDgd8BmshYKkHqYCzu/zzn46d 5uzS6vPmIX1XLziS6kUs8zqZ6u/aA0diUHsVlM+dzZ2Z7yW9SwOyVgw+DgYbreXBtmhJ n3Tcvdq6Wu6P+4LR+W1oG9FHgGR9gI1NEmhtU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=rqtZKNW0JURxfPje39lPU+25x+m+iGI2S8tlrbj/EYgjYXu+X8aB34JMv7h+ADfjR2 eW5VRoVcVU/b1MKjfuaguHKf4iP1FgfmhX1tTBg2ytuEa7gnSUZeHzq8VVdMsGMxUdXt SjBOvHEqm8a8SiDE9rg347DVVdNxNRHIpUlyk= MIME-Version: 1.0 Received: by 10.231.12.12 with SMTP id v12mr495779ibv.4.1234893049159; Tue, 17 Feb 2009 09:50:49 -0800 (PST) In-Reply-To: <20090217115651.GE79178@hoeg.nl> References: <20080526110543.J26343@fledge.watson.org> <4999F7F9.4030204@elischer.org> <499A024A.60209@protected-networks.net> <20090217110524.GC79178@hoeg.nl> <499A9C9D.3000403@protected-networks.net> <20090217115651.GE79178@hoeg.nl> Date: Tue, 17 Feb 2009 09:50:48 -0800 Message-ID: From: Maksim Yevmenkin To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Michael Butler , current@freebsd.org Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 17:50:52 -0000 On Tue, Feb 17, 2009 at 3:56 AM, Ed Schouten wrote: > Hello Michael, > > * Michael Butler wrote: >> I have NETGRAPH_BLUETOOTH et al defined in my kernel which automagically >> creates /dev/ubt0. With the appropriate entries in >> /etc/bluetooth/[hosts|hcsecd.conf], I simply do .. >> >> imb@toshi:/home/imb> less bin/gps-connect.sh >> #!/bin/sh >> /usr/bin/rfcomm_sppd -b -a QstarzGPS -t /dev/ttyp9 >> >> .. to bring it out to a device where roadnav or gspdrive can read it. >> >> Should I be doing something else in this script now? > > Well, this is not related to IFF_NEEDSGIANT and everything's fine, but > there is something else I don't like about this approach in general (the > way rfcomm_sppd works), namely that you `hardcode' a PTY name on the > command line. There is never a guarantee ttyp9 is available for use, > because another user can use it to log in with SSH, for example. > > Can you try this patch? > > http://80386.nl/pub/rfcomm_sppd.diff > > This changes the -t switch to take no argument and let the pseudo- > terminal be allocated with posix_openpt(). Unfortunately I don't know > how practical this is for rfcomm_sppd. So let me get this straight: when > you use rfcomm_sppd -t, the application itself will not give any output > and will close immediately (because it is run in the background). Maybe > we could change it to just printf() the pseudo-terminal name, so you can > do something like this: > > TTYNAME="`rfcomm_sppd -b -a QstarzGPS -t`" > # Use $TTYNAME here > > Any opinions on the subject? (Other people as well?) well, actually, the whole reason for providing tty name is to make sure rfcomm_sppd uses the specified tty. that is, if you want to _provide_ serial port service you need a "virtual serial port emulating entity" (aka tty :) . and, yes, you are correct, there is no guarantee that user specified tty will be available, but usually specifying high enough tty number works. perhaps the whole thing should be switched to use nmdm(4) or something like that. also, rfcomm_sppd(1) can use stdin/stdout instead of tty. this makes it possible to use rfcomm_sppd(1) in, for example, ppp(8) like so set device "!/usr/bin/rfcomm_sppd -a my_phone -c dun" ... this way rfcomm_sppd(1) will be started/killed by ppp(8) when it needs to open/close ppp connection using bluetooth enabled phone as wireless modem. so, for now, i think we should keep rfcomm_sppd(1) as it is. if this is not an option (with new tty subsystem) then we should convert it to use nmdm(4) or something similar. thanks, max From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 17:55:13 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E85C11065722 for ; Tue, 17 Feb 2009 17:55:13 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 7CBB88FC08 for ; Tue, 17 Feb 2009 17:55:13 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 490191CC77; Tue, 17 Feb 2009 18:55:12 +0100 (CET) Date: Tue, 17 Feb 2009 18:55:12 +0100 From: Ed Schouten To: Maksim Yevmenkin Message-ID: <20090217175512.GG79178@hoeg.nl> References: <20080526110543.J26343@fledge.watson.org> <4999F7F9.4030204@elischer.org> <499A024A.60209@protected-networks.net> <20090217110524.GC79178@hoeg.nl> <499A9C9D.3000403@protected-networks.net> <20090217115651.GE79178@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tQHaQFR6K/xpRpl8" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Michael Butler , current@freebsd.org Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 17:55:16 -0000 --tQHaQFR6K/xpRpl8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Maksim Yevmenkin wrote: > so, for now, i think we should keep rfcomm_sppd(1) as it is. if this > is not an option (with new tty subsystem) then we should convert it to > use nmdm(4) or something similar. Well, the problem with the current approach is that if you remove "device pty" from your kernel config, it won't work. With MPSAFE TTY we switched to Unix98-style pseudo-terminals, so the preferred mechanism is to call posix_openpt() (or open /dev/ptmx) and use ptsname() to determine which character device to use. I won't change anything now, but will keep my patch at the before mentioned URL. --=20 Ed Schouten WWW: http://80386.nl/ --tQHaQFR6K/xpRpl8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkma+gAACgkQ52SDGA2eCwVB6wCfRInJqLiFC5bb1UncooAUnS9q AywAn11BWsLsLPiIiQbQa7vkXFbUS4uC =XMJt -----END PGP SIGNATURE----- --tQHaQFR6K/xpRpl8-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 18:03:51 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F37FD106564A for ; Tue, 17 Feb 2009 18:03:50 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f224.google.com (mail-gx0-f224.google.com [209.85.217.224]) by mx1.freebsd.org (Postfix) with ESMTP id 875998FC1C for ; Tue, 17 Feb 2009 18:03:50 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk24 with SMTP id 24so5565985gxk.19 for ; Tue, 17 Feb 2009 10:03:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4a9rH6JoaqDAn7163rimrx1YWEwapjMNeUuu3E6O8XY=; b=W2zm6HGJOl8vEcitTBhU668Ci5t1U63bR51fRTUmYjp+wohDL35NM86UggXLj+GnEX 7JLaGzb0hDfIjcI1GBXqhL3bYCcQU+qCt703TEE4DH3753luXBt5hQYCDOsJfP48DVD9 VrKeiAeiTM0tLex0hUzEPjAqTFiQZhuPTEemA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Phf/5UH6gPmID+8CaDyTEIn3iTirNA2FiqO1T4Ufs1k8PaU5xDqlzNW5hX83HUTTTp RvVaM1dTlM5PXVIGk9GO3zfBPaNHCmpyfuiJbtwtQ28+7kdzWuV6PLX89QhJmyWx5tpD eOx0uK6+IYEIYg9iPiU4CqZPEXiF/FQQ7G3Gw= MIME-Version: 1.0 Received: by 10.231.16.129 with SMTP id o1mr1169301iba.47.1234893829591; Tue, 17 Feb 2009 10:03:49 -0800 (PST) In-Reply-To: <20090217175512.GG79178@hoeg.nl> References: <20080526110543.J26343@fledge.watson.org> <4999F7F9.4030204@elischer.org> <499A024A.60209@protected-networks.net> <20090217110524.GC79178@hoeg.nl> <499A9C9D.3000403@protected-networks.net> <20090217115651.GE79178@hoeg.nl> <20090217175512.GG79178@hoeg.nl> Date: Tue, 17 Feb 2009 10:03:49 -0800 Message-ID: From: Maksim Yevmenkin To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Michael Butler , current@freebsd.org Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 18:03:51 -0000 On Tue, Feb 17, 2009 at 9:55 AM, Ed Schouten wrote: > * Maksim Yevmenkin wrote: >> so, for now, i think we should keep rfcomm_sppd(1) as it is. if this >> is not an option (with new tty subsystem) then we should convert it to >> use nmdm(4) or something similar. > > Well, the problem with the current approach is that if you remove > "device pty" from your kernel config, it won't work. With MPSAFE TTY we > switched to Unix98-style pseudo-terminals, so the preferred mechanism is > to call posix_openpt() (or open /dev/ptmx) and use ptsname() to > determine which character device to use. is there a way allocate tty with a given name under "new world order"? > I won't change anything now, but will keep my patch at the before > mentioned URL. like i said, the only problem i have here is that any rfcomm_sppd callers will have to do extra work to figure which tty was allocated. that is the biggest difference from user's point of view. thanks, max > > -- > Ed Schouten > WWW: http://80386.nl/ > From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 18:21:29 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 32106106570B for ; Tue, 17 Feb 2009 18:21:29 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id E32718FC1B for ; Tue, 17 Feb 2009 18:21:28 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 462A41CC77; Tue, 17 Feb 2009 19:21:28 +0100 (CET) Date: Tue, 17 Feb 2009 19:21:28 +0100 From: Ed Schouten To: Maksim Yevmenkin Message-ID: <20090217182128.GH79178@hoeg.nl> References: <20080526110543.J26343@fledge.watson.org> <4999F7F9.4030204@elischer.org> <499A024A.60209@protected-networks.net> <20090217110524.GC79178@hoeg.nl> <499A9C9D.3000403@protected-networks.net> <20090217115651.GE79178@hoeg.nl> <20090217175512.GG79178@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="l4IMblsHEWQg+b+m" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Michael Butler , current@freebsd.org Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 18:21:29 -0000 --l4IMblsHEWQg+b+m Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Maksim, * Maksim Yevmenkin wrote: > On Tue, Feb 17, 2009 at 9:55 AM, Ed Schouten wrote: > > * Maksim Yevmenkin wrote: > >> so, for now, i think we should keep rfcomm_sppd(1) as it is. if this > >> is not an option (with new tty subsystem) then we should convert it to > >> use nmdm(4) or something similar. > > > > Well, the problem with the current approach is that if you remove > > "device pty" from your kernel config, it won't work. With MPSAFE TTY we > > switched to Unix98-style pseudo-terminals, so the preferred mechanism is > > to call posix_openpt() (or open /dev/ptmx) and use ptsname() to > > determine which character device to use. >=20 > is there a way allocate tty with a given name under "new world order"? No, there isn't. I have been thinking about this. Allowing pseudo-terminals to be allocated with a certain name would allow us to do things like implementing device drivers as a daemon in userspace. > > I won't change anything now, but will keep my patch at the before > > mentioned URL. >=20 > like i said, the only problem i have here is that any rfcomm_sppd > callers will have to do extra work to figure which tty was allocated. > that is the biggest difference from user's point of view. Well, we already have existing tools that use such an approach as well, like mdmconfig. They print a name of the md device to stdout. I'm not saying I'm 100% happy with this approach, but it's more correct than just reserving a certain pseudo-terminal device name. --=20 Ed Schouten WWW: http://80386.nl/ --l4IMblsHEWQg+b+m Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmbACgACgkQ52SDGA2eCwWTTACfXyZ95/Y4f84feVDt96jZlivr BUQAn3l+NJ4CGRD1La8q35CdhqUG0+at =8dvc -----END PGP SIGNATURE----- --l4IMblsHEWQg+b+m-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 18:31:17 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88BFB106575D; Tue, 17 Feb 2009 18:31:17 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout014.mac.com (asmtpout014.mac.com [17.148.16.89]) by mx1.freebsd.org (Postfix) with ESMTP id 6BB1F8FC12; Tue, 17 Feb 2009 18:31:17 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp014.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KF80098K3CNIG10@asmtp014.mac.com>; Tue, 17 Feb 2009 10:31:14 -0800 (PST) Message-id: From: Marcel Moolenaar To: "Bjoern A. Zeeb" In-reply-to: <20090217113718.N53478@maildrop.int.zabbadoz.net> Date: Tue, 17 Feb 2009 10:29:10 -0800 References: <20090217113718.N53478@maildrop.int.zabbadoz.net> X-Mailer: Apple Mail (2.930.3) Cc: Marcel Moolenaar , FreeBSD current mailing list Subject: Re: boot0cfg -s vs. GEOM_PART_*? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 18:31:19 -0000 On Feb 17, 2009, at 3:46 AM, Bjoern A. Zeeb wrote: > with a fresh kernel and world from last night I get: > > dopt# boot0cfg -s 3 ad4 > boot0cfg: /dev/ad4: ad4 > boot0cfg: /dev/ad4: ioctl DIOCSMBR: Inappropriate ioctl for device > > is this GEOM_PART_* fallout and can it be fixed? boot0cfg is not (yet) supported by GPART. It should not be too hard: 1. We need to expose the current bootcode through kern.geom.confxml 2. boot0cfg grabs the bootcode from the XML, makes the changes in memory and then uses existing g_part ctlreq to update the bootcode. > I am wondering how to change it from a rnning system now, as > > dopt# gpart set -a active -i 3 ad4 > gpart: pre-check failed: Device not configured Fixed in revision 188723. Sorry about that. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 18:37:13 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9CCC710656C8 for ; Tue, 17 Feb 2009 18:37:13 +0000 (UTC) (envelope-from ulf.lilleengen@gmail.com) Received: from bene2.itea.ntnu.no (bene2.itea.ntnu.no [IPv6:2001:700:300:3::57]) by mx1.freebsd.org (Postfix) with ESMTP id E8FA08FC08 for ; Tue, 17 Feb 2009 18:37:12 +0000 (UTC) (envelope-from ulf.lilleengen@gmail.com) Received: from localhost (localhost [127.0.0.1]) by bene2.itea.ntnu.no (Postfix) with ESMTP id 42A359000C; Tue, 17 Feb 2009 19:37:11 +0100 (CET) Received: from carrot (unknown [IPv6:2001:700:300:3::184]) by bene2.itea.ntnu.no (Postfix) with ESMTP id E11509000B; Tue, 17 Feb 2009 19:37:10 +0100 (CET) Date: Tue, 17 Feb 2009 19:38:00 +0000 From: Ulf Lilleengen To: Marcel Moolenaar Message-ID: <20090217193759.GA27739@carrot> References: <20090217113718.N53478@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: Debian amavisd-new at bene2.itea.ntnu.no Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: boot0cfg -s vs. GEOM_PART_*? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 18:37:14 -0000 On Tue, Feb 17, 2009 at 10:29:10AM -0800, Marcel Moolenaar wrote: > > On Feb 17, 2009, at 3:46 AM, Bjoern A. Zeeb wrote: > > > with a fresh kernel and world from last night I get: > > > > dopt# boot0cfg -s 3 ad4 > > boot0cfg: /dev/ad4: ad4 > > boot0cfg: /dev/ad4: ioctl DIOCSMBR: Inappropriate ioctl for device > > > > is this GEOM_PART_* fallout and can it be fixed? > > boot0cfg is not (yet) supported by GPART. It should not > be too hard: > 1. We need to expose the current bootcode through > kern.geom.confxml > 2. boot0cfg grabs the bootcode from the XML, makes > the changes in memory and then uses existing > g_part ctlreq to update the bootcode. Mhm, this seems to be a good way to do it. Also, fdisk and bsdlabel might need a sweep as well. -- Ulf Lilleengen From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 18:55:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD11E10656E0; Tue, 17 Feb 2009 18:55:44 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 595C88FC17; Tue, 17 Feb 2009 18:55:44 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl126-61.kln.forthnet.gr [77.49.245.61]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-6) with ESMTP id n1HItWRo006048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Feb 2009 20:55:37 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n1HItVbG019633; Tue, 17 Feb 2009 20:55:31 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n1HItVdN019632; Tue, 17 Feb 2009 20:55:31 +0200 (EET) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Hans Petter Selasky References: <87mycme9wc.fsf@kobe.laptop> <200902170848.28659.hselasky@freebsd.org> <87eixxpgya.fsf@kobe.laptop> <200902171436.58658.hselasky@freebsd.org> Date: Tue, 17 Feb 2009 20:55:30 +0200 In-Reply-To: <200902171436.58658.hselasky@freebsd.org> (Hans Petter Selasky's message of "Tue, 17 Feb 2009 14:36:57 +0100") Message-ID: <87tz6sdhb1.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Hellug-MailScanner-ID: n1HItWRo006048 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.485, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL -0.09, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: usb2 moused issue (Microsoft Wireless Optical) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 18:55:45 -0000 On Tue, 17 Feb 2009 14:36:57 +0100, Hans Petter Selasky wrote: > Can you send me the patched file "sys/dev/usb2/core/usb2_hid.c" ? I > cannot see that "size=2" has changed. It's wrong size information that > causes your mouse problem. It is usb2_hid.c from /head at svn rev 188665, plus the changes you sent me before. Script started on Tue Feb 17 20:25:31 2009 keramida@kobe:/home/keramida/svn/head$ svn diff sys/dev/usb2/core Index: sys/dev/usb2/core/usb2_hid.c =================================================================== --- sys/dev/usb2/core/usb2_hid.c (revision 188665) +++ sys/dev/usb2/core/usb2_hid.c (working copy) @@ -392,22 +392,38 @@ { struct hid_data *d; struct hid_item h; - int hi, lo, size, id; + uint32_t size; + uint32_t hi; + uint32_t lo; + uint8_t id; id = 0; - hi = lo = -1; + hi = 0; + lo = (uint32_t)(0-1); for (d = hid_start_parse(buf, len, 1 << k); hid_get_item(d, &h);) if (h.kind == k) { if (h.report_ID != 0 && !id) id = h.report_ID; if (h.report_ID == id) { - if (lo < 0) + /* check if "lo" is greater than "pos" */ + if (lo > h.loc.pos) lo = h.loc.pos; - hi = h.loc.pos + h.loc.size * h.loc.count; + /* compute end position */ + size = h.loc.pos + (h.loc.size * h.loc.count); + /* check if "size" wrapped */ + /* check if "hi" is less than "size" */ + if (size < h.loc.pos) + hi = (uint32_t)(0-1); + else if (hi < size) + hi = size; } } hid_end_parse(d); - size = hi - lo; + if (lo > hi) + size = 0; + else + size = hi - lo; + if (id != 0) { size += 8; *idp = id; /* XXX wrong */ keramida@kobe:/home/keramida/svn/head$ exit exit Script done on Tue Feb 17 20:25:39 2009 The code of hid_report_size() is similar in old usb and the new usb stack, but I am not sure about all the differences I see. The calculation of `size' is done correctly with old usb code, so I am testing the patch attached below now. It essentially pulls in the hid_report_size() from the old usb code, with the if (h.kind == k) check reversed to remove one spurious indentation level: %%% diff --git a/sys/dev/usb2/core/usb2_hid.c b/sys/dev/usb2/core/usb2_hid.c --- a/sys/dev/usb2/core/usb2_hid.c +++ b/sys/dev/usb2/core/usb2_hid.c @@ -392,41 +392,26 @@ { struct hid_data *d; struct hid_item h; - uint32_t size; - uint32_t hi; - uint32_t lo; - uint8_t id; + int hi, lo, size, id; id = 0; - hi = 0; - lo = (uint32_t)(0-1); - for (d = hid_start_parse(buf, len, 1 << k); hid_get_item(d, &h);) - if (h.kind == k) { - if (h.report_ID != 0 && !id) - id = h.report_ID; - if (h.report_ID == id) { - /* check if "lo" is greater than "pos" */ - if (lo > h.loc.pos) - lo = h.loc.pos; - /* compute end position */ - size = h.loc.pos + (h.loc.size * h.loc.count); - /* check if "size" wrapped */ - /* check if "hi" is less than "size" */ - if (size < h.loc.pos) - hi = (uint32_t)(0-1); - else if (hi < size) - hi = size; - } + hi = lo = -1; + for (d = hid_start_parse(buf, len, 1< hi) - size = 0; - else - size = hi - lo; - + size = hi - lo; if (id != 0) { size += 8; - *idp = id; /* XXX wrong */ + *idp = id; /* XXX wrong */ } else *idp = 0; return ((size + 7) / 8); %%% I'll report back later ;) From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 19:00:00 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 877E6106566C for ; Tue, 17 Feb 2009 19:00:00 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout011.mac.com (asmtpout011.mac.com [17.148.16.86]) by mx1.freebsd.org (Postfix) with ESMTP id 6D35E8FC13 for ; Tue, 17 Feb 2009 19:00:00 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from sivam-t43.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp011.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KF800FX84RYRX10@asmtp011.mac.com> for current@freebsd.org; Tue, 17 Feb 2009 10:59:59 -0800 (PST) Message-id: <9FE792C6-8560-4C64-BD74-CD70DF5EBBF5@mac.com> From: Marcel Moolenaar To: Ulf Lilleengen In-reply-to: <20090217193759.GA27739@carrot> Date: Tue, 17 Feb 2009 10:59:57 -0800 References: <20090217113718.N53478@maildrop.int.zabbadoz.net> <20090217193759.GA27739@carrot> X-Mailer: Apple Mail (2.930.3) Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: boot0cfg -s vs. GEOM_PART_*? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 19:00:00 -0000 On Feb 17, 2009, at 11:38 AM, Ulf Lilleengen wrote: > On Tue, Feb 17, 2009 at 10:29:10AM -0800, Marcel Moolenaar wrote: >> >> On Feb 17, 2009, at 3:46 AM, Bjoern A. Zeeb wrote: >> >>> with a fresh kernel and world from last night I get: >>> >>> dopt# boot0cfg -s 3 ad4 >>> boot0cfg: /dev/ad4: ad4 >>> boot0cfg: /dev/ad4: ioctl DIOCSMBR: Inappropriate ioctl for device >>> >>> is this GEOM_PART_* fallout and can it be fixed? >> >> boot0cfg is not (yet) supported by GPART. It should not >> be too hard: >> 1. We need to expose the current bootcode through >> kern.geom.confxml >> 2. boot0cfg grabs the bootcode from the XML, makes >> the changes in memory and then uses existing >> g_part ctlreq to update the bootcode. > Mhm, this seems to be a good way to do it. Also, fdisk and bsdlabel > might > need a sweep as well. That won't be as easy as boot0cfg. Both fdisk and bsdlabel do all partitioning operations in memory and then expect to dump/write the blob. This is not how gpart works, so there's a mismatch in paradigm. With respect to partitioning, I'd rather we focus our attention to a more user-friendly tool. The geom tool is really low-level and could use some UI "fodder". Also, I started writing pe(8) a while back, which is a ncurses-based partition editor. I think a nice partitioning tool would be good to have. For those interested in pe(8), I have diffs here. It's nowhere near useful, but it should give a first glipse of what I was thinking of: http://people.freebsd.org/~marcel/gpt.diff Certain aspects of the code show early thinking and has been implemented differently in gpart nowadays... :-) -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 19:08:00 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F89D1065672 for ; Tue, 17 Feb 2009 19:08:00 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from mail-gx0-f224.google.com (mail-gx0-f224.google.com [209.85.217.224]) by mx1.freebsd.org (Postfix) with ESMTP id D21CE8FC22 for ; Tue, 17 Feb 2009 19:07:59 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by gxk24 with SMTP id 24so5670534gxk.19 for ; Tue, 17 Feb 2009 11:07:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ppb0j+d4zxXHNCJfvkufBdkbzrZeV0KS19JOxiZCg78=; b=KIgOPzNs6YgtxQOZgh8JDH62Bxuq4U25k7wcROldhiJhHSiSkDVTfArzxr/mQheV9z SHoCTegMqqdCHznnGZdjcHgOjtyIv6K6uFdjxhRnn70Foiwj2n3utW4Kq18kH70VcK5X oWW4vDuCxoCafE3+h0ID9vFm7MiGjQ/N3L3Cg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dOkL3eizkSdGPRb2gmbEqgdy2xLUfNbouh+y+PM3itxVpIVAxYA4LYTNNrRHp9EqOy u4a2Aa1El1dIbTbylOVgw2PdCTLVH62E1cW1ZpKWCszGY6ztt5vAbA/pcCeOKbYOV8y1 MDeAbHge1wOdwOaWHMtdWPwkV+vej0sGK6uH4= MIME-Version: 1.0 Received: by 10.231.20.1 with SMTP id d1mr1215004ibb.19.1234897678871; Tue, 17 Feb 2009 11:07:58 -0800 (PST) In-Reply-To: <20090217182128.GH79178@hoeg.nl> References: <20080526110543.J26343@fledge.watson.org> <4999F7F9.4030204@elischer.org> <499A024A.60209@protected-networks.net> <20090217110524.GC79178@hoeg.nl> <499A9C9D.3000403@protected-networks.net> <20090217115651.GE79178@hoeg.nl> <20090217175512.GG79178@hoeg.nl> <20090217182128.GH79178@hoeg.nl> Date: Tue, 17 Feb 2009 11:07:58 -0800 Message-ID: From: Maksim Yevmenkin To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Michael Butler , current@freebsd.org Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 19:08:00 -0000 On Tue, Feb 17, 2009 at 10:21 AM, Ed Schouten wrote: > Hi Maksim, > > * Maksim Yevmenkin wrote: >> On Tue, Feb 17, 2009 at 9:55 AM, Ed Schouten wrote: >> > * Maksim Yevmenkin wrote: >> >> so, for now, i think we should keep rfcomm_sppd(1) as it is. if this >> >> is not an option (with new tty subsystem) then we should convert it to >> >> use nmdm(4) or something similar. >> > >> > Well, the problem with the current approach is that if you remove >> > "device pty" from your kernel config, it won't work. With MPSAFE TTY we >> > switched to Unix98-style pseudo-terminals, so the preferred mechanism is >> > to call posix_openpt() (or open /dev/ptmx) and use ptsname() to >> > determine which character device to use. >> >> is there a way allocate tty with a given name under "new world order"? > > No, there isn't. I have been thinking about this. Allowing > pseudo-terminals to be allocated with a certain name would allow us to > do things like implementing device drivers as a daemon in userspace. ok >> > I won't change anything now, but will keep my patch at the before >> > mentioned URL. >> >> like i said, the only problem i have here is that any rfcomm_sppd >> callers will have to do extra work to figure which tty was allocated. >> that is the biggest difference from user's point of view. > > Well, we already have existing tools that use such an approach as well, > like mdmconfig. They print a name of the md device to stdout. I'm not > saying I'm 100% happy with this approach, but it's more correct than > just reserving a certain pseudo-terminal device name. do you mean mdconfig(8) and its ability to print auto-allocated /dev/md device unit? if so, it can also allocate specific /dev/md unit, so it really has both options. your patch simply eliminates one of the option and forces users to always use auto-allocation. i'm not saying its bad, i'm just saying its different from what it used to be. that is all. anyway, i guess conversion to nmdm(4) is in order then. at least this way users will have to change /dev/tty to /dev/nmdm which is possibly less pain than other alternatives. while we are at it, we also could implement your approach, i.e. auto-allocate and print /dev/nmdm node if requested. thanks, max From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 19:21:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12DD01065672 for ; Tue, 17 Feb 2009 19:21:54 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id C4A0B8FC21 for ; Tue, 17 Feb 2009 19:21:53 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id BDBE51CC77; Tue, 17 Feb 2009 20:21:52 +0100 (CET) Date: Tue, 17 Feb 2009 20:21:52 +0100 From: Ed Schouten To: Maksim Yevmenkin Message-ID: <20090217192152.GI79178@hoeg.nl> References: <4999F7F9.4030204@elischer.org> <499A024A.60209@protected-networks.net> <20090217110524.GC79178@hoeg.nl> <499A9C9D.3000403@protected-networks.net> <20090217115651.GE79178@hoeg.nl> <20090217175512.GG79178@hoeg.nl> <20090217182128.GH79178@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WTEzZvM72OaERIi0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Michael Butler , current@freebsd.org Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 19:21:54 -0000 --WTEzZvM72OaERIi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Maksim Yevmenkin wrote: > anyway, i guess conversion to nmdm(4) is in order then. at least this > way users will have to change /dev/tty to /dev/nmdm which is possibly > less pain than other alternatives. while we are at it, we also could > implement your approach, i.e. auto-allocate and print /dev/nmdm node > if requested. But nmdm(4) is not really meant to be used for stuff like that, not that I think pts(4) should even be abused for this. The reason why pts(4) is used, is because the application tries to mimic a serial port of some sort on which data arrives that is normally handled by some kind of pppd. pts(4) doesn't have a lot of overhead in this setup. As you mentioned earlier, there is no need to use pts(4), because rfcomm_sppd also supports using stdout/stdin. This is a lot better, because our pipe implementation is probably a lot faster than pts(4). I'd rather see the handbook changed to not mention TTYs anywhere. --=20 Ed Schouten WWW: http://80386.nl/ --WTEzZvM72OaERIi0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmbDlAACgkQ52SDGA2eCwU2lQCeOVRHhDJe92KXaSqjTUOYi5jG SuQAniBRytJmBrHh0FutArlEOyUPh7ny =UA93 -----END PGP SIGNATURE----- --WTEzZvM72OaERIi0-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 19:23:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E518A1065704; Tue, 17 Feb 2009 19:23:18 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 608D48FC2F; Tue, 17 Feb 2009 19:23:17 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl126-61.kln.forthnet.gr [77.49.245.61]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-6) with ESMTP id n1HJN48a008729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Feb 2009 21:23:10 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n1HJN4MQ012914; Tue, 17 Feb 2009 21:23:04 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n1HJN3Ff012874; Tue, 17 Feb 2009 21:23:03 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Hans Petter Selasky References: <87mycme9wc.fsf@kobe.laptop> <200902170848.28659.hselasky@freebsd.org> <87eixxpgya.fsf@kobe.laptop> <200902171436.58658.hselasky@freebsd.org> <87tz6sdhb1.fsf@kobe.laptop> Date: Tue, 17 Feb 2009 21:23:03 +0200 In-Reply-To: <87tz6sdhb1.fsf@kobe.laptop> (Giorgos Keramidas's message of "Tue, 17 Feb 2009 20:55:30 +0200") Message-ID: <87tz6sj2aw.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Hellug-MailScanner-ID: n1HJN48a008729 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.875, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.52, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: usb2 moused issue (Microsoft Wireless Optical) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 19:23:20 -0000 On Tue, 17 Feb 2009 20:55:30 +0200, Giorgos Keramidas wrote: > The code of hid_report_size() is similar in old usb and the new usb > stack, but I am not sure about all the differences I see. The > calculation of `size' is done correctly with old usb code, so I am > testing the patch attached below now. It essentially pulls in the > hid_report_size() from the old usb code, with the if (h.kind == k) check > reversed to remove one spurious indentation level: No luck with the old usb code for hid_report_size() either. We may be looking at the wrong place. I'll build a kernel with a pre-usb2 stack and see what ums debugging shows for this mouse. If it used to work with size=2 then we might have to look elsewhere for the bug. From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 19:37:40 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A7491065692; Tue, 17 Feb 2009 19:37:40 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id C97658FC13; Tue, 17 Feb 2009 19:37:39 +0000 (UTC) (envelope-from hselasky@freebsd.org) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=v1l4sCoM7rMA:10 a=-QvcQp4i0RcA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=6I5d2MoRAAAA:8 a=j3337_ArTOnjN38r2ZAA:9 a=bfMOuIxchP6vL-kLgSEA:7 a=bbDz0ygQ19usFYDZqbD0KfGsRYoA:4 a=LY0hPdMaydYA:10 a=SV7veod9ZcQA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1197290750; Tue, 17 Feb 2009 20:37:38 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 17 Feb 2009 20:40:05 +0100 User-Agent: KMail/1.9.7 References: <87mycme9wc.fsf@kobe.laptop> <87tz6sdhb1.fsf@kobe.laptop> <87tz6sj2aw.fsf@kobe.laptop> In-Reply-To: <87tz6sj2aw.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902172040.06348.hselasky@freebsd.org> Cc: Giorgos Keramidas , Andrew Thompson Subject: Re: usb2 moused issue (Microsoft Wireless Optical) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 19:37:41 -0000 On Tuesday 17 February 2009, Giorgos Keramidas wrote: > On Tue, 17 Feb 2009 20:55:30 +0200, Giorgos Keramidas wrote: > > The code of hid_report_size() is similar in old usb and the new usb > > stack, but I am not sure about all the differences I see. The > > calculation of `size' is done correctly with old usb code, so I am > > testing the patch attached below now. It essentially pulls in the > > hid_report_size() from the old usb code, with the if (h.kind == k) check > > reversed to remove one spurious indentation level: > > No luck with the old usb code for hid_report_size() either. We may be > looking at the wrong place. I'll build a kernel with a pre-usb2 stack > and see what ums debugging shows for this mouse. If it used to work > with size=2 then we might have to look elsewhere for the bug. I don't think that will help. Can you try the following. XYZ information includes: (64+8-40)/8 = 4 bytes Then you need add one PD byte, so size should be 5 bytes. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 19:48:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0F2F106564A; Tue, 17 Feb 2009 19:48:44 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe02.swip.net [212.247.154.33]) by mx1.freebsd.org (Postfix) with ESMTP id 49CE58FC1B; Tue, 17 Feb 2009 19:48:43 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=v1l4sCoM7rMA:10 a=-QvcQp4i0RcA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=6I5d2MoRAAAA:8 a=EHBwwFOhjfWp-xShJlAA:9 a=ILQEA7Zb3BuWGUTgViUA:7 a=YlKnIW4Cj1R7o28Bbi-yqSmv-osA:4 a=LY0hPdMaydYA:10 a=SV7veod9ZcQA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe02.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1200782402; Tue, 17 Feb 2009 20:48:42 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Tue, 17 Feb 2009 20:51:10 +0100 User-Agent: KMail/1.9.7 References: <87mycme9wc.fsf@kobe.laptop> <87tz6sj2aw.fsf@kobe.laptop> <200902172040.06348.hselasky@freebsd.org> In-Reply-To: <200902172040.06348.hselasky@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902172051.11077.hselasky@c2i.net> Cc: Giorgos Keramidas , Andrew Thompson Subject: Re: usb2 moused issue (Microsoft Wireless Optical) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 19:48:46 -0000 On Tuesday 17 February 2009, Hans Petter Selasky wrote: > On Tuesday 17 February 2009, Giorgos Keramidas wrote: > > On Tue, 17 Feb 2009 20:55:30 +0200, Giorgos Keramidas > > > > wrote: > > > The code of hid_report_size() is similar in old usb and the new usb > > > stack, but I am not sure about all the differences I see. The > > > calculation of `size' is done correctly with old usb code, so I am > > > testing the patch attached below now. It essentially pulls in the > > > hid_report_size() from the old usb code, with the if (h.kind == k) > > > check reversed to remove one spurious indentation level: > > > > No luck with the old usb code for hid_report_size() either. We may be > > looking at the wrong place. I'll build a kernel with a pre-usb2 stack > > and see what ums debugging shows for this mouse. If it used to work > > with size=2 then we might have to look elsewhere for the bug. > > I don't think that will help. Can you try the following. > > XYZ information includes: (64+8-40)/8 = 4 bytes > > Then you need add one PD byte, so size should be 5 bytes. Maybe this will help: kldload usb2_quirk And re-plug mouse? Because it looks like your mouse is already listed there. BTW: I want to find a permanent solution for those quirks. So stand by for another patch. --HPS From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 19:51:47 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA30C106572C for ; Tue, 17 Feb 2009 19:51:46 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.29]) by mx1.freebsd.org (Postfix) with ESMTP id 9A4998FC2B for ; Tue, 17 Feb 2009 19:51:46 +0000 (UTC) (envelope-from maksim.yevmenkin@gmail.com) Received: by yx-out-2324.google.com with SMTP id 31so1297905yxl.13 for ; Tue, 17 Feb 2009 11:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pSZsE/1K4R5cdm1EMr41O15KGOAjcy4V6cTlnyu13RM=; b=xZ8rp6OBjWBloAJWugMGofphmLuyH1wQBnOzQOIkLbfjAP8oGqo33nxRlWxkH4aWvu G0jVGAXSooTL3lGb97yxTtlG6dNL6hkA8DJnPrrGDW4K4uAqakhdD98UHQItHGWB2s0S hPS62cmmQubTvit3/FeQggWh5wLcc+wh4wB3A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=H2+sNw9WFlXXuNlzs6kUZ/5we6CxJsNHgxe2br9A9Bkbmcqf62mkehYiZ7eHFwzk+V DP76b/9ZNd61SWOx18dTfpK6mLLcqRG5YKYrBYlG7q4mf/jIhU7l0yyaI93u6ay5aCqw S89q7njIU7zMRfUYZrQBGHGYGJhQqJHFn3GWs= MIME-Version: 1.0 Received: by 10.151.26.12 with SMTP id d12mr5219657ybj.217.1234900306016; Tue, 17 Feb 2009 11:51:46 -0800 (PST) In-Reply-To: <20090217192152.GI79178@hoeg.nl> References: <4999F7F9.4030204@elischer.org> <20090217110524.GC79178@hoeg.nl> <499A9C9D.3000403@protected-networks.net> <20090217115651.GE79178@hoeg.nl> <20090217175512.GG79178@hoeg.nl> <20090217182128.GH79178@hoeg.nl> <20090217192152.GI79178@hoeg.nl> Date: Tue, 17 Feb 2009 11:51:45 -0800 Message-ID: From: Maksim Yevmenkin To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Michael Butler , current@freebsd.org Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 19:51:51 -0000 On Tue, Feb 17, 2009 at 11:21 AM, Ed Schouten wrote: > * Maksim Yevmenkin wrote: >> anyway, i guess conversion to nmdm(4) is in order then. at least this >> way users will have to change /dev/tty to /dev/nmdm which is possibly >> less pain than other alternatives. while we are at it, we also could >> implement your approach, i.e. auto-allocate and print /dev/nmdm node >> if requested. > > But nmdm(4) is not really meant to be used for stuff like that, not that why not? i think its exactly what it was meant for. > I think pts(4) should even be abused for this. The reason why pts(4) is > used, is because the application tries to mimic a serial port of some > sort on which data arrives that is normally handled by some kind of > pppd. pts(4) doesn't have a lot of overhead in this setup. not really. imagine a legacy application that wants to talk some sort of serial protocol. now imagine that you want to replace your physical serial cable with bluetooth link. all you really need is 1) run rfcomm_sppd in server mode and tell it to use /dev/nmdmA 2) run legacy application on /dev/nmdmB when wireless client connects to the rfcomm_sppd legacy application will get input from /dev/nmdmB just as it would get it from /dev/cuau or whatever. the whole purpose of those little wrappers is to provide legacy application with something that looks like serial port. otherwise it is required to change the legacy application and make it aware of bluetooth etc. for example, you _could_ change ppp(8) and teach it about bluetooth etc, but why do it? its so much simpler/cleaner to write small wrapper that gives access to bluetooth link via something ppp(8) already knows about, i.e. tty and/or stdin/stdout. > As you mentioned earlier, there is no need to use pts(4), because > rfcomm_sppd also supports using stdout/stdin. This is a lot better, > because our pipe implementation is probably a lot faster than pts(4). > I'd rather see the handbook changed to not mention TTYs anywhere. its not all about speed. its about flexibility. thanks, max From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 19:55:28 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 502CE106564A for ; Tue, 17 Feb 2009 19:55:28 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 149DB8FC19 for ; Tue, 17 Feb 2009 19:55:27 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 12DB13F129; Tue, 17 Feb 2009 19:55:27 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n1HJtUj0015529; Tue, 17 Feb 2009 19:55:30 GMT (envelope-from phk@critter.freebsd.dk) To: Maksim Yevmenkin From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 17 Feb 2009 11:51:45 PST." Date: Tue, 17 Feb 2009 19:55:30 +0000 Message-ID: <15528.1234900530@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Ed Schouten , Michael Butler , current@freebsd.org Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 19:55:29 -0000 In message , Maksim Yevmenkin writes: >> But nmdm(4) is not really meant to be used for stuff like that, not that > >why not? i think its exactly what it was meant for. A further example: Testing software that implements serial protocols is soo much easier when one does not have to lug a serial cable around. 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-current@FreeBSD.ORG Tue Feb 17 19:58:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46EF71065676 for ; Tue, 17 Feb 2009 19:58:54 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 0AB188FC0C for ; Tue, 17 Feb 2009 19:58:53 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 0D42C3F130; Tue, 17 Feb 2009 19:58:53 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n1HJwulq015553; Tue, 17 Feb 2009 19:58:56 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 17 Feb 2009 10:59:57 PST." <9FE792C6-8560-4C64-BD74-CD70DF5EBBF5@mac.com> Date: Tue, 17 Feb 2009 19:58:56 +0000 Message-ID: <15552.1234900736@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list , Ulf Lilleengen Subject: Re: boot0cfg -s vs. GEOM_PART_*? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 19:58:54 -0000 In message <9FE792C6-8560-4C64-BD74-CD70DF5EBBF5@mac.com>, Marcel Moolenaar wri tes: >That won't be as easy as boot0cfg. Both fdisk and bsdlabel >do all partitioning operations in memory and then expect to >dump/write the blob. This is not how gpart works, so there's >a mismatch in paradigm. The reason for that modus operandi, was that the kernel only needed code to read the metadata, the software that formatted and wrote the metadata could be contained entirely in userland thus not bloating the kernel. Your choice is legit as well, with today RAM sizes I doubt the difference is measureable. But not updating boot0cfg to support the new API got you a bad mark in my book. I would prefer if fdisk and bsdlabel also kept working or at least gave some guidance on what to do. 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-current@FreeBSD.ORG Tue Feb 17 19:59:57 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E56021065672 for ; Tue, 17 Feb 2009 19:59:57 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A6F608FC1F for ; Tue, 17 Feb 2009 19:59:57 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id DCEDC3F129; Tue, 17 Feb 2009 19:59:56 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n1HK00RD015567; Tue, 17 Feb 2009 20:00:00 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 17 Feb 2009 10:29:10 PST." Date: Tue, 17 Feb 2009 20:00:00 +0000 Message-ID: <15566.1234900800@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: "Bjoern A. Zeeb" , Marcel Moolenaar , FreeBSD current mailing list Subject: Re: boot0cfg -s vs. GEOM_PART_*? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 19:59:58 -0000 In message , Marcel Moolenaar wri tes: >1. We need to expose the current bootcode through > kern.geom.confxml No. No. NO. We do not want arbitrary large binary blobs in the confxml output. 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-current@FreeBSD.ORG Tue Feb 17 20:05:10 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D9E31065670 for ; Tue, 17 Feb 2009 20:05:10 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 2AAA58FC13 for ; Tue, 17 Feb 2009 20:05:10 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 8952D1CC77; Tue, 17 Feb 2009 21:05:09 +0100 (CET) Date: Tue, 17 Feb 2009 21:05:09 +0100 From: Ed Schouten To: Maksim Yevmenkin Message-ID: <20090217200509.GJ79178@hoeg.nl> References: <20090217110524.GC79178@hoeg.nl> <499A9C9D.3000403@protected-networks.net> <20090217115651.GE79178@hoeg.nl> <20090217175512.GG79178@hoeg.nl> <20090217182128.GH79178@hoeg.nl> <20090217192152.GI79178@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mHEGYOlXWdrdotU2" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Michael Butler , current@freebsd.org Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 20:05:10 -0000 --mHEGYOlXWdrdotU2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Maksim Yevmenkin wrote: > its not all about speed. its about flexibility. Yes, but abusing TTYs reduces flexibility. Once you're doing stuff in user space, try to keep it there. There is no reason why one should prefer to use pts(4) to exchange data between processes when pipes are sufficient for the particular scenario. Depending on pseudo-terminals makes your application less portable and even less likely to work in the future. Just see what happened here. FreeBSD now uses a more standard pseudo-terminal allocation interface and stuff breaks. TTY implementations have never proven to be portable at all. --=20 Ed Schouten WWW: http://80386.nl/ --mHEGYOlXWdrdotU2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmbGHUACgkQ52SDGA2eCwXzCQCdF12N59Jpykm5QwQxvwxM0Nz6 LbYAn0A4W6glWbTYeHH7WxmGosKT+zWv =ZuUf -----END PGP SIGNATURE----- --mHEGYOlXWdrdotU2-- From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 20:20:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7AEFA106564A; Tue, 17 Feb 2009 20:20:16 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id D568D8FC18; Tue, 17 Feb 2009 20:20:15 +0000 (UTC) (envelope-from keramida@freebsd.org) Received: from kobe.laptop (adsl126-61.kln.forthnet.gr [77.49.245.61]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-6) with ESMTP id n1HKK4gQ013125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Feb 2009 22:20:09 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n1HKK3kn002147; Tue, 17 Feb 2009 22:20:03 +0200 (EET) (envelope-from keramida@freebsd.org) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n1HKK3qD002146; Tue, 17 Feb 2009 22:20:03 +0200 (EET) (envelope-from keramida@freebsd.org) From: Giorgos Keramidas To: Hans Petter Selasky References: <87mycme9wc.fsf@kobe.laptop> <87tz6sdhb1.fsf@kobe.laptop> <87tz6sj2aw.fsf@kobe.laptop> <200902172040.06348.hselasky@freebsd.org> Date: Tue, 17 Feb 2009 22:20:03 +0200 In-Reply-To: <200902172040.06348.hselasky@freebsd.org> (Hans Petter Selasky's message of "Tue, 17 Feb 2009 20:40:05 +0100") Message-ID: <87k57oeryk.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Hellug-MailScanner-ID: n1HKK4gQ013125 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-4.483, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL -0.08, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@freebsd.org X-Spam-Status: No Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: usb2 moused issue (Microsoft Wireless Optical) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 20:20:16 -0000 On Tue, 17 Feb 2009 20:40:05 +0100, Hans Petter Selasky wrote: > On Tuesday 17 February 2009, Giorgos Keramidas wrote: >> On Tue, 17 Feb 2009 20:55:30 +0200, Giorgos Keramidas > wrote: >> > The code of hid_report_size() is similar in old usb and the new usb >> > stack, but I am not sure about all the differences I see. The >> > calculation of `size' is done correctly with old usb code, so I am >> > testing the patch attached below now. It essentially pulls in the >> > hid_report_size() from the old usb code, with the if (h.kind == k) check >> > reversed to remove one spurious indentation level: >> >> No luck with the old usb code for hid_report_size() either. We may be >> looking at the wrong place. I'll build a kernel with a pre-usb2 stack >> and see what ums debugging shows for this mouse. If it used to work >> with size=2 then we might have to look elsewhere for the bug. > > I don't think that will help. Can you try the following. > > XYZ information includes: (64+8-40)/8 = 4 bytes > > Then you need add one PD byte, so size should be 5 bytes. Yep. Before kldloading usb2_quirk.ko this is the X/Y/Z information: kernel: ums_attach:583: X 48/8 kernel: ums_attach:584: Y 56/8 kernel: ums_attach:585: Z 64/8 After kldloading the quirks, I now see: kernel: ugen4.2: at usbus4 kernel: ums0: on usbus4 kernel: ums0: 3 buttons and [XYZ] coordinates kernel: ums_attach:582: sc=0xc662f000 kernel: ums_attach:583: X 16/8 kernel: ums_attach:584: Y 24/8 kernel: ums_attach:585: Z 32/8 kernel: ums_attach:586: T 0/0 kernel: ums_attach:587: W 0/0 kernel: ums_attach:591: B1 8/1 kernel: ums_attach:591: B2 9/1 kernel: ums_attach:591: B3 10/1 kernel: ums_attach:593: size=5, id=0 kernel: Symlink: ums0 -> usb4.2.0.16 and AFAICT the mouse seems to work now. Thanks! :) From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 20:23:53 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6116510656F6; Tue, 17 Feb 2009 20:23:53 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout020.mac.com (asmtpout020.mac.com [17.148.16.95]) by mx1.freebsd.org (Postfix) with ESMTP id 126998FC2C; Tue, 17 Feb 2009 20:23:52 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from iphone-5.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp020.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KF800FVZ8N3IV20@asmtp020.mac.com>; Tue, 17 Feb 2009 12:23:28 -0800 (PST) Message-id: From: Marcel Moolenaar To: Poul-Henning Kamp In-reply-to: <15566.1234900800@critter.freebsd.dk> Date: Tue, 17 Feb 2009 12:23:26 -0800 References: <15566.1234900800@critter.freebsd.dk> X-Mailer: Apple Mail (2.930.3) Cc: "Bjoern A. Zeeb" , Marcel Moolenaar , FreeBSD current mailing list Subject: Re: boot0cfg -s vs. GEOM_PART_*? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 20:23:54 -0000 On Feb 17, 2009, at 12:00 PM, Poul-Henning Kamp wrote: > In message , Marcel > Moolenaar wri > tes: > >> 1. We need to expose the current bootcode through >> kern.geom.confxml > > No. > > No. > > NO. > > We do not want arbitrary large binary blobs in the confxml > output. I'm not going to start a discussion on arbitrariness and largeness of bootcode. Instead, let me just ask: Do you have alternatives? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 20:27:36 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D24C31065670; Tue, 17 Feb 2009 20:27:36 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 954E38FC20; Tue, 17 Feb 2009 20:27:36 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 9C5E53F129; Tue, 17 Feb 2009 20:27:35 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n1HKRdKZ015769; Tue, 17 Feb 2009 20:27:39 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 17 Feb 2009 12:23:26 PST." Date: Tue, 17 Feb 2009 20:27:39 +0000 Message-ID: <15768.1234902459@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: "Bjoern A. Zeeb" , Marcel Moolenaar , FreeBSD current mailing list Subject: Re: boot0cfg -s vs. GEOM_PART_*? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 20:27:37 -0000 In message , Marcel Moolenaar wri tes: >> We do not want arbitrary large binary blobs in the confxml >> output. > >I'm not going to start a discussion on arbitrariness >and largeness of bootcode. Instead, let me just ask: > >Do you have alternatives? Open the parent device, use read(2) to get it. You can always open an geom device for reading (subject to filesystem permissions). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 20:46:29 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 447CC106564A; Tue, 17 Feb 2009 20:46:29 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id E83FF8FC1E; Tue, 17 Feb 2009 20:46:28 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.local ([192.168.254.200]) (authenticated bits=0) by pooker.samsco.org (8.14.2/8.14.2) with ESMTP id n1HKkKkV097118; Tue, 17 Feb 2009 13:46:20 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <499B221C.2050804@samsco.org> Date: Tue, 17 Feb 2009 13:46:20 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 MIME-Version: 1.0 To: Bruce Evans References: <499981AF.9030204@samsco.org> <20090217164203.4c586f48@ernst.jennejohn.org> <20090218073542.E5200@delplex.bde.org> In-Reply-To: <20090218073542.E5200@delplex.bde.org> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.4 required=3.8 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: FreeBSD@FreeBSD.org, FreeBSD Current , Stable , scsi@FreeBSD.org Subject: Re: HEADS UP: More CAM fixes. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 20:46:30 -0000 Bruce Evans wrote: > On Tue, 17 Feb 2009, Gary Jennejohn wrote: > >> I tested this with an Adaptec 29160. I saw no real improvement in >> performance, but also no regressions. >> >> I suspect that the old disk I had attached just didn't have enough >> performance reserves to show an improvement. >> >> My test scenario was buildworld. Since /usr/src and /usr/obj were both >> on the one disk it got a pretty good workout. > ^^^^ low >> >> AMD64 X2 (2.5 GHz) with 4GB of RAM. > > Buildworld hardly uses the disk at all. It reads and writes a few hundred > MB. Ideally the i/o should go at disk speeds of 50-200MB/S and thus take > between 20 and 5 seconds. In practice, it will take a few more seconds. > physically but perhaps even less virtually due to parallelism. > > Bruce Yes, on modern machines, buildworld is bound almost completely by disk latency, and not at all by disk or controller bandwidth. Scott From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 21:01:48 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D289106566B for ; Tue, 17 Feb 2009 21:01:48 +0000 (UTC) (envelope-from prvs=julian=29260e750@elischer.org) Received: from smtp-outbound.ironport.com (smtp-outbound.ironport.com [63.251.108.112]) by mx1.freebsd.org (Postfix) with ESMTP id 5E4938FC18 for ; Tue, 17 Feb 2009 21:01:48 +0000 (UTC) (envelope-from prvs=julian=29260e750@elischer.org) Received: from unknown (HELO julian-mac.elischer.org) ([10.251.60.104]) by smtp-outbound.ironport.com with ESMTP; 17 Feb 2009 12:33:00 -0800 Message-ID: <499B1F0D.4080209@elischer.org> Date: Tue, 17 Feb 2009 12:33:17 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Maksim Yevmenkin References: <4999F7F9.4030204@elischer.org> <20090217110524.GC79178@hoeg.nl> <499A9C9D.3000403@protected-networks.net> <20090217115651.GE79178@hoeg.nl> <20090217175512.GG79178@hoeg.nl> <20090217182128.GH79178@hoeg.nl> <20090217192152.GI79178@hoeg.nl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ed Schouten , Michael Butler , current@freebsd.org Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 21:01:48 -0000 Maksim Yevmenkin wrote: > On Tue, Feb 17, 2009 at 11:21 AM, Ed Schouten wrote: >> * Maksim Yevmenkin wrote: >>> anyway, i guess conversion to nmdm(4) is in order then. at least this >>> way users will have to change /dev/tty to /dev/nmdm which is possibly >>> less pain than other alternatives. while we are at it, we also could >>> implement your approach, i.e. auto-allocate and print /dev/nmdm node >>> if requested. >> But nmdm(4) is not really meant to be used for stuff like that, not that > > why not? i think its exactly what it was meant for. I wrote nmdm to allow two vmware machines to talk to each other across a serial link. In those days when one ran vmware on FreeBSD it could only connect to a serial port. I later discovered it also allowed me to connect gdb to the vmware instance so I could run a vmware kernel under gdb. i.e. both vmware and gdb thought they were talking to a serial port. > >> I think pts(4) should even be abused for this. The reason why pts(4) is >> used, is because the application tries to mimic a serial port of some >> sort on which data arrives that is normally handled by some kind of >> pppd. pts(4) doesn't have a lot of overhead in this setup. > > not really. imagine a legacy application that wants to talk some sort > of serial protocol. now imagine that you want to replace your physical > serial cable with bluetooth link. all you really need is > > 1) run rfcomm_sppd in server mode and tell it to use /dev/nmdmA > > 2) run legacy application on /dev/nmdmB > > when wireless client connects to the rfcomm_sppd legacy application > will get input from /dev/nmdmB just as it would get it from /dev/cuau > or whatever. > > the whole purpose of those little wrappers is to provide legacy > application with something that looks like serial port. otherwise it > is required to change the legacy application and make it aware of > bluetooth etc. for example, you _could_ change ppp(8) and teach it > about bluetooth etc, but why do it? its so much simpler/cleaner to > write small wrapper that gives access to bluetooth link via something > ppp(8) already knows about, i.e. tty and/or stdin/stdout. > >> As you mentioned earlier, there is no need to use pts(4), because >> rfcomm_sppd also supports using stdout/stdin. This is a lot better, >> because our pipe implementation is probably a lot faster than pts(4). >> I'd rather see the handbook changed to not mention TTYs anywhere. > > its not all about speed. its about flexibility. > > thanks, > max > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 21:16:14 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4BFF81065676; Tue, 17 Feb 2009 21:16:14 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout018.mac.com (asmtpout018.mac.com [17.148.16.93]) by mx1.freebsd.org (Postfix) with ESMTP id 2C85F8FC17; Tue, 17 Feb 2009 21:16:14 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp018.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KF8007MZB2KQF30@asmtp018.mac.com>; Tue, 17 Feb 2009 13:16:01 -0800 (PST) Message-id: From: Marcel Moolenaar To: Poul-Henning Kamp In-reply-to: <15768.1234902459@critter.freebsd.dk> Date: Tue, 17 Feb 2009 13:15:55 -0800 References: <15768.1234902459@critter.freebsd.dk> X-Mailer: Apple Mail (2.930.3) Cc: "Bjoern A. Zeeb" , Marcel Moolenaar , FreeBSD current mailing list Subject: Re: boot0cfg -s vs. GEOM_PART_*? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 21:16:14 -0000 On Feb 17, 2009, at 12:27 PM, Poul-Henning Kamp wrote: > In message , Marcel > Moolenaar wri > tes: > >>> We do not want arbitrary large binary blobs in the confxml >>> output. >> >> I'm not going to start a discussion on arbitrariness >> and largeness of bootcode. Instead, let me just ask: >> >> Do you have alternatives? > > Open the parent device, use read(2) to get it. > > You can always open an geom device for reading (subject > to filesystem permissions). For boot0cfg this is probably acceptable, because it only operates on MBRs. But as a generic solution this won't work. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 21:19:55 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B35131065678 for ; Tue, 17 Feb 2009 21:19:55 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 766A98FC27 for ; Tue, 17 Feb 2009 21:19:55 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 0FC8E3F129; Tue, 17 Feb 2009 21:19:54 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n1HLJuDX016158; Tue, 17 Feb 2009 21:19:57 GMT (envelope-from phk@critter.freebsd.dk) To: Julian Elischer From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 17 Feb 2009 12:33:17 PST." <499B1F0D.4080209@elischer.org> Date: Tue, 17 Feb 2009 21:19:56 +0000 Message-ID: <16157.1234905596@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Ed Schouten , Michael Butler , current@freebsd.org, Maksim Yevmenkin Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 21:19:56 -0000 In message <499B1F0D.4080209@elischer.org>, Julian Elischer writes: >Maksim Yevmenkin wrote: >>> But nmdm(4) is not really meant to be used for stuff like that, not that >> >> why not? i think its exactly what it was meant for. > >I wrote nmdm to allow two vmware machines to talk to each other across >a serial link. And I added the speed emulation, because I was tasked to represent ed(1) in a "Editor Celebrity Death-Match" in the danish unix users group, and wanted to show my "slides" in ed(1) as well as prove that it was a usable editor across a 300 bps line. If I had bribed the convincingly female judges, as much as the rest of the "celebrities" who defended other editors, I might even have won :-) 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-current@FreeBSD.ORG Tue Feb 17 21:22:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66A1D106566B; Tue, 17 Feb 2009 21:22:54 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 3A01A8FC12; Tue, 17 Feb 2009 21:22:53 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1HLMpg1014230; Tue, 17 Feb 2009 16:22:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1HLMp4M098661; Tue, 17 Feb 2009 16:22:51 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A8EFB7302F; Tue, 17 Feb 2009 16:22:51 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090217212251.A8EFB7302F@freebsd-current.sentex.ca> Date: Tue, 17 Feb 2009 16:22:51 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 21:22:56 -0000 TB --- 2009-02-17 20:03:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-17 20:03:00 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-02-17 20:03:00 - cleaning the object tree TB --- 2009-02-17 20:03:32 - cvsupping the source tree TB --- 2009-02-17 20:03:32 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-02-17 20:03:40 - building world TB --- 2009-02-17 20:03:40 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-17 20:03:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-17 20:03:40 - TARGET=powerpc TB --- 2009-02-17 20:03:40 - TARGET_ARCH=powerpc TB --- 2009-02-17 20:03:40 - TZ=UTC TB --- 2009-02-17 20:03:40 - __MAKE_CONF=/dev/null TB --- 2009-02-17 20:03:40 - cd /src TB --- 2009-02-17 20:03:40 - /usr/bin/make -B buildworld >>> World build started on Tue Feb 17 20:03:41 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/ftp-proxy.c cc -O2 -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/filter.c cc -O2 -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o ftp-proxy ftp-proxy.o filter.o /obj/powerpc/src/usr.sbin/ftp-proxy/ftp-proxy/../libevent/libevent.a gzip -cn /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/ftp-proxy.8 > ftp-proxy.8.gz ===> usr.sbin/fwcontrol (all) cc -O2 -pipe -I/src/usr.sbin/fwcontrol -I/src/usr.sbin/fwcontrol/../../sys -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/fwcontrol/fwcontrol.c /src/usr.sbin/fwcontrol/fwcontrol.c: In function 'show_topology_map': /src/usr.sbin/fwcontrol/fwcontrol.c:546: error: 'struct ' has no member named 'phy_delay' *** Error code 1 Stop in /src/usr.sbin/fwcontrol. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-17 21:22:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-17 21:22:51 - ERROR: failed to build world TB --- 2009-02-17 21:22:51 - 3837.02 user 349.02 system 4791.08 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 21:37:30 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D3321065670; Tue, 17 Feb 2009 21:37:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 3F7168FC08; Tue, 17 Feb 2009 21:37:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 72BE93F129; Tue, 17 Feb 2009 21:37:29 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n1HLbX3k016289; Tue, 17 Feb 2009 21:37:33 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 17 Feb 2009 13:15:55 PST." Date: Tue, 17 Feb 2009 21:37:33 +0000 Message-ID: <16288.1234906653@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: "Bjoern A. Zeeb" , Marcel Moolenaar , FreeBSD current mailing list Subject: Re: boot0cfg -s vs. GEOM_PART_*? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 21:37:31 -0000 In message , Marcel Moolenaar wri tes: >For boot0cfg this is probably acceptable, because >it only operates on MBRs. But as a generic solution >this won't work. Then pick up the bootcode via ioctls, it does not belong in the confxml sysctl. 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-current@FreeBSD.ORG Tue Feb 17 22:05:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81C0910656BC for ; Tue, 17 Feb 2009 22:05:59 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id 0B1768FC18 for ; Tue, 17 Feb 2009 22:05:58 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 331CB19909A; Tue, 17 Feb 2009 23:05:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 26F11199094; Tue, 17 Feb 2009 23:05:58 +0100 (CET) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 03C84199093; Tue, 17 Feb 2009 23:05:58 +0100 (CET) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2HF443) with ESMTP id 2009021723055705-81008 ; Tue, 17 Feb 2009 23:05:57 +0100 Received: by wep4035 (sSMTP sendmail emulation); Tue, 17 Feb 2009 23:05:57 +0100 From: "Alexey Shuvaev" Date: Tue, 17 Feb 2009 23:05:57 +0100 To: Pyun YongHyeon Message-ID: <20090217220557.GA1745@wep4035.physik.uni-wuerzburg.de> References: <7d6fde3d0902150028n5f07ee55mc6026e1e4935eeb0@mail.gmail.com> <20090217011358.GC23900@michelle.cdnetworks.co.kr> MIME-Version: 1.0 In-Reply-To: <20090217011358.GC23900@michelle.cdnetworks.co.kr> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.18 (2008-05-17) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 02/17/2009 11:05:57 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 02/17/2009 11:05:58 PM, Serialize complete at 02/17/2009 11:05:58 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: Garrett Cooper , FreeBSD Current Subject: Re: Annoyance with recent parallelism in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 22:06:00 -0000 On Tue, Feb 17, 2009 at 10:13:58AM +0900, Pyun YongHyeon wrote: > Would you try attached patch? I don't like the patch but it may > reduce number of link state change message generated by dhclient. > Seems to be so. Not sure it solves the problem entirely: [snip] /dev/ad6p8: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ad6p8: clean, 5999509 free (41045 frags, 744808 blocks, 0.5% fragmentation) msk0: link state changed to DOWN Starting Network: lo0 msk0. Removing stale Samba tdb files: done Feb 17 21:49:22 ntpd[1295]: getaddrinfo: "wrzx03.rz.uni-wuerzburg.de" invalid h ost address, ignored Feb 17 21:49:22 ntpd[1295]: getaddrinfo: "wep4001.physik.uni-wuerzburg.de" inva lid host address, ignored Configuring syscons: blanktime screensaver. Configuring jails:. Starting jails:. moused: unable to open /dev/ums0: Device busy Tue Feb 17 21:49:23 CET 2009 FreeBSD/amd64 (wep4035) (ttyv0) login: After all I have ntpd running & connected to upstream ntp server. This is without synchronous_dhclient="YES" in rc.conf. I have some feeling that the problem is not localized to msk driver only, so... if you don't like the patch I'm ok to live with synchronous dhclient. Alexey. > Index: sys/dev/msk/if_msk.c > =================================================================== > --- sys/dev/msk/if_msk.c (revision 188700) > +++ sys/dev/msk/if_msk.c (working copy) > @@ -943,8 +943,11 @@ > else { > MSK_IF_LOCK(sc_if); > ifp->if_mtu = ifr->ifr_mtu; > - if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) > + if ((ifp->if_drv_flags & > + IFF_DRV_RUNNING) != 0) { > + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; > msk_init_locked(sc_if); > + } > MSK_IF_UNLOCK(sc_if); > } > } > @@ -2726,6 +2729,7 @@ > if_printf(sc_if->msk_ifp, "watchdog timeout " > "(missed link)\n"); > ifp->if_oerrors++; > + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; > msk_init_locked(sc_if); > return; > } > @@ -2750,6 +2754,7 @@ > > if_printf(ifp, "watchdog timeout\n"); > ifp->if_oerrors++; > + ifp->if_drv_flags &= ~IFF_DRV_RUNNING; > msk_init_locked(sc_if); > if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) > taskqueue_enqueue(taskqueue_fast, &sc_if->msk_tx_task); > @@ -2828,8 +2833,10 @@ > mskc_reset(sc); > for (i = 0; i < sc->msk_num_port; i++) { > if (sc->msk_if[i] != NULL && sc->msk_if[i]->msk_ifp != NULL && > - ((sc->msk_if[i]->msk_ifp->if_flags & IFF_UP) != 0)) > + ((sc->msk_if[i]->msk_ifp->if_flags & IFF_UP) != 0)) { > + sc->msk_if[i]->msk_ifp->if_drv_flags &= ~IFF_DRV_RUNNING; > msk_init_locked(sc->msk_if[i]); > + } > } > sc->msk_suspended = 0; > > @@ -3515,6 +3522,9 @@ > sc = sc_if->msk_softc; > mii = device_get_softc(sc_if->msk_miibus); > > + if ((ifp->if_drv_flags & IFF_DRV_RUNNING) != 0) > + return; > + > error = 0; > /* Cancel pending I/O and free all Rx/Tx buffers. */ > msk_stop(sc_if); From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 22:10:12 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90B2E1065697; Tue, 17 Feb 2009 22:10:12 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout017.mac.com (asmtpout017.mac.com [17.148.16.92]) by mx1.freebsd.org (Postfix) with ESMTP id 7AF028FC1B; Tue, 17 Feb 2009 22:10:12 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from MacBook-Pro.lan.xcllnt.net (xcllnt.net [75.101.29.67]) by asmtp017.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KF800M96DKZM540@asmtp017.mac.com>; Tue, 17 Feb 2009 14:10:12 -0800 (PST) Message-id: From: Marcel Moolenaar To: Poul-Henning Kamp In-reply-to: <16288.1234906653@critter.freebsd.dk> Date: Tue, 17 Feb 2009 14:10:10 -0800 References: <16288.1234906653@critter.freebsd.dk> X-Mailer: Apple Mail (2.930.3) Cc: "Bjoern A. Zeeb" , Marcel Moolenaar , FreeBSD current mailing list Subject: Re: boot0cfg -s vs. GEOM_PART_*? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 22:10:13 -0000 On Feb 17, 2009, at 1:37 PM, Poul-Henning Kamp wrote: > In message , Marcel > Moolenaar wri > tes: > >> For boot0cfg this is probably acceptable, because >> it only operates on MBRs. But as a generic solution >> this won't work. > > Then pick up the bootcode via ioctls, it does not belong > in the confxml sysctl. On what grounds doesn't it belong in the confxml? And how do these not apply to ioctls? -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 22:34:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37ED010656BA for ; Tue, 17 Feb 2009 22:34:13 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id ECFB08FC21 for ; Tue, 17 Feb 2009 22:34:12 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1HM5OgQ025073; Tue, 17 Feb 2009 17:05:24 -0500 (EST) (envelope-from mike@sentex.net) Received: from pyroxene.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1HM5Lj3027518; Tue, 17 Feb 2009 17:05:21 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by pyroxene.sentex.ca (8.14.3/8.13.8) with ESMTP id n1HM5IUf022092; Tue, 17 Feb 2009 17:05:20 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200902172205.n1HM5IUf022092@pyroxene.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 17 Feb 2009 17:05:12 -0500 To: Luigi Rizzo , Scott Long From: Mike Tancsa In-Reply-To: <20090217075742.GA69308@onelab2.iet.unipi.it> References: <499551B9.7050805@samsco.org> <4995DFE5.1020205@samsco.org> <9bbcef730902131421r53efa13dq371658888747f387@mail.gmail.com> <4996D635.3000802@samsco.org> <20090217075742.GA69308@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: HEADS UP: Major CAM performance regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 22:34:13 -0000 At 02:57 AM 2/17/2009, Luigi Rizzo wrote: >On Sat, Feb 14, 2009 at 07:33:25AM -0700, Scott Long wrote: >... > > >I'll try your suggestion if you have one. > > > > I don't have a magic universal testing suite in my back pocket, sorry. > > You need to look at your expected workload and develop tests to simulate > > it. When I do testing during driver development, I try a lot of > > different parallel, sequential, large i/o, and small i/o combinations. > >i just committed a port sysutils/fio that perhaps can help testing >IO performance with various patterns. Hi, Do you have any suggestions as to what tests to run with fio ? Am I right in assuming that the Areca is hit by this bug ? 0[releng7]# camcontrol tags da0 (pass0:arcmsr0:0:0:0): device openings: 1 0[releng7]# ---Mike From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 22:35:23 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 29E361065678; Tue, 17 Feb 2009 22:35:23 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id E08E48FC27; Tue, 17 Feb 2009 22:35:22 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id A071A3F130; Tue, 17 Feb 2009 22:35:21 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n1HMZO9C016679; Tue, 17 Feb 2009 22:35:24 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 17 Feb 2009 14:10:10 PST." Date: Tue, 17 Feb 2009 22:35:24 +0000 Message-ID: <16678.1234910124@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: "Bjoern A. Zeeb" , Marcel Moolenaar , FreeBSD current mailing list Subject: Re: boot0cfg -s vs. GEOM_PART_*? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 22:35:23 -0000 In message , Marcel Moolenaar wri tes: >> In message , Marcel >> Moolenaar wri >> tes: >> >>> For boot0cfg this is probably acceptable, because >>> it only operates on MBRs. But as a generic solution >>> this won't work. >> >> Then pick up the bootcode via ioctls, it does not belong >> in the confxml sysctl. > >On what grounds doesn't it belong in the confxml? Because the way we (currently) implement confxml and the uses it is put to would generally be greatly inconvenienced if you have to include 8KB of hexdump data in the xml stream. >And how do these not apply to ioctls? ioctls was designed and built to move binary blobs across the userland/kernel barrier to and from I/O devices. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 22:39:21 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DA6B1065688; Tue, 17 Feb 2009 22:39:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 53D9F8FC25; Tue, 17 Feb 2009 22:39:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1HMdGmu033169; Tue, 17 Feb 2009 17:39:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1HMdGbN049564; Tue, 17 Feb 2009 17:39:16 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B73EA7302F; Tue, 17 Feb 2009 17:39:16 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090217223916.B73EA7302F@freebsd-current.sentex.ca> Date: Tue, 17 Feb 2009 17:39:16 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 22:39:22 -0000 TB --- 2009-02-17 21:23:15 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-17 21:23:15 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-02-17 21:23:15 - cleaning the object tree TB --- 2009-02-17 21:23:49 - cvsupping the source tree TB --- 2009-02-17 21:23:49 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-02-17 21:23:58 - building world TB --- 2009-02-17 21:23:58 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-17 21:23:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-17 21:23:58 - TARGET=sun4v TB --- 2009-02-17 21:23:58 - TARGET_ARCH=sparc64 TB --- 2009-02-17 21:23:58 - TZ=UTC TB --- 2009-02-17 21:23:58 - __MAKE_CONF=/dev/null TB --- 2009-02-17 21:23:58 - cd /src TB --- 2009-02-17 21:23:58 - /usr/bin/make -B buildworld >>> World build started on Tue Feb 17 21:23:59 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/ftp-proxy.c cc -O2 -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/filter.c cc -O2 -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o ftp-proxy ftp-proxy.o filter.o /obj/sun4v/src/usr.sbin/ftp-proxy/ftp-proxy/../libevent/libevent.a gzip -cn /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/ftp-proxy.8 > ftp-proxy.8.gz ===> usr.sbin/fwcontrol (all) cc -O2 -pipe -I/src/usr.sbin/fwcontrol -I/src/usr.sbin/fwcontrol/../../sys -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/fwcontrol/fwcontrol.c /src/usr.sbin/fwcontrol/fwcontrol.c: In function 'show_topology_map': /src/usr.sbin/fwcontrol/fwcontrol.c:546: error: 'struct ' has no member named 'phy_delay' *** Error code 1 Stop in /src/usr.sbin/fwcontrol. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-17 22:39:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-17 22:39:16 - ERROR: failed to build world TB --- 2009-02-17 22:39:16 - 3599.45 user 353.77 system 4561.21 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 22:39:33 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8F3C10656FA; Tue, 17 Feb 2009 22:39:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 813D88FC1A; Tue, 17 Feb 2009 22:39:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1HMdR8D040165; Tue, 17 Feb 2009 17:39:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1HMdQSk094673; Tue, 17 Feb 2009 17:39:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DFD9E73031; Tue, 17 Feb 2009 17:39:26 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090217223926.DFD9E73031@freebsd-current.sentex.ca> Date: Tue, 17 Feb 2009 17:39:26 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 22:39:35 -0000 TB --- 2009-02-17 21:22:51 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-17 21:22:51 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2009-02-17 21:22:51 - cleaning the object tree TB --- 2009-02-17 21:23:24 - cvsupping the source tree TB --- 2009-02-17 21:23:24 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2009-02-17 21:23:33 - building world TB --- 2009-02-17 21:23:33 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-17 21:23:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-17 21:23:33 - TARGET=sparc64 TB --- 2009-02-17 21:23:33 - TARGET_ARCH=sparc64 TB --- 2009-02-17 21:23:33 - TZ=UTC TB --- 2009-02-17 21:23:33 - __MAKE_CONF=/dev/null TB --- 2009-02-17 21:23:33 - cd /src TB --- 2009-02-17 21:23:33 - /usr/bin/make -B buildworld >>> World build started on Tue Feb 17 21:23:35 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/ftp-proxy.c cc -O2 -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/filter.c cc -O2 -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o ftp-proxy ftp-proxy.o filter.o /obj/sparc64/src/usr.sbin/ftp-proxy/ftp-proxy/../libevent/libevent.a gzip -cn /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/ftp-proxy.8 > ftp-proxy.8.gz ===> usr.sbin/fwcontrol (all) cc -O2 -pipe -I/src/usr.sbin/fwcontrol -I/src/usr.sbin/fwcontrol/../../sys -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/fwcontrol/fwcontrol.c /src/usr.sbin/fwcontrol/fwcontrol.c: In function 'show_topology_map': /src/usr.sbin/fwcontrol/fwcontrol.c:546: error: 'struct ' has no member named 'phy_delay' *** Error code 1 Stop in /src/usr.sbin/fwcontrol. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-17 22:39:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-17 22:39:26 - ERROR: failed to build world TB --- 2009-02-17 22:39:26 - 3599.99 user 353.70 system 4595.11 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 22:50:23 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD1F310656DA; Tue, 17 Feb 2009 22:50:23 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 677F98FC14; Tue, 17 Feb 2009 22:50:23 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n1HMoMtt018218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 17:50:22 -0500 (EST) X-DKIM: Sendmail DKIM Filter v2.5.3 duke.cs.duke.edu n1HMoMtt018218 Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id n1HJQFAx077974; Tue, 17 Feb 2009 14:26:15 -0500 (EST) (envelope-from gallatin) Date: Tue, 17 Feb 2009 14:26:15 -0500 From: Andrew Gallatin To: current@freebsd.org Message-ID: <20090217142615.A77950@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i X-Operating-System: FreeBSD 4.9-RELEASE-p1 on an i386 Cc: Subject: r187880 causes fatal trap 30 when unloading drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 22:50:47 -0000 I'm seeing a panic when I unload if_mxge. I suspect it was caused by the recent change to allocate apic vectors on a per-CPU basis. I see the panic only when running an SMP kernel, and only on our 8-way opterons (a dual-core athlon64 is fine). This is on a box with 2 NICs. Every time I unload my driver, 2 CPUs panic at the same time slightly after unloading the driver. It occurs both when I use a single MSI, or legacy interrupts. Untangling the garbled jibberish, I see this on console: Fatal trap 30: reserved (unknown) fault while in kernel mode cpuid = 2; apic id = 02 instruction pointer = 0x8:0xffffffff807ded46 stack pointer = 0x10:0xfffffffe40063b70 frame pointer = 0x10:0xfffffffe40063b80 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 11 (idle: cpu2) trap number = 30 Fatal trap 30: reserved (unknown) fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x8:0xffffffff807ded46 stack pointer = 0x10:0xfffffffe40068b70 frame pointer = 0x10:0xfffffffe40068b80 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 11 (idle: cpu1) trap number = 30 I cannot get a dump, and ddb shows that it is sitting in the acpi acpi_cpu_c1() function. I saw a similar report a little while back (http://lists.freebsd.org/pipermail/freebsd-current/2009-February/003141.html). Following John's suggestion later in the thread, I tried backing out r187880, and I can again unload drivers. FWIW, I'm fairly certain the unhandled IRQ is not coming from the NIC. The NIC will not generate interrupts when it is not ifconfig'ed up. Given that, and how I usually see kldunload finish before the panic happens, I wonder if it might be a clock interrupt that is triggering the trap. Drew From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 22:50:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BC1610656D2 for ; Tue, 17 Feb 2009 22:50:23 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id F300D8FC1B for ; Tue, 17 Feb 2009 22:50:22 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n1HMoMtr018218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 17 Feb 2009 17:50:22 -0500 (EST) X-DKIM: Sendmail DKIM Filter v2.5.3 duke.cs.duke.edu n1HMoMtr018218 Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id n1HLJLm7078123; Tue, 17 Feb 2009 16:19:21 -0500 (EST) (envelope-from gallatin) Date: Tue, 17 Feb 2009 16:19:21 -0500 From: Andrew Gallatin To: Mike Makonnen Message-ID: <20090217161921.A78099@grasshopper.cs.duke.edu> References: <7d6fde3d0902150028n5f07ee55mc6026e1e4935eeb0@mail.gmail.com> <20090215153531.GA36438@wep4035.physik.uni-wuerzburg.de> <49998707.40205@gmail.com> <20090216210118.GA85984@wep4035.physik.uni-wuerzburg.de> <499A55AB.9080606@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <499A55AB.9080606@gmail.com>; from mmakonnen@gmail.com on Tue, Feb 17, 2009 at 09:13:40AM +0300 X-Operating-System: FreeBSD 4.9-RELEASE-p1 on an i386 Cc: Alexey Shuvaev , Garrett Cooper , FreeBSD Current Subject: Re: Annoyance with recent parallelism in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 22:50:47 -0000 Mike Makonnen [mmakonnen@gmail.com] wrote: > Alexey Shuvaev wrote: > > Rev. 1.4 of rc.d/defaultroute. > > Ok, what should I do to have network daemons happy on startup? > > I am on a LAN so always have plugged-in cable. > > I do see on the console: > > msk0: link state changed to DOWN > > msk0: link state changed to UP > > got link > > msk0: link state changed to DOWN > > Starting Network: lo0 msk0. > > msk0: link state changed to UP > > msk0: link state changed to DOWN > > > > AFAIK some NIC (or PHY-s?) require some sort of reset to handle some > > events. > > Should I live with synchronous_dhclient="YES" or something else? > > This seems to be an issue with the driver for the network card. No > special handling needs to take place in rc.d. So, yes, > synchronous_dhclient=yes should be the appropriate work-around. Maybe synchronous_dhclient=yes should be the default, as there are a lot of cases of it not working async? I had horribly annoying problems with NFS failing (via amd using NIS based maps) at boot on different machines 90% of the time. Some use bge, and others use nfe. At least in my case, there was no "reset". Eg: /dev/da0s2g: clean, 1992874 free (138 frags, 249092 blocks, 0.0% fragmentation) bge0: link state changed to DOWN Starting Network: lo0 bge0. bge1: link state changed to DOWN Setting date via ntp. 13 Feb 13:41:48 ntpdate[638]: no servers can be used, exiting Setting NIS domain: sw.myri.com. Starting rpcbind. /etc/rc: WARNING: failed to start amd Recovering vi editor sessions:. Setting synchronous_dhclient=yes seems to have fixed it for me. Drew From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 22:50:47 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6C0A10656FC; Tue, 17 Feb 2009 22:50:40 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 8A38D8FC12; Tue, 17 Feb 2009 22:50:40 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [172.31.193.10] (cpe-075-177-134-250.nc.res.rr.com [75.177.134.250]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n1HG87NQ028939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 11:08:24 -0500 (EST) X-DKIM: Sendmail DKIM Filter v2.5.3 duke.cs.duke.edu n1HG87NQ028939 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1234886904; bh=y/dB/EPnT/coDvFzNl4pjqlSU51tV6t+kicvVPbW1W0=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=HrZkf6FBbJNW y1oNT0LQTcLacXqOaF+C2bxc30g8m27nP/4RYadzu3YRlF+O/1HCY3dXNY1mMhRXRlY af5/EZ9zpEv7xl2YlHVAXPtTg4G8QqGlF2cOajl/OGGp8eVdCjNPhNlMwmBMKN0PVcE O1F5Q72TQFHAkq795IdMlKjc8= Message-ID: <499AE0E1.8030000@cs.duke.edu> Date: Tue, 17 Feb 2009 11:08:01 -0500 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: Chagin Dmitry References: <4995A792.5050003@cs.duke.edu> <20090215151114.GA2422@dchagin.static.corbina.ru> In-Reply-To: <20090215151114.GA2422@dchagin.static.corbina.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Dtrace panic'ed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 22:51:07 -0000 Chagin Dmitry wrote: > hi, I have the same problem and found the hack "solution": > > dchagin# sysctl machdep.idle=hlt > machdep.idle: acpi -> hlt Unfortunately, that did not help on this machine.. Drew From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 23:07:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7989A106564A; Tue, 17 Feb 2009 23:07:07 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 3B7C78FC12; Tue, 17 Feb 2009 23:07:07 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1HN75Mr043065; Tue, 17 Feb 2009 18:07:05 -0500 (EST) (envelope-from mike@sentex.net) Received: from pyroxene.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1HN74j6064947; Tue, 17 Feb 2009 18:07:04 -0500 (EST) (envelope-from mike@sentex.net) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by pyroxene.sentex.ca (8.14.3/8.13.8) with ESMTP id n1HN74ml025580; Tue, 17 Feb 2009 18:07:04 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <200902172307.n1HN74ml025580@pyroxene.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 17 Feb 2009 18:06:57 -0500 To: Scott Long , FreeBSD Current , FreeBSD Stable From: Mike Tancsa In-Reply-To: <499551B9.7050805@samsco.org> References: <499551B9.7050805@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: Re: HEADS UP: Major CAM performance regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 23:07:07 -0000 At 05:55 AM 2/13/2009, Scott Long wrote: >If, instead, it reports a value of '1', you are likely affected. Note >that it may be normal for USB memory devices to report a low number. >Also, many legacy SCSI disks, and devices that are not disks, may >also be expected to report a low number. Hi Scott, I tested with the patch on my areca controller, and it still reports 1 post patch. (On RELENG_6, it shows 255 with the same controller) ---Mike From owner-freebsd-current@FreeBSD.ORG Tue Feb 17 23:43:29 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEC841065783; Tue, 17 Feb 2009 23:43:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8367A8FC19; Tue, 17 Feb 2009 23:43:29 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1HNhRJC046270; Tue, 17 Feb 2009 18:43:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1HNhRhL039733; Tue, 17 Feb 2009 18:43:27 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D8C007302F; Tue, 17 Feb 2009 18:43:26 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090217234326.D8C007302F@freebsd-current.sentex.ca> Date: Tue, 17 Feb 2009 18:43:26 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on arm/arm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Feb 2009 23:43:30 -0000 TB --- 2009-02-17 22:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-17 22:40:00 - starting HEAD tinderbox run for arm/arm TB --- 2009-02-17 22:40:00 - cleaning the object tree TB --- 2009-02-17 22:40:27 - cvsupping the source tree TB --- 2009-02-17 22:40:27 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/arm/arm/supfile TB --- 2009-02-17 22:40:36 - building world TB --- 2009-02-17 22:40:36 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-17 22:40:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-17 22:40:36 - TARGET=arm TB --- 2009-02-17 22:40:36 - TARGET_ARCH=arm TB --- 2009-02-17 22:40:36 - TZ=UTC TB --- 2009-02-17 22:40:36 - __MAKE_CONF=/dev/null TB --- 2009-02-17 22:40:36 - cd /src TB --- 2009-02-17 22:40:36 - /usr/bin/make -B buildworld >>> World build started on Tue Feb 17 22:40:38 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/ftp-proxy.c cc -O -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/filter.c cc -O -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o ftp-proxy ftp-proxy.o filter.o /obj/arm/src/usr.sbin/ftp-proxy/ftp-proxy/../libevent/libevent.a gzip -cn /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/ftp-proxy.8 > ftp-proxy.8.gz ===> usr.sbin/fwcontrol (all) cc -O -pipe -I/src/usr.sbin/fwcontrol -I/src/usr.sbin/fwcontrol/../../sys -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/fwcontrol/fwcontrol.c /src/usr.sbin/fwcontrol/fwcontrol.c: In function 'show_topology_map': /src/usr.sbin/fwcontrol/fwcontrol.c:546: error: 'struct ' has no member named 'phy_delay' *** Error code 1 Stop in /src/usr.sbin/fwcontrol. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-17 23:43:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-17 23:43:26 - ERROR: failed to build world TB --- 2009-02-17 23:43:26 - 2959.34 user 356.17 system 3806.18 real http://tinderbox.des.no/tinderbox-head-HEAD-arm-arm.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 00:00:48 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C9199106566C; Wed, 18 Feb 2009 00:00:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 9DAE08FC13; Wed, 18 Feb 2009 00:00:48 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1I00jWW047487; Tue, 17 Feb 2009 19:00:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1I00jRS073180; Tue, 17 Feb 2009 19:00:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 890FF7302F; Tue, 17 Feb 2009 19:00:45 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090218000045.890FF7302F@freebsd-current.sentex.ca> Date: Tue, 17 Feb 2009 19:00:45 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 00:00:50 -0000 TB --- 2009-02-17 22:40:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-17 22:40:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2009-02-17 22:40:00 - cleaning the object tree TB --- 2009-02-17 22:40:50 - cvsupping the source tree TB --- 2009-02-17 22:40:50 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/amd64/amd64/supfile TB --- 2009-02-17 22:40:58 - building world TB --- 2009-02-17 22:40:58 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-17 22:40:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-17 22:40:58 - TARGET=amd64 TB --- 2009-02-17 22:40:58 - TARGET_ARCH=amd64 TB --- 2009-02-17 22:40:58 - TZ=UTC TB --- 2009-02-17 22:40:58 - __MAKE_CONF=/dev/null TB --- 2009-02-17 22:40:58 - cd /src TB --- 2009-02-17 22:40:58 - /usr/bin/make -B buildworld >>> World build started on Tue Feb 17 22:41:00 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/ftp-proxy.c cc -O2 -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/filter.c cc -O2 -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o ftp-proxy ftp-proxy.o filter.o /obj/amd64/src/usr.sbin/ftp-proxy/ftp-proxy/../libevent/libevent.a gzip -cn /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/ftp-proxy.8 > ftp-proxy.8.gz ===> usr.sbin/fwcontrol (all) cc -O2 -pipe -I/src/usr.sbin/fwcontrol -I/src/usr.sbin/fwcontrol/../../sys -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/fwcontrol/fwcontrol.c /src/usr.sbin/fwcontrol/fwcontrol.c: In function 'show_topology_map': /src/usr.sbin/fwcontrol/fwcontrol.c:546: error: 'struct ' has no member named 'phy_delay' *** Error code 1 Stop in /src/usr.sbin/fwcontrol. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-18 00:00:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-18 00:00:45 - ERROR: failed to build world TB --- 2009-02-18 00:00:45 - 3769.54 user 377.65 system 4845.09 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 00:04:57 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45F53106564A; Wed, 18 Feb 2009 00:04:57 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx10.syd.optusnet.com.au (fallbackmx10.syd.optusnet.com.au [211.29.132.251]) by mx1.freebsd.org (Postfix) with ESMTP id 2A1868FC13; Wed, 18 Feb 2009 00:04:55 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by fallbackmx10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n1HKh69f016671; Wed, 18 Feb 2009 07:43:06 +1100 Received: from c122-107-120-227.carlnfd1.nsw.optusnet.com.au (c122-107-120-227.carlnfd1.nsw.optusnet.com.au [122.107.120.227]) by mail09.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id n1HKgrda024968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 07:43:03 +1100 Date: Wed, 18 Feb 2009 07:42:53 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Gary Jennejohn In-Reply-To: <20090217164203.4c586f48@ernst.jennejohn.org> Message-ID: <20090218073542.E5200@delplex.bde.org> References: <499981AF.9030204@samsco.org> <20090217164203.4c586f48@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 18 Feb 2009 00:14:06 +0000 Cc: FreeBSD@FreeBSD.org, FreeBSD Current , Stable , scsi@FreeBSD.org Subject: Re: HEADS UP: More CAM fixes. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 00:04:57 -0000 On Tue, 17 Feb 2009, Gary Jennejohn wrote: > I tested this with an Adaptec 29160. I saw no real improvement in > performance, but also no regressions. > > I suspect that the old disk I had attached just didn't have enough > performance reserves to show an improvement. > > My test scenario was buildworld. Since /usr/src and /usr/obj were both > on the one disk it got a pretty good workout. ^^^^ low > > AMD64 X2 (2.5 GHz) with 4GB of RAM. Buildworld hardly uses the disk at all. It reads and writes a few hundred MB. Ideally the i/o should go at disk speeds of 50-200MB/S and thus take between 20 and 5 seconds. In practice, it will take a few more seconds. physically but perhaps even less virtually due to parallelism. Bruce From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 00:19:57 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D45421065673 for ; Wed, 18 Feb 2009 00:19:57 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by mx1.freebsd.org (Postfix) with ESMTP id BFD248FC1D for ; Wed, 18 Feb 2009 00:19:57 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from [172.24.240.93] (natint3.juniper.net [66.129.224.36]) by asmtp019.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KF800E68JL7QB60@asmtp019.mac.com> for current@FreeBSD.org; Tue, 17 Feb 2009 16:19:57 -0800 (PST) Message-id: From: Marcel Moolenaar To: Poul-Henning Kamp In-reply-to: <16678.1234910124@critter.freebsd.dk> Date: Tue, 17 Feb 2009 16:19:55 -0800 References: <16678.1234910124@critter.freebsd.dk> X-Mailer: Apple Mail (2.930.3) Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: boot0cfg -s vs. GEOM_PART_*? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 00:19:58 -0000 On Feb 17, 2009, at 2:35 PM, Poul-Henning Kamp wrote: > In message , Marcel > Moolenaar wri > tes: > >>> In message , Marcel >>> Moolenaar wri >>> tes: >>> >>>> For boot0cfg this is probably acceptable, because >>>> it only operates on MBRs. But as a generic solution >>>> this won't work. >>> >>> Then pick up the bootcode via ioctls, it does not belong >>> in the confxml sysctl. >> >> On what grounds doesn't it belong in the confxml? > > Because the way we (currently) implement confxml and the uses it is > put to would generally be greatly inconvenienced if you have to > include > 8KB of hexdump data in the xml stream. > >> And how do these not apply to ioctls? > > ioctls was designed and built to move binary blobs across the > userland/kernel barrier to and from I/O devices. I'll consider this. From my perspective: o The fact that we have a separate OAM interface that doesn't use file descriptors (at the application level), having to use ioctl(2) all of a sudden is... well... odd. Likewise for regular read/write. Just for boot code do we need o worry about mapping GEOM names to device special files. o XML is ideally suited for any and all kinds of data. Since all of the information related to GPART is obtained through the confxml, it seems inconsistent to not have the boot code obtained in that manner. To me it becomes a question of inconsistency vs inconvenience and inconsistency is always worse. o geom_getxml(3) allocates 1MB up-front for the XML. Either the XML is in that order of magnitude, in which case up to 10KB or so for boot code is insignificant, or 1MB is way too large and we have plenty of room for 10KB of boot code. Either way, it looks like it was envisioned that the XML can be large. How inconvenient can 10KB be, objectively, I wonder. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 01:01:10 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95ABB1065673; Wed, 18 Feb 2009 01:01:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 6BD528FC1C; Wed, 18 Feb 2009 01:01:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1I116h4048858; Tue, 17 Feb 2009 20:01:06 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1I116Lv020662; Tue, 17 Feb 2009 20:01:06 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 647B57302F; Tue, 17 Feb 2009 20:01:06 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090218010106.647B57302F@freebsd-current.sentex.ca> Date: Tue, 17 Feb 2009 20:01:06 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 01:01:11 -0000 TB --- 2009-02-17 23:43:26 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-17 23:43:26 - starting HEAD tinderbox run for i386/i386 TB --- 2009-02-17 23:43:26 - cleaning the object tree TB --- 2009-02-17 23:44:06 - cvsupping the source tree TB --- 2009-02-17 23:44:06 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/i386/supfile TB --- 2009-02-17 23:44:18 - building world TB --- 2009-02-17 23:44:18 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-17 23:44:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-17 23:44:18 - TARGET=i386 TB --- 2009-02-17 23:44:18 - TARGET_ARCH=i386 TB --- 2009-02-17 23:44:18 - TZ=UTC TB --- 2009-02-17 23:44:18 - __MAKE_CONF=/dev/null TB --- 2009-02-17 23:44:18 - cd /src TB --- 2009-02-17 23:44:18 - /usr/bin/make -B buildworld >>> World build started on Tue Feb 17 23:44:19 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/ftp-proxy.c cc -O2 -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/filter.c cc -O2 -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o ftp-proxy ftp-proxy.o filter.o /obj/src/usr.sbin/ftp-proxy/ftp-proxy/../libevent/libevent.a gzip -cn /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/ftp-proxy.8 > ftp-proxy.8.gz ===> usr.sbin/fwcontrol (all) cc -O2 -pipe -I/src/usr.sbin/fwcontrol -I/src/usr.sbin/fwcontrol/../../sys -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/fwcontrol/fwcontrol.c /src/usr.sbin/fwcontrol/fwcontrol.c: In function 'show_topology_map': /src/usr.sbin/fwcontrol/fwcontrol.c:546: error: 'struct ' has no member named 'phy_delay' *** Error code 1 Stop in /src/usr.sbin/fwcontrol. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-18 01:01:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-18 01:01:06 - ERROR: failed to build world TB --- 2009-02-18 01:01:06 - 3717.32 user 351.66 system 4659.27 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 01:03:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F057106564A; Wed, 18 Feb 2009 01:03:55 +0000 (UTC) (envelope-from prvs=1300dcceb8=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (core6.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 9E12A8FC19; Wed, 18 Feb 2009 01:03:54 +0000 (UTC) (envelope-from prvs=1300dcceb8=killing@multiplay.co.uk) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=multiplay.co.uk; s=Multiplay; t=1234917856; x=1235522656; q=dns/txt; h=Received: Message-ID:From:To:References:Subject:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; bh=m4Y5QBCkZRGVnhWwfge7D YynbdEftt4YBL4N6kwwZR8=; b=KHa0oeK0xLmiuNLTOjKMUPoawAqyVzPpb79JO ovag2Pc5Aq5tnaM1h5EP2O52Bmp4mvDPPkV7rcbg8FLDbyhKjxmEC5NyAXTvXqOy lB4kv/P7O5LitJi1g1aSHSpxk+6g9mq+WqZpA6XVOWjr9E1xpKz/cm3frGeiYZ5I jKhy18= X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-14.7 required=6.0 tests=BAYES_00, FORGED_MUA_OUTLOOK, USER_IN_WHITELIST,USER_IN_WHITELIST_TO autolearn=ham version=3.1.8 Received: from r2d2 by mail1.multiplay.co.uk (MDaemon PRO v9.6.6) with ESMTP id md50006992469.msg; Wed, 18 Feb 2009 00:44:12 +0000 X-Authenticated-Sender: Killing@multiplay.co.uk X-MDRemoteIP: 213.123.247.160 X-Return-Path: prvs=1300dcceb8=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <36F6FB422621418CA51378C8F3F49ADA@multiplay.co.uk> From: "Steven Hartland" To: "Scott Long" , "FreeBSD Current" , "FreeBSD Stable" , "Mike Tancsa" References: <499551B9.7050805@samsco.org> <200902172307.n1HN74ml025580@pyroxene.sentex.ca> Date: Wed, 18 Feb 2009 00:44:12 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5512 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 18 Feb 2009 00:44:14 +0000 X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 18 Feb 2009 00:44:16 +0000 Cc: Subject: Re: HEADS UP: Major CAM performance regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 01:03:55 -0000 This is also the case with 7.0-RELEASE on areca. We have a machine here which literally grinds to a half every time we run our rrd updates, so may be a good test case here if we can fix that ;-) Regards Steve ----- Original Message ----- From: "Mike Tancsa" To: "Scott Long" ; "FreeBSD Current" ; "FreeBSD Stable" Sent: Tuesday, February 17, 2009 11:06 PM Subject: Re: HEADS UP: Major CAM performance regression > At 05:55 AM 2/13/2009, Scott Long wrote: > >>If, instead, it reports a value of '1', you are likely affected. Note >>that it may be normal for USB memory devices to report a low number. >>Also, many legacy SCSI disks, and devices that are not disks, may also be expected to report a low number. > > Hi Scott, > I tested with the patch on my areca controller, and it still reports 1 post patch. (On RELENG_6, it shows 255 with the > same controller) > > ---Mike > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 01:17:58 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BA30C106564A; Wed, 18 Feb 2009 01:17:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 8FCC48FC12; Wed, 18 Feb 2009 01:17:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1I1HuvN052245; Tue, 17 Feb 2009 20:17:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1I1HuOi037760; Tue, 17 Feb 2009 20:17:56 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DF4A07302F; Tue, 17 Feb 2009 20:17:55 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090218011755.DF4A07302F@freebsd-current.sentex.ca> Date: Tue, 17 Feb 2009 20:17:55 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 01:17:59 -0000 TB --- 2009-02-18 00:00:45 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-18 00:00:45 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-02-18 00:00:45 - cleaning the object tree TB --- 2009-02-18 00:01:19 - cvsupping the source tree TB --- 2009-02-18 00:01:19 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-02-18 00:01:28 - building world TB --- 2009-02-18 00:01:28 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-18 00:01:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-18 00:01:28 - TARGET=pc98 TB --- 2009-02-18 00:01:28 - TARGET_ARCH=i386 TB --- 2009-02-18 00:01:28 - TZ=UTC TB --- 2009-02-18 00:01:28 - __MAKE_CONF=/dev/null TB --- 2009-02-18 00:01:28 - cd /src TB --- 2009-02-18 00:01:28 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 18 00:01:29 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/ftp-proxy.c cc -O2 -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/filter.c cc -O2 -pipe -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/libevent -I/src/usr.sbin/ftp-proxy/ftp-proxy/../../../sys/contrib/pf -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o ftp-proxy ftp-proxy.o filter.o /obj/pc98/src/usr.sbin/ftp-proxy/ftp-proxy/../libevent/libevent.a gzip -cn /src/usr.sbin/ftp-proxy/ftp-proxy/../../../contrib/pf/ftp-proxy/ftp-proxy.8 > ftp-proxy.8.gz ===> usr.sbin/fwcontrol (all) cc -O2 -pipe -I/src/usr.sbin/fwcontrol -I/src/usr.sbin/fwcontrol/../../sys -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/fwcontrol/fwcontrol.c /src/usr.sbin/fwcontrol/fwcontrol.c: In function 'show_topology_map': /src/usr.sbin/fwcontrol/fwcontrol.c:546: error: 'struct ' has no member named 'phy_delay' *** Error code 1 Stop in /src/usr.sbin/fwcontrol. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-18 01:17:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-18 01:17:55 - ERROR: failed to build world TB --- 2009-02-18 01:17:55 - 3678.49 user 365.05 system 4630.27 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 02:04:55 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E35E106566B for ; Wed, 18 Feb 2009 02:04:55 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id F07E18FC08 for ; Wed, 18 Feb 2009 02:04:54 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=rmac.psg.com) by ran.psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LZbny-0002bc-IW for freebsd-current@freebsd.org; Wed, 18 Feb 2009 02:04:54 +0000 Received: from rmac.psg.com.psg.com (localhost [127.0.0.1]) by rmac.psg.com (Postfix) with ESMTP id 13714737217 for ; Wed, 18 Feb 2009 11:04:54 +0900 (JST) Date: Wed, 18 Feb 2009 11:04:54 +0900 Message-ID: From: Randy Bush To: FreeBSD Current User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.7 Emacs/22.3 (i386-apple-darwin9.6.0) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: snapless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 02:04:55 -0000 [ i am trying to build some systems post the bleeping geom gmirror boot mess ] i find no 2009 snapshots in ftp://ftp.freebsd.org/pub/FreeBSD/snapshots so i break all the rules and read the README.TXT which tells me where to go (unnecessary, as i am married). but ftp://current.FreeBSD.org/pub/FreeBSD just gives me "The server at current.freebsd.org is taking too long to respond." clue bat, please. randy From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 02:27:51 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 385DF106568A for ; Wed, 18 Feb 2009 02:27:51 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id E8E258FC1B for ; Wed, 18 Feb 2009 02:27:50 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.3/8.14.3) with ESMTP id n1I2QZnH014868; Tue, 17 Feb 2009 20:26:35 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.3/8.14.3/Submit) id n1I2QZh2014867; Tue, 17 Feb 2009 20:26:35 -0600 (CST) (envelope-from brooks) Date: Tue, 17 Feb 2009 20:26:35 -0600 From: Brooks Davis To: Randy Bush Message-ID: <20090218022634.GA14835@lor.one-eyed-alien.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (lor.one-eyed-alien.net [127.0.0.1]); Tue, 17 Feb 2009 20:26:35 -0600 (CST) Cc: FreeBSD Current Subject: Re: snapless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 02:27:51 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 18, 2009 at 11:04:54AM +0900, Randy Bush wrote: > [ i am trying to build some systems post the bleeping geom gmirror boot > mess ] >=20 > i find no 2009 snapshots in ftp://ftp.freebsd.org/pub/FreeBSD/snapshots Releases were broken for a while due to the switch to geom_part breaking some assumptions. They have been fixed, but snapshots have not been generated yet. Presumably that will happen eventually. -- Brooks --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iD8DBQFJm3HaXY6L6fI4GtQRAn4wAKDLoy8fQyYoP9MdlXL5ldlOEKxJtwCdGARE 7XO7kVJLHB5tU4gR/XmORCs= =1rqN -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 02:33:31 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43E221065673; Wed, 18 Feb 2009 02:33:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 199478FC17; Wed, 18 Feb 2009 02:33:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1I2XSBS058210; Tue, 17 Feb 2009 21:33:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1I2XS4o060522; Tue, 17 Feb 2009 21:33:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 227617302F; Tue, 17 Feb 2009 21:33:27 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090218023328.227617302F@freebsd-current.sentex.ca> Date: Tue, 17 Feb 2009 21:33:27 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 02:33:31 -0000 TB --- 2009-02-18 01:17:56 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-18 01:17:56 - starting HEAD tinderbox run for mips/mips TB --- 2009-02-18 01:17:56 - mkdir /tinderbox/HEAD/mips TB --- 2009-02-18 01:17:56 - mkdir /tinderbox/HEAD/mips/mips TB --- 2009-02-18 01:17:56 - cleaning the object tree TB --- 2009-02-18 01:17:56 - cvsupping the source tree TB --- 2009-02-18 01:17:56 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-02-18 01:32:55 - building world TB --- 2009-02-18 01:32:55 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-18 01:32:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-18 01:32:55 - TARGET=mips TB --- 2009-02-18 01:32:55 - TARGET_ARCH=mips TB --- 2009-02-18 01:32:55 - TZ=UTC TB --- 2009-02-18 01:32:55 - __MAKE_CONF=/dev/null TB --- 2009-02-18 01:32:55 - cd /src TB --- 2009-02-18 01:32:55 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 18 01:32:56 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -fpic -DPIC -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -DNDEBUG -I/src/usr.sbin/bsnmpd/modules/snmp_hostres/../../../lpr/common_source -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c hostres_tree.c -o hostres_tree.So building shared library snmp_hostres.so.5 sed -e 's%@MODPATH@%/usr/lib/%g' -e 's%@DEFPATH@%/usr/share/snmp/defs/%g' -e 's%@MIBSPATH@%/usr/share/snmp/mibs/%g' < /src/usr.sbin/bsnmpd/modules/snmp_hostres/snmp_hostres.3 | gzip -cn > snmp_hostres.3.gz ===> usr.sbin/bsnmpd/modules/snmp_mibII (all) cc -fpic -DPIC -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/lib -I/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmpd -DHAVE_ERR_H -DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_SYS_TREE_H -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c -o mibII.So cc1: warnings being treated as errors /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c: In function 'handle_rtmsg': /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/bsnmpd/modules/snmp_mibII. *** Error code 1 Stop in /src/usr.sbin/bsnmpd/modules. *** Error code 1 Stop in /src/usr.sbin/bsnmpd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-18 02:33:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-18 02:33:27 - ERROR: failed to build world TB --- 2009-02-18 02:33:27 - 2896.77 user 337.68 system 4531.49 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 02:42:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6FEA4106566B for ; Wed, 18 Feb 2009 02:42:49 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwmtas06p.mx.bigpond.com (nschwmtas06p.mx.bigpond.com [61.9.189.152]) by mx1.freebsd.org (Postfix) with ESMTP id 04E188FC1B for ; Wed, 18 Feb 2009 02:42:48 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwotgx03p.mx.bigpond.com ([124.188.162.219]) by nschwmtas06p.mx.bigpond.com with ESMTP id <20090218024247.PVXI3101.nschwmtas06p.mx.bigpond.com@nschwotgx03p.mx.bigpond.com> for ; Wed, 18 Feb 2009 02:42:47 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nschwotgx03p.mx.bigpond.com with ESMTP id <20090218024243.FSDY7357.nschwotgx03p.mx.bigpond.com@areilly.bpa.nu> for ; Wed, 18 Feb 2009 02:42:43 +0000 Received: (qmail 93053 invoked by uid 501); 18 Feb 2009 02:42:07 -0000 Date: Wed, 18 Feb 2009 13:42:07 +1100 From: Andrew Reilly To: Andriy Gapon Message-ID: <20090218024207.GA87916@duncan.reilly.home> References: <4997F105.5020409@icyb.net.ua> <499811DF.6030905@incunabulum.net> <20090215151318.0d17bfb9@ernst.jennejohn.org> <499835BE.3000705@gmx.de> <8EF8771C-76D8-4556-96B2-B97B35573CBD@mac.com> <49986ABB.5040207@gmx.de> <20090216055602.GA70145@duncan.reilly.home> <49992A68.8010702@icyb.net.ua> <20090217015248.GC21644@duncan.reilly.home> <499A7FC6.40502@icyb.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <499A7FC6.40502@icyb.net.ua> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150201.499B75A4.011D,ss=1,fgs=0 Cc: Christoph Mallon , Marcel Moolenaar , Bruce Simpson , freebsd-current@freebsd.org Subject: Re: weeding out c++ keywords from sys/sys X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 02:42:49 -0000 On Tue, Feb 17, 2009 at 11:13:42AM +0200, Andriy Gapon wrote: > on 17/02/2009 03:52 Andrew Reilly said the following: > In general the following hold true: > 1. temporary objects always have automatic scope which means that they > are destroyed as soon as a scope where they were needed is left; > compiler generates that code; > 2. compiler would not allow to assign a pointer to a temporary object; > it only allows to initialize a const reference with a temporary object, > in which case the scope of the temporary is extended to be the same as > the scope of that reference variable. > 3. constructor of a temporary variable can, of course, allocate > something on the heap (e.g. some sort of a buffer); its destructor must > deallocate that memory; if it doesn't, then this just buggy code, > nothing to do with temporaries. OK, that seems pretty clear (if quite limited, compared to more dynamic languages). > >This issue is, I believe, undecidable at compile time, and > >goes by the name "escape detection". It is why *all* modern > >object-oriented languages require garbage collection. Some > >recent JIT runtime systems go to a great deal of effort to prove > >that references to some objects do not "escape" the block, and > >so can be stack-allocated and eagerly collected. That requires > >whole-program analysis, which is something that a JIT can fudge, > >but which a C++ compiler doing separate-compilation can't. > > No, no. C++ has stricter and simpler rules. It tries very hard to not > allow a programmer to let any pointers/references to temporary objects > escape. Of course, a sufficiently good programmer can still manage to > make it happen, but then it's a programmer's problem - the temporary > object would still not escape and be destroyed, the pointer/reference > would point to garbage. > It's like in C - you can return a pointer to a struct on stack, but that > wouldn't make that struct magically be transfered to heap and persist, > it would just make the returned pointer point to bad data. Thanks for that clear explanation. I hadn't noticed that the array of Strings was already allocated, so there wasn't any allocation going on of the temporary. I guess that the restriction for const references in these sorts of situations ensures that any callee that wants to maintain a pointer/reference to the source has to do a copy. > I hope I managed to explain at least something, not made too many > mistakes (I am not a big C++ expert recently) and not added to the > confusion :-) > > -- > Andriy Gapon Thanks very much (both you and Christoph) for the explanation. I think that I have a much better understanding of where C++ is coming from, now. It is, of course, not too different from the sorts of things that one does in C, just with more under-the-covers magic to help things along. I don't think that it's to my taste though, and the incredible complexity and ugly syntax will ensure that I continue to avoid it as much as I can. Maybe when the follow-up to C++0x adds garbage collection... Cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 03:21:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 293D61065670 for ; Wed, 18 Feb 2009 03:21:19 +0000 (UTC) (envelope-from hitormiz13@yahoo.com) Received: from web53111.mail.re2.yahoo.com (web53111.mail.re2.yahoo.com [206.190.49.61]) by mx1.freebsd.org (Postfix) with SMTP id DB30C8FC1D for ; Wed, 18 Feb 2009 03:21:18 +0000 (UTC) (envelope-from hitormiz13@yahoo.com) Received: (qmail 92615 invoked by uid 60001); 18 Feb 2009 02:54:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=klU8NL2D3fRsrAGpW2ioV+FefC9nSVLOLiNj0N5cWZQxrZakk7jaHMISPIDkOZSQ7Rk2SrY4VUMYkQYTwqeyozMggq3QCaBZjfSXgGQaioC5ijpxVbq4nyoBfvkpipTIH/WlIDbEZCjtC3ipGaLqNN2/qzP8amdD0uWgDHaClqo=; X-YMail-OSG: ui_WPMQVM1nVVqlo7tGLBiDFOvyISwSA_0MNYyu22asqwy3znaT6qxHLwSnKlZes9NxNlmhc_DxU7D.6wWtz9o0huJMnyEYCBRceeOVsc9uJYWGuCpznoPyULlUjmojdzgqDuv5_2EDew.HCtdgnrhP7t2_1UYd5T6.gRQktlrKFSOCtQUYnejnEbtahUg-- Received: from [58.71.34.137] by web53111.mail.re2.yahoo.com via HTTP; Tue, 17 Feb 2009 18:54:35 PST X-Mailer: YahooMailWebService/0.7.260.1 Date: Tue, 17 Feb 2009 18:54:35 -0800 (PST) From: ro ra To: freebsd-current@freebsd.org MIME-Version: 1.0 Message-ID: <453702.89046.qm@web53111.mail.re2.yahoo.com> Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: sam@freebsd.org Subject: Atheros Card not detected X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hitormiz13@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 03:21:19 -0000 Hela, Ive been trying to get my atheros card working for a week now on FreeBSD 7.1 Release, i have tried using ath_hal 9.20.3 and 10.5.6 to get my atheros card working..but still my atheros card is not detected by the atheros driver. i also tried using ndisgen and my atheros card was detected and was able to connect to the wifi ap, however, the connection is not stable. it keeps disconnecting..and it keeps displaying ndis0: no matching rate for: 600 ive tried updating to Freebsd current and recompiled my kernel, however my atheros card is still not detected. Here's the ouput of pciconf -vlc: none0@pci0:2:0:0: class=0x028000 card=0x10671a3b chip=0x002a168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' class = network cap 01[40] = powerspec 2 supports D0 D1 D3 current D0 cap 05[50] = MSI supports 1 message cap 10[60] = PCI-Express 1 legacy endpoint cap 11[90] = MSI-X supports 1 message in map 0x10 i really want to get my wifi card working...please help..^^ Cheers, drip From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 03:34:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D50E4106566B for ; Wed, 18 Feb 2009 03:34:07 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id AC2E38FC27 for ; Wed, 18 Feb 2009 03:34:07 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n1I3Y6RC080722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 Feb 2009 19:34:07 -0800 (PST) (envelope-from sam@freebsd.org) Message-ID: <499B81AE.3050108@freebsd.org> Date: Tue, 17 Feb 2009 19:34:06 -0800 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: hitormiz13@yahoo.com References: <453702.89046.qm@web53111.mail.re2.yahoo.com> In-Reply-To: <453702.89046.qm@web53111.mail.re2.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: freebsd-current@freebsd.org Subject: Re: Atheros Card not detected X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 03:34:08 -0000 ro ra wrote: > Hela, > > Ive been trying to get my atheros card working for a week now on FreeBSD 7.1 Release, i have tried using ath_hal 9.20.3 and 10.5.6 to get my atheros card working..but still my atheros card is not detected by the atheros driver. i also tried using ndisgen and my atheros card was detected and was able to connect to the wifi ap, however, the connection is not stable. it keeps disconnecting..and it keeps displaying > > ndis0: no matching rate for: 600 > ive tried updating to Freebsd current and recompiled my kernel, however my atheros card is still not detected. > > Here's the ouput of pciconf -vlc: > none0@pci0:2:0:0: class=0x028000 card=0x10671a3b chip=0x002a168c rev=0x01 hdr=0x00 > vendor = 'Atheros Communications Inc.' > class = network > cap 01[40] = powerspec 2 supports D0 D1 D3 current D0 > cap 05[50] = MSI supports 1 message > cap 10[60] = PCI-Express 1 legacy endpoint > cap 11[90] = MSI-X supports 1 message in map 0x10 > > i really want to get my wifi card working...please help..^^ > > This is a 9280 card. There is no support yet on any branch. The good news is I just received one; now all I need is free time. No eta. Sam From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 03:39:41 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9842B106564A; Wed, 18 Feb 2009 03:39:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 4029C8FC18; Wed, 18 Feb 2009 03:39:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n1I3adYk040226; Tue, 17 Feb 2009 20:36:39 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 17 Feb 2009 20:36:47 -0700 (MST) Message-Id: <20090217.203647.-1518647466.imp@bsdimp.com> To: tinderbox@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20090218023328.227617302F@freebsd-current.sentex.ca> References: <20090218023328.227617302F@freebsd-current.sentex.ca> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mips@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 03:39:42 -0000 In message: <20090218023328.227617302F@freebsd-current.sentex.ca> FreeBSD Tinderbox writes: : /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required alignment of target type there's still 3 or 4 of these in the tree that I'm trying to track back to root cause. A simple (void *) fixes the problem, but I want to understand the issues before I slap that bad-boy in there... Warner From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 04:06:10 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C2EF1065675 for ; Wed, 18 Feb 2009 04:06:10 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout022.mac.com (asmtpout022.mac.com [17.148.16.97]) by mx1.freebsd.org (Postfix) with ESMTP id BAF978FC18 for ; Wed, 18 Feb 2009 04:06:09 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from MacBook-Pro.lan.xcllnt.net (xcllnt.net [75.101.29.67]) by asmtp022.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KF8006M6U28MG80@asmtp022.mac.com>; Tue, 17 Feb 2009 20:06:09 -0800 (PST) Message-id: <302F9BB0-AF38-422C-86DB-96FCF47C2168@mac.com> From: Marcel Moolenaar To: "M. Warner Losh" In-reply-to: <20090217.203647.-1518647466.imp@bsdimp.com> Date: Tue, 17 Feb 2009 20:06:08 -0800 References: <20090218023328.227617302F@freebsd-current.sentex.ca> <20090217.203647.-1518647466.imp@bsdimp.com> X-Mailer: Apple Mail (2.930.3) Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 04:06:10 -0000 On Feb 17, 2009, at 7:36 PM, M. Warner Losh wrote: > In message: <20090218023328.227617302F@freebsd-current.sentex.ca> > FreeBSD Tinderbox writes: > : /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/ > snmp_mibII/mibII.c:1016: warning: cast increases required alignment > of target type > > there's still 3 or 4 of these in the tree that I'm trying to track > back to root cause. A simple (void *) fixes the problem, but I want > to understand the issues before I slap that bad-boy in there... I think the warning simply means that you cast from pointer to type A with alignment requirement P to pointer to type B with alignment requirement Q, and with P < Q. This doesn't necessary mean there's a problem (i.e that you have a misaligned dereference), but there's a potential. A case by case analysis is called for... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 05:24:48 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B1C471065670; Wed, 18 Feb 2009 05:24:48 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 632558FC16; Wed, 18 Feb 2009 05:24:48 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n1I5LiA7041225; Tue, 17 Feb 2009 22:21:45 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 17 Feb 2009 22:21:52 -0700 (MST) Message-Id: <20090217.222152.-109416210.imp@bsdimp.com> To: tinderbox@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20090217.203647.-1518647466.imp@bsdimp.com> References: <20090218023328.227617302F@freebsd-current.sentex.ca> <20090217.203647.-1518647466.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mips@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 05:24:49 -0000 In message: <20090217.203647.-1518647466.imp@bsdimp.com> "M. Warner Losh" writes: : In message: <20090218023328.227617302F@freebsd-current.sentex.ca> : FreeBSD Tinderbox writes: : : /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required alignment of target type : : there's still 3 or 4 of these in the tree that I'm trying to track : back to root cause. A simple (void *) fixes the problem, but I want : to understand the issues before I slap that bad-boy in there... The first one is: case RTM_IFINFO: ifm = (struct if_msghdr *)rtm; mib_extract_addrs(ifm->ifm_addrs, (u_char *)(ifm + 1), addrs); if ((ifp = mib_find_if_sys(ifm->ifm_index)) == NULL) break; rtm is of type struct rt_msghdr. This has an alignment requirement of 4 on mips, at least on 32-bit mips (the biggest data element is a u_long). struct if_msghdr has an alignment requirement of 8, because time_t is int64_t on MIPS, which is 8-bytes in size. One way to fix this is to add __aligned(8) to struct rt_msghdr to compensate for this. Otherwise, if the time_t element is referenced in ifm_data we'll core dump. But that doesn't seem very portable and seems like a hack. Adding (void *) to "fix" the warning would be even worse... Anybody else have any ideas? Warner From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 06:01:35 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C430106564A for ; Wed, 18 Feb 2009 06:01:35 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from creme-brulee.marcuscom.com (marcuscom-pt.tunnel.tserv1.fmt.ipv6.he.net [IPv6:2001:470:1f00:ffff::1279]) by mx1.freebsd.org (Postfix) with ESMTP id 4FCCE8FC08 for ; Wed, 18 Feb 2009 06:01:35 +0000 (UTC) (envelope-from marcus@FreeBSD.org) Received: from [IPv6:2001:470:1f00:2464::4] (shumai.marcuscom.com [IPv6:2001:470:1f00:2464::4]) by creme-brulee.marcuscom.com (8.14.3/8.14.3) with ESMTP id n1I62lms016688 for ; Wed, 18 Feb 2009 01:02:47 -0500 (EST) (envelope-from marcus@FreeBSD.org) From: Joe Marcus Clarke To: current Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-pvfx4DwXxpvwFDloAFMH" Organization: FreeBSD, Inc. Date: Wed, 18 Feb 2009 01:01:44 -0500 Message-Id: <1234936904.17001.108.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Evolution 2.24.4 FreeBSD GNOME Team Port X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on creme-brulee.marcuscom.com Cc: Subject: HEADS UP: usb2 support for hal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 06:01:35 -0000 --=-pvfx4DwXxpvwFDloAFMH Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I've completed working (at least for me) usb2 support for hal. I've also fixed some hal bugs along the way. Before I commit this, please try this out. I don't have a lot of hardware, but I was able to test umass drive mounting in GNOME. If you have problems, refer to the HAL FAQ at http://www.freebsd.org/gnome/docs/halfaq.html before reporting them. http://www.marcuscom.com/downloads/hal_usb2.diff Joe --=20 Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome --=-pvfx4DwXxpvwFDloAFMH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAkmbpEcACgkQb2iPiv4Uz4crWACgg0eSrAwFAPsPj5Hby1tsgoUz M6YAn1RlLs+pT4POOJXGpaoLokxCREas =Y9qi -----END PGP SIGNATURE----- --=-pvfx4DwXxpvwFDloAFMH-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 06:26:10 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A671C106564A; Wed, 18 Feb 2009 06:26:10 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout017.mac.com (asmtpout017.mac.com [17.148.16.92]) by mx1.freebsd.org (Postfix) with ESMTP id 8E8E88FC13; Wed, 18 Feb 2009 06:26:10 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from MacBook-Pro.lan.xcllnt.net (xcllnt.net [75.101.29.67]) by asmtp017.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KF9003FQ0JKV900@asmtp017.mac.com>; Tue, 17 Feb 2009 22:26:10 -0800 (PST) Message-id: <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> From: Marcel Moolenaar To: "M. Warner Losh" In-reply-to: <20090217.222152.-109416210.imp@bsdimp.com> Date: Tue, 17 Feb 2009 22:26:08 -0800 References: <20090218023328.227617302F@freebsd-current.sentex.ca> <20090217.203647.-1518647466.imp@bsdimp.com> <20090217.222152.-109416210.imp@bsdimp.com> X-Mailer: Apple Mail (2.930.3) Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 06:26:11 -0000 On Feb 17, 2009, at 9:21 PM, M. Warner Losh wrote: > In message: <20090217.203647.-1518647466.imp@bsdimp.com> > "M. Warner Losh" writes: > : In message: <20090218023328.227617302F@freebsd-current.sentex.ca> > : FreeBSD Tinderbox writes: > : : /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/ > bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required > alignment of target type > : > : there's still 3 or 4 of these in the tree that I'm trying to track > : back to root cause. A simple (void *) fixes the problem, but I want > : to understand the issues before I slap that bad-boy in there... > > The first one is: > > case RTM_IFINFO: > ifm = (struct if_msghdr *)rtm; > mib_extract_addrs(ifm->ifm_addrs, (u_char *)(ifm + 1), addrs); > if ((ifp = mib_find_if_sys(ifm->ifm_index)) == NULL) > break; > > rtm is of type struct rt_msghdr. This has an alignment requirement of > 4 on mips, at least on 32-bit mips (the biggest data element is a > u_long). struct if_msghdr has an alignment requirement of 8, because > time_t is int64_t on MIPS, which is 8-bytes in size. Normally on 32-bit architectures, 64-bit data types have a 32-bit alignment requirement by virtue of needing 2 32-bit loads/stores to read/write them. Does 32-bit MIPS use 64-bit wide registers? > One way to fix this is to add __aligned(8) to struct rt_msghdr to > compensate for this. Otherwise, if the time_t element is referenced > in ifm_data we'll core dump. A safer approach is to mark ifi_epoch as packed or put differently, define time_t as a 64-bit integral with 32-bit alignment. This can avoid a lot of unexpected internal padding as well (e.g. struct timeval). Just a thought. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 06:42:20 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9B3A8106566B; Wed, 18 Feb 2009 06:42:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 3BAB38FC14; Wed, 18 Feb 2009 06:42:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n1I6g84X042155; Tue, 17 Feb 2009 23:42:08 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 17 Feb 2009 23:42:16 -0700 (MST) Message-Id: <20090217.234216.1276682135.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> References: <20090217.203647.-1518647466.imp@bsdimp.com> <20090217.222152.-109416210.imp@bsdimp.com> <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 06:42:21 -0000 In message: <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> Marcel Moolenaar writes: : : On Feb 17, 2009, at 9:21 PM, M. Warner Losh wrote: : : > In message: <20090217.203647.-1518647466.imp@bsdimp.com> : > "M. Warner Losh" writes: : > : In message: <20090218023328.227617302F@freebsd-current.sentex.ca> : > : FreeBSD Tinderbox writes: : > : : /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/ : > bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required : > alignment of target type : > : : > : there's still 3 or 4 of these in the tree that I'm trying to track : > : back to root cause. A simple (void *) fixes the problem, but I want : > : to understand the issues before I slap that bad-boy in there... : > : > The first one is: : > : > case RTM_IFINFO: : > ifm = (struct if_msghdr *)rtm; : > mib_extract_addrs(ifm->ifm_addrs, (u_char *)(ifm + 1), addrs); : > if ((ifp = mib_find_if_sys(ifm->ifm_index)) == NULL) : > break; : > : > rtm is of type struct rt_msghdr. This has an alignment requirement of : > 4 on mips, at least on 32-bit mips (the biggest data element is a : > u_long). struct if_msghdr has an alignment requirement of 8, because : > time_t is int64_t on MIPS, which is 8-bytes in size. : : Normally on 32-bit architectures, 64-bit data types have a 32-bit : alignment requirement by virtue of needing 2 32-bit loads/stores : to read/write them. Does 32-bit MIPS use 64-bit wide registers? MIPS isn't normal :). MIPS really is a 64-bit architecture. The only way to make the warning go away would be to build -mmips32r2 or something like that. But since we're going to be supporting n32 ABI (which really is a 64-bit ABI despite its name) and n64, the issue won't be going away. This is desirable for the Octeon support that I hope to commit soon. : > One way to fix this is to add __aligned(8) to struct rt_msghdr to : > compensate for this. Otherwise, if the time_t element is referenced : > in ifm_data we'll core dump. : : A safer approach is to mark ifi_epoch as packed or put differently, : define time_t as a 64-bit integral with 32-bit alignment. This can : avoid a lot of unexpected internal padding as well (e.g. struct : timeval). Marking it as packed won't help. If the elements aren't properly aligned, gcc won't access multi-word entities properly. It might eliminate the warning, but it will break at runtime. Warner From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 06:51:12 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48E381065676; Wed, 18 Feb 2009 06:51:12 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout015.mac.com (asmtpout015.mac.com [17.148.16.90]) by mx1.freebsd.org (Postfix) with ESMTP id 30B858FC22; Wed, 18 Feb 2009 06:51:12 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from MacBook-Pro.lan.xcllnt.net (xcllnt.net [75.101.29.67]) by asmtp015.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KF900CBA1PAMW60@asmtp015.mac.com>; Tue, 17 Feb 2009 22:51:12 -0800 (PST) Message-id: From: Marcel Moolenaar To: "M. Warner Losh" In-reply-to: <20090217.234216.1276682135.imp@bsdimp.com> Date: Tue, 17 Feb 2009 22:51:10 -0800 References: <20090217.203647.-1518647466.imp@bsdimp.com> <20090217.222152.-109416210.imp@bsdimp.com> <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> <20090217.234216.1276682135.imp@bsdimp.com> X-Mailer: Apple Mail (2.930.3) Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 06:51:13 -0000 On Feb 17, 2009, at 10:42 PM, M. Warner Losh wrote: > : A safer approach is to mark ifi_epoch as packed or put differently, > : define time_t as a 64-bit integral with 32-bit alignment. This can > : avoid a lot of unexpected internal padding as well (e.g. struct > : timeval). > > Marking it as packed won't help. If the elements aren't properly > aligned, gcc won't access multi-word entities properly. It might > eliminate the warning, but it will break at runtime. But GCC will use a pair of 32-bit loads and/or stores to access the 64-bit integral in that case. There should be no runtime breakage. You only do this for n32 of course. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 07:00:54 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95F1D1065676; Wed, 18 Feb 2009 07:00:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 541EB8FC1B; Wed, 18 Feb 2009 07:00:54 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n1I6wIkf042376; Tue, 17 Feb 2009 23:58:18 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 17 Feb 2009 23:58:26 -0700 (MST) Message-Id: <20090217.235826.-1697751865.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: References: <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> <20090217.234216.1276682135.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 07:00:55 -0000 In message: Marcel Moolenaar writes: : : On Feb 17, 2009, at 10:42 PM, M. Warner Losh wrote: : : > : A safer approach is to mark ifi_epoch as packed or put differently, : > : define time_t as a 64-bit integral with 32-bit alignment. This can : > : avoid a lot of unexpected internal padding as well (e.g. struct : > : timeval). : > : > Marking it as packed won't help. If the elements aren't properly : > aligned, gcc won't access multi-word entities properly. It might : > eliminate the warning, but it will break at runtime. : : But GCC will use a pair of 32-bit loads and/or stores to : access the 64-bit integral in that case. There should be : no runtime breakage. You only do this for n32 of course. Why only n32? Registers are still 64-bit in n32. Warner From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 07:09:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 16A6A106566B; Wed, 18 Feb 2009 07:09:41 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swip.net [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id 4B78C8FC1A; Wed, 18 Feb 2009 07:09:40 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=alLys8lIAMYA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=6I5d2MoRAAAA:8 a=LeH6XzfVAAAA:8 a=B3vYKI5NH0Pu5sZRWoAA:9 a=BErSo5_AH2QeOVcG6iYA:7 a=bNNTZTAhNDwJElQ85b00C3hNfSYA:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1025453376; Wed, 18 Feb 2009 08:09:38 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org, Andrew Thompson Date: Wed, 18 Feb 2009 08:12:06 +0100 User-Agent: KMail/1.9.7 References: <1234936904.17001.108.camel@shumai.marcuscom.com> In-Reply-To: <1234936904.17001.108.camel@shumai.marcuscom.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902180812.06702.hselasky@c2i.net> Cc: Joe Marcus Clarke Subject: Re: HEADS UP: usb2 support for hal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 07:09:41 -0000 On Wednesday 18 February 2009, Joe Marcus Clarke wrote: > I've completed working (at least for me) usb2 support for hal. I've > also fixed some hal bugs along the way. Before I commit this, please > try this out. I don't have a lot of hardware, but I was able to test > umass drive mounting in GNOME. If you have problems, refer to the HAL > FAQ at http://www.freebsd.org/gnome/docs/halfaq.html before reporting > them. > > http://www.marcuscom.com/downloads/hal_usb2.diff > > Joe The new functions in libusb20 required by HAL has not yet been committed to -current. I will see about getting it in soon. --HPS From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 07:12:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B75061065779 for ; Wed, 18 Feb 2009 07:12:04 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from koef.zs64.net (koef.zs64.net [212.12.50.230]) by mx1.freebsd.org (Postfix) with ESMTP id 1A9FC8FC33 for ; Wed, 18 Feb 2009 07:12:03 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from localhost by koef.zs64.net (8.14.3/8.14.3) with ESMTP id n1I6t2He028828 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 18 Feb 2009 07:55:04 +0100 (CET) (envelope-from stb@lassitu.de) (authenticated as stb) Message-Id: <7EFAB629-75C5-41C1-BDAC-ADE5F69D9EF6@lassitu.de> From: Stefan Bethke To: FreeBSD Current In-Reply-To: <171C5946-63D1-4AC7-89F7-A951BEF3D1C6@lassitu.de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 18 Feb 2009 07:55:02 +0100 References: <76873DDF-D21B-48AF-9AFB-5A2747BE406B@lassitu.de> <3A302EE1-F54D-4415-BC13-CA8ABBA320EC@lassitu.de> <171C5946-63D1-4AC7-89F7-A951BEF3D1C6@lassitu.de> X-Mailer: Apple Mail (2.930.3) Subject: Re: zfs: using, then destroying a snapshot sometimes panics zfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 07:12:05 -0000 Didn't get any responses on -fs, maybe someone here has seen similar behaviour? Stefan Am 15.02.2009 um 12:08 schrieb Stefan Bethke: > > Am 15.02.2009 um 11:39 schrieb Stefan Bethke: > >> Am 08.02.2009 um 14:37 schrieb Stefan Bethke: >> >>> Sorry I can't be more precise at the moment, but while creating a >>> script that mirrors some zfs filesystems to another machine, I've >>> now twice gotten weird behaviour and then a panic. >>> >>> The script iterates over a couple of zfs file systems: >>> - creates a snapshot with zfs snapshot tank/foo@mirror >>> - uses rsync to copy the contents of the snapshot with rsync /tank/ >>> foo/.zfs/snapshot/mirror/ dest:... >>> - destroys the snapshot with zfs destroy tank/foo@mirror >>> >>> During testing the script, I twice got to a point where, after the >>> snapshot was created without an error message, rsync dropped out >>> with an error message similar to "invalid file handle" on /tank/ >>> foo/.zfs/snapshot. >>> >>> At that point, I could cd to /tank/foo/.zfs, but ls produced the >>> same error message. >>> >>> I then tried to unmount the snapshot with zfs umount, and got a >>> panic (which I also didn't manage to capture). >>> >>> Is this a generally known issue, or should I try to capture more >>> information when this happens again? >> >> >> # cd /tank/foo/.zfs >> # ls -l >> ls: snapshot: Bad file descriptor >> total 0 >> # cd snapshot >> -su: cd: snapshot: Not a directory >> >> I currently have no snapshots: >> # zfs list -t snapshot >> no datasets available >> >> However, on a different file system, I can list and cd into snapshot: >> # /tank/bar/.zfs >> # ls -l >> total 0 >> dr-xr-xr-x 2 root wheel 2 Feb 8 00:43 snapshot/ >> # cd snapshot >> >> Trying to umount produces a panic: >> # zfs umount /jail/foo >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; apic id = 01 >> fault virtual address = 0xa8 >> fault code = supervisor write data, page not present >> instruction pointer = 0x8:0xffffffff802ee565 >> stack pointer = 0x10:0xfffffffea29c39e0 >> frame pointer = 0x10:0xfffffffea29c39f0 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 51383 (zfs) >> [thread pid 51383 tid 100298 ] >> Stopped at _sx_xlock+0x15: lock cmpxchgq %rsi,0x18(%rdi) >> db> bt >> Tracing pid 51383 tid 100298 td 0xffffff00a598e720 >> _sx_xlock() at _sx_xlock+0x15 >> zfsctl_umount_snapshots() at zfsctl_umount_snapshots+0xa5 >> zfs_umount() at zfs_umount+0xdd >> dounmount() at dounmount+0x2b4 >> unmount() at unmount+0x24b >> syscall() at syscall+0x1a5 >> Xfast_syscall() at Xfast_syscall+0xab >> --- syscall (22, FreeBSD ELF64, unmount), rip = 0x800f412fc, rsp = >> 0x7fffffffd1a8, rbp = 0x801202300 --- >> db> call doadump >> Physical memory: 3314 MB >> Dumping 1272 MB: 1257 1241 1225 1209 1193 1177 1161 1145 1129 1113 >> 1097 1081 1065 1049 1033 1017 1001 985 969 953 937 921 905 889 873 >> 857 841 825 809 793 777 761 745 729 713 697 681 665 649 633 617 601 >> 585 569 553 537 521 505 489 473 457 441 425 409 393 377 361 345 329 >> 313 297 281 265 249 233 217 201 185 169 153 137 121 105 89 73 57 41 >> 25 9 >> Dump complete >> = 0 >> >> I've got the crashdump saved, if there's any information in there >> that can be helpful. >> >> This is -current from a week ago on amd64. >> >> At the current rate, this happens every couple of days, so >> gathering more information on the live system probably won't be a >> problem. > > Different machine, identical configuration, I just got this panic on > reboot: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xa8 > fault code = supervisor write data, page not present > instruction pointer = 0x8:0xffffffff802ee3b5 > stack pointer = 0x10:0xfffffffe40016980 > frame pointer = 0x10:0xfffffffe40016990 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 1 (init) > [thread pid 1 tid 100002 ] > Stopped at _sx_xlock+0x15: lock cmpxchgq %rsi,0x18(%rdi) > db> bt > Tracing pid 1 tid 100002 td 0xffffff000141fab0 > _sx_xlock() at _sx_xlock+0x15 > zfsctl_umount_snapshots() at zfsctl_umount_snapshots+0xa5 > zfs_umount() at zfs_umount+0xdd > dounmount() at dounmount+0x2b4 > vfs_unmountall() at vfs_unmountall+0x42 > boot() at boot+0x655 > reboot() at reboot+0x42 > syscall() at syscall+0x1a5 > Xfast_syscall() at Xfast_syscall+0xab > --- syscall (55, FreeBSD ELF64, reboot), rip = 0x40897c, rsp = > 0x7fffffffe7b8, rbp = 0x402420 --- > > > -- > Stefan Bethke Fon +49 151 14070811 > > > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" -- Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 08:12:05 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0554106573B; Wed, 18 Feb 2009 08:12:03 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from mout1.freenet.de (mout1.freenet.de [IPv6:2001:748:100:40::2:3]) by mx1.freebsd.org (Postfix) with ESMTP id 5284B8FC0C; Wed, 18 Feb 2009 08:12:03 +0000 (UTC) (envelope-from gary.jennejohn@freenet.de) Received: from [195.4.92.14] (helo=4.mx.freenet.de) by mout1.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #76) id 1LZhX9-0004Dt-1N; Wed, 18 Feb 2009 09:11:55 +0100 Received: from tcc1f.t.pppool.de ([89.55.204.31]:39187 helo=ernst.jennejohn.org) by 4.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #76) id 1LZhX8-0000Lm-OZ; Wed, 18 Feb 2009 09:11:54 +0100 Date: Wed, 18 Feb 2009 09:11:51 +0100 From: Gary Jennejohn To: Scott Long Message-ID: <20090218091151.4d9c2bd7@ernst.jennejohn.org> In-Reply-To: <499B221C.2050804@samsco.org> References: <499981AF.9030204@samsco.org> <20090217164203.4c586f48@ernst.jennejohn.org> <20090218073542.E5200@delplex.bde.org> <499B221C.2050804@samsco.org> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; amd64-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Stable , Bruce Evans , scsi@FreeBSD.org Subject: Re: HEADS UP: More CAM fixes. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: gary.jennejohn@freenet.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 08:12:08 -0000 On Tue, 17 Feb 2009 13:46:20 -0700 Scott Long wrote: > Bruce Evans wrote: > > On Tue, 17 Feb 2009, Gary Jennejohn wrote: > > > >> I tested this with an Adaptec 29160. I saw no real improvement in > >> performance, but also no regressions. > >> > >> I suspect that the old disk I had attached just didn't have enough > >> performance reserves to show an improvement. > >> > >> My test scenario was buildworld. Since /usr/src and /usr/obj were both > >> on the one disk it got a pretty good workout. > > ^^^^ low > >> > >> AMD64 X2 (2.5 GHz) with 4GB of RAM. > > > > Buildworld hardly uses the disk at all. It reads and writes a few hundred > > MB. Ideally the i/o should go at disk speeds of 50-200MB/S and thus take > > between 20 and 5 seconds. In practice, it will take a few more seconds. > > physically but perhaps even less virtually due to parallelism. > > > > Bruce > > Yes, on modern machines, buildworld is bound almost completely by disk > latency, and not at all by disk or controller bandwidth. > > Scott > Maybe I misunderstood something, but I thought the patch was supposed to improve queuing. Seems like all the seeks during a buildowrld would exercise that. All I can say is that the disk did _lots_ of seeking. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 08:13:13 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 59E941065868 for ; Wed, 18 Feb 2009 08:13:13 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 1D4F58FC1E for ; Wed, 18 Feb 2009 08:13:12 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id F38AD3F129; Wed, 18 Feb 2009 08:13:11 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id n1I8DFdt018685; Wed, 18 Feb 2009 08:13:15 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 17 Feb 2009 16:19:55 PST." Date: Wed, 18 Feb 2009 08:13:15 +0000 Message-ID: <18684.1234944795@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: "Bjoern A. Zeeb" , FreeBSD current mailing list Subject: Re: boot0cfg -s vs. GEOM_PART_*? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 08:13:14 -0000 In message , Marcel Moolenaar wri tes: >I'll consider this. > > From my perspective: > >o The fact that we have a separate OAM interface that > doesn't use file descriptors (at the application > level), having to use ioctl(2) all of a sudden is... > well... odd. Likewise for regular read/write. Just > for boot code do we need o worry about mapping GEOM > names to device special files. You can use g_ctl instead of ioctl if you want, it just does not belong in the xml. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 10:56:53 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7717D106564A for ; Wed, 18 Feb 2009 10:56:53 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by mx1.freebsd.org (Postfix) with ESMTP id 00AB28FC0C for ; Wed, 18 Feb 2009 10:56:52 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by ey-out-2122.google.com with SMTP id d26so246427eyd.7 for ; Wed, 18 Feb 2009 02:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9HyJYAyGPrg5GooMbGTihyxzKxR8rqrdh+jHuypMEzQ=; b=V4TWHDiriRUXkwZvFKwZK+dhExYZXjOhi6JY3WOjb/+ueohLT/kRvJ48lUEz4R9/K6 ObjOgLLxe2g3gdrxu5YfNrx0vpJjNDVHVx8whGUdTfI0Nusn5K5PkK1tbiGphBbmt/z8 7Apy03MtNGfz/p2T42Rfb8uLUxsZhZN9kovPc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=kFMLgw4zh8bAVrPu1F6SX+zSmJfGNtMElzkK7dXkP/v7DhtEgDyEzgSneE6lq5m+E9 DqBwlIzwQJqzA1fSyvKZhxE7dDQJ+okG4MmRrHgd7wlewOVqeHMyMN7AgEVDCsVOvMFO j+8smXLAe67Z4dJM//P+OdzpzwcDfVTCWXRos= MIME-Version: 1.0 Received: by 10.210.41.14 with SMTP id o14mr4057317ebo.30.1234954612071; Wed, 18 Feb 2009 02:56:52 -0800 (PST) In-Reply-To: <20090217142615.A77950@grasshopper.cs.duke.edu> References: <20090217142615.A77950@grasshopper.cs.duke.edu> Date: Wed, 18 Feb 2009 11:56:52 +0100 Message-ID: <3a142e750902180256p68ef8fc0nbda773d41d42a7a0@mail.gmail.com> From: "Paul B. Mahol" To: Andrew Gallatin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: r187880 causes fatal trap 30 when unloading drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 10:56:53 -0000 On 2/17/09, Andrew Gallatin wrote: > I'm seeing a panic when I unload if_mxge. I suspect it was caused by > the recent change to allocate apic vectors on a per-CPU basis. > > I see the panic only when running an SMP kernel, and only on our 8-way > opterons (a dual-core athlon64 is fine). This is on a box with 2 > NICs. Every time I unload my driver, 2 CPUs panic at the same time > slightly after unloading the driver. It occurs both when I use a > single MSI, or legacy interrupts. Untangling the garbled jibberish, I > see this on console: > > Fatal trap 30: reserved (unknown) fault while in kernel mode > cpuid = 2; apic id = 02 > instruction pointer = 0x8:0xffffffff807ded46 > stack pointer = 0x10:0xfffffffe40063b70 > frame pointer = 0x10:0xfffffffe40063b80 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, IOPL = 0 > current process = 11 (idle: cpu2) > trap number = 30 > > Fatal trap 30: reserved (unknown) fault while in kernel mode > cpuid = 1; apic id = 01 > instruction pointer = 0x8:0xffffffff807ded46 > stack pointer = 0x10:0xfffffffe40068b70 > frame pointer = 0x10:0xfffffffe40068b80 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, IOPL = 0 > current process = 11 (idle: cpu1) > trap number = 30 > > I cannot get a dump, and ddb shows that it is sitting in the > acpi acpi_cpu_c1() function. I saw a similar report a > little while back > (http://lists.freebsd.org/pipermail/freebsd-current/2009-February/003141.html). > Following John's suggestion later in the thread, I tried backing > out r187880, and I can again unload drivers. > > FWIW, I'm fairly certain the unhandled IRQ is not coming from the NIC. > The NIC will not generate interrupts when it is not ifconfig'ed up. > Given that, and how I usually see kldunload finish before the panic > happens, I wonder if it might be a clock interrupt that is triggering > the trap. > > > Drew > _______________________________________________ > 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" > Me too, happens when zaping Xorg: db:0:kdb.enter.unknown> run lockinfodb:1:lockinfo> show locksdb:1:locks> show alllocksProcess 13 (acpi_thermal) thread 0xc3d88d80 (100024)db:1:alllocks> show lockedvnodsLocked vnodesdb:0:kdb.enter.unknown> show pcpucpuid = 1curthread = 0xc3d08d80: pid 10 "idle: cpu1"curpcb = 0xc399ed90fpcurthread = noneidlethread = 0xc3d08d80: pid 10 "idle: cpu1"APIC ID = 1currentldt = 0x50spin locks held:db:0:kdb.enter.unknown> bt Tracing pid 10 tid 100002 td 0xc3d08d80acpi_cpu_c1(1,c399ec88,c399ecd8,1,0,...) at acpi_cpu_c1+0x5acpi_cpu_idle(c399ecb4,c05d1b75,1,c399ecf8,c04c1435,...) at acpi_cpu_idle+0x186cpu_idle_acpi(1,c399ecf8,c04c1435,1,c399ecd8,...) at cpu_idle_acpi+0x1bcpu_idle(1,c399ecd8,c060671c,a0b,c3d08d80,...) at cpu_idle+0x1bsched_idletd(0,c399ed38,c0600bf0,32d,c3d06d34,...) at sched_idletd+0x216fork_exit(c04c121f,0,c399ed38) at fork_exit+0xb8fork_trampoline() at fork_trampoline+0x8 Fatal trap 30: reserved (unknown) fault while in kernel modecpuid = 1; apic id = 01instruction pointer = 0x20:0xc096d23cstack pointer = 0x28:0xc399ec70frame pointer = 0x28:0xc399ec70code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1processor eflags = interrupt enabled, IOPL = 0current process = 10 (idle: cpu1)exclusive sx ACPI embedded controller (ACPI embedded controller) r = 0 (0xc097e130) locked @ /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi_ec.c:210 The only workaroud is to disable SMP. -- Paul From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 11:04:19 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C2371065672 for ; Wed, 18 Feb 2009 11:04:19 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwmtas06p.mx.bigpond.com (nschwmtas06p.mx.bigpond.com [61.9.189.152]) by mx1.freebsd.org (Postfix) with ESMTP id 9A64E8FC18 for ; Wed, 18 Feb 2009 11:04:18 +0000 (UTC) (envelope-from andrew@areilly.bpa.nu) Received: from nschwotgx01p.mx.bigpond.com ([124.188.162.219]) by nschwmtas06p.mx.bigpond.com with ESMTP id <20090218110417.UMMD3101.nschwmtas06p.mx.bigpond.com@nschwotgx01p.mx.bigpond.com> for ; Wed, 18 Feb 2009 11:04:17 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by nschwotgx01p.mx.bigpond.com with ESMTP id <20090218110415.RDVR807.nschwotgx01p.mx.bigpond.com@areilly.bpa.nu> for ; Wed, 18 Feb 2009 11:04:15 +0000 Received: (qmail 13316 invoked by uid 501); 18 Feb 2009 11:04:02 -0000 Date: Wed, 18 Feb 2009 22:04:02 +1100 From: Andrew Reilly To: "M. Warner Losh" Message-ID: <20090218110402.GA13040@duncan.reilly.home> References: <20090218023328.227617302F@freebsd-current.sentex.ca> <20090217.203647.-1518647466.imp@bsdimp.com> <20090217.222152.-109416210.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090217.222152.-109416210.imp@bsdimp.com> User-Agent: Mutt/1.4.2.3i X-RPD-ScanID: Class unknown; VirusThreatLevel unknown, RefID str=0001.0A150205.499BEB2F.006A,ss=1,fgs=0 Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 11:04:19 -0000 On Tue, Feb 17, 2009 at 10:21:52PM -0700, M. Warner Losh wrote: > In message: <20090217.203647.-1518647466.imp@bsdimp.com> > "M. Warner Losh" writes: > : In message: <20090218023328.227617302F@freebsd-current.sentex.ca> > : FreeBSD Tinderbox writes: > : : /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required alignment of target type > The first one is: > > case RTM_IFINFO: > ifm = (struct if_msghdr *)rtm; > mib_extract_addrs(ifm->ifm_addrs, (u_char *)(ifm + 1), addrs); > if ((ifp = mib_find_if_sys(ifm->ifm_index)) == NULL) > break; > > rtm is of type struct rt_msghdr. This has an alignment requirement of > 4 on mips, at least on 32-bit mips (the biggest data element is a > u_long). struct if_msghdr has an alignment requirement of 8, because > time_t is int64_t on MIPS, which is 8-bytes in size. If the memory that rtm can be pointing to can be either a struct rt_msghdr or a struct if_msghdr, then shouldn't it really be pointing to a union of those two, and then the alignment will sort itself out? (As far as I know, that's the only way that C99 will guarantee that the right thing happens anyway, otherwise strict aliasing analysis would allow much worse badness to happen, potentially.) Not looked at the code myself. Perhaps there's a reason why that would be unworkable. Cheers, Andrew From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 11:10:59 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 954341065670; Wed, 18 Feb 2009 11:10:59 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 534A48FC1F; Wed, 18 Feb 2009 11:10:59 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id E1A1146B06; Wed, 18 Feb 2009 06:10:58 -0500 (EST) Date: Wed, 18 Feb 2009 11:10:58 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Hans Petter Selasky In-Reply-To: <200902171704.48860.hselasky@c2i.net> Message-ID: References: <200902171704.48860.hselasky@c2i.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Andrew Thompson Subject: Re: USB2 + kdb support (UMASS disk dump + USB keyboard) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 11:11:00 -0000 On Tue, 17 Feb 2009, Hans Petter Selasky wrote: > With USB1 it was possible to use the USB keyboard in the debugger. With USB2 > this is also possible, but not as long as the keyboard driver is using > Giant. > > Currently USB2 supports a special mode called polling mode, which is going > to be removed, because even on a micro embedded system polling mode is not > useful, which was my thought keeping this behaviour. > > Instead I want to enforce normal running mode where USB and timer callbacks > are handled like normal when in the kernel debugger. > > Question: > > When the CPU is in the debugger and is asking for USB devices to be polled, > is there a way to get the USB threads running again so that callbacks can be > handled? DDB is a very special execution environment intended to be able to be execute in a number of sticky circumstances including: - Complete deadlock of the system with interrupts disabled on all CPUs. - panic() within the scheduler itself, possibly as a result of corrupted scheduler data structures or violated invariants relating to threads, locking, such as a corrupted mutex pointer being passed to a locking primitive, etc. - Following a crashdump that has reset disk controllers in order to perform a dump from an unknown controller state. - From within both fast and ithread interrupt handlers. - From within callout handlers and task queue execution environments. - From within the idle loop in idle threads, which must always be in a runnable state and never block when the scheduler is in execution. - From any regular code path in the kernel. While in DDB, in general, no further kernel execution is permitted, and we disable interrupts and IPI all CPUs (ideally with an NMI on supporting platforms) to ensure that is the case. To add insult to injury, the kernel then has to be restartable again after running in DDB for a potentially extended period. On the whole this works well, although you can upset accounting of process execution times in practice, or cause things to time out oddly when the callout thread is suspended for an extended period (for example). This is the reason for the polled interface to all low-level console devices, which provide a reliable, minimal, and lock-free path that can be used by the debugger for I/O to the user, and in the case of serial ports, a serial debugger. On the whole, this is possible because normal console and serial parts support minimalist "just pop things in the I/O port" interfaces that are moderately reentrant with respect to normal kernel interface with the device. Execution of kernel threads for the purposes of I/O would violate a number of the above requirements in at least the following ways: - It would require restarting some or all of the kernel in a debugging context. - It would require entering the scheduler and relying on its data structures, as well as potentially IPI'ing other CPUs if the thread in question were already running there, requiring interrupt handling to be working and enabled. At the end of the day, DDB can only be used to debug things effectively if they aren't used to interact with DDB, so not being able to debug USB well may be a natural consequence of using USB to talk to DDB. However, USB, if used to interact with DDB, must play by DDB's rules. Any weakening of DDB's assumptions (no interrupts, no parallelism, no scheduling, no locking, ...) will make DDB a less effective debugging tool, and if possible, we should try to entirely avoid that. Certainly, executing complex code paths, such as the kbd mux code requiring deferred execution contexts, is out of the question, but it would be useful if a USB keyboard could be used in a minimal mode with minimal code and functional footprint with DDB. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 11:16:47 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 291901065675 for ; Wed, 18 Feb 2009 11:16:47 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from mailrelay.rz.uni-wuerzburg.de (mailrelay.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.freebsd.org (Postfix) with ESMTP id A61038FC1A for ; Wed, 18 Feb 2009 11:16:46 +0000 (UTC) (envelope-from shuvaev@physik.uni-wuerzburg.de) Received: from virusscan.mail (localhost [127.0.0.1]) by mailrelay.mail (Postfix) with ESMTP id 99232A07A7; Wed, 18 Feb 2009 12:16:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by virusscan.mail (Postfix) with ESMTP id 8C711A07A5; Wed, 18 Feb 2009 12:16:45 +0100 (CET) Received: from mail.physik.uni-wuerzburg.de (wthp192.physik.uni-wuerzburg.de [132.187.40.192]) by mailmaster.uni-wuerzburg.de (Postfix) with ESMTP id 78346A0799; Wed, 18 Feb 2009 12:16:45 +0100 (CET) Received: from wep4035 ([132.187.37.35]) by mail.physik.uni-wuerzburg.de (Lotus Domino Release 8.0.2HF443) with ESMTP id 2009021812164526-83230 ; Wed, 18 Feb 2009 12:16:45 +0100 Received: by wep4035 (sSMTP sendmail emulation); Wed, 18 Feb 2009 12:16:44 +0100 From: "Alexey Shuvaev" Date: Wed, 18 Feb 2009 12:16:44 +0100 To: Gary Jennejohn Message-ID: <20090218111644.GB43516@wep4035.physik.uni-wuerzburg.de> References: <499981AF.9030204@samsco.org> <20090217164203.4c586f48@ernst.jennejohn.org> <20090218073542.E5200@delplex.bde.org> <499B221C.2050804@samsco.org> <20090218091151.4d9c2bd7@ernst.jennejohn.org> MIME-Version: 1.0 In-Reply-To: <20090218091151.4d9c2bd7@ernst.jennejohn.org> Organization: Universitaet Wuerzburg User-Agent: Mutt/1.5.18 (2008-05-17) X-MIMETrack: Itemize by SMTP Server on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 02/18/2009 12:16:45 PM, Serialize by Router on domino1/uni-wuerzburg(Release 8.0.2HF443 | November 25, 2008) at 02/18/2009 12:16:45 PM, Serialize complete at 02/18/2009 12:16:45 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new at uni-wuerzburg.de Cc: FreeBSD Current Subject: Re: HEADS UP: More CAM fixes. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 11:16:47 -0000 On Wed, Feb 18, 2009 at 09:11:51AM +0100, Gary Jennejohn wrote: > On Tue, 17 Feb 2009 13:46:20 -0700 > Scott Long wrote: > > > Bruce Evans wrote: > > > On Tue, 17 Feb 2009, Gary Jennejohn wrote: > > > > > >> I tested this with an Adaptec 29160. I saw no real improvement in > > >> performance, but also no regressions. > > >> > > >> I suspect that the old disk I had attached just didn't have enough > > >> performance reserves to show an improvement. > > >> > > >> My test scenario was buildworld. Since /usr/src and /usr/obj were both > > >> on the one disk it got a pretty good workout. > > > ^^^^ low > > >> > > >> AMD64 X2 (2.5 GHz) with 4GB of RAM. > > > > > > Buildworld hardly uses the disk at all. It reads and writes a few hundred > > > MB. Ideally the i/o should go at disk speeds of 50-200MB/S and thus take > > > between 20 and 5 seconds. In practice, it will take a few more seconds. > > > physically but perhaps even less virtually due to parallelism. > > > > > > Bruce > > > > Yes, on modern machines, buildworld is bound almost completely by disk > > latency, and not at all by disk or controller bandwidth. > > > > Scott > > > > Maybe I misunderstood something, but I thought the patch was supposed > to improve queuing. Seems like all the seeks during a buildowrld > would exercise that. All I can say is that the disk did _lots_ of > seeking. > I suppose on not extreme multi-core systems (ncores <= 4) buildworld is a good CPU test. For example: time make -j3 TARGET_ARCH=i386 buildworld [building] -------------------------------------------------------------- >>> World build completed on Wed Feb 18 11:59:28 CET 2009 -------------------------------------------------------------- 2163.449u 513.894s 24:17.49 183.6% 6113+2368k 26280+5968io 10602pf+0w ^^^^^^ This is on Core2Duo 3.0GHz with the single 500G WD SATA drive. Pre-caching src directory (with 'tar -cvf /dev/null src', for example) may speed up things by ~10%. Alexey. From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 12:46:53 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AF88106566C for ; Wed, 18 Feb 2009 12:46:53 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 104D58FC08 for ; Wed, 18 Feb 2009 12:46:52 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [172.31.193.10] (cpe-075-177-134-250.nc.res.rr.com [75.177.134.250]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id n1ICkNIL022260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 07:46:23 -0500 (EST) X-DKIM: Sendmail DKIM Filter v2.5.3 duke.cs.duke.edu n1ICkNIL022260 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1234961184; bh=PyRI5LiuIIInu9xTrmFhnDuEed/E0bHnTy1Ec+BhnCM=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type; b=EkSZYWyapwezEHlzXsCX+uUC0/BxIaUcVeuD4z +3uLDuOJIxrJD2DxMH4C6W5G/z2s4rmTL9SOGQ1v4bRmp6c4eht0mce0gdXQ/r2rRJU 4SCvetLVVqAJuR9tUUeiGql7mvrpyn9SkuzahsVca8AbPDomXIn6otHUtoBi2LvZCI= Message-ID: <499C0319.9040100@cs.duke.edu> Date: Wed, 18 Feb 2009 07:46:17 -0500 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: "Paul B. Mahol" References: <20090217142615.A77950@grasshopper.cs.duke.edu> <3a142e750902180256p68ef8fc0nbda773d41d42a7a0@mail.gmail.com> In-Reply-To: <3a142e750902180256p68ef8fc0nbda773d41d42a7a0@mail.gmail.com> Content-Type: multipart/mixed; boundary="------------070105040609080801090900" Cc: current@freebsd.org Subject: Re: r187880 causes fatal trap 30 when unloading drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 12:46:53 -0000 This is a multi-part message in MIME format. --------------070105040609080801090900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Paul B. Mahol wrote: > Fatal trap 30: reserved (unknown) fault while in kernel modecpuid = 1; <...> > The only workaroud is to disable SMP. Try backing out the commit in question and see if that helps. I used the attached patch on yesterday's -current. Drew --------------070105040609080801090900 Content-Type: text/x-diff; name="idt.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="idt.diff" Index: i386/include/apicvar.h =================================================================== --- i386/include/apicvar.h (revision 187880) +++ i386/include/apicvar.h (revision 187879) @@ -187,17 +187,14 @@ IDTVEC(apic_isr7), IDTVEC(spuriousint), IDTVEC(timerint); extern vm_paddr_t lapic_paddr; -extern int apic_cpuids[]; -u_int apic_alloc_vector(u_int apic_id, u_int irq); -u_int apic_alloc_vectors(u_int apic_id, u_int *irqs, u_int count, - u_int align); -void apic_disable_vector(u_int apic_id, u_int vector); -void apic_enable_vector(u_int apic_id, u_int vector); -void apic_free_vector(u_int apic_id, u_int vector, u_int irq); -u_int apic_idt_to_irq(u_int apic_id, u_int vector); +u_int apic_alloc_vector(u_int irq); +u_int apic_alloc_vectors(u_int *irqs, u_int count, u_int align); +void apic_disable_vector(u_int vector); +void apic_enable_vector(u_int vector); +void apic_free_vector(u_int vector, u_int irq); +u_int apic_idt_to_irq(u_int vector); void apic_register_enumerator(struct apic_enumerator *enumerator); -u_int apic_cpuid(u_int apic_id); void *ioapic_create(vm_paddr_t addr, int32_t apic_id, int intbase); int ioapic_disable_pin(void *cookie, u_int pin); int ioapic_get_vector(void *cookie, u_int pin); Index: i386/include/intr_machdep.h =================================================================== --- i386/include/intr_machdep.h (revision 187880) +++ i386/include/intr_machdep.h (revision 187879) @@ -47,7 +47,7 @@ * IRQ values beyond 256 are used by MSI. We leave 255 unused to avoid * confusion since 255 is used in PCI to indicate an invalid IRQ. */ -#define NUM_MSI_INTS 512 +#define NUM_MSI_INTS 128 #define FIRST_MSI_INT 256 #define NUM_IO_INTS (FIRST_MSI_INT + NUM_MSI_INTS) Index: i386/i386/io_apic.c =================================================================== --- i386/i386/io_apic.c (revision 187880) +++ i386/i386/io_apic.c (revision 187879) @@ -327,56 +327,39 @@ { struct ioapic_intsrc *intpin = (struct ioapic_intsrc *)isrc; struct ioapic *io = (struct ioapic *)isrc->is_pic; - u_int old_vector; - u_int old_id; - /* - * keep 1st core as the destination for NMI - */ - if (intpin->io_irq == IRQ_NMI) - apic_id = 0; - - /* - * Set us up to free the old irq. - */ - old_vector = intpin->io_vector; - old_id = intpin->io_cpu; - if (old_vector && apic_id == old_id) - return; - - /* - * Allocate an APIC vector for this interrupt pin. Once - * we have a vector we program the interrupt pin. - */ intpin->io_cpu = apic_id; - intpin->io_vector = apic_alloc_vector(apic_id, intpin->io_irq); if (bootverbose) { - printf("ioapic%u: routing intpin %u (", io->io_id, - intpin->io_intpin); + printf("ioapic%u: Assigning ", io->io_id); ioapic_print_irq(intpin); - printf(") to lapic %u vector %u\n", intpin->io_cpu, - intpin->io_vector); + printf(" to local APIC %u\n", intpin->io_cpu); } ioapic_program_intpin(intpin); - /* - * Free the old vector after the new one is established. This is done - * to prevent races where we could miss an interrupt. - */ - if (old_vector) - apic_free_vector(old_id, old_vector, intpin->io_irq); } static void ioapic_enable_intr(struct intsrc *isrc) { struct ioapic_intsrc *intpin = (struct ioapic_intsrc *)isrc; + struct ioapic *io = (struct ioapic *)isrc->is_pic; - if (intpin->io_vector == 0) - ioapic_assign_cpu(isrc, pcpu_find(0)->pc_apic_id); - apic_enable_vector(intpin->io_cpu, intpin->io_vector); + if (intpin->io_vector == 0) { + /* + * Allocate an APIC vector for this interrupt pin. Once + * we have a vector we program the interrupt pin. + */ + intpin->io_vector = apic_alloc_vector(intpin->io_irq); + if (bootverbose) { + printf("ioapic%u: routing intpin %u (", io->io_id, + intpin->io_intpin); + ioapic_print_irq(intpin); + printf(") to vector %u\n", intpin->io_vector); + } + ioapic_program_intpin(intpin); + apic_enable_vector(intpin->io_vector); + } } - static void ioapic_disable_intr(struct intsrc *isrc) { @@ -386,11 +369,11 @@ if (intpin->io_vector != 0) { /* Mask this interrupt pin and free its APIC vector. */ vector = intpin->io_vector; - apic_disable_vector(intpin->io_cpu, vector); + apic_disable_vector(vector); intpin->io_masked = 1; intpin->io_vector = 0; ioapic_program_intpin(intpin); - apic_free_vector(intpin->io_cpu, vector, intpin->io_irq); + apic_free_vector(vector, intpin->io_irq); } } Index: i386/i386/mp_machdep.c =================================================================== --- i386/i386/mp_machdep.c (revision 187880) +++ i386/i386/mp_machdep.c (revision 187879) @@ -206,7 +206,6 @@ int cpu_disabled:1; } static cpu_info[MAX_APIC_ID + 1]; int cpu_apic_ids[MAXCPU]; -int apic_cpuids[MAX_APIC_ID + 1]; /* Holds pending bitmap based IPIs per CPU */ static volatile u_int cpu_ipi_pending[MAXCPU]; @@ -398,7 +397,6 @@ KASSERT(boot_cpu_id == PCPU_GET(apic_id), ("BSP's APIC ID doesn't match boot_cpu_id")); cpu_apic_ids[0] = boot_cpu_id; - apic_cpuids[boot_cpu_id] = 0; assign_cpu_ids(); @@ -707,7 +705,6 @@ if (mp_ncpus < MAXCPU) { cpu_apic_ids[mp_ncpus] = i; - apic_cpuids[i] = mp_ncpus; mp_ncpus++; } else cpu_info[i].cpu_disabled = 1; Index: i386/i386/local_apic.c =================================================================== --- i386/i386/local_apic.c (revision 187880) +++ i386/i386/local_apic.c (revision 187879) @@ -46,8 +46,6 @@ #include #include #include -#include -#include #include #include @@ -111,8 +109,6 @@ u_long la_hard_ticks; u_long la_stat_ticks; u_long la_prof_ticks; - /* Include IDT_SYSCALL to make indexing easier. */ - u_int la_ioint_irqs[APIC_NUM_IOINTS + 1]; } static lapics[MAX_APIC_ID + 1]; /* XXX: should thermal be an NMI? */ @@ -138,6 +134,8 @@ IDTVEC(apic_isr7), /* 224 - 255 */ }; +/* Include IDT_SYSCALL to make indexing easier. */ +static u_int ioint_irqs[APIC_NUM_IOINTS + 1]; static u_int32_t lapic_timer_divisors[] = { APIC_TDCR_1, APIC_TDCR_2, APIC_TDCR_4, APIC_TDCR_8, APIC_TDCR_16, @@ -218,6 +216,7 @@ /* Perform basic initialization of the BSP's local APIC. */ lapic_enable(); + ioint_irqs[IDT_SYSCALL - APIC_IO_INTS] = IRQ_SYSCALL; /* Set BSP's per-CPU local APIC ID. */ PCPU_SET(apic_id, lapic_id()); @@ -225,6 +224,7 @@ /* Local APIC timer interrupt. */ setidt(APIC_TIMER_INT, IDTVEC(timerint), SDT_SYS386IGT, SEL_KPL, GSEL(GCODE_SEL, SEL_KPL)); + ioint_irqs[APIC_TIMER_INT - APIC_IO_INTS] = IRQ_TIMER; /* XXX: error/thermal interrupts */ } @@ -256,9 +256,6 @@ lapics[apic_id].la_lvts[i] = lvts[i]; lapics[apic_id].la_lvts[i].lvt_active = 0; } - lapics[apic_id].la_ioint_irqs[IDT_SYSCALL - APIC_IO_INTS] = IRQ_SYSCALL; - lapics[apic_id].la_ioint_irqs[APIC_TIMER_INT - APIC_IO_INTS] = - IRQ_TIMER; #ifdef SMP cpu_add(apic_id, boot_cpu); @@ -669,8 +666,7 @@ if (vector == -1) panic("Couldn't get vector from ISR!"); - isrc = intr_lookup_source(apic_idt_to_irq(PCPU_GET(apic_id), - vector)); + isrc = intr_lookup_source(apic_idt_to_irq(vector)); intr_execute_handlers(isrc, frame); } @@ -785,19 +781,9 @@ lapic->lvt_timer = value; } -u_int -apic_cpuid(u_int apic_id) -{ -#ifdef SMP - return apic_cpuids[apic_id]; -#else - return 0; -#endif -} - /* Request a free IDT vector to be used by the specified IRQ. */ u_int -apic_alloc_vector(u_int apic_id, u_int irq) +apic_alloc_vector(u_int irq) { u_int vector; @@ -809,9 +795,9 @@ */ mtx_lock_spin(&icu_lock); for (vector = 0; vector < APIC_NUM_IOINTS; vector++) { - if (lapics[apic_id].la_ioint_irqs[vector] != 0) + if (ioint_irqs[vector] != 0) continue; - lapics[apic_id].la_ioint_irqs[vector] = irq; + ioint_irqs[vector] = irq; mtx_unlock_spin(&icu_lock); return (vector + APIC_IO_INTS); } @@ -826,7 +812,7 @@ * satisfied, 0 is returned. */ u_int -apic_alloc_vectors(u_int apic_id, u_int *irqs, u_int count, u_int align) +apic_alloc_vectors(u_int *irqs, u_int count, u_int align) { u_int first, run, vector; @@ -849,7 +835,7 @@ for (vector = 0; vector < APIC_NUM_IOINTS; vector++) { /* Vector is in use, end run. */ - if (lapics[apic_id].la_ioint_irqs[vector] != 0) { + if (ioint_irqs[vector] != 0) { run = 0; first = 0; continue; @@ -869,8 +855,7 @@ /* Found a run, assign IRQs and return the first vector. */ for (vector = 0; vector < count; vector++) - lapics[apic_id].la_ioint_irqs[first + vector] = - irqs[vector]; + ioint_irqs[first + vector] = irqs[vector]; mtx_unlock_spin(&icu_lock); return (first + APIC_IO_INTS); } @@ -879,14 +864,8 @@ return (0); } -/* - * Enable a vector for a particular apic_id. Since all lapics share idt - * entries and ioint_handlers this enables the vector on all lapics. lapics - * which do not have the vector configured would report spurious interrupts - * should it fire. - */ void -apic_enable_vector(u_int apic_id, u_int vector) +apic_enable_vector(u_int vector) { KASSERT(vector != IDT_SYSCALL, ("Attempt to overwrite syscall entry")); @@ -897,7 +876,7 @@ } void -apic_disable_vector(u_int apic_id, u_int vector) +apic_disable_vector(u_int vector) { KASSERT(vector != IDT_SYSCALL, ("Attempt to overwrite syscall entry")); @@ -909,42 +888,27 @@ /* Release an APIC vector when it's no longer in use. */ void -apic_free_vector(u_int apic_id, u_int vector, u_int irq) +apic_free_vector(u_int vector, u_int irq) { - struct thread *td; KASSERT(vector >= APIC_IO_INTS && vector != IDT_SYSCALL && vector <= APIC_IO_INTS + APIC_NUM_IOINTS, ("Vector %u does not map to an IRQ line", vector)); KASSERT(irq < NUM_IO_INTS, ("Invalid IRQ %u", irq)); - KASSERT(lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS] == - irq, ("IRQ mismatch")); - - /* - * Bind us to the cpu that owned the vector before freeing it so - * we don't lose an interrupt delivery race. - */ - td = curthread; - thread_lock(td); - if (sched_is_bound(td)) - panic("apic_free_vector: Thread already bound.\n"); - sched_bind(td, apic_cpuid(apic_id)); + KASSERT(ioint_irqs[vector - APIC_IO_INTS] == irq, ("IRQ mismatch")); mtx_lock_spin(&icu_lock); - lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS] = 0; + ioint_irqs[vector - APIC_IO_INTS] = 0; mtx_unlock_spin(&icu_lock); - sched_unbind(td); - thread_unlock(td); - } /* Map an IDT vector (APIC) to an IRQ (interrupt source). */ u_int -apic_idt_to_irq(u_int apic_id, u_int vector) +apic_idt_to_irq(u_int vector) { KASSERT(vector >= APIC_IO_INTS && vector != IDT_SYSCALL && vector <= APIC_IO_INTS + APIC_NUM_IOINTS, ("Vector %u does not map to an IRQ line", vector)); - return (lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS]); + return (ioint_irqs[vector - APIC_IO_INTS]); } #ifdef DDB @@ -955,7 +919,6 @@ { struct intsrc *isrc; int i, verbose; - u_int apic_id; u_int irq; if (strcmp(modif, "vv") == 0) @@ -964,14 +927,9 @@ verbose = 1; else verbose = 0; - for (apic_id = 0; apic_id <= MAX_APIC_ID; apic_id++) { - if (lapics[apic_id].la_present == 0) - continue; - db_printf("Interrupts bound to lapic %u\n", apic_id); - for (i = 0; i < APIC_NUM_IOINTS + 1 && !db_pager_quit; i++) { - irq = lapics[apic_id].la_ioint_irqs[i]; - if (irq == 0 || irq == IRQ_SYSCALL) - continue; + for (i = 0; i < APIC_NUM_IOINTS + 1 && !db_pager_quit; i++) { + irq = ioint_irqs[i]; + if (irq != 0 && irq != IRQ_SYSCALL) { db_printf("vec 0x%2x -> ", i + APIC_IO_INTS); if (irq == IRQ_TIMER) db_printf("lapic timer\n"); Index: i386/i386/msi.c =================================================================== --- i386/i386/msi.c (revision 187880) +++ i386/i386/msi.c (revision 187879) @@ -161,9 +161,7 @@ { struct msi_intsrc *msi = (struct msi_intsrc *)isrc; - if (msi->msi_vector == 0) - msi_assign_cpu(isrc, 0); - apic_enable_vector(msi->msi_cpu, msi->msi_vector); + apic_enable_vector(msi->msi_vector); } static void @@ -171,7 +169,7 @@ { struct msi_intsrc *msi = (struct msi_intsrc *)isrc; - apic_disable_vector(msi->msi_cpu, msi->msi_vector); + apic_disable_vector(msi->msi_vector); } static int @@ -201,35 +199,15 @@ msi_assign_cpu(struct intsrc *isrc, u_int apic_id) { struct msi_intsrc *msi = (struct msi_intsrc *)isrc; - int old_vector; - u_int old_id; - int vector; - /* Store information to free existing irq. */ - old_vector = msi->msi_vector; - old_id = msi->msi_cpu; - if (old_vector && old_id == apic_id) - return; - /* Allocate IDT vector on this cpu. */ - vector = apic_alloc_vector(apic_id, msi->msi_irq); - if (vector == 0) - return; /* XXX alloc_vector panics on failure. */ msi->msi_cpu = apic_id; - msi->msi_vector = vector; if (bootverbose) - printf("msi: Assigning %s IRQ %d to local APIC %u vector %u\n", + printf("msi: Assigning %s IRQ %d to local APIC %u\n", msi->msi_msix ? "MSI-X" : "MSI", msi->msi_irq, - msi->msi_cpu, msi->msi_vector); + msi->msi_cpu); pci_remap_msi_irq(msi->msi_dev, msi->msi_irq); - /* - * Free the old vector after the new one is established. This is done - * to prevent races where we could miss an interrupt. - */ - if (old_vector) - apic_free_vector(old_id, old_vector, msi->msi_irq); } - void msi_init(void) { @@ -285,7 +263,7 @@ msi_alloc(device_t dev, int count, int maxcount, int *irqs) { struct msi_intsrc *msi, *fsrc; - int cnt, i; + int cnt, i, vector; if (!msi_enabled) return (ENXIO); @@ -331,12 +309,22 @@ /* Ok, we now have the IRQs allocated. */ KASSERT(cnt == count, ("count mismatch")); + /* Allocate 'count' IDT vectors. */ + vector = apic_alloc_vectors(irqs, count, maxcount); + if (vector == 0) { + mtx_unlock(&msi_lock); + return (ENOSPC); + } + /* Assign IDT vectors and make these messages owned by 'dev'. */ fsrc = (struct msi_intsrc *)intr_lookup_source(irqs[0]); for (i = 0; i < count; i++) { msi = (struct msi_intsrc *)intr_lookup_source(irqs[i]); msi->msi_dev = dev; - msi->msi_vector = 0; + msi->msi_vector = vector + i; + if (bootverbose) + printf("msi: routing MSI IRQ %d to vector %u\n", + msi->msi_irq, msi->msi_vector); msi->msi_first = fsrc; KASSERT(msi->msi_intsrc.is_handlers == 0, ("dead MSI has handlers")); @@ -389,18 +377,14 @@ KASSERT(msi->msi_dev == first->msi_dev, ("owner mismatch")); msi->msi_first = NULL; msi->msi_dev = NULL; - if (msi->msi_vector) - apic_free_vector(msi->msi_cpu, msi->msi_vector, - msi->msi_irq); + apic_free_vector(msi->msi_vector, msi->msi_irq); msi->msi_vector = 0; } /* Clear out the first message. */ first->msi_first = NULL; first->msi_dev = NULL; - if (first->msi_vector) - apic_free_vector(first->msi_cpu, first->msi_vector, - first->msi_irq); + apic_free_vector(first->msi_vector, first->msi_irq); first->msi_vector = 0; first->msi_count = 0; @@ -449,7 +433,7 @@ msix_alloc(device_t dev, int *irq) { struct msi_intsrc *msi; - int i; + int i, vector; if (!msi_enabled) return (ENXIO); @@ -484,9 +468,15 @@ goto again; } + /* Allocate an IDT vector. */ + vector = apic_alloc_vector(i); + if (bootverbose) + printf("msi: routing MSI-X IRQ %d to vector %u\n", msi->msi_irq, + vector); + /* Setup source. */ msi->msi_dev = dev; - msi->msi_vector = 0; + msi->msi_vector = vector; msi->msi_msix = 1; KASSERT(msi->msi_intsrc.is_handlers == 0, ("dead MSI-X has handlers")); @@ -518,8 +508,7 @@ /* Clear out the message. */ msi->msi_dev = NULL; - if (msi->msi_vector) - apic_free_vector(msi->msi_cpu, msi->msi_vector, msi->msi_irq); + apic_free_vector(msi->msi_vector, msi->msi_irq); msi->msi_vector = 0; msi->msi_msix = 0; Index: amd64/include/apicvar.h =================================================================== --- amd64/include/apicvar.h (revision 187880) +++ amd64/include/apicvar.h (revision 187879) @@ -176,17 +176,14 @@ IDTVEC(apic_isr7), IDTVEC(spuriousint), IDTVEC(timerint); extern vm_paddr_t lapic_paddr; -extern int apic_cpuids[]; -u_int apic_alloc_vector(u_int apic_id, u_int irq); -u_int apic_alloc_vectors(u_int apic_id, u_int *irqs, u_int count, - u_int align); -void apic_disable_vector(u_int apic_id, u_int vector); -void apic_enable_vector(u_int apic_id, u_int vector); -void apic_free_vector(u_int apic_id, u_int vector, u_int irq); -u_int apic_idt_to_irq(u_int apic_id, u_int vector); +u_int apic_alloc_vector(u_int irq); +u_int apic_alloc_vectors(u_int *irqs, u_int count, u_int align); +void apic_disable_vector(u_int vector); +void apic_enable_vector(u_int vector); +void apic_free_vector(u_int vector, u_int irq); +u_int apic_idt_to_irq(u_int vector); void apic_register_enumerator(struct apic_enumerator *enumerator); -u_int apic_cpuid(u_int apic_id); void *ioapic_create(vm_paddr_t addr, int32_t apic_id, int intbase); int ioapic_disable_pin(void *cookie, u_int pin); int ioapic_get_vector(void *cookie, u_int pin); Index: amd64/include/intr_machdep.h =================================================================== --- amd64/include/intr_machdep.h (revision 187880) +++ amd64/include/intr_machdep.h (revision 187879) @@ -47,7 +47,7 @@ * IRQ values beyond 256 are used by MSI. We leave 255 unused to avoid * confusion since 255 is used in PCI to indicate an invalid IRQ. */ -#define NUM_MSI_INTS 512 +#define NUM_MSI_INTS 128 #define FIRST_MSI_INT 256 #define NUM_IO_INTS (FIRST_MSI_INT + NUM_MSI_INTS) Index: amd64/amd64/io_apic.c =================================================================== --- amd64/amd64/io_apic.c (revision 187880) +++ amd64/amd64/io_apic.c (revision 187879) @@ -327,56 +327,39 @@ { struct ioapic_intsrc *intpin = (struct ioapic_intsrc *)isrc; struct ioapic *io = (struct ioapic *)isrc->is_pic; - u_int old_vector; - u_int old_id; - /* - * keep 1st core as the destination for NMI - */ - if (intpin->io_irq == IRQ_NMI) - apic_id = 0; - - /* - * Set us up to free the old irq. - */ - old_vector = intpin->io_vector; - old_id = intpin->io_cpu; - if (old_vector && apic_id == old_id) - return; - - /* - * Allocate an APIC vector for this interrupt pin. Once - * we have a vector we program the interrupt pin. - */ intpin->io_cpu = apic_id; - intpin->io_vector = apic_alloc_vector(apic_id, intpin->io_irq); if (bootverbose) { - printf("ioapic%u: routing intpin %u (", io->io_id, - intpin->io_intpin); + printf("ioapic%u: Assigning ", io->io_id); ioapic_print_irq(intpin); - printf(") to lapic %u vector %u\n", intpin->io_cpu, - intpin->io_vector); + printf(" to local APIC %u\n", intpin->io_cpu); } ioapic_program_intpin(intpin); - /* - * Free the old vector after the new one is established. This is done - * to prevent races where we could miss an interrupt. - */ - if (old_vector) - apic_free_vector(old_id, old_vector, intpin->io_irq); } static void ioapic_enable_intr(struct intsrc *isrc) { struct ioapic_intsrc *intpin = (struct ioapic_intsrc *)isrc; + struct ioapic *io = (struct ioapic *)isrc->is_pic; - if (intpin->io_vector == 0) - ioapic_assign_cpu(isrc, pcpu_find(0)->pc_apic_id); - apic_enable_vector(intpin->io_cpu, intpin->io_vector); + if (intpin->io_vector == 0) { + /* + * Allocate an APIC vector for this interrupt pin. Once + * we have a vector we program the interrupt pin. + */ + intpin->io_vector = apic_alloc_vector(intpin->io_irq); + if (bootverbose) { + printf("ioapic%u: routing intpin %u (", io->io_id, + intpin->io_intpin); + ioapic_print_irq(intpin); + printf(") to vector %u\n", intpin->io_vector); + } + ioapic_program_intpin(intpin); + apic_enable_vector(intpin->io_vector); + } } - static void ioapic_disable_intr(struct intsrc *isrc) { @@ -386,11 +369,11 @@ if (intpin->io_vector != 0) { /* Mask this interrupt pin and free its APIC vector. */ vector = intpin->io_vector; - apic_disable_vector(intpin->io_cpu, vector); + apic_disable_vector(vector); intpin->io_masked = 1; intpin->io_vector = 0; ioapic_program_intpin(intpin); - apic_free_vector(intpin->io_cpu, vector, intpin->io_irq); + apic_free_vector(vector, intpin->io_irq); } } Index: amd64/amd64/mp_machdep.c =================================================================== --- amd64/amd64/mp_machdep.c (revision 187880) +++ amd64/amd64/mp_machdep.c (revision 187879) @@ -152,7 +152,6 @@ int cpu_disabled:1; } static cpu_info[MAX_APIC_ID + 1]; int cpu_apic_ids[MAXCPU]; -int apic_cpuids[MAX_APIC_ID + 1]; /* Holds pending bitmap based IPIs per CPU */ static volatile u_int cpu_ipi_pending[MAXCPU]; @@ -350,7 +349,6 @@ KASSERT(boot_cpu_id == PCPU_GET(apic_id), ("BSP's APIC ID doesn't match boot_cpu_id")); cpu_apic_ids[0] = boot_cpu_id; - apic_cpuids[boot_cpu_id] = 0; assign_cpu_ids(); @@ -658,7 +656,6 @@ if (mp_ncpus < MAXCPU) { cpu_apic_ids[mp_ncpus] = i; - apic_cpuids[i] = mp_ncpus; mp_ncpus++; } else cpu_info[i].cpu_disabled = 1; Index: amd64/amd64/local_apic.c =================================================================== --- amd64/amd64/local_apic.c (revision 187880) +++ amd64/amd64/local_apic.c (revision 187879) @@ -46,8 +46,6 @@ #include #include #include -#include -#include #include #include @@ -111,8 +109,6 @@ u_long la_hard_ticks; u_long la_stat_ticks; u_long la_prof_ticks; - /* Include IDT_SYSCALL to make indexing easier. */ - u_int la_ioint_irqs[APIC_NUM_IOINTS + 1]; } static lapics[MAX_APIC_ID + 1]; /* XXX: should thermal be an NMI? */ @@ -138,6 +134,8 @@ IDTVEC(apic_isr7), /* 224 - 255 */ }; +/* Include IDT_SYSCALL to make indexing easier. */ +static u_int ioint_irqs[APIC_NUM_IOINTS + 1]; static u_int32_t lapic_timer_divisors[] = { APIC_TDCR_1, APIC_TDCR_2, APIC_TDCR_4, APIC_TDCR_8, APIC_TDCR_16, @@ -217,12 +215,14 @@ /* Perform basic initialization of the BSP's local APIC. */ lapic_enable(); + ioint_irqs[IDT_SYSCALL - APIC_IO_INTS] = IRQ_SYSCALL; /* Set BSP's per-CPU local APIC ID. */ PCPU_SET(apic_id, lapic_id()); /* Local APIC timer interrupt. */ setidt(APIC_TIMER_INT, IDTVEC(timerint), SDT_SYSIGT, SEL_KPL, 0); + ioint_irqs[APIC_TIMER_INT - APIC_IO_INTS] = IRQ_TIMER; /* XXX: error/thermal interrupts */ } @@ -254,9 +254,6 @@ lapics[apic_id].la_lvts[i] = lvts[i]; lapics[apic_id].la_lvts[i].lvt_active = 0; } - lapics[apic_id].la_ioint_irqs[IDT_SYSCALL - APIC_IO_INTS] = IRQ_SYSCALL; - lapics[apic_id].la_ioint_irqs[APIC_TIMER_INT - APIC_IO_INTS] = - IRQ_TIMER; #ifdef SMP cpu_add(apic_id, boot_cpu); @@ -667,8 +664,7 @@ if (vector == -1) panic("Couldn't get vector from ISR!"); - isrc = intr_lookup_source(apic_idt_to_irq(PCPU_GET(apic_id), - vector)); + isrc = intr_lookup_source(apic_idt_to_irq(vector)); intr_execute_handlers(isrc, frame); } @@ -783,19 +779,9 @@ lapic->lvt_timer = value; } -u_int -apic_cpuid(u_int apic_id) -{ -#ifdef SMP - return apic_cpuids[apic_id]; -#else - return 0; -#endif -} - /* Request a free IDT vector to be used by the specified IRQ. */ u_int -apic_alloc_vector(u_int apic_id, u_int irq) +apic_alloc_vector(u_int irq) { u_int vector; @@ -807,9 +793,9 @@ */ mtx_lock_spin(&icu_lock); for (vector = 0; vector < APIC_NUM_IOINTS; vector++) { - if (lapics[apic_id].la_ioint_irqs[vector] != 0) + if (ioint_irqs[vector] != 0) continue; - lapics[apic_id].la_ioint_irqs[vector] = irq; + ioint_irqs[vector] = irq; mtx_unlock_spin(&icu_lock); return (vector + APIC_IO_INTS); } @@ -824,7 +810,7 @@ * satisfied, 0 is returned. */ u_int -apic_alloc_vectors(u_int apic_id, u_int *irqs, u_int count, u_int align) +apic_alloc_vectors(u_int *irqs, u_int count, u_int align) { u_int first, run, vector; @@ -847,7 +833,7 @@ for (vector = 0; vector < APIC_NUM_IOINTS; vector++) { /* Vector is in use, end run. */ - if (lapics[apic_id].la_ioint_irqs[vector] != 0) { + if (ioint_irqs[vector] != 0) { run = 0; first = 0; continue; @@ -867,8 +853,7 @@ /* Found a run, assign IRQs and return the first vector. */ for (vector = 0; vector < count; vector++) - lapics[apic_id].la_ioint_irqs[first + vector] = - irqs[vector]; + ioint_irqs[first + vector] = irqs[vector]; mtx_unlock_spin(&icu_lock); return (first + APIC_IO_INTS); } @@ -877,14 +862,8 @@ return (0); } -/* - * Enable a vector for a particular apic_id. Since all lapics share idt - * entries and ioint_handlers this enables the vector on all lapics. lapics - * which do not have the vector configured would report spurious interrupts - * should it fire. - */ void -apic_enable_vector(u_int apic_id, u_int vector) +apic_enable_vector(u_int vector) { KASSERT(vector != IDT_SYSCALL, ("Attempt to overwrite syscall entry")); @@ -894,7 +873,7 @@ } void -apic_disable_vector(u_int apic_id, u_int vector) +apic_disable_vector(u_int vector) { KASSERT(vector != IDT_SYSCALL, ("Attempt to overwrite syscall entry")); @@ -905,42 +884,27 @@ /* Release an APIC vector when it's no longer in use. */ void -apic_free_vector(u_int apic_id, u_int vector, u_int irq) +apic_free_vector(u_int vector, u_int irq) { - struct thread *td; KASSERT(vector >= APIC_IO_INTS && vector != IDT_SYSCALL && vector <= APIC_IO_INTS + APIC_NUM_IOINTS, ("Vector %u does not map to an IRQ line", vector)); KASSERT(irq < NUM_IO_INTS, ("Invalid IRQ %u", irq)); - KASSERT(lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS] == - irq, ("IRQ mismatch")); - - /* - * Bind us to the cpu that owned the vector before freeing it so - * we don't lose an interrupt delivery race. - */ - td = curthread; - thread_lock(td); - if (sched_is_bound(td)) - panic("apic_free_vector: Thread already bound.\n"); - sched_bind(td, apic_cpuid(apic_id)); + KASSERT(ioint_irqs[vector - APIC_IO_INTS] == irq, ("IRQ mismatch")); mtx_lock_spin(&icu_lock); - lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS] = 0; + ioint_irqs[vector - APIC_IO_INTS] = 0; mtx_unlock_spin(&icu_lock); - sched_unbind(td); - thread_unlock(td); - } /* Map an IDT vector (APIC) to an IRQ (interrupt source). */ u_int -apic_idt_to_irq(u_int apic_id, u_int vector) +apic_idt_to_irq(u_int vector) { KASSERT(vector >= APIC_IO_INTS && vector != IDT_SYSCALL && vector <= APIC_IO_INTS + APIC_NUM_IOINTS, ("Vector %u does not map to an IRQ line", vector)); - return (lapics[apic_id].la_ioint_irqs[vector - APIC_IO_INTS]); + return (ioint_irqs[vector - APIC_IO_INTS]); } #ifdef DDB @@ -951,7 +915,6 @@ { struct intsrc *isrc; int i, verbose; - u_int apic_id; u_int irq; if (strcmp(modif, "vv") == 0) @@ -960,14 +923,9 @@ verbose = 1; else verbose = 0; - for (apic_id = 0; apic_id <= MAX_APIC_ID; apic_id++) { - if (lapics[apic_id].la_present == 0) - continue; - db_printf("Interrupts bound to lapic %u\n", apic_id); - for (i = 0; i < APIC_NUM_IOINTS + 1 && !db_pager_quit; i++) { - irq = lapics[apic_id].la_ioint_irqs[i]; - if (irq == 0 || irq == IRQ_SYSCALL) - continue; + for (i = 0; i < APIC_NUM_IOINTS + 1 && !db_pager_quit; i++) { + irq = ioint_irqs[i]; + if (irq != 0 && irq != IRQ_SYSCALL) { db_printf("vec 0x%2x -> ", i + APIC_IO_INTS); if (irq == IRQ_TIMER) db_printf("lapic timer\n"); Index: amd64/amd64/msi.c =================================================================== --- amd64/amd64/msi.c (revision 187880) +++ amd64/amd64/msi.c (revision 187879) @@ -161,9 +161,7 @@ { struct msi_intsrc *msi = (struct msi_intsrc *)isrc; - if (msi->msi_vector == 0) - msi_assign_cpu(isrc, 0); - apic_enable_vector(msi->msi_cpu, msi->msi_vector); + apic_enable_vector(msi->msi_vector); } static void @@ -171,7 +169,7 @@ { struct msi_intsrc *msi = (struct msi_intsrc *)isrc; - apic_disable_vector(msi->msi_cpu, msi->msi_vector); + apic_disable_vector(msi->msi_vector); } static int @@ -201,35 +199,15 @@ msi_assign_cpu(struct intsrc *isrc, u_int apic_id) { struct msi_intsrc *msi = (struct msi_intsrc *)isrc; - int old_vector; - u_int old_id; - int vector; - /* Store information to free existing irq. */ - old_vector = msi->msi_vector; - old_id = msi->msi_cpu; - if (old_vector && old_id == apic_id) - return; - /* Allocate IDT vector on this cpu. */ - vector = apic_alloc_vector(apic_id, msi->msi_irq); - if (vector == 0) - return; /* XXX alloc_vector panics on failure. */ msi->msi_cpu = apic_id; - msi->msi_vector = vector; if (bootverbose) - printf("msi: Assigning %s IRQ %d to local APIC %u vector %u\n", + printf("msi: Assigning %s IRQ %d to local APIC %u\n", msi->msi_msix ? "MSI-X" : "MSI", msi->msi_irq, - msi->msi_cpu, msi->msi_vector); + msi->msi_cpu); pci_remap_msi_irq(msi->msi_dev, msi->msi_irq); - /* - * Free the old vector after the new one is established. This is done - * to prevent races where we could miss an interrupt. - */ - if (old_vector) - apic_free_vector(old_id, old_vector, msi->msi_irq); } - void msi_init(void) { @@ -285,7 +263,7 @@ msi_alloc(device_t dev, int count, int maxcount, int *irqs) { struct msi_intsrc *msi, *fsrc; - int cnt, i; + int cnt, i, vector; if (!msi_enabled) return (ENXIO); @@ -331,12 +309,22 @@ /* Ok, we now have the IRQs allocated. */ KASSERT(cnt == count, ("count mismatch")); + /* Allocate 'count' IDT vectors. */ + vector = apic_alloc_vectors(irqs, count, maxcount); + if (vector == 0) { + mtx_unlock(&msi_lock); + return (ENOSPC); + } + /* Assign IDT vectors and make these messages owned by 'dev'. */ fsrc = (struct msi_intsrc *)intr_lookup_source(irqs[0]); for (i = 0; i < count; i++) { msi = (struct msi_intsrc *)intr_lookup_source(irqs[i]); msi->msi_dev = dev; - msi->msi_vector = 0; + msi->msi_vector = vector + i; + if (bootverbose) + printf("msi: routing MSI IRQ %d to vector %u\n", + msi->msi_irq, msi->msi_vector); msi->msi_first = fsrc; KASSERT(msi->msi_intsrc.is_handlers == 0, ("dead MSI has handlers")); @@ -389,18 +377,14 @@ KASSERT(msi->msi_dev == first->msi_dev, ("owner mismatch")); msi->msi_first = NULL; msi->msi_dev = NULL; - if (msi->msi_vector) - apic_free_vector(msi->msi_cpu, msi->msi_vector, - msi->msi_irq); + apic_free_vector(msi->msi_vector, msi->msi_irq); msi->msi_vector = 0; } /* Clear out the first message. */ first->msi_first = NULL; first->msi_dev = NULL; - if (first->msi_vector) - apic_free_vector(first->msi_cpu, first->msi_vector, - first->msi_irq); + apic_free_vector(first->msi_vector, first->msi_irq); first->msi_vector = 0; first->msi_count = 0; @@ -449,7 +433,7 @@ msix_alloc(device_t dev, int *irq) { struct msi_intsrc *msi; - int i; + int i, vector; if (!msi_enabled) return (ENXIO); @@ -484,9 +468,15 @@ goto again; } + /* Allocate an IDT vector. */ + vector = apic_alloc_vector(i); + if (bootverbose) + printf("msi: routing MSI-X IRQ %d to vector %u\n", msi->msi_irq, + vector); + /* Setup source. */ msi->msi_dev = dev; - msi->msi_vector = 0; + msi->msi_vector = vector; msi->msi_msix = 1; KASSERT(msi->msi_intsrc.is_handlers == 0, ("dead MSI-X has handlers")); @@ -518,8 +508,7 @@ /* Clear out the message. */ msi->msi_dev = NULL; - if (msi->msi_vector) - apic_free_vector(msi->msi_cpu, msi->msi_vector, msi->msi_irq); + apic_free_vector(msi->msi_vector, msi->msi_irq); msi->msi_vector = 0; msi->msi_msix = 0; --------------070105040609080801090900-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 12:49:16 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9447106566B; Wed, 18 Feb 2009 12:49:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id BE4B48FC16; Wed, 18 Feb 2009 12:49:16 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1ICnEUm003710; Wed, 18 Feb 2009 07:49:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1ICnEmS040353; Wed, 18 Feb 2009 07:49:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EF54F7302F; Wed, 18 Feb 2009 07:49:13 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090218124913.EF54F7302F@freebsd-current.sentex.ca> Date: Wed, 18 Feb 2009 07:49:13 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 12:49:17 -0000 TB --- 2009-02-18 11:47:46 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-18 11:47:46 - starting HEAD tinderbox run for mips/mips TB --- 2009-02-18 11:47:46 - cleaning the object tree TB --- 2009-02-18 11:47:57 - cvsupping the source tree TB --- 2009-02-18 11:47:57 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-02-18 11:48:05 - building world TB --- 2009-02-18 11:48:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-18 11:48:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-18 11:48:05 - TARGET=mips TB --- 2009-02-18 11:48:05 - TARGET_ARCH=mips TB --- 2009-02-18 11:48:05 - TZ=UTC TB --- 2009-02-18 11:48:05 - __MAKE_CONF=/dev/null TB --- 2009-02-18 11:48:05 - cd /src TB --- 2009-02-18 11:48:05 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 18 11:48:06 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -fpic -DPIC -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -DNDEBUG -I/src/usr.sbin/bsnmpd/modules/snmp_hostres/../../../lpr/common_source -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c hostres_tree.c -o hostres_tree.So building shared library snmp_hostres.so.5 sed -e 's%@MODPATH@%/usr/lib/%g' -e 's%@DEFPATH@%/usr/share/snmp/defs/%g' -e 's%@MIBSPATH@%/usr/share/snmp/mibs/%g' < /src/usr.sbin/bsnmpd/modules/snmp_hostres/snmp_hostres.3 | gzip -cn > snmp_hostres.3.gz ===> usr.sbin/bsnmpd/modules/snmp_mibII (all) cc -fpic -DPIC -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -I/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/lib -I/src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmpd -DHAVE_ERR_H -DHAVE_GETADDRINFO -DHAVE_STRLCPY -DHAVE_SYS_TREE_H -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wno-pointer-sign -c /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c -o mibII.So cc1: warnings being treated as errors /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c: In function 'handle_rtmsg': /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/bsnmpd/modules/snmp_mibII. *** Error code 1 Stop in /src/usr.sbin/bsnmpd/modules. *** Error code 1 Stop in /src/usr.sbin/bsnmpd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-18 12:49:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-18 12:49:13 - ERROR: failed to build world TB --- 2009-02-18 12:49:13 - 2882.20 user 323.10 system 3687.23 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 13:37:58 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 715C91065676 for ; Wed, 18 Feb 2009 13:37:58 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 300F38FC19 for ; Wed, 18 Feb 2009 13:37:57 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 3FF5DFF2D; Thu, 19 Feb 2009 02:37:57 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORT+TaSOBD0J; Thu, 19 Feb 2009 02:37:51 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Thu, 19 Feb 2009 02:37:51 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id A7AA11142A; Thu, 19 Feb 2009 02:37:50 +1300 (NZDT) Date: Wed, 18 Feb 2009 05:37:50 -0800 From: Andrew Thompson To: Hans Petter Selasky Message-ID: <20090218133750.GA57935@citylink.fud.org.nz> References: <1234936904.17001.108.camel@shumai.marcuscom.com> <200902180812.06702.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200902180812.06702.hselasky@c2i.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-current@freebsd.org, Joe Marcus Clarke Subject: Re: HEADS UP: usb2 support for hal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 13:37:58 -0000 On Wed, Feb 18, 2009 at 08:12:06AM +0100, Hans Petter Selasky wrote: > On Wednesday 18 February 2009, Joe Marcus Clarke wrote: > > I've completed working (at least for me) usb2 support for hal. I've > > also fixed some hal bugs along the way. Before I commit this, please > > try this out. I don't have a lot of hardware, but I was able to test > > umass drive mounting in GNOME. If you have problems, refer to the HAL > > FAQ at http://www.freebsd.org/gnome/docs/halfaq.html before reporting > > them. > > > > http://www.marcuscom.com/downloads/hal_usb2.diff > > > > Joe > > The new functions in libusb20 required by HAL has not yet been committed > to -current. I will see about getting it in soon. Yea they have :) Andrew From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 15:22:20 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51C111065672; Wed, 18 Feb 2009 15:22:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E81398FC23; Wed, 18 Feb 2009 15:22:19 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n1IFKsnu056598; Wed, 18 Feb 2009 08:20:55 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 18 Feb 2009 08:21:03 -0700 (MST) Message-Id: <20090218.082103.-761055997.imp@bsdimp.com> To: andrew-freebsd@areilly.bpc-users.org From: "M. Warner Losh" In-Reply-To: <20090218110402.GA13040@duncan.reilly.home> References: <20090217.203647.-1518647466.imp@bsdimp.com> <20090217.222152.-109416210.imp@bsdimp.com> <20090218110402.GA13040@duncan.reilly.home> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 15:22:21 -0000 In message: <20090218110402.GA13040@duncan.reilly.home> Andrew Reilly writes: : On Tue, Feb 17, 2009 at 10:21:52PM -0700, M. Warner Losh wrote: : > In message: <20090217.203647.-1518647466.imp@bsdimp.com> : > "M. Warner Losh" writes: : > : In message: <20090218023328.227617302F@freebsd-current.sentex.ca> : > : FreeBSD Tinderbox writes: : > : : /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required alignment of target type : > The first one is: : > : > case RTM_IFINFO: : > ifm = (struct if_msghdr *)rtm; : > mib_extract_addrs(ifm->ifm_addrs, (u_char *)(ifm + 1), addrs); : > if ((ifp = mib_find_if_sys(ifm->ifm_index)) == NULL) : > break; : > : > rtm is of type struct rt_msghdr. This has an alignment requirement of : > 4 on mips, at least on 32-bit mips (the biggest data element is a : > u_long). struct if_msghdr has an alignment requirement of 8, because : > time_t is int64_t on MIPS, which is 8-bytes in size. : : If the memory that rtm can be pointing to can be either a struct : rt_msghdr or a struct if_msghdr, then shouldn't it really be : pointing to a union of those two, and then the alignment will : sort itself out? (As far as I know, that's the only way that : C99 will guarantee that the right thing happens anyway, : otherwise strict aliasing analysis would allow much worse : badness to happen, potentially.) This is a stream of data from the kernel, multiple messages, so making it be a union wouldn't force the proper alignment from the kernel... : Not looked at the code myself. Perhaps there's a reason why : that would be unworkable. Yes. There is. Warner From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 15:28:18 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EBD0106564A; Wed, 18 Feb 2009 15:28:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 09D928FC12; Wed, 18 Feb 2009 15:28:17 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n1IFPoLM056703; Wed, 18 Feb 2009 08:25:50 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 18 Feb 2009 08:25:59 -0700 (MST) Message-Id: <20090218.082559.-1112729020.imp@bsdimp.com> To: andrew-freebsd@areilly.bpc-users.org From: "M. Warner Losh" In-Reply-To: <20090218110402.GA13040@duncan.reilly.home> References: <20090217.203647.-1518647466.imp@bsdimp.com> <20090217.222152.-109416210.imp@bsdimp.com> <20090218110402.GA13040@duncan.reilly.home> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mips@freebsd.org, tinderbox@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 15:28:19 -0000 In message: <20090218110402.GA13040@duncan.reilly.home> Andrew Reilly writes: : On Tue, Feb 17, 2009 at 10:21:52PM -0700, M. Warner Losh wrote: : > In message: <20090217.203647.-1518647466.imp@bsdimp.com> : > "M. Warner Losh" writes: : > : In message: <20090218023328.227617302F@freebsd-current.sentex.ca> : > : FreeBSD Tinderbox writes: : > : : /src/usr.sbin/bsnmpd/modules/snmp_mibII/../../../../contrib/bsnmp/snmp_mibII/mibII.c:1016: warning: cast increases required alignment of target type : > The first one is: : > : > case RTM_IFINFO: : > ifm = (struct if_msghdr *)rtm; : > mib_extract_addrs(ifm->ifm_addrs, (u_char *)(ifm + 1), addrs); : > if ((ifp = mib_find_if_sys(ifm->ifm_index)) == NULL) : > break; : > : > rtm is of type struct rt_msghdr. This has an alignment requirement of : > 4 on mips, at least on 32-bit mips (the biggest data element is a : > u_long). struct if_msghdr has an alignment requirement of 8, because : > time_t is int64_t on MIPS, which is 8-bytes in size. : : If the memory that rtm can be pointing to can be either a struct : rt_msghdr or a struct if_msghdr, then shouldn't it really be : pointing to a union of those two, and then the alignment will : sort itself out? (As far as I know, that's the only way that : C99 will guarantee that the right thing happens anyway, : otherwise strict aliasing analysis would allow much worse : badness to happen, potentially.) : : Not looked at the code myself. Perhaps there's a reason why : that would be unworkable. There's a second issue. There's a number of different structures that are type punned to rt_msghdr. I'm worried it would be an ABI change to do that as well. In this case, code inspection shows the code to be fine since the dangerous element isn't touched. Warner From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 15:59:56 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 807E61065670 for ; Wed, 18 Feb 2009 15:59:56 +0000 (UTC) (envelope-from ulf.lilleengen@gmail.com) Received: from bene2.itea.ntnu.no (bene2.itea.ntnu.no [IPv6:2001:700:300:3::57]) by mx1.freebsd.org (Postfix) with ESMTP id C30A68FC15 for ; Wed, 18 Feb 2009 15:59:55 +0000 (UTC) (envelope-from ulf.lilleengen@gmail.com) Received: from localhost (localhost [127.0.0.1]) by bene2.itea.ntnu.no (Postfix) with ESMTP id 2FCE89000B; Wed, 18 Feb 2009 16:59:54 +0100 (CET) Received: from carrot (unknown [IPv6:2001:700:300:3::184]) by bene2.itea.ntnu.no (Postfix) with ESMTP id CEEB09000A; Wed, 18 Feb 2009 16:59:53 +0100 (CET) Date: Wed, 18 Feb 2009 17:00:43 +0000 From: Ulf Lilleengen To: Marcel Moolenaar Message-ID: <20090218170043.GA76148@carrot> References: <16678.1234910124@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: Debian amavisd-new at bene2.itea.ntnu.no Cc: Poul-Henning Kamp , FreeBSD current mailing list Subject: Re: boot0cfg -s vs. GEOM_PART_*? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 15:59:57 -0000 On Tue, Feb 17, 2009 at 04:19:55PM -0800, Marcel Moolenaar wrote: > > On Feb 17, 2009, at 2:35 PM, Poul-Henning Kamp wrote: > > > In message , Marcel > > Moolenaar wri > > tes: > > > >>> In message , Marcel > >>> Moolenaar wri > >>> tes: > >>> > >>>> For boot0cfg this is probably acceptable, because > >>>> it only operates on MBRs. But as a generic solution > >>>> this won't work. > >>> > >>> Then pick up the bootcode via ioctls, it does not belong > >>> in the confxml sysctl. > >> > >> On what grounds doesn't it belong in the confxml? > > > > Because the way we (currently) implement confxml and the uses it is > > put to would generally be greatly inconvenienced if you have to > > include > > 8KB of hexdump data in the xml stream. > > > >> And how do these not apply to ioctls? > > > > ioctls was designed and built to move binary blobs across the > > userland/kernel barrier to and from I/O devices. > How about the way that was done in GEOM_MBR? Defining a verb like "write MBR", and supply the mbr as a parameter with gctl? (Currently used by boot0cfg). -- Ulf Lilleengen From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 16:01:47 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67F831065740 for ; Wed, 18 Feb 2009 16:01:47 +0000 (UTC) (envelope-from ulf.lilleengen@gmail.com) Received: from bene2.itea.ntnu.no (bene2.itea.ntnu.no [IPv6:2001:700:300:3::57]) by mx1.freebsd.org (Postfix) with ESMTP id 1CDE18FC18 for ; Wed, 18 Feb 2009 16:01:47 +0000 (UTC) (envelope-from ulf.lilleengen@gmail.com) Received: from localhost (localhost [127.0.0.1]) by bene2.itea.ntnu.no (Postfix) with ESMTP id 48D419000C; Wed, 18 Feb 2009 17:01:46 +0100 (CET) Received: from carrot (unknown [IPv6:2001:700:300:3::184]) by bene2.itea.ntnu.no (Postfix) with ESMTP id D7F269000B; Wed, 18 Feb 2009 17:01:45 +0100 (CET) Date: Wed, 18 Feb 2009 17:02:36 +0000 From: Ulf Lilleengen To: Marcel Moolenaar Message-ID: <20090218170236.GB76148@carrot> References: <16678.1234910124@critter.freebsd.dk> <20090218170043.GA76148@carrot> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090218170043.GA76148@carrot> User-Agent: Mutt/1.5.19 (2009-01-05) X-Virus-Scanned: Debian amavisd-new at bene2.itea.ntnu.no Cc: Poul-Henning Kamp , FreeBSD current mailing list Subject: Re: boot0cfg -s vs. GEOM_PART_*? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 16:01:48 -0000 On Wed, Feb 18, 2009 at 05:00:43PM +0000, Ulf Lilleengen wrote: > On Tue, Feb 17, 2009 at 04:19:55PM -0800, Marcel Moolenaar wrote: > > > > On Feb 17, 2009, at 2:35 PM, Poul-Henning Kamp wrote: > > > > > In message , Marcel > > > Moolenaar wri > > > tes: > > > > > >>> In message , Marcel > > >>> Moolenaar wri > > >>> tes: > > >>> > > >>>> For boot0cfg this is probably acceptable, because > > >>>> it only operates on MBRs. But as a generic solution > > >>>> this won't work. > > >>> > > >>> Then pick up the bootcode via ioctls, it does not belong > > >>> in the confxml sysctl. > > >> > > >> On what grounds doesn't it belong in the confxml? > > > > > > Because the way we (currently) implement confxml and the uses it is > > > put to would generally be greatly inconvenienced if you have to > > > include > > > 8KB of hexdump data in the xml stream. > > > > > >> And how do these not apply to ioctls? > > > > > > ioctls was designed and built to move binary blobs across the > > > userland/kernel barrier to and from I/O devices. > > > > How about the way that was done in GEOM_MBR? Defining a verb like "write > MBR", and supply the mbr as a parameter with gctl? (Currently used by > boot0cfg). Ah, like phk@ mentioned in an older reply :) -- Ulf Lilleengen From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 16:12:26 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56C2A1065670; Wed, 18 Feb 2009 16:12:26 +0000 (UTC) (envelope-from ml@netfence.it) Received: from parrot.aev.net (parrot.aev.eu [212.31.247.179]) by mx1.freebsd.org (Postfix) with ESMTP id 657F98FC2D; Wed, 18 Feb 2009 16:12:24 +0000 (UTC) (envelope-from ml@netfence.it) Received: from soth.ventu (adsl-ull-63-16.51-151.net24.it [151.51.16.63]) (authenticated bits=128) by parrot.aev.net (8.14.3/8.14.3) with ESMTP id n1IBogb3066642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Feb 2009 12:50:47 +0100 (CET) (envelope-from ml@netfence.it) Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.3/8.14.2) with ESMTP id n1IBrcC9097445; Wed, 18 Feb 2009 12:53:39 +0100 (CET) (envelope-from ml@netfence.it) Message-ID: <499BF630.7080306@netfence.it> Date: Wed, 18 Feb 2009 12:51:12 +0100 From: Andrea Venturoli User-Agent: Thunderbird 2.0.0.19 (X11/20090201) MIME-Version: 1.0 To: Scott Long References: <499551B9.7050805@samsco.org> In-Reply-To: <499551B9.7050805@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 212.31.247.179 X-Mailman-Approved-At: Wed, 18 Feb 2009 16:36:18 +0000 Cc: FreeBSD Current , FreeBSD Stable Subject: Re: HEADS UP: Major CAM performance regression X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 16:12:26 -0000 Scott Long ha scritto: Hello. > The following configurations are known to be affected: > > VMWare ESX > VMWare Fusion > (using bt or lsilogic controller options) > HP CISS RAID > Some MPT-SAS combinations with SATA drives attached > (Includes Dell SAS5/ir, but not PERC5/PERC6). Does it holds for any of these? Or do you require a combination of factors? I ask because I have two identical HP machines, one running 7.1p2/amd64, the other still at 7.1-PRERELEASE/amd64 and on both I get: # camcontrol tags da0 (pass1:ciss0:0:0:0): device openings: 254 So it looks like I'm not affected, although I have a ciss RAID. ??? bye & Thanks av. From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 18:19:36 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E73F31065686; Wed, 18 Feb 2009 18:19:36 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout021.mac.com (asmtpout021.mac.com [17.148.16.96]) by mx1.freebsd.org (Postfix) with ESMTP id CF3138FC23; Wed, 18 Feb 2009 18:19:36 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from dpham-t61.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp021.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KF9006SNXKNQS10@asmtp021.mac.com>; Wed, 18 Feb 2009 10:19:36 -0800 (PST) Message-id: From: Marcel Moolenaar To: "M. Warner Losh" In-reply-to: <20090217.235826.-1697751865.imp@bsdimp.com> Date: Wed, 18 Feb 2009 10:19:34 -0800 References: <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> <20090217.234216.1276682135.imp@bsdimp.com> <20090217.235826.-1697751865.imp@bsdimp.com> X-Mailer: Apple Mail (2.930.3) Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 18:19:37 -0000 On Feb 17, 2009, at 10:58 PM, M. Warner Losh wrote: > In message: > Marcel Moolenaar writes: > : > : On Feb 17, 2009, at 10:42 PM, M. Warner Losh wrote: > : > : > : A safer approach is to mark ifi_epoch as packed or put > differently, > : > : define time_t as a 64-bit integral with 32-bit alignment. This > can > : > : avoid a lot of unexpected internal padding as well (e.g. struct > : > : timeval). > : > > : > Marking it as packed won't help. If the elements aren't properly > : > aligned, gcc won't access multi-word entities properly. It might > : > eliminate the warning, but it will break at runtime. > : > : But GCC will use a pair of 32-bit loads and/or stores to > : access the 64-bit integral in that case. There should be > : no runtime breakage. You only do this for n32 of course. > > Why only n32? Registers are still 64-bit in n32. I think that's the problem. With registers still 64-bit, MIPS n32 isn't really behaving like a 32-bit machine in the case of 64-bit accesses. It's that aspect you want to tweak. So, if you give all 64-bit integrals an alignment of 4 bytes, then GCC will use a pair of 32-bit loads and stores (just like, say, powerpc) and you don't run into the alignment problems where all of a sudden a data structure gets 8-byte alignment, triggers warnings, and we try to correct it with kluges. For MIPS n64 things are like any other LP64 architecture, so you don't have to tweak anything. In other words: by tweaking the alignment of 64-bit types in n32, you prohibit GCC from using the 64-bit capabilities of the processor and MIPS isn't so weird anymore. NOTE: On ARM, GCC aligns structures to a 4-byte boundary by default. This has caused us problems and instead of fixing the default behaviour of the compiler, we slammed __packed onto structures. If we had changed the default behaviour of the compiler, then all structures would be naturally aligned and we would be able to use the half-word memory accesses that newer ARM processors have. No, we __packed the lot and created a big performance bottleneck because now we can only use byte-wise memory accesses. What was done for performance (default alignment of 4-bytes for structures), was turned into a huge pessimisation by us compensating with __packed. We have more optimal code if the compiler aligns structures on their natural boundary! The point being that programmers *do* code with certain assumptions and as soon as those assumptions don't hold on a platform, you end up worse off. My thoughts for MIPS n32 are to make it behave like any "normal" 32-bit strong- alignment platform to avoid 1) a large number of runtime alignment faults -- which are a bigger performance bottleneck than forcing 64-bit integrals to be accessed with 2 32-bit accesses and 2) avoid further abuse of __packed, which turns all accesses in a series of byte-wise accesses. At Juniper I changed the ARM compiler default by adding: -mstructure-size-boundary=8 That made life a *lot* simpler and performance hasn't been sacrificed. Just an explanation of where I'm coming from... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 18:21:19 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C5EC1065693 for ; Wed, 18 Feb 2009 18:21:19 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout017.mac.com (asmtpout017.mac.com [17.148.16.92]) by mx1.freebsd.org (Postfix) with ESMTP id 45F3C8FC2A for ; Wed, 18 Feb 2009 18:21:19 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp017.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KF90031TXNCW920@asmtp017.mac.com> for current@FreeBSD.org; Wed, 18 Feb 2009 10:21:12 -0800 (PST) Message-id: From: Marcel Moolenaar To: Ulf Lilleengen In-reply-to: <20090218170043.GA76148@carrot> Date: Wed, 18 Feb 2009 10:21:12 -0800 References: <16678.1234910124@critter.freebsd.dk> <20090218170043.GA76148@carrot> X-Mailer: Apple Mail (2.930.3) Cc: Poul-Henning Kamp , FreeBSD current mailing list Subject: Re: boot0cfg -s vs. GEOM_PART_*? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 18:21:21 -0000 On Feb 18, 2009, at 9:00 AM, Ulf Lilleengen wrote: > How about the way that was done in GEOM_MBR? Defining a verb like > "write > MBR", and supply the mbr as a parameter with gctl? (Currently used by > boot0cfg). There's already averb to write bootcode, There's just no verb (yet) to read bootcode. -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 18:38:19 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A590106564A for ; Wed, 18 Feb 2009 18:38:19 +0000 (UTC) (envelope-from sean.bruno@dsl-only.net) Received: from iron2.pdx.net (iron2.pdx.net [69.64.224.71]) by mx1.freebsd.org (Postfix) with ESMTP id 1FBB88FC1A for ; Wed, 18 Feb 2009 18:38:18 +0000 (UTC) (envelope-from sean.bruno@dsl-only.net) Received: (qmail 29668 invoked from network); 18 Feb 2009 10:37:18 -0800 Received: from 069-064-235-060.pdx.net (HELO ?192.168.1.51?) (69.64.235.60) by iron2.pdx.net with SMTP; 18 Feb 2009 10:37:17 -0800 From: Sean Bruno To: current@FreeBSD.org Content-Type: text/plain Date: Wed, 18 Feb 2009 10:38:17 -0800 Message-Id: <1234982297.20261.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.24.3 (2.24.3-1.fc10) Content-Transfer-Encoding: 7bit Cc: Subject: HEADSUP: dev/firewire usr.sbin/fwcontrol X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 18:38:19 -0000 Looks like I changed a shared header file yesterday(as noted by folks whose buildworld broke). When updating to today's -current, a recompile/install of usr.sbin/fwcontrol is required. Sean From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 19:07:19 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 011FB10656ED; Wed, 18 Feb 2009 19:07:19 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 8671F8FC17; Wed, 18 Feb 2009 19:07:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n1IJ55rc059811; Wed, 18 Feb 2009 12:05:05 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 18 Feb 2009 12:05:14 -0700 (MST) Message-Id: <20090218.120514.831271136.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: References: <20090217.235826.-1697751865.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 19:07:20 -0000 In message: Marcel Moolenaar writes: : : On Feb 17, 2009, at 10:58 PM, M. Warner Losh wrote: : : > In message: : > Marcel Moolenaar writes: : > : : > : On Feb 17, 2009, at 10:42 PM, M. Warner Losh wrote: : > : : > : > : A safer approach is to mark ifi_epoch as packed or put : > differently, : > : > : define time_t as a 64-bit integral with 32-bit alignment. This : > can : > : > : avoid a lot of unexpected internal padding as well (e.g. struct : > : > : timeval). : > : > : > : > Marking it as packed won't help. If the elements aren't properly : > : > aligned, gcc won't access multi-word entities properly. It might : > : > eliminate the warning, but it will break at runtime. : > : : > : But GCC will use a pair of 32-bit loads and/or stores to : > : access the 64-bit integral in that case. There should be : > : no runtime breakage. You only do this for n32 of course. : > : > Why only n32? Registers are still 64-bit in n32. : : I think that's the problem. With registers still 64-bit, MIPS : n32 isn't really behaving like a 32-bit machine in the case of : 64-bit accesses. It's that aspect you want to tweak. So, if : you give all 64-bit integrals an alignment of 4 bytes, then : GCC will use a pair of 32-bit loads and stores (just like, : say, powerpc) and you don't run into the alignment problems : where all of a sudden a data structure gets 8-byte alignment, : triggers warnings, and we try to correct it with kluges. MIPS n32 is a 64-bit ABI in many ways, but 32-bit in others. Its data-types are 32-bit, but the compiler is free to leverage the underlying 64-bit machine to implement it. So for 64-bit quantities, is uses the ld/sd op codes. : For MIPS n64 things are like any other LP64 architecture, so : you don't have to tweak anything. I think so. : In other words: by tweaking the alignment of 64-bit types in : n32, you prohibit GCC from using the 64-bit capabilities of : the processor and MIPS isn't so weird anymore. I think so, but there's a twist. On MIPS, one kernel supports multiple ABIs at the same time. I'm not entirely sure how the routing interface would cope with this sort of thing because the size of u_long changes. I need to do some more research to see what's going on there... : NOTE: On ARM, GCC aligns structures to a 4-byte boundary by : default. This has caused us problems and instead of fixing : the default behaviour of the compiler, we slammed __packed : onto structures. If we had changed the default behaviour of : the compiler, then all structures would be naturally aligned : and we would be able to use the half-word memory accesses : that newer ARM processors have. No, we __packed the lot and : created a big performance bottleneck because now we can only : use byte-wise memory accesses. : What was done for performance (default alignment of 4-bytes : for structures), was turned into a huge pessimisation by us : compensating with __packed. We have more optimal code if : the compiler aligns structures on their natural boundary! The reason we have the compiler doing this on ARM is for ABI conformance. There are other ABIs on ARM that don't suffer from these problems. We should investigate using them. : The point being that programmers *do* code with certain : assumptions and as soon as those assumptions don't hold on : a platform, you end up worse off. My thoughts for MIPS n32 : are to make it behave like any "normal" 32-bit strong- : alignment platform to avoid 1) a large number of runtime : alignment faults -- which are a bigger performance bottleneck : than forcing 64-bit integrals to be accessed with 2 32-bit : accesses Run time faults aren't a bottleneck. They are a core dump, which is why I'm looking at this in the first place. :) : and 2) avoid further abuse of __packed, which turns : all accesses in a series of byte-wise accesses. We haven't really abused __packed. The items we have as '__packed' really are packed data structures for the wire. We have also added some __aligned() flag as well which help to mitigate the performance penalties because the compiler can unpack the items. : At Juniper I changed the ARM compiler default by adding: : -mstructure-size-boundary=8 : : That made life a *lot* simpler and performance hasn't been : sacrificed. Except you've invented a new ABI by doing that... I think that the project should look at transitioning to a different ABI that works better. ARM has several to choose from... : Just an explanation of where I'm coming from... Yes. Unfortunately, those kinds of hacks take us further away form the standard environment for these platforms. There are many dark corners of the current MIPS code that knows all the alignment and layout issues and changing the compiler to force a different alignment will break that code... Anyway, since we are a little ways away from having to cope with all the ABI issues for MIPS... It also turns out that in this case, a simple (void *) is safe and causes no issues because that time_t isn't accessed... It does give one time to pause and think about it. Warner From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 19:36:32 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7C59F1065675; Wed, 18 Feb 2009 19:36:32 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout011.mac.com (asmtpout011.mac.com [17.148.16.86]) by mx1.freebsd.org (Postfix) with ESMTP id 64CA58FC19; Wed, 18 Feb 2009 19:36:32 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from jflores-gxdt755.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp011.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KFA00ME214TZA40@asmtp011.mac.com>; Wed, 18 Feb 2009 11:36:31 -0800 (PST) Message-id: <064E7F22-AF3D-432C-B5E3-F71A34AB24AC@mac.com> From: Marcel Moolenaar To: "M. Warner Losh" In-reply-to: <20090218.120514.831271136.imp@bsdimp.com> Date: Wed, 18 Feb 2009 11:36:29 -0800 References: <20090217.235826.-1697751865.imp@bsdimp.com> <20090218.120514.831271136.imp@bsdimp.com> X-Mailer: Apple Mail (2.930.3) Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 19:36:33 -0000 On Feb 18, 2009, at 11:05 AM, M. Warner Losh wrote: > : In other words: by tweaking the alignment of 64-bit types in > : n32, you prohibit GCC from using the 64-bit capabilities of > : the processor and MIPS isn't so weird anymore. > > I think so, but there's a twist. > > On MIPS, one kernel supports multiple ABIs at the same time. I'm not > entirely sure how the routing interface would cope with this sort of > thing because the size of u_long changes. I need to do some more > research to see what's going on there... Hmm... My first reaction is not to go there right away. It's probably safer or go the amd64 route: keep ILP32 and LP64 distinct. We have the infrastructure in place and we can always optimize and blend once things are working. > There are other ABIs on ARM that don't suffer from these problems. We > should investigate using them. I agree. It's better for FreeBSD/arm in particular if it's more like FreeBSD/i386. It may not be best for the ARM port in absolute sense, but we only have a few developers working on non-i386 hardware and a whole lot of developers who don't care about non-i386... > : The point being that programmers *do* code with certain > : assumptions and as soon as those assumptions don't hold on > : a platform, you end up worse off. My thoughts for MIPS n32 > : are to make it behave like any "normal" 32-bit strong- > : alignment platform to avoid 1) a large number of runtime > : alignment faults -- which are a bigger performance bottleneck > : than forcing 64-bit integrals to be accessed with 2 32-bit > : accesses > > Run time faults aren't a bottleneck. They are a core dump, which is > why I'm looking at this in the first place. :) :-) > : At Juniper I changed the ARM compiler default by adding: > : -mstructure-size-boundary=8 > : > : That made life a *lot* simpler and performance hasn't been > : sacrificed. > > Except you've invented a new ABI by doing that... We have a products to make and a source base to work with. Swimming upstream is best left to salmons :-) > I think that the > project should look at transitioning to a different ABI that works > better. ARM has several to choose from... I tend to agree. > It also turns out that in this case, a simple (void *) is safe and > causes no issues because that time_t isn't accessed... It does give > one time to pause and think about it. Fair enough. Misalignment in process space can easily be made non-fatal, in which case it's mostly a performance problem. That makes the problem space much more contained and therefore easier to deal with... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 20:00:31 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B72881065673 for ; Wed, 18 Feb 2009 20:00:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id 4C7EF8FC15 for ; Wed, 18 Feb 2009 20:00:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LZsaq-000Ne7-2O; Wed, 18 Feb 2009 22:00:28 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n1IK0N4t065336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Feb 2009 22:00:24 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n1IK0NrS094763; Wed, 18 Feb 2009 22:00:23 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n1IK0NC4094762; Wed, 18 Feb 2009 22:00:23 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 18 Feb 2009 22:00:23 +0200 From: Kostik Belousov To: Marcel Moolenaar Message-ID: <20090218200023.GU41617@deviant.kiev.zoral.com.ua> References: <4CB77F1D-4235-47D8-B654-1C4F29B6C649@mac.com> <20090217.234216.1276682135.imp@bsdimp.com> <20090217.235826.-1697751865.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eNjIDde0W37E3OQP" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LZsaq-000Ne7-2O 51d45eccd875aacf2d71f4555f4f2809 X-Terabit: YES Cc: mips@freebsd.org, tinderbox@freebsd.org, "M. Warner Losh" , current@freebsd.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 20:00:32 -0000 --eNjIDde0W37E3OQP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 18, 2009 at 10:19:34AM -0800, Marcel Moolenaar wrote: >=20 > On Feb 17, 2009, at 10:58 PM, M. Warner Losh wrote: >=20 > >In message: > > Marcel Moolenaar writes: > >: > >: On Feb 17, 2009, at 10:42 PM, M. Warner Losh wrote: > >: > >: > : A safer approach is to mark ifi_epoch as packed or put =20 > >differently, > >: > : define time_t as a 64-bit integral with 32-bit alignment. This =20 > >can > >: > : avoid a lot of unexpected internal padding as well (e.g. struct > >: > : timeval). > >: > > >: > Marking it as packed won't help. If the elements aren't properly > >: > aligned, gcc won't access multi-word entities properly. It might > >: > eliminate the warning, but it will break at runtime. > >: > >: But GCC will use a pair of 32-bit loads and/or stores to > >: access the 64-bit integral in that case. There should be > >: no runtime breakage. You only do this for n32 of course. > > > >Why only n32? Registers are still 64-bit in n32. >=20 > I think that's the problem. With registers still 64-bit, MIPS > n32 isn't really behaving like a 32-bit machine in the case of > 64-bit accesses. It's that aspect you want to tweak. So, if > you give all 64-bit integrals an alignment of 4 bytes, then > GCC will use a pair of 32-bit loads and stores (just like, > say, powerpc) and you don't run into the alignment problems > where all of a sudden a data structure gets 8-byte alignment, > triggers warnings, and we try to correct it with kluges. >=20 > For MIPS n64 things are like any other LP64 architecture, so > you don't have to tweak anything. >=20 > In other words: by tweaking the alignment of 64-bit types in > n32, you prohibit GCC from using the 64-bit capabilities of > the processor and MIPS isn't so weird anymore. >=20 > NOTE: On ARM, GCC aligns structures to a 4-byte boundary by > default. This has caused us problems and instead of fixing > the default behaviour of the compiler, we slammed __packed > onto structures. If we had changed the default behaviour of > the compiler, then all structures would be naturally aligned > and we would be able to use the half-word memory accesses > that newer ARM processors have. No, we __packed the lot and > created a big performance bottleneck because now we can only > use byte-wise memory accesses. > What was done for performance (default alignment of 4-bytes > for structures), was turned into a huge pessimisation by us > compensating with __packed. We have more optimal code if > the compiler aligns structures on their natural boundary! >=20 > The point being that programmers *do* code with certain > assumptions and as soon as those assumptions don't hold on > a platform, you end up worse off. My thoughts for MIPS n32 > are to make it behave like any "normal" 32-bit strong- > alignment platform to avoid 1) a large number of runtime > alignment faults -- which are a bigger performance bottleneck > than forcing 64-bit integrals to be accessed with 2 32-bit > accesses and 2) avoid further abuse of __packed, which turns > all accesses in a series of byte-wise accesses. >=20 > At Juniper I changed the ARM compiler default by adding: > -mstructure-size-boundary=3D8 >=20 > That made life a *lot* simpler and performance hasn't been > sacrificed. >=20 > Just an explanation of where I'm coming from... I have a question. All architectures I had a slightest interest in, included the required alignment of types into the ABI specification. This is true at least for i386. amd64, sparc v8 and v9, and HP-PA 1.1 and 2.0. Is MIPS different in this aspect ? --eNjIDde0W37E3OQP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmcaNYACgkQC3+MBN1Mb4iwHQCdEFcZiY7fFPfYKjvou23tkeng hWcAoI6GzgOthcWUAOzx09gY3wy6p/DL =x3VL -----END PGP SIGNATURE----- --eNjIDde0W37E3OQP-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 21:23:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 15D05106566B for ; Wed, 18 Feb 2009 21:23:15 +0000 (UTC) (envelope-from root@free.fr) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by mx1.freebsd.org (Postfix) with ESMTP id C60E88FC13 for ; Wed, 18 Feb 2009 21:23:12 +0000 (UTC) (envelope-from root@free.fr) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id AF2344C8153 for ; Wed, 18 Feb 2009 22:23:09 +0100 (CET) Received: from free.fr (evr27-1-88-172-40-194.fbx.proxad.net [88.172.40.194]) by smtp4-g21.free.fr (Postfix) with ESMTP id C05704C8079 for ; Wed, 18 Feb 2009 22:23:06 +0100 (CET) From: rmgls@free.fr To: freebsd-current@freebsd.org Date: Wed, 18 Feb 2009 22:23:02 +0100 Sender: root@free.fr Message-Id: <20090218212306.C05704C8079@smtp4-g21.free.fr> Subject: man usb2_core(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 21:23:15 -0000 Hi all, just to say that in the libusb20 man page there is a mention to usb2_core(4), but this man page does not exist! sure, some words of the usb2 specialists woukd be handy here. regards Raoul rmgls@free.fr From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 21:31:17 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE05010656CC for ; Wed, 18 Feb 2009 21:31:17 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8CC7A8FC0C for ; Wed, 18 Feb 2009 21:31:17 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 842DB29A35C; Wed, 18 Feb 2009 16:11:49 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 18 Feb 2009 16:11:49 -0500 X-Sasl-enc: 4ic1MK/s/o781sdcB5dZNReOpgOwlvV6G9Fg3KgACwCO 1234991508 Received: from empiric.lon.incunabulum.net (unknown [81.168.51.182]) by mail.messagingengine.com (Postfix) with ESMTPSA id 5956D30B31; Wed, 18 Feb 2009 16:11:48 -0500 (EST) Message-ID: <499C7992.7000705@incunabulum.net> Date: Wed, 18 Feb 2009 21:11:46 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: Ed Schouten References: <4999F7F9.4030204@elischer.org> <499A024A.60209@protected-networks.net> <20090217110524.GC79178@hoeg.nl> <499A9C9D.3000403@protected-networks.net> <20090217115651.GE79178@hoeg.nl> <20090217175512.GG79178@hoeg.nl> <20090217182128.GH79178@hoeg.nl> <20090217192152.GI79178@hoeg.nl> In-Reply-To: <20090217192152.GI79178@hoeg.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Michael Butler , current@freebsd.org, Maksim Yevmenkin Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 21:31:18 -0000 Ed Schouten wrote: > ... > As you mentioned earlier, there is no need to use pts(4), because > rfcomm_sppd also supports using stdout/stdin. This is a lot better, > because our pipe implementation is probably a lot faster than pts(4). > I'd rather see the handbook changed to not mention TTYs anywhere. > > For what it's worth, rfcomm_sppd exists largely because up until now, mobile phone vendors have not implemented the BNEP profile in their hardware. Having to initiate a PPP session across a virtual serial port... to get to a PPP session over UMTS/GPRS... is just silly. It's not possible to roam even locally across a Bluetooth piconet to other providers with this sort of setup, as may be possible with BNEP in some situations. Also, if for whatever reason the local Bluetooth RFCOMM session is interrupted (phone rebooted, or interference in the ISM 2.4GHz band), due to the stateful nature of PPP, the connection can get torn down. BNEP doesn't have this issue, because it presents an Ethernet-like layer, and is therefore stateless, apart from address configuration. However, having said that, most folks will still be using mobile handsets which don't support BNEP for the foreseeable future. Unfortunately this means rfcomm_sppd still needs to play nice with userland ppp. Of course for the typical use case, as I undestand it, rfcomm_pppd is going to be invoking rfcomm_sppd as a wrapper, so pipes are just fine (and in fact probably already being used). Maksim seems to be talking about the use case where folk are actually doing straight serial over RFCOMM and need to tie it down to a known tty, though. Surely there must be a way to tie rfcomm_sppd down to a specific pts number, or failing that, teach it to report the pts which it got allocated? cheers, BMS From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 21:31:20 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB4CA10656CC for ; Wed, 18 Feb 2009 21:31:20 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 6BC0A8FC20 for ; Wed, 18 Feb 2009 21:31:20 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.3/8.14.3) with ESMTP id n1ILVJZA027733 for ; Wed, 18 Feb 2009 13:31:19 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.3/8.14.3/Submit) id n1ILVJYQ027732 for current@freebsd.org; Wed, 18 Feb 2009 13:31:19 -0800 (PST) (envelope-from david) Date: Wed, 18 Feb 2009 13:31:19 -0800 From: David Wolfskill To: current@freebsd.org Message-ID: <20090218213119.GU81076@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="iDpyORI+WvZmjlkd" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: High CPU usage for hald(8) as of r188749 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 21:31:22 -0000 --iDpyORI+WvZmjlkd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On my laptop, after building CURRENT (r188749) this morning, it seems that hald(8) is using a bit more CPU than its proper share: last pid: 2203; load averages: 1.27, 1.10, 0.63 up 0+00:12:14 13:0= 4:12 60 processes: 2 running, 58 sleeping CPU: 19.1% user, 0.0% nice, 78.2% system, 2.7% interrupt, 0.0% idle Mem: 78M Active, 18M Inact, 47M Wired, 376K Cache, 26M Buf, 1351M Free Swap: 6144M Total, 6144M Free PID USERNAME THR PRI NICE SIZE RES STATE TIME WCPU COMMAND 1734 haldaemon 1 118 0 19968K 5160K RUN 6:57 97.17% hald 2203 david 1 46 0 6352K 4492K select 0:00 0.20% ssh 1806 root 1 44 0 91156K 77684K select 0:04 0.00% Xorg 1917 david 1 44 0 3672K 2928K select 0:04 0.00% piewm =2E.. FreeBSD g1-37.catwhisker.org. 8.0-CURRENT FreeBSD 8.0-CURRENT #955 r188749:= Wed Feb 18 09:28:21 PST 2009 root@g1-37.catwhisker.org.:/common/S4/obj= /usr/src/sys/CANARY i386 Possible complication(s) in this include: * I built hald(8) under RELENG_6. This is because * I build all ports (save for misc/compat6x) under RELENG_6, and update ports daily. The laptop spends enough of its time rebuilding software just tracking RELENG_6, RELENG_7, HEAD, and ports under RELENG_6 every day; if I tried updating the ports under RELENG_7 & HEAD, too, the task would often take more than 24 hrs. per day. The machine is an older Dell Latitude C840 (single-core 2.4 GHz) laptop; nothing especially remarkable about it. Booting: FreeBSD g1-37.catwhisker.org. 6.4-STABLE FreeBSD 6.4-STABLE #669 r188436: T= ue Feb 10 04:23:24 PST 2009 root@g1-35.catwhisker.org:/common/S1/obj/us= r/src/sys/CANARY i386 hald(8)'s CPPU usage is down in the noise, even when the system is nearly completely idle. My recollection is that hald(8) was also a low CPU-usage task for RELENG_7. I have done nothing with respect to configuring or tweaking hald(8); the high CPU usage appears to be a new artifact since yesterday (when I ran r188709). I note, too, that if I boot CURRENT while I have a Cisco/Aironet 350 (an(4)) card inserted in one of the PCcard slots, in addition to hald(8) consuming CPU, the only things to which the keyboard responds are chords to switch among vtys and Ctl+Alt+Esc to go to the debugger -- Ctl+Alt+Del is ignored, and xdm(1) doesn't start. Ensuring that the an(4) card is not in the syystem avoids the issue, and xdm(1) comes up fine. (Well, I admit to having taken some evasive action when X.org started wanting to use hald(8) && modified my start-up script for xdm, but I haven't changed that in a couple of days.) Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --iDpyORI+WvZmjlkd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkmcficACgkQmprOCmdXAD38OQCfcx4uWKhhy23zAoL+j7iRt2Ce figAniZhrZYQieNsmp5fA2nIuWL8S7rQ =WTm2 -----END PGP SIGNATURE----- --iDpyORI+WvZmjlkd-- From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 21:42:16 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A94A106564A for ; Wed, 18 Feb 2009 21:42:16 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe06.swip.net [212.247.154.161]) by mx1.freebsd.org (Postfix) with ESMTP id 219EC8FC17 for ; Wed, 18 Feb 2009 21:42:15 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=u0LlsF5tRVX9mqbAtXMA:9 a=r9lP9UGAru-gxg8DstoA:7 a=u0p5CHKr9iEPDIPbjDV26bwjh6UA:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe06.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1198918319; Wed, 18 Feb 2009 22:42:14 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Wed, 18 Feb 2009 22:44:41 +0100 User-Agent: KMail/1.9.7 References: <20090218212306.C05704C8079@smtp4-g21.free.fr> In-Reply-To: <20090218212306.C05704C8079@smtp4-g21.free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902182244.41967.hselasky@c2i.net> Cc: rmgls@free.fr Subject: Re: man usb2_core(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 21:42:16 -0000 On Wednesday 18 February 2009, rmgls@free.fr wrote: > Hi all, > > just to say that in the libusb20 man page there is a mention > to usb2_core(4), but this man page does not exist! > sure, some words of the usb2 specialists woukd be handy here. > The manpage is there, but maybe not installed properly: src/share/man/man4/usb2_core.4 --HPS From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 21:51:12 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 349361065695 for ; Wed, 18 Feb 2009 21:51:12 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 8165C8FC0C for ; Wed, 18 Feb 2009 21:51:11 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl183-211.kln.forthnet.gr [77.49.14.211]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-6) with ESMTP id n1ILoxMb002185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Feb 2009 23:51:05 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n1ILoxTP005436; Wed, 18 Feb 2009 23:50:59 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n1ILowOR005435; Wed, 18 Feb 2009 23:50:58 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Hans Petter Selasky References: <20090218212306.C05704C8079@smtp4-g21.free.fr> <200902182244.41967.hselasky@c2i.net> Date: Wed, 18 Feb 2009 23:50:57 +0200 In-Reply-To: <200902182244.41967.hselasky@c2i.net> (Hans Petter Selasky's message of "Wed, 18 Feb 2009 22:44:41 +0100") Message-ID: <87y6w3v2gu.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Hellug-MailScanner-ID: n1ILoxMb002185 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.877, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.52, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: rmgls@free.fr, freebsd-current@freebsd.org Subject: Re: man usb2_core(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 21:51:13 -0000 On Wed, 18 Feb 2009 22:44:41 +0100, Hans Petter Selasky wrote: > On Wednesday 18 February 2009, rmgls@free.fr wrote: >> Hi all, >> >> just to say that in the libusb20 man page there is a mention >> to usb2_core(4), but this man page does not exist! >> sure, some words of the usb2 specialists woukd be handy here. >> > > The manpage is there, but maybe not installed properly: > > src/share/man/man4/usb2_core.4 It isn't installed at all: keramida@kobe:/usr/src/share/man/man4$ fgrep usb2_ Makefile keramida@kobe:/usr/src/share/man/man4$ From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 21:52:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A23451065696 for ; Wed, 18 Feb 2009 21:52:00 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 2F1888FC1C for ; Wed, 18 Feb 2009 21:51:59 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so829104fgb.35 for ; Wed, 18 Feb 2009 13:51:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Xy40GXY0hfSu8KSZ32stx0mwmOCQ3Mkxgha08HyDWEM=; b=krW9pJ4GmZk3blWpmyF02eQ7zn2aH+/PL72VPMiNGRLoyYpoXKtzFoX+TkHcnLtPeT YGa+YZkeRthJ5NT3K+sFViYAq78fUMdRM3DllR76X7N81BwXNGunfaA8xcPWiBeWCwUf 7zFSKNIO6zUk3jyCT1rpECQJH4HfFbqh07eSU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=KxfmGoEXxTGLkIkn6M0q4Q/IDgVDeze8e1RLqWFJSk08TZjbyevGerkS8unHlKnRpI U7d/kZT01TRpb9xsKv6t97NC4+W0ftxQdQnVgyvmlh/GjnVlYEix3FxGF7zXDdNFRM8o MxStDpHtc77UUZYa27aE/MtLVqHVZ6suHkynI= MIME-Version: 1.0 Received: by 10.86.82.16 with SMTP id f16mr3047936fgb.26.1234993919023; Wed, 18 Feb 2009 13:51:59 -0800 (PST) In-Reply-To: <200902182244.41967.hselasky@c2i.net> References: <20090218212306.C05704C8079@smtp4-g21.free.fr> <200902182244.41967.hselasky@c2i.net> Date: Thu, 19 Feb 2009 00:51:58 +0300 Message-ID: From: pluknet To: Hans Petter Selasky Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: rmgls@free.fr, freebsd-current@freebsd.org Subject: Re: man usb2_core(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 21:52:02 -0000 2009/2/19 Hans Petter Selasky : > On Wednesday 18 February 2009, rmgls@free.fr wrote: >> Hi all, >> >> just to say that in the libusb20 man page there is a mention >> to usb2_core(4), but this man page does not exist! >> sure, some words of the usb2 specialists woukd be handy here. >> > > The manpage is there, but maybe not installed properly: > > src/share/man/man4/usb2_core.4 Indeed all those usb2_*(4) not linked to build. -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 21:54:39 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BF6C3106567D for ; Wed, 18 Feb 2009 21:54:39 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6219A8FC19 for ; Wed, 18 Feb 2009 21:54:39 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 9996129B032; Wed, 18 Feb 2009 16:54:38 -0500 (EST) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute2.internal (MEProxy); Wed, 18 Feb 2009 16:54:38 -0500 X-Sasl-enc: dXKtkqfSb1fnZTVFZkGS9ZcHDBV79PODrDElARWeQdY7 1234994078 Received: from empiric.lon.incunabulum.net (unknown [81.168.51.182]) by mail.messagingengine.com (Postfix) with ESMTPSA id 3446A1AD32; Wed, 18 Feb 2009 16:54:33 -0500 (EST) Message-ID: <499C8396.2020000@incunabulum.net> Date: Wed, 18 Feb 2009 21:54:30 +0000 From: Bruce Simpson User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: "M. Warner Losh" References: <20090217.235826.-1697751865.imp@bsdimp.com> <20090218.120514.831271136.imp@bsdimp.com> In-Reply-To: <20090218.120514.831271136.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: xcllnt@mac.com, mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 21:54:40 -0000 M. Warner Losh wrote: > ... > : The point being that programmers *do* code with certain > : assumptions and as soon as those assumptions don't hold on > : a platform, you end up worse off. My thoughts for MIPS n32 > : are to make it behave like any "normal" 32-bit strong- > : alignment platform to avoid 1) a large number of runtime > : alignment faults -- which are a bigger performance bottleneck > : than forcing 64-bit integrals to be accessed with 2 32-bit > : accesses > FWIW, Linux use a type-length-value protocol for the netlink routing socket, so alignment issues of this kind are shifted around (forgive the pun). > It also turns out that in this case, a simple (void *) is safe and > causes no issues because that time_t isn't accessed... It does give > one time to pause and think about it. > Yes, the void * cast works around the issue for now, but doesn't offer any guarantees that we are doing the right thing on strict alignment architectures. If the alignment *is* invalid, then we take the hit. cheers BMS From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 22:11:43 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0A32106566B; Wed, 18 Feb 2009 22:11:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E56FC8FC0A; Wed, 18 Feb 2009 22:11:42 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n1ILaTRJ061685; Wed, 18 Feb 2009 14:37:14 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 18 Feb 2009 14:36:38 -0700 (MST) Message-Id: <20090218.143638.-1025539642.imp@bsdimp.com> To: kostikbel@gmail.com From: "M. Warner Losh" In-Reply-To: <20090218200023.GU41617@deviant.kiev.zoral.com.ua> References: <20090217.235826.-1697751865.imp@bsdimp.com> <20090218200023.GU41617@deviant.kiev.zoral.com.ua> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: xcllnt@mac.com, mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:11:44 -0000 In message: <20090218200023.GU41617@deviant.kiev.zoral.com.ua> Kostik Belousov writes: : I have a question. All architectures I had a slightest interest in, : included the required alignment of types into the ABI specification. : This is true at least for i386. amd64, sparc v8 and v9, and HP-PA 1.1 : and 2.0. : : Is MIPS different in this aspect ? MIPS does define it as well. I have all the old o32 docs, but have had trouble locating the n32/n64 docs since they were done by SGI and SGI is now defunct. I know MIPS Technologies has information on nubi, which is yet another ABI family aimed more at the embedded platforms, but it hasn't had much traction. Warner From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 22:11:44 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C1A7106566C; Wed, 18 Feb 2009 22:11:44 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id DF47E8FC13; Wed, 18 Feb 2009 22:11:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n1ILXcel061679; Wed, 18 Feb 2009 14:34:23 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 18 Feb 2009 14:33:47 -0700 (MST) Message-Id: <20090218.143347.466770936.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: <064E7F22-AF3D-432C-B5E3-F71A34AB24AC@mac.com> References: <20090218.120514.831271136.imp@bsdimp.com> <064E7F22-AF3D-432C-B5E3-F71A34AB24AC@mac.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:11:44 -0000 In message: <064E7F22-AF3D-432C-B5E3-F71A34AB24AC@mac.com> Marcel Moolenaar writes: : : On Feb 18, 2009, at 11:05 AM, M. Warner Losh wrote: : > : In other words: by tweaking the alignment of 64-bit types in : > : n32, you prohibit GCC from using the 64-bit capabilities of : > : the processor and MIPS isn't so weird anymore. : > : > I think so, but there's a twist. : > : > On MIPS, one kernel supports multiple ABIs at the same time. I'm not : > entirely sure how the routing interface would cope with this sort of : > thing because the size of u_long changes. I need to do some more : > research to see what's going on there... : : Hmm... My first reaction is not to go there right away. It's : probably safer or go the amd64 route: keep ILP32 and LP64 : distinct. We have the infrastructure in place and we can : always optimize and blend once things are working. I don't think that's a viable option. MIPS doesn't have a 64-bit mode, but rather is always 64-bit. Or rather right now even in the port we have that supports n32 and n64 along side of o32, it is A or B or C. : > There are other ABIs on ARM that don't suffer from these problems. We : > should investigate using them. : : I agree. It's better for FreeBSD/arm in particular if it's : more like FreeBSD/i386. It may not be best for the ARM : port in absolute sense, but we only have a few developers : working on non-i386 hardware and a whole lot of developers : who don't care about non-i386... So far the number of places we've had to change in the kernel is minimal for the current ABI. The newer ABI is indeed targeted more at software that's been traditionally developed for x86 hardware. : > : At Juniper I changed the ARM compiler default by adding: : > : -mstructure-size-boundary=8 : > : : > : That made life a *lot* simpler and performance hasn't been : > : sacrificed. : > : > Except you've invented a new ABI by doing that... : : We have a products to make and a source base to work : with. Swimming upstream is best left to salmons :-) Yes. In a closed environment, you have that option. : > I think that the : > project should look at transitioning to a different ABI that works : > better. ARM has several to choose from... : : I tend to agree. : : : > It also turns out that in this case, a simple (void *) is safe and : > causes no issues because that time_t isn't accessed... It does give : > one time to pause and think about it. : : Fair enough. Misalignment in process space can easily be : made non-fatal, in which case it's mostly a performance : problem. That makes the problem space much more contained : and therefore easier to deal with... Other systems on mips are a mixed bag. Some allow user land fixup, while others abort the application... I think we need more real-world experience for which one is the best approach... Warner From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 22:45:59 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B10E51065676; Wed, 18 Feb 2009 22:45:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 6D7238FC1A; Wed, 18 Feb 2009 22:45:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n1IMi5Yb062162; Wed, 18 Feb 2009 15:44:05 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 18 Feb 2009 15:44:14 -0700 (MST) Message-Id: <20090218.154414.-1283372409.imp@bsdimp.com> To: bms@incunabulum.net From: "M. Warner Losh" In-Reply-To: <499C8396.2020000@incunabulum.net> References: <20090218.120514.831271136.imp@bsdimp.com> <499C8396.2020000@incunabulum.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: xcllnt@mac.com, mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:46:01 -0000 In message: <499C8396.2020000@incunabulum.net> Bruce Simpson writes: : M. Warner Losh wrote: : > ... : > : The point being that programmers *do* code with certain : > : assumptions and as soon as those assumptions don't hold on : > : a platform, you end up worse off. My thoughts for MIPS n32 : > : are to make it behave like any "normal" 32-bit strong- : > : alignment platform to avoid 1) a large number of runtime : > : alignment faults -- which are a bigger performance bottleneck : > : than forcing 64-bit integrals to be accessed with 2 32-bit : > : accesses : > : : FWIW, Linux use a type-length-value protocol for the netlink routing : socket, so alignment issues of this kind are shifted around (forgive the : pun). FreeBSD does too for the most part, but it is only at the inter-message level, not intra-message. : > It also turns out that in this case, a simple (void *) is safe and : > causes no issues because that time_t isn't accessed... It does give : > one time to pause and think about it. : > : : Yes, the void * cast works around the issue for now, but doesn't offer : any guarantees that we are doing the right thing on strict alignment : architectures. : If the alignment *is* invalid, then we take the hit. Right. The compiler doesn't check it, but I just did and things are fine given the fields accessed. But its that last bit that's the problem... I also have changed the offending line in my tree to be u_long instead of time_t since that is a better match to the protocol, and also gives us 168 years of uptime before there's an issue. Warner From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 22:49:35 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D9414106566B; Wed, 18 Feb 2009 22:49:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id AEC228FC16; Wed, 18 Feb 2009 22:49:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1IMnXQW036221; Wed, 18 Feb 2009 17:49:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1IMnXnZ060359; Wed, 18 Feb 2009 17:49:33 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1A16A7302F; Wed, 18 Feb 2009 17:49:33 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090218224933.1A16A7302F@freebsd-current.sentex.ca> Date: Wed, 18 Feb 2009 17:49:33 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:49:36 -0000 TB --- 2009-02-18 21:45:55 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-18 21:45:55 - starting HEAD tinderbox run for mips/mips TB --- 2009-02-18 21:45:55 - cleaning the object tree TB --- 2009-02-18 21:46:17 - cvsupping the source tree TB --- 2009-02-18 21:46:17 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/mips/mips/supfile TB --- 2009-02-18 21:46:27 - building world TB --- 2009-02-18 21:46:27 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-18 21:46:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-18 21:46:27 - TARGET=mips TB --- 2009-02-18 21:46:27 - TARGET_ARCH=mips TB --- 2009-02-18 21:46:27 - TZ=UTC TB --- 2009-02-18 21:46:27 - __MAKE_CONF=/dev/null TB --- 2009-02-18 21:46:27 - cd /src TB --- 2009-02-18 21:46:27 - /usr/bin/make -B buildworld >>> World build started on Wed Feb 18 21:46:29 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -fno-strict-aliasing -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/vipw -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/ypserv -I/src/usr.sbin/rpc.yppasswdd/../../libexec/ypxfr -I/src/usr.sbin/rpc.yppasswdd -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/rpc.yppasswdd/../../libexec/ypxfr/yp_dbwrite.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -fno-strict-aliasing -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/vipw -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/ypserv -I/src/usr.sbin/rpc.yppasswdd/../../libexec/ypxfr -I/src/usr.sbin/rpc.yppasswdd -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/rpc.yppasswdd/../../usr.sbin/ypserv/yp_error.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -fno-strict-aliasing -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/vipw -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/ypserv -I/src/usr.sbin/rpc.yppasswdd/../../libexec/ypxfr -I/src/usr.sbin/rpc.yppasswdd -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/rpc.yppasswdd/yppasswdd_main.c cc -O -pipe -EL -msoft-float -G0 -mno-dsp -mabicalls -fno-strict-aliasing -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/vipw -I/src/usr.sbin/rpc.yppasswdd/../../usr.sbin/ypserv -I/src/usr.sbin/rpc.yppasswdd/../../libexec/ypxfr -I/src/usr.sbin/rpc.yppasswdd -I. -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c /src/usr.sbin/rpc.yppasswdd/yppasswdd_server.c cc1: warnings being treated as errors /src/usr.sbin/rpc.yppasswdd/yppasswdd_server.c: In function 'yppasswdproc_update_master_1_svc': /src/usr.sbin/rpc.yppasswdd/yppasswdd_server.c:823: warning: cast increases required alignment of target type /src/usr.sbin/rpc.yppasswdd/yppasswdd_server.c:861: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/rpc.yppasswdd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-18 22:49:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-18 22:49:32 - ERROR: failed to build world TB --- 2009-02-18 22:49:32 - 2988.00 user 333.27 system 3817.88 real http://tinderbox.des.no/tinderbox-head-HEAD-mips-mips.full From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 22:54:11 2009 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D084F1065670; Wed, 18 Feb 2009 22:54:11 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by mx1.freebsd.org (Postfix) with ESMTP id B930D8FC12; Wed, 18 Feb 2009 22:54:11 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from [172.24.240.93] (natint3.juniper.net [66.129.224.36]) by asmtp019.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KFA0043BAA9QZ10@asmtp019.mac.com>; Wed, 18 Feb 2009 14:54:11 -0800 (PST) Message-id: From: Marcel Moolenaar To: "M. Warner Losh" In-reply-to: <20090218.143638.-1025539642.imp@bsdimp.com> Date: Wed, 18 Feb 2009 14:54:09 -0800 References: <20090217.235826.-1697751865.imp@bsdimp.com> <20090218200023.GU41617@deviant.kiev.zoral.com.ua> <20090218.143638.-1025539642.imp@bsdimp.com> X-Mailer: Apple Mail (2.930.3) Cc: kostikbel@gmail.com, mips@FreeBSD.org, tinderbox@FreeBSD.org, current@FreeBSD.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 22:54:13 -0000 On Feb 18, 2009, at 1:36 PM, M. Warner Losh wrote: > MIPS does define it as well. I have all the old o32 docs, but have > had trouble locating the n32/n64 docs since they were done by SGI and > SGI is now defunct. http://wwweic.eri.u-tokyo.ac.jp/computer/manual/lx/SGI_Developer/books/Mpro_n32_ABI/sgi_html/index.html -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Wed Feb 18 23:47:00 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5ED5B106564A for ; Wed, 18 Feb 2009 23:47:00 +0000 (UTC) (envelope-from pepe@rdc.cl) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id 39D218FC1A for ; Wed, 18 Feb 2009 23:46:59 +0000 (UTC) (envelope-from pepe@rdc.cl) Received: from pd6ml1no-ssvc.prod.shaw.ca ([10.0.153.160]) by pd6mo1no-svcs.prod.shaw.ca with ESMTP; 18 Feb 2009 16:18:38 -0700 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=0 a=8JW0u8jkzNyjOwQM3T8A:9 a=kr9GUh29niz5jHeGK1YA:7 a=pgZBv2HkYFcGyzuvcY55bbsSpHMA:4 Received: from unknown (HELO [192.168.1.203]) ([96.49.96.182]) by pd6ml1no-dmz.prod.shaw.ca with ESMTP; 18 Feb 2009 16:18:38 -0700 Message-Id: From: Jose Amengual M To: freebsd-current@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 18 Feb 2009 15:18:38 -0800 X-Mailer: Apple Mail (2.930.3) Subject: 7.1 amb64 boot problem after makeworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Feb 2009 23:47:01 -0000 Hi Guys. I have a estrange problem with a new install of 7.1 amd64. I install the system without problems, then I cvsup to update it, then make buildworld and all the jazz. I copy the GENERIC kernel and I didn't add any new option, just changed the ident to JAILS. I did the complete make installworld and installkernel and after the reboot I got this error : FreeBSD/i386 bootstrap loader, Revision 1.1 (blablabla) (blablabla) Can't work out witch disk we are booting from. Guessed Bios Device 0xConsoles; internal video/keyboard BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS drive D: is disk2 BIOS 639kB/3668480kb available memory and the message repeat again and again until reboots and then does the same cycle again. My make.conf file is : MAKEOPTS=-j3 CPUTYPE?=core2 CFLAGS=-O3 -pipe -fno-strict-aliasing -funroll-loops COPTFLAGS=-O2 -pipe -funroll-loops -ffast-math I have a Intel Quad core processor , 8 gigs of ram , asus p5k premium, nothing special. any ideas ? Thanks. From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 00:05:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 91351106566B for ; Thu, 19 Feb 2009 00:05:15 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id 233748FC08 for ; Thu, 19 Feb 2009 00:05:15 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n1J05EeF027102; Wed, 18 Feb 2009 16:05:14 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n1J05EoS027101; Wed, 18 Feb 2009 16:05:14 -0800 (PST) (envelope-from sgk) Date: Wed, 18 Feb 2009 16:05:14 -0800 From: Steve Kargl To: Jose Amengual M Message-ID: <20090219000514.GA27045@troutmask.apl.washington.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: 7.1 amb64 boot problem after makeworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 00:05:15 -0000 On Wed, Feb 18, 2009 at 03:18:38PM -0800, Jose Amengual M wrote: > CFLAGS=-O3 -pipe -fno-strict-aliasing -funroll-loops > COPTFLAGS=-O2 -pipe -funroll-loops -ffast-math Why? -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 00:08:28 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1AF2C1065672 for ; Thu, 19 Feb 2009 00:08:28 +0000 (UTC) (envelope-from pepe@rdc.cl) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id E71D08FC0C for ; Thu, 19 Feb 2009 00:08:27 +0000 (UTC) (envelope-from pepe@rdc.cl) Received: from pd7ml1no-ssvc.prod.shaw.ca ([10.0.153.161]) by pd7mo1no-svcs.prod.shaw.ca with ESMTP; 18 Feb 2009 17:08:27 -0700 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=0 a=LRvIzUzL8UvLEWFP9XYA:9 a=3fdhTVrYpa9uDp88fUPqsAaYaYEA:4 a=rzUpc4uwE_4A:10 Received: from unknown (HELO [192.168.1.203]) ([96.49.96.182]) by pd7ml1no-dmz.prod.shaw.ca with ESMTP; 18 Feb 2009 17:08:27 -0700 Message-Id: <354CC169-67AB-4913-8546-7D342AE56B40@rdc.cl> From: Jose Amengual M To: Steve Kargl In-Reply-To: <20090219000514.GA27045@troutmask.apl.washington.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 18 Feb 2009 16:08:26 -0800 References: <20090219000514.GA27045@troutmask.apl.washington.edu> X-Mailer: Apple Mail (2.930.3) Cc: freebsd-current@freebsd.org Subject: Re: 7.1 amb64 boot problem after makeworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 00:08:28 -0000 tuning ? just for tune up. I know that -O3 is not the best choice, but I read that is not harmful. or I'm wrong ? On 18-Feb-09, at 4:05 PM, Steve Kargl wrote: > On Wed, Feb 18, 2009 at 03:18:38PM -0800, Jose Amengual M wrote: >> CFLAGS=-O3 -pipe -fno-strict-aliasing -funroll-loops >> COPTFLAGS=-O2 -pipe -funroll-loops -ffast-math > > Why? > > -- > Steve From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 00:16:57 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 152631065670 for ; Thu, 19 Feb 2009 00:16:57 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.freebsd.org (Postfix) with ESMTP id E92848FC16 for ; Thu, 19 Feb 2009 00:16:56 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.3/8.14.3) with ESMTP id n1J0GuSE027211; Wed, 18 Feb 2009 16:16:56 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.3/8.14.3/Submit) id n1J0Guuj027210; Wed, 18 Feb 2009 16:16:56 -0800 (PST) (envelope-from sgk) Date: Wed, 18 Feb 2009 16:16:56 -0800 From: Steve Kargl To: Jose Amengual M Message-ID: <20090219001656.GA27187@troutmask.apl.washington.edu> References: <20090219000514.GA27045@troutmask.apl.washington.edu> <354CC169-67AB-4913-8546-7D342AE56B40@rdc.cl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <354CC169-67AB-4913-8546-7D342AE56B40@rdc.cl> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: 7.1 amb64 boot problem after makeworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 00:16:57 -0000 On Wed, Feb 18, 2009 at 04:08:26PM -0800, Jose Amengual M wrote: > On 18-Feb-09, at 4:05 PM, Steve Kargl wrote: > >On Wed, Feb 18, 2009 at 03:18:38PM -0800, Jose Amengual M wrote: > >>CFLAGS=-O3 -pipe -fno-strict-aliasing -funroll-loops > >>COPTFLAGS=-O2 -pipe -funroll-loops -ffast-math > > > >Why? > > > > tuning ? > > just for tune up. > > I know that -O3 is not the best choice, but I read that is not harmful. > > or I'm wrong ? > Please, do not top post. -ffast-math and -funroll-loops for the kernel? -- Steve From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 01:24:41 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B65371065672; Thu, 19 Feb 2009 01:24:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 5D3E28FC1A; Thu, 19 Feb 2009 01:24:41 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n1J1MqTx064206; Wed, 18 Feb 2009 18:22:52 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 18 Feb 2009 18:23:01 -0700 (MST) Message-Id: <20090218.182301.112148095.imp@bsdimp.com> To: xcllnt@mac.com From: "M. Warner Losh" In-Reply-To: References: <20090218200023.GU41617@deviant.kiev.zoral.com.ua> <20090218.143638.-1025539642.imp@bsdimp.com> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: kostikbel@gmail.com, mips@freebsd.org, tinderbox@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on mips/mips X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 01:24:42 -0000 In message: Marcel Moolenaar writes: : : On Feb 18, 2009, at 1:36 PM, M. Warner Losh wrote: : > MIPS does define it as well. I have all the old o32 docs, but have : > had trouble locating the n32/n64 docs since they were done by SGI and : > SGI is now defunct. : : http://wwweic.eri.u-tokyo.ac.jp/computer/manual/lx/SGI_Developer/books/Mpro_n32_ABI/sgi_html/index.html Excellent! Thanks! It actually is still at techpubs.sgi.com too... I could have sworn I looked there a while ago only to find nothing running... Warner From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 02:49:04 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4B120106564A for ; Thu, 19 Feb 2009 02:49:04 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 172718FC0C for ; Thu, 19 Feb 2009 02:49:03 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id C53C5125422; Thu, 19 Feb 2009 11:49:02 +0900 (JST) Message-ID: <499CC89E.2040408@ongs.co.jp> Date: Thu, 19 Feb 2009 11:49:02 +0900 From: Daichi GOTO User-Agent: Thunderbird 2.0.0.19 (X11/20090201) MIME-Version: 1.0 To: FreeBSD Current , Masanori OZAWA , Hans Petter Selasky Content-Type: multipart/mixed; boundary="------------090004080300070505020900" Cc: Subject: USB2: booting from usb memory issue, including a foolish patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 02:49:04 -0000 This is a multi-part message in MIME format. --------------090004080300070505020900 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi usb2 folks, first please give me a time to say congratulations! I'm very glad that usb2 is default usb stack right now :) Well but, bad news I have. I have known that usb2 stack have a issue around boot from usb devices. System has been engaging root filesystem mount treatment before completion of device proving in kernel main thread. It leads root mount fail, then system boot fails from usb device. So I have made a patch included. That patch sleeps 30 seconds before root mount treatment while a kernel thread doing usb2 device probing. Yes you know, very foolish patch but I have no idea to fix it in other way. If you have better ideas, please try and commit that. Thanks -- Daichi GOTO, http://people.freebsd.org/~daichi --------------090004080300070505020900 Content-Type: text/plain; name="init_main.c.diff" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="init_main.c.diff" LS0tIHN5cy9rZXJuL2luaXRfbWFpbi5jLm9yaWcJMjAwOS0wMi0xMSAwMTowMjowNy4wMDAw MDAwMDAgKzA5MDAKKysrIHN5cy9rZXJuL2luaXRfbWFpbi5jCTIwMDktMDItMTEgMDE6MDA6 NTMuMDAwMDAwMDAwICswOTAwCkBAIC02MDgsNiArNjA4LDggQEAKIAlzdHJ1Y3QgdGhyZWFk ICp0ZDsKIAlzdHJ1Y3QgcHJvYyAqcDsKIAorCXBhdXNlKCJXYWl0aW5nIGZvciBVU0IyIGRl dmljZXMuIiwgMzAwMDApOworCiAJbXR4X2xvY2soJkdpYW50KTsKIAogCUdJQU5UX1JFUVVJ UkVEOwo= --------------090004080300070505020900-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 03:41:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE0831065672 for ; Thu, 19 Feb 2009 03:41:20 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 40EE98FC08 for ; Thu, 19 Feb 2009 03:41:19 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (adsl183-211.kln.forthnet.gr [77.49.14.211]) (authenticated bits=128) by igloo.linux.gr (8.14.3/8.14.3/Debian-6) with ESMTP id n1J3fAJM012374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Feb 2009 05:41:17 +0200 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.3/8.14.3) with ESMTP id n1J3fAtK006825; Thu, 19 Feb 2009 05:41:10 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.3/8.14.3/Submit) id n1J3f8GO006824; Thu, 19 Feb 2009 05:41:08 +0200 (EET) (envelope-from keramida@ceid.upatras.gr) From: Giorgos Keramidas To: Daichi GOTO References: <499CC89E.2040408@ongs.co.jp> Date: Thu, 19 Feb 2009 05:41:07 +0200 In-Reply-To: <499CC89E.2040408@ongs.co.jp> (Daichi GOTO's message of "Thu, 19 Feb 2009 11:49:02 +0900") Message-ID: <87skmb8564.fsf@kobe.laptop> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.90 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Hellug-MailScanner-ID: n1J3fAJM012374 X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.878, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.52, BAYES_00 -2.60) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: FreeBSD Current , Masanori OZAWA , Hans Petter Selasky Subject: Re: USB2: booting from usb memory issue, including a foolish patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 03:41:21 -0000 On Thu, 19 Feb 2009 11:49:02 +0900, Daichi GOTO wrote: > Hi usb2 folks, first please give me a time to say congratulations! I'm > very glad that usb2 is default usb stack right now :) > > Well but, bad news I have. > > I have known that usb2 stack have a issue around boot from usb > devices. System has been engaging root filesystem mount treatment > before completion of device proving in kernel main thread. It leads > root mount fail, then system boot fails from usb device. > > So I have made a patch included. That patch sleeps 30 seconds before > root mount treatment while a kernel thread doing usb2 device probing. > > Yes you know, very foolish patch but I have no idea to fix it in other > way. If you have better ideas, please try and commit that. Delaying *all* boots for such a long time doesn't seem very good. It may be a good idea to patch usb2 to install a SYSINIT handler with SI_SUB_CONFIGURE, so that it gets a chance to hook itself at the end of the device configuration. I'll try to do this, unless Hans beats me to it of course :) From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 05:04:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB325106564A for ; Thu, 19 Feb 2009 05:04:08 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 6DA678FC1A for ; Thu, 19 Feb 2009 05:04:08 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id BFBEBFF2F; Thu, 19 Feb 2009 18:04:07 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jyyolm-f7z0; Thu, 19 Feb 2009 18:04:04 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Thu, 19 Feb 2009 18:04:04 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 0CA491142F; Thu, 19 Feb 2009 18:04:04 +1300 (NZDT) Date: Wed, 18 Feb 2009 21:04:03 -0800 From: Andrew Thompson To: Giorgos Keramidas Message-ID: <20090219050403.GB84647@citylink.fud.org.nz> References: <499CC89E.2040408@ongs.co.jp> <87skmb8564.fsf@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87skmb8564.fsf@kobe.laptop> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: FreeBSD Current , Daichi GOTO , Masanori OZAWA , Hans Petter Selasky Subject: Re: USB2: booting from usb memory issue, including a foolish patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 05:04:09 -0000 On Thu, Feb 19, 2009 at 05:41:07AM +0200, Giorgos Keramidas wrote: > On Thu, 19 Feb 2009 11:49:02 +0900, Daichi GOTO wrote: > > Hi usb2 folks, first please give me a time to say congratulations! I'm > > very glad that usb2 is default usb stack right now :) > > > > Well but, bad news I have. > > > > I have known that usb2 stack have a issue around boot from usb > > devices. System has been engaging root filesystem mount treatment > > before completion of device proving in kernel main thread. It leads > > root mount fail, then system boot fails from usb device. > > > > So I have made a patch included. That patch sleeps 30 seconds before > > root mount treatment while a kernel thread doing usb2 device probing. > > > > Yes you know, very foolish patch but I have no idea to fix it in other > > way. If you have better ideas, please try and commit that. > > Delaying *all* boots for such a long time doesn't seem very good. > > It may be a good idea to patch usb2 to install a SYSINIT handler with > SI_SUB_CONFIGURE, so that it gets a chance to hook itself at the end of > the device configuration. I'll try to do this, unless Hans beats me to > it of course :) There has already been a thread about this on usb@, maybe have a read first. http://lists.freebsd.org/pipermail/freebsd-usb/2009-February/006242.html Andrew From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 05:09:09 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D6F7106564A for ; Thu, 19 Feb 2009 05:09:09 +0000 (UTC) (envelope-from chflags@gmail.com) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.227]) by mx1.freebsd.org (Postfix) with ESMTP id F33878FC18 for ; Thu, 19 Feb 2009 05:09:08 +0000 (UTC) (envelope-from chflags@gmail.com) Received: by rv-out-0506.google.com with SMTP id f6so286247rvb.43 for ; Wed, 18 Feb 2009 21:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=vTAOAlK+C7Qc8rA7AALD5f1WgQ7mSbSG8RHVjbGHX8U=; b=EOWayFI7JKyIg7Vh62NZWaHqfFB3vs0CZsqfRSbYxnt0r8goAN29HhpHQGP47kmheo kolqrpAPQ+Do8MFRAJufsylJvng6pexTfCQDiHT/SYrXgakyeG6WiVo9fu95S3p8x833 ADR++6AuEEGJMTidGafwuJSljNJrXOD+Rhdro= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=yC6R8qUdUSsQtc7WPwkh/jQxLUHaIIV+vsvD62L/AB4+rXCk6E0LCVeA8pwC27F7fW GdVZxn6V+FOvMLPN3bbeRid+AQzy49YAOuZ4g4cvqEZ9YWSjubpG6iFoIS2GKdiycqN7 GgBTrAmYkFed0raKfv6IYcQ8z1fsQkmRXH7WA= MIME-Version: 1.0 Received: by 10.140.127.13 with SMTP id z13mr4361259rvc.145.1235018654352; Wed, 18 Feb 2009 20:44:14 -0800 (PST) In-Reply-To: References: Date: Thu, 19 Feb 2009 12:44:14 +0800 Message-ID: <25cb30902182044g18732b02i168e28f4f4f042a2@mail.gmail.com> From: Kevin Foo To: Jose Amengual M Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: 7.1 amb64 boot problem after makeworld X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: chflags@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 05:09:09 -0000 On Thu, Feb 19, 2009 at 7:18 AM, Jose Amengual M wrote: > CFLAGS=-O3 -pipe -fno-strict-aliasing -funroll-loops > COPTFLAGS=-O2 -pipe -funroll-loops -ffast-math > http://funroll-loops.info/ -- Regards Kevin Foo From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 07:29:38 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BFB2106566B for ; Thu, 19 Feb 2009 07:29:38 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 4B8598FC13 for ; Thu, 19 Feb 2009 07:29:38 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id A47731D2C2; Thu, 19 Feb 2009 08:29:37 +0100 (CET) Date: Thu, 19 Feb 2009 08:29:37 +0100 From: Ed Schouten To: Bruce Simpson Message-ID: <20090219072937.GB19161@hoeg.nl> References: <20090217110524.GC79178@hoeg.nl> <499A9C9D.3000403@protected-networks.net> <20090217115651.GE79178@hoeg.nl> <20090217175512.GG79178@hoeg.nl> <20090217182128.GH79178@hoeg.nl> <20090217192152.GI79178@hoeg.nl> <499C7992.7000705@incunabulum.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XOIedfhf+7KOe/yw" Content-Disposition: inline In-Reply-To: <499C7992.7000705@incunabulum.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: Michael Butler , current@freebsd.org, Maksim Yevmenkin Subject: Re: HEADS UP: IFF_NEEDSGIANT consumers to be disabled, removed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 07:29:38 -0000 --XOIedfhf+7KOe/yw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Bruce, * Bruce Simpson wrote: > Maksim seems to be talking about the use case where folk are actually= =20 > doing straight serial over RFCOMM and need to tie it down to a known tty,= =20 > though. Ah, that's indeed something I didn't know. Well, in that case we still need pseudo-terminals. > Surely there must be a way to tie rfcomm_sppd down to a specific pts = =20 > number, or failing that, teach it to report the pts which it got=20 > allocated? Well, with MPSAFE TTY the only way pseudo-terminals should be allocated, is by calling posix_openpt(). The device name is determined by a simple unrhdr (alloc_unr(9)). There is no actual way to influence the naming, so I guess we should make rfcomm_sppd just use a random device name. We could maybe solve this by creating a symlink to the TTY? --=20 Ed Schouten WWW: http://80386.nl/ --XOIedfhf+7KOe/yw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmdCmEACgkQ52SDGA2eCwVpKgCfQ2W+Ob+vFdeJZB7jPhfjldU3 H8UAn3J8/WFrsvQTeBuB6PhquuIYKJsd =vh40 -----END PGP SIGNATURE----- --XOIedfhf+7KOe/yw-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 07:44:02 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C2F5B106566B for ; Thu, 19 Feb 2009 07:44:02 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [IPv6:2001:7b8:613:100::211]) by mx1.freebsd.org (Postfix) with ESMTP id 7C0BF8FC23 for ; Thu, 19 Feb 2009 07:44:02 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id D07D91D0E8; Thu, 19 Feb 2009 08:44:01 +0100 (CET) Date: Thu, 19 Feb 2009 08:44:01 +0100 From: Ed Schouten To: Daichi GOTO Message-ID: <20090219074401.GC19161@hoeg.nl> References: <499CC89E.2040408@ongs.co.jp> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vOmOzSkFvhd7u8Ms" Content-Disposition: inline In-Reply-To: <499CC89E.2040408@ongs.co.jp> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: FreeBSD Current , Masanori OZAWA , Hans Petter Selasky Subject: Re: USB2: booting from usb memory issue, including a foolish patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 07:44:03 -0000 --vOmOzSkFvhd7u8Ms Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Daichi GOTO wrote: > Yes you know, very foolish patch but I have no idea to > fix it in other way. If you have better ideas, please > try and commit that. Maybe we should gain a "Waiting for 15 secons for SCSI devices to settle", but for the USB subsystem? --=20 Ed Schouten WWW: http://80386.nl/ --vOmOzSkFvhd7u8Ms Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmdDcEACgkQ52SDGA2eCwWtAwCZATC80g2FpnduTU5pACRIvPaE bCoAnRrI6Q8GP293def+PCsKQdq4ATV4 =uZCp -----END PGP SIGNATURE----- --vOmOzSkFvhd7u8Ms-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 07:54:39 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BA20106566B for ; Thu, 19 Feb 2009 07:54:39 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe11.swip.net [212.247.155.65]) by mx1.freebsd.org (Postfix) with ESMTP id 109858FC18 for ; Thu, 19 Feb 2009 07:54:38 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=pNvzuO4k8j8A:10 a=vHU9Hh9LfWEA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=6I5d2MoRAAAA:8 a=Oi4C4SF1dPtsklyxqigA:9 a=YsLX_SxPmYdA9LDa6zQA:7 a=_thJ5eeRvlvic2cRaTyqs4RhAYUA:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe11.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1026008523; Thu, 19 Feb 2009 08:54:37 +0100 From: Hans Petter Selasky To: Daichi GOTO Date: Thu, 19 Feb 2009 08:57:05 +0100 User-Agent: KMail/1.9.7 References: <499CC89E.2040408@ongs.co.jp> In-Reply-To: <499CC89E.2040408@ongs.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902190857.05883.hselasky@c2i.net> Cc: FreeBSD Current , Masanori OZAWA Subject: Re: USB2: booting from usb memory issue, including a foolish patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 07:54:39 -0000 On Thursday 19 February 2009, Daichi GOTO wrote: > Hi usb2 folks, first please give me a time to say > congratulations! I'm very glad that usb2 is default > usb stack right now :) > There is a better approach, see: http://wiki.freebsd.org/USB --HPS From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 08:08:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9C6E1065674 for ; Thu, 19 Feb 2009 08:08:08 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 7E1858FC0A for ; Thu, 19 Feb 2009 08:08:08 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 65DD1125422; Thu, 19 Feb 2009 17:08:07 +0900 (JST) Message-ID: <499D1367.9040509@ongs.co.jp> Date: Thu, 19 Feb 2009 17:08:07 +0900 From: Daichi GOTO User-Agent: Thunderbird 2.0.0.19 (X11/20090201) MIME-Version: 1.0 To: Ed Schouten References: <499CC89E.2040408@ongs.co.jp> <20090219074401.GC19161@hoeg.nl> In-Reply-To: <20090219074401.GC19161@hoeg.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Masanori OZAWA , Hans Petter Selasky Subject: Re: USB2: booting from usb memory issue, including a foolish patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 08:08:09 -0000 Ed Schouten wrote: > * Daichi GOTO wrote: >> Yes you know, very foolish patch but I have no idea to >> fix it in other way. If you have better ideas, please >> try and commit that. > > Maybe we should gain a "Waiting for 15 secons for SCSI devices to > settle", but for the USB subsystem? Mmmmh, if there are not SCSI devices, then usb subsystem (especially like USB memory) does not wait 15 secons. I do not know well around that area, so sorry. -- Daichi GOTO, http://people.freebsd.org/~daichi From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 08:11:30 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 554551065670 for ; Thu, 19 Feb 2009 08:11:30 +0000 (UTC) (envelope-from rink@rink.nu) Received: from mx1.rink.nu (gloom.rink.nu [213.34.49.2]) by mx1.freebsd.org (Postfix) with ESMTP id 173D78FC13 for ; Thu, 19 Feb 2009 08:11:29 +0000 (UTC) (envelope-from rink@rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id 5C7DA6D42B; Thu, 19 Feb 2009 09:13:20 +0100 (CET) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([213.34.49.2]) by localhost (gloom.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcPxhQxkOXb8; Thu, 19 Feb 2009 09:13:17 +0100 (CET) Received: by mx1.rink.nu (Postfix, from userid 1000) id F278B6D423; Thu, 19 Feb 2009 09:13:16 +0100 (CET) Date: Thu, 19 Feb 2009 09:13:16 +0100 From: Rink Springer To: Ed Schouten Message-ID: <20090219081316.GD15525@rink.nu> References: <499CC89E.2040408@ongs.co.jp> <20090219074401.GC19161@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090219074401.GC19161@hoeg.nl> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: FreeBSD Current , Daichi GOTO , Masanori OZAWA , Hans Petter Selasky Subject: Re: USB2: booting from usb memory issue, including a foolish patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 08:11:30 -0000 On Thu, Feb 19, 2009 at 08:44:01AM +0100, Ed Schouten wrote: > * Daichi GOTO wrote: > > Yes you know, very foolish patch but I have no idea to > > fix it in other way. If you have better ideas, please > > try and commit that. > > Maybe we should gain a "Waiting for 15 secons for SCSI devices to > settle", but for the USB subsystem? No thanks, it already takes aeons to boot FreeBSD, and adding extra delays for only USB devices will only make it worse :-( Isn't it possible to either use the CAM delay loop (which waits for SCSI devices) or just implement a generic "Waiting for devices" which both CAM and USB can use? -- Rink P.W. Springer - http://rink.nu "Chance favours the prepared mind" - Penn From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 08:12:19 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E50C1065670 for ; Thu, 19 Feb 2009 08:12:19 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from natial.ongs.co.jp (natial.ongs.co.jp [202.216.246.90]) by mx1.freebsd.org (Postfix) with ESMTP id 623A68FC18 for ; Thu, 19 Feb 2009 08:12:19 +0000 (UTC) (envelope-from daichi@ongs.co.jp) Received: from parancell.ongs.co.jp (dullmdaler.ongs.co.jp [202.216.246.94]) by natial.ongs.co.jp (Postfix) with ESMTPSA id 6D1B5125422; Thu, 19 Feb 2009 17:12:18 +0900 (JST) Message-ID: <499D1462.6030900@ongs.co.jp> Date: Thu, 19 Feb 2009 17:12:18 +0900 From: Daichi GOTO User-Agent: Thunderbird 2.0.0.19 (X11/20090201) MIME-Version: 1.0 To: Hans Petter Selasky References: <499CC89E.2040408@ongs.co.jp> <200902190857.05883.hselasky@c2i.net> In-Reply-To: <200902190857.05883.hselasky@c2i.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Masanori OZAWA Subject: Re: USB2: booting from usb memory issue, including a foolish patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 08:12:19 -0000 Hans Petter Selasky wrote: > On Thursday 19 February 2009, Daichi GOTO wrote: >> Hi usb2 folks, first please give me a time to say >> congratulations! I'm very glad that usb2 is default >> usb stack right now :) >> > > There is a better approach, see: > > http://wiki.freebsd.org/USB I have checked a patch on above URL (freesbie term), it looks like better than mine. How about to merge that patch to usb2 stack, HPS? If someone could add feature that waits all boot deives prove, that's best. And adding tuning feature of 16 seconds wait time by /boot/loader.conf, it's great. Anyone could do that? > --HPS > _______________________________________________ > 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" -- Daichi GOTO, http://people.freebsd.org/~daichi From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 08:29:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 168E2106566C for ; Thu, 19 Feb 2009 08:29:05 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe12.swipnet.se [212.247.155.97]) by mx1.freebsd.org (Postfix) with ESMTP id A0B8B8FC13 for ; Thu, 19 Feb 2009 08:29:04 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=pNvzuO4k8j8A:10 a=vHU9Hh9LfWEA:10 a=MXw7gxVQKqGXY79tIT8aFQ==:17 a=6I5d2MoRAAAA:8 a=oeLUo3TQgdawKVXUBysA:9 a=jxH31os3oCf9qPeM2MIA:7 a=_0O8i1wvUNhRbMW5zKK0_nVGiGsA:4 a=LY0hPdMaydYA:10 Received: from [62.113.132.61] (account mc467741@c2i.net HELO laptop) by mailfe12.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 1025864934; Thu, 19 Feb 2009 09:29:03 +0100 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Thu, 19 Feb 2009 09:31:31 +0100 User-Agent: KMail/1.9.7 References: <499CC89E.2040408@ongs.co.jp> <200902190857.05883.hselasky@c2i.net> <499D1462.6030900@ongs.co.jp> In-Reply-To: <499D1462.6030900@ongs.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902190931.32064.hselasky@c2i.net> Cc: Daichi GOTO , Masanori OZAWA Subject: Re: USB2: booting from usb memory issue, including a foolish patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 08:29:05 -0000 On Thursday 19 February 2009, Daichi GOTO wrote: > Hans Petter Selasky wrote: > > On Thursday 19 February 2009, Daichi GOTO wrote: > >> Hi usb2 folks, first please give me a time to say > >> congratulations! I'm very glad that usb2 is default > >> usb stack right now :) > > > > There is a better approach, see: > > > > http://wiki.freebsd.org/USB > > I have checked a patch on above URL (freesbie term), it looks > like better than mine. How about to merge that patch to usb2 > stack, HPS? > > If someone could add feature that waits all boot deives prove, > that's best. And adding tuning feature of 16 seconds wait > time by /boot/loader.conf, it's great. Anyone could do that? Could we change "mount", that if we specify some wait flag, it will simply loop in kernel and userland for a user specified amount of time? --HPS From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 06:31:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B15C5106566B for ; Thu, 19 Feb 2009 06:31:07 +0000 (UTC) (envelope-from mmakonnen@gmail.com) Received: from mail-bw0-f170.google.com (mail-bw0-f170.google.com [209.85.218.170]) by mx1.freebsd.org (Postfix) with ESMTP id CCAC88FC0C for ; Thu, 19 Feb 2009 06:31:06 +0000 (UTC) (envelope-from mmakonnen@gmail.com) Received: by bwz18 with SMTP id 18so839096bwz.19 for ; Wed, 18 Feb 2009 22:31:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=YGDaWwNTn/q40TuA55MHcRL9cwKPLiRTfTalFeuXWto=; b=Lnd0RSzElgjsYm8EICJMDjxfzMhz7wQYPXiUrFTF/zaSloBj6WXgN7zlT1pSUC8IE7 in7yIhk3O41aWVjzTAGRWX6Phj3TNguJm7MWU1/rtZwIuLYr9/DZQcmYXlrYfAFCRM48 H0jT5J1frydM069l1MNBs8zgDqfFQZD4ib7OQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=TjamH76uiUOxXOd22fueWY3CahoRBdI+XOz9qwRn8rE0rz9/hwG0wVvAJOz7wYYKZu zlU3ilbfrSHWfb+6PqxpstCBQGUiZw5jnPoRMwLsuyyrMFe5vKA4iaX1WBS+TwpYgXEd h9v//A7qYUf+Q+9xWu/MlDTlQFO0H8oN5aTwY= Received: by 10.223.107.19 with SMTP id z19mr5055103fao.27.1235025064651; Wed, 18 Feb 2009 22:31:04 -0800 (PST) Received: from storm.mike.lan ([213.55.69.180]) by mx.google.com with ESMTPS id 34sm1284141nfu.77.2009.02.18.22.30.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Feb 2009 22:31:04 -0800 (PST) Message-ID: <499CFC13.5040709@gmail.com> Date: Thu, 19 Feb 2009 09:28:35 +0300 From: Mike Makonnen User-Agent: Thunderbird 2.0.0.19 (X11/20090201) MIME-Version: 1.0 To: Andrew Gallatin References: <7d6fde3d0902150028n5f07ee55mc6026e1e4935eeb0@mail.gmail.com> <20090215153531.GA36438@wep4035.physik.uni-wuerzburg.de> <49998707.40205@gmail.com> <20090216210118.GA85984@wep4035.physik.uni-wuerzburg.de> <499A55AB.9080606@gmail.com> <20090217161921.A78099@grasshopper.cs.duke.edu> In-Reply-To: <20090217161921.A78099@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 19 Feb 2009 12:14:24 +0000 Cc: Alexey Shuvaev , Garrett Cooper , FreeBSD Current , Brooks Davis Subject: Re: Re: Annoyance with recent parallelism in rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 06:31:07 -0000 CC'ing Brooks since he was the one who originally introduced it. Andrew Gallatin wrote: > > Maybe synchronous_dhclient=yes should be the default, as there are a > lot of cases of it not working async? That seems like the better solution to me too. >I had horribly annoying > problems with NFS failing (via amd using NIS based maps) at boot on > different machines 90% of the time. Some use bge, and others use nfe. > > At least in my case, there was no "reset". Eg: > > /dev/da0s2g: clean, 1992874 free (138 frags, 249092 blocks, 0.0% fragmentation) > bge0: link state changed to DOWN > Starting Network: lo0 bge0. > bge1: link state changed to DOWN > Setting date via ntp. > 13 Feb 13:41:48 ntpdate[638]: no servers can be used, exiting > Setting NIS domain: sw.myri.com. > Starting rpcbind. > /etc/rc: WARNING: failed to start amd > Recovering vi editor sessions:. > > Setting synchronous_dhclient=yes seems to have fixed it for me. > > Drew > Cheers. -- Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 FreeBSD | http://www.freebsd.org From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 07:50:03 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36BBC106566B for ; Thu, 19 Feb 2009 07:50:03 +0000 (UTC) (envelope-from root@free.fr) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by mx1.freebsd.org (Postfix) with ESMTP id DA9088FC29 for ; Thu, 19 Feb 2009 07:50:01 +0000 (UTC) (envelope-from root@free.fr) Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id 062F94C8092 for ; Thu, 19 Feb 2009 08:49:57 +0100 (CET) Received: from free.fr (evr27-1-88-172-40-194.fbx.proxad.net [88.172.40.194]) by smtp4-g21.free.fr (Postfix) with ESMTP id 1B2F04C8142 for ; Thu, 19 Feb 2009 08:49:55 +0100 (CET) To: freebsd-current@freebsd.org Date: Thu, 19 Feb 2009 08:49:50 +0100 From: raoul megelas Message-Id: <20090219074955.1B2F04C8142@smtp4-g21.free.fr> X-Mailman-Approved-At: Thu, 19 Feb 2009 12:24:40 +0000 Subject: Re: man usb2_core(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 07:50:03 -0000 On Wed, 18 Feb 2009 22:44:41 +0100 Hans Petter Selasky wrote: > On Wednesday 18 February 2009, rmgls@free.fr wrote: > src/share/man/man4/usb2_core.4 Thanks, hope this help! Raoul rmgls@free.fr From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 15:28:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF12F1065670 for ; Thu, 19 Feb 2009 15:28:53 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 9B00B8FC19 for ; Thu, 19 Feb 2009 15:28:53 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 820A4FF3A; Fri, 20 Feb 2009 04:28:52 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iX6rlug+tWxJ; Fri, 20 Feb 2009 04:28:48 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Fri, 20 Feb 2009 04:28:48 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 3D66D1142F; Fri, 20 Feb 2009 04:28:48 +1300 (NZDT) Date: Thu, 19 Feb 2009 07:28:48 -0800 From: Andrew Thompson To: Rink Springer Message-ID: <20090219152848.GA85154@citylink.fud.org.nz> References: <499CC89E.2040408@ongs.co.jp> <20090219074401.GC19161@hoeg.nl> <20090219081316.GD15525@rink.nu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090219081316.GD15525@rink.nu> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Ed Schouten , FreeBSD Current , Daichi GOTO , Masanori OZAWA , Hans Petter Selasky Subject: Re: USB2: booting from usb memory issue, including a foolish patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 15:28:54 -0000 On Thu, Feb 19, 2009 at 09:13:16AM +0100, Rink Springer wrote: > On Thu, Feb 19, 2009 at 08:44:01AM +0100, Ed Schouten wrote: > > * Daichi GOTO wrote: > > > Yes you know, very foolish patch but I have no idea to > > > fix it in other way. If you have better ideas, please > > > try and commit that. > > > > Maybe we should gain a "Waiting for 15 secons for SCSI devices to > > settle", but for the USB subsystem? > > No thanks, it already takes aeons to boot FreeBSD, and adding extra > delays for only USB devices will only make it worse :-( I think it was meant to be a joke. From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 17:23:55 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A060A1065679; Thu, 19 Feb 2009 17:23:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5978A8FC1E; Thu, 19 Feb 2009 17:23:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1JHNq3o088641; Thu, 19 Feb 2009 12:23:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1JHNqVa019478; Thu, 19 Feb 2009 12:23:52 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E20527302F; Thu, 19 Feb 2009 12:23:51 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090219172351.E20527302F@freebsd-current.sentex.ca> Date: Thu, 19 Feb 2009 12:23:51 -0500 (EST) X-Virus-Scanned: ClamAV 0.94.1/8983/Thu Feb 12 07:48:01 2009 clamav-milter version 0.94.2 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 17:23:56 -0000 TB --- 2009-02-19 15:55:38 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-19 15:55:38 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-02-19 15:55:38 - cleaning the object tree TB --- 2009-02-19 15:56:12 - cvsupping the source tree TB --- 2009-02-19 15:56:12 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-02-19 15:56:20 - building world TB --- 2009-02-19 15:56:20 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-19 15:56:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-19 15:56:20 - TARGET=pc98 TB --- 2009-02-19 15:56:20 - TARGET_ARCH=i386 TB --- 2009-02-19 15:56:20 - TZ=UTC TB --- 2009-02-19 15:56:20 - __MAKE_CONF=/dev/null TB --- 2009-02-19 15:56:20 - cd /src TB --- 2009-02-19 15:56:20 - /usr/bin/make -B buildworld >>> World build started on Thu Feb 19 15:56:22 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Feb 19 17:18:01 UTC 2009 TB --- 2009-02-19 17:18:01 - generating LINT kernel config TB --- 2009-02-19 17:18:01 - cd /src/sys/pc98/conf TB --- 2009-02-19 17:18:01 - /usr/bin/make -B LINT TB --- 2009-02-19 17:18:01 - building LINT kernel TB --- 2009-02-19 17:18:01 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-19 17:18:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-19 17:18:01 - TARGET=pc98 TB --- 2009-02-19 17:18:01 - TARGET_ARCH=i386 TB --- 2009-02-19 17:18:01 - TZ=UTC TB --- 2009-02-19 17:18:01 - __MAKE_CONF=/dev/null TB --- 2009-02-19 17:18:01 - cd /src TB --- 2009-02-19 17:18:01 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Feb 19 17:18:01 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-lowlevel.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-queue.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-card.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-cbus.c /src/sys/dev/ata/ata-cbus.c: In function 'ata_cbuschannel_detach': /src/sys/dev/ata/ata-cbus.c:308: error: 'ch' undeclared (first use in this function) /src/sys/dev/ata/ata-cbus.c:308: error: (Each undeclared identifier is reported only once /src/sys/dev/ata/ata-cbus.c:308: error: for each function it appears in.) *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-19 17:23:51 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-19 17:23:51 - ERROR: failed to build lint kernel TB --- 2009-02-19 17:23:51 - 4112.88 user 419.67 system 5293.09 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 18:02:41 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD7E810656CE; Thu, 19 Feb 2009 18:02:41 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (merlin.alerce.com [64.62.142.94]) by mx1.freebsd.org (Postfix) with ESMTP id 937958FC27; Thu, 19 Feb 2009 18:02:41 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 541BA33C62; Thu, 19 Feb 2009 10:02:41 -0800 (PST) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id CA20D33C5B; Thu, 19 Feb 2009 10:02:40 -0800 (PST) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18845.40641.33220.936902@almost.alerce.com> Date: Thu, 19 Feb 2009 10:02:41 -0800 To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org X-Mailer: VM 8.0.12 under 22.1.50.1 (i386-apple-darwin8.11.1) X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Thu, 19 Feb 2009 18:11:13 +0000 Cc: goran.lowkrantz@ismobile.com, Pawel Jakub Dawidek Subject: Patch for 'zfs send -R' core dump (pr bin/130105) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hartzell@alerce.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 18:02:42 -0000 The following patch to /usr/src/sys/cddl/contrib/opensolaris/common/zfs/zfs_prop.c seems to keep 'zfs send -R' from dumping core. I've only been able to test sending the stream to /dev/null or a file, I'm still setting up a pool to do the receiving. This is based on a bit of gdb debugging and a thread from zfs-fuse: http://groups.google.com/group/zfs-fuse/browse_thread/thread/158cb78bc3325ae3/6a0109c7b0942707?#6a0109c7b0942707 g. --- zfs_prop.c 2009/02/17 18:58:58 1.1 +++ zfs_prop.c 2009/02/19 09:54:04 @@ -297,7 +297,7 @@ /* hidden properties */ register_hidden(ZFS_PROP_CREATETXG, "createtxg", PROP_TYPE_NUMBER, - PROP_READONLY, ZFS_TYPE_DATASET, NULL); + PROP_READONLY, ZFS_TYPE_DATASET, "CREATETXG"); register_hidden(ZFS_PROP_NUMCLONES, "numclones", PROP_TYPE_NUMBER, PROP_READONLY, ZFS_TYPE_SNAPSHOT, NULL); register_hidden(ZFS_PROP_NAME, "name", PROP_TYPE_STRING, From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 18:14:20 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75D1D106568E; Thu, 19 Feb 2009 18:14:20 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (77-93-215-190.static.masterinter.net [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 281AD8FC28; Thu, 19 Feb 2009 18:14:19 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 930B59CB15D; Thu, 19 Feb 2009 19:11:17 +0100 (CET) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hws6gqYwACZS; Thu, 19 Feb 2009 19:11:15 +0100 (CET) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id 497349CB16C; Thu, 19 Feb 2009 19:11:15 +0100 (CET) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id n1JIBE9A057623; Thu, 19 Feb 2009 19:11:14 +0100 (CET) (envelope-from rdivacky) Date: Thu, 19 Feb 2009 19:11:14 +0100 From: Roman Divacky To: George Hartzell Message-ID: <20090219181114.GA57360@freebsd.org> References: <18845.40641.33220.936902@almost.alerce.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18845.40641.33220.936902@almost.alerce.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@freebsd.org, goran.lowkrantz@ismobile.com, freebsd-current@freebsd.org, Pawel Jakub Dawidek Subject: Re: Patch for 'zfs send -R' core dump (pr bin/130105) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 18:14:20 -0000 btw.... I track the opensolaris hg at work and there's a quite a few commits to zfs (almost) every week. fixing coredumps and other problems. maybe we can track the opensolaris a little closer? On Thu, Feb 19, 2009 at 10:02:41AM -0800, George Hartzell wrote: > > The following patch to > > /usr/src/sys/cddl/contrib/opensolaris/common/zfs/zfs_prop.c > > seems to keep 'zfs send -R' from dumping core. I've only been able to > test sending the stream to /dev/null or a file, I'm still setting up a > pool to do the receiving. > > This is based on a bit of gdb debugging and a thread from zfs-fuse: > > http://groups.google.com/group/zfs-fuse/browse_thread/thread/158cb78bc3325ae3/6a0109c7b0942707?#6a0109c7b0942707 > > g. > > --- zfs_prop.c 2009/02/17 18:58:58 1.1 > +++ zfs_prop.c 2009/02/19 09:54:04 > @@ -297,7 +297,7 @@ > > /* hidden properties */ > register_hidden(ZFS_PROP_CREATETXG, "createtxg", PROP_TYPE_NUMBER, > - PROP_READONLY, ZFS_TYPE_DATASET, NULL); > + PROP_READONLY, ZFS_TYPE_DATASET, "CREATETXG"); > register_hidden(ZFS_PROP_NUMCLONES, "numclones", PROP_TYPE_NUMBER, > PROP_READONLY, ZFS_TYPE_SNAPSHOT, NULL); > register_hidden(ZFS_PROP_NAME, "name", PROP_TYPE_STRING, > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 18:20:49 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27B581065670 for ; Thu, 19 Feb 2009 18:20:49 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (merlin.alerce.com [64.62.142.94]) by mx1.freebsd.org (Postfix) with ESMTP id 08F438FC1F for ; Thu, 19 Feb 2009 18:20:48 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id B0CCC33C62 for ; Thu, 19 Feb 2009 10:20:48 -0800 (PST) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 73ED733C5B for ; Thu, 19 Feb 2009 10:20:48 -0800 (PST) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18845.41728.753753.864779@almost.alerce.com> Date: Thu, 19 Feb 2009 10:20:48 -0800 To: freebsd-current@freebsd.org X-Mailer: VM 8.0.12 under 22.1.50.1 (i386-apple-darwin8.11.1) X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Thu, 19 Feb 2009 18:40:07 +0000 Subject: help generating good id string for ATA id fix (Via VB8001) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hartzell@alerce.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 18:20:49 -0000 I have a Via VB8001 running -CURRENT. The disk controllers aren't recognized and end up running in UDMA33. The following patches to things under /usr/src/sys/dev/ata recognize my drives as SATA300. I don't know how to figure out what id strings to use though, everything I've found about the board claims that the chip is a 8237S, which is already used. Clearly calling it the GH is a hack. How can I track down the correct info so that I can submit a useful PR? I've tacked the machine's pciconf -lv output onto the end in case it's useful. Thanks. --- ata-pci.h 2009/02/16 18:06:53 1.1 +++ ata-pci.h 2009/02/19 10:12:36 @@ -390,6 +390,7 @@ #define ATA_VIA8237 0x32271106 #define ATA_VIA8237A 0x05911106 #define ATA_VIA8237S 0x53371106 +#define ATA_VIA8237GH 0x53721106 #define ATA_VIA8251 0x33491106 #define ATA_VIA8361 0x31121106 #define ATA_VIA8363 0x03051106 --- chipsets/ata-via.c 2009/02/16 18:10:45 1.1 +++ chipsets/ata-via.c 2009/02/16 18:12:02 @@ -94,6 +94,7 @@ { ATA_VIA8237, 0x00, VIA133, 0x00, ATA_UDMA6, "8237" }, { ATA_VIA8237A, 0x00, VIA133, 0x00, ATA_UDMA6, "8237A" }, { ATA_VIA8237S, 0x00, VIA133, 0x00, ATA_UDMA6, "8237S" }, + { ATA_VIA8237GH, 0x00, VIA133, 0x00, ATA_UDMA6, "8237GH" }, { ATA_VIA8251, 0x00, VIA133, 0x00, ATA_UDMA6, "8251" }, { 0, 0, 0, 0, 0, 0 }}; static struct ata_chip_id new_ids[] = @@ -102,6 +103,7 @@ { ATA_VIA6421, 0x00, 6, VIABAR, ATA_SA150, "6421" }, { ATA_VIA8237A, 0x00, 7, 0x00, ATA_SA150, "8237A" }, { ATA_VIA8237S, 0x00, 7, 0x00, ATA_SA150, "8237S" }, + { ATA_VIA8237GH, 0x00, 7, 0x00, ATA_SA300, "8237GH" }, { ATA_VIA8251, 0x00, 0, VIAAHCI, ATA_SA300, "8251" }, { 0, 0, 0, 0, 0, 0 }}; === pciconf -lv output ================================================ hostb0@pci0:0:0:0: class=0x060000 card=0xaa111106 chip=0x03641106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'P4M900 Host Bridge' class = bridge subclass = HOST-PCI hostb1@pci0:0:0:1: class=0x060000 card=0x00000000 chip=0x13641106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'P4M900 Host Bridge' class = bridge subclass = HOST-PCI hostb2@pci0:0:0:2: class=0x060000 card=0x00000000 chip=0x23641106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'P4M900 Host Bridge' class = bridge subclass = HOST-PCI hostb3@pci0:0:0:3: class=0x060000 card=0x00000000 chip=0x33641106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'P4M900 Host Bridge' class = bridge subclass = HOST-PCI hostb4@pci0:0:0:4: class=0x060000 card=0x00000000 chip=0x43641106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'P4M900 Host Bridge' class = bridge subclass = HOST-PCI ioapic0@pci0:0:0:5: class=0x080020 card=0x00000000 chip=0x53641106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'P4M900 I/O APIC Interrupt Controller' class = base peripheral subclass = interrupt controller hostb5@pci0:0:0:6: class=0x060000 card=0x00000000 chip=0x63641106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'P4M900 Security Device' class = bridge subclass = HOST-PCI hostb6@pci0:0:0:7: class=0x060000 card=0x00000000 chip=0x73641106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'P4M900 Host Bridge' class = bridge subclass = HOST-PCI pcib1@pci0:0:1:0: class=0x060400 card=0x00000000 chip=0xb1981106 rev=0x00 hdr=0x01 vendor = 'VIA Technologies Inc' device = 'ProSavageDDR P4X600,Apollo KT400/A/600 CPU to AGP Bridge' class = bridge subclass = PCI-PCI pcib2@pci0:0:2:0: class=0x060400 card=0xc3231106 chip=0xa3641106 rev=0x80 hdr=0x01 vendor = 'VIA Technologies Inc' device = 'P4M900 PCI to PCI Bridge Controller' class = bridge subclass = PCI-PCI pcib3@pci0:0:3:0: class=0x060400 card=0xc3231106 chip=0xc3641106 rev=0x80 hdr=0x01 vendor = 'VIA Technologies Inc' device = 'P4M900 PCI to PCI Bridge Controller' class = bridge subclass = PCI-PCI atapci0@pci0:0:15:0: class=0x01018f card=0x53721106 chip=0x53721106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' class = mass storage subclass = ATA atapci1@pci0:0:15:1: class=0x01018a card=0x05711106 chip=0x05711106 rev=0x07 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT82C586A/B/VT82C686/A/B/VT823x/A/C Bus Master IDE Controller' class = mass storage subclass = ATA uhci0@pci0:0:16:0: class=0x0c0300 card=0x30381106 chip=0x30381106 rev=0xb0 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT83C572, VT6202 VIA Rev 5 or later USB Universal Host Controller' class = serial bus subclass = USB uhci1@pci0:0:16:1: class=0x0c0300 card=0x30381106 chip=0x30381106 rev=0xb0 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT83C572, VT6202 VIA Rev 5 or later USB Universal Host Controller' class = serial bus subclass = USB uhci2@pci0:0:16:2: class=0x0c0300 card=0x30381106 chip=0x30381106 rev=0xb0 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT83C572, VT6202 VIA Rev 5 or later USB Universal Host Controller' class = serial bus subclass = USB uhci3@pci0:0:16:3: class=0x0c0300 card=0x30381106 chip=0x30381106 rev=0xb0 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT83C572, VT6202 VIA Rev 5 or later USB Universal Host Controller' class = serial bus subclass = USB ehci0@pci0:0:16:4: class=0x0c0320 card=0x31041106 chip=0x31041106 rev=0x90 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT6202/12 USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB isab0@pci0:0:17:0: class=0x060100 card=0xaa111106 chip=0x33721106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' class = bridge subclass = PCI-ISA hostb7@pci0:0:17:7: class=0x060000 card=0x337e1106 chip=0x287e1106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT8251 Ultra VLINK Controller' class = bridge subclass = HOST-PCI hostb8@pci0:0:19:0: class=0x060000 card=0x00000000 chip=0x337b1106 rev=0x00 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT8237A Standard PCI to PCIe Bridge' class = bridge subclass = HOST-PCI pcib4@pci0:0:19:1: class=0x060401 card=0x337a1106 chip=0x337a1106 rev=0x00 hdr=0x01 vendor = 'VIA Technologies Inc' device = 'VT8237A Standard PCI to PCI Bridge' class = bridge subclass = PCI-PCI vgapci0@pci0:1:0:0: class=0x030000 card=0x33711106 chip=0x33711106 rev=0x01 hdr=0x00 vendor = 'VIA Technologies Inc' class = display subclass = VGA vge0@pci0:3:0:0: class=0x020000 card=0x01101106 chip=0x31191106 rev=0x82 hdr=0x00 vendor = 'VIA Technologies Inc' device = 'VT6120/VT6121/VT6122 'Velocity' Gigabit Ethernet Controllers' class = network subclass = ethernet none0@pci0:128:1:0: class=0x040300 card=0x32881106 chip=0x32881106 rev=0x10 hdr=0x00 vendor = 'VIA Technologies Inc' device = '??? VIA VT8251/8237A High Definition Audio Controller - HDA Codec Realtek ALC660' class = multimedia subclass = HDA From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 19:32:22 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B83F81065714 for ; Thu, 19 Feb 2009 19:32:22 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 82F018FC0C for ; Thu, 19 Feb 2009 19:32:22 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.38] (S0106001372fd1e07.vs.shawcable.net [70.71.171.106]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id n1JJWJ62023079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Feb 2009 11:32:19 -0800 (PST) (envelope-from sobomax@FreeBSD.org) Message-ID: <499DB399.4000604@FreeBSD.org> Date: Thu, 19 Feb 2009 11:31:37 -0800 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: hartzell@alerce.com References: <18845.41728.753753.864779@almost.alerce.com> In-Reply-To: <18845.41728.753753.864779@almost.alerce.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: help generating good id string for ATA id fix (Via VB8001) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 19:32:23 -0000 George Hartzell wrote: > I have a Via VB8001 running -CURRENT. The disk controllers aren't > recognized and end up running in UDMA33. > > The following patches to things under /usr/src/sys/dev/ata recognize > my drives as SATA300. > > I don't know how to figure out what id strings to use though, > everything I've found about the board claims that the chip is a 8237S, > which is already used. Clearly calling it the GH is a hack. > > How can I track down the correct info so that I can submit a useful > PR? Why does it matter so much? Call it ATA_VIA8237S_1 or ATA_VIA8237S_5372 for example, this is definitely not the first time in history when vendor use different PCI Id for the different silicon revisions of the same part. -Maxim From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 19:56:56 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79C25106566B for ; Thu, 19 Feb 2009 19:56:56 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 50E108FC13 for ; Thu, 19 Feb 2009 19:56:56 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id D930D46B2D; Thu, 19 Feb 2009 14:56:55 -0500 (EST) Date: Thu, 19 Feb 2009 19:56:55 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Hans Petter Selasky In-Reply-To: <200902190931.32064.hselasky@c2i.net> Message-ID: References: <499CC89E.2040408@ongs.co.jp> <200902190857.05883.hselasky@c2i.net> <499D1462.6030900@ongs.co.jp> <200902190931.32064.hselasky@c2i.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Daichi GOTO , Masanori OZAWA Subject: Re: USB2: booting from usb memory issue, including a foolish patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 19:56:56 -0000 On Thu, 19 Feb 2009, Hans Petter Selasky wrote: >> I have checked a patch on above URL (freesbie term), it looks like better >> than mine. How about to merge that patch to usb2 stack, HPS? >> >> If someone could add feature that waits all boot deives prove, that's best. >> And adding tuning feature of 16 seconds wait time by /boot/loader.conf, >> it's great. Anyone could do that? > > Could we change "mount", that if we specify some wait flag, it will simply > loop in kernel and userland for a user specified amount of time? I thought run_interrupt_driven_config_hooks(), done at SI_SUB_INT_CONFIG_HOOKS, allowed subsystems such as SCSI to suspend the boot while they finish probing, and root_mount_hold() similarly allowed higher level subsystems such as GEOM modules to delay the root mount while they do their bit. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 21:04:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1588C10656C6; Thu, 19 Feb 2009 21:04:22 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello087206045082.chello.pl [87.206.45.82]) by mx1.freebsd.org (Postfix) with ESMTP id BFFCA8FC1D; Thu, 19 Feb 2009 21:04:20 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 04118456AB; Thu, 19 Feb 2009 21:35:16 +0100 (CET) Received: from localhost (chello087206045082.chello.pl [87.206.45.82]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id E450645685; Thu, 19 Feb 2009 21:35:09 +0100 (CET) Date: Thu, 19 Feb 2009 21:35:41 +0100 From: Pawel Jakub Dawidek To: Roman Divacky Message-ID: <20090219203541.GB2083@garage.freebsd.pl> References: <18845.40641.33220.936902@almost.alerce.com> <20090219181114.GA57360@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vGgW1X5XWziG23Ko" Content-Disposition: inline In-Reply-To: <20090219181114.GA57360@freebsd.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 8.0-CURRENT i386 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.0 tests=BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-fs@freebsd.org, goran.lowkrantz@ismobile.com, freebsd-current@freebsd.org, George Hartzell Subject: Re: Patch for 'zfs send -R' core dump (pr bin/130105) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 21:04:22 -0000 --vGgW1X5XWziG23Ko Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 19, 2009 at 07:11:14PM +0100, Roman Divacky wrote: >=20 > btw.... I track the opensolaris hg at work and there's a quite a few comm= its > to zfs (almost) every week. fixing coredumps and other problems. >=20 > maybe we can track the opensolaris a little closer? It is beeing tracked very close, I'd say, in perforce (//depot/user/pjd/zfs/...). The problem is that trivial fixes are mixed with very intrusive changes, so it is too risky to track it even in HEAD (I'm running HEAD on my ZFS-only laptop!). OpenSolaris development is also very different from FreeBSD's. We use to describe every single change very carefully in commit logs, where OpenSolaris commits are based only on bug number and bug descriptions. Many changes are committed at once, so it is hard to pick only some changes. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --vGgW1X5XWziG23Ko Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFJncKcForvXbEpPzQRAgXhAKDf5XViG1Dp9qhZLW6NKUPL9bJXXwCgsfCn XJahA62CiDpUGk5jmzg45Eg= =H+Gt -----END PGP SIGNATURE----- --vGgW1X5XWziG23Ko-- From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 21:34:15 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CDBB106566C for ; Thu, 19 Feb 2009 21:34:15 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (merlin.alerce.com [64.62.142.94]) by mx1.freebsd.org (Postfix) with ESMTP id 713B08FC19 for ; Thu, 19 Feb 2009 21:34:15 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 0F3B533C62; Thu, 19 Feb 2009 13:34:15 -0800 (PST) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 8747633C5B; Thu, 19 Feb 2009 13:34:14 -0800 (PST) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18845.53334.624408.594679@almost.alerce.com> Date: Thu, 19 Feb 2009 13:34:14 -0800 To: Maxim Sobolev In-Reply-To: <499DB399.4000604@FreeBSD.org> References: <18845.41728.753753.864779@almost.alerce.com> <499DB399.4000604@FreeBSD.org> X-Mailer: VM 8.0.12 under 22.1.50.1 (i386-apple-darwin8.11.1) X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Thu, 19 Feb 2009 22:04:03 +0000 Cc: freebsd-current@FreeBSD.org, hartzell@alerce.com Subject: Re: help generating good id string for ATA id fix (Via VB8001) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hartzell@alerce.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 21:34:15 -0000 Maxim Sobolev writes: > George Hartzell wrote: > > I have a Via VB8001 running -CURRENT. The disk controllers aren't > > recognized and end up running in UDMA33. > > > > The following patches to things under /usr/src/sys/dev/ata recognize > > my drives as SATA300. > > > > I don't know how to figure out what id strings to use though, > > everything I've found about the board claims that the chip is a 8237S, > > which is already used. Clearly calling it the GH is a hack. > > > > How can I track down the correct info so that I can submit a useful > > PR? > > Why does it matter so much? Call it ATA_VIA8237S_1 or ATA_VIA8237S_5372 > for example, this is definitely not the first time in history when > vendor use different PCI Id for the different silicon revisions of the > same part. It doesn't matter to me, but for the same reason it's useful to choose evocative and mnemonic variable name I'd be willing to do a bit of leg work to actually call it with it's proper name. The obvious (to me) googling and such didn't get me anywhere and I'm not sure where to turn next. If sos@ or whoever else eventually commits it is happy with ATA_VIA8237S_1 then I'll move on to other stuff. g. From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 22:15:23 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C21E31065706; Thu, 19 Feb 2009 22:15:23 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from maste.org (emaste.tor.istop.com [66.11.182.63]) by mx1.freebsd.org (Postfix) with ESMTP id 8E5958FC19; Thu, 19 Feb 2009 22:15:23 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: by maste.org (Postfix, from userid 1001) id 954D9D5; Thu, 19 Feb 2009 22:02:49 +0000 (UTC) Date: Thu, 19 Feb 2009 22:02:49 +0000 From: Ed Maste To: freebsd-current@freebsd.org Message-ID: <20090219220249.GA35945@jem.dhs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: attilio@freebsd.org Subject: Re: svn commit: r188743 - head/sys/dev/aac X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 22:15:24 -0000 (Sorry if multiple copies of this email come through -- $WORK's email infrastructure is having some issues) On Wed, Feb 18, 2009 at 01:36:20AM +0000, Ed Maste wrote: > Author: emaste > Date: Wed Feb 18 01:36:20 2009 > New Revision: 188743 > URL: http://svn.freebsd.org/changeset/base/188743 > > Log: > Use outbound message register 0 instead of mailbox 7 in > aac_{rx,rkt}_get_fwstatus, as done in Adaptec's vendor driver as well as > the Linux drivers. > > Submitted by: jkim, from Adaptec's driver This change to the aac(4) driver comes from Adaptec's vendor driver, but it might break older controllers (Dell PERC 3, Adaptec 2200, etc.) and/or controllers running with older firmware. If you're able to test with this change on such an adapter, please let me know whether or not it works for you and which controller and firmware you have. If the driver is going to fail with this change, it should happen at attach time. (Make sure you still have a kernel without the change saved away.) If it does fail, please test with the patch at http://people.freebsd.org/~emaste/patches/aac_fwstatus_new_comm.diff and let me know if that fixes it. Thanks, Ed From owner-freebsd-current@FreeBSD.ORG Thu Feb 19 22:44:41 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E58D51065672 for ; Thu, 19 Feb 2009 22:44:41 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by mx1.freebsd.org (Postfix) with ESMTP id D64098FC18 for ; Thu, 19 Feb 2009 22:44:39 +0000 (UTC) (envelope-from jeremie@le-hen.org) Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 5F7AD818096; Thu, 19 Feb 2009 23:44:34 +0100 (CET) Received: from endor.tataz.chchile.org (tataz.chchile.org [82.233.239.98]) by smtp3-g21.free.fr (Postfix) with ESMTP id 46D418180AB; Thu, 19 Feb 2009 23:44:32 +0100 (CET) Received: from obiwan.tataz.chchile.org (endor.tataz.chchile.org [192.168.1.25]) by endor.tataz.chchile.org (Postfix) with ESMTP id D08713406D; Thu, 19 Feb 2009 22:44:31 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id B725B5082A; Thu, 19 Feb 2009 23:44:31 +0100 (CET) Date: Thu, 19 Feb 2009 23:44:31 +0100 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Message-ID: <20090219224431.GC70440@obiwan.tataz.chchile.org> References: <20090113202046.GH41799@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="EVF5PPMfhYS0aIcm" Content-Disposition: inline In-Reply-To: <20090113202046.GH41799@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ru@FreeBSD.org Subject: Re: WITH_SSP in src.conf(5) breaks the build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Feb 2009 22:44:42 -0000 --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Ruslan, Could you commit the attached patch please (third try :)). Thanks. Regards, Jeremie On Tue, Jan 13, 2009 at 09:20:46PM +0100, Jeremie Le Hen wrote: > Hi list, > > I'd like to have SSP MFC'd for 7.2. However, there is still a problem: > WITH_SSP breaks the build if set in src.conf(5). See my previous mail > explaining this below. > > On Thu, Sep 04, 2008 at 04:17:05PM +0200, Jeremie Le Hen wrote: > > We indeed already have WITH_SSP/WITHOUT_SSP knob which is turned into > > MK_SSP="yes" or MK_SSP="no" respectively. > > > > The actual problem lies in Makefiles that define WITHOUT_SSP for some > > reason. For instance, in Makefile.inc1 the toolchain (namely > > bootstrap-tools, build-tools, cross-tools and a few other things) is > > built without SSP thanks to -DWITHOUT_SSP. For example: > > > > 224 BMAKE= MAKEOBJDIRPREFIX=${WORLDTMP} \ > > 225 ${BMAKEENV} ${MAKE} -f Makefile.inc1 \ > > 226 DESTDIR= \ > > 227 BOOTSTRAPPING=${OSRELDATE} \ > > 228 -DWITHOUT_SSP \ > > 229 -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN \ > > 230 -DWITHOUT_NLS -DNO_PIC -DWITHOUT_PROFILE -DNO_SHARED \ > > 231 -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF > > > > There is a problem is the user defines WITH_SSP in src.conf or on > > command-line. In this case, bsd.own.mk screams because both WITH_SSP > > and WITHOUT_SSP are defined. > > The attached patch fixes this by using the trick proposed by Ruslan [1] > where possible, or overriding SSP_CFLAGS otherwise. > > Once committed, I expect to provide a patch to introduce SSP for > RELENG_7 a few weeks later. > > Thank you. > Best regards, > > [1] http://lists.freebsd.org/pipermail/freebsd-hackers/2008-September/025891.html -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > --EVF5PPMfhYS0aIcm Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="MK_SSP=no.diff" Index: Makefile.inc1 =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/Makefile.inc1,v retrieving revision 1.610 diff -u -p -r1.610 Makefile.inc1 --- Makefile.inc1 19 Aug 2008 14:23:26 -0000 1.610 +++ Makefile.inc1 5 Sep 2008 15:16:25 -0000 @@ -225,7 +225,7 @@ BMAKE= MAKEOBJDIRPREFIX=${WORLDTMP} \ ${BMAKEENV} ${MAKE} -f Makefile.inc1 \ DESTDIR= \ BOOTSTRAPPING=${OSRELDATE} \ - -DWITHOUT_SSP \ + SSP_CFLAGS= \ -DWITHOUT_HTML -DWITHOUT_INFO -DNO_LINT -DWITHOUT_MAN \ -DWITHOUT_NLS -DNO_PIC -DWITHOUT_PROFILE -DNO_SHARED \ -DNO_CPU_CFLAGS -DNO_WARNS -DNO_CTF @@ -235,8 +235,9 @@ TMAKE= MAKEOBJDIRPREFIX=${OBJTREE} \ ${BMAKEENV} ${MAKE} -f Makefile.inc1 \ TARGET=${TARGET} TARGET_ARCH=${TARGET_ARCH} \ DESTDIR= \ + SSP_CFLAGS= \ BOOTSTRAPPING=${OSRELDATE} -DNO_LINT -DNO_CPU_CFLAGS \ - -DNO_WARNS -DNO_CTF -DWITHOUT_SSP + -DNO_WARNS -DNO_CTF # cross-tools stage XMAKE= TOOLS_PREFIX=${WORLDTMP} ${BMAKE} \ @@ -453,7 +454,7 @@ build32: .if ${MK_KERBEROS} != "no" .for _t in obj depend all cd ${.CURDIR}/kerberos5/tools; \ - MAKEOBJDIRPREFIX=${OBJTREE}/lib32 ${MAKE} -DWITHOUT_SSP DESTDIR= \ + MAKEOBJDIRPREFIX=${OBJTREE}/lib32 ${MAKE} SSP_CFLAGS= DESTDIR= \ ${_t} .endfor .endif @@ -476,7 +477,7 @@ build32: .endfor .for _dir in lib/ncurses/ncurses lib/ncurses/ncursesw lib/libmagic cd ${.CURDIR}/${_dir}; \ - MAKEOBJDIRPREFIX=${OBJTREE}/lib32 ${MAKE} -DWITHOUT_SSP DESTDIR= \ + MAKEOBJDIRPREFIX=${OBJTREE}/lib32 ${MAKE} SSP_CFLAGS= DESTDIR= \ build-tools .endfor cd ${.CURDIR}; \ @@ -765,14 +766,14 @@ buildkernel: @echo "--------------------------------------------------------------" cd ${KRNLOBJDIR}/${_kernel}; \ MAKESRCPATH=${KERNSRCDIR}/dev/aic7xxx/aicasm \ - ${MAKE} -DWITHOUT_SSP -DNO_CPU_CFLAGS -DNO_CTF \ + ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF \ -f ${KERNSRCDIR}/dev/aic7xxx/aicasm/Makefile # XXX - Gratuitously builds aicasm in the ``makeoptions NO_MODULES'' case. .if !defined(MODULES_WITH_WORLD) && !defined(NO_MODULES) && exists(${KERNSRCDIR}/modules) .for target in obj depend all cd ${KERNSRCDIR}/modules/aic7xxx/aicasm; \ MAKEOBJDIRPREFIX=${KRNLOBJDIR}/${_kernel}/modules \ - ${MAKE} -DWITHOUT_SSP -DNO_CPU_CFLAGS -DNO_CTF ${target} + ${MAKE} SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF ${target} .endfor .endif .if !defined(NO_KERNELDEPEND) Index: gnu/lib/csu/Makefile =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/gnu/lib/csu/Makefile,v retrieving revision 1.29 diff -u -p -r1.29 Makefile --- gnu/lib/csu/Makefile 25 Jun 2008 21:33:28 -0000 1.29 +++ gnu/lib/csu/Makefile 5 Sep 2008 15:24:07 -0000 @@ -1,5 +1,8 @@ # $FreeBSD: src/gnu/lib/csu/Makefile,v 1.29 2008/06/25 21:33:28 ru Exp $ +.include +MK_SSP= no + GCCDIR= ${.CURDIR}/../../../contrib/gcc GCCLIB= ${.CURDIR}/../../../contrib/gcclibs CCDIR= ${.CURDIR}/../../usr.bin/cc @@ -19,7 +22,6 @@ CFLAGS+= -I${GCCLIB}/include -I${GCCDIR} -I${CCDIR}/cc_tools CRTS_CFLAGS= -DCRTSTUFFS_O -DSHARED ${PICFLAG} MKDEP= -DCRT_BEGIN -WITHOUT_SSP= .if ${MACHINE_ARCH} == "ia64" BEGINSRC= crtbegin.asm Index: gnu/lib/libssp/Makefile =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/gnu/lib/libssp/Makefile,v retrieving revision 1.3 diff -u -p -r1.3 Makefile --- gnu/lib/libssp/Makefile 25 Jun 2008 21:33:28 -0000 1.3 +++ gnu/lib/libssp/Makefile 5 Sep 2008 15:24:00 -0000 @@ -1,5 +1,8 @@ # $FreeBSD: src/gnu/lib/libssp/Makefile,v 1.3 2008/06/25 21:33:28 ru Exp $ +.include +MK_SSP= no + GCCDIR= ${.CURDIR}/../../../contrib/gcc GCCLIB= ${.CURDIR}/../../../contrib/gcclibs SRCDIR= ${GCCLIB}/libssp @@ -10,7 +13,6 @@ LIB= ssp SHLIB_MAJOR= 0 SHLIBDIR?= /lib NO_PROFILE= -WITHOUT_SSP= SRCS= ssp.c gets-chk.c memcpy-chk.c memmove-chk.c mempcpy-chk.c \ memset-chk.c snprintf-chk.c sprintf-chk.c stpcpy-chk.c \ Index: lib/csu/Makefile.inc =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/lib/csu/Makefile.inc,v retrieving revision 1.1 diff -u -p -r1.1 Makefile.inc --- lib/csu/Makefile.inc 25 Jun 2008 21:33:28 -0000 1.1 +++ lib/csu/Makefile.inc 5 Sep 2008 15:17:19 -0000 @@ -1,3 +1,3 @@ # $FreeBSD: src/lib/csu/Makefile.inc,v 1.1 2008/06/25 21:33:28 ru Exp $ -WITHOUT_SSP= +SSP_CFLAGS= Index: lib/libstand/Makefile =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/lib/libstand/Makefile,v retrieving revision 1.62 diff -u -p -r1.62 Makefile --- lib/libstand/Makefile 25 Jun 2008 21:33:28 -0000 1.62 +++ lib/libstand/Makefile 5 Sep 2008 15:23:52 -0000 @@ -6,13 +6,15 @@ # quite large. # +.include +MK_SSP= no + LIB= stand NO_PROFILE= NO_PIC= INCS= stand.h MAN= libstand.3 -WITHOUT_SSP= CFLAGS+= -ffreestanding -Wformat CFLAGS+= -I${.CURDIR} Index: lib/libthr/Makefile =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/lib/libthr/Makefile,v retrieving revision 1.35 diff -u -p -r1.35 Makefile --- lib/libthr/Makefile 25 Jun 2008 21:33:28 -0000 1.35 +++ lib/libthr/Makefile 5 Sep 2008 15:23:47 -0000 @@ -8,9 +8,8 @@ # (for system call stubs) to CFLAGS below. -DSYSLIBC_SCCS affects just the # system call stubs. -WITHOUT_SSP= - .include +MK_SSP= no .if ${SHLIBDIR} == "/usr/lib" SHLIBDIR= /lib Index: libexec/rtld-elf/Makefile =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/libexec/rtld-elf/Makefile,v retrieving revision 1.42 diff -u -p -r1.42 Makefile --- libexec/rtld-elf/Makefile 25 Jun 2008 21:33:28 -0000 1.42 +++ libexec/rtld-elf/Makefile 5 Sep 2008 15:23:40 -0000 @@ -1,8 +1,7 @@ # $FreeBSD: src/libexec/rtld-elf/Makefile,v 1.42 2008/06/25 21:33:28 ru Exp $ -WITHOUT_SSP= - .include +MK_SSP= no PROG?= ld-elf.so.1 SRCS= rtld_start.S \ Index: rescue/librescue/Makefile =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/rescue/librescue/Makefile,v retrieving revision 1.10 diff -u -p -r1.10 Makefile --- rescue/librescue/Makefile 25 Jun 2008 21:33:28 -0000 1.10 +++ rescue/librescue/Makefile 5 Sep 2008 15:23:36 -0000 @@ -2,9 +2,8 @@ # $FreeBSD: src/rescue/librescue/Makefile,v 1.10 2008/06/25 21:33:28 ru Exp $ # -WITHOUT_SSP= - .include +MK_SSP= no # Certain library entries have hard-coded references to # /bin, /sbin, etc, that require those entries to be Index: rescue/rescue/Makefile =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/rescue/rescue/Makefile,v retrieving revision 1.63 diff -u -p -r1.63 Makefile --- rescue/rescue/Makefile 31 Aug 2008 14:27:59 -0000 1.63 +++ rescue/rescue/Makefile 5 Sep 2008 18:03:12 -0000 @@ -2,9 +2,9 @@ # @(#)Makefile 8.1 (Berkeley) 6/2/93 NO_MAN= -WITHOUT_SSP= .include +MK_SSP= no PROG= rescue BINDIR?=/rescue Index: sys/boot/Makefile.inc =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/sys/boot/Makefile.inc,v retrieving revision 1.1 diff -u -p -r1.1 Makefile.inc --- sys/boot/Makefile.inc 25 Jun 2008 21:33:28 -0000 1.1 +++ sys/boot/Makefile.inc 5 Sep 2008 15:23:21 -0000 @@ -1,3 +1,3 @@ # $FreeBSD: src/sys/boot/Makefile.inc,v 1.1 2008/06/25 21:33:28 ru Exp $ -WITHOUT_SSP= +SSP_CFLAGS= Index: sys/boot/i386/loader/Makefile =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/sys/boot/i386/loader/Makefile,v retrieving revision 1.86 diff -u -p -r1.86 Makefile --- sys/boot/i386/loader/Makefile 25 Jun 2008 21:33:28 -0000 1.86 +++ sys/boot/i386/loader/Makefile 5 Sep 2008 15:23:19 -0000 @@ -1,8 +1,7 @@ # $FreeBSD: src/sys/boot/i386/loader/Makefile,v 1.86 2008/06/25 21:33:28 ru Exp $ -WITHOUT_SSP= - .include +MK_SSP= no PROG= loader.sym INTERNALPROG= Index: sys/boot/ia64/common/Makefile =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/sys/boot/ia64/common/Makefile,v retrieving revision 1.2 diff -u -p -r1.2 Makefile --- sys/boot/ia64/common/Makefile 25 Jun 2008 21:33:28 -0000 1.2 +++ sys/boot/ia64/common/Makefile 5 Sep 2008 15:23:13 -0000 @@ -1,8 +1,7 @@ # $FreeBSD: src/sys/boot/ia64/common/Makefile,v 1.2 2008/06/25 21:33:28 ru Exp $ -WITHOUT_SSP= - .include +MK_SSP= no LIB= ia64 INTERNALLIB= Index: sys/boot/ia64/efi/Makefile =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/sys/boot/ia64/efi/Makefile,v retrieving revision 1.29 diff -u -p -r1.29 Makefile --- sys/boot/ia64/efi/Makefile 25 Jun 2008 21:33:28 -0000 1.29 +++ sys/boot/ia64/efi/Makefile 5 Sep 2008 15:23:09 -0000 @@ -1,9 +1,9 @@ # $FreeBSD: src/sys/boot/ia64/efi/Makefile,v 1.29 2008/06/25 21:33:28 ru Exp $ NO_MAN= -WITHOUT_SSP= .include +MK_SSP= no PROG= loader.sym INTERNALPROG= Index: sys/boot/ia64/ski/Makefile =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/sys/boot/ia64/ski/Makefile,v retrieving revision 1.21 diff -u -p -r1.21 Makefile --- sys/boot/ia64/ski/Makefile 25 Jun 2008 21:33:28 -0000 1.21 +++ sys/boot/ia64/ski/Makefile 5 Sep 2008 15:23:03 -0000 @@ -1,9 +1,9 @@ # $FreeBSD: src/sys/boot/ia64/ski/Makefile,v 1.21 2008/06/25 21:33:28 ru Exp $ NO_MAN= -WITHOUT_SSP= .include +MK_SSP= no PROG= skiload STRIP= # We must not strip skiload at install time. Index: sys/boot/pc98/loader/Makefile =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/sys/boot/pc98/loader/Makefile,v retrieving revision 1.42 diff -u -p -r1.42 Makefile --- sys/boot/pc98/loader/Makefile 25 Jun 2008 21:33:28 -0000 1.42 +++ sys/boot/pc98/loader/Makefile 5 Sep 2008 15:24:29 -0000 @@ -1,8 +1,7 @@ # $FreeBSD: src/sys/boot/pc98/loader/Makefile,v 1.42 2008/06/25 21:33:28 ru Exp $ -WITHOUT_SSP= - .include +MK_SSP= no PROG= loader.sym INTERNALPROG= Index: sys/boot/powerpc/ofw/Makefile =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/sys/boot/powerpc/ofw/Makefile,v retrieving revision 1.24 diff -u -p -r1.24 Makefile --- sys/boot/powerpc/ofw/Makefile 25 Jun 2008 21:33:28 -0000 1.24 +++ sys/boot/powerpc/ofw/Makefile 5 Sep 2008 15:24:37 -0000 @@ -1,8 +1,7 @@ # $FreeBSD: src/sys/boot/powerpc/ofw/Makefile,v 1.24 2008/06/25 21:33:28 ru Exp $ -WITHOUT_SSP= - .include +MK_SSP= no PROG= loader NEWVERSWHAT= "Open Firmware loader" ${MACHINE_ARCH} Index: sys/boot/sparc64/loader/Makefile =================================================================== RCS file: /mnt/octobre/space/freebsd-cvs/src/sys/boot/sparc64/loader/Makefile,v retrieving revision 1.21 diff -u -p -r1.21 Makefile --- sys/boot/sparc64/loader/Makefile 25 Jun 2008 21:33:28 -0000 1.21 +++ sys/boot/sparc64/loader/Makefile 5 Sep 2008 15:24:46 -0000 @@ -1,8 +1,7 @@ # $FreeBSD: src/sys/boot/sparc64/loader/Makefile,v 1.21 2008/06/25 21:33:28 ru Exp $ -WITHOUT_SSP= - .include +MK_SSP= no PROG= loader NEWVERSWHAT= "bootstrap loader" sparc64 --EVF5PPMfhYS0aIcm-- From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 01:16:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3DBEE106564A; Fri, 20 Feb 2009 01:16:31 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id D44E68FC15; Fri, 20 Feb 2009 01:16:30 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id BC8EC28448; Fri, 20 Feb 2009 09:16:29 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 41DEFEB0B17; Fri, 20 Feb 2009 09:16:29 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id KqcOJLzh4o8y; Fri, 20 Feb 2009 09:16:24 +0800 (CST) Received: from charlie.delphij.net (adsl-76-237-33-62.dsl.pltn13.sbcglobal.net [76.237.33.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 44A9FEB0924; Fri, 20 Feb 2009 09:16:22 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=lWCc7XW7ykv7n7cIw5SRqJEgVxapGmI96/3jcrhDU66BGmclKslIIHZDW+rh7qCJR qRDxXas4AFepAHuFpTzXg== Message-ID: <499E0463.2070608@delphij.net> Date: Thu, 19 Feb 2009 17:16:19 -0800 From: Xin LI Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.19 (X11/20090217) MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <499244E6.9030205@delphij.net> <20090212122419.Q53478@maildrop.int.zabbadoz.net> In-Reply-To: <20090212122419.Q53478@maildrop.int.zabbadoz.net> X-Enigmail-Version: 0.95.7 OpenPGP: id=18EDEBA0; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-rc@FreeBSD.org, freebsd-jail@freebsd.org, d@delphij.net, FreeBSD Current Subject: Re: [RFC] Skeleton jail (rc.d feature proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 01:16:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Bjoern, Bjoern A. Zeeb wrote: [...] > I do not have the following two on most/any of my machines: > >> usr/src >> usr/obj I agree. > The correct way to do this I think would leave rc.d/jail untouched and > (pre-)populate an /etc/fstab. and use that. I do not think this is a very good approach for this use case. Making it an rc.conf option, enables the following tasks as a one-liner change: - Enabling/Disabling skeleton jail (how will the system perform if I have the template directories read-only?); - Switching template root (what will happen if switch from 7.1 userland to 7.2 userland?); - Change mount points within all jails. I do admit that all these can be done with scripts though. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.10 (FreeBSD) iEYEARECAAYFAkmeBGIACgkQi+vbBBjt66A4GgCgsBo4b6PNTVDX3/3SCyv/ezXI 6+wAn2KZFdazhFjyyf0RPFHP6+8YpyPS =rHFi -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 02:20:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CCAA106566C; Fri, 20 Feb 2009 02:20:11 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.delphij.net (delphij-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:2c9::2]) by mx1.freebsd.org (Postfix) with ESMTP id DE16F8FC17; Fri, 20 Feb 2009 02:20:09 +0000 (UTC) (envelope-from quakelee@geekcn.org) Received: from tarsier.geekcn.org (tarsier.geekcn.org [211.166.10.233]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.delphij.net (Postfix) with ESMTPS id A12D628449; Fri, 20 Feb 2009 10:20:08 +0800 (CST) Received: from localhost (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 2FC45EB0A49; Fri, 20 Feb 2009 10:20:08 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by localhost (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with ESMTP id wQ1KJQthCnK4; Fri, 20 Feb 2009 10:20:03 +0800 (CST) Received: from qld630 (unknown [219.142.100.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id D2C16EB0947; Fri, 20 Feb 2009 10:20:02 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=geekcn.org; c=nofws; q=dns; h=date:to:subject:from:organization:cc:content-type: mime-version:references:content-transfer-encoding:message-id:in-reply-to:user-agent; b=TeBvowhwQ+umOE8j+V/60PdMIpz8ZHw7nfK2ggkVnzJSkbR88Gl27kkHzmqU+NxOG b11zyNX7ZKOj0+QlOqx8Q== Date: Fri, 20 Feb 2009 10:20:01 +0800 To: d@delphij.net, "Bjoern A. Zeeb" From: "Chao Shin" Organization: GeekCN Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 References: <499244E6.9030205@delphij.net> <20090212122419.Q53478@maildrop.int.zabbadoz.net> <499E0463.2070608@delphij.net> Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <499E0463.2070608@delphij.net> User-Agent: Opera Mail/9.62 (Win32) Cc: freebsd-jail@freebsd.org, freebsd-rc@freebsd.org, FreeBSD Current Subject: Re: [RFC] Skeleton jail (rc.d feature proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 02:20:11 -0000 在 Fri, 20 Feb 2009 09:16:19 +0800，Xin LI 写道: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, Bjoern, > > Bjoern A. Zeeb wrote: > [...] >> I do not have the following two on most/any of my machines: >> >>> usr/src >>> usr/obj > > I agree. > >> The correct way to do this I think would leave rc.d/jail untouched and >> (pre-)populate an /etc/fstab. and use that. > > I do not think this is a very good approach for this use case. > > Making it an rc.conf option, enables the following tasks as a one-liner > change: > - Enabling/Disabling skeleton jail (how will the system perform if I > have the template directories read-only?); > - Switching template root (what will happen if switch from 7.1 userland > to 7.2 userland?); > - Change mount points within all jails. > > I do admit that all these can be done with scripts though. > > Cheers, > - -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.10 (FreeBSD) > > iEYEARECAAYFAkmeBGIACgkQi+vbBBjt66A4GgCgsBo4b6PNTVDX3/3SCyv/ezXI > 6+wAn2KZFdazhFjyyf0RPFHP6+8YpyPS > =rHFi > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" I think I like Li Xin's way. I have set a jail host in my company with Li Xin's patch, it didn't change the usage of original jail system, just add a make target in /usr/src/Makefile, I can use skeleton jail and original jail in one jail host. They have not much differents in rc.conf, if want skeleton, I just add two options with normal settings. It is compatible way with orignal design. quakelee -- The Power to Serve From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 03:04:11 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4FCB1106566C; Fri, 20 Feb 2009 03:04:11 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 037858FC13; Fri, 20 Feb 2009 03:04:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1K348U0009553; Thu, 19 Feb 2009 22:04:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1K348VW085799; Thu, 19 Feb 2009 22:04:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E68237302F; Thu, 19 Feb 2009 22:04:07 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090220030407.E68237302F@freebsd-current.sentex.ca> Date: Thu, 19 Feb 2009 22:04:07 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 03:04:12 -0000 TB --- 2009-02-20 01:35:21 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-20 01:35:21 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-02-20 01:35:21 - cleaning the object tree TB --- 2009-02-20 01:35:44 - cvsupping the source tree TB --- 2009-02-20 01:35:44 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-02-20 01:35:55 - building world TB --- 2009-02-20 01:35:55 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-20 01:35:55 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-20 01:35:55 - TARGET=pc98 TB --- 2009-02-20 01:35:55 - TARGET_ARCH=i386 TB --- 2009-02-20 01:35:55 - TZ=UTC TB --- 2009-02-20 01:35:55 - __MAKE_CONF=/dev/null TB --- 2009-02-20 01:35:55 - cd /src TB --- 2009-02-20 01:35:55 - /usr/bin/make -B buildworld >>> World build started on Fri Feb 20 01:35:57 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Feb 20 02:58:20 UTC 2009 TB --- 2009-02-20 02:58:20 - generating LINT kernel config TB --- 2009-02-20 02:58:20 - cd /src/sys/pc98/conf TB --- 2009-02-20 02:58:20 - /usr/bin/make -B LINT TB --- 2009-02-20 02:58:20 - building LINT kernel TB --- 2009-02-20 02:58:20 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-20 02:58:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-20 02:58:20 - TARGET=pc98 TB --- 2009-02-20 02:58:20 - TARGET_ARCH=i386 TB --- 2009-02-20 02:58:20 - TZ=UTC TB --- 2009-02-20 02:58:20 - __MAKE_CONF=/dev/null TB --- 2009-02-20 02:58:20 - cd /src TB --- 2009-02-20 02:58:20 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 20 02:58:20 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-lowlevel.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-queue.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-card.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-cbus.c /src/sys/dev/ata/ata-cbus.c: In function 'ata_cbuschannel_detach': /src/sys/dev/ata/ata-cbus.c:308: error: 'ch' undeclared (first use in this function) /src/sys/dev/ata/ata-cbus.c:308: error: (Each undeclared identifier is reported only once /src/sys/dev/ata/ata-cbus.c:308: error: for each function it appears in.) *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-20 03:04:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-20 03:04:07 - ERROR: failed to build lint kernel TB --- 2009-02-20 03:04:07 - 4111.52 user 421.56 system 5326.30 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 00:44:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA367106564A; Fri, 20 Feb 2009 00:44:45 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (merlin.alerce.com [64.62.142.94]) by mx1.freebsd.org (Postfix) with ESMTP id BFE638FC08; Fri, 20 Feb 2009 00:44:45 +0000 (UTC) (envelope-from hartzell@alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 8640A33C62; Thu, 19 Feb 2009 16:44:45 -0800 (PST) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id F1E3433C5B; Thu, 19 Feb 2009 16:44:44 -0800 (PST) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18845.64765.71312.244570@almost.alerce.com> Date: Thu, 19 Feb 2009 16:44:45 -0800 To: Pawel Jakub Dawidek In-Reply-To: <20090219203541.GB2083@garage.freebsd.pl> References: <18845.40641.33220.936902@almost.alerce.com> <20090219181114.GA57360@freebsd.org> <20090219203541.GB2083@garage.freebsd.pl> X-Mailer: VM 8.0.12 under 22.1.50.1 (i386-apple-darwin8.11.1) X-Virus-Scanned: ClamAV using ClamSMTP X-Mailman-Approved-At: Fri, 20 Feb 2009 03:31:57 +0000 Cc: freebsd-fs@freebsd.org, goran.lowkrantz@ismobile.com, Roman Divacky , freebsd-current@freebsd.org, George Hartzell Subject: Re: Patch for 'zfs send -R' core dump (pr bin/130105) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hartzell@alerce.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 00:44:46 -0000 Pawel Jakub Dawidek writes: > On Thu, Feb 19, 2009 at 07:11:14PM +0100, Roman Divacky wrote: > > > > btw.... I track the opensolaris hg at work and there's a quite a few commits > > to zfs (almost) every week. fixing coredumps and other problems. > > > > maybe we can track the opensolaris a little closer? > > It is beeing tracked very close, I'd say, in perforce > (//depot/user/pjd/zfs/...). > > The problem is that trivial fixes are mixed with very intrusive changes, > so it is too risky to track it even in HEAD (I'm running HEAD on my > ZFS-only laptop!). OpenSolaris development is also very different from > FreeBSD's. We use to describe every single change very carefully in > commit logs, where OpenSolaris commits are based only on bug number and > bug descriptions. Many changes are committed at once, so it is hard to > pick only some changes. Is it possible for fixes like the one that I posted to get merged into -CURRENT w/out waiting for your next mega-relase? On the one hand it would be very useful, on the other I can imagine that if it happens too often it would make your life difficult. g. From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 03:37:45 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DF22106566B; Fri, 20 Feb 2009 03:37:45 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 344408FC12; Fri, 20 Feb 2009 03:37:45 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 98EA5FF37; Fri, 20 Feb 2009 16:37:44 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7+ejr3xYgkHq; Fri, 20 Feb 2009 16:37:40 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Fri, 20 Feb 2009 16:37:40 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 4DAC111428; Fri, 20 Feb 2009 16:37:40 +1300 (NZDT) Date: Thu, 19 Feb 2009 19:37:40 -0800 From: Andrew Thompson To: current@freebsd.org Message-ID: <20090220033740.GA903@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) Cc: usb@freebsd.org Subject: CFR: usb switchover patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 03:37:45 -0000 Hi, I have put together a proposed set of changes for moving USB2 to its permanent location. The layout has some differences to how it is right now so I am looking for feedback. The changeover requires that the old usb stack be available until 8.0 is branched and moves it from sys/dev/usb to sys/legacy/dev/usb. The reason for this location is to reduce the changes in #includes (using -I compiler hacks). The patch doesnt show userland changes required for usbdevs and friends but they will be done. Some ports will break. Any that exist solely for the old usb stack can be marked broken (like udesc_dump). I dont know that the fallout will be like for the others, maybe portmgr would be interested in doing a build test. The change roughly goes svn move sys/dev/usb -> sys/legacy/dev/usb svn move sys/dev/usb2 -> sys/dev/usb (with fixups, see below) The patch for the build system can be viewed here, http://people.freebsd.org/~thompsa/usb_layout/usb_xover.diff Now the changes... For starters the '2' will be removed from the filenames but furthermore I want to flatten dev/usb2/core and dev/usb2/include into just dev/usb, keeping the peripheral drivers in their subdirs. Its hard to show with a diff so simply browse the layout here, http://people.freebsd.org/~thompsa/usb_layout/dev/ Please send any minor/nitpick changes to me privately, keeping any list replies to the overall changes. regards, Andrew From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 03:46:25 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 155B41065673 for ; Fri, 20 Feb 2009 03:46:25 +0000 (UTC) (envelope-from marcus@freebsd.org) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by mx1.freebsd.org (Postfix) with ESMTP id CB7818FC20 for ; Fri, 20 Feb 2009 03:46:24 +0000 (UTC) (envelope-from marcus@freebsd.org) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n1K3kNK8008866; Thu, 19 Feb 2009 22:46:24 -0500 (EST) Received: from [10.1.1.20] (jclarke-vpn.cisco.com [172.18.254.237]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n1K3kLUM006922; Thu, 19 Feb 2009 22:46:22 -0500 (EST) Message-ID: <499E278D.7060406@freebsd.org> Date: Thu, 19 Feb 2009 22:46:21 -0500 From: Joe Marcus Clarke Organization: FreeBSD, Inc. User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: Andrew Thompson References: <20090220033740.GA903@citylink.fud.org.nz> In-Reply-To: <20090220033740.GA903@citylink.fud.org.nz> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: usb@freebsd.org, current@freebsd.org Subject: Re: CFR: usb switchover patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 03:46:29 -0000 Andrew Thompson wrote: > Hi, > > > I have put together a proposed set of changes for moving USB2 to its > permanent location. The layout has some differences to how it is right > now so I am looking for feedback. > > The changeover requires that the old usb stack be available until 8.0 is > branched and moves it from sys/dev/usb to sys/legacy/dev/usb. The reason > for this location is to reduce the changes in #includes (using -I > compiler hacks). The patch doesnt show userland changes required for > usbdevs and friends but they will be done. > > Some ports will break. Any that exist solely for the old usb stack can > be marked broken (like udesc_dump). I dont know that the fallout will be > like for the others, maybe portmgr would be interested in doing a build > test. > > The change roughly goes > > svn move sys/dev/usb -> sys/legacy/dev/usb > svn move sys/dev/usb2 -> sys/dev/usb (with fixups, see below) > > > The patch for the build system can be viewed here, > http://people.freebsd.org/~thompsa/usb_layout/usb_xover.diff > > Now the changes... For starters the '2' will be removed from the > filenames but furthermore I want to flatten dev/usb2/core and > dev/usb2/include into just dev/usb, keeping the peripheral drivers in > their subdirs. Its hard to show with a diff so simply browse the layout > here, http://people.freebsd.org/~thompsa/usb_layout/dev/ > > Please send any minor/nitpick changes to me privately, keeping any list > replies to the overall changes. What about libusb20? Will this name change, or is this the final name (same question for the libusb20 functions)? I need to know for hal. Thanks. Joe -- Joe Marcus Clarke FreeBSD GNOME Team :: gnome@FreeBSD.org FreeNode / #freebsd-gnome http://www.FreeBSD.org/gnome From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 03:51:15 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB50B106566C; Fri, 20 Feb 2009 03:51:15 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 7DCDB8FC15; Fri, 20 Feb 2009 03:51:15 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id D632FFF37; Fri, 20 Feb 2009 16:51:14 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeAI3gBOco9P; Fri, 20 Feb 2009 16:51:10 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Fri, 20 Feb 2009 16:51:10 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 633C911428; Fri, 20 Feb 2009 16:51:10 +1300 (NZDT) Date: Thu, 19 Feb 2009 19:51:10 -0800 From: Andrew Thompson To: Joe Marcus Clarke Message-ID: <20090220035110.GA3444@citylink.fud.org.nz> References: <20090220033740.GA903@citylink.fud.org.nz> <499E278D.7060406@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <499E278D.7060406@freebsd.org> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: usb@freebsd.org, current@freebsd.org Subject: Re: CFR: usb switchover patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 03:51:16 -0000 On Thu, Feb 19, 2009 at 10:46:21PM -0500, Joe Marcus Clarke wrote: > Andrew Thompson wrote: > > Hi, > > > > > > I have put together a proposed set of changes for moving USB2 to its > > permanent location. The layout has some differences to how it is right > > now so I am looking for feedback. > > What about libusb20? Will this name change, or is this the final name > (same question for the libusb20 functions)? I need to know for hal. > Thanks. As far as I know libusb20 will not change at all. Andrew From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 04:18:49 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5EFBC106567E; Fri, 20 Feb 2009 04:18:49 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id EF6868FC1F; Fri, 20 Feb 2009 04:18:48 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n1K4HOR8089807; Thu, 19 Feb 2009 21:17:24 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Thu, 19 Feb 2009 21:17:35 -0700 (MST) Message-Id: <20090219.211735.1528532921.imp@bsdimp.com> To: thompsa@freebsd.org From: "M. Warner Losh" In-Reply-To: <20090220033740.GA903@citylink.fud.org.nz> References: <20090220033740.GA903@citylink.fud.org.nz> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: usb@freebsd.org, current@freebsd.org Subject: Re: CFR: usb switchover patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 04:18:50 -0000 In message: <20090220033740.GA903@citylink.fud.org.nz> Andrew Thompson writes: : Hi, : : : I have put together a proposed set of changes for moving USB2 to its : permanent location. The layout has some differences to how it is right : now so I am looking for feedback. : : The changeover requires that the old usb stack be available until 8.0 is : branched and moves it from sys/dev/usb to sys/legacy/dev/usb. The reason : for this location is to reduce the changes in #includes (using -I : compiler hacks). The patch doesnt show userland changes required for : usbdevs and friends but they will be done. : : Some ports will break. Any that exist solely for the old usb stack can : be marked broken (like udesc_dump). I dont know that the fallout will be : like for the others, maybe portmgr would be interested in doing a build : test. : : The change roughly goes : : svn move sys/dev/usb -> sys/legacy/dev/usb : svn move sys/dev/usb2 -> sys/dev/usb (with fixups, see below) : : : The patch for the build system can be viewed here, : http://people.freebsd.org/~thompsa/usb_layout/usb_xover.diff : : Now the changes... For starters the '2' will be removed from the : filenames but furthermore I want to flatten dev/usb2/core and : dev/usb2/include into just dev/usb, keeping the peripheral drivers in : their subdirs. Its hard to show with a diff so simply browse the layout : here, http://people.freebsd.org/~thompsa/usb_layout/dev/ : : Please send any minor/nitpick changes to me privately, keeping any list : replies to the overall changes. While I might want to nitpick here, I'm going to refrain from doing so and just say "Close enough for my tastes, please go ahead." I could argue that there are a number of inconsistencies with historic practice that this (or the original usb2 commit) introduces, we shouldn't hold up this commit on those grounds. Instead, we should get experience with this layout and look to socialize ideas for a reorg post 8.0 that is more comprehensive in nature. This will give people plenty of time to think about it, and a chance for people with competing ideas to flesh them out. Warner From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 06:14:37 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E964B1065670 for ; Fri, 20 Feb 2009 06:14:37 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.188]) by mx1.freebsd.org (Postfix) with ESMTP id 2464F8FC12 for ; Fri, 20 Feb 2009 06:14:36 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: by fk-out-0910.google.com with SMTP id f40so1059988fka.11 for ; Thu, 19 Feb 2009 22:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QX3eJXWNxpbMlgvnJbyRodHsOXToLeHag8CGr2e/kVc=; b=e3ks+PdClx6LurBKUJGSfauHlAI5E6tE92v9BRuEAD1i922sIXphRlG+Rrl7u8IbiQ Dpv8j0JNVn8E8q/ktJCicklFrkSsgzA2RjRVHX7Mvw3qZpmokyx0IfWzSWEHXs6nDyQF 4/4dKW1DUrbvx8BSCNGYrAH0nzPuOd1IfUs6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=q3TjeYvES5QIIfdwPYINoRl7wAk9JsTHKT/uKYd9Z4hcbQNh4ZuWV4vWAA0fAkWbqL u1k5Ab2C2I501ETECQ8nIfk6/SiJcHAlqIoUFXaMBMYj8qOk+gZQXsuiX96KmChXCyCO Thy0c85tGws3KEHalXRQrsrV0oyFMBfQtFp6w= MIME-Version: 1.0 Received: by 10.180.246.2 with SMTP id t2mr153355bkh.161.1235110475873; Thu, 19 Feb 2009 22:14:35 -0800 (PST) In-Reply-To: <20090219220249.GA35945@jem.dhs.org> References: <20090219220249.GA35945@jem.dhs.org> Date: Fri, 20 Feb 2009 09:14:35 +0300 Message-ID: From: pluknet To: Ed Maste Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: attilio@freebsd.org, freebsd-current@freebsd.org Subject: Re: svn commit: r188743 - head/sys/dev/aac X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 06:14:38 -0000 2009/2/20 Ed Maste : >> Author: emaste >> Date: Wed Feb 18 01:36:20 2009 >> New Revision: 188743 >> URL: http://svn.freebsd.org/changeset/base/188743 >> >> Log: >> Use outbound message register 0 instead of mailbox 7 in >> aac_{rx,rkt}_get_fwstatus, as done in Adaptec's vendor driver as well as >> the Linux drivers. >> >> Submitted by: jkim, from Adaptec's driver > > This change to the aac(4) driver comes from Adaptec's vendor driver, > but it might break older controllers (Dell PERC 3, Adaptec 2200, etc.) > and/or controllers running with older firmware. > Hi. Can you describe a little more what is the purpose of this change? -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 06:21:32 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90493106564A; Fri, 20 Feb 2009 06:21:32 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 55A3B8FC12; Fri, 20 Feb 2009 06:21:32 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id 1E4B4FF37; Fri, 20 Feb 2009 19:21:31 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjhDbtCumbY0; Fri, 20 Feb 2009 19:21:27 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Fri, 20 Feb 2009 19:21:27 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id B753D11431; Fri, 20 Feb 2009 19:21:26 +1300 (NZDT) Date: Thu, 19 Feb 2009 22:21:26 -0800 From: Andrew Thompson To: current@freebsd.org Message-ID: <20090220062126.GA4137@citylink.fud.org.nz> References: <20090220033740.GA903@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090220033740.GA903@citylink.fud.org.nz> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: usb@freebsd.org Subject: Re: CFR: usb switchover patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 06:21:33 -0000 On Thu, Feb 19, 2009 at 07:37:40PM -0800, Andrew Thompson wrote: > Hi, > > > I have put together a proposed set of changes for moving USB2 to its > permanent location. The layout has some differences to how it is right > now so I am looking for feedback. > > The changeover requires that the old usb stack be available until 8.0 is > branched and moves it from sys/dev/usb to sys/legacy/dev/usb. The reason > for this location is to reduce the changes in #includes (using -I > compiler hacks). The patch doesnt show userland changes required for > usbdevs and friends but they will be done. Also, I wasnt planning on keeping the old usb kernel modules hooked into the build unless someone particularly wants them. They can all still be built into the kernel. Andrew From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 06:53:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C18181065672 for ; Fri, 20 Feb 2009 06:53:50 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.182]) by mx1.freebsd.org (Postfix) with ESMTP id 99F238FC1B for ; Fri, 20 Feb 2009 06:53:50 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by wa-out-1112.google.com with SMTP id k34so431452wah.27 for ; Thu, 19 Feb 2009 22:53:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=n024r/+EME/WiqehQCC4tiK1nW8+aCMAzqeU4ulHkWQ=; b=jo/rAtZMAH0lL2i8Hhj9pqV8ISMPTOuoYteX3GbnCQvR46w7EHSKp6WgGXhT68K1mr lHmx9QMEeXVl0ylOT8yoBXTadvwEy/Bp8qSFa2yGAVy0FJTkFsd6/wpzgmFIRh/HEoHF v4kC51xP/vfXa19Ic7c0CRSbYERD+bLnfP8Aw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=AkAWUTfi7sD5kpeqBoKUBmVv8Q+q8rfwkXCVQ1AX3K/J8YAg2Y4IdsXyWBccOaLpkC //0YgpSrdobQA1EfsbkceozZ9BaAo8Dh4/cBfNue+RXfbycnsBd+RFgzwRNUttQECGBa P2KlL78B8/r4s+5L2ivGnPHFX6KKJKnABNvyc= MIME-Version: 1.0 Received: by 10.114.37.9 with SMTP id k9mr216837wak.197.1235112830392; Thu, 19 Feb 2009 22:53:50 -0800 (PST) Date: Thu, 19 Feb 2009 22:53:50 -0800 Message-ID: <7d6fde3d0902192253t2013b0a7s40db6f24e8ac1e87@mail.gmail.com> From: Garrett Cooper To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: delete-old* doesn't honor WITHOUT_CVS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 06:53:51 -0000 I ran into issues with CVS some time back and disabled building CVS by setting the WITHOUT_CVS flag to yes in src.conf, but I see that it's still being built / called up when I do buildworld. Can someone else comment on whether or not this functionality is broken? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 09:37:17 2009 Return-Path: Delivered-To: current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1060) id 98622106568C; Fri, 20 Feb 2009 09:37:17 +0000 (UTC) Date: Fri, 20 Feb 2009 09:37:17 +0000 From: Craig Rodrigues To: David Wolfskill , current@freebsd.org Message-ID: <20090220093717.GA90962@crodrigues.org> References: <20090218213119.GU81076@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090218213119.GU81076@albert.catwhisker.org> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: High CPU usage for hald(8) as of r188749 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 09:37:18 -0000 On Wed, Feb 18, 2009 at 01:31:19PM -0800, David Wolfskill wrote: > On my laptop, after building CURRENT (r188749) this morning, it seems > that hald(8) is using a bit more CPU than its proper share: Go back and read the freebsd-current archives for the past few weeks. There are some problematic interactions between the new USB2 code and hal that are being worked on right now. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 10:05:08 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5910106566C for ; Fri, 20 Feb 2009 10:05:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 979B38FC08 for ; Fri, 20 Feb 2009 10:05:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 02F3C41C678; Fri, 20 Feb 2009 11:05:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id D4RNEhkOtxsF; Fri, 20 Feb 2009 11:05:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 94C1A41C677; Fri, 20 Feb 2009 11:05:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 5E8A34448E6; Fri, 20 Feb 2009 10:02:09 +0000 (UTC) Date: Fri, 20 Feb 2009 10:02:09 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Andrew Thompson In-Reply-To: <20090220062126.GA4137@citylink.fud.org.nz> Message-ID: <20090220100115.R53478@maildrop.int.zabbadoz.net> References: <20090220033740.GA903@citylink.fud.org.nz> <20090220062126.GA4137@citylink.fud.org.nz> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: usb@freebsd.org, FreeBSD current mailing list Subject: Re: CFR: usb switchover patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 10:05:09 -0000 On Thu, 19 Feb 2009, Andrew Thompson wrote: > On Thu, Feb 19, 2009 at 07:37:40PM -0800, Andrew Thompson wrote: >> Hi, >> >> >> I have put together a proposed set of changes for moving USB2 to its >> permanent location. The layout has some differences to how it is right >> now so I am looking for feedback. >> >> The changeover requires that the old usb stack be available until 8.0 is >> branched and moves it from sys/dev/usb to sys/legacy/dev/usb. The reason >> for this location is to reduce the changes in #includes (using -I >> compiler hacks). The patch doesnt show userland changes required for >> usbdevs and friends but they will be done. > > Also, I wasnt planning on keeping the old usb kernel modules hooked into > the build unless someone particularly wants them. They can all still be > built into the kernel. what about renaming it to dev/usb1 instead of starting another top level directory in sys/ ? I mean I like legacy and would prefer to move netinet/ in there asap but;-)) /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 12:44:11 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49FC61065676; Fri, 20 Feb 2009 12:44:11 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 0697A8FC08; Fri, 20 Feb 2009 12:44:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1KCi8uY051423; Fri, 20 Feb 2009 07:44:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1KCi8H1073125; Fri, 20 Feb 2009 07:44:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5F6F97302F; Fri, 20 Feb 2009 07:44:08 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090220124408.5F6F97302F@freebsd-current.sentex.ca> Date: Fri, 20 Feb 2009 07:44:08 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 12:44:11 -0000 TB --- 2009-02-20 11:15:22 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-20 11:15:22 - starting HEAD tinderbox run for i386/pc98 TB --- 2009-02-20 11:15:22 - cleaning the object tree TB --- 2009-02-20 11:15:49 - cvsupping the source tree TB --- 2009-02-20 11:15:49 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/i386/pc98/supfile TB --- 2009-02-20 11:15:59 - building world TB --- 2009-02-20 11:15:59 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-20 11:15:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-20 11:15:59 - TARGET=pc98 TB --- 2009-02-20 11:15:59 - TARGET_ARCH=i386 TB --- 2009-02-20 11:15:59 - TZ=UTC TB --- 2009-02-20 11:15:59 - __MAKE_CONF=/dev/null TB --- 2009-02-20 11:15:59 - cd /src TB --- 2009-02-20 11:15:59 - /usr/bin/make -B buildworld >>> World build started on Fri Feb 20 11:16:01 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Feb 20 12:38:08 UTC 2009 TB --- 2009-02-20 12:38:08 - generating LINT kernel config TB --- 2009-02-20 12:38:08 - cd /src/sys/pc98/conf TB --- 2009-02-20 12:38:08 - /usr/bin/make -B LINT TB --- 2009-02-20 12:38:08 - building LINT kernel TB --- 2009-02-20 12:38:08 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-20 12:38:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-20 12:38:08 - TARGET=pc98 TB --- 2009-02-20 12:38:08 - TARGET_ARCH=i386 TB --- 2009-02-20 12:38:08 - TZ=UTC TB --- 2009-02-20 12:38:08 - __MAKE_CONF=/dev/null TB --- 2009-02-20 12:38:08 - cd /src TB --- 2009-02-20 12:38:08 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Feb 20 12:38:08 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-lowlevel.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-queue.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-card.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/ata-cbus.c /src/sys/dev/ata/ata-cbus.c: In function 'ata_cbuschannel_detach': /src/sys/dev/ata/ata-cbus.c:308: error: 'ch' undeclared (first use in this function) /src/sys/dev/ata/ata-cbus.c:308: error: (Each undeclared identifier is reported only once /src/sys/dev/ata/ata-cbus.c:308: error: for each function it appears in.) *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-20 12:44:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-20 12:44:08 - ERROR: failed to build lint kernel TB --- 2009-02-20 12:44:08 - 4116.54 user 416.02 system 5325.71 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 14:25:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE233106566C for ; Fri, 20 Feb 2009 14:25:10 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 766CF8FC1B for ; Fri, 20 Feb 2009 14:25:10 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (pD9E2D8A3.dip.t-dialin.net [217.226.216.163]) by redbull.bpaserver.net (Postfix) with ESMTP id 2A1D52E0AD; Fri, 20 Feb 2009 15:25:05 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id DC127BB6E5; Fri, 20 Feb 2009 15:25:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1235139901; bh=SjTSVM4T3vEl8ii3TOE71HADSnd7YTB0l ArYas8dnmI=; h=Message-ID:Date:From:To:Cc:Subject:References: In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=vDSDn1Z8YeH0iGcHH1UDoe74CLVkehW3adaJC/TM4AjJmMubSr/J8LGmgeDM1MCax x8Sf68Wr6IVivRr7dh8/B0ytKSqF75GPaUyRfrZJ4dreX8D8hnk5P+7CxG4xEx334Ar PQynS0GH9CRaCRVQDkC8KcquCnt4gsn7IGylW1jPT4ILY8Mf1+P5YLydUNchLIEXQXF 1tO7E+tDsq3OFe7NGorx9PIfWuTFtiIPlMcPWPvuppk/HIHC6FKTtA8uPwEIfXCYFV4 jTGFAU5NzjiPdg+XELoUTus23DdeY5F1Lnw7Z7JUYZlogfPceNhGdfh1TXJ463VsfZQ G0FhzuQvA== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n1KEP1jQ053497; Fri, 20 Feb 2009 15:25:01 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Luna.Leidinger.net (Luna.Leidinger.net [192.168.2.100]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 20 Feb 2009 15:25:01 +0100 Message-ID: <20090220152501.349021fd4lzrkr40@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 20 Feb 2009 15:25:01 +0100 From: Alexander Leidinger To: Garrett Cooper References: <7d6fde3d0902192253t2013b0a7s40db6f24e8ac1e87@mail.gmail.com> In-Reply-To: <7d6fde3d0902192253t2013b0a7s40db6f24e8ac1e87@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 2A1D52E0AD.BD944 X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-14.9, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: FreeBSD Current Subject: Re: delete-old* doesn't honor WITHOUT_CVS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 14:25:11 -0000 Quoting Garrett Cooper (from Thu, 19 Feb 2009 22:53:50 -0800): > I ran into issues with CVS some time back and disabled building > CVS by setting the WITHOUT_CVS flag to yes in src.conf, but I see that > it's still being built / called up when I do buildworld. Can someone > else comment on whether or not this functionality is broken? Your subject does not match the body of the mail. I don't know about the stuff in the body, but regarding the subject you have to have a look into /usr/src/tools/build/mk/OptionalObsoleteFiles.inc and add the files which are covered by WITHOUT_CVS to the MK_CVS part. Patches are welcome. Bye, Alexander. -- Also, the Scots are said to have invented golf. Then they had to invent Scotch whiskey to take away the pain and frustration. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 15:31:05 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55ED5106566B; Fri, 20 Feb 2009 15:31:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id 1068B8FC12; Fri, 20 Feb 2009 15:31:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id n1KFSWRM014143; Fri, 20 Feb 2009 08:28:33 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 20 Feb 2009 08:28:43 -0700 (MST) Message-Id: <20090220.082843.517086508.imp@bsdimp.com> To: bzeeb-lists@lists.zabbadoz.net From: "M. Warner Losh" In-Reply-To: <20090220100115.R53478@maildrop.int.zabbadoz.net> References: <20090220033740.GA903@citylink.fud.org.nz> <20090220062126.GA4137@citylink.fud.org.nz> <20090220100115.R53478@maildrop.int.zabbadoz.net> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: usb@freebsd.org, current@freebsd.org, thompsa@freebsd.org Subject: Re: CFR: usb switchover patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 15:31:05 -0000 In message: <20090220100115.R53478@maildrop.int.zabbadoz.net> "Bjoern A. Zeeb" writes: : On Thu, 19 Feb 2009, Andrew Thompson wrote: : : > On Thu, Feb 19, 2009 at 07:37:40PM -0800, Andrew Thompson wrote: : >> Hi, : >> : >> : >> I have put together a proposed set of changes for moving USB2 to its : >> permanent location. The layout has some differences to how it is right : >> now so I am looking for feedback. : >> : >> The changeover requires that the old usb stack be available until 8.0 is : >> branched and moves it from sys/dev/usb to sys/legacy/dev/usb. The reason : >> for this location is to reduce the changes in #includes (using -I : >> compiler hacks). The patch doesnt show userland changes required for : >> usbdevs and friends but they will be done. : > : > Also, I wasnt planning on keeping the old usb kernel modules hooked into : > the build unless someone particularly wants them. They can all still be : > built into the kernel. : : what about renaming it to dev/usb1 instead of starting another top : level directory in sys/ ? I mean I like legacy and would prefer to : move netinet/ in there asap but;-)) We'd have to hack all the old usb1 drivers. Moving to sys/legacy/dev/usb means minimal frobbing of the code. From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 15:36:13 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9C341106564A; Fri, 20 Feb 2009 15:36:13 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: from maste.org (emaste.tor.istop.com [66.11.182.63]) by mx1.freebsd.org (Postfix) with ESMTP id 660548FC1C; Fri, 20 Feb 2009 15:36:13 +0000 (UTC) (envelope-from emaste@freebsd.org) Received: by maste.org (Postfix, from userid 1001) id 66F38DB; Fri, 20 Feb 2009 15:52:55 +0000 (UTC) Date: Fri, 20 Feb 2009 15:52:55 +0000 From: Ed Maste To: pluknet Message-ID: <20090220155255.GA68556@jem.dhs.org> References: <20090219220249.GA35945@jem.dhs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: attilio@freebsd.org, freebsd-current@freebsd.org Subject: Re: svn commit: r188743 - head/sys/dev/aac X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 15:36:13 -0000 On Fri, Feb 20, 2009 at 09:14:35AM +0300, pluknet wrote: > 2009/2/20 Ed Maste : > >> Author: emaste > >> Date: Wed Feb 18 01:36:20 2009 > >> New Revision: 188743 > >> URL: http://svn.freebsd.org/changeset/base/188743 > >> > >> Log: > >> Use outbound message register 0 instead of mailbox 7 in > >> aac_{rx,rkt}_get_fwstatus, as done in Adaptec's vendor driver as well as > >> the Linux drivers. > >> > >> Submitted by: jkim, from Adaptec's driver > > > > This change to the aac(4) driver comes from Adaptec's vendor driver, > > but it might break older controllers (Dell PERC 3, Adaptec 2200, etc.) > > and/or controllers running with older firmware. > > > > Hi. > > Can you describe a little more what is the purpose of this change? Unfortunately I do not know the specifics, just that this is what's done in Adaptec's driver. There is some speculation it may be related to command timeouts observed with the latest series of controllers. In any case the change is part of a larger project to sync the in-tree driver with Adaptec's version. I have one report so far -- a PERC3 running firmware 2.7-1 BUILD 3170 works with this change. - Ed From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 15:45:08 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4114510656CE; Fri, 20 Feb 2009 15:45:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id E65EB8FC2C; Fri, 20 Feb 2009 15:45:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id 0247E41C67E; Fri, 20 Feb 2009 16:45:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id LBxl7revk5HZ; Fri, 20 Feb 2009 16:45:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 9AAC241C678; Fri, 20 Feb 2009 16:45:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 99F0D4448E6; Fri, 20 Feb 2009 15:41:16 +0000 (UTC) Date: Fri, 20 Feb 2009 15:41:16 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: "M. Warner Losh" In-Reply-To: <20090220.082843.517086508.imp@bsdimp.com> Message-ID: <20090220154049.H53478@maildrop.int.zabbadoz.net> References: <20090220033740.GA903@citylink.fud.org.nz> <20090220062126.GA4137@citylink.fud.org.nz> <20090220100115.R53478@maildrop.int.zabbadoz.net> <20090220.082843.517086508.imp@bsdimp.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: usb@freebsd.org, FreeBSD current mailing list , thompsa@freebsd.org Subject: Re: CFR: usb switchover patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 15:45:09 -0000 On Fri, 20 Feb 2009, M. Warner Losh wrote: > In message: <20090220100115.R53478@maildrop.int.zabbadoz.net> > "Bjoern A. Zeeb" writes: > : On Thu, 19 Feb 2009, Andrew Thompson wrote: > : > : > On Thu, Feb 19, 2009 at 07:37:40PM -0800, Andrew Thompson wrote: > : >> Hi, > : >> > : >> > : >> I have put together a proposed set of changes for moving USB2 to its > : >> permanent location. The layout has some differences to how it is right > : >> now so I am looking for feedback. > : >> > : >> The changeover requires that the old usb stack be available until 8.0 is > : >> branched and moves it from sys/dev/usb to sys/legacy/dev/usb. The reason > : >> for this location is to reduce the changes in #includes (using -I > : >> compiler hacks). The patch doesnt show userland changes required for > : >> usbdevs and friends but they will be done. > : > > : > Also, I wasnt planning on keeping the old usb kernel modules hooked into > : > the build unless someone particularly wants them. They can all still be > : > built into the kernel. > : > : what about renaming it to dev/usb1 instead of starting another top > : level directory in sys/ ? I mean I like legacy and would prefer to > : move netinet/ in there asap but;-)) > > We'd have to hack all the old usb1 drivers. Moving to > sys/legacy/dev/usb means minimal frobbing of the code. ok, that explains. #include . -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 17:48:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DC82D106566B for ; Fri, 20 Feb 2009 17:48:10 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 677408FC13 for ; Fri, 20 Feb 2009 17:48:09 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LaZTl-0002s7-Gv for freebsd-current@freebsd.org; Fri, 20 Feb 2009 17:48:01 +0000 Received: from mulderlab.f5.com ([205.229.151.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Feb 2009 17:48:01 +0000 Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Feb 2009 17:48:01 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Followup-To: gmane.os.freebsd.current Date: Fri, 20 Feb 2009 09:47:49 -0800 Lines: 70 Message-ID: References: <84dead720902121838p3a72f993xc1c52104c666ed0a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mulderlab.f5.com User-Agent: KNode/0.99.01 Sender: news Subject: Re: memory alignment problems with -current on amd64? [Found Cause] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 17:48:11 -0000 Joseph Koshy wrote: >> example, my latest failure: >> peigen.c: In function '_bfd_pei_only_swap_filehdr_out': >> peigen.c:2089: internal compiler error: Bus error: 10 >> Please submit a full bug report, >> with preprocessed source if appropriate. > >> With an deliberately induced bus error, a program will dump core. > > You may need to specify option "-dH" if you want gcc to dump core on > error. See: contrib/gcc/diagnostic.[ch]. Very useful tip. after several tries I was able to get a core. However, I'm not sure how useful it is. The stack looks like it was blown out (gdb shows 1042 frames and complains after that, plus the addresses seem to be random garbage.) I changed CFLAGS to -O0 -dH cc -O0 -dH -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/usr/src/tmp/usr\" - I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools - I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc - I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config - I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include - I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include - I/usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber - I/usr/obj/usr/src/tmp/legacy/usr/include -c /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/flow.c In file included from /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/flow.c:133: /usr/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/flags.h:174: internal compiler error: Bus error: 10 cc: Internal error: Abort trap: 6 (program cc1) Please submit a full bug report. See for instructions. (gdb) info registers rax 0x0 0 rbx 0x7fffffffdb3c 140737488345916 rcx 0x852f5c 8728412 rdx 0x0 0 rsi 0x6 6 rdi 0x5a2f 23087 rbp 0x7fffffffdbf0 0x7fffffffdbf0 rsp 0x7fffffffdb28 0x7fffffffdb28 r8 0xffffff000760f880 -1099387832192 r9 0x7fffffffdb18 140737488345880 r10 0x1 1 r11 0x206 518 r12 0x7fffffffdc00 140737488346112 r13 0x92b765 9615205 r14 0x8019fe060 34386993248 r15 0x0 0 rip 0x852f3c 0x852f3c eflags 0x246 582 cs 0x2b 43 ss 0x23 35 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 17:58:31 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1DD61065676 for ; Fri, 20 Feb 2009 17:58:31 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2EE5D8FC19 for ; Fri, 20 Feb 2009 17:58:30 +0000 (UTC) (envelope-from freebsd-current@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LaZdt-0003JW-TB for freebsd-current@freebsd.org; Fri, 20 Feb 2009 17:58:29 +0000 Received: from mulderlab.f5.com ([205.229.151.151]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Feb 2009 17:58:29 +0000 Received: from atkin901 by mulderlab.f5.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Feb 2009 17:58:29 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: Mark Atkinson Followup-To: gmane.os.freebsd.current Date: Fri, 20 Feb 2009 09:58:21 -0800 Lines: 73 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mulderlab.f5.com User-Agent: KNode/0.99.01 Sender: news Subject: Re: memory alignment problems with -current on amd64? [Found Cause] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 17:58:31 -0000 Alan Cox wrote: > On Tue, Feb 10, 2009 at 2:20 PM, Mark Atkinson wrote: > [snip] >> >> >> >> Well, taking the information I knew -- OCT 15th == good, Mid DEC == BAD, >> I trolled every commit logged between. Eventually I found this one: >> >> http://svn.freebsd.org/viewvc/base?view=revision&revision=185715 >> >> http://docs.freebsd.org/cgi/mid.cgi?200812061937.mB6JbqAI003273 >> >> I set vm.pmap.pg_ps_enabled="0" in /boot/loader.conf, and >> was able to complete buildworld and -j16 buildworld and -j8 buildkernel >> no problem. >> >> It appears superpage mapping causes alignment problems on this box. > > > Can you please provide more detailed information about this machine, in > particular, the processor including the revision? It would also be > helpful to see what gdb says about a couple of these crashes, > specifically, the machine registers at the time of the exception. Looking at the core a little further, you probably want the registers at the frame before the signal handler is called. [...] #61 0x178d2d478b6062af in ?? () #62 0x000000000000000a in ?? () #63 0x0000000000504620 in ?? () #64 0x0000000000000001 in ?? () #65 #66 0x0000000000444d68 in ?? () #67 0x0000000000000000 in ?? () #68 0x0000000000000001 in ?? () #69 0x0000000800ce0f30 in ?? () [...] (gdb) frame 66 #66 0x0000000000444d68 in ?? () (gdb) info registers rax 0x0 0 rbx 0x1 1 rcx 0x8019ff030 34386997296 rdx 0x1 1 rsi 0x8019ff060 34386997344 rdi 0x8019fe0a0 34386993312 rbp 0x801a00000 0x801a00000 rsp 0x7fffffffe180 0x7fffffffe180 r8 0x2 2 r9 0x0 0 r10 0x1 1 r11 0x801a00000 34387001344 r12 0x801a00000 34387001344 r13 0x800ce0f30 34373242672 r14 0x8019fe060 34386993248 r15 0x0 0 rip 0x444d68 0x444d68 eflags 0x297 663 cs 0x2b 43 ss 0x23 35 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 -- Mark Atkinson atkin901@yahoo.com (!wired)?(coffee++):(wired); From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 18:35:10 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66EDE106564A for ; Fri, 20 Feb 2009 18:35:10 +0000 (UTC) (envelope-from buganini@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.159]) by mx1.freebsd.org (Postfix) with ESMTP id ECF3F8FC13 for ; Fri, 20 Feb 2009 18:35:09 +0000 (UTC) (envelope-from buganini@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1329187fgb.35 for ; Fri, 20 Feb 2009 10:35:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qqJQBTyg/XMGHe2vOi1yB6Cf6o4zWLs9iCSmFCErAB0=; b=gC/pkA1tGQNJCfF4cfrfjpxNMFqf/Oo1+mdT6llQeH0fmaTV5v2wRbV7QMm2wBtEX6 +58J+RsUcw2VVygbCoqhcnZ8Fw4EsATVUQ9lWHb2vkbl29VVclp2/V1TUBduR7eIJf9j JQQh3+z8kpmLqJOayzi75A432dX6beVuDGrnE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CDpCSPr6kR++zXLraNYygxg2nTKVzTK85TPKk2Jf+urNvEzfoo6HW5AWNGn9xnvoof qA9gwgrH3xeKOxMAHFzS72+6NZz9hGHy0Rq4GwGojq+8wMUqh5IavrcCvx++O4yA/Onk RBXgVlke0H4Bcj0MhkRhXrRdeuPrjsuXgZ7a4= MIME-Version: 1.0 Received: by 10.103.49.12 with SMTP id b12mr1936654muk.81.1235154909038; Fri, 20 Feb 2009 10:35:09 -0800 (PST) In-Reply-To: <200902120818.34567.jhb@freebsd.org> References: <49935993.50303@stillbilde.net> <200902120818.34567.jhb@freebsd.org> Date: Sat, 21 Feb 2009 02:35:09 +0800 Message-ID: From: Buganini To: freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: army.of.root@googlemail.com Subject: Re: modular kernconf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 18:35:10 -0000 I've made a patch to allow using section/nosection in kernconf. http://140.112.64.5/buganini/config.patch My uname -a: FreeBSD Zeta.twbbs.org 8.0-CURRENT FreeBSD 8.0-CURRENT #9: Fri Feb 20 01:18:21 CST 2009 root@Zeta.twbbs.org:/usr/obj/usr/src/sys/ZETA i386 Currently this patch can deal with cpu/options/device/makeoptions, probably enough (actually I think options/device is usually enough). I havent tested it fully, just modify GENERIC as follow: ... section USB2 # USB core support ... section FireWire # FireWire support ... and the customized kernconf: include GENERIC ident ZETA nosection USB2 nosection FireWire then `config ZETA`, I can see corresponding in /usr/src/sys/i386/compile/ZETA/config.c The default section is "main", everythins before the first section direction will be in section "main". I've not really make kernel by this yet. From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 19:23:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C89D1065694; Fri, 20 Feb 2009 19:23:15 +0000 (UTC) (envelope-from simon@nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.freebsd.org (Postfix) with ESMTP id BBAA78FC21; Fri, 20 Feb 2009 19:23:14 +0000 (UTC) (envelope-from simon@nitro.dk) Received: from arthur.nitro.dk (arthur.bofh [192.168.2.3]) by mx.nitro.dk (Postfix) with ESMTP id 1A8AE2E6821; Fri, 20 Feb 2009 19:23:14 +0000 (UTC) Received: by arthur.nitro.dk (Postfix, from userid 1000) id 025095C6A; Fri, 20 Feb 2009 20:23:13 +0100 (CET) Date: Fri, 20 Feb 2009 20:23:13 +0100 From: "Simon L. Nielsen" To: d@delphij.net Message-ID: <20090220192312.GD1064@arthur.nitro.dk> References: <499244E6.9030205@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <499244E6.9030205@delphij.net> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-jail@FreeBSD.org, FreeBSD Current , freebsd-rc@FreeBSD.org Subject: Re: [RFC] Skeleton jail (rc.d feature proposal) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 19:23:16 -0000 On 2009.02.10 19:24:22 -0800, Xin LI wrote: > Ok, some local users has prodded me in committing the "skeleton jail" > feature, I find it useful myself but not sure if it's appropriate to > commit it against -HEAD, so I'd like to explain it, try to present it in This complicates an already complicated etc/rc.d/jail script so I think this is a very bad idea. rc.d/jail is already interesting enough security wise as it is IMO. If anyone wants this very much think it should be done in an "external" (to etc/rc.d/jail) jail management system/script. Personally I have been very happy with ezjail, and I think having a script like that "externally" is a much better way to go. If that means importing ezjail or making something like it I don't know. -- Simon L. Nielsen From owner-freebsd-current@FreeBSD.ORG Fri Feb 20 20:33:54 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBAD21065675; Fri, 20 Feb 2009 20:33:54 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from pele.citylink.co.nz (pele.citylink.co.nz [202.8.44.226]) by mx1.freebsd.org (Postfix) with ESMTP id 9EA948FC12; Fri, 20 Feb 2009 20:33:54 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) by pele.citylink.co.nz (Postfix) with ESMTP id ECC69FF42; Sat, 21 Feb 2009 09:33:53 +1300 (NZDT) X-Virus-Scanned: Debian amavisd-new at citylink.co.nz Received: from pele.citylink.co.nz ([127.0.0.1]) by localhost (pele.citylink.co.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+DnjkF3k7e9; Sat, 21 Feb 2009 09:33:50 +1300 (NZDT) Received: from citylink.fud.org.nz (unknown [202.8.44.45]) by pele.citylink.co.nz (Postfix) with ESMTP; Sat, 21 Feb 2009 09:33:50 +1300 (NZDT) Received: by citylink.fud.org.nz (Postfix, from userid 1001) id 9640D1142F; Sat, 21 Feb 2009 09:33:50 +1300 (NZDT) Date: Fri, 20 Feb 2009 12:33:50 -0800 From: Andrew Thompson To: current@freebsd.org Message-ID: <20090220203350.GF4265@citylink.fud.org.nz> References: <20090220033740.GA903@citylink.fud.org.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090220033740.GA903@citylink.fud.org.nz> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: usb@freebsd.org Subject: Re: CFR: usb switchover patches X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Feb 2009 20:33:56 -0000 On Thu, Feb 19, 2009 at 07:37:40PM -0800, Andrew Thompson wrote: > Hi, > > > I have put together a proposed set of changes for moving USB2 to its > permanent location. The layout has some differences to how it is right > now so I am looking for feedback. I should have said the attached patch was to illustrate the changes and I didnt expect anyone to test a build with them. Andrew From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 00:10:07 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A70C71065687 for ; Sat, 21 Feb 2009 00:10:07 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by mx1.freebsd.org (Postfix) with ESMTP id 77F8B8FC08 for ; Sat, 21 Feb 2009 00:10:07 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from [10.9.200.133] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 20 Feb 2009 15:38:20 -0800 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Fri, 20 Feb 2009 15:39:40 -0800 From: "David Christensen" To: "freebsd-current@freebsd.org" Date: Fri, 20 Feb 2009 15:40:56 -0800 Thread-Topic: Hopefully Simple Question on Debugging Kernel Modules Thread-Index: AcmTtKc3gs5fbKK5QXOxPePNXaU5dw== Message-ID: <5D267A3F22FD854F8F48B3D2B5238193394588D54D@IRVEXCHCCR01.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: BN6+ CLIc CjGX Dlcs EOxv GLq2 GRe+ GuAn G0Wd HjKS Hsyu IbO8 I3J0 I/lv JF4/ JlEY; 1; ZgByAGUAZQBiAHMAZAAtAGMAdQByAHIAZQBuAHQAQABmAHIAZQBlAGIAcwBkAC4AbwByAGcA; Sosha1_v1; 7; {2E7814AB-1EE8-45EF-A78A-AE9AFD495446}; ZABhAHYAaQBkAGMAaABAAGIAcgBvAGEAZABjAG8AbQAuAGMAbwBtAA==; Fri, 20 Feb 2009 23:40:56 GMT; SABvAHAAZQBmAHUAbABsAHkAIABTAGkAbQBwAGwAZQAgAFEAdQBlAHMAdABpAG8AbgAgAG8AbgAgAEQAZQBiAHUAZwBnAGkAbgBnACAASwBlAHIAbgBlAGwAIABNAG8AZAB1AGwAZQBzAA== x-cr-puzzleid: {2E7814AB-1EE8-45EF-A78A-AE9AFD495446} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 6581E1661RW878093-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Hopefully Simple Question on Debugging Kernel Modules X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 00:10:09 -0000 I'm sure this is a simple question but the answer is alluding my Google search capabilities. My driver is being loaded as a kernel module and is failing with the following error: Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0xfffffffe40abe9dc fault code =3D supervisor write data, page not present instruction pointer =3D 0x8:0xffffffff920b638f stack pointer =3D 0x10:0xffffffff9212bb10 frame pointer =3D 0x10:0xffffffff9212bbb0 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 12 (irq268: bce0) [thread pid 12 tid 100166 ] Stopped at bce_intr+0x8df: addl $0x1,0x2c854(%r12,%rax,4) db> I simply need to find the offending source line in my driver. Not sure=20 how I've managed to get the driver running at all without this but it's=20 time to do things the right way. I have KDB/DDB/GDB built into my=20 -CURRENT kernel already. It'd be great to find the source line while in the kernel debugger but I'm also fine with rebooting the system to=20 identify the line number. Dave From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 00:31:14 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7342C1065673 for ; Sat, 21 Feb 2009 00:31:14 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by mx1.freebsd.org (Postfix) with ESMTP id 05BC38FC19 for ; Sat, 21 Feb 2009 00:31:13 +0000 (UTC) (envelope-from onemda@gmail.com) Received: by nf-out-0910.google.com with SMTP id e27so164929nfd.33 for ; Fri, 20 Feb 2009 16:31:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yLCOUVQAbZWQStkFlY/2tN5DCdFMVjr/rLzpYEwNckU=; b=GKo5sUVcL15dXx/+xNC+9o5Kp5HwQK2xu1Kb0NxnJ+8yxxZWyTnekvPq0Nne3RbJE3 Nvx9c4Gddz1ZVyRFwKYFzTC79tHDeVsmRLjX0CtQgqhOpYJ+/yy+6vnywwNq7+TPW2yY IyWIG1Tq378CBAYACxU0h01fLFwqYIjTb86jc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ipiUVdwRpTTCKc2kSIx07FDmK+452383Pokdi4Ferrkrglry/0tV/eYHmQb6bj2wCY tLl1mf6p0Fp+7QKTT1QaR5DrdXu3kkOEjBBk9CqCWM38fAyf16X4hcdJafl6ycH3oDAu uQA2yAiVFgeurNWfV3VpXMR4++yNidH/hMWe8= MIME-Version: 1.0 Received: by 10.210.119.5 with SMTP id r5mr1097324ebc.21.1235176273167; Fri, 20 Feb 2009 16:31:13 -0800 (PST) In-Reply-To: <499C0319.9040100@cs.duke.edu> References: <20090217142615.A77950@grasshopper.cs.duke.edu> <3a142e750902180256p68ef8fc0nbda773d41d42a7a0@mail.gmail.com> <499C0319.9040100@cs.duke.edu> Date: Sat, 21 Feb 2009 01:31:13 +0100 Message-ID: <3a142e750902201631v2889e677s3691f491482f1d37@mail.gmail.com> From: "Paul B. Mahol" To: Andrew Gallatin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: r187880 causes fatal trap 30 when unloading drivers X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 00:31:14 -0000 On 2/18/09, Andrew Gallatin wrote: > Paul B. Mahol wrote: > >> Fatal trap 30: reserved (unknown) fault while in kernel modecpuid = 1; > > <...> > >> The only workaroud is to disable SMP. > > Try backing out the commit in question and see if that helps. > I used the attached patch on yesterday's -current. > > Drew > Got hit with this again when unloading driver. If this issue dont get fixed and/or nobody cares for it being fixed, I'm voting for reverting r187880. -- Paul From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 01:27:15 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1663B106564A for ; Sat, 21 Feb 2009 01:27:15 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-gx0-f176.google.com (mail-gx0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id ACE518FC0C for ; Sat, 21 Feb 2009 01:27:14 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by gxk24 with SMTP id 24so4095956gxk.19 for ; Fri, 20 Feb 2009 17:27:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=SejXBnOGvVLaHBqqExjPKD6FWdCUL2H5QGwIEA/1DR0=; b=P0l4O6G1on/j6wFrY6e5MZfrqpbntmbml9bBQbGts4zGZDGqieZkZt0Cndu0Z5bSji msekxIT0GdDTrl1fUkn1X3kKj/bqxyTqIY5hNUdJ6D2WGHKlKb+qz/QrQjexOpCTsAzL iU1S05FuT81bqh/K2dDOBQnG/CraSNr56kJE0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Xq3aXlBOhPmMCOTJlWS4zgfpftJIf3dVLrCTFVzpODJ4yef90QPJJze3qT4PCoN3Bc Md8RBDLi/dCRgIiBOLzkFhAeI2feL9+wclhB5cJfB+09xEOX34JIozfHOwBXirs6ZWou W2On8yC56+6vzi0o0LW5pqu00BXPYNOi5hoek= MIME-Version: 1.0 Received: by 10.90.84.17 with SMTP id h17mr123917agb.40.1235179634005; Fri, 20 Feb 2009 17:27:14 -0800 (PST) In-Reply-To: References: <49935993.50303@stillbilde.net> <200902120818.34567.jhb@freebsd.org> Date: Fri, 20 Feb 2009 17:27:13 -0800 Message-ID: <7d6fde3d0902201727k61554608j9b3d5cdc3e78c3dc@mail.gmail.com> From: Garrett Cooper To: Buganini Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: army.of.root@googlemail.com, freebsd-current@freebsd.org Subject: Re: modular kernconf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 01:27:15 -0000 On Fri, Feb 20, 2009 at 10:35 AM, Buganini wrote: > I've made a patch to allow using section/nosection in kernconf. > http://140.112.64.5/buganini/config.patch > > My uname -a: > FreeBSD Zeta.twbbs.org 8.0-CURRENT FreeBSD 8.0-CURRENT #9: Fri Feb 20 > 01:18:21 CST 2009 root@Zeta.twbbs.org:/usr/obj/usr/src/sys/ZETA > i386 > > Currently this patch can deal with cpu/options/device/makeoptions, > probably enough (actually I think options/device is usually enough). > > I havent tested it fully, just modify GENERIC as follow: > ... > section USB2 > # USB core support > ... > section FireWire > # FireWire support > ... > > and the customized kernconf: > include GENERIC > ident ZETA > nosection USB2 > nosection FireWire > > then `config ZETA`, > I can see corresponding in > /usr/src/sys/i386/compile/ZETA/config.c > > The default section is "main", everythins before the first section > direction will be in section "main". > I've not really make kernel by this yet. The included file _must_ be quoted (at least on 8-CURRENT). It's a common mistake in the examples. HTH, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 01:51:51 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6435A106566B; Sat, 21 Feb 2009 01:51:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 24F8B8FC19; Sat, 21 Feb 2009 01:51:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1L1pmwQ087952; Fri, 20 Feb 2009 20:51:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1L1pmxj042896; Fri, 20 Feb 2009 20:51:48 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 718E87302F; Fri, 20 Feb 2009 20:51:48 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090221015148.718E87302F@freebsd-current.sentex.ca> Date: Fri, 20 Feb 2009 20:51:48 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 01:51:52 -0000 TB --- 2009-02-21 00:11:26 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-21 00:11:26 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2009-02-21 00:11:26 - cleaning the object tree TB --- 2009-02-21 00:11:56 - cvsupping the source tree TB --- 2009-02-21 00:11:56 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2009-02-21 00:12:05 - building world TB --- 2009-02-21 00:12:05 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-21 00:12:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-21 00:12:05 - TARGET=powerpc TB --- 2009-02-21 00:12:05 - TARGET_ARCH=powerpc TB --- 2009-02-21 00:12:05 - TZ=UTC TB --- 2009-02-21 00:12:05 - __MAKE_CONF=/dev/null TB --- 2009-02-21 00:12:05 - cd /src TB --- 2009-02-21 00:12:05 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 21 00:12:06 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Sat Feb 21 01:35:48 UTC 2009 TB --- 2009-02-21 01:35:48 - generating LINT kernel config TB --- 2009-02-21 01:35:48 - cd /src/sys/powerpc/conf TB --- 2009-02-21 01:35:48 - /usr/bin/make -B LINT TB --- 2009-02-21 01:35:48 - building LINT kernel TB --- 2009-02-21 01:35:48 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-21 01:35:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-21 01:35:48 - TARGET=powerpc TB --- 2009-02-21 01:35:48 - TARGET_ARCH=powerpc TB --- 2009-02-21 01:35:48 - TZ=UTC TB --- 2009-02-21 01:35:48 - __MAKE_CONF=/dev/null TB --- 2009-02-21 01:35:48 - cd /src TB --- 2009-02-21 01:35:48 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Feb 21 01:35:48 UTC 2009 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] machdep.o(.text+0x7ec): In function `grab_mcontext': : undefined reference to `save_vec' swtch.o(.text+0x64): In function `cpu_switch': : undefined reference to `save_vec' swtch.o(.text+0xac): In function `cpu_switchin': : undefined reference to `enable_vec' trap.o(.text+0xbf0): In function `trap': : undefined reference to `enable_vec' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-21 01:51:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-21 01:51:48 - ERROR: failed to build lint kernel TB --- 2009-02-21 01:51:48 - 4839.33 user 416.44 system 6021.48 real http://tinderbox.des.no/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 02:00:35 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 01C731065670 for ; Sat, 21 Feb 2009 02:00:35 +0000 (UTC) (envelope-from bsd@maxnet.ws) Received: from mx2.je-eigen-domein.nl (mx2.je-eigen-domein.nl [85.10.196.86]) by mx1.freebsd.org (Postfix) with ESMTP id BAE2A8FC14 for ; Sat, 21 Feb 2009 02:00:34 +0000 (UTC) (envelope-from bsd@maxnet.ws) Received: by mx2.je-eigen-domein.nl (Postfix, from userid 80) id 9484F3C002; Sat, 21 Feb 2009 03:25:07 +0100 (CET) To: freebsd-current@freebsd.org X-PHP-Script: www.je-eigen-domein.nl/webmail/index.php for 87.208.46.55 MIME-Version: 1.0 Date: Sat, 21 Feb 2009 03:25:07 +0100 From: Floris Bos Message-ID: <6599a94d9f968da5957fd7f49c8e715a@mx1.je-eigen-domein.nl> X-Sender: bsd@maxnet.ws User-Agent: RoundCube Webmail/0.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Subject: No disks found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 02:00:35 -0000 Hi, On one of my systems, I get the message "no disks found" during the installation of 8-current. During boot it detects the disk controller correctly (atapci0: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A0DBB106566C for ; Sat, 21 Feb 2009 02:47:51 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.freebsd.org (Postfix) with ESMTP id D148B8FC14 for ; Sat, 21 Feb 2009 02:47:50 +0000 (UTC) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.localnet (ppp121-45-60-236.lns11.adl2.internode.on.net [121.45.60.236]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id n1L2lhO3040784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Feb 2009 13:17:44 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Sat, 21 Feb 2009 13:17:33 +1030 User-Agent: KMail/1.10.4 (Linux/2.6.27-11-generic; KDE/4.1.4; i686; ; ) References: <5D267A3F22FD854F8F48B3D2B5238193394588D54D@IRVEXCHCCR01.corp.ad.broadcom.com> In-Reply-To: <5D267A3F22FD854F8F48B3D2B5238193394588D54D@IRVEXCHCCR01.corp.ad.broadcom.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1722849.InnfbM87XX"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200902211317.41479.doconnor@gsoft.com.au> X-Spam-Score: -2.212 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: David Christensen Subject: Re: Hopefully Simple Question on Debugging Kernel Modules X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 02:47:51 -0000 --nextPart1722849.InnfbM87XX Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 21 February 2009 10:10:56 David Christensen wrote: > I'm sure this is a simple question but the answer is alluding my Google eluding -^ > search capabilities. My driver is being loaded as a kernel module and > is failing with the following error: > > Fatal trap 12: page fault while in kernel mode > cpuid =3D 0; apic id =3D 00 > fault virtual address =3D 0xfffffffe40abe9dc > fault code =3D supervisor write data, page not present > instruction pointer =3D 0x8:0xffffffff920b638f > stack pointer =3D 0x10:0xffffffff9212bb10 > frame pointer =3D 0x10:0xffffffff9212bbb0 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 12 (irq268: bce0) > [thread pid 12 tid 100166 ] > Stopped at bce_intr+0x8df: addl $0x1,0x2c854(%r12,%rax,4) > db> > > I simply need to find the offending source line in my driver. Not sure > how I've managed to get the driver running at all without this but it's > time to do things the right way. I have KDB/DDB/GDB built into my > -CURRENT kernel already. It'd be great to find the source line while in > the kernel debugger but I'm also fine with rebooting the system to > identify the line number. DDB doesn't understand debugging symbols to that degree, however you could= =20 connect a GDB remotely using a serial or firewire connection (the later is= =20 much, much nicer) I imagine you could get GDB or some other tool to tell you what line that=20 offset corresponds to but I'm not sure how you go about doing that with=20 modules loaded unless you have a crash dump (or remote GDB on a live system) I guess you could also rebuild your .c files with.. -Wa,-adhlmsn=3D$foo.lst= and=20 look it up that way. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1722849.InnfbM87XX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQBJn2tG5ZPcIHs/zowRAkglAKCmlFLD5sdGRfSaMmKCV8fYNTYvLgCeJ/Wd NVCxj4fFU30jPtmTKR1jXKk= =TIRH -----END PGP SIGNATURE----- --nextPart1722849.InnfbM87XX-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 03:00:47 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA5CE1065675; Sat, 21 Feb 2009 03:00:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.freebsd.org (Postfix) with ESMTP id 942C58FC0C; Sat, 21 Feb 2009 03:00:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.14.3/8.14.3) with ESMTP id n1L30jBO092856; Fri, 20 Feb 2009 22:00:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.14.3/8.14.3) with ESMTP id n1L30jE1085048; Fri, 20 Feb 2009 22:00:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 20F247302F; Fri, 20 Feb 2009 22:00:45 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20090221030045.20F247302F@freebsd-current.sentex.ca> Date: Fri, 20 Feb 2009 22:00:45 -0500 (EST) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.64 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 03:00:48 -0000 TB --- 2009-02-21 01:51:48 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2009-02-21 01:51:48 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2009-02-21 01:51:48 - cleaning the object tree TB --- 2009-02-21 01:52:12 - cvsupping the source tree TB --- 2009-02-21 01:52:12 - /usr/bin/csup -z -r 3 -g -L 1 -h localhost -s /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2009-02-21 01:52:19 - building world TB --- 2009-02-21 01:52:19 - MAKEOBJDIRPREFIX=/obj TB --- 2009-02-21 01:52:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2009-02-21 01:52:19 - TARGET=sun4v TB --- 2009-02-21 01:52:19 - TARGET_ARCH=sparc64 TB --- 2009-02-21 01:52:19 - TZ=UTC TB --- 2009-02-21 01:52:19 - __MAKE_CONF=/dev/null TB --- 2009-02-21 01:52:19 - cd /src TB --- 2009-02-21 01:52:19 - /usr/bin/make -B buildworld >>> World build started on Sat Feb 21 01:52:20 UTC 2009 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /obj/sun4v/src/tmp/usr/include/dev/usb2/include/usb2_standard.h:596: error: conflicting types for 'usb_otg_descriptor_t' /obj/sun4v/src/tmp/usr/include/dev/usb/usb.h:362: error: previous declaration of 'usb_otg_descriptor_t' was here /obj/sun4v/src/tmp/usr/include/dev/usb2/include/usb2_standard.h:611: error: conflicting types for 'usb_status_t' /obj/sun4v/src/tmp/usr/include/dev/usb/usb.h:376: error: previous declaration of 'usb_status_t' was here /obj/sun4v/src/tmp/usr/include/dev/usb2/include/usb2_standard.h:619: error: conflicting types for 'usb_hub_status_t' /obj/sun4v/src/tmp/usr/include/dev/usb/usb.h:383: error: previous declaration of 'usb_hub_status_t' was here /obj/sun4v/src/tmp/usr/include/dev/usb2/include/usb2_standard.h:641: error: conflicting types for 'usb_port_status_t' /obj/sun4v/src/tmp/usr/include/dev/usb/usb.h:403: error: previous declaration of 'usb_port_status_t' was here *** Error code 1 Stop in /src/usr.bin/kdump. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2009-02-21 03:00:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2009-02-21 03:00:44 - ERROR: failed to build world TB --- 2009-02-21 03:00:44 - 3410.39 user 332.16 system 4136.39 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 07:40:41 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D1A3106566C for ; Sat, 21 Feb 2009 07:40:41 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 382368FC15 for ; Sat, 21 Feb 2009 07:40:41 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (pD9E2C405.dip.t-dialin.net [217.226.196.5]) by redbull.bpaserver.net (Postfix) with ESMTP id F3D682E0E2 for ; Sat, 21 Feb 2009 08:24:56 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 94D5FBF3BD for ; Sat, 21 Feb 2009 08:24:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1235201093; bh=ulYMREvR772FDqUWgJN9wWV3ruF4Sj7cg vQKDu9Lj1E=; h=Message-ID:Date:From:To:Subject:MIME-Version: Content-Type:Content-Transfer-Encoding; b=FFVxer4CauICj1IIbpPMEoyU CUSRz1UMwi5vbscGpIO58dTiAAxsoMlBuIkU/v06KmQCAWsDVtTvXITcYYF9L5fof6A 4YvC6bKYQOtDjo+4zGQ/uT+ZbvKqbenPhtlZjoU6134j+/mK1Cl/TWWajQdhR0ZaQbz QbZgTeTdtNJLFZldwjfzKiXCQRPombEoQADQHxhoMkYCVjr46nVHnSyhDKRVGxxavY0 fGaqzRQzMEs7vlqEgmoUdL6fm2Qe7aVhZM+57bdcl2Jf+LD+RFLe3xXgyiPQc7bRpMf l/An6qmd3aF+wTh+KxXCSykXvhqHywGc2OKKVvYsMsCA0qRItw== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n1L7OrGw007124 for current@freebsd.org; Sat, 21 Feb 2009 08:24:53 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Luna.Leidinger.net (Luna.Leidinger.net [192.168.2.100]) by webmail.leidinger.net (Horde Framework) with HTTP; Sat, 21 Feb 2009 08:24:52 +0100 Message-ID: <20090221082452.2087647tusayg60w@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Sat, 21 Feb 2009 08:24:52 +0100 From: Alexander Leidinger To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: F3D682E0E2.E7FA0 X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-13.234, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, RDNS_DYNAMIC 0.10, SARE_SUB_CASINO_OB2 1.67) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Subject: Problems with savecore / crashinfo_enable=yes? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 07:40:41 -0000 Hi, I noticed already 2 times that /etc/rc.d/savecore does not stop. It blocks the booting until I press ctrl-c. I have crashinfo enabled, I use the default ddb.conf. Anyone else experiencing this? Bye, Alexander. -- Help fight continental drift. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 07:40:42 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A1861065670 for ; Sat, 21 Feb 2009 07:40:42 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 317FE8FC14 for ; Sat, 21 Feb 2009 07:40:41 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (pD9E2C405.dip.t-dialin.net [217.226.196.5]) by redbull.bpaserver.net (Postfix) with ESMTP id 603342E0AD; Sat, 21 Feb 2009 08:21:31 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id BE041BF3A0; Sat, 21 Feb 2009 08:21:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1235200886; bh=7m6/wM3biaUp/z+1EYqlFMZigwe0Q6cAI 9TcOp8a7uI=; h=Message-ID:Date:From:To:Subject:MIME-Version: Content-Type:Content-Transfer-Encoding; b=eqgSUfmRm/nIlrgeG7q0UYBI uKVHqxcHZFvq5ToqtZvsjIIczx777SOmjSouec76o67RnkJuUOTX/UfpAce+bhbUF4z fUPZPE+1IKZkW08Se14lPSwwlxUMio1P87mQDafI+fjSZXqn5urXOb6fGlSVRaYHNG/ 1bhGMXjGXWnf0SQiFP+UAMl1bc/cX58Mme9yMFuaMcRpFp8sY8WJohazQ9H9utjOXwg Kh08TwEWjxBBc50V1GnC6lDkI0NcJa5LOAEgmlqmcAIj0QlKSpLrclNg8LRhzEhGirt Jkte0r4v4PMRi2tDpAkER9JEVElRoauJjK2obRxWo7LO+/HpSQ== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id n1L7LPnA006426; Sat, 21 Feb 2009 08:21:25 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from Luna.Leidinger.net (Luna.Leidinger.net [192.168.2.100]) by webmail.leidinger.net (Horde Framework) with HTTP; Sat, 21 Feb 2009 08:21:25 +0100 Message-ID: <20090221082125.80181fdf4561z7vo@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Sat, 21 Feb 2009 08:21:25 +0100 From: Alexander Leidinger To: current@freebsd.org, pjd@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_10zr6qzqfkhc" Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-MailScanner-ID: 603342E0AD.15728 X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, ORDB-RBL, SpamAssassin (not cached, score=-11.826, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, J_CHICKENPOX_23 0.60, MIME_QP_LONG_LINE 1.40, RDNS_DYNAMIC 0.10, TW_BD 0.08, TW_EV 0.08, TW_KB 0.08, TW_KQ 0.08, TW_PG 0.08, TW_QR 0.08, TW_SB 0.08, TW_SK 0.08, TW_SV 0.08, TW_TK 0.08, TW_TX 0.08, TW_VB 0.08, TW_VL 0.08, TW_ZF 0.08) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: Subject: panic in zfs: solaris assert: sm->sm_space == 0 (0x2d800 == 0x0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 07:40:42 -0000 This message is in MIME format. --=_10zr6qzqfkhc Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit Hi, I got a panic in zfs. The file where the kassert is, is at CVS rev 1.3 (sorry, no idea which svn rev this is, and unfortunately there are no ID tags inside). The crash dump is attached. Any other info needed? Bye, Alexander. -- To you I'm an atheist; to God, I'm the loyal opposition. -- Woody Allen http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 --=_10zr6qzqfkhc Content-Type: text/plain; charset=UTF-8; name="core.txt.22" Content-Disposition: attachment; filename="core.txt.22" Content-Transfer-Encoding: quoted-printable M87.Leidinger.net dumped core - see /var/crash/vmcore.22 Sat Feb 21 08:09:18 CET 2009 FreeBSD M87.Leidinger.net 8.0-CURRENT FreeBSD 8.0-CURRENT #29: Sat Nov 29 18= :43:42 CET 2008 root@M87.Leidinger.net:/space/system/usr_src/sys/i386/co= mpile/M87 i386 panic: solaris assert: sm->sm_space =3D=3D 0 (0x2d800 =3D=3D 0x0), file: /sp= ace/system/usr_src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common= /fs/zfs/space_map.c, line: 498 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions= . Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd"... Unread portion of the kernel message buffer: panic: solaris assert: sm->sm_space =3D=3D 0 (0x2d800 =3D=3D 0x0), file: /sp= ace/system/usr_src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common= /fs/zfs/space_map.c, line: 498 cpuid =3D 0 KDB: stack backtrace: db_trace_self_wrapper(8072f70f,0,8097ef75,83bada1c,0,...) at db_trace_self_w= rapper+0x26 panic(8097ef75,80983362,2d800,0,8097eef8,...) at panic+0x116 space_map_sync(8418e48c,0,8418e42c,841fb618,88f38080,...) at space_map_sync+= 0x464 metaslab_sync(8418e400,b5821d,0,0,83badb5c,...) at metaslab_sync+0xfc vdev_sync(841e9800,b5821d,0,0,0,...) at vdev_sync+0x70 spa_sync(83eac800,b5821d,0,0,3e8,...) at spa_sync+0x3cf txg_sync_thread(84508800,83badd38,0,0,0,...) at txg_sync_thread+0x3bb fork_exit(808ebb20,84508800,83badd38) at fork_exit+0x90 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip =3D 0, esp =3D 0x83badd70, ebp =3D 0 --- Uptime: 6h17m43s Physical memory: 1015 MB Dumping 305 MB: 290 274 258 242 226 210 194 178 162 146 130 114 98 82 66 50 = 34 18 2 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel= /zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boo= t/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /boo= t/kernel/geom_mirror.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kern= el/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko Reading symbols from /boot/kernel/miibus.ko...Reading symbols from /boot/ker= nel/miibus.ko.symbols...done. done. Loaded symbols for /boot/kernel/miibus.ko Reading symbols from /boot/kernel/if_dc.ko...Reading symbols from /boot/kern= el/if_dc.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_dc.ko Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from /boot/ke= rnel/snd_ich.ko.symbols...done. done. Loaded symbols for /boot/kernel/snd_ich.ko Reading symbols from /boot/kernel/sound.ko...Reading symbols from /boot/kern= el/sound.ko.symbols...done. done. Loaded symbols for /boot/kernel/sound.ko Reading symbols from /boot/kernel/ugen.ko...Reading symbols from /boot/kerne= l/ugen.ko.symbols...done. done. Loaded symbols for /boot/kernel/ugen.ko Reading symbols from /boot/kernel/uhid.ko...Reading symbols from /boot/kerne= l/uhid.ko.symbols...done. done. Loaded symbols for /boot/kernel/uhid.ko Reading symbols from /boot/kernel/ukbd.ko...Reading symbols from /boot/kerne= l/ukbd.ko.symbols...done. done. Loaded symbols for /boot/kernel/ukbd.ko Reading symbols from /boot/kernel/ums.ko...Reading symbols from /boot/kernel= /ums.ko.symbols...done. done. Loaded symbols for /boot/kernel/ums.ko Reading symbols from /boot/kernel/umass.ko...Reading symbols from /boot/kern= el/umass.ko.symbols...done. done. Loaded symbols for /boot/kernel/umass.ko Reading symbols from /boot/kernel/cam.ko...Reading symbols from /boot/kernel= /cam.ko.symbols...done. done. Loaded symbols for /boot/kernel/cam.ko Reading symbols from /boot/kernel/accf_dns.ko...Reading symbols from /boot/k= ernel/accf_dns.ko.symbols...done. done. Loaded symbols for /boot/kernel/accf_dns.ko Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from /boot/= kernel/accf_http.ko.symbols...done. done. Loaded symbols for /boot/kernel/accf_http.ko Reading symbols from /boot/kernel/kbdmux.ko...Reading symbols from /boot/ker= nel/kbdmux.ko.symbols...done. done. Loaded symbols for /boot/kernel/kbdmux.ko Reading symbols from /boot/kernel/vkbd.ko...Reading symbols from /boot/kerne= l/vkbd.ko.symbols...done. done. Loaded symbols for /boot/kernel/vkbd.ko Reading symbols from /boot/kernel/cpufreq.ko...Reading symbols from /boot/ke= rnel/cpufreq.ko.symbols...done. done. Loaded symbols for /boot/kernel/cpufreq.ko Reading symbols from /boot/kernel/cpuctl.ko...Reading symbols from /boot/ker= nel/cpuctl.ko.symbols...done. done. Loaded symbols for /boot/kernel/cpuctl.ko Reading symbols from /boot/kernel/radeon.ko...Reading symbols from /boot/ker= nel/radeon.ko.symbols...done. done. Loaded symbols for /boot/kernel/radeon.ko Reading symbols from /boot/kernel/drm.ko...Reading symbols from /boot/kernel= /drm.ko.symbols...done. done. Loaded symbols for /boot/kernel/drm.ko Reading symbols from /boot/kernel/geom_md.ko...Reading symbols from /boot/ke= rnel/geom_md.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_md.ko Reading symbols from /boot/kernel/nfsserver.ko...Reading symbols from /boot/= kernel/nfsserver.ko.symbols...done. done. Loaded symbols for /boot/kernel/nfsserver.ko Reading symbols from /boot/kernel/krpc.ko...Reading symbols from /boot/kerne= l/krpc.ko.symbols...done. done. Loaded symbols for /boot/kernel/krpc.ko Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/ker= nel/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko #0 doadump () at pcpu.h:246 246=09pcpu.h: No such file or directory. =09in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0x80539e04 in boot (howto=3D260) at ../../../kern/kern_shutdown.c:420 #2 0x8053a26a in panic ( fmt=3D0x8097ef75 "solaris assert: %s (0x%jx %s 0x%jx), file: %s, line: %= d") at ../../../kern/kern_shutdown.c:576 #3 0x808e9624 in space_map_truncate (smo=3D0x8097eef8, os=3D0x0, tx=3D0x841= 8e42c) at /space/system/usr_src/sys/modules/zfs/../../cddl/contrib/opensolaris/= uts/common/fs/zfs/space_map.c:504 #4 0x808d9e8c in metaslab_alloc (spa=3D0x8418e400, mc=3D0xb5821d, psize=3D0= ,=20 bp=3D0x83badb5c, ndvas=3D-2138133578, txg=3D11895324, hintbp=3D0x841e99f= 8,=20 flags=3D-2081765376) at /space/system/usr_src/sys/modules/zfs/../../cddl/contrib/opensolaris/= uts/common/fs/zfs/metaslab.c:767 #5 0x808ede20 in vdev_resilver_needed (vd=3D0x0, minp=3D0xb5821d, maxp=3D0x= 0) at /space/system/usr_src/sys/modules/zfs/../../cddl/contrib/opensolaris/= uts/common/fs/zfs/vdev.c:1484 #6 0x808e21ef in spa_prop_get (spa=3D0x83eac800, nvp=3D0xb5821d) at /space/system/usr_src/sys/modules/zfs/../../cddl/contrib/opensolaris/= uts/common/fs/zfs/spa.c:224 #7 0x808ebedb in txg_init (dp=3D0x0, txg=3D2210061624) at /space/system/usr_src/sys/modules/zfs/../../cddl/contrib/opensolaris/= uts/common/fs/zfs/txg.c:79 #8 0x80516ea0 in fork_exit (callout=3D0x808ebb20 ,= =20 arg=3D0x84508800, frame=3D0x83badd38) at ../../../kern/kern_fork.c:815 #9 0x806c51e0 in fork_trampoline () at ../../../i386/i386/exception.s:270 (kgdb)=20 ------------------------------------------------------------------------ ps -axl UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 0 0 0 8 0 0 0 - DLs ?? 451057:32.00 [kern= el] 0 1 0 0 46 0 1888 0 wait DLs ?? 278659:08.00 [init= ] 0 2 0 0 -8 0 0 0 - DL ?? 1666053:08.00 [g_e= vent] 0 3 0 0 -8 0 0 0 - RL ?? 22155910:04.00 [g_= up] 0 4 0 0 -8 0 0 0 - DL ?? 23764131:22.00 [g_= down] 0 5 0 0 -16 0 0 0 tq->tq DL ?? 0:00.00 [system_= tas 0 6 0 0 -16 0 0 0 tq->tq DL ?? 0:00.00 [system_= tas 0 7 0 0 -16 0 0 0 ccb_sc DL ?? 0:00.00 [xpt_thr= d] 0 8 0 0 -16 0 0 0 - DL ?? 109338:10.00 [fdc0= ] 0 9 0 0 44 0 0 0 d DL ?? 2493831:04.00 [arc= _reclai 0 10 0 0 171 0 0 0 - RL ?? -28867976:-53.55 [= idle] 0 11 0 0 -60 0 0 0 - WL ?? 11591856:38.00 [in= tr] 0 12 0 0 -16 0 0 0 - DL ?? 2336104:46.00 [yar= row] 0 13 0 0 -16 0 0 0 usbevt DL ?? 2295:28.00 [usb0] 0 14 0 0 -16 0 0 0 usbtsk DL ?? 0:00.00 [usbtask= -hc 0 15 0 0 -16 0 0 0 usbtsk DL ?? 0:00.00 [usbtask= -dr 0 16 0 0 -16 0 0 0 usbevt DL ?? 1403:00.00 [usb1] 0 17 0 0 -16 0 0 0 usbevt DL ?? 1646:24.00 [usb2] 0 18 0 0 -16 0 0 0 usbevt DL ?? 1368:28.00 [usb3] 0 19 0 0 -16 0 0 0 usbevt DL ?? 3245:44.00 [usb4] 0 20 0 0 -16 0 0 0 tzpoll DL ?? 2085038:22.00 [acp= i_therm 0 21 0 0 -16 0 0 0 coolin DL ?? 14535:52.00 [acpi_= cooli 0 22 0 0 -16 0 0 0 809944f4 DL ?? 98178:30.00 [l2a= rc_feed 0 23 0 0 -32 0 0 0 psleep DL ?? 27531:00.00 [paged= aemon 0 24 0 0 -32 0 0 0 psleep DL ?? 202:04.00 [vmdaemo= n] 0 25 0 0 76 0 0 0 pgzero DL ?? 351:28.00 [pagezer= o] 0 26 0 0 -32 0 0 0 psleep DL ?? 88333:52.00 [bufda= emon] 0 27 0 0 44 0 0 0 syncer DL ?? 9047316:38.00 [syn= cer] 0 28 0 0 44 0 0 0 vlruwt DL ?? 106473:26.00 [vnlr= u] 0 29 0 0 -32 0 0 0 sdflus DL ?? 369536:34.00 [soft= depflu 0 30 0 0 -8 0 0 0 m:w1 DL ?? 2066853:04.00 [g_m= irror r 0 31 0 0 -8 0 0 0 m:w1 DL ?? 16551:48.00 [g_mir= ror s 0 125 0 0 76 0 0 0 tq->tq DL ?? 301278:36.00 [spa_= zio] 0 126 0 0 76 0 0 0 tq->tq DL ?? 411130:28.00 [spa_= zio] 0 127 0 0 76 0 0 0 tq->tq DL ?? 138630:56.00 [spa_= zio] 0 128 0 0 44 0 0 0 - RL ?? 11552909:32.00 [sp= a_zio] 0 129 0 0 44 0 0 0 tq->tq DL ?? 2427929:36.00 [spa= _zio] 0 130 0 0 76 0 0 0 tq->tq DL ?? 1894784:04.00 [spa= _zio] 0 131 0 0 76 0 0 0 tq->tq DL ?? 1900236:12.00 [spa= _zio] 0 132 0 0 76 0 0 0 tq->tq DL ?? 1962426:52.00 [spa= _zio] 0 133 0 0 76 0 0 0 tq->tq DL ?? 1836002:28.00 [spa= _zio] 0 134 0 0 76 0 0 0 tq->tq DL ?? 2143021:00.00 [spa= _zio] 0 135 0 0 76 0 0 0 tq->tq DL ?? 1814434:44.00 [spa= _zio] 0 136 0 0 76 0 0 0 tq->tq DL ?? 1153919:16.00 [spa= _zio] 0 137 0 0 44 0 0 0 tq->tq DL ?? 1474666:20.00 [spa= _zio] 0 138 0 0 44 0 0 0 tq->tq DL ?? 1472723:20.00 [spa= _zio] 0 139 0 0 44 0 0 0 tq->tq DL ?? 962872:24.00 [spa_= zio] 0 140 0 0 44 0 0 0 tq->tq DL ?? 1431527:56.00 [spa= _zio] 0 141 0 0 44 0 0 0 tq->tq DL ?? 1797704:08.00 [spa= _zio] 0 142 0 0 44 0 0 0 tq->tq DL ?? 1287222:56.00 [spa= _zio] 0 143 0 0 44 0 0 0 tq->tq DL ?? 2440316:34.00 [spa= _zio] 0 144 0 0 44 0 0 0 tq->tq DL ?? 7525984:56.00 [spa= _zio] 0 145 0 0 76 0 0 0 tq->tq DL ?? 131:28.00 [spa_zio= ] 0 146 0 0 76 0 0 0 tq->tq DL ?? 133:04.00 [spa_zio= ] 0 147 0 0 76 0 0 0 tq->tq DL ?? 144:28.00 [spa_zio= ] 0 148 0 0 76 0 0 0 tq->tq DL ?? 151:20.00 [spa_zio= ] 0 149 0 0 76 0 0 0 tq->tq DL ?? 126:52.00 [spa_zio= ] 0 150 0 0 76 0 0 0 tq->tq DL ?? 202609:40.00 [spa_= zio] 0 151 0 0 76 0 0 0 84268048 DL ?? 1497950:38.00 [v= dev:worke 0 152 0 0 76 0 0 0 84319508 DL ?? 1534427:56.00 [v= dev:worke 0 153 0 0 76 0 0 0 84319748 DL ?? 1532318:14.00 [v= dev:worke 0 154 0 0 76 0 0 0 tx->tx DL ?? 7354:52.00 [txg_th= read 0 155 0 0 44 0 0 0 - RL ?? 2599686:34.00 [txg= _thread 0 157 0 0 76 0 0 0 tq->tq DL ?? 458:32.00 [zil_cle= an] 0 158 0 0 76 0 0 0 tq->tq DL ?? 355:44.00 [zil_cle= an] 0 159 0 0 76 0 0 0 tq->tq DL ?? 305:00.00 [zil_cle= an] 0 160 0 0 76 0 0 0 tq->tq DL ?? 352:36.00 [zil_cle= an] 0 161 0 0 76 0 0 0 tq->tq DL ?? 359:36.00 [zil_cle= an] 0 162 0 0 76 0 0 0 tq->tq DL ?? 343:44.00 [zil_cle= an] 0 163 0 0 76 0 0 0 tq->tq DL ?? 402:16.00 [zil_cle= an] 0 164 0 0 76 0 0 0 tq->tq DL ?? 397:20.00 [zil_cle= an] 0 165 0 0 76 0 0 0 tq->tq DL ?? 295:40.00 [zil_cle= an] 0 166 0 0 76 0 0 0 tq->tq DL ?? 313:20.00 [zil_cle= an] 0 167 0 0 76 0 0 0 tq->tq DL ?? 10100:00.00 [zil_c= lean] 0 168 0 0 76 0 0 0 tq->tq DL ?? 3262:36.00 [zil_cl= ean] 0 169 0 0 76 0 0 0 tq->tq DL ?? 2686:16.00 [zil_cl= ean] 0 170 0 0 76 0 0 0 tq->tq DL ?? 383:40.00 [zil_cle= an] 0 171 0 0 76 0 0 0 tq->tq DL ?? 362:32.00 [zil_cle= an] 0 172 0 0 76 0 0 0 tq->tq DL ?? 406:16.00 [zil_cle= an] 0 173 0 0 76 0 0 0 tq->tq DL ?? 368:56.00 [zil_cle= an] 0 174 0 0 76 0 0 0 tq->tq DL ?? 316:04.00 [zil_cle= an] 0 175 0 0 76 0 0 0 tq->tq DL ?? 398:00.00 [zil_cle= an] 0 176 0 0 76 0 0 0 tq->tq DL ?? 374:40.00 [zil_cle= an] 0 177 0 0 76 0 0 0 tq->tq DL ?? 2157:28.00 [zil_cl= ean] 0 208 1 0 76 0 1448 0 pause Ds ?? 24082:56.00 [adjke= rntz] 0 543 1 0 44 0 3352 0 select Ds ?? 19063:48.00 [mouse= d] 0 592 1 0 57 0 1888 0 select Ds ?? 12875889:58.00 [de= vd] 0 727 1 0 44 0 3252 0 select Ds ?? 3247142:16.00 [sys= logd] 1 797 1 0 44 0 3280 0 select Ds ?? 344110:12.00 [rpcb= ind] 0 821 0 0 -8 0 0 0 mdwait DL ?? 86614:28.00 [md0] 0 870 1 0 76 0 3252 0 select Ds ?? 173395:24.00 [moun= td] 0 878 1 0 76 0 3196 0 accept Ds ?? 1494420:40.00 [nfs= d] 0 879 878 0 44 0 3196 0 rpcsvc D ?? 95644:50.00 [nfsd] 0 903 1 0 44 0 4416 0 nanslp D ?? 371823:24.00 [smar= td] 0 959 1 0 44 0 4772 0 select Ds ?? 4325991:58.00 [ntp= d] 0 966 1 0 44 0 3252 0 select Ds ?? 10497990:42.00 [po= werd] 0 1013 1 0 76 0 6520 0 select Ds ?? 78373:12.00 [sshd] 0 1229 1 0 44 0 3216 0 select Ds ?? 361579:56.00 [sysl= ogd] 53 1244 1 0 44 0 22564 0 select Ds ?? 9323261:04.00 [nam= ed] 0 1343 1 0 76 0 6520 0 select Ds ?? 96009:28.00 [sshd] 0 1350 1 0 44 0 5924 0 pause Ds ?? 135613:36.00 [send= mail] 0 1357 1 0 44 0 3244 0 nanslp Ds ?? 364200:38.00 [cron= ] 0 1495 1 0 44 0 3216 0 select Ds ?? 191990:20.00 [sysl= ogd] 125 1552 1 0 76 0 12620 0 sigwai Ds ?? 7718931:18.00 [dki= m-filte 0 1640 1 0 44 0 5920 0 kqread Ds ?? 1723421:42.00 [mas= ter] 125 1654 1640 0 44 0 5920 0 kqread D ?? 1167711:54.00 [qmg= r] 0 1659 1 0 76 0 6520 0 select Ds ?? 89479:52.00 [sshd] 0 1668 1 0 44 0 3244 0 nanslp Ds ?? 319592:02.00 [cron= ] 0 1805 1 0 44 0 3216 0 select Ds ?? 921985:08.00 [sysl= ogd] 0 1898 1 0 44 0 73848 0 select Ds ?? -22630975:-25.55 [= perl5.8.8] 0 1908 1 0 76 0 3160 0 piperd D ?? 137147:52.00 [cour= ierlog 0 1909 1908 0 44 0 3444 0 select D ?? 1379754:16.00 [aut= hdaemon 0 1916 1 0 44 0 5924 0 pause Ds ?? 122834:04.00 [send= mail] 0 1930 1909 0 44 0 3444 0 select D ?? 260061:48.00 [auth= daemon 0 1931 1909 0 44 0 3444 0 select D ?? 368388:28.00 [auth= daemon 0 1967 1 0 76 0 3160 0 piperd D ?? 72051:04.00 [couri= erlog 0 1968 1967 0 76 0 3160 0 select D ?? 371141:40.00 [cour= iertcp 0 1977 1 0 44 0 3160 0 piperd D ?? 188370:20.00 [cour= ierlog 0 1978 1977 0 46 0 3160 0 select D ?? 637650:36.00 [cour= iertcp 0 2015 1898 0 44 0 81832 0 select D ?? 383591:24.00 [perl= 5.8.8] 0 2050 1 0 44 0 6520 0 select Ds ?? 203623:52.00 [sshd= ] 0 2055 1 0 44 0 3244 0 nanslp Ds ?? 526224:52.00 [cron= ] 0 2178 1 0 44 0 3216 0 select Ds ?? 158316:36.00 [sysl= ogd] 88 2275 1 0 76 0 3496 0 wait D ?? 985916:52.00 [sh] 88 2312 2275 0 44 0 49940 0 sigwai D ?? 25182239:32.00 [my= sqld] 0 2777 1 0 68 0 6520 0 select Ds ?? 98054:04.00 [sshd] 0 2784 1 0 44 0 5924 0 pause Ds ?? 125303:08.00 [send= mail] 0 2791 1 0 44 0 3244 0 nanslp Ds ?? 305843:56.00 [cron= ] 0 2916 1 0 44 0 3216 0 select Ds ?? 160805:40.00 [sysl= ogd] 0 3091 1 0 44 0 26068 0 select Ds ?? 21839658:26.00 [ht= tpd] 0 3108 1 0 76 0 6520 0 select Ds ?? 106348:28.00 [sshd= ] 0 3115 1 0 44 0 5924 0 pause Ds ?? 126747:08.00 [send= mail] 0 3122 1 0 44 0 3244 0 nanslp Ds ?? 248563:16.00 [cron= ] 0 3253 1 0 44 0 3252 0 select Ds ?? 138379:24.00 [sysl= ogd] 0 3366 1 0 76 0 6520 0 select Ds ?? 94820:12.00 [sshd] 0 3373 1 0 44 0 5960 0 pause Ds ?? 123069:04.00 [send= mail] 0 3380 1 0 44 0 3280 0 nanslp Ds ?? 338506:36.00 [cron= ] 0 3519 1 0 44 0 3216 0 select Ds ?? 324463:24.00 [sysl= ogd] 0 3592 1 0 44 0 8528 0 select Ds ?? 1239194:00.00 [nmb= d] 0 3596 1 0 52 0 12216 0 select Ds ?? 1249238:00.00 [smb= d] 0 3644 3596 0 51 0 12216 0 pause D ?? 34822:12.00 [smbd] 0 3886 1 0 67 0 6520 0 select Ds ?? 104942:00.00 [sshd= ] 0 3893 1 0 44 0 5924 0 pause Ds ?? 125288:28.00 [send= mail] 0 3900 1 0 44 0 3244 0 nanslp Ds ?? 313375:24.00 [cron= ] 0 4022 1 0 44 0 3216 0 select Ds ?? 151508:44.00 [sysl= ogd] 100 4118 1 0 76 0 5576 0 wait Ds ?? 85208:32.00 [squid= ] 100 4120 4118 0 67 0 14792 0 ucond D ?? -33566108:-21.55 [= squid] 0 4137 1 0 76 0 6520 0 select Ds ?? 87393:32.00 [sshd] 0 4144 1 0 44 0 5924 0 pause Ds ?? 122986:20.00 [send= mail] 0 4151 1 0 44 0 3244 0 nanslp Ds ?? 301907:04.00 [cron= ] 100 4175 4120 0 76 0 1408 0 piperd Ds ?? 97317:08.00 [unlin= kd] 0 4284 1 0 44 0 3216 0 select Ds ?? 124172:48.00 [sysl= ogd] 0 4459 1 0 69 0 6520 0 select Ds ?? 89199:48.00 [sshd] 0 4466 1 0 44 0 5924 0 pause Ds ?? 119847:56.00 [send= mail] 0 4473 1 0 44 0 3244 0 nanslp Ds ?? 361535:16.00 [cron= ] 0 4487 1 0 76 0 3272 0 select Ds ?? 223592:56.00 [inet= d] 0 4600 1 0 44 0 3216 0 select Ds ?? 124827:16.00 [sysl= ogd] 0 4695 1 0 44 0 19108 0 select Ds ?? 5454971:52.00 [htt= pd] 0 4712 1 0 76 0 6520 0 select Ds ?? 90270:40.00 [sshd] 0 4719 1 0 44 0 5924 0 pause Ds ?? 122634:12.00 [send= mail] 0 4726 1 0 44 0 3244 0 nanslp Ds ?? 279145:04.00 [cron= ] 80 4797 4695 0 61 0 19108 0 accept D ?? 102306:48.00 [http= d] 0 4866 1 0 44 0 3216 0 select Ds ?? 122368:44.00 [sysl= ogd] 0 4961 1 0 44 0 20008 0 select Ds ?? 31431925:48.00 [ht= tpd] 0 4978 1 0 76 0 6520 0 select Ds ?? 91521:04.00 [sshd] 0 4985 1 0 44 0 5924 0 pause Ds ?? 123613:12.00 [send= mail] 0 4992 1 0 44 0 3244 0 nanslp Ds ?? 247899:56.00 [cron= ] 80 5064 4961 0 44 0 22056 0 accept D ?? 180498:40.00 [http= d] 80 5065 4961 0 63 0 20008 0 accept D ?? 114843:04.00 [http= d] 0 5095 1 0 44 0 5960 0 select Ds ?? 131371:24.00 [send= mail] 25 5101 1 0 44 0 5960 0 pause Ds ?? 112936:48.00 [send= mail] 0 5107 1 0 44 0 3280 0 nanslp Ds ?? 225909:08.00 [cron= ] 0 5119 1 0 76 0 3532 0 wait D ?? 127942:40.00 [sh] 0 5155 1 0 76 0 3308 0 select Ds ?? 205544:40.00 [inet= d] 0 5182 1 0 76 0 3252 0 tty in Ds ?? 167007:24.00 [gett= y] 0 5183 1 0 76 0 3252 0 tty in Ds ?? 175454:56.00 [gett= y] 0 5184 1 0 76 0 3252 0 tty in Ds ?? 158722:28.00 [gett= y] 0 5185 1 0 76 0 3252 0 tty in Ds ?? 161638:24.00 [gett= y] 0 5186 1 0 76 0 3252 0 tty in Ds ?? 163116:36.00 [gett= y] 0 5187 1 0 76 0 3252 0 tty in Ds ?? 151599:28.00 [gett= y] 0 5188 1 0 76 0 3252 0 tty in Ds ?? 158330:00.00 [gett= y] 0 6095 1 0 44 0 3252 0 tty in Ds ?? 109721:20.00 [gett= y] 0 7772 1 0 44 0 6476 0 kqread Ds ?? 0:00.00 [nscd] 1001 7879 1 0 46 0 7208 0 select Ds ?? 17129708:40.00 [fe= tchmail] 1002 7909 1 0 44 0 6184 0 select Ds ?? 0:00.00 [fetchma= il] 125 11878 1640 0 44 0 5920 0 kqread D ?? 0:00.00 [tlsmgr] 80 15626 3091 0 46 0 35864 0 accept D ?? 0:00.00 [httpd] 80 19106 3091 0 46 0 34840 0 accept D ?? 0:00.00 [httpd] 125 57540 1640 0 44 0 5920 0 kqread D ?? 0:00.00 [pickup] 0 70435 1357 0 44 0 3244 0 piperd D ?? 0:00.00 [cron] 0 70436 70435 0 44 0 3496 0 wait Ds ?? 0:00.00 [sh] 0 70437 3122 0 44 0 3244 0 piperd D ?? 0:00.00 [cron] 0 70438 70437 0 44 0 3496 0 wait Ds ?? 0:00.00 [sh] 0 70439 3900 0 44 0 3244 0 piperd D ?? 0:00.00 [cron] 0 70440 70439 0 45 0 3496 0 wait Ds ?? 0:00.00 [sh] 0 70441 4726 0 44 0 3244 0 piperd D ?? 0:00.00 [cron] 0 70442 70441 0 44 0 3496 0 wait Ds ?? 0:00.00 [sh] 0 70443 3380 0 44 0 3280 0 piperd D ?? 0:00.00 [cron] 0 70444 70443 0 44 0 3532 0 wait Ds ?? 0:00.00 [sh] 0 70445 70440 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70448 4151 0 44 0 3244 0 piperd D ?? 0:00.00 [cron] 0 70449 70448 0 44 0 3496 0 wait Ds ?? 0:00.00 [sh] 0 70454 70445 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70455 70445 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70456 70455 0 76 0 3160 0 piperd D ?? 0:00.00 [mail] 0 70457 2791 0 44 0 3244 0 piperd D ?? 0:00.00 [cron] 0 70458 70457 0 45 0 3496 0 wait Ds ?? 0:00.00 [sh] 0 70459 70454 0 76 0 3496 0 piperd D ?? 0:00.00 [sh] 0 70463 70459 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70464 70463 0 44 0 4184 0 zfs D ?? 0:00.00 [find] 0 70465 70463 0 76 0 3160 0 piperd D ?? 0:00.00 [tee] 0 70466 70463 0 76 0 1412 0 piperd D ?? 0:00.00 [wc] 0 70467 70458 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70474 70467 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70475 70467 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70476 70475 0 76 0 3160 0 piperd D ?? 0:00.00 [mail] 0 70477 70474 0 76 0 3496 0 piperd D ?? 0:00.00 [sh] 0 70481 70477 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70482 70481 0 44 0 4184 0 zfsvfs D ?? 0:00.00 [find] 0 70483 70481 0 76 0 3160 0 piperd D ?? 0:00.00 [tee] 0 70484 70481 0 76 0 1412 0 piperd D ?? 0:00.00 [wc] 0 70485 2055 0 44 0 3244 0 piperd D ?? 0:00.00 [cron] 0 70486 70485 0 44 0 3496 0 wait Ds ?? 0:00.00 [sh] 0 70487 1668 0 44 0 3244 0 piperd D ?? 0:00.00 [cron] 0 70488 70487 0 44 0 3496 0 wait Ds ?? 0:00.00 [sh] 0 70489 4473 0 44 0 3244 0 piperd D ?? 0:00.00 [cron] 0 70490 70489 0 44 0 3496 0 wait Ds ?? 0:00.00 [sh] 0 70492 5107 0 44 0 3280 0 piperd D ?? 0:00.00 [cron] 0 70494 70492 0 45 0 3532 0 wait Ds ?? 0:00.00 [sh] 0 70496 70494 0 76 0 3532 0 wait D ?? 0:00.00 [sh] 0 70502 4992 0 44 0 3244 0 piperd D ?? 0:00.00 [cron] 0 70504 70502 0 44 0 3496 0 wait Ds ?? 0:00.00 [sh] 0 70505 70496 0 76 0 3532 0 wait D ?? 0:00.00 [sh] 0 70506 70496 0 76 0 3532 0 wait D ?? 0:00.00 [sh] 0 70507 70506 0 57 0 3196 0 piperd D ?? 0:00.00 [mail] 0 70584 70490 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70586 70504 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70599 70505 0 76 0 3532 0 wait D ?? 0:00.00 [sh] 0 70600 70599 0 76 0 3532 0 wait D ?? 0:00.00 [sh] 0 70606 70584 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70607 70584 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70608 70607 0 76 0 3160 0 piperd D ?? 0:00.00 [mail] 0 70610 70606 0 76 0 3496 0 piperd D ?? 0:00.00 [sh] 0 70611 70600 0 76 0 3532 0 wait D ?? 0:00.00 [sh] 0 70612 70600 0 76 0 3532 0 wait D ?? 0:00.00 [sh] 0 70613 70612 0 76 0 3196 0 piperd D ?? 0:00.00 [mail] 0 70614 70611 0 76 0 3532 0 wait D ?? 0:00.00 [sh] 0 70620 70610 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70621 70620 0 44 0 4184 0 zfs D ?? 0:00.00 [find] 0 70622 70620 0 76 0 3160 0 piperd D ?? 0:00.00 [tee] 0 70623 70620 0 76 0 1412 0 piperd D ?? 0:00.00 [wc] 0 70627 70614 0 44 0 3196 0 biord D ?? 0:00.00 [find] 0 70628 70614 0 76 0 3532 0 wait D ?? 0:00.00 [sh] 0 70630 70628 0 76 0 3196 0 piperd D ?? 0:00.00 [cat] 0 70635 70586 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70636 70586 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70637 70636 0 76 0 3160 0 piperd D ?? 0:00.00 [mail] 0 70638 70635 0 76 0 3496 0 piperd D ?? 0:00.00 [sh] 0 70642 70638 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70643 70642 0 44 0 4184 0 zfs D ?? 0:00.00 [find] 0 70644 70642 0 76 0 3160 0 piperd D ?? 0:00.00 [tee] 0 70645 70642 0 76 0 1412 0 piperd D ?? 0:00.00 [wc] 0 70646 70438 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70653 70646 0 71 0 3496 0 wait D ?? 0:00.00 [sh] 0 70654 70646 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70655 70654 0 70 0 3160 0 piperd D ?? 0:00.00 [mail] 0 70656 70653 0 76 0 3496 0 piperd D ?? 0:00.00 [sh] 0 70660 70656 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70661 70660 0 45 0 4184 0 zio->i D ?? 0:00.00 [find] 0 70662 70660 0 76 0 3196 0 piperd D ?? 0:00.00 [tee] 0 70663 70660 0 76 0 1448 0 piperd D ?? 0:00.00 [wc] 0 70664 70486 0 66 0 3496 0 wait D ?? 0:00.00 [sh] 0 70671 70664 0 63 0 3496 0 wait D ?? 0:00.00 [sh] 0 70672 70664 0 68 0 3496 0 wait D ?? 0:00.00 [sh] 0 70673 70672 0 60 0 3160 0 piperd D ?? 0:00.00 [mail] 0 70674 70671 0 76 0 3496 0 piperd D ?? 0:00.00 [sh] 0 70678 70674 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70679 70678 0 44 0 4184 0 zio->i D ?? 0:00.00 [find] 0 70680 70678 0 76 0 3196 0 piperd D ?? 0:00.00 [tee] 0 70681 70678 0 76 0 1448 0 piperd D ?? 0:00.00 [wc] 0 70682 70442 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70689 70682 0 71 0 3496 0 wait D ?? 0:00.00 [sh] 0 70690 70682 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70691 70690 0 65 0 3160 0 piperd D ?? 0:00.00 [mail] 0 70692 70689 0 76 0 3496 0 piperd D ?? 0:00.00 [sh] 0 70696 70692 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70697 70696 0 45 0 3160 0 zio->i D ?? 0:00.00 [find] 0 70698 70696 0 76 0 3160 0 piperd D ?? 0:00.00 [tee] 0 70699 70696 0 76 0 1412 0 piperd D ?? 0:00.00 [wc] 0 70700 70436 0 53 0 3496 0 wait D ?? 0:00.00 [sh] 0 70701 70449 0 65 0 3496 0 wait D ?? 0:00.00 [sh] 0 70785 70700 0 51 0 3496 0 wait D ?? 0:00.00 [sh] 0 70786 70700 0 54 0 3496 0 wait D ?? 0:00.00 [sh] 0 70787 70786 0 50 0 3160 0 piperd D ?? 0:00.00 [mail] 0 70788 70701 0 61 0 3496 0 wait D ?? 0:00.00 [sh] 0 70789 70701 0 66 0 3496 0 wait D ?? 0:00.00 [sh] 0 70790 70789 0 60 0 3160 0 piperd D ?? 0:00.00 [mail] 0 70791 70788 0 76 0 3496 0 piperd D ?? 0:00.00 [sh] 0 70792 70785 0 76 0 3496 0 piperd D ?? 0:00.00 [sh] 0 70799 70792 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70800 70799 0 44 0 4184 0 zio->i D ?? 0:00.00 [find] 0 70801 70799 0 71 0 3160 0 piperd D ?? 0:00.00 [tee] 0 70802 70799 0 76 0 1412 0 piperd D ?? 0:00.00 [wc] 0 70803 70791 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70804 70803 0 45 0 3160 0 zfsvfs D ?? 0:00.00 [find] 0 70805 70803 0 76 0 3160 0 piperd D ?? 0:00.00 [tee] 0 70806 70803 0 76 0 1412 0 piperd D ?? 0:00.00 [wc] 0 70807 70488 0 72 0 3496 0 wait D ?? 0:00.00 [sh] 0 70814 70807 0 65 0 3496 0 wait D ?? 0:00.00 [sh] 0 70815 70807 0 73 0 3496 0 wait D ?? 0:00.00 [sh] 0 70816 70815 0 62 0 3160 0 piperd D ?? 0:00.00 [mail] 0 70817 70814 0 76 0 3496 0 piperd D ?? 0:00.00 [sh] 0 70822 70817 0 76 0 3496 0 wait D ?? 0:00.00 [sh] 0 70823 70822 0 45 0 4184 0 zio->i D ?? 0:00.00 [find] 0 70824 70822 0 69 0 3160 0 piperd D ?? 0:00.00 [tee] 0 70825 70822 0 70 0 1412 0 piperd D ?? 0:00.00 [wc] 0 70826 70444 0 57 0 3532 0 wait D ?? 0:00.00 [sh] 0 70833 70826 0 53 0 3532 0 wait D ?? 0:00.00 [sh] 0 70834 70826 0 58 0 3532 0 wait D ?? 0:00.00 [sh] 0 70835 70834 0 51 0 3196 0 piperd D ?? 0:00.00 [mail] 0 70836 70833 0 64 0 3532 0 piperd D ?? 0:00.00 [sh] 0 70840 70836 0 66 0 3532 0 wait D ?? 0:00.00 [sh] 0 70841 70840 0 44 0 4220 0 zio->i D ?? 0:00.00 [find] 0 70842 70840 0 63 0 3196 0 piperd D ?? 0:00.00 [tee] 0 70843 70840 0 64 0 1448 0 piperd D ?? 0:00.00 [wc] 0 71168 5119 0 76 0 1444 0 nanslp D ?? 0:00.00 [sleep] ------------------------------------------------------------------------ vmstat -s 0 cpu context switches 0 device interrupts 0 software interrupts 0 traps 0 system calls 0 kernel threads created 0 fork() calls 0 vfork() calls 0 rfork() calls 0 swap pager pageins 0 swap pager pages paged in 0 swap pager pageouts 0 swap pager pages paged out 0 vnode pager pageins 0 vnode pager pages paged in 0 vnode pager pageouts 0 vnode pager pages paged out 0 page daemon wakeups 0 pages examined by the page daemon 5066 pages reactivated 0 copy-on-write faults 0 copy-on-write optimized faults 0 zero fill pages zeroed 0 zero fill pages prezeroed 0 intransit blocking page faults 0 total VM faults taken 0 pages affected by kernel thread creation 0 pages affected by fork() 0 pages affected by vfork() 0 pages affected by rfork() 5435 pages cached 0 pages freed 0 pages freed by daemon 2680625 pages freed by exiting processes 63979 pages active 26772 pages inactive 11 pages in VM cache 65422 pages wired down 99042 pages free 4096 bytes per page 5841817 total name lookups cache hits (90% pos + 3% neg) system 0% per-directory deletions 0%, falsehits 0%, toolong 0% ------------------------------------------------------------------------ vmstat -m Type InUse MemUse HighUse Requests Size(s) acpidev -58 0K - 0 =20 KTRACE -100 -11K - 0 =20 acpipwr -1 0K - 0 =20 linker 29057 -306K - 29536 16,32,64,128,256,512,1024,2048 lockf 10460048 -10381K - 10627904 16,32,64,128,256,1024,2048,= 8192,16384,32768,524288,1048576 agp -2 -127K - 0 =20 ip6ndp -3 0K - 0 =20 temp 5862045283 -5725408K - 5862580368 32,64,128,1024,2048,4= 096,8192,16384,32768,65536,262144,524288,1048576,2097152,4194304 devbuf 42111 -2222K - 42688 32,64,128,256 module -253 -14K - 0 =20 ppbusdev -2 0K - 0 =20 mtx_pool -1 -3K - 0 =20 entropy -1024 -63K - 0 =20 osd 3095 -2K - 3312 16,32,64,128,256,512,2048 UART -6 -1K - 0 =20 subproc 290109551 -284782K - 290181120 16,64,128,256,512,2048,1= 6384,32768,65536,131072,262144,524288 proc -2 -7K - 0 =20 session 91822 -96K - 93376 16,32,64,128,512,2048,4096,8192 pgrp 94273 -98K - 95872 16,128,256,1024,2048,4096,8192 cred 47279085 -46403K - 47464704 16,32,64,128,256,512,8192,3= 2768,65536,131072,524288,1048576 uidinfo 11583 -12K - 11968 32,64,256,512,1024,4096 plimit 4544806 -4469K - 4562688 16,32,64,128,256,2048,4096,81= 92,32768,65536,131072 USBHC -3 0K - 0 =20 sysctltmp 177522 -177K - 183056 32,64,128,256,512,1024,2048,81= 92,65536 sysctloid -2180 -108K - 1488 16,64,128,256,1024 sysctl 465693 -472K - 485216 16,32,64,128,256,512,1024,2048= ,4096,8192,32768,131072 callout -1 -255K - 0 =20 umtx -497 -30K - 0 =20 p1003.1b -1 0K - 0 =20 SWAP -2 -275K - 0 =20 USBdev -27 -9K - 0 =20 bus-sc 461480 -493K - 463264 64,128,512,2048,8192,16384 bus 1016548 -1033K - 1021600 16,128,256,512,1024,4096,8192= ,16384,32768 clist -54 -5K - 0 =20 devstat -24 -47K - 0 =20 eventhandler -75 -2K - 0 =20 USB 10255 -25K - 10400 64,128,256 kobj 38721 -381K - 38912 16,32,256 DEVFS1 1412 -30K - 1536 16,64 DEVFS3 387 -206K - 2048 128 rman 22172 -32K - 22720 16,32,512,1024,4096 DEVFS2 42298 -48K - 43600 16,32,64,128,256,512,1024,4096,= 8192 sbuf 2877896 -2810K - 2879008 128,256,512,1024,2048,4096,81= 92 DEVFS_RULE -88 -18K - 0 =20 DEVFS -130 -1K - 16 16 stack 254 0K - 256 32 taskqueue -9 0K - 0 =20 Unitno 48977 -50K - 52256 16,64,128,256,512,2048,16384,32= 768 iov 851469 -848K - 870032 16,32,128,256,512,1024,4096,81= 92,16384,131072 select 644717 -640K - 646144 32,64,128,256,1024,2048,8192 ioctlops 7647680 -7571K - 7754512 16,32,64,128,1024,2048,4096,8= 192,16384,32768,65536,262144,1048576 msg -4 -24K - 0 =20 sem -4 -5K - 0 =20 shm -1 -11K - 0 =20 tty 491 -9K - 512 16 pts 127 0K - 128 16 accf 40 0K - 48 16,32 mbuf_tag 961 0K - 992 16,32,64,128,256 shmfd -1 -3K - 0 =20 acpitask 62 0K - 64 32 pcb 64043 -72K - 68352 16,32,64,128,256,2048,4096,8192= ,16384,32768 soname 3283391 -3266K - 3342096 16,64,128,256,4096,8192,32768= ,65536,131072,262144 biobuf 24560 -31K - 24576 64,128 vfscache -1 -511K - 0 =20 cl_savebuf 6777 -5K - 6912 16,32,64,2048 export_host -3 0K - 0 =20 vfs_hash -1 -255K - 0 =20 vnodes -4 0K - 0 =20 ddb_capture -1 -47K - 0 =20 vnodemarker 31199616 -30527K - 31260672 64,128,256,512,1024,4096,16= 384,32768,131072,262144,524288 mount 31615 -63K - 33632 16,32,256,512,1024,4096,8192 GEOM 1522158 -1517K - 1523712 32,64,128,256,1024,2048,4096,= 8192 BPF -2 0K - 0 =20 ether_multi 46 0K - 64 16 ifaddr -39 -8K - 0 =20 ifnet -3 -1K - 0 =20 clone -3 -11K - 0 =20 arpcom -1 0K - 0 =20 isadev -18 0K - 0 =20 acpica 20508086 -20231K - 20620400 16,256,512,1024,2048,8192,1= 6384,32768,131072,524288,1048576 pci_link -16 0K - 0 =20 routetbl 227173 -228K - 228160 16,32,64,128,256,1024,4096,819= 2 ipid -2 -23K - 0 =20 in_multi -2 0K - 0 =20 encap_export_host -2 -1K - 0 =20 hostcache -1 -15K - 0 =20 ata_generic 68213 -69K - 68400 16,32,64,256,512,2048 syncache -1 -71K - 0 =20 in6_multi -19 0K - 0 =20 ip6_moptions -1 0K - 0 =20 savedino 20400 -19K - 20480 256,1024 dirrem 11408 -10K - 11776 16,32,64,128,512,1024,4096 mkdir 62 0K - 64 32 diradd 23373 -22K - 23744 16,32,64,128,256,1024,4096 freefile 2883 -1K - 2976 16,32,128,256,1024 freeblks 19380 -18K - 19456 32,128,1024 freefrag 18507 -17K - 19104 16,32,64,128,256,512,8192 allocindir 189126 -186K - 192128 32,64,256,512,2048,4096,8192,3= 2768 indirdep 16476 -15K - 16480 32 allocdirect 17399 -16K - 17536 16,128,512,1024 bmsafemap 3906 -2K - 3968 16,64,128,256,512 newblk 197756 -195K - 200896 16,32,64,128,256,512,1024,2048= ,4096,8192,32768 inodedep 56641 -310K - 57088 16,64,128,256,512,2048,4096 pagedep 3464 -34K - 3520 16,32,64,256,512 ufs_dirhash -102 -17K - 0 =20 ufs_quota -1 -255K - 0 =20 ufs_mount -6 -11K - 0 =20 UMAHash 763 -1K - 768 32 ad_driver -3 0K - 0 =20 cdev -15 0K - 0 =20 vm_pgdata -2 -63K - 0 =20 atkbddev -2 0K - 0 =20 acd_driver -1 -1K - 0 =20 apmdev -2 0K - 0 =20 sigio -1 0K - 0 =20 filedesc 18126351 -18215K - 18197760 16,32,64,512,1024,4096,1638= 4,32768,524288 kdtrace 4876586 -4963K - 4949824 16,32,128,512,1024,2048,8192,= 32768,65536,131072,262144,524288 kenv 22 -5K - 96 16,64 io_apic -1 0K - 0 =20 memdesc -1 -3K - 0 =20 nexusdev -4 0K - 0 =20 kqueue 12823895 -12583K - 12873632 16,64,128,512,1024,2048,409= 6,131072,262144 proc-args 2881724 -2878K - 2933296 16,32,128,256,2048,16384,3276= 8,65536,131072,262144 acpisem -12 0K - 0 =20 ithread -80 -5K - 0 =20 prison -11 -21K - 0 =20 solaris 17414655413 -17113368K - 17436330128 32,128,512,1024,32= 768,65536,131072,262144,524288,1048576,2097152,4194304,8388608,16777216,3355= 4432,67108864,134217728 kstat_data -2 0K - 0 =20 CAM periph 419 0K - 432 16,32,128 CAM dev queue -1 0K - 0 =20 CAM queue -3 0K - 0 =20 CAM SIM -1 0K - 0 =20 CAM XPT 477 0K - 512 32,64,256 mixer -1 -3K - 0 =20 mirror_data 698840 -684K - 700224 16,64,128,256,1024,4096,16384 linux -12 0K - 0 =20 ac97 -2 0K - 0 =20 feeder 292 -6K - 704 16,32,128 kbdmux -7 -7K - 0 =20 cpuctl -1 0K - 0 =20 drm_ctxbitmap -1 -3K - 0 =20 drm_agplists -1 0K - 0 =20 drm_driver 57 0K - 64 64 drm_sarea -1 0K - 0 =20 md_disk -1 -1K - 0 =20 rpc -10 -3K - 0 =20 NFS FHA -1 0K - 0 =20 nullfs_node 5393305 -5619K - 5753024 16,32,128,256,512,1024,4096,8= 192,32768,65536,131072,262144,1048576,2097152 nullfs_hash -1 0K - 0 =20 nullfs_mount -37 0K - 0 =20 ------------------------------------------------------------------------ vmstat -z --=_10zr6qzqfkhc-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 08:30:08 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0ACC91065673; Sat, 21 Feb 2009 08:30:08 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mail.cksoft.de (mail.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id B59168FC18; Sat, 21 Feb 2009 08:30:07 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from localhost (amavis.str.cksoft.de [192.168.74.71]) by mail.cksoft.de (Postfix) with ESMTP id C63C741C705; Sat, 21 Feb 2009 09:30:06 +0100 (CET) X-Virus-Scanned: amavisd-new at cksoft.de Received: from mail.cksoft.de ([62.111.66.27]) by localhost (amavis.str.cksoft.de [192.168.74.71]) (amavisd-new, port 10024) with ESMTP id PEyLEMR-yLvx; Sat, 21 Feb 2009 09:30:05 +0100 (CET) Received: by mail.cksoft.de (Postfix, from userid 66) id 355B441C69F; Sat, 21 Feb 2009 09:30:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id DBB1C4448E6; Sat, 21 Feb 2009 08:25:29 +0000 (UTC) Date: Sat, 21 Feb 2009 08:25:29 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: Marcel Moolenaar In-Reply-To: <725CDB16-7D31-42C9-924E-DB6B595BF071@mac.com> Message-ID: <20090221082155.T53478@maildrop.int.zabbadoz.net> References: <20090217113718.N53478@maildrop.int.zabbadoz.net> <725CDB16-7D31-42C9-924E-DB6B595BF071@mac.com> X-OpenPGP-Key: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD current mailing list Subject: Re: boot0cfg -s vs. GEOM_PART_*? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 08:30:08 -0000 On Tue, 17 Feb 2009, Marcel Moolenaar wrote: Hi, > On Feb 17, 2009, at 3:46 AM, Bjoern A. Zeeb wrote: > >> dopt# gpart set -a active -i 3 ad4 >> gpart: pre-check failed: Device not configured > > Oops. This is a bug. The pre-check is not implemented > for the MBR scheme and should succeed. I seem to have > forgotten about the error that unimplemented methods > return (KOBJ default). I'll fix this right away... Thanks. I see boot0cfg no longer errors but I am not sure if it does the right thing: boot0cfg -s 5 ad0 (doesn't atter if it's 0 or 2 to the -s options) as dopt# gpart show ad0 => 63 312581745 ad0 MBR (149G) 63 122881122 1 !7 (59G) 122881185 2939895 - free - (1.4G) 125821080 125821080 2 freebsd (60G) 251642160 60934545 3 freebsd [active] (29G) 312576705 5103 - free - (2.5M) seems s3 is still active. That leaves me to the question - what's the boot0cfg -s5 equivalent with gpart? I think adding that to the man page might be a good idea. /bz -- Bjoern A. Zeeb The greatest risk is not taking one. From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 09:01:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67B30106564A for ; Sat, 21 Feb 2009 09:01:08 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 2266A8FC0A for ; Sat, 21 Feb 2009 09:01:08 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by yx-out-2324.google.com with SMTP id 31so481521yxl.13 for ; Sat, 21 Feb 2009 01:01:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=bSTSpwt5Ga7QyMg/fPt+6IgH0LTcLOq9qxogiuMsEzE=; b=A4XOW8X2IeBxwTrk4ajOcE5fKt+jFs9uma+eto8kw1q6t+DuBeVTXIoKvUB5cCF2H3 uI08v7FGw1OhJ75bx+sIZFe7B4xmgQVYcXWhK5h1nZSmGp46lvhHdfq8EgoJ3JLBRmyT AFeadypfw/ffj8QbIMIN8PwnjHA8XB2fmpk8A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=MKeG3joIrE974BG4preLFdoD019s45wtRUndodDSYtiA6+6iVdunIuCuELvYs5yGg/ qnouMDLdBokaMmqEHdtxEN6q/EQ1FU7yYZZoSuv581bz19zgLMKBaY6zzvNsj1PVHXvh HjoQfiKqhi3TcLOFadV8HKEbi0YH5HFzEtpn4= MIME-Version: 1.0 Received: by 10.90.31.8 with SMTP id e8mr260018age.63.1235206867112; Sat, 21 Feb 2009 01:01:07 -0800 (PST) Date: Sat, 21 Feb 2009 01:01:07 -0800 Message-ID: <7d6fde3d0902210101yfb42ff6yd0aa31e6f16b5761@mail.gmail.com> From: Garrett Cooper To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Annoying whitenoise sound coming from snd_hda enabled chipset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 09:01:08 -0000 I don't know how else to describe it, but when I turn up my speakers enough (50%+) and don't have any sound playing, I hear a whitenoise hiss coming out of them. When I change webpages (nvidia driver is GIANT locked) or do something else kernel intensive it stops for a brief second, but apart from that it's an annoying trill sound almost like a mosquito humming around me waiting to be swatted. It's really driving me insane... Hopefully helpful snippets follow: vendor = 'Intel Corporation' device = '82801IB/IR/IH (ICH9 Family) HD Audio Controller' class = multimedia subclass = HDA pcib2@pci0:0:28:0: class=0x060400 card=0x82771043 chip=0x29408086 rev=0x02 hdr=0x01 [gcooper@orangebox /usr/home/gcooper]$ uname -a FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT #1: Mon Feb 16 20:50:56 PST 2009 root@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX i386 Comments? -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 10:15:47 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F36A41065672 for ; Sat, 21 Feb 2009 10:15:46 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 4601A8FC13 for ; Sat, 21 Feb 2009 10:15:45 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 21 Feb 2009 10:15:45 -0000 Received: from p54A3E156.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.225.86] by mail.gmx.net (mp028) with SMTP; 21 Feb 2009 11:15:45 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX199kEU2JMF9QEdd4hgzwyfvE6guMotZ7tPGJzPMYs G9CjITSd4Z8Uu8 Message-ID: <499FD450.7040205@gmx.de> Date: Sat, 21 Feb 2009 11:15:44 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Garrett Cooper References: <7d6fde3d0902210101yfb42ff6yd0aa31e6f16b5761@mail.gmail.com> In-Reply-To: <7d6fde3d0902210101yfb42ff6yd0aa31e6f16b5761@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.49 Cc: FreeBSD Current Subject: Re: Annoying whitenoise sound coming from snd_hda enabled chipset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 10:15:47 -0000 Garrett Cooper schrieb: > I don't know how else to describe it, but when I turn up my > speakers enough (50%+) and don't have any sound playing, I hear a > whitenoise hiss coming out of them. When I change webpages (nvidia > driver is GIANT locked) or do something else kernel intensive it stops > for a brief second, but apart from that it's an annoying trill sound > almost like a mosquito humming around me waiting to be swatted. > It's really driving me insane... Hopefully helpful snippets follow: > > vendor = 'Intel Corporation' > device = '82801IB/IR/IH (ICH9 Family) HD Audio Controller' > class = multimedia > subclass = HDA > pcib2@pci0:0:28:0: class=0x060400 card=0x82771043 chip=0x29408086 rev=0x02 > hdr=0x01 > > [gcooper@orangebox /usr/home/gcooper]$ uname -a > FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT > #1: Mon Feb 16 20:50:56 PST 2009 > root@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX i386 > > Comments? > -Garrett Try setting kern.hz="100" in loader.conf. From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 13:06:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83B5D106566B for ; Sat, 21 Feb 2009 13:06:44 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 077EC8FC30 for ; Sat, 21 Feb 2009 13:06:43 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 235410057; Sat, 21 Feb 2009 15:06:43 +0200 Message-ID: <499FFC5F.3020903@FreeBSD.org> Date: Sat, 21 Feb 2009 15:06:39 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Garrett Cooper References: <1235218982.00077642.1235207402@10.7.7.3> In-Reply-To: <1235218982.00077642.1235207402@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Annoying whitenoise sound coming from snd_hda enabled chipset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 13:06:44 -0000 Garrett Cooper wrote: > I don't know how else to describe it, but when I turn up my > speakers enough (50%+) and don't have any sound playing, I hear a > whitenoise hiss coming out of them. When I change webpages (nvidia > driver is GIANT locked) or do something else kernel intensive it stops > for a brief second, but apart from that it's an annoying trill sound > almost like a mosquito humming around me waiting to be swatted. I think it may be radio interference with disconnected microphone inputs. Try to set all unneeded mixer volumes to 0, especially mic, monitor, speaker and mix. Inputs often have too sensitive 20-30dB pre-amplifiers. Some codecs have them on all inputs. > It's really driving me insane... Hopefully helpful snippets follow: > > vendor = 'Intel Corporation' > device = '82801IB/IR/IH (ICH9 Family) HD Audio Controller' > class = multimedia > subclass = HDA > pcib2@pci0:0:28:0: class=0x060400 card=0x82771043 chip=0x29408086 rev=0x02 > hdr=0x01 > > [gcooper@orangebox /usr/home/gcooper]$ uname -a > FreeBSD orangebox.gateway.2wire.net 8.0-CURRENT FreeBSD 8.0-CURRENT > #1: Mon Feb 16 20:50:56 PST 2009 > root@orangebox.gateway.2wire.net:/usr/obj/usr/src/sys/ORANGEBOX i386 Infromation about codec or even complete verbose dmesg would be more helpful. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 13:27:17 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E8361065675 for ; Sat, 21 Feb 2009 13:27:17 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 04E798FC13 for ; Sat, 21 Feb 2009 13:27:16 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 235410698 for freebsd-current@freebsd.org; Sat, 21 Feb 2009 15:27:16 +0200 Message-ID: <49A00130.9070105@FreeBSD.org> Date: Sat, 21 Feb 2009 15:27:12 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: FreeBSD-Current Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Subject: Fatal trap 30: reserved (unknown) fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 13:27:17 -0000 Hi. About month ago after one of my amd64 8-CURRENT upgrade I have started to see crashes with very strange message: Fatal trap 30: reserved (unknown) fault while in kernel mode Crash usually happens during some driver loading or unloading, for example, snd_hda, which always worked fine before, or during ata channel detach/attach which also causes device destruction/creation. Backtrace of this state shows nothing interesting, for example idling in acpi_cpu_c1() or just DELAY(). Does anybody knows, for whom is this fault "reserved" and what does it mean? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 14:34:03 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECAAD1065672 for ; Sat, 21 Feb 2009 14:34:03 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from hercules.mthelicon.com (hercules.mthelicon.com [IPv6:2001:49f0:2023::2]) by mx1.freebsd.org (Postfix) with ESMTP id B7E8B8FC12 for ; Sat, 21 Feb 2009 14:34:03 +0000 (UTC) (envelope-from ken@mthelicon.com) Received: from feathers.peganest.com (78-33-110-3.static-adsl.entanet.co.uk [78.33.110.3] (may be forged)) (authenticated bits=0) by hercules.mthelicon.com (8.14.3/8.14.3) with ESMTP id n1LEY1E8043393 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Sat, 21 Feb 2009 14:34:03 GMT (envelope-from ken@mthelicon.com) From: Pegasus Mc Cleaft Organization: Feathers To: current@freebsd.org Date: Sat, 21 Feb 2009 14:33:54 +0000 User-Agent: KMail/1.11.0 (FreeBSD/8.0-CURRENT; KDE/4.2.0; amd64; ; ) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902211433.54247.ken@mthelicon.com> Cc: Subject: ZFS corruption with -current(21/02/2009) on AMD64 w/ ZFS boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 14:34:04 -0000 Hi Current, I am having a horrible time with the latest current (21/02/2009) with my AMD64 machine and ZFS boot. The kernel appears to load OK, but when it tries to mount the root filing system from the ZFS pool, it mounts but starts to corrupt the data on the drives. It is unable to mount the zraid pools/filing systems and the machine just goes to a login prompt. In the configuration I have, I use a zraid pool for all /usr /var and /local, the rest is off a 3 way mirror for / The only way out of this is to physically disconnect the corrupted drive and boot off one of the mirrors with the previous kernel (The last one what works for me is -Current 14/02/2009). Once the system is booted, normally I have to remove the faulted drive, reattach it to the mirror and let the system resilver. dmesg outputs look like: Feb 21 14:16:56 feathers root: ZFS: vdev failure, zpool=PegaBoot2 type=vdev.corrupt_data Feb 21 14:16:58 feathers root: ZFS: vdev failure, zpool=PegaBoot2 type=vdev.corrupt_data Feb 21 14:17:08 feathers su: ken to root on /dev/pts/1 Feb 21 14:17:29 feathers root: ZFS: vdev failure, zpool=PegaBoot2 type=vdev.corrupt_data Feb 21 14:18:00 feathers last message repeated 2 times Feb 21 14:18:00 feathers root: ZFS: vdev failure, zpool=PegaBoot2 type=vdev.corrupt_data If there is any more information that I can give that will be helpfull, please let me know.. Peg From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 15:22:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33EFF106564A for ; Sat, 21 Feb 2009 15:22:50 +0000 (UTC) (envelope-from ru@freebsd.org) Received: from mail.vega.ru (mail.vega.ru [90.156.167.5]) by mx1.freebsd.org (Postfix) with ESMTP id E28598FC18 for ; Sat, 21 Feb 2009 15:22:49 +0000 (UTC) (envelope-from ru@freebsd.org) Received: from [10.100.124.199] (port=54790 helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1LatQ2-0003AN-Sm; Sat, 21 Feb 2009 18:05:30 +0300 Date: Sat, 21 Feb 2009 18:05:23 +0300 From: Ruslan Ermilov To: Jeremie Le Hen Message-ID: <20090221150523.GA45134@edoofus.dev.vega.ru> References: <20090113202046.GH41799@obiwan.tataz.chchile.org> <20090219224431.GC70440@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090219224431.GC70440@obiwan.tataz.chchile.org> Cc: freebsd-current@freebsd.org Subject: Re: WITH_SSP in src.conf(5) breaks the build X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 15:22:50 -0000 On Thu, Feb 19, 2009 at 11:44:31PM +0100, Jeremie Le Hen wrote: > Ruslan, > > Could you commit the attached patch please (third try :)). > Done. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 15:44:22 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06C2E1065672 for ; Sat, 21 Feb 2009 15:44:22 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 32A938FC14 for ; Sat, 21 Feb 2009 15:44:20 +0000 (UTC) (envelope-from christoph.mallon@gmx.de) Received: (qmail invoked by alias); 21 Feb 2009 15:44:19 -0000 Received: from p54A3E156.dip.t-dialin.net (EHLO tron.homeunix.org) [84.163.225.86] by mail.gmx.net (mp022) with SMTP; 21 Feb 2009 16:44:19 +0100 X-Authenticated: #1673122 X-Provags-ID: V01U2FsdGVkX187b3xIjqs7E6KzAOt6jubgwbha/G5exGb9VdQwZU m2B1W2Sxsxg7Rq Message-ID: <49A02152.8050209@gmx.de> Date: Sat, 21 Feb 2009 16:44:18 +0100 From: Christoph Mallon User-Agent: Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Alexander Motin References: <49A00130.9070105@FreeBSD.org> In-Reply-To: <49A00130.9070105@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-FuHaFi: 0.61 Cc: FreeBSD-Current Subject: Re: Fatal trap 30: reserved (unknown) fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 15:44:22 -0000 Alexander Motin schrieb: > Hi. > > About month ago after one of my amd64 8-CURRENT upgrade I have started > to see crashes with very strange message: > Fatal trap 30: reserved (unknown) fault while in kernel mode > > Crash usually happens during some driver loading or unloading, for > example, snd_hda, which always worked fine before, or during ata channel > detach/attach which also causes device destruction/creation. Backtrace > of this state shows nothing interesting, for example idling in > acpi_cpu_c1() or just DELAY(). > > Does anybody knows, for whom is this fault "reserved" and what does it > mean? Intel: 20-31 -- Intel reserved. Do not use. This exception really should not happen. Maybe int 0x30 is executed, but this should not be the case either. From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 15:54:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD207106566B for ; Sat, 21 Feb 2009 15:54:50 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 33C968FC0A for ; Sat, 21 Feb 2009 15:54:49 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 235417233; Sat, 21 Feb 2009 17:54:49 +0200 Message-ID: <49A023C6.5070401@FreeBSD.org> Date: Sat, 21 Feb 2009 17:54:46 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Christoph Mallon References: <49A00130.9070105@FreeBSD.org> <49A02152.8050209@gmx.de> In-Reply-To: <49A02152.8050209@gmx.de> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: Fatal trap 30: reserved (unknown) fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 15:54:50 -0000 Christoph Mallon wrote: > Alexander Motin schrieb: >> About month ago after one of my amd64 8-CURRENT upgrade I have started >> to see crashes with very strange message: >> Fatal trap 30: reserved (unknown) fault while in kernel mode >> >> Crash usually happens during some driver loading or unloading, for >> example, snd_hda, which always worked fine before, or during ata >> channel detach/attach which also causes device destruction/creation. >> Backtrace of this state shows nothing interesting, for example idling >> in acpi_cpu_c1() or just DELAY(). >> >> Does anybody knows, for whom is this fault "reserved" and what does it >> mean? > > Intel: > 20-31 -- Intel reserved. Do not use. > > This exception really should not happen. Maybe int 0x30 is executed, but > this should not be the case either. I have hit somewhere on web that traps may share vectors with interrupts and this may cause problems. Can't it be some mishandled IRQ? What will happen if some IRQ arrive after driver detach? How it will be handled? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 16:08:44 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 383621065670; Sat, 21 Feb 2009 16:08:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.terabit.net.ua (mail.terabit.net.ua [195.137.202.147]) by mx1.freebsd.org (Postfix) with ESMTP id CFC008FC08; Sat, 21 Feb 2009 16:08:43 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from skuns.zoral.com.ua ([91.193.166.194] helo=mail.zoral.com.ua) by mail.terabit.net.ua with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63 (FreeBSD)) (envelope-from ) id 1LauPB-000PWN-QE; Sat, 21 Feb 2009 18:08:41 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id n1LG8dKM056246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 21 Feb 2009 18:08:39 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id n1LG8cYo044713; Sat, 21 Feb 2009 18:08:38 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3/Submit) id n1LG8cir044712; Sat, 21 Feb 2009 18:08:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 21 Feb 2009 18:08:38 +0200 From: Kostik Belousov To: Alexander Motin Message-ID: <20090221160838.GB41617@deviant.kiev.zoral.com.ua> References: <49A00130.9070105@FreeBSD.org> <49A02152.8050209@gmx.de> <49A023C6.5070401@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="JyUo+2rKuw1VKSUr" Content-Disposition: inline In-Reply-To: <49A023C6.5070401@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua X-Virus-Scanned: mail.terabit.net.ua 1LauPB-000PWN-QE ae46656ab6a4dff81efaf80f51b1a898 X-Terabit: YES Cc: Christoph Mallon , FreeBSD-Current Subject: Re: Fatal trap 30: reserved (unknown) fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 16:08:44 -0000 --JyUo+2rKuw1VKSUr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 21, 2009 at 05:54:46PM +0200, Alexander Motin wrote: > Christoph Mallon wrote: > >Alexander Motin schrieb: > >>About month ago after one of my amd64 8-CURRENT upgrade I have started= =20 > >>to see crashes with very strange message: > >>Fatal trap 30: reserved (unknown) fault while in kernel mode > >> > >>Crash usually happens during some driver loading or unloading, for=20 > >>example, snd_hda, which always worked fine before, or during ata=20 > >>channel detach/attach which also causes device destruction/creation.=20 > >>Backtrace of this state shows nothing interesting, for example idling= =20 > >>in acpi_cpu_c1() or just DELAY(). > >> > >>Does anybody knows, for whom is this fault "reserved" and what does it= =20 > >>mean? > > > >Intel: > > 20-31 -- Intel reserved. Do not use. > > > >This exception really should not happen. Maybe int 0x30 is executed, but= =20 > >this should not be the case either. >=20 > I have hit somewhere on web that traps may share vectors with interrupts= =20 > and this may cause problems. Can't it be some mishandled IRQ? What will= =20 > happen if some IRQ arrive after driver detach? How it will be handled? 30 is not CPU trap number, this is a freebsd trap number; see i386/include/trap.h. Actually, this is a crack from r187880. Trap 30 is reported when interrupt is delivered for a vector that has no (non-default) handler installed. Read apic_disable_vector() that sets irq handler for unhandled vector to rsvd. --JyUo+2rKuw1VKSUr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkmgJwYACgkQC3+MBN1Mb4hMjwCg82qlHKbNrjxkASw2bfm8ZUFH dRoAnjapQR9YvcZjInpdKxO8bj7wt3EI =4lZc -----END PGP SIGNATURE----- --JyUo+2rKuw1VKSUr-- From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 16:34:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BD832106564A; Sat, 21 Feb 2009 16:34:50 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (brucec-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:c09::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7C79D8FC0C; Sat, 21 Feb 2009 16:34:50 +0000 (UTC) (envelope-from bruce@cran.org.uk) Received: from muon.cran.org.uk (localhost [127.0.0.1]) by muon.cran.org.uk (Postfix) with ESMTP id BA6A719014; Sat, 21 Feb 2009 16:34:48 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on muon X-Spam-Level: X-Spam-Status: No, score=-2.5 required=8.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.2.5 Received: from [IPv6:2a01:348:10f:0:71a4:e1a:d4b6:59ab] (unknown [IPv6:2a01:348:10f:0:71a4:e1a:d4b6:59ab]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by muon.cran.org.uk (Postfix) with ESMTPSA; Sat, 21 Feb 2009 16:34:48 +0000 (GMT) Message-ID: <49A02D23.5080406@cran.org.uk> Date: Sat, 21 Feb 2009 16:34:43 +0000 From: Bruce Cran User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) MIME-Version: 1.0 To: Alexander Motin References: <49A00130.9070105@FreeBSD.org> In-Reply-To: <49A00130.9070105@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: Fatal trap 30: reserved (unknown) fault X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 16:34:51 -0000 Alexander Motin wrote: > About month ago after one of my amd64 8-CURRENT upgrade I have started > to see crashes with very strange message: > Fatal trap 30: reserved (unknown) fault while in kernel mode > > Crash usually happens during some driver loading or unloading, for > example, snd_hda, which always worked fine before, or during ata > channel detach/attach which also causes device destruction/creation. > Backtrace of this state shows nothing interesting, for example idling > in acpi_cpu_c1() or just DELAY(). > > Does anybody knows, for whom is this fault "reserved" and what does it > mean? > There was a recent thread about this - see also "r187880 causes fatal trap 30 when unloading drivers" -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 17:49:05 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F2279106566B; Sat, 21 Feb 2009 17:49:05 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.173]) by mx1.freebsd.org (Postfix) with ESMTP id BFB068FC0C; Sat, 21 Feb 2009 17:49:05 +0000 (UTC) (envelope-from minimarmot@gmail.com) Received: by wf-out-1314.google.com with SMTP id 27so1456200wfd.7 for ; Sat, 21 Feb 2009 09:49:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=V0lk4ZSvIbE1WSZaV5h0A1Pp/WDsmbb9CdWFz/fgR0Y=; b=YmYSCpgQ5keTioFSRJzr8AeoJkWHYSmWMnXJsYk93icPsi+qKq5BeY7myoDQFi2m2e gTKX9dThORCOajoY9QMwMG4MMygyWCUN09WinlBwW5s5ViNZXSJ27APQrBp7Mz2F1nwj VRISEwfTeFW9IrUSETc7M7GTnxmxhmMNUFQbs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BAr36FrGzH6VHPFgl4pt3kKUdT/eXxrYoSyTsHeLUnAp+FLAoyMc9Pe93Pfz+cXtTG qASUyvRFROqmDFXY1i+0xFfOAOGFswqjg+iDvySeeQzoZIiBjNZfEhq8iU2j3SAi6WL0 ulCecV2s0f34K1ZY+BUBDgDWLufh7oOnR+L+k= MIME-Version: 1.0 Received: by 10.142.79.17 with SMTP id c17mr1047097wfb.171.1235238545236; Sat, 21 Feb 2009 09:49:05 -0800 (PST) In-Reply-To: <499FFC5F.3020903@FreeBSD.org> References: <1235218982.00077642.1235207402@10.7.7.3> <499FFC5F.3020903@FreeBSD.org> Date: Sat, 21 Feb 2009 12:49:05 -0500 Message-ID: <47d0403c0902210949i74473bc5j57c923e13c85e89@mail.gmail.com> From: Ben Kaduk To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , FreeBSD Current Subject: Re: Annoying whitenoise sound coming from snd_hda enabled chipset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 17:49:06 -0000 On Sat, Feb 21, 2009 at 8:06 AM, Alexander Motin wrote: > Garrett Cooper wrote: >> >> I don't know how else to describe it, but when I turn up my >> speakers enough (50%+) and don't have any sound playing, I hear a >> whitenoise hiss coming out of them. When I change webpages (nvidia >> driver is GIANT locked) or do something else kernel intensive it stops >> for a brief second, but apart from that it's an annoying trill sound >> almost like a mosquito humming around me waiting to be swatted. > > I think it may be radio interference with disconnected microphone inputs. > Try to set all unneeded mixer volumes to 0, especially mic, monitor, speaker > and mix. Inputs often have too sensitive 20-30dB pre-amplifiers. Some codecs > have them on all inputs. It's hard to be sure, since I'm not sure that I could describe what I hear any better than Garret did, but I think I'm seeing the same sort of thing on my work desktop. I'll try setting unneeded volumes to zero the next time I'm in, and see if that helps. dmesg and pciconf are available here: http://stuff.mit.edu/afs/sipb.mit.edu/user/kaduk/freebsd/periphrasis/ -Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 18:16:53 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA7591065670 for ; Sat, 21 Feb 2009 18:16:53 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 5E9338FC1E for ; Sat, 21 Feb 2009 18:16:53 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 235422533; Sat, 21 Feb 2009 20:16:52 +0200 Message-ID: <49A04510.5030405@FreeBSD.org> Date: Sat, 21 Feb 2009 20:16:48 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Ben Kaduk References: <1235218982.00077642.1235207402@10.7.7.3> <499FFC5F.3020903@FreeBSD.org> <47d0403c0902210949i74473bc5j57c923e13c85e89@mail.gmail.com> In-Reply-To: <47d0403c0902210949i74473bc5j57c923e13c85e89@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , FreeBSD Current Subject: Re: Annoying whitenoise sound coming from snd_hda enabled chipset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 18:16:54 -0000 Ben Kaduk wrote: > On Sat, Feb 21, 2009 at 8:06 AM, Alexander Motin wrote: >> Garrett Cooper wrote: >>> I don't know how else to describe it, but when I turn up my >>> speakers enough (50%+) and don't have any sound playing, I hear a >>> whitenoise hiss coming out of them. When I change webpages (nvidia >>> driver is GIANT locked) or do something else kernel intensive it stops >>> for a brief second, but apart from that it's an annoying trill sound >>> almost like a mosquito humming around me waiting to be swatted. >> I think it may be radio interference with disconnected microphone inputs. >> Try to set all unneeded mixer volumes to 0, especially mic, monitor, speaker >> and mix. Inputs often have too sensitive 20-30dB pre-amplifiers. Some codecs >> have them on all inputs. > > It's hard to be sure, since I'm not sure that I could describe what I > hear any better than Garret did, but I think I'm seeing the same sort > of thing on my work desktop. I'll try setting unneeded volumes to > zero the next time I'm in, and see if that helps. > > dmesg and pciconf are available here: > http://stuff.mit.edu/afs/sipb.mit.edu/user/kaduk/freebsd/periphrasis/ I see there some old 7.0-STABLE dmesg without any pcm. There is nothing to talk about. If you wish to have good working HDA, update to recent STABLE or at least take driver from there. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 18:48:43 2009 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74CCD106566C for ; Sat, 21 Feb 2009 18:48:43 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout019.mac.com (asmtpout019.mac.com [17.148.16.94]) by mx1.freebsd.org (Postfix) with ESMTP id 602F88FC14 for ; Sat, 21 Feb 2009 18:48:43 +0000 (UTC) (envelope-from xcllnt@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed Received: from MacBook-Pro.lan.xcllnt.net (xcllnt.net [75.101.29.67]) by asmtp019.mac.com (Sun Java(tm) System Messaging Server 6.3-7.03 (built Aug 7 2008; 32bit)) with ESMTPSA id <0KFF00GBFIWM3W40@asmtp019.mac.com> for current@freebsd.org; Sat, 21 Feb 2009 10:48:23 -0800 (PST) Message-id: <09A4377D-3275-45CA-AB7B-2C2722B51521@mac.com> From: Marcel Moolenaar To: "Bjoern A. Zeeb" In-reply-to: <20090221082155.T53478@maildrop.int.zabbadoz.net> Date: Sat, 21 Feb 2009 10:48:22 -0800 References: <20090217113718.N53478@maildrop.int.zabbadoz.net> <725CDB16-7D31-42C9-924E-DB6B595BF071@mac.com> <20090221082155.T53478@maildrop.int.zabbadoz.net> X-Mailer: Apple Mail (2.930.3) Cc: FreeBSD current mailing list Subject: Re: boot0cfg -s vs. GEOM_PART_*? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 18:48:43 -0000 On Feb 21, 2009, at 12:25 AM, Bjoern A. Zeeb wrote: > Thanks. I see boot0cfg no longer errors but I am not sure if it does > the right thing: > > boot0cfg -s 5 ad0 > (doesn't atter if it's 0 or 2 to the -s options) as boot0cfg -s doesn't set the active flag on partitions. It changes some magic offset in the boot code that is being interpreted by the boot code. > That leaves me to the question - what's the boot0cfg -s5 equivalent > with gpart? There's no equivalent to the -s option, because gpart doesn't interpret or understand the boot code. You can change the active partition with gpart though: # gpart set -a active -i ad0 FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 18:51:46 2009 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 591331065689 for ; Sat, 21 Feb 2009 18:51:46 +0000 (UTC) (envelope-from kaduk@MIT.EDU) Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU [18.7.7.80]) by mx1.freebsd.org (Postfix) with ESMTP id EA9218FC19 for ; Sat, 21 Feb 2009 18:51:45 +0000 (UTC) (envelope-from kaduk@MIT.EDU) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by biscayne-one-station.mit.edu (8.13.6/8.9.2) with ESMTP id n1LIZWuP020070; Sat, 21 Feb 2009 13:35:32 -0500 (EST) Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id n1LIZVAN010966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 21 Feb 2009 13:35:31 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id n1LIZUk6013169; Sat, 21 Feb 2009 13:35:30 -0500 (EST) Date: Sat, 21 Feb 2009 13:35:29 -0500 (EST) From: Benjamin Kaduk To: Alexander Motin In-Reply-To: <49A04510.5030405@FreeBSD.org> Message-ID: References: <1235218982.00077642.1235207402@10.7.7.3> <499FFC5F.3020903@FreeBSD.org> <47d0403c0902210949i74473bc5j57c923e13c85e89@mail.gmail.com> <49A04510.5030405@FreeBSD.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.42 X-Spam-Flag: NO X-Spam-Score: 0.00 Cc: Garrett Cooper , FreeBSD Current , Ben Kaduk Subject: Re: Annoying whitenoise sound coming from snd_hda enabled chipset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 18:51:46 -0000 On Sat, 21 Feb 2009, Alexander Motin wrote: > Ben Kaduk wrote: >> On Sat, Feb 21, 2009 at 8:06 AM, Alexander Motin wrote: >>> Garrett Cooper wrote: >>>> I don't know how else to describe it, but when I turn up my >>>> speakers enough (50%+) and don't have any sound playing, I hear a >>>> whitenoise hiss coming out of them. When I change webpages (nvidia >>>> driver is GIANT locked) or do something else kernel intensive it stops >>>> for a brief second, but apart from that it's an annoying trill sound >>>> almost like a mosquito humming around me waiting to be swatted. >>> I think it may be radio interference with disconnected microphone inputs. >>> Try to set all unneeded mixer volumes to 0, especially mic, monitor, >>> speaker >>> and mix. Inputs often have too sensitive 20-30dB pre-amplifiers. Some >>> codecs >>> have them on all inputs. >> >> It's hard to be sure, since I'm not sure that I could describe what I >> hear any better than Garret did, but I think I'm seeing the same sort >> of thing on my work desktop. I'll try setting unneeded volumes to >> zero the next time I'm in, and see if that helps. >> >> dmesg and pciconf are available here: >> http://stuff.mit.edu/afs/sipb.mit.edu/user/kaduk/freebsd/periphrasis/ > > I see there some old 7.0-STABLE dmesg without any pcm. There is nothing to > talk about. If you wish to have good working HDA, update to recent STABLE or > at least take driver from there. Oops, I had been blocking on updating from 7 to current because of a bounce zone bug that was causing the box to panic, and I didn't update the dmesg after I did finally upgrade. Should be updated, now. Sorry about that, Ben Kaduk From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 21:56:36 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CC5091065673; Sat, 21 Feb 2009 21:56:36 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 69F148FC13; Sat, 21 Feb 2009 21:56:36 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by yx-out-2324.google.com with SMTP id 31so536843yxl.13 for ; Sat, 21 Feb 2009 13:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=znY9jCAp5LyGI/+GkY3wvhlUqoOI32szQRcb8pTQa0o=; b=f3LB91xU2gG659z0jOnDwHGOqxv7lsDMEFkrbuligQ3DcODVEBkEmR7r/smLsBhuUd vbG+Il50ZKasjWw3jqpjMTLzX33M3gck4xXBbJNpgTkhY9AtVLKJPFkL04a09naIQK0O o78iiwG4D0Tqox9WM88S1k3gSqgpENFzPQ0X0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GPBNwooJ3ZRUzSLOwZvX2MY9F+oLAZrj/tvX3ptP+C9Z6NJ9fufWavplSlq2REvV9M 0WNAOrvKva187VIUpaXfgh1P/szXY//AGVvztmhygfDw+cjLVU8oaWGMfEmtUEN/M/wK vX9iYo3kX/FYDdp3CmURWKMBqvaFhSWoDWyKk= MIME-Version: 1.0 Received: by 10.90.35.15 with SMTP id i15mr601464agi.83.1235253395156; Sat, 21 Feb 2009 13:56:35 -0800 (PST) In-Reply-To: References: <1235218982.00077642.1235207402@10.7.7.3> <499FFC5F.3020903@FreeBSD.org> <47d0403c0902210949i74473bc5j57c923e13c85e89@mail.gmail.com> <49A04510.5030405@FreeBSD.org> Date: Sat, 21 Feb 2009 13:56:35 -0800 Message-ID: <7d6fde3d0902211356h66b05cfcxf2ebbe9b2a6fd0f0@mail.gmail.com> From: Garrett Cooper To: Benjamin Kaduk Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexander Motin , FreeBSD Current , Ben Kaduk Subject: Re: Annoying whitenoise sound coming from snd_hda enabled chipset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 21:56:37 -0000 On Sat, Feb 21, 2009 at 10:35 AM, Benjamin Kaduk wrote: > On Sat, 21 Feb 2009, Alexander Motin wrote: > >> Ben Kaduk wrote: >>> >>> On Sat, Feb 21, 2009 at 8:06 AM, Alexander Motin wrote: >>>> >>>> Garrett Cooper wrote: >>>>> >>>>> I don't know how else to describe it, but when I turn up my >>>>> speakers enough (50%+) and don't have any sound playing, I hear a >>>>> whitenoise hiss coming out of them. When I change webpages (nvidia >>>>> driver is GIANT locked) or do something else kernel intensive it stops >>>>> for a brief second, but apart from that it's an annoying trill sound >>>>> almost like a mosquito humming around me waiting to be swatted. >>>> >>>> I think it may be radio interference with disconnected microphone >>>> inputs. >>>> Try to set all unneeded mixer volumes to 0, especially mic, monitor, >>>> speaker >>>> and mix. Inputs often have too sensitive 20-30dB pre-amplifiers. Some >>>> codecs >>>> have them on all inputs. >>> >>> It's hard to be sure, since I'm not sure that I could describe what I >>> hear any better than Garret did, but I think I'm seeing the same sort >>> of thing on my work desktop. I'll try setting unneeded volumes to >>> zero the next time I'm in, and see if that helps. >>> >>> dmesg and pciconf are available here: >>> http://stuff.mit.edu/afs/sipb.mit.edu/user/kaduk/freebsd/periphrasis/ >> >> I see there some old 7.0-STABLE dmesg without any pcm. There is nothing to >> talk about. If you wish to have good working HDA, update to recent STABLE or >> at least take driver from there. > > Oops, I had been blocking on updating from 7 to current because of > a bounce zone bug that was causing the box to panic, and I didn't > update the dmesg after I did finally upgrade. > > Should be updated, now. > > Sorry about that, > > Ben Kaduk Unfortunately I must use mix though or line-in doesn't function from my console peripherals. It does appear to be the culprit unfortunately. So I suppose I have to live with this issue until my SB Audigy card comes :(? This is something that should be noted in the driver manpage or you'll get more annoyed folks with support emails like this one ><... Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 22:00:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6719F106567B for ; Sat, 21 Feb 2009 22:00:21 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.28]) by mx1.freebsd.org (Postfix) with ESMTP id 1D3698FC1A for ; Sat, 21 Feb 2009 22:00:20 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by yx-out-2324.google.com with SMTP id 31so537159yxl.13 for ; Sat, 21 Feb 2009 14:00:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0qkCDZwGtvGLZXF0U5poVquxZ/LL+jAGBY04K+84hXs=; b=TbnCMxkHzdgduakhb0NkZE9V2KRQAZM6ft8b4CasZ+V1OGz+GxDJsfRDtfCojx5vYp KgwaPAznuzruEqdVAltKXSaJb4+fH/9mkLwwWppn4WMWZcsyeT5BR5SjzeFnkU6uegu3 x9CxNYvmjmGjrYJXym8veknyXCFigax94XxMM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=EcxOUy9zhTKSvCUVhr2xCWPBldo8wM1UeG1yVweyr1dMDsRMojb+fJL63c3WSvtd5h yl01gDbWqefFXmuuBGt4D3kcc9Eojw3O4RgnTJVt8PGGezWekLUxto/mS4jhVbwnX/+I ZHY1abRVxOHFY9nucSq1HHmB7CC1eL7iM6gWw= MIME-Version: 1.0 Received: by 10.90.49.8 with SMTP id w8mr606758agw.90.1235253620410; Sat, 21 Feb 2009 14:00:20 -0800 (PST) In-Reply-To: References: <49935993.50303@stillbilde.net> <200902120818.34567.jhb@freebsd.org> <7d6fde3d0902201727k61554608j9b3d5cdc3e78c3dc@mail.gmail.com> Date: Sat, 21 Feb 2009 14:00:20 -0800 Message-ID: <7d6fde3d0902211400i772e6cb4uda66f79fa7c4bf6@mail.gmail.com> From: Garrett Cooper To: Buganini Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: modular kernconf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 22:00:22 -0000 On Sat, Feb 21, 2009 at 3:39 AM, Buganini wrote: > Do you mean I should use << include "GENERIC" >>? > but in USB2 and PAE, there were no quotes, > I just mimic them. > > > On Sat, Feb 21, 2009 at 9:27 AM, Garrett Cooper wrote: >> The included file _must_ be quoted (at least on 8-CURRENT). It's a >> common mistake in the examples. >> HTH, >> -Garrett Yes, but if you try and compile it that way, it will fail. At least it did with me and my include files... HTH, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 22:03:11 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD5B51065672 for ; Sat, 21 Feb 2009 22:03:11 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 624878FC13 for ; Sat, 21 Feb 2009 22:03:10 +0000 (UTC) (envelope-from mav@FreeBSD.org) X-Spam-Flag: SKIP X-Spam-Yversion: Spamooborona-2.1.0 Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 235429951; Sun, 22 Feb 2009 00:03:10 +0200 Message-ID: <49A07A1A.2030902@FreeBSD.org> Date: Sun, 22 Feb 2009 00:03:06 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.19 (X11/20090118) MIME-Version: 1.0 To: Garrett Cooper References: <1235218982.00077642.1235207402@10.7.7.3> <499FFC5F.3020903@FreeBSD.org> <47d0403c0902210949i74473bc5j57c923e13c85e89@mail.gmail.com> <49A04510.5030405@FreeBSD.org> <7d6fde3d0902211356h66b05cfcxf2ebbe9b2a6fd0f0@mail.gmail.com> In-Reply-To: <7d6fde3d0902211356h66b05cfcxf2ebbe9b2a6fd0f0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Benjamin Kaduk , Ben Kaduk Subject: Re: Annoying whitenoise sound coming from snd_hda enabled chipset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 22:03:12 -0000 Garrett Cooper wrote: > On Sat, Feb 21, 2009 at 10:35 AM, Benjamin Kaduk wrote: >> On Sat, 21 Feb 2009, Alexander Motin wrote: >> >>> Ben Kaduk wrote: >>>> On Sat, Feb 21, 2009 at 8:06 AM, Alexander Motin wrote: >>>>> Garrett Cooper wrote: >>>>>> I don't know how else to describe it, but when I turn up my >>>>>> speakers enough (50%+) and don't have any sound playing, I hear a >>>>>> whitenoise hiss coming out of them. When I change webpages (nvidia >>>>>> driver is GIANT locked) or do something else kernel intensive it stops >>>>>> for a brief second, but apart from that it's an annoying trill sound >>>>>> almost like a mosquito humming around me waiting to be swatted. >>>>> I think it may be radio interference with disconnected microphone >>>>> inputs. >>>>> Try to set all unneeded mixer volumes to 0, especially mic, monitor, >>>>> speaker >>>>> and mix. Inputs often have too sensitive 20-30dB pre-amplifiers. Some >>>>> codecs >>>>> have them on all inputs. >>>> It's hard to be sure, since I'm not sure that I could describe what I >>>> hear any better than Garret did, but I think I'm seeing the same sort >>>> of thing on my work desktop. I'll try setting unneeded volumes to >>>> zero the next time I'm in, and see if that helps. >>>> >>>> dmesg and pciconf are available here: >>>> http://stuff.mit.edu/afs/sipb.mit.edu/user/kaduk/freebsd/periphrasis/ >>> I see there some old 7.0-STABLE dmesg without any pcm. There is nothing to >>> talk about. If you wish to have good working HDA, update to recent STABLE or >>> at least take driver from there. >> Oops, I had been blocking on updating from 7 to current because of >> a bounce zone bug that was causing the box to panic, and I didn't >> update the dmesg after I did finally upgrade. >> >> Should be updated, now. >> >> Sorry about that, >> >> Ben Kaduk > > Unfortunately I must use mix though or line-in doesn't function > from my console peripherals. It does appear to be the culprit > unfortunately. Have you tried to mute other sources specifically? mix is just a sum of inputs, it is not an input itself. You may read driver verbose boot messages to find which inputs are mixed and how they controlled. > So I suppose I have to live with this issue until my SB Audigy > card comes :(? This is something that should be noted in the driver > manpage or you'll get more annoyed folks with support emails like this > one ><... It won't help. People never read manuals, especially long ones. :( -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 22:12:08 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C57F6106564A for ; Sat, 21 Feb 2009 22:12:08 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-gx0-f176.google.com (mail-gx0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id 80EA68FC08 for ; Sat, 21 Feb 2009 22:12:08 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by gxk24 with SMTP id 24so5023468gxk.19 for ; Sat, 21 Feb 2009 14:12:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=hxtWpU/5surIxAN81hHGSG3HovSB4ZFrlzRjpo1n7Z8=; b=G1DbXpxabtn6oC5+c4q6CFmfTuoP3Cm++Ipc0E+EVDzLoNWyL5YGIlFRIwwkKe24RT N43MnL/PcdY3K+9dSi+ZcU01eGGs1kJOa2oX1PuLUCSb8buIVuRTTBKw+xAaxDHEoGkP aqxTUiovZVK+HyhlDfgVrfWa3dJrZc90CLQms= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=Q4DDLBiPnqDhP2/ddDHm+UOzsrNfMtAs5Lv9sjlX/hPn5JNHcVTIPRPCOvUB1oJ6uN h7umB7/Oqdk++F08RR9h7d7aJzC9YliT/4pK08/FUbeeQhFJZeOMGdfy0FNFjHM/f2mo Ek355rZ11Is1cWv8IrIcOqrRFPvbbCy58dbhE= MIME-Version: 1.0 Received: by 10.90.83.2 with SMTP id g2mr619032agb.69.1235254327935; Sat, 21 Feb 2009 14:12:07 -0800 (PST) Date: Sat, 21 Feb 2009 14:12:07 -0800 Message-ID: <7d6fde3d0902211412i15eb88c5x7ae8d54caa286cec@mail.gmail.com> From: Garrett Cooper To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: CVS suckage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 22:12:09 -0000 Hi guys, Now I realize that cvs is an old RCS method and all, and is incredibly buggy, but I cannot for the life of me get the version in the source tree nor the version in ports to work for me when syncing (fails to connect), checking out (fails to connect), or check in (segfaults) either for the FreeBSD repository or outside repositories. What I'm trying to do is trace down the dependent libraries and rebuild them, just in case they're corrupt / nonfunctional, but I can't determine where gcrypt lives within the source tree: [root@orangebox /usr/src]# ldd `which cvs` /usr/bin/cvs: libintl.so.8 => /usr/local/lib/libintl.so.8 (0x28130000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28139000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x2822e000) libc.so.7 => /lib/libc.so.7 (0x28247000) Could someone provide me a pointer on this? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 22:14:18 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB5111065674; Sat, 21 Feb 2009 22:14:18 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-gx0-f176.google.com (mail-gx0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id 7AF278FC13; Sat, 21 Feb 2009 22:14:18 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by gxk24 with SMTP id 24so5025313gxk.19 for ; Sat, 21 Feb 2009 14:14:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Bw5L6BvJaSYgw+9MDQCrqHnM6rDrVC3GS2R35xrl6jo=; b=J/4Q70YCWAIFG+Yw0GPUvsPRSTREzsHKnEViFQ6iVoIShsUC159DEKJxsP1uFzac20 kNG3GPxmZI+ZhD9ytCSpIvc4liFfoLrcn7pzrIIKlExEzDLtqkaWzSd4mWLEXzQ1bHUX agxkyrpwuQEaK4uHebQSLuj6skjIwK8pakGKE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=nzjnMclm/QrnpW9inRGfr2bt2F2W9xpIRPzUJNKS3/ixEd23E0NahBGq5q6dOGGtzU UYZ1miDtzWn4iYlvXeGHM+SfTyR0WXerKU9Ks3q2OsBzzaxEs+MmXz6dMQS7s88xn4ST Z8DxJu0aVzbgMiIzYjGPsbH1ayolykShYLVx8= MIME-Version: 1.0 Received: by 10.90.49.3 with SMTP id w3mr616916agw.21.1235254457816; Sat, 21 Feb 2009 14:14:17 -0800 (PST) In-Reply-To: <49A07A1A.2030902@FreeBSD.org> References: <1235218982.00077642.1235207402@10.7.7.3> <499FFC5F.3020903@FreeBSD.org> <47d0403c0902210949i74473bc5j57c923e13c85e89@mail.gmail.com> <49A04510.5030405@FreeBSD.org> <7d6fde3d0902211356h66b05cfcxf2ebbe9b2a6fd0f0@mail.gmail.com> <49A07A1A.2030902@FreeBSD.org> Date: Sat, 21 Feb 2009 14:14:17 -0800 Message-ID: <7d6fde3d0902211414k571fa88ajcb1ba9771c2be423@mail.gmail.com> From: Garrett Cooper To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current , Benjamin Kaduk , Ben Kaduk Subject: Re: Annoying whitenoise sound coming from snd_hda enabled chipset X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 22:14:19 -0000 On Sat, Feb 21, 2009 at 2:03 PM, Alexander Motin wrote: > Garrett Cooper wrote: >> >> On Sat, Feb 21, 2009 at 10:35 AM, Benjamin Kaduk wrote: >>> >>> On Sat, 21 Feb 2009, Alexander Motin wrote: >>> >>>> Ben Kaduk wrote: >>>>> >>>>> On Sat, Feb 21, 2009 at 8:06 AM, Alexander Motin >>>>> wrote: >>>>>> >>>>>> Garrett Cooper wrote: >>>>>>> >>>>>>> I don't know how else to describe it, but when I turn up my >>>>>>> speakers enough (50%+) and don't have any sound playing, I hear a >>>>>>> whitenoise hiss coming out of them. When I change webpages (nvidia >>>>>>> driver is GIANT locked) or do something else kernel intensive it >>>>>>> stops >>>>>>> for a brief second, but apart from that it's an annoying trill sound >>>>>>> almost like a mosquito humming around me waiting to be swatted. >>>>>> >>>>>> I think it may be radio interference with disconnected microphone >>>>>> inputs. >>>>>> Try to set all unneeded mixer volumes to 0, especially mic, monitor, >>>>>> speaker >>>>>> and mix. Inputs often have too sensitive 20-30dB pre-amplifiers. Some >>>>>> codecs >>>>>> have them on all inputs. >>>>> >>>>> It's hard to be sure, since I'm not sure that I could describe what I >>>>> hear any better than Garret did, but I think I'm seeing the same sort >>>>> of thing on my work desktop. I'll try setting unneeded volumes to >>>>> zero the next time I'm in, and see if that helps. >>>>> >>>>> dmesg and pciconf are available here: >>>>> http://stuff.mit.edu/afs/sipb.mit.edu/user/kaduk/freebsd/periphrasis/ >>>> >>>> I see there some old 7.0-STABLE dmesg without any pcm. There is nothing >>>> to >>>> talk about. If you wish to have good working HDA, update to recent >>>> STABLE or >>>> at least take driver from there. >>> >>> Oops, I had been blocking on updating from 7 to current because of >>> a bounce zone bug that was causing the box to panic, and I didn't >>> update the dmesg after I did finally upgrade. >>> >>> Should be updated, now. >>> >>> Sorry about that, >>> >>> Ben Kaduk >> >> Unfortunately I must use mix though or line-in doesn't function >> from my console peripherals. It does appear to be the culprit >> unfortunately. > > Have you tried to mute other sources specifically? mix is just a sum of > inputs, it is not an input itself. You may read driver verbose boot messages > to find which inputs are mixed and how they controlled. As I suggested earlier it's Line, so again I'm stuck without line-in to my console peripherals :(. >> So I suppose I have to live with this issue until my SB Audigy >> card comes :(? This is something that should be noted in the driver >> manpage or you'll get more annoyed folks with support emails like this >> one ><... > > It won't help. People never read manuals, especially long ones. :( Yes, but what about the BUGS section, etc :)? -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 22:16:24 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB5BE106564A for ; Sat, 21 Feb 2009 22:16:24 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-gx0-f176.google.com (mail-gx0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id A83468FC08 for ; Sat, 21 Feb 2009 22:16:24 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by gxk24 with SMTP id 24so5026882gxk.19 for ; Sat, 21 Feb 2009 14:16:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=YrcxYW5NwjBSkkYfrhJWnsNPQnI2xJchBYs+hVKFBiw=; b=i0TW0tXsrYuQbaxhUE76UZJmj49FaVdw6g6tr2izSkBsBxQZrnnHpvzVKHjuino2Cj VMlHBdt3FEi9BEtH1wyGyFIzGbyeznu+ws/YYehGg2QDMHFmbCic1K8wbeP6+gkOnnwx 6eREXD8iU9dqc0P9LE5GNXBeM5jc6uFs3T4kw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=sOtyxVNfcSKxflI/GP1aUlO/Ovje23aCXyVGQOCBZWdXeYjWK2ZTkvgFfGyV8a6G8n g12k+VR8OthG2Usppv1h6dA5+6a1SdnxqHCW7Nla4w7Beo7BKyQm4JIxHujbcTNsfD49 FQ5RMwri7l3quaQnhMnKj5zCd5dbH5zAYWlf4= MIME-Version: 1.0 Received: by 10.90.93.13 with SMTP id q13mr618510agb.51.1235254584170; Sat, 21 Feb 2009 14:16:24 -0800 (PST) In-Reply-To: <7d6fde3d0902211412i15eb88c5x7ae8d54caa286cec@mail.gmail.com> References: <7d6fde3d0902211412i15eb88c5x7ae8d54caa286cec@mail.gmail.com> Date: Sat, 21 Feb 2009 14:16:24 -0800 Message-ID: <7d6fde3d0902211416y17593931n8b1d43426d6fc5e0@mail.gmail.com> From: Garrett Cooper To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: CVS suckage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 22:16:25 -0000 On Sat, Feb 21, 2009 at 2:12 PM, Garrett Cooper wrote: > Hi guys, > Now I realize that cvs is an old RCS method and all, and is > incredibly buggy, but I cannot for the life of me get the version in > the source tree nor the version in ports to work for me when syncing > (fails to connect), checking out (fails to connect), or check in > (segfaults) either for the FreeBSD repository or outside repositories. > What I'm trying to do is trace down the dependent libraries and > rebuild them, just in case they're corrupt / nonfunctional, but I > can't determine where gcrypt lives within the source tree: > [root@orangebox /usr/src]# ldd `which cvs` > /usr/bin/cvs: > libintl.so.8 => /usr/local/lib/libintl.so.8 (0x28130000) > libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28139000) > libcrypt.so.4 => /lib/libcrypt.so.4 (0x2822e000) > libc.so.7 => /lib/libc.so.7 (0x28247000) > Could someone provide me a pointer on this? > Thanks, > -Garrett I just stared at the ldd output and it appears that 2/4 of the libraries are being picked up from ports. Isn't there a policy for LDFLAGS / CFLAGS in base? Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 22:32:50 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FC8B1065679 for ; Sat, 21 Feb 2009 22:32:50 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 411AA8FC1F for ; Sat, 21 Feb 2009 22:32:50 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from [IPv6:2001:7b8:3a7:0:41d5:154d:8a11:1315] (unknown [IPv6:2001:7b8:3a7:0:41d5:154d:8a11:1315]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id DEB6D5C42; Sat, 21 Feb 2009 23:32:48 +0100 (CET) Message-ID: <49A08113.4080100@andric.com> Date: Sat, 21 Feb 2009 23:32:51 +0100 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b3pre) Gecko/20090220 Shredder/3.0b3pre MIME-Version: 1.0 To: Garrett Cooper References: <7d6fde3d0902211412i15eb88c5x7ae8d54caa286cec@mail.gmail.com> In-Reply-To: <7d6fde3d0902211412i15eb88c5x7ae8d54caa286cec@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: CVS suckage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 22:32:50 -0000 On 2009-02-21 23:12, Garrett Cooper wrote: > /usr/bin/cvs: > libintl.so.8 => /usr/local/lib/libintl.so.8 (0x28130000) > libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28139000) > libcrypt.so.4 => /lib/libcrypt.so.4 (0x2822e000) > libc.so.7 => /lib/libc.so.7 (0x28247000) There must be something wrong with your CVS binary, on my -CURRENT system it gives: $ ldd /usr/bin/cvs /usr/bin/cvs: libgnuregex.so.4 => /usr/lib/libgnuregex.so.4 (0x28109000) libmd.so.4 => /lib/libmd.so.4 (0x2811a000) libcrypt.so.4 => /lib/libcrypt.so.4 (0x2812a000) libz.so.4 => /lib/libz.so.4 (0x28143000) libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x28155000) libkrb5.so.10 => /usr/lib/libkrb5.so.10 (0x2815e000) libhx509.so.10 => /usr/lib/libhx509.so.10 (0x281bc000) libasn1.so.10 => /usr/lib/libasn1.so.10 (0x281f2000) libcrypto.so.5 => /lib/libcrypto.so.5 (0x28267000) libroken.so.10 => /usr/lib/libroken.so.10 (0x283c2000) libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x283d2000) libc.so.7 => /lib/libc.so.7 (0x283d4000) E.g. nothing from /usr/local. Have you overwritten your base version with a version from ports, or something like that? From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 22:38:38 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0BF2106564A for ; Sat, 21 Feb 2009 22:38:38 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by mx1.freebsd.org (Postfix) with ESMTP id 6708D8FC0A for ; Sat, 21 Feb 2009 22:38:38 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by yw-out-2324.google.com with SMTP id 2so541087ywt.13 for ; Sat, 21 Feb 2009 14:38:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Q6qsoccgH/2X6Z+gTCuVrsyx8siZvFPpYMvdwmc5/wI=; b=KqWve6aGdmW+lG8CIEY/UzWLTAUmbqKug33zv7c/nf1/g7Q+YKxgpNUHa7rNkypHYX H30m1o/GUNpVGEKnpPpsdd0ug+rrX50mWTVP0h3JP1TtJ3chmXiRiTBF+RA1vBt6Wq/R OueZK1GXiIw6uYpDk5BcHKKZmhxh8uApMcx+M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=pWmrrMAKUZ8QfBVWWmWOHVaa7fgNpJ0+QTseKMcXo9tPaL+wRzBiCsBUIE6oqcX3Ww GwvAWk1MCcS9emMPRpAv1Ax/jINj1uvMrDv3R9V7ghvuLX9yYAwY3ut4NQrVLofN7Lcf ZjygmB2Tl/J02Fj0iZAsF7ON2Xodcc99DXFWE= MIME-Version: 1.0 Received: by 10.90.84.17 with SMTP id h17mr628010agb.40.1235255917793; Sat, 21 Feb 2009 14:38:37 -0800 (PST) In-Reply-To: <49A08113.4080100@andric.com> References: <7d6fde3d0902211412i15eb88c5x7ae8d54caa286cec@mail.gmail.com> <49A08113.4080100@andric.com> Date: Sat, 21 Feb 2009 14:38:37 -0800 Message-ID: <7d6fde3d0902211438t212bbe7cwc3726ea1c1fe9120@mail.gmail.com> From: Garrett Cooper To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: CVS suckage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 22:38:39 -0000 On Sat, Feb 21, 2009 at 2:32 PM, Dimitry Andric wrote: > On 2009-02-21 23:12, Garrett Cooper wrote: >> /usr/bin/cvs: >> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x28130000) >> libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28139000) >> libcrypt.so.4 => /lib/libcrypt.so.4 (0x2822e000) >> libc.so.7 => /lib/libc.so.7 (0x28247000) > > There must be something wrong with your CVS binary, on my -CURRENT > system it gives: > > $ ldd /usr/bin/cvs > /usr/bin/cvs: > libgnuregex.so.4 => /usr/lib/libgnuregex.so.4 (0x28109000) > libmd.so.4 => /lib/libmd.so.4 (0x2811a000) > libcrypt.so.4 => /lib/libcrypt.so.4 (0x2812a000) > libz.so.4 => /lib/libz.so.4 (0x28143000) > libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x28155000) > libkrb5.so.10 => /usr/lib/libkrb5.so.10 (0x2815e000) > libhx509.so.10 => /usr/lib/libhx509.so.10 (0x281bc000) > libasn1.so.10 => /usr/lib/libasn1.so.10 (0x281f2000) > libcrypto.so.5 => /lib/libcrypto.so.5 (0x28267000) > libroken.so.10 => /usr/lib/libroken.so.10 (0x283c2000) > libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x283d2000) > libc.so.7 => /lib/libc.so.7 (0x283d4000) > > E.g. nothing from /usr/local. Have you overwritten your base version > with a version from ports, or something like that? Not that I recall... -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 22:40:21 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C916610656C4 for ; Sat, 21 Feb 2009 22:40:21 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mail-gx0-f176.google.com (mail-gx0-f176.google.com [209.85.217.176]) by mx1.freebsd.org (Postfix) with ESMTP id 6CCE08FC1E for ; Sat, 21 Feb 2009 22:40:21 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by gxk24 with SMTP id 24so5045800gxk.19 for ; Sat, 21 Feb 2009 14:40:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=wLE8mDC1yz4Xc6TSHzJEsTeTiN8BB/YUvPl/+NidERw=; b=vLGQrv5Uq7tpFlJUVJd9GtR772H2wYH08OqEWUFFpeu6qFPN9jgyl2KxGpvCBzmtX9 eGRQhWzqu71MCmiUa3Y+gg/jfeYJBjEUoivksqKbvIduVqwbMFluye3k2L7DHWH38hma 9spxdwxX3rNjFQwgzmXRcE5a8iFDrxgNMe8bU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sxZUStrk5ByUVte3Y5rBtyDBu7vmfHHsrpSIYifwfzcmeghZUcuWfiBF5Yy0NJ5NqG iaIpWPtSf1FD9m6adnZxw6Tpb9t3Q6x5RLpWXjPKQxHy5rFt/RfTZHuRThcv9AJRxt97 LSWhDcPB8Ez0dpcKrCTYbblKRp2G9PEyzQlQM= MIME-Version: 1.0 Received: by 10.90.49.3 with SMTP id w3mr629036agw.21.1235256020836; Sat, 21 Feb 2009 14:40:20 -0800 (PST) In-Reply-To: <7d6fde3d0902211438t212bbe7cwc3726ea1c1fe9120@mail.gmail.com> References: <7d6fde3d0902211412i15eb88c5x7ae8d54caa286cec@mail.gmail.com> <49A08113.4080100@andric.com> <7d6fde3d0902211438t212bbe7cwc3726ea1c1fe9120@mail.gmail.com> Date: Sat, 21 Feb 2009 14:40:20 -0800 Message-ID: <7d6fde3d0902211440i7f8d901i1470a421becbb739@mail.gmail.com> From: Garrett Cooper To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: CVS suckage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 22:40:23 -0000 On Sat, Feb 21, 2009 at 2:38 PM, Garrett Cooper wrote: > On Sat, Feb 21, 2009 at 2:32 PM, Dimitry Andric wrote: >> On 2009-02-21 23:12, Garrett Cooper wrote: >>> /usr/bin/cvs: >>> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x28130000) >>> libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28139000) >>> libcrypt.so.4 => /lib/libcrypt.so.4 (0x2822e000) >>> libc.so.7 => /lib/libc.so.7 (0x28247000) >> >> There must be something wrong with your CVS binary, on my -CURRENT >> system it gives: >> >> $ ldd /usr/bin/cvs >> /usr/bin/cvs: >> libgnuregex.so.4 => /usr/lib/libgnuregex.so.4 (0x28109000) >> libmd.so.4 => /lib/libmd.so.4 (0x2811a000) >> libcrypt.so.4 => /lib/libcrypt.so.4 (0x2812a000) >> libz.so.4 => /lib/libz.so.4 (0x28143000) >> libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x28155000) >> libkrb5.so.10 => /usr/lib/libkrb5.so.10 (0x2815e000) >> libhx509.so.10 => /usr/lib/libhx509.so.10 (0x281bc000) >> libasn1.so.10 => /usr/lib/libasn1.so.10 (0x281f2000) >> libcrypto.so.5 => /lib/libcrypto.so.5 (0x28267000) >> libroken.so.10 => /usr/lib/libroken.so.10 (0x283c2000) >> libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x283d2000) >> libc.so.7 => /lib/libc.so.7 (0x283d4000) >> >> E.g. nothing from /usr/local. Have you overwritten your base version >> with a version from ports, or something like that? > > Not that I recall... > -Garrett I might have in the past trying to troubleshoot and issue and I forgot to remove it... removing the old binary and running make install again seems to have worked.. Let's see how this goes. Thanks! -Garrett From owner-freebsd-current@FreeBSD.ORG Sat Feb 21 22:48:48 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DAA11106566C for ; Sat, 21 Feb 2009 22:48:48 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 9205F8FC12 for ; Sat, 21 Feb 2009 22:48:48 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: by yx-out-2324.google.com with SMTP id 31so540916yxl.13 for ; Sat, 21 Feb 2009 14:48:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5V12DS6W5BrLO7Elrxu6ni0S3BwY+gTVojHniqO0Pgc=; b=tIlQlTtFI9chp1nUucdTAsHHp7cG73r3f8ufiuTfZANhla2LtSCsKAl6N1Zj9fqTt6 na0ZABw4WtVFXFgNt9hckAoN21/coPw9M5tYzZEmSMqPNtAyJDR/QIQVxD20/9gFurYJ fpYPhqRkI1PaDX5NwweKBxLMzsFjVabyAWKJA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BS1TyvThpySgNO/AgKd86rIZDi3hWOojpKB5T4YNNA0pthhdUVlFDDoQw6KX73bg5c CEDFQGmilehsG6vB/y4cjIECLKYYDu16UwPW5p50NtR0UQ1mMoN0Tvct2qrE0Duc0Dri cL04vkTVW9go1BC0ifUlDtamLsRkdcsFnr2sw= MIME-Version: 1.0 Received: by 10.90.83.2 with SMTP id g2mr636244agb.69.1235256528036; Sat, 21 Feb 2009 14:48:48 -0800 (PST) In-Reply-To: <7d6fde3d0902211440i7f8d901i1470a421becbb739@mail.gmail.com> References: <7d6fde3d0902211412i15eb88c5x7ae8d54caa286cec@mail.gmail.com> <49A08113.4080100@andric.com> <7d6fde3d0902211438t212bbe7cwc3726ea1c1fe9120@mail.gmail.com> <7d6fde3d0902211440i7f8d901i1470a421becbb739@mail.gmail.com> Date: Sat, 21 Feb 2009 14:48:47 -0800 Message-ID: <7d6fde3d0902211448i3c15208bu2ee553a02b4b8d49@mail.gmail.com> From: Garrett Cooper To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: CVS suckage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Feb 2009 22:48:49 -0000 On Sat, Feb 21, 2009 at 2:40 PM, Garrett Cooper wrote: > On Sat, Feb 21, 2009 at 2:38 PM, Garrett Cooper wrote: >> On Sat, Feb 21, 2009 at 2:32 PM, Dimitry Andric wrote: >>> On 2009-02-21 23:12, Garrett Cooper wrote: >>>> /usr/bin/cvs: >>>> libintl.so.8 => /usr/local/lib/libintl.so.8 (0x28130000) >>>> libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28139000) >>>> libcrypt.so.4 => /lib/libcrypt.so.4 (0x2822e000) >>>> libc.so.7 => /lib/libc.so.7 (0x28247000) >>> >>> There must be something wrong with your CVS binary, on my -CURRENT >>> system it gives: >>> >>> $ ldd /usr/bin/cvs >>> /usr/bin/cvs: >>> libgnuregex.so.4 => /usr/lib/libgnuregex.so.4 (0x28109000) >>> libmd.so.4 => /lib/libmd.so.4 (0x2811a000) >>> libcrypt.so.4 => /lib/libcrypt.so.4 (0x2812a000) >>> libz.so.4 => /lib/libz.so.4 (0x28143000) >>> libgssapi.so.10 => /usr/lib/libgssapi.so.10 (0x28155000) >>> libkrb5.so.10 => /usr/lib/libkrb5.so.10 (0x2815e000) >>> libhx509.so.10 => /usr/lib/libhx509.so.10 (0x281bc000) >>> libasn1.so.10 => /usr/lib/libasn1.so.10 (0x281f2000) >>> libcrypto.so.5 => /lib/libcrypto.so.5 (0x28267000) >>> libroken.so.10 => /usr/lib/libroken.so.10 (0x283c2000) >>> libcom_err.so.4 => /usr/lib/libcom_err.so.4 (0x283d2000) >>> libc.so.7 => /lib/libc.so.7 (0x283d4000) >>> >>> E.g. nothing from /usr/local. Have you overwritten your base version >>> with a version from ports, or something like that? >> >> Not that I recall... >> -Garrett > > I might have in the past trying to troubleshoot and issue and I > forgot to remove it... removing the old binary and running make > install again seems to have worked.. > Let's see how this goes. > Thanks! > -Garrett I also commented out the line WITHOUT_CVS=yes in src.conf before doing the install, and it works now. Thanks! -Garrett