From owner-freebsd-current@FreeBSD.ORG Sun Jan 24 03:22:40 2010 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 2D662106566C for ; Sun, 24 Jan 2010 03:22:40 +0000 (UTC) (envelope-from fluffy@Fluffy.Khv.RU) Received: from ns.ael.RU (ns.ael.ru [62.76.207.226]) by mx1.freebsd.org (Postfix) with ESMTP id 6D41D8FC13 for ; Sun, 24 Jan 2010 03:22:39 +0000 (UTC) Received: from Fluffy.Khv.RU (85.9.168.188.retail.ttk.ru [188.168.9.85] (may be forged)) by ns.ael.RU (8.14.3/8.14.3/Fluffy/5.3) with ESMTP id o0O3CTAK048321 for ; Sun, 24 Jan 2010 13:12:31 +1000 (VLAT) (envelope-from fluffy@Fluffy.Khv.RU) Received: from Fluffy.Khv.RU (localhost [127.0.0.1]) by Fluffy.Khv.RU (8.14.3/8.14.3/Fluffy/5.4.1) with ESMTP id o0O3CBhp054254 for ; Sun, 24 Jan 2010 13:12:11 +1000 (VLAT) (envelope-from fluffy@Fluffy.Khv.RU) Received: (from fluffy@localhost) by Fluffy.Khv.RU (8.14.3/8.14.3/Submit) id o0O2h59N049671 for current@FreeBSD.org; Sun, 24 Jan 2010 12:43:05 +1000 (VLAT) (envelope-from fluffy) Date: Sun, 24 Jan 2010 12:43:02 +1000 From: Dima Panov To: current@FreeBSD.org Message-ID: <20100124024214.GA49252@Fluffy.Khv.RU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Twilight Zone X-Operating-System: FreeBSD 9.0-900008-CURRENT amd64 X-Disclaimer: Listen, and thou shall not fear. User-Agent: Mutt/1.5.20 (2009-06-14) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (ns.ael.RU [62.76.207.226]); Sun, 24 Jan 2010 13:12:31 +1000 (VLAT) X-Spam-Status: No, score=-0.1 required=3.0 tests=AWL,BAYES_00, FH_DATE_PAST_20XX, RDNS_NONE, SPF_FAIL, SPF_HELO_FAIL autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ns.ael.RU Cc: Subject: Regression in -current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 03:22:40 -0000 Good day, folks! I see a strange regression since Friday's kernel, may be it's a kqueue-related. While building ports, now I never see 100% load of cpu, and portupgrade -fa takes ~7 hours for ~40 ports. Updating to current state (~3am VLAT) doesn't help. KDB and WITNESS/INVARIANTS disablen in kernel config # uname -a FreeBSD Fluffy.Khv.RU 9.0-900008-CURRENT FreeBSD 9.0-900008-CURRENT #0: Sun Jan 24 03:37:40 VLAT 2010 fluffy@Fluffy.Khv.RU:/usr/obj/usr/src/sys/Spot amd64 -- Dima "Red Fox" Panov @ Home | C73E 2B72 1FFD 61BD E206 1234 A626 76ED 93E3 B018 Khabarovsk, Russia | 2D30 2CCB 9984 130C 6F87 BAFC FB8B A09D D539 8F29 KDE@FreeBSD Team | FreeBSD committer since 10.08.2009 | FreeBSD since Sept 1995 Twitter.com:fluffy_khv | Skype:dima.panov | Jabber.org:fluffy.khv | ICQ:1745024 From owner-freebsd-current@FreeBSD.ORG Sun Jan 24 03:35:38 2010 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 E92E2106566C for ; Sun, 24 Jan 2010 03:35:38 +0000 (UTC) (envelope-from avl@logvinov.com) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx1.freebsd.org (Postfix) with ESMTP id C85398FC0A for ; Sun, 24 Jan 2010 03:35:38 +0000 (UTC) Received: by pwi15 with SMTP id 15so1749745pwi.3 for ; Sat, 23 Jan 2010 19:35:38 -0800 (PST) Received: by 10.141.214.4 with SMTP id r4mr2081449rvq.3.1264304138284; Sat, 23 Jan 2010 19:35:38 -0800 (PST) Received: from incubus.bsd ([125.34.33.104]) by mx.google.com with ESMTPS id 21sm3562885pzk.7.2010.01.23.19.35.35 (version=SSLv3 cipher=RC4-MD5); Sat, 23 Jan 2010 19:35:37 -0800 (PST) Message-ID: <4B5BC039.5060406@logvinov.com> Date: Sun, 24 Jan 2010 11:36:25 +0800 From: Alexander Logvinov User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.9.1.7) Gecko/20100122 Thunderbird/3.0.1 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20100124024214.GA49252@Fluffy.Khv.RU> In-Reply-To: <20100124024214.GA49252@Fluffy.Khv.RU> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: Regression in -current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 03:35:39 -0000 Hello! On 24.01.2010 10:43 Dima Panov wrote: > I see a strange regression since Friday's kernel, may be it's a kqueue-related. > While building ports, now I never see 100% load of cpu, and portupgrade -fa > takes ~7 hours for ~40 ports. Updating to current state (~3am VLAT) doesn't help. > > KDB and WITNESS/INVARIANTS disablen in kernel config I have a similar problem with r202904 amd64 kernel with interesting CPU statistic: top output: last pid: 1885; load averages: 2.89, 1.56, 0.66 up 0+00:02:47 09:31:44 72 processes: 3 running, 69 sleeping _CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle_ Mem: 120M Active, 39M Inact, 153M Wired, 6968K Cache, 65M Buf, 3565M Free Swap: 8192M Total, 8192M Free htop output: _1 [ nan%]_ Tasks: 53 total, 4 running _2 [ nan%]_ Load average: 2.52 1.52 0.65 Mem[||| 146/4035MB] Uptime: 00:02:32 Swp[ 0/8191MB] With r202370 everything is OK. -- Best regards, Alexander From owner-freebsd-current@FreeBSD.ORG Sun Jan 24 05:45:53 2010 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 B43AA106566B for ; Sun, 24 Jan 2010 05:45:53 +0000 (UTC) (envelope-from rmtodd@ichotolot.servalan.com) Received: from mx1.synetsystems.com (mx1.synetsystems.com [76.10.206.14]) by mx1.freebsd.org (Postfix) with ESMTP id 8D2718FC17 for ; Sun, 24 Jan 2010 05:45:53 +0000 (UTC) Received: by mx1.synetsystems.com (Postfix, from userid 66) id CB2D5E1A; Sun, 24 Jan 2010 00:45:52 -0500 (EST) Received: from rmtodd by servalan.servalan.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NYurF-0004Cs-KN; Sat, 23 Jan 2010 23:18:11 -0600 To: Alexander Logvinov , freebsd-current@freebsd.org References: <20100124024214.GA49252@Fluffy.Khv.RU> <4B5BC039.5060406@logvinov.com> From: Richard Todd Date: Sat, 23 Jan 2010 23:17:54 -0600 In-Reply-To: (Alexander Logvinov's message of "Sun, 24 Jan 2010 11:36:25 +0800") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.5-b28 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Subject: Re: Regression in -current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 05:45:53 -0000 Alexander Logvinov writes: > Hello! > > On 24.01.2010 10:43 Dima Panov wrote: >> I see a strange regression since Friday's kernel, may be it's a kqueue-related. >> While building ports, now I never see 100% load of cpu, and portupgrade -fa >> takes ~7 hours for ~40 ports. Updating to current state (~3am VLAT) doesn't help. >> >> KDB and WITNESS/INVARIANTS disablen in kernel config > I have a similar problem with r202904 amd64 kernel with interesting CPU > statistic: > > top output: > > last pid: 1885; load averages: 2.89, 1.56, 0.66 up 0+00:02:47 > 09:31:44 > 72 processes: 3 running, 69 sleeping > _CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle_ > Mem: 120M Active, 39M Inact, 153M Wired, 6968K Cache, 65M Buf, 3565M Free > Swap: 8192M Total, 8192M Free Yeah, I saw the same thing on my core2duo system (running in amd64 mode, dunno if that makes a difference.) Caused the system to go *really* slow when powerd started and decided that since CPU usage was 0.00% it could safely throttle the CPU all the way down midway thru all the rc.d/* stuff executing. :-) As near as I can tell, the culprit is this rev (and the SVN #s you quote are consistent with this being the case): SVN rev 202387 on 2010-01-15 16:04:30Z by attilio Handling all the three clocks (hardclock, softclock, profclock) with the LAPIC may lead to aliasing for softclock and profclock because frequencies are sized in order to fit mainly hardclock. atrtc used to take care of the softclock and profclock and it does still do, if the LAPIC can't handle the clocks properly. Revert the change when the LAPIC started taking charge of all three of them and let atrtc handle softclock and profclock if not explicitly requested. Such request can be made setting != 0 the new tunable machdep.lapic_allclocks or if the new device ATPIC is not present within the i386 kernel config (atrtc is linked to atpic presence). As a check, my current post-rev-202387 kernel has working clock if I boot with machdep.lapic_allclocks=1 in loader.conf, and doesn't if I leave that out, so that pretty conclusively points to those changes. From owner-freebsd-current@FreeBSD.ORG Sun Jan 24 07:09:37 2010 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 405EB1065672 for ; Sun, 24 Jan 2010 07:09:37 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.freebsd.org (Postfix) with ESMTP id C48008FC14 for ; Sun, 24 Jan 2010 07:09:36 +0000 (UTC) Received: (qmail 23037 invoked by uid 399); 24 Jan 2010 07:09:36 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 24 Jan 2010 07:09:36 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4B5BF236.1030801@FreeBSD.org> Date: Sat, 23 Jan 2010 23:09:42 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.7) Gecko/20100123 Thunderbird/3.0.1 MIME-Version: 1.0 To: Kostik Belousov References: <4B595D56.8030408@omnilan.de> <86d412gxxa.fsf@ds4.des.no> <20100122120856.GD59590@deviant.kiev.zoral.com.ua> In-Reply-To: <20100122120856.GD59590@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 1.0 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Dag-Erling Sm??rgrav , freebsd-current@freebsd.org, Harald Schmalzbauer Subject: Re: single (debug) binaries from base source tree install fails (/usr/bin/true) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jan 2010 07:09:37 -0000 On 01/22/10 04:08, Kostik Belousov wrote: > On Fri, Jan 22, 2010 at 12:51:29PM +0100, Dag-Erling Sm??rgrav wrote: >> Harald Schmalzbauer writes: >>> I try to install a DEBUG_FLAGS=-g version of top since it core dumps >>> on my 8.0-RELEASE box. >> >> How? >> >>> Compiling works with warnings, but installing fails with superfluous >>> "/usr/bin/true" after install: >>> >>> install /usr/bin/true -o root -g wheel -m 555 top /usr/bin >>> install: -o: No such file or director >> >> You screwed up somewhere... built in the wrong directory or something. >> The correct procedure is simply: >> >> % cd /usr/src/usr.bin/top >> % make clean >> % make DEBUG_FLAGS=-g >> % make install > > make install shall be done with DEBUG_FLAGS=-g too, otherwise installed > binary will be stripped. Also you probably want to do cleandir, obj, and depend steps as well. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso From owner-freebsd-current@FreeBSD.ORG Sun Jan 24 09:05:16 2010 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 1291F106566C; Sun, 24 Jan 2010 09:05:16 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from asuka.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id BB9BA8FC12; Sun, 24 Jan 2010 09:05:15 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=CRAM-MD5 bits=0) by asuka.mahoroba.org (8.14.3/8.14.3) with ESMTP/inet6 id o0O95ArS030377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Jan 2010 18:05:10 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 24 Jan 2010 18:05:09 +0900 Message-ID: From: Hajimu UMEMOTO To: Gabor Kovesdan In-Reply-To: <4B5B515C.9000109@FreeBSD.org> References: <20100119212019.GL59590@deviant.kiev.zoral.com.ua> <4B56CACF.50508@FreeBSD.org> <20100123193834.GM59590@deviant.kiev.zoral.com.ua> <4B5B515C.9000109@FreeBSD.org> User-Agent: xcite1.58> Wanderlust/2.15.7 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.7 Emacs/23.1 (i386-portbld-freebsd8.0) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.0-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=ISO-2022-JP-2 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (asuka.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sun, 24 Jan 2010 18:05:10 +0900 (JST) X-Virus-Scanned: clamav-milter 0.95.3 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on asuka.mahoroba.org Cc: Kostik Belousov , attilio@FreeBSD.org, current@FreeBSD.org Subject: Re: NLS/strerror efficiency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jan 2010 09:05:16 -0000 Hi, >>>>> On Sat, 23 Jan 2010 20:43:24 +0100 >>>>> Gabor Kovesdan said: gabor> El 2010. 01. 23. 20:38, Kostik Belousov escribi$(D+Q(B: > Wouldn't this cause the locale for error strings to be fixated at the > time of the first strerror/gai_strerror call ? > > Current code, despite it inefficiency, allow dynamic change of locale > that is reflected in strerror() output, I believe. Yes, you are right. I didn't notice the situation that locale might be changed dynamically. We need to save current locale to adapt to the situation. gabor> That's a good point. Imho, it should be cached in another static gabor> variable just like in my patch, where I should store it in another gabor> member of the struct. It seems difficult to save the current locale outside of the cat*(3) without race condition. We need to handle it inside of the cat*(3). Perhaps, your approach is correct. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-current@FreeBSD.ORG Sun Jan 24 09:19:19 2010 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 C7485106566B; Sun, 24 Jan 2010 09:19:19 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from mail34.syd.optusnet.com.au (mail34.syd.optusnet.com.au [211.29.133.218]) by mx1.freebsd.org (Postfix) with ESMTP id 4C61B8FC17; Sun, 24 Jan 2010 09:19:18 +0000 (UTC) Received: from server.vk2pj.dyndns.org (c122-106-232-148.belrs3.nsw.optusnet.com.au [122.106.232.148]) by mail34.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o0O9JGHA001633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Jan 2010 20:19:17 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.3/8.14.3) with ESMTP id o0O9JBtw018713; Sun, 24 Jan 2010 20:19:11 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.3/8.14.3/Submit) id o0O9JBr6018712; Sun, 24 Jan 2010 20:19:11 +1100 (EST) (envelope-from peter) Date: Sun, 24 Jan 2010 20:19:11 +1100 From: Peter Jeremy To: Gabor Kovesdan Message-ID: <20100124091911.GI31243@server.vk2pj.dyndns.org> References: <20100119212019.GL59590@deviant.kiev.zoral.com.ua> <4B56CACF.50508@FreeBSD.org> <4B5B4F4B.3030201@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SdaPbLtAangIkrMZ" Content-Disposition: inline In-Reply-To: <4B5B4F4B.3030201@FreeBSD.org> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Kostik Belousov , attilio@FreeBSD.org, Hajimu UMEMOTO , current@FreeBSD.org Subject: Re: NLS/strerror efficiency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jan 2010 09:19:19 -0000 --SdaPbLtAangIkrMZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2010-Jan-23 20:34:35 +0100, Gabor Kovesdan wrote: >I have a fix for msgcat.c to optimalize catalog handling. As I'm not an=20 >src committer, delphij@ is helping me in reviewing and approving my=20 >patches. I've sent the attached patch to him today and I'm waiting for=20 >his response now. This patch caches the failing and the succesful=20 >catopen() calls in a thread-safe way and in the latter case it counts=20 >references to cached catalog. I think this is a good start but still needs some work. One issue is that the patch mixes whitespace changes (some not complying with style(9)) and functional changes. This makes it harder to see the functional changes. On 2010-Jan-23 21:38:35 +0200, Kostik Belousov wrote: >Wouldn't this cause the locale for error strings to be fixated at the >time of the first strerror/gai_strerror call ? Yes. >Current code, despite it inefficiency, allow dynamic change of locale >that is reflected in strerror() output, I believe. How much of an issue is this in reality? There are two cases to consider: 1) A process that dynamically changes its locale. 2) Locale files being updated whilst the process is running. The first can be worked around by also caching the current locale and checking that it hasn't changed. The second is more problematic - particularly for long-running programs. Maybe add a timestamp and re-check every minute or 5. --=20 Peter Jeremy --SdaPbLtAangIkrMZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktcEI8ACgkQ/opHv/APuIfgdwCgwhA4UHUj3sq4hh8a7NW0etga hpoAoKKWdpMZOuMlXQeEtHtmLMsrxq6O =Mi+e -----END PGP SIGNATURE----- --SdaPbLtAangIkrMZ-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 24 10:58:15 2010 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 164701065670; Sun, 24 Jan 2010 10:58:15 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id BB9A88FC15; Sun, 24 Jan 2010 10:58:14 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 78CCC14DA36C; Sun, 24 Jan 2010 11:58:12 +0100 (CET) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iiFw-PQ6rvVA; Sun, 24 Jan 2010 11:58:02 +0100 (CET) Received: from [192.168.1.105] (catv-89-132-179-104.catv.broadband.hu [89.132.179.104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id A757D14DA313; Sun, 24 Jan 2010 11:58:02 +0100 (CET) Message-ID: <4B5C27B9.1080805@FreeBSD.org> Date: Sun, 24 Jan 2010 11:58:01 +0100 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; es-ES; rv:1.9.1.5) Gecko/20091204 Thunderbird/3.0 MIME-Version: 1.0 To: Peter Jeremy References: <20100119212019.GL59590@deviant.kiev.zoral.com.ua> <4B56CACF.50508@FreeBSD.org> <4B5B4F4B.3030201@FreeBSD.org> <20100124091911.GI31243@server.vk2pj.dyndns.org> In-Reply-To: <20100124091911.GI31243@server.vk2pj.dyndns.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: Kostik Belousov , attilio@FreeBSD.org, Hajimu UMEMOTO , current@FreeBSD.org Subject: Re: NLS/strerror efficiency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jan 2010 10:58:15 -0000 El 2010. 01. 24. 10:19, Peter Jeremy escribió: > I think this is a good start but still needs some work. One issue is > that the patch mixes whitespace changes (some not complying with > style(9)) and functional changes. This makes it harder to see the > functional changes. > I thought fixing up some style(9) nits was ok but I meant them to be compliant with style(9). Could you please point out, which are not compliant? Shall I revert the style(9) changes for now? > How much of an issue is this in reality? There are two cases to > consider: > 1) A process that dynamically changes its locale. > 2) Locale files being updated whilst the process is running. > > The first can be worked around by also caching the current locale > and checking that it hasn't changed. > I'll fix up my patch to do that. > The second is more problematic - particularly for long-running > programs. Maybe add a timestamp and re-check every minute or 5. > I agree, that it should track changing catalogs but do we really want that? Catalogs are usually bundled with third-party apps and if you update something you obviously want to restart that. And in the case of strerror(3), catalogs are supposed to be updated with libc and when you update libc you probably want to restart everything. -- Gabor Kovesdan FreeBSD Volunteer EMAIL: gabor@FreeBSD.org .:|:. gabor@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org From owner-freebsd-current@FreeBSD.ORG Sun Jan 24 11:37:28 2010 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 D312F106566B; Sun, 24 Jan 2010 11:37:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 4468A8FC0A; Sun, 24 Jan 2010 11:37:27 +0000 (UTC) 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 o0OBbIEe075353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Jan 2010 13:37:18 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.3/8.14.3) with ESMTP id o0OBbIe8009572; Sun, 24 Jan 2010 13:37:18 +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 o0OBbI1E009571; Sun, 24 Jan 2010 13:37:18 +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: Sun, 24 Jan 2010 13:37:18 +0200 From: Kostik Belousov To: Gabor Kovesdan Message-ID: <20100124113718.GC3877@deviant.kiev.zoral.com.ua> References: <20100119212019.GL59590@deviant.kiev.zoral.com.ua> <4B56CACF.50508@FreeBSD.org> <4B5B4F4B.3030201@FreeBSD.org> <20100124091911.GI31243@server.vk2pj.dyndns.org> <4B5C27B9.1080805@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="w7PDEPdKQumQfZlR" Content-Disposition: inline In-Reply-To: <4B5C27B9.1080805@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at 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 Cc: attilio@freebsd.org, Hajimu UMEMOTO , Peter Jeremy , current@freebsd.org Subject: Re: NLS/strerror efficiency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jan 2010 11:37:29 -0000 --w7PDEPdKQumQfZlR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 24, 2010 at 11:58:01AM +0100, Gabor Kovesdan wrote: > El 2010. 01. 24. 10:19, Peter Jeremy escribi?: > >I think this is a good start but still needs some work. One issue is > >that the patch mixes whitespace changes (some not complying with > >style(9)) and functional changes. This makes it harder to see the > >functional changes. > > =20 > I thought fixing up some style(9) nits was ok but I meant them to be=20 > compliant with style(9). Could you please point out, which are not=20 > compliant? Shall I revert the style(9) changes for now? > >How much of an issue is this in reality? There are two cases to > >consider: > >1) A process that dynamically changes its locale. > >2) Locale files being updated whilst the process is running. > > > >The first can be worked around by also caching the current locale > >and checking that it hasn't changed. > > =20 > I'll fix up my patch to do that. > >The second is more problematic - particularly for long-running > >programs. Maybe add a timestamp and re-check every minute or 5. > > =20 > I agree, that it should track changing catalogs but do we really want=20 > that? Catalogs are usually bundled with third-party apps and if you=20 > update something you obviously want to restart that. And in the case of= =20 > strerror(3), catalogs are supposed to be updated with libc and when you= =20 > update libc you probably want to restart everything. I do not think that this ought to be handled. Dynamic locale change, on the other hand, is something I have actually seen. --w7PDEPdKQumQfZlR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktcMO0ACgkQC3+MBN1Mb4gt8QCeMbX51g0RDUOWduLTJv990M9z AckAoIFckJbaGZ+233pTd/STtcUGCepu =WGGN -----END PGP SIGNATURE----- --w7PDEPdKQumQfZlR-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 24 14:58:14 2010 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 8D415106566C; Sun, 24 Jan 2010 14:58:14 +0000 (UTC) (envelope-from lobo@bsd.com.br) Received: from mail-yw0-f197.google.com (mail-yw0-f197.google.com [209.85.211.197]) by mx1.freebsd.org (Postfix) with ESMTP id AFDDA8FC39; Sun, 24 Jan 2010 14:58:13 +0000 (UTC) Received: by ywh35 with SMTP id 35so2123755ywh.7 for ; Sun, 24 Jan 2010 06:58:12 -0800 (PST) Received: by 10.150.118.11 with SMTP id q11mr7046276ybc.40.1264345090694; Sun, 24 Jan 2010 06:58:10 -0800 (PST) Received: from papi.localnet ([187.78.195.154]) by mx.google.com with ESMTPS id 20sm1334254yxe.2.2010.01.24.06.57.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 24 Jan 2010 06:58:07 -0800 (PST) To: freebsd-current@freebsd.org From: Mario Lobo Date: Sun, 24 Jan 2010 12:01:31 -0300 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_LDGXL2yksVavkys" Message-Id: <201001241201.31892.lobo@bsd.com.br> X-Mailman-Approved-At: Sun, 24 Jan 2010 15:30:48 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-emulation@freebsd.org Subject: Re: JFYI: VirtualBox stable/unstable setteings +nvidia amd64 (3.1.2 OSE - GOOD NEWS) - The freeze is GONE ! [was: JFYI: VirtualBox stable/unstable setteings (3.0.51.r22902)] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jan 2010 14:58:14 -0000 --Boundary-00=_LDGXL2yksVavkys Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit On Wednesday 23 December 2009 02:29:33 Daichi GOTO wrote: >> In a month, I have been tried to investigate FreeBSD system >> stable/unstable situations and factors around VirtualBox >> bacause frequently my VirtualBox let FreeBSD freeze, panic >> and fatal trap. [Snip.] > What I have found out in all the time I've been testing is that, at least on > my system here, the problem with VBox/Nvidia IS definitely with OpenGL. > If I leave the KDE composite option as XRENDER, I can open up to 6 VMs > without any freeze. All of them with 2 CPUs, 3D accel enabled an all. But > all I need to do to freeze the machine is to start ANY OpenGL app and let it > run for about a minute. It can even be one of the GL screensavers. It is a > guarantied freeze ! > I have tried all sorts of combinations: nvidia.ko last, vboxdrv.ko last, no > linux.ko, with powerd, no powerd, etc..., etc... No matter what, if it > involves OpenGL, bang !! if it doesn't, it's OK. Sorry for the long subject !. ------------------------------------------------------------------ Machine: OS: FreeBSD 8.0-STABLE #0 r198930M: Sat Dec 12 12:49:49 BRT 2009 MB: AOD790GX/128M VB: nvidia0: on vgapci0 RAM: 8 G CPU: Phenom 955 black (II) Module nvidia: vendor="NVIDIA Corporation" compiled for 4.0.2, module version = 1.0.0 Module class: X.Org Video Driver (II) NVIDIA dlloader X Driver 195.22 Mon Nov 30 14:03:12 posix/SystemV/PST 2009 (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs X: X.Org X Server 1.6.1 KDE: 4.3.4 with OpenGl composite enabled VBOX: 3.1.2 OSE ------------------------------------------------------------------ Stability is back!. No more host freezes ! I found out that compiling the nvidia driver WITHOUT the linux_emulation option did it! The instability and freeze issue with vbox+openGL active is GONE! As you can see on attached image, I have started: 2 XP 1 Win7 32 1 Win7 64 2 Win 2003 1 Fedora Plus a few other kde apps. Before doing this, if I started only one of the win7 VM, my host would freeze!. -- Mario Lobo http://www.mallavoodoo.com.br FreeBSD since version 2.2.8 [not Pro-Audio.... YET!!] (99,7% winfoes FREE) --Boundary-00=_LDGXL2yksVavkys-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 24 16:08:14 2010 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 44E31106568B for ; Sun, 24 Jan 2010 16:08:14 +0000 (UTC) (envelope-from avl@logvinov.com) Received: from mail-pz0-f202.google.com (mail-pz0-f202.google.com [209.85.222.202]) by mx1.freebsd.org (Postfix) with ESMTP id 223838FC18 for ; Sun, 24 Jan 2010 16:08:13 +0000 (UTC) Received: by pzk40 with SMTP id 40so132651pzk.7 for ; Sun, 24 Jan 2010 08:08:13 -0800 (PST) Received: by 10.143.27.1 with SMTP id e1mr2118569wfj.291.1264349293527; Sun, 24 Jan 2010 08:08:13 -0800 (PST) Received: from incubus.bsd ([125.34.35.20]) by mx.google.com with ESMTPS id 21sm4149867pzk.7.2010.01.24.08.08.10 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Jan 2010 08:08:12 -0800 (PST) Message-ID: <4B5C709D.2070707@logvinov.com> Date: Mon, 25 Jan 2010 00:09:01 +0800 From: Alexander Logvinov User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.9.1.7) Gecko/20100122 Thunderbird/3.0.1 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Richard Todd References: <20100124024214.GA49252@Fluffy.Khv.RU> <4B5BC039.5060406@logvinov.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Regression in -current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 16:08:14 -0000 Hello! On 24.01.2010 13:17 Richard Todd wrote: >> I have a similar problem with r202904 amd64 kernel with interesting CPU >> statistic: >> _CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle_ >> Mem: 120M Active, 39M Inact, 153M Wired, 6968K Cache, 65M Buf, 3565M Free >> Swap: 8192M Total, 8192M Free > SVN rev 202387 on 2010-01-15 16:04:30Z by attilio > As a check, my current post-rev-202387 kernel has working clock if I boot with > machdep.lapic_allclocks=1 > in loader.conf, and doesn't if I leave that out, so that pretty conclusively > points to those changes. Yes, it fixed the problem. Thanks! -- Best regards, Alexander From owner-freebsd-current@FreeBSD.ORG Sun Jan 24 16:29:18 2010 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 651061065672 for ; Sun, 24 Jan 2010 16:29:18 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f200.google.com (mail-iw0-f200.google.com [209.85.223.200]) by mx1.freebsd.org (Postfix) with ESMTP id 278988FC17 for ; Sun, 24 Jan 2010 16:29:18 +0000 (UTC) Received: by mail-iw0-f200.google.com with SMTP id 38so2332432iwn.11 for ; Sun, 24 Jan 2010 08:29:18 -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=jKEbx4OUN9c7wNmSkyV5KARW9UP8c1pwm9eEf02ngnY=; b=DVQc/52XtuhBIrxYM7tfMzab+htYiu4mMNRYSinADHtx+eqDRjkd/POJ8qeYNrUhrf tiZjBM7IxqUTEdDSA59cGwYNKtLU5rl4v8kP2Zy6RT4RkyKiKCEmTabCg8jspfa0Z/X9 MZ2vKZqxEehIn90k3yl9C+i63hsU7mvkPZ5Ys= 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=R9BFvYrpQ9aQj3xWFHaKCt1aOGFYeW2b5vI/TDPiWZ+tOqj+M6yk5mw5RvcBA95PR6 4dF/Qgdf9o3NG27Qp7wxfnZKKyGwCgkG1gtXXea3bARx89CbYeJKAXIBVM8cxYYfryVO ok59h7OULGNj3W3wGvaRD66RcDVaHB4aRkmEc= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.59.7 with SMTP id j7mr676647ibh.12.1264350557286; Sun, 24 Jan 2010 08:29:17 -0800 (PST) In-Reply-To: References: <20100124024214.GA49252@Fluffy.Khv.RU> <4B5BC039.5060406@logvinov.com> Date: Sun, 24 Jan 2010 17:29:17 +0100 X-Google-Sender-Auth: 16474e0be0ef8c6b Message-ID: <3bbf2fe11001240829k46d62476pda54d149c39ae7c3@mail.gmail.com> From: Attilio Rao To: Richard Todd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: fluffy@fluffy.khv.ru, freebsd-current@freebsd.org, Alexander Logvinov Subject: Re: Regression in -current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 16:29:18 -0000 2010/1/24 Richard Todd : > Alexander Logvinov writes: > >> Hello! >> >> On 24.01.2010 10:43 Dima Panov wrote: >>> I see a strange regression since Friday's kernel, may be it's a kqueue-= related. >>> While building ports, now I never see 100% load of cpu, and portupgrade= -fa >>> takes ~7 hours for ~40 ports. Updating to current state (~3am VLAT) doe= sn't help. >>> >>> KDB and WITNESS/INVARIANTS disablen in kernel config > >> =C2=A0I have a similar problem with r202904 amd64 kernel with interestin= g CPU >> statistic: >> >> top output: >> >> last pid: =C2=A01885; =C2=A0load averages: =C2=A02.89, =C2=A01.56, =C2= =A00.66 =C2=A0 =C2=A0up 0+00:02:47 >> 09:31:44 >> 72 processes: =C2=A03 running, 69 sleeping >> _CPU: =C2=A00.0% user, =C2=A00.0% nice, =C2=A00.0% system, =C2=A00.0% in= terrupt, =C2=A00.0% idle_ >> Mem: 120M Active, 39M Inact, 153M Wired, 6968K Cache, 65M Buf, 3565M Fre= e >> Swap: 8192M Total, 8192M Free > > Yeah, I saw the same thing on my core2duo system (running in amd64 mode, > dunno if that makes a difference.) =C2=A0Caused the system to go *really*= slow when > powerd started and decided that since CPU usage was 0.00% it could safely > throttle the CPU all the way down midway thru all the rc.d/* stuff > executing. :-) > > As near as I can tell, the culprit is this rev (and the SVN #s you quote > are consistent with this being the case): > > =C2=A0SVN rev 202387 on 2010-01-15 16:04:30Z by attilio > > =C2=A0Handling all the three clocks (hardclock, softclock, profclock) wit= h the > =C2=A0LAPIC may lead to aliasing for softclock and profclock because freq= uencies > =C2=A0are sized in order to fit mainly hardclock. > =C2=A0atrtc used to take care of the softclock and profclock and it does = still > =C2=A0do, if the LAPIC can't handle the clocks properly. > > =C2=A0Revert the change when the LAPIC started taking charge of all three= of > =C2=A0them and let atrtc handle softclock and profclock if not explicitly > =C2=A0requested. Such request can be made setting !=3D 0 the new tunable > =C2=A0machdep.lapic_allclocks or if the new device ATPIC is not present > =C2=A0within the i386 kernel config (atrtc is linked to atpic presence). > > As a check, my current post-rev-202387 kernel has working clock if I boot= with > > =C2=A0machdep.lapic_allclocks=3D1 Can you all please do: % sysctl kern.timecounter Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Sun Jan 24 16:49:15 2010 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 F37CB1065672; Sun, 24 Jan 2010 16:49:14 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 07B988FC17; Sun, 24 Jan 2010 16:49:13 +0000 (UTC) Received: by fxm26 with SMTP id 26so334084fxm.13 for ; Sun, 24 Jan 2010 08:49:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=CO/wPqQnCfpx5JrmnoT+31Rwv8hdZ1euih4gMI6S+WU=; b=lXrW9uQHEPTDEltBSwRoqmEFfg/WcsiZXFOY1RMYU1P5cUdXTC3BUpMcggTrHhuvFh LiJ84/Vzb+NUiFGFH9UTn2bVfee64J+gcjBVzGtZ5eT4fMIfA92xNYe5csB8hoQ0oOcC Svac1k9LqY8zzKXcULo5jAkc+SmYQNWb0W9o0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=nebP95A5xsak88y9d99hJyl5iiFmXb/IPMofub/E4lthItXXW93dpKjgCl0ZM1Xqwl /qHsB3woKwYxFc4i1VJ9qvJkWUSWCk9WjC1veT/HJjGFBLozw/AsVEbJ5cx0s42Mnm/q S+Bi4f4dXFbHwg1iihR0xmSM66MxwnW2P+XBE= Received: by 10.223.59.3 with SMTP id j3mr98510fah.46.1264351752927; Sun, 24 Jan 2010 08:49:12 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm2297269fxm.2.2010.01.24.08.49.11 (version=SSLv3 cipher=RC4-MD5); Sun, 24 Jan 2010 08:49:11 -0800 (PST) Sender: Alexander Motin Message-ID: <4B5C79CF.9070504@FreeBSD.org> Date: Sun, 24 Jan 2010 18:48:15 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: gary.jennejohn@freenet.de References: <4B55D9D4.1000008@FreeBSD.org> <201001231407.o0NE7l8j002620@triton8.kn-bremen.de> <20100123184619.257203d9@ernst.jennejohn.org> In-Reply-To: <20100123184619.257203d9@ernst.jennejohn.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , FreeBSD Stable , Juergen Lock Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jan 2010 16:49:15 -0000 Gary Jennejohn wrote: > I started seeing a problem a few days ago with one of my DVD drives (a > burner at cd0) under 9-current, which makes it impossible to use it even > to simply read a DVD. > > Here the (rather strange IMO) output in dmesg: > > cd0: Removable CD-ROM SCSI-0 device > cd0: 66.700MB/s transfers (UDMA4, PIO size 65534bytes) > cd0: Attempt to query device size failed: UNIT ATTENTION, Power on, reset, > or bus device reset occurred > cd1 at ata0 bus 0 scbus6 target 1 lun 0 > cd1: Removable CD-ROM SCSI-0 device > cd1: 33.300MB/s transfers (UDMA2, PIO size 65534bytes) > cd1: Attempt to query device size failed: NOT READY, Medium not present - > tray closed > > I haven't the foggiest why cd0 behaves diffrently from cd1, which is a > vanilla DVD drive and just works. I am not sure yet what triggered these changes. May be just some timing issue. That UNIT ATTENTION seems reasonable, as reset indeed just happened there. The real problem is that CAM had several limitations in SCSI status handling, when working with ATAPI or USB devices. It made request processing stop in some cases, where retries would be expected. New patch version should handle this and some other problems: http://people.freebsd.org/~mav/cam-ata.20100124.patch Try it please. Thanks. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sun Jan 24 17:54:40 2010 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 97BF81065670; Sun, 24 Jan 2010 17:54:40 +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 2896F8FC0C; Sun, 24 Jan 2010 17:54:40 +0000 (UTC) Received: from [195.4.92.15] (helo=5.mx.freenet.de) by mout5.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NZ6fW-0001q6-Tt; Sun, 24 Jan 2010 18:54:38 +0100 Received: from p57ae25fd.dip0.t-ipconnect.de ([87.174.37.253]:32268 helo=ernst.jennejohn.org) by 5.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1NZ6fW-0000xk-Mo; Sun, 24 Jan 2010 18:54:38 +0100 Date: Sun, 24 Jan 2010 18:54:35 +0100 From: Gary Jennejohn To: Alexander Motin Message-ID: <20100124185435.54b5fef6@ernst.jennejohn.org> In-Reply-To: <4B5C79CF.9070504@FreeBSD.org> References: <4B55D9D4.1000008@FreeBSD.org> <201001231407.o0NE7l8j002620@triton8.kn-bremen.de> <20100123184619.257203d9@ernst.jennejohn.org> <4B5C79CF.9070504@FreeBSD.org> X-Mailer: Claws Mail 3.7.4 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current , FreeBSD Stable , Juergen Lock Subject: Re: Pack of CAM improvements 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, 24 Jan 2010 17:54:40 -0000 On Sun, 24 Jan 2010 18:48:15 +0200 Alexander Motin wrote: > Gary Jennejohn wrote: > > I started seeing a problem a few days ago with one of my DVD drives (a > > burner at cd0) under 9-current, which makes it impossible to use it even > > to simply read a DVD. > > > > Here the (rather strange IMO) output in dmesg: > > > > cd0: Removable CD-ROM SCSI-0 device > > cd0: 66.700MB/s transfers (UDMA4, PIO size 65534bytes) > > cd0: Attempt to query device size failed: UNIT ATTENTION, Power on, reset, > > or bus device reset occurred > > cd1 at ata0 bus 0 scbus6 target 1 lun 0 > > cd1: Removable CD-ROM SCSI-0 device > > cd1: 33.300MB/s transfers (UDMA2, PIO size 65534bytes) > > cd1: Attempt to query device size failed: NOT READY, Medium not present - > > tray closed > > > > I haven't the foggiest why cd0 behaves diffrently from cd1, which is a > > vanilla DVD drive and just works. > > I am not sure yet what triggered these changes. May be just some timing > issue. That UNIT ATTENTION seems reasonable, as reset indeed just > happened there. The real problem is that CAM had several limitations in > SCSI status handling, when working with ATAPI or USB devices. It made > request processing stop in some cases, where retries would be expected. > > New patch version should handle this and some other problems: > http://people.freebsd.org/~mav/cam-ata.20100124.patch > > Try it please. Thanks. > This patch works extremely well! Thanks. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Sun Jan 24 20:16:03 2010 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 53104106568D for ; Sun, 24 Jan 2010 20:16:03 +0000 (UTC) (envelope-from rmtodd@servalan.servalan.com) Received: from mx1.synetsystems.com (mx1.synetsystems.com [76.10.206.14]) by mx1.freebsd.org (Postfix) with ESMTP id 28E2A8FC12 for ; Sun, 24 Jan 2010 20:16:02 +0000 (UTC) Received: by mx1.synetsystems.com (Postfix, from userid 66) id D5A96E37; Sun, 24 Jan 2010 14:45:48 -0500 (EST) Received: from rmtodd by servalan.servalan.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NZ7hz-00043w-OH; Sun, 24 Jan 2010 13:01:23 -0600 Date: Sun, 24 Jan 2010 13:01:15 -0600 From: Richard Todd To: Attilio Rao Message-ID: <20100124190115.GA15079@ichotolot.servalan.com> References: <20100124024214.GA49252@Fluffy.Khv.RU> <4B5BC039.5060406@logvinov.com> <3bbf2fe11001240829k46d62476pda54d149c39ae7c3@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3bbf2fe11001240829k46d62476pda54d149c39ae7c3@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: Regression in -current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2010 20:16:03 -0000 On Sun, Jan 24, 2010 at 05:29:17PM +0100, Attilio Rao wrote: > > Can you all please do: > > % sysctl kern.timecounter > > Thanks, > Attilio >From the "bad" case: (machdep.lapic_allclocks=0): kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-1000000) kern.timecounter.hardware: ACPI-fast kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 43003 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 11430002 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 1000 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 3399320019 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 900 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 2591427657 kern.timecounter.tc.TSC.frequency: 2397618396 kern.timecounter.tc.TSC.quality: -100 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 1 kern.clockrate: { hz = 300, tick = 3333, profhz = 300, stathz = 150 } and the good case: (lapic_allclocks=1, CPU accounting working properly) kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-1000000) kern.timecounter.hardware: ACPI-fast kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 16871 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 2589325 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 1000 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 2021776154 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 900 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 3848116053 kern.timecounter.tc.TSC.frequency: 2397620511 kern.timecounter.tc.TSC.quality: -100 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 1 kern.clockrate: { hz = 300, tick = 3333, profhz = 1200, stathz = 133 } From owner-freebsd-current@FreeBSD.ORG Sun Jan 24 22:32:57 2010 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 658DD106568F; Sun, 24 Jan 2010 22:32:57 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id F35C88FC0A; Sun, 24 Jan 2010 22:32:56 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 991BE14DA381; Sun, 24 Jan 2010 23:32:54 +0100 (CET) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id QNAIAx5BD60n; Sun, 24 Jan 2010 23:32:44 +0100 (CET) Received: from [192.168.1.121] (catv-89-132-179-104.catv.broadband.hu [89.132.179.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 9DEB914DA37F; Sun, 24 Jan 2010 23:32:44 +0100 (CET) Message-ID: <4B5CD916.1060003@FreeBSD.org> Date: Mon, 25 Jan 2010 00:34:46 +0100 From: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= User-Agent: Thunderbird 2.0.0.21 (X11/20090516) MIME-Version: 1.0 To: Kostik Belousov References: <20100119212019.GL59590@deviant.kiev.zoral.com.ua> <4B56CACF.50508@FreeBSD.org> <4B5B4F4B.3030201@FreeBSD.org> <20100124091911.GI31243@server.vk2pj.dyndns.org> <4B5C27B9.1080805@FreeBSD.org> <20100124113718.GC3877@deviant.kiev.zoral.com.ua> In-Reply-To: <20100124113718.GC3877@deviant.kiev.zoral.com.ua> Content-Type: multipart/mixed; boundary="------------060809070007000604060304" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: attilio@freebsd.org, Xin LI , Hajimu UMEMOTO , Peter Jeremy , current@freebsd.org Subject: Re: NLS/strerror efficiency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Jan 2010 22:32:57 -0000 This is a multi-part message in MIME format. --------------060809070007000604060304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kostik Belousov wrote: >> I'll fix up my patch to do that. >> Here's my new patch with a little program to demonstrate that it works as expected even if locale is changed between various strerror(3)/strsignal(3) calls. Gabor --------------060809070007000604060304 Content-Type: text/x-patch; name="msgcat.c.diff" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="msgcat.c.diff" Index: nls/msgcat.c =================================================================== --- nls/msgcat.c (revisión: 202658) +++ nls/msgcat.c (copia de trabajo) @@ -1,5 +1,6 @@ /*********************************************************** Copyright 1990, by Alfalfa Software Incorporated, Cambridge, Massachusetts. +Copyright 2010, Gabor Kovesdan All Rights Reserved @@ -39,6 +40,7 @@ #include #include #include +#include #include /* for ntohl() */ @@ -47,6 +49,7 @@ #include #include #include +#include #include #include #include @@ -57,38 +60,94 @@ #define _DEFAULT_NLS_PATH "/usr/share/nls/%L/%N.cat:/usr/share/nls/%N/%L:/usr/local/share/nls/%L/%N.cat:/usr/local/share/nls/%N/%L" +#define RLOCK(fail) { if (_pthread_rwlock_rdlock(&rwlock) != 0) return (fail); } +#define WLOCK(fail) { if (_pthread_rwlock_wrlock(&rwlock) != 0) return (fail); } +#define UNLOCK(fail) { if (_pthread_rwlock_unlock(&rwlock) != 0) return (fail); } + #define NLERR ((nl_catd) -1) #define NLRETERR(errc) { errno = errc; return (NLERR); } +#define SAVEFAIL(n, e) { WLOCK(NLERR); \ + np = malloc(sizeof(struct catentry)); \ + if (np != NULL) { \ + np->name = strdup(n); \ + np->caterrno = e; \ + SLIST_INSERT_HEAD(&flist, np, list); \ + } \ + UNLOCK(NLERR); \ + } -static nl_catd load_msgcat(const char *); +static nl_catd load_msgcat(const char *, const char *, const char *); +static pthread_rwlock_t rwlock; + +struct catentry { + SLIST_ENTRY(catentry) list; + char *name; + char *path; + int caterrno; + nl_catd catd; + char *lang; + int refcount; +}; + +SLIST_HEAD(listhead, catentry) flist = + SLIST_HEAD_INITIALIZER(flist); + nl_catd catopen(const char *name, int type) { - int spcleft, saverr; - char path[PATH_MAX]; - char *nlspath, *lang, *base, *cptr, *pathP, *tmpptr; - char *cptr1, *plang, *pter, *pcode; - struct stat sbuf; + int spcleft, saverr; + char path[PATH_MAX]; + char *nlspath, *lang, *base, *cptr, *pathP, *tmpptr; + char *cptr1, *plang, *pter, *pcode; + struct stat sbuf; + struct catentry *np; if (name == NULL || *name == '\0') NLRETERR(EINVAL); - /* is it absolute path ? if yes, load immediately */ if (strchr(name, '/') != NULL) - return (load_msgcat(name)); + lang = NULL; + else { + if (type == NL_CAT_LOCALE) + lang = setlocale(LC_MESSAGES, NULL); + else + lang = getenv("LANG"); - if (type == NL_CAT_LOCALE) - lang = setlocale(LC_MESSAGES, NULL); - else - lang = getenv("LANG"); + if (lang == NULL || *lang == '\0' || strlen(lang) > ENCODING_LEN || + (lang[0] == '.' && + (lang[1] == '\0' || (lang[1] == '.' && lang[2] == '\0'))) || + strchr(lang, '/') != NULL) + lang = "C"; + } - if (lang == NULL || *lang == '\0' || strlen(lang) > ENCODING_LEN || - (lang[0] == '.' && - (lang[1] == '\0' || (lang[1] == '.' && lang[2] == '\0'))) || - strchr(lang, '/') != NULL) - lang = "C"; + /* Init rwlock used to protect cache */ + if ((rwlock == (pthread_rwlock_t)0) && + (_pthread_rwlock_init(&rwlock, NULL) != 0)) + return (NLERR); + /* Try to get it from the cache first */ + RLOCK(NLERR); + SLIST_FOREACH(np, &flist, list) { + if (strcmp(np->name, name) == 0) { + if (np->caterrno != 0) { + /* Found cached failing entry */ + UNLOCK(NLERR); + NLRETERR(np->caterrno); + } else if (strcmp(np->lang, lang) == 0) { + /* Found cached successful entry */ + np->refcount++; + UNLOCK(NLERR); + return (np->catd); + } + } + } + UNLOCK(NLERR); + + /* is it absolute path ? if yes, load immediately */ + if (strchr(name, '/') != NULL) + return (load_msgcat(name, name, lang)); + if ((plang = cptr1 = strdup(lang)) == NULL) return (NLERR); if ((cptr = strchr(cptr1, '@')) != NULL) @@ -166,7 +225,7 @@ if (stat(path, &sbuf) == 0) { free(plang); free(base); - return (load_msgcat(path)); + return (load_msgcat(path, name, lang)); } } else { tmpptr = (char *)name; @@ -182,20 +241,20 @@ char * catgets(nl_catd catd, int set_id, int msg_id, const char *s) { - struct _nls_cat_hdr *cat_hdr; - struct _nls_set_hdr *set_hdr; - struct _nls_msg_hdr *msg_hdr; - int l, u, i, r; + struct _nls_cat_hdr *cat_hdr; + struct _nls_set_hdr *set_hdr; + struct _nls_msg_hdr *msg_hdr; + int l, u, i, r; if (catd == NULL || catd == NLERR) { errno = EBADF; /* LINTED interface problem */ - return (char *) s; -} + return ((char *)s); + } cat_hdr = (struct _nls_cat_hdr *)catd->__data; set_hdr = (struct _nls_set_hdr *)(void *)((char *)catd->__data - + sizeof(struct _nls_cat_hdr)); + + sizeof(struct _nls_cat_hdr)); /* binary search, see knuth algorithm b */ l = 0; @@ -228,7 +287,7 @@ } else { l = i + 1; } -} + } /* not found */ goto notfound; @@ -238,25 +297,41 @@ } else { l = i + 1; } -} + } notfound: /* not found */ errno = ENOMSG; /* LINTED interface problem */ - return (char *) s; + return ((char *)s); } int catclose(nl_catd catd) { + struct catentry *np; + if (catd == NULL || catd == NLERR) { errno = EBADF; return (-1); } - munmap(catd->__data, (size_t)catd->__size); - free(catd); + /* Remove from cache if not referenced any more */ + WLOCK(-1); + SLIST_FOREACH(np, &flist, list) { + if ((np->catd->__size == catd->__size) && + memcmp((const void *)np->catd, (const void *)catd, np->catd->__size) == 0) { + np->refcount--; + if (np->refcount == 0) { + munmap(catd->__data, (size_t)catd->__size); + free(catd); + SLIST_REMOVE(&flist, np, catentry, list); + free(np); + } + break; + } + } + UNLOCK(-1); return (0); } @@ -265,19 +340,38 @@ */ static nl_catd -load_msgcat(const char *path) +load_msgcat(const char *path, const char *name, const char *lang) { - struct stat st; - nl_catd catd; - void *data; - int fd; + struct stat st; + nl_catd catd; + struct catentry *np; + void *data; + int fd; - /* XXX: path != NULL? */ + if (path == NULL) { + errno = EINVAL; + return (NLERR); + } - if ((fd = _open(path, O_RDONLY)) == -1) + /* One more try in cache; if it was not found by name, + it might still be found by absolute path. */ + RLOCK(NLERR); + SLIST_FOREACH(np, &flist, list) { + if (strcmp(np->path, path) == 0) { + np->refcount++; + UNLOCK(NLERR); + return (np->catd); + } + } + UNLOCK(NLERR); + + if ((fd = _open(path, O_RDONLY)) == -1) { + SAVEFAIL(name, errno); return (NLERR); + } if (_fstat(fd, &st) != 0) { + SAVEFAIL(name, errno); _close(fd); return (NLERR); } @@ -286,22 +380,39 @@ (off_t)0); _close(fd); - if (data == MAP_FAILED) + if (data == MAP_FAILED) { + SAVEFAIL(name, errno); return (NLERR); + } if (ntohl((u_int32_t)((struct _nls_cat_hdr *)data)->__magic) != _NLS_MAGIC) { + SAVEFAIL(name, errno); munmap(data, (size_t)st.st_size); NLRETERR(EINVAL); } if ((catd = malloc(sizeof (*catd))) == NULL) { + SAVEFAIL(name, errno); munmap(data, (size_t)st.st_size); return (NLERR); } catd->__data = data; catd->__size = (int)st.st_size; + + /* Caching opened catalog */ + WLOCK(NLERR); + if ((np = malloc(sizeof(struct catentry))) != NULL) { + np->name = strdup(name); + np->path = strdup(path); + np->catd = catd; + np->lang = (lang == NULL) ? NULL : strdup(lang); + np->refcount = 1; + np->caterrno = 0; + SLIST_INSERT_HEAD(&flist, np, list); + } + UNLOCK(NLERR); return (catd); } --------------060809070007000604060304-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 25 00:59:33 2010 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 F098D106566B for ; Mon, 25 Jan 2010 00:59:32 +0000 (UTC) (envelope-from inurneck@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by mx1.freebsd.org (Postfix) with ESMTP id 8909C8FC1E for ; Mon, 25 Jan 2010 00:59:32 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e21so4646fga.13 for ; Sun, 24 Jan 2010 16:59:31 -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; bh=hZU/APIuRs6GB9yYqw2S+Db4nQQblFfv42Xd8OYp2Q0=; b=r03z1Ne8OMRpL1YumXlgQfHO16Oju0DDU5TkXuWLZy7vOSeOIp3KV03jbKkkMScmCA kAcf3K1fZ9RHIAGW3WnMY6tdE9QVtEXnWCgAUAPrMqPUlajBItiuV6hgws5olc/xlt2A gxEV37+/g8LU4WQc7rJY8EjythilbQ2oy2fvQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=VZT9iXkuR9Gjvdx31TFEY/BeFFlG3oySkBREKArJ/wmb+ng0q5iYQSg9qbYiWHqbGW JZnbVzxy4dzVFSs0eoFb90h49ivH3U5TjqssWDc99+XZDMfRdEIiPh0URcMNffvhdkgN 9iIYpzc0f7PC4z04oYWQTDIHDjOfedBw9o0uU= MIME-Version: 1.0 Received: by 10.103.126.23 with SMTP id d23mr3019875mun.104.1264379315806; Sun, 24 Jan 2010 16:28:35 -0800 (PST) Date: Sun, 24 Jan 2010 19:28:35 -0500 Message-ID: <79b166921001241628g20372cc4xcd647745e0492e7c@mail.gmail.com> From: inurneck To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Dell poweredge 2400 floppy drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 00:59:33 -0000 Hello, I Can't seem to get my floppy recognized by the kernel. It is in fact a stripped kernel, I previously took a lot of things out of it, but i have added all I believe I need. The system sees the controller but never probes for an actual drive. I *re*added the options # Floppy drive. device atapifd # For floppy support. device eisa # For floppy support. device ata # For floppy support. device fdc # Floppy drive controller. If I read correctly rthat's what the handbook said was needed. but when the system boots all I get is > [142]daemon[/daemon/kernel]: dmesg | grep fdc fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FILTER] [143]daemon[/daemon/kernel]: And in dev all I see relevant is the directory structure: fd>0>1>2 I'd appreciate your help, what is the minimum things I need in my kernel config for it to see the floppy, and if I already do have them, why isn't it probing for it? Lastly what can I do to debug this? I am not one to ask questions I usually google, and did but all I seem to be getting is irrelevant information about installation from floppies. Thank you so much. From owner-freebsd-current@FreeBSD.ORG Mon Jan 25 03:08:42 2010 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 4CE9D1065672 for ; Mon, 25 Jan 2010 03:08:42 +0000 (UTC) (envelope-from inurneck@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id D9C938FC20 for ; Mon, 25 Jan 2010 03:08:41 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e12so15850fga.13 for ; Sun, 24 Jan 2010 19:08:40 -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; bh=qOSiEvxhrrkNCG4Yr1jFHZmJWyrNqepdimQt6G25TmM=; b=mCyOeDGUS2FjmDZeKvC3FDniA3RFhrmAIRwBwHgNll00QzNOhb6MghSW17xocDtPu3 nV3KlxMyLQLIhYCJeS/KGbuxxxWOc6jOY2lcyGKcsR7Jjz0JdhbaO3gdHwFKRAZESaEp N6KWEIvSBcwxZmaHu5jvz6DF2ZOZ5W+nNUE+c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=cKN+0x2YDPp6ussjEVaKQxLPDf0jSxWaNP4mrsUpzcM+lzeU1v8MmRYJZbcfRe1KGA b5uwS1Xz/0uMZsXeJIf0WlFnQzZ81HAME04Mt+UK2dIQGMMLjhPKFZF6FA+Ck11HLcVC jpm36EGJkTCTa6n83+8wi0VLRtFa4I+jqcd1U= MIME-Version: 1.0 Received: by 10.103.80.34 with SMTP id h34mr1381729mul.20.1264388920775; Sun, 24 Jan 2010 19:08:40 -0800 (PST) Date: Sun, 24 Jan 2010 22:08:40 -0500 Message-ID: <79b166921001241908p247f902cq5fe4b2ce301918f9@mail.gmail.com> From: inurneck To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: FD0 not recognized by kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jan 2010 03:08:42 -0000 Sorry for the noise, I created boot/device.hints and added hint.fd.0.at ="fdc0" And all works. No further assistance needed. But if you want to help me with my cat problem by all means.. http://forums.freebsd.org/showthread.php?p=64027#post64027 -- I am my only local user and I cannot be trusted. This is a bad thing. Good thing is, in FreeBSD where there is a shell there is a way. Over the years I've come to regard you as people I've met. I may be schizophrenic, but at least I have each other, and only when I am alone am I truly together. Hans reiser is still my hero. From owner-freebsd-current@FreeBSD.ORG Mon Jan 25 04:03:59 2010 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 435FE106566B for ; Mon, 25 Jan 2010 04:03:59 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-ew0-f211.google.com (mail-ew0-f211.google.com [209.85.219.211]) by mx1.freebsd.org (Postfix) with ESMTP id CDD9F8FC1F for ; Mon, 25 Jan 2010 04:03:58 +0000 (UTC) Received: by ewy3 with SMTP id 3so1975953ewy.13 for ; Sun, 24 Jan 2010 20:03:57 -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; bh=dU/c+M3e/Stb/s45V/jptQcVBN0Ovo8MLyL9yUNT2qQ=; b=F28D3Hy9T/8X8oScO0z8OKIVZmBsb52kwuz46QSSBJZJ4GKuR7xVAjE6A+H0fNYTic 71iq1en0qm3xYbQ6PpLk8gCLqZIwen3jUtKvYWtqIzQNQB1o8STamP6TAdAKIDYQZVJb 3AfZ+G6QVT+7DoqxFODa62UI+n/RbO6xm0BFo= 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; b=nG3BMhbJrLJuweE+LcnGj/chK70PLo2JfZom+AuCab2kBsDqPztUKvKIeClvR/SyHQ G724VHB1sAYM4zlUUfq7/EZDVzQdM1EWYyX8CRplfQPK1xh5j+3cfZwR6TulDy3fgrGh sBP0FNcbvzqNvHanpszIQlfeQiD5FbOt1ZGdE= MIME-Version: 1.0 Received: by 10.216.93.18 with SMTP id k18mr2245071wef.218.1264392237651; Sun, 24 Jan 2010 20:03:57 -0800 (PST) In-Reply-To: <79b166921001241628g20372cc4xcd647745e0492e7c@mail.gmail.com> References: <79b166921001241628g20372cc4xcd647745e0492e7c@mail.gmail.com> Date: Sun, 24 Jan 2010 23:03:57 -0500 Message-ID: <5f67a8c41001242003t3f4f6df3n7a3b1c1867154ceb@mail.gmail.com> From: Zaphod Beeblebrox To: inurneck Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: Dell poweredge 2400 floppy drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 04:03:59 -0000 On Sun, Jan 24, 2010 at 7:28 PM, inurneck wrote: > Hello, > I Can't seem to get my floppy recognized by the kernel. It is in fact a > stripped kernel, I previously took a lot of things out of it, but i have > added all I believe I need. The system sees the controller but never probes > for an actual drive. I *re*added the options > # Floppy drive. > device atapifd # For floppy support. > device eisa # For floppy support. > device ata # For floppy support. > device fdc # Floppy drive controller. > > > If I read correctly rthat's what the handbook said was needed. but when the > system boots all I get is > > > [142]daemon[/daemon/kernel]: dmesg | grep fdc > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: [FILTER] > [143]daemon[/daemon/kernel]: My first reaction: are you sure it's a regular floppy and not a USB device? Check to see if 'daX' shows up in /dev (where X is an integer). > And in dev all I see relevant is the directory structure: fd>0>1>2 > I'd appreciate your help, what is the minimum things I need in my kernel > config for it to see the floppy, and if I already do have them, why isn't it > probing for it? Lastly what can I do to debug this? I am not one to ask > questions I usually google, and did but all I seem to be getting is > irrelevant information about installation from floppies. Thank you so much. 'fd' is not floppy disk here. It's "file descriptor" ... /dev/fd/X is how you might access your own open file descriptors if you so desired. /dev/fd0 is not related to /dev/fd/0. From owner-freebsd-current@FreeBSD.ORG Mon Jan 25 07:37:25 2010 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 CFB8D106566C for ; Mon, 25 Jan 2010 07:37:25 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3146B8FC21 for ; Mon, 25 Jan 2010 07:37:24 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id o0P7Yeq6013115 for ; Mon, 25 Jan 2010 18:04:40 +1030 (CST) Received: from ednex510.dsto.defence.gov.au (ednex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.2) with ESMTP id for ; Mon, 25 Jan 2010 18:07:23 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by ednex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 18:07:23 +1030 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Mon, 25 Jan 2010 15:37:22 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id o0P7RUDi077708 for ; Mon, 25 Jan 2010 15:27:30 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id o0P7RU3R077707 for freebsd-current@freebsd.org; Mon, 25 Jan 2010 15:27:30 +0800 (WST) (envelope-from wilkinsa) Date: Mon, 25 Jan 2010 15:27:30 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20100125072730.GI76877@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <4B595D56.8030408@omnilan.de> <86d412gxxa.fsf@ds4.des.no> <20100122120856.GD59590@deviant.kiev.zoral.com.ua> <4B5BF236.1030801@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <4B5BF236.1030801@FreeBSD.org> Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 25 Jan 2010 07:37:22.0710 (UTC) FILETIME=[3B793B60:01CA9D91] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.000.1038-17152.005 X-TM-AS-Result: No--4.937600-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Subject: Re: single (debug) binaries from base source tree install fails (/usr/bin/true) [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jan 2010 07:37:25 -0000 0n Sat, Jan 23, 2010 at 11:09:42PM -0800, Doug Barton wrote: >> make install shall be done with DEBUG_FLAGS=-g too, otherwise installed >> binary will be stripped. > >Also you probably want to do cleandir, obj, and depend steps as well. Do each of these make targets also need "DEBUG_FLAGS=-g" ? -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Mon Jan 25 12:11:55 2010 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 B017D1065672 for ; Mon, 25 Jan 2010 12:11:55 +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 EC9E58FC1E for ; Mon, 25 Jan 2010 12:11:54 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA15329; Mon, 25 Jan 2010 14:11:52 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B5D8A87.6030701@icyb.net.ua> Date: Mon, 25 Jan 2010 14:11:51 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: current@freebsd.org References: <20100120162326.GD50360@dan.emsphone.com> <20100120235024.GE50360@dan.emsphone.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Matt Thyer , Dan Nelson Subject: Re: Buildworld failure with -j24 and ZFS on GPT on Core i7-860 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jan 2010 12:11:55 -0000 on 23/01/2010 15:03 Matt Thyer said the following: [snip] > r202214 works with make -j24 buildworld. > r202215 fails make -j24 buildworld as does every revision since then: > > make: don't know how to make /usr/obj/usr/src/tmp/usr/lib/libmd.a. Stop > *** Error code 2 [snip] > I can only assume there is a problem with "/usr/src/lib/libulog/Makefile". Hmm, I am not sure about how we enforce build order between libraries under lib/ that have interdependencies. Is it solely by SUBDIR ordering in lib/Makefile? In that case, could it be that the distance between libmd and libulog is too short for this number of tasks? I.e. libulog build starts and completes before libmd build completes (despite libulog being further down on the list)? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jan 25 12:47:05 2010 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 D674F106568F for ; Mon, 25 Jan 2010 12:47:05 +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 E9A318FC29 for ; Mon, 25 Jan 2010 12:47:04 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA16399; Mon, 25 Jan 2010 14:47:03 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B5D92C7.8070908@icyb.net.ua> Date: Mon, 25 Jan 2010 14:47:03 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-current@freebsd.org X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: tun setup (routing?) issue in head X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jan 2010 12:47:05 -0000 I've updated my HEAD amd64 system from December's sources to something more recent and I've got problems with security/vpnc. To be precise vpnc itself seems to work as good as before but its post-connect script is now failing: $ ifconfig tun0 inet 10.99.15.144 10.99.15.144 netmask 255.255.255.255 mtu 1412 up ifconfig: ioctl (SIOCAIFADDR): File exists Where tun0 is an interface created by vpnc. ktrace gives this: ifconfig CALL socket(PF_INET,SOCK_DGRAM,IPPROTO_IP) ifconfig RET socket 3 ifconfig CALL ioctl(0x3,SIOCSIFMTU,0x525a60) ifconfig RET ioctl 0 ifconfig CALL ioctl(0x3,SIOCGIFFLAGS,0x7fffffffda30) ifconfig RET ioctl 0 ifconfig CALL ioctl(0x3,SIOCSIFFLAGS,0x7fffffffda30) ifconfig RET ioctl 0 ifconfig CALL ioctl(0x3,SIOCDIFADDR,0x525380) ifconfig RET ioctl -1 errno 49 Can't assign requested address ifconfig CALL ioctl(0x3,SIOCAIFADDR,0x525340) ifconfig RET ioctl -1 errno 17 File exists ifconfig CALL write(0x2,0x7fffffffd2d0,0xa) So, what's happening? Do you I have to update the ifconfig command? Or is there some issue in the networking code? BTW, I also get the following messages in the system log when vpnc is started: kernel: tun0: link state changed to UP kernel: ifa_add_loopback_route: insertion failed I have net.link.tap.up_on_open=1 in sysctl.conf if that matters. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jan 25 12:56:21 2010 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 65AFB10656A3; Mon, 25 Jan 2010 12:56:21 +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 185628FC1C; Mon, 25 Jan 2010 12:56:20 +0000 (UTC) Received: from [10.100.124.99] (helo=edoofus.dev.vega.ru) by mail.vega.ru with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NZOUL-000DdZ-Bd; Mon, 25 Jan 2010 15:56:17 +0300 Date: Mon, 25 Jan 2010 15:55:54 +0300 From: Ruslan Ermilov To: Andriy Gapon Message-ID: <20100125125554.GA76457@edoofus.dev.vega.ru> References: <20100120162326.GD50360@dan.emsphone.com> <20100120235024.GE50360@dan.emsphone.com> <4B5D8A87.6030701@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B5D8A87.6030701@icyb.net.ua> Cc: Daniel Eischen , Ed Schouten , Matt Thyer , Dan Nelson , current@freebsd.org Subject: Re: Buildworld failure with -j24 and ZFS on GPT on Core i7-860 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jan 2010 12:56:21 -0000 On Mon, Jan 25, 2010 at 02:11:51PM +0200, Andriy Gapon wrote: > on 23/01/2010 15:03 Matt Thyer said the following: > [snip] > > r202214 works with make -j24 buildworld. > > r202215 fails make -j24 buildworld as does every revision since then: > > > > make: don't know how to make /usr/obj/usr/src/tmp/usr/lib/libmd.a. Stop > > *** Error code 2 > [snip] > > I can only assume there is a problem with "/usr/src/lib/libulog/Makefile". > > Hmm, I am not sure about how we enforce build order between libraries under lib/ > that have interdependencies. Is it solely by SUBDIR ordering in lib/Makefile? > In that case, could it be that the distance between libmd and libulog is too short > for this number of tasks? I.e. libulog build starts and completes before libmd > build completes (despite libulog being further down on the list)? The problem is already fixed in r202755 by Ed. When libulog was first added, it was needed for libpam (pam_lastlog), so it had to be built before libpam in Makefile.inc1:_prebuild_libs. What broke parallel builds is that Ed forgot to add an inter-library dependency of libulog on libmd. Now that libpam no longer required libulog it was removed from Makefile.inc1 completely, and the problem is resolved. Cheers, -- Ruslan Ermilov ru@FreeBSD.org FreeBSD committer From owner-freebsd-current@FreeBSD.ORG Mon Jan 25 12:59:36 2010 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 50FF91065692; Mon, 25 Jan 2010 12:59:36 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id CEA2F8FC0C; Mon, 25 Jan 2010 12:59:35 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0PCxHon018361; Mon, 25 Jan 2010 13:59:33 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0PCxHBp018360; Mon, 25 Jan 2010 13:59:17 +0100 (CET) (envelope-from olli) Date: Mon, 25 Jan 2010 13:59:17 +0100 (CET) Message-Id: <201001251259.o0PCxHBp018360@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, attilio@FreeBSD.ORG In-Reply-To: <3bbf2fe11001211033t4dfab54ai5d48156928fe7657@mail.gmail.com> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 25 Jan 2010 13:59:33 +0100 (CET) Cc: Subject: Re: top(1) + vmstat(8): CPU percentages broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 12:59:36 -0000 Attilio Rao <> wrote: > 2010/1/21 Oliver Fromme : > > Hello, > > > > On a 9-current system (sources as of Monday 2010-01-18), > > top(1) displays 0% for _all_ values in the "CPU" line > > (user, nice, sys, int, idle).  Also, in vmstat(1) the > > cpu columns us/sy/id are always zero. > > > > Is there a know problem with CPU time accounting in > > 9-current? > > May you revert r202387, 202441 and 202534 and see if it does make a difference? Yes, reverting those fixes the problem. The CPU statistics are back to normal. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The ITU has offered the IETF formal alignment with its corresponding technology, Penguins, but that won't fly." -- RFC 2549 From owner-freebsd-current@FreeBSD.ORG Mon Jan 25 13:42:21 2010 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 7260B1065692; Mon, 25 Jan 2010 13:42:21 +0000 (UTC) (envelope-from matt.thyer@gmail.com) Received: from mail-gx0-f209.google.com (mail-gx0-f209.google.com [209.85.217.209]) by mx1.freebsd.org (Postfix) with ESMTP id EAB648FC0C; Mon, 25 Jan 2010 13:42:20 +0000 (UTC) Received: by gxk1 with SMTP id 1so3349559gxk.14 for ; Mon, 25 Jan 2010 05:42: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; bh=uGFhW9NKpPQZbCt92KG0LQKaJVeoC5kecAXh1sWbQhE=; b=SM21QwMJ1owMXfEPYa3dfuW+qlZHdCeMf2cNYdGnvOTZ/jaWhpWB/MTNn09PJiCki3 u8q+MoTI8A9WAWx9l2oX1nV/qhRqUJIeA+Yjwondfuy/8defcaZU4rTubGDwNLmB+/4G LpyCFWQ9Y1aaWKVpTQeSv8IQgSOfUKTrY8Qwc= 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; b=lmwOhZbYrbrb2lv13Qvncb1BbVyeQHfGOK20sOy4s0piJ8A21JBSx8yAftApvvu3UA OrV+bxGW4fAAN0bm33H/qcHdBIvdS34sEtzASfSWhz+Oa2I2fRMFFmqC0z4InAj0bcmq cpFdRt2Lw9Vn9DsYvJCngkF1LWajL95kIdelI= MIME-Version: 1.0 Received: by 10.91.19.17 with SMTP id w17mr5701952agi.54.1264426937893; Mon, 25 Jan 2010 05:42:17 -0800 (PST) In-Reply-To: <20100125125554.GA76457@edoofus.dev.vega.ru> References: <20100120162326.GD50360@dan.emsphone.com> <20100120235024.GE50360@dan.emsphone.com> <4B5D8A87.6030701@icyb.net.ua> <20100125125554.GA76457@edoofus.dev.vega.ru> Date: Tue, 26 Jan 2010 00:12:17 +1030 Message-ID: From: Matt Thyer To: Ruslan Ermilov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Daniel Eischen , Ed Schouten , Dan Nelson , Andriy Gapon , current@freebsd.org Subject: Re: Buildworld failure with -j24 and ZFS on GPT on Core i7-860 system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jan 2010 13:42:21 -0000 2010/1/25 Ruslan Ermilov > On Mon, Jan 25, 2010 at 02:11:51PM +0200, Andriy Gapon wrote: > > on 23/01/2010 15:03 Matt Thyer said the following: > > > I can only assume there is a problem with > "/usr/src/lib/libulog/Makefile". > > > > Hmm, I am not sure about how we enforce build order between libraries > under lib/ > > that have interdependencies. Is it solely by SUBDIR ordering in > lib/Makefile? > > In that case, could it be that the distance between libmd and libulog is > too short > > for this number of tasks? I.e. libulog build starts and completes before > libmd > > build completes (despite libulog being further down on the list)? > > The problem is already fixed in r202755 by Ed. When libulog was first > added, it was needed for libpam (pam_lastlog), so it had to be built > before libpam in Makefile.inc1:_prebuild_libs. What broke parallel > builds is that Ed forgot to add an inter-library dependency of libulog > on libmd. Now that libpam no longer required libulog it was removed > from Makefile.inc1 completely, and the problem is resolved. > Thanks. I have confirmed that -j6 buildworld works in a VM a couple of hours ago. From owner-freebsd-current@FreeBSD.ORG Mon Jan 25 14:48:06 2010 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 75537106566B for ; Mon, 25 Jan 2010 14:48:06 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f204.google.com (mail-iw0-f204.google.com [209.85.223.204]) by mx1.freebsd.org (Postfix) with ESMTP id 3A6648FC0C for ; Mon, 25 Jan 2010 14:48:05 +0000 (UTC) Received: by iwn42 with SMTP id 42so515263iwn.9 for ; Mon, 25 Jan 2010 06:48:05 -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=TxmbFelCySbXF3gi4XrBpSNBCk3aoDHHFeJ9RirJuK4=; b=mcmpZK5eoiWVxYQxveTgDWfgIPS+yQayYiIkpMLsyFaZWnEsCKkBhbVUebS2rSfz55 PZaoXa/TzSGUtcJMNsFVv3oDK9cJlasS+gf2fKo0dCsXgEvtoGr7LtT8+QJOAgCBgeN2 CvRgh20JyiK9orBApbIc/pThGDso42sWQcY1g= 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=jZCAam/1aU9/O3lkCSWAecpw0bv4y8XoKIrQAyX/pF6YENTsJ51D8DSoXrpxTaJPmY NBoF0NVbWGmpt10ty1FS0dpHs1wyEK1VzdI4STXFzBYNPs8ZIKD00XjZKI3iGLeoE0iX kMU4u2Rq0wyZKAmxGxeDJE+O/incrgLfOaLV4= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.158.21 with SMTP id d21mr7081765ibx.61.1264430884814; Mon, 25 Jan 2010 06:48:04 -0800 (PST) In-Reply-To: <201001251259.o0PCxHBp018360@lurza.secnetix.de> References: <3bbf2fe11001211033t4dfab54ai5d48156928fe7657@mail.gmail.com> <201001251259.o0PCxHBp018360@lurza.secnetix.de> Date: Mon, 25 Jan 2010 15:48:04 +0100 X-Google-Sender-Auth: 4468575f7dd7a380 Message-ID: <3bbf2fe11001250648n4f02e33eu1bf44df5370cd28b@mail.gmail.com> From: Attilio Rao To: Oliver Fromme Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: top(1) + vmstat(8): CPU percentages broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 14:48:06 -0000 2010/1/25 Oliver Fromme : > Attilio Rao <> wrote: > =C2=A0> 2010/1/21 Oliver Fromme : > =C2=A0> > Hello, > =C2=A0> > > =C2=A0> > On a 9-current system (sources as of Monday 2010-01-18), > =C2=A0> > top(1) displays 0% for _all_ values in the "CPU" line > =C2=A0> > (user, nice, sys, int, idle). =C2=A0Also, in vmstat(1) the > =C2=A0> > cpu columns us/sy/id are always zero. > =C2=A0> > > =C2=A0> > Is there a know problem with CPU time accounting in > =C2=A0> > 9-current? > =C2=A0> > =C2=A0> May you revert r202387, 202441 and 202534 and see if it does make= a difference? > > Yes, reverting those fixes the problem. =C2=A0The CPU statistics > are back to normal. With the latest current, may you please provide a verbose dmesg? May you also provide a %sysctl kern.timecounter ? Thanks, Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon Jan 25 14:49:16 2010 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 2436510656B9 for ; Mon, 25 Jan 2010 14:49:16 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f204.google.com (mail-iw0-f204.google.com [209.85.223.204]) by mx1.freebsd.org (Postfix) with ESMTP id DC5118FC1B for ; Mon, 25 Jan 2010 14:49:15 +0000 (UTC) Received: by iwn42 with SMTP id 42so516426iwn.9 for ; Mon, 25 Jan 2010 06:49:15 -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; bh=15xjweBT/A3hn1UsSuumdI6x9R2lYuO7Y0UA4eneAEg=; b=b+zjUPb1QssQJrrPQR6DGP8ApsY2al6TBBH19Qn7oLUbNqtl2Gs3BQKSo7x/xOn+86 kHLXHDWLyG+7y25E0GdweucwVCRKBUhBx89rfjPxLKtshAm2FxizsSeWLrQAWMqgcmop coNLC0RoT4Ft50opLo1eiR11sRJoAZRjtKmxg= 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; b=coF1d7Lbx2K4yc8vSrlj6JDc8cAfI33MBHyhXvuWKSbTwLYs65GMH61FtGoPKOFAx6 3t0Hac5eD28DOVrUdgTg45o4BkdOqSkQdKW72lIrzsjFgKTFWDGbXAfbARDOdUqmYR3m yDm6qiXAj79P98cPwk4Q9NKJhleFqM+HuNInk= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.153.1 with SMTP id i1mr2656077ibw.35.1264430955299; Mon, 25 Jan 2010 06:49:15 -0800 (PST) In-Reply-To: <20100124190115.GA15079@ichotolot.servalan.com> References: <20100124024214.GA49252@Fluffy.Khv.RU> <4B5BC039.5060406@logvinov.com> <3bbf2fe11001240829k46d62476pda54d149c39ae7c3@mail.gmail.com> <20100124190115.GA15079@ichotolot.servalan.com> Date: Mon, 25 Jan 2010 15:49:15 +0100 X-Google-Sender-Auth: 561498d0ff215eb7 Message-ID: <3bbf2fe11001250649i32deaa23g90d12e60fa083c1d@mail.gmail.com> From: Attilio Rao To: Richard Todd Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: Regression in -current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 14:49:16 -0000 2010/1/24 Richard Todd : > On Sun, Jan 24, 2010 at 05:29:17PM +0100, Attilio Rao wrote: >> >> Can you all please do: >> >> % sysctl kern.timecounter >> >> Thanks, >> Attilio > > From the "bad" case: (machdep.lapic_allclocks=0): > > kern.timecounter.tick: 1 > kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-1000000) > kern.timecounter.hardware: ACPI-fast > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.i8254.counter: 43003 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.ACPI-fast.mask: 16777215 > kern.timecounter.tc.ACPI-fast.counter: 11430002 > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > kern.timecounter.tc.ACPI-fast.quality: 1000 > kern.timecounter.tc.HPET.mask: 4294967295 > kern.timecounter.tc.HPET.counter: 3399320019 > kern.timecounter.tc.HPET.frequency: 14318180 > kern.timecounter.tc.HPET.quality: 900 > kern.timecounter.tc.TSC.mask: 4294967295 > kern.timecounter.tc.TSC.counter: 2591427657 > kern.timecounter.tc.TSC.frequency: 2397618396 > kern.timecounter.tc.TSC.quality: -100 > kern.timecounter.smp_tsc: 0 > kern.timecounter.invariant_tsc: 1 > kern.clockrate: { hz = 300, tick = 3333, profhz = 300, stathz = 150 } > > and the good case: (lapic_allclocks=1, CPU accounting working properly) > > kern.timecounter.tick: 1 > kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-1000000) > kern.timecounter.hardware: ACPI-fast > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.i8254.counter: 16871 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.ACPI-fast.mask: 16777215 > kern.timecounter.tc.ACPI-fast.counter: 2589325 > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > kern.timecounter.tc.ACPI-fast.quality: 1000 > kern.timecounter.tc.HPET.mask: 4294967295 > kern.timecounter.tc.HPET.counter: 2021776154 > kern.timecounter.tc.HPET.frequency: 14318180 > kern.timecounter.tc.HPET.quality: 900 > kern.timecounter.tc.TSC.mask: 4294967295 > kern.timecounter.tc.TSC.counter: 3848116053 > kern.timecounter.tc.TSC.frequency: 2397620511 > kern.timecounter.tc.TSC.quality: -100 > kern.timecounter.smp_tsc: 0 > kern.timecounter.invariant_tsc: 1 > kern.clockrate: { hz = 300, tick = 3333, profhz = 1200, stathz = 133 } May you please also output a verbose dmesg of the 'broken' version? Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon Jan 25 15:54:56 2010 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 0C4451065676; Mon, 25 Jan 2010 15:54:56 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id D0C1C8FC19; Mon, 25 Jan 2010 15:54:55 +0000 (UTC) Received: from bcs-mail03.internal.cacheflow.com ([10.2.2.95]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id o0PFssqd012115; Mon, 25 Jan 2010 07:54:55 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 25 Jan 2010 07:52:56 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: tun setup (routing?) issue in head Thread-Index: AcqdvJcHBYXgJd9IRSK9UrbZhv7sPQAGd89+ References: <4B5D92C7.8070908@icyb.net.ua> From: "Li, Qing" To: "Andriy Gapon" , , Cc: Subject: RE: tun setup (routing?) issue in head X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jan 2010 15:54:56 -0000 Yes, the failure is due to route installation. To make a long story = short, many of the scripts that worked before not necessary because of the right reasons.=20 =20 I have been very busy at work, but I do have a patch and I will try to = get it=20 finalized shortly. =20 -- Qing =20 ________________________________ From: owner-freebsd-current@freebsd.org on behalf of Andriy Gapon Sent: Mon 1/25/2010 4:47 AM To: freebsd-net@freebsd.org; freebsd-current@freebsd.org Subject: tun setup (routing?) issue in head I've updated my HEAD amd64 system from December's sources to something = more recent and I've got problems with security/vpnc. To be precise vpnc itself = seems to work as good as before but its post-connect script is now failing: $ ifconfig tun0 inet 10.99.15.144 10.99.15.144 netmask 255.255.255.255 = mtu 1412 up ifconfig: ioctl (SIOCAIFADDR): File exists Where tun0 is an interface created by vpnc. ktrace gives this: ifconfig CALL socket(PF_INET,SOCK_DGRAM,IPPROTO_IP) ifconfig RET socket 3 ifconfig CALL ioctl(0x3,SIOCSIFMTU,0x525a60) ifconfig RET ioctl 0 ifconfig CALL ioctl(0x3,SIOCGIFFLAGS,0x7fffffffda30) ifconfig RET ioctl 0 ifconfig CALL ioctl(0x3,SIOCSIFFLAGS,0x7fffffffda30) ifconfig RET ioctl 0 ifconfig CALL ioctl(0x3,SIOCDIFADDR,0x525380) ifconfig RET ioctl -1 errno 49 Can't assign requested address ifconfig CALL ioctl(0x3,SIOCAIFADDR,0x525340) ifconfig RET ioctl -1 errno 17 File exists ifconfig CALL write(0x2,0x7fffffffd2d0,0xa) So, what's happening? Do you I have to update the ifconfig command? Or is there some issue in the networking code? BTW, I also get the following messages in the system log when vpnc is = started: kernel: tun0: link state changed to UP kernel: ifa_add_loopback_route: insertion failed I have net.link.tap.up_on_open=3D1 in sysctl.conf if that matters. -- Andriy Gapon _______________________________________________ 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 Jan 25 16:02:07 2010 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 3BEB7106566C; Mon, 25 Jan 2010 16:02:07 +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 4BBC78FC12; Mon, 25 Jan 2010 16:02:05 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA19719; Mon, 25 Jan 2010 18:01:08 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B5DC043.7030806@icyb.net.ua> Date: Mon, 25 Jan 2010 18:01:07 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: "Li, Qing" References: <4B5D92C7.8070908@icyb.net.ua> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: tun setup (routing?) issue in head X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jan 2010 16:02:07 -0000 on 25/01/2010 17:52 Li, Qing said the following: > Yes, the failure is due to route installation. To make a long story short, many of the > scripts that worked before not necessary because of the right reasons. > > I have been very busy at work, but I do have a patch and I will try to get it > finalized shortly. I see, cool! Perhaps there is some interim work-around for this issue? I can not access my work VPN because of this and I don't like having to roll back my kernel. > From: owner-freebsd-current@freebsd.org on behalf of Andriy Gapon > Sent: Mon 1/25/2010 4:47 AM > To: freebsd-net@freebsd.org; freebsd-current@freebsd.org > Subject: tun setup (routing?) issue in head > > > > > I've updated my HEAD amd64 system from December's sources to something more recent > and I've got problems with security/vpnc. To be precise vpnc itself seems to work > as good as before but its post-connect script is now failing: > > $ ifconfig tun0 inet 10.99.15.144 10.99.15.144 netmask 255.255.255.255 mtu 1412 up > ifconfig: ioctl (SIOCAIFADDR): File exists > > Where tun0 is an interface created by vpnc. > ktrace gives this: > ifconfig CALL socket(PF_INET,SOCK_DGRAM,IPPROTO_IP) > ifconfig RET socket 3 > ifconfig CALL ioctl(0x3,SIOCSIFMTU,0x525a60) > ifconfig RET ioctl 0 > ifconfig CALL ioctl(0x3,SIOCGIFFLAGS,0x7fffffffda30) > ifconfig RET ioctl 0 > ifconfig CALL ioctl(0x3,SIOCSIFFLAGS,0x7fffffffda30) > ifconfig RET ioctl 0 > ifconfig CALL ioctl(0x3,SIOCDIFADDR,0x525380) > ifconfig RET ioctl -1 errno 49 Can't assign requested address > ifconfig CALL ioctl(0x3,SIOCAIFADDR,0x525340) > ifconfig RET ioctl -1 errno 17 File exists > ifconfig CALL write(0x2,0x7fffffffd2d0,0xa) > > So, what's happening? > Do you I have to update the ifconfig command? > Or is there some issue in the networking code? > > BTW, I also get the following messages in the system log when vpnc is started: > kernel: tun0: link state changed to UP > kernel: ifa_add_loopback_route: insertion failed > I have net.link.tap.up_on_open=1 in sysctl.conf if that matters. > > -- > Andriy Gapon > _______________________________________________ > 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" > > -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Jan 25 16:05:56 2010 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 5390D1065672; Mon, 25 Jan 2010 16:05:56 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id D09778FC0A; Mon, 25 Jan 2010 16:05:55 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0PG5dOW026348; Mon, 25 Jan 2010 17:05:54 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0PG5dGn026347; Mon, 25 Jan 2010 17:05:39 +0100 (CET) (envelope-from olli) Date: Mon, 25 Jan 2010 17:05:39 +0100 (CET) Message-Id: <201001251605.o0PG5dGn026347@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, attilio@FreeBSD.ORG In-Reply-To: <3bbf2fe11001250648n4f02e33eu1bf44df5370cd28b@mail.gmail.com> X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 25 Jan 2010 17:05:54 +0100 (CET) Cc: Subject: Re: top(1) + vmstat(8): CPU percentages broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 16:05:56 -0000 Attilio Rao wrote: > 2010/1/25 Oliver Fromme : > > [...] > >  > May you revert r202387, 202441 and 202534 and see if it does make a difference? > > > > Yes, reverting those fixes the problem.  The CPU statistics > > are back to normal. > > With the latest current, may you please provide a verbose dmesg? > May you also provide a %sysctl kern.timecounter? Is a current of last week (2010-01-18) sufficient? I haven't seen any commits to the clock subsystem in the meantime, so it should be sufficient. Verbose dmesg, sysctl and much more can be found here: http://www.secnetix.de/olli/dmesg/hs22/ (It's with the "broken" kernel, i.e. with the above-mentioned revisions not reverted.) If 2010-01-18 isn't sufficient, I'll have to update, but that will take some time. The machine has no network, and I don't have physical access to it, so it's a little troublesome to get any files to/from it. IBM's painful remote console app doesn't even support copy&paste. :-( Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "We, the unwilling, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little, we are now qualified to do anything with nothing."         -- Mother Teresa From owner-freebsd-current@FreeBSD.ORG Mon Jan 25 16:58:12 2010 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 E7136106566C for ; Mon, 25 Jan 2010 16:58:12 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-iw0-f199.google.com (mail-iw0-f199.google.com [209.85.223.199]) by mx1.freebsd.org (Postfix) with ESMTP id AB1C58FC16 for ; Mon, 25 Jan 2010 16:58:12 +0000 (UTC) Received: by iwn37 with SMTP id 37so3741064iwn.30 for ; Mon, 25 Jan 2010 08:58:11 -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=ybh1Ktbx10zcQHCsXYnpJ6aWV3/x2iSdtteDggYXeeE=; b=vRV3FwbSK9KnTkVzc78cggVE2TAzq7nmP4ui+oNvpWNdF6efdnKMukp0oDv0zeifj9 VHoSqB2ubkNW2drgneRsdK1mDAB8HhFchhj7ErdJOxAniMpxF7BNtR08HO3Jg50LFPts 4Vb3430oQtSGHjAir3DWvs7zOBWEnWOyUt9hg= 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=rWIDiPeDup4itJlTr+jTM9IQilkCe64djowyPWFdt0vMljIjjbNOvAsDAN/dktPEdx BClsi0JmdTyHr6bFfuOZwJ71K7GbNpt4+al3QvCXSjxVjJdHJth1fjpbSHRzBpN7HwEI yDSd1XaN9aRMyKZQWTYb95XOLs9pFnul6ic3Q= MIME-Version: 1.0 Sender: asmrookie@gmail.com Received: by 10.231.167.65 with SMTP id p1mr962854iby.20.1264438691574; Mon, 25 Jan 2010 08:58:11 -0800 (PST) In-Reply-To: <201001251605.o0PG5dGn026347@lurza.secnetix.de> References: <3bbf2fe11001250648n4f02e33eu1bf44df5370cd28b@mail.gmail.com> <201001251605.o0PG5dGn026347@lurza.secnetix.de> Date: Mon, 25 Jan 2010 17:58:11 +0100 X-Google-Sender-Auth: aecf3058f5354638 Message-ID: <3bbf2fe11001250858p2516e20y95576eb3cc59764c@mail.gmail.com> From: Attilio Rao To: Oliver Fromme Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Richard Todd Subject: Re: top(1) + vmstat(8): CPU percentages broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 16:58:13 -0000 2010/1/25 Oliver Fromme : > Attilio Rao wrote: > =C2=A0> 2010/1/25 Oliver Fromme : > =C2=A0> > [...] > =C2=A0> > =C2=A0> May you revert r202387, 202441 and 202534 and see if it= does make a difference? > =C2=A0> > > =C2=A0> > Yes, reverting those fixes the problem. =C2=A0The CPU statistic= s > =C2=A0> > are back to normal. > =C2=A0> > =C2=A0> With the latest current, may you please provide a verbose dmesg? > =C2=A0> May you also provide a %sysctl kern.timecounter? > > Is a current of last week (2010-01-18) sufficient? =C2=A0I haven't > seen any commits to the clock subsystem in the meantime, so > it should be sufficient. =C2=A0Verbose dmesg, sysctl and much more > can be found here: Thanks a lot for the report. I see this: RTC BIOS diagnostic error 80 which means basically atrtc has been disabled and thus profhz and stathz fellback. The other traces I got are someway similar (I see values of hz which go in this direction). What needs to happen is that, if atrtc is not available apic should be choosen actually. I will try to make a patch very soon. Attilio --=20 Peace can only be achieved by understanding - A. Einstein From owner-freebsd-current@FreeBSD.ORG Mon Jan 25 18:39:11 2010 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 441CF1065692 for ; Mon, 25 Jan 2010 18:39:11 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id C321F8FC16 for ; Mon, 25 Jan 2010 18:39:10 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e12so308096fga.13 for ; Mon, 25 Jan 2010 10:39:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=TXYA5ebh0IFWjCc83JRzO0gQxogcN9ENHVcLCvh4n64=; b=T7gL/Mw/L9BPJZOPQaopgEHKeSbKJRtQELa6MrKCKsN3+KDKXuTc3bu5Ps7toSdlWO k2STRUawrSf4ochA7Owwztw4sDXpcSLOLPNlvkvgB3tpLVUTC9db/euINlAz/K466+DK BZz8gWChSwbSe3keRPbNBxhvhtQq6f0SNuN7M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=p1k/KlQWZuMsmIu31PLTNe5Rh80YqgyD+igt3gSLkvDWUJhaXaYbkzZaz9iTxLlbL6 8OO05S/kRwWdyUojEAfjRavFv38hO2Q+NrkvjynK+IZG98YrXJ3WnbjsBMEYlSH0RGF+ aKH+mkx571A7mvIf7WodswSHaYXg3nEFV5Ha8= Received: by 10.87.54.5 with SMTP id g5mr5623532fgk.78.1264444749754; Mon, 25 Jan 2010 10:39:09 -0800 (PST) Received: from dragon.dg ([41.216.197.17]) by mx.google.com with ESMTPS id 16sm2888423fxm.8.2010.01.25.10.39.06 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Jan 2010 10:39:08 -0800 (PST) From: David Naylor Organization: Private To: freebsd-current@freebsd.org Date: Mon, 25 Jan 2010 20:39:11 +0200 User-Agent: KMail/1.12.3 (FreeBSD/9.0-CURRENT; KDE/4.3.3; amd64; ; ) References: <201001231233.18832.naylor.b.david@gmail.com> In-Reply-To: <201001231233.18832.naylor.b.david@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1671660.s51KELAnJF"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001252039.16220.naylor.b.david@gmail.com> Subject: Re: "tinderbox" using stacked unionfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jan 2010 18:39:11 -0000 --nextPart1671660.s51KELAnJF Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Saturday 23 January 2010 12:33:14 David Naylor wrote: > Hi, >=20 > I have been experimenting with using unionfs to build ports in a > "tinderbox" environment. This avoids having to remove and extract files > for the build of each port and it allows the discovery of > installed/modified files by the port. >=20 > Please see attached for a (updated) shell script that handles all the > "heavy lifting" of building ports. Of importance is LOCALBASE and > BUILDDIR. If you want to override LOCALBASE please use `env` as the > script needs to know about it. BUILDDIR (/usr/build by default) is where > the script stores everything (including PKG_DBDIR). Please see attached for an updated script. This no longer uses `sort -u` b= ut=20 removed duplicates while maintaining dependency order. (See below) > # env LOCALBASE=3D/tmp/local BUILDDIR=3D/tmp/build ./ports-union-builder.= sh >=20 > Will install x11/xorg without affecting already installed systems. >=20 > CURRENT STATUS: > - *** Currently kernel stack size is too small and the above will trigger > a stack overflow. Recompiling a kernel with ``options KSTACK_PAGES=3D32= '' > will alleviate that problem. In building xorg there were at least 207 stacked unionfs (206 ro, 1 rw, all= =20 noatime). =20 > - Currently there is a build problem that affects eggdbus/polkit (possib= ly > others) thus preventing x11/xorg from being built. I will investigate the > cause (help welcome). This is due to not mounting the dependencies in the correct order. If=20 dependency 'a' modified file from dependency 'b' then mounting in order 'a'= ,=20 'b' will result in those changes being lost as the original files from 'b'= =20 will supersede 'a'. The dependencies need to be mounted 'b', 'a'. =20 This has been fixed although may cause a problem if multiple "independent"= =20 ports modify the same file. This is a detectable problem. =20 > - I highly recommend running this in a chroot > - NO WARRANTY, SLIPPERY WHEN WET, EATS CHILDREN. - I am experiencing process freeze (anything involved in the directories t= hat=20 are unionfs). Any way that I can figure out the problem? I can run a kern= el=20 will full debug capability. =20 - mtree does not behave well with unionfs and consumed a fair amount of=20 resources: # /usr/sbin/mtree -U -f /usr/ports/Templates/BSD.local.dist -d -e -p=20 /usr/local/ took a long time (many minutes) to complete. =20 > Since the script doesn't complete a full build I am unable to compare the > build speeds (thus the overhead of unionfs) but here are some partial > results (with FORCE_MAKE_JOBS and quad core): The script is now able to complete building but not at once due to process= =20 freezing. Please help with debugging the process freezing. (There is a LOR I have=20 reported for unionfs: kern/141950) Regards David --nextPart1671660.s51KELAnJF Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEABECAAYFAktd5VQACgkQUaaFgP9pFrL67wCfdjKnUsfNxGYIgHXQBu7LeEka SvkAnjc6BOd0Nl9W2agsKjox52t+7Sgr =Hh/M -----END PGP SIGNATURE----- --nextPart1671660.s51KELAnJF-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 25 22:33:18 2010 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 C3A591065697 for ; Mon, 25 Jan 2010 22:33:18 +0000 (UTC) (envelope-from christof.schulze@gmx.com) Received: from mailout-eu.gmx.com (mailout-eu.gmx.com [213.165.64.42]) by mx1.freebsd.org (Postfix) with SMTP id 3BB9A8FC15 for ; Mon, 25 Jan 2010 22:33:18 +0000 (UTC) Received: (qmail invoked by alias); 25 Jan 2010 22:33:16 -0000 Received: from e181212122.adsl.alicedsl.de (EHLO klausdieter0815.dyndns.org) [85.181.212.122] by mail.gmx.com (mp-eu003) with SMTP; 25 Jan 2010 23:33:16 +0100 X-Authenticated: #56306756 X-Provags-ID: V01U2FsdGVkX1+6Avka+2K6zh5fExberuoH67eFqf6m8jzQ8vN729 4NMiyA7geGP3fC Received: by myhost.mydomain.de (Postfix, from userid 1001) id 6A6BC768A; Mon, 25 Jan 2010 23:33:11 +0100 (CET) From: Christof Schulze To: freebsd-current@freebsd.org Date: Mon, 25 Jan 2010 23:32:58 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-STABLE; KDE/4.3.4; amd64; ; ) References: <201001231233.18832.naylor.b.david@gmail.com> <201001252039.16220.naylor.b.david@gmail.com> In-Reply-To: <201001252039.16220.naylor.b.david@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8493944.lMmWUNsqzN"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001252333.08045.christof.schulze@gmx.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.5 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: "tinderbox" using stacked unionfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jan 2010 22:33:18 -0000 --nextPart8493944.lMmWUNsqzN Content-Type: multipart/mixed; boundary="Boundary-01=_hwhXLcMfEjAV8bv" Content-Transfer-Encoding: 7bit --Boundary-01=_hwhXLcMfEjAV8bv Content-Type: Text/Plain; charset="iso-8859-6" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi David, I like your unionfs idea. Noticing the tinderbox limitation I moved on my z= fs=20 based system to a jail I set up using a self written script. It is currentl= y=20 customized to my environment but still might prove useful for quick setup o= f=20 jails. it handles=20 * fs creation=20 * putting the proper data on them * routing setup (since I use a laptop and my active nic changes from cable- bound to wireless) Since this both contributes to the topic of building software in a separate= =20 environment, I share it here.=20 Regards Christof Am Montag 25 Januar 2010 19:39:11 schrieb David Naylor: > On Saturday 23 January 2010 12:33:14 David Naylor wrote: > > Hi, > > > > I have been experimenting with using unionfs to build ports in a > > "tinderbox" environment. This avoids having to remove and extract fil= es > > for the build of each port and it allows the discovery of > > installed/modified files by the port. > > > > Please see attached for a (updated) shell script that handles all the > > "heavy lifting" of building ports. Of importance is LOCALBASE and > > BUILDDIR. If you want to override LOCALBASE please use `env` as the > > script needs to know about it. BUILDDIR (/usr/build by default) is > > where the script stores everything (including PKG_DBDIR). >=20 > Please see attached for an updated script. This no longer uses `sort -u` > but removed duplicates while maintaining dependency order. (See below) >=20 > > # env LOCALBASE=3D/tmp/local BUILDDIR=3D/tmp/build ./ports-union-builde= r.sh > > > > Will install x11/xorg without affecting already installed systems. > > > > CURRENT STATUS: > > - *** Currently kernel stack size is too small and the above will > > trigger a stack overflow. Recompiling a kernel with ``options > > KSTACK_PAGES=3D32'' will alleviate that problem. >=20 > In building xorg there were at least 207 stacked unionfs (206 ro, 1 rw, a= ll > noatime). >=20 > > - Currently there is a build problem that affects eggdbus/polkit > > (possibly others) thus preventing x11/xorg from being built. I will > > investigate the cause (help welcome). >=20 > This is due to not mounting the dependencies in the correct order. If > dependency 'a' modified file from dependency 'b' then mounting in order > 'a', 'b' will result in those changes being lost as the original files > from 'b' will supersede 'a'. The dependencies need to be mounted 'b', > 'a'. >=20 > This has been fixed although may cause a problem if multiple "independent" > ports modify the same file. This is a detectable problem. >=20 > > - I highly recommend running this in a chroot > > - NO WARRANTY, SLIPPERY WHEN WET, EATS CHILDREN. >=20 > - I am experiencing process freeze (anything involved in the directories > that are unionfs). Any way that I can figure out the problem? I can run > a kernel will full debug capability. > - mtree does not behave well with unionfs and consumed a fair amount of > resources: > # /usr/sbin/mtree -U -f /usr/ports/Templates/BSD.local.dist -d -e -p > /usr/local/ > took a long time (many minutes) to complete. >=20 > > Since the script doesn't complete a full build I am unable to compare t= he > > build speeds (thus the overhead of unionfs) but here are some partial > > results (with FORCE_MAKE_JOBS and quad core): >=20 > The script is now able to complete building but not at once due to process > freezing. >=20 > Please help with debugging the process freezing. (There is a LOR I have > reported for unionfs: kern/141950) >=20 > Regards >=20 > David >=20 =2D-=20 () ascii ribbon campaign - against html e-mail=20 /\ www.asciiribbon.org - against proprietary attachments --Boundary-01=_hwhXLcMfEjAV8bv-- --nextPart8493944.lMmWUNsqzN Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEABECAAYFAkteHCIACgkQpZfyPAmdZJnTqgCglEYg/Eb5a8aVJ6SBfs0PPN1O 8ToAoK7AxTAsBVMEMxVrD4nJ8wkmF6Kt =uDzN -----END PGP SIGNATURE----- --nextPart8493944.lMmWUNsqzN-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 25 22:45:26 2010 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 08F0A106566B for ; Mon, 25 Jan 2010 22:45:26 +0000 (UTC) (envelope-from rmtodd@servalan.servalan.com) Received: from mx1.synetsystems.com (mx1.synetsystems.com [76.10.206.14]) by mx1.freebsd.org (Postfix) with ESMTP id CF9F88FC21 for ; Mon, 25 Jan 2010 22:45:25 +0000 (UTC) Received: by mx1.synetsystems.com (Postfix, from userid 66) id 18C0FE53; Mon, 25 Jan 2010 17:45:25 -0500 (EST) Received: from rmtodd by servalan.servalan.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NZX04-0005L4-MU; Mon, 25 Jan 2010 16:01:36 -0600 Date: Mon, 25 Jan 2010 16:01:36 -0600 From: Richard Todd To: Attilio Rao Message-ID: <20100125220136.GA19877@ichotolot.servalan.com> References: <3bbf2fe11001250648n4f02e33eu1bf44df5370cd28b@mail.gmail.com> <201001251605.o0PG5dGn026347@lurza.secnetix.de> <3bbf2fe11001250858p2516e20y95576eb3cc59764c@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3bbf2fe11001250858p2516e20y95576eb3cc59764c@mail.gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: top(1) + vmstat(8): CPU percentages broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2010 22:45:26 -0000 On Mon, Jan 25, 2010 at 05:58:11PM +0100, Attilio Rao wrote: > Thanks a lot for the report. > I see this: > RTC BIOS diagnostic error 80 > > which means basically atrtc has been disabled and thus profhz and > stathz fellback. The other traces I got are someway similar (I see > values of hz which go in this direction). Yep, I see the same thing here, RTC BIOS diagnostic error 80. > What needs to happen is that, if atrtc is not available apic should be > choosen actually. > I will try to make a patch very soon. Sounds good, thanks for looking into it for us all. Richard From owner-freebsd-current@FreeBSD.ORG Mon Jan 25 23:34:27 2010 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 DAE191065670 for ; Mon, 25 Jan 2010 23:34:27 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 7A7828FC18 for ; Mon, 25 Jan 2010 23:34:27 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 19so423419fgg.13 for ; Mon, 25 Jan 2010 15:34:26 -0800 (PST) Received: by 10.87.76.23 with SMTP id d23mr4037729fgl.1.1264462466496; Mon, 25 Jan 2010 15:34:26 -0800 (PST) Received: from ?10.0.1.198? (udp022762uds.hawaiiantel.net [72.234.79.107]) by mx.google.com with ESMTPS id l12sm19468214fgb.10.2010.01.25.15.34.23 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Jan 2010 15:34:25 -0800 (PST) Date: Mon, 25 Jan 2010 13:38:41 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: current@freebsd.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Subject: SUJ testing update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Jan 2010 23:34:27 -0000 Hello folks, I just committed some big changes to suj to svn at svn://svn.freebsd.org/base/projects/suj/head You can now run softdep without journaling again. The fast journal checker is enabled. You need only use tunefs -j enable or tunefs -j disable. The SUJ flag in the filesystem moved for backwards compat reasons. If you have an earlier SUJ volume please disable it with the old tunefs and enable again with the new tunefs. I'll be making a few more minor changes before I commit to HEAD but we're pretty close. Please give it a go and make sure it works for you! Thanks, Jeff From owner-freebsd-current@FreeBSD.ORG Tue Jan 26 01:41:09 2010 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 9720F106566C for ; Tue, 26 Jan 2010 01:41:09 +0000 (UTC) (envelope-from avl@logvinov.com) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by mx1.freebsd.org (Postfix) with ESMTP id 2244C8FC0A for ; Tue, 26 Jan 2010 01:41:08 +0000 (UTC) Received: by gxk6 with SMTP id 6so2414255gxk.13 for ; Mon, 25 Jan 2010 17:41:08 -0800 (PST) Received: by 10.150.193.15 with SMTP id q15mr7105740ybf.126.1264470068248; Mon, 25 Jan 2010 17:41:08 -0800 (PST) Received: from incubus.bsd ([124.64.179.246]) by mx.google.com with ESMTPS id 35sm1860187yxh.51.2010.01.25.17.41.05 (version=SSLv3 cipher=RC4-MD5); Mon, 25 Jan 2010 17:41:07 -0800 (PST) Message-ID: <4B5E4865.2010504@logvinov.com> Date: Tue, 26 Jan 2010 09:41:57 +0800 From: Alexander Logvinov User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; ru-RU; rv:1.9.1.7) Gecko/20100125 Thunderbird/3.0.1 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Attilio Rao References: <20100124024214.GA49252@Fluffy.Khv.RU> <4B5BC039.5060406@logvinov.com> <3bbf2fe11001240829k46d62476pda54d149c39ae7c3@mail.gmail.com> In-Reply-To: <3bbf2fe11001240829k46d62476pda54d149c39ae7c3@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: fluffy@fluffy.khv.ru, Richard Todd , freebsd-current@freebsd.org Subject: Re: Regression in -current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2010 01:41:09 -0000 Hello! On 25.01.2010 00:29 Attilio Rao wrote: > Can you all please do: > % sysctl kern.timecounter Without machdep.lapic_allclocks: http://people.freebsd.org/~avl/misc/kernel/1.dmesg kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-1000000) kern.timecounter.hardware: ACPI-fast kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 10056 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 2222887 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 1000 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 3915528721 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 900 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 1078877352 kern.timecounter.tc.TSC.frequency: 2136527808 kern.timecounter.tc.TSC.quality: -100 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 1 With machdep.lapic_allclocks=1: http://people.freebsd.org/~avl/misc/kernel/2.dmesg kern.timecounter.tick: 1 kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-1000000) kern.timecounter.hardware: ACPI-fast kern.timecounter.stepwarnings: 0 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 20450 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 14493170 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 1000 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 1088390709 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 900 kern.timecounter.tc.TSC.mask: 4294967295 kern.timecounter.tc.TSC.counter: 403869192 kern.timecounter.tc.TSC.frequency: 2136529376 kern.timecounter.tc.TSC.quality: -100 kern.timecounter.smp_tsc: 0 kern.timecounter.invariant_tsc: 1 -- Best regards, Alexander From owner-freebsd-current@FreeBSD.ORG Tue Jan 26 10:26:25 2010 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 55063106566C for ; Tue, 26 Jan 2010 10:26:25 +0000 (UTC) (envelope-from michael.gusek@web.de) Received: from fmmailgate02.web.de (fmmailgate02.web.de [217.72.192.227]) by mx1.freebsd.org (Postfix) with ESMTP id DDA658FC15 for ; Tue, 26 Jan 2010 10:26:24 +0000 (UTC) Received: from smtp08.web.de (fmsmtp08.dlan.cinetic.de [172.20.5.216]) by fmmailgate02.web.de (Postfix) with ESMTP id 59FF114C91F39 for ; Tue, 26 Jan 2010 11:02:57 +0100 (CET) Received: from [82.144.33.34] (helo=kerkyra.vanguard.de) by smtp08.web.de with asmtp (TLSv1:AES256-SHA:256) (WEB.DE 4.110 #314) id 1NZiG9-0000NV-00 for freebsd-current@freebsd.org; Tue, 26 Jan 2010 11:02:57 +0100 Message-ID: <4B5EBDD0.5090309@web.de> Date: Tue, 26 Jan 2010 11:02:56 +0100 From: Michael Gusek User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.1.5) Gecko/20100105 Thunderbird/3.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4B55D9D4.1000008@FreeBSD.org> In-Reply-To: <4B55D9D4.1000008@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Sender: michael.gusek@web.de X-Sender: michael.gusek@web.de X-Provags-ID: V01U2FsdGVkX19DMg+S4l8WKCocRL8ei77Xvx5uQP1z3AijplpO B2BIErdnJR3+P+g5ccRjB/E807hilzVmAHWZOKfMom3aGzgsM5 0bntpi4aJiZdmBXX/yTg== Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jan 2010 10:26:25 -0000 On 19.01.2010 17:12, Alexander Motin wrote: > Hi. > > I've made a patch, that should solve set of problems of CAM ATA and CAM > generally. I would like to ask for testing and feedback. > > What patch does: > - It unifies bus reset/probe sequence. Whenever bus attached at boot or > later, CAM will automatically reset and scan it. It allows to remove > duplicate code from many drivers. > - Any bus, attached before CAM completed it's boot-time initialization, > will equally join to the process, delaying boot if needed. > - New kern.cam.boot_delay loader tunable should help controllers that > are still unable to register their buses in time (such as slow USB/ > PCCard/ CardBus devices). > - To allow synchronization between different CAM levels, concept of > requests priorities was extended. Priorities now split between several > "run levels". Device can be freezed at specified level, allowing higher > priority requests to pass. For example, no payload requests allowed, > until PMP driver enable port. ATA XPT negotiate transfer parameters, > periph driver configure caching and so on. > - Frozen requests are no more counted by request allocation scheduler. > It fixes deadlocks, when frozen low priority payload requests occupying > slots, required by higher levels to manage theit execution. > - Two last changes were holding proper ATA reinitialization and error > recovery implementation. Now it is done: SATA controllers and Port > Multipliers now implement automatic hot-plug and should correctly > recover from timeouts and bus resets. > > Patch can be found here: > http://people.freebsd.org/~mav/cam-ata.20100119.patch > > Feedback as always welcome. > > This patch solved my problem which i describe in the Mail "USB pen encryption at boot-time". I have to set kern.cam.boot_delay=6000 in /boot/loader.conf. Thank you ! Michael From owner-freebsd-current@FreeBSD.ORG Tue Jan 26 11:59:14 2010 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 9876D106566B for ; Tue, 26 Jan 2010 11:59:14 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [IPv6:2a01:170:102f::2]) by mx1.freebsd.org (Postfix) with ESMTP id 21ACF8FC16 for ; Tue, 26 Jan 2010 11:59:13 +0000 (UTC) Received: from lurza.secnetix.de (localhost [127.0.0.1]) by lurza.secnetix.de (8.14.3/8.14.3) with ESMTP id o0QBwvmn076432; Tue, 26 Jan 2010 12:59:12 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.14.3/8.14.3/Submit) id o0QBwv2B076431; Tue, 26 Jan 2010 12:58:57 +0100 (CET) (envelope-from olli) Date: Tue, 26 Jan 2010 12:58:57 +0100 (CET) Message-Id: <201001261158.o0QBwv2B076431@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG, jroberson@jroberson.net In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.8.3-20070201 ("Scotasay") (UNIX) (FreeBSD/6.4-PRERELEASE-20080904 (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Tue, 26 Jan 2010 12:59:13 +0100 (CET) Cc: Subject: Re: SUJ testing update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jan 2010 11:59:14 -0000 Jeff Roberson wrote: > I just committed some big changes to suj to svn at > svn://svn.freebsd.org/base/projects/suj/head > > You can now run softdep without journaling again. The fast journal > checker is enabled. You need only use tunefs -j enable or tunefs -j > disable. > > The SUJ flag in the filesystem moved for backwards compat reasons. If you > have an earlier SUJ volume please disable it with the old tunefs and > enable again with the new tunefs. > > I'll be making a few more minor changes before I commit to HEAD but we're > pretty close. Please give it a go and make sure it works for you! Just out of curiosity, is it possible to put the journal on a different physical disk (e.g. a flash disk or other kind of SSD)? Or does the journal have to live inside the actual file system? And a second, more important question: How well does SUJ cope with unexpected power outages? I just had two power failures recently, the first caused by a bad supply, the second caused by a failing CPU fan which lead to an emergency shutdown of the hardware (power-off). I also remember the last "real" power outage at home when I tried to use the electric kettle, the toaster and the microwave at the same time ... Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "The most important decision in [programming] language design concerns what is to be left out." -- Niklaus Wirth From owner-freebsd-current@FreeBSD.ORG Tue Jan 26 13:05:04 2010 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 5B01D106568F for ; Tue, 26 Jan 2010 13:05:04 +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 E8D5F8FC08 for ; Tue, 26 Jan 2010 13:05:03 +0000 (UTC) Received: from [195.4.92.14] (helo=4.mx.freenet.de) by mout2.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NZl6M-0004Lt-OT; Tue, 26 Jan 2010 14:05:02 +0100 Received: from p57ae1443.dip0.t-ipconnect.de ([87.174.20.67]:52270 helo=ernst.jennejohn.org) by 4.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1NZl6M-0006OA-ET; Tue, 26 Jan 2010 14:05:02 +0100 Date: Tue, 26 Jan 2010 14:04:59 +0100 From: Gary Jennejohn To: David Naylor Message-ID: <20100126140459.61e3951d@ernst.jennejohn.org> In-Reply-To: <201001252039.16220.naylor.b.david@gmail.com> References: <201001231233.18832.naylor.b.david@gmail.com> <201001252039.16220.naylor.b.david@gmail.com> X-Mailer: Claws Mail 3.7.4 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: "tinderbox" using stacked unionfs 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, 26 Jan 2010 13:05:04 -0000 On Mon, 25 Jan 2010 20:39:11 +0200 David Naylor wrote: > On Saturday 23 January 2010 12:33:14 David Naylor wrote: > > Hi, > > > > I have been experimenting with using unionfs to build ports in a > > "tinderbox" environment. This avoids having to remove and extract files > > for the build of each port and it allows the discovery of > > installed/modified files by the port. > > > > Please see attached for a (updated) shell script that handles all the > > "heavy lifting" of building ports. Of importance is LOCALBASE and > > BUILDDIR. If you want to override LOCALBASE please use `env` as the > > script needs to know about it. BUILDDIR (/usr/build by default) is where > > the script stores everything (including PKG_DBDIR). > > Please see attached for an updated script. This no longer uses `sort -u` but > removed duplicates while maintaining dependency order. (See below) > ENOSCRIPT --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Jan 26 13:13:55 2010 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 653441065697 for ; Tue, 26 Jan 2010 13:13:55 +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 23C5A8FC28 for ; Tue, 26 Jan 2010 13:13:55 +0000 (UTC) Received: from [195.4.92.22] (helo=12.mx.freenet.de) by mout2.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NZlEw-0006kW-CB; Tue, 26 Jan 2010 14:13:54 +0100 Received: from p57ae1443.dip0.t-ipconnect.de ([87.174.20.67]:33457 helo=ernst.jennejohn.org) by 12.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.69 #94) id 1NZlEj-0005Ah-77; Tue, 26 Jan 2010 14:13:46 +0100 Date: Tue, 26 Jan 2010 14:13:10 +0100 From: Gary Jennejohn To: freebsd-current@freebsd.org Message-ID: <20100126141310.23cb08fa@ernst.jennejohn.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.4 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Jeff Roberson Subject: Re: SUJ testing update 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, 26 Jan 2010 13:13:55 -0000 On Mon, 25 Jan 2010 13:38:41 -1000 (HST) Jeff Roberson wrote: > I just committed some big changes to suj to svn at > svn://svn.freebsd.org/base/projects/suj/head > > You can now run softdep without journaling again. The fast journal > checker is enabled. You need only use tunefs -j enable or tunefs -j > disable. > > The SUJ flag in the filesystem moved for backwards compat reasons. If you > have an earlier SUJ volume please disable it with the old tunefs and > enable again with the new tunefs. > Upadating my old SUJ volumess worked for me. > I'll be making a few more minor changes before I commit to HEAD but we're > pretty close. Please give it a go and make sure it works for you! > One thing I liked about the last patch was that the output of mount(8) showed "soft-updates journal." Any plans to put that back? --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Tue Jan 26 16:10:42 2010 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 DEF87106568B for ; Tue, 26 Jan 2010 16:10:42 +0000 (UTC) (envelope-from prvs=0642d55c7e=ob@gruft.de) Received: from main.mx.e-gitt.net (service.rules.org [IPv6:2001:1560:2342::2]) by mx1.freebsd.org (Postfix) with ESMTP id 903EE8FC1C for ; Tue, 26 Jan 2010 16:10:42 +0000 (UTC) Received: from ob by main.mx.e-gitt.net with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NZo01-000CWh-Op for freebsd-current@freebsd.org; Tue, 26 Jan 2010 17:10:41 +0100 Date: Tue, 26 Jan 2010 17:10:41 +0100 From: Oliver Brandmueller To: freebsd-current@freebsd.org Message-ID: <20100126161041.GO3917@e-Gitt.NET> Mail-Followup-To: freebsd-current@freebsd.org References: <201001101437.37269.hselasky@c2i.net> <201001221442.07624.doconnor@gsoft.com.au> <201001222303.57515.christof.schulze@gmx.com> <201001231300.49077.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zx4FCpZtqtKETZ7O" Content-Disposition: inline In-Reply-To: <201001231300.49077.doconnor@gsoft.com.au> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: Oliver Brandmueller Subject: Re: [FreeBSD 8/9] USB webcamd and video4bsd: Call for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jan 2010 16:10:42 -0000 --zx4FCpZtqtKETZ7O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sat, Jan 23, 2010 at 01:00:40PM +1030, Daniel O'Connor wrote: > > Interestingly skype does not seem to detect the webcam even though it > > claims to support v4l >=20 > Skype doesn't work for me either, it lists /dev/video0 but nothing=20 > happens when I click test and it doesn't work in a video call (the=20 > recipient sees nothing). For me Skype doesn't even detect /dev/video0 - pwcview works fine though=20 (at least the first time I use it, afterwards I have to restart webcamd=20 to use it a second time). - Oliver --=20 | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | --zx4FCpZtqtKETZ7O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAktfFAEACgkQiqtMdzjafynEggCfd1ymsFVw3r/unjs65VPgd9cR pn0An1zHsKsfhpVD0lOLMS0LXaDKi5T+ =U1H2 -----END PGP SIGNATURE----- --zx4FCpZtqtKETZ7O-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 26 16:41:23 2010 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 422A710656C0 for ; Tue, 26 Jan 2010 16:41:23 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by mx1.freebsd.org (Postfix) with ESMTP id BE4368FC13 for ; Tue, 26 Jan 2010 16:41:22 +0000 (UTC) Received: by ewy6 with SMTP id 6so3482468ewy.14 for ; Tue, 26 Jan 2010 08:41:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=Nm/VfrQAVIq4MkPq1WhF9TdrwthSTtHTpr62FILvPOQ=; b=IKTWMgiTF3dTjF2mjMOED0Tj00ywikahT6cyrXLBM4U63ap0f4ktW90WDju5r59RWl b/UmobvYH8pP7Z2T8r6vIfrZlnJb4xeu9X/4AvV3Y1fF1uAvLaR+UW7zrqb3wJ4Xv6K/ zqeS+8aEjPExY3Ti6K5eEwbQwNTu7nkoc0ZHs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=qGC3vGOeSBfTcx0EHDmGIcqEFyLFBXcFBvmO2B6OipN5mE3BziJeVAhB1jzst58/UD LeOcxh36+aeNdF+R/QyAmgwlALvAZ7gjnl5cHm66uWF1mknVlKKvbgrjVsQcj0Xwwq/S LxUy2Vq36JGgVQbFCJTDO1TFNgUmcH2iFi7cM= Received: by 10.213.50.203 with SMTP id a11mr3027473ebg.76.1264524081410; Tue, 26 Jan 2010 08:41:21 -0800 (PST) Received: from dragon.dg ([41.216.197.17]) by mx.google.com with ESMTPS id 28sm10457575eyg.28.2010.01.26.08.41.16 (version=SSLv3 cipher=RC4-MD5); Tue, 26 Jan 2010 08:41:18 -0800 (PST) From: David Naylor Organization: Private To: gary.jennejohn@freenet.de Date: Tue, 26 Jan 2010 18:41:20 +0200 User-Agent: KMail/1.12.3 (FreeBSD/8.0-STABLE; KDE/4.3.3; amd64; ; ) References: <201001231233.18832.naylor.b.david@gmail.com> <201001252039.16220.naylor.b.david@gmail.com> <20100126140459.61e3951d@ernst.jennejohn.org> In-Reply-To: <20100126140459.61e3951d@ernst.jennejohn.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1388239.PjsOTXcBQ3"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001261841.23815.naylor.b.david@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: "tinderbox" using stacked unionfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jan 2010 16:41:23 -0000 --nextPart1388239.PjsOTXcBQ3 Content-Type: multipart/mixed; boundary="Boundary-01=_wsxXLim1PzKXdFE" Content-Transfer-Encoding: 7bit --Boundary-01=_wsxXLim1PzKXdFE Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 26 January 2010 15:04:59 Gary Jennejohn wrote: > On Mon, 25 Jan 2010 20:39:11 +0200 >=20 > David Naylor wrote: > > On Saturday 23 January 2010 12:33:14 David Naylor wrote: > > > Hi, > > > > > > I have been experimenting with using unionfs to build ports in a > > > "tinderbox" environment. This avoids having to remove and extract > > > files for the build of each port and it allows the discovery of > > > installed/modified files by the port. > > > > > > Please see attached for a (updated) shell script that handles all the > > > "heavy lifting" of building ports. Of importance is LOCALBASE and > > > BUILDDIR. If you want to override LOCALBASE please use `env` as the > > > script needs to know about it. BUILDDIR (/usr/build by default) is > > > where the script stores everything (including PKG_DBDIR). > > > > Please see attached for an updated script. This no longer uses `sort -= u` > > but removed duplicates while maintaining dependency order. (See below) >=20 > ENOSCRIPT See attached. Processes are still freezing periodically (requiring a=20 restart). The mtree problem appears when installing meta ports (x11/xorg- apps, x11/xorg, etc). =20 --Boundary-01=_wsxXLim1PzKXdFE Content-Type: text/plain; charset="ISO-8859-1"; name="ports-union-builder.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ports-union-builder.txt" #!/bin/sh BUILDDIR=${BUILDDIR:-/usr/build} LOCALBASE=${LOCALBASE:-/usr/local} PORTSDIR=${PORTSDIR:-/usr/ports} PORT_DBDIR=${PKG_DBDIR:-$BUILDDIR/db_ports} PKG_DBDIR=${PKG_DBDIR:-$BUILDDIR/db_pkg} PACKAGES=${PACKAGES:-$BUILDDIR/packages} MAKE="env LOCALBASE=$LOCALBASE PORTSDIR=$PORTSDIR PORT_DBDIR=$PORT_DBDIR PKG_DBDIR=$PKG_DBDIR PACKAGES=$PACKAGES make" set -e mkdir -p $BUILDDIR $LOCALBASE $PKG_DBDIR $PACKAGES [ -n "$(kldstat -v | grep unionfs)" ] || kldload unionfs [ ! -e $BUILDDIR/.installing_port ] || rm -r `cat $BUILDDIR/.installing_port` $BUILDDIR/.installing_port port2name() { echo $1 | sed 's|[/.-]|_|g' } port2pkg() { local pkg_name= local port= port=$1; shift eval pkg_name=PKG$(port2name $port) eval pkg=\$$pkg_name if [ -z "$pkg" ] then pkg=$($MAKE -C $port -V PKGNAME) eval $pkg_name=$pkg fi } depends() { local depend= local depends_name= local _deps= local name= local port= local type type=$1 port=$2 eval depends_name=DEPEND_${type}_$(port2name $port) eval deps=\"\$$depends_name\" if [ -z "$deps" ] then echo "Getting $type dependancies for $port" > /dev/stderr if [ "$type" = "build" ] then depend_list="$($MAKE -C $port -V EXTRACT_DEPENDS -V BUILD_DEPENDS -V LIB_DEPENDS -V RUN_DEPENDS)" else depend_list="$($MAKE -C $port -V LIB_DEPENDS -V RUN_DEPENDS)" fi for depend in $depend_list do name=$(echo $depend | cut -f 2 -d ':') depends runtime $name _deps="$_deps $deps $name" done deps=" " for depend in $_deps do if [ -z "`echo "$deps" | grep " $depend "`" ] then deps="$deps$depend " fi done [ "`echo $deps | tr ' ' '\n' | sort`" = "`echo $deps | tr ' ' '\n' | sort -u`" ] depends_name=$depends_name eval $depends_name=\"$deps \" fi } run_make() { set +e trap "true" INT TERM EXIT $MAKE "$@" status=$? trap - INT TERM EXIT set -e } build() { local _deps= local dep= local port= port=$1 depends build $port _deps="$deps" for dep in $_deps do port2pkg $dep if [ ! -d $BUILDDIR/$pkg ] then if ! build $dep then echo "Port $port failed due to dependency $dep" > /dev/stderr return 255 fi fi done echo "Building port $port..." for pkg in $_deps do port2pkg $pkg mount -t unionfs -r -o noatime $BUILDDIR/$pkg $LOCALBASE done run_make -C $port clean build -DNO_DEPENDS -DBATCH if [ $status -eq 0 ] then port2pkg $port mkdir -p $BUILDDIR/$pkg mount -t unionfs -o noatime $BUILDDIR/$pkg $LOCALBASE echo $BUILDDIR/$pkg > $BUILDDIR/.installing_port run_make -C $port install package -DNO_DEPENDS -DBATCH rm $BUILDDIR/.installing_port [ $status -ne 0 -a -n "$NO_CLEANUP" ] || umount $LOCALBASE fi for pkg in $(echo $_deps | sort -r) do [ $status -ne 0 -a -n "$NO_CLEANUP" ] || umount $LOCALBASE done if [ $status -ne 0 ] then echo "Port $port failed to build" > /dev/stderr port2pkg $port rm -rf $BUILDDIR/$pkg || (chflags -R 0 $BUILDDIR/$pkg; rm -rf $BUILDDIR/$pkg) else $MAKE -C $port clean fi return $status } build /usr/ports/x11/xorg --Boundary-01=_wsxXLim1PzKXdFE-- --nextPart1388239.PjsOTXcBQ3 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEABECAAYFAktfGzMACgkQUaaFgP9pFrLAPQCePKUE4t5Sz7bT/Yy9trU/YNwV TQQAniGCV2Q66PUyOCz3B4UY5+alJVZY =UhXd -----END PGP SIGNATURE----- --nextPart1388239.PjsOTXcBQ3-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 26 21:16:53 2010 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 930271065679 for ; Tue, 26 Jan 2010 21:16:53 +0000 (UTC) (envelope-from jroberson@jroberson.net) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 2B7928FC1B for ; Tue, 26 Jan 2010 21:16:52 +0000 (UTC) Received: by bwz5 with SMTP id 5so4097095bwz.3 for ; Tue, 26 Jan 2010 13:16:52 -0800 (PST) Received: by 10.204.15.140 with SMTP id k12mr434190bka.63.1264540611979; Tue, 26 Jan 2010 13:16:51 -0800 (PST) Received: from ?10.0.1.198? (udp022762uds.hawaiiantel.net [72.234.79.107]) by mx.google.com with ESMTPS id 13sm2870379bwz.6.2010.01.26.13.16.42 (version=SSLv3 cipher=RC4-MD5); Tue, 26 Jan 2010 13:16:44 -0800 (PST) Date: Tue, 26 Jan 2010 11:21:05 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: Gary Jennejohn In-Reply-To: <20100126141310.23cb08fa@ernst.jennejohn.org> Message-ID: References: <20100126141310.23cb08fa@ernst.jennejohn.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: freebsd-current@freebsd.org Subject: Re: SUJ testing update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jan 2010 21:16:53 -0000 On Tue, 26 Jan 2010, Gary Jennejohn wrote: > On Mon, 25 Jan 2010 13:38:41 -1000 (HST) > Jeff Roberson wrote: > >> I just committed some big changes to suj to svn at >> svn://svn.freebsd.org/base/projects/suj/head >> >> You can now run softdep without journaling again. The fast journal >> checker is enabled. You need only use tunefs -j enable or tunefs -j >> disable. >> >> The SUJ flag in the filesystem moved for backwards compat reasons. If you >> have an earlier SUJ volume please disable it with the old tunefs and >> enable again with the new tunefs. >> > > Upadating my old SUJ volumess worked for me. > >> I'll be making a few more minor changes before I commit to HEAD but we're >> pretty close. Please give it a go and make sure it works for you! >> > > One thing I liked about the last patch was that the output of mount(8) > showed "soft-updates journal." Any plans to put that back? Unfortunately the MNT_* flags namespace is full and I had used an overlapping flag. Unless we can garbage collect some space I don't know if it will return. I liked it too. Thanks, Jeff > > --- > Gary Jennejohn > From owner-freebsd-current@FreeBSD.ORG Tue Jan 26 21:34:53 2010 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 00B69106568D for ; Tue, 26 Jan 2010 21:34:53 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 429608FC1D for ; Tue, 26 Jan 2010 21:34:51 +0000 (UTC) Received: by ewy10 with SMTP id 10so470170ewy.3 for ; Tue, 26 Jan 2010 13:34:51 -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; bh=TDhF1KDLIyHIE4xM3v/RxF2RwdnnYJTl28mcdcRz1X4=; b=rTrf7NVVW0gm4fms2vY+8G2BV0un8wXrdlkq10QCQeL6/7iWhq247082SmV3v7/1Yv SXdavfTZcMPkp7TN+ilqNws5weLh56NKfAC0d/8yZF4CYweImDmbZtqIz/0a7zpbDZzg llq5bVJFlcM9yhgCOhIRfpTmlIz9bWg6OXKWk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=NxtaTAMjZUi7jr/YGiaRytOgNDINmpDZa7PhncxFv/t/AgcPHN+RWYeHTL7j+Edh74 MbAVdUTVPDH6y0tjf6sEZD2dR8snjxHo80vk2VqSQJs9uPlsy6StBZLMj29lJj/kxACK j9K/pWVQbnOgkYGB05koQHaHbqD0R28xRHp1E= MIME-Version: 1.0 Received: by 10.213.47.206 with SMTP id o14mr1792859ebf.11.1264541690755; Tue, 26 Jan 2010 13:34:50 -0800 (PST) Date: Tue, 26 Jan 2010 16:34:50 -0500 Message-ID: From: Ryan Stone To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary=001485e9a6c647fa15047e180e11 Cc: jasone@freebsd.org Subject: Missing return in malloc.c:arena_dalloc? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jan 2010 21:34:53 -0000 --001485e9a6c647fa15047e180e11 Content-Type: text/plain; charset=ISO-8859-1 I think that there is a bug in the magazine allocator in jemalloc that can cause a segfault in certain rare conditions. It looks to me like a return is missing: *** malloc.c (revision 203047) --- malloc.c (working copy) *************** *** 3793,3812 **** --- 3793,3813 ---- #ifdef MALLOC_MAG if (__isthreaded && opt_mag) { mag_rack_t *rack = mag_rack; if (rack == NULL) { rack = mag_rack_create(arena); if (rack == NULL) { malloc_spin_lock(&arena->lock); arena_dalloc_small(arena, chunk, ptr, mapelm); malloc_spin_unlock(&arena->lock); + return; } mag_rack = rack; } mag_rack_dalloc(rack, ptr); } else { #endif malloc_spin_lock(&arena->lock); arena_dalloc_small(arena, chunk, ptr, mapelm); malloc_spin_unlock(&arena->lock); #ifdef MALLOC_MAG The logic here seems to be, "if the magazine option is enabled, try to get the magazine rack out of the TLS variable mag_rack. If we haven't yet allocated a rack for this thread, try to create one with mag_rack_create. If we fail to allocate the rack, then free the memory directly to the arena. Currently, after freeing to the arena the code falls-through and tries to free the memory to a NULL rack, which can't possibly be right. mag_rack_dalloc definitely can't handle a NULL rack. It seems to me that the intent here is to return after calling arena_dalloc_small? There's a similar case in mag_rack_dalloc where it tries to allocate a magazine, and if it fails, it calls arena_dalloc_small and then returns. Note that gmail has mangled the tabs in the diff I pasted above, so I'm attaching a correct version as a patch. --001485e9a6c647fa15047e180e11 Content-Type: application/octet-stream; name="malloc.diff" Content-Disposition: attachment; filename="malloc.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_g4x7g2qa0 SW5kZXg6IG1hbGxvYy5jDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoqKiogbWFsbG9jLmMJKHJldmlzaW9uIDIwMzA0 NykKLS0tIG1hbGxvYy5jCSh3b3JraW5nIGNvcHkpCioqKioqKioqKioqKioqKgoqKiogMzc5Mywz ODEyICoqKioKLS0tIDM3OTMsMzgxMyAtLS0tCiAgI2lmZGVmIE1BTExPQ19NQUcKICAJCWlmIChf X2lzdGhyZWFkZWQgJiYgb3B0X21hZykgewogIAkJCW1hZ19yYWNrX3QgKnJhY2sgPSBtYWdfcmFj azsKICAJCQlpZiAocmFjayA9PSBOVUxMKSB7CiAgCQkJCXJhY2sgPSBtYWdfcmFja19jcmVhdGUo YXJlbmEpOwogIAkJCQlpZiAocmFjayA9PSBOVUxMKSB7CiAgCQkJCQltYWxsb2Nfc3Bpbl9sb2Nr KCZhcmVuYS0+bG9jayk7CiAgCQkJCQlhcmVuYV9kYWxsb2Nfc21hbGwoYXJlbmEsIGNodW5rLCBw dHIsCiAgCQkJCQkgICAgbWFwZWxtKTsKICAJCQkJCW1hbGxvY19zcGluX3VubG9jaygmYXJlbmEt PmxvY2spOworIAkJCQkJcmV0dXJuOwogIAkJCQl9CiAgCQkJCW1hZ19yYWNrID0gcmFjazsKICAJ CQl9CiAgCQkJbWFnX3JhY2tfZGFsbG9jKHJhY2ssIHB0cik7CiAgCQl9IGVsc2UgewogICNlbmRp ZgogIAkJCW1hbGxvY19zcGluX2xvY2soJmFyZW5hLT5sb2NrKTsKICAJCQlhcmVuYV9kYWxsb2Nf c21hbGwoYXJlbmEsIGNodW5rLCBwdHIsIG1hcGVsbSk7CiAgCQkJbWFsbG9jX3NwaW5fdW5sb2Nr KCZhcmVuYS0+bG9jayk7CiAgI2lmZGVmIE1BTExPQ19NQUcK --001485e9a6c647fa15047e180e11-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 26 22:23:40 2010 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 9D38B106568B; Tue, 26 Jan 2010 22:23:40 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) by mx1.freebsd.org (Postfix) with ESMTP id 056E28FC12; Tue, 26 Jan 2010 22:23:40 +0000 (UTC) Received: from toad.stack.nl (toad.stack.nl [IPv6:2001:610:1108:5010::135]) by mx1.stack.nl (Postfix) with ESMTP id F12E51DD643; Tue, 26 Jan 2010 23:23:38 +0100 (CET) Received: by toad.stack.nl (Postfix, from userid 1677) id D5E0E73F9D; Tue, 26 Jan 2010 23:23:38 +0100 (CET) Date: Tue, 26 Jan 2010 23:23:38 +0100 From: Jilles Tjoelker To: =?iso-8859-1?Q?G=E1bor_K=F6vesd=E1n?= Message-ID: <20100126222338.GA40281@stack.nl> References: <20100119212019.GL59590@deviant.kiev.zoral.com.ua> <4B56CACF.50508@FreeBSD.org> <4B5B4F4B.3030201@FreeBSD.org> <20100124091911.GI31243@server.vk2pj.dyndns.org> <4B5C27B9.1080805@FreeBSD.org> <20100124113718.GC3877@deviant.kiev.zoral.com.ua> <4B5CD916.1060003@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4B5CD916.1060003@FreeBSD.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Hajimu UMEMOTO , Peter Jeremy , attilio@freebsd.org, Kostik Belousov , Xin LI , current@freebsd.org Subject: Re: NLS/strerror efficiency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jan 2010 22:23:40 -0000 On Mon, Jan 25, 2010 at 12:34:46AM +0100, Gábor Kövesdán wrote: > Kostik Belousov wrote: > >> I'll fix up my patch to do that. > >> > Here's my new patch with a little program to demonstrate that it works > as expected even if locale is changed between various > strerror(3)/strsignal(3) calls. This idea seems sensible, but I have some comments. > Index: nls/msgcat.c > =================================================================== > --- nls/msgcat.c (revisi?n: 202658) > +++ nls/msgcat.c (copia de trabajo) > +#define RLOCK(fail) { if (_pthread_rwlock_rdlock(&rwlock) != 0) return (fail); } > +#define WLOCK(fail) { if (_pthread_rwlock_wrlock(&rwlock) != 0) return (fail); } > +#define UNLOCK(fail) { if (_pthread_rwlock_unlock(&rwlock) != 0) return (fail); } > + > +#define SAVEFAIL(n, e) { WLOCK(NLERR); \ > + np = malloc(sizeof(struct catentry)); \ > + if (np != NULL) { \ > + np->name = strdup(n); \ > + np->caterrno = e; \ > + SLIST_INSERT_HEAD(&flist, np, list); \ > + } \ > + UNLOCK(NLERR); \ > + } These may return from the function if locking operations fail. They do this without setting errno to a sensible value. > -static nl_catd load_msgcat(const char *); > +static nl_catd load_msgcat(const char *, const char *, const char *); > > +static pthread_rwlock_t rwlock; Use PTHREAD_RWLOCK_INITIALIZER here to avoid problems with initializing the lock. > +struct catentry { > + SLIST_ENTRY(catentry) list; > + char *name; > + char *path; > + int caterrno; > + nl_catd catd; > + char *lang; > + int refcount; > +}; > + > +SLIST_HEAD(listhead, catentry) flist = > + SLIST_HEAD_INITIALIZER(flist); > + > nl_catd > catopen(const char *name, int type) > { > - int spcleft, saverr; > - char path[PATH_MAX]; > - char *nlspath, *lang, *base, *cptr, *pathP, *tmpptr; > - char *cptr1, *plang, *pter, *pcode; > - struct stat sbuf; > + int spcleft, saverr; > + char path[PATH_MAX]; > + char *nlspath, *lang, *base, *cptr, *pathP, *tmpptr; > + char *cptr1, *plang, *pter, *pcode; > + struct stat sbuf; > + struct catentry *np; > > if (name == NULL || *name == '\0') > NLRETERR(EINVAL); > > - /* is it absolute path ? if yes, load immediately */ > if (strchr(name, '/') != NULL) > - return (load_msgcat(name)); > + lang = NULL; > + else { > + if (type == NL_CAT_LOCALE) > + lang = setlocale(LC_MESSAGES, NULL); > + else > + lang = getenv("LANG"); > > - if (type == NL_CAT_LOCALE) > - lang = setlocale(LC_MESSAGES, NULL); > - else > - lang = getenv("LANG"); > + if (lang == NULL || *lang == '\0' || strlen(lang) > ENCODING_LEN || > + (lang[0] == '.' && > + (lang[1] == '\0' || (lang[1] == '.' && lang[2] == '\0'))) || > + strchr(lang, '/') != NULL) > + lang = "C"; > + } > > - if (lang == NULL || *lang == '\0' || strlen(lang) > ENCODING_LEN || > - (lang[0] == '.' && > - (lang[1] == '\0' || (lang[1] == '.' && lang[2] == '\0'))) || > - strchr(lang, '/') != NULL) > - lang = "C"; > + /* Init rwlock used to protect cache */ > + if ((rwlock == (pthread_rwlock_t)0) && > + (_pthread_rwlock_init(&rwlock, NULL) != 0)) > + return (NLERR); > > + /* Try to get it from the cache first */ > + RLOCK(NLERR); > + SLIST_FOREACH(np, &flist, list) { > + if (strcmp(np->name, name) == 0) { > + if (np->caterrno != 0) { > + /* Found cached failing entry */ Hmm, so an error for one language makes it give up for all other languages too? It is possible that a catalog is only available in a few languages. > + UNLOCK(NLERR); > + NLRETERR(np->caterrno); > + } else if (strcmp(np->lang, lang) == 0) { Some code below can apparently set np->lang = NULL, how does that work? > + /* Found cached successful entry */ > + np->refcount++; > + UNLOCK(NLERR); np leaked if unlock fails. > + return (np->catd); > + } > + } > + } > + UNLOCK(NLERR); > + > + /* is it absolute path ? if yes, load immediately */ > + if (strchr(name, '/') != NULL) > + return (load_msgcat(name, name, lang)); > + > if ((plang = cptr1 = strdup(lang)) == NULL) > return (NLERR); > if ((cptr = strchr(cptr1, '@')) != NULL) > @@ -166,7 +225,7 @@ > if (stat(path, &sbuf) == 0) { > free(plang); > free(base); > - return (load_msgcat(path)); > + return (load_msgcat(path, name, lang)); > } > } else { > tmpptr = (char *)name; > @@ -182,20 +241,20 @@ > char * > catgets(nl_catd catd, int set_id, int msg_id, const char *s) > { > - struct _nls_cat_hdr *cat_hdr; > - struct _nls_set_hdr *set_hdr; > - struct _nls_msg_hdr *msg_hdr; > - int l, u, i, r; > + struct _nls_cat_hdr *cat_hdr; > + struct _nls_set_hdr *set_hdr; > + struct _nls_msg_hdr *msg_hdr; > + int l, u, i, r; > > if (catd == NULL || catd == NLERR) { > errno = EBADF; > /* LINTED interface problem */ > - return (char *) s; > -} > + return ((char *)s); > + } > > cat_hdr = (struct _nls_cat_hdr *)catd->__data; > set_hdr = (struct _nls_set_hdr *)(void *)((char *)catd->__data > - + sizeof(struct _nls_cat_hdr)); > + + sizeof(struct _nls_cat_hdr)); > > /* binary search, see knuth algorithm b */ > l = 0; > @@ -228,7 +287,7 @@ > } else { > l = i + 1; > } > -} > + } > > /* not found */ > goto notfound; > @@ -238,25 +297,41 @@ > } else { > l = i + 1; > } > -} > + } > > notfound: > /* not found */ > errno = ENOMSG; > /* LINTED interface problem */ > - return (char *) s; > + return ((char *)s); > } > > int > catclose(nl_catd catd) > { > + struct catentry *np; > + > if (catd == NULL || catd == NLERR) { > errno = EBADF; > return (-1); > } > > - munmap(catd->__data, (size_t)catd->__size); > - free(catd); > + /* Remove from cache if not referenced any more */ > + WLOCK(-1); > + SLIST_FOREACH(np, &flist, list) { > + if ((np->catd->__size == catd->__size) && > + memcmp((const void *)np->catd, (const void *)catd, np->catd->__size) == 0) { Hmm, why not simply if (catd == np->catd) here? > + np->refcount--; > + if (np->refcount == 0) { > + munmap(catd->__data, (size_t)catd->__size); > + free(catd); > + SLIST_REMOVE(&flist, np, catentry, list); > + free(np); The two or three strings in np need to be freed too. > + } > + break; > + } > + } > + UNLOCK(-1); > return (0); > } > > @@ -265,19 +340,38 @@ > */ > > static nl_catd > -load_msgcat(const char *path) > +load_msgcat(const char *path, const char *name, const char *lang) > { > - struct stat st; > - nl_catd catd; > - void *data; > - int fd; > + struct stat st; > + nl_catd catd; > + struct catentry *np; > + void *data; > + int fd; > > - /* XXX: path != NULL? */ > + if (path == NULL) { > + errno = EINVAL; > + return (NLERR); > + } > > - if ((fd = _open(path, O_RDONLY)) == -1) > + /* One more try in cache; if it was not found by name, > + it might still be found by absolute path. */ > + RLOCK(NLERR); > + SLIST_FOREACH(np, &flist, list) { > + if (strcmp(np->path, path) == 0) { > + np->refcount++; > + UNLOCK(NLERR); np leaked if unlock fails. > + return (np->catd); > + } > + } > + UNLOCK(NLERR); > + > + if ((fd = _open(path, O_RDONLY)) == -1) { > + SAVEFAIL(name, errno); > return (NLERR); > + } > > if (_fstat(fd, &st) != 0) { > + SAVEFAIL(name, errno); fd not closed if locking fails. > _close(fd); > return (NLERR); > } > @@ -286,22 +380,39 @@ > (off_t)0); > _close(fd); > > - if (data == MAP_FAILED) > + if (data == MAP_FAILED) { > + SAVEFAIL(name, errno); > return (NLERR); > + } > > if (ntohl((u_int32_t)((struct _nls_cat_hdr *)data)->__magic) != > _NLS_MAGIC) { > + SAVEFAIL(name, errno); data still mapped if locking fails. > munmap(data, (size_t)st.st_size); > NLRETERR(EINVAL); > } > > if ((catd = malloc(sizeof (*catd))) == NULL) { > + SAVEFAIL(name, errno); data still mapped if locking fails. > munmap(data, (size_t)st.st_size); > return (NLERR); > } > > catd->__data = data; > catd->__size = (int)st.st_size; > + > + /* Caching opened catalog */ > + WLOCK(NLERR); > + if ((np = malloc(sizeof(struct catentry))) != NULL) { > + np->name = strdup(name); > + np->path = strdup(path); > + np->catd = catd; > + np->lang = (lang == NULL) ? NULL : strdup(lang); > + np->refcount = 1; > + np->caterrno = 0; > + SLIST_INSERT_HEAD(&flist, np, list); > + } > + UNLOCK(NLERR); np leaked if unlock fails. > return (catd); > } -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Tue Jan 26 23:27:13 2010 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 6868C106566B for ; Tue, 26 Jan 2010 23:27:13 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 281E98FC0C for ; Tue, 26 Jan 2010 23:27:13 +0000 (UTC) Received: from isis.bris.ac.uk ([137.222.10.63]) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1NZuoO-0005PV-VE for freebsd-current@freebsd.org; Tue, 26 Jan 2010 23:27:12 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by isis.bris.ac.uk with esmtp (Exim 4.67) (envelope-from ) id 1NZuoO-0000mE-01 for freebsd-current@freebsd.org; Tue, 26 Jan 2010 23:27:08 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.3/8.14.3) with ESMTP id o0QNR7Yw057481 for ; Tue, 26 Jan 2010 23:27:07 GMT (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.3/8.14.3/Submit) id o0QNR70E057469 for freebsd-current@freebsd.org; Tue, 26 Jan 2010 23:27:07 GMT (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Tue, 26 Jan 2010 23:27:07 +0000 From: Anton Shterenlikht To: freebsd-current@freebsd.org Message-ID: <20100126232707.GG26462@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -1.4 X-Spam-Level: - Subject: can't load smbfs kernel module X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Jan 2010 23:27:13 -0000 I didn't get any luck asking in questions@, so maybe this is a current@ issue: On Mon, Jan 25, 2010 at 09:56:54PM +0000, Anton Shterenlikht wrote: > On Mon, Jan 25, 2010 at 10:38:47AM -0600, Kevin Kinsey wrote: > > Anton Shterenlikht wrote: > > > This is on FreeBSD 9.0-CURRENT #0 r202964M ia64 > > > > > > I've built a kernel with smbfs module: > > > > > > # ls -al /boot/kernel/smb* > > > -r-xr-xr-x 1 root wheel 265579 25 Jan 13:36 /boot/kernel/smbfs.ko > > > -r-xr-xr-x 1 root wheel 680186 25 Jan 13:36 /boot/kernel/smbfs.ko.symbols > > > > > > but can't load it: > > > > > > # kldload smbfs > > > kldload: can't load smbfs: No such file or directory > > > > > > > > > Other modules load fine with kldload, e.g.: > > > > Does it make any difference to use the ".ko" extension, to > > call it by absolute path, or to use "-v" for more information, > > per The Friendly Manual? > > no, doesn't make any difference: > > # kldload -v /boot/kernel/smbfs.ko > kldload: can't load /boot/kernel/smbfs.ko: No such file or directory > # > > but I see in /var/log/messages: > > kernel: KLD smbfs.ko: depends on libiconv - not available or version mismatch > > I've rebuilt world, rebuilt and reinstalled kernel, installed world, > and merged, etc., including rm -rf /usr/obj/* , so there shouldn't > be any version mismatch. > > Is there a way to debug this further? well.. maybe this is irrelevant, but I disovered that there is actually a module libiconv, despite the fact that there are already libiconv lib built with the base OS: > ls -al /usr/local/lib/libiconv.* -rw-r--r-- 1 root wheel 1113476 4 Aug 22:40 /usr/local/lib/libiconv.a -r--r--r-- 1 root wheel 920 4 Aug 22:40 /usr/local/lib/libiconv.la lrwxr-xr-x 1 root wheel 13 4 Aug 22:40 /usr/local/lib/libiconv.so -> libiconv.so.3 -r--r--r-- 1 root wheel 1102764 4 Aug 22:40 /usr/local/lib/libiconv.so.3 Anyway, I've built the libiconv module, and loaded it to the kernel, but still get the same error trying to load smbfs. Please advise many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ----- End forwarded message ----- -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Tue Jan 26 23:49:41 2010 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 E11361065698; Tue, 26 Jan 2010 23:49:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 734BC8FC13; Tue, 26 Jan 2010 23:49:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0QNne9i025230; Tue, 26 Jan 2010 18:49:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0QNnexq025225; Tue, 26 Jan 2010 23:49:40 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 26 Jan 2010 23:49:40 GMT Message-Id: <201001262349.o0QNnexq025225@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Tue, 26 Jan 2010 23:49:42 -0000 TB --- 2010-01-26 22:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-26 22:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-01-26 22:10:00 - cleaning the object tree TB --- 2010-01-26 22:10:25 - cvsupping the source tree TB --- 2010-01-26 22:10:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-01-26 22:18:15 - building world TB --- 2010-01-26 22:18:15 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-26 22:18:15 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-26 22:18:15 - TARGET=amd64 TB --- 2010-01-26 22:18:15 - TARGET_ARCH=amd64 TB --- 2010-01-26 22:18:15 - TZ=UTC TB --- 2010-01-26 22:18:15 - __MAKE_CONF=/dev/null TB --- 2010-01-26 22:18:15 - cd /src TB --- 2010-01-26 22:18:15 - /usr/bin/make -B buildworld >>> World build started on Tue Jan 26 22:18:15 UTC 2010 >>> 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 >>> World build completed on Tue Jan 26 23:44:30 UTC 2010 TB --- 2010-01-26 23:44:30 - generating LINT kernel config TB --- 2010-01-26 23:44:30 - cd /src/sys/amd64/conf TB --- 2010-01-26 23:44:30 - /usr/bin/make -B LINT TB --- 2010-01-26 23:44:30 - building LINT kernel TB --- 2010-01-26 23:44:30 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-26 23:44:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-26 23:44:30 - TARGET=amd64 TB --- 2010-01-26 23:44:30 - TARGET_ARCH=amd64 TB --- 2010-01-26 23:44:30 - TZ=UTC TB --- 2010-01-26 23:44:30 - __MAKE_CONF=/dev/null TB --- 2010-01-26 23:44:30 - cd /src TB --- 2010-01-26 23:44:30 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jan 26 23:44:30 UTC 2010 >>> 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 -frename-registers -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-micron.c cc -c -O2 -frename-registers -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-national.c cc -c -O2 -frename-registers -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-netcell.c cc -c -O2 -frename-registers -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-nvidia.c cc -c -O2 -frename-registers -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ata/chipsets/ata-promise.c cc1: warnings being treated as errors /src/sys/dev/ata/chipsets/ata-promise.c: In function 'ata_promise_mio_status': /src/sys/dev/ata/chipsets/ata-promise.c:631: warning: cast from pointer to integer of different size *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-26 23:49:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-26 23:49:40 - ERROR: failed to build lint kernel TB --- 2010-01-26 23:49:40 - 4024.88 user 940.25 system 5979.32 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 00:24:22 2010 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 3CEDB106568B; Wed, 27 Jan 2010 00:24:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 0A42F8FC21; Wed, 27 Jan 2010 00:24:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0R0OKHH098673; Tue, 26 Jan 2010 19:24:20 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0R0OKvr098664; Wed, 27 Jan 2010 00:24:20 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Jan 2010 00:24:20 GMT Message-Id: <201001270024.o0R0OKvr098664@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Wed, 27 Jan 2010 00:24:22 -0000 TB --- 2010-01-26 23:00:59 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-26 23:00:59 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-01-26 23:00:59 - cleaning the object tree TB --- 2010-01-26 23:01:19 - cvsupping the source tree TB --- 2010-01-26 23:01:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-01-26 23:02:28 - building world TB --- 2010-01-26 23:02:28 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-26 23:02:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-26 23:02:28 - TARGET=ia64 TB --- 2010-01-26 23:02:28 - TARGET_ARCH=ia64 TB --- 2010-01-26 23:02:28 - TZ=UTC TB --- 2010-01-26 23:02:28 - __MAKE_CONF=/dev/null TB --- 2010-01-26 23:02:28 - cd /src TB --- 2010-01-26 23:02:28 - /usr/bin/make -B buildworld >>> World build started on Tue Jan 26 23:02:28 UTC 2010 >>> 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 Wed Jan 27 00:19:19 UTC 2010 TB --- 2010-01-27 00:19:19 - generating LINT kernel config TB --- 2010-01-27 00:19:19 - cd /src/sys/ia64/conf TB --- 2010-01-27 00:19:19 - /usr/bin/make -B LINT TB --- 2010-01-27 00:19:19 - building LINT kernel TB --- 2010-01-27 00:19:19 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 00:19:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 00:19:19 - TARGET=ia64 TB --- 2010-01-27 00:19:19 - TARGET_ARCH=ia64 TB --- 2010-01-27 00:19:19 - TZ=UTC TB --- 2010-01-27 00:19:19 - __MAKE_CONF=/dev/null TB --- 2010-01-27 00:19:19 - cd /src TB --- 2010-01-27 00:19:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jan 27 00:19:19 UTC 2010 >>> 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 -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-micron.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 -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-national.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 -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-netcell.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 -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-nvidia.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 -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding -Werror /src/sys/dev/ata/chipsets/ata-promise.c cc1: warnings being treated as errors /src/sys/dev/ata/chipsets/ata-promise.c: In function 'ata_promise_mio_status': /src/sys/dev/ata/chipsets/ata-promise.c:631: warning: cast from pointer to integer of different size *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-27 00:24:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-27 00:24:20 - ERROR: failed to build lint kernel TB --- 2010-01-27 00:24:20 - 3861.90 user 654.45 system 5000.76 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 00:54:06 2010 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 06E3110656EB; Wed, 27 Jan 2010 00:54:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id B2B6E8FC0C; Wed, 27 Jan 2010 00:54:05 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0R0s4aJ007187; Tue, 26 Jan 2010 19:54:04 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0R0s4hi007177; Wed, 27 Jan 2010 00:54:04 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Jan 2010 00:54:04 GMT Message-Id: <201001270054.o0R0s4hi007177@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Wed, 27 Jan 2010 00:54:06 -0000 TB --- 2010-01-26 23:49:40 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-26 23:49:40 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-01-26 23:49:40 - cleaning the object tree TB --- 2010-01-26 23:49:55 - cvsupping the source tree TB --- 2010-01-26 23:49:55 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-01-26 23:50:11 - building world TB --- 2010-01-26 23:50:11 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-26 23:50:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-26 23:50:11 - TARGET=powerpc TB --- 2010-01-26 23:50:11 - TARGET_ARCH=powerpc TB --- 2010-01-26 23:50:11 - TZ=UTC TB --- 2010-01-26 23:50:11 - __MAKE_CONF=/dev/null TB --- 2010-01-26 23:50:11 - cd /src TB --- 2010-01-26 23:50:11 - /usr/bin/make -B buildworld >>> World build started on Tue Jan 26 23:50:12 UTC 2010 >>> 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 Wed Jan 27 00:50:04 UTC 2010 TB --- 2010-01-27 00:50:04 - generating LINT kernel config TB --- 2010-01-27 00:50:04 - cd /src/sys/powerpc/conf TB --- 2010-01-27 00:50:04 - /usr/bin/make -B LINT TB --- 2010-01-27 00:50:04 - building LINT kernel TB --- 2010-01-27 00:50:04 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 00:50:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 00:50:04 - TARGET=powerpc TB --- 2010-01-27 00:50:04 - TARGET_ARCH=powerpc TB --- 2010-01-27 00:50:04 - TZ=UTC TB --- 2010-01-27 00:50:04 - __MAKE_CONF=/dev/null TB --- 2010-01-27 00:50:04 - cd /src TB --- 2010-01-27 00:50:04 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jan 27 00:50:04 UTC 2010 >>> 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/dev/e1000/if_em.c:5291: error: 'struct adapter' has no member named 'mbuf_cluster_failed' /src/sys/dev/e1000/if_em.c: In function 'em_print_hw_stats': /src/sys/dev/e1000/if_em.c:5332: error: 'struct adapter' has no member named 'rx_irq' /src/sys/dev/e1000/if_em.c:5333: error: 'struct adapter' has no member named 'tx_irq' /src/sys/dev/e1000/if_em.c:5333: warning: format '%ld' expects type 'long int', but argument 5 has type 'int' /src/sys/dev/e1000/if_em.c: In function 'em_sysctl_int_delay': /src/sys/dev/e1000/if_em.c:5462: error: 'struct adapter' has no member named 'txd_cmd' /src/sys/dev/e1000/if_em.c:5466: error: 'struct adapter' has no member named 'txd_cmd' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-27 00:54:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-27 00:54:04 - ERROR: failed to build lint kernel TB --- 2010-01-27 00:54:04 - 2932.91 user 612.20 system 3864.36 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 01:08:31 2010 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 739261065696; Wed, 27 Jan 2010 01:08:31 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 35EAA8FC12; Wed, 27 Jan 2010 01:08:30 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0R18UNF066466; Tue, 26 Jan 2010 20:08:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0R18UZf066465; Wed, 27 Jan 2010 01:08:30 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Jan 2010 01:08:30 GMT Message-Id: <201001270108.o0R18UZf066465@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Wed, 27 Jan 2010 01:08:31 -0000 TB --- 2010-01-27 00:09:51 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-27 00:09:51 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-01-27 00:09:51 - cleaning the object tree TB --- 2010-01-27 00:10:13 - cvsupping the source tree TB --- 2010-01-27 00:10:13 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-01-27 00:10:26 - building world TB --- 2010-01-27 00:10:26 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 00:10:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 00:10:26 - TARGET=sparc64 TB --- 2010-01-27 00:10:26 - TARGET_ARCH=sparc64 TB --- 2010-01-27 00:10:26 - TZ=UTC TB --- 2010-01-27 00:10:26 - __MAKE_CONF=/dev/null TB --- 2010-01-27 00:10:26 - cd /src TB --- 2010-01-27 00:10:26 - /usr/bin/make -B buildworld >>> World build started on Wed Jan 27 00:10:27 UTC 2010 >>> 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 Wed Jan 27 01:05:14 UTC 2010 TB --- 2010-01-27 01:05:14 - generating LINT kernel config TB --- 2010-01-27 01:05:14 - cd /src/sys/sparc64/conf TB --- 2010-01-27 01:05:14 - /usr/bin/make -B LINT TB --- 2010-01-27 01:05:14 - building LINT kernel TB --- 2010-01-27 01:05:14 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 01:05:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 01:05:14 - TARGET=sparc64 TB --- 2010-01-27 01:05:14 - TARGET_ARCH=sparc64 TB --- 2010-01-27 01:05:14 - TZ=UTC TB --- 2010-01-27 01:05:14 - __MAKE_CONF=/dev/null TB --- 2010-01-27 01:05:14 - cd /src TB --- 2010-01-27 01:05:14 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jan 27 01:05:14 UTC 2010 >>> 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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-micron.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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-national.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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-netcell.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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-nvidia.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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-promise.c cc1: warnings being treated as errors /src/sys/dev/ata/chipsets/ata-promise.c: In function 'ata_promise_mio_status': /src/sys/dev/ata/chipsets/ata-promise.c:631: warning: cast from pointer to integer of different size *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-27 01:08:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-27 01:08:30 - ERROR: failed to build lint kernel TB --- 2010-01-27 01:08:30 - 2726.21 user 592.91 system 3518.30 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 01:21:52 2010 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 2C2821065692; Wed, 27 Jan 2010 01:21:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C67AE8FC1C; Wed, 27 Jan 2010 01:21:51 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0R1Lo24000590; Tue, 26 Jan 2010 20:21:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0R1Lomx000589; Wed, 27 Jan 2010 01:21:50 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Jan 2010 01:21:50 GMT Message-Id: <201001270121.o0R1Lomx000589@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Wed, 27 Jan 2010 01:21:52 -0000 TB --- 2010-01-27 00:24:20 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-27 00:24:20 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-01-27 00:24:20 - cleaning the object tree TB --- 2010-01-27 00:24:34 - cvsupping the source tree TB --- 2010-01-27 00:24:34 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-01-27 00:24:48 - building world TB --- 2010-01-27 00:24:48 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 00:24:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 00:24:48 - TARGET=sun4v TB --- 2010-01-27 00:24:48 - TARGET_ARCH=sparc64 TB --- 2010-01-27 00:24:48 - TZ=UTC TB --- 2010-01-27 00:24:48 - __MAKE_CONF=/dev/null TB --- 2010-01-27 00:24:48 - cd /src TB --- 2010-01-27 00:24:48 - /usr/bin/make -B buildworld >>> World build started on Wed Jan 27 00:24:49 UTC 2010 >>> 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 Wed Jan 27 01:18:28 UTC 2010 TB --- 2010-01-27 01:18:28 - generating LINT kernel config TB --- 2010-01-27 01:18:28 - cd /src/sys/sun4v/conf TB --- 2010-01-27 01:18:28 - /usr/bin/make -B LINT TB --- 2010-01-27 01:18:28 - building LINT kernel TB --- 2010-01-27 01:18:28 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 01:18:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 01:18:28 - TARGET=sun4v TB --- 2010-01-27 01:18:28 - TARGET_ARCH=sparc64 TB --- 2010-01-27 01:18:28 - TZ=UTC TB --- 2010-01-27 01:18:28 - __MAKE_CONF=/dev/null TB --- 2010-01-27 01:18:28 - cd /src TB --- 2010-01-27 01:18:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jan 27 01:18:28 UTC 2010 >>> 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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-micron.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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-national.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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-netcell.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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-nvidia.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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -Werror /src/sys/dev/ata/chipsets/ata-promise.c cc1: warnings being treated as errors /src/sys/dev/ata/chipsets/ata-promise.c: In function 'ata_promise_mio_status': /src/sys/dev/ata/chipsets/ata-promise.c:631: warning: cast from pointer to integer of different size *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-27 01:21:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-27 01:21:50 - ERROR: failed to build lint kernel TB --- 2010-01-27 01:21:50 - 2736.66 user 577.62 system 3450.12 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 05:35:09 2010 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 697BE106566C for ; Wed, 27 Jan 2010 05:35:09 +0000 (UTC) (envelope-from jasone@FreeBSD.org) Received: from canonware.com (10140.x.rootbsd.net [204.109.63.53]) by mx1.freebsd.org (Postfix) with ESMTP id 4C3D08FC0A for ; Wed, 27 Jan 2010 05:35:09 +0000 (UTC) Received: from [IPv6:::1] (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by canonware.com (Postfix) with ESMTPSA id CEBDC28432; Tue, 26 Jan 2010 21:16:14 -0800 (PST) Message-ID: <4B5FCC1E.7040909@FreeBSD.org> Date: Tue, 26 Jan 2010 21:16:14 -0800 From: Jason Evans User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Ryan Stone References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Missing return in malloc.c:arena_dalloc? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jan 2010 05:35:09 -0000 Ryan Stone wrote: > I think that there is a bug in the magazine allocator in jemalloc that > can cause a segfault in certain rare conditions. Yes, you're right about the bug. I recently moved, and my development machines are still in boxes, but I'll try to get one unpacked this weekend and check in the fix if no one beats me to it. Thanks for the bug report. Jason From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 09:11:22 2010 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 1473F106568F; Wed, 27 Jan 2010 09:11:22 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E02A88FC16; Wed, 27 Jan 2010 09:11:21 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0R9BLgJ084721; Wed, 27 Jan 2010 04:11:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0R9BLQG084720; Wed, 27 Jan 2010 09:11:21 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Jan 2010 09:11:21 GMT Message-Id: <201001270911.o0R9BLQG084720@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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, 27 Jan 2010 09:11:22 -0000 TB --- 2010-01-27 08:05:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-27 08:05:01 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-01-27 08:05:01 - cleaning the object tree TB --- 2010-01-27 08:05:33 - cvsupping the source tree TB --- 2010-01-27 08:05:33 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-01-27 08:06:57 - building world TB --- 2010-01-27 08:06:57 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 08:06:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 08:06:57 - TARGET=pc98 TB --- 2010-01-27 08:06:57 - TARGET_ARCH=i386 TB --- 2010-01-27 08:06:57 - TZ=UTC TB --- 2010-01-27 08:06:57 - __MAKE_CONF=/dev/null TB --- 2010-01-27 08:06:57 - cd /src TB --- 2010-01-27 08:06:57 - /usr/bin/make -B buildworld >>> World build started on Wed Jan 27 08:06:58 UTC 2010 >>> 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 Wed Jan 27 09:06:11 UTC 2010 TB --- 2010-01-27 09:06:11 - generating LINT kernel config TB --- 2010-01-27 09:06:11 - cd /src/sys/pc98/conf TB --- 2010-01-27 09:06:11 - /usr/bin/make -B LINT TB --- 2010-01-27 09:06:11 - building LINT kernel TB --- 2010-01-27 09:06:11 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 09:06:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 09:06:11 - TARGET=pc98 TB --- 2010-01-27 09:06:11 - TARGET_ARCH=i386 TB --- 2010-01-27 09:06:11 - TZ=UTC TB --- 2010-01-27 09:06:11 - __MAKE_CONF=/dev/null TB --- 2010-01-27 09:06:11 - cd /src TB --- 2010-01-27 09:06:11 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jan 27 09:06:11 UTC 2010 >>> 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/dev/e1000/if_em.c:5291: error: 'struct adapter' has no member named 'mbuf_cluster_failed' /src/sys/dev/e1000/if_em.c: In function 'em_print_hw_stats': /src/sys/dev/e1000/if_em.c:5332: error: 'struct adapter' has no member named 'rx_irq' /src/sys/dev/e1000/if_em.c:5333: error: 'struct adapter' has no member named 'tx_irq' /src/sys/dev/e1000/if_em.c:5333: warning: format '%ld' expects type 'long int', but argument 5 has type 'int' /src/sys/dev/e1000/if_em.c: In function 'em_sysctl_int_delay': /src/sys/dev/e1000/if_em.c:5462: error: 'struct adapter' has no member named 'txd_cmd' /src/sys/dev/e1000/if_em.c:5466: error: 'struct adapter' has no member named 'txd_cmd' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-27 09:11:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-27 09:11:21 - ERROR: failed to build lint kernel TB --- 2010-01-27 09:11:21 - 2850.16 user 693.27 system 3980.06 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 09:13:07 2010 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 6104B1065693; Wed, 27 Jan 2010 09:13:07 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1EB258FC1A; Wed, 27 Jan 2010 09:13:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0R9D61X098836; Wed, 27 Jan 2010 04:13:06 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0R9D6ao098814; Wed, 27 Jan 2010 09:13:06 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Jan 2010 09:13:06 GMT Message-Id: <201001270913.o0R9D6ao098814@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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, 27 Jan 2010 09:13:07 -0000 TB --- 2010-01-27 08:05:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-27 08:05:01 - starting HEAD tinderbox run for i386/i386 TB --- 2010-01-27 08:05:01 - cleaning the object tree TB --- 2010-01-27 08:05:35 - cvsupping the source tree TB --- 2010-01-27 08:05:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-01-27 08:06:57 - building world TB --- 2010-01-27 08:06:57 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 08:06:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 08:06:57 - TARGET=i386 TB --- 2010-01-27 08:06:57 - TARGET_ARCH=i386 TB --- 2010-01-27 08:06:57 - TZ=UTC TB --- 2010-01-27 08:06:57 - __MAKE_CONF=/dev/null TB --- 2010-01-27 08:06:57 - cd /src TB --- 2010-01-27 08:06:57 - /usr/bin/make -B buildworld >>> World build started on Wed Jan 27 08:06:58 UTC 2010 >>> 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 Wed Jan 27 09:06:49 UTC 2010 TB --- 2010-01-27 09:06:49 - generating LINT kernel config TB --- 2010-01-27 09:06:49 - cd /src/sys/i386/conf TB --- 2010-01-27 09:06:49 - /usr/bin/make -B LINT TB --- 2010-01-27 09:06:49 - building LINT kernel TB --- 2010-01-27 09:06:49 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 09:06:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 09:06:49 - TARGET=i386 TB --- 2010-01-27 09:06:49 - TARGET_ARCH=i386 TB --- 2010-01-27 09:06:49 - TZ=UTC TB --- 2010-01-27 09:06:49 - __MAKE_CONF=/dev/null TB --- 2010-01-27 09:06:49 - cd /src TB --- 2010-01-27 09:06:49 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jan 27 09:06:49 UTC 2010 >>> 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/dev/e1000/if_em.c:5291: error: 'struct adapter' has no member named 'mbuf_cluster_failed' /src/sys/dev/e1000/if_em.c: In function 'em_print_hw_stats': /src/sys/dev/e1000/if_em.c:5332: error: 'struct adapter' has no member named 'rx_irq' /src/sys/dev/e1000/if_em.c:5333: error: 'struct adapter' has no member named 'tx_irq' /src/sys/dev/e1000/if_em.c:5333: warning: format '%ld' expects type 'long int', but argument 5 has type 'int' /src/sys/dev/e1000/if_em.c: In function 'em_sysctl_int_delay': /src/sys/dev/e1000/if_em.c:5462: error: 'struct adapter' has no member named 'txd_cmd' /src/sys/dev/e1000/if_em.c:5466: error: 'struct adapter' has no member named 'txd_cmd' *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-27 09:13:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-27 09:13:06 - ERROR: failed to build lint kernel TB --- 2010-01-27 09:13:06 - 2935.36 user 698.12 system 4085.50 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 09:38:41 2010 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 DD73E106566C; Wed, 27 Jan 2010 09:38:40 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9C7828FC20; Wed, 27 Jan 2010 09:38:40 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0R9cdvt023418; Wed, 27 Jan 2010 04:38:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0R9cdrI023377; Wed, 27 Jan 2010 09:38:39 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Jan 2010 09:38:39 GMT Message-Id: <201001270938.o0R9cdrI023377@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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, 27 Jan 2010 09:38:41 -0000 TB --- 2010-01-27 08:05:01 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-27 08:05:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-01-27 08:05:01 - cleaning the object tree TB --- 2010-01-27 08:05:31 - cvsupping the source tree TB --- 2010-01-27 08:05:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-01-27 08:06:57 - building world TB --- 2010-01-27 08:06:57 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 08:06:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 08:06:57 - TARGET=amd64 TB --- 2010-01-27 08:06:57 - TARGET_ARCH=amd64 TB --- 2010-01-27 08:06:57 - TZ=UTC TB --- 2010-01-27 08:06:57 - __MAKE_CONF=/dev/null TB --- 2010-01-27 08:06:57 - cd /src TB --- 2010-01-27 08:06:57 - /usr/bin/make -B buildworld >>> World build started on Wed Jan 27 08:06:58 UTC 2010 >>> 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 >>> World build completed on Wed Jan 27 09:32:53 UTC 2010 TB --- 2010-01-27 09:32:53 - generating LINT kernel config TB --- 2010-01-27 09:32:53 - cd /src/sys/amd64/conf TB --- 2010-01-27 09:32:53 - /usr/bin/make -B LINT TB --- 2010-01-27 09:32:53 - building LINT kernel TB --- 2010-01-27 09:32:53 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 09:32:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 09:32:53 - TARGET=amd64 TB --- 2010-01-27 09:32:53 - TARGET_ARCH=amd64 TB --- 2010-01-27 09:32:53 - TZ=UTC TB --- 2010-01-27 09:32:53 - __MAKE_CONF=/dev/null TB --- 2010-01-27 09:32:53 - cd /src TB --- 2010-01-27 09:32:53 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jan 27 09:32:53 UTC 2010 >>> 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/dev/e1000/if_em.c:5291: error: 'struct adapter' has no member named 'mbuf_cluster_failed' /src/sys/dev/e1000/if_em.c: In function 'em_print_hw_stats': /src/sys/dev/e1000/if_em.c:5332: error: 'struct adapter' has no member named 'rx_irq' /src/sys/dev/e1000/if_em.c:5333: error: 'struct adapter' has no member named 'tx_irq' /src/sys/dev/e1000/if_em.c:5333: warning: format '%ld' expects type 'long int', but argument 5 has type 'int' /src/sys/dev/e1000/if_em.c: In function 'em_sysctl_int_delay': /src/sys/dev/e1000/if_em.c:5462: error: 'struct adapter' has no member named 'txd_cmd' /src/sys/dev/e1000/if_em.c:5466: error: 'struct adapter' has no member named 'txd_cmd' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-27 09:38:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-27 09:38:39 - ERROR: failed to build lint kernel TB --- 2010-01-27 09:38:39 - 4079.87 user 959.98 system 5618.66 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 10:18:41 2010 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 809FA1065670; Wed, 27 Jan 2010 10:18:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 3F4BC8FC0C; Wed, 27 Jan 2010 10:18:40 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0RAIexe027759; Wed, 27 Jan 2010 05:18:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0RAIeMr027756; Wed, 27 Jan 2010 10:18:40 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Jan 2010 10:18:40 GMT Message-Id: <201001271018.o0RAIeMr027756@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Wed, 27 Jan 2010 10:18:41 -0000 TB --- 2010-01-27 09:13:06 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-27 09:13:06 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-01-27 09:13:06 - cleaning the object tree TB --- 2010-01-27 09:13:17 - cvsupping the source tree TB --- 2010-01-27 09:13:17 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-01-27 09:13:43 - building world TB --- 2010-01-27 09:13:43 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 09:13:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 09:13:43 - TARGET=powerpc TB --- 2010-01-27 09:13:43 - TARGET_ARCH=powerpc TB --- 2010-01-27 09:13:43 - TZ=UTC TB --- 2010-01-27 09:13:43 - __MAKE_CONF=/dev/null TB --- 2010-01-27 09:13:43 - cd /src TB --- 2010-01-27 09:13:43 - /usr/bin/make -B buildworld >>> World build started on Wed Jan 27 09:13:44 UTC 2010 >>> 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 Wed Jan 27 10:14:19 UTC 2010 TB --- 2010-01-27 10:14:19 - generating LINT kernel config TB --- 2010-01-27 10:14:19 - cd /src/sys/powerpc/conf TB --- 2010-01-27 10:14:19 - /usr/bin/make -B LINT TB --- 2010-01-27 10:14:19 - building LINT kernel TB --- 2010-01-27 10:14:19 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 10:14:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 10:14:19 - TARGET=powerpc TB --- 2010-01-27 10:14:19 - TARGET_ARCH=powerpc TB --- 2010-01-27 10:14:19 - TZ=UTC TB --- 2010-01-27 10:14:19 - __MAKE_CONF=/dev/null TB --- 2010-01-27 10:14:19 - cd /src TB --- 2010-01-27 10:14:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jan 27 10:14:19 UTC 2010 >>> 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/dev/e1000/if_em.c:5291: error: 'struct adapter' has no member named 'mbuf_cluster_failed' /src/sys/dev/e1000/if_em.c: In function 'em_print_hw_stats': /src/sys/dev/e1000/if_em.c:5332: error: 'struct adapter' has no member named 'rx_irq' /src/sys/dev/e1000/if_em.c:5333: error: 'struct adapter' has no member named 'tx_irq' /src/sys/dev/e1000/if_em.c:5333: warning: format '%ld' expects type 'long int', but argument 5 has type 'int' /src/sys/dev/e1000/if_em.c: In function 'em_sysctl_int_delay': /src/sys/dev/e1000/if_em.c:5462: error: 'struct adapter' has no member named 'txd_cmd' /src/sys/dev/e1000/if_em.c:5466: error: 'struct adapter' has no member named 'txd_cmd' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-27 10:18:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-27 10:18:40 - ERROR: failed to build lint kernel TB --- 2010-01-27 10:18:40 - 2940.12 user 616.11 system 3933.71 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 10:19:24 2010 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 5CF8B10656A3; Wed, 27 Jan 2010 10:19:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 1BF128FC2B; Wed, 27 Jan 2010 10:19:24 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0RAJNPG029086; Wed, 27 Jan 2010 05:19:23 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0RAJNvq029080; Wed, 27 Jan 2010 10:19:23 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Jan 2010 10:19:23 GMT Message-Id: <201001271019.o0RAJNvq029080@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Wed, 27 Jan 2010 10:19:24 -0000 TB --- 2010-01-27 08:55:29 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-27 08:55:29 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-01-27 08:55:29 - cleaning the object tree TB --- 2010-01-27 08:55:50 - cvsupping the source tree TB --- 2010-01-27 08:55:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-01-27 08:57:14 - building world TB --- 2010-01-27 08:57:14 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 08:57:14 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 08:57:14 - TARGET=ia64 TB --- 2010-01-27 08:57:14 - TARGET_ARCH=ia64 TB --- 2010-01-27 08:57:14 - TZ=UTC TB --- 2010-01-27 08:57:14 - __MAKE_CONF=/dev/null TB --- 2010-01-27 08:57:14 - cd /src TB --- 2010-01-27 08:57:14 - /usr/bin/make -B buildworld >>> World build started on Wed Jan 27 08:57:15 UTC 2010 >>> 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 Wed Jan 27 10:13:33 UTC 2010 TB --- 2010-01-27 10:13:33 - generating LINT kernel config TB --- 2010-01-27 10:13:33 - cd /src/sys/ia64/conf TB --- 2010-01-27 10:13:33 - /usr/bin/make -B LINT TB --- 2010-01-27 10:13:33 - building LINT kernel TB --- 2010-01-27 10:13:33 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 10:13:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 10:13:33 - TARGET=ia64 TB --- 2010-01-27 10:13:33 - TARGET_ARCH=ia64 TB --- 2010-01-27 10:13:33 - TZ=UTC TB --- 2010-01-27 10:13:33 - __MAKE_CONF=/dev/null TB --- 2010-01-27 10:13:33 - cd /src TB --- 2010-01-27 10:13:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jan 27 10:13:33 UTC 2010 >>> 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/dev/e1000/if_em.c:5291: error: 'struct adapter' has no member named 'mbuf_cluster_failed' /src/sys/dev/e1000/if_em.c: In function 'em_print_hw_stats': /src/sys/dev/e1000/if_em.c:5332: error: 'struct adapter' has no member named 'rx_irq' /src/sys/dev/e1000/if_em.c:5333: error: 'struct adapter' has no member named 'tx_irq' /src/sys/dev/e1000/if_em.c:5333: warning: format '%ld' expects type 'long int', but argument 5 has type 'int' /src/sys/dev/e1000/if_em.c: In function 'em_sysctl_int_delay': /src/sys/dev/e1000/if_em.c:5462: error: 'struct adapter' has no member named 'txd_cmd' /src/sys/dev/e1000/if_em.c:5466: error: 'struct adapter' has no member named 'txd_cmd' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-27 10:19:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-27 10:19:23 - ERROR: failed to build lint kernel TB --- 2010-01-27 10:19:23 - 3919.80 user 668.27 system 5034.16 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 10:39:38 2010 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 2E86A10656A4; Wed, 27 Jan 2010 10:39:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E1EC78FC36; Wed, 27 Jan 2010 10:39:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0RAdbNq015166; Wed, 27 Jan 2010 05:39:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0RAdbGb015165; Wed, 27 Jan 2010 10:39:37 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Jan 2010 10:39:37 GMT Message-Id: <201001271039.o0RAdbGb015165@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Wed, 27 Jan 2010 10:39:38 -0000 TB --- 2010-01-27 09:38:39 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-27 09:38:39 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-01-27 09:38:39 - cleaning the object tree TB --- 2010-01-27 09:38:50 - cvsupping the source tree TB --- 2010-01-27 09:38:50 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-01-27 09:39:32 - building world TB --- 2010-01-27 09:39:32 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 09:39:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 09:39:32 - TARGET=sparc64 TB --- 2010-01-27 09:39:32 - TARGET_ARCH=sparc64 TB --- 2010-01-27 09:39:32 - TZ=UTC TB --- 2010-01-27 09:39:32 - __MAKE_CONF=/dev/null TB --- 2010-01-27 09:39:32 - cd /src TB --- 2010-01-27 09:39:32 - /usr/bin/make -B buildworld >>> World build started on Wed Jan 27 09:39:33 UTC 2010 >>> 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 Wed Jan 27 10:35:39 UTC 2010 TB --- 2010-01-27 10:35:39 - generating LINT kernel config TB --- 2010-01-27 10:35:39 - cd /src/sys/sparc64/conf TB --- 2010-01-27 10:35:39 - /usr/bin/make -B LINT TB --- 2010-01-27 10:35:39 - building LINT kernel TB --- 2010-01-27 10:35:39 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 10:35:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 10:35:39 - TARGET=sparc64 TB --- 2010-01-27 10:35:39 - TARGET_ARCH=sparc64 TB --- 2010-01-27 10:35:39 - TZ=UTC TB --- 2010-01-27 10:35:39 - __MAKE_CONF=/dev/null TB --- 2010-01-27 10:35:39 - cd /src TB --- 2010-01-27 10:35:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jan 27 10:35:39 UTC 2010 >>> 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/dev/e1000/if_em.c:5291: error: 'struct adapter' has no member named 'mbuf_cluster_failed' /src/sys/dev/e1000/if_em.c: In function 'em_print_hw_stats': /src/sys/dev/e1000/if_em.c:5332: error: 'struct adapter' has no member named 'rx_irq' /src/sys/dev/e1000/if_em.c:5333: error: 'struct adapter' has no member named 'tx_irq' /src/sys/dev/e1000/if_em.c:5333: warning: format '%ld' expects type 'long int', but argument 5 has type 'int' /src/sys/dev/e1000/if_em.c: In function 'em_sysctl_int_delay': /src/sys/dev/e1000/if_em.c:5462: error: 'struct adapter' has no member named 'txd_cmd' /src/sys/dev/e1000/if_em.c:5466: error: 'struct adapter' has no member named 'txd_cmd' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-27 10:39:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-27 10:39:37 - ERROR: failed to build lint kernel TB --- 2010-01-27 10:39:37 - 2769.93 user 582.99 system 3657.16 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 10:46:09 2010 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 AE8FB1065776; Wed, 27 Jan 2010 10:46:09 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (unknown [IPv6:2001:380:e06:127::53]) by mx1.freebsd.org (Postfix) with ESMTP id 02BE38FC13; Wed, 27 Jan 2010 10:46:08 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id D77A178C53; Wed, 27 Jan 2010 19:46:07 +0900 (JST) Received: from artemis (unknown [192.168.2.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTP id 869B678C3B; Wed, 27 Jan 2010 19:46:07 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: References: <18D68DBE18AC435984C5F66597A869D3@artemis> Date: Wed, 27 Jan 2010 19:46:04 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [PATCH] VirtualBox headless VNC support by LibVNCServer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jan 2010 10:46:09 -0000 Hi, all I updated for 3.1.2_1 and fixed bug of initial pixel format. Before building, install "ports/net/libvncserver". I recommend you backup virtualbox-ose directory before doing. Uncheck QT4, X11, NLS by make config before extracting. Howto apply the patch: # cd /usr/ports/emulators/virtualbox-ose # make config # make extract # patch -p < /path/to/VBox-VNC-Makefile.patch # patch -p < /path/to/VBox-VNC-20100127.patch # make Regards, Daisuke Aoyama From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 10:48:07 2010 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 ED280106566C; Wed, 27 Jan 2010 10:48:07 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (unknown [IPv6:2001:380:e06:127::53]) by mx1.freebsd.org (Postfix) with ESMTP id 87C298FC1F; Wed, 27 Jan 2010 10:48:07 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id DFDB578C53; Wed, 27 Jan 2010 19:48:06 +0900 (JST) Received: from artemis (unknown [192.168.2.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTP id C2F4378C3B; Wed, 27 Jan 2010 19:48:06 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: Date: Wed, 27 Jan 2010 19:48:04 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0034_01CA9F89.A42D0430" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [PATCH] VirtualBox headless VNC support by LibVNCServer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jan 2010 10:48:08 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0034_01CA9F89.A42D0430 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit Sorry, I forgot attached files. ----- Original Message ----- From: "Daisuke Aoyama" To: Cc: ; Sent: Wednesday, January 27, 2010 7:46 PM Subject: Re: [PATCH] VirtualBox headless VNC support by LibVNCServer > Hi, all > > I updated for 3.1.2_1 and fixed bug of initial pixel format. > > Before building, install "ports/net/libvncserver". > I recommend you backup virtualbox-ose directory before doing. > Uncheck QT4, X11, NLS by make config before extracting. > > Howto apply the patch: > # cd /usr/ports/emulators/virtualbox-ose > # make config > # make extract > # patch -p < /path/to/VBox-VNC-Makefile.patch > # patch -p < /path/to/VBox-VNC-20100127.patch > # make > > Regards, > Daisuke Aoyama ------=_NextPart_000_0034_01CA9F89.A42D0430 Content-Type: application/octet-stream; name="VBox-VNC-Makefile.patch.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="VBox-VNC-Makefile.patch.gz" H4sICKTlX0sCA1ZCb3gtVk5DLU1ha2VmaWxlLnBhdGNoAJ2RW2vCQBCFn82vGESwsm666y1RiMRc 1NA0kWS9vAVr1jYYTWkstIj/vTGttRTF0n3YeRi+M2fOYIzhfr7iyyjm+Dl52aaFGqEEE4prTSBy h8qduiyS4wNE2oQICKFv7ARIQFsd0ug06yJpNyS5eQJUFbDcrrYAZb8EqirARHNnQd9zHWY6ho+U iZa8aX0TDtU37Lwynm7dgS3AyLZ8FvhjDSmFGaVKsSiAyOOUC2hqsWFgW9rE0RV456kAuuv0rcHY M4OeN8iUMX54jeIQP/F5GPM0PSOnLpL1mm+2kOtuwmiZW6ZS/eCZSo1qOzddUEs7Ux+6eyjn/vPh jsn6NgMFaBm6XSjtpt6d7+n7WztZzGM92SyjR3G1Xl3Ge8Yow/9FM9Nnes83feUKjsRoCWF2sg0P b36EVhHQWeHP7h+2Ql+Bwe8B7pgFWbqVC86zVtAzDItZrnPV/fEqH8Bi7AGxAgAA ------=_NextPart_000_0034_01CA9F89.A42D0430 Content-Type: application/octet-stream; name="VBox-VNC-20100127.patch.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="VBox-VNC-20100127.patch.gz" H4sICLfmX0sCA1ZCb3gtVk5DLTIwMTAwMTI3LnBhdGNoAO19e1/bSLLo3+RTdJiTYIMBS34CgR0e JvEdXmtDJrMzOb6yLWMtsuxIMuBJsp/9dvVL/ZBsE9jZ+zu/w0xsq6q6u7qrurq6+qG+NxigTWca XqCHcXi36T7GodOLtz96YTx1/KPx42Zpy9qyO5ftxnYU9rY/YtD2aTgOYjfoR+Txg+v0fTeKts+d O3fg+e7W3eiOZPf8bF5tbm6+MGcrdrG4s2nZm1YN2aVdu7ZbqW4V+R/aKO4Ui682NjZeqAa4OKu4 WbQ2bQvZxV1rZ7dcM4r7+We0WbELVbSBPy0b/fzzKyTn2LlunF+dHV43ENrdR/+V8wb44+PR5afO r83rD50Ph62TxkXz4n2+AMDzw+bF8VmzcXF9cnamQRqfGnkt75PGaRvRv31EMj09Pb9qvNfI2pc3 reNGm5MlmK3eZPJqwxv03QFKeDprHn28OH61kVHWxv5CWlEg0F4cn4bOyO1OBwM3pCVmU9+5s5Ez 2erpNLgcUfp90Ivc8N4N0Z/onxP39tUGlqM3eIX0inxsnVy9QstUI41SZkuvQf8lO58ukWeoryHc l+mEerZ/QUdMKZJ1xhKy6ruVym5xJ7UzlmvQGfEn5g06409e0POnfRe9I8W5Ybg1PDDA8PHR67tj gny18VNWp5ARrLNt/DQNTBjVyQ1RzqrWEYarIrNO5zR03aP2SacjJXgXzaLteDZxI+BJgk8DL4r7 FEhKQdvrch5ofVvG6HUgaGgAoyJSo/RwCb7XVRqqh9suGB+QVq5VoZXruJUt0sqv0PYL/82VQhQ7 sddDR5eXZ+h2cNiNxv40ds/H08h9P3WjGNu508OzdmNPJyXYC9ftRx/GUXw8DaNxKBEvbDWMufXH XcdHD65zh0IXi9INem6EcgOck3vvBjEaOgHW2zDKQyLEGDgej67iEL1rtrFGe+OgAJBfcSYtd3CA bhl0z6Q/Hge4eq5Gz6B7RBpWuQLisKpWwSoyecBf+/rkvHH94fIkdxmQxjl2Jk7X8714doyZvHXz KEcaJppOJuMwjnhLFmh7BWpD5WmuX+cIho1GWULRy9mTU2TIRmNioZR4hoBvjLwYOawwNAJWmIzi McLmEJslf4bcwOn6LoqHLhrichhdjxS3pWSJS83pdUBv3wpx5BPSr0QypQrpKCXcX6wSkcxXStK6 vgq9IB7kVm8i59bd/SNYTdKSv1X8bzMq4H+xE8b3I/yL/0TvAmxIvk2nXv8AxAxQdOvhiqGP5ygX ul+mXuj2kRPeTke4tnnIfbHQkmLvcWF4mIUi8RcaB9/GeMDT/hq02XI4U2fqx3mExdX3ItGWII82 GahJ8WYpDi3F6fdDrP2sMPaE3nkTqBtqXiEO4pmy0f/B833U9YI+FmZGCRNaAsiLZQ8/0Tv4POCU VwAKpqMuzvPpRdzRIqjjwgqhD+gd/cYF/eLOumMn7CP8CO6laLRd1J16fuwF6KadzyihTUuI3F7o 8mrQBzxGkG9cAjB9OMXsB9h4YAMyDhDFUdHP7zE/ZXhO6XoR9mk98TfTjG+9cTDwbpfVC5x5urov 98dkA7mOg7UY9YgpI1lHbozb8hZyJ76ATZ2BSpn3PlJd7Au5YYBWj1fRSeP4rPHp6rJ1jXK4O+bR dTiNYrd/7mCRAAT6EO4HuIwQra/jh3vx4Ab3k/yrheZwGkTebYB7I+SGRUfUbR9VsMPCzB9uvShm uWKCQ6bu++ji5uwsnYa2cX8uzS9UC+eRtKkaCZIf1xMlY6wZrJY031QKvZpEYHU6lbKwuaxTgRFT mlhVtMqN4GoBrUVrBWxJ3zeuL6+uO63G3zvt6xaeTKHvBTXJkmkWm0jIjFkRyGui53XTvLgu2SQv pfwfSJPYQkjlzOFaL+kHkuFUQH7/hFKeQi9sIiS6e0IhT08ljCMkaj+hqOVSPc+SEgax7mfqQpb+ LpmIRCNKJdKHajsFuyT6kPwHXsxrr59/lWpewbWAOIHjT92bAA8kW5Pozz2TthtiZ3RvSbei52CP CnO+qw1w+C8xiVKR05K9Z5LyIs2cnYycEyOj1+cJmd9nZJ4Y4WdkfpeRubDez8i7nZG3MPtL5/18 ByLRAEOTpPFCZwgUumoVQaGrtVLBqqQqNK7MFA/om5akpt9fsa+Fc3ll+s37R9JKr+kAlYeBfgU7 GJNw3Iu92Hdzqx/Pd9GbiDiQ+EefOGC72CfCvTRHupFI+zfarXbRajAOXIxnWp9nbf4duT5un6WL GAx+oIwfjxeg9HgBb6ypTyIbv3r9eIjeoYplo2/fkAI9QHaxXDfAb5CdJ0Ku04nSjl0vlHdShcxU URbwHNmukAnsAP9OemkcTmHGuUKCPRfHp0dofSKFZFRPSXHdpm2sCm7QhFzAa8OZMCXhuXMpYMxX tRvhJpUnUdDYhjGO4rA3mkj5FdAqyDgPDZaKZQ71aj5vdlq11gMHa5bWtYmykclsWsEBLhdPatNw dKpslPrVZCKZ4JLaszlphJxATEtRjrYJTHzySxq278njd5CD3IxSvSX+NN7Oxrcoh/uVFF/cpVMW PHGQ5n5bW1vAVn5PLgX+NJUJ3AeUKFROrwcRr5zkKS3XCMNxuIsl6IEoIWTh+2M8u3PRIMnwxxov lbfNA3/s9OnIkxNjUD7/RC4hExbJX8DcSgpXKkPYGoLJawaDcWKTFzby5oEXeDGxj8IMFiR/IP8s KUDenuN7f76QHIwak5gZjy/l3qYF0wrobXrETOfByJyFqnI9FrKaS4/bq+UODK3G1mfiO7PNg7Yb S/Q5YScLSj5y8u/PdSZwMhZZQF4E4pDCd5iQhwdyXad39wAxl954NHFij8Y980o8jw0SOBkLWvBB AoaknQrxO6xitVKwylJYNdOM0NCiPx5P0NDBvLnhyAtwd+0nxgQt4TCDOmeYjK/zhNVyfRe8LENc mFnMK0P3daWdpwHmmPg0+cmeQnrVpD74sqtqxrrjc1ajzEXMF1pZMzJesXZqZKGraKHizm6xiP9/ 6bU1s1CxulZBVnXXsnYrldTVtWIBP1nYRSPLDBvb61gx1rU1XvTgYc/uzOtiMI3/EiJsNVzmTsFS CbifF4dtVNyqbVmE4BhbStxXUHeGThwvmt656HA8c0YOeueQ758nrtMbbgXu1j8nB5AElmQ2tJU8 3Nvhn7ZmJlDYqcHjfBb2/dTrZ+HIMADjUCYB9P6/T92pm0WRSItQyDTeJIyBOdfRWScYN7g3kvRg cVAjTq1e1kIiwKNx786NNUTgxh7+t+0FGsIJJ842oBgz0wicJhhmo4nTc8HUEn/pJ2wAMBk6u3zf ed+6vLlKfnXe3zSNxmGrsjrYH9/qtVYsLltEnbvCypFsZwEAiQlGlMW+tBnj09Xx5Tk2thftTvP8 6qzTbN9cQWi4bXWOmznh5BVQUzXOmB7iyJ3js8N2u3lxepnQ5pOVYLEUGQ66R+Oxj/rjyUNv6Pbu chhy7HtYe2DFr+cXpFjpOvacowl+xI4MBJB9N8gnq5r3Y68P+cQhiVV3p3E8Ds6d6I4SP9KvWQFp JZhZ3HX7uYSxh4Akwf5fezYCVw5/pWbyakNUdXdX/MzharORCsoPe2z8wOPQqT9+YOPmqZZKHovC Hh55WtfHoRdjly9ugjf3dtS5mfSxiTjDOssJDyM83sfn0W0Okuyjj7j9O+2b4+NGu41nyNR5wyPe eKRl91oubtShjos63I06kRYfp9DUpU2FImMpU6ERa0IanOSqA7GEHzGM/JjhHxDq2Piutf+/0gSg trlBKbcCDM6iJZSwB5Z8eziNQTGoRRd0BXTdumlADisD/JzLgT6t5zl68wAb/bt4PLnAHWYOFXFJ joSzSAokqGPsswTTiSiPYNPFxbzqRMwn2OEB/1nXG9JuXdB0qUnIhEFeo6CTB2X1hq4jykQs1K7q +wMJbeyjarlYQEPXux2CgpTr+Kk7gVhkvYCiCcT2SgDBP8p7Um8ZOSBqu1IpoFvpd1f8lomjoTeA 3K0qpuYPOP8u/12UqPtQpw42IXw1iNSBQMU0V2pbLIT3bkwfc9DQBUQ/SQV51UilSIVIZbgyibJI Q6ANNVqF/gbhBYwl0DzaRcU8prHkxDhhjpjA/IjMe3MiS1lh1RgYCaAFEzpz61MRimQFOnqg3Jso v1ogw1Za/G1B8tW8qm+pqo55582q0kxonBO+pErwFe59Wg/MxbdvPP4ilsdX11fzQFHMQGM3Ef5j RLQtkoJ9L8KuYBP7g+EAhup9NMRjhZ9rXhyenLQ6hxe/pbTFvOTgBnSgdM5CZrtInduQKe0r67yb rMsqNHJHeL6aS82ogHBvSk+dNxs9DvFElvhnIBgYLw0aPAAqNPjZoInI94kTO1APasPioRcZhM40 Hl45UfTQV4n5iGJyCMTjsH8M/gDlkfoGfDwcdGHQ0oyvWVM6+T0dYyMSb4Wwjg02A0zKfNJbgFHi 24XEXX/qUtruQlrMQ5tZImqrluCDJ7hdIgHwwum7Mj1usdY0IPI8wxNyacDatJJBi9HS9QMWH04d HqTAmGz/qVcpmX/cmYG0QxGdGKIKOUYFZor1S1aiHJv9nskLcdEkXuSYmMwM1a2EGcl/EWqXlaEa ciJxkfW0qBPFpAaepHJTPSQTuMhfSgPPqQOPbNGtc2Ln3AF6K7ZncRYZYPMAe/zvG9fXjVaO+2P5 XOKbbTnR5TS+crDdyeVNl/N1Qpn4mncMIntWKcWRVoCyyI/FBRGypBSyR40X8f0lZxeijaRlkkEX bJgArOd7PreGslVU3Aqhe8zgD7qbB7eS5tLuBzOxIk3Ght1VmnD/TfQHLKRFIuLLJ1JiIx4rgHkU MCQSyO/FzwBc+6O4lk+6Gt/iyWxDI+iFs0l8NIvdKAe1AZN9PMSDkhvcunKxwjN2RzDeptAmbQjt J/dyXE4Y5lYddWMWiySTSQmrJeQKew+p82tyrBoHsF6a2H94Jvh8cfPuRjT0APH5C5M3eRQRSWJW nW6k4YXhycveKowweJTvz9j3n/Sb1i0SS3EpKoSbYRc97r/B3XJGPke4JfAP0ta4LWYFqYXSdCvB oreo+Fi0QJN4wd/2aSWPyHMbC8DtnLmDmD7vZediL8rl3Ov3fXdhPuVF+bTAHVqYTR2yIa26aWWT WUVBZokRkzit3YiqOSl+8+BqSoVJxlwhUdra/T8LkuhSPE0yvcKT3AJ8zshEUdIPrF+5BEs6CYkk w6z4NbAP65VkakyeKFtkIgE6lMs9ok2Sex67iFYV985tZJHtd5RoRohmlGiWTpRWyVz/EdQzrXor 31kVIqkK0BaSl5zSf38kDPNyPZgPZgdICk4wOXCI0kWjnhP0xn03qx9CFUj/w4zvv3kk3Q9gePpn wZyvwCqV1gUpBr0jKlgEAXuR40+GDsPQZckVRraP4rE/fsDOcZKjZDijBy/uDXmmYkGTbEr59Evn 0I87rV2Y/LEKIXIUKZqNbA7JMbIzIl3eGkQh2pyk+OgW56Bfs6qLQr7hutWLuCE4hCSWVww5g9iB iMOxvwyTnPQ/wyhZNNWYLD7azr+bF6W4Uu2vqjrovKW2wC9XneKurJhrxbU9dDuOxyiAOYvfkXqN ltBSE1pLJ7TVhPbSCUtqwtLSCctqwvLSCStqwsrSCatqwurSCWtqwtrSCetqwvrSCXfUhDtLJzxx ex6mUJNvZSeXjSY/UoDTsow1+gW2IzGcZHAVlO+4O0tW37e5bZ8GdwH0FULDbLuUhTS2q+kgX54I 7R+oSQtqNyOmm/PxFrp2bcDhz+q/39VBWByUap5fyZPKZLpGtqvlczdnlxfv0TqJOy2Isb93Y5JI j7C/5om13YuNTvPi4+FZ8+Sw9Z6Rr/NIMi1XipcTxJ4yKWh3Ln/ZW7o+H0jETFSIBtAW14gmM6ok ki9RJxEQNypFMU+vFcT1F614AI3MdrJK0ICYZvri0hN4uAn8JbigVOl8nLnOvftsPhIJ861OuaPf rhtwdkVfqsiSMUtoCDnJYAkpi4g2IuVnrPU8p35HXhxdueGV9+j6Qo+7MnBhTeUsjOpqWS1RZzlF mn7L+GfVHIIWOKMzL3CTmsvAxTWXqM2aq1ktU3MpRVLznGav8Lwql94aeKpVzz9L20k2NCacR7xN JhJQCdG+VjFGDa8umxc4V149iRoplwFIpXZO4b6A407r/dFz6nETuREJe35sHZ7z47nrUwWqVkXH LaqMQi+dfX7mUNJy+9MehLeS5h9qCJVvE7uIcy2FtLj5Q3xf3ruh7+Dpfk7ez8GgYDA5gcq3BF7E MCd9Lqe/ekGzj/mcYg+qWu7E4BgARGWMwxZxReh+jKWLcewNZnSAYlJ+LCD6Y8Z/PPAfkofEaO0C mtlKEOmBLlZil+yBBZg4ZigwQwnzaOOHR7SBHhhgBoAZBgyVfB/RQZbbBFk+LnKqSB72gkzsZXKZ pWYiPKaV2UJXiORiL8rGnptPSnCGihF9IgGa38jnr+TzA/7EnrkIlWKBDrlx5onlVJ9s+mCrEVYq bT20Ew66505418Iez2F0PsZwz+1Lq3N62idqaMv9Arat5Uben1xFnWRXMgVI9ryAqHt0jy1Awdy9 nfJHs5BHL56tPAo+Ja+kw/D1tYEXeNHQ1Xu4BF4Rvfv0sHmmCpiuG7UIQU4Zu5YYvArKAK8uRbEs VT9nH5VsM1Gy603WGkU6u+iB6M2QfHYnE/btk+/BKGYRQzrfAyUsaM2uNLgs1WRpV96P8yDtxhn+ J/fi0AWysd8fdAtoPXAfBl3BMI9UKu6nEq8s2buw9/pTvV4nW2BXWEX2eEX2aEVQmSwmJaxKVdhT q7Ai8b4n8b6n8m5G/Owy4eX/B1asKmGlUq2ksmJzVmyJlZItOKmWBSMlW+XDkvioLOSjTtgolexU NizOhiWxURNc1BImFB4qEgv2QhaKVEE+fRKnzaTY0H9GRN9ThyDMC+nskej89Dskn7cUxkYVagaU vWYF0kFp16Sd0jQ9pJeRrZPZ80/SA39kaxJJuGArklTtRWNfkfyvuRIygA335pB64T7I53CSLBmH y+zY+99dROYuIrJblahQMqSI0Tk5UvpEJ4XcNIbl77bpXUJYCZgnQMXEvAEmLOZcgLSodxDxVJp7 IMMXTQIEbVIJSVHJMjC2Cq/BGIK3odDzXUuKDi5f+/du/NGLvK7vttxbPI9jASoHuoUT3PpuxOvs HI+ngWiBdfp4PJ54RtWlxIsr/wRe20/k9S9i6yoc99wo+vjh18Pj8WjkBH3G2IQ9JnywXHFpF5fX cKyB5P3vPGo1fLmjScN/zzGr4V9/yGpoXmBoF+cdsarX2AkrZDQvP/c0COj1BR86QNI6PG8c3Zye NlrJ+Zs0nHzKBo8c2/ifdvYGoHRxKP2YUi/EvilWbIbt+U4USZsPdunRv/Zxq3l1fXh01iCnaXLa oRmsnpNp1/d6u9rmBbHB4J42O/qXihIHKFvXWBCdX5sXJ5e/tmkS0V861KAWED3Ams+x7vfV6IW7 u2RTM8Tl3X4zwKMDPZr+NnQHvSDW9hGYBbBTlWkl+OPgFvXIfmKllBM3qxRuOEgiGv1Qjt2SAw1I 2nIsVQSn0S964C2rSuOk2b46vD7+kCoWmoSfaBInoDgiuVFQXxrT1sb2sunZ0pO+9mSkICsgORNO F1HSMObih7H6MSeNsqCQvqIwL7UcNE+Pys9JLYev0+PXcxKrMeOMoPFCgSSR2OwI7pxMeFR0cTh1 b54qQQgzJdK5ZyqgHIvMLxOMNMpVohH5Fw4WvUyYaGGAyKiU6Vvmf9C5TGlz3XXL/5jvZjDdfmq+ acyZTlFe94pEKrIP9XlHvuQdrfNPB/DxDLb4Ldi7n3JNn7JnGn3l5l4cJeFDE8/+BXbyy1Uzt+jK Bxhy66mb/b99Q+vpu/q18VRh+optXuablaG24ujj415y+nGmVvpWS/+WZfCW5CDOTeIcZuIMpdFs iw8PZG6WVHZHyhLiUFGYtlU62R4tpyKgPXq9zST07rF92xUTfWadsDLA7k8+nU02E7Sa1+3G8TWS txGkKJV2EInqQpooNYKMExnp7SI1QGr1eVWTECqVU4HLaL6zR9wr6j9Jk9HvNBW7omI7zQV+0ckP v7H+GVMFcen9y0x2eHZ/wSRHFCVNbmx7t4T/r8+b3FR3dvjsBmsl9gtithsN7nMRW7dgnrP91Hsh jFsh0q9J6HtjE+Z73ez7FObMkLJvGci4eI5Nz35p/HZ+eHXSbKHV7WkUbsPlTv52hHuou81mP10s j3HkspaOyF2+fuRm50FTR7MIuruSbO7V5iz4wyeVJ43Tw5uz6w7NPSlNhaNVdntxZ6oWoZElF8xJ zXLdaF/r1ThtnjW0Gm1Nepu9OPS37rr9VXrjyII0/5xsWcUqo1fvtoMymYKAVgAbWMLYuRXhEjZw d/uROCMKhokKG0IniOJsCunEe3My07bIp2TGsWp2vILnh5861+dX2GyhcnGnmiA+ffrEwzk53+nC ClFROkygsag+//4Z7QsOv8JlgXC/Kv4rimtRMbQbUSDsSz1yendtcr+HRDCME4JrpyujGIKgwMkd 4PEiCw/n+0MZ2QuTfOl6Y1bSKwcOGknICOaFQIGReFwc+34Hhr+s9O1ZhEv4IqPdqEcpMLqBZTNR 8sfTb4GldwsQrMAPcAOXdzAJxn8Yj5S0gKuUKA7OChm4IsXdTAxMhWLImR4DWafIE9j1mtVOoTcO jYQWTXjl3LpaoXLaCzwSGUl3pKR6wYSgRgkaQabYj7CbH6itp4gGt24vnlOhIBPZeHR709ho+ypr 32YAC9lZiW+C/jgLh2fBmbhzN5hm4U697GY4xr3f9bOwH1w/UzBHsLaWyQ62KB22kJxBEvVCbxKn EAVSJ7qYjpIeJCh8skBCm5MsmnTO5AxCA92S0T4Yc5a/OKqipE8haGU34CSa38kpg0YlVOnFjsqD gVWr4PjU+PEjQQr7GjKTdTw/d8PsYik6M/WH2dzUFN0y7VOR9ftTS+8hRZthbAPD7NZpycCUGaZs YJjVOq0YmCrDVA0MsxunNQPDzNxp3cAwY3S6o2OsIq9p0UCJRrAyxy2jfSzePpadmchoOos3nVXK TGS0qsVb1SpnJjIa3OINblUyExmysLgsrGpmIkNMFheTVctMZEjQ4hK06pmJDOFaXLjWTmYiQ+42 l7tdzBauoRI2Vwk7UyVahkrYostkqkTLUAmbq4SdqRItQyVsrhJ2pkq0MjGndqZKtCrZiTJVolXN TpSpEq1adqJMlWjVsxNlqkQrE3NaKmYLt5idao5KWNmpsnUi24KclrKVItuEnJaytSLbhpyWstWC GRFlUwCmubg57xT56AYHHeUMAGlJSEtH2hLS1pElCVnSkWUJWdaRFQlZ0ZFVCVnVkTUJWdORdQlZ 15E7EnJHHWUBvSGhD/t9PfWmhG5PuyTWo9OsSzTnUzzJnvgznWZbojnx7r2+q1NsyRT0bKFOQmc1 nETMaiQKOiWjFOS0lFlheeqDqfTZDyfhMyBMok+CBElRkKjTEkFQEQTGlEjQ1JMqZc2MkGgYY4Ik srFENvPmSUlO+nRJZLSjZqQzJehqgi5r8pQUlsyhtFyqSRNK0x11W9xXdpXbJu2lNGoKb7dzAzek N4yPRyg7oqRFZkhQhUUfjJgGmkYdDYi0KAQie9+kyqQArELqtHwOwi7AGWoD9FoFlQpwYNoA/ayC ygU4HW2AflJBlQIchTZA/6WCqgU492yA3qigWgEOORug/1ZB9QKcaDZAb1XQTgGOLxugdQVk4SZf 2zFBORWEm3utaILyKggaetMEdVQQNPS+CdpQQeVCVhhqPq5SMKNTFCrFz7qx080rBCCLL2sG6O8q CGTxYIJ+VUEgC9cENVQQyCI0QS0FZIMsYhN0rYJAFjMT9JsKAllMTdCNCgJZeCaoqYKgH4xN0KUK qpBXFxmgKxUEDf27CfqqgqChP5ug7yqoXkgNIs5B7BSywhJzcaUiedWWATpUQRZ5+5gBaqsgEEPf BJ2oIBDDwASdqiAQw60Jeq+CQAxDE/RBBYEY/mmC/o8KqpFXdRmgX1QQdAHfBJ2pIOgCeyZoVwHB Hatrf6yZsFUVBC39f03Qv1SQnRHVmoeBdv/jjzUD9k0FQcP/aYL+oYKg4R9N0CcVBA3fM0HHKqhG 3tBmgD6qIGj4rgk6UkHQ8IEJulBAFWj3kQk6V0HQ7gUT9E4FgdJvmaADFQQNvW2C/qaCyhnRyHmY SiHb+16ErRbSYoPZcBALWlsEqmdboLm4HTPilwDluRaqFs0QoAAqM0lUtcyYoAAqMShUtc0goQAq kSdULZlRQwFU4k2oWjbDiAKoRJlQtWLGFQVQiS2hatUMNAqgElFC1ZoZeRRAJYyEqvWUUKSA2mpz U8kosffFqBoVUvqy1yKslbZkxcHa3BjVbHOhigO1qTKqlTIWmThGTJ85uKw6Z2RSZOcNkqypM6pV 0pbYOFgLH6BaNaW4ct4gMWILqFZLXZTjcC3agGr1lIKqeYMkJWKAajspq2kcqsVZUL2Yth7IwVrg BdWtzJU8jtPCMahup6+jcYQWFUJ1KmgjssARqYEJVC9rsz8TUFkIqC4E1FKWAQTUVutdT4n+C6gS lkX1nQwHMxOxUyxkrXfNxwkhGfGf+Thb1ccg6oX5eQQTg6BUSFviyoaXU41MFriSYmTSgdUsEzMH U0s1ElngenpXz4Sn9tdUqFVM7a6Z4OzuOh+X0WcpQpayE8VuXqEomYaraj2ZpDxn/KFYKYPIuXdD NX0lpQj7ySQp1r5aejJJLYWk/GSSumqLJAAHwT3leniuNw1Dl24hgrfDzo26resxt3301ozE/V78 vCdtHfKC+NXGxAkjl19h7nuBm6PborrTAd1ZK7LmL0PvDY8KCLbR43Lh6wiO664ggW0r2HZyPE3e lAqnkHERKdtVv0i7p2B/AjDriguA6Vvh+E56L5hMY3jF1MiJpdffrv5EL51DXTghjRA9qQynZkKf P21tbSXZr0ppESoWLXhvZtRDqV+Q8lJPYeMfEH+Er9dr9EK+Cf+SU9AdaezldpgBn9aPH97+Ahe4 x2FvGOYmBXqvNWuPh6Hnu7kv6ABN6AWp5DVMufXNzS/wisMV9VSn3HJJk5Ib6wWCXbkik65dru2J bYd6Phwpx5ZxJZJL/nglCKsoJ1icEAYnGxsSHxEkG0AlV9/0V6W7AOEgqqVsPBc3Fn9Xsn+dmr9g i8j+KRyBTu7T+AJu3/XcZMMizIAQOMTOcxrKIcjQjWGZhFwAANKboA1yoF+79BgaimwwlSjh4LxR GSpNoguCPX6zLX9dieiCR9B8vTdb67CFT8iqgNVoE+GmFecRoLt9kVuHdoL/sc3DbFD7h5qHqV1R u3admMtkb6V6pCMOs+0cRkrvu1FsHcXKV4Vgo/h7shf0c9pWUg7wlFuQXkA+YuyAoxV5mgW/IhR4 3YcgUHI/qGhvMlZAe48HiPwmy1NvevSqz4jdEgpJyNWmketgA9cR9RE3dGaqg2Cs+Ax2QAcmgpNk AOLFK2zB7Rnw6sKcR0rVttV6n7cYS+QO8j3kbWwkjJAbrQ16ApDe+gPv9cmg0t5qsIJVJvYC+kJr YT/xIIEtHLymICMXqK30eqCkETPqArmv6G/rlW5PVTpHsq9Z6iEpfsmrjR7Z0i9cEfaaFLkXDDz5 dR2pzo19F6kvACM7wdcHExU6pwdxFDadc7HtjN4HrlEw1l6yFUxHGkS5JZ3cKgEsDsYTN8hBPbEy hqvyDYyDCdcJKqYBU+Io7rthCK/oxkmRS99LzN4gQRoMhES6E8GljpCDWzeOzO4woK+nScqkdSPm dIW+FWDAVfCnNTjgJQBrfwQqQCgpM21CT8md/YZvScp/m3iUVCAye/AIirjCXqlMZKIStOX3btA2 1tqMFEwbBjlUduhNf4s0Hq2sapF4E64kV9esyHcYA7PkghrM3f6bCL7b4qUlRmUYk5KvBPYseZ83 Zoo4Jw6eH9JxWDkGs4K1KpEFUTHhEdEOQnsDu7qGtQzrJOs0xTqy83nFXNBEstRNVaM50tbYYu+4 XlGVLLEL6p3PnCnc2SlX8CzE9hLMsZyX5A66H7Q6FghtVFLG76T8TWhNzAQelIuft6RbsqXOm00v zKjkClDJE4ZIme15ZVpPLNOaU2ZbO2OJS4/pG7L5+6hD4eRJ2lTMsDXYwLFTTbx9TQsjvT1vSZkL oUNl8vmkpgyutAdx9nW8qL8+FRj0/HHkYiOqXR9I0hMbTC2nYm+57YMW0NMn6ihTwc1ABKoVw4Ye om3EPTTfB/bcgY6kHEx9f+LEw99h2Ls4PG908CD1WXH/IG/znYLMQ2AjD7sZTH5rIDugpZ8BW6HZ afBkaihknxllWDEjElwoK5KDPfccmeJ4aE4Pq5J0KE12dhayp7+ShrUgDGrgM2+n+ZVcCkLFE8Dq m2gbHEwaCYEb6/khNWm0lu1kulfEM0y7VX9BSl7Id6V/ZFhXo+PTTJntoO+sEiYgYxaeLd+0ORTp HfpbCJJZjfpSVY9lwvq45Ibrssx2xOXXGpjU+4r/gLUPwjS4nGAce6OJT8237tJ8XyZbVh+RtzBI RhrZ8n9Pe/VX8uJf5Ril9BahVxv96WiSZnCyjIvZ0FmKIiSv3QbLwpGksF2mI6aYwHxnC4fn9aaf vKuB+FeUXrkMlHBXSLJM/C2tFP1tS0TlRo4XED1zwtsej2Cu44f7vHYOlFm85KDpPK+evBML54gO uGfGkkPOv1uf1a7Cqwujg+HEz3uZJKGRnF2j30ISHiBO77ZW6qWMptpoCqPfOzj/PUR0xc+4N1gs Be7zN3/IL+ZYkO3az2t6hrBPMzMr1eKY54D/HTcBDJ9/nn74sjcBDP+6mwDSrjmrb9XK1Uq5mnoT gFXmFwGI5lOvN6N9r/NBP/YNEKq+FNzPdTq9iT+N4B/ux7jhXCz61eNV4tIwtaULCAv9sT1KOWds 2ptXtnQBF/3G1eNc/7janbj3Xs+NtmM3isHj2Y6jmMLa5Nh5GzsgW73JZBkpLpvXUxVx2XyxmhR3 Ni1706ohu7Rr17Cm/KhGPqFMqppWFVk7u+XKbiX9Br5S0SrsoA34sixQT8SkScad4w+N4186543z o0arc3jWfH9x3ri4zl01r9s0kAxf+KkZfimgOlaUeanabug5PkvI3wRDkzHTPC/1x/eH7evD60YB 4fouLiwhh7D3U+iBwdY/zt3ROJy1cJfnHC5ulo/n55i31Aoi436Mj83WdfNyfn5Xx03GVC+i+fw/ Nw5ljAqnAAA= ------=_NextPart_000_0034_01CA9F89.A42D0430-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 10:58:13 2010 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 74E401065679; Wed, 27 Jan 2010 10:58:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 33F078FC13; Wed, 27 Jan 2010 10:58:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0RAwCve058019; Wed, 27 Jan 2010 05:58:12 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0RAwCev058018; Wed, 27 Jan 2010 10:58:12 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Jan 2010 10:58:12 GMT Message-Id: <201001271058.o0RAwCev058018@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Wed, 27 Jan 2010 10:58:13 -0000 TB --- 2010-01-27 09:59:49 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-27 09:59:49 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-01-27 09:59:49 - cleaning the object tree TB --- 2010-01-27 10:00:02 - cvsupping the source tree TB --- 2010-01-27 10:00:02 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-01-27 10:00:29 - building world TB --- 2010-01-27 10:00:29 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 10:00:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 10:00:29 - TARGET=sun4v TB --- 2010-01-27 10:00:29 - TARGET_ARCH=sparc64 TB --- 2010-01-27 10:00:29 - TZ=UTC TB --- 2010-01-27 10:00:29 - __MAKE_CONF=/dev/null TB --- 2010-01-27 10:00:29 - cd /src TB --- 2010-01-27 10:00:29 - /usr/bin/make -B buildworld >>> World build started on Wed Jan 27 10:00:29 UTC 2010 >>> 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 Wed Jan 27 10:54:12 UTC 2010 TB --- 2010-01-27 10:54:12 - generating LINT kernel config TB --- 2010-01-27 10:54:12 - cd /src/sys/sun4v/conf TB --- 2010-01-27 10:54:12 - /usr/bin/make -B LINT TB --- 2010-01-27 10:54:12 - building LINT kernel TB --- 2010-01-27 10:54:12 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 10:54:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 10:54:12 - TARGET=sun4v TB --- 2010-01-27 10:54:12 - TARGET_ARCH=sparc64 TB --- 2010-01-27 10:54:12 - TZ=UTC TB --- 2010-01-27 10:54:12 - __MAKE_CONF=/dev/null TB --- 2010-01-27 10:54:12 - cd /src TB --- 2010-01-27 10:54:12 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jan 27 10:54:12 UTC 2010 >>> 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/dev/e1000/if_em.c:5291: error: 'struct adapter' has no member named 'mbuf_cluster_failed' /src/sys/dev/e1000/if_em.c: In function 'em_print_hw_stats': /src/sys/dev/e1000/if_em.c:5332: error: 'struct adapter' has no member named 'rx_irq' /src/sys/dev/e1000/if_em.c:5333: error: 'struct adapter' has no member named 'tx_irq' /src/sys/dev/e1000/if_em.c:5333: warning: format '%ld' expects type 'long int', but argument 5 has type 'int' /src/sys/dev/e1000/if_em.c: In function 'em_sysctl_int_delay': /src/sys/dev/e1000/if_em.c:5462: error: 'struct adapter' has no member named 'txd_cmd' /src/sys/dev/e1000/if_em.c:5466: error: 'struct adapter' has no member named 'txd_cmd' *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-27 10:58:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-27 10:58:12 - ERROR: failed to build lint kernel TB --- 2010-01-27 10:58:12 - 2788.30 user 567.80 system 3502.65 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 13:30:24 2010 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 05C79106566C; Wed, 27 Jan 2010 13:30:24 +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 515098FC08; Wed, 27 Jan 2010 13:30:22 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp121-45-156-224.lns6.adl6.internode.on.net [121.45.156.224]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o0RDUJg5069024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 28 Jan 2010 00:00:19 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Thu, 28 Jan 2010 00:00:05 +1030 User-Agent: KMail/1.9.10 References: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1853852.VSxyxXvjT2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001280000.16773.doconnor@gsoft.com.au> X-Spam-Score: -1.687 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: Daisuke Aoyama , freebsd-current@freebsd.org, freebsd-emulation@freebsd.org Subject: Re: [PATCH] VirtualBox headless VNC support by LibVNCServer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jan 2010 13:30:24 -0000 --nextPart1853852.VSxyxXvjT2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 27 Jan 2010, Daisuke Aoyama wrote: > > I updated for 3.1.2_1 and fixed bug of initial pixel format. > > > > Before building, install "ports/net/libvncserver". > > I recommend you backup virtualbox-ose directory before doing. > > Uncheck QT4, X11, NLS by make config before extracting. > > > > Howto apply the patch: > > # cd /usr/ports/emulators/virtualbox-ose > > # make config > > # make extract > > # patch -p < /path/to/VBox-VNC-Makefile.patch > > # patch -p < /path/to/VBox-VNC-20100127.patch > > # make I put VBox-VNC-20100127.patch in files an modified the paths to be=20 acceptable to the ports tree and applied the Makefile patch and it=20 works well. (I say this as IMO it's easier to try if you distribute it=20 like that :) Is there any prospect of being able to build the VNC server extension in=20 parallel with X11/QT4? =2D-=20 Daniel O'Con Thanks. nor 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 --nextPart1853852.VSxyxXvjT2 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLYD/o5ZPcIHs/zowRAgvLAKCZG1P5JaGpwWdbuPmvWB4JNUQKaACfZXK/ qcU6PmJURadcX64NqmtC8A4= =9ZJB -----END PGP SIGNATURE----- --nextPart1853852.VSxyxXvjT2-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 16:41:37 2010 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 85684106566B for ; Wed, 27 Jan 2010 16:41:37 +0000 (UTC) (envelope-from v.t.mueller@continum.net) Received: from mailsrv1.continum.net (mr1.continum.net [80.72.129.121]) by mx1.freebsd.org (Postfix) with ESMTP id 486028FC1F for ; Wed, 27 Jan 2010 16:41:37 +0000 (UTC) Received: from c483.continum.net ([80.72.130.250] helo=[172.16.4.65]) by mr1.continum.net with esmtpa (Exim 4.67) (envelope-from ) id 1NaAjI-0003vs-5j for freebsd-current@freebsd.org; Wed, 27 Jan 2010 17:26:56 +0100 Message-ID: <4B60694A.8010900@continum.net> Date: Wed, 27 Jan 2010 17:26:50 +0100 From: "V. T. Mueller, Continum" User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 27 Jan 2010 17:00:52 +0000 Subject: realtek 811C-GR freeze with latest 8.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 16:41:37 -0000 Hello, We use a couple of Supermicro X7SLN-F mainboards (w/ 2x Realtek RTL8111C-GR) and experienced frequent freezes of the NICs in use. With Debian, a driver update solved the problem. With FreeBSD, we first tried ifconfig -rxcsum -txcsum as a workaround, later compiled a kernel with the latest driver. The problems persist. Is there anything we can do to support nailing down the cause and finding a solution? In the meantime, is there any known workaround besides resetting the interface daily? TIA, vt dnstest# uname -a FreeBSD dnstest.continum.net 8.0-STABLE FreeBSD 8.0-STABLE #0: Tue Jan 26 14:08:00 CET 2010 root@dnstest.continum.net:/usr/obj/usr/src/sys/RELENG8 amd64 dnstest# grep 'Exp ' /usr/src/sys/dev/re/if_re.c __FBSDID("$FreeBSD: src/sys/dev/re/if_re.c,v 1.160.2.5 2009/12/03 18:48:32 yongari Exp $"); Jan 26 13:29:54 dnstest kernel: re0: port 0xc800-0xc8ff mem 0xfdeff000-0xfdefffff,0xfcef0000-0xfcefffff irq 16 at device 0.0 on pci2 Jan 26 13:29:54 dnstest kernel: re1: port 0xd800-0xd8ff mem 0xfdfff000-0xfdffffff,0xfcff0000-0xfcffffff irq 17 at device 0.0 on pci3 -- Volker T. Mueller Continum AG Bismarckallee 7d 79098 Freiburg i. Br. Tel. +49 761 21711171 Fax. +49 761 21711198 http://www.continum.net Sitz der Gesellschaft: Freiburg im Breisgau Registergericht: Amtsgericht Freiburg, HRB 6866 Vorstand: Rolf Mathis, Volker T. Mueller Vorsitzender d. Aufsichtsrats: Prof. Dr. Karl-F. Fischbach From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 17:05:23 2010 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 8FA7A1065771 for ; Wed, 27 Jan 2010 17:05:22 +0000 (UTC) (envelope-from v.t.mueller@continum.net) Received: from mailsrv1.continum.net (mr1.continum.net [80.72.129.121]) by mx1.freebsd.org (Postfix) with ESMTP id ABB268FC17 for ; Wed, 27 Jan 2010 17:05:22 +0000 (UTC) Received: from c483.continum.net ([80.72.130.250] helo=[172.16.4.65]) by mr1.continum.net with esmtpa (Exim 4.67) (envelope-from ) id 1NaBKZ-00076N-5c for freebsd-current@freebsd.org; Wed, 27 Jan 2010 18:05:27 +0100 Resent-From: "V. T. Mueller, Continum" Resent-To: freebsd-current@freebsd.org Resent-Date: Wed, 27 Jan 2010 18:05:20 +0100 Resent-Message-Id: <4B607250.9000100@continum.net> Resent-User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Message-ID: <4B60694A.8010900@continum.net> Date: Wed, 27 Jan 2010 17:26:50 +0100 From: "V. T. Mueller, Continum" User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: realtek 811C-GR freeze with latest 8.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 17:05:23 -0000 Hello, We use a couple of Supermicro X7SLN-F mainboards (w/ 2x Realtek RTL8111C-GR) and experienced frequent freezes of the NICs in use. With Debian, a driver update solved the problem. With FreeBSD, we first tried ifconfig -rxcsum -txcsum as a workaround, later compiled a kernel with the latest driver. The problems persist. Is there anything we can do to support nailing down the cause and finding a solution? In the meantime, is there any known workaround besides resetting the interface daily? TIA, vt dnstest# uname -a FreeBSD dnstest.continum.net 8.0-STABLE FreeBSD 8.0-STABLE #0: Tue Jan 26 14:08:00 CET 2010 root@dnstest.continum.net:/usr/obj/usr/src/sys/RELENG8 amd64 dnstest# grep 'Exp ' /usr/src/sys/dev/re/if_re.c __FBSDID("$FreeBSD: src/sys/dev/re/if_re.c,v 1.160.2.5 2009/12/03 18:48:32 yongari Exp $"); Jan 26 13:29:54 dnstest kernel: re0: port 0xc800-0xc8ff mem 0xfdeff000-0xfdefffff,0xfcef0000-0xfcefffff irq 16 at device 0.0 on pci2 Jan 26 13:29:54 dnstest kernel: re1: port 0xd800-0xd8ff mem 0xfdfff000-0xfdffffff,0xfcff0000-0xfcffffff irq 17 at device 0.0 on pci3 -- Volker T. Mueller Continum AG Bismarckallee 7d 79098 Freiburg i. Br. Tel. +49 761 21711171 Fax. +49 761 21711198 http://www.continum.net Sitz der Gesellschaft: Freiburg im Breisgau Registergericht: Amtsgericht Freiburg, HRB 6866 Vorstand: Rolf Mathis, Volker T. Mueller Vorsitzender d. Aufsichtsrats: Prof. Dr. Karl-F. Fischbach From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 17:59:36 2010 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 6F60A106566C for ; Wed, 27 Jan 2010 17:59:36 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by mx1.freebsd.org (Postfix) with ESMTP id 223528FC15 for ; Wed, 27 Jan 2010 17:59:35 +0000 (UTC) Received: by qyk41 with SMTP id 41so4127383qyk.29 for ; Wed, 27 Jan 2010 09:59:35 -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=mb7v6Z7kP/bXGs47ho71oeQLm/nkDfm87rAkB+juMHM=; b=Fmy0Ew3k8h/B8ChQmXIrFMCZ0ACzt5tbUnrEFCd+INaF9638lkbVrMJ3IS7wAjEhqD XlcgsklyMFRPoLi8PDRToL0JpbJd3aE9xq7DHXr8gPp9V0L7Sz2VwzjgcM0xL/qsygIE 3ViR8vBqcUG8uFSzRz14/SjSbZKbVVP8/CpnI= 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=SmpoQ3LxuSfEQrnJA8x/mS2Y9jALjiQOh3PiJrjWeYHbL3GvtU+bq8200tFNeb9XUT fv3l3Wi9+Kcq8XMP6e0gQAAmJRYMu4ZY+2Z7LLl9fZKZFy2fiYxhXVl+L4l2lVPbHJ63 PRjXfRASdTsQq9B5ktWhQx3AA718571zWSMbg= Received: by 10.224.85.5 with SMTP id m5mr4167459qal.97.1264615174696; Wed, 27 Jan 2010 09:59:34 -0800 (PST) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id 20sm77328qyk.13.2010.01.27.09.59.32 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 27 Jan 2010 09:59:33 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 27 Jan 2010 09:59:34 -0800 From: Pyun YongHyeon Date: Wed, 27 Jan 2010 09:59:34 -0800 To: "V. T. Mueller, Continum" Message-ID: <20100127175934.GN1187@michelle.cdnetworks.com> References: <4B60694A.8010900@continum.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B60694A.8010900@continum.net> User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@freebsd.org Subject: Re: realtek 811C-GR freeze with latest 8.0 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: Wed, 27 Jan 2010 17:59:36 -0000 On Wed, Jan 27, 2010 at 05:26:50PM +0100, V. T. Mueller, Continum wrote: > Hello, > > We use a couple of Supermicro X7SLN-F mainboards (w/ 2x Realtek > RTL8111C-GR) and experienced frequent freezes of the NICs in use. With > Debian, a driver update solved the problem. With FreeBSD, we first tried > ifconfig -rxcsum -txcsum as a workaround, later compiled a kernel with > the latest driver. The problems persist. > > Is there anything we can do to support nailing down the cause and > finding a solution? In the meantime, is there any known workaround > besides resetting the interface daily? > Would you show me more information for the issue? Frequent freeze is ambiguous to me. More specific issues like, watchdog timeout, or console output generated by re(4) would be better to me. If you know how to reliably trigger the issue, also include that information. > TIA, > vt > > > dnstest# uname -a > FreeBSD dnstest.continum.net 8.0-STABLE FreeBSD 8.0-STABLE #0: Tue Jan > 26 14:08:00 CET 2010 > root@dnstest.continum.net:/usr/obj/usr/src/sys/RELENG8 amd64 > > dnstest# grep 'Exp ' /usr/src/sys/dev/re/if_re.c > __FBSDID("$FreeBSD: src/sys/dev/re/if_re.c,v 1.160.2.5 2009/12/03 > 18:48:32 yongari Exp $"); > > Jan 26 13:29:54 dnstest kernel: re0: 8168/8168B/8168C/8168CP/8168D/8168DP/8111B/8111C/8111CP/8111DP PCIe > Gigabit Ethernet> port 0xc800-0xc8ff mem > 0xfdeff000-0xfdefffff,0xfcef0000-0xfcefffff irq 16 at device 0.0 on pci2 > Jan 26 13:29:54 dnstest kernel: re1: 8168/8168B/8168C/8168CP/8168D/8168DP/8111B/8111C/8111CP/8111DP PCIe > Gigabit Ethernet> port 0xd800-0xd8ff mem > 0xfdfff000-0xfdffffff,0xfcff0000-0xfcffffff irq 17 at device 0.0 on pci3 Please show me full dmesg output related with re(4) and rgephy(4). re(4) might show more detailed chip/MAC revision for your controller. From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 18:50:37 2010 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 EE990106566C; Wed, 27 Jan 2010 18:50:36 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id C38AE8FC0C; Wed, 27 Jan 2010 18:50:36 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0RIoZtg041830; Wed, 27 Jan 2010 13:50:35 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0RIoZSH041813; Wed, 27 Jan 2010 18:50:35 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Jan 2010 18:50:35 GMT Message-Id: <201001271850.o0RIoZSH041813@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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, 27 Jan 2010 18:50:37 -0000 TB --- 2010-01-27 17:45:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-27 17:45:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-01-27 17:45:00 - cleaning the object tree TB --- 2010-01-27 17:45:18 - cvsupping the source tree TB --- 2010-01-27 17:45:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-01-27 17:45:53 - building world TB --- 2010-01-27 17:45:53 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 17:45:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 17:45:53 - TARGET=pc98 TB --- 2010-01-27 17:45:53 - TARGET_ARCH=i386 TB --- 2010-01-27 17:45:53 - TZ=UTC TB --- 2010-01-27 17:45:53 - __MAKE_CONF=/dev/null TB --- 2010-01-27 17:45:53 - cd /src TB --- 2010-01-27 17:45:53 - /usr/bin/make -B buildworld >>> World build started on Wed Jan 27 17:45:53 UTC 2010 >>> 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 Wed Jan 27 18:45:31 UTC 2010 TB --- 2010-01-27 18:45:31 - generating LINT kernel config TB --- 2010-01-27 18:45:31 - cd /src/sys/pc98/conf TB --- 2010-01-27 18:45:31 - /usr/bin/make -B LINT TB --- 2010-01-27 18:45:31 - building LINT kernel TB --- 2010-01-27 18:45:31 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 18:45:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 18:45:31 - TARGET=pc98 TB --- 2010-01-27 18:45:31 - TARGET_ARCH=i386 TB --- 2010-01-27 18:45:31 - TZ=UTC TB --- 2010-01-27 18:45:31 - __MAKE_CONF=/dev/null TB --- 2010-01-27 18:45:31 - cd /src TB --- 2010-01-27 18:45:31 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jan 27 18:45:32 UTC 2010 >>> 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/dev/e1000/if_em.c:5291: error: 'struct adapter' has no member named 'mbuf_cluster_failed' /src/sys/dev/e1000/if_em.c: In function 'em_print_hw_stats': /src/sys/dev/e1000/if_em.c:5332: error: 'struct adapter' has no member named 'rx_irq' /src/sys/dev/e1000/if_em.c:5333: error: 'struct adapter' has no member named 'tx_irq' /src/sys/dev/e1000/if_em.c:5333: warning: format '%ld' expects type 'long int', but argument 5 has type 'int' /src/sys/dev/e1000/if_em.c: In function 'em_sysctl_int_delay': /src/sys/dev/e1000/if_em.c:5462: error: 'struct adapter' has no member named 'txd_cmd' /src/sys/dev/e1000/if_em.c:5466: error: 'struct adapter' has no member named 'txd_cmd' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-27 18:50:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-27 18:50:35 - ERROR: failed to build lint kernel TB --- 2010-01-27 18:50:35 - 2848.18 user 688.26 system 3935.14 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 18:51:55 2010 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 ABEBA106568B; Wed, 27 Jan 2010 18:51:55 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 5EA018FC1C; Wed, 27 Jan 2010 18:51:55 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0RIpsOh053358; Wed, 27 Jan 2010 13:51:54 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0RIpsnp053333; Wed, 27 Jan 2010 18:51:54 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Jan 2010 18:51:54 GMT Message-Id: <201001271851.o0RIpsnp053333@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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, 27 Jan 2010 18:51:55 -0000 TB --- 2010-01-27 17:45:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-27 17:45:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-01-27 17:45:00 - cleaning the object tree TB --- 2010-01-27 17:45:18 - cvsupping the source tree TB --- 2010-01-27 17:45:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-01-27 17:45:53 - building world TB --- 2010-01-27 17:45:53 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 17:45:53 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 17:45:53 - TARGET=i386 TB --- 2010-01-27 17:45:53 - TARGET_ARCH=i386 TB --- 2010-01-27 17:45:53 - TZ=UTC TB --- 2010-01-27 17:45:53 - __MAKE_CONF=/dev/null TB --- 2010-01-27 17:45:53 - cd /src TB --- 2010-01-27 17:45:53 - /usr/bin/make -B buildworld >>> World build started on Wed Jan 27 17:45:53 UTC 2010 >>> 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 Wed Jan 27 18:45:40 UTC 2010 TB --- 2010-01-27 18:45:40 - generating LINT kernel config TB --- 2010-01-27 18:45:40 - cd /src/sys/i386/conf TB --- 2010-01-27 18:45:40 - /usr/bin/make -B LINT TB --- 2010-01-27 18:45:40 - building LINT kernel TB --- 2010-01-27 18:45:40 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 18:45:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 18:45:40 - TARGET=i386 TB --- 2010-01-27 18:45:40 - TARGET_ARCH=i386 TB --- 2010-01-27 18:45:40 - TZ=UTC TB --- 2010-01-27 18:45:40 - __MAKE_CONF=/dev/null TB --- 2010-01-27 18:45:40 - cd /src TB --- 2010-01-27 18:45:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jan 27 18:45:40 UTC 2010 >>> 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/dev/e1000/if_em.c:5291: error: 'struct adapter' has no member named 'mbuf_cluster_failed' /src/sys/dev/e1000/if_em.c: In function 'em_print_hw_stats': /src/sys/dev/e1000/if_em.c:5332: error: 'struct adapter' has no member named 'rx_irq' /src/sys/dev/e1000/if_em.c:5333: error: 'struct adapter' has no member named 'tx_irq' /src/sys/dev/e1000/if_em.c:5333: warning: format '%ld' expects type 'long int', but argument 5 has type 'int' /src/sys/dev/e1000/if_em.c: In function 'em_sysctl_int_delay': /src/sys/dev/e1000/if_em.c:5462: error: 'struct adapter' has no member named 'txd_cmd' /src/sys/dev/e1000/if_em.c:5466: error: 'struct adapter' has no member named 'txd_cmd' *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-27 18:51:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-27 18:51:54 - ERROR: failed to build lint kernel TB --- 2010-01-27 18:51:54 - 2935.40 user 672.51 system 4013.95 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 19:18:12 2010 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 B31B9106566B; Wed, 27 Jan 2010 19:18:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 702A38FC12; Wed, 27 Jan 2010 19:18:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0RJIBB5086748; Wed, 27 Jan 2010 14:18:11 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0RJIBuR086745; Wed, 27 Jan 2010 19:18:11 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Jan 2010 19:18:11 GMT Message-Id: <201001271918.o0RJIBuR086745@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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, 27 Jan 2010 19:18:12 -0000 TB --- 2010-01-27 17:45:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-27 17:45:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-01-27 17:45:00 - cleaning the object tree TB --- 2010-01-27 17:45:23 - cvsupping the source tree TB --- 2010-01-27 17:45:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-01-27 17:46:00 - building world TB --- 2010-01-27 17:46:00 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 17:46:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 17:46:00 - TARGET=amd64 TB --- 2010-01-27 17:46:00 - TARGET_ARCH=amd64 TB --- 2010-01-27 17:46:00 - TZ=UTC TB --- 2010-01-27 17:46:00 - __MAKE_CONF=/dev/null TB --- 2010-01-27 17:46:00 - cd /src TB --- 2010-01-27 17:46:00 - /usr/bin/make -B buildworld >>> World build started on Wed Jan 27 17:46:01 UTC 2010 >>> 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 >>> World build completed on Wed Jan 27 19:12:28 UTC 2010 TB --- 2010-01-27 19:12:28 - generating LINT kernel config TB --- 2010-01-27 19:12:28 - cd /src/sys/amd64/conf TB --- 2010-01-27 19:12:28 - /usr/bin/make -B LINT TB --- 2010-01-27 19:12:28 - building LINT kernel TB --- 2010-01-27 19:12:28 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 19:12:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 19:12:28 - TARGET=amd64 TB --- 2010-01-27 19:12:28 - TARGET_ARCH=amd64 TB --- 2010-01-27 19:12:28 - TZ=UTC TB --- 2010-01-27 19:12:28 - __MAKE_CONF=/dev/null TB --- 2010-01-27 19:12:28 - cd /src TB --- 2010-01-27 19:12:28 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jan 27 19:12:28 UTC 2010 >>> 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/dev/e1000/if_em.c:5291: error: 'struct adapter' has no member named 'mbuf_cluster_failed' /src/sys/dev/e1000/if_em.c: In function 'em_print_hw_stats': /src/sys/dev/e1000/if_em.c:5332: error: 'struct adapter' has no member named 'rx_irq' /src/sys/dev/e1000/if_em.c:5333: error: 'struct adapter' has no member named 'tx_irq' /src/sys/dev/e1000/if_em.c:5333: warning: format '%ld' expects type 'long int', but argument 5 has type 'int' /src/sys/dev/e1000/if_em.c: In function 'em_sysctl_int_delay': /src/sys/dev/e1000/if_em.c:5462: error: 'struct adapter' has no member named 'txd_cmd' /src/sys/dev/e1000/if_em.c:5466: error: 'struct adapter' has no member named 'txd_cmd' *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-27 19:18:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-27 19:18:11 - ERROR: failed to build lint kernel TB --- 2010-01-27 19:18:11 - 4081.31 user 954.19 system 5591.00 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 19:29:32 2010 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 AB4411065670 for ; Wed, 27 Jan 2010 19:29:32 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 859638FC18 for ; Wed, 27 Jan 2010 19:29:32 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id o0RJTVbB053140; Wed, 27 Jan 2010 14:29:31 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <201001271929.o0RJTVbB053140@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Jan 2010 14:29:38 -0500 To: freebsd-current@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Jack Vogel Subject: new em problems on HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jan 2010 19:29:32 -0000 Not sure if the panic is related, but the watchdog timeout issue on bootup seems to be repeatable on this motherboard with HEAD from last Friday. It boots up fine under 6.x FreeBSD 9.0-CURRENT #1: Fri Jan 22 16:43:53 EST 2010 mdtancsa@ich10.sentex.ca:/usr/HEAD/obj/usr/HEAD/src/sys/alix i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) CPU E6500 @ 2.93GHz (0.00-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 Features=0xbfebfbff Features2=0x400e3bd AMD Features=0x20100000 AMD Features2=0x1 TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2089807872 (1992 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard kbd1 at kbdmux0 cryptosoft0: on motherboard acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: irq 17 at device 28.0 on pci0 pci9: on pcib2 pcib3: at device 0.0 on pci9 pci10: on pcib3 pci10: at device 1.0 (no driver attached) pcib4: irq 17 at device 28.4 on pci0 pci13: on pcib4 em0: port 0x5000-0x501f mem 0xe1000000-0xe101ffff irq 16 at device 0.0 on pci13 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:30:48:8d:2a:96 pcib5: irq 16 at device 28.5 on pci0 pci14: on pcib5 em1: port 0x6000-0x601f mem 0xe1100000-0xe111ffff irq 17 at device 0.0 on pci14 em1: Using MSI interrupt em1: [FILTER] em1: Ethernet address: 00:30:48:8d:2a:97 uhci0: port 0x3000-0x301f irq 23 at device 29.0 on pci0 uhci0: [ITHREAD] usbus0: on uhci0 uhci1: port 0x3020-0x303f irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] usbus1: on uhci1 uhci2: port 0x3040-0x305f irq 18 at device 29.2 on pci0 uhci2: [ITHREAD] usbus2: on uhci2 uhci3: port 0x3060-0x307f irq 16 at device 29.3 on pci0 uhci3: [ITHREAD] usbus3: on uhci3 ehci0: mem 0xe0000000-0xe00003ff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib6: at device 30.0 on pci0 pci15: on pcib6 vgapci0: port 0x7000-0x70ff mem 0xe8000000-0xefffffff,0xe1200000-0xe120ffff irq 16 at device 0.0 on pci15 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 ata0: on atapci0 ata0: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 uart0: [FILTER] uart0: console (9600,n,8,1) uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 uart1: [FILTER] cpu0: on acpi0 est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6160b2506000616 device_attach: est0 attach returned 6 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 6160b2506000616 device_attach: est1 attach returned 6 p4tcc1: on cpu1 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xcd000-0xcdfff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 SMP: AP CPU #1 Launched! ugen0.1: at usbus0 ugen1.1: at usbus1 uhub0: on usbus0 uhub1: on usbus1 Root mount waiting for: usbus4 usbus3 usbus2 usbus1 usbus0 ugen2.1: at usbus2 ugen3.1: at usbus3 uhub2: on usbus2 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered Root mount waiting for: usbus4 Root mount waiting for: usbus4 Root mount waiting for: usbus4 uhub4: 8 ports with 8 removable, self powered Trying to mount root from nfs: NFS ROOT: 10.255.255.1:/usr/home/pxe9/ em0: Watchdog timeout -- resetting em0: link state changed to UP Interface em0 IP-Address 10.255.255.118 Broadcast 10.255.255.255 mount_nfs: can't update /var/db/mounttab for 10.255.255.1:/usr/home/pxe9//etc kernel trap 18 with interrupts disabled Fatal trap 18: integer divide fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0xc0995f0b stack pointer = 0x28:0xc4e746f8 frame pointer = 0x28:0xc4e7476c code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 52 (ps) trap number = 18 panic: integer divide fault cpuid = 1 Uptime: 1m23s Cannot dump. Device not defined or unavailable. Automatic reboot in 15 seconds - press a key on the console to abort Fatal double fault: eip = 0xc098e8d0 esp = 0xc4d00000 ebp = 0xc4d00020 cpuid = 1; Rebooting... apic id = 01 cpu_reset: Stopping other CPUs panic: double fault cpuid = 1 Uptime: 1m23s Cannot dump. Device not defined or unavailable. Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... cpu_reset: Stopping other CPUs -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 19:45:16 2010 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 D438C106566B for ; Wed, 27 Jan 2010 19:45:16 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id A65A78FC1B for ; Wed, 27 Jan 2010 19:45:16 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id o0RJjFc2090089 for ; Wed, 27 Jan 2010 11:45:15 -0800 (PST) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id o0RJjFHe090088 for current@freebsd.org; Wed, 27 Jan 2010 11:45:15 -0800 (PST) (envelope-from david) Date: Wed, 27 Jan 2010 11:45:15 -0800 From: David Wolfskill To: current@freebsd.org Message-ID: <20100127194515.GW58789@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org References: <20091208164048.GL1258@albert.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zuE2pCA56U4I9Fhk" Content-Disposition: inline In-Reply-To: <20091208164048.GL1258@albert.catwhisker.org> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: Poweroff (shutdown -p) fails to power off as of r200252? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jan 2010 19:45:16 -0000 --zuE2pCA56U4I9Fhk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 08, 2009 at 08:40:48AM -0800, David Wolfskill wrote: > ... > I'm pretty sure the poweroff worked as expected yesterday (r200211). >=20 > As an experiment, I tried booting into single-user mode, then issuing > "halt -p" ... yup; same effect. >=20 > Booting to single-user mode in 8.0-STABLE (slice 3), then issuing > "halt -p" appears to work OK. > ...` Poweroff function continued to not work in head through yesterday (r203021); as of today (r203067M -- r203021 + hand-application of r203081 & r203083), "shutdown -p" correctly powers my "build machine" off again. Laptop is still building; if there's anything unusual there, I'll report, but it's been working fine (at least as far as poweroff function is concerned). 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. --zuE2pCA56U4I9Fhk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAktgl8oACgkQmprOCmdXAD0jzACfUIYKluABCz2p6SBP7xXleKb8 C0gAmgJpCg21FnZMf+3QWhjr1kaofEP5 =e+Fz -----END PGP SIGNATURE----- --zuE2pCA56U4I9Fhk-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 19:57:24 2010 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 53345106566B; Wed, 27 Jan 2010 19:57:24 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id F187D8FC19; Wed, 27 Jan 2010 19:57:23 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0RJvNUF083938; Wed, 27 Jan 2010 14:57:23 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0RJvNtQ083932; Wed, 27 Jan 2010 19:57:23 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Jan 2010 19:57:23 GMT Message-Id: <201001271957.o0RJvNtQ083932@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Wed, 27 Jan 2010 19:57:24 -0000 TB --- 2010-01-27 18:51:54 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-27 18:51:54 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-01-27 18:51:54 - cleaning the object tree TB --- 2010-01-27 18:52:04 - cvsupping the source tree TB --- 2010-01-27 18:52:04 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-01-27 18:52:30 - building world TB --- 2010-01-27 18:52:30 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 18:52:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 18:52:30 - TARGET=powerpc TB --- 2010-01-27 18:52:30 - TARGET_ARCH=powerpc TB --- 2010-01-27 18:52:30 - TZ=UTC TB --- 2010-01-27 18:52:30 - __MAKE_CONF=/dev/null TB --- 2010-01-27 18:52:30 - cd /src TB --- 2010-01-27 18:52:30 - /usr/bin/make -B buildworld >>> World build started on Wed Jan 27 18:52:30 UTC 2010 >>> 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 Wed Jan 27 19:53:05 UTC 2010 TB --- 2010-01-27 19:53:05 - generating LINT kernel config TB --- 2010-01-27 19:53:05 - cd /src/sys/powerpc/conf TB --- 2010-01-27 19:53:05 - /usr/bin/make -B LINT TB --- 2010-01-27 19:53:05 - building LINT kernel TB --- 2010-01-27 19:53:05 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 19:53:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 19:53:05 - TARGET=powerpc TB --- 2010-01-27 19:53:05 - TARGET_ARCH=powerpc TB --- 2010-01-27 19:53:05 - TZ=UTC TB --- 2010-01-27 19:53:05 - __MAKE_CONF=/dev/null TB --- 2010-01-27 19:53:05 - cd /src TB --- 2010-01-27 19:53:05 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jan 27 19:53:05 UTC 2010 >>> 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/dev/e1000/if_em.c:5291: error: 'struct adapter' has no member named 'mbuf_cluster_failed' /src/sys/dev/e1000/if_em.c: In function 'em_print_hw_stats': /src/sys/dev/e1000/if_em.c:5332: error: 'struct adapter' has no member named 'rx_irq' /src/sys/dev/e1000/if_em.c:5333: error: 'struct adapter' has no member named 'tx_irq' /src/sys/dev/e1000/if_em.c:5333: warning: format '%ld' expects type 'long int', but argument 5 has type 'int' /src/sys/dev/e1000/if_em.c: In function 'em_sysctl_int_delay': /src/sys/dev/e1000/if_em.c:5462: error: 'struct adapter' has no member named 'txd_cmd' /src/sys/dev/e1000/if_em.c:5466: error: 'struct adapter' has no member named 'txd_cmd' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-27 19:57:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-27 19:57:23 - ERROR: failed to build lint kernel TB --- 2010-01-27 19:57:23 - 2937.85 user 617.86 system 3928.16 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 19:57:45 2010 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 5A06F106568D; Wed, 27 Jan 2010 19:57:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id F3F1B8FC08; Wed, 27 Jan 2010 19:57:44 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0RJvhiw084749; Wed, 27 Jan 2010 14:57:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0RJvh5m084745; Wed, 27 Jan 2010 19:57:43 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Jan 2010 19:57:43 GMT Message-Id: <201001271957.o0RJvh5m084745@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Wed, 27 Jan 2010 19:57:45 -0000 TB --- 2010-01-27 18:34:50 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-27 18:34:50 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-01-27 18:34:50 - cleaning the object tree TB --- 2010-01-27 18:35:02 - cvsupping the source tree TB --- 2010-01-27 18:35:02 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-01-27 18:35:31 - building world TB --- 2010-01-27 18:35:31 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 18:35:31 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 18:35:31 - TARGET=ia64 TB --- 2010-01-27 18:35:31 - TARGET_ARCH=ia64 TB --- 2010-01-27 18:35:31 - TZ=UTC TB --- 2010-01-27 18:35:31 - __MAKE_CONF=/dev/null TB --- 2010-01-27 18:35:31 - cd /src TB --- 2010-01-27 18:35:31 - /usr/bin/make -B buildworld >>> World build started on Wed Jan 27 18:35:31 UTC 2010 >>> 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 Wed Jan 27 19:51:59 UTC 2010 TB --- 2010-01-27 19:51:59 - generating LINT kernel config TB --- 2010-01-27 19:51:59 - cd /src/sys/ia64/conf TB --- 2010-01-27 19:51:59 - /usr/bin/make -B LINT TB --- 2010-01-27 19:51:59 - building LINT kernel TB --- 2010-01-27 19:51:59 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 19:51:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 19:51:59 - TARGET=ia64 TB --- 2010-01-27 19:51:59 - TARGET_ARCH=ia64 TB --- 2010-01-27 19:51:59 - TZ=UTC TB --- 2010-01-27 19:51:59 - __MAKE_CONF=/dev/null TB --- 2010-01-27 19:51:59 - cd /src TB --- 2010-01-27 19:51:59 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jan 27 19:51:59 UTC 2010 >>> 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/dev/e1000/if_em.c:5291: error: 'struct adapter' has no member named 'mbuf_cluster_failed' /src/sys/dev/e1000/if_em.c: In function 'em_print_hw_stats': /src/sys/dev/e1000/if_em.c:5332: error: 'struct adapter' has no member named 'rx_irq' /src/sys/dev/e1000/if_em.c:5333: error: 'struct adapter' has no member named 'tx_irq' /src/sys/dev/e1000/if_em.c:5333: warning: format '%ld' expects type 'long int', but argument 5 has type 'int' /src/sys/dev/e1000/if_em.c: In function 'em_sysctl_int_delay': /src/sys/dev/e1000/if_em.c:5462: error: 'struct adapter' has no member named 'txd_cmd' /src/sys/dev/e1000/if_em.c:5466: error: 'struct adapter' has no member named 'txd_cmd' *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-27 19:57:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-27 19:57:43 - ERROR: failed to build lint kernel TB --- 2010-01-27 19:57:43 - 3920.75 user 662.73 system 4972.41 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 19:58:39 2010 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 587D0106568B for ; Wed, 27 Jan 2010 19:58:39 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id A2B4E8FC2A for ; Wed, 27 Jan 2010 19:58:38 +0000 (UTC) Received: by fxm26 with SMTP id 26so988682fxm.13 for ; Wed, 27 Jan 2010 11:58: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; bh=MaMMpCl4JCTp398vmAg4Lpb4IRcEhJPrYRYuB/a7hNg=; b=U6S26w6jK5yB6xsiV+Ev1ixQxkFGHh4/7Wl1t3ufwx1VxTSMGnPxxCza2ktSYRQTfI YAISdbfRd+5NhfRjriaD7T2GkoD6LGm4XJVYtX/tEQbg8y5jiV41JQmJVudepxpVX5ko 4QSDo1dphbH8nj/QsAmktpnyDOkDKL1hc9sdA= 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; b=oJMFlngtrBNCG9Zgl0l24tpo9yRCDl/l3JaUGr7Dz2f3p1p8GBABGOmq4YrTJkpW+d 0WGK+tFtbP/W8rdBUgN/KFuokpBRDZaZHQqUcQUSshynKScR9TtwL8dPJK+T7Yrs8AAi J1wgQOjq5ujzT+ECVm2a2KQGmrpgFBRUhWQMw= MIME-Version: 1.0 Received: by 10.216.86.65 with SMTP id v43mr2632052wee.118.1264622317250; Wed, 27 Jan 2010 11:58:37 -0800 (PST) In-Reply-To: <201001271929.o0RJTVbB053140@lava.sentex.ca> References: <201001271929.o0RJTVbB053140@lava.sentex.ca> Date: Wed, 27 Jan 2010 11:58:37 -0800 Message-ID: <2a41acea1001271158p516ecedfge068edefff02ccbe@mail.gmail.com> From: Jack Vogel To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: new em problems on HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jan 2010 19:58:39 -0000 Please try the driver as updated today and see if this still happens, I sure hope not. Cheers, Jack On Wed, Jan 27, 2010 at 11:29 AM, Mike Tancsa wrote: > > Not sure if the panic is related, but the watchdog timeout issue on bootup > seems to be repeatable on this motherboard with HEAD from last Friday. It > boots up fine under 6.x > > > FreeBSD 9.0-CURRENT #1: Fri Jan 22 16:43:53 EST 2010 > mdtancsa@ich10.sentex.ca:/usr/HEAD/obj/usr/HEAD/src/sys/alix i386 > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) CPU E6500 @ 2.93GHz (0.00-MHz 686-class > CPU) > Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 > > Features=0xbfebfbff > > Features2=0x400e3bd > AMD Features=0x20100000 > AMD Features2=0x1 > TSC: P-state invariant > real memory = 2147483648 (2048 MB) > avail memory = 2089807872 (1992 MB) > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs > FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 > ioapic0 irqs 0-23 on motherboard > ioapic1 irqs 24-47 on motherboard > kbd1 at kbdmux0 > cryptosoft0: on motherboard > acpi0: on motherboard > acpi0: [ITHREAD] > acpi0: Power Button (fixed) > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pcib1: irq 16 at device 1.0 on pci0 > pci1: on pcib1 > pcib2: irq 17 at device 28.0 on pci0 > pci9: on pcib2 > pcib3: at device 0.0 on pci9 > pci10: on pcib3 > pci10: at device 1.0 (no driver attached) > pcib4: irq 17 at device 28.4 on pci0 > pci13: on pcib4 > em0: port 0x5000-0x501f mem > 0xe1000000-0xe101ffff irq 16 at device 0.0 on pci13 > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:30:48:8d:2a:96 > pcib5: irq 16 at device 28.5 on pci0 > pci14: on pcib5 > em1: port 0x6000-0x601f mem > 0xe1100000-0xe111ffff irq 17 at device 0.0 on pci14 > em1: Using MSI interrupt > em1: [FILTER] > em1: Ethernet address: 00:30:48:8d:2a:97 > uhci0: port 0x3000-0x301f irq 23 > at device 29.0 on pci0 > uhci0: [ITHREAD] > usbus0: on uhci0 > uhci1: port 0x3020-0x303f irq 19 > at device 29.1 on pci0 > uhci1: [ITHREAD] > usbus1: on uhci1 > uhci2: port 0x3040-0x305f irq 18 > at device 29.2 on pci0 > uhci2: [ITHREAD] > usbus2: on uhci2 > uhci3: port 0x3060-0x307f irq 16 > at device 29.3 on pci0 > uhci3: [ITHREAD] > usbus3: on uhci3 > ehci0: mem > 0xe0000000-0xe00003ff irq 23 at device 29.7 on pci0 > ehci0: [ITHREAD] > usbus4: EHCI version 1.0 > usbus4: on ehci0 > pcib6: at device 30.0 on pci0 > pci15: on pcib6 > vgapci0: port 0x7000-0x70ff mem > 0xe8000000-0xefffffff,0xe1200000-0xe120ffff irq 16 at device 0.0 on pci15 > isab0: at device 31.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 > ata0: on atapci0 > ata0: [ITHREAD] > pci0: at device 31.3 (no driver attached) > acpi_button0: on acpi0 > atrtc0: port 0x70-0x71 irq 8 on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > uart0: [FILTER] > uart0: console (9600,n,8,1) > uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 > uart1: [FILTER] > cpu0: on acpi0 > est0: on cpu0 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6160b2506000616 > device_attach: est0 attach returned 6 > p4tcc0: on cpu0 > cpu1: on acpi0 > est1: on cpu1 > est: CPU supports Enhanced Speedstep, but is not recognized. > est: cpu_vendor GenuineIntel, msr 6160b2506000616 > device_attach: est1 attach returned 6 > p4tcc1: on cpu1 > pmtimer0 on isa0 > orm0: at iomem > 0xc0000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xcd000-0xcdfff pnpid > ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > Timecounters tick every 1.000 msec > IPsec: Initialized Security Association Processing. > usbus0: 12Mbps Full Speed USB v1.0 > usbus1: 12Mbps Full Speed USB v1.0 > usbus2: 12Mbps Full Speed USB v1.0 > usbus3: 12Mbps Full Speed USB v1.0 > usbus4: 480Mbps High Speed USB v2.0 > SMP: AP CPU #1 Launched! > ugen0.1: at usbus0 > ugen1.1: at usbus1 > uhub0: on usbus0 > uhub1: on usbus1 > Root mount waiting for: usbus4 usbus3 usbus2 usbus1 usbus0 > ugen2.1: at usbus2 > ugen3.1: at usbus3 > uhub2: on usbus2 > uhub3: on usbus3 > ugen4.1: at usbus4 > uhub4: on usbus4 > uhub0: 2 ports with 2 removable, self powered > uhub1: 2 ports with 2 removable, self powered > uhub2: 2 ports with 2 removable, self powered > uhub3: 2 ports with 2 removable, self powered > Root mount waiting for: usbus4 > Root mount waiting for: usbus4 > Root mount waiting for: usbus4 > uhub4: 8 ports with 8 removable, self powered > Trying to mount root from nfs: > NFS ROOT: 10.255.255.1:/usr/home/pxe9/ > em0: Watchdog timeout -- resetting > em0: link state changed to UP > Interface em0 IP-Address 10.255.255.118 Broadcast 10.255.255.255 > mount_nfs: can't update /var/db/mounttab for 10.255.255.1: > /usr/home/pxe9//etc > kernel trap 18 with interrupts disabled > > > Fatal trap 18: integer divide fault while in kernel mode > cpuid = 1; apic id = 01 > instruction pointer = 0x20:0xc0995f0b > stack pointer = 0x28:0xc4e746f8 > frame pointer = 0x28:0xc4e7476c > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 52 (ps) > trap number = 18 > panic: integer divide fault > cpuid = 1 > Uptime: 1m23s > Cannot dump. Device not defined or unavailable. > Automatic reboot in 15 seconds - press a key on the console to abort > > Fatal double fault: > eip = 0xc098e8d0 > esp = 0xc4d00000 > ebp = 0xc4d00020 > cpuid = 1; Rebooting... > apic id = 01 > cpu_reset: Stopping other CPUs > panic: double fault > cpuid = 1 > Uptime: 1m23s > Cannot dump. Device not defined or unavailable. > Automatic reboot in 15 seconds - press a key on the console to abort > Rebooting... > cpu_reset: Stopping other CPUs > > > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 20:20:38 2010 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 39B1F106566C; Wed, 27 Jan 2010 20:20:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id E8C3B8FC15; Wed, 27 Jan 2010 20:20:37 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.3/8.14.3) with ESMTP id o0RKKb74076237; Wed, 27 Jan 2010 15:20:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.3/8.14.3/Submit) id o0RKKbMi076232; Wed, 27 Jan 2010 20:20:37 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 27 Jan 2010 20:20:37 GMT Message-Id: <201001272020.o0RKKbMi076232@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Wed, 27 Jan 2010 20:20:38 -0000 TB --- 2010-01-27 19:18:11 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-01-27 19:18:11 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-01-27 19:18:11 - cleaning the object tree TB --- 2010-01-27 19:18:22 - cvsupping the source tree TB --- 2010-01-27 19:18:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-01-27 19:20:41 - building world TB --- 2010-01-27 19:20:41 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 19:20:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 19:20:41 - TARGET=sparc64 TB --- 2010-01-27 19:20:41 - TARGET_ARCH=sparc64 TB --- 2010-01-27 19:20:41 - TZ=UTC TB --- 2010-01-27 19:20:41 - __MAKE_CONF=/dev/null TB --- 2010-01-27 19:20:41 - cd /src TB --- 2010-01-27 19:20:41 - /usr/bin/make -B buildworld >>> World build started on Wed Jan 27 19:20:41 UTC 2010 >>> 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 Wed Jan 27 20:16:33 UTC 2010 TB --- 2010-01-27 20:16:33 - generating LINT kernel config TB --- 2010-01-27 20:16:33 - cd /src/sys/sparc64/conf TB --- 2010-01-27 20:16:33 - /usr/bin/make -B LINT TB --- 2010-01-27 20:16:33 - building LINT kernel TB --- 2010-01-27 20:16:33 - MAKEOBJDIRPREFIX=/obj TB --- 2010-01-27 20:16:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-01-27 20:16:33 - TARGET=sparc64 TB --- 2010-01-27 20:16:33 - TARGET_ARCH=sparc64 TB --- 2010-01-27 20:16:33 - TZ=UTC TB --- 2010-01-27 20:16:33 - __MAKE_CONF=/dev/null TB --- 2010-01-27 20:16:33 - cd /src TB --- 2010-01-27 20:16:33 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Jan 27 20:16:33 UTC 2010 >>> 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/dev/e1000/if_em.c:5291: error: 'struct adapter' has no member named 'mbuf_cluster_failed' /src/sys/dev/e1000/if_em.c: In function 'em_print_hw_stats': /src/sys/dev/e1000/if_em.c:5332: error: 'struct adapter' has no member named 'rx_irq' /src/sys/dev/e1000/if_em.c:5333: error: 'struct adapter' has no member named 'tx_irq' /src/sys/dev/e1000/if_em.c:5333: warning: format '%ld' expects type 'long int', but argument 5 has type 'int' /src/sys/dev/e1000/if_em.c: In function 'em_sysctl_int_delay': /src/sys/dev/e1000/if_em.c:5462: error: 'struct adapter' has no member named 'txd_cmd' /src/sys/dev/e1000/if_em.c:5466: error: 'struct adapter' has no member named 'txd_cmd' *** Error code 1 Stop in /obj/sparc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-01-27 20:20:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-01-27 20:20:37 - ERROR: failed to build lint kernel TB --- 2010-01-27 20:20:37 - 2766.50 user 581.80 system 3745.14 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 20:53:33 2010 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 DBDD9106568F; Wed, 27 Jan 2010 20:53:33 +0000 (UTC) (envelope-from weongyo.jeong@gmail.com) Received: from mail-qy0-f203.google.com (mail-qy0-f203.google.com [209.85.221.203]) by mx1.freebsd.org (Postfix) with ESMTP id 3A7F88FC17; Wed, 27 Jan 2010 20:53:32 +0000 (UTC) Received: by qyk41 with SMTP id 41so4211039qyk.29 for ; Wed, 27 Jan 2010 12:53:32 -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:mail-followup-to:mime-version :content-type:content-disposition:user-agent:organization :x-operation-sytem; bh=XMY1/a3vO7IxaauwdRU5auawETgw7yn9cQoGMaMePUY=; b=Su7gobfLni0XgHMgJ1zxHHQG3zou/vBVoR7PozxoBp8bmTA6CGisWM7Zw9rFX9LeMR SRGCKkLbqvcF9iLH0mGNJZyGw9vmc/PGFwJ9NWsOekVqj/xvO2FNWrFIyFZA2uo0nY3p fO66MX2iuEIePc1ONKXDvOya5ZtK14clpzAWM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mail-followup-to :mime-version:content-type:content-disposition:user-agent :organization:x-operation-sytem; b=Ark3/Rg9Yh/LAoqescQEhKVzjIpcLiz4nczhzPyvLiyKRYw5LCQjSnRUcMWb8VEQb2 L8E7Id+x3Pu2GIK55OYpefmP3MorD7jbnT+qIYTTvm5ITWtAbCVRLtG2ZVFIcCRu4GIR jBzChkGHIPWEwfSmS/VkMjO9vOl6gaipg4YUU= Received: by 10.224.121.213 with SMTP id i21mr5436640qar.8.1264625612429; Wed, 27 Jan 2010 12:53:32 -0800 (PST) Received: from weongyo ([174.35.1.224]) by mx.google.com with ESMTPS id 6sm561154qwk.50.2010.01.27.12.53.29 (version=SSLv3 cipher=RC4-MD5); Wed, 27 Jan 2010 12:53:31 -0800 (PST) Received: by weongyo (sSMTP sendmail emulation); Wed, 27 Jan 2010 12:53:38 -0800 From: Weongyo Jeong Date: Wed, 27 Jan 2010 12:53:38 -0800 To: current@freebsd.org Message-ID: <20100127205338.GA28399@weongyo> Mail-Followup-To: current@freebsd.org, imp@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Organization: CDNetworks. X-Operation-Sytem: FreeBSD Cc: imp@freebsd.org Subject: HEADUP: major update of siba(4) - again X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Weongyo Jeong List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 20:53:33 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jan 12, 2010 at 01:33:29PM -0800, Weongyo Jeong wrote: > Hello, > > As someone know I posted a new ssb(4) driver to support bwn(4) driver > I'd written some weeks ago and gavin@ told me that there's a almost > same-purpose driver called siba(4) that could be merged into one with > ssb(4). > > As a result I made a patch here: > > http://people.freebsd.org/~weongyo/patch_siba_20100112.diff > > The changes are as follows: > > - This patch is focused to support Broadcom Wireless NICs so major > consumer would be bwn(4) currently. > - could break backward compatibility of siba(4). But I could not > find consumers of siba(4), Makefile to build or examples in the > tree. > - adds a siba(4) man page that it'll be reviewed before committing. > > If no objections, I'll commit it by end of this week. I made an another patch not to break the backward compatibility of siba(4). http://people.freebsd.org/~weongyo/patch_siba_20100127.diff This version is tested just on MIPS cross-compilation due to lack of H/W but I expect that the patch doesn't touch any original siba(4) logics. By design reasons I made a siba_bwn bridge module whose parent device is PCI that placed at sys/modules/siba_bwn/Makefile. I believe that with this patch I solved a objection until now so If no more objections by end of this week, I'll commit it into HEAD. regards, Weongyo Jeong --YiEDa0DAkWCtVeE4 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="patch_siba_20100127.diff" Index: siba.c =================================================================== --- siba.c (revision 202983) +++ siba.c (working copy) @@ -37,9 +37,9 @@ #include -#include -#include #include +#include +#include /* * TODO: De-mipsify this code. @@ -77,7 +77,7 @@ "MIPS core" }, { SIBA_VID_BROADCOM, SIBA_DEVID_ETHERNET, SIBA_REV_ANY, "Ethernet core" }, - { SIBA_VID_BROADCOM, SIBA_DEVID_USB, SIBA_REV_ANY, + { SIBA_VID_BROADCOM, SIBA_DEVID_USB11_HOSTDEV, SIBA_REV_ANY, "USB host controller" }, { SIBA_VID_BROADCOM, SIBA_DEVID_IPSEC, SIBA_REV_ANY, "IPSEC accelerator" }, @@ -103,7 +103,6 @@ static struct resource_list * siba_get_reslist(device_t, device_t); static uint8_t siba_getirq(uint16_t); -static uint8_t siba_getncores(uint16_t); static int siba_print_all_resources(device_t dev); static int siba_print_child(device_t, device_t); static int siba_probe(device_t); @@ -112,32 +111,9 @@ static struct siba_devinfo * siba_setup_devinfo(device_t, uint8_t); int siba_write_ivar(device_t, device_t, int, uintptr_t); +uint8_t siba_getncores(device_t, uint16_t); /* - * Earlier ChipCommon revisions have hardcoded number of cores - * present dependent on the ChipCommon ID. - */ -static uint8_t -siba_getncores(uint16_t ccid) -{ - uint8_t ncores; - - switch (ccid) { - case SIBA_CCID_SENTRY5: - ncores = 7; - break; - case SIBA_CCID_BCM4710: - case SIBA_CCID_BCM4704: - ncores = 9; - break; - default: - ncores = 0; - } - - return (ncores); -} - -/* * On the Sentry5, the system bus IRQs are the same as the * MIPS IRQs. Particular cores are hardwired to certain IRQ lines. */ @@ -156,7 +132,7 @@ case SIBA_DEVID_IPSEC: irq = 2; break; - case SIBA_DEVID_USB: + case SIBA_DEVID_USB11_HOSTDEV: irq = 3; break; case SIBA_DEVID_PCI: @@ -188,7 +164,7 @@ uint16_t ccid; int rid; - sc->sc_dev = dev; + sc->siba_dev = dev; //rman_debug = 1; /* XXX */ @@ -197,24 +173,24 @@ * was compiled with. */ rid = MIPS_MEM_RID; - sc->sc_mem = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, + sc->siba_mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, &rid, RF_ACTIVE); - if (sc->sc_mem == NULL) { + if (sc->siba_mem_res == NULL) { device_printf(dev, "unable to allocate probe aperture\n"); return (ENXIO); } - sc->sc_bt = rman_get_bustag(sc->sc_mem); - sc->sc_bh = rman_get_bushandle(sc->sc_mem); - sc->sc_maddr = rman_get_start(sc->sc_mem); - sc->sc_msize = rman_get_size(sc->sc_mem); + sc->siba_mem_bt = rman_get_bustag(sc->siba_mem_res); + sc->siba_mem_bh = rman_get_bushandle(sc->siba_mem_res); + sc->siba_maddr = rman_get_start(sc->siba_mem_res); + sc->siba_msize = rman_get_size(sc->siba_mem_res); if (siba_debug) { device_printf(dev, "start %08x len %08x\n", - sc->sc_maddr, sc->sc_msize); + sc->siba_maddr, sc->siba_msize); } - idlo = siba_read_4(sc, 0, SIBA_CORE_IDLO); - idhi = siba_read_4(sc, 0, SIBA_CORE_IDHI); + idlo = siba_mips_read_4(sc, 0, SIBA_IDLOW); + idhi = siba_mips_read_4(sc, 0, SIBA_IDHIGH); ccid = ((idhi & 0x8ff0) >> 4); if (siba_debug) { device_printf(dev, "idlo = %08x\n", idlo); @@ -256,7 +232,7 @@ uint16_t cc_id; uint16_t cc_rev; - ccidreg = siba_read_4(sc, 0, SIBA_CC_CCID); + ccidreg = siba_mips_read_4(sc, 0, SIBA_CC_CHIPID); cc_id = (ccidreg & SIBA_CC_IDMASK); cc_rev = (ccidreg & SIBA_CC_REVMASK) >> SIBA_CC_REVSHIFT; if (siba_debug) { @@ -264,9 +240,9 @@ ccidreg, cc_id, cc_rev); } - sc->sc_ncores = siba_getncores(cc_id); + sc->siba_ncores = siba_getncores(dev, cc_id); if (siba_debug) { - device_printf(dev, "%d cores detected.\n", sc->sc_ncores); + device_printf(dev, "%d cores detected.\n", sc->siba_ncores); } /* @@ -275,36 +251,38 @@ */ rid = MIPS_MEM_RID; int result; - result = bus_release_resource(dev, SYS_RES_MEMORY, rid, sc->sc_mem); + result = bus_release_resource(dev, SYS_RES_MEMORY, rid, + sc->siba_mem_res); if (result != 0) { device_printf(dev, "error %d releasing resource\n", result); return (ENXIO); } uint32_t total; - total = sc->sc_ncores * SIBA_CORE_LEN; + total = sc->siba_ncores * SIBA_CORE_LEN; /* XXX Don't allocate the entire window until we * enumerate the bus. Once the bus has been enumerated, * and instance variables/children instantiated + populated, * release the resource so children may attach. */ - sc->sc_mem = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, - sc->sc_maddr, sc->sc_maddr + total - 1, total, RF_ACTIVE); - if (sc->sc_mem == NULL) { + sc->siba_mem_res = bus_alloc_resource(dev, SYS_RES_MEMORY, &rid, + sc->siba_maddr, sc->siba_maddr + total - 1, total, RF_ACTIVE); + if (sc->siba_mem_res == NULL) { device_printf(dev, "unable to allocate entire aperture\n"); return (ENXIO); } - sc->sc_bt = rman_get_bustag(sc->sc_mem); - sc->sc_bh = rman_get_bushandle(sc->sc_mem); - sc->sc_maddr = rman_get_start(sc->sc_mem); - sc->sc_msize = rman_get_size(sc->sc_mem); + sc->siba_mem_bt = rman_get_bustag(sc->siba_mem_res); + sc->siba_mem_bh = rman_get_bushandle(sc->siba_mem_res); + sc->siba_maddr = rman_get_start(sc->siba_mem_res); + sc->siba_msize = rman_get_size(sc->siba_mem_res); if (siba_debug) { device_printf(dev, "after remapping: start %08x len %08x\n", - sc->sc_maddr, sc->sc_msize); + sc->siba_maddr, sc->siba_msize); } - bus_set_resource(dev, SYS_RES_MEMORY, rid, sc->sc_maddr, sc->sc_msize); + bus_set_resource(dev, SYS_RES_MEMORY, rid, sc->siba_maddr, + sc->siba_msize); /* * We need a manager for the space we claim on nexus to @@ -313,12 +291,13 @@ * otherwise it may be claimed elsewhere. * XXX move to softc */ - mem_rman.rm_start = sc->sc_maddr; - mem_rman.rm_end = sc->sc_maddr + sc->sc_msize - 1; + mem_rman.rm_start = sc->siba_maddr; + mem_rman.rm_end = sc->siba_maddr + sc->siba_msize - 1; mem_rman.rm_type = RMAN_ARRAY; mem_rman.rm_descr = "SiBa I/O memory addresses"; if (rman_init(&mem_rman) != 0 || - rman_manage_region(&mem_rman, mem_rman.rm_start, mem_rman.rm_end) != 0) { + rman_manage_region(&mem_rman, mem_rman.rm_start, + mem_rman.rm_end) != 0) { panic("%s: mem_rman", __func__); } @@ -344,7 +323,7 @@ * NB: only one core may be mapped at any time if the siba bus * is the child of a PCI or PCMCIA bus. */ - for (idx = 0; idx < sc->sc_ncores; idx++) { + for (idx = 0; idx < sc->siba_ncores; idx++) { sdi = siba_setup_devinfo(dev, idx); child = device_add_child(dev, NULL, -1); if (child == NULL) @@ -483,13 +462,14 @@ sdi = malloc(sizeof(*sdi), M_DEVBUF, M_WAITOK | M_ZERO); resource_list_init(&sdi->sdi_rl); - idlo = siba_read_4(sc, idx, SIBA_CORE_IDLO); - idhi = siba_read_4(sc, idx, SIBA_CORE_IDHI); + idlo = siba_mips_read_4(sc, idx, SIBA_IDLOW); + idhi = siba_mips_read_4(sc, idx, SIBA_IDHIGH); - vendorid = (idhi & SIBA_IDHIGH_VC) >> SIBA_IDHIGH_VC_SHIFT; + vendorid = (idhi & SIBA_IDHIGH_VENDORMASK) >> + SIBA_IDHIGH_VENDOR_SHIFT; devid = ((idhi & 0x8ff0) >> 4); - rev = (idhi & SIBA_IDHIGH_RCLO); - rev |= (idhi & SIBA_IDHIGH_RCHI) >> SIBA_IDHIGH_RCHI_SHIFT; + rev = (idhi & SIBA_IDHIGH_REVLO); + rev |= (idhi & SIBA_IDHIGH_REVHI) >> SIBA_IDHIGH_REVHI_SHIFT; sdi->sdi_vid = vendorid; sdi->sdi_devid = devid; @@ -500,7 +480,7 @@ /* * Determine memory window on bus and irq if one is needed. */ - baseaddr = sc->sc_maddr + (idx * SIBA_CORE_LEN); + baseaddr = sc->siba_maddr + (idx * SIBA_CORE_LEN); resource_list_add(&sdi->sdi_rl, SYS_RES_MEMORY, MIPS_MEM_RID, /* XXX */ baseaddr, baseaddr + SIBA_CORE_LEN - 1, SIBA_CORE_LEN); Index: sibareg.h =================================================================== --- sibareg.h (revision 202983) +++ sibareg.h (working copy) @@ -34,40 +34,383 @@ #ifndef _SIBA_SIBAREG_H_ #define _SIBA_SIBAREG_H_ +#define PCI_DEVICE_ID_BCM4401 0x4401 +#define PCI_DEVICE_ID_BCM4401B0 0x4402 +#define PCI_DEVICE_ID_BCM4401B1 0x170c +#define SIBA_PCIR_BAR PCIR_BAR(0) +#define SIBA_CCID_BCM4710 0x4710 +#define SIBA_CCID_BCM4704 0x4704 +#define SIBA_CCID_SENTRY5 0x5365 + +/* + * ChipCommon registers. + */ +#define SIBA_CC_CHIPID 0x0000 +#define SIBA_CC_IDMASK 0x0000ffff +#define SIBA_CC_ID(id) (id & SIBA_CC_IDMASK) +#define SIBA_CC_REVMASK 0x000f0000 +#define SIBA_CC_REVSHIFT 16 +#define SIBA_CC_REV(id) \ + ((id & SIBA_CC_REVMASK) >> SIBA_CC_REVSHIFT) +#define SIBA_CC_PKGMASK 0x00F00000 +#define SIBA_CC_PKGSHIFT 20 +#define SIBA_CC_PKG(id) \ + ((id & SIBA_CC_PKGMASK) >> SIBA_CC_PKGSHIFT) +#define SIBA_CC_NCORESMASK 0x0F000000 +#define SIBA_CC_NCORESSHIFT 24 +#define SIBA_CC_NCORES(id) \ + ((id & SIBA_CC_NCORESMASK) >> SIBA_CC_NCORESSHIFT) +#define SIBA_CC_CAPS 0x0004 +#define SIBA_CC_CAPS_PWCTL 0x00040000 +#define SIBA_CC_CAPS_PMU 0x10000000 /* PMU (rev >= 20) */ +#define SIBA_CC_CHIPCTL 0x0028 /* rev >= 11 */ +#define SIBA_CC_CHIPSTAT 0x002C /* rev >= 11 */ +#define SIBA_CC_BCAST_ADDR 0x0050 /* Broadcast Address */ +#define SIBA_CC_BCAST_DATA 0x0054 /* Broadcast Data */ +#define SIBA_CC_PLLONDELAY 0x00B0 /* Rev >= 4 only */ +#define SIBA_CC_FREFSELDELAY 0x00B4 /* Rev >= 4 only */ +#define SIBA_CC_CLKSLOW 0x00b8 /* 6 <= Rev <= 9 only */ +#define SIBA_CC_CLKSLOW_SRC 0x00000007 +#define SIBA_CC_CLKSLOW_SRC_CRYSTAL 0x00000001 +#define SIBA_CC_CLKSLOW_FSLOW 0x00000800 +#define SIBA_CC_CLKSLOW_IPLL 0x00001000 +#define SIBA_CC_CLKSLOW_ENXTAL 0x00002000 +#define SIBA_CC_CLKSYSCTL 0x00C0 /* Rev >= 3 only */ +#define SIBA_CC_CLKCTLSTATUS 0x01e0 +#define SIBA_CC_CLKCTLSTATUS_HT 0x00010000 +#define SIBA_CC_UART0 0x0300 /* offset of UART0 */ +#define SIBA_CC_UART1 0x0400 /* offset of UART1 */ +#define SIBA_CC_PMUCTL 0x0600 /* PMU control */ +#define SIBA_CC_PMUCTL_ILP 0xffff0000 /* mask */ +#define SIBA_CC_PMUCTL_NOILP 0x00000200 +#define SIBA_CC_PMUCTL_XF 0x0000007c /* crystal freq */ +#define SIBA_CC_PMUCTL_XF_VAL(id) ((id & 0x0000007c) >> 2) +#define SIBA_CC_PMUCAPS 0x0604 +#define SIBA_CC_PMUCAPS_REV 0x000000ff +#define SIBA_CC_PMU_MINRES 0x0618 +#define SIBA_CC_PMU_MAXRES 0x061c +#define SIBA_CC_PMU_TABSEL 0x0620 +#define SIBA_CC_PMU_DEPMSK 0x0624 +#define SIBA_CC_PMU_UPDNTM 0x0628 +#define SIBA_CC_PLLCTL_ADDR 0x0660 +#define SIBA_CC_PLLCTL_DATA 0x0664 + +#define SIBA_CC_PMU0_PLL0 0 +#define SIBA_CC_PMU0_PLL0_PDIV_MSK 0x00000001 +#define SIBA_CC_PMU0_PLL0_PDIV_FREQ 25000 +#define SIBA_CC_PMU0_PLL1 1 +#define SIBA_CC_PMU0_PLL1_IMSK 0xf0000000 +#define SIBA_CC_PMU0_PLL1_FMSK 0x0fffff00 +#define SIBA_CC_PMU0_PLL1_STOPMOD 0x00000040 +#define SIBA_CC_PMU0_PLL2 2 +#define SIBA_CC_PMU0_PLL2_IMSKHI 0x0000000f +#define SIBA_CC_PMU1_PLL0 0 +#define SIBA_CC_PMU1_PLL0_P1DIV 0x00f00000 +#define SIBA_CC_PMU1_PLL0_P2DIV 0x0f000000 +#define SIBA_CC_PMU1_PLL2 2 +#define SIBA_CC_PMU1_PLL2_NDIVMODE 0x000e0000 +#define SIBA_CC_PMU1_PLL2_NDIVINT 0x1ff00000 +#define SIBA_CC_PMU1_PLL3 3 +#define SIBA_CC_PMU1_PLL3_NDIVFRAC 0x00ffffff +#define SIBA_CC_PMU1_PLL5 5 +#define SIBA_CC_PMU1_PLL5_CLKDRV 0xffffff00 + +#define SIBA_CC_PMU0_DEFAULT_XTALFREQ 20000 +#define SIBA_CC_PMU1_DEFAULT_FREQ 15360 + +#define SIBA_CC_PMU1_PLLTAB_ENTRY \ +{ \ + { 12000, 1, 3, 22, 0x9, 0xffffef }, \ + { 13000, 2, 1, 6, 0xb, 0x483483 }, \ + { 14400, 3, 1, 10, 0xa, 0x1c71c7 }, \ + { 15360, 4, 1, 5, 0xb, 0x755555 }, \ + { 16200, 5, 1, 10, 0x5, 0x6e9e06 }, \ + { 16800, 6, 1, 10, 0x5, 0x3cf3cf }, \ + { 19200, 7, 1, 9, 0x5, 0x17b425 }, \ + { 19800, 8, 1, 11, 0x4, 0xa57eb }, \ + { 20000, 9, 1, 11, 0x4, 0 }, \ + { 24000, 10, 3, 11, 0xa, 0 }, \ + { 25000, 11, 5, 16, 0xb, 0 }, \ + { 26000, 12, 1, 2, 0x10, 0xec4ec4 }, \ + { 30000, 13, 3, 8, 0xb, 0 }, \ + { 38400, 14, 1, 5, 0x4, 0x955555 }, \ + { 40000, 15, 1, 2, 0xb, 0 } \ +} + +#define SIBA_CC_PMU0_PLLTAB_ENTRY \ +{ \ + { 12000, 1, 73, 349525, }, { 13000, 2, 67, 725937, }, \ + { 14400, 3, 61, 116508, }, { 15360, 4, 57, 305834, }, \ + { 16200, 5, 54, 336579, }, { 16800, 6, 52, 399457, }, \ + { 19200, 7, 45, 873813, }, { 19800, 8, 44, 466033, }, \ + { 20000, 9, 44, 0, }, { 25000, 10, 70, 419430, }, \ + { 26000, 11, 67, 725937, }, { 30000, 12, 58, 699050, }, \ + { 38400, 13, 45, 873813, }, { 40000, 14, 45, 0, }, \ +} + +#define SIBA_CC_PMU_4325_BURST 1 +#define SIBA_CC_PMU_4325_CLBURST 3 +#define SIBA_CC_PMU_4325_LN 10 +#define SIBA_CC_PMU_4325_CRYSTAL 13 +#define SIBA_CC_PMU_4325_RX_PWR 15 +#define SIBA_CC_PMU_4325_TX_PWR 16 +#define SIBA_CC_PMU_4325_LOGEN_PWR 18 +#define SIBA_CC_PMU_4325_AFE_PWR 19 +#define SIBA_CC_PMU_4325_BBPLL_PWR 20 +#define SIBA_CC_PMU_4325_HT 21 +#define SIBA_CC_PMU_4328_EXT_SWITCH_PWM 0 +#define SIBA_CC_PMU_4328_BB_SWITCH_PWM 1 +#define SIBA_CC_PMU_4328_BB_SWITCH_BURST 2 +#define SIBA_CC_PMU_4328_BB_EXT_SWITCH_BURST 3 +#define SIBA_CC_PMU_4328_ILP_REQUEST 4 +#define SIBA_CC_PMU_4328_RADSWITCH_PWM 5 /* radio switch */ +#define SIBA_CC_PMU_4328_RADSWITCH_BURST 6 +#define SIBA_CC_PMU_4328_ROM_SWITCH 7 +#define SIBA_CC_PMU_4328_PA_REF 8 +#define SIBA_CC_PMU_4328_RADIO 9 +#define SIBA_CC_PMU_4328_AFE 10 +#define SIBA_CC_PMU_4328_PLL 11 +#define SIBA_CC_PMU_4328_BG_FILTBYP 12 +#define SIBA_CC_PMU_4328_TX_FILTBYP 13 +#define SIBA_CC_PMU_4328_RX_FILTBYP 14 +#define SIBA_CC_PMU_4328_CRYSTAL_PU 15 +#define SIBA_CC_PMU_4328_CRYSTAL_EN 16 +#define SIBA_CC_PMU_4328_BB_PLL_FILTBYP 17 +#define SIBA_CC_PMU_4328_RF_PLL_FILTBYP 18 +#define SIBA_CC_PMU_4328_BB_PLL_PU 19 +#define SIBA_CC_PMU_5354_BB_PLL_PU 19 + +#define SIBA_CC_PMU_4325_RES_UPDOWN \ +{ \ + { SIBA_CC_PMU_4325_CRYSTAL, 0x1501 } \ +} + +#define SIBA_CC_PMU_4325_RES_DEPEND \ +{ \ + { SIBA_CC_PMU_4325_HT, SIBA_CC_PMU_DEP_ADD, \ + ((1 << SIBA_CC_PMU_4325_RX_PWR) | \ + (1 << SIBA_CC_PMU_4325_TX_PWR) | \ + (1 << SIBA_CC_PMU_4325_LOGEN_PWR) | \ + (1 << SIBA_CC_PMU_4325_AFE_PWR)) } \ +} + +#define SIBA_CC_PMU_4328_RES_UPDOWN \ +{ \ + { SIBA_CC_PMU_4328_EXT_SWITCH_PWM, 0x0101 }, \ + { SIBA_CC_PMU_4328_BB_SWITCH_PWM, 0x1f01 }, \ + { SIBA_CC_PMU_4328_BB_SWITCH_BURST, 0x010f }, \ + { SIBA_CC_PMU_4328_BB_EXT_SWITCH_BURST, 0x0101 }, \ + { SIBA_CC_PMU_4328_ILP_REQUEST, 0x0202 }, \ + { SIBA_CC_PMU_4328_RADSWITCH_PWM, 0x0f01 }, \ + { SIBA_CC_PMU_4328_RADSWITCH_BURST, 0x0f01 }, \ + { SIBA_CC_PMU_4328_ROM_SWITCH, 0x0101 }, \ + { SIBA_CC_PMU_4328_PA_REF, 0x0f01 }, \ + { SIBA_CC_PMU_4328_RADIO, 0x0f01 }, \ + { SIBA_CC_PMU_4328_AFE, 0x0f01 }, \ + { SIBA_CC_PMU_4328_PLL, 0x0f01 }, \ + { SIBA_CC_PMU_4328_BG_FILTBYP, 0x0101 }, \ + { SIBA_CC_PMU_4328_TX_FILTBYP, 0x0101 }, \ + { SIBA_CC_PMU_4328_RX_FILTBYP, 0x0101 }, \ + { SIBA_CC_PMU_4328_CRYSTAL_PU, 0x0101 }, \ + { SIBA_CC_PMU_4328_CRYSTAL_EN, 0xa001 }, \ + { SIBA_CC_PMU_4328_BB_PLL_FILTBYP, 0x0101 }, \ + { SIBA_CC_PMU_4328_RF_PLL_FILTBYP, 0x0101 }, \ + { SIBA_CC_PMU_4328_BB_PLL_PU, 0x0701 }, \ +} + +#define SIBA_CC_PMU_4328_RES_DEPEND \ +{ \ + { SIBA_CC_PMU_4328_ILP_REQUEST, SIBA_CC_PMU_DEP_SET, \ + ((1 << SIBA_CC_PMU_4328_EXT_SWITCH_PWM) | \ + (1 << SIBA_CC_PMU_4328_BB_SWITCH_PWM)) }, \ +} + +#define SIBA_CC_CHST_4325_PMUTOP_2B 0x00000200 + +#define SIBA_BAR0 0x80 +#define SIBA_IRQMASK 0x94 +#define SIBA_GPIO_IN 0xb0 +#define SIBA_GPIO_OUT 0xb4 +#define SIBA_GPIO_OUT_EN 0xb8 +#define SIBA_GPIO_CRYSTAL 0x40 +#define SIBA_GPIO_PLL 0x80 + +#define SIBA_REGWIN(x) \ + (SIBA_ENUM_START + ((x) * SIBA_CORE_LEN)) #define SIBA_CORE_LEN 0x00001000 /* Size of cfg per core */ #define SIBA_CFG_END 0x00010000 /* Upper bound of cfg space */ #define SIBA_MAX_CORES (SIBA_CFG_END/SIBA_CORE_LEN) /* #max cores */ +#define SIBA_ENUM_START 0x18000000U +#define SIBA_ENUM_END 0x18010000U -/* offset of high ID register */ -#define SIBA_CORE_IDLO 0x00000ff8 -#define SIBA_CORE_IDHI 0x00000ffc +#define SIBA_DMA_TRANSLATION_MASK 0xc0000000 -/* - * Offsets of ChipCommon core registers. - * XXX: move to siba_cc - */ -#define SIBA_CC_UART0 0x00000300 /* offset of UART0 */ -#define SIBA_CC_UART1 0x00000400 /* offset of UART1 */ +#define SIBA_PCI_DMA 0x40000000U +#define SIBA_TPS 0x0f18 +#define SIBA_TPS_BPFLAG 0x0000003f +#define SIBA_IAS 0x0f90 /* Initiator Agent State */ +#define SIBA_IAS_INBAND_ERR 0x00020000 +#define SIBA_IAS_TIMEOUT 0x00040000 +#define SIBA_INTR_MASK 0x0f94 +#define SIBA_TGSLOW 0x0f98 +#define SIBA_TGSLOW_RESET 0x00000001 /* target state low */ +#define SIBA_TGSLOW_REJECT_22 0x00000002 +#define SIBA_TGSLOW_REJECT_23 0x00000004 +#define SIBA_TGSLOW_CLOCK 0x00010000 +#define SIBA_TGSLOW_FGC 0x00020000 +#define SIBA_TGSHIGH 0x0f9c +#define SIBA_TGSHIGH_SERR 0x00000001 +#define SIBA_TGSHIGH_BUSY 0x00000004 +#define SIBA_TGSHIGH_DMA64 0x10000000 +#define SIBA_IMCFGLO 0x0fa8 +#define SIBA_IMCFGLO_SERTO 0x00000007 +#define SIBA_IMCFGLO_REQTO 0x00000070 +#define SIBA_IDLOW 0x0ff8 +#define SIBA_IDLOW_SSBREV 0xf0000000 +#define SIBA_IDLOW_SSBREV_22 0x00000000 +#define SIBA_IDLOW_SSBREV_23 0x10000000 +#define SIBA_IDLOW_SSBREV_24 0x40000000 +#define SIBA_IDLOW_SSBREV_25 0x50000000 +#define SIBA_IDLOW_SSBREV_26 0x60000000 +#define SIBA_IDLOW_SSBREV_27 0x70000000 +#define SIBA_IDHIGH 0x0ffc +#define SIBA_IDHIGH_CORECODEMASK 0x00008FF0 /* Core Code */ +#define SIBA_IDHIGH_CORECODE_SHIFT 4 +#define SIBA_IDHIGH_CORECODE(id) \ + ((id & SIBA_IDHIGH_CORECODEMASK) >> SIBA_IDHIGH_CORECODE_SHIFT) +/* Revision Code (low part) */ +#define SIBA_IDHIGH_REVLO 0x0000000f +/* Revision Code (high part) */ +#define SIBA_IDHIGH_REVHI 0x00007000 +#define SIBA_IDHIGH_REVHI_SHIFT 8 +#define SIBA_IDHIGH_REV(id) \ + ((id & SIBA_IDHIGH_REVLO) | ((id & SIBA_IDHIGH_REVHI) >> \ + SIBA_IDHIGH_REVHI_SHIFT)) +#define SIBA_IDHIGH_VENDORMASK 0xFFFF0000 /* Vendor Code */ +#define SIBA_IDHIGH_VENDOR_SHIFT 16 +#define SIBA_IDHIGH_VENDOR(id) \ + ((id & SIBA_IDHIGH_VENDORMASK) >> SIBA_IDHIGH_VENDOR_SHIFT) -#define SIBA_CC_CCID 0x0000 -#define SIBA_CC_IDMASK 0x0000FFFF -#define SIBA_CC_REVMASK 0x000F0000 -#define SIBA_CC_REVSHIFT 16 -#define SIBA_CC_PACKMASK 0x00F00000 -#define SIBA_CC_PACKSHIFT 20 -#define SIBA_CC_NRCORESMASK 0x0F000000 -#define SIBA_CC_NRCORESSHIFT 24 +#define SIBA_SPROMSIZE_R123 64 +#define SIBA_SPROMSIZE_R4 220 +#define SIBA_SPROM_BASE 0x1000 +#define SIBA_SPROM_REV_CRC 0xff00 +#define SIBA_SPROM1_MAC_80211BG 0x1048 +#define SIBA_SPROM1_MAC_ETH 0x104e +#define SIBA_SPROM1_MAC_80211A 0x1054 +#define SIBA_SPROM1_ETHPHY 0x105a +#define SIBA_SPROM1_ETHPHY_MII_ETH0 0x001f +#define SIBA_SPROM1_ETHPHY_MII_ETH1 0x03e0 +#define SIBA_SPROM1_ETHPHY_MDIO_ETH0 (1 << 14) +#define SIBA_SPROM1_ETHPHY_MDIO_ETH1 (1 << 15) +#define SIBA_SPROM1_BOARDINFO 0x105c +#define SIBA_SPROM1_BOARDINFO_BREV 0x00ff +#define SIBA_SPROM1_BOARDINFO_CCODE 0x0f00 +#define SIBA_SPROM1_BOARDINFO_ANTBG 0x3000 +#define SIBA_SPROM1_BOARDINFO_ANTA 0xc000 +#define SIBA_SPROM1_PA0B0 0x105e +#define SIBA_SPROM1_PA0B1 0x1060 +#define SIBA_SPROM1_PA0B2 0x1062 +#define SIBA_SPROM1_GPIOA 0x1064 +#define SIBA_SPROM1_GPIOA_P0 0x00ff +#define SIBA_SPROM1_GPIOA_P1 0xff00 +#define SIBA_SPROM1_GPIOB 0x1066 +#define SIBA_SPROM1_GPIOB_P2 0x00ff +#define SIBA_SPROM1_GPIOB_P3 0xff00 +#define SIBA_SPROM1_MAXPWR 0x1068 +#define SIBA_SPROM1_MAXPWR_BG 0x00ff +#define SIBA_SPROM1_MAXPWR_A 0xff00 +#define SIBA_SPROM1_PA1B0 0x106a +#define SIBA_SPROM1_PA1B1 0x106c +#define SIBA_SPROM1_PA1B2 0x106e +#define SIBA_SPROM1_TSSI 0x1070 +#define SIBA_SPROM1_TSSI_BG 0x00ff +#define SIBA_SPROM1_TSSI_A 0xff00 +#define SIBA_SPROM1_BFLOW 0x1072 +#define SIBA_SPROM1_AGAIN 0x1074 +#define SIBA_SPROM1_AGAIN_BG 0x00ff +#define SIBA_SPROM1_AGAIN_A 0xff00 +#define SIBA_SPROM2_BFHIGH 0x1038 +#define SIBA_SPROM3_MAC_80211BG 0x104a +#define SIBA_SPROM4_MAC_80211BG 0x104c +#define SIBA_SPROM4_ETHPHY 0x105a +#define SIBA_SPROM4_ETHPHY_ET0A 0x001f +#define SIBA_SPROM4_ETHPHY_ET1A 0x03e0 +#define SIBA_SPROM4_CCODE 0x1052 +#define SIBA_SPROM4_ANTAVAIL 0x105d +#define SIBA_SPROM4_ANTAVAIL_A 0x00ff +#define SIBA_SPROM4_ANTAVAIL_BG 0xff00 +#define SIBA_SPROM4_BFLOW 0x1044 +#define SIBA_SPROM4_AGAIN01 0x105e +#define SIBA_SPROM4_AGAIN0 0x00ff +#define SIBA_SPROM4_AGAIN1 0xff00 +#define SIBA_SPROM4_AGAIN23 0x1060 +#define SIBA_SPROM4_AGAIN2 0x00ff +#define SIBA_SPROM4_AGAIN3 0xff00 +#define SIBA_SPROM4_BFHIGH 0x1046 +#define SIBA_SPROM4_MAXP_BG 0x1080 +#define SIBA_SPROM4_MAXP_BG_MASK 0x00ff +#define SIBA_SPROM4_TSSI_BG 0xff00 +#define SIBA_SPROM4_MAXP_A 0x108a +#define SIBA_SPROM4_MAXP_A_MASK 0x00ff +#define SIBA_SPROM4_TSSI_A 0xff00 +#define SIBA_SPROM4_GPIOA 0x1056 +#define SIBA_SPROM4_GPIOA_P0 0x00ff +#define SIBA_SPROM4_GPIOA_P1 0xff00 +#define SIBA_SPROM4_GPIOB 0x1058 +#define SIBA_SPROM4_GPIOB_P2 0x00ff +#define SIBA_SPROM4_GPIOB_P3 0xff00 +#define SIBA_SPROM5_BFLOW 0x104a +#define SIBA_SPROM5_BFHIGH 0x104c +#define SIBA_SPROM5_MAC_80211BG 0x1052 +#define SIBA_SPROM5_CCODE 0x1044 +#define SIBA_SPROM5_GPIOA 0x1076 +#define SIBA_SPROM5_GPIOA_P0 0x00ff +#define SIBA_SPROM5_GPIOA_P1 0xff00 +#define SIBA_SPROM5_GPIOB 0x1078 +#define SIBA_SPROM5_GPIOB_P2 0x00ff +#define SIBA_SPROM5_GPIOB_P3 0xff00 +#define SIBA_SPROM8_BFLOW 0x1084 +#define SIBA_SPROM8_BFHIGH 0x1086 +#define SIBA_SPROM8_CCODE 0x1092 +#define SIBA_SPROM8_ANTAVAIL 0x109c +#define SIBA_SPROM8_ANTAVAIL_A 0xff00 +#define SIBA_SPROM8_ANTAVAIL_BG 0x00ff +#define SIBA_SPROM8_AGAIN01 0x109e +#define SIBA_SPROM8_AGAIN0 0x00ff +#define SIBA_SPROM8_AGAIN1 0xff00 +#define SIBA_SPROM8_AGAIN23 0x10a0 +#define SIBA_SPROM8_AGAIN2 0x00ff +#define SIBA_SPROM8_AGAIN3 0xff00 +#define SIBA_SPROM8_GPIOA 0x1096 +#define SIBA_SPROM8_GPIOA_P0 0x00ff +#define SIBA_SPROM8_GPIOA_P1 0xff00 +#define SIBA_SPROM8_GPIOB 0x1098 +#define SIBA_SPROM8_GPIOB_P2 0x00ff +#define SIBA_SPROM8_GPIOB_P3 0xff00 +#define SIBA_SPROM8_MAXP_BG 0x10c0 +#define SIBA_SPROM8_MAXP_BG_MASK 0x00ff +#define SIBA_SPROM8_TSSI_BG 0xff00 +#define SIBA_SPROM8_MAXP_A 0x10c8 +#define SIBA_SPROM8_MAXP_A_MASK 0x00ff +#define SIBA_SPROM8_TSSI_A 0xff00 -#define SIBA_IDHIGH_RCLO 0x0000000F /* Revision Code (low part) */ -#define SIBA_IDHIGH_CC 0x00008FF0 /* Core Code */ -#define SIBA_IDHIGH_CC_SHIFT 4 -#define SIBA_IDHIGH_RCHI 0x00007000 /* Revision Code (high part) */ -#define SIBA_IDHIGH_RCHI_SHIFT 8 -#define SIBA_IDHIGH_VC 0xFFFF0000 /* Vendor Code */ -#define SIBA_IDHIGH_VC_SHIFT 16 +#define SIBA_BOARDVENDOR_DELL 0x1028 +#define SIBA_BOARDVENDOR_BCM 0x14e4 +#define SIBA_BOARD_BCM4309G 0x0421 +#define SIBA_BOARD_MP4318 0x044a +#define SIBA_BOARD_BU4306 0x0416 +#define SIBA_BOARD_BU4309 0x040a -#define SIBA_CCID_BCM4710 0x4710 -#define SIBA_CCID_BCM4704 0x4704 -#define SIBA_CCID_SENTRY5 0x5365 +#define SIBA_PCICORE_BCAST_ADDR SIBA_CC_BCAST_ADDR +#define SIBA_PCICORE_BCAST_DATA SIBA_CC_BCAST_DATA +#define SIBA_PCICORE_SBTOPCI0 0x0100 +#define SIBA_PCICORE_SBTOPCI1 0x0104 +#define SIBA_PCICORE_SBTOPCI2 0x0108 +#define SIBA_PCICORE_MDIO_CTL 0x0128 +#define SIBA_PCICORE_MDIO_DATA 0x012c +#define SIBA_PCICORE_SBTOPCI_PREF 0x00000004 +#define SIBA_PCICORE_SBTOPCI_BURST 0x00000008 +#define SIBA_PCICORE_SBTOPCI_MRM 0x00000020 #endif /* _SIBA_SIBAREG_H_ */ Index: siba_ids.h =================================================================== --- siba_ids.h (revision 202983) +++ siba_ids.h (working copy) @@ -39,23 +39,45 @@ uint8_t sd_rev; char *sd_desc; }; +#define SIBA_DEV(_vendor, _cid, _rev, _msg) \ + { SIBA_VID_##_vendor, SIBA_DEVID_##_cid, _rev, _msg } /* * Device IDs */ -#define SIBA_DEVID_ANY 0xffff -#define SIBA_DEVID_CHIPCOMMON 0x0800 -#define SIBA_DEVID_INSIDELINE 0x0801 -#define SIBA_DEVID_SDRAM 0x0803 -#define SIBA_DEVID_PCI 0x0804 -#define SIBA_DEVID_MIPS 0x0805 -#define SIBA_DEVID_ETHERNET 0x0806 -#define SIBA_DEVID_MODEM 0x0807 -#define SIBA_DEVID_USB 0x0808 -#define SIBA_DEVID_IPSEC 0x080b -#define SIBA_DEVID_SDRAMDDR 0x080f -#define SIBA_DEVID_EXTIF 0x0811 -#define SIBA_DEVID_MIPS_3302 0x0816 +#define SIBA_DEVID_ANY 0xffff +#define SIBA_DEVID_CHIPCOMMON 0x800 +#define SIBA_DEVID_ILINE20 0x801 +#define SIBA_DEVID_SDRAM 0x803 +#define SIBA_DEVID_PCI 0x804 +#define SIBA_DEVID_MIPS 0x805 +#define SIBA_DEVID_ETHERNET 0x806 +#define SIBA_DEVID_MODEM 0x807 +#define SIBA_DEVID_USB11_HOSTDEV 0x808 +#define SIBA_DEVID_ADSL 0x809 +#define SIBA_DEVID_ILINE100 0x80a +#define SIBA_DEVID_IPSEC 0x80b +#define SIBA_DEVID_PCMCIA 0x80d +#define SIBA_DEVID_INTERNAL_MEM 0x80e +#define SIBA_DEVID_SDRAMDDR 0x80f +#define SIBA_DEVID_EXTIF 0x811 +#define SIBA_DEVID_80211 0x812 +#define SIBA_DEVID_MIPS_3302 0x816 +#define SIBA_DEVID_USB11_HOST 0x817 +#define SIBA_DEVID_USB11_DEV 0x818 +#define SIBA_DEVID_USB20_HOST 0x819 +#define SIBA_DEVID_USB20_DEV 0x81a +#define SIBA_DEVID_SDIO_HOST 0x81b +#define SIBA_DEVID_ROBOSWITCH 0x81c +#define SIBA_DEVID_PARA_ATA 0x81d +#define SIBA_DEVID_SATA_XORDMA 0x81e +#define SIBA_DEVID_ETHERNET_GBIT 0x81f +#define SIBA_DEVID_PCIE 0x820 +#define SIBA_DEVID_MIMO_PHY 0x821 +#define SIBA_DEVID_SRAM_CTRLR 0x822 +#define SIBA_DEVID_MINI_MACPHY 0x823 +#define SIBA_DEVID_ARM_1176 0x824 +#define SIBA_DEVID_ARM_7TDMI 0x825 /* * Vendor IDs Index: siba_cc.c =================================================================== --- siba_cc.c (revision 202983) +++ siba_cc.c (working copy) @@ -55,9 +55,9 @@ #include +#include +#include #include -#include -#include static int siba_cc_attach(device_t); static int siba_cc_probe(device_t); Index: siba_bwn.c =================================================================== --- siba_bwn.c (revision 0) +++ siba_bwn.c (revision 0) @@ -0,0 +1,366 @@ +/*- + * Copyright (c) 2009-2010 Weongyo Jeong + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer, + * without modification. + * 2. Redistributions in binary form must reproduce at minimum a disclaimer + * similar to the "NO WARRANTY" disclaimer below ("Disclaimer") and any + * redistribution must be conditioned upon including a substantially + * similar Disclaimer requirement for further binary redistribution. + * + * NO WARRANTY + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTIBILITY + * AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL + * THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY, + * OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER + * IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF + * THE POSSIBILITY OF SUCH DAMAGES. + */ + +#include +__FBSDID("$FreeBSD$"); + +/* + * Sonics Silicon Backplane front-end for bwn(4). + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include +#include + +#include +#include +#include + +/* + * PCI glue. + */ + +struct siba_bwn_softc { + /* Child driver using MSI. */ + device_t ssc_msi_child; + struct siba_softc ssc_siba; +}; + +#define BS_BAR 0x10 +#define PCI_VENDOR_BROADCOM 0x14e4 +#define N(a) (sizeof(a) / sizeof(a[0])) + +static const struct siba_dev { + uint16_t vid; + uint16_t did; + const char *desc; +} siba_devices[] = { + { PCI_VENDOR_BROADCOM, 0x4301, "Broadcom BCM4301 802.11b Wireless" }, + { PCI_VENDOR_BROADCOM, 0x4306, "Unknown" }, + { PCI_VENDOR_BROADCOM, 0x4307, "Broadcom BCM4307 802.11b Wireless" }, + { PCI_VENDOR_BROADCOM, 0x4311, "Broadcom BCM4311 802.11b/g Wireless" }, + { PCI_VENDOR_BROADCOM, 0x4312, + "Broadcom BCM4312 802.11a/b/g Wireless" }, + { PCI_VENDOR_BROADCOM, 0x4315, "Broadcom BCM4312 802.11b/g Wireless" }, + { PCI_VENDOR_BROADCOM, 0x4318, "Broadcom BCM4318 802.11b/g Wireless" }, + { PCI_VENDOR_BROADCOM, 0x4319, + "Broadcom BCM4318 802.11a/b/g Wireless" }, + { PCI_VENDOR_BROADCOM, 0x4320, "Broadcom BCM4306 802.11b/g Wireless" }, + { PCI_VENDOR_BROADCOM, 0x4321, "Broadcom BCM4306 802.11a Wireless" }, + { PCI_VENDOR_BROADCOM, 0x4324, + "Broadcom BCM4309 802.11a/b/g Wireless" }, + { PCI_VENDOR_BROADCOM, 0x4325, "Broadcom BCM4306 802.11b/g Wireless" }, + { PCI_VENDOR_BROADCOM, 0x4328, "Unknown" }, + { PCI_VENDOR_BROADCOM, 0x4329, "Unknown" }, + { PCI_VENDOR_BROADCOM, 0x432b, "Unknown" } +}; + +device_t siba_add_child(device_t, struct siba_softc *, int, const char *, + int); +int siba_core_attach(struct siba_softc *); +int siba_core_detach(struct siba_softc *); +int siba_core_suspend(struct siba_softc *); +int siba_core_resume(struct siba_softc *); + +static int +siba_bwn_probe(device_t dev) +{ + int i; + uint16_t did, vid; + + did = pci_get_device(dev); + vid = pci_get_vendor(dev); + + for (i = 0; i < N(siba_devices); i++) { + if (siba_devices[i].did == did && siba_devices[i].vid == vid) { + device_set_desc(dev, siba_devices[i].desc); + return (BUS_PROBE_DEFAULT); + } + } + return (ENXIO); +} + +static int +siba_bwn_attach(device_t dev) +{ + struct siba_bwn_softc *ssc = device_get_softc(dev); + struct siba_softc *siba = &ssc->ssc_siba; + + siba->siba_dev = dev; + siba->siba_type = SIBA_TYPE_PCI; + + /* + * Enable bus mastering. + */ + pci_enable_busmaster(dev); + + /* + * Setup memory-mapping of PCI registers. + */ + siba->siba_mem_rid = SIBA_PCIR_BAR; + siba->siba_mem_res = bus_alloc_resource_any(dev, SYS_RES_MEMORY, + &siba->siba_mem_rid, RF_ACTIVE); + if (siba->siba_mem_res == NULL) { + device_printf(dev, "cannot map register space\n"); + return (ENXIO); + } + siba->siba_mem_bt = rman_get_bustag(siba->siba_mem_res); + siba->siba_mem_bh = rman_get_bushandle(siba->siba_mem_res); + + /* Get more PCI information */ + siba->siba_pci_did = pci_get_device(dev); + siba->siba_pci_vid = pci_get_vendor(dev); + siba->siba_pci_subvid = pci_get_subvendor(dev); + siba->siba_pci_subdid = pci_get_subdevice(dev); + + return (siba_core_attach(siba)); +} + +static int +siba_bwn_detach(device_t dev) +{ + struct siba_bwn_softc *ssc = device_get_softc(dev); + struct siba_softc *siba = &ssc->ssc_siba; + + /* check if device was removed */ + siba->siba_invalid = !bus_child_present(dev); + + pci_disable_busmaster(dev); + bus_generic_detach(dev); + siba_core_detach(siba); + + bus_release_resource(dev, SYS_RES_MEMORY, BS_BAR, siba->siba_mem_res); + + return (0); +} + +static int +siba_bwn_shutdown(device_t dev) +{ + device_t *devlistp; + int devcnt, error = 0, i; + + error = device_get_children(dev, &devlistp, &devcnt); + if (error != 0) + return (error); + + for (i = 0 ; i < devcnt ; i++) + device_shutdown(devlistp[i]); + free(devlistp, M_TEMP); + return (0); +} + +static int +siba_bwn_suspend(device_t dev) +{ + struct siba_bwn_softc *ssc = device_get_softc(dev); + struct siba_softc *siba = &ssc->ssc_siba; + device_t *devlistp; + int devcnt, error = 0, i, j; + + error = device_get_children(dev, &devlistp, &devcnt); + if (error != 0) + return (error); + + for (i = 0 ; i < devcnt ; i++) { + error = DEVICE_SUSPEND(devlistp[i]); + if (error) { + for (j = 0; j < i; i++) + DEVICE_RESUME(devlistp[j]); + return (error); + } + } + free(devlistp, M_TEMP); + return (siba_core_suspend(siba)); +} + +static int +siba_bwn_resume(device_t dev) +{ + struct siba_bwn_softc *ssc = device_get_softc(dev); + struct siba_softc *siba = &ssc->ssc_siba; + device_t *devlistp; + int devcnt, error = 0, i; + + error = siba_core_resume(siba); + if (error != 0) + return (error); + + error = device_get_children(dev, &devlistp, &devcnt); + if (error != 0) + return (error); + + for (i = 0 ; i < devcnt ; i++) + DEVICE_RESUME(devlistp[i]); + free(devlistp, M_TEMP); + return (0); +} + +static device_t +siba_bwn_add_child(device_t dev, int order, const char *name, int unit) +{ + struct siba_bwn_softc *ssc = device_get_softc(dev); + struct siba_softc *siba = &ssc->ssc_siba; + + return (siba_add_child(dev, siba, order, name, unit)); +} + +/* proxying to the parent */ +static struct resource * +siba_bwn_alloc_resource(device_t dev, device_t child, int type, int *rid, + u_long start, u_long end, u_long count, u_int flags) +{ + + return (BUS_ALLOC_RESOURCE(device_get_parent(dev), dev, + type, rid, start, end, count, flags)); +} + +/* proxying to the parent */ +static int +siba_bwn_release_resource(device_t dev, device_t child, int type, + int rid, struct resource *r) +{ + + return (BUS_RELEASE_RESOURCE(device_get_parent(dev), dev, type, + rid, r)); +} + +/* proxying to the parent */ +static int +siba_bwn_setup_intr(device_t dev, device_t child, struct resource *irq, + int flags, driver_filter_t *filter, driver_intr_t *intr, void *arg, + void **cookiep) +{ + + return (BUS_SETUP_INTR(device_get_parent(dev), dev, irq, flags, + filter, intr, arg, cookiep)); +} + +/* proxying to the parent */ +static int +siba_bwn_teardown_intr(device_t dev, device_t child, struct resource *irq, + void *cookie) +{ + + return (BUS_TEARDOWN_INTR(device_get_parent(dev), dev, irq, cookie)); +} + +static int +siba_bwn_find_extcap(device_t dev, device_t child, int capability, + int *capreg) +{ + + return (pci_find_extcap(dev, capability, capreg)); +} + +static int +siba_bwn_alloc_msi(device_t dev, device_t child, int *count) +{ + struct siba_bwn_softc *ssc; + int error; + + ssc = device_get_softc(dev); + if (ssc->ssc_msi_child != NULL) + return (EBUSY); + error = pci_alloc_msi(dev, count); + if (error == 0) + ssc->ssc_msi_child = child; + return (error); +} + +static int +siba_bwn_release_msi(device_t dev, device_t child) +{ + struct siba_bwn_softc *ssc; + int error; + + ssc = device_get_softc(dev); + if (ssc->ssc_msi_child != child) + return (ENXIO); + error = pci_release_msi(dev); + if (error == 0) + ssc->ssc_msi_child = NULL; + return (error); +} + +static int +siba_bwn_msi_count(device_t dev, device_t child) +{ + + return (pci_msi_count(dev)); +} + +static device_method_t siba_bwn_methods[] = { + /* Device interface */ + DEVMETHOD(device_probe, siba_bwn_probe), + DEVMETHOD(device_attach, siba_bwn_attach), + DEVMETHOD(device_detach, siba_bwn_detach), + DEVMETHOD(device_shutdown, siba_bwn_shutdown), + DEVMETHOD(device_suspend, siba_bwn_suspend), + DEVMETHOD(device_resume, siba_bwn_resume), + + /* Bus interface */ + DEVMETHOD(bus_add_child, siba_bwn_add_child), + DEVMETHOD(bus_alloc_resource, siba_bwn_alloc_resource), + DEVMETHOD(bus_release_resource, siba_bwn_release_resource), + DEVMETHOD(bus_setup_intr, siba_bwn_setup_intr), + DEVMETHOD(bus_teardown_intr, siba_bwn_teardown_intr), + + /* PCI interface */ + DEVMETHOD(pci_find_extcap, siba_bwn_find_extcap), + DEVMETHOD(pci_alloc_msi, siba_bwn_alloc_msi), + DEVMETHOD(pci_release_msi, siba_bwn_release_msi), + DEVMETHOD(pci_msi_count, siba_bwn_msi_count), + + { 0,0 } +}; +static driver_t siba_bwn_driver = { + "siba_bwn", + siba_bwn_methods, + sizeof(struct siba_bwn_softc) +}; +static devclass_t siba_bwn_devclass; +DRIVER_MODULE(siba_bwn, pci, siba_bwn_driver, siba_bwn_devclass, 0, 0); +MODULE_VERSION(siba_bwn, 1); Index: siba_core.c =================================================================== --- siba_core.c (revision 0) +++ siba_core.c (revision 0) @@ -0,0 +1,2007 @@ +/*- + * Copyright (c) 2009-2010 Weongyo Jeong + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer, + * without modification. + * 2. Redistributions in binary form must reproduce at minimum a disclaimer + * similar to the "NO WARRANTY" disclaimer below ("Disclaimer") and any + * redistribution must be conditioned upon including a substantially + * similar Disclaimer requirement for further binary redistribution. + * + * NO WARRANTY + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS + * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT + * LIMITED TO, THE IMPLIED WARRANTIES OF NONINFRINGEMENT, MERCHANTIBILITY + * AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL + * THE COPYRIGHT HOLDERS OR CONTRIBUTORS BE LIABLE FOR SPECIAL, EXEMPLARY, + * OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER + * IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF + * THE POSSIBILITY OF SUCH DAMAGES. + */ + +#include +__FBSDID("$FreeBSD$"); + +/* + * the Sonics Silicon Backplane driver. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include + +#include +#include + +#include +#include +#include + +#ifdef SIBA_DEBUG +enum { + SIBA_DEBUG_SCAN = 0x00000001, /* scan */ + SIBA_DEBUG_PMU = 0x00000002, /* PMU */ + SIBA_DEBUG_PLL = 0x00000004, /* PLL */ + SIBA_DEBUG_SWITCHCORE = 0x00000008, /* switching core */ + SIBA_DEBUG_SPROM = 0x00000010, /* SPROM */ + SIBA_DEBUG_CORE = 0x00000020, /* handling cores */ + SIBA_DEBUG_ANY = 0xffffffff +}; +#define DPRINTF(siba, m, fmt, ...) do { \ + if (siba->siba_debug & (m)) \ + printf(fmt, __VA_ARGS__); \ +} while (0) +#else +#define DPRINTF(siba, m, fmt, ...) do { (void) siba; } while (0) +#endif +#define N(a) (sizeof(a) / sizeof(a[0])) + +static void siba_pci_gpio(struct siba_softc *, uint32_t, int); +static void siba_scan(struct siba_softc *); +static int siba_switchcore(struct siba_softc *, uint8_t); +static int siba_pci_switchcore_sub(struct siba_softc *, uint8_t); +static uint32_t siba_scan_read_4(struct siba_softc *, uint8_t, uint16_t); +static uint16_t siba_dev2chipid(struct siba_softc *); +static uint16_t siba_pci_read_2(struct siba_dev_softc *, uint16_t); +static uint32_t siba_pci_read_4(struct siba_dev_softc *, uint16_t); +static void siba_pci_write_2(struct siba_dev_softc *, uint16_t, uint16_t); +static void siba_pci_write_4(struct siba_dev_softc *, uint16_t, uint32_t); +static void siba_cc_clock(struct siba_cc *, + enum siba_clock); +static void siba_cc_pmu_init(struct siba_cc *); +static void siba_cc_power_init(struct siba_cc *); +static void siba_cc_powerup_delay(struct siba_cc *); +static int siba_cc_clockfreq(struct siba_cc *, int); +static void siba_cc_pmu1_pll0_init(struct siba_cc *, uint32_t); +static void siba_cc_pmu0_pll0_init(struct siba_cc *, uint32_t); +static enum siba_clksrc siba_cc_clksrc(struct siba_cc *); +static const struct siba_cc_pmu1_plltab *siba_cc_pmu1_plltab_find(uint32_t); +static uint32_t siba_cc_pll_read(struct siba_cc *, uint32_t); +static void siba_cc_pll_write(struct siba_cc *, uint32_t, + uint32_t); +static const struct siba_cc_pmu0_plltab * + siba_cc_pmu0_plltab_findentry(uint32_t); +static int siba_pci_sprom(struct siba_softc *, struct siba_sprom *); +static int siba_sprom_read(struct siba_softc *, uint16_t *, uint16_t); +static int sprom_check_crc(const uint16_t *, size_t); +static uint8_t siba_crc8(uint8_t, uint8_t); +static void siba_sprom_r123(struct siba_sprom *, const uint16_t *); +static void siba_sprom_r45(struct siba_sprom *, const uint16_t *); +static void siba_sprom_r8(struct siba_sprom *, const uint16_t *); +static int8_t siba_sprom_r123_antgain(uint8_t, const uint16_t *, uint16_t, + uint16_t); +static uint32_t siba_tmslow_reject_bitmask(struct siba_dev_softc *); +static uint32_t siba_pcicore_read_4(struct siba_pci *, uint16_t); +static void siba_pcicore_write_4(struct siba_pci *, uint16_t, uint32_t); +static uint32_t siba_pcie_read(struct siba_pci *, uint32_t); +static void siba_pcie_write(struct siba_pci *, uint32_t, uint32_t); +static void siba_pcie_mdio_write(struct siba_pci *, uint8_t, uint8_t, + uint16_t); +static void siba_pci_read_multi_1(struct siba_dev_softc *, void *, size_t, + uint16_t); +static void siba_pci_read_multi_2(struct siba_dev_softc *, void *, size_t, + uint16_t); +static void siba_pci_read_multi_4(struct siba_dev_softc *, void *, size_t, + uint16_t); +static void siba_pci_write_multi_1(struct siba_dev_softc *, const void *, + size_t, uint16_t); +static void siba_pci_write_multi_2(struct siba_dev_softc *, const void *, + size_t, uint16_t); +static void siba_pci_write_multi_4(struct siba_dev_softc *, const void *, + size_t, uint16_t); +static const char *siba_core_name(uint16_t); +static void siba_pcicore_init(struct siba_pci *); +device_t siba_add_child(device_t, struct siba_softc *, int, const char *, + int); +int siba_core_attach(struct siba_softc *); +int siba_core_detach(struct siba_softc *); +int siba_core_suspend(struct siba_softc *); +int siba_core_resume(struct siba_softc *); +uint8_t siba_getncores(device_t, uint16_t); + +static const struct siba_bus_ops siba_pci_ops = { + .read_2 = siba_pci_read_2, + .read_4 = siba_pci_read_4, + .write_2 = siba_pci_write_2, + .write_4 = siba_pci_write_4, + .read_multi_1 = siba_pci_read_multi_1, + .read_multi_2 = siba_pci_read_multi_2, + .read_multi_4 = siba_pci_read_multi_4, + .write_multi_1 = siba_pci_write_multi_1, + .write_multi_2 = siba_pci_write_multi_2, + .write_multi_4 = siba_pci_write_multi_4, +}; + +static const struct siba_cc_pmu_res_updown siba_cc_pmu_4325_updown[] = + SIBA_CC_PMU_4325_RES_UPDOWN; +static const struct siba_cc_pmu_res_depend siba_cc_pmu_4325_depend[] = + SIBA_CC_PMU_4325_RES_DEPEND; +static const struct siba_cc_pmu_res_updown siba_cc_pmu_4328_updown[] = + SIBA_CC_PMU_4328_RES_UPDOWN; +static const struct siba_cc_pmu_res_depend siba_cc_pmu_4328_depend[] = + SIBA_CC_PMU_4328_RES_DEPEND; +static const struct siba_cc_pmu0_plltab siba_cc_pmu0_plltab[] = + SIBA_CC_PMU0_PLLTAB_ENTRY; +static const struct siba_cc_pmu1_plltab siba_cc_pmu1_plltab[] = + SIBA_CC_PMU1_PLLTAB_ENTRY; + +int +siba_core_attach(struct siba_softc *siba) +{ + struct siba_cc *scc; + int error; + + KASSERT(siba->siba_type == SIBA_TYPE_PCI, + ("unsupported BUS type (%#x)", siba->siba_type)); + + siba->siba_ops = &siba_pci_ops; + + siba_pci_gpio(siba, SIBA_GPIO_CRYSTAL | SIBA_GPIO_PLL, 1); + siba_scan(siba); + + /* XXX init PCI or PCMCIA host devices */ + + siba_powerup(siba, 0); + + /* init ChipCommon */ + scc = &siba->siba_cc; + if (scc->scc_dev != NULL) { + siba_cc_pmu_init(scc); + siba_cc_power_init(scc); + siba_cc_clock(scc, SIBA_CLOCK_FAST); + siba_cc_powerup_delay(scc); + } + + /* fetch various internal informations for PCI */ + siba->siba_board_vendor = pci_read_config(siba->siba_dev, + PCIR_SUBVEND_0, 2); + siba->siba_board_type = pci_read_config(siba->siba_dev, PCIR_SUBDEV_0, + 2); + siba->siba_board_rev = pci_read_config(siba->siba_dev, PCIR_REVID, 2); + error = siba_pci_sprom(siba, &siba->siba_sprom); + if (error) { + siba_powerdown(siba); + return (error); + } + + siba_powerdown(siba); + return (0); +} + +int +siba_core_detach(struct siba_softc *siba) +{ + device_t *devlistp; + int devcnt, error = 0, i; + + error = device_get_children(siba->siba_dev, &devlistp, &devcnt); + if (error != 0) + return (0); + + for ( i = 0 ; i < devcnt ; i++) + device_delete_child(siba->siba_dev, devlistp[i]); + free(devlistp, M_TEMP); + return (0); +} + +static void +siba_pci_gpio(struct siba_softc *siba, uint32_t what, int on) +{ + uint32_t in, out; + uint16_t status; + + if (siba->siba_type != SIBA_TYPE_PCI) + return; + + out = pci_read_config(siba->siba_dev, SIBA_GPIO_OUT, 4); + if (on == 0) { + if (what & SIBA_GPIO_PLL) + out |= SIBA_GPIO_PLL; + if (what & SIBA_GPIO_CRYSTAL) + out &= ~SIBA_GPIO_CRYSTAL; + pci_write_config(siba->siba_dev, SIBA_GPIO_OUT, out, 4); + pci_write_config(siba->siba_dev, SIBA_GPIO_OUT_EN, + pci_read_config(siba->siba_dev, + SIBA_GPIO_OUT_EN, 4) | what, 4); + return; + } + + in = pci_read_config(siba->siba_dev, SIBA_GPIO_IN, 4); + if ((in & SIBA_GPIO_CRYSTAL) != SIBA_GPIO_CRYSTAL) { + if (what & SIBA_GPIO_CRYSTAL) { + out |= SIBA_GPIO_CRYSTAL; + if (what & SIBA_GPIO_PLL) + out |= SIBA_GPIO_PLL; + pci_write_config(siba->siba_dev, SIBA_GPIO_OUT, out, 4); + pci_write_config(siba->siba_dev, + SIBA_GPIO_OUT_EN, pci_read_config(siba->siba_dev, + SIBA_GPIO_OUT_EN, 4) | what, 4); + DELAY(1000); + } + if (what & SIBA_GPIO_PLL) { + out &= ~SIBA_GPIO_PLL; + pci_write_config(siba->siba_dev, SIBA_GPIO_OUT, out, 4); + DELAY(5000); + } + } + + status = pci_read_config(siba->siba_dev, PCIR_STATUS, 2); + status &= ~PCIM_STATUS_STABORT; + pci_write_config(siba->siba_dev, PCIR_STATUS, status, 2); +} + +static void +siba_scan(struct siba_softc *siba) +{ + struct siba_dev_softc *sd; + uint32_t idhi, tmp; + int base, dev_i = 0, error, i, is_pcie, n_80211 = 0, n_cc = 0, + n_pci = 0; + + KASSERT(siba->siba_type == SIBA_TYPE_PCI, + ("unsupported BUS type (%#x)", siba->siba_type)); + + siba->siba_ndevs = 0; + error = siba_switchcore(siba, 0); /* need the first core */ + if (error) + return; + + idhi = siba_scan_read_4(siba, 0, SIBA_IDHIGH); + if (SIBA_IDHIGH_CORECODE(idhi) == SIBA_DEVID_CHIPCOMMON) { + tmp = siba_scan_read_4(siba, 0, SIBA_CC_CHIPID); + siba->siba_chipid = SIBA_CC_ID(tmp); + siba->siba_chiprev = SIBA_CC_REV(tmp); + siba->siba_chippkg = SIBA_CC_PKG(tmp); + if (SIBA_IDHIGH_REV(idhi) >= 4) + siba->siba_ndevs = SIBA_CC_NCORES(tmp); + siba->siba_cc.scc_caps = siba_scan_read_4(siba, 0, + SIBA_CC_CAPS); + } else { + if (siba->siba_type == SIBA_TYPE_PCI) { + siba->siba_chipid = siba_dev2chipid(siba); + siba->siba_chiprev = pci_read_config(siba->siba_dev, + PCIR_REVID, 2); + siba->siba_chippkg = 0; + } else { + siba->siba_chipid = 0x4710; + siba->siba_chiprev = 0; + siba->siba_chippkg = 0; + } + } + if (siba->siba_ndevs == 0) + siba->siba_ndevs = siba_getncores(siba->siba_dev, + siba->siba_chipid); + if (siba->siba_ndevs > SIBA_MAX_CORES) { + device_printf(siba->siba_dev, + "too many siba cores (max %d %d)\n", + SIBA_MAX_CORES, siba->siba_ndevs); + return; + } + + /* looking basic information about each cores/devices */ + for (i = 0; i < siba->siba_ndevs; i++) { + error = siba_switchcore(siba, i); + if (error) + return; + sd = &(siba->siba_devs[dev_i]); + idhi = siba_scan_read_4(siba, i, SIBA_IDHIGH); + sd->sd_bus = siba; + sd->sd_id.sd_device = SIBA_IDHIGH_CORECODE(idhi); + sd->sd_id.sd_rev = SIBA_IDHIGH_REV(idhi); + sd->sd_id.sd_vendor = SIBA_IDHIGH_VENDOR(idhi); + sd->sd_ops = siba->siba_ops; + sd->sd_coreidx = i; + + DPRINTF(siba, SIBA_DEBUG_SCAN, + "core %d (%s) found (cc %#xrev %#x vendor %#x)\n", + i, siba_core_name(sd->sd_id.sd_device), + sd->sd_id.sd_device, sd->sd_id.sd_rev, sd->sd_id.vendor); + + switch (sd->sd_id.sd_device) { + case SIBA_DEVID_CHIPCOMMON: + n_cc++; + if (n_cc > 1) { + device_printf(siba->siba_dev, + "warn: multiple ChipCommon\n"); + break; + } + siba->siba_cc.scc_dev = sd; + break; + case SIBA_DEVID_80211: + n_80211++; + if (n_80211 > 1) { + device_printf(siba->siba_dev, + "warn: multiple 802.11 core\n"); + continue; + } + break; + case SIBA_DEVID_PCI: + case SIBA_DEVID_PCIE: + n_pci++; + error = pci_find_extcap(siba->siba_dev, PCIY_EXPRESS, + &base); + is_pcie = (error == 0) ? 1 : 0; + + if (n_pci > 1) { + device_printf(siba->siba_dev, + "warn: multiple PCI(E) cores\n"); + break; + } + if (sd->sd_id.sd_device == SIBA_DEVID_PCI && + is_pcie == 1) + continue; + if (sd->sd_id.sd_device == SIBA_DEVID_PCIE && + is_pcie == 0) + continue; + siba->siba_pci.spc_dev = sd; + break; + case SIBA_DEVID_MODEM: + case SIBA_DEVID_PCMCIA: + break; + default: + device_printf(siba->siba_dev, + "unsupported coreid (%s)\n", + siba_core_name(sd->sd_id.sd_device)); + break; + } + dev_i++; + } + siba->siba_ndevs = dev_i; +} + +static int +siba_switchcore(struct siba_softc *siba, uint8_t idx) +{ + + switch (siba->siba_type) { + case SIBA_TYPE_PCI: + return (siba_pci_switchcore_sub(siba, idx)); + default: + KASSERT(0 == 1, + ("%s: unsupported bustype %#x", __func__, + siba->siba_type)); + } + return (0); +} + +static int +siba_pci_switchcore_sub(struct siba_softc *siba, uint8_t idx) +{ +#define RETRY_MAX 50 + int i; + uint32_t dir; + + dir = SIBA_REGWIN(idx); + + for (i = 0; i < RETRY_MAX; i++) { + pci_write_config(siba->siba_dev, SIBA_BAR0, dir, 4); + if (pci_read_config(siba->siba_dev, SIBA_BAR0, 4) == dir) + return (0); + DELAY(10); + } + return (ENODEV); +#undef RETRY_MAX +} + +static int +siba_pci_switchcore(struct siba_softc *siba, struct siba_dev_softc *sd) +{ + int error; + + DPRINTF(siba, SIBA_DEBUG_SWITCHCORE, "Switching to %s core, index %d\n", + siba_core_name(sd->sd_id.sd_device), sd->sd_coreidx); + + error = siba_pci_switchcore_sub(siba, sd->sd_coreidx); + if (error == 0) + siba->siba_curdev = sd; + + return (error); +} + +static uint32_t +siba_scan_read_4(struct siba_softc *siba, uint8_t coreidx, + uint16_t offset) +{ + + (void)coreidx; + KASSERT(siba->siba_type == SIBA_TYPE_PCI, + ("unsupported BUS type (%#x)", siba->siba_type)); + + return (SIBA_READ_4(siba, offset)); +} + +static uint16_t +siba_dev2chipid(struct siba_softc *siba) +{ + uint16_t chipid = 0; + + switch (siba->siba_pci_did) { + case 0x4301: + chipid = 0x4301; + break; + case 0x4305: + case 0x4306: + case 0x4307: + chipid = 0x4307; + break; + case 0x4403: + chipid = 0x4402; + break; + case 0x4610: + case 0x4611: + case 0x4612: + case 0x4613: + case 0x4614: + case 0x4615: + chipid = 0x4610; + break; + case 0x4710: + case 0x4711: + case 0x4712: + case 0x4713: + case 0x4714: + case 0x4715: + chipid = 0x4710; + break; + case 0x4320: + case 0x4321: + case 0x4322: + case 0x4323: + case 0x4324: + case 0x4325: + chipid = 0x4309; + break; + case PCI_DEVICE_ID_BCM4401: + case PCI_DEVICE_ID_BCM4401B0: + case PCI_DEVICE_ID_BCM4401B1: + chipid = 0x4401; + break; + default: + device_printf(siba->siba_dev, "unknown PCI did (%d)\n", + siba->siba_pci_did); + } + + return (chipid); +} + +/* + * Earlier ChipCommon revisions have hardcoded number of cores + * present dependent on the ChipCommon ID. + */ +uint8_t +siba_getncores(device_t dev, uint16_t chipid) +{ + switch (chipid) { + case 0x4401: + case 0x4402: + return (3); + case 0x4301: + case 0x4307: + return (5); + case 0x4306: + return (6); + case SIBA_CCID_SENTRY5: + return (7); + case 0x4310: + return (8); + case SIBA_CCID_BCM4710: + case 0x4610: + case SIBA_CCID_BCM4704: + return (9); + default: + device_printf(dev, "unknown the chipset ID %#x\n", chipid); + } + + return (1); +} + +static const char * +siba_core_name(uint16_t coreid) +{ + + switch (coreid) { + case SIBA_DEVID_CHIPCOMMON: + return ("ChipCommon"); + case SIBA_DEVID_ILINE20: + return ("ILine 20"); + case SIBA_DEVID_SDRAM: + return ("SDRAM"); + case SIBA_DEVID_PCI: + return ("PCI"); + case SIBA_DEVID_MIPS: + return ("MIPS"); + case SIBA_DEVID_ETHERNET: + return ("Fast Ethernet"); + case SIBA_DEVID_MODEM: + return ("Modem"); + case SIBA_DEVID_USB11_HOSTDEV: + return ("USB 1.1 Hostdev"); + case SIBA_DEVID_ADSL: + return ("ADSL"); + case SIBA_DEVID_ILINE100: + return ("ILine 100"); + case SIBA_DEVID_IPSEC: + return ("IPSEC"); + case SIBA_DEVID_PCMCIA: + return ("PCMCIA"); + case SIBA_DEVID_INTERNAL_MEM: + return ("Internal Memory"); + case SIBA_DEVID_SDRAMDDR: + return ("MEMC SDRAM"); + case SIBA_DEVID_EXTIF: + return ("EXTIF"); + case SIBA_DEVID_80211: + return ("IEEE 802.11"); + case SIBA_DEVID_MIPS_3302: + return ("MIPS 3302"); + case SIBA_DEVID_USB11_HOST: + return ("USB 1.1 Host"); + case SIBA_DEVID_USB11_DEV: + return ("USB 1.1 Device"); + case SIBA_DEVID_USB20_HOST: + return ("USB 2.0 Host"); + case SIBA_DEVID_USB20_DEV: + return ("USB 2.0 Device"); + case SIBA_DEVID_SDIO_HOST: + return ("SDIO Host"); + case SIBA_DEVID_ROBOSWITCH: + return ("Roboswitch"); + case SIBA_DEVID_PARA_ATA: + return ("PATA"); + case SIBA_DEVID_SATA_XORDMA: + return ("SATA XOR-DMA"); + case SIBA_DEVID_ETHERNET_GBIT: + return ("GBit Ethernet"); + case SIBA_DEVID_PCIE: + return ("PCI-Express"); + case SIBA_DEVID_MIMO_PHY: + return ("MIMO PHY"); + case SIBA_DEVID_SRAM_CTRLR: + return ("SRAM Controller"); + case SIBA_DEVID_MINI_MACPHY: + return ("Mini MACPHY"); + case SIBA_DEVID_ARM_1176: + return ("ARM 1176"); + case SIBA_DEVID_ARM_7TDMI: + return ("ARM 7TDMI"); + } + return ("unknown"); +} + +static uint16_t +siba_pci_read_2(struct siba_dev_softc *sd, uint16_t offset) +{ + struct siba_softc *siba = sd->sd_bus; + + if (siba->siba_curdev != sd && siba_pci_switchcore(siba, sd) != 0) + return (0xffff); + + return (SIBA_READ_2(siba, offset)); +} + +static uint32_t +siba_pci_read_4(struct siba_dev_softc *sd, uint16_t offset) +{ + struct siba_softc *siba = sd->sd_bus; + + if (siba->siba_curdev != sd && siba_pci_switchcore(siba, sd) != 0) + return (0xffff); + + return (SIBA_READ_4(siba, offset)); +} + +static void +siba_pci_write_2(struct siba_dev_softc *sd, uint16_t offset, uint16_t value) +{ + struct siba_softc *siba = sd->sd_bus; + + if (siba->siba_curdev != sd && siba_pci_switchcore(siba, sd) != 0) + return; + + SIBA_WRITE_2(siba, offset, value); +} + +static void +siba_pci_write_4(struct siba_dev_softc *sd, uint16_t offset, uint32_t value) +{ + struct siba_softc *siba = sd->sd_bus; + + if (siba->siba_curdev != sd && siba_pci_switchcore(siba, sd) != 0) + return; + + SIBA_WRITE_4(siba, offset, value); +} + +static void +siba_pci_read_multi_1(struct siba_dev_softc *sd, void *buffer, size_t count, + uint16_t offset) +{ + struct siba_softc *siba = sd->sd_bus; + + if (siba->siba_curdev != sd && siba_pci_switchcore(siba, sd) != 0) { + memset(buffer, 0xff, count); + return; + } + + SIBA_READ_MULTI_1(siba, offset, buffer, count); +} + +static void +siba_pci_read_multi_2(struct siba_dev_softc *sd, void *buffer, size_t count, + uint16_t offset) +{ + struct siba_softc *siba = sd->sd_bus; + + if (siba->siba_curdev != sd && siba_pci_switchcore(siba, sd) != 0) { + memset(buffer, 0xff, count); + return; + } + + KASSERT(!(count & 1), ("%s:%d: fail", __func__, __LINE__)); + SIBA_READ_MULTI_2(siba, offset, buffer, count >> 1); +} + +static void +siba_pci_read_multi_4(struct siba_dev_softc *sd, void *buffer, size_t count, + uint16_t offset) +{ + struct siba_softc *siba = sd->sd_bus; + + if (siba->siba_curdev != sd && siba_pci_switchcore(siba, sd) != 0) { + memset(buffer, 0xff, count); + return; + } + + KASSERT(!(count & 3), ("%s:%d: fail", __func__, __LINE__)); + SIBA_READ_MULTI_4(siba, offset, buffer, count >> 2); +} + +static void +siba_pci_write_multi_1(struct siba_dev_softc *sd, const void *buffer, + size_t count, uint16_t offset) +{ + struct siba_softc *siba = sd->sd_bus; + + if (siba->siba_curdev != sd && siba_pci_switchcore(siba, sd) != 0) + return; + + SIBA_WRITE_MULTI_1(siba, offset, buffer, count); +} + +static void +siba_pci_write_multi_2(struct siba_dev_softc *sd, const void *buffer, + size_t count, uint16_t offset) +{ + struct siba_softc *siba = sd->sd_bus; + + if (siba->siba_curdev != sd && siba_pci_switchcore(siba, sd) != 0) + return; + + KASSERT(!(count & 1), ("%s:%d: fail", __func__, __LINE__)); + SIBA_WRITE_MULTI_2(siba, offset, buffer, count >> 1); +} + +static void +siba_pci_write_multi_4(struct siba_dev_softc *sd, const void *buffer, + size_t count, uint16_t offset) +{ + struct siba_softc *siba = sd->sd_bus; + + if (siba->siba_curdev != sd && siba_pci_switchcore(siba, sd) != 0) + return; + + KASSERT(!(count & 3), ("%s:%d: fail", __func__, __LINE__)); + SIBA_WRITE_MULTI_4(siba, offset, buffer, count >> 2); +} + +void +siba_powerup(struct siba_softc *siba, int dynamic) +{ + + siba_pci_gpio(siba, SIBA_GPIO_CRYSTAL | SIBA_GPIO_PLL, 1); + siba_cc_clock(&siba->siba_cc, + (dynamic != 0) ? SIBA_CLOCK_DYNAMIC : SIBA_CLOCK_FAST); +} + +static void +siba_cc_clock(struct siba_cc *scc, enum siba_clock clock) +{ + struct siba_dev_softc *sd = scc->scc_dev; + struct siba_softc *siba; + uint32_t tmp; + + if (sd == NULL) + return; + siba = sd->sd_bus; + /* + * chipcommon < r6 (no dynamic clock control) + * chipcommon >= r10 (unknown) + */ + if (sd->sd_id.sd_rev < 6 || sd->sd_id.sd_rev >= 10 || + (scc->scc_caps & SIBA_CC_CAPS_PWCTL) == 0) + return; + + switch (clock) { + case SIBA_CLOCK_DYNAMIC: + tmp = SIBA_CC_READ32(scc, SIBA_CC_CLKSLOW) & + ~(SIBA_CC_CLKSLOW_ENXTAL | SIBA_CC_CLKSLOW_FSLOW | + SIBA_CC_CLKSLOW_IPLL); + if ((tmp & SIBA_CC_CLKSLOW_SRC) != SIBA_CC_CLKSLOW_SRC_CRYSTAL) + tmp |= SIBA_CC_CLKSLOW_ENXTAL; + SIBA_CC_WRITE32(scc, SIBA_CC_CLKSLOW, tmp); + if (tmp & SIBA_CC_CLKSLOW_ENXTAL) + siba_pci_gpio(siba, SIBA_GPIO_CRYSTAL, 0); + break; + case SIBA_CLOCK_SLOW: + SIBA_CC_WRITE32(scc, SIBA_CC_CLKSLOW, + SIBA_CC_READ32(scc, SIBA_CC_CLKSLOW) | + SIBA_CC_CLKSLOW_FSLOW); + break; + case SIBA_CLOCK_FAST: + /* crystal on */ + siba_pci_gpio(siba, SIBA_GPIO_CRYSTAL, 1); + SIBA_CC_WRITE32(scc, SIBA_CC_CLKSLOW, + (SIBA_CC_READ32(scc, SIBA_CC_CLKSLOW) | + SIBA_CC_CLKSLOW_IPLL) & ~SIBA_CC_CLKSLOW_FSLOW); + break; + default: + KASSERT(0 == 1, + ("%s: unsupported clock %#x", __func__, clock)); + } +} + +uint16_t +siba_read_2(struct siba_dev_softc *sd, uint16_t offset) +{ + + return (sd->sd_ops->read_2(sd, offset)); +} + +uint32_t +siba_read_4(struct siba_dev_softc *sd, uint16_t offset) +{ + + return (sd->sd_ops->read_4(sd, offset)); +} + +void +siba_write_2(struct siba_dev_softc *sd, uint16_t offset, uint16_t value) +{ + + sd->sd_ops->write_2(sd, offset, value); +} + +void +siba_write_4(struct siba_dev_softc *sd, uint16_t offset, uint32_t value) +{ + + sd->sd_ops->write_4(sd, offset, value); +} + +void +siba_read_multi_1(struct siba_dev_softc *sd, void *buffer, size_t count, + uint16_t offset) +{ + + sd->sd_ops->read_multi_1(sd, buffer, count, offset); +} + +void +siba_read_multi_2(struct siba_dev_softc *sd, void *buffer, size_t count, + uint16_t offset) +{ + + sd->sd_ops->read_multi_2(sd, buffer, count, offset); +} + +void +siba_read_multi_4(struct siba_dev_softc *sd, void *buffer, size_t count, + uint16_t offset) +{ + + sd->sd_ops->read_multi_4(sd, buffer, count, offset); +} + +void +siba_write_multi_1(struct siba_dev_softc *sd, const void *buffer, + size_t count, uint16_t offset) +{ + + sd->sd_ops->write_multi_1(sd, buffer, count, offset); +} + +void +siba_write_multi_2(struct siba_dev_softc *sd, const void *buffer, + size_t count, uint16_t offset) +{ + + sd->sd_ops->write_multi_2(sd, buffer, count, offset); +} + +void +siba_write_multi_4(struct siba_dev_softc *sd, const void *buffer, + size_t count, uint16_t offset) +{ + + sd->sd_ops->write_multi_4(sd, buffer, count, offset); +} + +static void +siba_cc_pmu_init(struct siba_cc *scc) +{ + const struct siba_cc_pmu_res_updown *updown = NULL; + const struct siba_cc_pmu_res_depend *depend = NULL; + struct siba_dev_softc *sd = scc->scc_dev; + struct siba_softc *siba = sd->sd_bus; + uint32_t min = 0, max = 0, pmucap; + unsigned int i, updown_size, depend_size; + + if ((scc->scc_caps & SIBA_CC_CAPS_PMU) == 0) + return; + + pmucap = SIBA_CC_READ32(scc, SIBA_CC_PMUCAPS); + scc->scc_pmu.rev = (pmucap & SIBA_CC_PMUCAPS_REV); + + DPRINTF(siba, SIBA_DEBUG_PMU, "PMU(r%u) found (caps %#x)\n", + scc->scc_pmu.rev, pmucap); + + if (scc->scc_pmu.rev >= 1) { + if (siba->siba_chiprev < 2 && siba->siba_chipid == 0x4325) + SIBA_CC_MASK32(scc, SIBA_CC_PMUCTL, + ~SIBA_CC_PMUCTL_NOILP); + else + SIBA_CC_SET32(scc, SIBA_CC_PMUCTL, + SIBA_CC_PMUCTL_NOILP); + } + + /* initialize PLL & PMU resources */ + switch (siba->siba_chipid) { + case 0x4312: + siba_cc_pmu1_pll0_init(scc, 0 /* use default */); + /* use the default: min = 0xcbb max = 0x7ffff */ + break; + case 0x4325: + siba_cc_pmu1_pll0_init(scc, 0 /* use default */); + + updown = siba_cc_pmu_4325_updown; + updown_size = N(siba_cc_pmu_4325_updown); + depend = siba_cc_pmu_4325_depend; + depend_size = N(siba_cc_pmu_4325_depend); + + min = (1 << SIBA_CC_PMU_4325_BURST) | + (1 << SIBA_CC_PMU_4325_LN); + if (SIBA_CC_READ32(scc, SIBA_CC_CHIPSTAT) & + SIBA_CC_CHST_4325_PMUTOP_2B) + min |= (1 << SIBA_CC_PMU_4325_CLBURST); + max = 0xfffff; + break; + case 0x4328: + siba_cc_pmu0_pll0_init(scc, 0 /* use default */); + + updown = siba_cc_pmu_4328_updown; + updown_size = N(siba_cc_pmu_4328_updown); + depend = siba_cc_pmu_4328_depend; + depend_size = N(siba_cc_pmu_4328_depend); + + min = (1 << SIBA_CC_PMU_4328_EXT_SWITCH_PWM) | + (1 << SIBA_CC_PMU_4328_BB_SWITCH_PWM) | + (1 << SIBA_CC_PMU_4328_CRYSTAL_EN); + + max = 0xfffff; + break; + case 0x5354: + siba_cc_pmu0_pll0_init(scc, 0 /* use default */); + + max = 0xfffff; + break; + default: + device_printf(siba->siba_dev, + "unknown chipid %#x for PLL & PMU init\n", + siba->siba_chipid); + } + + if (updown) { + for (i = 0; i < updown_size; i++) { + SIBA_CC_WRITE32(scc, SIBA_CC_PMU_TABSEL, + updown[i].res); + SIBA_CC_WRITE32(scc, SIBA_CC_PMU_UPDNTM, + updown[i].updown); + } + } + if (depend) { + for (i = 0; i < depend_size; i++) { + SIBA_CC_WRITE32(scc, SIBA_CC_PMU_TABSEL, + depend[i].res); + switch (depend[i].task) { + case SIBA_CC_PMU_DEP_SET: + SIBA_CC_WRITE32(scc, SIBA_CC_PMU_DEPMSK, + depend[i].depend); + break; + case SIBA_CC_PMU_DEP_ADD: + SIBA_CC_SET32(scc, SIBA_CC_PMU_DEPMSK, + depend[i].depend); + break; + case SIBA_CC_PMU_DEP_REMOVE: + SIBA_CC_MASK32(scc, SIBA_CC_PMU_DEPMSK, + ~(depend[i].depend)); + break; + default: + KASSERT(0 == 1, + ("%s:%d: assertion failed", + __func__, __LINE__)); + } + } + } + + if (min) + SIBA_CC_WRITE32(scc, SIBA_CC_PMU_MINRES, min); + if (max) + SIBA_CC_WRITE32(scc, SIBA_CC_PMU_MAXRES, max); +} + +static void +siba_cc_power_init(struct siba_cc *scc) +{ + struct siba_softc *siba = scc->scc_dev->sd_bus; + int maxfreq; + + if (siba->siba_chipid == 0x4321) { + if (siba->siba_chiprev == 0) + SIBA_CC_WRITE32(scc, SIBA_CC_CHIPCTL, 0x3a4); + else if (siba->siba_chiprev == 1) + SIBA_CC_WRITE32(scc, SIBA_CC_CHIPCTL, 0xa4); + } + + if ((scc->scc_caps & SIBA_CC_CAPS_PWCTL) == 0) + return; + + if (scc->scc_dev->sd_id.sd_rev >= 10) + SIBA_CC_WRITE32(scc, SIBA_CC_CLKSYSCTL, + (SIBA_CC_READ32(scc, SIBA_CC_CLKSYSCTL) & + 0xffff) | 0x40000); + else { + maxfreq = siba_cc_clockfreq(scc, 1); + SIBA_CC_WRITE32(scc, SIBA_CC_PLLONDELAY, + (maxfreq * 150 + 999999) / 1000000); + SIBA_CC_WRITE32(scc, SIBA_CC_FREFSELDELAY, + (maxfreq * 15 + 999999) / 1000000); + } +} + +static void +siba_cc_powerup_delay(struct siba_cc *scc) +{ + struct siba_softc *siba = scc->scc_dev->sd_bus; + int min; + + if (siba->siba_type != SIBA_TYPE_PCI || + !(scc->scc_caps & SIBA_CC_CAPS_PWCTL)) + return; + + min = siba_cc_clockfreq(scc, 0); + scc->scc_powerup_delay = + (((SIBA_CC_READ32(scc, SIBA_CC_PLLONDELAY) + 2) * 1000000) + + (min - 1)) / min; +} + +static int +siba_cc_clockfreq(struct siba_cc *scc, int max) +{ + enum siba_clksrc src; + int div = 1, limit = 0; + + src = siba_cc_clksrc(scc); + if (scc->scc_dev->sd_id.sd_rev < 6) { + div = (src == SIBA_CC_CLKSRC_PCI) ? 64 : + (src == SIBA_CC_CLKSRC_CRYSTAL) ? 32 : 1; + KASSERT(div != 1, + ("%s: unknown clock %d", __func__, src)); + } else if (scc->scc_dev->sd_id.sd_rev < 10) { + switch (src) { + case SIBA_CC_CLKSRC_CRYSTAL: + case SIBA_CC_CLKSRC_PCI: + div = ((SIBA_CC_READ32(scc, SIBA_CC_CLKSLOW) >> 16) + + 1) * 4; + break; + case SIBA_CC_CLKSRC_LOWPW: + break; + } + } else + div = ((SIBA_CC_READ32(scc, SIBA_CC_CLKSYSCTL) >> 16) + 1) * 4; + + switch (src) { + case SIBA_CC_CLKSRC_CRYSTAL: + limit = (max) ? 20200000 : 19800000; + break; + case SIBA_CC_CLKSRC_LOWPW: + limit = (max) ? 43000 : 25000; + break; + case SIBA_CC_CLKSRC_PCI: + limit = (max) ? 34000000 : 25000000; + break; + } + + return (limit / div); +} + +static void +siba_cc_pmu1_pll0_init(struct siba_cc *scc, uint32_t freq) +{ + struct siba_dev_softc *sd = scc->scc_dev; + struct siba_softc *siba = sd->sd_bus; + const struct siba_cc_pmu1_plltab *e = NULL; + uint32_t bufsth = 0, pll, pmu; + unsigned int i; + + KASSERT(freq == 0, ("%s:%d: assertion vail", __func__, __LINE__)); + if (siba->siba_chipid == 0x4312) { + scc->scc_pmu.freq = 20000; + return; + } + + e = siba_cc_pmu1_plltab_find(SIBA_CC_PMU1_DEFAULT_FREQ); + KASSERT(e != NULL, ("%s:%d: assertion vail", __func__, __LINE__)); + scc->scc_pmu.freq = e->freq; + + pmu = SIBA_CC_READ32(scc, SIBA_CC_PMUCTL); + if (SIBA_CC_PMUCTL_XF_VAL(pmu) == e->xf) + return; + + DPRINTF(siba, SIBA_DEBUG_PLL, "change PLL value to %u.%03u MHz\n", + (e->freq / 1000), (e->freq % 1000)); + + /* turn PLL off */ + switch (siba->siba_chipid) { + case 0x4325: + bufsth = 0x222222; + SIBA_CC_MASK32(scc, SIBA_CC_PMU_MINRES, + ~((1 << SIBA_CC_PMU_4325_BBPLL_PWR) | + (1 << SIBA_CC_PMU_4325_HT))); + SIBA_CC_MASK32(scc, SIBA_CC_PMU_MAXRES, + ~((1 << SIBA_CC_PMU_4325_BBPLL_PWR) | + (1 << SIBA_CC_PMU_4325_HT))); + break; + default: + KASSERT(0 == 1, + ("%s:%d: assertion failed", __func__, __LINE__)); + } + for (i = 0; i < 1500; i++) { + if (!(SIBA_CC_READ32(scc, SIBA_CC_CLKCTLSTATUS) & + SIBA_CC_CLKCTLSTATUS_HT)) + break; + DELAY(10); + } + if (SIBA_CC_READ32(scc, SIBA_CC_CLKCTLSTATUS) & SIBA_CC_CLKCTLSTATUS_HT) + device_printf(siba->siba_dev, "failed to turn PLL off!\n"); + + pll = siba_cc_pll_read(scc, SIBA_CC_PMU1_PLL0); + pll &= ~(SIBA_CC_PMU1_PLL0_P1DIV | SIBA_CC_PMU1_PLL0_P2DIV); + pll |= ((uint32_t)e->p1div << 20) & SIBA_CC_PMU1_PLL0_P1DIV; + pll |= ((uint32_t)e->p2div << 24) & SIBA_CC_PMU1_PLL0_P2DIV; + siba_cc_pll_write(scc, SIBA_CC_PMU1_PLL0, pll); + + pll = siba_cc_pll_read(scc, SIBA_CC_PMU1_PLL2); + pll &= ~(SIBA_CC_PMU1_PLL2_NDIVINT | SIBA_CC_PMU1_PLL2_NDIVMODE); + pll |= ((uint32_t)e->ndiv_int << 20) & SIBA_CC_PMU1_PLL2_NDIVINT; + pll |= (1 << 17) & SIBA_CC_PMU1_PLL2_NDIVMODE; + siba_cc_pll_write(scc, SIBA_CC_PMU1_PLL2, pll); + + pll = siba_cc_pll_read(scc, SIBA_CC_PMU1_PLL3); + pll &= ~SIBA_CC_PMU1_PLL3_NDIVFRAC; + pll |= ((uint32_t)e->ndiv_frac << 0) & SIBA_CC_PMU1_PLL3_NDIVFRAC; + siba_cc_pll_write(scc, SIBA_CC_PMU1_PLL3, pll); + + if (bufsth) { + pll = siba_cc_pll_read(scc, SIBA_CC_PMU1_PLL5); + pll &= ~SIBA_CC_PMU1_PLL5_CLKDRV; + pll |= (bufsth << 8) & SIBA_CC_PMU1_PLL5_CLKDRV; + siba_cc_pll_write(scc, SIBA_CC_PMU1_PLL5, pll); + } + + pmu = SIBA_CC_READ32(scc, SIBA_CC_PMUCTL); + pmu &= ~(SIBA_CC_PMUCTL_ILP | SIBA_CC_PMUCTL_XF); + pmu |= ((((uint32_t)e->freq + 127) / 128 - 1) << 16) & + SIBA_CC_PMUCTL_ILP; + pmu |= ((uint32_t)e->xf << 2) & SIBA_CC_PMUCTL_XF; + SIBA_CC_WRITE32(scc, SIBA_CC_PMUCTL, pmu); +} + +static void +siba_cc_pmu0_pll0_init(struct siba_cc *scc, uint32_t xtalfreq) +{ + struct siba_dev_softc *sd = scc->scc_dev; + struct siba_softc *siba = sd->sd_bus; + const struct siba_cc_pmu0_plltab *e = NULL; + uint32_t pmu, tmp, pll; + unsigned int i; + + if ((siba->siba_chipid == 0x5354) && !xtalfreq) + xtalfreq = 25000; + if (xtalfreq) + e = siba_cc_pmu0_plltab_findentry(xtalfreq); + if (!e) + e = siba_cc_pmu0_plltab_findentry( + SIBA_CC_PMU0_DEFAULT_XTALFREQ); + KASSERT(e != NULL, ("%s:%d: fail", __func__, __LINE__)); + xtalfreq = e->freq; + scc->scc_pmu.freq = e->freq; + + pmu = SIBA_CC_READ32(scc, SIBA_CC_PMUCTL); + if (((pmu & SIBA_CC_PMUCTL_XF) >> 2) == e->xf) + return; + + DPRINTF(siba, SIBA_DEBUG_PLL, "change PLL value to %u.%03u mhz\n", + (xtalfreq / 1000), (xtalfreq % 1000)); + + KASSERT(siba->siba_chipid == 0x4328 || siba->siba_chipid == 0x5354, + ("%s:%d: fail", __func__, __LINE__)); + + switch (siba->siba_chipid) { + case 0x4328: + SIBA_CC_MASK32(scc, SIBA_CC_PMU_MINRES, + ~(1 << SIBA_CC_PMU_4328_BB_PLL_PU)); + SIBA_CC_MASK32(scc, SIBA_CC_PMU_MAXRES, + ~(1 << SIBA_CC_PMU_4328_BB_PLL_PU)); + break; + case 0x5354: + SIBA_CC_MASK32(scc, SIBA_CC_PMU_MINRES, + ~(1 << SIBA_CC_PMU_5354_BB_PLL_PU)); + SIBA_CC_MASK32(scc, SIBA_CC_PMU_MAXRES, + ~(1 << SIBA_CC_PMU_5354_BB_PLL_PU)); + break; + } + for (i = 1500; i; i--) { + tmp = SIBA_CC_READ32(scc, SIBA_CC_CLKCTLSTATUS); + if (!(tmp & SIBA_CC_CLKCTLSTATUS_HT)) + break; + DELAY(10); + } + tmp = SIBA_CC_READ32(scc, SIBA_CC_CLKCTLSTATUS); + if (tmp & SIBA_CC_CLKCTLSTATUS_HT) + device_printf(siba->siba_dev, "failed to turn PLL off!\n"); + + /* set PDIV */ + pll = siba_cc_pll_read(scc, SIBA_CC_PMU0_PLL0); + if (xtalfreq >= SIBA_CC_PMU0_PLL0_PDIV_FREQ) + pll |= SIBA_CC_PMU0_PLL0_PDIV_MSK; + else + pll &= ~SIBA_CC_PMU0_PLL0_PDIV_MSK; + siba_cc_pll_write(scc, SIBA_CC_PMU0_PLL0, pll); + + /* set WILD */ + pll = siba_cc_pll_read(scc, SIBA_CC_PMU0_PLL1); + pll &= ~(SIBA_CC_PMU0_PLL1_STOPMOD | SIBA_CC_PMU0_PLL1_IMSK | + SIBA_CC_PMU0_PLL1_FMSK); + pll |= ((uint32_t)e->wb_int << 28) & SIBA_CC_PMU0_PLL1_IMSK; + pll |= ((uint32_t)e->wb_frac << 8) & SIBA_CC_PMU0_PLL1_FMSK; + if (e->wb_frac == 0) + pll |= SIBA_CC_PMU0_PLL1_STOPMOD; + siba_cc_pll_write(scc, SIBA_CC_PMU0_PLL1, pll); + + /* set WILD */ + pll = siba_cc_pll_read(scc, SIBA_CC_PMU0_PLL2); + pll &= ~SIBA_CC_PMU0_PLL2_IMSKHI; + pll |= (((uint32_t)e->wb_int >> 4) << 0) & SIBA_CC_PMU0_PLL2_IMSKHI; + siba_cc_pll_write(scc, SIBA_CC_PMU0_PLL2, pll); + + /* set freq and divisor. */ + pmu = SIBA_CC_READ32(scc, SIBA_CC_PMUCTL); + pmu &= ~SIBA_CC_PMUCTL_ILP; + pmu |= (((xtalfreq + 127) / 128 - 1) << 16) & SIBA_CC_PMUCTL_ILP; + pmu &= ~SIBA_CC_PMUCTL_XF; + pmu |= ((uint32_t)e->xf << 2) & SIBA_CC_PMUCTL_XF; + SIBA_CC_WRITE32(scc, SIBA_CC_PMUCTL, pmu); +} + +static enum siba_clksrc +siba_cc_clksrc(struct siba_cc *scc) +{ + struct siba_dev_softc *sd = scc->scc_dev; + struct siba_softc *siba = sd->sd_bus; + + if (sd->sd_id.sd_rev < 6) { + if (siba->siba_type == SIBA_TYPE_PCI) { + if (pci_read_config(siba->siba_dev, SIBA_GPIO_OUT, 4) & + 0x10) + return (SIBA_CC_CLKSRC_PCI); + return (SIBA_CC_CLKSRC_CRYSTAL); + } + if (siba->siba_type == SIBA_TYPE_SSB || + siba->siba_type == SIBA_TYPE_PCMCIA) + return (SIBA_CC_CLKSRC_CRYSTAL); + } + if (sd->sd_id.sd_rev < 10) { + switch (SIBA_CC_READ32(scc, SIBA_CC_CLKSLOW) & 0x7) { + case 0: + return (SIBA_CC_CLKSRC_LOWPW); + case 1: + return (SIBA_CC_CLKSRC_CRYSTAL); + case 2: + return (SIBA_CC_CLKSRC_PCI); + default: + break; + } + } + + return (SIBA_CC_CLKSRC_CRYSTAL); +} + +static const struct siba_cc_pmu1_plltab * +siba_cc_pmu1_plltab_find(uint32_t crystalfreq) +{ + const struct siba_cc_pmu1_plltab *e; + unsigned int i; + + for (i = 0; i < N(siba_cc_pmu1_plltab); i++) { + e = &siba_cc_pmu1_plltab[i]; + if (crystalfreq == e->freq) + return (e); + } + + return (NULL); +} + +static uint32_t +siba_cc_pll_read(struct siba_cc *scc, uint32_t offset) +{ + + SIBA_CC_WRITE32(scc, SIBA_CC_PLLCTL_ADDR, offset); + return (SIBA_CC_READ32(scc, SIBA_CC_PLLCTL_DATA)); +} + +static void +siba_cc_pll_write(struct siba_cc *scc, uint32_t offset, uint32_t value) +{ + + SIBA_CC_WRITE32(scc, SIBA_CC_PLLCTL_ADDR, offset); + SIBA_CC_WRITE32(scc, SIBA_CC_PLLCTL_DATA, value); +} + +static const struct siba_cc_pmu0_plltab * +siba_cc_pmu0_plltab_findentry(uint32_t crystalfreq) +{ + const struct siba_cc_pmu0_plltab *e; + unsigned int i; + + for (i = 0; i < N(siba_cc_pmu0_plltab); i++) { + e = &siba_cc_pmu0_plltab[i]; + if (e->freq == crystalfreq) + return (e); + } + + return (NULL); +} + +static int +siba_pci_sprom(struct siba_softc *siba, struct siba_sprom *sprom) +{ + int error = ENOMEM; + uint16_t *buf; + + buf = malloc(SIBA_SPROMSIZE_R123 * sizeof(uint16_t), + M_DEVBUF, M_NOWAIT | M_ZERO); + if (buf == NULL) + return (ENOMEM); + siba_sprom_read(siba, buf, SIBA_SPROMSIZE_R123); + error = sprom_check_crc(buf, siba->siba_spromsize); + if (error) { + free(buf, M_DEVBUF); + buf = malloc(SIBA_SPROMSIZE_R4 * sizeof(uint16_t), + M_DEVBUF, M_NOWAIT | M_ZERO); + if (buf == NULL) + return (ENOMEM); + siba_sprom_read(siba, buf, SIBA_SPROMSIZE_R4); + error = sprom_check_crc(buf, siba->siba_spromsize); + if (error) + device_printf(siba->siba_dev, "warn: bad SPROM CRC\n"); + } + + bzero(sprom, sizeof(*sprom)); + + sprom->rev = buf[siba->siba_spromsize - 1] & 0x00FF; + DPRINTF(siba, SIBA_DEBUG_SPROM, "SPROM rev %d\n", + sprom->rev); + memset(sprom->mac_eth, 0xff, 6); + memset(sprom->mac_80211a, 0xff, 6); + if ((siba->siba_chipid & 0xff00) == 0x4400) { + sprom->rev = 1; + siba_sprom_r123(sprom, buf); + } else if (siba->siba_chipid == 0x4321) { + sprom->rev = 4; + siba_sprom_r45(sprom, buf); + } else { + switch (sprom->rev) { + case 1: + case 2: + case 3: + siba_sprom_r123(sprom, buf); + break; + case 4: + case 5: + siba_sprom_r45(sprom, buf); + break; + case 8: + siba_sprom_r8(sprom, buf); + break; + default: + device_printf(siba->siba_dev, + "unknown SPROM revision %d.\n", sprom->rev); + siba_sprom_r123(sprom, buf); + } + } + + if (sprom->bf_lo == 0xffff) + sprom->bf_lo = 0; + if (sprom->bf_hi == 0xffff) + sprom->bf_hi = 0; + + free(buf, M_DEVBUF); + return (error); +} + +static int +siba_sprom_read(struct siba_softc *siba, uint16_t *sprom, uint16_t len) +{ + int i; + + for (i = 0; i < len; i++) + sprom[i] = SIBA_READ_2(siba, SIBA_SPROM_BASE + (i * 2)); + + siba->siba_spromsize = len; + return (0); +} + +static int +sprom_check_crc(const uint16_t *sprom, size_t size) +{ + int word; + uint8_t crc0, crc1 = 0xff; + + crc0 = (sprom[size - 1] & SIBA_SPROM_REV_CRC) >> 8; + for (word = 0; word < size - 1; word++) { + crc1 = siba_crc8(crc1, sprom[word] & 0x00ff); + crc1 = siba_crc8(crc1, (sprom[word] & 0xff00) >> 8); + } + crc1 = siba_crc8(crc1, sprom[size - 1] & 0x00ff); + crc1 ^= 0xff; + + return ((crc0 != crc1) ? EPROTO : 0); +} + +static uint8_t +siba_crc8(uint8_t crc, uint8_t data) +{ + static const uint8_t ct[] = { + 0x00, 0xf7, 0xb9, 0x4e, 0x25, 0xd2, 0x9c, 0x6b, + 0x4a, 0xbd, 0xf3, 0x04, 0x6f, 0x98, 0xd6, 0x21, + 0x94, 0x63, 0x2d, 0xda, 0xb1, 0x46, 0x08, 0xff, + 0xde, 0x29, 0x67, 0x90, 0xfb, 0x0c, 0x42, 0xb5, + 0x7f, 0x88, 0xc6, 0x31, 0x5a, 0xad, 0xe3, 0x14, + 0x35, 0xc2, 0x8c, 0x7b, 0x10, 0xe7, 0xa9, 0x5e, + 0xeb, 0x1c, 0x52, 0xa5, 0xce, 0x39, 0x77, 0x80, + 0xa1, 0x56, 0x18, 0xef, 0x84, 0x73, 0x3d, 0xca, + 0xfe, 0x09, 0x47, 0xb0, 0xdb, 0x2c, 0x62, 0x95, + 0xb4, 0x43, 0x0d, 0xfa, 0x91, 0x66, 0x28, 0xdf, + 0x6a, 0x9d, 0xd3, 0x24, 0x4f, 0xb8, 0xf6, 0x01, + 0x20, 0xd7, 0x99, 0x6e, 0x05, 0xf2, 0xbc, 0x4b, + 0x81, 0x76, 0x38, 0xcf, 0xa4, 0x53, 0x1d, 0xea, + 0xcb, 0x3c, 0x72, 0x85, 0xee, 0x19, 0x57, 0xa0, + 0x15, 0xe2, 0xac, 0x5b, 0x30, 0xc7, 0x89, 0x7e, + 0x5f, 0xa8, 0xe6, 0x11, 0x7a, 0x8d, 0xc3, 0x34, + 0xab, 0x5c, 0x12, 0xe5, 0x8e, 0x79, 0x37, 0xc0, + 0xe1, 0x16, 0x58, 0xaf, 0xc4, 0x33, 0x7d, 0x8a, + 0x3f, 0xc8, 0x86, 0x71, 0x1a, 0xed, 0xa3, 0x54, + 0x75, 0x82, 0xcc, 0x3b, 0x50, 0xa7, 0xe9, 0x1e, + 0xd4, 0x23, 0x6d, 0x9a, 0xf1, 0x06, 0x48, 0xbf, + 0x9e, 0x69, 0x27, 0xd0, 0xbb, 0x4c, 0x02, 0xf5, + 0x40, 0xb7, 0xf9, 0x0e, 0x65, 0x92, 0xdc, 0x2b, + 0x0a, 0xfd, 0xb3, 0x44, 0x2f, 0xd8, 0x96, 0x61, + 0x55, 0xa2, 0xec, 0x1b, 0x70, 0x87, 0xc9, 0x3e, + 0x1f, 0xe8, 0xa6, 0x51, 0x3a, 0xcd, 0x83, 0x74, + 0xc1, 0x36, 0x78, 0x8f, 0xe4, 0x13, 0x5d, 0xaa, + 0x8b, 0x7c, 0x32, 0xc5, 0xae, 0x59, 0x17, 0xe0, + 0x2a, 0xdd, 0x93, 0x64, 0x0f, 0xf8, 0xb6, 0x41, + 0x60, 0x97, 0xd9, 0x2e, 0x45, 0xb2, 0xfc, 0x0b, + 0xbe, 0x49, 0x07, 0xf0, 0x9b, 0x6c, 0x22, 0xd5, + 0xf4, 0x03, 0x4d, 0xba, 0xd1, 0x26, 0x68, 0x9f, + }; + return (ct[crc ^ data]); +} + +#define SIBA_LOWEST_SET_BIT(__mask) ((((__mask) - 1) & (__mask)) ^ (__mask)) +#define SIBA_OFFSET(offset) \ + (((offset) - SIBA_SPROM_BASE) / sizeof(uint16_t)) +#define SIBA_SHIFTOUT_SUB(__x, __mask) \ + (((__x) & (__mask)) / SIBA_LOWEST_SET_BIT(__mask)) +#define SIBA_SHIFTOUT(_var, _offset, _mask) \ + out->_var = SIBA_SHIFTOUT_SUB(in[SIBA_OFFSET(_offset)], (_mask)) + +static void +siba_sprom_r123(struct siba_sprom *out, const uint16_t *in) +{ + int i; + uint16_t v; + int8_t gain; + uint16_t loc[3]; + + if (out->rev == 3) + loc[0] = SIBA_SPROM3_MAC_80211BG; + else { + loc[0] = SIBA_SPROM1_MAC_80211BG; + loc[1] = SIBA_SPROM1_MAC_ETH; + loc[2] = SIBA_SPROM1_MAC_80211A; + } + for (i = 0; i < 3; i++) { + v = in[SIBA_OFFSET(loc[0]) + i]; + *(((uint16_t *)out->mac_80211bg) + i) = htobe16(v); + } + if (out->rev < 3) { + for (i = 0; i < 3; i++) { + v = in[SIBA_OFFSET(loc[1]) + i]; + *(((uint16_t *)out->mac_eth) + i) = htobe16(v); + } + for (i = 0; i < 3; i++) { + v = in[SIBA_OFFSET(loc[2]) + i]; + *(((uint16_t *)out->mac_80211a) + i) = htobe16(v); + } + } + SIBA_SHIFTOUT(mii_eth0, SIBA_SPROM1_ETHPHY, + SIBA_SPROM1_ETHPHY_MII_ETH0); + SIBA_SHIFTOUT(mii_eth1, SIBA_SPROM1_ETHPHY, + SIBA_SPROM1_ETHPHY_MII_ETH1); + SIBA_SHIFTOUT(mdio_eth0, SIBA_SPROM1_ETHPHY, + SIBA_SPROM1_ETHPHY_MDIO_ETH0); + SIBA_SHIFTOUT(mdio_eth1, SIBA_SPROM1_ETHPHY, + SIBA_SPROM1_ETHPHY_MDIO_ETH1); + SIBA_SHIFTOUT(brev, SIBA_SPROM1_BOARDINFO, SIBA_SPROM1_BOARDINFO_BREV); + SIBA_SHIFTOUT(ccode, SIBA_SPROM1_BOARDINFO, + SIBA_SPROM1_BOARDINFO_CCODE); + SIBA_SHIFTOUT(ant_a, SIBA_SPROM1_BOARDINFO, SIBA_SPROM1_BOARDINFO_ANTA); + SIBA_SHIFTOUT(ant_bg, SIBA_SPROM1_BOARDINFO, + SIBA_SPROM1_BOARDINFO_ANTBG); + SIBA_SHIFTOUT(pa0b0, SIBA_SPROM1_PA0B0, 0xffff); + SIBA_SHIFTOUT(pa0b1, SIBA_SPROM1_PA0B1, 0xffff); + SIBA_SHIFTOUT(pa0b2, SIBA_SPROM1_PA0B2, 0xffff); + SIBA_SHIFTOUT(pa1b0, SIBA_SPROM1_PA1B0, 0xffff); + SIBA_SHIFTOUT(pa1b1, SIBA_SPROM1_PA1B1, 0xffff); + SIBA_SHIFTOUT(pa1b2, SIBA_SPROM1_PA1B2, 0xffff); + SIBA_SHIFTOUT(gpio0, SIBA_SPROM1_GPIOA, SIBA_SPROM1_GPIOA_P0); + SIBA_SHIFTOUT(gpio1, SIBA_SPROM1_GPIOA, SIBA_SPROM1_GPIOA_P1); + SIBA_SHIFTOUT(gpio2, SIBA_SPROM1_GPIOB, SIBA_SPROM1_GPIOB_P2); + SIBA_SHIFTOUT(gpio3, SIBA_SPROM1_GPIOB, SIBA_SPROM1_GPIOB_P3); + SIBA_SHIFTOUT(maxpwr_a, SIBA_SPROM1_MAXPWR, SIBA_SPROM1_MAXPWR_A); + SIBA_SHIFTOUT(maxpwr_bg, SIBA_SPROM1_MAXPWR, SIBA_SPROM1_MAXPWR_BG); + SIBA_SHIFTOUT(tssi_a, SIBA_SPROM1_TSSI, SIBA_SPROM1_TSSI_A); + SIBA_SHIFTOUT(tssi_bg, SIBA_SPROM1_TSSI, SIBA_SPROM1_TSSI_BG); + SIBA_SHIFTOUT(bf_lo, SIBA_SPROM1_BFLOW, 0xffff); + if (out->rev >= 2) + SIBA_SHIFTOUT(bf_hi, SIBA_SPROM2_BFHIGH, 0xffff); + + /* antenna gain */ + gain = siba_sprom_r123_antgain(out->rev, in, SIBA_SPROM1_AGAIN_BG, 0); + out->again.ghz24.a0 = out->again.ghz24.a1 = gain; + out->again.ghz24.a2 = out->again.ghz24.a3 = gain; + gain = siba_sprom_r123_antgain(out->rev, in, SIBA_SPROM1_AGAIN_A, 8); + out->again.ghz5.a0 = out->again.ghz5.a1 = gain; + out->again.ghz5.a2 = out->again.ghz5.a3 = gain; +} + +static void +siba_sprom_r45(struct siba_sprom *out, const uint16_t *in) +{ + int i; + uint16_t v; + uint16_t mac_80211bg_offset; + + if (out->rev == 4) + mac_80211bg_offset = SIBA_SPROM4_MAC_80211BG; + else + mac_80211bg_offset = SIBA_SPROM5_MAC_80211BG; + for (i = 0; i < 3; i++) { + v = in[SIBA_OFFSET(mac_80211bg_offset) + i]; + *(((uint16_t *)out->mac_80211bg) + i) = htobe16(v); + } + SIBA_SHIFTOUT(mii_eth0, SIBA_SPROM4_ETHPHY, SIBA_SPROM4_ETHPHY_ET0A); + SIBA_SHIFTOUT(mii_eth1, SIBA_SPROM4_ETHPHY, SIBA_SPROM4_ETHPHY_ET1A); + if (out->rev == 4) { + SIBA_SHIFTOUT(ccode, SIBA_SPROM4_CCODE, 0xffff); + SIBA_SHIFTOUT(bf_lo, SIBA_SPROM4_BFLOW, 0xffff); + SIBA_SHIFTOUT(bf_hi, SIBA_SPROM4_BFHIGH, 0xffff); + } else { + SIBA_SHIFTOUT(ccode, SIBA_SPROM5_CCODE, 0xffff); + SIBA_SHIFTOUT(bf_lo, SIBA_SPROM5_BFLOW, 0xffff); + SIBA_SHIFTOUT(bf_hi, SIBA_SPROM5_BFHIGH, 0xffff); + } + SIBA_SHIFTOUT(ant_a, SIBA_SPROM4_ANTAVAIL, SIBA_SPROM4_ANTAVAIL_A); + SIBA_SHIFTOUT(ant_bg, SIBA_SPROM4_ANTAVAIL, SIBA_SPROM4_ANTAVAIL_BG); + SIBA_SHIFTOUT(maxpwr_bg, SIBA_SPROM4_MAXP_BG, SIBA_SPROM4_MAXP_BG_MASK); + SIBA_SHIFTOUT(tssi_bg, SIBA_SPROM4_MAXP_BG, SIBA_SPROM4_TSSI_BG); + SIBA_SHIFTOUT(maxpwr_a, SIBA_SPROM4_MAXP_A, SIBA_SPROM4_MAXP_A_MASK); + SIBA_SHIFTOUT(tssi_a, SIBA_SPROM4_MAXP_A, SIBA_SPROM4_TSSI_A); + if (out->rev == 4) { + SIBA_SHIFTOUT(gpio0, SIBA_SPROM4_GPIOA, SIBA_SPROM4_GPIOA_P0); + SIBA_SHIFTOUT(gpio1, SIBA_SPROM4_GPIOA, SIBA_SPROM4_GPIOA_P1); + SIBA_SHIFTOUT(gpio2, SIBA_SPROM4_GPIOB, SIBA_SPROM4_GPIOB_P2); + SIBA_SHIFTOUT(gpio3, SIBA_SPROM4_GPIOB, SIBA_SPROM4_GPIOB_P3); + } else { + SIBA_SHIFTOUT(gpio0, SIBA_SPROM5_GPIOA, SIBA_SPROM5_GPIOA_P0); + SIBA_SHIFTOUT(gpio1, SIBA_SPROM5_GPIOA, SIBA_SPROM5_GPIOA_P1); + SIBA_SHIFTOUT(gpio2, SIBA_SPROM5_GPIOB, SIBA_SPROM5_GPIOB_P2); + SIBA_SHIFTOUT(gpio3, SIBA_SPROM5_GPIOB, SIBA_SPROM5_GPIOB_P3); + } + + /* antenna gain */ + SIBA_SHIFTOUT(again.ghz24.a0, SIBA_SPROM4_AGAIN01, SIBA_SPROM4_AGAIN0); + SIBA_SHIFTOUT(again.ghz24.a1, SIBA_SPROM4_AGAIN01, SIBA_SPROM4_AGAIN1); + SIBA_SHIFTOUT(again.ghz24.a2, SIBA_SPROM4_AGAIN23, SIBA_SPROM4_AGAIN2); + SIBA_SHIFTOUT(again.ghz24.a3, SIBA_SPROM4_AGAIN23, SIBA_SPROM4_AGAIN3); + bcopy(&out->again.ghz24, &out->again.ghz5, sizeof(out->again.ghz5)); +} + +static void +siba_sprom_r8(struct siba_sprom *out, const uint16_t *in) +{ + int i; + uint16_t v; + + for (i = 0; i < 3; i++) { + v = in[SIBA_OFFSET(SIBA_SPROM1_MAC_80211BG) + i]; + *(((uint16_t *)out->mac_80211bg) + i) = htobe16(v); + } + SIBA_SHIFTOUT(ccode, SIBA_SPROM8_CCODE, 0xffff); + SIBA_SHIFTOUT(bf_lo, SIBA_SPROM8_BFLOW, 0xffff); + SIBA_SHIFTOUT(bf_hi, SIBA_SPROM8_BFHIGH, 0xffff); + SIBA_SHIFTOUT(ant_a, SIBA_SPROM8_ANTAVAIL, SIBA_SPROM8_ANTAVAIL_A); + SIBA_SHIFTOUT(ant_bg, SIBA_SPROM8_ANTAVAIL, SIBA_SPROM8_ANTAVAIL_BG); + SIBA_SHIFTOUT(maxpwr_bg, SIBA_SPROM8_MAXP_BG, SIBA_SPROM8_MAXP_BG_MASK); + SIBA_SHIFTOUT(tssi_bg, SIBA_SPROM8_MAXP_BG, SIBA_SPROM8_TSSI_BG); + SIBA_SHIFTOUT(maxpwr_a, SIBA_SPROM8_MAXP_A, SIBA_SPROM8_MAXP_A_MASK); + SIBA_SHIFTOUT(tssi_a, SIBA_SPROM8_MAXP_A, SIBA_SPROM8_TSSI_A); + SIBA_SHIFTOUT(gpio0, SIBA_SPROM8_GPIOA, SIBA_SPROM8_GPIOA_P0); + SIBA_SHIFTOUT(gpio1, SIBA_SPROM8_GPIOA, SIBA_SPROM8_GPIOA_P1); + SIBA_SHIFTOUT(gpio2, SIBA_SPROM8_GPIOB, SIBA_SPROM8_GPIOB_P2); + SIBA_SHIFTOUT(gpio3, SIBA_SPROM8_GPIOB, SIBA_SPROM8_GPIOB_P3); + + /* antenna gain */ + SIBA_SHIFTOUT(again.ghz24.a0, SIBA_SPROM8_AGAIN01, SIBA_SPROM8_AGAIN0); + SIBA_SHIFTOUT(again.ghz24.a1, SIBA_SPROM8_AGAIN01, SIBA_SPROM8_AGAIN1); + SIBA_SHIFTOUT(again.ghz24.a2, SIBA_SPROM8_AGAIN23, SIBA_SPROM8_AGAIN2); + SIBA_SHIFTOUT(again.ghz24.a3, SIBA_SPROM8_AGAIN23, SIBA_SPROM8_AGAIN3); + bcopy(&out->again.ghz24, &out->again.ghz5, sizeof(out->again.ghz5)); +} + +static int8_t +siba_sprom_r123_antgain(uint8_t sprom_revision, const uint16_t *in, + uint16_t mask, uint16_t shift) +{ + uint16_t v; + uint8_t gain; + + v = in[SIBA_OFFSET(SIBA_SPROM1_AGAIN)]; + gain = (v & mask) >> shift; + gain = (gain == 0xff) ? 2 : (sprom_revision == 1) ? gain << 2 : + ((gain & 0xc0) >> 6) | ((gain & 0x3f) << 2); + + return ((int8_t)gain); +} + +#undef SIBA_LOWEST_SET_BIT +#undef SIBA_OFFSET +#undef SIBA_SHIFTOUT_SUB +#undef SIBA_SHIFTOUT + +int +siba_powerdown(struct siba_softc *siba) +{ + struct siba_cc *scc; + + if (siba->siba_type == SIBA_TYPE_SSB) + return (0); + + scc = &siba->siba_cc; + if (!scc->scc_dev || scc->scc_dev->sd_id.sd_rev < 5) + return (0); + siba_cc_clock(scc, SIBA_CLOCK_SLOW); + siba_pci_gpio(siba, SIBA_GPIO_CRYSTAL | SIBA_GPIO_PLL, 0); + return (0); +} + +static void +siba_pcicore_init(struct siba_pci *spc) +{ + struct siba_dev_softc *sd = spc->spc_dev; + struct siba_softc *siba; + + if (sd == NULL) + return; + + siba = sd->sd_bus; + if (!siba_dev_isup(sd)) + siba_dev_up(sd, 0); + + KASSERT(spc->spc_hostmode == 0, + ("%s:%d: hostmode", __func__, __LINE__)); + /* disable PCI interrupt */ + siba_write_4(spc->spc_dev, SIBA_INTR_MASK, 0); +} + +int +siba_dev_isup(struct siba_dev_softc *sd) +{ + uint32_t reject, val; + + reject = siba_tmslow_reject_bitmask(sd); + val = siba_read_4(sd, SIBA_TGSLOW); + val &= SIBA_TGSLOW_CLOCK | SIBA_TGSLOW_RESET | reject; + + return (val == SIBA_TGSLOW_CLOCK); +} + +void +siba_dev_up(struct siba_dev_softc *sd, uint32_t flags) +{ + uint32_t val; + + siba_dev_down(sd, flags); + siba_write_4(sd, SIBA_TGSLOW, SIBA_TGSLOW_RESET | SIBA_TGSLOW_CLOCK | + SIBA_TGSLOW_FGC | flags); + siba_read_4(sd, SIBA_TGSLOW); + DELAY(1); + + if (siba_read_4(sd, SIBA_TGSHIGH) & SIBA_TGSHIGH_SERR) + siba_write_4(sd, SIBA_TGSHIGH, 0); + + val = siba_read_4(sd, SIBA_IAS); + if (val & (SIBA_IAS_INBAND_ERR | SIBA_IAS_TIMEOUT)) { + val &= ~(SIBA_IAS_INBAND_ERR | SIBA_IAS_TIMEOUT); + siba_write_4(sd, SIBA_IAS, val); + } + + siba_write_4(sd, SIBA_TGSLOW, + SIBA_TGSLOW_CLOCK | SIBA_TGSLOW_FGC | flags); + siba_read_4(sd, SIBA_TGSLOW); + DELAY(1); + + siba_write_4(sd, SIBA_TGSLOW, SIBA_TGSLOW_CLOCK | flags); + siba_read_4(sd, SIBA_TGSLOW); + DELAY(1); +} + +static uint32_t +siba_tmslow_reject_bitmask(struct siba_dev_softc *sd) +{ + uint32_t rev = siba_read_4(sd, SIBA_IDLOW) & SIBA_IDLOW_SSBREV; + + switch (rev) { + case SIBA_IDLOW_SSBREV_22: + return (SIBA_TGSLOW_REJECT_22); + case SIBA_IDLOW_SSBREV_23: + return (SIBA_TGSLOW_REJECT_23); + case SIBA_IDLOW_SSBREV_24: + case SIBA_IDLOW_SSBREV_25: + case SIBA_IDLOW_SSBREV_26: + case SIBA_IDLOW_SSBREV_27: + return (SIBA_TGSLOW_REJECT_23); + default: + KASSERT(0 == 1, + ("%s:%d: unknown backplane rev %#x\n", + __func__, __LINE__, rev)); + } + return (SIBA_TGSLOW_REJECT_22 | SIBA_TGSLOW_REJECT_23); +} + +void +siba_dev_down(struct siba_dev_softc *sd, uint32_t flags) +{ + struct siba_softc *siba = sd->sd_bus; + uint32_t reject, val; + int i; + + if (siba_read_4(sd, SIBA_TGSLOW) & SIBA_TGSLOW_RESET) + return; + + reject = siba_tmslow_reject_bitmask(sd); + siba_write_4(sd, SIBA_TGSLOW, reject | SIBA_TGSLOW_CLOCK); + + for (i = 0; i < 1000; i++) { + val = siba_read_4(sd, SIBA_TGSLOW); + if (val & reject) + break; + DELAY(10); + } + if ((val & reject) == 0) { + device_printf(siba->siba_dev, "timeout (bit %#x reg %#x)\n", + reject, SIBA_TGSLOW); + } + for (i = 0; i < 1000; i++) { + val = siba_read_4(sd, SIBA_TGSHIGH); + if (!(val & SIBA_TGSHIGH_BUSY)) + break; + DELAY(10); + } + if ((val & SIBA_TGSHIGH_BUSY) != 0) { + device_printf(siba->siba_dev, "timeout (bit %#x reg %#x)\n", + SIBA_TGSHIGH_BUSY, SIBA_TGSHIGH); + } + + siba_write_4(sd, SIBA_TGSLOW, SIBA_TGSLOW_FGC | SIBA_TGSLOW_CLOCK | + reject | SIBA_TGSLOW_RESET | flags); + siba_read_4(sd, SIBA_TGSLOW); + DELAY(1); + siba_write_4(sd, SIBA_TGSLOW, reject | SIBA_TGSLOW_RESET | flags); + siba_read_4(sd, SIBA_TGSLOW); + DELAY(1); +} + +static void +siba_pcicore_setup(struct siba_pci *spc, struct siba_dev_softc *sd) +{ + struct siba_dev_softc *psd = spc->spc_dev; + struct siba_softc *siba = psd->sd_bus; + uint32_t tmp; + + if (psd->sd_id.sd_device == SIBA_DEVID_PCI) { + siba_pcicore_write_4(spc, SIBA_PCICORE_SBTOPCI2, + siba_pcicore_read_4(spc, SIBA_PCICORE_SBTOPCI2) | + SIBA_PCICORE_SBTOPCI_PREF | SIBA_PCICORE_SBTOPCI_BURST); + + if (psd->sd_id.sd_rev < 5) { + tmp = siba_read_4(psd, SIBA_IMCFGLO); + tmp &= ~SIBA_IMCFGLO_SERTO; + tmp = (tmp | 2) & ~SIBA_IMCFGLO_REQTO; + tmp |= 3 << 4 /* SIBA_IMCFGLO_REQTO_SHIFT */; + siba_write_4(psd, SIBA_IMCFGLO, tmp); + + /* broadcast value */ + sd = (siba->siba_cc.scc_dev != NULL) ? + siba->siba_cc.scc_dev : siba->siba_pci.spc_dev; + if (sd != NULL) { + siba_write_4(sd, SIBA_PCICORE_BCAST_ADDR, + 0xfd8); + siba_read_4(sd, SIBA_PCICORE_BCAST_ADDR); + siba_write_4(sd, SIBA_PCICORE_BCAST_DATA, 0); + siba_read_4(sd, SIBA_PCICORE_BCAST_DATA); + } + } else if (psd->sd_id.sd_rev >= 11) { + tmp = siba_pcicore_read_4(spc, SIBA_PCICORE_SBTOPCI2); + tmp |= SIBA_PCICORE_SBTOPCI_MRM; + siba_pcicore_write_4(spc, SIBA_PCICORE_SBTOPCI2, tmp); + } + } else { + KASSERT(psd->sd_id.sd_device == SIBA_DEVID_PCIE, ("only PCIE")); + if ((psd->sd_id.sd_rev == 0) || (psd->sd_id.sd_rev == 1)) + siba_pcie_write(spc, 0x4, + siba_pcie_read(spc, 0x4) | 0x8); + if (psd->sd_id.sd_rev == 0) { + siba_pcie_mdio_write(spc, 0x1f, 2, 0x8128); /* Timer */ + siba_pcie_mdio_write(spc, 0x1f, 6, 0x0100); /* CDR */ + siba_pcie_mdio_write(spc, 0x1f, 7, 0x1466); /* CDR BW */ + } else if (psd->sd_id.sd_rev == 1) + siba_pcie_write(spc, 0x100, + siba_pcie_read(spc, 0x100) | 0x40); + } + spc->spc_inited = 1; +} + +void +siba_pcicore_intr(struct siba_pci *spc, struct siba_dev_softc *sd) +{ + struct siba_dev_softc *psd = spc->spc_dev; + struct siba_softc *siba; + uint32_t tmp; + + if (sd->sd_bus->siba_type != SIBA_TYPE_PCI || !psd) + return; + + siba = psd->sd_bus; + /* enable interrupts */ + if (siba->siba_dev != NULL && + (psd->sd_id.sd_rev >= 6 || psd->sd_id.sd_device == SIBA_DEVID_PCIE)) { + tmp = pci_read_config(siba->siba_dev, SIBA_IRQMASK, 4); + tmp |= (1 << sd->sd_coreidx) << 8; + pci_write_config(siba->siba_dev, SIBA_IRQMASK, tmp, 4); + } else { + tmp = siba_read_4(sd, SIBA_TPS); + tmp &= SIBA_TPS_BPFLAG; + siba_write_4(psd, SIBA_INTR_MASK, + siba_read_4(psd, SIBA_INTR_MASK) | (1 << tmp)); + } + + /* setup PCIcore */ + if (spc->spc_inited == 0) + siba_pcicore_setup(spc, sd); +} + +static uint32_t +siba_pcicore_read_4(struct siba_pci *spc, uint16_t offset) +{ + + return (siba_read_4(spc->spc_dev, offset)); +} + +static void +siba_pcicore_write_4(struct siba_pci *spc, uint16_t offset, uint32_t value) +{ + + siba_write_4(spc->spc_dev, offset, value); +} + +static uint32_t +siba_pcie_read(struct siba_pci *spc, uint32_t address) +{ + + siba_pcicore_write_4(spc, 0x130, address); + return (siba_pcicore_read_4(spc, 0x134)); +} + +static void +siba_pcie_write(struct siba_pci *spc, uint32_t address, uint32_t data) +{ + + siba_pcicore_write_4(spc, 0x130, address); + siba_pcicore_write_4(spc, 0x134, data); +} + +static void +siba_pcie_mdio_write(struct siba_pci *spc, uint8_t device, uint8_t address, + uint16_t data) +{ + int i; + + siba_pcicore_write_4(spc, SIBA_PCICORE_MDIO_CTL, 0x80 | 0x2); + siba_pcicore_write_4(spc, SIBA_PCICORE_MDIO_DATA, + (1 << 30) | (1 << 28) | + ((uint32_t)device << 22) | ((uint32_t)address << 18) | + (1 << 17) | data); + DELAY(10); + for (i = 0; i < 10; i++) { + if (siba_pcicore_read_4(spc, SIBA_PCICORE_MDIO_CTL) & 0x100) + break; + DELAY(1000); + } + siba_pcicore_write_4(spc, SIBA_PCICORE_MDIO_CTL, 0); +} + +uint32_t +siba_dma_translation(struct siba_dev_softc *sd) +{ + + KASSERT(sd->sd_bus->siba_type == SIBA_TYPE_PCI, + ("unsupported bustype %d\n", sd->sd_bus->siba_type)); + return (SIBA_PCI_DMA); +} + +void +siba_barrier(struct siba_dev_softc *sd, int flags) +{ + struct siba_softc *siba = sd->sd_bus; + + SIBA_BARRIER(siba, flags); +} + +/* + * Attach it as child. + */ +device_t +siba_add_child(device_t dev, struct siba_softc *siba, int order, + const char *name, int unit) +{ + struct siba_dev_softc *sd; + device_t child; + int idx = 0, i; + + child = device_add_child(dev, name, unit); + if (child == NULL) + return (NULL); + + siba_powerup(siba, 0); + siba_pcicore_init(&siba->siba_pci); + siba_powerdown(siba); + + for (i = 0; i < siba->siba_ndevs; i++) { + sd = &(siba->siba_devs[i]); + + if (sd->sd_id.sd_device != SIBA_DEVID_80211) { + DPRINTF(siba, SIBA_DEBUG_CORE, + "skip to register coreid %#x (%s)\n", + sd->sd_id.sd_device, + siba_core_name(sd->sd_id.sd_device)); + continue; + } + + DPRINTF(siba, SIBA_DEBUG_CORE, + "siba: attaching coreid %#x (%s) idx %d\n", + sd->sd_id.sd_device, + siba_core_name(sd->sd_id.sd_device), idx); + + KASSERT(sd->sd_id.sd_device == SIBA_DEVID_80211, + ("%s:%d: SIBA_DEVID_80211 is only supportted currently.", + __func__, __LINE__)); + + device_set_ivars(child, sd); + device_probe_and_attach(child); + idx++; + } + return (child); +} + +static void +siba_cc_suspend(struct siba_cc *scc) +{ + + siba_cc_clock(scc, SIBA_CLOCK_SLOW); +} + +static void +siba_cc_resume(struct siba_cc *scc) +{ + + siba_cc_power_init(scc); + siba_cc_clock(scc, SIBA_CLOCK_FAST); +} + +int +siba_core_suspend(struct siba_softc *siba) +{ + + siba_cc_suspend(&siba->siba_cc); + siba_pci_gpio(siba, SIBA_GPIO_CRYSTAL | SIBA_GPIO_PLL, 0); + return (0); +} + +int +siba_core_resume(struct siba_softc *siba) +{ + + siba->siba_pci.spc_inited = 0; + siba->siba_curdev = NULL; + + siba_powerup(siba, 0); + /* XXX setup H/W for PCMCIA??? */ + siba_cc_resume(&siba->siba_cc); + siba_powerdown(siba); + + return (0); +} Index: siba_pcib.c =================================================================== --- siba_pcib.c (revision 202983) +++ siba_pcib.c (working copy) @@ -55,9 +55,9 @@ #include "pcib_if.h" -#include -#include #include +#include +#include #include #ifndef MIPS_MEM_RID @@ -79,10 +79,6 @@ #define SBPCI_CFGBASE 0x0C000000 #define SBPCI_CFGSIZE 0x01000000 -#define SBPCI_SBTOPCI0 0x100 -#define SBPCI_SBTOPCI1 0x104 -#define SBPCI_SBTOPCI2 0x108 - /* * TODO: implement type 1 config space access (ie beyond bus 0) * we may need to tweak the windows to do this @@ -187,9 +183,12 @@ * XXX we need to be able to do type 1 too. * we probably don't need to be able to do i/o cycles. */ - SBPCI_WRITE_4(sc, SBPCI_SBTOPCI0, 1); /* I/O read/write window */ - SBPCI_WRITE_4(sc, SBPCI_SBTOPCI1, 2); /* type 0 configuration only */ - SBPCI_WRITE_4(sc, SBPCI_SBTOPCI2, 1 << 30); /* memory only */ + + /* I/O read/write window */ + SBPCI_WRITE_4(sc, SIBA_PCICORE_SBTOPCI0, 1); + /* type 0 configuration only */ + SBPCI_WRITE_4(sc, SIBA_PCICORE_SBTOPCI1, 2); + SBPCI_WRITE_4(sc, SIBA_PCICORE_SBTOPCI2, 1 << 30); /* memory only */ DELAY(500); /* XXX resource managers */ @@ -365,7 +364,7 @@ /* * The configuration tag on the broadcom is weird. */ - SBPCI_WRITE_4(sc, SBPCI_SBTOPCI1, 2); /* XXX again??? */ + SBPCI_WRITE_4(sc, SIBA_PCICORE_SBTOPCI1, 2); /* XXX again??? */ cfgtag = ((1 << slot) << 16) | (func << 8); cfgaddr = SBPCI_CFGBASE | cfgtag | (reg & ~3); Index: sibavar.h =================================================================== --- sibavar.h (revision 202983) +++ sibavar.h (working copy) @@ -31,62 +31,341 @@ #include -struct siba_softc { - device_t sc_dev; /* Device ID */ - struct resource *sc_mem; /* Memory window on nexus */ +struct siba_softc; +struct siba_dev_softc; - bus_space_tag_t sc_bt; - bus_space_handle_t sc_bh; - bus_addr_t sc_maddr; - bus_size_t sc_msize; - - uint8_t sc_ncores; +enum siba_device_ivars { + SIBA_IVAR_VENDOR, + SIBA_IVAR_DEVICE, + SIBA_IVAR_REVID, + SIBA_IVAR_CORE_INDEX }; -struct siba_devinfo { - struct resource_list sdi_rl; - /*devhandle_t sdi_devhandle; XXX*/ - /*struct rman sdi_intr_rman;*/ +#define SIBA_ACCESSOR(var, ivar, type) \ + __BUS_ACCESSOR(siba, var, SIBA, ivar, type) - /* Accessors are needed for ivars below. */ - uint16_t sdi_vid; - uint16_t sdi_devid; - uint8_t sdi_rev; - uint8_t sdi_idx; /* core index on bus */ - uint8_t sdi_irq; /* TODO */ +SIBA_ACCESSOR(vendor, VENDOR, uint16_t) +SIBA_ACCESSOR(device, DEVICE, uint16_t) +SIBA_ACCESSOR(revid, REVID, uint8_t) +SIBA_ACCESSOR(core_index, CORE_INDEX, uint8_t) + +#undef SIBA_ACCESSOR + +/* XXX just for SPROM1? */ +enum { + SIBA_CCODE_WORLD, + SIBA_CCODE_THAILAND, + SIBA_CCODE_ISRAEL, + SIBA_CCODE_JORDAN, + SIBA_CCODE_CHINA, + SIBA_CCODE_JAPAN, + SIBA_CCODE_USA_CANADA_ANZ, + SIBA_CCODE_EUROPE, + SIBA_CCODE_USA_LOW, + SIBA_CCODE_JAPAN_HIGH, + SIBA_CCODE_ALL, + SIBA_CCODE_NONE, }; -#define siba_read_2(sc, core, reg) \ - bus_space_read_2((sc)->sc_bt, (sc)->sc_bh, \ +#define siba_mips_read_2(sc, core, reg) \ + bus_space_read_2((sc)->siba_mem_bt, (sc)->siba_mem_bh, \ (core * SIBA_CORE_LEN) + (reg)) -#define siba_read_4(sc, core, reg) \ - bus_space_read_4((sc)->sc_bt, (sc)->sc_bh, \ +#define siba_mips_read_4(sc, core, reg) \ + bus_space_read_4((sc)->siba_mem_bt, (sc)->siba_mem_bh, \ (core * SIBA_CORE_LEN) + (reg)) -#define siba_write_2(sc, core, reg, val) \ - bus_space_write_2((sc)->sc_bt, (sc)->sc_bh, \ +#define siba_mips_write_2(sc, core, reg, val) \ + bus_space_write_2((sc)->siba_mem_bt, (sc)->siba_mem_bh, \ (core * SIBA_CORE_LEN) + (reg), (val)) -#define siba_write_4(sc, core, reg, val) \ - bus_space_write_4((sc)->sc_bt, (sc)->sc_bh, \ +#define siba_mips_write_4(sc, core, reg, val) \ + bus_space_write_4((sc)->siba_mem_bt, (sc)->siba_mem_bh, \ (core * SIBA_CORE_LEN) + (reg), (val)) -enum siba_device_ivars { - SIBA_IVAR_VENDOR, - SIBA_IVAR_DEVICE, - SIBA_IVAR_REVID, - SIBA_IVAR_CORE_INDEX +#define SIBA_READ_4(siba, reg) \ + bus_space_read_4((siba)->siba_mem_bt, (siba)->siba_mem_bh, (reg)) +#define SIBA_READ_2(siba, reg) \ + bus_space_read_2((siba)->siba_mem_bt, (siba)->siba_mem_bh, (reg)) +#define SIBA_READ_MULTI_1(siba, reg, addr, count) \ + bus_space_read_multi_1((siba)->siba_mem_bt, (siba)->siba_mem_bh,\ + (reg), (addr), (count)) +#define SIBA_READ_MULTI_2(siba, reg, addr, count) \ + bus_space_read_multi_2((siba)->siba_mem_bt, (siba)->siba_mem_bh,\ + (reg), (addr), (count)) +#define SIBA_READ_MULTI_4(siba, reg, addr, count) \ + bus_space_read_multi_4((siba)->siba_mem_bt, (siba)->siba_mem_bh,\ + (reg), (addr), (count)) + +#define SIBA_WRITE_4(siba, reg, val) \ + bus_space_write_4((siba)->siba_mem_bt, (siba)->siba_mem_bh, \ + (reg), (val)) +#define SIBA_WRITE_2(siba, reg, val) \ + bus_space_write_2((siba)->siba_mem_bt, (siba)->siba_mem_bh, \ + (reg), (val)) +#define SIBA_WRITE_MULTI_1(siba, reg, addr, count) \ + bus_space_write_multi_1((siba)->siba_mem_bt, (siba)->siba_mem_bh,\ + (reg), (addr), (count)) +#define SIBA_WRITE_MULTI_2(siba, reg, addr, count) \ + bus_space_write_multi_2((siba)->siba_mem_bt, (siba)->siba_mem_bh,\ + (reg), (addr), (count)) +#define SIBA_WRITE_MULTI_4(siba, reg, addr, count) \ + bus_space_write_multi_4((siba)->siba_mem_bt, (siba)->siba_mem_bh,\ + (reg), (addr), (count)) + +#define SIBA_BARRIER(siba, flags) \ + bus_space_barrier((siba)->siba_mem_bt, (siba)->siba_mem_bh, (0),\ + (0), (flags)) + +#define SIBA_SETBITS_4(siba, reg, bits) \ + SIBA_WRITE_4((siba), (reg), SIBA_READ_4((siba), (reg)) | (bits)) +#define SIBA_SETBITS_2(siba, reg, bits) \ + SIBA_WRITE_2((siba), (reg), SIBA_READ_2((siba), (reg)) | (bits)) + +#define SIBA_FILT_SETBITS_4(siba, reg, filt, bits) \ + SIBA_WRITE_4((siba), (reg), (SIBA_READ_4((siba), \ + (reg)) & (filt)) | (bits)) +#define SIBA_FILT_SETBITS_2(siba, reg, filt, bits) \ + SIBA_WRITE_2((siba), (reg), (SIBA_READ_2((siba), \ + (reg)) & (filt)) | (bits)) + +#define SIBA_CLRBITS_4(siba, reg, bits) \ + SIBA_WRITE_4((siba), (reg), SIBA_READ_4((siba), (reg)) & ~(bits)) +#define SIBA_CLRBITS_2(siba, reg, bits) \ + SIBA_WRITE_2((siba), (reg), SIBA_READ_2((siba), (reg)) & ~(bits)) + +#define SIBA_CC_READ32(scc, offset) \ + siba_read_4((scc)->scc_dev, offset) +#define SIBA_CC_WRITE32(scc, offset, val) \ + siba_write_4((scc)->scc_dev, offset, val) +#define SIBA_CC_MASK32(scc, offset, mask) \ + SIBA_CC_WRITE32(scc, offset, SIBA_CC_READ32(scc, offset) & (mask)) +#define SIBA_CC_SET32(scc, offset, set) \ + SIBA_CC_WRITE32(scc, offset, SIBA_CC_READ32(scc, offset) | (set)) +#define SIBA_CC_MASKSET32(scc, offset, mask, set) \ + SIBA_CC_WRITE32(scc, offset, \ + (SIBA_CC_READ32(scc, offset) & (mask)) | (set)) + +enum siba_type { + SIBA_TYPE_SSB, + SIBA_TYPE_PCI, + SIBA_TYPE_PCMCIA, }; -#define SIBA_ACCESSOR(var, ivar, type) \ - __BUS_ACCESSOR(siba, var, SIBA, ivar, type) +enum siba_clock { + SIBA_CLOCK_DYNAMIC, + SIBA_CLOCK_SLOW, + SIBA_CLOCK_FAST, +}; -SIBA_ACCESSOR(vendor, VENDOR, uint16_t) -SIBA_ACCESSOR(device, DEVICE, uint16_t) -SIBA_ACCESSOR(revid, REVID, uint8_t) -SIBA_ACCESSOR(core_index, CORE_INDEX, uint8_t) +enum siba_clksrc { + SIBA_CC_CLKSRC_PCI, + SIBA_CC_CLKSRC_CRYSTAL, + SIBA_CC_CLKSRC_LOWPW, +}; -#undef SIBA_ACCESSOR +struct siba_cc_pmu0_plltab { + uint16_t freq; /* in kHz.*/ + uint8_t xf; /* crystal frequency */ + uint8_t wb_int; + uint32_t wb_frac; +}; +struct siba_cc_pmu1_plltab { + uint16_t freq; + uint8_t xf; + uint8_t p1div; + uint8_t p2div; + uint8_t ndiv_int; + uint32_t ndiv_frac; +}; + +struct siba_cc_pmu_res_updown { + uint8_t res; + uint16_t updown; +}; + +#define SIBA_CC_PMU_DEP_SET 1 +#define SIBA_CC_PMU_DEP_ADD 2 +#define SIBA_CC_PMU_DEP_REMOVE 3 + +struct siba_cc_pmu_res_depend { + uint8_t res; + uint8_t task; + uint32_t depend; +}; + +struct siba_sprom { + uint8_t rev; /* revision */ + uint8_t mac_80211bg[6]; /* address for 802.11b/g */ + uint8_t mac_eth[6]; /* address for Ethernet */ + uint8_t mac_80211a[6]; /* address for 802.11a */ + uint8_t mii_eth0; /* MII address for eth0 */ + uint8_t mii_eth1; /* MII address for eth1 */ + uint8_t mdio_eth0; /* MDIO for eth0 */ + uint8_t mdio_eth1; /* MDIO for eth1 */ + uint8_t brev; /* board revision */ + uint8_t ccode; /* Country Code */ + uint8_t ant_a; /* A-PHY antenna */ + uint8_t ant_bg; /* B/G-PHY antenna */ + uint16_t pa0b0; + uint16_t pa0b1; + uint16_t pa0b2; + uint16_t pa1b0; + uint16_t pa1b1; + uint16_t pa1b2; + uint8_t gpio0; + uint8_t gpio1; + uint8_t gpio2; + uint8_t gpio3; + uint16_t maxpwr_a; /* A-PHY Max Power */ + uint16_t maxpwr_bg; /* BG-PHY Max Power */ + uint8_t tssi_a; /* Idle TSSI */ + uint8_t tssi_bg; /* Idle TSSI */ + uint16_t bf_lo; /* boardflags */ + uint16_t bf_hi; /* boardflags */ + struct { + struct { + int8_t a0, a1, a2, a3; + } ghz24; + struct { + int8_t a0, a1, a2, a3; + } ghz5; + } again; /* antenna gain */ +}; + +struct siba_cc_pmu { + uint8_t rev; /* PMU rev */ + uint32_t freq; /* crystal freq in kHz */ +}; + +struct siba_cc { + struct siba_dev_softc *scc_dev; + uint32_t scc_caps; + struct siba_cc_pmu scc_pmu; + uint16_t scc_powerup_delay; +}; + +struct siba_pci { + struct siba_dev_softc *spc_dev; + uint8_t spc_inited; + uint8_t spc_hostmode; +}; + +struct siba_bus_ops { + uint16_t (*read_2)(struct siba_dev_softc *, + uint16_t); + uint32_t (*read_4)(struct siba_dev_softc *, + uint16_t); + void (*write_2)(struct siba_dev_softc *, + uint16_t, uint16_t); + void (*write_4)(struct siba_dev_softc *, + uint16_t, uint32_t); + void (*read_multi_1)(struct siba_dev_softc *, + void *, size_t, uint16_t); + void (*read_multi_2)(struct siba_dev_softc *, + void *, size_t, uint16_t); + void (*read_multi_4)(struct siba_dev_softc *, + void *, size_t, uint16_t); + void (*write_multi_1)(struct siba_dev_softc *, + const void *, size_t, uint16_t); + void (*write_multi_2)(struct siba_dev_softc *, + const void *, size_t, uint16_t); + void (*write_multi_4)(struct siba_dev_softc *, + const void *, size_t, uint16_t); +}; + +struct siba_dev_softc { + struct siba_softc *sd_bus; + struct siba_devid sd_id; + const struct siba_bus_ops *sd_ops; + + uint8_t sd_coreidx; +}; + +struct siba_devinfo { + struct resource_list sdi_rl; + /*devhandle_t sdi_devhandle; XXX*/ + /*struct rman sdi_intr_rman;*/ + + /* Accessors are needed for ivars below. */ + uint16_t sdi_vid; + uint16_t sdi_devid; + uint8_t sdi_rev; + uint8_t sdi_idx; /* core index on bus */ + uint8_t sdi_irq; /* TODO */ +}; + +struct siba_softc { + /* + * common variables which used for siba(4) bus and siba_bwn bridge. + */ + device_t siba_dev; /* Device ID */ + struct resource *siba_mem_res; + bus_space_tag_t siba_mem_bt; + bus_space_handle_t siba_mem_bh; + bus_addr_t siba_maddr; + bus_size_t siba_msize; + uint8_t siba_ncores; + + /* + * the following variables are only used for siba_bwn bridge. + */ + + enum siba_type siba_type; + int siba_invalid; + + struct siba_dev_softc *siba_curdev; /* only for PCI */ + struct siba_dev_softc siba_devs[SIBA_MAX_CORES]; + int siba_ndevs; + + uint16_t siba_pci_vid; + uint16_t siba_pci_did; + uint16_t siba_pci_subvid; + uint16_t siba_pci_subdid; + int siba_mem_rid; + + uint16_t siba_chipid; /* for CORE 0 */ + uint16_t siba_chiprev; + uint8_t siba_chippkg; + + struct siba_cc siba_cc; /* ChipCommon */ + struct siba_pci siba_pci; /* PCI-core */ + const struct siba_bus_ops *siba_ops; + + /* board informations */ + uint16_t siba_board_vendor; + uint16_t siba_board_type; + uint16_t siba_board_rev; + struct siba_sprom siba_sprom; /* SPROM */ + uint16_t siba_spromsize; /* in word size */ +}; + +void siba_powerup(struct siba_softc *, int); +uint16_t siba_read_2(struct siba_dev_softc *, uint16_t); +void siba_write_2(struct siba_dev_softc *, uint16_t, uint16_t); +uint32_t siba_read_4(struct siba_dev_softc *, uint16_t); +void siba_write_4(struct siba_dev_softc *, uint16_t, uint32_t); +void siba_dev_up(struct siba_dev_softc *, uint32_t); +void siba_dev_down(struct siba_dev_softc *, uint32_t); +int siba_powerdown(struct siba_softc *); +int siba_dev_isup(struct siba_dev_softc *); +void siba_pcicore_intr(struct siba_pci *, struct siba_dev_softc *); +uint32_t siba_dma_translation(struct siba_dev_softc *); +void *siba_dma_alloc_consistent(struct siba_dev_softc *, size_t, + bus_addr_t *); +void siba_read_multi_1(struct siba_dev_softc *, void *, size_t, + uint16_t); +void siba_read_multi_2(struct siba_dev_softc *, void *, size_t, + uint16_t); +void siba_read_multi_4(struct siba_dev_softc *, void *, size_t, + uint16_t); +void siba_write_multi_1(struct siba_dev_softc *, const void *, + size_t, uint16_t); +void siba_write_multi_2(struct siba_dev_softc *, const void *, + size_t, uint16_t); +void siba_write_multi_4(struct siba_dev_softc *, const void *, + size_t, uint16_t); +void siba_barrier(struct siba_dev_softc *, int); + #endif /* _SIBA_SIBAVAR_H_ */ --YiEDa0DAkWCtVeE4-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 20:58:32 2010 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 B15F91065670 for ; Wed, 27 Jan 2010 20:58:32 +0000 (UTC) (envelope-from naylor.b.david@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 38FFA8FC13 for ; Wed, 27 Jan 2010 20:58:31 +0000 (UTC) Received: by ewy10 with SMTP id 10so1728607ewy.3 for ; Wed, 27 Jan 2010 12:58:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:organization:to:subject :date:user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=YcVj5taHUAtaXhly+RBJYxgdExvogBg602pXoBYpYYc=; b=WElOBWBplTlxPCgFJr9DFYORp6sYZYOVPnZQ0lnmPQg3uD9fVcDz+BOeMSG6FhEvMn FoZ93vBbZ+YAj2ye+cmd4yo9+gaMIApUqhcUz8KwkMoQD2dobO+TeQTKSp8u99IpBrRI Y00NztPZfgalpbAclUhy/pr8V6PiRFBr+/ch8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:organization:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; b=LBK6YIAtzgLCqderEi3C9yzdX866i3lh3NTsCzIiOsUmWf7rA38jdcMUnsamSVtnI9 QMFTJLWIKvDO7YzlU/HXaqYRSXx0vQjAQNekcGD0ijcTEWtttugH2mUtGuG0Ae5kvmTS d77WzYj3b4bLyeDMAmPeSWbimS4FU2Qn6IxXU= Received: by 10.213.44.17 with SMTP id y17mr4420486ebe.25.1264625910269; Wed, 27 Jan 2010 12:58:30 -0800 (PST) Received: from dragon.dg ([41.216.197.17]) by mx.google.com with ESMTPS id 10sm586948eyz.15.2010.01.27.12.58.27 (version=SSLv3 cipher=RC4-MD5); Wed, 27 Jan 2010 12:58:28 -0800 (PST) From: David Naylor Organization: Private To: gary.jennejohn@freenet.de Date: Wed, 27 Jan 2010 22:58:31 +0200 User-Agent: KMail/1.12.3 (FreeBSD/8.0-STABLE; KDE/4.3.3; amd64; ; ) References: <201001231233.18832.naylor.b.david@gmail.com> <20100126140459.61e3951d@ernst.jennejohn.org> <201001261841.23815.naylor.b.david@gmail.com> In-Reply-To: <201001261841.23815.naylor.b.david@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1335951.JWWOHOyWEC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001272258.35184.naylor.b.david@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: "tinderbox" using stacked unionfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jan 2010 20:58:32 -0000 --nextPart1335951.JWWOHOyWEC Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Tuesday 26 January 2010 18:41:20 David Naylor wrote: > On Tuesday 26 January 2010 15:04:59 Gary Jennejohn wrote: > > On Mon, 25 Jan 2010 20:39:11 +0200 > > > > David Naylor wrote: > > > On Saturday 23 January 2010 12:33:14 David Naylor wrote: > > > > Hi, > > > > > > > > I have been experimenting with using unionfs to build ports in a > > > > "tinderbox" environment. This avoids having to remove and extract > > > > files for the build of each port and it allows the discovery of > > > > installed/modified files by the port. > > > > > > > > Please see attached for a (updated) shell script that handles all t= he > > > > "heavy lifting" of building ports. Of importance is LOCALBASE and > > > > BUILDDIR. If you want to override LOCALBASE please use `env` as t= he > > > > script needs to know about it. BUILDDIR (/usr/build by default) is > > > > where the script stores everything (including PKG_DBDIR). > > > > > > Please see attached for an updated script. This no longer uses `sort > > > -u` but removed duplicates while maintaining dependency order. (See > > > below) > > > > ENOSCRIPT >=20 > See attached. Processes are still freezing periodically (requiring a > restart). The mtree problem appears when installing meta ports (x11/xorg- > apps, x11/xorg, etc). The script finally managed to finish without stalling. Here are some=20 comparative results: # time make -C /usr/ports/x11/xorg install clean 2185.180u 1066.927s 38:12.27 141.8% 4123+1745k 5185+1890io 51638pf+0w # time ./ports-union-builder.sh 2264.914u 6097.779s 2:15:07.39 103.1% 3777+1608k 171735+226215io 51424pf+= 0w This results in the unionfs method being ~2.5x longer in execution. This=20 difference should decrease a fair amount if the long execution times of mtr= ee=20 can be reduced. =20 The benefits of using memory backed UFS storage has not been explored. =20 NOTE: ports-union-builder.sh also produces packages. =20 --nextPart1335951.JWWOHOyWEC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) iEYEABECAAYFAktgqPsACgkQUaaFgP9pFrInNQCfTbYbXHmYexfCExQfpWAbIAmG 9nsAn0eqWhjB+9dml9+AN6O5589UIinC =e8dc -----END PGP SIGNATURE----- --nextPart1335951.JWWOHOyWEC-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 21:32:15 2010 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 BB82D106568F; Wed, 27 Jan 2010 21:32:15 +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 61B708FC1E; Wed, 27 Jan 2010 21:32:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o0RLGat1095594; Wed, 27 Jan 2010 14:16:36 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 27 Jan 2010 14:17:28 -0700 (MST) Message-Id: <20100127.141728.18550985194373697.imp@bsdimp.com> To: weongyo@freebsd.org, weongyo.jeong@gmail.com From: "M. Warner Losh" In-Reply-To: <20100127205338.GA28399@weongyo> References: <20100127205338.GA28399@weongyo> X-Mailer: Mew version 6.3 on Emacs 22.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: HEADUP: major update of siba(4) - again X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2010 21:32:15 -0000 In message: <20100127205338.GA28399@weongyo> Weongyo Jeong writes: : I made an another patch not to break the backward compatibility of : siba(4). : : http://people.freebsd.org/~weongyo/patch_siba_20100127.diff I think this will work better. I have no further objections... Warner From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 22:01:43 2010 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 1C0691065693 for ; Wed, 27 Jan 2010 22:01:43 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id E98D78FC0C for ; Wed, 27 Jan 2010 22:01:42 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id o0RM1fQ9053896; Wed, 27 Jan 2010 17:01:41 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <201001272201.o0RM1fQ9053896@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Jan 2010 17:01:48 -0500 To: Jack Vogel From: Mike Tancsa In-Reply-To: <2a41acea1001271158p516ecedfge068edefff02ccbe@mail.gmail.co m> References: <201001271929.o0RJTVbB053140@lava.sentex.ca> <2a41acea1001271158p516ecedfge068edefff02ccbe@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: new em problems on HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jan 2010 22:01:43 -0000 At 02:58 PM 1/27/2010, Jack Vogel wrote: >Please try the driver as updated today and see if this still >happens, I sure hope not. The watchdog error seems to be gone! but it still panics on the netboot for some reason. I loaded up a GENERIC kernel as well. Not sure if thats just a result of not being able to mount things or some other problem ? NFS ROOT: 10.255.255.1:/usr/home/pxe9/ em0: link state changed to UP Interface em0 IP-Address 10.255.255.118 Broadcast 10.255.255.255 mount_nfs: can't update /var/db/mounttab for 10.255.255.1:/usr/home/pxe9//etc lock order reversal: 1st 0xd94ef2a0 bufwait (bufwait) @ /usr/HEAD/src/sys/kern/vfs_bio.c:2559 2nd 0xc59cc800 dirhash (dirhash) @ /usr/HEAD/src/sys/ufs/ufs/ufs_dirhash.c:285 KDB: stack backtrace: db_trace_self_wrapper(c0c9c547,c53bf74c,c08d51c5,c08c5ddb,c0c9f4a3,...) at db_trace_self_wrapper+0x26 kdb_backtrace(c08c5ddb,c0c9f4a3,c552efc8,c5532840,c53bf7a8,...) at kdb_backtrace+0x29 _witness_debugger(c0c9f4a3,c59cc800,c0cc149a,c5532840,c0cc111a,...) at _witness_debugger+0x25 witness_checkorder(c59cc800,9,c0cc111a,11d,0,...) at witness_checkorder+0x839 _sx_xlock(c59cc800,0,c0cc111a,11d,c5e55658,...) at _sx_xlock+0x85 ufsdirhash_acquire(d94ef240,d991e800,200,d991e814,c53bf878,...) at ufsdirhash_acquire+0x35 ufsdirhash_add(c5e55658,c53bf8d0,814,c53bf864,c53bf868,...) at ufsdirhash_add+0x13 ufs_direnter(c5e6a660,c5eb9550,c53bf8d0,c53bfbd0,0,...) at ufs_direnter+0x729 ufs_makeinode(c53bfbd0,0,c53bfabc,c53bfa18,c0bdf755,...) at ufs_makeinode+0x50d ufs_create(c53bfabc,c53bfad4,0,0,c53bfba4,...) at ufs_create+0x30 VOP_CREATE_APV(c0da6540,c53bfabc,c53bfbd0,c53bfa54,0,...) at VOP_CREATE_APV+0xa5 vn_open_cred(c53bfba4,c53bfc5c,16d,0,c556ec00,...) at vn_open_cred+0x215 vn_open(c53bfba4,c53bfc5c,16d,c5dada10,c0d96aa0,...) at vn_open+0x3b kern_openat(c5db3240,ffffff9c,804c5e8,0,602,...) at kern_openat+0x11f kern_open(c5db3240,804c5e8,0,601,816d,...) at kern_open+0x35 open(c5db3240,c53bfcf8,c0cd38ae,c0c7faf5,c5dea2a8,...) at open+0x30 syscall(c53bfd38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (5, FreeBSD ELF32, open), eip = 0x2816ead3, esp = 0xbfbfec6c, ebp = 0xbfbfecd8 --- kernel trap 18 with interrupts disabled Fatal trap 18: integer divide fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xc0bd216b stack pointer = 0x28:0xc53b7704 frame pointer = 0x28:0xc53b7778 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 48 (ps) [thread pid 48 tid 100078 ] Stopped at __qdivrem+0x3b: divl %ecx,%eax db> bt Tracing pid 48 tid 100078 td 0xc5db36c0 __qdivrem(0,0,0,0,0,...) at __qdivrem+0x3b __udivdi3(0,0,0,0,c53b7a20,...) at __udivdi3+0x2e cputick2usec(0,0,c0c980c6,2ef,c5db3764,...) at cputick2usec+0xfd fill_kinfo_proc(c599e550,c53b7810,c0c980c6,3d8,4,...) at fill_kinfo_proc+0x3ac sysctl_out_proc(c5db36c0,c599e550,51c,c53b7b58,c08990d6,...) at sysctl_out_proc+0xac sysctl_kern_proc(c0d8cec0,c53b7c1c,1,c53b7ba4,c53b7ba4,...) at sysctl_kern_proc+0xd2 sysctl_root(c53b7ba4,0,c0c99ca0,5f1,c5db36c0,...) at sysctl_root+0x1c8 userland_sysctl(c5db36c0,c53b7c10,4,0,bfbfe2b4,...) at userland_sysctl+0x17c __sysctl(c5db36c0,c53b7cf8,c0cd38ae,c0c7faf5,c5dea7f8,...) at __sysctl+0x94 syscall(c53b7d38) at syscall+0x220 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x281a593b, esp = 0xbfbfe1dc, ebp = 0xbfbfe208 --- db> Booting from the RELENG6 disk shows the nics to be em0@pci13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = '82573E Intel Corporation 82573E Gigabit Ethernet Controller (Copper)' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint em1@pci14:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = '82573L Intel PRO/1000 PL Network Adaptor' class = network subclass = ethernet cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint >Cheers, > >Jack > > >On Wed, Jan 27, 2010 at 11:29 AM, Mike Tancsa ><mike@sentex.net> wrote: > >Not sure if the panic is related, but the watchdog timeout issue on >bootup seems to be repeatable on this motherboard with HEAD from >last Friday. It boots up fine under 6.x > > >FreeBSD 9.0-CURRENT #1: Fri Jan 22 16:43:53 EST 2010 > mdtancsa@ich10.sentex.ca:/usr/HEAD/obj/usr/HEAD/src/sys/alix i386 >Timecounter "i8254" frequency 1193182 Hz quality 0 >CPU: Intel(R) Pentium(R) CPU E6500 @ 2.93GHz (0.00-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 > >Features=0xbfebfbff > >Features2=0x400e3bd > AMD Features=0x20100000 > AMD Features2=0x1 > TSC: P-state invariant >real memory = 2147483648 (2048 MB) >avail memory = 2089807872 (1992 MB) >ACPI APIC Table: >FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 >ioapic0 irqs 0-23 on motherboard >ioapic1 irqs 24-47 on motherboard >kbd1 at kbdmux0 >cryptosoft0: on motherboard >acpi0: on motherboard >acpi0: [ITHREAD] >acpi0: Power Button (fixed) >Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 >pcib0: port 0xcf8-0xcff on acpi0 >pci0: on pcib0 >pcib1: irq 16 at device 1.0 on pci0 >pci1: on pcib1 >pcib2: irq 17 at device 28.0 on pci0 >pci9: on pcib2 >pcib3: at device 0.0 on pci9 >pci10: on pcib3 >pci10: at device 1.0 (no driver attached) >pcib4: irq 17 at device 28.4 on pci0 >pci13: on pcib4 >em0: port >0x5000-0x501f mem 0xe1000000-0xe101ffff irq 16 at device 0.0 on pci13 >em0: Using MSI interrupt >em0: [FILTER] >em0: Ethernet address: 00:30:48:8d:2a:96 >pcib5: irq 16 at device 28.5 on pci0 >pci14: on pcib5 >em1: port >0x6000-0x601f mem 0xe1100000-0xe111ffff irq 17 at device 0.0 on pci14 >em1: Using MSI interrupt >em1: [FILTER] >em1: Ethernet address: 00:30:48:8d:2a:97 >uhci0: port 0x3000-0x301f >irq 23 at device 29.0 on pci0 >uhci0: [ITHREAD] >usbus0: on uhci0 >uhci1: port 0x3020-0x303f >irq 19 at device 29.1 on pci0 >uhci1: [ITHREAD] >usbus1: on uhci1 >uhci2: port 0x3040-0x305f >irq 18 at device 29.2 on pci0 >uhci2: [ITHREAD] >usbus2: on uhci2 >uhci3: port 0x3060-0x307f >irq 16 at device 29.3 on pci0 >uhci3: [ITHREAD] >usbus3: on uhci3 >ehci0: mem >0xe0000000-0xe00003ff irq 23 at device 29.7 on pci0 >ehci0: [ITHREAD] >usbus4: EHCI version 1.0 >usbus4: on ehci0 >pcib6: at device 30.0 on pci0 >pci15: on pcib6 >vgapci0: port 0x7000-0x70ff mem >0xe8000000-0xefffffff,0xe1200000-0xe120ffff irq 16 at device 0.0 on pci15 >isab0: at device 31.0 on pci0 >isa0: on isab0 >atapci0: port >0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 >ata0: on atapci0 >ata0: [ITHREAD] >pci0: at device 31.3 (no driver attached) >acpi_button0: on acpi0 >atrtc0: port 0x70-0x71 irq 8 on acpi0 >atkbdc0: port 0x60,0x64 irq 1 on acpi0 >atkbd0: irq 1 on atkbdc0 >kbd0 at atkbd0 >atkbd0: [GIANT-LOCKED] >atkbd0: [ITHREAD] >uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >uart0: [FILTER] >uart0: console (9600,n,8,1) >uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 >uart1: [FILTER] >cpu0: on acpi0 >est0: on cpu0 >est: CPU supports Enhanced Speedstep, but is not recognized. >est: cpu_vendor GenuineIntel, msr 6160b2506000616 >device_attach: est0 attach returned 6 >p4tcc0: on cpu0 >cpu1: on acpi0 >est1: on cpu1 >est: CPU supports Enhanced Speedstep, but is not recognized. >est: cpu_vendor GenuineIntel, msr 6160b2506000616 >device_attach: est1 attach returned 6 >p4tcc1: on cpu1 >pmtimer0 on isa0 >orm0: at iomem >0xc0000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xcd000-0xcdfff >pnpid ORM0000 on isa0 >sc0: at flags 0x100 on isa0 >sc0: VGA <16 virtual consoles, flags=0x300> >vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >Timecounters tick every 1.000 msec >IPsec: Initialized Security Association Processing. >usbus0: 12Mbps Full Speed USB v1.0 >usbus1: 12Mbps Full Speed USB v1.0 >usbus2: 12Mbps Full Speed USB v1.0 >usbus3: 12Mbps Full Speed USB v1.0 >usbus4: 480Mbps High Speed USB v2.0 >SMP: AP CPU #1 Launched! >ugen0.1: at usbus0 >ugen1.1: at usbus1 >uhub0: on usbus0 >uhub1: on usbus1 >Root mount waiting for: usbus4 usbus3 usbus2 usbus1 usbus0 >ugen2.1: at usbus2 >ugen3.1: at usbus3 >uhub2: on usbus2 >uhub3: on usbus3 >ugen4.1: at usbus4 >uhub4: on usbus4 >uhub0: 2 ports with 2 removable, self powered >uhub1: 2 ports with 2 removable, self powered >uhub2: 2 ports with 2 removable, self powered >uhub3: 2 ports with 2 removable, self powered >Root mount waiting for: usbus4 >Root mount waiting for: usbus4 >Root mount waiting for: usbus4 >uhub4: 8 ports with 8 removable, self powered >Trying to mount root from nfs: >NFS ROOT: 10.255.255.1:/usr/home/pxe9/ >em0: Watchdog timeout -- resetting >em0: link state changed to UP >Interface em0 IP-Address 10.255.255.118 Broadcast 10.255.255.255 >mount_nfs: can't update /var/db/mounttab for 10.255.255.1:/usr/home/pxe9//etc >kernel trap 18 with interrupts disabled > > >Fatal trap 18: integer divide fault while in kernel mode >cpuid = 1; apic id = 01 >instruction pointer = 0x20:0xc0995f0b >stack pointer = 0x28:0xc4e746f8 >frame pointer = 0x28:0xc4e7476c >code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 >processor eflags = resume, IOPL = 0 >current process = 52 (ps) >trap number = 18 >panic: integer divide fault >cpuid = 1 >Uptime: 1m23s >Cannot dump. Device not defined or unavailable. >Automatic reboot in 15 seconds - press a key on the console to abort > >Fatal double fault: >eip = 0xc098e8d0 >esp = 0xc4d00000 >ebp = 0xc4d00020 >cpuid = 1; Rebooting... >apic id = 01 >cpu_reset: Stopping other CPUs >panic: double fault >cpuid = 1 >Uptime: 1m23s >Cannot dump. Device not defined or unavailable. >Automatic reboot in 15 seconds - press a key on the console to abort >Rebooting... >cpu_reset: Stopping other CPUs > > >-------------------------------------------------------------------- >Mike Tancsa, tel +1 519 651 3400 >Sentex >Communications, >mike@sentex.net >Providing Internet since >1994 www.sentex.net >Cambridge, Ontario >Canada www.sentex.net/mike > -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 22:06:39 2010 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 87CA21065679 for ; Wed, 27 Jan 2010 22:06:39 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by mx1.freebsd.org (Postfix) with ESMTP id 668778FC1E for ; Wed, 27 Jan 2010 22:06:38 +0000 (UTC) Received: by ewy10 with SMTP id 10so45273ewy.3 for ; Wed, 27 Jan 2010 14:06: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; bh=FzNg9iABMf/qGobJvf86Bb7moVKkI87pNnqoYIWEURM=; b=uVR0TqMuRc124V7cz6GDNEtKhyzsGW9o//kg2FGURTy9AoLU6XMkRVDW/QJxV5RTxi LsSeC03BQuY8IR0ezkfc1sj4Aq1AoDf3dJV5cDzyYn4qQOJh+fl9qEBdsYuS89feuz0h Wwf3c08R1Faw+RSc4zPevRF9vXRSivkyg/5bU= 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; b=G7r+cEsvYu2XMHMIps2BoJ03J65DqT+1AYIWFdZs32tbabfXWqrUmGdtnbtnvySkMq 13U2fYAxAaP1K2Tsgh4sbl+2hycNNhVN6F5QH60r45/BJVV8nNDXcOodZbmJjXIUn0IL ee37cklatD63w+kUaD9ntM76p7Vajxgf/XqlM= MIME-Version: 1.0 Received: by 10.216.93.14 with SMTP id k14mr1687086wef.152.1264629997299; Wed, 27 Jan 2010 14:06:37 -0800 (PST) In-Reply-To: <201001272201.o0RM1fQ9053896@lava.sentex.ca> References: <201001271929.o0RJTVbB053140@lava.sentex.ca> <2a41acea1001271158p516ecedfge068edefff02ccbe@mail.gmail.com> <201001272201.o0RM1fQ9053896@lava.sentex.ca> Date: Wed, 27 Jan 2010 14:06:37 -0800 Message-ID: <2a41acea1001271406h7a61a72fv713e06ed2448b619@mail.gmail.com> From: Jack Vogel To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: new em problems on HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jan 2010 22:06:39 -0000 I have no idea, i see no evidence that its the em driver at fault, do you? Jack On Wed, Jan 27, 2010 at 2:01 PM, Mike Tancsa wrote: > At 02:58 PM 1/27/2010, Jack Vogel wrote: > >> Please try the driver as updated today and see if this still happens, I >> sure hope not. >> > > The watchdog error seems to be gone! but it still panics on the netboot for > some reason. I loaded up a GENERIC kernel as well. Not sure if thats just > a result of not being able to mount things or some other problem ? > > > NFS ROOT: 10.255.255.1:/usr/home/pxe9/ > em0: link state changed to UP > Interface em0 IP-Address 10.255.255.118 Broadcast 10.255.255.255 > mount_nfs: can't update /var/db/mounttab for 10.255.255.1: > /usr/home/pxe9//etc > lock order reversal: > 1st 0xd94ef2a0 bufwait (bufwait) @ /usr/HEAD/src/sys/kern/vfs_bio.c:2559 > 2nd 0xc59cc800 dirhash (dirhash) @ > /usr/HEAD/src/sys/ufs/ufs/ufs_dirhash.c:285 > KDB: stack backtrace: > db_trace_self_wrapper(c0c9c547,c53bf74c,c08d51c5,c08c5ddb,c0c9f4a3,...) at > db_trace_self_wrapper+0x26 > kdb_backtrace(c08c5ddb,c0c9f4a3,c552efc8,c5532840,c53bf7a8,...) at > kdb_backtrace+0x29 > _witness_debugger(c0c9f4a3,c59cc800,c0cc149a,c5532840,c0cc111a,...) at > _witness_debugger+0x25 > witness_checkorder(c59cc800,9,c0cc111a,11d,0,...) at > witness_checkorder+0x839 > _sx_xlock(c59cc800,0,c0cc111a,11d,c5e55658,...) at _sx_xlock+0x85 > ufsdirhash_acquire(d94ef240,d991e800,200,d991e814,c53bf878,...) at > ufsdirhash_acquire+0x35 > ufsdirhash_add(c5e55658,c53bf8d0,814,c53bf864,c53bf868,...) at > ufsdirhash_add+0x13 > ufs_direnter(c5e6a660,c5eb9550,c53bf8d0,c53bfbd0,0,...) at > ufs_direnter+0x729 > ufs_makeinode(c53bfbd0,0,c53bfabc,c53bfa18,c0bdf755,...) at > ufs_makeinode+0x50d > ufs_create(c53bfabc,c53bfad4,0,0,c53bfba4,...) at ufs_create+0x30 > VOP_CREATE_APV(c0da6540,c53bfabc,c53bfbd0,c53bfa54,0,...) at > VOP_CREATE_APV+0xa5 > vn_open_cred(c53bfba4,c53bfc5c,16d,0,c556ec00,...) at vn_open_cred+0x215 > vn_open(c53bfba4,c53bfc5c,16d,c5dada10,c0d96aa0,...) at vn_open+0x3b > kern_openat(c5db3240,ffffff9c,804c5e8,0,602,...) at kern_openat+0x11f > kern_open(c5db3240,804c5e8,0,601,816d,...) at kern_open+0x35 > open(c5db3240,c53bfcf8,c0cd38ae,c0c7faf5,c5dea2a8,...) at open+0x30 > syscall(c53bfd38) at syscall+0x220 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (5, FreeBSD ELF32, open), eip = 0x2816ead3, esp = 0xbfbfec6c, > ebp = 0xbfbfecd8 --- > > kernel trap 18 with interrupts disabled > > > Fatal trap 18: integer divide fault while in kernel mode > cpuid = 0; apic id = 00 > instruction pointer = 0x20:0xc0bd216b > stack pointer = 0x28:0xc53b7704 > frame pointer = 0x28:0xc53b7778 > > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 48 (ps) > [thread pid 48 tid 100078 ] > Stopped at __qdivrem+0x3b: divl %ecx,%eax > db> bt > Tracing pid 48 tid 100078 td 0xc5db36c0 > __qdivrem(0,0,0,0,0,...) at __qdivrem+0x3b > __udivdi3(0,0,0,0,c53b7a20,...) at __udivdi3+0x2e > cputick2usec(0,0,c0c980c6,2ef,c5db3764,...) at cputick2usec+0xfd > fill_kinfo_proc(c599e550,c53b7810,c0c980c6,3d8,4,...) at > fill_kinfo_proc+0x3ac > sysctl_out_proc(c5db36c0,c599e550,51c,c53b7b58,c08990d6,...) at > sysctl_out_proc+0xac > sysctl_kern_proc(c0d8cec0,c53b7c1c,1,c53b7ba4,c53b7ba4,...) at > sysctl_kern_proc+0xd2 > sysctl_root(c53b7ba4,0,c0c99ca0,5f1,c5db36c0,...) at sysctl_root+0x1c8 > userland_sysctl(c5db36c0,c53b7c10,4,0,bfbfe2b4,...) at > userland_sysctl+0x17c > __sysctl(c5db36c0,c53b7cf8,c0cd38ae,c0c7faf5,c5dea7f8,...) at __sysctl+0x94 > syscall(c53b7d38) at syscall+0x220 > Xint0x80_syscall() at Xint0x80_syscall+0x20 > --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x281a593b, esp = > 0xbfbfe1dc, ebp = 0xbfbfe208 --- > db> > > > Booting from the RELENG6 disk shows the nics to be > > em0@pci13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82573E Intel Corporation 82573E Gigabit Ethernet > Controller (Copper)' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint > em1@pci14:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82573L Intel PRO/1000 PL Network Adaptor' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint > > > > > > Cheers, >> >> Jack >> >> >> >> On Wed, Jan 27, 2010 at 11:29 AM, Mike Tancsa < >> mike@sentex.net> wrote: >> >> Not sure if the panic is related, but the watchdog timeout issue on bootup >> seems to be repeatable on this motherboard with HEAD from last Friday. It >> boots up fine under 6.x >> >> >> FreeBSD 9.0-CURRENT #1: Fri Jan 22 16:43:53 EST 2010 >> mdtancsa@ich10.sentex.ca:/usr/HEAD/obj/usr/HEAD/src/sys/alix i386 >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Pentium(R) CPU E6500 @ 2.93GHz (0.00-MHz 686-class >> CPU) >> Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 >> >> >> Features=0xbfebfbff >> >> >> Features2=0x400e3bd >> AMD Features=0x20100000 >> AMD Features2=0x1 >> TSC: P-state invariant >> real memory = 2147483648 (2048 MB) >> avail memory = 2089807872 (1992 MB) >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> FreeBSD/SMP: 1 package(s) x 2 core(s) >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> ioapic0 irqs 0-23 on motherboard >> ioapic1 irqs 24-47 on motherboard >> kbd1 at kbdmux0 >> cryptosoft0: on motherboard >> acpi0: on motherboard >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pcib1: irq 16 at device 1.0 on pci0 >> pci1: on pcib1 >> pcib2: irq 17 at device 28.0 on pci0 >> pci9: on pcib2 >> pcib3: at device 0.0 on pci9 >> pci10: on pcib3 >> pci10: at device 1.0 (no driver attached) >> pcib4: irq 17 at device 28.4 on pci0 >> pci13: on pcib4 >> em0: port 0x5000-0x501f mem >> 0xe1000000-0xe101ffff irq 16 at device 0.0 on pci13 >> em0: Using MSI interrupt >> em0: [FILTER] >> em0: Ethernet address: 00:30:48:8d:2a:96 >> pcib5: irq 16 at device 28.5 on pci0 >> pci14: on pcib5 >> em1: port 0x6000-0x601f mem >> 0xe1100000-0xe111ffff irq 17 at device 0.0 on pci14 >> em1: Using MSI interrupt >> em1: [FILTER] >> em1: Ethernet address: 00:30:48:8d:2a:97 >> uhci0: port 0x3000-0x301f irq >> 23 at device 29.0 on pci0 >> uhci0: [ITHREAD] >> usbus0: on uhci0 >> uhci1: port 0x3020-0x303f irq >> 19 at device 29.1 on pci0 >> uhci1: [ITHREAD] >> usbus1: on uhci1 >> uhci2: port 0x3040-0x305f irq >> 18 at device 29.2 on pci0 >> uhci2: [ITHREAD] >> usbus2: on uhci2 >> uhci3: port 0x3060-0x307f irq >> 16 at device 29.3 on pci0 >> uhci3: [ITHREAD] >> usbus3: on uhci3 >> ehci0: mem >> 0xe0000000-0xe00003ff irq 23 at device 29.7 on pci0 >> ehci0: [ITHREAD] >> usbus4: EHCI version 1.0 >> usbus4: on ehci0 >> pcib6: at device 30.0 on pci0 >> pci15: on pcib6 >> vgapci0: port 0x7000-0x70ff mem >> 0xe8000000-0xefffffff,0xe1200000-0xe120ffff irq 16 at device 0.0 on pci15 >> isab0: at device 31.0 on pci0 >> isa0: on isab0 >> atapci0: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 >> ata0: on atapci0 >> ata0: [ITHREAD] >> pci0: at device 31.3 (no driver attached) >> acpi_button0: on acpi0 >> atrtc0: port 0x70-0x71 irq 8 on acpi0 >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> atkbd0: [ITHREAD] >> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >> uart0: [FILTER] >> uart0: console (9600,n,8,1) >> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 >> uart1: [FILTER] >> cpu0: on acpi0 >> est0: on cpu0 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 6160b2506000616 >> device_attach: est0 attach returned 6 >> p4tcc0: on cpu0 >> cpu1: on acpi0 >> est1: on cpu1 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 6160b2506000616 >> device_attach: est1 attach returned 6 >> p4tcc1: on cpu1 >> pmtimer0 on isa0 >> orm0: at iomem >> 0xc0000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xcd000-0xcdfff pnpid >> ORM0000 on isa0 >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=0x300> >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >> Timecounters tick every 1.000 msec >> IPsec: Initialized Security Association Processing. >> usbus0: 12Mbps Full Speed USB v1.0 >> usbus1: 12Mbps Full Speed USB v1.0 >> usbus2: 12Mbps Full Speed USB v1.0 >> usbus3: 12Mbps Full Speed USB v1.0 >> usbus4: 480Mbps High Speed USB v2.0 >> SMP: AP CPU #1 Launched! >> ugen0.1: at usbus0 >> ugen1.1: at usbus1 >> uhub0: on usbus0 >> uhub1: on usbus1 >> Root mount waiting for: usbus4 usbus3 usbus2 usbus1 usbus0 >> ugen2.1: at usbus2 >> ugen3.1: at usbus3 >> uhub2: on usbus2 >> uhub3: on usbus3 >> ugen4.1: at usbus4 >> uhub4: on usbus4 >> uhub0: 2 ports with 2 removable, self powered >> uhub1: 2 ports with 2 removable, self powered >> uhub2: 2 ports with 2 removable, self powered >> uhub3: 2 ports with 2 removable, self powered >> Root mount waiting for: usbus4 >> Root mount waiting for: usbus4 >> Root mount waiting for: usbus4 >> uhub4: 8 ports with 8 removable, self powered >> Trying to mount root from nfs: >> NFS ROOT: 10.255.255.1:/usr/home/pxe9/ >> em0: Watchdog timeout -- resetting >> em0: link state changed to UP >> Interface em0 IP-Address 10.255.255.118 Broadcast 10.255.255.255 >> mount_nfs: can't update /var/db/mounttab for 10.255.255.1: >> /usr/home/pxe9//etc >> kernel trap 18 with interrupts disabled >> >> >> Fatal trap 18: integer divide fault while in kernel mode >> cpuid = 1; apic id = 01 >> instruction pointer = 0x20:0xc0995f0b >> stack pointer = 0x28:0xc4e746f8 >> frame pointer = 0x28:0xc4e7476c >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = resume, IOPL = 0 >> current process = 52 (ps) >> trap number = 18 >> panic: integer divide fault >> cpuid = 1 >> Uptime: 1m23s >> Cannot dump. Device not defined or unavailable. >> Automatic reboot in 15 seconds - press a key on the console to abort >> >> Fatal double fault: >> eip = 0xc098e8d0 >> esp = 0xc4d00000 >> ebp = 0xc4d00020 >> cpuid = 1; Rebooting... >> apic id = 01 >> cpu_reset: Stopping other CPUs >> panic: double fault >> cpuid = 1 >> Uptime: 1m23s >> Cannot dump. Device not defined or unavailable. >> Automatic reboot in 15 seconds - press a key on the console to abort >> Rebooting... >> cpu_reset: Stopping other CPUs >> >> >> -------------------------------------------------------------------- >> Mike Tancsa, tel +1 519 651 3400 >> Sentex Communications, mike@sentex.net >> Providing Internet since 1994 >> www.sentex.net >> Cambridge, Ontario Canada < >> http://www.sentex.net/mike>www.sentex.net/mike >> >> > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 22:17:03 2010 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 804F31065670 for ; Wed, 27 Jan 2010 22:17:03 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2EDFF8FC19 for ; Wed, 27 Jan 2010 22:17:03 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id o0RMH1VH053964; Wed, 27 Jan 2010 17:17:01 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <201001272217.o0RMH1VH053964@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 27 Jan 2010 17:17:09 -0500 To: Jack Vogel From: Mike Tancsa In-Reply-To: <2a41acea1001271406h7a61a72fv713e06ed2448b619@mail.gmail.co m> References: <201001271929.o0RJTVbB053140@lava.sentex.ca> <2a41acea1001271158p516ecedfge068edefff02ccbe@mail.gmail.com> <201001272201.o0RM1fQ9053896@lava.sentex.ca> <2a41acea1001271406h7a61a72fv713e06ed2448b619@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: new em problems on HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jan 2010 22:17:03 -0000 At 05:06 PM 1/27/2010, Jack Vogel wrote: >I have no idea, i see no evidence that its the em driver at fault, do you? Nope, I think its something else. But the watchdog issue is gone! I am also testing with the i3 board that had a couple of watchdog timeouts before and so far so good. It took about a day for it to show up before, so I will keep an eye on it. em0: port 0xf040-0xf05f mem 0xfe700000-0xfe71ffff,0xfe728000-0xfe728fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:27:0e:09:5e:00 ---Mike >Jack > > >On Wed, Jan 27, 2010 at 2:01 PM, Mike Tancsa ><mike@sentex.net> wrote: >At 02:58 PM 1/27/2010, Jack Vogel wrote: >Please try the driver as updated today and see if this still >happens, I sure hope not. > > >The watchdog error seems to be gone! but it still panics on the >netboot for some reason. I loaded up a GENERIC kernel as well. Not >sure if thats just a result of not being able to mount things or >some other problem ? > > >NFS ROOT: 10.255.255.1:/usr/home/pxe9/ >em0: link state changed to UP >Interface em0 IP-Address 10.255.255.118 Broadcast 10.255.255.255 >mount_nfs: can't update /var/db/mounttab for 10.255.255.1:/usr/home/pxe9//etc >lock order reversal: > 1st 0xd94ef2a0 bufwait (bufwait) @ /usr/HEAD/src/sys/kern/vfs_bio.c:2559 > 2nd 0xc59cc800 dirhash (dirhash) @ > /usr/HEAD/src/sys/ufs/ufs/ufs_dirhash.c:285 >KDB: stack backtrace: >db_trace_self_wrapper(c0c9c547,c53bf74c,c08d51c5,c08c5ddb,c0c9f4a3,...) >at db_trace_self_wrapper+0x26 >kdb_backtrace(c08c5ddb,c0c9f4a3,c552efc8,c5532840,c53bf7a8,...) at >kdb_backtrace+0x29 >_witness_debugger(c0c9f4a3,c59cc800,c0cc149a,c5532840,c0cc111a,...) >at _witness_debugger+0x25 >witness_checkorder(c59cc800,9,c0cc111a,11d,0,...) at witness_checkorder+0x839 >_sx_xlock(c59cc800,0,c0cc111a,11d,c5e55658,...) at _sx_xlock+0x85 >ufsdirhash_acquire(d94ef240,d991e800,200,d991e814,c53bf878,...) at >ufsdirhash_acquire+0x35 >ufsdirhash_add(c5e55658,c53bf8d0,814,c53bf864,c53bf868,...) at >ufsdirhash_add+0x13 >ufs_direnter(c5e6a660,c5eb9550,c53bf8d0,c53bfbd0,0,...) at ufs_direnter+0x729 >ufs_makeinode(c53bfbd0,0,c53bfabc,c53bfa18,c0bdf755,...) at >ufs_makeinode+0x50d >ufs_create(c53bfabc,c53bfad4,0,0,c53bfba4,...) at ufs_create+0x30 >VOP_CREATE_APV(c0da6540,c53bfabc,c53bfbd0,c53bfa54,0,...) at >VOP_CREATE_APV+0xa5 >vn_open_cred(c53bfba4,c53bfc5c,16d,0,c556ec00,...) at vn_open_cred+0x215 >vn_open(c53bfba4,c53bfc5c,16d,c5dada10,c0d96aa0,...) at vn_open+0x3b >kern_openat(c5db3240,ffffff9c,804c5e8,0,602,...) at kern_openat+0x11f >kern_open(c5db3240,804c5e8,0,601,816d,...) at kern_open+0x35 >open(c5db3240,c53bfcf8,c0cd38ae,c0c7faf5,c5dea2a8,...) at open+0x30 >syscall(c53bfd38) at syscall+0x220 >Xint0x80_syscall() at Xint0x80_syscall+0x20 >--- syscall (5, FreeBSD ELF32, open), eip = 0x2816ead3, esp = >0xbfbfec6c, ebp = 0xbfbfecd8 --- > >kernel trap 18 with interrupts disabled > > >Fatal trap 18: integer divide fault while in kernel mode >cpuid = 0; apic id = 00 >instruction pointer = 0x20:0xc0bd216b >stack pointer = 0x28:0xc53b7704 >frame pointer = 0x28:0xc53b7778 > >code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 >processor eflags = resume, IOPL = 0 >current process = 48 (ps) >[thread pid 48 tid 100078 ] >Stopped at __qdivrem+0x3b: divl %ecx,%eax >db> bt >Tracing pid 48 tid 100078 td 0xc5db36c0 >__qdivrem(0,0,0,0,0,...) at __qdivrem+0x3b >__udivdi3(0,0,0,0,c53b7a20,...) at __udivdi3+0x2e >cputick2usec(0,0,c0c980c6,2ef,c5db3764,...) at cputick2usec+0xfd >fill_kinfo_proc(c599e550,c53b7810,c0c980c6,3d8,4,...) at fill_kinfo_proc+0x3ac >sysctl_out_proc(c5db36c0,c599e550,51c,c53b7b58,c08990d6,...) at >sysctl_out_proc+0xac >sysctl_kern_proc(c0d8cec0,c53b7c1c,1,c53b7ba4,c53b7ba4,...) at >sysctl_kern_proc+0xd2 >sysctl_root(c53b7ba4,0,c0c99ca0,5f1,c5db36c0,...) at sysctl_root+0x1c8 >userland_sysctl(c5db36c0,c53b7c10,4,0,bfbfe2b4,...) at userland_sysctl+0x17c >__sysctl(c5db36c0,c53b7cf8,c0cd38ae,c0c7faf5,c5dea7f8,...) at __sysctl+0x94 >syscall(c53b7d38) at syscall+0x220 >Xint0x80_syscall() at Xint0x80_syscall+0x20 >--- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x281a593b, esp = >0xbfbfe1dc, ebp = 0xbfbfe208 --- >db> > > >Booting from the RELENG6 disk shows the nics to be > >em0@pci13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 >rev=0x03 hdr=0x00 > vendor = 'Intel Corporation' > device = '82573E Intel Corporation 82573E Gigabit Ethernet > Controller (Copper)' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint >em1@pci14:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 >rev=0x00 hdr=0x00 > vendor = 'Intel Corporation' > device = '82573L Intel PRO/1000 PL Network Adaptor' > class = network > subclass = ethernet > cap 01[c8] = powerspec 2 supports D0 D3 current D0 > cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message > cap 10[e0] = PCI-Express 1 endpoint > > > > > >Cheers, > >Jack > > > >On Wed, Jan 27, 2010 at 11:29 AM, Mike Tancsa ><mike@sentex.net> wrote: > >Not sure if the panic is related, but the watchdog timeout issue on >bootup seems to be repeatable on this motherboard with HEAD from >last Friday. It boots up fine under 6.x > > >FreeBSD 9.0-CURRENT #1: Fri Jan 22 16:43:53 EST 2010 > mdtancsa@ich10.sentex.ca:/usr/HEAD/obj/usr/HEAD/src/sys/alix i386 >Timecounter "i8254" frequency 1193182 Hz quality 0 >CPU: Intel(R) Pentium(R) CPU E6500 @ 2.93GHz (0.00-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 > >Features=0xbfebfbff > >Features2=0x400e3bd > AMD Features=0x20100000 > AMD Features2=0x1 > TSC: P-state invariant >real memory = 2147483648 (2048 MB) >avail memory = 2089807872 (1992 MB) >ACPI APIC Table: >FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >FreeBSD/SMP: 1 package(s) x 2 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 1 >ioapic0 irqs 0-23 on motherboard >ioapic1 irqs 24-47 on motherboard >kbd1 at kbdmux0 >cryptosoft0: on motherboard >acpi0: on motherboard >acpi0: [ITHREAD] >acpi0: Power Button (fixed) >Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 >pcib0: port 0xcf8-0xcff on acpi0 >pci0: on pcib0 >pcib1: irq 16 at device 1.0 on pci0 >pci1: on pcib1 >pcib2: irq 17 at device 28.0 on pci0 >pci9: on pcib2 >pcib3: at device 0.0 on pci9 >pci10: on pcib3 >pci10: at device 1.0 (no driver attached) >pcib4: irq 17 at device 28.4 on pci0 >pci13: on pcib4 >em0: port >0x5000-0x501f mem 0xe1000000-0xe101ffff irq 16 at device 0.0 on pci13 >em0: Using MSI interrupt >em0: [FILTER] >em0: Ethernet address: 00:30:48:8d:2a:96 >pcib5: irq 16 at device 28.5 on pci0 >pci14: on pcib5 >em1: port >0x6000-0x601f mem 0xe1100000-0xe111ffff irq 17 at device 0.0 on pci14 >em1: Using MSI interrupt >em1: [FILTER] >em1: Ethernet address: 00:30:48:8d:2a:97 >uhci0: port 0x3000-0x301f >irq 23 at device 29.0 on pci0 >uhci0: [ITHREAD] >usbus0: on uhci0 >uhci1: port 0x3020-0x303f >irq 19 at device 29.1 on pci0 >uhci1: [ITHREAD] >usbus1: on uhci1 >uhci2: port 0x3040-0x305f >irq 18 at device 29.2 on pci0 >uhci2: [ITHREAD] >usbus2: on uhci2 >uhci3: port 0x3060-0x307f >irq 16 at device 29.3 on pci0 >uhci3: [ITHREAD] >usbus3: on uhci3 >ehci0: mem >0xe0000000-0xe00003ff irq 23 at device 29.7 on pci0 >ehci0: [ITHREAD] >usbus4: EHCI version 1.0 >usbus4: on ehci0 >pcib6: at device 30.0 on pci0 >pci15: on pcib6 >vgapci0: port 0x7000-0x70ff mem >0xe8000000-0xefffffff,0xe1200000-0xe120ffff irq 16 at device 0.0 on pci15 >isab0: at device 31.0 on pci0 >isa0: on isab0 >atapci0: port >0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 >ata0: on atapci0 >ata0: [ITHREAD] >pci0: at device 31.3 (no driver attached) >acpi_button0: on acpi0 >atrtc0: port 0x70-0x71 irq 8 on acpi0 >atkbdc0: port 0x60,0x64 irq 1 on acpi0 >atkbd0: irq 1 on atkbdc0 >kbd0 at atkbd0 >atkbd0: [GIANT-LOCKED] >atkbd0: [ITHREAD] >uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >uart0: [FILTER] >uart0: console (9600,n,8,1) >uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 >uart1: [FILTER] >cpu0: on acpi0 >est0: on cpu0 >est: CPU supports Enhanced Speedstep, but is not recognized. >est: cpu_vendor GenuineIntel, msr 6160b2506000616 >device_attach: est0 attach returned 6 >p4tcc0: on cpu0 >cpu1: on acpi0 >est1: on cpu1 >est: CPU supports Enhanced Speedstep, but is not recognized. >est: cpu_vendor GenuineIntel, msr 6160b2506000616 >device_attach: est1 attach returned 6 >p4tcc1: on cpu1 >pmtimer0 on isa0 >orm0: at iomem >0xc0000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xcd000-0xcdfff >pnpid ORM0000 on isa0 >sc0: at flags 0x100 on isa0 >sc0: VGA <16 virtual consoles, flags=0x300> >vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >Timecounters tick every 1.000 msec >IPsec: Initialized Security Association Processing. >usbus0: 12Mbps Full Speed USB v1.0 >usbus1: 12Mbps Full Speed USB v1.0 >usbus2: 12Mbps Full Speed USB v1.0 >usbus3: 12Mbps Full Speed USB v1.0 >usbus4: 480Mbps High Speed USB v2.0 >SMP: AP CPU #1 Launched! >ugen0.1: at usbus0 >ugen1.1: at usbus1 >uhub0: on usbus0 >uhub1: on usbus1 >Root mount waiting for: usbus4 usbus3 usbus2 usbus1 usbus0 >ugen2.1: at usbus2 >ugen3.1: at usbus3 >uhub2: on usbus2 >uhub3: on usbus3 >ugen4.1: at usbus4 >uhub4: on usbus4 >uhub0: 2 ports with 2 removable, self powered >uhub1: 2 ports with 2 removable, self powered >uhub2: 2 ports with 2 removable, self powered >uhub3: 2 ports with 2 removable, self powered >Root mount waiting for: usbus4 >Root mount waiting for: usbus4 >Root mount waiting for: usbus4 >uhub4: 8 ports with 8 removable, self powered >Trying to mount root from nfs: >NFS ROOT: 10.255.255.1:/usr/home/pxe9/ >em0: Watchdog timeout -- resetting >em0: link state changed to UP >Interface em0 IP-Address 10.255.255.118 Broadcast 10.255.255.255 >mount_nfs: can't update /var/db/mounttab for 10.255.255.1:/usr/home/pxe9//etc >kernel trap 18 with interrupts disabled > > >Fatal trap 18: integer divide fault while in kernel mode >cpuid = 1; apic id = 01 >instruction pointer = 0x20:0xc0995f0b >stack pointer = 0x28:0xc4e746f8 >frame pointer = 0x28:0xc4e7476c >code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 >processor eflags = resume, IOPL = 0 >current process = 52 (ps) >trap number = 18 >panic: integer divide fault >cpuid = 1 >Uptime: 1m23s >Cannot dump. Device not defined or unavailable. >Automatic reboot in 15 seconds - press a key on the console to abort > >Fatal double fault: >eip = 0xc098e8d0 >esp = 0xc4d00000 >ebp = 0xc4d00020 >cpuid = 1; Rebooting... >apic id = 01 >cpu_reset: Stopping other CPUs >panic: double fault >cpuid = 1 >Uptime: 1m23s >Cannot dump. Device not defined or unavailable. >Automatic reboot in 15 seconds - press a key on the console to abort >Rebooting... >cpu_reset: Stopping other CPUs > > >-------------------------------------------------------------------- >Mike Tancsa, tel +1 519 651 3400 >Sentex Communications, >mike@sentex.net >Providing Internet since >1994 ><http://www.sentex.net>www.sentex.net >Cambridge, Ontario >Canada ><http://www.sentex.net/mike>www.sentex.net/mike > > >-------------------------------------------------------------------- >Mike Tancsa, tel +1 519 651 3400 >Sentex >Communications, >mike@sentex.net >Providing Internet since >1994 www.sentex.net >Cambridge, Ontario >Canada www.sentex.net/mike > -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Wed Jan 27 22:20:42 2010 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 5EABD1065748 for ; Wed, 27 Jan 2010 22:20:42 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 957DE8FC0A for ; Wed, 27 Jan 2010 22:20:41 +0000 (UTC) Received: by fxm26 with SMTP id 26so61767fxm.13 for ; Wed, 27 Jan 2010 14:20:40 -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; bh=2vJ5dDWkZNgdtGpF/4qiw4tDSXQDXTBkaEqJBmboJo4=; b=rVmi9UGt9K7wS1pNF0kZX08+WfAQ72FbXOLcQE4sNrYlJfHliV+LGxbaR4d9zYDRHo oJ7og1hMZLbCAUhcJOMFV3blvG45AlBaJuS5dSw+gv7XQbvD2AS5bo4OH1tfOzPnplBs YlE3WTJTOwwCOj7ow0VzXKodmID3QacxLkv0Y= 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; b=Rd07eTlIt7qtEMuPoH1ex/O6haUpVBDlxIGKD9qXtavGh7V2BojRn5j7PhmMopD+Nk 9czmISOUY7I3YMgDNcdf+PmVSOqPMSDSQ/avo5qwM5W8McZmvRtqZxXmKLo2exb0QWFo kWL8g7B5XhunPDI7MoNXIpyWTMeic73Xqo4Xs= MIME-Version: 1.0 Received: by 10.216.86.14 with SMTP id v14mr1930989wee.183.1264630840173; Wed, 27 Jan 2010 14:20:40 -0800 (PST) In-Reply-To: <201001272217.o0RMH1VH053964@lava.sentex.ca> References: <201001271929.o0RJTVbB053140@lava.sentex.ca> <2a41acea1001271158p516ecedfge068edefff02ccbe@mail.gmail.com> <201001272201.o0RM1fQ9053896@lava.sentex.ca> <2a41acea1001271406h7a61a72fv713e06ed2448b619@mail.gmail.com> <201001272217.o0RMH1VH053964@lava.sentex.ca> Date: Wed, 27 Jan 2010 14:20:40 -0800 Message-ID: <2a41acea1001271420l4a1bd008xab181201ac77985c@mail.gmail.com> From: Jack Vogel To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: new em problems on HEAD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Jan 2010 22:20:42 -0000 Ahh, i3, so that's the new pch interface, you're one of the first I've heard of using it, let me know how it goes, should be fine. Jack On Wed, Jan 27, 2010 at 2:17 PM, Mike Tancsa wrote: > At 05:06 PM 1/27/2010, Jack Vogel wrote: > >> I have no idea, i see no evidence that its the em driver at fault, do you? >> > > Nope, I think its something else. But the watchdog issue is gone! I am > also testing with the i3 board that had a couple of watchdog timeouts before > and so far so good. It took about a day for it to show up before, so I will > keep an eye on it. > > > em0: port 0xf040-0xf05f mem > 0xfe700000-0xfe71ffff,0xfe728000-0xfe728fff irq 20 at device 25.0 on pci0 > > em0: Using MSI interrupt > em0: [FILTER] > em0: Ethernet address: 00:27:0e:09:5e:00 > > > > ---Mike > > Jack >> >> >> >> On Wed, Jan 27, 2010 at 2:01 PM, Mike Tancsa < >> mike@sentex.net> wrote: >> At 02:58 PM 1/27/2010, Jack Vogel wrote: >> Please try the driver as updated today and see if this still happens, I >> sure hope not. >> >> >> The watchdog error seems to be gone! but it still panics on the netboot >> for some reason. I loaded up a GENERIC kernel as well. Not sure if thats >> just a result of not being able to mount things or some other problem ? >> >> >> NFS ROOT: 10.255.255.1:/usr/home/pxe9/ >> em0: link state changed to UP >> Interface em0 IP-Address 10.255.255.118 Broadcast 10.255.255.255 >> mount_nfs: can't update /var/db/mounttab for 10.255.255.1: >> /usr/home/pxe9//etc >> lock order reversal: >> 1st 0xd94ef2a0 bufwait (bufwait) @ /usr/HEAD/src/sys/kern/vfs_bio.c:2559 >> 2nd 0xc59cc800 dirhash (dirhash) @ >> /usr/HEAD/src/sys/ufs/ufs/ufs_dirhash.c:285 >> KDB: stack backtrace: >> db_trace_self_wrapper(c0c9c547,c53bf74c,c08d51c5,c08c5ddb,c0c9f4a3,...) at >> db_trace_self_wrapper+0x26 >> kdb_backtrace(c08c5ddb,c0c9f4a3,c552efc8,c5532840,c53bf7a8,...) at >> kdb_backtrace+0x29 >> _witness_debugger(c0c9f4a3,c59cc800,c0cc149a,c5532840,c0cc111a,...) at >> _witness_debugger+0x25 >> witness_checkorder(c59cc800,9,c0cc111a,11d,0,...) at >> witness_checkorder+0x839 >> _sx_xlock(c59cc800,0,c0cc111a,11d,c5e55658,...) at _sx_xlock+0x85 >> ufsdirhash_acquire(d94ef240,d991e800,200,d991e814,c53bf878,...) at >> ufsdirhash_acquire+0x35 >> ufsdirhash_add(c5e55658,c53bf8d0,814,c53bf864,c53bf868,...) at >> ufsdirhash_add+0x13 >> ufs_direnter(c5e6a660,c5eb9550,c53bf8d0,c53bfbd0,0,...) at >> ufs_direnter+0x729 >> ufs_makeinode(c53bfbd0,0,c53bfabc,c53bfa18,c0bdf755,...) at >> ufs_makeinode+0x50d >> ufs_create(c53bfabc,c53bfad4,0,0,c53bfba4,...) at ufs_create+0x30 >> VOP_CREATE_APV(c0da6540,c53bfabc,c53bfbd0,c53bfa54,0,...) at >> VOP_CREATE_APV+0xa5 >> vn_open_cred(c53bfba4,c53bfc5c,16d,0,c556ec00,...) at vn_open_cred+0x215 >> vn_open(c53bfba4,c53bfc5c,16d,c5dada10,c0d96aa0,...) at vn_open+0x3b >> kern_openat(c5db3240,ffffff9c,804c5e8,0,602,...) at kern_openat+0x11f >> kern_open(c5db3240,804c5e8,0,601,816d,...) at kern_open+0x35 >> open(c5db3240,c53bfcf8,c0cd38ae,c0c7faf5,c5dea2a8,...) at open+0x30 >> syscall(c53bfd38) at syscall+0x220 >> Xint0x80_syscall() at Xint0x80_syscall+0x20 >> --- syscall (5, FreeBSD ELF32, open), eip = 0x2816ead3, esp = 0xbfbfec6c, >> ebp = 0xbfbfecd8 --- >> >> kernel trap 18 with interrupts disabled >> >> >> Fatal trap 18: integer divide fault while in kernel mode >> cpuid = 0; apic id = 00 >> instruction pointer = 0x20:0xc0bd216b >> stack pointer = 0x28:0xc53b7704 >> frame pointer = 0x28:0xc53b7778 >> >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = resume, IOPL = 0 >> current process = 48 (ps) >> [thread pid 48 tid 100078 ] >> Stopped at __qdivrem+0x3b: divl %ecx,%eax >> db> bt >> Tracing pid 48 tid 100078 td 0xc5db36c0 >> __qdivrem(0,0,0,0,0,...) at __qdivrem+0x3b >> __udivdi3(0,0,0,0,c53b7a20,...) at __udivdi3+0x2e >> cputick2usec(0,0,c0c980c6,2ef,c5db3764,...) at cputick2usec+0xfd >> fill_kinfo_proc(c599e550,c53b7810,c0c980c6,3d8,4,...) at >> fill_kinfo_proc+0x3ac >> sysctl_out_proc(c5db36c0,c599e550,51c,c53b7b58,c08990d6,...) at >> sysctl_out_proc+0xac >> sysctl_kern_proc(c0d8cec0,c53b7c1c,1,c53b7ba4,c53b7ba4,...) at >> sysctl_kern_proc+0xd2 >> sysctl_root(c53b7ba4,0,c0c99ca0,5f1,c5db36c0,...) at sysctl_root+0x1c8 >> userland_sysctl(c5db36c0,c53b7c10,4,0,bfbfe2b4,...) at >> userland_sysctl+0x17c >> __sysctl(c5db36c0,c53b7cf8,c0cd38ae,c0c7faf5,c5dea7f8,...) at >> __sysctl+0x94 >> syscall(c53b7d38) at syscall+0x220 >> Xint0x80_syscall() at Xint0x80_syscall+0x20 >> --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x281a593b, esp = >> 0xbfbfe1dc, ebp = 0xbfbfe208 --- >> db> >> >> >> Booting from the RELENG6 disk shows the nics to be >> >> em0@pci13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086 rev=0x03 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82573E Intel Corporation 82573E Gigabit Ethernet >> Controller (Copper)' >> class = network >> subclass = ethernet >> cap 01[c8] = powerspec 2 supports D0 D3 current D0 >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message >> cap 10[e0] = PCI-Express 1 endpoint >> em1@pci14:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086 rev=0x00 >> hdr=0x00 >> vendor = 'Intel Corporation' >> device = '82573L Intel PRO/1000 PL Network Adaptor' >> class = network >> subclass = ethernet >> cap 01[c8] = powerspec 2 supports D0 D3 current D0 >> cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message >> cap 10[e0] = PCI-Express 1 endpoint >> >> >> >> >> >> Cheers, >> >> Jack >> >> >> >> On Wed, Jan 27, 2010 at 11:29 AM, Mike Tancsa <> >mike@sentex.net> wrote: >> >> Not sure if the panic is related, but the watchdog timeout issue on bootup >> seems to be repeatable on this motherboard with HEAD from last Friday. It >> boots up fine under 6.x >> >> >> FreeBSD 9.0-CURRENT #1: Fri Jan 22 16:43:53 EST 2010 >> mdtancsa@ich10.sentex.ca:/usr/HEAD/obj/usr/HEAD/src/sys/alix i386 >> Timecounter "i8254" frequency 1193182 Hz quality 0 >> CPU: Intel(R) Pentium(R) CPU E6500 @ 2.93GHz (0.00-MHz 686-class >> CPU) >> Origin = "GenuineIntel" Id = 0x1067a Stepping = 10 >> >> >> Features=0xbfebfbff >> >> >> Features2=0x400e3bd >> AMD Features=0x20100000 >> AMD Features2=0x1 >> TSC: P-state invariant >> real memory = 2147483648 (2048 MB) >> avail memory = 2089807872 (1992 MB) >> ACPI APIC Table: >> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs >> FreeBSD/SMP: 1 package(s) x 2 core(s) >> cpu0 (BSP): APIC ID: 0 >> cpu1 (AP): APIC ID: 1 >> ioapic0 irqs 0-23 on motherboard >> ioapic1 irqs 24-47 on motherboard >> kbd1 at kbdmux0 >> cryptosoft0: on motherboard >> acpi0: on motherboard >> acpi0: [ITHREAD] >> acpi0: Power Button (fixed) >> Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 >> acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 >> pcib0: port 0xcf8-0xcff on acpi0 >> pci0: on pcib0 >> pcib1: irq 16 at device 1.0 on pci0 >> pci1: on pcib1 >> pcib2: irq 17 at device 28.0 on pci0 >> pci9: on pcib2 >> pcib3: at device 0.0 on pci9 >> pci10: on pcib3 >> pci10: at device 1.0 (no driver attached) >> pcib4: irq 17 at device 28.4 on pci0 >> pci13: on pcib4 >> em0: port 0x5000-0x501f mem >> 0xe1000000-0xe101ffff irq 16 at device 0.0 on pci13 >> em0: Using MSI interrupt >> em0: [FILTER] >> em0: Ethernet address: 00:30:48:8d:2a:96 >> pcib5: irq 16 at device 28.5 on pci0 >> pci14: on pcib5 >> em1: port 0x6000-0x601f mem >> 0xe1100000-0xe111ffff irq 17 at device 0.0 on pci14 >> em1: Using MSI interrupt >> em1: [FILTER] >> em1: Ethernet address: 00:30:48:8d:2a:97 >> uhci0: port 0x3000-0x301f irq >> 23 at device 29.0 on pci0 >> uhci0: [ITHREAD] >> usbus0: on uhci0 >> uhci1: port 0x3020-0x303f irq >> 19 at device 29.1 on pci0 >> uhci1: [ITHREAD] >> usbus1: on uhci1 >> uhci2: port 0x3040-0x305f irq >> 18 at device 29.2 on pci0 >> uhci2: [ITHREAD] >> usbus2: on uhci2 >> uhci3: port 0x3060-0x307f irq >> 16 at device 29.3 on pci0 >> uhci3: [ITHREAD] >> usbus3: on uhci3 >> ehci0: mem >> 0xe0000000-0xe00003ff irq 23 at device 29.7 on pci0 >> ehci0: [ITHREAD] >> usbus4: EHCI version 1.0 >> usbus4: on ehci0 >> pcib6: at device 30.0 on pci0 >> pci15: on pcib6 >> vgapci0: port 0x7000-0x70ff mem >> 0xe8000000-0xefffffff,0xe1200000-0xe120ffff irq 16 at device 0.0 on pci15 >> isab0: at device 31.0 on pci0 >> isa0: on isab0 >> atapci0: port >> 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x30a0-0x30af at device 31.1 on pci0 >> ata0: on atapci0 >> ata0: [ITHREAD] >> pci0: at device 31.3 (no driver attached) >> acpi_button0: on acpi0 >> atrtc0: port 0x70-0x71 irq 8 on acpi0 >> atkbdc0: port 0x60,0x64 irq 1 on acpi0 >> atkbd0: irq 1 on atkbdc0 >> kbd0 at atkbd0 >> atkbd0: [GIANT-LOCKED] >> atkbd0: [ITHREAD] >> uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 >> uart0: [FILTER] >> uart0: console (9600,n,8,1) >> uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 >> uart1: [FILTER] >> cpu0: on acpi0 >> est0: on cpu0 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 6160b2506000616 >> device_attach: est0 attach returned 6 >> p4tcc0: on cpu0 >> cpu1: on acpi0 >> est1: on cpu1 >> est: CPU supports Enhanced Speedstep, but is not recognized. >> est: cpu_vendor GenuineIntel, msr 6160b2506000616 >> device_attach: est1 attach returned 6 >> p4tcc1: on cpu1 >> pmtimer0 on isa0 >> orm0: at iomem >> 0xc0000-0xcafff,0xcb000-0xcbfff,0xcc000-0xccfff,0xcd000-0xcdfff pnpid >> ORM0000 on isa0 >> sc0: at flags 0x100 on isa0 >> sc0: VGA <16 virtual consoles, flags=0x300> >> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >> Timecounters tick every 1.000 msec >> IPsec: Initialized Security Association Processing. >> usbus0: 12Mbps Full Speed USB v1.0 >> usbus1: 12Mbps Full Speed USB v1.0 >> usbus2: 12Mbps Full Speed USB v1.0 >> usbus3: 12Mbps Full Speed USB v1.0 >> usbus4: 480Mbps High Speed USB v2.0 >> SMP: AP CPU #1 Launched! >> ugen0.1: at usbus0 >> ugen1.1: at usbus1 >> uhub0: on usbus0 >> uhub1: on usbus1 >> Root mount waiting for: usbus4 usbus3 usbus2 usbus1 usbus0 >> ugen2.1: at usbus2 >> ugen3.1: at usbus3 >> uhub2: on usbus2 >> uhub3: on usbus3 >> ugen4.1: at usbus4 >> uhub4: on usbus4 >> uhub0: 2 ports with 2 removable, self powered >> uhub1: 2 ports with 2 removable, self powered >> uhub2: 2 ports with 2 removable, self powered >> uhub3: 2 ports with 2 removable, self powered >> Root mount waiting for: usbus4 >> Root mount waiting for: usbus4 >> Root mount waiting for: usbus4 >> uhub4: 8 ports with 8 removable, self powered >> Trying to mount root from nfs: >> NFS ROOT: 10.255.255.1:/usr/home/pxe9/ >> em0: Watchdog timeout -- resetting >> em0: link state changed to UP >> Interface em0 IP-Address 10.255.255.118 Broadcast 10.255.255.255 >> mount_nfs: can't update /var/db/mounttab for 10.255.255.1: >> /usr/home/pxe9//etc >> kernel trap 18 with interrupts disabled >> >> >> Fatal trap 18: integer divide fault while in kernel mode >> cpuid = 1; apic id = 01 >> instruction pointer = 0x20:0xc0995f0b >> stack pointer = 0x28:0xc4e746f8 >> frame pointer = 0x28:0xc4e7476c >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = resume, IOPL = 0 >> current process = 52 (ps) >> trap number = 18 >> panic: integer divide fault >> cpuid = 1 >> Uptime: 1m23s >> Cannot dump. Device not defined or unavailable. >> Automatic reboot in 15 seconds - press a key on the console to abort >> >> Fatal double fault: >> eip = 0xc098e8d0 >> esp = 0xc4d00000 >> ebp = 0xc4d00020 >> cpuid = 1; Rebooting... >> apic id = 01 >> cpu_reset: Stopping other CPUs >> panic: double fault >> cpuid = 1 >> Uptime: 1m23s >> Cannot dump. Device not defined or unavailable. >> Automatic reboot in 15 seconds - press a key on the console to abort >> Rebooting... >> cpu_reset: Stopping other CPUs >> >> >> -------------------------------------------------------------------- >> Mike Tancsa, tel +1 519 651 3400 >> Sentex Communications, >> mike@sentex.net >> Providing Internet since 1994 < >> http://www.sentex.net>www.sentex.net >> Cambridge, Ontario Canada < >> http://www.sentex.net/mike>www.sentex.net/mike >> >> >> >> -------------------------------------------------------------------- >> Mike Tancsa, tel +1 519 651 3400 >> Sentex Communications, mike@sentex.net >> Providing Internet since 1994 >> www.sentex.net >> Cambridge, Ontario Canada < >> http://www.sentex.net/mike>www.sentex.net/mike >> >> > -------------------------------------------------------------------- > Mike Tancsa, tel +1 519 651 3400 > Sentex Communications, mike@sentex.net > Providing Internet since 1994 www.sentex.net > Cambridge, Ontario Canada www.sentex.net/mike > > From owner-freebsd-current@FreeBSD.ORG Thu Jan 28 03:23:46 2010 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 88424106568B for ; Thu, 28 Jan 2010 03:23:46 +0000 (UTC) (envelope-from wilkinsa@dsto.defence.gov.au) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.freebsd.org (Postfix) with ESMTP id 986688FC12 for ; Thu, 28 Jan 2010 03:23:45 +0000 (UTC) Received: from ednmsw520.dsto.defence.gov.au (ednmsw520.dsto.defence.gov.au [131.185.68.60]) by digger1.defence.gov.au (DSTO/DSTO) with ESMTP id o0S3KvnS020335 for ; Thu, 28 Jan 2010 13:50:57 +1030 (CST) Received: from fmbex510.dsto.defence.gov.au (fmbex510.dsto.defence.gov.au) by ednmsw520.dsto.defence.gov.au (Clearswift SMTPRS 5.3.2) with ESMTP id for ; Thu, 28 Jan 2010 13:51:23 +1030 Received: from stlex511.dsto.defence.gov.au ([203.6.60.49]) by fmbex510.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 14:21:22 +1100 Received: from stlux550.dsto.defence.gov.au ([203.6.60.61]) by stlex511.dsto.defence.gov.au with Microsoft SMTPSVC(6.0.3790.3959); Thu, 28 Jan 2010 09:57:57 +0800 Received: from stlux550.dsto.defence.gov.au (localhost [127.0.0.1]) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3) with ESMTP id o0S1jvIn049683 for ; Thu, 28 Jan 2010 09:45:57 +0800 (WST) (envelope-from wilkinsa@stlux550.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by stlux550.dsto.defence.gov.au (8.14.3/8.14.3/Submit) id o0S1jvEi049682 for freebsd-current@freebsd.org; Thu, 28 Jan 2010 09:45:57 +0800 (WST) (envelope-from wilkinsa) Date: Thu, 28 Jan 2010 09:45:57 +0800 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20100128014557.GA44494@stlux503.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: Organisation: Defence Science Technology Organisation X-Message-Flag: "Please Restore Line Breaks If Necessary" User-Agent: Mutt/1.5.20 (2009-06-14) X-OriginalArrivalTime: 28 Jan 2010 01:57:57.0849 (UTC) FILETIME=[504F4C90:01CA9FBD] X-TM-AS-Product-Ver: SMEX-8.0.0.1285-6.000.1038-17158.004 X-TM-AS-Result: No--5.813800-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Content-Transfer-Encoding: 7bit Subject: Re: SUJ testing update [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jan 2010 03:23:46 -0000 0n Mon, Jan 25, 2010 at 01:38:41PM -1000, Jeff Roberson wrote: >I just committed some big changes to suj to svn at >svn://svn.freebsd.org/base/projects/suj/head > >You can now run softdep without journaling again. The fast journal >checker is enabled. You need only use tunefs -j enable or tunefs -j >disable. > >The SUJ flag in the filesystem moved for backwards compat reasons. If you >have an earlier SUJ volume please disable it with the old tunefs and >enable again with the new tunefs. Hi Jeff, All looks good. I did notice two small things: 1. Your new code no longer outputs "soft-updates, journal" from mount(8) e.g. old code: /dev/ad8s3d on /export (ufs, NFS exported, local, soft-updates, journal) new code: /dev/ad8s3d on /export (ufs, NFS exported, local, soft-updates) If you are not planning to keep the "journal" label in the output of mount(8) is there any other mechanism to verify that a fs has actually got SUj switched on ? (this seems to work actually: #dumpfs /dev/ad8s3d | grep -i journal). 2. dmesg(8) displays this upon bootstrap: WARNING: /export: GJOURNAL flag on fs but no gjournal provider below I have done at least 4 ALT_BREAK_TO_DEBUGGERs' (~^B) -> reset ... no probs whatsoever. Thanks! -Alex IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. From owner-freebsd-current@FreeBSD.ORG Thu Jan 28 09:09:37 2010 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 DBFAF106566B for ; Thu, 28 Jan 2010 09:09:37 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id F30648FC21 for ; Thu, 28 Jan 2010 09:09:36 +0000 (UTC) Received: from elsa.codelab.cz (localhost.codelab.cz [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id A6C3E19E023; Thu, 28 Jan 2010 10:09:34 +0100 (CET) Received: from [192.168.1.2] (r5bb235.net.upc.cz [86.49.61.235]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id 8766119E019; Thu, 28 Jan 2010 10:09:32 +0100 (CET) Message-ID: <4B61544C.8080109@quip.cz> Date: Thu, 28 Jan 2010 10:09:32 +0100 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.7) Gecko/20100104 SeaMonkey/2.0.2 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20100128014557.GA44494@stlux503.dsto.defence.gov.au> In-Reply-To: <20100128014557.GA44494@stlux503.dsto.defence.gov.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alex.wilkinson@dsto.defence.gov.au Subject: Re: SUJ testing update [SEC=UNCLASSIFIED] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jan 2010 09:09:37 -0000 Wilkinson, Alex wrote: [...] > All looks good. I did notice two small things: > > 1. Your new code no longer outputs "soft-updates, journal" from mount(8) e.g. > > old code: /dev/ad8s3d on /export (ufs, NFS exported, local, soft-updates, journal) > new code: /dev/ad8s3d on /export (ufs, NFS exported, local, soft-updates) > > If you are not planning to keep the "journal" label in the output of mount(8) is > there any other mechanism to verify that a fs has actually got SUj switched on ? > (this seems to work actually: #dumpfs /dev/ad8s3d | grep -i journal). I did not tested the SUJ, but it should be possible with "tunefs -p" > 2. dmesg(8) displays this upon bootstrap: > > WARNING: /export: GJOURNAL flag on fs but no gjournal provider below Had you gjournal on this partition before? You can drop the flag by tunefs -J disable /dev/ad8s3d Miroslav Lachman From owner-freebsd-current@FreeBSD.ORG Thu Jan 28 12:44:10 2010 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 BCD041065672 for ; Thu, 28 Jan 2010 12:44:10 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 4FF8D8FC1B for ; Thu, 28 Jan 2010 12:44:09 +0000 (UTC) Received: by fxm27 with SMTP id 27so132312fxm.3 for ; Thu, 28 Jan 2010 04:44: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=sWj2brLXatRuCw7fQQY1B5Hw8/NT16UDtv2LMFfs4LI=; b=jdHYFL1VLfq0ImJ2xoqlvlmRlZS0LZZZlqjeIlmnhk0JD8+kWl/Rhlyo4BshAK515s U5ogxTipwhS03mCxUtOpKywHgzoSA7VrQfZWbglrVWc8+9bsm0t7qN2AxKo3PORsuYCR 3bxNS8JtpARr5Dcx/DKcYl424qoTmUhMZJfek= 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=tQsk9xXZbzaQ8+TnfnwEd8SXSM4mM1hp/h7qyMQENwOwAy8Iqf49Bett8AAz+l43bE C/aDuwBmftjutLjOYwh8mjoTXXKuz1Z6rkZNV5ZVOSwCKBChMVUcBE20zkDmPru8LTF8 rXgZet+t3YscHZvJ0jfBoEAyJgVGbJf5ntzRM= MIME-Version: 1.0 Received: by 10.223.58.198 with SMTP id i6mr2767674fah.28.1264682648822; Thu, 28 Jan 2010 04:44:08 -0800 (PST) In-Reply-To: <20100126232707.GG26462@mech-cluster241.men.bris.ac.uk> References: <20100126232707.GG26462@mech-cluster241.men.bris.ac.uk> Date: Thu, 28 Jan 2010 13:44:08 +0100 Message-ID: <4e6cba831001280444g12ba21b3hcc51c8180f08b3c3@mail.gmail.com> From: Giovanni Trematerra To: Anton Shterenlikht Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: can't load smbfs kernel module X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jan 2010 12:44:10 -0000 On Wed, Jan 27, 2010 at 12:27 AM, Anton Shterenlikht wrote: > I didn't get any luck asking in questions@, > so maybe this is a current@ issue: > > > On Mon, Jan 25, 2010 at 09:56:54PM +0000, Anton Shterenlikht wrote: >> On Mon, Jan 25, 2010 at 10:38:47AM -0600, Kevin Kinsey wrote: >> > Anton Shterenlikht wrote: >> > > This is on FreeBSD 9.0-CURRENT #0 r202964M ia64 >> > > >> > > I've built a kernel with smbfs module: >> > > >> > > # ls -al /boot/kernel/smb* >> > > -r-xr-xr-x =A01 root =A0wheel =A0265579 25 Jan 13:36 /boot/kernel/sm= bfs.ko >> > > -r-xr-xr-x =A01 root =A0wheel =A0680186 25 Jan 13:36 /boot/kernel/sm= bfs.ko.symbols >> > > >> > > but can't load it: >> > > >> > > # kldload smbfs >> > > kldload: can't load smbfs: No such file or directory >> > > >> > > >> > > Other modules load fine with kldload, e.g.: >> > >> > Does it make any difference to use the ".ko" extension, to >> > call it by absolute path, or to use "-v" for more information, >> > per The Friendly Manual? >> >> no, doesn't make any difference: >> >> # kldload -v /boot/kernel/smbfs.ko >> kldload: can't load /boot/kernel/smbfs.ko: No such file or directory >> # >> >> but I see in /var/log/messages: >> >> =A0kernel: KLD smbfs.ko: depends on libiconv - not available or version = mismatch >> If you have all modules compiled do: #kldload libiconv #kldload libmchain #kldload smbfs otherwise you have to include/compile such modules Have fun! -- Gianni From owner-freebsd-current@FreeBSD.ORG Thu Jan 28 15:42:45 2010 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 A6F651065670; Thu, 28 Jan 2010 15:42:45 +0000 (UTC) (envelope-from aoyama@peach.ne.jp) Received: from moon.peach.ne.jp (unknown [IPv6:2001:380:e06:127::53]) by mx1.freebsd.org (Postfix) with ESMTP id 6EAD98FC15; Thu, 28 Jan 2010 15:42:45 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id AA00D78C4B; Fri, 29 Jan 2010 00:42:44 +0900 (JST) Received: from artemis (unknown [192.168.2.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTP id 7233F78C3B; Fri, 29 Jan 2010 00:42:44 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: "Daniel O'Connor" , References: <201001280000.16773.doconnor@gsoft.com.au> Date: Fri, 29 Jan 2010 00:42:38 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5843 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org Subject: Re: [PATCH] VirtualBox headless VNC support by LibVNCServer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jan 2010 15:42:45 -0000 Thank you for your reply. >I put VBox-VNC-20100127.patch in files an modified the paths to be >acceptable to the ports tree and applied the Makefile patch and it >works well. (I say this as IMO it's easier to try if you distribute it >like that :) I think too. I have created it to use with FreeNAS. I assumed that it is used internally. The first mail of FreeBSD ML is here: http://lists.freebsd.org/pipermail/freebsd-emulation/2010-January/007336.html Next time, I will try to change you said. >Is there any prospect of being able to build the VNC server extension in >parallel with X11/QT4? There might not be problem. I'm not using X11. That is all of the reason. Daisuke Aoyama From owner-freebsd-current@FreeBSD.ORG Thu Jan 28 16:25:26 2010 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 24AAF1065672; Thu, 28 Jan 2010 16:25:26 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.org (yamagi.org [88.198.78.242]) by mx1.freebsd.org (Postfix) with ESMTP id DB75C8FC13; Thu, 28 Jan 2010 16:25:25 +0000 (UTC) Received: from screw (f054138160.adsl.alicedsl.de [78.54.138.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.org (Postfix) with ESMTP id ECB1B10849D1; Thu, 28 Jan 2010 17:25:23 +0100 (CET) Date: Thu, 28 Jan 2010 17:25:23 +0100 (CET) From: Yamagi Burmeister X-X-Sender: yamagi@screw.home.yamagi.org To: freebsd-current@freebsd.org In-Reply-To: Message-ID: References: <4B55D9D4.1000008@FreeBSD.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: mav@FreeBSD.org Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jan 2010 16:25:26 -0000 On Sat, 23 Jan 2010, Yamagi Burmeister wrote: > Hello, > applied this patch to 8-stable recompiled the kernel and rebooted. The > kernel did not boot it hangs while probing the ahci-controller. The > error message is: > > ahcich0: Timeout on slot 0 > ahcich0: is 00000002 cs 00000000 ss 000000000 rs 00000001 tfs 50 serr > 00000000 > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > > After that the kernel hangs forever. A 8-stable without the patch shows > > ahcich0: Timeout on slot 0 > run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config > > and boots but doesn't find any hard disks. It's an Asus M3A-H/HDMI > motherboard with AMD SB710 southbridge. The harddisk is an Western > Digital WD10EAVS. Both are working with the old ata implementation in > AHCI mode. pciconf output of the controller is > > atapci0@pci0:0:17:0: class=0x010601 card=0x43911002 chip=0x43911002 > rev=0x00 hdr=0x00 Okay, I took a deeper look into this and tried 9-CURRENT SVN r203116. Still the same problem but some more and maybe helpfull informations. With ahci.ko loaded the dmesg shows (transcribed by hand): ahci0: port 0xd000-0xd007, 0xc000-0xc003,0xb000-0xb007,0xa000-0xa003,0x9000-0x900f mem 0xfe8ffbff irq 22 at device 7.0 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci 0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci 0 ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci 0 ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci 0 ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci 0 ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci 0 ahcich5: [ITHREAD] [snip] ahcich0: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr 00000000 ahcich0: Timeout on slot 0 After that the kernel hangs indefinitly, endless repeating the last two lines. I changed some bios-options, deactivated s-ata port 5 and 6, even tried the latest bios version. No change, it always hangs. The same kernel but without ahci.ko reports: atapci0: port 0xd000-0xd007,0xc000-0xc003,0xb000-0xb007,0 xa000-0xa003,0x9000-0x900f mem 0xfe8ff800-0xfe8ffbff irq 22 at device 17.0 on pci0 atapci0: [ITHREAD] atapci0: AHCI v1.10 controller with 6 3Gbps ports, PM supported ata2: on atapci0 ata2: port is not ready (timeout 0ms) tfd = 000001d0 ata2: software reset clear timeout ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] ata4: on atapci0 ata4: [ITHREAD] ata5: on atapci0 ata5: [ITHREAD] ata6: on atapci0 ata6: [ITHREAD] ata7: on atapci0 ata7: [ITHREAD] [snip] ad4: 953869MB at ata2-master UDMA100 SATA 3Gb/s So it's working fine with the old ahci driver without cam. Hope that helps, Yamagi -- Homepage: www.yamagi.org Jabber: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-current@FreeBSD.ORG Thu Jan 28 17:17:02 2010 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 DEF0310656C0 for ; Thu, 28 Jan 2010 17:17:02 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 6CFEB8FC1B for ; Thu, 28 Jan 2010 17:17:02 +0000 (UTC) Received: by fxm27 with SMTP id 27so426702fxm.3 for ; Thu, 28 Jan 2010 09:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=RpxJ/0aSV6xRhkSUw5yUYX8WwMQo+R7GLC4BLN38258=; b=O9jpK7pWA6wWzjbSziC3aYMkYsNNjquRSuKX6+wR2NXtvBxUila8TAS9+JbD0rLNWI u3o3RHwd67JbbixP8vF7fSbFggndJXq4eG3S2xDDOImsoZa9i4qo1qnZXER61PkMoevf cSj9ULLLhUuaT+jP/caBSm/IjNWxx6u+w6Tto= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=v3a8sFfWd2ION4X0iEINm6fEScwRXv6DThJa59yvlxcK1vDwtg01YMnbJDO/6IzfEr wrvF/TgAx8pJQHAD0FlmT7YCfDPN73CovpbNsWnfzs06HBM1Bn84vuBa39eX5aXdXEby kn/9H9qlzirXc1lXrvgAM5zqoQ38chRadVWag= Received: by 10.223.4.139 with SMTP id 11mr3976490far.61.1264699019517; Thu, 28 Jan 2010 09:16:59 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm76696fxm.2.2010.01.28.09.16.57 (version=SSLv3 cipher=RC4-MD5); Thu, 28 Jan 2010 09:16:58 -0800 (PST) Sender: Alexander Motin Message-ID: <4B61C688.2050609@FreeBSD.org> Date: Thu, 28 Jan 2010 19:16:56 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Yamagi Burmeister References: <4B55D9D4.1000008@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jan 2010 17:17:02 -0000 Yamagi Burmeister wrote: > ahcich0: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr > 00000000 > ahcich0: Timeout on slot 0 Try to disable MSI interrupts with `hint.ahci.0.msi=0`. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Jan 28 17:35:52 2010 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 D6531106566B; Thu, 28 Jan 2010 17:35:52 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.org (yamagi.org [88.198.78.242]) by mx1.freebsd.org (Postfix) with ESMTP id 9839A8FC14; Thu, 28 Jan 2010 17:35:52 +0000 (UTC) Received: from screw (f054138160.adsl.alicedsl.de [78.54.138.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.org (Postfix) with ESMTP id 650DE1084B4F; Thu, 28 Jan 2010 18:35:51 +0100 (CET) Date: Thu, 28 Jan 2010 18:35:50 +0100 (CET) From: Yamagi Burmeister X-X-Sender: yamagi@screw.home.yamagi.org To: Alexander Motin In-Reply-To: <4B61C688.2050609@FreeBSD.org> Message-ID: References: <4B55D9D4.1000008@FreeBSD.org> <4B61C688.2050609@FreeBSD.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: freebsd-current@freebsd.org Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jan 2010 17:35:52 -0000 On Thu, 28 Jan 2010, Alexander Motin wrote: > Yamagi Burmeister wrote: >> ahcich0: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr >> 00000000 >> ahcich0: Timeout on slot 0 > > Try to disable MSI interrupts with `hint.ahci.0.msi=0`. That fixed the problem. Thank you :) -- Homepage: www.yamagi.org Jabber: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-current@FreeBSD.ORG Thu Jan 28 17:43:24 2010 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 356B1106566C for ; Thu, 28 Jan 2010 17:43:24 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id B6A1E8FC1B for ; Thu, 28 Jan 2010 17:43:23 +0000 (UTC) Received: by fxm27 with SMTP id 27so455355fxm.3 for ; Thu, 28 Jan 2010 09:43:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=OYS0+fqAg+uMvGiKrjRDgxK3JN++/IzvkhcaXTSdhnc=; b=j4IbIi0UMNEd9fydGCXED/srQU1EtbhwG3Y+L7nrW11Y5lmBQp/n0mIGDBevLtTGBE TLUeeE+s2yRugBMExckgjfZwil0LhUNWBuqBhywxBJDaD+IIO5sRc96Lr7eg21MXhn/s qIfgQoN+oeHSW7bDUl3blvFcL1PB9B3mb9PnY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=WnUyopc+js+19kgdC6+WuFVCvDRMRLtEiDb2G7teUVYutoofHDbjQLlcNqRnvcj9Vb 9SEr5AlVzZ5xJwNaIr+8CjtRvMIAm8OCih5aehrmkT2w5hN/vMH/PWx4vnR1XMXeh1X9 5gjnqV6A1FhHo5kbHKbx3eWaranAoIVqr1Il0= Received: by 10.87.11.34 with SMTP id o34mr65554fgi.26.1264700602449; Thu, 28 Jan 2010 09:43:22 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm88305fxm.8.2010.01.28.09.43.21 (version=SSLv3 cipher=RC4-MD5); Thu, 28 Jan 2010 09:43:21 -0800 (PST) Sender: Alexander Motin Message-ID: <4B61CCB6.4040005@FreeBSD.org> Date: Thu, 28 Jan 2010 19:43:18 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Yamagi Burmeister References: <4B55D9D4.1000008@FreeBSD.org> <4B61C688.2050609@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jan 2010 17:43:24 -0000 Yamagi Burmeister wrote: > On Thu, 28 Jan 2010, Alexander Motin wrote: > >> Yamagi Burmeister wrote: >>> ahcich0: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr >>> 00000000 >>> ahcich0: Timeout on slot 0 >> >> Try to disable MSI interrupts with `hint.ahci.0.msi=0`. > > That fixed the problem. Thank you :) That's quite strange, as in many other cases IXP700 is working fine. Different revisions? What is your `pciconf -lvbc` reports? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Jan 28 18:29:01 2010 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 BF2371065692; Thu, 28 Jan 2010 18:29:01 +0000 (UTC) (envelope-from lists@yamagi.org) Received: from mail.yamagi.org (yamagi.org [88.198.78.242]) by mx1.freebsd.org (Postfix) with ESMTP id 7CDD58FC15; Thu, 28 Jan 2010 18:29:01 +0000 (UTC) Received: from [192.168.1.150] (f054138160.adsl.alicedsl.de [78.54.138.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yamagi.org (Postfix) with ESMTP id 699AF1084C71; Thu, 28 Jan 2010 19:29:00 +0100 (CET) Date: Thu, 28 Jan 2010 19:28:57 +0100 (CET) From: Yamagi Burmeister X-X-Sender: yamagi@idate.home.yamagi.org To: Alexander Motin In-Reply-To: <4B61CCB6.4040005@FreeBSD.org> Message-ID: References: <4B55D9D4.1000008@FreeBSD.org> <4B61C688.2050609@FreeBSD.org> <4B61CCB6.4040005@FreeBSD.org> User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jan 2010 18:29:01 -0000 On Thu, 28 Jan 2010, Alexander Motin wrote: >>> Yamagi Burmeister wrote: >>>> ahcich0: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr >>>> 00000000 >>>> ahcich0: Timeout on slot 0 >>> >>> Try to disable MSI interrupts with `hint.ahci.0.msi=0`. >> >> That fixed the problem. Thank you :) > > That's quite strange, as in many other cases IXP700 is working fine. > Different revisions? What is your `pciconf -lvbc` reports? When I helped nox@ debugging a problem with timeouts we noticed, that our controlers are of differend revisions. The pciconf output ist: ahci0@pci0:0:17:0: class=0x010601 card=0x43911002 chip=0x43911002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 SATA Controller [AHCI mode]' class = mass storage subclass = SATA bar [10] = type I/O Port, range 32, base 0xd000, size 8, enabled bar [14] = type I/O Port, range 32, base 0xc000, size 4, enabled bar [18] = type I/O Port, range 32, base 0xb000, size 8, enabled bar [1c] = type I/O Port, range 32, base 0xa000, size 4, enabled bar [20] = type I/O Port, range 32, base 0x9000, size 16, enabled bar [24] = type Memory, range 32, base 0xfe8ff800, size 1024, enabled cap 01[60] = powerspec 2 supports D0 D3 current D0 cap 05[50] = MSI supports 4 messages, 64 bit cap 12[70] = SATA Index-Data Pair -- Homepage: www.yamagi.org Jabber: yamagi@yamagi.org GnuPG/GPG: 0xEFBCCBCB From owner-freebsd-current@FreeBSD.ORG Thu Jan 28 18:31:00 2010 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 984931065692 for ; Thu, 28 Jan 2010 18:31:00 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 4C8418FC22 for ; Thu, 28 Jan 2010 18:31:00 +0000 (UTC) Received: from mobile-166-129-001-156.mycingular.net (mobile-166-129-001-156.mycingular.net [166.129.1.156] (may be forged)) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o0SIUkWj075744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 28 Jan 2010 13:30:59 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: From: Randall Stewart To: FreeBSD Current Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 28 Jan 2010 10:30:37 -0800 X-Mailer: Apple Mail (2.936) Subject: A strange thing with yesterday's head.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jan 2010 18:31:00 -0000 All: I just found a very strange thing with yesterdays head. The program http://www.freebsd.org/~rrs/my_thr.c I compile it: cc -g -o my_thr my_thr.c /usr/lib/libthr.a -lpthread Now when you run this on a 2 core 64 bit machine running X11 with yesterday AM's current. The machine appears to lock completely. It really has not give it time and it will chug along.. but the mouse disappears etc... as if its locked. It takes quite some time to complete .. and every now and then a hickup will occur and you get a slight response.. Now I took this code home and ran it on my 4core AMD (2.8Gig with real AMD cores). And it did NOT do the same.. but ran like you would expect it to. I then took the same code running on an identical 8.0 release machine and ran it and it worked like you would expect.. It looks like some change in the scheduler in head is not doing good things. Note my 4 core is behind the 2 core.. so it may not be core count related.. when I get off work today and get home I will do a update and see if the 4 core starts behaving badly too... R ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-current@FreeBSD.ORG Thu Jan 28 19:11:46 2010 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 C68F1106568B for ; Thu, 28 Jan 2010 19:11:46 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 5B0228FC0A for ; Thu, 28 Jan 2010 19:11:46 +0000 (UTC) Received: from mobile-166-129-219-006.mycingular.net (mobile-166-129-219-006.mycingular.net [166.129.219.6] (may be forged)) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o0SJBfPi077469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Jan 2010 14:11:44 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <9BB1CD0C-A7EE-42E6-A6D8-E571D908FE35@lakerest.net> From: Randall Stewart To: Jille Timmermans In-Reply-To: <4B61D888.4010507@quis.cx> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 28 Jan 2010 11:11:34 -0800 References: <4B61D888.4010507@quis.cx> X-Mailer: Apple Mail (2.936) Cc: FreeBSD Current Subject: Re: A strange thing with yesterday's head.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jan 2010 19:11:46 -0000 My bad.. I fogot to fix the permissions.. It should work now. Sorry about that.. R On Jan 28, 2010, at 10:33 AM, Jille Timmermans wrote: > 403 - Forbidden ;) > > -- Jille > > Randall Stewart schreef: >> All: >> >> I just found a very strange thing with yesterdays head. >> >> The program >> >> http://www.freebsd.org/~rrs/my_thr.c >> >> I compile it: >> >> cc -g -o my_thr my_thr.c /usr/lib/libthr.a -lpthread >> >> Now when you run this on a 2 core 64 bit machine running X11 with >> yesterday >> AM's current. The machine appears to lock completely. It really has >> not give >> it time and it will chug along.. but the mouse disappears etc... as >> if >> its locked. >> >> It takes quite some time to complete .. and every now and then a >> hickup will occur >> and you get a slight response.. >> >> Now I took this code home and ran it on my 4core AMD (2.8Gig with >> real >> AMD cores). And >> it did NOT do the same.. but ran like you would expect it to. >> >> I then took the same code running on an identical 8.0 release machine >> and ran it >> and it worked like you would expect.. >> >> >> It looks like some change in the scheduler in head is not doing good >> things. >> >> Note my 4 core is behind the 2 core.. so it may not be core count >> related.. when >> I get off work today and get home I will do a update and see if the 4 >> core starts >> behaving badly too... >> >> R >> ------------------------------ >> Randall Stewart >> 803-317-4952 (cell) >> 803-345-0391(direct) >> >> _______________________________________________ >> 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" > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-current@FreeBSD.ORG Thu Jan 28 19:15:26 2010 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 2BC0F1065670 for ; Thu, 28 Jan 2010 19:15:26 +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 832758FC15 for ; Thu, 28 Jan 2010 19:15:25 +0000 (UTC) Received: from [195.4.92.10] (helo=0.mx.freenet.de) by mout0.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.70 #1) id 1NaZpr-0000cM-9z; Thu, 28 Jan 2010 20:15:23 +0100 Received: from p57ae10b4.dip0.t-ipconnect.de ([87.174.16.180]:18194 helo=ernst.jennejohn.org) by 0.mx.freenet.de with esmtpa (ID gary.jennejohn@freenet.de) (port 25) (Exim 4.72 #1) id 1NaZpq-0000eX-VS; Thu, 28 Jan 2010 20:15:23 +0100 Date: Thu, 28 Jan 2010 20:15:20 +0100 From: Gary Jennejohn To: Randall Stewart Message-ID: <20100128201520.6a114290@ernst.jennejohn.org> In-Reply-To: References: X-Mailer: Claws Mail 3.7.4 (GTK+ 2.16.2; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: A strange thing with yesterday's head.. 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: Thu, 28 Jan 2010 19:15:26 -0000 On Thu, 28 Jan 2010 10:30:37 -0800 Randall Stewart wrote: > All: > > I just found a very strange thing with yesterdays head. > > The program > > http://www.freebsd.org/~rrs/my_thr.c > > I compile it: > > cc -g -o my_thr my_thr.c /usr/lib/libthr.a -lpthread > > Now when you run this on a 2 core 64 bit machine running X11 with > yesterday > AM's current. The machine appears to lock completely. It really has > not give > it time and it will chug along.. but the mouse disappears etc... as if > its locked. > > It takes quite some time to complete .. and every now and then a > hickup will occur > and you get a slight response.. > > Now I took this code home and ran it on my 4core AMD (2.8Gig with real > AMD cores). And > it did NOT do the same.. but ran like you would expect it to. > > I then took the same code running on an identical 8.0 release machine > and ran it > and it worked like you would expect.. > > > It looks like some change in the scheduler in head is not doing good > things. > > Note my 4 core is behind the 2 core.. so it may not be core count > related.. when > I get off work today and get home I will do a update and see if the 4 > core starts > behaving badly too... > Are you using SCHED_4BSD? Seems to me some changes were made to it very recently. I tried this on my AMD64 X2 using SCHED_ULE and it worked OK. But I'm not running HEAD, because I'm using the svn tree with soft-updates journaling from a few days ago. --- Gary Jennejohn From owner-freebsd-current@FreeBSD.ORG Thu Jan 28 19:49:32 2010 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 71C991065679; Thu, 28 Jan 2010 19:49:32 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id CF0528FC17; Thu, 28 Jan 2010 19:49:31 +0000 (UTC) Received: by bwz5 with SMTP id 5so882778bwz.3 for ; Thu, 28 Jan 2010 11:49:30 -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; bh=AAJ8yNZOGscxkUAMoA3wCw/rqW9A5kda3qs9Lut93mc=; b=eGOazLj00YqVAwhtE5zJ6N1uLpbGM+ByjRGhuzMpuuLIX/C6yogOpjPw7AtycOOIFh B4zmzRH4s4R+3l1Iz/l55pVyu6VaGFjseX6I3vJGb4+Rnbj3SgJGf/F4mGA/XYAv31UR 3LAtclfrpfoC4cFPCa3ZLH7FRNsbDkgDgK+zI= 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; b=p6Etpx8QlAohi1tCWtrLhc3FXouBMCpcV9ht7OxIeDFr5nJhpbbiVzM35KqoanZJn7 wYNCd5QKhUrR1JKa6K2XlLpfMsCpifIPfLRG7177WQ4r5xQXH6Wx1RvN+NAlbthUnlEY jHXjDPGM5d4KMzr3//Evn8AD2HzHqlK8LZ/7o= MIME-Version: 1.0 Received: by 10.204.39.193 with SMTP id h1mr142361bke.147.1264708170588; Thu, 28 Jan 2010 11:49:30 -0800 (PST) In-Reply-To: <4B61C688.2050609@FreeBSD.org> References: <4B55D9D4.1000008@FreeBSD.org> <4B61C688.2050609@FreeBSD.org> Date: Thu, 28 Jan 2010 22:49:29 +0300 Message-ID: From: pluknet To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org, Yamagi Burmeister Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jan 2010 19:49:32 -0000 On 28 January 2010 20:16, Alexander Motin wrote: > Yamagi Burmeister wrote: >> ahcich0: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr >> 00000000 >> ahcich0: Timeout on slot 0 > > Try to disable MSI interrupts with `hint.ahci.0.msi=0`. > Sorry for hijacking your thread. Can this help on my similar issue as well? It's hardly reproducible for me. (it's reported while back: http://lists.freebsd.org/pipermail/freebsd-stable/2009-December/053372.html) -- wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Thu Jan 28 20:08:15 2010 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 05372106568F for ; Thu, 28 Jan 2010 20:08:15 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f226.google.com (mail-fx0-f226.google.com [209.85.220.226]) by mx1.freebsd.org (Postfix) with ESMTP id 85B778FC1F for ; Thu, 28 Jan 2010 20:08:14 +0000 (UTC) Received: by fxm26 with SMTP id 26so829464fxm.13 for ; Thu, 28 Jan 2010 12:08:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=bZo+logZ/bpJWndIshP0NHMq4fifM32C3cp78TEnrsQ=; b=izXq9aWHOe2yYsSF7VHDbgblhUo7vNIr9UHQLkWXYpBPukUVaCXR2y3g2fUiKGvgGK 7YuRrh9FnEHI62P4BbSI9g5OF96C4L+V5jBZ8w0rYSrSMe7czw9U78CveBgTTOfysYeJ pz4CwoZp0+ksg5PUlana8dbzrUzl9z1gE5gIs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=bEmaH90zLuTt/WaXuTkNdR6xHqS5lbhhlbSKAgWowF55fyAKD3cQyMeA4oai2fY0Xc QKK2rTIFw0ZJTrOiydtIjs/PJJk1DFgzyTDzSUuVay4im3o7Vi4IRAkkyVoovGhExtBk r353/SAdn7ciRB8IcbGMqiplswFmZFRXZRdTg= Received: by 10.223.101.148 with SMTP id c20mr12079304fao.94.1264709293289; Thu, 28 Jan 2010 12:08:13 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 16sm163560fxm.8.2010.01.28.12.08.12 (version=SSLv3 cipher=RC4-MD5); Thu, 28 Jan 2010 12:08:12 -0800 (PST) Sender: Alexander Motin Message-ID: <4B61EEA8.7030503@FreeBSD.org> Date: Thu, 28 Jan 2010 22:08:08 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: pluknet References: <4B55D9D4.1000008@FreeBSD.org> <4B61C688.2050609@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Yamagi Burmeister Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jan 2010 20:08:15 -0000 pluknet wrote: > On 28 January 2010 20:16, Alexander Motin wrote: >> Yamagi Burmeister wrote: >>> ahcich0: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr >>> 00000000 >>> ahcich0: Timeout on slot 0 >> Try to disable MSI interrupts with `hint.ahci.0.msi=0`. > > Sorry for hijacking your thread. > Can this help on my similar issue as well? It's hardly reproducible for me. > (it's reported while back: > http://lists.freebsd.org/pipermail/freebsd-stable/2009-December/053372.html) I am not sure. "ss ffffffff" there means that none of 32 sent NCQ commands are completed. So it may be a real timeout. But you may try it, if that virtual controller supports MSI at all and there is something to disable. The other possible option is to try AHCI_Q_EDGEIS quirk. It helps some controllers to avoid lost interrupts under high load. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Thu Jan 28 21:55:44 2010 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 126FD106566C for ; Thu, 28 Jan 2010 21:55:44 +0000 (UTC) (envelope-from rrs@lakerest.net) Received: from lakerest.net (unknown [IPv6:2001:240:585:2:213:d4ff:fef3:2d8d]) by mx1.freebsd.org (Postfix) with ESMTP id 97D978FC1A for ; Thu, 28 Jan 2010 21:55:43 +0000 (UTC) Received: from mobile-166-129-219-006.mycingular.net (mobile-166-129-219-006.mycingular.net [166.129.219.6] (may be forged)) (authenticated bits=0) by lakerest.net (8.14.3/8.14.3) with ESMTP id o0SLtURf084194 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Jan 2010 16:55:38 -0500 (EST) (envelope-from rrs@lakerest.net) Message-Id: <117532D7-75B9-4BE8-A8B6-0A6761064B92@lakerest.net> From: Randall Stewart To: gary.jennejohn@freenet.de In-Reply-To: <20100128201520.6a114290@ernst.jennejohn.org> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 28 Jan 2010 13:55:21 -0800 References: <20100128201520.6a114290@ernst.jennejohn.org> X-Mailer: Apple Mail (2.936) Cc: FreeBSD Current Subject: Re: A strange thing with yesterday's head.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jan 2010 21:55:44 -0000 I was running SCHED_ULE on an 8.0 and everything works fine. On my 2 core head of yesterday I tried both SCHED_ULE AND 4BSD.. and got the same results ;-0 I will try my 4 core when I get home ;-) R On Jan 28, 2010, at 11:15 AM, Gary Jennejohn wrote: > On Thu, 28 Jan 2010 10:30:37 -0800 > Randall Stewart wrote: > >> All: >> >> I just found a very strange thing with yesterdays head. >> >> The program >> >> http://www.freebsd.org/~rrs/my_thr.c >> >> I compile it: >> >> cc -g -o my_thr my_thr.c /usr/lib/libthr.a -lpthread >> >> Now when you run this on a 2 core 64 bit machine running X11 with >> yesterday >> AM's current. The machine appears to lock completely. It really has >> not give >> it time and it will chug along.. but the mouse disappears etc... as >> if >> its locked. >> >> It takes quite some time to complete .. and every now and then a >> hickup will occur >> and you get a slight response.. >> >> Now I took this code home and ran it on my 4core AMD (2.8Gig with >> real >> AMD cores). And >> it did NOT do the same.. but ran like you would expect it to. >> >> I then took the same code running on an identical 8.0 release machine >> and ran it >> and it worked like you would expect.. >> >> >> It looks like some change in the scheduler in head is not doing good >> things. >> >> Note my 4 core is behind the 2 core.. so it may not be core count >> related.. when >> I get off work today and get home I will do a update and see if the 4 >> core starts >> behaving badly too... >> > > Are you using SCHED_4BSD? Seems to me some changes were made to it > very recently. > > I tried this on my AMD64 X2 using SCHED_ULE and it worked OK. But I'm > not running HEAD, because I'm using the svn tree with soft-updates > journaling from a few days ago. > > --- > Gary Jennejohn > ------------------------------ Randall Stewart 803-317-4952 (cell) 803-345-0391(direct) From owner-freebsd-current@FreeBSD.ORG Thu Jan 28 22:43:47 2010 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 348D61065692; Thu, 28 Jan 2010 22:43:47 +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 A23488FC1B; Thu, 28 Jan 2010 22:43:46 +0000 (UTC) Received: from inchoate.gsoft.com.au (ppp121-45-156-224.lns6.adl6.internode.on.net [121.45.156.224]) (authenticated bits=0) by cain.gsoft.com.au (8.13.8/8.13.8) with ESMTP id o0SMhfjE061277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 29 Jan 2010 09:13:42 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: "Daisuke Aoyama" Date: Fri, 29 Jan 2010 09:13:26 +1030 User-Agent: KMail/1.9.10 References: <201001280000.16773.doconnor@gsoft.com.au> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1644808.5eoKPeSfur"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201001290913.36223.doconnor@gsoft.com.au> X-Spam-Score: -1.696 () AWL,BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.63 on 203.31.81.10 Cc: freebsd-emulation@freebsd.org, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [PATCH] VirtualBox headless VNC support by LibVNCServer X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Jan 2010 22:43:47 -0000 --nextPart1644808.5eoKPeSfur Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 29 Jan 2010, Daisuke Aoyama wrote: > I think too. I have created it to use with FreeNAS. I assumed that it > is used internally. > The first mail of FreeBSD ML is here: > http://lists.freebsd.org/pipermail/freebsd-emulation/2010-January/007 >336.html Next time, I will try to change you said. OK thanks. > >Is there any prospect of being able to build the VNC server > > extension in parallel with X11/QT4? > > There might not be problem. I'm not using X11. That is all of the > reason. Ahh.. I think that the VNC option is orthogonal to X11. IMO it should probably be installed unconditionally as it is only a very=20 minor code increase which makes the headless server much, much more=20 useful. =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 --nextPart1644808.5eoKPeSfur Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iD8DBQBLYhMY5ZPcIHs/zowRAuPYAJ4nngBWL8fgyWmVarHYdK8xNI2DVACgrIO6 BihY3D8fwTWGc6zmYLdm2Gw= =nQ/Y -----END PGP SIGNATURE----- --nextPart1644808.5eoKPeSfur-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 04:41:56 2010 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 3D04B1065676 for ; Fri, 29 Jan 2010 04:41:56 +0000 (UTC) (envelope-from inurneck@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 977AF8FC0A for ; Fri, 29 Jan 2010 04:41:55 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so197902fgb.13 for ; Thu, 28 Jan 2010 20:41:54 -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; bh=V4VklIwWvRNhgx9zn40SOkhBA4Go8tiVENRaY4FdF40=; b=Bl+h4warpGZ2kpM3n8UdBtEkjB0Y7GoLjq3ljsoTAkw7lznEqjxMjvQ/wrI7HF2v1u oQZB42cV6LzzjCtLHCmqqz24IcSdc9FZTYJfjCGVp0rraTK/r6Ri/sBwKtPFqoFu3e+1 kwfUlj87kdbEBImSVJZ1J7dwUEKb834XMzXs8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Axftsf49HJs7exiU5/zACoEWrgDM70tnj94REAehJlvGy9nnzVhqT7EF6PpqnV06jK cUQbqyoIm4zJ+fHQUFuKNMupoSwv4vgd72A9qK1Tx4e4tUwHyC0owMgJjGcDW4jjtcxh wRebZNHjMbvvT+adv0uLIOp6rnCFEvLaime3o= MIME-Version: 1.0 Received: by 10.103.50.2 with SMTP id c2mr140618muk.9.1264740114430; Thu, 28 Jan 2010 20:41:54 -0800 (PST) Date: Thu, 28 Jan 2010 23:41:54 -0500 Message-ID: <79b166921001282041m7dbacb52kc885d27d3c793b34@mail.gmail.com> From: inurneck To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Boot hangs indefinitely on cd1: Attempt to query device size failed: NOT READY, Medium not present X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 04:41:56 -0000 Hello, greeting salutions, all that jive; It's only been about a week i'd say since I last supped current code and went in a kernel with my config and booted up fine. My questiion s then within the last week what did you guys commit that would make my box dndefinitely hang on cd1: Attempt to query device size failed: NOT READY, Medium not present ? I waited about 2 minutes and it still just stayed there, I cant change t oany other consoles yet or do anything. My kernel config although custom should not be an issue as Ive been in it for several months and have had a stable OS. But here it is none the less. Thanks for any help on this as I like to keep current and watch you guys do good work.. ############################################################################### ############################################################################### # What am I ? cpu I686_CPU machine i386 ident core maxusers 256 # To make an SMP kernel, the next lines are wanted. device cpufreq # CPU frequency scaling. options SMP # Symmetric MultiProcessor Kernel. device apic # Symmetric (APIC) I/O. device acpi # Support for ACPI. device nvram # Access to rtc cmos. # Linux compatibility. options COMPAT_LINUX options LINPROCFS # Linux /proc fs support. options INCLUDE_CONFIG_FILE # Learned this the hard way. # Bus support. device pci # PCI BUS support. device agp # AGP support. # Floppy drive. device fdc # Floppy drive controller. # SoundBlaster Audigy2 XS. device sound # Support for sound. device snd_emu10k1 # Support for the card. # Video card. device drm # DRM core module required by DRM drivers. device mach64drm # DRM for mach64. device radeondrm # DRM for ATI Radeon. # Keyboard and USB. device ohci # OHCI PCI->USB interface. device uhci # UHCI for USB. device ehci # EHCI for USB. device usb # USB Bus (required). device umass # USB mass storage. device ums # USB mouse. device ukbd # USB Keyboard. device uhid # UHID for USB. device atkbdc # AT keyboard controller. device atkbd # AT keyboard. device kbdmux # Keyboard multiplexer. device psm # PS/2 Mouse. # Video, graphic and console settings. device vga # VGA video card driver. device vesa # Vesa. device splash # Splash screen and screen saver support. device sc # Default console driver. options SC_PIXEL_MODE # Support for SC_PIXEL. options SC_NORM_ATTR="(FG_RED|BG_BLACK)" options SC_NORM_REV_ATTR="(FG_BLACK|BG_LIGHTGREY)" options SC_KERNEL_CONS_ATTR="(FG_YELLOW|BG_BLUE)" options SC_KERNEL_CONS_REV_ATTR="(FG_BLUE|BG_LIGHTGREY)" # Pseudo devices. device loop # Network loopback. device random # Entropy device. device ether # Ethernet support. device pty # BSD-style compatibility pseudo ttys. device md # Memory "disks". device firmware # firmware assist module. # NETWORKING devices and PF FIREWALL. device miibus # MII bus support need this for fxp. device fxp # Intel EtherExpress PRO/100B (82557, 82558). device bpf # Berkeley packet filter. device pf # OpenBSD packet filter. device pflog # logging. device pfsync # Sync. options ALTQ # Altq support. options ALTQ_CBQ # Class Bases Queuing (CBQ). options ALTQ_RED # Random Early Detection (RED). options ALTQ_RIO # RED In/Out. options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC). options ALTQ_PRIQ # Priority Queuing (PRIQ). options ALTQ_NOPCC # Required for SMP build. options HZ=1000 # HZ. options DEVICE_POLLING # Support for polling. options IPSTEALTH options SHMSEG=16 options SHMMNI=32 options SHMMAX=2097152 options SHMALL=4096 options MAXFILES=8192 # Some stock options I have not gone through completely yet. options SCHED_ULE # ULE scheduler. options FULL_PREEMPTION # Full preemption. options PREEMPTION # Enable kernel thread preemption. options IPI_PREEMPTION # current. options COUNT_IPIS # Per-CPU IPI interrupt counters options AUTO_EOI_1 # current. options AUTO_EOI_2 # current. options INET # InterNETworking. options FFS # Berkeley Fast Filesystem. options SOFTUPDATES # Enable FFS soft updates support. options UFS_ACL # Support for access control lists. options UFS_DIRHASH # Improve performance on big directories. options UFS_GJOURNAL # Enable gjournal-based UFS journaling. options MD_ROOT # MD is a potential root device. options CD9660 # ISO 9660 Filesystem. options PROCFS # Process filesystem (requires PSEUDOFS). options PSEUDOFS # Pseudo-filesystem framework. options MSDOSFS # Support for msdos FS. Needed this for USBSTICK. options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization. options STACK # stack(9) support. options SYSVSHM # SYSV-style shared memory. options SYSVMSG # SYSV-style message queues. options SYSVSEM # SYSV-style semaphores. options P1003_1B_SEMAPHORES # POSIX-style semaphores. options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions. options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options AUDIT # Security event auditing. options MAC # TrustedBSD MAC Framework. options FLOWTABLE # per-cpu routing cache. # SCSI, RAID devices and a pleuthora of options for debugging them. device ahc # Adaptec aic78xx. device aac # Perc2/SI. device aacp # SCSI Passthrough interface (optional, CAM required). device pass # Passthrough device (direct SCSI access). device da # Direct Access (disks). Needed this for USBSTICK. device scbus # SCSI bus (required for SCSI). device cd # Only need one. Code dynamically grows. device sg # Linux SCSI SG passthrough device. # SCSI_DELAY: The number of MILLISECONDS to freeze the SIM (scsi adapter). options SCSI_DELAY=100 # Use lowest integer by default. # CAMDEBUG: When defined enables debugging macros. # options CAMDEBUG # CAM_DEBUG_BUS: Debug the given bus. Use -1 to debug all busses. # options CAM_DEBUG_BUS=-1 # CAM_DEBUG_TARGET: Debug the given target. Use -1 to debug all targets. # options CAM_DEBUG_TARGET=-1 # CAM_DEBUG_LUN: Debug the given lun. Use -1 to debug all luns. # options CAM_DEBUG_LUN=-1 # CAM_DEBUG_FLAGS: CAM_DEBUG_INFO, CAM_DEBUG_TRACE,CAM_DEBUG_SUBTRACE, and CAM_DEBUG_CDB. # options CAM_DEBUG_FLAGS=(CAM_DEBUG_INFO|CAM_DEBUG_TRACE|CAM_DEBUG_CDB) # CAM_MAX_HIGHPOWER: Maximum number of concurrent high power (start unit) cmds. #options CAM_MAX_HIGHPOWER=6 # Timeout for the CAM processor target. #options SCSI_PT_DEFAULT_TIMEOUT=60 # Adaptec Array Controller driver options # options AAC_DEBUG=0 # Debugging levels: # 0 - quiet, only emit warnings # 1 - noisy, emit major function # points and things done # 2 - extremely noisy, emit trace # items in loops, etc. # The aic7xxx driver will attempt to use memory mapped I/O for all PCI # controllers that have it configured only if this option is set. But # this doesn't work with all motherboards, So it's not on by default. #options AHC_ALLOW_MEMIO # Dump the contents of the ahc controller configuration PROM. # options AHC_DUMP_EEPROM # Bitmap of units to enable targetmode operations. #options AHC_TMODE_ENABLE # Compile in Aic7xxx Debugging code. # options AHC_DEBUG # See /sys/dev/aic7***/aic7***.h for all options. # options AHC_DEBUG_OPTS=AHC_SHOW_MESSAGES # Print register bitfields in debug output. # options AHC_REG_PRETTY_PRINT # Debugging for use in -CURRENT. # makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols. # options KDTRACE_HOOKS # make WITH_CTF=1 buildkernel KERNCONF=core && make installkernel KERNCONF=core --More--(91%) # options DDB_CTF # CTF for DDB. # options DIAGNOSTIC # This reduces performance. # options KDB # Enable kernel debugger support. # options KDB_UNATTENDED # KDB unattended support. # options DDB # Support DDB. # options GDB # Support remote GDB. # options INVARIANTS # Enable calls of extra sanity checking. # options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS. # options WITNESS # Enable checks to detect deadlocks and cycles. # options WITNESS_SKIPSPIN ############################################################################### ############################################################################### System is a dell poweredge 2400. I am going to play with scsi_delay=100 and see if that might be it. I have no freakin idea if its even that. The next step for it would have been to mount the root fs but i recieve no error. Thanks again. -- I am my only local user and I cannot be trusted. This is a bad thing. Thing is, with FreeBSD where there is a shell there is a way. Over the years I've come to regard you as people I've met. I may be schizophrenic, but at least I have each other, and only when I am alone am I truly together. Hans reiser is still my hero, i'm not saying it's right, but I understand. From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 05:31:09 2010 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 0EB97106566B for ; Fri, 29 Jan 2010 05:31:09 +0000 (UTC) (envelope-from inurneck@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 999838FC15 for ; Fri, 29 Jan 2010 05:31:08 +0000 (UTC) Received: by fxm27 with SMTP id 27so206791fxm.3 for ; Thu, 28 Jan 2010 21:31: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; bh=lfUTvVop9dIcIiwCSy/LvXhZqv1DkIBuoIosqe/P7qI=; b=PsRPEZGx923AAAJlozvo1OGuf+wSGXcCrbnKwb5b8zIr7D8J8EEZ2+jRldVc2pyMN1 P0+E1W0uAR3/N/9MJ2wBmOW22eYLDEk5MHU/ALLIqs9VFZH4IL08PfZ6AqjiTtFTSk3b 5BIdAcRqszyn1rBXrX2lM5mTA6rRZsdeBUwCg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=NeLwvNkUVNaHbuYb2QBOX1L+Qx+fM67yhxWRHH/S1uzNP3FBGsbQMZOFCw5TuqcoHP aAyQSYPb7oEaj59JXkAfzaRJx9YwZXwumpcs8j3mn7+dC1Tj4iGi+vQgVomy3/UO343o 5IJK4mi/Egv3ppyxcQcDNwFFBsMtrGz52vy1A= MIME-Version: 1.0 Received: by 10.103.84.30 with SMTP id m30mr162035mul.22.1264743067680; Thu, 28 Jan 2010 21:31:07 -0800 (PST) Date: Fri, 29 Jan 2010 00:31:07 -0500 Message-ID: <79b166921001282131s5b0bce24sc3134fe0f7dda194@mail.gmail.com> From: inurneck To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: update* Bootup hangs on scsi cdrom attaching X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 05:31:09 -0000 I turned off my seconday scsi controller (scsi cdroms) and the box boots fine. --With no scsi cdrom devices.. Looking at the code in the last 20 hours a lot of things have been done to CAM. I am putting my money in that direction. Any idea where I should begin? How can I tell freebsd just to not probe the cdroms at boot, I don't need to be told, nor even care if a cdrom is in the device or not upon boot, Why would I want 12 lines of error messages on bootup telling me when there isnt, and now, a machine that wont boot? I could have lived with just the errors, and I was, but this? hmm. -- I am my only local user and I cannot be trusted. This is a bad thing. Thing is, with FreeBSD where there is a shell there is a way. Over the years I've come to regard you as people I've met. I may be schizophrenic, but at least I have each other, and only when I am alone am I truly together. Hans reiser is still my hero, i'm not saying it's right, but I understand. From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 07:35:33 2010 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 EC100106566C for ; Fri, 29 Jan 2010 07:35:33 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 79D7F8FC1C for ; Fri, 29 Jan 2010 07:35:33 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 19so10362fgg.13 for ; Thu, 28 Jan 2010 23:35:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=yKgLPDyBL8NpxLQaEp45ZpDp0b/L9ksAw2nmrDmnErA=; b=FGci5Plv9KrH3Rl3LnFAo0QSu7h8u8E3eQoRIvFMkWgzZobiDb9aJ5tZ9qawk7BTZ0 GMFP6P2IYZTMEM1tLnmh6Nv607+c8eQ0P+BPzvHK30clYR+X1Z1qUb3fkzkkqU3IcPSV 4vnOtKdfEARTdK69u0lrvOdr+ztGpOW+AB6l8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Ag44Rhz4dHPFClmfEuLk9uT3s3KNlwhUfqQJx6aDqNYenujL5qjFfM/K7pmcNcXK4E MMPAJaDzypLvbrL07lJUQXiWPur0wiNv95Yza+3lJQPhpuR5CwusVT4j0k4eGB+0mw08 ScK7egKilqp7wtfNxuzSIMAwfLCFfTbvotGdE= Received: by 10.103.67.31 with SMTP id u31mr135303muk.122.1264750532301; Thu, 28 Jan 2010 23:35:32 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id b9sm4613774mug.39.2010.01.28.23.35.31 (version=SSLv3 cipher=RC4-MD5); Thu, 28 Jan 2010 23:35:31 -0800 (PST) Sender: Alexander Motin Message-ID: <4B628FC1.5090405@FreeBSD.org> Date: Fri, 29 Jan 2010 09:35:29 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: inurneck , FreeBSD-Current References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: update* Bootup hangs on scsi cdrom attaching X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 07:35:34 -0000 inurneck wrote: > I turned off my seconday scsi controller (scsi cdroms) and the box boots > fine. --With no scsi cdrom devices.. Looking at the code in the last 20 > hours a lot of things have been done to CAM. I am putting my money in that > direction. Any idea where I should begin? How can I tell freebsd just to not > probe the cdroms at boot, I don't need to be told, nor even care if a cdrom > is in the device or not upon boot, Why would I want 12 lines of error > messages on bootup telling me when there isnt, and now, a machine that wont > boot? I could have lived with just the errors, and I was, but this? hmm. Can you (for beginning) grab verbose boot messages? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 07:36:36 2010 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 71C691065672 for ; Fri, 29 Jan 2010 07:36:36 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by mx1.freebsd.org (Postfix) with ESMTP id F1FBE8FC1D for ; Fri, 29 Jan 2010 07:36:35 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e21so72314fga.13 for ; Thu, 28 Jan 2010 23:36:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=QPiWpLV+SJVOtcHEHzlELqu7S76AsEfCGDfi+QYbx1s=; b=gGQswvAMigxLtC22Kjpa6KjBvwDOZWifiMWgrkcxHTpYW74u6ZDmUxq1dBRiawMdIk lfzMrJdQIwPqx0/WlvS74PQniewcV18wxyGeVMGr4ZBU0kv+zmVf+gmrCyEfpAr0HvVG cfGjvXQeJ+5XxQdMGaNFHIbvaCu0g1h3vU0ZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=PKnc5wfFgYUMZdxdYTO0pM302wVpQSxXbV0F/b6l0QIt75UT5dchR7JXpvyQtdvO62 /bU5UOee5A13n10Xv/DJB6KOxOZ5rIPpCiSC1FHVXTegmbLp90jxQAxbmlXjMvoUSLJT vKktcgIAHQc3kZPJzT0fHoXIoC5wyZK3HxdTA= Received: by 10.103.125.37 with SMTP id c37mr224012mun.3.1264750594935; Thu, 28 Jan 2010 23:36:34 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id y6sm7464151mug.31.2010.01.28.23.36.33 (version=SSLv3 cipher=RC4-MD5); Thu, 28 Jan 2010 23:36:34 -0800 (PST) Sender: Alexander Motin Message-ID: <4B629000.1010805@FreeBSD.org> Date: Fri, 29 Jan 2010 09:36:32 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: inurneck , FreeBSD-Current References: <4B628FC1.5090405@FreeBSD.org> In-Reply-To: <4B628FC1.5090405@FreeBSD.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: update* Bootup hangs on scsi cdrom attaching X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 07:36:36 -0000 Alexander Motin wrote: > inurneck wrote: >> I turned off my seconday scsi controller (scsi cdroms) and the box boots >> fine. --With no scsi cdrom devices.. Looking at the code in the last 20 >> hours a lot of things have been done to CAM. I am putting my money in that >> direction. Any idea where I should begin? How can I tell freebsd just to not >> probe the cdroms at boot, I don't need to be told, nor even care if a cdrom >> is in the device or not upon boot, Why would I want 12 lines of error >> messages on bootup telling me when there isnt, and now, a machine that wont >> boot? I could have lived with just the errors, and I was, but this? hmm. > > Can you (for beginning) grab verbose boot messages? Also you may try to enable INVARIANTS. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 11:01:04 2010 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 5496C106566B; Fri, 29 Jan 2010 11:01:04 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 87BAE8FC1F; Fri, 29 Jan 2010 11:01:03 +0000 (UTC) Received: by fxm27 with SMTP id 27so147025fxm.3 for ; Fri, 29 Jan 2010 03:01:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=JwWrJBEQHSjE3g4PxphGt4WrEJ3674s8Bi6gVzAs1h4=; b=x9PnFDKxkpjxRW5aMBnS7XGg0u5mRhuygU1GKF6A9xB/jQ/X9CogdiiyvXDTcLVIh5 m6y1KTsNu57kzIRiWSclvmbk1p4ewAAjqwt9sIkSv+xWqESMRU/klu3cavbJ29uO6sX7 b6ZX7btut7UY4kTB4taJTMCRt6IvXubiLuRDo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:from:content-type:content-transfer-encoding:subject:date :message-id:to:mime-version:x-mailer; b=MXyIjYESlqF8UXpf8Lls58MjWArQcEuOCG4wbBJGC5k+y4om6pxTt4sTXFlWh4oYpd hmZxoqvP9K2T4XXvi3U7wmvZ0NEVSTmfYPJPAHFxNIYbjmfQkjCpz0qtGaEJLTjfenmC OGOFCx+QRNFkCxOTh98kKYY4/2Ql6AlbrRbNg= Received: by 10.223.14.216 with SMTP id h24mr450354faa.106.1264762862517; Fri, 29 Jan 2010 03:01:02 -0800 (PST) Received: from ?10.0.10.4? (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 15sm411642fxm.6.2010.01.29.03.01.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Jan 2010 03:01:01 -0800 (PST) Sender: Rui Paulo From: Rui Paulo Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 29 Jan 2010 11:00:58 +0000 Message-Id: To: Sergey Vinogradov , Paul Webster , S Smirnov , Eugene Dzhurinsky , freebsd-current@freebsd.org, freebsd-mobile@freebsd.org, freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Cc: Subject: HEADS UP: Atheros AR9285 support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 11:01:04 -0000 Hi, I just committed initial support for the Atheros AR9285 wireless chipset = found on many netbooks. The driver still has issues but it's stable = enough for general use (don't expect good throughput, though). I'm looking for testers to make sure I didn't break anything else in the = Atheros driver. If you notice any problems with ath on a recent kernel, please inform = me. Thanks, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 11:41:58 2010 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 07A1F1065679 for ; Fri, 29 Jan 2010 11:41:58 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id 862F38FC12 for ; Fri, 29 Jan 2010 11:41:57 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e21so19409fga.13 for ; Fri, 29 Jan 2010 03:41:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=NL6CsDEmBL2hpTerr1P3875qRWrzq56fzIOsDyFP6ZM=; b=l4UjKXSx2gf8J4BAIMEv6H3jdzdqD2iW6kSj2+S1AcG1/p7vTek89aQhrK/IhqTQLw aZ/dBqHPWv2eoxPzV5e68yjVJ5lhwepPdJP2ILbLme0PUIRnEqKG9YuXvJSAALnhyorJ HX3RArMWoIDCtFt2bLGO9/K3P3JN54VZq/v9k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=UMphORtRg9eA13Bbs9CE/RQ7YBwYaGXCyBKwR+YvyBQnPWRUq3UbmIH6lRHLZpO/zC yyc61dJ3bc4jbTncDGEYe/jWaL1LRTblgGCFjIbCfevmXG4/HHE3GYRkQfyRaE0GCJrJ beSKlUn8eflHdl1iBVOXdHkyCq3e0buz2+67U= Received: by 10.103.80.34 with SMTP id h34mr311833mul.20.1264765316372; Fri, 29 Jan 2010 03:41:56 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id i5sm10205747mue.25.2010.01.29.03.41.53 (version=SSLv3 cipher=RC4-MD5); Fri, 29 Jan 2010 03:41:54 -0800 (PST) Sender: Alexander Motin Message-ID: <4B62C97F.7080000@FreeBSD.org> Date: Fri, 29 Jan 2010 13:41:51 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Yamagi Burmeister References: <4B55D9D4.1000008@FreeBSD.org> <4B61C688.2050609@FreeBSD.org> <4B61CCB6.4040005@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 11:41:58 -0000 Yamagi Burmeister wrote: > On Thu, 28 Jan 2010, Alexander Motin wrote: > >>>> Yamagi Burmeister wrote: >>>>> ahcich0: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr >>>>> 00000000 >>>>> ahcich0: Timeout on slot 0 >>>> >>>> Try to disable MSI interrupts with `hint.ahci.0.msi=0`. >>> >>> That fixed the problem. Thank you :) >> >> That's quite strange, as in many other cases IXP700 is working fine. >> Different revisions? What is your `pciconf -lvbc` reports? > > When I helped nox@ debugging a problem with timeouts we noticed, that > our controlers are of differend revisions. The pciconf output ist: > > ahci0@pci0:0:17:0: class=0x010601 card=0x43911002 chip=0x43911002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'SB700 SATA Controller [AHCI mode]' > class = mass storage > subclass = SATA > bar [10] = type I/O Port, range 32, base 0xd000, size 8, enabled > bar [14] = type I/O Port, range 32, base 0xc000, size 4, enabled > bar [18] = type I/O Port, range 32, base 0xb000, size 8, enabled > bar [1c] = type I/O Port, range 32, base 0xa000, size 4, enabled > bar [20] = type I/O Port, range 32, base 0x9000, size 16, enabled > bar [24] = type Memory, range 32, base 0xfe8ff800, size 1024, > enabled > cap 01[60] = powerspec 2 supports D0 D3 current D0 > cap 05[50] = MSI supports 4 messages, 64 bit > cap 12[70] = SATA Index-Data Pair What's interesting, is that Asus board with the same chipset doesn't expose MSI support at all: ahci0@pci0:0:17:0: class=0x010601 card=0x43911002 chip=0x43911002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 SATA Controller [AHCI mode]' class = mass storage subclass = SATA bar [10] = type I/O Port, range 32, base 0xc000, size 8, enabled bar [14] = type I/O Port, range 32, base 0xb000, size 4, enabled bar [18] = type I/O Port, range 32, base 0xa000, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x9000, size 4, enabled bar [20] = type I/O Port, range 32, base 0x8000, size 16, enabled bar [24] = type Memory, range 32, base 0xfbcffc00, size 1024, enabled cap 01[60] = powerspec 2 supports D0 D3 current D0 cap 12[70] = SATA Index-Data Pair -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 13:03:51 2010 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 45E221065670; Fri, 29 Jan 2010 13:03:51 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id A705E8FC0C; Fri, 29 Jan 2010 13:03:50 +0000 (UTC) Received: by bwz5 with SMTP id 5so1375024bwz.3 for ; Fri, 29 Jan 2010 05: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; bh=oSDQBMNgVcpEOznUjVaI80mgipFGQsXFtSOsBEmvIO4=; b=YMTqOt7enQRcMsHLSimMjAFsMbq6liNaRXpCxV5yDqAmIMV8AZ3+TAXVjeE/9eykbt 0/A7kcJDLM2TrXlLoLrVmlLYRdJUBO+WO12LCYh+MMNE8aiUNTg0q4QLcgeooyIPunRW lsqQH4cEtmlYuJhKYZsONgTd2MhQLyDGMo3Bk= 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; b=T0p8gXjaoKitJ/2xFQVyj1xa2e+Oh3IWQy1EgI6z4Sc4p910+5soyN4c4HEzkq84zZ TFprAUHTNW+67xgg9wjrnfEi7AQrj47LNsSoCt6+2MOGQuIee0KzRTea8l2ADlUVIV9v wcJMhFVCcbxrSft9cxsXk5QG+Ui7YzeP+Q3T8= MIME-Version: 1.0 Received: by 10.204.5.75 with SMTP id 11mr497181bku.20.1264770229150; Fri, 29 Jan 2010 05:03:49 -0800 (PST) In-Reply-To: <4B5C79CF.9070504@FreeBSD.org> References: <4B55D9D4.1000008@FreeBSD.org> <201001231407.o0NE7l8j002620@triton8.kn-bremen.de> <20100123184619.257203d9@ernst.jennejohn.org> <4B5C79CF.9070504@FreeBSD.org> Date: Fri, 29 Jan 2010 14:03:49 +0100 Message-ID: <83e5fb981001290503n140d4c05ga755853a1588de@mail.gmail.com> From: Diego Depaoli To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD-Current Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 13:03:51 -0000 On Sun, Jan 24, 2010 at 5:48 PM, Alexander Motin wrote: > New patch version should handle this and some other problems: > http://people.freebsd.org/~mav/cam-ata.20100124.patch I didn't yet test in depth your patch but... - ogmrip doesn't more freeze the system - while the system boots, closing the optical drive's tray with a video dvd inserted, I get a reproducible (for me) panic. Regards -- Diego Depaoli From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 13:06:21 2010 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 068F6106566B for ; Fri, 29 Jan 2010 13:06:21 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 8572F8FC1E for ; Fri, 29 Jan 2010 13:06:19 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e21so49723fga.13 for ; Fri, 29 Jan 2010 05:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=6bNXwyxA/ZrftdNWSON9d0JAQywI5PQoDZpsMR369W4=; b=AVKRT5uwhmRShMjRHVnQQrZozTNGkjVzL8xK/OOlhew4+38epDfFKi5ojqSE8ArEN6 IjxEMdjD2r8fvQYHWr6pTvl7lkuuMhFnjEgtYm+wnfsQRJFaaBSYFn2X4oge2UEdJAsO zvwJk1RGcHmWDdfRMpl5u0nO0lav9OYa9ib6I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=sg139j07s6zBRFz5y3alF9EuycjGaTwOZm7EyBN1fm/+kAwyzYSLYjRDCksDYBOzm+ C9OaZBmLqwdJc3Id5+cEzwUyHIgIbM5aB19UqYfzXW5YUwRYguEa3pTfwDizWLZykt9i xSsBt9EJYWKblUTYd2MQK2Ae+e5VeVSGuZBwA= Received: by 10.103.4.9 with SMTP id g9mr344235mui.57.1264770378222; Fri, 29 Jan 2010 05:06:18 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 12sm5860810muq.42.2010.01.29.05.06.16 (version=SSLv3 cipher=RC4-MD5); Fri, 29 Jan 2010 05:06:17 -0800 (PST) Sender: Alexander Motin Message-ID: <4B62DD46.4060908@FreeBSD.org> Date: Fri, 29 Jan 2010 15:06:14 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Diego Depaoli References: <4B55D9D4.1000008@FreeBSD.org> <201001231407.o0NE7l8j002620@triton8.kn-bremen.de> <20100123184619.257203d9@ernst.jennejohn.org> <4B5C79CF.9070504@FreeBSD.org> <83e5fb981001290503n140d4c05ga755853a1588de@mail.gmail.com> In-Reply-To: <83e5fb981001290503n140d4c05ga755853a1588de@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 13:06:21 -0000 Diego Depaoli wrote: > On Sun, Jan 24, 2010 at 5:48 PM, Alexander Motin wrote: >> New patch version should handle this and some other problems: >> http://people.freebsd.org/~mav/cam-ata.20100124.patch > I didn't yet test in depth your patch but... > - ogmrip doesn't more freeze the system > - while the system boots, closing the optical drive's tray with a > video dvd inserted, I get a reproducible (for me) panic. If you wish it to be fixed - you had to give much more info. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 13:38:38 2010 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 CCD451065692 for ; Fri, 29 Jan 2010 13:38:38 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.161.16.135]) by mx1.freebsd.org (Postfix) with ESMTP id 599B68FC1C for ; Fri, 29 Jan 2010 13:38:37 +0000 (UTC) Received: from [41.154.0.10] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Nar3S-0007v3-HN for current@freebsd.org; Fri, 29 Jan 2010 15:38:34 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Nar3R-0000Jw-B1 for current@freebsd.org; Fri, 29 Jan 2010 15:38:33 +0200 To: current@freebsd.org From: "Ian FREISLICH" X-Attribution: BOFH Date: Fri, 29 Jan 2010 15:38:33 +0200 Message-Id: Cc: Subject: Problem using MC950D with u3g X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 13:38:38 -0000 Hi I am not sure if it's the driver or the device. It worked for about an hour. Now when I plug it in I get this: ugen0.2: at usbus0 (disconnected) usb_alloc_device: set address 2 failed (USB_ERR_STALLED, ignored) usb_alloc_device: getting device descriptor at addr 2 failed, USB_ERR_STALLED usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_STALLED, ignored) usbd_req_re_enumerate: getting device descriptor at addr 2 failed, USB_ERR_STALLED usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_STALLED, ignored) usbd_req_re_enumerate: getting device descriptor at addr 2 failed, USB_ERR_STALLED ugen0.2: <(null)> at usbus0 (disconnected) uhub_reattach_port: could not allocate new device Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 14:17:34 2010 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 D05AA106566C; Fri, 29 Jan 2010 14:17: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 C36298FC15; Fri, 29 Jan 2010 14:17:33 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA09645; Fri, 29 Jan 2010 16:17:31 +0200 (EET) (envelope-from avg@icyb.net.ua) Message-ID: <4B62EDFB.1060103@icyb.net.ua> Date: Fri, 29 Jan 2010 16:17:31 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091206) MIME-Version: 1.0 To: Alexander Motin References: <4B55D9D4.1000008@FreeBSD.org> <4B61C688.2050609@FreeBSD.org> <4B61CCB6.4040005@FreeBSD.org> <4B62C97F.7080000@FreeBSD.org> In-Reply-To: <4B62C97F.7080000@FreeBSD.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Yamagi Burmeister Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 14:17:34 -0000 on 29/01/2010 13:41 Alexander Motin said the following: > Yamagi Burmeister wrote: >> On Thu, 28 Jan 2010, Alexander Motin wrote: >> >>>>> Yamagi Burmeister wrote: >>>>>> ahcich0: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr >>>>>> 00000000 >>>>>> ahcich0: Timeout on slot 0 >>>>> Try to disable MSI interrupts with `hint.ahci.0.msi=0`. >>>> That fixed the problem. Thank you :) >>> That's quite strange, as in many other cases IXP700 is working fine. >>> Different revisions? What is your `pciconf -lvbc` reports? >> When I helped nox@ debugging a problem with timeouts we noticed, that >> our controlers are of differend revisions. The pciconf output ist: >> >> ahci0@pci0:0:17:0: class=0x010601 card=0x43911002 chip=0x43911002 >> rev=0x00 hdr=0x00 >> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >> device = 'SB700 SATA Controller [AHCI mode]' >> class = mass storage >> subclass = SATA >> bar [10] = type I/O Port, range 32, base 0xd000, size 8, enabled >> bar [14] = type I/O Port, range 32, base 0xc000, size 4, enabled >> bar [18] = type I/O Port, range 32, base 0xb000, size 8, enabled >> bar [1c] = type I/O Port, range 32, base 0xa000, size 4, enabled >> bar [20] = type I/O Port, range 32, base 0x9000, size 16, enabled >> bar [24] = type Memory, range 32, base 0xfe8ff800, size 1024, >> enabled >> cap 01[60] = powerspec 2 supports D0 D3 current D0 >> cap 05[50] = MSI supports 4 messages, 64 bit >> cap 12[70] = SATA Index-Data Pair > > What's interesting, is that Asus board with the same chipset doesn't > expose MSI support at all: > > ahci0@pci0:0:17:0: class=0x010601 card=0x43911002 chip=0x43911002 > rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'SB700 SATA Controller [AHCI mode]' > class = mass storage > subclass = SATA > bar [10] = type I/O Port, range 32, base 0xc000, size 8, enabled > bar [14] = type I/O Port, range 32, base 0xb000, size 4, enabled > bar [18] = type I/O Port, range 32, base 0xa000, size 8, enabled > bar [1c] = type I/O Port, range 32, base 0x9000, size 4, enabled > bar [20] = type I/O Port, range 32, base 0x8000, size 16, enabled > bar [24] = type Memory, range 32, base 0xfbcffc00, size 1024, enabled > cap 01[60] = powerspec 2 supports D0 D3 current D0 > cap 12[70] = SATA Index-Data Pair > PCI revision register of SMBus device (0:20:0) gives a particular revision of SB7x0. SB700 RPR document (section 7.11) says that MSI capability should be disabled if the revision is 0x39 or 0x3a, it should be enabled for newer revisions (0x3b, 03c). Those who like to experiment with potentially dangerous things may try playing with bit 16 of PCI config register 0x50 of SATA controller device. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 14:37:43 2010 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 648AA106566B for ; Fri, 29 Jan 2010 14:37:43 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id B90D18FC1F for ; Fri, 29 Jan 2010 14:37:42 +0000 (UTC) Received: by bwz5 with SMTP id 5so1451240bwz.3 for ; Fri, 29 Jan 2010 06:37:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=Oaq7Hu/Q3VKk+dOw9Z8TN9EIOnWycblH6WDuwpqhOv4=; b=vngB6T82B3cUfgmgX4kHAlBBhZteFy9a0cAXmnsnTru2WBIa6nLJmOj+UUyGwnkRIU aMKoK+hcffEF3zK8JDwvVtSPGT4b0E/clTzaoppoU7QneMoQc/eXR6c9OJGnMaGVEx61 VBkqtML/G57rg371sbyybDopYzmTqz7ZEeXFA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=xHXYobyYZqvEB1Z+ofH/Zpz+onUsvFlL2hKY4hNGzgNfTtOHosRPI7yg/xNeXHJamr PZB7SgI0W9dZPHEIEmSuDwX0z5q+5bvdH/S0GwYLthL2ZZLkhyvYUNtgn4HrTkJtNCsv LXKTBlnszpBG/K6qKZshmqaNmppNSV8sE4vFo= Received: by 10.103.80.15 with SMTP id h15mr418927mul.54.1264775861552; Fri, 29 Jan 2010 06:37:41 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id y37sm5661538mug.38.2010.01.29.06.37.38 (version=SSLv3 cipher=RC4-MD5); Fri, 29 Jan 2010 06:37:38 -0800 (PST) Sender: Alexander Motin Message-ID: <4B62F2B0.2030704@FreeBSD.org> Date: Fri, 29 Jan 2010 16:37:36 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Andriy Gapon References: <4B55D9D4.1000008@FreeBSD.org> <4B61C688.2050609@FreeBSD.org> <4B61CCB6.4040005@FreeBSD.org> <4B62C97F.7080000@FreeBSD.org> <4B62EDFB.1060103@icyb.net.ua> In-Reply-To: <4B62EDFB.1060103@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Yamagi Burmeister Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 14:37:43 -0000 Andriy Gapon wrote: > on 29/01/2010 13:41 Alexander Motin said the following: >> Yamagi Burmeister wrote: >>> On Thu, 28 Jan 2010, Alexander Motin wrote: >>> >>>>>> Yamagi Burmeister wrote: >>>>>>> ahcich0: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr >>>>>>> 00000000 >>>>>>> ahcich0: Timeout on slot 0 >>>>>> Try to disable MSI interrupts with `hint.ahci.0.msi=0`. >>>>> That fixed the problem. Thank you :) >>>> That's quite strange, as in many other cases IXP700 is working fine. >>>> Different revisions? What is your `pciconf -lvbc` reports? >>> When I helped nox@ debugging a problem with timeouts we noticed, that >>> our controlers are of differend revisions. The pciconf output ist: >>> >>> ahci0@pci0:0:17:0: class=0x010601 card=0x43911002 chip=0x43911002 >>> rev=0x00 hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'SB700 SATA Controller [AHCI mode]' >>> class = mass storage >>> subclass = SATA >>> bar [10] = type I/O Port, range 32, base 0xd000, size 8, enabled >>> bar [14] = type I/O Port, range 32, base 0xc000, size 4, enabled >>> bar [18] = type I/O Port, range 32, base 0xb000, size 8, enabled >>> bar [1c] = type I/O Port, range 32, base 0xa000, size 4, enabled >>> bar [20] = type I/O Port, range 32, base 0x9000, size 16, enabled >>> bar [24] = type Memory, range 32, base 0xfe8ff800, size 1024, >>> enabled >>> cap 01[60] = powerspec 2 supports D0 D3 current D0 >>> cap 05[50] = MSI supports 4 messages, 64 bit >>> cap 12[70] = SATA Index-Data Pair >> What's interesting, is that Asus board with the same chipset doesn't >> expose MSI support at all: >> >> ahci0@pci0:0:17:0: class=0x010601 card=0x43911002 chip=0x43911002 >> rev=0x00 hdr=0x00 >> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >> device = 'SB700 SATA Controller [AHCI mode]' >> class = mass storage >> subclass = SATA >> bar [10] = type I/O Port, range 32, base 0xc000, size 8, enabled >> bar [14] = type I/O Port, range 32, base 0xb000, size 4, enabled >> bar [18] = type I/O Port, range 32, base 0xa000, size 8, enabled >> bar [1c] = type I/O Port, range 32, base 0x9000, size 4, enabled >> bar [20] = type I/O Port, range 32, base 0x8000, size 16, enabled >> bar [24] = type Memory, range 32, base 0xfbcffc00, size 1024, enabled >> cap 01[60] = powerspec 2 supports D0 D3 current D0 >> cap 12[70] = SATA Index-Data Pair >> > > PCI revision register of SMBus device (0:20:0) gives a particular revision of SB7x0. > SB700 RPR document (section 7.11) says that MSI capability should be disabled if > the revision is 0x39 or 0x3a, it should be enabled for newer revisions (0x3b, 03c). VIA uses ISA bridge to identify chipset, ATI (as you said) - SMBus. Hell! Why not to do it properly? > Those who like to experiment with potentially dangerous things may try playing > with bit 16 of PCI config register 0x50 of SATA controller device. I would prefer it was done by BIOS. Probably ASUS did it, as my board has 0x3a. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 15:44:27 2010 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 3CD761065670; Fri, 29 Jan 2010 15:44:27 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 9E5608FC17; Fri, 29 Jan 2010 15:44:26 +0000 (UTC) Received: by fxm27 with SMTP id 27so422739fxm.3 for ; Fri, 29 Jan 2010 07:44:25 -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; bh=ktSYKlGTq0gg8e4DdaroW8Bw6bqYXytShHa8QWcypUU=; b=AIG5D8yNJ2IK4tmkix3jX6qa8WZp0hcAXlGfAklo5DNBWixCucOHGQRlU4BcWf5oOM Zmm7CidwSlEzmMA2cb7QnO3+OXsqjIViOK3Zlh+8UsWqAf6Cd4z0rNugLL4coQhaUQPP ZAQeWP5dJ5ihyE9m8t8thwEv+alWVqY/74iK8= 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; b=oJWy8NbhLKkQQvqA7dWPJZNERn8iIDHrjqYoQcT69AOlZWwctLnf+0cFfQoIMimf9S w9/ilCIpxlJGmICPm0CQ8php6BrqVFoAA1ePCQDk74cQdx0iPwA58tTbhukqGfqTwqE4 thIOqYYS7+vuLh+0Bu9JjbprRktA/YCYb7/l8= MIME-Version: 1.0 Received: by 10.223.81.90 with SMTP id w26mr963073fak.9.1264779865365; Fri, 29 Jan 2010 07:44:25 -0800 (PST) In-Reply-To: <117532D7-75B9-4BE8-A8B6-0A6761064B92@lakerest.net> References: <20100128201520.6a114290@ernst.jennejohn.org> <117532D7-75B9-4BE8-A8B6-0A6761064B92@lakerest.net> Date: Fri, 29 Jan 2010 16:44:25 +0100 Message-ID: <4e6cba831001290744m6067691ct489c61fe9cd28502@mail.gmail.com> From: Giovanni Trematerra To: Randall Stewart Content-Type: text/plain; charset=ISO-8859-1 Cc: Attilio Rao , FreeBSD Current Subject: Re: A strange thing with yesterday's head.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 15:44:27 -0000 On Thu, Jan 28, 2010 at 10:55 PM, Randall Stewart wrote: > I was running SCHED_ULE on an 8.0 and everything works > fine. > > On my 2 core head of yesterday I tried both SCHED_ULE AND > 4BSD.. and got the same results ;-0 > > I will try my 4 core when I get home ;-) > > R > On Jan 28, 2010, at 11:15 AM, Gary Jennejohn wrote: > >> On Thu, 28 Jan 2010 10:30:37 -0800 >> Randall Stewart wrote: >> >>> All: >>> >>> I just found a very strange thing with yesterdays head. >>> >>> The program >>> >>> http://www.freebsd.org/~rrs/my_thr.c >>> >>> I compile it: >>> >>> cc -g -o my_thr my_thr.c /usr/lib/libthr.a -lpthread >>> Hi Randal, I tried your code on an 8-core machine with a fresh head (i386) I have no problems with both 4BSD and ULE scheduler. I even upping the value of macro NUM_THREAD to 24 but I didn't notice nothing strange. Have you got a chance to reproduce it on your machines? -- Gianni From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 15:56:19 2010 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 A44311065676; Fri, 29 Jan 2010 15:56:19 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id B2D868FC16; Fri, 29 Jan 2010 15:56:18 +0000 (UTC) Received: by fxm27 with SMTP id 27so435576fxm.3 for ; Fri, 29 Jan 2010 07:56:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=M05tgLi8XhFz4cFCUtV8dLbiU8+NSDOBztgiZ/Ct+x4=; b=kyRTiWXZXzoUD2nC2uQjx032kaGCOpHtSE4w17ZfzYIU/5M8DdP1KO6qldRHCpCvAN cxPZW2tPFm5F/L4cUxIBkNFWGPBZSsSUzTBEJ/qsGefrNXw3gC0zPZOrz9M1a/0MP3H8 /k+JfL+JrUC38Ugw0znyxV+4Re4ZdtRAVzJbE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=m6qHJcLSL0A+lWQmID9rb2z5YFj19cL2xZBZkSmEu9j2m0IB6nSK9rqhtMh381FSYk iaaKjtjpFZWMo42wGlczxbch9Z0iD4pE9z8VTvvPm3tR4F4NjXG9am016KKDYh6mhJKq M/ODtJuH75nZQZ86dUoQSMDVuCtwrGhlrNXj8= Received: by 10.223.29.193 with SMTP id r1mr938011fac.29.1264780577600; Fri, 29 Jan 2010 07:56:17 -0800 (PST) Received: from ?10.0.10.4? (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 15sm548020fxm.2.2010.01.29.07.56.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 29 Jan 2010 07:56:16 -0800 (PST) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: Date: Fri, 29 Jan 2010 15:56:14 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <37797801-B178-485B-A5E1-CA42CA0619DB@freebsd.org> References: To: Rui Paulo X-Mailer: Apple Mail (2.1077) Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, freebsd-mobile@freebsd.org Subject: Re: HEADS UP: Atheros AR9285 support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2010 15:56:19 -0000 On 29 Jan 2010, at 11:00, Rui Paulo wrote: > Hi, > I just committed initial support for the Atheros AR9285 wireless = chipset found on many netbooks. The driver still has issues but it's = stable enough for general use (don't expect good throughput, though). >=20 > I'm looking for testers to make sure I didn't break anything else in = the Atheros driver. > If you notice any problems with ath on a recent kernel, please inform = me. Patch against stable/8: http://people.freebsd.org/~rpaulo/ar9285_stable_8.diff -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 19:02:09 2010 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 2892E106566C; Fri, 29 Jan 2010 19:02:09 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id BAB6E8FC12; Fri, 29 Jan 2010 19:02:08 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id AF8E714DA436; Fri, 29 Jan 2010 20:02:04 +0100 (CET) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qQA6lqIteMzz; Fri, 29 Jan 2010 20:01:55 +0100 (CET) Received: from [192.168.1.121] (catv-89-132-179-104.catv.broadband.hu [89.132.179.104]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 1CBB414DA435; Fri, 29 Jan 2010 20:01:55 +0100 (CET) Message-ID: <4B633F2D.6010804@FreeBSD.org> Date: Fri, 29 Jan 2010 21:03:57 +0100 From: =?ISO-8859-1?Q?G=E1bor_K=F6vesd=E1n?= User-Agent: Thunderbird 2.0.0.23 (X11/20100119) MIME-Version: 1.0 To: Jilles Tjoelker References: <20100119212019.GL59590@deviant.kiev.zoral.com.ua> <4B56CACF.50508@FreeBSD.org> <4B5B4F4B.3030201@FreeBSD.org> <20100124091911.GI31243@server.vk2pj.dyndns.org> <4B5C27B9.1080805@FreeBSD.org> <20100124113718.GC3877@deviant.kiev.zoral.com.ua> <4B5CD916.1060003@FreeBSD.org> <20100126222338.GA40281@stack.nl> In-Reply-To: <20100126222338.GA40281@stack.nl> Content-Type: multipart/mixed; boundary="------------090104020009000102060209" Cc: Xin LI , Hajimu UMEMOTO , current@freebsd.org Subject: Re: NLS/strerror efficiency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 19:02:09 -0000 This is a multi-part message in MIME format. --------------090104020009000102060209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Jilles, thanks for your observations, I've made a new patch to improve the parts you mentioned. It is attached. And I comment on some things below. > > These may return from the function if locking operations fail. They do > this without setting errno to a sensible value. > This was already fixed in the committed version. > >> -static nl_catd load_msgcat(const char *); >> +static nl_catd load_msgcat(const char *, const char *, const char *); >> >> +static pthread_rwlock_t rwlock; >> > > Use PTHREAD_RWLOCK_INITIALIZER here to avoid problems with initializing > the lock. > I talked to delphij@ about this. Shouldn't pthread_rwlock_rdlock() and pthread_rwlock_wrlock() automatically initialize the lock if it is NULL? We even removed the pthread_rwlock_init() call and it just works. > > Hmm, so an error for one language makes it give up for all other > languages too? It is possible that a catalog is only available in a few > languages. > Fixed. > >> + UNLOCK(NLERR); >> + NLRETERR(np->caterrno); >> + } else if (strcmp(np->lang, lang) == 0) { >> > > Some code below can apparently set np->lang = NULL, how does that work? > NULL means locale-independent open, i.e. catopen() is given an absolute path. We could add more if's to separate those cases more but that would result in more code, while this just works. If name is set to an absolute path, lang will be NULL and strcmp(NULL, NULL) will return 0, so it will match. > >> + /* Found cached successful entry */ >> + np->refcount++; >> + UNLOCK(NLERR); >> > > np leaked if unlock fails. > We discussed this with delphij@ and unlock cannot actually fail, because it can only fail in two cases: 1, uninitialized rwlock descriptor 2, lock wasn't actually acquired None of these can happen in this code, so we removed the return from there. > > Hmm, why not simply if (catd == np->catd) here? > Ok, done. > >> + np->refcount--; >> + if (np->refcount == 0) { >> + munmap(catd->__data, (size_t)catd->__size); >> + free(catd); >> + SLIST_REMOVE(&flist, np, catentry, list); >> + free(np); >> > > The two or three strings in np need to be freed too. > Done. > > np leaked if unlock fails. > > Same applies here, won't fail, return removed. >> + return (np->catd); >> + } >> + } >> + UNLOCK(NLERR); >> + >> + if ((fd = _open(path, O_RDONLY)) == -1) { >> + SAVEFAIL(name, errno); >> return (NLERR); >> + } >> >> if (_fstat(fd, &st) != 0) { >> + SAVEFAIL(name, errno); >> > > fd not closed if locking fails. > [...] > data still mapped if locking fails. > > [..] > > data still mapped if locking fails. > > I changed the order of free and caching here. > > > np leaked if unlock fails. > Same as above. Please take a look if the new patch seems good to you. Cheers, Gabor --------------090104020009000102060209 Content-Type: text/x-patch; name="msgcat.c.diff" Content-Transfer-Encoding: 8bit Content-Disposition: inline; filename="msgcat.c.diff" Index: nls/msgcat.c =================================================================== --- nls/msgcat.c (revisión: 203174) +++ nls/msgcat.c (copia de trabajo) @@ -89,7 +89,7 @@ static nl_catd load_msgcat(const char *, const char *, const char *); -static pthread_rwlock_t rwlock; +static pthread_rwlock_t rwlock = PTHREAD_RWLOCK_INITIALIZER; struct catentry { SLIST_ENTRY(catentry) list; @@ -135,12 +135,12 @@ /* Try to get it from the cache first */ RLOCK(NLERR); SLIST_FOREACH(np, &cache, list) { - if (strcmp(np->name, name) == 0) { + if ((strcmp(np->name, name) == 0) && (strcmp(np->lang, lang) == 0)) { if (np->caterrno != 0) { /* Found cached failing entry */ UNLOCK; NLRETERR(np->caterrno); - } else if (strcmp(np->lang, lang) == 0) { + } else { /* Found cached successful entry */ np->refcount++; UNLOCK; @@ -325,13 +325,15 @@ /* Remove from cache if not referenced any more */ WLOCK(-1); SLIST_FOREACH(np, &cache, list) { - if ((np->catd->__size == catd->__size) && - memcmp((const void *)np->catd, (const void *)catd, np->catd->__size) == 0) { + if (catd == np->catd) { np->refcount--; if (np->refcount == 0) { munmap(catd->__data, (size_t)catd->__size); free(catd); SLIST_REMOVE(&cache, np, catentry, list); + free(np->name); + free(np->path); + free(np->lang); free(np); } break; @@ -374,8 +376,8 @@ } if (_fstat(fd, &st) != 0) { + _close(fd); SAVEFAIL(name, errno); - _close(fd); return (NLERR); } @@ -390,8 +392,8 @@ if (ntohl((u_int32_t)((struct _nls_cat_hdr *)data)->__magic) != _NLS_MAGIC) { + munmap(data, (size_t)st.st_size); SAVEFAIL(name, errno); - munmap(data, (size_t)st.st_size); NLRETERR(EINVAL); } --------------090104020009000102060209-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 19:51:44 2010 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 976841065672; Fri, 29 Jan 2010 19:51:44 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 2113B8FC0C; Fri, 29 Jan 2010 19:51:43 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 3606F1E0076C; Fri, 29 Jan 2010 20:51:42 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id o0TJnD2o013982; Fri, 29 Jan 2010 20:49:13 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id o0TJnCAa013981; Fri, 29 Jan 2010 20:49:12 +0100 (CET) (envelope-from nox) Date: Fri, 29 Jan 2010 20:49:12 +0100 (CET) From: Juergen Lock Message-Id: <201001291949.o0TJnCAa013981@triton8.kn-bremen.de> To: mav@FreeBSD.org X-Newsgroups: local.list.freebsd.current In-Reply-To: <4B62F2B0.2030704@FreeBSD.org> References: <4B55D9D4.1000008@FreeBSD.org> <4B61C688.2050609@FreeBSD.org> <4B61CCB6.4040005@FreeBSD.org> <4B62C97F.7080000@FreeBSD.org> <4B62EDFB.1060103@icyb.net.ua> Organization: home Cc: freebsd-current@FreeBSD.org, Andriy Gapon , Yamagi Burmeister Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 19:51:44 -0000 In article <4B62F2B0.2030704@FreeBSD.org> you write: >Andriy Gapon wrote: >> on 29/01/2010 13:41 Alexander Motin said the following: >>> Yamagi Burmeister wrote: >>>> On Thu, 28 Jan 2010, Alexander Motin wrote: >>>> >>>>>>> Yamagi Burmeister wrote: >>>>>>>> ahcich0: is 00000002 cs 00000000 ss 00000000 rs 00000001 tfd 50 serr >>>>>>>> 00000000 >>>>>>>> ahcich0: Timeout on slot 0 >>>>>>> Try to disable MSI interrupts with `hint.ahci.0.msi=0`. >>>>>> That fixed the problem. Thank you :) >>>>> That's quite strange, as in many other cases IXP700 is working fine. >>>>> Different revisions? What is your `pciconf -lvbc` reports? >>>> When I helped nox@ debugging a problem with timeouts we noticed, that >>>> our controlers are of differend revisions. The pciconf output ist: >>>> >>>> ahci0@pci0:0:17:0: class=0x010601 card=0x43911002 chip=0x43911002 >>>> rev=0x00 hdr=0x00 >>>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>>> device = 'SB700 SATA Controller [AHCI mode]' >>>> class = mass storage >>>> subclass = SATA >>>> bar [10] = type I/O Port, range 32, base 0xd000, size 8, enabled >>>> bar [14] = type I/O Port, range 32, base 0xc000, size 4, enabled >>>> bar [18] = type I/O Port, range 32, base 0xb000, size 8, enabled >>>> bar [1c] = type I/O Port, range 32, base 0xa000, size 4, enabled >>>> bar [20] = type I/O Port, range 32, base 0x9000, size 16, enabled >>>> bar [24] = type Memory, range 32, base 0xfe8ff800, size 1024, >>>> enabled >>>> cap 01[60] = powerspec 2 supports D0 D3 current D0 >>>> cap 05[50] = MSI supports 4 messages, 64 bit >>>> cap 12[70] = SATA Index-Data Pair >>> What's interesting, is that Asus board with the same chipset doesn't >>> expose MSI support at all: >>> >>> ahci0@pci0:0:17:0: class=0x010601 card=0x43911002 chip=0x43911002 >>> rev=0x00 hdr=0x00 >>> vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' >>> device = 'SB700 SATA Controller [AHCI mode]' >>> class = mass storage >>> subclass = SATA >>> bar [10] = type I/O Port, range 32, base 0xc000, size 8, enabled >>> bar [14] = type I/O Port, range 32, base 0xb000, size 4, enabled >>> bar [18] = type I/O Port, range 32, base 0xa000, size 8, enabled >>> bar [1c] = type I/O Port, range 32, base 0x9000, size 4, enabled >>> bar [20] = type I/O Port, range 32, base 0x8000, size 16, enabled >>> bar [24] = type Memory, range 32, base 0xfbcffc00, size 1024, enabled >>> cap 01[60] = powerspec 2 supports D0 D3 current D0 >>> cap 12[70] = SATA Index-Data Pair >>> >> >> PCI revision register of SMBus device (0:20:0) gives a particular revision of SB7x0. >> SB700 RPR document (section 7.11) says that MSI capability should be disabled if >> the revision is 0x39 or 0x3a, it should be enabled for newer revisions (0x3b, 03c). > >VIA uses ISA bridge to identify chipset, ATI (as you said) - SMBus. >Hell! Why not to do it properly? > >> Those who like to experiment with potentially dangerous things may try playing >> with bit 16 of PCI config register 0x50 of SATA controller device. > >I would prefer it was done by BIOS. Probably ASUS did it, as my board >has 0x3a. Ok while we are talking about ahci(4) on IXP700... Can anyone reproduce the `test unit ready' bug on one of those? Since I saw no reply to my post, http://docs.freebsd.org/cgi/mid.cgi?201001231407.o0NE7l8j002620 maybe the bug is controller-specific? How to reproduce: just try camcontrol tur adaX or cdrecord -scanbus or (at least I think this is the same issue) start xfburn without hal running, then watch for the bus to hang at the next disk access. (Also leaving the disk led on solid here.) With the previous patch, http://people.freebsd.org/~mav/cam-ata.20100119.patch (haven't tested the latest one yet) at least it now seems to recover after some timeout, leaving this in dmesg: (sorry I didn't notice when I first tried, guess I didn't wait long enough...) ahcich2: Timeout on slot 20 ahcich2: is 04000000 cs 00100000 ss 00100000 rs 00100000 tfd 451 serr 00400000 ahcich2: AHCI reset... ahcich2: hardware reset ... ahcich2: SATA connect time=0ms status=00000123 ahcich2: ready wait time=11ms ahcich2: AHCI reset done: device found (ada1:ahcich2:0:0:0): Command timed out (ada1:ahcich2:0:0:0): Retrying Command And pciconf here looks like this: ahci0@pci0:0:17:0: class=0x010601 card=0xb0021458 chip=0x43911002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 SATA Controller [AHCI mode]' class = mass storage subclass = SATA bar [10] = type I/O Port, range 32, base 0xff00, size 8, enabled bar [14] = type I/O Port, range 32, base 0xfe00, size 4, enabled bar [18] = type I/O Port, range 32, base 0xfd00, size 8, enabled bar [1c] = type I/O Port, range 32, base 0xfc00, size 4, enabled bar [20] = type I/O Port, range 32, base 0xfb00, size 16, enabled bar [24] = type Memory, range 32, base 0xfe02f000, size 1024, enabled Thanx, Juergen From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 20:07:14 2010 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 227C51065670 for ; Fri, 29 Jan 2010 20:07:14 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 9ED918FC15 for ; Fri, 29 Jan 2010 20:07:13 +0000 (UTC) Received: by fxm27 with SMTP id 27so690451fxm.3 for ; Fri, 29 Jan 2010 12:07:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=r6A/lih7SlgyuO8sMFuxAy8mTWEb0DCSbAnsyp0fGuA=; b=vr/4tRtd1ZbBgn8Ud6nhydgFr9yAGlea5Pjd2AO9gXNJGdonUyyKXVS0PmT1Y/brCW mEzNzJa9m8G1v8o8j90aF4KWBQKMlfiwkHNUOtaXeimYfM8F2XgdbF3X+LSrsr+IDpUw R+03IX6s2LqYz6y1d1HOXsFKN87OnU8FJZ/9o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=l8ImtGTEdJn1Y69MiDBaYxIJx7VlcuHn95m2nEWz3o104bvPbJrRlEQP2T1FTErR5Y Xpj1xamwBUHjAyFVzFn1sI8UyVPOmRzsfr6bX7/ht/+ANGdcy2/+90raJdnjjbAEg910 XFY/0dewrCKXV2fMY6Ra9W3gFBzuNtPlCLAbE= Received: by 10.102.222.7 with SMTP id u7mr726461mug.1.1264795632457; Fri, 29 Jan 2010 12:07:12 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id j10sm7056781mue.0.2010.01.29.12.07.11 (version=SSLv3 cipher=RC4-MD5); Fri, 29 Jan 2010 12:07:11 -0800 (PST) Sender: Alexander Motin Message-ID: <4B633FED.3030103@FreeBSD.org> Date: Fri, 29 Jan 2010 22:07:09 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Juergen Lock References: <4B55D9D4.1000008@FreeBSD.org> <4B61C688.2050609@FreeBSD.org> <4B61CCB6.4040005@FreeBSD.org> <4B62C97F.7080000@FreeBSD.org> <4B62EDFB.1060103@icyb.net.ua> <201001291949.o0TJnCAa013981@triton8.kn-bremen.de> In-Reply-To: <201001291949.o0TJnCAa013981@triton8.kn-bremen.de> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Andriy Gapon , Yamagi Burmeister Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 20:07:14 -0000 Juergen Lock wrote: > Ok while we are talking about ahci(4) on IXP700... Can anyone reproduce > the `test unit ready' bug on one of those? Since I saw no reply to > my post, > http://docs.freebsd.org/cgi/mid.cgi?201001231407.o0NE7l8j002620 > maybe the bug is controller-specific? How to reproduce: just try > camcontrol tur adaX > or > cdrecord -scanbus > or (at least I think this is the same issue) start xfburn without hal > running, then watch for the bus to hang at the next disk access. > (Also leaving the disk led on solid here.) With the previous patch, > http://people.freebsd.org/~mav/cam-ata.20100119.patch > (haven't tested the latest one yet) at least it now seems to recover > after some timeout, leaving this in dmesg: (sorry I didn't notice > when I first tried, guess I didn't wait long enough...) It is controller specific. Intel and NVidia controllers just return error immediately, as they should, and continue operation. ATI IXP700 - doesn't: > ahcich2: Timeout on slot 20 > ahcich2: is 04000000 cs 00100000 ss 00100000 rs 00100000 tfd 451 serr 00400000 > ahcich2: AHCI reset... > ahcich2: hardware reset ... > ahcich2: SATA connect time=0ms status=00000123 > ahcich2: ready wait time=11ms > ahcich2: AHCI reset done: device found > (ada1:ahcich2:0:0:0): Command timed out > (ada1:ahcich2:0:0:0): Retrying Command But after command timeout channel should reset and continue operation. I've tried to handle this situation, but haven't found a good way. But it is possible to just avoid this situation. As soon as CAM will any way need to tell SIM ATAPI CDB length supported by device, it will be easy for SIM to not send ATAPI commands to ATA devices. I am going to do it, as soon as more important things will stabilize. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 20:12:12 2010 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 63D7F106566B; Fri, 29 Jan 2010 20:12:12 +0000 (UTC) (envelope-from jamesbrandongooch@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id 2FFC28FC0A; Fri, 29 Jan 2010 20:12:11 +0000 (UTC) Received: by pxi13 with SMTP id 13so469324pxi.3 for ; Fri, 29 Jan 2010 12:12:11 -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; bh=4vxwY6z/arfp0MXZZuqFnO2iIskqSXlQoo69HfxWdPk=; b=P+mL5mQn+0VBYaN/+PdCKaBpgxcg6C/C+j2sw7nBJVZdV46QN2yefGt3+R+RyI8DWb 0SFuO37HFcCfoYajImy9kSdihAho9pY06Iucgd6Vpe2aENtLIu/C2ZB4oZItSC3N3yi0 qAXRDXEEw5VBMEUUuEp7fxuFVi/tnUwLEwg0w= 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; b=X1uHcgvG0cwNQ0B2PxRDzs7FdgCgIyCKQ1VtKKv+iSsgHEYTq1HeXSrXnFgIbRtffO k16XxlqdxSQKPsmxbgp4wVN/jiRqLU0IU2TVh371woMP5JsqcXNrRPrclKsUzPzWBLyf qAfH64W5u/EAF7IqWCAGzgC9bFuYZdQtC91WU= MIME-Version: 1.0 Received: by 10.142.152.40 with SMTP id z40mr859910wfd.211.1264795931630; Fri, 29 Jan 2010 12:12:11 -0800 (PST) In-Reply-To: <4e6cba831001290744m6067691ct489c61fe9cd28502@mail.gmail.com> References: <20100128201520.6a114290@ernst.jennejohn.org> <117532D7-75B9-4BE8-A8B6-0A6761064B92@lakerest.net> <4e6cba831001290744m6067691ct489c61fe9cd28502@mail.gmail.com> Date: Fri, 29 Jan 2010 20:12:11 +0000 Message-ID: <179b97fb1001291212p5b0829f2pea28ab36a85751cf@mail.gmail.com> From: Brandon Gooch To: Giovanni Trematerra Content-Type: text/plain; charset=ISO-8859-1 Cc: Attilio Rao , FreeBSD Current , Randall Stewart Subject: Re: A strange thing with yesterday's head.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 20:12:12 -0000 On Fri, Jan 29, 2010 at 3:44 PM, Giovanni Trematerra wrote: > On Thu, Jan 28, 2010 at 10:55 PM, Randall Stewart wrote: >> I was running SCHED_ULE on an 8.0 and everything works >> fine. >> >> On my 2 core head of yesterday I tried both SCHED_ULE AND >> 4BSD.. and got the same results ;-0 >> >> I will try my 4 core when I get home ;-) >> >> R >> On Jan 28, 2010, at 11:15 AM, Gary Jennejohn wrote: >> >>> On Thu, 28 Jan 2010 10:30:37 -0800 >>> Randall Stewart wrote: >>> >>>> All: >>>> >>>> I just found a very strange thing with yesterdays head. >>>> >>>> The program >>>> >>>> http://www.freebsd.org/~rrs/my_thr.c >>>> >>>> I compile it: >>>> >>>> cc -g -o my_thr my_thr.c /usr/lib/libthr.a -lpthread >>>> > > Hi Randal, > I tried your code on an 8-core machine with a fresh head (i386) > I have no problems with both 4BSD and ULE scheduler. > I even upping the value of macro NUM_THREAD to 24 but I didn't notice > nothing strange. > > Have you got a chance to reproduce it on your machines? > > -- > Gianni > _______________________________________________ > 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 ran it on my dual-core, 8-STABLE/ULE laptop. The very first time I ran it, I experienced the temporary "seizure". It took several more runs before I could get it to happen again. When it did act up again, the subsequent runs resulted in VERY strange behavior -- the machine froze, the X server displayed "anomalous" behavior, and my mouse cursor lost it's bearing. After the my_thr program exited, I had to switch to ttyv0 and back to "reset" the mouse and get control of X again. Also -- and I assume this is a side-effect of whatever in the my_thr code (which I haven't read through and would doubtfully understand) -- the X apps I tried to launch (xpdf, Firefox) would not start-up until after the my_thr program exited. -Brandon From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 21:31:55 2010 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 03438106566B for ; Fri, 29 Jan 2010 21:31:55 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id B91CB8FC18 for ; Fri, 29 Jan 2010 21:31:54 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 2CE4D489F5 for ; Fri, 29 Jan 2010 21:31:53 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-7TTQgNjYsC for ; Fri, 29 Jan 2010 21:31:50 +0000 (GMT) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 3A674489F2 for ; Fri, 29 Jan 2010 21:31:50 +0000 (GMT) Message-ID: <4B63533D.1050404@tomjudge.com> Date: Fri, 29 Jan 2010 21:29:33 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: FreeBSD-Current X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Boot Lockup on XenServer 5.5 (r203178) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 21:31:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I am having problems booting my 9 box at r203178 in Citrix XenServer 5.5. The last time I updated this box was October 3rd. The box now hangs at: Trying to mount root from ufs:/dev/ad0s1a I am unable to break to the debugger on this system right now. Any tips would be useful. Thanks tj-tinderbox# uname -a FreeBSD tj-tinderbox.XXXX 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Fri Oct 2 21:15:34 UTC 2009 tj@tj-tinderbox.XXXX:/usr/obj/usr/src/sys/GENERIC i386 tj-tinderbox# cd sys/i386/conf/ tj-tinderbox# svn diff Index: GENERIC =================================================================== - --- GENERIC (revision 203178) +++ GENERIC (working copy) @@ -76,7 +76,12 @@ options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed +options DEBUG_LOCKS +options DEBUG_VFS_LOCKS +options DIAGNOSTIC +options BREAK_TO_DEBUGGER + # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic # I/O APIC tj-tinderbox# cd /usr/src tj-tinderbox# svn info Path: . URL: http://svn.freebsd.org/base/head Repository Root: http://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 203178 Node Kind: directory Schedule: normal Last Changed Author: marcel Last Changed Rev: 203177 Last Changed Date: 2010-01-29 20:37:12 +0000 (Fri, 29 Jan 2010) - -- TJU13-ARIN -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLY1M9AAoJEMSwVS7lr0OdQqAIALdUaH9YQy7boSKDOOOdNgTW s/ZLhrJx3xbyE5d+elKdoRFNk3uUNnNxUO1aZGIIjNYfc+0Vb/TL6axNQuRqntry E1s80vsqwWKSjtFsYEufX3ERArr60Z+tCElVp7eFXaEa57Rw5CvFQtRE/uQtv2Q7 /s1QSaVbfo9WMkcUmpCWFPbzr3TTHdsYRGd/SZX9UHbPjWr6i4D3wtGfHUizP2t/ HSh3jy+DOwDYLHB/SxxZdVjHZ8fZH2sw3ETB19NCniLxDquLTHElERXVFAfkojc2 fGo+4eQo3gKIPu32TSEtOoAheYGMxhopnfdwYcNSVoY3N7HOUSZ3b1BcD03CZio= =e4o5 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 21:49:58 2010 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 869FD106566C for ; Fri, 29 Jan 2010 21:49:58 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id DD32F8FC1C for ; Fri, 29 Jan 2010 21:49:57 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id DE263489F5 for ; Fri, 29 Jan 2010 21:49:56 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q9+JI7GeUhC for ; Fri, 29 Jan 2010 21:49:53 +0000 (GMT) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 24F69489F2 for ; Fri, 29 Jan 2010 21:49:52 +0000 (GMT) Message-ID: <4B635777.70200@tomjudge.com> Date: Fri, 29 Jan 2010 21:47:35 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: FreeBSD-Current References: <4B63533D.1050404@tomjudge.com> In-Reply-To: <4B63533D.1050404@tomjudge.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: Boot Lockup on XenServer 5.5 (r203178) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 21:49:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Judge wrote: > Hi, > > I am having problems booting my 9 box at r203178 in Citrix XenServer 5.5. > > The last time I updated this box was October 3rd. > > The box now hangs at: > > Trying to mount root from ufs:/dev/ad0s1a > > I have just worked out how to access the VM's serial port so I switched the console over to it and managed to capture a boot verbose: ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ ³ ³ ³ ______ ³ ³ | ____| __ ___ ___ ³ Welcome to FreeBSD! ³ | |__ | '__/ _ \/ _ \ ³ ³ | __|| | | __/ __/ ³ ³ | | | | | | | ³ 1. Boot FreeBSD [default] ³ |_| |_| \___|\___| ³ 2. Boot FreeBSD with ACPI disabled ³ ____ _____ _____ ³ 3. Boot FreeBSD in Safe Mode ³ | _ \ / ____| __ \ ³ 4. Boot FreeBSD in single user mode ³ | |_) | (___ | | | | ³ 5. Boot FreeBSD with verbose logging ³ | _ < \___ \| | | | ³ 6. Escape to loader prompt ³ | |_) |____) | |__| | ³ 7. Reboot ³ | | | | ³ ³ |____/|_____/|_____/ ³ ³ ³ ³ ³ ³ ³ Select option, [Enter] for default ³ ³ or [Space] to pause timer 7 ³ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ GDB: no debug ports present KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009fc00 SMAP type=02 base=000000000009fc00 len=0000000000000400 SMAP type=02 base=00000000000e0000 len=0000000000020000 SMAP type=01 base=0000000000100000 len=00000000ef2f6400 SMAP type=02 base=00000000ef3f6400 len=0000000000c04c00 SMAP type=02 base=00000000efffc000 len=0000000000004000 SMAP type=01 base=0000000100000000 len=000000000a000000 163840K of memory above 4GB ignored Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #9 r203178M: Fri Jan 29 21:09:00 UTC 2010 tj@tj-tinderbox.chicago.mintel.ad:/usr/obj/usr/src/sys/GENERIC i386 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc114c000. Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1995028866 Hz CPU: Intel(R) Xeon(R) CPU E5335 @ 2.00GHz (1995.03-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0x781fbff Features2=0x80002201> AMD Features=0x20000000 AMD Features2=0x1 TSC: P-state invariant Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size L2 cache: 4096 kbytes, 16-way associative, 64 bytes/line real memory = 4194304000 (4000 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000001426000 - 0x00000000eb043fff, 3921797120 bytes (957470 pages) avail memory = 3919826944 (3738 MB) Table 'FACP' at 0xef4f79e0 Table 'APIC' at 0xef4f7ae0 APIC: Found table at 0xef4f7ae0 MP Configuration Table version 1.4 found at 0xc00fcc00 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 2 ACPI ID 1: enabled SMP: Added CPU 2 (AP) MADT: Found CPU APIC ID 4 ACPI ID 2: enabled SMP: Added CPU 4 (AP) MADT: Found CPU APIC ID 6 ACPI ID 3: enabled SMP: Added CPU 6 (AP) ACPI APIC Table: INTR: Adding local APIC 2 as a target INTR: Adding local APIC 4 as a target INTR: Adding local APIC 6 as a target FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 4 package(s) x 1 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 bios32: Found BIOS32 Service Directory header at 0xc00fa8f0 bios32: Entry = 0xfa900 (c00fa900) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xa940 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 APIC: CPU 1 has ACPI ID 1 APIC: CPU 2 has ACPI ID 2 APIC: CPU 3 has ACPI ID 3 ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 ACPI: RSDP 0xea010 00024 (v2 Xen) ACPI: XSDT 0xef4f7ba0 0003C (v1 Xen HVM 00000000 HVML 00000000) ACPI: FACP 0xef4f79e0 000F4 (v4 Xen HVM 00000000 HVML 00000000) ACPI: DSDT 0xef4f6840 01116 (v2 Xen HVM 00000000 INTL 20060707) ACPI: FACS 0xef4f6800 00040 ACPI: APIC 0xef4f7ae0 00080 (v2 Xen HVM 00000000 HVML 00000000) ACPI: HPET 0xef4f7b60 00038 (v1 Xen HVM 00000000 HVML 00000000) MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's -> intpin 0 MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 MADT: Interrupt override: source 5, irq 5 ioapic0: intpin 5 trigger: level ioapic0: intpin 5 polarity: low MADT: Interrupt override: source 10, irq 10 ioapic0: intpin 10 trigger: level ioapic0: intpin 10 polarity: low MADT: Interrupt override: source 11, irq 11 ioapic0: intpin 11 trigger: level ioapic0: intpin 11 polarity: low MADT: Forcing active-low polarity and level trigger for SCI ioapic0: intpin 9 polarity: low ioapic0: intpin 9 trigger: level ioapic0 irqs 0-47 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 wlan: <802.11 Link Layer> nfslock: pseudo-device kbd: new array size 4 kbd1 at kbdmux0 mem: Pentium Pro MTRR support enabled io: null: random: hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 npx0: INT 16 interface acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 acpi0: [MPSAFE] acpi0: [ITHREAD] acpi0: wakeup code va 0xc72ab000 pa 0x1000 pci_open(1): mode 1 addr port (0x0cf8) is 0x80000000 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=12378086) pcibios: BIOS version 2.10 AcpiOsDerivePciId: \_SB_.PCI0.ISA_.PIRQ -> bus 0 dev 1 func 0 ACPI timer: 0/15 0/16 0/13 0/12 0/14 0/21 0/66 0/18 0/9 0/126 -> 0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x1f48-0x1f4b on acpi0 pci_link0: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 5 10 11 Validation 0 5 N 0 5 10 11 After Disable 0 255 N 0 5 10 11 pci_link1: Index IRQ Rtd Ref IRQs Initial Probe 0 10 N 0 5 10 11 Validation 0 10 N 0 5 10 11 After Disable 0 255 N 0 5 10 11 pci_link2: Index IRQ Rtd Ref IRQs Initial Probe 0 11 N 0 5 10 11 Validation 0 11 N 0 5 10 11 After Disable 0 255 N 0 5 10 11 pci_link3: Index IRQ Rtd Ref IRQs Initial Probe 0 5 N 0 5 10 11 Validation 0 5 N 0 5 10 11 After Disable 0 255 N 0 5 10 11 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 62500000 opts: legacy_route 64-bit Timecounter "HPET" frequency 62500000 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: domain=0, physical bus=0 found-> vendor=0x8086, dev=0x1237, revid=0x02 domain=0, bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7000, revid=0x00 domain=0, bus=0, slot=1, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7010, revid=0x00 domain=0, bus=0, slot=1, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type I/O Port, range 32, base 0xc220, size 4, enabled found-> vendor=0x8086, dev=0x7020, revid=0x01 domain=0, bus=0, slot=1, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=5 map[20]: type I/O Port, range 32, base 0xc200, size 5, enabled pcib0: matched entry for 0.1.INTD pcib0: slot 1 INTD hardwired to IRQ 23 found-> vendor=0x8086, dev=0x7113, revid=0x01 domain=0, bus=0, slot=1, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 20 found-> vendor=0x1013, dev=0x00b8, revid=0x00 domain=0, bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type Prefetchable Memory, range 32, base 0xf0000000, size 25, enabled map[14]: type Memory, range 32, base 0xf3000000, size 12, enabled found-> vendor=0x5853, dev=0x0001, revid=0x01 domain=0, bus=0, slot=3, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 map[10]: type I/O Port, range 32, base 0xc000, size 8, enabled map[14]: type Prefetchable Memory, range 32, base 0xf2000000, size 24, enabled pcib0: matched entry for 0.3.INTC pcib0: slot 3 INTC hardwired to IRQ 30 found-> vendor=0x10ec, dev=0x8139, revid=0x20 domain=0, bus=0, slot=4, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[10]: type I/O Port, range 32, base 0xc100, size 8, enabled map[14]: type Memory, range 32, base 0xf3001000, size 8, enabled pcib0: matched entry for 0.4.INTA pcib0: slot 4 INTA hardwired to IRQ 32 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc220-0xc22f at device 1.1 on pci0 ata0: on atapci0 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0xff msb=0xff ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 49 ata0: [MPSAFE] ata0: [ITHREAD] ata1: on atapci0 ata1: reset tp1 mask=03 ostat0=50 ostat1=50 ata1: stat0=0x50 err=0x01 lsb=0xff msb=0xff ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=50 stat1=00 devices=0x20001 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 50 ata1: [MPSAFE] ata1: [ITHREAD] uhci0: port 0xc200-0xc21f irq 23 at device 1.2 on pci0 ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 51 uhci0: [MPSAFE] uhci0: [ITHREAD] usbus0: controller did not stop usbus0: on uhci0 pci0: at device 1.3 (no driver attached) vgapci0: mem 0xf0000000-0xf1ffffff,0xf3000000-0xf3000fff at device 2.0 on pci0 pci0: at device 3.0 (no driver attached) re0: port 0xc100-0xc1ff mem 0xf3001000-0xf30010ff irq 32 at device 4.0 on pci0 re0: Chip rev. 0x74800000 re0: MAC rev. 0x00000000 miibus0: on re0 rlphy0: PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto re0: bpf attached re0: Ethernet address: 0e:90:13:eb:42:84 ioapic0: routing intpin 32 (PCI IRQ 32) to lapic 0 vector 52 re0: [MPSAFE] re0: [FILTER] atrtc0: port 0x70-0x71 irq 8 on acpi0 atrtc0: registered as a time-of-day clock (resolution 1000000us) psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0061 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x1d0000 ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 53 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] psm0: current command byte:0061 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 psm: status 00 02 64 psm: status 00 00 64 psm: status 00 03 64 psm: status 00 03 64 psm: data 08 00 00 psm: status 00 02 64 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 54 psm0: [GIANT-LOCKED] psm0: [ITHREAD] psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 uart0: port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 55 uart0: [FILTER] uart0: fast interrupt uart0: console (9600,n,8,1) ppc0: using extended I/O port range ppc0: SPP ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ioapic0: routing intpin 7 (ISA IRQ 7) to lapic 0 vector 56 ppc0: [MPSAFE] ppc0: [ITHREAD] ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached plip0: [MPSAFE] plip0: [ITHREAD] lpt0: on ppbus0 lpt0: [MPSAFE] lpt0: [ITHREAD] lpt0: Interrupt-driven port ppi0: on ppbus0 cpu0: on acpi0 cpu0: switching to generic Cx mode cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 ahc_isa_probe 0: ioport 0xc00 alloc failed ex_isa_identify() pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff isa_probe_children: disabling PnP devices pmtimer0 on isa0 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it atrtc: atrtc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sc: sc0 already exists; skipping it uart: uart0 already exists; skipping it isa_probe_children: probing non-PnP devices orm0: at iomem 0xd0000-0xd7fff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 245763 -> 100000 procfs registered lapic: Divisor 2, Frequency 50000945 Hz ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 57 Timecounter "TSC" frequency 1995028866 Hz quality -100 Timecounters tick every 1.000 msec vlan: initialized, using hash tables with chaining lo0: bpf attached hptrr: no controller detected. ata0: Identifying devices: 00000001 ata0: New devices: 00000001 ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire usbus0: 12Mbps Full Speed USB v1.0 ad0: setting WDMA2 ad0: 102400MB at ata0-master WDMA2 ad0: 209715200 sectors [208050C/16H/63S] 16 sectors/interrupt 1 depth queue ugen0.1: at usbus0 uhub0: on usbus0 Expensive timeout(9) function: 0xc08cee70(0xc7755900) 0.027107631 s GEOM: new disk ad0 ad0: Intel check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed ata1: Identifying devices: 00020001 ata1: New devices: 00020001 ata1-slave: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire GEOM: ad0s1: geometry does not match label (255h,63s != 16h,63s). uhub0: 2 ports with 2 removable, self powered ata1: reiniting channel .. ata1: reset tp1 mask=03 ostat0=50 ostat1=50 ata1: stat0=0x50 err=0x01 lsb=0xff msb=0xff ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=50 stat1=00 devices=0x20001 ata1: reinit done .. unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 Expensive timeout(9) function: 0xc0571910(0xc7977bf4) 0.150055583 s ugen0.2: at usbus0 ums0: on usbus0 ums0: 3 buttons and [Z] coordinates ID=0 ata1: reiniting channel .. ata1: reset tp1 mask=03 ostat0=50 ostat1=00 ata1: stat0=0x50 err=0x01 lsb=0xff msb=0xff ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=50 stat1=00 devices=0x20001 ata1: reinit done .. unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 acd0: setting WDMA2 acd0: CDROM drive at ata1 as slave acd0: read 689KB/s (689KB/s), 512KB buffer, WDMA2 acd0: Reads: acd0: Writes: acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc ATA PseudoRAID loaded SMP: AP CPU #3 Launched! cpu3 AP: ID: 0x06000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 SMP: AP CPU #2 Launched! cpu2 AP: ID: 0x04000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x02000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 Roapicf0l:o wrtoaubtlien gc lienatpnine r4 s(taIrStAe dI Q 4) to lapic 2 vector 48 ioapic0: routing intpin 7 (ISA IRQ 7) to lapic 4 vector 48 ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 6 vector 48 ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 2 vector 49 ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 4 vector 49 ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 6 vector 49 ioapic0: routing intpin 32 (PCI IRQ 32) to lapic 2 vector 50 WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. Trying to mount root from ufs:/dev/ad0s1a ct_to_ts([2010-01-29 21:47:24]) = 1264801644.000000000 start_init: trying /sbin/init Entropy harvesti - -- TJU13-ARIN -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLY1d3AAoJEMSwVS7lr0OdZxYIAKLOkaU+V7h5GxGOastdUcl0 w6nwFHFHzVMzB+3AwaBBIfSkFIka8gzqqRm5uju47y5FmZ+BRoOVkmMmWNr9KWQK 3imj2DItQsCfqcpjMdMfcFNt71gY6XUQ9sK8RmbiVLSnXPqHYQNPgiDlBAqs+ntb zMUEO/fiZmOgWjVmifdMvER6ytEJAV420lQ09PRK+6K8joKDRS7GjYzItfizaYg+ WOYJq6z1I2fFQBpX7AqbWzKIG8z4RSaboEMHG+HzkU1J8iLnwxTfkpsX2yipgo9E xL6HokYkIx4xNi/cHzVkMDalSWGG2EAIqiK7B+y8TgrbHbDIgZEAc30eUyuMrvM= =PVz9 -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 21:50:40 2010 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 012F31065672; Fri, 29 Jan 2010 21:50:40 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id B41328FC1A; Fri, 29 Jan 2010 21:50:39 +0000 (UTC) Received: from toad.stack.nl (toad.stack.nl [IPv6:2001:610:1108:5010::135]) by mx1.stack.nl (Postfix) with ESMTP id 9818435988D; Fri, 29 Jan 2010 22:50:38 +0100 (CET) Received: by toad.stack.nl (Postfix, from userid 1677) id 8E84C73F9D; Fri, 29 Jan 2010 22:50:38 +0100 (CET) Date: Fri, 29 Jan 2010 22:50:38 +0100 From: Jilles Tjoelker To: =?iso-8859-1?Q?G=E1bor_K=F6vesd=E1n?= Message-ID: <20100129215038.GA95021@stack.nl> References: <20100119212019.GL59590@deviant.kiev.zoral.com.ua> <4B56CACF.50508@FreeBSD.org> <4B5B4F4B.3030201@FreeBSD.org> <20100124091911.GI31243@server.vk2pj.dyndns.org> <4B5C27B9.1080805@FreeBSD.org> <20100124113718.GC3877@deviant.kiev.zoral.com.ua> <4B5CD916.1060003@FreeBSD.org> <20100126222338.GA40281@stack.nl> <4B633F2D.6010804@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4B633F2D.6010804@FreeBSD.org> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Xin LI , current@freebsd.org Subject: Re: NLS/strerror efficiency X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 21:50:40 -0000 On Fri, Jan 29, 2010 at 09:03:57PM +0100, Gábor Kövesdán wrote: > >> +static pthread_rwlock_t rwlock; > > Use PTHREAD_RWLOCK_INITIALIZER here to avoid problems with initializing > > the lock. > I talked to delphij@ about this. Shouldn't pthread_rwlock_rdlock() and > pthread_rwlock_wrlock() automatically initialize the lock if it is NULL? > We even removed the pthread_rwlock_init() call and it just works. If you look in you will notice that PTHREAD_RWLOCK_INITIALIZER is simply NULL. Also, pthread_rwlock_t is just a pointer. However, this may well change later on to allow rwlocks in shared memory, making pthread_rwlock_t a struct and PTHREAD_RWLOCK_INITIALIZER something more complicated. It already works that way in various other implementations, and sem_t has already been changed similarly in 9-CURRENT. > > Hmm, so an error for one language makes it give up for all other > > languages too? It is possible that a catalog is only available in a few > > languages. > Fixed. > >> + UNLOCK(NLERR); > >> + NLRETERR(np->caterrno); > >> + } else if (strcmp(np->lang, lang) == 0) { > > Some code below can apparently set np->lang = NULL, how does that work? > NULL means locale-independent open, i.e. catopen() is given an absolute > path. We could add more if's to separate those cases more but that would > result in more code, while this just works. If name is set to an > absolute path, lang will be NULL and strcmp(NULL, NULL) will return 0, > so it will match. strcmp(3) and the POSIX spec do not specifically allow passing NULL to strcmp(), so it is not valid to do so. It seems that gcc treats a literal strcmp(NULL, NULL) specially, replacing it with 0, but any real strcmp call involving NULL segfaults. This probably needs to become something more complicated like (np->lang == NULL || lang == NULL ? np->lang == lang : strcmp(np->lang, lang) == 0) > @@ -374,8 +376,8 @@ > } > > if (_fstat(fd, &st) != 0) { > + _close(fd); > SAVEFAIL(name, errno); > - _close(fd); > return (NLERR); > } Be careful that cleanup actions like these might overwrite errno. munmap() and _close() are system calls and they should not fail in this case (read-only file), so it should be safe. It is cleaner to save errno immediately after the failing call, though. > @@ -390,8 +392,8 @@ > > if (ntohl((u_int32_t)((struct _nls_cat_hdr *)data)->__magic) != > _NLS_MAGIC) { > + munmap(data, (size_t)st.st_size); > SAVEFAIL(name, errno); > - munmap(data, (size_t)st.st_size); > NLRETERR(EINVAL); > } The errno value seems garbage. SAVEFAIL with EINVAL, or perhaps use EFTYPE (in both places). The cast to size_t reminds me to ask what happens in the pathological case of a catalog file bigger than a size_t can describe, which may happen on 32-bit systems. I think this should fail rather than mapping the initial size%(1<<32) part. -- Jilles Tjoelker From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 21:54:00 2010 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 09D621065696; Fri, 29 Jan 2010 21:54: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 104CC8FC20; Fri, 29 Jan 2010 21:53:58 +0000 (UTC) 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 XAA13834; Fri, 29 Jan 2010 23:53:57 +0200 (EET) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Naymq-0005rM-OW; Fri, 29 Jan 2010 23:53:56 +0200 Message-ID: <4B6358F3.7080908@icyb.net.ua> Date: Fri, 29 Jan 2010 23:53:55 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.23 (X11/20091128) MIME-Version: 1.0 To: Alexander Motin References: <4B55D9D4.1000008@FreeBSD.org> <4B61C688.2050609@FreeBSD.org> <4B61CCB6.4040005@FreeBSD.org> <4B62C97F.7080000@FreeBSD.org> <4B62EDFB.1060103@icyb.net.ua> <201001291949.o0TJnCAa013981@triton8.kn-bremen.de> <4B633FED.3030103@FreeBSD.org> In-Reply-To: <4B633FED.3030103@FreeBSD.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-current@FreeBSD.org, Juergen Lock , Yamagi Burmeister Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 21:54:00 -0000 on 29/01/2010 22:07 Alexander Motin said the following: > Juergen Lock wrote: >> Ok while we are talking about ahci(4) on IXP700... Can anyone reproduce >> the `test unit ready' bug on one of those? Since I saw no reply to >> my post, >> http://docs.freebsd.org/cgi/mid.cgi?201001231407.o0NE7l8j002620 >> maybe the bug is controller-specific? How to reproduce: just try >> camcontrol tur adaX >> or >> cdrecord -scanbus >> or (at least I think this is the same issue) start xfburn without hal >> running, then watch for the bus to hang at the next disk access. >> (Also leaving the disk led on solid here.) With the previous patch, >> http://people.freebsd.org/~mav/cam-ata.20100119.patch >> (haven't tested the latest one yet) at least it now seems to recover >> after some timeout, leaving this in dmesg: (sorry I didn't notice >> when I first tried, guess I didn't wait long enough...) > > It is controller specific. Intel and NVidia controllers just return > error immediately, as they should, and continue operation. ATI IXP700 - > doesn't: I have this simple patch in my local tree: --- a/sys/cam/ata/ata_xpt.c +++ b/sys/cam/ata/ata_xpt.c @@ -1341,6 +1341,20 @@ ata_action(union ccb *start_ccb) (*(sim->sim_action))(sim, start_ccb); break; } + case XPT_SCSI_IO: + { + struct cam_ed *device; + + device = start_ccb->ccb_h.path->device; + if (device->protocol == PROTO_ATA) { + xpt_print(start_ccb->ccb_h.path, + "XPT_SCSI_IO command for device with PROTO_ATA\n"); + start_ccb->ccb_h.status = CAM_REQ_INVALID; + xpt_done(start_ccb); + return; + } + /* FALLTHROUGH */ + } default: xpt_action_default(start_ccb); break; Here's what it does: $ drecord -scanbus Cdrecord-ProDVD-ProBD-Clone 2.01.01a72 (amd64-unknown-freebsd9.0) Copyright (C) 1995-2010 Jörg Schilling Using libscg version 'schily-0.9'. scsibus0: 0,0,0 0) '' '' '' NON CCS Disk 0,1,0 1) * 0,2,0 2) * 0,3,0 3) * 0,4,0 4) * 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * scsibus1: 1,0,0 100) '' '' '' NON CCS Disk 1,1,0 101) * 1,2,0 102) * 1,3,0 103) * 1,4,0 104) * 1,5,0 105) * 1,6,0 106) * 1,7,0 107) * scsibus5: 5,0,0 500) 'Optiarc ' 'DVD RW AD-7191S ' '1.02' Removable CD-ROM 5,1,0 501) * 5,2,0 502) * 5,3,0 503) * 5,4,0 504) * 5,5,0 505) * 5,6,0 506) * 5,7,0 507) * And in dmesg: kernel: (pass0:ahcich0:0:0:0): XPT_SCSI_IO command for device with PROTO_ATA last message repeated 2 times kernel: (pass1:ahcich1:0:0:0): XPT_SCSI_IO command for device with PROTO_ATA I remember that this patch is not perfect, but it works for my simple desktop setup. No bad side-effects from it either. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 21:58:34 2010 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 C198E106566C for ; Fri, 29 Jan 2010 21:58:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 3513A8FC18 for ; Fri, 29 Jan 2010 21:58:33 +0000 (UTC) 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 o0TLwTH9084008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jan 2010 23:58:29 +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 o0TLwT7k048403; Fri, 29 Jan 2010 23:58:29 +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 o0TLwTh9048402; Fri, 29 Jan 2010 23:58:29 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 29 Jan 2010 23:58:29 +0200 From: Kostik Belousov To: Tom Judge Message-ID: <20100129215829.GR3877@deviant.kiev.zoral.com.ua> References: <4B63533D.1050404@tomjudge.com> <4B635777.70200@tomjudge.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VIdDLDeyEAhJQ0DY" Content-Disposition: inline In-Reply-To: <4B635777.70200@tomjudge.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at 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 Cc: FreeBSD-Current Subject: Re: Boot Lockup on XenServer 5.5 (r203178) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 21:58:34 -0000 --VIdDLDeyEAhJQ0DY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jan 29, 2010 at 09:47:35PM +0000, Tom Judge wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Tom Judge wrote: > > Hi, > >=20 > > I am having problems booting my 9 box at r203178 in Citrix XenServer 5.= 5. > >=20 > > The last time I updated this box was October 3rd. > >=20 > > The box now hangs at: > >=20 > > Trying to mount root from ufs:/dev/ad0s1a > >=20 > >=20 >=20 > I have just worked out how to access the VM's serial port so I switched > the console over to it and managed to capture a boot verbose: > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > Trying to mount root from ufs:/dev/ad0s1a > ct_to_ts([2010-01-29 21:47:24]) =3D 1264801644.000000000 > start_init: trying /sbin/init > Entropy harvesti Do you have /dev directory ? --VIdDLDeyEAhJQ0DY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktjWgQACgkQC3+MBN1Mb4jSkQCgsq49Unzg/vhQkhMFWPGRrkt1 M1EAoNV+WfLi+nI+fcZFsaz2gPMSooi7 =mAaw -----END PGP SIGNATURE----- --VIdDLDeyEAhJQ0DY-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 22:02:37 2010 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 7E1181065698 for ; Fri, 29 Jan 2010 22:02:37 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id D7DF28FC16 for ; Fri, 29 Jan 2010 22:02:36 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id F0A31489F5; Fri, 29 Jan 2010 22:02:35 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SQykyTITyEy; Fri, 29 Jan 2010 22:02:33 +0000 (GMT) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id AA9D8489F4; Fri, 29 Jan 2010 22:02:32 +0000 (GMT) Message-ID: <4B635A6F.9020509@tomjudge.com> Date: Fri, 29 Jan 2010 22:00:15 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: Kostik Belousov References: <4B63533D.1050404@tomjudge.com> <4B635777.70200@tomjudge.com> <20100129215829.GR3877@deviant.kiev.zoral.com.ua> In-Reply-To: <20100129215829.GR3877@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: Boot Lockup on XenServer 5.5 (r203178) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 22:02:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kostik Belousov wrote: > On Fri, Jan 29, 2010 at 09:47:35PM +0000, Tom Judge wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Tom Judge wrote: >>> Hi, >>> >>> I am having problems booting my 9 box at r203178 in Citrix XenServer 5.5. >>> >>> The last time I updated this box was October 3rd. >>> >>> The box now hangs at: >>> >>> Trying to mount root from ufs:/dev/ad0s1a >>> >>> >> I have just worked out how to access the VM's serial port so I switched >> the console over to it and managed to capture a boot verbose: > >> WARNING: DIAGNOSTIC option enabled, expect reduced performance. >> Trying to mount root from ufs:/dev/ad0s1a >> ct_to_ts([2010-01-29 21:47:24]) = 1264801644.000000000 >> start_init: trying /sbin/init >> Entropy harvesti > > Do you have /dev directory ? > I do have a /dev directory in the vm and have access to /dev on the XenServer host. I reduced the CPU's in the system to 1 and I got a few more lines: flowtable cleaner started Trying to mount root from ufs:/dev/ad0s1a ct_to_ts([2010-01-29 21:59:05]) = 1264802345.000000000 start_init: trying /sbin/init Entropy harvestire0: link state changed to UP ts_to_ct(1264802364.324944423) = [2010-01-29 21:59:24] Expensive timeout(9) function: 0xc0b78fb0(0xc0f7c040) 0.977547221 s TJ - -- TJU13-ARIN -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLY1pvAAoJEMSwVS7lr0OdJqEH/iz85/TDfb8ig6NTuzzf76Ny 18lLkve9RGT6N6yCAjiN8OkdOwYOIV/57ui/GPQGy/PE+tg5ZZiUcEVQeLfpKavn ULf14wEnrp6wUrhsfxiuFVAjCYugAgDvOh7+Eq2MK09uuD65r4T5qawJMWB+yKo6 nfTuz1IuzQdo1Ff4b296KsBYjhLDNaSZVBP4nGONpqEeiW6Nge/tzImKj+1gmby/ XeqNlWIcRHDZhlcrCL42mvkQexIjH0qAdnNK8ybxb0mX67IdzpaUvWB6y9DgYuxG aVkjtuDrC5S41tK+eCuxk4YZ/4fcdx7/5bFX0WvHumIy93raaekEyJJaiy8umKs= =FKHU -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 22:52:49 2010 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 1F7AB106566B for ; Fri, 29 Jan 2010 22:52:49 +0000 (UTC) (envelope-from tom@tomjudge.com) Received: from tomjudge.vm.bytemark.co.uk (tomjudge.vm.bytemark.co.uk [80.68.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id 75A808FC13 for ; Fri, 29 Jan 2010 22:52:48 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 70E12489F5 for ; Fri, 29 Jan 2010 22:52:47 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at tomjudge.vm.bytemark.co.uk Received: from tomjudge.vm.bytemark.co.uk ([127.0.0.1]) by localhost (tomjudge.vm.bytemark.co.uk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeynOV0Ce4Pw for ; Fri, 29 Jan 2010 22:52:44 +0000 (GMT) Received: from rita.nodomain (unknown [192.168.205.6]) by tomjudge.vm.bytemark.co.uk (Postfix) with ESMTP id 84B6B489F4 for ; Fri, 29 Jan 2010 22:52:42 +0000 (GMT) Message-ID: <4B636631.8070405@tomjudge.com> Date: Fri, 29 Jan 2010 22:50:25 +0000 From: Tom Judge User-Agent: Thunderbird 2.0.0.23 (X11/20090822) MIME-Version: 1.0 To: FreeBSD-Current References: <4B63533D.1050404@tomjudge.com> <4B635777.70200@tomjudge.com> In-Reply-To: <4B635777.70200@tomjudge.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: Boot Lockup on XenServer 5.5 (r203178) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 22:52:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Judge wrote: > Tom Judge wrote: >> Hi, > >> I am having problems booting my 9 box at r203178 in Citrix XenServer 5.5. > >> The last time I updated this box was October 3rd. > >> The box now hangs at: > >> Trying to mount root from ufs:/dev/ad0s1a > > So it seems it just takes a painfully long time for the system to boot now, I walked away from my desk for a bit and returned after about 45 mins and the system had booted and there was a login prompt. TJ > > I have just worked out how to access the VM's serial port so I switched > the console over to it and managed to capture a boot verbose: > > ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ > ³ ³ > ³ ³ ______ > ³ ³ | ____| __ ___ ___ > ³ Welcome to FreeBSD! ³ | |__ | '__/ _ \/ _ \ > ³ ³ | __|| | | __/ __/ > ³ ³ | | | | | | | > ³ 1. Boot FreeBSD [default] ³ |_| |_| \___|\___| > ³ 2. Boot FreeBSD with ACPI disabled ³ ____ _____ _____ > ³ 3. Boot FreeBSD in Safe Mode ³ | _ \ / ____| __ \ > ³ 4. Boot FreeBSD in single user mode ³ | |_) | (___ | | | | > ³ 5. Boot FreeBSD with verbose logging ³ | _ < \___ \| | | | > ³ 6. Escape to loader prompt ³ | |_) |____) | |__| | > ³ 7. Reboot ³ | | | | > ³ ³ |____/|_____/|_____/ > ³ ³ > ³ ³ > ³ ³ > ³ Select option, [Enter] for default ³ > ³ or [Space] to pause timer 7 ³ > ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ > > > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > SMAP type=01 base=0000000000000000 len=000000000009fc00 > SMAP type=02 base=000000000009fc00 len=0000000000000400 > SMAP type=02 base=00000000000e0000 len=0000000000020000 > SMAP type=01 base=0000000000100000 len=00000000ef2f6400 > SMAP type=02 base=00000000ef3f6400 len=0000000000c04c00 > SMAP type=02 base=00000000efffc000 len=0000000000004000 > SMAP type=01 base=0000000100000000 len=000000000a000000 > 163840K of memory above 4GB ignored > Copyright (c) 1992-2010 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 9.0-CURRENT #9 r203178M: Fri Jan 29 21:09:00 UTC 2010 > tj@tj-tinderbox.chicago.mintel.ad:/usr/obj/usr/src/sys/GENERIC i386 > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > Preloaded elf kernel "/boot/kernel/kernel" at 0xc114c000. > Timecounter "i8254" frequency 1193182 Hz quality 0 > Calibrating TSC clock ... TSC clock: 1995028866 Hz > CPU: Intel(R) Xeon(R) CPU E5335 @ 2.00GHz (1995.03-MHz > 686-class CPU) > Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 > > Features=0x781fbff > Features2=0x80002201> > AMD Features=0x20000000 > AMD Features2=0x1 > TSC: P-state invariant > > Instruction TLB: 4 KB Pages, 4-way set associative, 128 entries > 1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size > 1st-level data cache: 32 KB, 8-way set associative, 64 byte line size > L2 cache: 4096 kbytes, 16-way associative, 64 bytes/line > real memory = 4194304000 (4000 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) > 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) > 0x0000000001426000 - 0x00000000eb043fff, 3921797120 bytes (957470 pages) > avail memory = 3919826944 (3738 MB) > Table 'FACP' at 0xef4f79e0 > Table 'APIC' at 0xef4f7ae0 > APIC: Found table at 0xef4f7ae0 > MP Configuration Table version 1.4 found at 0xc00fcc00 > APIC: Using the MADT enumerator. > MADT: Found CPU APIC ID 0 ACPI ID 0: enabled > SMP: Added CPU 0 (AP) > MADT: Found CPU APIC ID 2 ACPI ID 1: enabled > SMP: Added CPU 2 (AP) > MADT: Found CPU APIC ID 4 ACPI ID 2: enabled > SMP: Added CPU 4 (AP) > MADT: Found CPU APIC ID 6 ACPI ID 3: enabled > SMP: Added CPU 6 (AP) > ACPI APIC Table: > INTR: Adding local APIC 2 as a target > INTR: Adding local APIC 4 as a target > INTR: Adding local APIC 6 as a target > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > FreeBSD/SMP: 4 package(s) x 1 core(s) > cpu0 (BSP): APIC ID: 0 > cpu1 (AP): APIC ID: 2 > cpu2 (AP): APIC ID: 4 > cpu3 (AP): APIC ID: 6 > bios32: Found BIOS32 Service Directory header at 0xc00fa8f0 > bios32: Entry = 0xfa900 (c00fa900) Rev = 0 Len = 1 > pcibios: PCI BIOS entry at 0xf0000+0xa940 > Other BIOS signatures found: > APIC: CPU 0 has ACPI ID 0 > APIC: CPU 1 has ACPI ID 1 > APIC: CPU 2 has ACPI ID 2 > APIC: CPU 3 has ACPI ID 3 > ULE: setup cpu 0 > ULE: setup cpu 1 > ULE: setup cpu 2 > ULE: setup cpu 3 > ACPI: RSDP 0xea010 00024 (v2 Xen) > ACPI: XSDT 0xef4f7ba0 0003C (v1 Xen HVM 00000000 HVML 00000000) > ACPI: FACP 0xef4f79e0 000F4 (v4 Xen HVM 00000000 HVML 00000000) > ACPI: DSDT 0xef4f6840 01116 (v2 Xen HVM 00000000 INTL 20060707) > ACPI: FACS 0xef4f6800 00040 > ACPI: APIC 0xef4f7ae0 00080 (v2 Xen HVM 00000000 HVML 00000000) > ACPI: HPET 0xef4f7b60 00038 (v1 Xen HVM 00000000 HVML 00000000) > MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 > ioapic0: Changing APIC ID to 1 > ioapic0: Routing external 8259A's -> intpin 0 > MADT: Interrupt override: source 0, irq 2 > ioapic0: Routing IRQ 0 -> intpin 2 > MADT: Interrupt override: source 5, irq 5 > ioapic0: intpin 5 trigger: level > ioapic0: intpin 5 polarity: low > MADT: Interrupt override: source 10, irq 10 > ioapic0: intpin 10 trigger: level > ioapic0: intpin 10 polarity: low > MADT: Interrupt override: source 11, irq 11 > ioapic0: intpin 11 trigger: level > ioapic0: intpin 11 polarity: low > MADT: Forcing active-low polarity and level trigger for SCI > ioapic0: intpin 9 polarity: low > ioapic0: intpin 9 trigger: level > ioapic0 irqs 0-47 on motherboard > cpu0 BSP: > ID: 0x00000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 > wlan: <802.11 Link Layer> > nfslock: pseudo-device > kbd: new array size 4 > kbd1 at kbdmux0 > mem: > Pentium Pro MTRR support enabled > io: > null: > random: > hptrr: RocketRAID 17xx/2xxx SATA controller driver v1.2 > npx0: INT 16 interface > acpi0: on motherboard > ioapic0: routing intpin 9 (ISA IRQ 9) to lapic 0 vector 48 > acpi0: [MPSAFE] > acpi0: [ITHREAD] > acpi0: wakeup code va 0xc72ab000 pa 0x1000 > pci_open(1): mode 1 addr port (0x0cf8) is 0x80000000 > pci_open(1a): mode1res=0x80000000 (0x80000000) > pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=12378086) > pcibios: BIOS version 2.10 > AcpiOsDerivePciId: \_SB_.PCI0.ISA_.PIRQ -> bus 0 dev 1 func 0 > ACPI timer: 0/15 0/16 0/13 0/12 0/14 0/21 0/66 0/18 0/9 0/126 -> 0 > Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 > acpi_timer0: <32-bit timer at 3.579545MHz> port 0x1f48-0x1f4b on acpi0 > pci_link0: Index IRQ Rtd Ref IRQs > Initial Probe 0 5 N 0 5 10 11 > Validation 0 5 N 0 5 10 11 > After Disable 0 255 N 0 5 10 11 > pci_link1: Index IRQ Rtd Ref IRQs > Initial Probe 0 10 N 0 5 10 11 > Validation 0 10 N 0 5 10 11 > After Disable 0 255 N 0 5 10 11 > pci_link2: Index IRQ Rtd Ref IRQs > Initial Probe 0 11 N 0 5 10 11 > Validation 0 11 N 0 5 10 11 > After Disable 0 255 N 0 5 10 11 > pci_link3: Index IRQ Rtd Ref IRQs > Initial Probe 0 5 N 0 5 10 11 > Validation 0 5 N 0 5 10 11 > After Disable 0 255 N 0 5 10 11 > acpi_hpet0: iomem 0xfed00000-0xfed003ff on > acpi0 > acpi_hpet0: vend: 0x8086 rev: 0x1 num: 3 hz: 62500000 opts: legacy_route > 64-bit > Timecounter "HPET" frequency 62500000 Hz quality 900 > pcib0: port 0xcf8-0xcff on acpi0 > pci0: on pcib0 > pci0: domain=0, physical bus=0 > found-> vendor=0x8086, dev=0x1237, revid=0x02 > domain=0, bus=0, slot=0, func=0 > class=06-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x7000, revid=0x00 > domain=0, bus=0, slot=1, func=0 > class=06-01-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0200, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x7010, revid=0x00 > domain=0, bus=0, slot=1, func=1 > class=01-01-80, hdrtype=0x00, mfdev=0 > cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > map[20]: type I/O Port, range 32, base 0xc220, size 4, enabled > found-> vendor=0x8086, dev=0x7020, revid=0x01 > domain=0, bus=0, slot=1, func=2 > class=0c-03-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0001, statreg=0x0000, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=d, irq=5 > map[20]: type I/O Port, range 32, base 0xc200, size 5, enabled > pcib0: matched entry for 0.1.INTD > pcib0: slot 1 INTD hardwired to IRQ 23 > found-> vendor=0x8086, dev=0x7113, revid=0x01 > domain=0, bus=0, slot=1, func=3 > class=06-80-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > pcib0: matched entry for 0.1.INTA > pcib0: slot 1 INTA hardwired to IRQ 20 > found-> vendor=0x1013, dev=0x00b8, revid=0x00 > domain=0, bus=0, slot=2, func=0 > class=03-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0003, statreg=0x0000, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > map[10]: type Prefetchable Memory, range 32, base 0xf0000000, size 25, > enabled > map[14]: type Memory, range 32, base 0xf3000000, size 12, enabled > found-> vendor=0x5853, dev=0x0001, revid=0x01 > domain=0, bus=0, slot=3, func=0 > class=01-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0003, statreg=0x0000, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=c, irq=10 > map[10]: type I/O Port, range 32, base 0xc000, size 8, enabled > map[14]: type Prefetchable Memory, range 32, base 0xf2000000, size 24, > enabled > pcib0: matched entry for 0.3.INTC > pcib0: slot 3 INTC hardwired to IRQ 30 > found-> vendor=0x10ec, dev=0x8139, revid=0x20 > domain=0, bus=0, slot=4, func=0 > class=02-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x0000, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=5 > map[10]: type I/O Port, range 32, base 0xc100, size 8, enabled > map[14]: type Memory, range 32, base 0xf3001000, size 8, enabled > pcib0: matched entry for 0.4.INTA > pcib0: slot 4 INTA hardwired to IRQ 32 > isab0: at device 1.0 on pci0 > isa0: on isab0 > atapci0: port > 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc220-0xc22f at device 1.1 on pci0 > ata0: on atapci0 > ata0: reset tp1 mask=03 ostat0=50 ostat1=00 > ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 > ata0: stat1=0x00 err=0x01 lsb=0xff msb=0xff > ata0: reset tp2 stat0=50 stat1=00 devices=0x1 > ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 0 vector 49 > ata0: [MPSAFE] > ata0: [ITHREAD] > ata1: on atapci0 > ata1: reset tp1 mask=03 ostat0=50 ostat1=50 > ata1: stat0=0x50 err=0x01 lsb=0xff msb=0xff > ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1: reset tp2 stat0=50 stat1=00 devices=0x20001 > ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 0 vector 50 > ata1: [MPSAFE] > ata1: [ITHREAD] > uhci0: port 0xc200-0xc21f irq 23 > at device 1.2 on pci0 > ioapic0: routing intpin 23 (PCI IRQ 23) to lapic 0 vector 51 > uhci0: [MPSAFE] > uhci0: [ITHREAD] > usbus0: controller did not stop > usbus0: on uhci0 > pci0: at device 1.3 (no driver attached) > vgapci0: mem > 0xf0000000-0xf1ffffff,0xf3000000-0xf3000fff at device 2.0 on pci0 > pci0: at device 3.0 (no driver attached) > re0: port 0xc100-0xc1ff mem > 0xf3001000-0xf30010ff irq 32 at device 4.0 on pci0 > re0: Chip rev. 0x74800000 > re0: MAC rev. 0x00000000 > miibus0: on re0 > rlphy0: PHY 0 on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > re0: bpf attached > re0: Ethernet address: 0e:90:13:eb:42:84 > ioapic0: routing intpin 32 (PCI IRQ 32) to lapic 0 vector 52 > re0: [MPSAFE] > re0: [FILTER] > atrtc0: port 0x70-0x71 irq 8 on acpi0 > atrtc0: registered as a time-of-day clock (resolution 1000000us) > psmcpnp0: irq 12 on acpi0 > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > atkbd: the current kbd controller command byte 0061 > atkbd: keyboard ID 0x41ab (2) > kbdc: RESET_KBD return code:00fa > kbdc: RESET_KBD status:00aa > kbd0 at atkbd0 > kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x1d0000 > ioapic0: routing intpin 1 (ISA IRQ 1) to lapic 0 vector 53 > atkbd0: [GIANT-LOCKED] > atkbd0: [ITHREAD] > psm0: current command byte:0061 > kbdc: TEST_AUX_PORT status:0000 > kbdc: RESET_AUX return code:00fa > kbdc: RESET_AUX status:00aa > kbdc: RESET_AUX ID:0000 > kbdc: RESET_AUX return code:00fa > kbdc: RESET_AUX status:00aa > kbdc: RESET_AUX ID:0000 > psm: status 00 02 64 > psm: status 00 00 64 > psm: status 00 03 64 > psm: status 00 03 64 > psm: data 08 00 00 > psm: status 00 02 64 > psm0: irq 12 on atkbdc0 > ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 0 vector 54 > psm0: [GIANT-LOCKED] > psm0: [ITHREAD] > psm0: model IntelliMouse Explorer, device ID 4-00, 5 buttons > psm0: config:00000000, flags:00000008, packet size:4 > psm0: syncmask:08, syncbits:00 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: does not respond > device_attach: fdc0 attach returned 6 > uart0: port 0x3f8-0x3ff irq > 4 flags 0x10 on acpi0 > ioapic0: routing intpin 4 (ISA IRQ 4) to lapic 0 vector 55 > uart0: [FILTER] > uart0: fast interrupt > uart0: console (9600,n,8,1) > ppc0: using extended I/O port range > ppc0: SPP > ppc0: port 0x378-0x37f irq 7 on acpi0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ioapic0: routing intpin 7 (ISA IRQ 7) to lapic 0 vector 56 > ppc0: [MPSAFE] > ppc0: [ITHREAD] > ppbus0: on ppc0 > plip0: on ppbus0 > plip0: bpf attached > plip0: [MPSAFE] > plip0: [ITHREAD] > lpt0: on ppbus0 > lpt0: [MPSAFE] > lpt0: [ITHREAD] > lpt0: Interrupt-driven port > ppi0: on ppbus0 > cpu0: on acpi0 > cpu0: switching to generic Cx mode > cpu1: on acpi0 > cpu2: on acpi0 > cpu3: on acpi0 > fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 > fdc0: does not respond > device_attach: fdc0 attach returned 6 > ahc_isa_probe 0: ioport 0xc00 alloc failed > ex_isa_identify() > pnp_identify: Trying Read_Port at 203 > pnp_identify: Trying Read_Port at 243 > pnp_identify: Trying Read_Port at 283 > pnp_identify: Trying Read_Port at 2c3 > pnp_identify: Trying Read_Port at 303 > pnp_identify: Trying Read_Port at 343 > pnp_identify: Trying Read_Port at 383 > pnp_identify: Trying Read_Port at 3c3 > PNP Identify complete > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > unknown: status reg test failed ff > isa_probe_children: disabling PnP devices > pmtimer0 on isa0 > ata: ata0 already exists; skipping it > ata: ata1 already exists; skipping it > atkbdc: atkbdc0 already exists; skipping it > atrtc: atrtc0 already exists; skipping it > fdc: fdc0 already exists; skipping it > ppc: ppc0 already exists; skipping it > sc: sc0 already exists; skipping it > uart: uart0 already exists; skipping it > isa_probe_children: probing non-PnP devices > orm0: at iomem 0xd0000-0xd7fff pnpid ORM0000 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x100> > sc0: fb0, kbd1, terminal emulator: scteken (teken terminal) > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > uart1: failed to probe at port 0x2f8-0x2ff irq 3 on isa0 > isa_probe_children: probing PnP devices > Device configuration finished. > Reducing kern.maxvnodes 245763 -> 100000 > procfs registered > lapic: Divisor 2, Frequency 50000945 Hz > ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 0 vector 57 > Timecounter "TSC" frequency 1995028866 Hz quality -100 > Timecounters tick every 1.000 msec > vlan: initialized, using hash tables with chaining > lo0: bpf attached > hptrr: no controller detected. > ata0: Identifying devices: 00000001 > ata0: New devices: 00000001 > ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire > usbus0: 12Mbps Full Speed USB v1.0 > ad0: setting WDMA2 > ad0: 102400MB at ata0-master WDMA2 > ad0: 209715200 sectors [208050C/16H/63S] 16 sectors/interrupt 1 depth queue > ugen0.1: at usbus0 > uhub0: on usbus0 > Expensive timeout(9) function: 0xc08cee70(0xc7755900) 0.027107631 s > GEOM: new disk ad0 > ad0: Intel check1 failed > ad0: Adaptec check1 failed > ad0: LSI (v3) check1 failed > ad0: LSI (v2) check1 failed > ad0: FreeBSD check1 failed > ata1: Identifying devices: 00020001 > ata1: New devices: 00020001 > ata1-slave: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire > GEOM: ad0s1: geometry does not match label (255h,63s != 16h,63s). > uhub0: 2 ports with 2 removable, self powered > ata1: reiniting channel .. > ata1: reset tp1 mask=03 ostat0=50 ostat1=50 > ata1: stat0=0x50 err=0x01 lsb=0xff msb=0xff > ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1: reset tp2 stat0=50 stat1=00 devices=0x20001 > ata1: reinit done .. > unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 > Expensive timeout(9) function: 0xc0571910(0xc7977bf4) 0.150055583 s > ugen0.2: at usbus0 > ums0: on usbus0 > ums0: 3 buttons and [Z] coordinates ID=0 > ata1: reiniting channel .. > ata1: reset tp1 mask=03 ostat0=50 ostat1=00 > ata1: stat0=0x50 err=0x01 lsb=0xff msb=0xff > ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb > ata1: reset tp2 stat0=50 stat1=00 devices=0x20001 > ata1: reinit done .. > unknown: FAILURE - ATA_IDENTIFY timed out LBA=0 > acd0: setting WDMA2 > acd0: CDROM drive at ata1 as slave > acd0: read 689KB/s (689KB/s), 512KB buffer, WDMA2 > acd0: Reads: > acd0: Writes: > acd0: Mechanism: ejectable tray, unlocked > acd0: Medium: no/blank disc > ATA PseudoRAID loaded > SMP: AP CPU #3 Launched! > cpu3 AP: > ID: 0x06000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 > SMP: AP CPU #2 Launched! > cpu2 AP: > ID: 0x04000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 > SMP: AP CPU #1 Launched! > cpu1 AP: > ID: 0x02000000 VER: 0x00050014 LDR: 0x00000000 DFR: 0xffffffff > lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff > timer: 0x000200ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010400 > Roapicf0l:o wrtoaubtlien gc lienatpnine r4 s(taIrStAe dI > Q 4) to lapic 2 vector 48 > ioapic0: routing intpin 7 (ISA IRQ 7) to lapic 4 vector 48 > ioapic0: routing intpin 8 (ISA IRQ 8) to lapic 6 vector 48 > ioapic0: routing intpin 12 (ISA IRQ 12) to lapic 2 vector 49 > ioapic0: routing intpin 14 (ISA IRQ 14) to lapic 4 vector 49 > ioapic0: routing intpin 15 (ISA IRQ 15) to lapic 6 vector 49 > ioapic0: routing intpin 32 (PCI IRQ 32) to lapic 2 vector 50 > WARNING: WITNESS option enabled, expect reduced performance. > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > Trying to mount root from ufs:/dev/ad0s1a > ct_to_ts([2010-01-29 21:47:24]) = 1264801644.000000000 > start_init: trying /sbin/init > Entropy harvesti > _______________________________________________ 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" - -- TJU13-ARIN -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJLY2YxAAoJEMSwVS7lr0Od1/0H/iMQQtRLzZZZoruHlP3r7x7t 0nECC+6d8VaqRNxkkl4ZLRL5deRM5JlwNyb3bxtAoGGbw7HB/msSxTnkaeSMh17N xcvPJoR85T75QYlv7p7y0Z7LWQsAG47xNz2K+UOkSly7pxhh29mU2+1tfrQzxKjQ HUpW+G8EgZdY5MyApF2SgyZnNrahp3kvPB9m2SN+rBK5Ir5ES4BcvHbYOjaEpvHE 5ltKLZfmZfQ8721bjvfLOyV/bgtLhRHOxzpy7IW2+Sf7owMXFF/YUINXyVgOSbd1 6kfVsx2CNyYmIgYCpZiLi2JLyd6xCw+ZM/VWvVC0Wru47ZZlW8tAuD74e4OP+qg= =6Waz -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 22:58:32 2010 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 F4082106566C; Fri, 29 Jan 2010 22:58:31 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 52DD88FC19; Fri, 29 Jan 2010 22:58:30 +0000 (UTC) Received: by fxm27 with SMTP id 27so819352fxm.3 for ; Fri, 29 Jan 2010 14:58:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:subject:x-enigmail-version:content-type :content-transfer-encoding; bh=2k8+4l3Yg/0zvW1bOdz0HOrERSM3U5XWnbUKlamQvPI=; b=huahRTR2a/+2G/Kx9uG1eohPGwICYPai0Ay3BDSGG4RYNdInL4xuwmSKpAOY81I7sE X3Zp8qGkzsPD0pT5AoPz2v0XMI2V5dLGDx1x/4XqWRgWaXKpOpgg45MJcFdKuWkZzt4O ToXbqOT/qq7Yc+C1fZf5LBXDqYPykS1u419Wo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; b=EZPbPuxpe6DKKyEH+DhdVj0ReXSu38dGBl+sC0jyJNp9QW1kgPMFrqzFh+sMoAEe11 okimhtvH7vtto9EHwl5cB+wzXrXQudCWMgMw5OqP5XmfESUHejGngceK9iUzE5Vte7/M 2dwpv2i26raPQ2tilvYD9FLcymXlGYZq4M3gg= Received: by 10.102.200.17 with SMTP id x17mr657326muf.125.1264805909944; Fri, 29 Jan 2010 14:58:29 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id y37sm1759033mug.8.2010.01.29.14.58.28 (version=SSLv3 cipher=RC4-MD5); Fri, 29 Jan 2010 14:58:29 -0800 (PST) Sender: Alexander Motin Message-ID: <4B636812.8060403@FreeBSD.org> Date: Sat, 30 Jan 2010 00:58:26 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: freebsd-geom@freebsd.org, freebsd-hackers@freebsd.org, FreeBSD-Current X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: Subject: Deadlock between GEOM and devfs device destroy and process exit. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 22:58:32 -0000 Hi. Experimenting with SATA hot-plug I've found quite repeatable deadlock case. Problem observed when several SATA devices, opened via devfs, disappear at exactly same time. In my case, at time of unplugging SATA Port Multiplier with several disks beyond it. All I have to do is to run several `dd if=/dev/adaX of=/dev/null bs=1m &` commands and unplug multiplier. That causes predictable I/O errors and devices destruction. But with high probability several dd processes getting stuck in kernel. I've discovered such pieces of problem: - CAM receives disconnect event and starts device destruction. But as device is still opened, it can't do it immediately. - dd receives I/O error and exits. - exit1() call closes all descriptors, including adaX device. It triggers final device destruction, by sending event to geom_dev. adaclose(4571fa00,4,40c16576,76,0,...) at 0x4049c521 g_disk_access(457e2200,ffffffff,0,0,0,...) at 0x4080b9a4 g_access(45643d80,ffffffff,0,0,2000,...) at 0x40810ccb g_dev_close(45766500,1,2000,4569fd80,4569fd80,...) at 0x4080a425 devfs_close(7b604aa8,80000,457f8000,80000,7b604acc,...) at 0x407f2762 VOP_CLOSE_APV(40d03180,7b604aa8,40c2e681,128,0,...) at 0x40b6da55 vn_close(457f8000,1,45624300,4569fd80,451271e0,...) at 0x40912750 vn_closefile(4566da48,4569fd80,4566da48,0,7b604b58,...) at 0x40912854 devfs_close_f(4566da48,4569fd80,3,0,4566da48,...) at 0x407f235b _fdrop(4566da48,4569fd80,7b604b8c,408b5cec,0,4569fe24,40eb23a8,40d10460,40c1a8bb,4560672c,721,40c1a8b2,7b604bb4,40878220,4560672c,8,40c1a8b2,721) at 0x40836da3 closef(4566da48,4569fd80,721,71e,4569fe24,...) at 0x40838ad0 fdfree(4569fd80,0,40c1b1a9,107,7b604c80,...) at 0x408394da exit1(4569fd80,100,7b604d2c,40b565c0,4569fd80,...) at 0x40844423 sys_exit(4569fd80,7b604cf8,40c59d34,40c26be4,4569d2a8,...) at 0x408450fd syscall(7b604d38) at 0x40b565c0 - GEOM event thread tries to destroy /dev/adaX device (which should be already free at this moment), but for some reason freezes, waiting for device to be freed: 0 2 0 0 -8 0 0 8 devdrn DL ?? 0:02.89 [g_event] - as GEOM event is still not handled, exit1() waits for it: kdb_backtrace(40c16bc4,0,40c16ab1,56,4540e640,...) at 0x408a2909 g_waitidle(4569fd80,0,40c1b1a9,107,7b604c80,...) at 0x4080cd1f exit1(4569fd80,100,7b604d2c,40b565c0,4569fd80,...) at 0x40844431 sys_exit(4569fd80,7b604cf8,40c59d34,40c26be4,4569d2a8,...) at 0x408450fd syscall(7b604d38) at 0x40b565c0 - system stationary. GEOM frozen. No way to get out of this, except pushing reset. 0 1065 1055 0 44 0 5344 3040 g_wait DE 0 0:00.43 dd if=/dev/ada1 of=/dev/null bs=1m 0 1066 1055 0 44 0 5344 3040 GEOM t DE 0 0:00.07 dd if=/dev/ada2 of=/dev/null bs=1m So, does anybody have good idea why destroy_dev() can't complete? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 23:11:15 2010 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 904FD106566B; Fri, 29 Jan 2010 23:11:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 1F0FA8FC0C; Fri, 29 Jan 2010 23:11:14 +0000 (UTC) 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 o0TNBAIS088873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Jan 2010 01:11:10 +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 o0TNBA01055788; Sat, 30 Jan 2010 01:11:10 +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 o0TNBAGH055787; Sat, 30 Jan 2010 01:11:10 +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, 30 Jan 2010 01:11:10 +0200 From: Kostik Belousov To: Alexander Motin Message-ID: <20100129231110.GS3877@deviant.kiev.zoral.com.ua> References: <4B636812.8060403@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zhl+qcI0cpCDfCbW" Content-Disposition: inline In-Reply-To: <4B636812.8060403@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at 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 Cc: freebsd-hackers@freebsd.org, FreeBSD-Current , freebsd-geom@freebsd.org Subject: Re: Deadlock between GEOM and devfs device destroy and process exit. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 23:11:15 -0000 --zhl+qcI0cpCDfCbW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 30, 2010 at 12:58:26AM +0200, Alexander Motin wrote: > Hi. >=20 > Experimenting with SATA hot-plug I've found quite repeatable deadlock > case. Problem observed when several SATA devices, opened via devfs, > disappear at exactly same time. In my case, at time of unplugging SATA > Port Multiplier with several disks beyond it. All I have to do is to run > several `dd if=3D/dev/adaX of=3D/dev/null bs=3D1m &` commands and unplug > multiplier. That causes predictable I/O errors and devices destruction. > But with high probability several dd processes getting stuck in kernel. >=20 > I've discovered such pieces of problem: > - CAM receives disconnect event and starts device destruction. But as > device is still opened, it can't do it immediately. > - dd receives I/O error and exits. > - exit1() call closes all descriptors, including adaX device. It > triggers final device destruction, by sending event to geom_dev. >=20 > adaclose(4571fa00,4,40c16576,76,0,...) at 0x4049c521 > g_disk_access(457e2200,ffffffff,0,0,0,...) at 0x4080b9a4 > g_access(45643d80,ffffffff,0,0,2000,...) at 0x40810ccb > g_dev_close(45766500,1,2000,4569fd80,4569fd80,...) at 0x4080a425 > devfs_close(7b604aa8,80000,457f8000,80000,7b604acc,...) at 0x407f2762 > VOP_CLOSE_APV(40d03180,7b604aa8,40c2e681,128,0,...) at 0x40b6da55 > vn_close(457f8000,1,45624300,4569fd80,451271e0,...) at 0x40912750 > vn_closefile(4566da48,4569fd80,4566da48,0,7b604b58,...) at 0x40912854 > devfs_close_f(4566da48,4569fd80,3,0,4566da48,...) at 0x407f235b > _fdrop(4566da48,4569fd80,7b604b8c,408b5cec,0,4569fe24,40eb23a8,40d10460,4= 0c1a8bb,4560672c,721,40c1a8b2,7b604bb4,40878220,4560672c,8,40c1a8b2,721) > at 0x40836da3 > closef(4566da48,4569fd80,721,71e,4569fe24,...) at 0x40838ad0 > fdfree(4569fd80,0,40c1b1a9,107,7b604c80,...) at 0x408394da > exit1(4569fd80,100,7b604d2c,40b565c0,4569fd80,...) at 0x40844423 > sys_exit(4569fd80,7b604cf8,40c59d34,40c26be4,4569d2a8,...) at 0x408450fd > syscall(7b604d38) at 0x40b565c0 >=20 > - GEOM event thread tries to destroy /dev/adaX device (which should be > already free at this moment), but for some reason freezes, waiting for > device to be freed: >=20 > 0 2 0 0 -8 0 0 8 devdrn DL ?? 0:02.89 > [g_event] >=20 > - as GEOM event is still not handled, exit1() waits for it: >=20 > kdb_backtrace(40c16bc4,0,40c16ab1,56,4540e640,...) at 0x408a2909 > g_waitidle(4569fd80,0,40c1b1a9,107,7b604c80,...) at 0x4080cd1f > exit1(4569fd80,100,7b604d2c,40b565c0,4569fd80,...) at 0x40844431 > sys_exit(4569fd80,7b604cf8,40c59d34,40c26be4,4569d2a8,...) at 0x408450fd > syscall(7b604d38) at 0x40b565c0 >=20 > - system stationary. GEOM frozen. No way to get out of this, except > pushing reset. >=20 > 0 1065 1055 0 44 0 5344 3040 g_wait DE 0 0:00.43 dd > if=3D/dev/ada1 of=3D/dev/null bs=3D1m > 0 1066 1055 0 44 0 5344 3040 GEOM t DE 0 0:00.07 dd > if=3D/dev/ada2 of=3D/dev/null bs=3D1m >=20 >=20 > So, does anybody have good idea why destroy_dev() can't complete? The devdrn state means that thread performing the device destruction, i.e. the thread called destroy_dev(), is waiting for threads to leave the cdevsw d_* methods. The thread that notified the destruction thread did that from d_close() method. This resulted in the deadlock. I introduced destroy_dev_sched(9) KPI to handle this and similar issues. Note that race-free use of destroy_dev_sched(9) is quite hard. --zhl+qcI0cpCDfCbW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktjaw0ACgkQC3+MBN1Mb4g4CgCg5qoXeNLMYgbyuZhwAZYQtX/g F4UAoOF3rYGBwcwwsat2EykHAGqEog0e =Rkef -----END PGP SIGNATURE----- --zhl+qcI0cpCDfCbW-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 23:23:32 2010 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 32C39106568D; Fri, 29 Jan 2010 23:23:32 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id 63F688FC13; Fri, 29 Jan 2010 23:23:31 +0000 (UTC) Received: by fxm27 with SMTP id 27so832917fxm.3 for ; Fri, 29 Jan 2010 15:23:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=LtEFmPGthK3fbozT5A2Sd4pzqLPAYGeXNOpggIFXl2I=; b=MUY3bZha8/l9HHbORTWYd2BY5netrT3cp8mlnJ9DzXa1zrCLS/WZbtvNxmnzgM/amI 1in7h8GkAMobFPtHDPB2LkuhcKcuM8ilgbQKofB3C00kSkt22oAbJMCPmSyG3D6BcbE/ G1Mc2QvKtz8Q9ESfQQipBlGwkWnV5aTKfnrw4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=JtZBYRduj2DfrG22ICVJ82hPr/6ebOuzGIS8PkRtaxQP5ZHAvlTD4UOcpH0KDajazt SeCL+3+IEzbxXtyH2Ew2riLWSE2PLmKpNtKEoJBJyDJUne65Bu5ldIRsRFBoFPoSjl19 gtTVO1gQtzy4W4ODEO0FI7FtGH442efU23ip0= Received: by 10.102.235.36 with SMTP id i36mr747418muh.56.1264807410244; Fri, 29 Jan 2010 15:23:30 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id j9sm11120931mue.6.2010.01.29.15.23.29 (version=SSLv3 cipher=RC4-MD5); Fri, 29 Jan 2010 15:23:29 -0800 (PST) Sender: Alexander Motin Message-ID: <4B636DEA.2060901@FreeBSD.org> Date: Sat, 30 Jan 2010 01:23:22 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Kostik Belousov References: <4B636812.8060403@FreeBSD.org> <20100129231110.GS3877@deviant.kiev.zoral.com.ua> In-Reply-To: <20100129231110.GS3877@deviant.kiev.zoral.com.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, FreeBSD-Current , freebsd-geom@freebsd.org Subject: Re: Deadlock between GEOM and devfs device destroy and process exit. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 23:23:32 -0000 Kostik Belousov wrote: > On Sat, Jan 30, 2010 at 12:58:26AM +0200, Alexander Motin wrote: >> Hi. >> >> Experimenting with SATA hot-plug I've found quite repeatable deadlock >> case. Problem observed when several SATA devices, opened via devfs, >> disappear at exactly same time. In my case, at time of unplugging SATA >> Port Multiplier with several disks beyond it. All I have to do is to run >> several `dd if=/dev/adaX of=/dev/null bs=1m &` commands and unplug >> multiplier. That causes predictable I/O errors and devices destruction. >> But with high probability several dd processes getting stuck in kernel. >> >> I've discovered such pieces of problem: >> - CAM receives disconnect event and starts device destruction. But as >> device is still opened, it can't do it immediately. >> - dd receives I/O error and exits. >> - exit1() call closes all descriptors, including adaX device. It >> triggers final device destruction, by sending event to geom_dev. >> >> adaclose(4571fa00,4,40c16576,76,0,...) at 0x4049c521 >> g_disk_access(457e2200,ffffffff,0,0,0,...) at 0x4080b9a4 >> g_access(45643d80,ffffffff,0,0,2000,...) at 0x40810ccb >> g_dev_close(45766500,1,2000,4569fd80,4569fd80,...) at 0x4080a425 >> devfs_close(7b604aa8,80000,457f8000,80000,7b604acc,...) at 0x407f2762 >> VOP_CLOSE_APV(40d03180,7b604aa8,40c2e681,128,0,...) at 0x40b6da55 >> vn_close(457f8000,1,45624300,4569fd80,451271e0,...) at 0x40912750 >> vn_closefile(4566da48,4569fd80,4566da48,0,7b604b58,...) at 0x40912854 >> devfs_close_f(4566da48,4569fd80,3,0,4566da48,...) at 0x407f235b >> _fdrop(4566da48,4569fd80,7b604b8c,408b5cec,0,4569fe24,40eb23a8,40d10460,40c1a8bb,4560672c,721,40c1a8b2,7b604bb4,40878220,4560672c,8,40c1a8b2,721) >> at 0x40836da3 >> closef(4566da48,4569fd80,721,71e,4569fe24,...) at 0x40838ad0 >> fdfree(4569fd80,0,40c1b1a9,107,7b604c80,...) at 0x408394da >> exit1(4569fd80,100,7b604d2c,40b565c0,4569fd80,...) at 0x40844423 >> sys_exit(4569fd80,7b604cf8,40c59d34,40c26be4,4569d2a8,...) at 0x408450fd >> syscall(7b604d38) at 0x40b565c0 >> >> - GEOM event thread tries to destroy /dev/adaX device (which should be >> already free at this moment), but for some reason freezes, waiting for >> device to be freed: >> >> 0 2 0 0 -8 0 0 8 devdrn DL ?? 0:02.89 >> [g_event] >> >> - as GEOM event is still not handled, exit1() waits for it: >> >> kdb_backtrace(40c16bc4,0,40c16ab1,56,4540e640,...) at 0x408a2909 >> g_waitidle(4569fd80,0,40c1b1a9,107,7b604c80,...) at 0x4080cd1f >> exit1(4569fd80,100,7b604d2c,40b565c0,4569fd80,...) at 0x40844431 >> sys_exit(4569fd80,7b604cf8,40c59d34,40c26be4,4569d2a8,...) at 0x408450fd >> syscall(7b604d38) at 0x40b565c0 >> >> - system stationary. GEOM frozen. No way to get out of this, except >> pushing reset. >> >> 0 1065 1055 0 44 0 5344 3040 g_wait DE 0 0:00.43 dd >> if=/dev/ada1 of=/dev/null bs=1m >> 0 1066 1055 0 44 0 5344 3040 GEOM t DE 0 0:00.07 dd >> if=/dev/ada2 of=/dev/null bs=1m >> >> >> So, does anybody have good idea why destroy_dev() can't complete? > > The devdrn state means that thread performing the device destruction, > i.e. the thread called destroy_dev(), is waiting for threads to leave > the cdevsw d_* methods. The thread that notified the destruction thread > did that from d_close() method. This resulted in the deadlock. d_close() doesn't call destroy_dev() directly. It schedules different thread to do it. destroy_dev() should run after d_close() already complete. Though I haven't checked how it is locked. > I introduced destroy_dev_sched(9) KPI to handle this and similar issues. > Note that race-free use of destroy_dev_sched(9) is quite hard. I think it should work without it here. Shouldn't it? -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 23:25:21 2010 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 3477A106566C; Fri, 29 Jan 2010 23:25:21 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id 859FF8FC1B; Fri, 29 Jan 2010 23:25:20 +0000 (UTC) Received: by bwz5 with SMTP id 5so125916bwz.3 for ; Fri, 29 Jan 2010 15:25: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; bh=vT55vH8JhdCIAnWMz/ElGfYsSv8SVadHWWRQe+OXKu0=; b=ZxZpTFb7s++3JZxqkuNFTUszi9BoQX5ErgfvNBDBvweuzXaJPWWNFcM2Sysrgnorca n1e73VhNzt8cm1r6b/3K3nqrdLY1vHgVQYqBQn5Y+SqC/0D+EbU50Fp8spDwaOz3FVeE u3+HL0aALrIO9FuNxpZIAkDfFWWb6JL5uD2dI= 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; b=KD4NTpq3ePwS7KOE8pkJ8oKcUmi6XMuzrNLzkX4RdymrWWnBW3q2Id5cenBvBGKbYb 1LTQE9hYwL7kKI3nlfIjCsyns/S3z2ZlqwsnHEQ3wu/03eOOALynxciWUQ7fXgVtt+JL xhNHowL7+MtvUnfH18vdm0YrH7OKgnIwqV/eM= MIME-Version: 1.0 Received: by 10.204.10.149 with SMTP id p21mr1079041bkp.3.1264807519303; Fri, 29 Jan 2010 15:25:19 -0800 (PST) In-Reply-To: <4B62DD46.4060908@FreeBSD.org> References: <4B55D9D4.1000008@FreeBSD.org> <201001231407.o0NE7l8j002620@triton8.kn-bremen.de> <20100123184619.257203d9@ernst.jennejohn.org> <4B5C79CF.9070504@FreeBSD.org> <83e5fb981001290503n140d4c05ga755853a1588de@mail.gmail.com> <4B62DD46.4060908@FreeBSD.org> Date: Sat, 30 Jan 2010 00:25:19 +0100 Message-ID: <83e5fb981001291525k6d533fdaj1611df806077d94f@mail.gmail.com> From: Diego Depaoli To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD-Current Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 23:25:21 -0000 On Fri, Jan 29, 2010 at 2:06 PM, Alexander Motin wrote: > Diego Depaoli wrote: >> On Sun, Jan 24, 2010 at 5:48 PM, Alexander Motin wrote: >>> New patch version should handle this and some other problems: >>> http://people.freebsd.org/~mav/cam-ata.20100124.patch >> I didn't yet test in depth your patch but... >> - ogmrip doesn't more freeze the system >> - while the system boots, closing the optical drive's tray with a >> video dvd inserted, I get a reproducible (for me) panic. > > If you wish it to be fixed - you had to give much more info. handwritten ------------------------ cd0: \ukD [ua? uhub2: 6 ports with 6 removable, self powered uhub5: 6 ports with 6 removable, self powered fatal trap 18: integer divide fault while in kernel mode cpuid=1, apic id=01 instruction pointer = 0x20:0xc057efcd stack pointer = 0x28:0xc63e0b94 frame pointer = 0x28:0xc63e0bd4 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL0, pres 1, def32 1, gran 1 processor eflags = interrupt enbled, resume, IOPL = 0 current process = 2(g_event) trap number = 18 panic integer divide fault cpuid = 1 ------------------------- only power button works my regular dmesg Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #6 r203138M: Fri Jan 29 02:39:01 CET 2010 root@genipizza.casadep.home:/usr/obj/usr/src/sys/CAMKERN i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5000+ (2730.12-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x60fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x11f TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 3412471808 (3254 MB) ACPI APIC Table: <121708 APIC2302> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI Warning: Optional field Pm2ControlBlock has zero address or length: 0 0/1 (20100121/tbfadt-655) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: <121708 RSDT2302> on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fee00000, 1000 (3) failed acpi0: reservation of ffb80000, 80000 (3) failed acpi0: reservation of fec10000, 20 (3) failed acpi0: reservation of 0, a0000 (3) failed acpi0: reservation of 100000, cfe00000 (3) failed ACPI HPET table warning: Sequence is non-zero (2) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <32-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xd000-0xd0ff mem 0xd0000000-0xdfffffff,0xfeaf0000-0xfeafffff,0xfe900000-0xfe9fffff irq 18 at device 5.0 on pci1 drm0: on vgapci0 info: [drm] MSI enabled 1 message(s) vgapci0: child drm0 requested pci_enable_busmaster info: [drm] Initialized radeon 1.31.0 20080613 hdac0: mem 0xfeae8000-0xfeaebfff irq 19 at device 5.1 on pci1 hdac0: HDA Driver Revision: 20100122_0141 hdac0: [ITHREAD] pcib2: irq 17 at device 5.0 on pci0 pci2: on pcib2 re0: port 0xe800-0xe8ff mem 0xfdfff000-0xfdffffff,0xfdff8000-0xfdffbfff irq 17 at device 0.0 on pci2 re0: Using 1 MSI messages re0: Chip rev. 0x28000000 re0: MAC rev. 0x00000000 miibus0: on re0 rgephy0: PHY 1 on miibus0 rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto re0: Ethernet address: 00:19:66:a7:2a:37 re0: [FILTER] ahci0: port 0xc000-0xc007,0xb000-0xb003,0xa000-0xa007,0x9000-0x9003,0x8000-0x800f mem 0xfe8ffc00-0xfe8fffff irq 22 at device 17.0 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.10 with 6 3Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [ITHREAD] ohci0: mem 0xfe8fe000-0xfe8fefff irq 16 at device 18.0 on pci0 ohci0: [ITHREAD] usbus0: on ohci0 ohci1: mem 0xfe8fd000-0xfe8fdfff irq 16 at device 18.1 on pci0 ohci1: [ITHREAD] usbus1: on ohci1 ehci0: mem 0xfe8ff800-0xfe8ff8ff irq 17 at device 18.2 on pci0 ehci0: [ITHREAD] ehci0: AMD SB600/700 quirk applied usbus2: EHCI version 1.0 usbus2: on ehci0 ohci2: mem 0xfe8fc000-0xfe8fcfff irq 18 at device 19.0 on pci0 ohci2: [ITHREAD] usbus3: on ohci2 ohci3: mem 0xfe8f7000-0xfe8f7fff irq 18 at device 19.1 on pci0 ohci3: [ITHREAD] usbus4: on ohci3 ehci1: mem 0xfe8ff400-0xfe8ff4ff irq 19 at device 19.2 on pci0 ehci1: [ITHREAD] ehci1: AMD SB600/700 quirk applied usbus5: EHCI version 1.0 usbus5: on ehci1 pci0: at device 20.0 (no driver attached) atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xff00-0xff0f at device 20.1 on pci0 ata1: on atapci0 ata1: [ITHREAD] hdac1: mem 0xfe8f0000-0xfe8f3fff irq 16 at device 20.2 on pci0 hdac1: HDA Driver Revision: 20100122_0141 hdac1: [ITHREAD] isab0: at device 20.3 on pci0 isa0: on isab0 pcib3: at device 20.4 on pci0 pci3: on pcib3 ohci4: mem 0xfe8f6000-0xfe8f6fff irq 18 at device 20.5 on pci0 ohci4: [ITHREAD] usbus6: on ohci4 acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] atkbd0: [ITHREAD] cpu0: on acpi0 acpi_throttle0: on cpu0 powernow0: on cpu0 device_attach: powernow0 attach returned 6 cpu1: on acpi0 powernow1: on cpu1 device_attach: powernow1 attach returned 6 pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. uart1: <16550 or compatible> at port 0x2f8-0x2ff irq 3 on isa0 uart1: [FILTER] Timecounters tick every 1.000 msec hdac0: HDA Codec #0: ATI RS690/780 HDMI pcm0: at cad 0 nid 1 on hdac0 hdac1: HDA Codec #0: Realtek ALC662 pcm1: at cad 0 nid 1 on hdac1 usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 12Mbps Full Speed USB v1.0 usbus5: 480Mbps High Speed USB v2.0 usbus6: 12Mbps Full Speed USB v1.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 ugen4.1: at usbus4 uhub4: on usbus4 ugen5.1: at usbus5 uhub5: on usbus5 ugen6.1: at usbus6 uhub6: on usbus6 uhub6: 2 ports with 2 removable, self powered uhub0: 3 ports with 3 removable, self powered uhub1: 3 ports with 3 removable, self powered uhub3: 3 ports with 3 removable, self powered uhub4: 3 ports with 3 removable, self powered ada0 at ahcich0 bus 0 scbus0 target 0 lun 0cd0 at ata1 bus 0 scbus6 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 66.700MB/s transfers (UDMA4, PIO size 65534bytes) cd0: cd present [3349840 x 2048 byte records] ada0: ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes) ada0: Command Queueing enabled ada0: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ATA-8 SATA 2.x device ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO size 8192bytes) ada1: Command Queueing enabled ada1: 305245MB (625142448 512 byte sectors: 16H 63S/T 16383C) SMP: AP CPU #1 Launched! uhub2: 6 ports with 6 removable, self powered uhub5: 6 ports with 6 removable, self powered ugen0.2: at usbus0 ulpt0: on usbus0 ulpt0: using bi-directional mode ugen1.2: at usbus1 ums0: on usbus1 ums0: 3 buttons and [XYZ] coordinates ID=0 GEOM: ada0: partition 1 does not start on a track boundary. GEOM: ada0: partition 1 does not end on a track boundary. GEOM: ada0s4: geometry does not match label (255h,63s != 16h,63s). GEOM: ada1: partition 3 does not start on a track boundary. GEOM: ada1: partition 3 does not end on a track boundary. Trying to mount root from ufs:/dev/label/rootbsd fuse4bsd: version 0.3.9-pre1, FUSE ABI 7.8 re0: link state changed to UP info: [drm] Setting GART location based on new memory map info: [drm] Loading RS780/RS880 Microcode info: [drm] Resetting GPU info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] info: [drm] Resetting GPU info: [drm] Setting GART location based on new memory map info: [drm] Loading RS780/RS880 Microcode info: [drm] Resetting GPU info: [drm] writeback test succeeded in 1 usecs drm0: [ITHREAD] ahci0@pci0:0:17:0: class=0x010601 card=0x43911849 chip=0x43911002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' device = 'SB700 SATA Controller [AHCI mode]' class = mass storage subclass = SATA bar [10] = type I/O Port, range 32, base 0xc000, size 8, enabled bar [14] = type I/O Port, range 32, base 0xb000, size 4, enabled bar [18] = type I/O Port, range 32, base 0xa000, size 8, enabled bar [1c] = type I/O Port, range 32, base 0x9000, size 4, enabled bar [20] = type I/O Port, range 32, base 0x8000, size 16, enabled bar [24] = type Memory, range 32, base 0xfe8ffc00, size 1024, enabled cap 01[60] = powerspec 2 supports D0 D3 current D0 cap 12[70] = SATA Index-Data Pair Let me know if I must provide other info Cheers -- Diego Depaoli From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 23:31:33 2010 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 2D3EA106566B for ; Fri, 29 Jan 2010 23:31:33 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f227.google.com (mail-fx0-f227.google.com [209.85.220.227]) by mx1.freebsd.org (Postfix) with ESMTP id A7D298FC0C for ; Fri, 29 Jan 2010 23:31:32 +0000 (UTC) Received: by fxm27 with SMTP id 27so837157fxm.3 for ; Fri, 29 Jan 2010 15:31:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=XUfkyfWVAosEoeJe67DaGe7ukBkB2TwvMDpKXuAy2r4=; b=UME5s6gxOQ96kSru9htik236PWgKgz7IXKvmzv6KJ7gO2j2xvGsNLfp20x1W2VWvia ykYBummOYoTik8o1InGc39i7xzG8SPB4Qz9xX9gbyBwhxsnjpvtMUsIC1XJUkpJHbXQ8 kQ1R9F8RHKbyZhu/YoH/FLFPurLywPbNt/VXI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=yCCmGfjwgewnMjDWAhDug5q98yPXyLcSvOXtRTfE5egFEAuGf84Cl1/8UohtZH6vYN Sqmtx+iogfw+DC/1/TBCwaL2xEe3KOQEPCDYflfXH/EZiyNJRmUMBxV58ypX8xSnIaSu dg6NrOIrALQSuPCqr6K8YO6+4zbfFuHYSP1CM= Received: by 10.102.169.26 with SMTP id r26mr793927mue.27.1264807890471; Fri, 29 Jan 2010 15:31:30 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id u26sm8552099mug.45.2010.01.29.15.31.29 (version=SSLv3 cipher=RC4-MD5); Fri, 29 Jan 2010 15:31:29 -0800 (PST) Sender: Alexander Motin Message-ID: <4B636FCF.3080209@FreeBSD.org> Date: Sat, 30 Jan 2010 01:31:27 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Diego Depaoli References: <4B55D9D4.1000008@FreeBSD.org> <201001231407.o0NE7l8j002620@triton8.kn-bremen.de> <20100123184619.257203d9@ernst.jennejohn.org> <4B5C79CF.9070504@FreeBSD.org> <83e5fb981001290503n140d4c05ga755853a1588de@mail.gmail.com> <4B62DD46.4060908@FreeBSD.org> <83e5fb981001291525k6d533fdaj1611df806077d94f@mail.gmail.com> In-Reply-To: <83e5fb981001291525k6d533fdaj1611df806077d94f@mail.gmail.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD-Current Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 23:31:33 -0000 Diego Depaoli wrote: > On Fri, Jan 29, 2010 at 2:06 PM, Alexander Motin wrote: >> Diego Depaoli wrote: >>> On Sun, Jan 24, 2010 at 5:48 PM, Alexander Motin wrote: >>>> New patch version should handle this and some other problems: >>>> http://people.freebsd.org/~mav/cam-ata.20100124.patch >>> I didn't yet test in depth your patch but... >>> - ogmrip doesn't more freeze the system >>> - while the system boots, closing the optical drive's tray with a >>> video dvd inserted, I get a reproducible (for me) panic. >> If you wish it to be fixed - you had to give much more info. > handwritten > ------------------------ > cd0: \ukD [ua? What's that? What was before it? Enable verbose boot messages to get more info. > uhub2: 6 ports with 6 removable, self powered > uhub5: 6 ports with 6 removable, self powered > > fatal trap 18: integer divide fault while in kernel mode > cpuid=1, apic id=01 > instruction pointer = 0x20:0xc057efcd If you have kernel.debug, you may use addr2line -e kernel.debug 0xc057efcd to get source line number, where it crashed. But stack back trace would be better. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Fri Jan 29 23:40:01 2010 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 7D4C51065672; Fri, 29 Jan 2010 23:40:01 +0000 (UTC) (envelope-from trebestie@gmail.com) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by mx1.freebsd.org (Postfix) with ESMTP id D62598FC0C; Fri, 29 Jan 2010 23:40:00 +0000 (UTC) Received: by bwz5 with SMTP id 5so131448bwz.3 for ; Fri, 29 Jan 2010 15:39: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; bh=q+5nNF4aH2aznfpxytyMCKcJq1s0Qs87nxgYMUOqujw=; b=HmKlSgkKKTUWnKzp7pqYcOieQ9YCg0IIdgxHQMA3EVLZFmQyy00wXJcNePV8wMv1Zq 4DZI0R3q1afGWqmIOB9pSC/eFDKcXXPhBGpTjjC/xBZjHGiEcS5okdc4xlTTQXe5NZVy DbPtJoyvfwJPHqF1USkZ5qANyR53pRXRIe+h4= 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; b=pih4nX6bQ0ux5tKD88kkUw2liN06ep99gr3lC1SyX2mY/w2fCnDgOBbhH7uM58T7o5 zngGPOWj+Hmbz734qqOBFIbG5NMVK9MfL2mW9HB1YKhs0Xzghf3Z5UIBoXnyGxM9KwA2 2exgTgFYOTM9heQujOmwKmMOgIy2cUClT5Qww= MIME-Version: 1.0 Received: by 10.204.27.3 with SMTP id g3mr725451bkc.204.1264808399697; Fri, 29 Jan 2010 15:39:59 -0800 (PST) In-Reply-To: <4B636FCF.3080209@FreeBSD.org> References: <4B55D9D4.1000008@FreeBSD.org> <201001231407.o0NE7l8j002620@triton8.kn-bremen.de> <20100123184619.257203d9@ernst.jennejohn.org> <4B5C79CF.9070504@FreeBSD.org> <83e5fb981001290503n140d4c05ga755853a1588de@mail.gmail.com> <4B62DD46.4060908@FreeBSD.org> <83e5fb981001291525k6d533fdaj1611df806077d94f@mail.gmail.com> <4B636FCF.3080209@FreeBSD.org> Date: Sat, 30 Jan 2010 00:39:59 +0100 Message-ID: <83e5fb981001291539t25ff9db9k9d9cf91e40877f1b@mail.gmail.com> From: Diego Depaoli To: Alexander Motin Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD-Current Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Jan 2010 23:40:01 -0000 On Sat, Jan 30, 2010 at 12:31 AM, Alexander Motin wrote: >> ------------------------ >> cd0: \ukD [ua? > > What's that? What was before it? cd0: Removable CD-ROM SCSI-0 device cd0: 66.700MB/s transfers (UDMA4, PIO size 65534bytes) and in regular dmesg cd0: cd present [3349840 x 2048 byte records] > Enable verbose boot messages to get > more info. ok > >> uhub2: 6 ports with 6 removable, self powered >> uhub5: 6 ports with 6 removable, self powered >> >> fatal trap 18: integer divide fault while in kernel mode >> cpuid=1, apic id=01 >> instruction pointer = 0x20:0xc057efcd > > If you have kernel.debug, you may use > addr2line -e kernel.debug 0xc057efcd > to get source line number, where it crashed. But stack back trace would > be better. I'll try it, but, after panic, I cannot get keyboard working. I manage only to poweroff the system. -- Diego Depaoli From owner-freebsd-current@FreeBSD.ORG Sat Jan 30 11:28:02 2010 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 E7846106566C; Sat, 30 Jan 2010 11:28:02 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id 3A4E08FC14; Sat, 30 Jan 2010 11:28:00 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id B76FE45685; Sat, 30 Jan 2010 12:27:58 +0100 (CET) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 1197145683; Sat, 30 Jan 2010 12:27:52 +0100 (CET) Date: Sat, 30 Jan 2010 12:27:49 +0100 From: Pawel Jakub Dawidek To: Alexander Motin Message-ID: <20100130112749.GA1660@garage.freebsd.pl> References: <4B636812.8060403@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <4B636812.8060403@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.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=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-hackers@freebsd.org, FreeBSD-Current , kib@FreeBSD.org, freebsd-geom@freebsd.org Subject: Re: Deadlock between GEOM and devfs device destroy and process exit. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2010 11:28:03 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 30, 2010 at 12:58:26AM +0200, Alexander Motin wrote: > Hi. >=20 > Experimenting with SATA hot-plug I've found quite repeatable deadlock > case. Problem observed when several SATA devices, opened via devfs, > disappear at exactly same time. In my case, at time of unplugging SATA > Port Multiplier with several disks beyond it. All I have to do is to run > several `dd if=3D/dev/adaX of=3D/dev/null bs=3D1m &` commands and unplug > multiplier. That causes predictable I/O errors and devices destruction. > But with high probability several dd processes getting stuck in kernel. [...] I observed the same thing yesterday while stress-testing HAST: 3659 2504 3659 0 DE+ GEOM top 0x8079a348 dd 3658 2102 2102 0 DE+ GEOM top 0x8079a348 hastd 2 0 0 0 DL devdrn 0x85b1bc68 [g_event] Both dd(1) and hastd(8) wait for the GEOM topology lock in the exit path, which is already held by the g_event thread. Interesting backtraces: db> bt 2 [...] _sleep(85b1bc68,8079aab8,4c,80711ab3,64,...) at _sleep+0x339 destroy_devl(5,0,80711c53,85b1bcb0,804945cd,...) at destroy_devl+0x20f destroy_dev(86a10a00,8070ea93,86a09800,860888e0,0,...) at destroy_dev+0x2f g_dev_orphan(86a09800,8070f424,871038d8,90,6,...) at g_dev_orphan+0x6d g_run_events(8079a378,0,4c,8070c221,64,...) at g_run_events+0x1c0 g_event_procbody(0,85b1bd38,80713228,343,85d0b7f8,...) at g_event_procbody+= 0x8a [...] db> bt 3658 [...] sleepq_wait(8079a348,0,8070f822,3,0,...) at sleepq_wait+0x63 _sx_xlock_hard(8079a348,86974240,0,8070ea66,c8,...) at _sx_xlock_hard+0x496 _sx_xlock(8079a348,0,8070ea66,c8,2000,...) at _sx_xlock+0xc0 g_dev_close(85f8ee00,4003,2000,86974240,86974240,...) at g_dev_close+0xbd devfs_close(dc49eaac,80745707,80000,80000,868be984,...) at devfs_close+0x2b2 VOP_CLOSE_APV(80753ac0,dc49eaac,80726500,128,2,...) at VOP_CLOSE_APV+0xc5 vn_close(868be984,4003,85fd5500,86974240,0,...) at vn_close+0x190 vn_closefile(86a20968,86974240,86a20968,0,dc49eb5c,...) at vn_closefile+0xe4 devfs_close_f(86a20968,86974240,0,0,86a20968,...) at devfs_close_f+0x2b _fdrop(86a20968,86974240,14,80719d1a,0,dc49eb98,1,86975000,8635c22c,8635c22= c,721,8071264b,dc49ebb8,804f87d0,8635c22c,8,8071264b,721) at _fdrop+0x43 closef(86a20968,86974240,721,71e,869742e4,...) at closef+0x290 fdfree(86974240,0,80712fdd,107,864c4330,...) at fdfree+0x3ea exit1(86974240,0,dc49ed2c,806d830a,86974240,...) at exit1+0x513 sys_exit(86974240,dc49ecf8,86974240,dc49ed2c,202,...) at sys_exit+0x1d [...] db> bt 3659 [...] sleepq_wait(8079a348,0,8070f822,3,0,...) at sleepq_wait+0x63 _sx_xlock_hard(8079a348,863e06c0,0,8070ea66,c8,...) at _sx_xlock_hard+0x496 _sx_xlock(8079a348,0,8070ea66,c8,2000,...) at _sx_xlock+0xc0 g_dev_close(86a10a00,3,2000,863e06c0,863e06c0,...) at g_dev_close+0xbd devfs_close(dc4f6aac,80745707,80000,80000,86aa6c3c,...) at devfs_close+0x2b2 VOP_CLOSE_APV(80753ac0,dc4f6aac,80726500,128,2,...) at VOP_CLOSE_APV+0xc5 vn_close(86aa6c3c,3,870d4080,863e06c0,80cbac08,...) at vn_close+0x190 vn_closefile(871028f8,863e06c0,871028f8,0,dc4f6b5c,...) at vn_closefile+0xe4 devfs_close_f(871028f8,863e06c0,0,0,871028f8,...) at devfs_close_f+0x2b _fdrop(871028f8,863e06c0,8071809c,40e,0,805354ab,8071809c,8071df19,8635d42c= ,8635d42c,721,8071264b,dc4f6bb8,804f87d0,8635d42c,8,8071264b,721) at _fdrop= +0x43 closef(871028f8,863e06c0,721,71e,863e0764,...) at closef+0x290 fdfree(863e06c0,0,80712fdd,107,86153088,...) at fdfree+0x3ea exit1(863e06c0,100,dc4f6d2c,806d830a,863e06c0,...) at exit1+0x513 sys_exit(863e06c0,dc4f6cf8,863e06c0,dc4f6d2c,202,...) at sys_exit+0x1d [...] db> show lock 0x8079a348 class: sx name: GEOM topology state: XLOCK: 0x85d0d000 (tid 100008, pid 2, "g_event") waiters: exclusive --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFLZBe1ForvXbEpPzQRArJDAKCIvEtVTvwLwDjFJFcK1wxfJjq/NACeIR/M lEoKsO8kDLty3lh8oeG/aHg= =/n19 -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 30 11:45:01 2010 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 A4FC5106566B; Sat, 30 Jan 2010 11:45:01 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (chello089077043238.chello.pl [89.77.43.238]) by mx1.freebsd.org (Postfix) with ESMTP id DE63A8FC16; Sat, 30 Jan 2010 11:45:00 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 0B20145E9C; Sat, 30 Jan 2010 12:44:59 +0100 (CET) Received: from localhost (chello089077043238.chello.pl [89.77.43.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id D5DA145CAC; Sat, 30 Jan 2010 12:44:53 +0100 (CET) Date: Sat, 30 Jan 2010 12:44:51 +0100 From: Pawel Jakub Dawidek To: Alexander Motin Message-ID: <20100130114451.GB1660@garage.freebsd.pl> References: <4B636812.8060403@FreeBSD.org> <20100130112749.GA1660@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EuxKj2iCbKjpUGkD" Content-Disposition: inline In-Reply-To: <20100130112749.GA1660@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.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=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-hackers@freebsd.org, FreeBSD-Current , kib@FreeBSD.org, freebsd-geom@freebsd.org Subject: Re: Deadlock between GEOM and devfs device destroy and process exit. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2010 11:45:01 -0000 --EuxKj2iCbKjpUGkD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 30, 2010 at 12:27:49PM +0100, Pawel Jakub Dawidek wrote: > On Sat, Jan 30, 2010 at 12:58:26AM +0200, Alexander Motin wrote: > > Hi. > >=20 > > Experimenting with SATA hot-plug I've found quite repeatable deadlock > > case. Problem observed when several SATA devices, opened via devfs, > > disappear at exactly same time. In my case, at time of unplugging SATA > > Port Multiplier with several disks beyond it. All I have to do is to run > > several `dd if=3D/dev/adaX of=3D/dev/null bs=3D1m &` commands and unplug > > multiplier. That causes predictable I/O errors and devices destruction. > > But with high probability several dd processes getting stuck in kernel. > [...] >=20 > I observed the same thing yesterday while stress-testing HAST: >=20 > 3659 2504 3659 0 DE+ GEOM top 0x8079a348 dd > 3658 2102 2102 0 DE+ GEOM top 0x8079a348 hastd > 2 0 0 0 DL devdrn 0x85b1bc68 [g_event] >=20 > Both dd(1) and hastd(8) wait for the GEOM topology lock in the exit path, > which is already held by the g_event thread. Maybe I'll add how I understand what's going on: GEOM calls destroy_dev() while holding the topology lock. Destroy_dev() wants to destroy device, but can't because there are threads that still have it open. The threads can't close it, because to close it they need the topology lock. The deadlock is quite obvious, IMHO. I believe the problem could be solved by dropping the topology lock in g_dev_orphan() when calling destroy_dev(dev), but it is hard to say if it is safe to drop the topology lock there. Maybe Poul-Henning could take a look. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --EuxKj2iCbKjpUGkD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFLZBuyForvXbEpPzQRAoaLAJ9X1IIhEfBcTNHc2CYBkh4RAzc/twCgj6x0 y1PsqIMgcFnE/ILC2kevD28= =hEg0 -----END PGP SIGNATURE----- --EuxKj2iCbKjpUGkD-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 30 13:51:40 2010 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 C270E1065676; Sat, 30 Jan 2010 13:51:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 42BD58FC1B; Sat, 30 Jan 2010 13:51:39 +0000 (UTC) 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 o0UDpQC3053952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Jan 2010 15:51:26 +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 o0UDpQU4073478; Sat, 30 Jan 2010 15:51:26 +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 o0UDpQZu073477; Sat, 30 Jan 2010 15:51:26 +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, 30 Jan 2010 15:51:26 +0200 From: Kostik Belousov To: Pawel Jakub Dawidek Message-ID: <20100130135126.GV3877@deviant.kiev.zoral.com.ua> References: <4B636812.8060403@FreeBSD.org> <20100130112749.GA1660@garage.freebsd.pl> <20100130114451.GB1660@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2HdWiV8iqzNK3pYB" Content-Disposition: inline In-Reply-To: <20100130114451.GB1660@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at 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 Cc: freebsd-hackers@freebsd.org, Alexander Motin , FreeBSD-Current , freebsd-geom@freebsd.org Subject: Re: Deadlock between GEOM and devfs device destroy and process exit. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2010 13:51:41 -0000 --2HdWiV8iqzNK3pYB Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 30, 2010 at 12:44:51PM +0100, Pawel Jakub Dawidek wrote: > On Sat, Jan 30, 2010 at 12:27:49PM +0100, Pawel Jakub Dawidek wrote: > > On Sat, Jan 30, 2010 at 12:58:26AM +0200, Alexander Motin wrote: > > > Hi. > > >=20 > > > Experimenting with SATA hot-plug I've found quite repeatable deadlock > > > case. Problem observed when several SATA devices, opened via devfs, > > > disappear at exactly same time. In my case, at time of unplugging SATA > > > Port Multiplier with several disks beyond it. All I have to do is to = run > > > several `dd if=3D/dev/adaX of=3D/dev/null bs=3D1m &` commands and unp= lug > > > multiplier. That causes predictable I/O errors and devices destructio= n. > > > But with high probability several dd processes getting stuck in kerne= l. > > [...] > >=20 > > I observed the same thing yesterday while stress-testing HAST: > >=20 > > 3659 2504 3659 0 DE+ GEOM top 0x8079a348 dd > > 3658 2102 2102 0 DE+ GEOM top 0x8079a348 hastd > > 2 0 0 0 DL devdrn 0x85b1bc68 [g_event] > >=20 > > Both dd(1) and hastd(8) wait for the GEOM topology lock in the exit pat= h, > > which is already held by the g_event thread. >=20 > Maybe I'll add how I understand what's going on: >=20 > GEOM calls destroy_dev() while holding the topology lock. >=20 > Destroy_dev() wants to destroy device, but can't because there are > threads that still have it open. >=20 > The threads can't close it, because to close it they need the topology > lock. >=20 > The deadlock is quite obvious, IMHO. >=20 > I believe the problem could be solved by dropping the topology lock in > g_dev_orphan() when calling destroy_dev(dev), but it is hard to say if > it is safe to drop the topology lock there. Maybe Poul-Henning could > take a look. As I already said, if you cannot drop a lock, destroy_dev_sched() is designed to handle this. You should be careful to not allow any further activitity on the device scheduled for destruction. --2HdWiV8iqzNK3pYB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktkOV0ACgkQC3+MBN1Mb4geLQCg3v+nX9pTfbMUUpasQBDnMwnd B7EAoN5oA9K9nFfI62P4vwKRzIUyAMO7 =15Wt -----END PGP SIGNATURE----- --2HdWiV8iqzNK3pYB-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 30 18:34:25 2010 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 27806106566B; Sat, 30 Jan 2010 18:34:25 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-px0-f183.google.com (mail-px0-f183.google.com [209.85.216.183]) by mx1.freebsd.org (Postfix) with ESMTP id E34E68FC13; Sat, 30 Jan 2010 18:34:24 +0000 (UTC) Received: by pxi13 with SMTP id 13so1260023pxi.3 for ; Sat, 30 Jan 2010 10:34:24 -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=Opk8+v1Ajo2h1aduqPkWN/GgyXjgky+DID09JSCpQtM=; b=hDcZtq2erJn1l41E71SF8W74NIcIXFEB63IeJ55T5gn+N+DSnzVKMzEFdVRjGVux9j vAgbjmICGdPRULDty63DdTnXqbkKJZyPsJW1UeK5EfD/aYTSYT4YDZ+DV1gMkIhcI/c/ IpT1Lnyfp7riIbQK09tx46qUHWc4TszMvCiMI= 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=Vecv4DRpIkFUTYgkwwSCqfQjGtnaCBBA9kW28GImBI/inmCqt4BfnIbt7Kih2Fjgj6 e9PJ8zakSboeC9M3qOcUsE/ENf3sVl9/XvkZGxpH4RasF0DpzMM0ms8RnyTi8AKrIIo+ N+nfDi5B0KiolJNEbdcuKGqVm/YbqHfgIi8aY= MIME-Version: 1.0 Received: by 10.143.153.19 with SMTP id f19mr1648545wfo.36.1264876464480; Sat, 30 Jan 2010 10:34:24 -0800 (PST) In-Reply-To: <4B32A1BF.1050200@protected-networks.net> References: <4B31AABD.2020804@ongs.co.jp> <4B322F56.3050703@protected-networks.net> <4B324994.2010805@icyb.net.ua> <4B328172.8070507@protected-networks.net> <4B329CF9.2020407@icyb.net.ua> <4B32A1BF.1050200@protected-networks.net> Date: Sat, 30 Jan 2010 12:34:24 -0600 Message-ID: From: Alan Cox To: Michael Butler Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-emulation@freebsd.org, freebsd-current , Andriy Gapon Subject: Re: JFYI: VirtualBox stable/unstable setteings (3.0.51.r22902) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: alc@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 18:34:25 -0000 On Wed, Dec 23, 2009 at 5:03 PM, Michael Butler wrote: > On 12/23/09 17:56, Alan Cox wrote: > >> Yes, there is an i386-specific race condition that I understand but >> haven't >> fixed. It's typically triggered by the page daemon calling uma_reclaim(). >> It affects all versions from 7.2 to HEAD. >> > > Ah - that's a shame because it does offer a noticeable "speed-up" on this > device with large executables, > > I just wanted to let you (and everyone else) know that this race condition with superpage promotion on i386 has been addressed in FreeBSD 7.x, 8.x, and HEAD. At this time, I don't know of any other bugs affecting superpage usage on i386. Regards, Alan From owner-freebsd-current@FreeBSD.ORG Sat Jan 30 18:51:33 2010 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 3B4BF106568B; Sat, 30 Jan 2010 18:51:33 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by mx1.freebsd.org (Postfix) with ESMTP id DA62F8FC15; Sat, 30 Jan 2010 18:51:31 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id e21so473520fga.13 for ; Sat, 30 Jan 2010 10:51:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=dEXZ1Vj0P9wqQ2ZosrktV+LFjbF33lwlRYQktMttHto=; b=B562ljXk9MSAlrEc3CcjbqRtts1ajmsJoWmCi7LTVICuHDBZBmZ+cZJMK/s0loPN2p 3bb3eLGKfa3AI0Y5rNaD0uLyeADXwG2033Hs3CCqpXrM1n0P3AUCEfljKaI2Y8YbHERt hlY3g2RXvFxGO+3EokysMnYY2Ia9nGugm5ywk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=TOyD6AFwyTsGKverlDiI6053vcBcTXxzXBoZfm7CHWvtasDeCGJUFe9AisXO097Z0o oIieYmLjqgJc+79tNGmf7dmPfi5O3sNoX+/7O1GgM5mFPXfAUc07q56AgWbnoxbffUaa uNlDUTmS5uI7Al5T1naqFsozGZ9ugxO+hKWz4= Received: by 10.103.35.5 with SMTP id n5mr1155025muj.132.1264877490919; Sat, 30 Jan 2010 10:51:30 -0800 (PST) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 23sm3341149mun.41.2010.01.30.10.51.29 (version=SSLv3 cipher=RC4-MD5); Sat, 30 Jan 2010 10:51:30 -0800 (PST) Sender: Alexander Motin Message-ID: <4B647FAF.4090409@FreeBSD.org> Date: Sat, 30 Jan 2010 20:51:27 +0200 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <4B636812.8060403@FreeBSD.org> <20100130112749.GA1660@garage.freebsd.pl> <20100130114451.GB1660@garage.freebsd.pl> In-Reply-To: <20100130114451.GB1660@garage.freebsd.pl> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, FreeBSD-Current , kib@FreeBSD.org, freebsd-geom@freebsd.org Subject: Re: Deadlock between GEOM and devfs device destroy and process exit. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2010 18:51:33 -0000 Pawel Jakub Dawidek wrote: > On Sat, Jan 30, 2010 at 12:27:49PM +0100, Pawel Jakub Dawidek wrote: >> On Sat, Jan 30, 2010 at 12:58:26AM +0200, Alexander Motin wrote: >>> Experimenting with SATA hot-plug I've found quite repeatable deadlock >>> case. Problem observed when several SATA devices, opened via devfs, >>> disappear at exactly same time. In my case, at time of unplugging SATA >>> Port Multiplier with several disks beyond it. All I have to do is to run >>> several `dd if=/dev/adaX of=/dev/null bs=1m &` commands and unplug >>> multiplier. That causes predictable I/O errors and devices destruction. >>> But with high probability several dd processes getting stuck in kernel. >> [...] >> >> I observed the same thing yesterday while stress-testing HAST: >> >> 3659 2504 3659 0 DE+ GEOM top 0x8079a348 dd >> 3658 2102 2102 0 DE+ GEOM top 0x8079a348 hastd >> 2 0 0 0 DL devdrn 0x85b1bc68 [g_event] >> >> Both dd(1) and hastd(8) wait for the GEOM topology lock in the exit path, >> which is already held by the g_event thread. > > Maybe I'll add how I understand what's going on: > > GEOM calls destroy_dev() while holding the topology lock. > > Destroy_dev() wants to destroy device, but can't because there are > threads that still have it open. > > The threads can't close it, because to close it they need the topology > lock. > > The deadlock is quite obvious, IMHO. You are right, but as it happens not every time I was interested why. After closer look I found two different scenarios. In first case application receives I/O error and closes device. On device close CAM calls disk_destroy(), which schedules device destruction. When destroy_dev() called, device already free and there is no problem, as these events are always asynchronous. In second case, application also receives I/O error, but before it is able to react, GEOM starts handling of disk_gone(), called by CAM. As result, destroy_dev() called with device still opened, and it can't ever be closed due to topology lock held. I've played a bit with destroy_dev_sched(), but locking indeed looks not to be easy. Is there some known good practice? destroy_dev_sched_cb() looks a bit more promising. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Sat Jan 30 19:34:08 2010 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 C7A64106568D; Sat, 30 Jan 2010 19:34:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id 976E88FC12; Sat, 30 Jan 2010 19:34:07 +0000 (UTC) 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 o0UJY32S077289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Jan 2010 21:34:03 +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 o0UJY2js006692; Sat, 30 Jan 2010 21:34:02 +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 o0UJY2pt006691; Sat, 30 Jan 2010 21:34:02 +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, 30 Jan 2010 21:34:02 +0200 From: Kostik Belousov To: Alexander Motin Message-ID: <20100130193402.GB3877@deviant.kiev.zoral.com.ua> References: <4B636812.8060403@FreeBSD.org> <20100130112749.GA1660@garage.freebsd.pl> <20100130114451.GB1660@garage.freebsd.pl> <4B647FAF.4090409@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Vu7hzOi38yxTgbOc" Content-Disposition: inline In-Reply-To: <4B647FAF.4090409@FreeBSD.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at 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 Cc: freebsd-hackers@freebsd.org, FreeBSD-Current , Pawel Jakub Dawidek , freebsd-geom@freebsd.org Subject: Re: Deadlock between GEOM and devfs device destroy and process exit. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2010 19:34:08 -0000 --Vu7hzOi38yxTgbOc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 30, 2010 at 08:51:27PM +0200, Alexander Motin wrote: > Pawel Jakub Dawidek wrote: > > On Sat, Jan 30, 2010 at 12:27:49PM +0100, Pawel Jakub Dawidek wrote: > >> On Sat, Jan 30, 2010 at 12:58:26AM +0200, Alexander Motin wrote: > >>> Experimenting with SATA hot-plug I've found quite repeatable deadlock > >>> case. Problem observed when several SATA devices, opened via devfs, > >>> disappear at exactly same time. In my case, at time of unplugging SATA > >>> Port Multiplier with several disks beyond it. All I have to do is to = run > >>> several `dd if=3D/dev/adaX of=3D/dev/null bs=3D1m &` commands and unp= lug > >>> multiplier. That causes predictable I/O errors and devices destructio= n. > >>> But with high probability several dd processes getting stuck in kerne= l. > >> [...] > >> > >> I observed the same thing yesterday while stress-testing HAST: > >> > >> 3659 2504 3659 0 DE+ GEOM top 0x8079a348 dd > >> 3658 2102 2102 0 DE+ GEOM top 0x8079a348 hastd > >> 2 0 0 0 DL devdrn 0x85b1bc68 [g_event] > >> > >> Both dd(1) and hastd(8) wait for the GEOM topology lock in the exit pa= th, > >> which is already held by the g_event thread. > >=20 > > Maybe I'll add how I understand what's going on: > >=20 > > GEOM calls destroy_dev() while holding the topology lock. > >=20 > > Destroy_dev() wants to destroy device, but can't because there are > > threads that still have it open. > >=20 > > The threads can't close it, because to close it they need the topology > > lock. > >=20 > > The deadlock is quite obvious, IMHO. >=20 > You are right, but as it happens not every time I was interested why. > After closer look I found two different scenarios. >=20 > In first case application receives I/O error and closes device. On > device close CAM calls disk_destroy(), which schedules device > destruction. When destroy_dev() called, device already free and there is > no problem, as these events are always asynchronous. >=20 > In second case, application also receives I/O error, but before it is > able to react, GEOM starts handling of disk_gone(), called by CAM. As > result, destroy_dev() called with device still opened, and it can't ever > be closed due to topology lock held. >=20 > I've played a bit with destroy_dev_sched(), but locking indeed looks not > to be easy. Is there some known good practice? destroy_dev_sched_cb() > looks a bit more promising. What do you mean by not easy locking ? destroy_dev_sched(dev) =3D=3D destroy_dev_sched_cb(dev, NULL, NULL). There is even a man page describing the interface. Main issue with destroy_dev_sched is the window between a moment when device is scheduled for destruction and thus kept in half-demolished state, and actual removal of devfs node. My exemplary case has been snp(4) before tty got rewritten, see r. 1.107 of sys/dev/snp/snp.c. No calls to destroy_dev_sched() that I placed in the src/ a kept around, that is good because corresponding subsystems got serious rewrite. --Vu7hzOi38yxTgbOc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktkiaoACgkQC3+MBN1Mb4igcACeI1FTL2MKQZW5g92KEk1V6PJD CsEAoKaG2t3br7mDNjSSVcfGA9zA0Khp =rl8T -----END PGP SIGNATURE----- --Vu7hzOi38yxTgbOc-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 30 20:07:42 2010 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 C36131065694; Sat, 30 Jan 2010 20:07:42 +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 64BE08FC14; Sat, 30 Jan 2010 20:07:42 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 81C851CEF1; Sat, 30 Jan 2010 21:07:41 +0100 (CET) Date: Sat, 30 Jan 2010 21:07:41 +0100 From: Ed Schouten To: Kostik Belousov Message-ID: <20100130200741.GG77705@hoeg.nl> References: <4B636812.8060403@FreeBSD.org> <20100130112749.GA1660@garage.freebsd.pl> <20100130114451.GB1660@garage.freebsd.pl> <4B647FAF.4090409@FreeBSD.org> <20100130193402.GB3877@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="213B/23bCmw+8GSd" Content-Disposition: inline In-Reply-To: <20100130193402.GB3877@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org, Alexander Motin , FreeBSD-Current , Pawel Jakub Dawidek , freebsd-geom@freebsd.org Subject: Re: Deadlock between GEOM and devfs device destroy and process exit. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2010 20:07:42 -0000 --213B/23bCmw+8GSd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, * Kostik Belousov wrote: > My exemplary case has been snp(4) before tty got rewritten, see r. 1.107 > of sys/dev/snp/snp.c. No calls to destroy_dev_sched() that I placed in > the src/ a kept around, that is good because corresponding subsystems > got serious rewrite. The current TTY code still uses destroy_dev_sched_cb(). In a very old version of the new TTY code, close() on a pseudo-terminal master device would also end up calling destroy_dev(), which meant it blocked until the TTY was closed as well, which is obviously not what it should do. I changed the TTY code to destroy_dev_sched_cb(), which means tty_gone() doesn't block. The TTY layer later calls a callback function, so the pts driver can deallocate the softc and reclaim the unit number (pts/%d). --=20 Ed Schouten WWW: http://80386.nl/ --213B/23bCmw+8GSd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktkkY0ACgkQ52SDGA2eCwWflQCdFWmTG3J08ANqTv7nfWwvgTqB B48An2Pi0/1RaRXOzwYoGOXgGBYinlHo =VEWu -----END PGP SIGNATURE----- --213B/23bCmw+8GSd-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 30 20:12:31 2010 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 B930E1065894; Sat, 30 Jan 2010 20:12:31 +0000 (UTC) (envelope-from vinnix.bsd@gmail.com) Received: from mail-pz0-f194.google.com (mail-pz0-f194.google.com [209.85.222.194]) by mx1.freebsd.org (Postfix) with ESMTP id 73F6E8FC1E; Sat, 30 Jan 2010 20:12:31 +0000 (UTC) Received: by pzk32 with SMTP id 32so353402pzk.27 for ; Sat, 30 Jan 2010 12:12:31 -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; bh=BGLlYw+4gHko7QKxl1VZQyX6GAWlXJjQZdNRcFD9gGQ=; b=uDx39ifGLSomPtt2aUYt1TfAz8LUPJzbY5wgEttpLhFsO3J3GVXjA2+6WY3CKpK6+P VwFa4jRZnbsmqjND/Fw5X4JlOfS35taxFRCQN7Lg4JtnWWsLMEL7kEsUDJFPICEFMbro yH1itt7dNGNUw7xSDLaMnkvvZKpfDiIL7gIo0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=XdX416K63A0+Avw1iyRxQOK+dAiBjkR7rYnlYoq5Z2cm8Lv9/qcwyPoDZqqGCrEDUg jXDByf+fo9xJukWGaBGWdxxwAEDDNuH2Q/PNkVZ46/iQ8l0NWB7lY7h41mnlbF/eIcCZ 3mSv+UaDfKn06W8lJPD/Z/VS7vU6adb78xIH0= MIME-Version: 1.0 Received: by 10.141.90.5 with SMTP id s5mr1725338rvl.81.1264882350879; Sat, 30 Jan 2010 12:12:30 -0800 (PST) Date: Sat, 30 Jan 2010 18:12:30 -0200 Message-ID: <1e31c7981001301212w4b787795j1e22837342faee5a@mail.gmail.com> From: Vinicius Abrahao To: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, freebsd-usb@freebsd.org, x11@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: amdmi3@freebsd.org, daimler3@gmail.com Subject: PS3's Joystick on FreeBSD (can be possible?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 20:12:31 -0000 Greetings Guys, I'm finally having some time to have fun with my FreeBSD. :-) Do you know about any progress with joystick supports? Here I have a PS3 controller, and have some time to help with tests and little coding. ugen1.5: at usbus1 uhid0: on usbus1 Is somebody working with it? http://wiki.freebsd.org/DmitryMarakasov .................................................. (Dmitry, do you need any help?) http://lists.freebsd.org/pipermail/freebsd-usb/2009-May/006812.html ..... ( Deniz, have you experiment any change with 8.0 ?) http://www.freshports.org/devel/linux-js/ ................................................... (I'll learn more about this driver) http://www.freshports.org/x11-drivers/xf86-input-joystick/ ........................ ( can this driver work with uhid devices? ) http://wiki.freebsd.org/uhidd ...................................................................... (I'll studying more about uhidd!) Best regards, Sorry for this mega-cross-post, but I think we all have interests with this working. []s Vinnix From owner-freebsd-current@FreeBSD.ORG Sat Jan 30 20:12:44 2010 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 CFB131065692; Sat, 30 Jan 2010 20:12:44 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 5C80A8FC0C; Sat, 30 Jan 2010 20:12:44 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id CA7C11E0076B; Sat, 30 Jan 2010 21:12:42 +0100 (CET) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.3/8.14.3) with ESMTP id o0UK60KV002436; Sat, 30 Jan 2010 21:06:00 +0100 (CET) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.3/8.14.3/Submit) id o0UK5xqk002435; Sat, 30 Jan 2010 21:05:59 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Sat, 30 Jan 2010 21:05:59 +0100 To: Andriy Gapon Message-ID: <20100130200559.GA2263@triton8.kn-bremen.de> References: <4B61C688.2050609@FreeBSD.org> <4B61CCB6.4040005@FreeBSD.org> <4B62C97F.7080000@FreeBSD.org> <4B62EDFB.1060103@icyb.net.ua> <201001291949.o0TJnCAa013981@triton8.kn-bremen.de> <4B633FED.3030103@FreeBSD.org> <4B6358F3.7080908@icyb.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4B6358F3.7080908@icyb.net.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Alexander Motin , freebsd-current@FreeBSD.org, Juergen Lock , Yamagi Burmeister Subject: Re: Pack of CAM improvements X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Jan 2010 20:12:44 -0000 On Fri, Jan 29, 2010 at 11:53:55PM +0200, Andriy Gapon wrote: > on 29/01/2010 22:07 Alexander Motin said the following: > > Juergen Lock wrote: > >> Ok while we are talking about ahci(4) on IXP700... Can anyone reproduce > >> the `test unit ready' bug on one of those? Since I saw no reply to > >> my post, > >> http://docs.freebsd.org/cgi/mid.cgi?201001231407.o0NE7l8j002620 > >> maybe the bug is controller-specific? How to reproduce: just try > >> camcontrol tur adaX > >> or > >> cdrecord -scanbus > >> or (at least I think this is the same issue) start xfburn without hal > >> running, then watch for the bus to hang at the next disk access. > >> (Also leaving the disk led on solid here.) With the previous patch, > >> http://people.freebsd.org/~mav/cam-ata.20100119.patch > >> (haven't tested the latest one yet) at least it now seems to recover > >> after some timeout, leaving this in dmesg: (sorry I didn't notice > >> when I first tried, guess I didn't wait long enough...) > > > > It is controller specific. Intel and NVidia controllers just return > > error immediately, as they should, and continue operation. ATI IXP700 - > > doesn't: > > I have this simple patch in my local tree: > > --- a/sys/cam/ata/ata_xpt.c > +++ b/sys/cam/ata/ata_xpt.c > @@ -1341,6 +1341,20 @@ ata_action(union ccb *start_ccb) > (*(sim->sim_action))(sim, start_ccb); > break; > } > + case XPT_SCSI_IO: > + { > + struct cam_ed *device; > + > + device = start_ccb->ccb_h.path->device; > + if (device->protocol == PROTO_ATA) { > + xpt_print(start_ccb->ccb_h.path, > + "XPT_SCSI_IO command for device with PROTO_ATA\n"); > + start_ccb->ccb_h.status = CAM_REQ_INVALID; > + xpt_done(start_ccb); > + return; > + } > + /* FALLTHROUGH */ > + } > default: > xpt_action_default(start_ccb); > break; > > Here's what it does: > $ drecord -scanbus > Cdrecord-ProDVD-ProBD-Clone 2.01.01a72 (amd64-unknown-freebsd9.0) Copyright (C) > 1995-2010 Jörg Schilling > Using libscg version 'schily-0.9'. > scsibus0: > 0,0,0 0) '' '' '' NON CCS Disk > 0,1,0 1) * > 0,2,0 2) * > 0,3,0 3) * > 0,4,0 4) * > 0,5,0 5) * > 0,6,0 6) * > 0,7,0 7) * > scsibus1: > 1,0,0 100) '' '' '' NON CCS Disk > 1,1,0 101) * > 1,2,0 102) * > 1,3,0 103) * > 1,4,0 104) * > 1,5,0 105) * > 1,6,0 106) * > 1,7,0 107) * > scsibus5: > 5,0,0 500) 'Optiarc ' 'DVD RW AD-7191S ' '1.02' Removable CD-ROM > 5,1,0 501) * > 5,2,0 502) * > 5,3,0 503) * > 5,4,0 504) * > 5,5,0 505) * > 5,6,0 506) * > 5,7,0 507) * > > And in dmesg: > kernel: (pass0:ahcich0:0:0:0): XPT_SCSI_IO command for device with PROTO_ATA > last message repeated 2 times > kernel: (pass1:ahcich1:0:0:0): XPT_SCSI_IO command for device with PROTO_ATA > > I remember that this patch is not perfect, but it works for my simple desktop > setup. No bad side-effects from it either. Thanx, applied and confirmed working for me here as well! :) Juergen From owner-freebsd-current@FreeBSD.ORG Sat Jan 30 20:29:48 2010 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 D912D1065670; Sat, 30 Jan 2010 20:29:48 +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 A08A38FC20; Sat, 30 Jan 2010 20:29:48 +0000 (UTC) Received: by palm.hoeg.nl (Postfix, from userid 1000) id CD6C21CEDF; Sat, 30 Jan 2010 21:29:47 +0100 (CET) Date: Sat, 30 Jan 2010 21:29:47 +0100 From: Ed Schouten To: Vinicius Abrahao Message-ID: <20100130202947.GH77705@hoeg.nl> References: <1e31c7981001301212w4b787795j1e22837342faee5a@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Hv6+fPJLRRhGCb8a" Content-Disposition: inline In-Reply-To: <1e31c7981001301212w4b787795j1e22837342faee5a@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: daimler3@gmail.com, freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, amdmi3@freebsd.org, freebsd-usb@freebsd.org, x11@freebsd.org Subject: Re: PS3's Joystick on FreeBSD (can be possible?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 20:29:49 -0000 --Hv6+fPJLRRhGCb8a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Vinicius Abrahao wrote: > I'm finally having some time to have fun with my FreeBSD. :-) > Do you know about any progress with joystick supports? >=20 > Here I have a PS3 controller, and have some time to help with tests > and little coding. > ugen1.5: at usbus1 > uhid0: addr 5> on usbus1 >=20 > Is somebody working with it? So those are the wireless controllers, but connected using the USB cable that you normally use to charge it? --=20 Ed Schouten WWW: http://80386.nl/ --Hv6+fPJLRRhGCb8a Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAktklrsACgkQ52SDGA2eCwWxLACeNWyoquV6JwamDmy6rPLVVIh7 LTsAn2fxzsR5J06UwPZT8ps4KHO4CKap =95so -----END PGP SIGNATURE----- --Hv6+fPJLRRhGCb8a-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 30 21:53:56 2010 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 D429A106568B; Sat, 30 Jan 2010 21:53:56 +0000 (UTC) (envelope-from vinnix.bsd@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 17FDF8FC0A; Sat, 30 Jan 2010 21:53:55 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 8so634694qwh.7 for ; Sat, 30 Jan 2010 13:53:55 -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; bh=2PFblp8v4HXLX1/kdqA5Lfd1AvAzV+5+2lbU0ndUlDw=; b=rqYdgrzp3KZRIc17LRp6b8BLOV/etJnJF9HdEiYl8Zyxu8wwkGcHNX63hcLJNfHS3y wh+29YLqGf+eYk8iONq7aShxWwOwfjHwOt8bxZyqUfNj2drMx6ruyPZpN38LveCBVnI4 YLirzxINoHy02dzNIG/wi/B2GWnheT0+0puxw= 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; b=DksbWuPu8ikM3lHugGxQ2RiDQ/8zs3JS1eigo9euMGKTT1186nIj07oxob2ZvD9+jn VCM2GSm9+QmflvMkFpIdMWpAHOytkJHQOZEqu40PNunc6clbQmvXV1wnvkyqpD+hOGMq vZ1kC9Ds7WhYAri2fibkoSlMwmD6ww6pOVSyg= MIME-Version: 1.0 Received: by 10.224.123.72 with SMTP id o8mr1085914qar.373.1264888435269; Sat, 30 Jan 2010 13:53:55 -0800 (PST) In-Reply-To: <20100130202947.GH77705@hoeg.nl> References: <1e31c7981001301212w4b787795j1e22837342faee5a@mail.gmail.com> <20100130202947.GH77705@hoeg.nl> Date: Sat, 30 Jan 2010 19:53:55 -0200 Message-ID: <1e31c7981001301353w7e4a55d9s28117613b6433c45@mail.gmail.com> From: Vinicius Abrahao To: Ed Schouten Content-Type: text/plain; charset=ISO-8859-1 Cc: daimler3@gmail.com, freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, amdmi3@freebsd.org, freebsd-usb@freebsd.org, x11@freebsd.org Subject: Re: PS3's Joystick on FreeBSD (can be possible?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 21:53:57 -0000 > So those are the wireless controllers, but connected using the USB cable > that you normally use to charge it? > Yes, I forgot mention this. This joystick connects with PS3 by bluetooth. It has the "SIXAXIS" too that permit nice things like this: http://www.pabr.org/sixlinux/sixlinux.en.html Imagine one BSD-Mini-Chopper? ;-) From owner-freebsd-current@FreeBSD.ORG Sat Jan 30 22:40:15 2010 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 C4067106566B; Sat, 30 Jan 2010 22:40:15 +0000 (UTC) (envelope-from amdmi3@amdmi3.ru) Received: from smtp.timeweb.ru (smtp.timeweb.ru [92.53.104.116]) by mx1.freebsd.org (Postfix) with ESMTP id 7623C8FC0C; Sat, 30 Jan 2010 22:40:15 +0000 (UTC) Received: from [213.148.20.85] (helo=hive.panopticon) by smtp.timeweb.ru with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NbLyv-000335-Bz; Sun, 31 Jan 2010 01:39:57 +0300 Received: from hades.panopticon (hades.panopticon [192.168.0.32]) by hive.panopticon (Postfix) with ESMTP id 5724EB84D; Sun, 31 Jan 2010 01:40:13 +0300 (MSK) Received: by hades.panopticon (Postfix, from userid 1000) id D0CEDB829; Sun, 31 Jan 2010 01:40:12 +0300 (MSK) Date: Sun, 31 Jan 2010 01:40:12 +0300 From: Dmitry Marakasov To: Vinicius Abrahao Message-ID: <20100130224012.GE7854@hades.panopticon> References: <1e31c7981001301212w4b787795j1e22837342faee5a@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1e31c7981001301212w4b787795j1e22837342faee5a@mail.gmail.com> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-multimedia@freebsd.org, freebsd-current@freebsd.org, x11@freebsd.org, daimler3@gmail.com, freebsd-usb@freebsd.org Subject: Re: PS3's Joystick on FreeBSD (can be possible?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 22:40:15 -0000 * Vinicius Abrahao (vinnix.bsd@gmail.com) wrote: > I'm finally having some time to have fun with my FreeBSD. :-) > Do you know about any progress with joystick supports? > > Here I have a PS3 controller, and have some time to help with tests > and little coding. > ugen1.5: at usbus1 > uhid0: addr 5> on usbus1 > > Is somebody working with it? > > http://wiki.freebsd.org/DmitryMarakasov > .................................................. (Dmitry, do you > need any help?) No, I just need more free time to finally get to it. Actually, if it's attached as uhid, it may already work in e.g. SDL games. If it doesn't, it - Uses some non-standart report (i.e. reporting buttons/axes as 'vendor-specific' values, which software doesn't know how to deal with). In this case the report should be analyzed and a simple wrapper driver may be written) - Is the same case as with my M$ joystick, which uses standart, but a just a bit unusual report, which e.g. SDL is unable to parse. This should be fixed by my long-planned rewrite of HID parser for SDL, which will also be useable in OIS and possibly other libs. Let's start with usbhidctl -f /dev/uhid0 -r -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru