From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 00:05:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA3E416A4CE; Sun, 29 Aug 2004 00:05:10 +0000 (GMT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41A5343D69; Sun, 29 Aug 2004 00:05:10 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i7T057mk012110; Sat, 28 Aug 2004 20:05:07 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <200408271337.i7RDbXgu052801@pooker.samsco.org> References: <200408271337.i7RDbXgu052801@pooker.samsco.org> Date: Sat, 28 Aug 2004 20:05:05 -0400 To: re@freebsd.org, current@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: 5.3-RELEASE TODO - make/kqueue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 00:05:10 -0000 At 7:37 AM -0600 8/27/04, Scott Long wrote: > >Testing focuses for 5.3-RELEASE And update on Issue: > |---------------------------------+ > | make -DUSE_KQUEUE causes lockup | > | with buildworld -jBIGNUM | > |---------------------------------+ The description says: > |-------------------+---------------+--------------+------------| > | Attempts to use make(1) with KQueues appears to result in a | > | kernel hang under "heavy load". It would be desirable to fix | > | this both from the perspective of building FreeBSD quickly | > | as a developer, but also because it's an instability that | > | could show up under other high load and heavy use of | > | KQueues. See PR kern/57945 for a proposed patch and details. | > | This appear to be the product of a locking problem, and must | > | be fixed for 5.3. | > |-------------------+---------------+--------------+------------| I have done many buildworlds using the WITH_KQUEUE make over the past week. I have done at least 50 buildworlds in my dual-proc Althon machine, with -j ranging from 3 to 15. I have not seen any lockups since the fix for IPI deadlocks went in. I do still get the "*** Signal 6"s, even though I am now running with v1.76 of src/sys/kern/kern_lock.c. Actually I had updated that one source file, expecting to get revision 1.75 (and thus backout revision 1.74), as recently mentioned by Doug White. I just now realized that I ended up with 1.76... I guess I should try it one more time with 1.75 instead of 1.76. One observation which is perhaps interesting. I also modified sys/kern/kern_sig.c so that it prints out a message to the console whenever kill() or killpg1() is called with a SIGABRT. I tested that change, and it seems to work correctly with programs caling kill(SIGABRT), abort(), or raise(SIGABORT). However, when my buildworld dies with `make' claiming it saw a Signal 6, these printf's in kern_sig.c are never triggered. This failure is "eventually repeatable" for me, in that I can trigger it within 10 buildworlds. And *seems* that it only happens if I am also running a "folding-at-home" client at the same time. That client program is a Linux ELF binary, so maybe that is significant. Or maybe it's a red herring. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 00:14:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39DF116A4CE; Sun, 29 Aug 2004 00:14:19 +0000 (GMT) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7B8143D1D; Sun, 29 Aug 2004 00:14:18 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i7T0EH8j014328; Sat, 28 Aug 2004 20:14:18 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: <200408271337.i7RDbXgu052801@pooker.samsco.org> Date: Sat, 28 Aug 2004 20:14:16 -0400 To: re@freebsd.org, current@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: 5.3-RELEASE TODO - make/kqueue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 00:14:19 -0000 At 8:05 PM -0400 8/28/04, Garance A Drosihn wrote: > >This failure is "eventually repeatable" for me, in that I can >trigger it within 10 buildworlds. And *seems* that it only >happens if I am also running a "folding-at-home" client at the >same time. That client program is a Linux ELF binary, so maybe >that is significant. Or maybe it's a red herring. It may also be related to me running the make commands in a `screen' session, so I can detach from it. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 00:28:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 20F8316A4CE; Sun, 29 Aug 2004 00:28:56 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id CED7443D5C; Sun, 29 Aug 2004 00:28:55 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smtp3.sentex.ca (8.13.1/8.13.1) with ESMTP id i7T0Snlr080366; Sat, 28 Aug 2004 20:28:49 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i7T0Ssmr018799; Sat, 28 Aug 2004 20:28:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 385757303F; Sat, 28 Aug 2004 20:28:55 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040829002855.385757303F@freebsd-current.sentex.ca> Date: Sat, 28 Aug 2004 20:28:55 -0400 (EDT) Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 00:28:56 -0000 TB --- 2004-08-28 23:09:46 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-28 23:09:46 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-08-28 23:09:46 - checking out the source tree TB --- 2004-08-28 23:09:46 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2004-08-28 23:09:46 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-28 23:14:37 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-28 23:14:37 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2004-08-28 23:14:37 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-29 00:17:45 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-29 00:17:45 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2004-08-29 00:17:45 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Aug 29 00:17:45 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Aug 29 00:28:54 UTC 2004 TB --- 2004-08-29 00:28:54 - generating LINT kernel config TB --- 2004-08-29 00:28:54 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- 2004-08-29 00:28:54 - /usr/bin/make -B LINT TB --- 2004-08-29 00:28:54 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-29 00:28:54 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2004-08-29 00:28:54 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 29 00:28:54 UTC 2004 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf; PATH=/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/i386/legacy/usr/sbin:/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/i386/legacy/usr/bin:/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/i386/legacy/usr/games:/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/sbin:/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/bin:/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf/LINT FYI: static unit limits for vcoda are set: NVCODA=4 config: Error: device "ichwd" is unknown config: 1 errors *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-08-29 00:28:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-29 00:28:54 - ERROR: failed to build lint kernel TB --- 2004-08-29 00:28:54 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 00:54:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A63CB16A4CE for ; Sun, 29 Aug 2004 00:54:47 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 21E5843D67 for ; Sun, 29 Aug 2004 00:54:47 +0000 (GMT) (envelope-from lists@MHoerich.de) Received: (qmail 15933 invoked by uid 0); 29 Aug 2004 00:54:45 -0000 Received: from 217.83.192.253 by www50.gmx.net with HTTP; Sun, 29 Aug 2004 02:54:46 +0200 (MEST) Date: Sun, 29 Aug 2004 02:54:46 +0200 (MEST) From: "Mario Hoerich" To: current@FreeBSD.org MIME-Version: 1.0 References: X-Priority: 3 (Normal) X-Authenticated: #5114400 Message-ID: <29145.1093740886@www50.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [FIXED] Re: [5.3-B2] PPPoE broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 00:54:47 -0000 # Bjoern A. Zeeb: > 3) could also be > http://docs.FreeBSD.org/cgi/mid.cgi?200408271833.i7RIX8fw068973 ? Manually applying the diffs and rebuilding world+kernel seems to have fixed it. Great. Thanks for the really fast help. :) Cheers, Mario From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 01:06:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B9DAE16A4CE for ; Sun, 29 Aug 2004 01:06:19 +0000 (GMT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73DF543D39 for ; Sun, 29 Aug 2004 01:06:19 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-69-104-103-54.dsl.snfc21.pacbell.net [69.104.103.54])i7T163H9252844; Sat, 28 Aug 2004 21:06:12 -0400 Message-ID: <41312BFA.4040802@elischer.org> Date: Sat, 28 Aug 2004 18:06:02 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4130C0FE.6040000@OTEL.net> <12127.1093725059@www47.gmx.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Iasen Kostov cc: FreeBSD current mailing list cc: Mario Hoerich Subject: Re: [5.3-B2] PPPoE broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 01:06:19 -0000 Bjoern A. Zeeb wrote: > On Sat, 28 Aug 2004, Mario Hoerich wrote: > > >>Apparently problems aren't restricted to pppoed. Moving from >>BETA1 to BETA2 (on i386) without changing either kernconf >>or ppp.conf broke PPPoE-dialup via user-ppp for me. World >>has been entirely rebuild, so UPDATING:20040826 should be >>satisfied. > > > new kernel and new world ? > > > ... > >>Afaict the connection _is_ established, but no packets go >>out the wire. (Tested pinging numerical addresses as well, >>to rule out DNS). > > ... > >>Hints, anyone? > > > just some shoots in the dark: > > 1) checked your firewall options and packet counters ? > > 2) please post a `ngctl l` > > 3) could also be > http://docs.FreeBSD.org/cgi/mid.cgi?200408271833.i7RIX8fw068973 what is this.?. I can't fetch it.. ? > From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 01:16:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 973A616A4CE for ; Sun, 29 Aug 2004 01:16:24 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35E3E43D5C for ; Sun, 29 Aug 2004 01:16:24 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1C1EIx-0001wn-00; Sun, 29 Aug 2004 03:16:23 +0200 Received: from [217.83.3.59] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1C1EIw-0000vH-00; Sun, 29 Aug 2004 03:16:23 +0200 From: Max Laier To: freebsd-current@freebsd.org, erik.u@dnainternet.net Date: Sun, 29 Aug 2004 03:14:38 +0200 User-Agent: KMail/1.6.2 References: <413102D4.60804@dnainternet.net> In-Reply-To: <413102D4.60804@dnainternet.net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_M4SMBTUMjySxn33"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408290314.52675.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 Subject: Re: Trying to see pf's logs using tcpdump X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 01:16:24 -0000 --Boundary-02=_M4SMBTUMjySxn33 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 29 August 2004 00:10, Erik U. wrote: > On FreeBSD 5.2.1. > > I installed pf from the ports, configured and ran it. > I just get this error when trying to watch pf's logs: > > [root@nat] ~ $ tcpdump -n -e -ttt -r /var/log/pflog > tcpdump: unknown data link type 117 prefix this with "pf" as: [root@nat] ~ $ pftcpdump -n -e -ttt -r /var/log/pflog and you should be fine. > Why can't they just put the logs in text not in some damn binary.. It's not "some damn binary" it's a pcap file and it is uses as it has *all*= =20 the information and not just some obscure bits that the developer though=20 might be interesting. The great benefit of this is the ability to pass the= =20 pflog-output (more or less) unmodified to an IDS which usually needs more=20 information than most of the plain-text logs will give you. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-02=_M4SMBTUMjySxn33 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBMS4MXyyEoT62BG0RAqVAAJ4qwOZSlRsFRKcPztSX3MON5pA0tgCfRWQf mDhSP/bn3cUjP7ZDR0miHoI= =Hnhe -----END PGP SIGNATURE----- --Boundary-02=_M4SMBTUMjySxn33-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 01:27:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0C4716A4F8; Sun, 29 Aug 2004 01:27:06 +0000 (GMT) Received: from out014.verizon.net (out014pub.verizon.net [206.46.170.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6349143D2F; Sun, 29 Aug 2004 01:27:06 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from [10.0.3.231] ([141.153.175.38]) by out014.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040829012705.ISMH24490.out014.verizon.net@[10.0.3.231]>; Sat, 28 Aug 2004 20:27:05 -0500 From: "Alexandre \"Sunny\" Kovalenko" To: Marc Fonvieille In-Reply-To: <20040828184118.GA16378@abigail.blackend.org> References: <20040805071236.GA595@loge.nixsys.be> <20040828184118.GA16378@abigail.blackend.org> Content-Type: text/plain Message-Id: <1093742805.832.3.camel@RabbitsDen> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 28 Aug 2004 21:26:46 -0400 Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out014.verizon.net from [141.153.175.38] at Sat, 28 Aug 2004 20:27:04 -0500 cc: freebsd-current@freebsd.org Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 01:27:11 -0000 On Sat, 2004-08-28 at 14:41, Marc Fonvieille wrote: > Hello, > > I updated my -CURRENT (from 16/08) laptop to today's -CURRENT, and I see > a lot of difference with my touchpad. > Well, it's really not useable, the touchpad is less accurate, the double > tap & hold is not working anymore etc. To sum up, if I want to use X > with my laptop, I have to plug in a mouse. > > So I'd like to back to previous behavior, I tried various psm flags to > make my touchpad seen as a vanilla PS/2 mouse, but nothing works. > Is there a way to switch back? > > Marc > _______________________________________________ > 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" Roll psm.c (/usr/src/sys/isa/psm.c) to version 1.70 and rebuild the kernel. At least in my case, sensitivity becomes sane and double tap and drag is there. Last psm.c, I have tried to no avail was 1.79. I just cvsup'ed my system and saw psm.c 1.81, maybe it has changed to the better. I will know for sure in couple of hours, when build/install is done. However, 1.70 is sure bet. --- Alexandre "Sunny" Kovalenko. From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 01:52:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2E4216A4CE; Sun, 29 Aug 2004 01:52:00 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B908643D53; Sun, 29 Aug 2004 01:52:00 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smtp3b.sentex.ca (8.13.1/8.13.1) with ESMTP id i7T1pxXR070844; Sat, 28 Aug 2004 21:52:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7T1q02E024995; Sat, 28 Aug 2004 21:52:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 08C527303F; Sat, 28 Aug 2004 21:51:59 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040829015159.08C527303F@freebsd-current.sentex.ca> Date: Sat, 28 Aug 2004 21:51:59 -0400 (EDT) Subject: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 01:52:01 -0000 TB --- 2004-08-29 00:30:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-29 00:30:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2004-08-29 00:30:00 - checking out the source tree TB --- 2004-08-29 00:30:00 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2004-08-29 00:30:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-29 00:35:04 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-29 00:35:04 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-08-29 00:35:04 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-29 01:39:05 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-29 01:39:05 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-08-29 01:39:05 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Aug 29 01:39:05 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Aug 29 01:51:59 UTC 2004 TB --- 2004-08-29 01:51:59 - generating LINT kernel config TB --- 2004-08-29 01:51:59 - cd /home/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- 2004-08-29 01:51:59 - /usr/bin/make -B LINT TB --- 2004-08-29 01:51:59 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-29 01:51:59 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-08-29 01:51:59 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 29 01:51:59 UTC 2004 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf; PATH=/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/legacy/usr/sbin:/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/legacy/usr/bin:/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/legacy/usr/games:/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/sbin:/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/bin:/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/LINT /tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf/LINT FYI: static unit limits for vcoda are set: NVCODA=4 config: Error: device "ichwd" is unknown config: 1 errors WARNING: kernel contains GPL contaminated ext2fs filesystem *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2004-08-29 01:51:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-29 01:51:59 - ERROR: failed to build lint kernel TB --- 2004-08-29 01:51:59 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 01:58:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4388216A4CE for ; Sun, 29 Aug 2004 01:58:15 +0000 (GMT) Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67D3F43D5A for ; Sun, 29 Aug 2004 01:58:12 +0000 (GMT) (envelope-from dashevil@sympatico.ca) Received: from [192.168.2.32] ([65.93.59.22]) by tomts5-srv.bellnexxia.net ESMTP <20040829015811.GKYW18869.tomts5-srv.bellnexxia.net@[192.168.2.32]> for ; Sat, 28 Aug 2004 21:58:11 -0400 From: Chris Laverdure To: freebsd-current@freebsd.org In-Reply-To: <20040829015159.08C527303F@freebsd-current.sentex.ca> References: <20040829015159.08C527303F@freebsd-current.sentex.ca> Content-Type: text/plain Message-Id: <1093730290.1010.0.camel@elemental.DashEvil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 28 Aug 2004 21:58:11 +0000 Content-Transfer-Encoding: 7bit Subject: Re: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 01:58:15 -0000 On Sun, 2004-08-29 at 01:51, FreeBSD Tinderbox wrote: > cd /tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf; PATH=/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/legacy/usr/sbin:/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/legacy/usr/bin:/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/legacy/usr/games:/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/sbin:/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/bin:/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/LINT /tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf/LINT > FYI: static unit limits for vcoda are set: NVCODA=4 > config: Error: device "ichwd" is unknown > config: 1 errors > WARNING: kernel contains GPL contaminated ext2fs filesystem > *** Error code 1 > GPL contaminated? That really doesn't sound good at all.... From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 02:13:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 125AF16A4CE; Sun, 29 Aug 2004 02:13:59 +0000 (GMT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E70643D58; Sun, 29 Aug 2004 02:13:58 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-69-104-103-54.dsl.snfc21.pacbell.net [69.104.103.54])i7T2DtH9175762; Sat, 28 Aug 2004 22:13:56 -0400 Message-ID: <41313BE3.2070906@elischer.org> Date: Sat, 28 Aug 2004 19:13:55 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: jreff@freebsd.org, FreeBSD current mailing list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: New scheduler interface patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 02:13:59 -0000 (CC'd to current) Discussing the patch at: http://www.freebsd.org/~julian/f.diff or available to committers as p4 branch "nsched2" AS discussed before there were several "goals" in this change. 1/ remove the KSE structure from general view. (if not delete it entirely) (I admit it was a mistake to make it visible in the first place.. we learn) 2/ clean up thread and ksegrp shutdown. 3/ Make the libthr interface behave according to the rules that threads were supposed to behave by (I am working on documenting this) i.e all threads under a single KSEGRP are limitted by the ksegrp's concurrency and may be handled in some special ways by schedulers. (e.g. affinity etc). Threads under different KSEGRPs are treated as completely separate from each other by the schedulers and not restricted in any way.. Threads in different processes are treated separatly by the scheduler because they are in different ksegrps. the schedulers should only dimmly be aware of the concept of a process, but keenly aware of kergrps and threads. More on this later. 4/ Make the schedulers a bit more independent from each other and, in a related goal: 5/ move all fields in the thread, and ksegrp structures that were scheduler internal implementation dependent into the scheduler specific extensions for those structures.. thus runqueue hooks etc are no longer generally visible. This allows development of schedulers that use completely different internal structures, such as puting a thread on multiple queues at once. There are a 6th and 7th goal for this particular patch: 6/ No changes to functionality of either sheduler (as far as possible) 7/ Comments, field-names, structure names etc. should be left as much alone as possible, even if generally making them inaccurate, in order to make the diff itself as small as possible. This should make it possible for you or others to prove to yourself that the schedulers are basically unalterred in a functional manner, without drowning the diff in non-functional nomenclature and comment changes. Optimisations which can now be made are NOT included in these diffs for the reason given above. I also used macros to achieve some of this. My intention is that after the FUNCTIONAL change has been committed and we all agree that functionality has not changed, that a completely separate pass should be made to fix all that stuff and to clean it up.. The aim is to have a working schedule(s) at all times.. Method: phase 1. I first made a set of diffs that absteacted all the current KSE handling to a set of sched_calls, and manipulated the number of KSEs via a sched_set_concurrency() call. (and some variantes of it.. init_concurrency.. reset_concurrency() etc.) The KSE structires were moved in their entirety to the sched_{4bsd,ule}.c files to ENSURE that nothing else was accessing them. Since these new sched_ methods were common to both schedulers I added them to kern_switch.c (at the bottom). This file was then INCLUDED into both schedulers so it could pick up their local definitions of the KSE structure etc. (these diffs are available on request) Phase 2 Once that was done and nothing outside the schedulers could see the KSE sructures I then merged the KSE sructure and the td_sched structure. The resulting structure is the td_sched structure however the fields from the kse still have their old names and cod estill refers to KSEs and compiles due to the macro "#define kse td_sched" . This meant that every thread has a KSE at all times. I could then remove all the kse_alloc() etc. stuff as they are allocated as part of the thread. Some fields moved from the ksegrp to the kg_sched extension. I added counters to the ksegrp structure to implement the concurrency calls. Nothing outside the schedulers was changed in this phase as all relevent code had already been isolated to the schedulers in phase 1. Phase 3 (Not yet done) After committing and testing, a pass over the code to rename items,correct comments, make new optimisations etc. will be made. Phase 4 Experiment with radically different and revolutionary schedulers. problems: * There may be an interration between the concurrency counters and the preemption code that was just re-enabled. A preemptionmay cause the ksegrp to lose track of the real status. I need to check this in the next day. This could lead to a threaded process 'freezing'. * Load Average under ULE is completely whacked.. I hope you (jeffr) can see what I've done wrong here. * I think I need to look at the new libthr interface code and make an alternate thr_create() that allows libthr to create all its threads under a single ksegrp, with a concurrency of NCPU (the suggested maximum for a ksegrp concurrency). The old thr_create was a strange hybrid.. All threads scheduled independently with no cuncurrency limit (i.e able to flood the run queues) but all onder one KSEGRP. Performance testing will be needed to check which way to go. From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 02:46:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECF0616A4CE for ; Sun, 29 Aug 2004 02:46:24 +0000 (GMT) Received: from web40701.mail.yahoo.com (web40701.mail.yahoo.com [66.218.78.158]) by mx1.FreeBSD.org (Postfix) with SMTP id 9B9F043D73 for ; Sun, 29 Aug 2004 02:46:24 +0000 (GMT) (envelope-from wisco_disco@yahoo.com) Message-ID: <20040829024624.43988.qmail@web40701.mail.yahoo.com> Received: from [24.208.53.189] by web40701.mail.yahoo.com via HTTP; Sat, 28 Aug 2004 19:46:24 PDT Date: Sat, 28 Aug 2004 19:46:24 -0700 (PDT) From: Doug Poland To: David Wolfskill In-Reply-To: <200408282000.i7SK00ws028814@bunrab.catwhisker.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-current@freebsd.org Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: doug@polands.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 02:46:25 -0000 > David Wolfskill wrote: > > Would this have anything to do with the mouse on a Dell laptop > > moving all by itself? When I boot with ACPI enabled on 5.2.1-R or > > 5.3Beta the mouse will simply go wild, moving all over the screen at > > will. This happens at the console and in X (both XFree86 and XOrg) > > Depends on the type of "pointing device(s)" available/in use: it's > fairly common for the "eraser head" (trackpoint) devices to do this. > The laptop in question has a trackpoint and touchpoint pad. I've never attempted to disable either device. So is it possible to disable one or the other, or both, to keep the mouse from going wild? -- Regards, Doug __________________________________ Do you Yahoo!? Yahoo! Mail - Helps protect you from nasty viruses. http://promotions.yahoo.com/new_mail From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 02:59:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C80FD16A4CE; Sun, 29 Aug 2004 02:59:25 +0000 (GMT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 2550F43D77; Sun, 29 Aug 2004 02:59:25 +0000 (GMT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 29 Aug 2004 03:59:24 +0100 (BST) To: current@freebsd.org Date: Sun, 29 Aug 2004 03:59:24 +0100 From: Ian Dowse Message-ID: <200408290359.aa54022@salmon.maths.tcd.ie> cc: amd64@freebsd.org Subject: Loader-preloaded modules on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 02:59:25 -0000 With the latest -CURRENT, it should now be possible to load kernel modules on the amd64 platform from /boot/loader.conf or the loader prompt just like on other platforms. Let me know if you notice any problems. Assuming there are no major issues uncovered, the changes to support this will hopefully get merged into RELENG_5 before the release. Ian From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 03:03:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E1F916A4CE for ; Sun, 29 Aug 2004 03:03:45 +0000 (GMT) Received: from web40706.mail.yahoo.com (web40706.mail.yahoo.com [66.218.78.163]) by mx1.FreeBSD.org (Postfix) with SMTP id 5D15943D41 for ; Sun, 29 Aug 2004 03:03:44 +0000 (GMT) (envelope-from wisco_disco@yahoo.com) Message-ID: <20040829030344.93993.qmail@web40706.mail.yahoo.com> Received: from [24.208.53.189] by web40706.mail.yahoo.com via HTTP; Sat, 28 Aug 2004 20:03:44 PDT Date: Sat, 28 Aug 2004 20:03:44 -0700 (PDT) From: Doug Poland To: Robert Watson In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-current@freebsd.org Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: doug@polands.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 03:03:45 -0000 > Robert Watson wrote: > > > > Would this have anything to do with the mouse on a Dell laptop > > moving all by itself? When I boot with ACPI enabled on 5.2.1-R > > or 5.3Beta the mouse will simply go wild, moving all over the > > screen at will. This happens at the console and in X (both > > XFree86 and XOrg). > > No, that's probably a problem with your Dell notebook. I've had > two Dells do it, and they do it under Windows as well. I was sure > it was a FreeBSD psm bug for months and months, and spent days > hacking on psm trying to figure out what was triggering it. Then > one day I was sitting in a meeting at our offices in Santa Clara, > and a whole room of people were typing on Dells, and about once a > minute someone would go "Damn mouse". Then it clicked :-). I > wouldn't rule out a recent FreeBSD change doing it, but given my > experiences I'd think it more likely to be a hardware issue. it > went away each time I replaced the motherboard, but came back a > few months later, suggesting wear-and-tear. > Well, that would explain much. This laptop (Dell C600) worked quite nicely when 5.2.1 was released. The mouse situation has slowly deteriorated in recent months. It's a shame if it's a hardware problem cause paying to have this laptop fixed is not an option. Thanks for taking the time to explain it to me. -- Regards, Doug _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 03:14:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE24016A4CE; Sun, 29 Aug 2004 03:14:21 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90D6043D1D; Sun, 29 Aug 2004 03:14:21 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smtp3.sentex.ca (8.13.1/8.13.1) with ESMTP id i7T3EKo5096421; Sat, 28 Aug 2004 23:14:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i7T3EKud064483; Sat, 28 Aug 2004 23:14:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6F49B7303F; Sat, 28 Aug 2004 23:14:20 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040829031420.6F49B7303F@freebsd-current.sentex.ca> Date: Sat, 28 Aug 2004 23:14:20 -0400 (EDT) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 03:14:22 -0000 TB --- 2004-08-29 01:52:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-29 01:52:00 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-08-29 01:52:00 - checking out the source tree TB --- 2004-08-29 01:52:00 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2004-08-29 01:52:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-29 01:57:07 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-29 01:57:07 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-08-29 01:57:07 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-29 03:01:23 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-29 03:01:23 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-08-29 03:01:23 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Aug 29 03:01:23 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Aug 29 03:14:19 UTC 2004 TB --- 2004-08-29 03:14:19 - generating LINT kernel config TB --- 2004-08-29 03:14:19 - cd /home/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2004-08-29 03:14:19 - /usr/bin/make -B LINT TB --- 2004-08-29 03:14:19 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-29 03:14:19 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-08-29 03:14:19 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 29 03:14:19 UTC 2004 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf; PATH=/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/sbin:/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/bin:/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/games:/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/sbin:/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/bin:/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/LINT /tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf/LINT FYI: static unit limits for vcoda are set: NVCODA=4 config: Error: device "ichwd" is unknown config: 1 errors WARNING: kernel contains GPL contaminated ext2fs filesystem *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-08-29 03:14:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-29 03:14:20 - ERROR: failed to build lint kernel TB --- 2004-08-29 03:14:20 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 03:30:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC68E16A4CE for ; Sun, 29 Aug 2004 03:30:11 +0000 (GMT) Received: from electra.cse.Buffalo.EDU (electra.cse.Buffalo.EDU [128.205.32.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C3BD43D73 for ; Sun, 29 Aug 2004 03:30:11 +0000 (GMT) (envelope-from kensmith@cse.Buffalo.EDU) Received: from electra.cse.Buffalo.EDU (kensmith@localhost [127.0.0.1]) i7T3U9TH005634; Sat, 28 Aug 2004 23:30:09 -0400 (EDT) Received: (from kensmith@localhost) by electra.cse.Buffalo.EDU (8.12.10/8.12.9/Submit) id i7T3U92r005633; Sat, 28 Aug 2004 23:30:09 -0400 (EDT) Date: Sat, 28 Aug 2004 23:30:08 -0400 From: Ken Smith To: David Syphers Message-ID: <20040829033008.GA5269@electra.cse.Buffalo.EDU> References: <200408270032.36664.dsyphers@u.washington.edu> <20040827165946.GA24472@electra.cse.Buffalo.EDU> <200408271912.26470.dsyphers@u.washington.edu> <200408272339.12183.dsyphers@u.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408272339.12183.dsyphers@u.washington.edu> User-Agent: Mutt/1.4.1i cc: Ken Smith cc: current@freebsd.org Subject: Re: 5.3-BETA1 install failure (was: 5.3-BETA1 install floppies working?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 03:30:11 -0000 On Fri, Aug 27, 2004 at 11:39:12PM -0700, David Syphers wrote: > Oh boy... since you successfully completed an install, perhaps you can tell me > which local problem causes this error (I'm now using floppies that seem good > - fdformat doesn't see any problems, anyway). After it uses KERN2, and asks > for BOOT again, I get this error: > > ata1-master: timeout sending command = a1 > ata1-master: issueing ATAPI_IDENTIFY command > ad0: WARNING - READ_DMA interrupt was seen but timeout fired LBA=1 > ATAPI_RESET time = 60us > acd0: CDROM at ata1-master P104 > Mounting root from ufs:/dev/md0 > spec_getpages: (md0) I/O read failure: (error = 5) bp 0xc2d8ad74 vp 0xc1711ab3 > size: 1024, resid: 1024, a_count: 932, valid: 0x0 > nread: 0, reqpage: 0, pindex: 500, pcount: 1 > vm_fault: pager read error, pid 1 (swapper) > init died (signal 6, exit 0) > panic: going nowhere without my init! > cpuid = 0; > KDB: enter: panic > [thread 100003] > Stopped at kdb_enter +0x2b: nop > > > (This was transcribed by hand, but the "issueing" typo isn't mine; it's in the > code.) Semi-guessing, you might want to give creating boot.flp again a try. That's where the MD filesystem's contents come from and it looks like that somehow got corrupted. The other two are just the kernel and nothing else so it seems like those aren't an issue. -- Ken Smith - From there to here, from here to | kensmith@cse.buffalo.edu there, funny things are everywhere. | - Theodore Geisel | From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 03:42:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CD2B16A4CE for ; Sun, 29 Aug 2004 03:42:21 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4086F43D4C for ; Sun, 29 Aug 2004 03:42:21 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7T3dtms054442; Sat, 28 Aug 2004 23:39:55 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7T3dsPx054439; Sat, 28 Aug 2004 23:39:55 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 28 Aug 2004 23:39:54 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: doug@polands.org In-Reply-To: <20040829030344.93993.qmail@web40706.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 03:42:21 -0000 On Sat, 28 Aug 2004, Doug Poland wrote: > Well, that would explain much. This laptop (Dell C600) worked quite > nicely when 5.2.1 was released. The mouse situation has slowly > deteriorated in recent months. It's a shame if it's a hardware problem > cause paying to have this laptop fixed is not an option. > > Thanks for taking the time to explain it to me. Well, I don't promise it's not a FreeBSD problem -- the best way to test for sure would be to load a copy of Windows XP or the like on it and see if the same problem recurs. I find that the new Synaptics psm driver changes made things a lot less comfortable, so I use the psm hints flags setting to turn that off. FWIW, my latest Latitude C600 just began doing it a few days ago -- all goes down hill from here... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 04:48:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF06116A4CE for ; Sun, 29 Aug 2004 04:48:59 +0000 (GMT) Received: from mail2.neureal.com (mail2.neureal.com [66.98.170.78]) by mx1.FreeBSD.org (Postfix) with SMTP id 52E9243D3F for ; Sun, 29 Aug 2004 04:48:59 +0000 (GMT) (envelope-from quaggamail@quaggaspace.org) Received: (qmail 979 invoked by uid 399); 29 Aug 2004 04:48:54 -0000 Received: from unknown (HELO ?192.168.42.25?) (68.162.100.90) by mail2.neureal.com with SMTP; 29 Aug 2004 04:48:54 -0000 From: Justin Settle To: freebsd-current@freebsd.org Content-Type: text/plain Message-Id: <1093754957.564.24.camel@amon.quaggaspace.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 29 Aug 2004 00:49:17 -0400 Content-Transfer-Encoding: 7bit Subject: APIC causes vr0 watchdog timeouts and Interrupt storms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 04:48:59 -0000 Hello, I recently installed 5.3-BETA. After booting, I found was unable to use my usb mouse or my ethernet (Via-rhine). I started tinkering with the kernel and found that if I disabled APIC, this system worked without ethernet issues or mouse isssues. After talking with some people they suggested I post boot -v, dmesg's of the different kernels so here they are: The first thing I tried was a GENERIC with SMP commented out. It had the same issues as GENERIC: Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-BETA2 #0: Sat Aug 28 23:18:57 EDT 2004 root@amon.quaggaspace.org:/usr/obj/usr/src/sys/GENERICNOSMP WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc0ad1000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0ad121c. Table 'FACP' at 0x2fff3040 Table 'APIC' at 0x2fff6e00 MADT: Found table at 0x2fff6e00 MP Configuration Table version 1.4 found at 0xc00f1400 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled ACPI APIC Table: Calibrating clock(s) ... i8254 clock: 1193135 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1467296595 Hz CPU: AMD Athlon(tm) XP 1700+ (1467.30-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x680 Stepping = 0 Features=0x383fbff AMD Features=0xc0400000 Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 805240832 (767 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009ffff, 651264 bytes (159 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c26000 - 0x000000002f23ffff, 778149888 bytes (189978 pages) avail memory = 778231808 (742 MB) bios32: Found BIOS32 Service Directory header at 0xc00fb040 bios32: Entry = 0xfb4b0 (c00fb4b0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb4e0 pnpbios: Found PnP BIOS data at 0xc00fbfb0 pnpbios: Entry = f0000:bfe0 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 0 MADT: Found IO APIC ID 2, Interrupt 0 at 0xfec00000 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: intr override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: intr override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: low ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00040010 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff wlan: <802.11 Link Layer> random: io: mem: Pentium Pro MTRR support enabled null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80008840 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=31891106) pcibios: BIOS version 2.10 Found $PIR table, 11 entries at 0xc00fdea0 PCI-Only Interrupts: 5 10 11 12 Location Bus Device Pin Link IRQs slot 1 0 8 A 0x01 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 B 0x02 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 C 0x03 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 D 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 B 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 C 0x03 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 D 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 B 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 C 0x05 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 D 0x03 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 A 0x05 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 B 0x01 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 C 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 D 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 12 A 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 12 B 0x05 3 4 5 7 9 10 11 12 14 15 slot 5 0 12 C 0x01 3 4 5 7 9 10 11 12 14 15 slot 5 0 12 D 0x02 3 4 5 7 9 10 11 12 14 15 slot 6 0 13 A 0x05 3 4 5 7 9 10 11 12 14 15 slot 6 0 13 B 0x02 3 4 5 7 9 10 11 12 14 15 slot 6 0 13 C 0x03 3 4 5 7 9 10 11 12 14 15 slot 6 0 13 D 0x01 3 4 5 7 9 10 11 12 14 15 slot 7 0 19 A 0x03 3 4 5 7 9 10 11 12 14 15 slot 7 0 19 B 0x05 3 4 5 7 9 10 11 12 14 15 slot 7 0 19 C 0x01 3 4 5 7 9 10 11 12 14 15 slot 7 0 19 D 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 17 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 17 D 0x05 3 4 5 7 9 10 11 12 14 15 embedded 0 1 A 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 1 B 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 1 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 1 D 0x05 3 4 5 7 9 10 11 12 14 15 embedded 0 16 A 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 16 B 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 16 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 16 D 0x05 3 4 5 7 9 10 11 12 14 15 embedded 0 18 A 0x01 3 4 5 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 17 func 0 acpi0: Power Button (fixed) ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 unknown: not probed (disabled) cpu0: on acpi0 acpi_tz0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \\_SB_.PCI0.ALKB irq 0: [21] 0+ low,level,sharable 0.16.0 \\_SB_.PCI0.ALKB irq 0: [21] 0+ low,level,sharable 0.16.1 \\_SB_.PCI0.ALKB irq 0: [21] 0+ low,level,sharable 0.16.2 \\_SB_.PCI0.ALKB irq 0: [21] 0+ low,level,sharable 0.16.3 \\_SB_.PCI0.ALKA irq 0: [20] 0+ low,level,sharable 0.17.0 \\_SB_.PCI0.ALKB irq 0: [21] 0+ low,level,sharable 0.17.1 \\_SB_.PCI0.ALKC irq 0: [22] 0+ low,level,sharable 0.17.2 \\_SB_.PCI0.ALKD irq 0: [23] 0+ low,level,sharable 0.17.3 \\_SB_.PCI0.ALKD irq 0: [23] 0+ low,level,sharable 0.18.0 \\_SB_.PCI0.ALKD irq 0: [23] 0+ low,level,sharable 0.18.1 \\_SB_.PCI0.ALKD irq 0: [23] 0+ low,level,sharable 0.18.2 \\_SB_.PCI0.ALKD irq 0: [23] 0+ low,level,sharable 0.18.3 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base e8000000, size 26, enabled found-> vendor=0x1106, dev=0x3189, revid=0x00 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0xb168, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000d000, size 5, enabled pcib0: matched entry for 0.16.INTA (src \\_SB_.PCI0.ALKB) pcib0: possible interrupts: 21 ACPI PCI link arbitrated settings: \\_SB_.PCI0.ALKB (references 5, priority 250): interrupts: 21 penalty: 50 \\_SB_.PCI0.ALKD (references 5, priority 250): interrupts: 23 penalty: 50 \\_SB_.PCI0.ALKA (references 1, priority 10): interrupts: 20 penalty: 10 \\_SB_.PCI0.ALKC (references 1, priority 10): interrupts: 22 penalty: 10 acpi link set: _CRS failed for link \\_SB_.PCI0.ALKB - AE_NULL_ENTRY acpi link set: curr irq 0 != 21 for \\_SB_.PCI0.ALKB (ignoring) unknown: _SRS failed, irq 21 via \\_SB_.PCI0.ALKB found-> vendor=0x1106, dev=0x3038, revid=0x80 bus=0, slot=16, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 0000d400, size 5, enabled pcib0: matched entry for 0.16.INTB (src \\_SB_.PCI0.ALKB) pcib0: slot 16 INTB is already routed to irq 21 found-> vendor=0x1106, dev=0x3038, revid=0x80 bus=0, slot=16, func=1 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=21 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 0000d800, size 5, enabled pcib0: matched entry for 0.16.INTC (src \\_SB_.PCI0.ALKB) pcib0: slot 16 INTC is already routed to irq 21 found-> vendor=0x1106, dev=0x3038, revid=0x80 bus=0, slot=16, func=2 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=21 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base ee000000, size 8, enabled pcib0: matched entry for 0.16.INTD (src \\_SB_.PCI0.ALKB) pcib0: slot 16 INTD is already routed to irq 21 found-> vendor=0x1106, dev=0x3104, revid=0x82 bus=0, slot=16, func=3 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=21 powerspec 2 supports D0 D1 D2 D3 current D0 found-> vendor=0x1106, dev=0x3177, revid=0x00 bus=0, slot=17, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0087, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000dc00, size 4, enabled found-> vendor=0x1106, dev=0x0571, revid=0x06 bus=0, slot=17, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000e000, size 8, enabled pcib0: matched entry for 0.17.INTC (src \\_SB_.PCI0.ALKC) pcib0: possible interrupts: 22 ACPI PCI link arbitrated settings: \\_SB_.PCI0.ALKD (references 5, priority 500): interrupts: 23 penalty: 100 \\_SB_.PCI0.ALKA (references 1, priority 20): interrupts: 20 penalty: 20 \\_SB_.PCI0.ALKC (references 1, priority 20): interrupts: 22 penalty: 20 acpi link set: _CRS failed for link \\_SB_.PCI0.ALKC - AE_NULL_ENTRY acpi link set: curr irq 0 != 22 for \\_SB_.PCI0.ALKC (ignoring) unknown: _SRS failed, irq 22 via \\_SB_.PCI0.ALKC found-> vendor=0x1106, dev=0x3059, revid=0x50 bus=0, slot=17, func=5 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000e400, size 8, enabled map[14]: type 1, range 32, base ee001000, size 8, enabled pcib0: matched entry for 0.18.INTA (src \\_SB_.PCI0.ALKD) pcib0: possible interrupts: 23 ACPI PCI link arbitrated settings: \\_SB_.PCI0.ALKD (references 5, priority 750): interrupts: 23 penalty: 150 \\_SB_.PCI0.ALKA (references 1, priority 30): interrupts: 20 penalty: 30 acpi link set: _CRS failed for link \\_SB_.PCI0.ALKD - AE_NULL_ENTRY acpi link set: curr irq 0 != 23 for \\_SB_.PCI0.ALKD (ignoring) unknown: _SRS failed, irq 23 via \\_SB_.PCI0.ALKD found-> vendor=0x1106, dev=0x3065, revid=0x74 bus=0, slot=18, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 agp0: mem 0xe8000000-0xebffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xe8000000 agp0: allocating GATT for aperture of size 240M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xec000000-0xedffffff pcib1: prefetched decode 0xe0000000-0xe7ffffff pci1: on pcib1 pci1: physical bus=1 map[10]: type 1, range 32, base ec000000, size 24, enabled pcib1: device (null) requested decoded memory range 0xec000000-0xecffffff map[14]: type 3, range 32, base e0000000, size 27, enabled pcib1: device (null) requested decoded memory range 0xe0000000-0xe7ffffff pcib0: matched entry for 0.1.INTA pcib0: slot 1 INTA hardwired to IRQ 16 pcib1: slot 0 INTA is routed to irq 16 found-> vendor=0x10de, dev=0x0281, revid=0xa1 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x05 (1250 ns), maxlat=0x01 (250 ns) intpin=a, irq=16 powerspec 2 supports D0 D3 current D0 pci1: at device 0.0 (no driver attached) uhci0: port 0xd000-0xd01f irq 11 at device 16.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd000 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/13.00, addr 2, iclass 3/1 ums0: 4 buttons and Z dir. uhci1: port 0xd400-0xd41f irq 21 at device 16.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd400 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xd800-0xd81f irq 21 at device 16.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd800 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: at device 16.3 (no driver attached) isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port 0xdc00-0xdc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 17.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xdc00 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=50 ata1-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 ata1-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0xc ata1: [MPSAFE] pci0: at device 17.5 (no driver attached) vr0: port 0xe400-0xe4ff mem 0xee001000-0xee0010ff irq 11 at device 18.0 on pci0 vr0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe400 miibus0: on vr0 ukphy0: on miibus0 ukphy0: OUI 0x004063, model 0x0032, rev. 5 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: bpf attached vr0: Ethernet address: 00:50:8d:46:5a:1f vr0: [GIANT-LOCKED] fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 sio0: irq maps: 0xd001 0xd011 0xd001 0xd001 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: irq maps: 0xd001 0xd009 0xd001 0xd001 sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A unknown: not probed (disabled) unknown: not probed (disabled) ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 ppbus0: IEEE1284 device found /NIBBLE/NIBBLE_ID/Extensibility Link Probing for PnP devices on ppbus0: ppbus0: HP ENHANCED PCL5,PJL plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 unknown: not probed (disabled) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 ex_isa_identify() unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ahc_isa_probe 13: ioport 0xdc00 alloc failed sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 54 80 bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 54 80 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 54 80 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 1467296595 Hz quality 800 Timecounters tick every 10.000 msec lo0: bpf attached cpu0: set speed to 100.0% acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% ata0-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata0-master: setting PIO4 on VIA 8235 chip ata0-master: setting UDMA100 on VIA 8235 chip ad0: ATA-6 disk at ata0-master ad0: 38146MB (78125000 sectors), 77504 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA100 GEOM: new disk ad0 ar: FreeBSD check1 failed ata1-slave: pio=0x0c wdma=0x22 udma=0x42 cable=40pin ATAPI_RESET time = 10us ata1-master: pio=0x0c wdma=0x22 udma=0x42 cable=40pin ATAPI_RESET time = 10us ata1-master: setting PIO4 on VIA 8235 chip ata1-master: setting UDMA33 on VIA 8235 chip ata1-slave: setting PIO4 on VIA 8235 chip ata1-slave: setting UDMA33 on VIA 8235 chip acd0: <_NEC DVD_RW ND-2510A/2.15> DVDR drive at ata1 as master acd0: read 6890KB/s (6890KB/s) write 5512KB/s (5512KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc acd1: CDRW drive at ata1 as slave acd1: 2048KB buffer, UDMA33 acd1: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd1: Writes: CDR, CDRW, test write, burnproof acd1: Audio: play, 255 volume levels acd1: Mechanism: ejectable tray, unlocked acd1: Medium: no/blank disc ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ioapic0: routing intpin 3 (ISA IRQ 3) to cluster 0 ioapic0: routing intpin 4 (ISA IRQ 4) to cluster 0 ioapic0: routing intpin 6 (ISA IRQ 6) to cluster 0 ioapic0: routing intpin 7 (ISA IRQ 7) to cluster 0 ioapic0: routing intpin 8 (ISA IRQ 8) to cluster 0 ioapic0: routing intpin 9 (ISA IRQ 9) to cluster 0 ioapic0: routing intpin 11 (ISA IRQ 11) to cluster 0 ioapic0: routing intpin 13 (ISA IRQ 13) to cluster 0 ioapic0: routing intpin 14 (ISA IRQ 14) to cluster 0 ioapic0: routing intpin 15 (ISA IRQ 15) to cluster 0 ioapic0: routing intpin 21 (PCI IRQ 21) to cluster 0 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:54524547 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 32256 length 27916568064 end 27916600319 GEOM: Configure ad0s1a, start 0 length 134217728 end 134217727 GEOM: Configure ad0s1b, start 134217728 length 1594351616 end 1728569343 GEOM: Configure ad0s1c, start 0 length 27916568064 end 27916568063 GEOM: Configure ad0s1d, start 14076600320 length 13839967744 end 27916568063 GEOM: Configure ad0s1e, start 1728569344 length 268435456 end 1997004799 GEOM: Configure ad0s1f, start 1997004800 length 268435456 end 2265440255 GEOM: Configure ad0s1g, start 2265440256 length 10737418240 end 13002858495 GEOM: Configure ad0s1h, start 13002858496 length 1073741824 end 14076600319 Mounting root from ufs:/dev/ad0s1a start_init: trying /sbin/init Interrupt storm detected on "irq21: uhci1 uhci2"; throttling interrupt source vr0: watchdog timeout usbd_setup_pipe: failed to start endpoint, TIMEOUT Linux ELF exec handler installed *************** As you can see, the interupt storm and vr0 timeouts at the end. USB mouse was unresponsive and vr0 timed out whenever I did anything. I then compiled without SMP or device APIC. This kernel seemingly works fine for me: *************** Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-BETA2 #0: Sun Aug 29 00:02:49 EDT 2004 root@amon.quaggaspace.org:/usr/obj/usr/src/sys/GENERICNOAPIC WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc0acb000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0acb21c. Calibrating clock(s) ... i8254 clock: 1193134 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1467292412 Hz CPU: AMD Athlon(tm) XP 1700+ (1467.29-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x680 Stepping = 0 Features=0x383fbff AMD Features=0xc0400000 Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 805240832 (767 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009ffff, 651264 bytes (159 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c26000 - 0x000000002f23ffff, 778149888 bytes (189978 pages) avail memory = 778231808 (742 MB) bios32: Found BIOS32 Service Directory header at 0xc00fb040 bios32: Entry = 0xfb4b0 (c00fb4b0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb4e0 pnpbios: Found PnP BIOS data at 0xc00fbfb0 pnpbios: Entry = f0000:bfe0 Rev = 1.0 Other BIOS signatures found: wlan: <802.11 Link Layer> random: io: mem: Pentium Pro MTRR support enabled null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80008840 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=31891106) pcibios: BIOS version 2.10 Found $PIR table, 11 entries at 0xc00fdea0 PCI-Only Interrupts: 5 10 11 12 Location Bus Device Pin Link IRQs slot 1 0 8 A 0x01 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 B 0x02 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 C 0x03 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 D 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 B 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 C 0x03 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 D 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 B 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 C 0x05 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 D 0x03 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 A 0x05 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 B 0x01 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 C 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 D 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 12 A 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 12 B 0x05 3 4 5 7 9 10 11 12 14 15 slot 5 0 12 C 0x01 3 4 5 7 9 10 11 12 14 15 slot 5 0 12 D 0x02 3 4 5 7 9 10 11 12 14 15 slot 6 0 13 A 0x05 3 4 5 7 9 10 11 12 14 15 slot 6 0 13 B 0x02 3 4 5 7 9 10 11 12 14 15 slot 6 0 13 C 0x03 3 4 5 7 9 10 11 12 14 15 slot 6 0 13 D 0x01 3 4 5 7 9 10 11 12 14 15 slot 7 0 19 A 0x03 3 4 5 7 9 10 11 12 14 15 slot 7 0 19 B 0x05 3 4 5 7 9 10 11 12 14 15 slot 7 0 19 C 0x01 3 4 5 7 9 10 11 12 14 15 slot 7 0 19 D 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 17 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 17 D 0x05 3 4 5 7 9 10 11 12 14 15 embedded 0 1 A 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 1 B 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 1 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 1 D 0x05 3 4 5 7 9 10 11 12 14 15 embedded 0 16 A 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 16 B 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 16 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 16 D 0x05 3 4 5 7 9 10 11 12 14 15 embedded 0 18 A 0x01 3 4 5 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 17 func 0 acpi0: Power Button (fixed) ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 ACPI timer looks GOOD min = 2, max = 3, width = 1 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 unknown: not probed (disabled) cpu0: on acpi0 acpi_tz0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 ACPI PCI link initial configuration: \\_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.8.0 \\_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.8.1 \\_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.8.2 \\_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.8.3 \\_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.9.0 \\_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.9.1 \\_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.9.2 \\_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.9.3 \\_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.10.0 \\_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.10.1 \\_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.10.2 \\_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.10.3 \\_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.11.0 \\_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.11.1 \\_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.11.2 \\_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.11.3 \\_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.12.0 \\_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.12.1 \\_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.12.2 \\_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.12.3 \\_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.13.0 \\_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.13.1 \\_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.13.2 \\_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.13.3 \\_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.19.0 \\_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.19.1 \\_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.19.2 \\_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.19.3 \\_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.16.0 \\_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.16.1 \\_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.16.2 \\_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.16.3 \\_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.17.0 \\_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.17.1 \\_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.17.2 \\_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.17.3 \\_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.1.0 \\_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.1.1 \\_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.1.2 \\_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.1.3 \\_SB_.PCI0.LNKA irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 11+ low,level,sharable 0.18.0 \\_SB_.PCI0.LNKB irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 5+ low,level,sharable 0.18.1 \\_SB_.PCI0.LNKC irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 10+ low,level,sharable 0.18.2 \\_SB_.PCI0.LNKD irq 0: [ 1 3 4 5 6 7 10 11 12 14 15] 12+ low,level,sharable 0.18.3 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base e8000000, size 26, enabled found-> vendor=0x1106, dev=0x3189, revid=0x00 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0xb168, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000d000, size 5, enabled pcib0: matched entry for 0.16.INTA (src \\_SB_.PCI0.LNKA) pcib0: possible interrupts: 1 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LNKA (references 11, priority 229890): interrupts: 11 10 5 12 7 6 4 3 15 14 1 penalty: 440 440 490 5440 5440 5440 5440 5440 50440 50440100440 \\_SB_.PCI0.LNKB (references 11, priority 229890): interrupts: 11 10 5 12 7 6 4 3 15 14 1 penalty: 440 440 490 5440 5440 5440 5440 5440 50440 50440100440 \\_SB_.PCI0.LNKC (references 11, priority 229890): interrupts: 11 10 5 12 7 6 4 3 15 14 1 penalty: 440 440 490 5440 5440 5440 5440 5440 50440 50440100440 \\_SB_.PCI0.LNKD (references 11, priority 229890): interrupts: 11 10 5 12 7 6 4 3 15 14 1 penalty: 440 440 490 5440 5440 5440 5440 5440 50440 50440100440 pcib0: slot 16 INTA routed to irq 11 via \\_SB_.PCI0.LNKA found-> vendor=0x1106, dev=0x3038, revid=0x80 bus=0, slot=16, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 0000d400, size 5, enabled pcib0: matched entry for 0.16.INTB (src \\_SB_.PCI0.LNKB) pcib0: possible interrupts: 1 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LNKB (references 11, priority 234840): interrupts: 10 5 11 12 7 6 4 3 15 14 1 penalty: 880 930 990 5880 5880 5880 5880 5880 50880 50880100880 \\_SB_.PCI0.LNKC (references 11, priority 234840): interrupts: 10 5 11 12 7 6 4 3 15 14 1 penalty: 880 930 990 5880 5880 5880 5880 5880 50880 50880100880 \\_SB_.PCI0.LNKD (references 11, priority 234840): interrupts: 10 5 11 12 7 6 4 3 15 14 1 penalty: 880 930 990 5880 5880 5880 5880 5880 50880 50880100880 pcib0: slot 16 INTB routed to irq 5 via \\_SB_.PCI0.LNKB found-> vendor=0x1106, dev=0x3038, revid=0x80 bus=0, slot=16, func=1 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 0000d800, size 5, enabled pcib0: matched entry for 0.16.INTC (src \\_SB_.PCI0.LNKC) pcib0: possible interrupts: 1 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LNKC (references 11, priority 239790): interrupts: 10 11 5 12 7 6 4 3 15 14 1 penalty: 1320 1430 1480 6320 6320 6320 6320 6320 51320 51320101320 \\_SB_.PCI0.LNKD (references 11, priority 239790): interrupts: 10 11 5 12 7 6 4 3 15 14 1 penalty: 1320 1430 1480 6320 6320 6320 6320 6320 51320 51320101320 pcib0: slot 16 INTC routed to irq 10 via \\_SB_.PCI0.LNKC found-> vendor=0x1106, dev=0x3038, revid=0x80 bus=0, slot=16, func=2 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base ee000000, size 8, enabled pcib0: matched entry for 0.16.INTD (src \\_SB_.PCI0.LNKD) pcib0: possible interrupts: 1 3 4 5 6 7 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LNKD (references 11, priority 244740): interrupts: 11 10 5 12 7 6 4 3 15 14 1 penalty: 1870 1870 1920 6760 6760 6760 6760 6760 51760 51760101760 pcib0: slot 16 INTD routed to irq 12 via \\_SB_.PCI0.LNKD found-> vendor=0x1106, dev=0x3104, revid=0x82 bus=0, slot=16, func=3 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=12 powerspec 2 supports D0 D1 D2 D3 current D0 found-> vendor=0x1106, dev=0x3177, revid=0x00 bus=0, slot=17, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0087, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000dc00, size 4, enabled found-> vendor=0x1106, dev=0x0571, revid=0x06 bus=0, slot=17, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000e000, size 8, enabled pcib0: matched entry for 0.17.INTC (src \\_SB_.PCI0.LNKC) pcib0: slot 17 INTC is already routed to irq 10 found-> vendor=0x1106, dev=0x3059, revid=0x50 bus=0, slot=17, func=5 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000e400, size 8, enabled map[14]: type 1, range 32, base ee001000, size 8, enabled pcib0: matched entry for 0.18.INTA (src \\_SB_.PCI0.LNKA) pcib0: slot 18 INTA is already routed to irq 11 found-> vendor=0x1106, dev=0x3065, revid=0x74 bus=0, slot=18, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 agp0: mem 0xe8000000-0xebffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xe8000000 agp0: allocating GATT for aperture of size 240M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xec000000-0xedffffff pcib1: prefetched decode 0xe0000000-0xe7ffffff pci1: on pcib1 pci1: physical bus=1 map[10]: type 1, range 32, base ec000000, size 24, enabled pcib1: device (null) requested decoded memory range 0xec000000-0xecffffff map[14]: type 3, range 32, base e0000000, size 27, enabled pcib1: device (null) requested decoded memory range 0xe0000000-0xe7ffffff pcib0: matched entry for 0.1.INTA (src \\_SB_.PCI0.LNKA) pcib0: slot 1 INTA is already routed to irq 11 pcib1: slot 0 INTA is routed to irq 11 found-> vendor=0x10de, dev=0x0281, revid=0xa1 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x05 (1250 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 pci1: at device 0.0 (no driver attached) uhci0: port 0xd000-0xd01f irq 11 at device 16.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd000 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/13.00, addr 2, iclass 3/1 ums0: 4 buttons and Z dir. uhci1: port 0xd400-0xd41f irq 5 at device 16.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd400 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xd800-0xd81f irq 10 at device 16.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xd800 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: at device 16.3 (no driver attached) isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port 0xdc00-0xdc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 17.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xdc00 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=50 ata1-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 ata1-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0xc ata1: [MPSAFE] pci0: at device 17.5 (no driver attached) vr0: port 0xe400-0xe4ff mem 0xee001000-0xee0010ff irq 11 at device 18.0 on pci0 vr0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xe400 miibus0: on vr0 ukphy0: on miibus0 ukphy0: OUI 0x004063, model 0x0032, rev. 5 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: bpf attached vr0: Ethernet address: 00:50:8d:46:5a:1f vr0: [GIANT-LOCKED] fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: irq maps: 0x1 0x9 0x1 0x1 sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A unknown: not probed (disabled) unknown: not probed (disabled) ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 ppbus0: IEEE1284 device found /NIBBLE/NIBBLE_ID/Extensibility Link Probing for PnP devices on ppbus0: ppbus0: HP ENHANCED PCL5,PJL plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 unknown: not probed (disabled) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 ex_isa_identify() unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff ahc_isa_probe 13: ioport 0xdc00 alloc failed sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 54 80 bf 1f 00 4f 0e 0f 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 54 80 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 54 80 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 1467292412 Hz quality 800 Timecounters tick every 10.000 msec lo0: bpf attached cpu0: set speed to 100.0% acpi_cpu: throttling enabled, 2 steps (100% to 50.0%), currently 100.0% ata0-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata0-master: setting PIO4 on VIA 8235 chip ata0-master: setting UDMA100 on VIA 8235 chip ad0: ATA-6 disk at ata0-master ad0: 38146MB (78125000 sectors), 77504 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA100 GEOM: new disk ad0 ar: FreeBSD check1 failed ata1-slave: pio=0x0c wdma=0x22 udma=0x42 cable=40pin ATAPI_RESET time = 10us ata1-master: pio=0x0c wdma=0x22 udma=0x42 cable=40pin ATAPI_RESET time = 20us ata1-master: setting PIO4 on VIA 8235 chip ata1-master: setting UDMA33 on VIA 8235 chip ata1-slave: setting PIO4 on VIA 8235 chip ata1-slave: setting UDMA33 on VIA 8235 chip acd0: <_NEC DVD_RW ND-2510A/2.15> DVDR drive at ata1 as master acd0: read 6890KB/s (6890KB/s) write 5512KB/s (5512KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc acd1: CDRW drive at ata1 as slave acd1: 2048KB buffer, UDMA33 acd1: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd1: Writes: CDR, CDRW, test write, burnproof acd1: Audio: play, 255 volume levels acd1: Mechanism: ejectable tray, unlocked acd1: Medium: no/blank disc [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:54524547 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 32256 length 27916568064 end 27916600319 GEOM: Configure ad0s1a, start 0 length 134217728 end 134217727 GEOM: Configure ad0s1b, start 134217728 length 1594351616 end 1728569343 GEOM: Configure ad0s1c, start 0 length 27916568064 end 27916568063 GEOM: Configure ad0s1d, start 14076600320 length 13839967744 end 27916568063 GEOM: Configure ad0s1e, start 1728569344 length 268435456 end 1997004799 GEOM: Configure ad0s1f, start 1997004800 length 268435456 end 2265440255 GEOM: Configure ad0s1g, start 2265440256 length 10737418240 end 13002858495 GEOM: Configure ad0s1h, start 13002858496 length 1073741824 end 14076600319 Mounting root from ufs:/dev/ad0s1a start_init: trying /sbin/init Linux ELF exec handler installed ACPI is on both of these kernels but I've tried both without and the results are the same. Should any other information be needed/wanted I'll be sure to reply. Thank you for your time. Jay Settle From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 04:58:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A21B16A4CE for ; Sun, 29 Aug 2004 04:58:06 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5043E43D55 for ; Sun, 29 Aug 2004 04:58:06 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 46B4872DD4; Sat, 28 Aug 2004 21:58:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 4492A72DCB; Sat, 28 Aug 2004 21:58:06 -0700 (PDT) Date: Sat, 28 Aug 2004 21:58:06 -0700 (PDT) From: Doug White To: Joe Marcus Clarke In-Reply-To: <20040823204959.V9327@carver.gumbysoft.com> Message-ID: <20040828215745.E62345@carver.gumbysoft.com> References: <1093058259.9940.29.camel@shumai.marcuscom.com> <1093121246.17246.33.camel@shumai.marcuscom.com> <1093195573.11223.3.camel@shumai.marcuscom.com> <1093222625.11223.26.camel@shumai.marcuscom.com> <20040823204959.V9327@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Divacky Roman cc: current@freebsd.org Subject: Re: Cannot install onto mpt-driven drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 04:58:06 -0000 On Mon, 23 Aug 2004, Doug White wrote: > I've committed the patch to HEAD, and will ask for a RELENG_5 merge later > this week. Thanks for testing it! The merge has been completed. Viva la RELENG_5! -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 04:59:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4B8716A4CE for ; Sun, 29 Aug 2004 04:59:18 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9AE943D46 for ; Sun, 29 Aug 2004 04:59:17 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i7T4xDVK030062; Sun, 29 Aug 2004 00:59:13 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i7T4xBvk030061; Sun, 29 Aug 2004 00:59:11 -0400 (EDT) (envelope-from green) Date: Sun, 29 Aug 2004 00:59:11 -0400 From: Brian Fundakowski Feldman To: Anish Mistry Message-ID: <20040829045911.GF1047@green.homeunix.org> References: <200407271731.12282.mistry.7@osu.edu> <200408041828.26762.mistry.7@osu.edu> <20040804223937.GA99521@freebsd3.cimlogic.com.au> <200408101353.22714.mistry.7@osu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408101353.22714.mistry.7@osu.edu> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: FreeBSD and wine mmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 04:59:18 -0000 On Tue, Aug 10, 2004 at 01:53:14PM -0400, Anish Mistry wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wednesday 04 August 2004 06:39 pm, you wrote: > > On Wed, Aug 04, 2004 at 06:28:02PM -0400, Anish Mistry wrote: > > > Ok, so we need something like vm_map_findspace(), but for process address > > > mapping? ie. pmap_findspace() that will return an address to a large > > > enough free chunk? > > > > That's a good start, just to get something to work with. How this fits in > > with the vm code and whether it is ultimately suitable in the long run is > > probably up to Alan Cox. For now, just get something that (a) doesn't break > > anything else; and (b) lets Wine behave the way it needs to. > > > > AFAIK, there are still pthread issues with Wine, but those can't be > > addressed until the mmap issue has a work-around. > I've got a small patch that gets by the initial problem about not being to > mmap the memory for the libraries, but the addresses that are mmap'ed seem to > seem to overlap with memory that the current pthread implementation want to > mmap for the "red zone" when wine tries to create a thread. It can't mmap > the "red zone" addresses since all those address mapping where gobbled up > before the thread launched. > I'll try to figure out a way to maybe leave a space for the "red zone" and see > if that works. > Someone who actually knows what they are doing should probably take a look. The red pages are implemented by leaving the memory space unallocated; I don't like that one bit -- this will cause those spaces to be allocated but given no protection, which should provide the crash feature that the guard pages are there for, but be less bogus (and it doesn't use more "memory," but it will use a few more vm_map_entrys. Index: lib/libpthread/thread/thr_stack.c =================================================================== RCS file: /usr/ncvs/src/lib/libpthread/thread/thr_stack.c,v retrieving revision 1.8 diff -u -r1.8 thr_stack.c --- lib/libpthread/thread/thr_stack.c 14 Sep 2003 22:39:44 -0000 1.8 +++ lib/libpthread/thread/thr_stack.c 29 Aug 2004 04:50:28 -0000 @@ -214,6 +214,17 @@ stacksize, PROT_READ | PROT_WRITE, MAP_STACK, -1, 0)) == MAP_FAILED) attr->stackaddr_attr = NULL; + if (attr->stackaddr_attr != NULL) { + void *red; + + red = mmap((char *)attr->stackaddr_attr + stacksize, + _thr_guard_default, PROT_NONE, + MAP_ANON | MAP_FIXED | MAP_PRIVATE, -1, 0); + if (red == MAP_FAILED) { + (void)munmap(attr->stackaddr_attr, stacksize); + attr->stackaddr_attr = NULL; + } + } } if (attr->stackaddr_attr != NULL) return (0); -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 05:02:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 06BC616A4CE for ; Sun, 29 Aug 2004 05:02:54 +0000 (GMT) Received: from creme-brulee.marcuscom.com (rrcs-midsouth-24-172-16-118.biz.rr.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id A815343D2F for ; Sun, 29 Aug 2004 05:02:53 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) i7T513cF096113; Sun, 29 Aug 2004 01:01:03 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Doug White In-Reply-To: <20040828215745.E62345@carver.gumbysoft.com> References: <1093058259.9940.29.camel@shumai.marcuscom.com> <20040821133949.M84878@carver.gumbysoft.com> <1093121246.17246.33.camel@shumai.marcuscom.com> <20040822131311.GA3734@stud.fit.vutbr.cz> <1093195573.11223.3.camel@shumai.marcuscom.com> <20040822154204.O94593@carver.gumbysoft.com> <1093222625.11223.26.camel@shumai.marcuscom.com> <20040823204959.V9327@carver.gumbysoft.com> <20040828215745.E62345@carver.gumbysoft.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-e8Iv6HJAMEvDTCGZ0axT" Organization: MarcusCom, Inc. Message-Id: <1093755768.55460.38.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 29 Aug 2004 01:02:48 -0400 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on creme-brulee.marcuscom.com cc: Divacky Roman cc: current@freebsd.org Subject: Re: Cannot install onto mpt-driven drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 05:02:54 -0000 --=-e8Iv6HJAMEvDTCGZ0axT Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Sun, 2004-08-29 at 00:58, Doug White wrote: > On Mon, 23 Aug 2004, Doug White wrote: >=20 > > I've committed the patch to HEAD, and will ask for a RELENG_5 merge lat= er > > this week. Thanks for testing it! >=20 > The merge has been completed. Viva la RELENG_5! Thanks! Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-e8Iv6HJAMEvDTCGZ0axT Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBMWN4b2iPiv4Uz4cRAso3AJ97XpNAES6nS9jU5TyI9GVNsEcqvgCglv6E XT/z+CGrfQ4a9518t4z5gc4= =IANv -----END PGP SIGNATURE----- --=-e8Iv6HJAMEvDTCGZ0axT-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 05:17:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4B6816A4CE for ; Sun, 29 Aug 2004 05:17:24 +0000 (GMT) Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E41043D49 for ; Sun, 29 Aug 2004 05:17:24 +0000 (GMT) (envelope-from dashevil@sympatico.ca) Received: from [192.168.2.32] ([65.93.59.22]) by tomts5-srv.bellnexxia.net ESMTP <20040829051722.JUUQ18869.tomts5-srv.bellnexxia.net@[192.168.2.32]>; Sun, 29 Aug 2004 01:17:22 -0400 From: Chris Laverdure To: Justin Settle In-Reply-To: <1093754957.564.24.camel@amon.quaggaspace.org> References: <1093754957.564.24.camel@amon.quaggaspace.org> Content-Type: text/plain Message-Id: <1093742244.3464.1.camel@elemental.DashEvil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 29 Aug 2004 01:17:24 +0000 Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: APIC causes vr0 watchdog timeouts and Interrupt storms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 05:17:24 -0000 On Sun, 2004-08-29 at 04:49, Justin Settle wrote: > Hello, > > I recently installed 5.3-BETA. After booting, I found was unable to use > my usb mouse or my ethernet (Via-rhine). I started tinkering with the > kernel and found that if I disabled APIC, this system worked without > ethernet issues or mouse isssues. After talking with some people they > suggested I post boot -v, dmesg's of the different kernels so here they > are: > > The first thing I tried was a GENERIC with SMP commented out. It had > the same issues as GENERIC: > ... > ACPI is on both of these kernels but I've tried both without and the > results are the same. Should any other information be needed/wanted > I'll be sure to reply. Thank you for your time. > > Jay Settle > I too cannot use my USB mouse with ACPI enabled (yet it works fine without it). I get a Interrupt Storm when usbd tries to come up, and then moused fails claiming an "Input/Output error on /dev/ums0". I would love to get to the bottom of this. From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 05:59:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90F6C16A4CE for ; Sun, 29 Aug 2004 05:59:37 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id F35C043D48 for ; Sun, 29 Aug 2004 05:59:36 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id D865650BD6; Sun, 29 Aug 2004 14:59:35 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id 4605D50BC0; Sun, 29 Aug 2004 14:59:34 +0900 (JST) Date: Sun, 29 Aug 2004 14:59:34 +0900 Message-ID: <7meklq4h89.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: "Poul-Henning Kamp" In-Reply-To: <3181.1093688358@critter.freebsd.dk> References: <7mk6vj4lis.wl@black.imgsrc.co.jp> <3181.1093688358@critter.freebsd.dk> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 cc: Current Subject: Re: Hang at probing on VMware installation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 05:59:37 -0000 At Sat, 28 Aug 2004 10:20:09 +0000 (UTC), Poul-Henning Kamp wrote: > >VMware said "unrecoverable error" and "Exception 0xc0000005 {access > >violation} has occured" and virtual machine has stopped. > > Is there any way to get mode detailed diagnostics ? Like the > program counter or anything ? In fdc_initial_reset() shows here: ----- fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa2 ----- Actual hang up is in loop in device_probe_and_attach(). With BUS_DEBUG, final output is here: ----- device_probe_child:1556: Start find loop device_probe_child:1561: Trying bt devclass_find_internal:752: looking for bt devclass_add_device:1225: (null) in devclass bt devclass_alloc_unit:1158: unit -1 in devclass bt devclass_alloc_unit:1198: now: unit 1 in devclass bt devclass_delete_device:1264: bt in devclass bt device_probe_child:1561: Trying cbb devclass_find_internal:752: looking for cbb devclass_add_device:1225: (null) in devclass cbb devclass_alloc_unit:1158: unit -1 in devclass cbb devclass_alllass cbb device_probe_child:1561: Trying sn devclass_t:1158: unit -1 in devclass sn devclass_alloc_unit:1198: now: unit 1 in devclass sn devclass_delete_device:1264: sn in devclass sn device_probe_child:1561: Trying stg devclass_find_internal:752: looking for stg devclass_add_device:1225: (null) in devclass stg devclass_alloc_unit:1158: unit -1 in devclass stg devclass_alloc_unit:1198: now: unit 0 in devclass stg ----- This is called from isa_probe_children(), isa_assign_resources(i=40) returns true, device_probe_and_attach(). Where should I check next? Inside of device_probe_child() or resouce allocation area more ealier stage? -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 06:11:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E70216A4CE for ; Sun, 29 Aug 2004 06:11:30 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6D14C43D49 for ; Sun, 29 Aug 2004 06:11:29 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i7T6BSrN031116; Sun, 29 Aug 2004 02:11:28 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i7T6BRxM031115; Sun, 29 Aug 2004 02:11:28 -0400 (EDT) (envelope-from green) Date: Sun, 29 Aug 2004 02:11:27 -0400 From: Brian Fundakowski Feldman To: Anish Mistry Message-ID: <20040829061127.GG1047@green.homeunix.org> References: <200407271731.12282.mistry.7@osu.edu> <200408041828.26762.mistry.7@osu.edu> <20040804223937.GA99521@freebsd3.cimlogic.com.au> <200408101353.22714.mistry.7@osu.edu> <20040829045911.GF1047@green.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040829045911.GF1047@green.homeunix.org> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: FreeBSD and wine mmap X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 06:11:30 -0000 On Sun, Aug 29, 2004 at 12:59:11AM -0400, Brian Fundakowski Feldman wrote: > On Tue, Aug 10, 2004 at 01:53:14PM -0400, Anish Mistry wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Wednesday 04 August 2004 06:39 pm, you wrote: > > > On Wed, Aug 04, 2004 at 06:28:02PM -0400, Anish Mistry wrote: > > > > Ok, so we need something like vm_map_findspace(), but for process address > > > > mapping? ie. pmap_findspace() that will return an address to a large > > > > enough free chunk? > > > > > > That's a good start, just to get something to work with. How this fits in > > > with the vm code and whether it is ultimately suitable in the long run is > > > probably up to Alan Cox. For now, just get something that (a) doesn't break > > > anything else; and (b) lets Wine behave the way it needs to. > > > > > > AFAIK, there are still pthread issues with Wine, but those can't be > > > addressed until the mmap issue has a work-around. > > I've got a small patch that gets by the initial problem about not being to > > mmap the memory for the libraries, but the addresses that are mmap'ed seem to > > seem to overlap with memory that the current pthread implementation want to > > mmap for the "red zone" when wine tries to create a thread. It can't mmap > > the "red zone" addresses since all those address mapping where gobbled up > > before the thread launched. > > I'll try to figure out a way to maybe leave a space for the "red zone" and see > > if that works. > > Someone who actually knows what they are doing should probably take a look. > > The red pages are implemented by leaving the memory space unallocated; > I don't like that one bit -- this will cause those spaces to be allocated > but given no protection, which should provide the crash feature that the > guard pages are there for, but be less bogus (and it doesn't use more > "memory," but it will use a few more vm_map_entrys. > > Index: lib/libpthread/thread/thr_stack.c > =================================================================== > RCS file: /usr/ncvs/src/lib/libpthread/thread/thr_stack.c,v > retrieving revision 1.8 > diff -u -r1.8 thr_stack.c > --- lib/libpthread/thread/thr_stack.c 14 Sep 2003 22:39:44 -0000 1.8 > +++ lib/libpthread/thread/thr_stack.c 29 Aug 2004 04:50:28 -0000 > @@ -214,6 +214,17 @@ > stacksize, PROT_READ | PROT_WRITE, MAP_STACK, > -1, 0)) == MAP_FAILED) > attr->stackaddr_attr = NULL; > + if (attr->stackaddr_attr != NULL) { > + void *red; > + > + red = mmap((char *)attr->stackaddr_attr + stacksize, > + _thr_guard_default, PROT_NONE, > + MAP_ANON | MAP_FIXED | MAP_PRIVATE, -1, 0); > + if (red == MAP_FAILED) { > + (void)munmap(attr->stackaddr_attr, stacksize); > + attr->stackaddr_attr = NULL; > + } > + } > } > if (attr->stackaddr_attr != NULL) > return (0); > BTW, I think you could also use something like this instead of giving the kernel questionable mmap(2) policy. I haven't compiled/tested this one due to lack of a breaking WINE application (but the libpthread change I know seems to work fine.) --- map_object.c Sun Aug 29 02:02:54 2004 +++ map_object.c.new Sun Aug 29 02:09:22 2004 @@ -152,6 +152,16 @@ mapbase = mmap(base_addr, mapsize, convert_prot(segs[0]->p_flags), convert_flags(segs[0]->p_flags), fd, base_offset); + /* + * If the entire area above the ELF data space is already allocated, + * go ahead and try the area before the text (and everything else); + * skip the first 1024 pages to not allocate any values "near" NULL + * thus hiding NULL pointer errors. + */ + if (mapbase == (caddr_t) -1 && base_addr == NULL) + mapbase = mmap(getpagesize() << 10, mapsize, + convert_prot(segs[0]->p_flags), convert_flags(segs[0]->p_flags), + fd, base_offset); if (mapbase == (caddr_t) -1) { _rtld_error("%s: mmap of entire address space failed: %s", path, strerror(errno)); -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 08:39:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC48316A4CE; Sun, 29 Aug 2004 08:39:26 +0000 (GMT) Received: from abigail.blackend.org (blackend.org [212.11.35.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FDA243D41; Sun, 29 Aug 2004 08:39:24 +0000 (GMT) (envelope-from marc@blackend.org) Received: from abigail.blackend.org (localhost [127.0.0.1]) i7T8dL8C048960; Sun, 29 Aug 2004 10:39:21 +0200 (CEST) (envelope-from marc@abigail.blackend.org) Received: (from marc@localhost) by abigail.blackend.org (8.12.11/8.12.11/Submit) id i7T8dLg3048959; Sun, 29 Aug 2004 10:39:21 +0200 (CEST) (envelope-from marc) Date: Sun, 29 Aug 2004 10:39:20 +0200 From: Marc Fonvieille To: philip@freebsd.org Message-ID: <20040829083920.GA48813@abigail.blackend.org> References: <20040828184118.GA16378@abigail.blackend.org> <20040828200633.GA16742@abigail.blackend.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040828200633.GA16742@abigail.blackend.org> User-Agent: Mutt/1.4.2.1i X-Useless-Header: blackend.org X-Operating-System: FreeBSD 4.10-PRERELEASE cc: freebsd-current@freebsd.org cc: Robert Watson Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 08:39:27 -0000 On Sat, Aug 28, 2004 at 10:06:33PM +0200, Marc Fonvieille wrote: > On Sat, Aug 28, 2004 at 03:39:06PM -0400, Robert Watson wrote: > > On Sat, 28 Aug 2004, Marc Fonvieille wrote: > > > > > I updated my -CURRENT (from 16/08) laptop to today's -CURRENT, and I see > > > a lot of difference with my touchpad. Well, it's really not useable, > > > the touchpad is less accurate, the double tap & hold is not working > > > anymore etc. To sum up, if I want to use X with my laptop, I have to > > > plug in a mouse. > > > > > > So I'd like to back to previous behavior, I tried various psm flags to > > > make my touchpad seen as a vanilla PS/2 mouse, but nothing works. Is > > > there a way to switch back? > > > > I'm using this entry in /boot/device.hints: > > > > hint.psm.0.flags="0x200" > > > [...] > > hmm I used 0x0200, which not worked, I will try with 0x200. > :((( 0x200 gives the same result as 0x0200. You only added this hint, nothing more? The only solution I found was to plug-in a PS/2 mouse to have a "working" touchpad. For information I use a DELL Inspiron 4150. Hmm I have a doubt, are these "changes" in RELENG_5? I did not checked, but I wish/hope RELENG_5 is "sypnaptic safe". Marc From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 08:41:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F93016A4CE; Sun, 29 Aug 2004 08:41:50 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2545943D1F; Sun, 29 Aug 2004 08:41:49 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (p67klxkz@localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id i7T8flUL079129; Sun, 29 Aug 2004 12:41:47 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Sun, 29 Aug 2004 12:41:47 +0400 (MSD) From: Maxim Konovalov To: Jeremy Chadwick In-Reply-To: <20040817102003.P5098@mp2.macomnet.net> Message-ID: <20040829123449.Y79110@mp2.macomnet.net> References: <20040817060556.GA7458@parodius.com> <20040817102003.P5098@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: luigi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: ipfw2 net.inet.ip.fw.verbose_limit broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 08:41:50 -0000 Hello, > On Mon, 16 Aug 2004, 23:05-0700, Jeremy Chadwick wrote: > > > Just wanted to toss this one up here. Also, apologies for not > > cross-posting this to freebsd-ipfw, but I'm not on the list; although > > they seem to be aware of it: > > > > http://lists.freebsd.org/mailman/htdig/freebsd-ipfw/2004-July/001239.html > > > > Seems that ipfw2's support for net.inet.ip.fw.verbose_limit is, to > > put it bluntly, broken. This applies to both -STABLE and -CURRENT. > > The following PR has been sitting around for quite some time... > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/46080 I have fixed this bug in -CURRENT and will MFC it in a week to RELENG_4 and RELENG_5 with the re@ approval. > > I've managed to confirm this still exists even as of an August 5th build > > of -CURRENT. Using `logamount' directives per rule works properly as > > a workaround. > > > > I've also looked at the patch, although I'm not sure about the performance > > implications of looking up a sysctl value per packet with a matching > > ipfw2 `log' directive. No, it works in a different way. There are max_log and log_left fields in ipfw_insn_log sructure associated with each ipfw rule. They are checked on every packet matches the rule. That is why a changing verbose_limit value does not affect the existent rules. -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 08:52:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E76316A4CE for ; Sun, 29 Aug 2004 08:52:37 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7822143D41 for ; Sun, 29 Aug 2004 08:52:37 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.13.1/8.12.11) with ESMTP id i7T8qamI028807; Sun, 29 Aug 2004 01:52:36 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i7T8qaHc028773; Sun, 29 Aug 2004 01:52:36 -0700 (PDT) (envelope-from obrien) Date: Sun, 29 Aug 2004 01:52:34 -0700 From: "David O'Brien" To: Chris Laverdure Message-ID: <20040829085234.GC3971@dragon.nuxi.com> References: <20040829015159.08C527303F@freebsd-current.sentex.ca> <1093730290.1010.0.camel@elemental.DashEvil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1093730290.1010.0.camel@elemental.DashEvil> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-current@freebsd.org Subject: Re: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 08:52:37 -0000 On Sat, Aug 28, 2004 at 09:58:11PM +0000, Chris Laverdure wrote: > On Sun, 2004-08-29 at 01:51, FreeBSD Tinderbox wrote: > > cd /tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf; PATH=/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/legacy/usr/sbin:/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/legacy/usr/bin:/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/legacy/usr/games:/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/sbin:/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/bin:/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/LINT /tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf/LINT > > FYI: static unit limits for vcoda are set: NVCODA=4 > > config: Error: device "ichwd" is unknown > > config: 1 errors > > WARNING: kernel contains GPL contaminated ext2fs filesystem > > *** Error code 1 > > GPL contaminated? That really doesn't sound good at all.... Yes, we do have some kernel bits that are GPV'ed. They aren't in GENERIC and aren't built by default into the kernel. The build you see above is 'LINT', which is meant to build every peice of kernel code we have -- the warning is normal and expected. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 09:15:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08C2416A4CE; Sun, 29 Aug 2004 09:15:49 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AD9243D53; Sun, 29 Aug 2004 09:15:48 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smtp3b.sentex.ca (8.13.1/8.13.1) with ESMTP id i7T9Fl7P009319; Sun, 29 Aug 2004 05:15:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i7T9FlQ8064525; Sun, 29 Aug 2004 05:15:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 927B07303F; Sun, 29 Aug 2004 05:15:47 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040829091547.927B07303F@freebsd-current.sentex.ca> Date: Sun, 29 Aug 2004 05:15:47 -0400 (EDT) Subject: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 09:15:49 -0000 TB --- 2004-08-29 07:09:55 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-29 07:09:55 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2004-08-29 07:09:55 - checking out the source tree TB --- 2004-08-29 07:09:55 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2004-08-29 07:09:55 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-29 07:18:20 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-29 07:18:20 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2004-08-29 07:18:20 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-29 08:46:57 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-29 08:46:57 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2004-08-29 08:46:57 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Aug 29 08:46:58 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Aug 29 09:06:09 UTC 2004 TB --- 2004-08-29 09:06:09 - generating LINT kernel config TB --- 2004-08-29 09:06:09 - cd /home/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf TB --- 2004-08-29 09:06:09 - /usr/bin/make -B LINT TB --- 2004-08-29 09:06:09 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-29 09:06:09 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2004-08-29 09:06:09 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 29 09:06:09 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -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 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/geom/gate/g_gate.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -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 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/geom/label/g_label.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -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 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/geom/label/g_label_iso9660.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -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 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/geom/label/g_label_msdosfs.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -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 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/geom/label/g_label_ufs.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -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 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/geom/mirror/g_mirror.c /tinderbox/CURRENT/ia64/ia64/src/sys/geom/mirror/g_mirror.c: In function `g_mirror_taste': /tinderbox/CURRENT/ia64/ia64/src/sys/geom/mirror/g_mirror.c:2485: warning: 'sc' might be used uninitialized in this function *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2004-08-29 09:15:47 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-29 09:15:47 - ERROR: failed to build lint kernel TB --- 2004-08-29 09:15:47 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 09:33:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 193DF16A4CE for ; Sun, 29 Aug 2004 09:33:17 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1426E43D46 for ; Sun, 29 Aug 2004 09:33:13 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.13.1/8.12.11) with ESMTP id i7T9X6bm040421; Sun, 29 Aug 2004 02:33:06 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i7T9X2cI040420; Sun, 29 Aug 2004 02:33:02 -0700 (PDT) (envelope-from obrien) Date: Sun, 29 Aug 2004 02:33:02 -0700 From: "David O'Brien" To: Maxim Sobolev Message-ID: <20040829093302.GE3971@dragon.nuxi.com> Mail-Followup-To: David O'Brien , Maxim Sobolev , current@freebsd.org References: <412DF886.4030107@portaone.com> <412E0243.1050808@delphij.net> <412E0B6C.8030001@portaone.com> <20040826164212.GA62037@troutmask.apl.washington.edu> <412E1709.7010706@portaone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <412E1709.7010706@portaone.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: current@freebsd.org Subject: Re: [patch] bug in cpp's #ident handling in gcc 3.4 [Was: ccache with buildworld] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 09:33:17 -0000 On Thu, Aug 26, 2004 at 07:59:53PM +0300, Maxim Sobolev wrote: > Steve Kargl wrote: > >On Thu, Aug 26, 2004 at 07:10:20PM +0300, Maxim Sobolev wrote: > > > >>Pointless. Instead of fixing the problem we will remove condition when > >>this problem evidences itself. I am not advocating about keeping #ident, > >>since it is completely orthogonal question. gcc claims that it supports > >>#ident, there are problems in this support - they have to be fixed. > >> > >>Remember, there are lot of software out of /usr/src over which we have > >>no control (e.g. /usr/ports), so that removing #ident will really be > >>only half-measure, especially considering that the patch is readily > >>available. > >>-Maxim > > > >Isn't src/contrib/gcc/c-ppoutput.c on the vendor branch? > >Have you sent your patch to GCC? > > I wonder if it would be better if kan will do it, since he obviously > knows better inner circles of gcc team. No, it would not be better. If all the GCC team ever sees on the their mailing lists are Kan and myself that doesn't show them that FreeBSD is a community that they need to be concerned with its needs. Please email this patch to 'gcc-patches@gcc.gnu.org'. Thanks, -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 09:57:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 597FD16A4CE for ; Sun, 29 Aug 2004 09:57:39 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A09543D68 for ; Sun, 29 Aug 2004 09:57:38 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1C1MRD-0005ez-LM; Sun, 29 Aug 2004 13:57:27 +0400 From: Vladimir Grebenschikov To: Deng XueFeng In-Reply-To: <20040828114635.0AC4.DSNOFE@msn.com> References: <200408280145.i7S1jqxl096468@mail.gits.dyndns.org> <20040828114635.0AC4.DSNOFE@msn.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Sun, 29 Aug 2004 13:57:26 +0400 Message-Id: <1093773446.901.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.93FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: cyrille.lefevre@laposte.net cc: "current@freebsd.org" Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 09:57:39 -0000 On Sat, 2004-08-28 at 11:46 +0800, Deng XueFeng wrote: > > On Aug 27, 2004 01:59:50 am +0000, Deng XueFeng wrote: > > > First to thanks Sascha Wildner . > > > he hack syscons to make dfbsd support 1024x768(16/24/32) syscons, > > > then I ported that to current. and it works well with my ati MOBILITY > > > 7500[T31]/9200 [NX7000]. > > > To make console support 1024x768; just type > > > #vidcontrol MODE_279 How about another notebook native resolutions, 1400x1050 for example. > Sincerely, > Deng XueFeng > MSN: dsnofe@msn.com > http://www.dengh.com -- Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 10:08:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F24716A4CE for ; Sun, 29 Aug 2004 10:08:00 +0000 (GMT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3714743D49 for ; Sun, 29 Aug 2004 10:08:00 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-69-104-103-54.dsl.snfc21.pacbell.net [69.104.103.54])i7TA7mK6142466; Sun, 29 Aug 2004 06:07:49 -0400 Message-ID: <4131AAF3.1040905@elischer.org> Date: Sun, 29 Aug 2004 03:07:47 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: Julian Elischer References: <412E3E28.4070209@elischer.org> <412F08A1.1060806@kasimir.com> <412F8584.2070803@elischer.org> In-Reply-To: <412F8584.2070803@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: Scheduler framework patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 10:08:00 -0000 Julian Elischer wrote: > > > Florian C. Smeets wrote: > >> Julian Elischer wrote: > [...] >> >> Hi Julian, >> >> seems to work, but there is something wrong with the load calculation: > > > > > hmm I'll look at that tonight.. OK I found and fixed that... you should find useful load avg figures now if you retry. > >> >> >> last pid: 4227; load averages: 576.70, 884.21, 460.30 up >> 0+00:15:10 12:05:41 >> 141 processes: 3 running, 112 sleeping, 1 zombie, 25 waiting From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 10:13:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53F8016A4D1; Sun, 29 Aug 2004 10:13:03 +0000 (GMT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB1E743D58; Sun, 29 Aug 2004 10:13:02 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-69-104-103-54.dsl.snfc21.pacbell.net [69.104.103.54])i7TAD0K6199568; Sun, 29 Aug 2004 06:13:00 -0400 Message-ID: <4131AC2C.5070602@elischer.org> Date: Sun, 29 Aug 2004 03:13:00 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: Julian Elischer References: <41313BE3.2070906@elischer.org> In-Reply-To: <41313BE3.2070906@elischer.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: jreff@freebsd.org cc: FreeBSD current mailing list Subject: Re: New scheduler interface patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 10:13:03 -0000 Replying to self: Julian Elischer wrote: [...] > > > > problems: [...] > > > * Load Average under ULE is completely whacked.. I hope you (jeffr) can > see what I've done wrong here. I have found and fixed this. From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 10:15:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 040B116A4CE for ; Sun, 29 Aug 2004 10:15:10 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 733D043D48 for ; Sun, 29 Aug 2004 10:15:09 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id C44D11FF92F; Sun, 29 Aug 2004 12:15:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id C158E1FF91D; Sun, 29 Aug 2004 12:15:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 969E115672; Sun, 29 Aug 2004 10:13:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 8BEA315329; Sun, 29 Aug 2004 10:13:48 +0000 (UTC) Date: Sun, 29 Aug 2004 10:13:48 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Mario Hoerich In-Reply-To: <29145.1093740886@www50.gmx.net> Message-ID: References: <29145.1093740886@www50.gmx.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: FreeBSD current mailing list Subject: Re: [FIXED] Re: [5.3-B2] PPPoE broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 10:15:10 -0000 On Sun, 29 Aug 2004, Mario Hoerich wrote: > # Bjoern A. Zeeb: > > 3) could also be > > http://docs.FreeBSD.org/cgi/mid.cgi?200408271833.i7RIX8fw068973 ? > > Manually applying the diffs and rebuilding world+kernel seems > to have fixed it. Great. Thanks for the really fast help. :) this doesn't make much sense at all. Are you sure you had a complete and clean new RELENG_5 world and kernel before ? -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Sat Aug 28 16:12:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C29E516A4CE for ; Sat, 28 Aug 2004 16:12:26 +0000 (GMT) Received: from conure.mail.pas.earthlink.net (conure.mail.pas.earthlink.net [207.217.120.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id B512E43D2D for ; Sat, 28 Aug 2004 16:12:26 +0000 (GMT) (envelope-from mvh@ix.netcom.com) Received: from lsanca1-ar6-4-62-200-195.lsanca1.elnk.dsl.genuity.net ([4.62.200.195] helo=bsd.mvh) by conure.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 1C15oY-0006JQ-00 for current@freebsd.org; Sat, 28 Aug 2004 09:12:26 -0700 Received: from localhost (localhost [127.0.0.1]) by bsd.mvh (Postfix) with ESMTP id 9D0AA547A for ; Sat, 28 Aug 2004 09:12:25 -0700 (PDT) Received: from bsd.mvh ([127.0.0.1]) by localhost (bsd.mvh [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50275-06 for ; Sat, 28 Aug 2004 09:12:24 -0700 (PDT) Received: by bsd.mvh (Postfix, from userid 1000) id F12705469; Sat, 28 Aug 2004 09:12:23 -0700 (PDT) From: Mike Harding To: current@freebsd.org Message-Id: <20040828161223.F12705469@bsd.mvh> Date: Sat, 28 Aug 2004 09:12:23 -0700 (PDT) X-Virus-Scanned: by amavisd-new at bsd.mvh X-Mailman-Approved-At: Sun, 29 Aug 2004 11:42:14 +0000 Subject: Install problem with 5.3 beta 1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Aug 2004 16:12:26 -0000 If I don't install a boot manager, the install fails later when the actual format and install should occur. I already had a boot manager installed from a previous install, so I selected this option the second time around. Of course most people won't run into this... - Mike H. From owner-freebsd-current@FreeBSD.ORG Sat Aug 28 16:48:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5FF116A4CE for ; Sat, 28 Aug 2004 16:48:22 +0000 (GMT) Received: from thunderbird.etv.net (thunderbird.etv.net [208.14.190.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40F7F43D46 for ; Sat, 28 Aug 2004 16:48:22 +0000 (GMT) (envelope-from efinley@efinley.com) Received: from [205.161.203.50] (helo=science1) by thunderbird.etv.net with smtp (Exim 4.34 (FreeBSD)) id 1C16NJ-00094r-AZ for freebsd-current@freebsd.org; Sat, 28 Aug 2004 10:48:21 -0600 Message-ID: <01fc01c48d1e$d3985e50$32cba1cd@science1> From: "Elliot Finley" To: Date: Sat, 28 Aug 2004 10:48:20 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailman-Approved-At: Sun, 29 Aug 2004 11:42:14 +0000 Subject: 5.3 Beta2 boot problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Elliot Finley List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2004 16:48:22 -0000 This is on an ASUS P4P800 GENERIC kernel. If I let the machine try to boot normally (hands off, or option 1 [default]) I get: ACPI autoload failed - no such file or directory as the first line, and it fails to boot. If I choose option 2 (ACPI Disabled) then I don't get the 'ACPI autoload failed' line, but it still fails to boot. (see my previous message '5.3 Beta1 boot problems' for failure) If I choose option 2 (Safe mode) I get the following failure mode: ------------------------------------------------------------------ Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x58 :0x2dac stack pointer = 0x10 :0xf80 frame pointer = 0x10 :0x0 code segment = base 0xc00f0000, limit 0xffff, type 0x1b = DPL 0, pres 1, def32 0, gran 0 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread 0] Stopped at 0x2dac: *** error reading from address 2dac *** ------------------------------------------------------------------ Starting with option 4 (Single user) fails with the 'ACPI autoload failed' line. Starting with option 5 (Verbos logging) fails with the 'ACPI autoload failed' line. Starting with option 6 (Escape to loader prompt) gets me to the loader prompt. If I then type 'boot-conf', it boots just fine. I would really really like to get this problem fixed before 5.3-Release (Booting worked fine as of 5.2-CURRENT 8-4-2004). This is a spare machine, so I can take any steps necessary to help debug this. I can also grant access to anybody willing to work on this problem. Please let me know what I can do to help resolve this problem. dmesg from successful 'boot-conf' boot follows: oregon root:~#>dmesg Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-BETA2 #9: Sat Aug 28 09:29:05 MDT 2004 root@oregon.etv.net:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 2.60GHz (2598.76-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff Hyperthreading: 2 logical CPUs real memory = 1072889856 (1023 MB) avail memory = 1040351232 (992 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xf8000000-0xfbffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.P0P1 - AE_NOT_FOUND pci1: on pcib1 pci1: at device 0.0 (no driver attached) uhci0: port 0xef00-0xef1f irq 16 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xef20-0xef3f irq 19 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xef40-0xef5f irq 18 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xef80-0xef9f irq 16 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered pci0: at device 29.7 (no driver attached) pcib2: at device 30.0 on pci0 pci2: on pcib2 skc0: <3Com 3C940 Gigabit Ethernet> port 0xd800-0xd8ff mem 0xfeafc000-0xfeafffff irq 22 at device 5.0 on pci2 skc0: 3Com Gigabit LOM (3C940) sk0: on skc0 sk0: Ethernet address: 00:0c:6e:54:4b:25 miibus0: on sk0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto skc0: [GIANT-LOCKED] atapci0: port 0xdc00-0xdc7f,0xdfa0-0xdfaf,0xdf00-0xdf3f mem 0xfeac0000-0xfeadffff,0xfeafb000-0xfeafbfff irq 21 at device 9.0 on pci2 atapci0: failed: rid 0x20 is memory, requested 4 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 ata4: channel #2 on atapci0 ata5: channel #3 on atapci0 fxp0: port 0xde80-0xdebf mem 0xfeaa0000-0xfeabffff,0xfeafa000-0xfeafafff irq 23 at device 11.0 on pci2 miibus1: on fxp0 inphy0: on miibus1 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:02:b3:d1:f7:ad fxp0: [GIANT-LOCKED] isab0: at device 31.0 on pci0 isa0: on isab0 atapci1: port 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci1 ata1: channel #1 on atapci1 atapci2: port 0xef60-0xef6f,0xefa8-0xefab,0xefa0-0xefa7,0xefac-0xefaf,0xefe0-0xefe7 irq 18 at device 31.2 on pci0 ata6: channel #0 on atapci2 ata7: channel #1 on atapci2 pci0: at device 31.3 (no driver attached) pci0: at device 31.5 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2e8-0x2ef irq 3 on acpi0 sio1: type 16550A ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 orm0: at iomem 0xc8000-0xc97ff,0xc0000-0xc7fff on isa0 pmtimer0 on isa0 fdc0: ready for input in output fdc0: cmd 3 failed at out byte 1 of 3 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 2598759924 Hz quality 800 Timecounters tick every 10.000 msec ATAPI_RESET time = 80us acd0: CDROM at ata0-master UDMA33 ad12: 76319MB [155061/16/63] at ata6-master SATA150 ad14: 76319MB [155061/16/63] at ata7-master SATA150 Mounting root from ufs:/dev/ad12s1a From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 07:45:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8C2716A4CE for ; Sun, 29 Aug 2004 07:45:34 +0000 (GMT) Received: from matrix.gatewaynet.com (matrix.gatewaynet.com [217.19.69.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D44443D2D for ; Sun, 29 Aug 2004 07:45:34 +0000 (GMT) (envelope-from achill@matrix.gatewaynet.com) Received: from matrix.gatewaynet.com (localhost.localdomain [127.0.0.1]) by matrix.gatewaynet.com (8.12.8/8.12.8) with ESMTP id i7T6wfsR026193 for ; Sun, 29 Aug 2004 09:58:41 +0300 Received: from localhost (achill@localhost)i7T6wfIb026189 for ; Sun, 29 Aug 2004 09:58:41 +0300 Date: Sun, 29 Aug 2004 09:58:41 +0300 (EEST) From: Achilleus Mantzios To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Sun, 29 Aug 2004 11:42:14 +0000 Subject: Transition from 5.1-RELEASE-p10 to 5.3-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 07:45:35 -0000 Hi, after make buildworld,make buildkernel, make install kernel i rebooted single-user, just to find out that ls, mount, etc.. gave ls exited with signal 12, bad system call. After i rebooted with the old 5.1 kernel and did make buildkernel *with* COMPAT_FREEBSD4, i could reboot single user with 5.3 and run ls,mount, etc... just fine. What has COMPAT_FREEBSD4 has to do, since i *didnt* have it in my 5.1-RELEASE-p10, and no FreeBSD 4.x programs were run? Another point that maybe should be addressed in docs (UPDATING) is that when rebooting single user / is mounted ro, so mergemaster -p cannot write to /etc/master.passwd, groups. -- -Achilleus From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 11:39:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B28B16A4CE for ; Sun, 29 Aug 2004 11:39:56 +0000 (GMT) Received: from dd2626.kasserver.com (dd2626.kasserver.com [81.209.184.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6134943D60 for ; Sun, 29 Aug 2004 11:39:55 +0000 (GMT) (envelope-from outi@bytephobia.de) Received: from [10.0.0.2] (pD95F0D10.dip.t-dialin.net [217.95.13.16]) by dd2626.kasserver.com (Postfix) with ESMTP id 418EF7A435; Sun, 29 Aug 2004 13:39:52 +0200 (CEST) Message-ID: <4131B0AA.6020402@bytephobia.de> Date: Sun, 29 Aug 2004 12:32:10 +0200 From: Patrick Hurrelmann User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040810) X-Accept-Language: en-us, en MIME-Version: 1.0 To: cyrille.lefevre@laposte.net References: <200408280145.i7S1jqxl096468@mail.gits.dyndns.org> In-Reply-To: <200408280145.i7S1jqxl096468@mail.gits.dyndns.org> Content-Type: multipart/mixed; boundary="------------060400080506060000090500" cc: Deng XueFeng cc: current@freebsd.org Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: outi@bytephobia.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, 29 Aug 2004 11:39:56 -0000 This is a multi-part message in MIME format. --------------060400080506060000090500 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Cyrille, I tried you patch and it applies cleanly to 5.3-BETA1, but kernelbuild breaks due to syscons. Does anybody experience the same? See attached log of kernelbuild. Thanks Patrick Cyrille Lefevre wrote: > On Aug 27, 2004 01:59:50 am +0000, Deng XueFeng wrote: > >>First to thanks Sascha Wildner . >>he hack syscons to make dfbsd support 1024x768(16/24/32) syscons, >>then I ported that to current. and it works well with my ati MOBILITY >>7500[T31]/9200 [NX7000]. >>To make console support 1024x768; just type >>#vidcontrol MODE_279 >> >>The originer patch can be get from dfbsd's maillist. > > > here it is :) > http://leaf.dragonflybsd.org/mailarchive/submit/2004-08/msg00074.html > > >>and the attachment is against with FreeBSD CURRENT and 5.3 >>enjoy it! >> >>NOTE: >> current-vidcontrol.1 current-vidcontrol.c is taken from dfbsd. which >>is include >> Sascha's patch. > > > Hi, > > I don't know why, but your patch set doesn't apply cleanly against -current ! > so, I merged it in manually. also, take care while importing things to -current >>from DFBSD, since DFBSD is a fork from -stable. in other words, your patch set > backout some change done in -current. the following patch set take care of this. > I also tried to reduce the diff against -current whenever possible and made some > style(9) changes (#define and ... to ). > > thanks anyway and good luck. > > PS : the following patch set applies and compiles cleanly against -current. > however, I didn't have tested it yet since I can't reboot right now. > > > Cyrille Lefevre -- =========================================================================== Patrick Hurrelmann | "Programming today is a race between software Mannheim, Germany | engineers striving to build bigger and better | idiot-proof programs, and the Universe trying outi at bytephobia.de | to produce bigger and better idiots. So far, www.bytephobia.de | the Universe is winning." - Rich Cook --------------060400080506060000090500 Content-Type: text/plain; name="kernelbuild.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kernelbuild.txt" cc -c -O -pipe -march=pentium4 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/sio/sio.c cc -c -O -pipe -march=pentium4 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/sio/sio_isa.c cc -c -O -pipe -march=pentium4 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/syscons/schistory.c cc -c -O -pipe -march=pentium4 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/syscons/scmouse.c cc -c -O -pipe -march=pentium4 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/syscons/scterm.c cc -c -O -pipe -march=pentium4 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/syscons/scterm-dumb.c cc -c -O -pipe -march=pentium4 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/syscons/scterm-sc.c cc -c -O -pipe -march=pentium4 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/syscons/scvesactl.c cc -c -O -pipe -march=pentium4 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/syscons/scvgarndr.c /usr/src/sys/dev/syscons/scvgarndr.c:513: warning: return type defaults to `int' /usr/src/sys/dev/syscons/scvgarndr.c:513: warning: conflicting types for 'vga_pxlclear' /usr/src/sys/dev/syscons/scvgarndr.c:66: warning: previous declaration of 'vga_pxlclear' was here /usr/src/sys/dev/syscons/scvgarndr.c:912: warning: return type defaults to `int' /usr/src/sys/dev/syscons/scvgarndr.c:912: warning: no previous prototype for 'draw_pxlcursor_direct' /usr/src/sys/dev/syscons/scvgarndr.c:1086: warning: return type defaults to `int' /usr/src/sys/dev/syscons/scvgarndr.c:1086: warning: no previous prototype for 'draw_pxlmouse_direct' /usr/src/sys/dev/syscons/scvgarndr.c:1240: warning: return type defaults to `int' /usr/src/sys/dev/syscons/scvgarndr.c:1240: warning: no previous prototype for 'draw_pxlmouse' *** Error code 1 Stop in /usr/obj/usr/src/sys/MOBILITY. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. --------------060400080506060000090500-- From owner-freebsd-current@FreeBSD.ORG Sat Aug 28 17:00:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D500516A4D0 for ; Sat, 28 Aug 2004 17:00:46 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (80-219-172-255.dclient.hispeed.ch [80.219.172.255]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E71743D54 for ; Sat, 28 Aug 2004 17:00:30 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:50db:acff:0:220:afff:fed4:dbcb]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id i7SH0QL00993 verified NO) for ; Sat, 28 Aug 2004 19:00:28 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id i7SH0Q700992; Sat, 28 Aug 2004 19:00:26 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Sat, 28 Aug 2004 19:00:26 +0200 (CEST) Message-Id: <200408281700.i7SH0Q700992@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma To: current@freebsd.org X-Mailman-Approved-At: Sun, 29 Aug 2004 11:51:58 +0000 Subject: M*K**BJD*RPR*F*X and make.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Aug 2004 17:00:47 -0000 [grrr, last IP was blacklisted; try the list again] Hi. You're going to hate me by the end of this message, in the unlikely chance that you don't hate me already. If I'm reading the failure of my attempted crossbuild of FreeBSD5 on my FBSD-4 machine, the check in Makefile.inc1 is not looking in the right __MAKE_CONF, which I've tried specifying both as environment and make-option to cover all bases. Instead, it's looking in /etc/make.conf, which as far as I know is never used during my crossbuild (I hope), and where as far as I know it's still not expressly forbidden to use M*K**BJetc ?= foo at the present time under 4.x ... I've tried the following for fun and laughs, and it actually seems to pick up the right values for M_K__BJD_RPR_F_X (I'm sure nobody wants to read the uncensored version of that for weeks or months to come), allowing my build to continue: _MAKEOBJDIRPREFIX!= env -i PATH=${PATH} __MAKE_CONF="${__MAKE_CONF}" \ MAKEFLAGS="${.MAKEFLAGS}" ${MAKE} \ -f /dev/null -V MAKEOBJDIRPREFIX dummy .if !empty(_MAKEOBJDIRPREFIX) May I request that something done properly (unlike the above which is certainly no more than an ugly hack) be applied in order to check the correct file for crossbuilds or other cases where __MAKE_CONF is specified instead? Sorry if this has been done already, my last time online to nab source was late UTC 22.Aug. I fully understand that you hate me now. thanks barry bouwsma (to rehash a previous thread, here's another reason I liked to be able to specify M*K**BJD*RPR*F*X in a make.conf, is in order to automagically get a different obj directory for each build, by evaluating `uname' and `date' and whatnot, which now requires an each-time invocation as environment, unlike the set-and-forget in a suitable make.conf. no, I haven't tried my hand at suitably replacing this (mis)feature in an acceptable way yet) From owner-freebsd-current@FreeBSD.ORG Sat Aug 28 17:15:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8577816A4CE for ; Sat, 28 Aug 2004 17:15:23 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (80-219-172-255.dclient.hispeed.ch [80.219.172.255]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6FE943D5E for ; Sat, 28 Aug 2004 17:15:19 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:50db:acff:0:220:afff:fed4:dbcb]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id i7SHFGL01018 verified NO) for ; Sat, 28 Aug 2004 19:15:18 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id i7SHFF201017; Sat, 28 Aug 2004 19:15:15 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Sat, 28 Aug 2004 19:15:15 +0200 (CEST) Message-Id: <200408281715.i7SHFF201017@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma References: <200408181910.i7IJAawl081643@bleep.craftncomp.com> <20040818183312.T55263@carver.gumbysoft.com> <20040819085119.GE76085@ip.net.ua> To: current@FreeBSD.org X-Mailman-Approved-At: Sun, 29 Aug 2004 11:51:58 +0000 Subject: Re: Persisten buildworld errors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 28 Aug 2004 17:15:23 -0000 [keep replies to the list and I'll catch up next time I'm online, thanks] > Please don't suggest people to run "make includes". This will likely > break upgrades from older systems because headers (most noticeble one > is /usr/include/osreldate.h) will not match the installed world, and Purely for interest, which other includes headers are critical like this? (I ask as I'm crossbuilding DragonFly and I've had to hack to use up-to-date includes during the crossbuild, and would like to exclude any from my hack that are important for this reason) thanks barry bouwsma From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 12:04:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DD7216A4CE for ; Sun, 29 Aug 2004 12:04:15 +0000 (GMT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CFC043D3F for ; Sun, 29 Aug 2004 12:04:15 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.112.132) by smtp01.syd.iprimus.net.au (7.0.028) id 412F6C1400085D1C; Sun, 29 Aug 2004 22:04:13 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id D0D174207; Sun, 29 Aug 2004 22:04:06 +1000 (EST) Date: Sun, 29 Aug 2004 22:04:06 +1000 From: Tim Robbins To: Achilleus Mantzios Message-ID: <20040829120406.GA52614@cat.robbins.dropbear.id.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: freebsd-current@freebsd.org Subject: Re: Transition from 5.1-RELEASE-p10 to 5.3-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 12:04:15 -0000 On Sun, Aug 29, 2004 at 09:58:41AM +0300, Achilleus Mantzios wrote: > Hi, after make buildworld,make buildkernel, make install kernel > i rebooted single-user, just to find out that > ls, mount, etc.. gave > ls exited with signal 12, > bad system call. > > After i rebooted with the old 5.1 kernel and did make buildkernel > *with* COMPAT_FREEBSD4, i could reboot single user with > 5.3 and run ls,mount, etc... just fine. This was covered by the 20031112 entry in /usr/src/UPDATING. As a general rule, you should use GENERIC instead of a custom kernel configuration (or a GENERIC config from a previous release) when updating, at least on branches that aren't marked -STABLE. > What has COMPAT_FREEBSD4 has to do, since i *didnt* have it in my > 5.1-RELEASE-p10, and no FreeBSD 4.x programs were run? I believe the rationale was that no -STABLE releases after FreeBSD 4 used the old statfs() interface. I agree that the name is misleading. Tim From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 13:31:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1754516A4CE for ; Sun, 29 Aug 2004 13:31:46 +0000 (GMT) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B625943D45 for ; Sun, 29 Aug 2004 13:31:45 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (andy@localhost [127.0.0.1]) i7TDVfG9032029; Sun, 29 Aug 2004 09:31:41 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)i7TDVeRr032026; Sun, 29 Aug 2004 09:31:41 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Sun, 29 Aug 2004 09:31:40 -0400 (EDT) From: Andre Guibert de Bruet To: Jun Kuriyama In-Reply-To: <7mllfz4qlj.wl@black.imgsrc.co.jp> Message-ID: <20040829093045.J5951@alpha.siliconlandmark.com> References: <7mllfz4qlj.wl@black.imgsrc.co.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean cc: current@freebsd.org Subject: Re: Coming soon: default to Giant-free networking in 6.x (was: Running the network stack without Giant -- change in default coming (fwd)) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 13:31:46 -0000 On Sat, 28 Aug 2004, Jun Kuriyama wrote: > At Fri, 27 Aug 2004 21:54:31 +0000 (UTC), > Robert Watson wrote: >> There are components of IPv6 that are not MPSAFE, but they are >> sufficiently minor components that they will be relatively safe in most >> scenarios, and it's probably reasonable to leave them enabled by default. >> We're working on completing locking for those components. > > Does this mean all 5.3 box in my office will be required to set > debug.mpsafenet=0 (80% of in my office is running 5.2.1 and rest are > 4.10, with using IPv6 much)? :-) I think you might have glanced over the following line right at the top: "This evening I will commit several changes to the 6.x branch relating to..." Regards, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 13:36:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59DA716A4CE; Sun, 29 Aug 2004 13:36:56 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0896943D1F; Sun, 29 Aug 2004 13:36:56 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smtp3.sentex.ca (8.13.1/8.13.1) with ESMTP id i7TDarpV063149; Sun, 29 Aug 2004 09:36:53 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i7TDat6R036288; Sun, 29 Aug 2004 09:36:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 49CE47303F; Sun, 29 Aug 2004 09:36:55 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040829133655.49CE47303F@freebsd-current.sentex.ca> Date: Sun, 29 Aug 2004 09:36:55 -0400 (EDT) Subject: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 13:36:56 -0000 TB --- 2004-08-29 12:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-29 12:15:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2004-08-29 12:15:00 - checking out the source tree TB --- 2004-08-29 12:15:00 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2004-08-29 12:15:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-29 12:20:21 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-29 12:20:21 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-08-29 12:20:21 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-29 13:24:08 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-29 13:24:08 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-08-29 13:24:08 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Aug 29 13:24:08 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Aug 29 13:36:54 UTC 2004 TB --- 2004-08-29 13:36:54 - generating LINT kernel config TB --- 2004-08-29 13:36:54 - cd /home/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- 2004-08-29 13:36:54 - /usr/bin/make -B LINT TB --- 2004-08-29 13:36:54 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-29 13:36:54 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-08-29 13:36:54 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 29 13:36:54 UTC 2004 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf; PATH=/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/legacy/usr/sbin:/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/legacy/usr/bin:/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/legacy/usr/games:/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/sbin:/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/bin:/home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/LINT /tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf/LINT /tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf/LINT: unknown option "HW_WDOG" *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2004-08-29 13:36:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-29 13:36:55 - ERROR: failed to build lint kernel TB --- 2004-08-29 13:36:55 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 13:57:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D1DC16A4CF for ; Sun, 29 Aug 2004 13:57:09 +0000 (GMT) Received: from abcjr.abcjr.net (abcjr.abcjr.net [207.178.110.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8BDC43D2F for ; Sun, 29 Aug 2004 13:57:08 +0000 (GMT) (envelope-from abcjr@abcjr.net) Received: from abcjr.abcjr.net (localhost [127.0.0.1]) by abcjr.abcjr.net (8.13.1/8.13.1) with ESMTP id i7TDv7Xg053455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 29 Aug 2004 08:57:08 -0500 (CDT) (envelope-from abcjr@abcjr.abcjr.net) Received: (from abcjr@localhost) by abcjr.abcjr.net (8.13.1/8.13.1/Submit) id i7TDv7pC053454 for freebsd-current@freebsd.org; Sun, 29 Aug 2004 08:57:07 -0500 (CDT) (envelope-from abcjr) Date: Sun, 29 Aug 2004 08:57:07 -0500 From: "Arnold Cavazos Jr." To: freebsd-current@freebsd.org Message-ID: <20040829135707.GA53317@abcjr.net> References: <16689.768.883054.824945@canoe.dclg.ca> <20040829021701.O77200@mp2.macomnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040829021701.O77200@mp2.macomnet.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: clamd / ClamAV version devel-20040706, clamav-milter version 0.74a on abcjr.abcjr.net X-Virus-Status: Clean Subject: Re: netstat oddness. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 13:57:09 -0000 from /usr/src/UPDATING: 20040802: making /dev/(null|zero) into a module proved to be too unpopular, so this bit has been revoked from the previous (20040801) entry. 20040801: The /dev/mem, /dev/io /dev/(null/zero) devices are now modules, so you may wish to add them to your kernel config file. See GENERIC for examples. In the alternative 'kldload mem.ko' will get you going as well. -- Arnold Cavazos, Jr. abcjr at abcjr . net On Sun, Aug 29, 2004 at 02:17:08AM +0400, Maxim Konovalov wrote: > On Sat, 28 Aug 2004, 18:11-0400, David Gilbert wrote: > > > Recent versions of -CURRENT have been giving me the following: > > > > [1:17:317]root@vulture:/usr/src> netstat -rn > > netstat: kvm not available > > Routing tables > > rt_tables: symbol not in namelist > > > > Most invocations of netstat complain about the kvm. Other ones I > > commonly use (like -an) output normal results. -rn seems to be > > completely broken. > > > > Any ideas? > > http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/70863 > > -- > Maxim Konovalov > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 13:59:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86A5D16A4D0 for ; Sun, 29 Aug 2004 13:59:52 +0000 (GMT) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [80.86.187.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FD2543D31 for ; Sun, 29 Aug 2004 13:59:51 +0000 (GMT) (envelope-from oliver@FreeBSD.org) Received: (qmail 30850 invoked from network); 29 Aug 2004 13:59:30 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (80.86.187.43) by avocado.salatschuessel.net with SMTP; 29 Aug 2004 13:59:30 -0000 Date: Sun, 29 Aug 2004 15:59:45 +0200 From: Oliver Lehmann To: re@freebsd.org Message-Id: <20040829155945.04c6e811.oliver@FreeBSD.org> X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd4.10) Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Sun__29_Aug_2004_15_59_45_+0200_b4ptC/ltohPxY+v6" cc: performance@freebsd.org cc: current@freebsd.org Subject: serious slowdown in 5.3-BETA1 using SCHED_4BSD and SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 13:59:52 -0000 This is a multi-part message in MIME format. --Multipart=_Sun__29_Aug_2004_15_59_45_+0200_b4ptC/ltohPxY+v6 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hello, I've noticed a serious speeddown by using SMP. When I run the same system with only one CPU, the system works quite well. But after sticking in the second CPU, the system slows down noticeable. The whole system responds quite laggy. That started to happen after I updated FreeBSD from 5.2.1 to 5.3-BETA1. On 5.2.1 I had all kernel debugging options enabled. With that kernel-config 5.3 was not useable in any way. For example playing 128kbit mp3s over nfs was nearly impossible because it stoped playing every 10-30 seconds for 2-5 seconds.... I did a "ln -s aj /etc/malloc.conf" and disabled all the [DGK]DB, WITNESS* and INVARIANT* options in my Kernel-config file. IT tokk me 9:52h(!!) to compile that kernel (make kernel). Now, booted with that kernel (NUDEL.bak) - SMP feels still much more slower then 5.2.1 felt. To show the speeddowns, I built now the attached kernel "NUDEL": ########################################################################## #### on System: nudel.dmesg Booted kernel: "NUDEL.bak" (SCHED_4BSD) 1 CPU : 3927.42 real 3279.99 user 454.95 sys 2 CPUs: 51546.74 real 44414.65 user 5151.46 sys (14hrs!!!) Booted kernel: "NUDEL" (SCHED_ULE) 1 CPU : 3943.72 real 3284.04 user 459.58 sys 2 CPUs: 3864.97 real 3287.69 user 454.52 sys ########################################################################## #### on System: curry.dmesg Booted kernel: "CURRY" (SCHED_4BSD) 1 CPU : 4376.41 real 3652.60 user 435.60 sys I built with: rm -rf /usr/obj/i386-5.3/usr/src/sys/NUDEL && \ /usr/bin/time env MAKEOBJDIRPREFIX=/usr/obj/i386-5.3 make kernel My make.conf: KERNCONF?=NUDEL # MAKEOBJDIRPREFIX=/usr/obj/i386-5.2.1 WRKDIRPREFIX=/usr/obj/${MACHINE}-${OSREL} #CPUTYPE=p2 # -- use.perl generated deltas -- # # Created: Fri Mar 21 00:28:26 2003 # Setting to use base perl from ports: PERL_VER=5.6.1 PERL_VERSION=5.6.1 PERL_ARCH=mach NOPERL=yo NO_PERL=yo NO_PERL_WRAPPER=yo I've attached the vmstat -i output during make For example - a simple "make buildworld" with 2CPUs/SCHED_4BSD for (and on) 5.2.1-RC2 took only 16916.70sec (I'm sorry, but I've no kernel building times archived) !!!And it's not just the kernel build - the whole system with running 2 CPUS + SCHED_4BSD is _slow_. I just took the kernel build as an example!!! Something seems to be verry broken with SCHED_4BSD+SMP -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ --Multipart=_Sun__29_Aug_2004_15_59_45_+0200_b4ptC/ltohPxY+v6 Content-Type: application/octet-stream; name="NUDEL" Content-Disposition: attachment; filename="NUDEL" Content-Transfer-Encoding: base64 IwojIEdFTkVSSUMgLS0gR2VuZXJpYyBrZXJuZWwgY29uZmlndXJhdGlvbiBmaWxlIGZvciBGcmVl QlNEL2kzODYKIwojIEZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHRoaXMgZmlsZSwgcGxlYXNlIHJl YWQgdGhlIGhhbmRib29rIHNlY3Rpb24gb24KIyBLZXJuZWwgQ29uZmlndXJhdGlvbiBGaWxlczoK IwojICAgIGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcvZG9jL2VuX1VTLklTTzg4NTktMS9ib29rcy9o YW5kYm9vay9rZXJuZWxjb25maWctY29uZmlnLmh0bWwKIwojIFRoZSBoYW5kYm9vayBpcyBhbHNv IGF2YWlsYWJsZSBsb2NhbGx5IGluIC91c3Ivc2hhcmUvZG9jL2hhbmRib29rCiMgaWYgeW91J3Zl IGluc3RhbGxlZCB0aGUgZG9jIGRpc3RyaWJ1dGlvbiwgb3RoZXJ3aXNlIGFsd2F5cyBzZWUgdGhl CiMgRnJlZUJTRCBXb3JsZCBXaWRlIFdlYiBzZXJ2ZXIgKGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcv KSBmb3IgdGhlCiMgbGF0ZXN0IGluZm9ybWF0aW9uLgojCiMgQW4gZXhoYXVzdGl2ZSBsaXN0IG9m IG9wdGlvbnMgYW5kIG1vcmUgZGV0YWlsZWQgZXhwbGFuYXRpb25zIG9mIHRoZQojIGRldmljZSBs aW5lcyBpcyBhbHNvIHByZXNlbnQgaW4gdGhlIC4uLy4uL2NvbmYvTk9URVMgYW5kIE5PVEVTIGZp bGVzLgojIElmIHlvdSBhcmUgaW4gZG91YnQgYXMgdG8gdGhlIHB1cnBvc2Ugb3IgbmVjZXNzaXR5 IG9mIGEgbGluZSwgY2hlY2sgZmlyc3QKIyBpbiBOT1RFUy4KIwojICRGcmVlQlNEOiBzcmMvc3lz L2kzODYvY29uZi9HRU5FUklDLHYgMS40MTMgMjAwNC8wOC8xMSAwMTozNDoxOCByd2F0c29uIEV4 cCAkCgptYWNoaW5lCQlpMzg2CiNjcHUJCUk0ODZfQ1BVCiNjcHUJCUk1ODZfQ1BVCmNwdQkJSTY4 Nl9DUFUKaWRlbnQJCU5VREVMCgojIFRvIHN0YXRpY2FsbHkgY29tcGlsZSBpbiBkZXZpY2Ugd2ly aW5nIGluc3RlYWQgb2YgL2Jvb3QvZGV2aWNlLmhpbnRzCiNoaW50cwkJIkdFTkVSSUMuaGludHMi CQkjIERlZmF1bHQgcGxhY2VzIHRvIGxvb2sgZm9yIGRldmljZXMuCgptYWtlb3B0aW9ucwlERUJV Rz0tZwkJIyBCdWlsZCBrZXJuZWwgd2l0aCBnZGIoMSkgZGVidWcgc3ltYm9scwoKb3B0aW9ucyAJ U0NIRURfVUxFCQkjIFVMRSBzY2hlZHVsZXIKb3B0aW9ucyAJSU5FVAkJCSMgSW50ZXJORVR3b3Jr aW5nCiNvcHRpb25zIAlJTkVUNgkJCSMgSVB2NiBjb21tdW5pY2F0aW9ucyBwcm90b2NvbHMKb3B0 aW9ucyAJRkZTCQkJIyBCZXJrZWxleSBGYXN0IEZpbGVzeXN0ZW0Kb3B0aW9ucyAJU09GVFVQREFU RVMJCSMgRW5hYmxlIEZGUyBzb2Z0IHVwZGF0ZXMgc3VwcG9ydApvcHRpb25zIAlVRlNfQUNMCQkJ IyBTdXBwb3J0IGZvciBhY2Nlc3MgY29udHJvbCBsaXN0cwpvcHRpb25zIAlVRlNfRElSSEFTSAkJ IyBJbXByb3ZlIHBlcmZvcm1hbmNlIG9uIGJpZyBkaXJlY3Rvcmllcwojb3B0aW9ucyAJTURfUk9P VAkJCSMgTUQgaXMgYSBwb3RlbnRpYWwgcm9vdCBkZXZpY2UKb3B0aW9ucyAJTkZTQ0xJRU5UCQkj IE5ldHdvcmsgRmlsZXN5c3RlbSBDbGllbnQKb3B0aW9ucyAJTkZTU0VSVkVSCQkjIE5ldHdvcmsg RmlsZXN5c3RlbSBTZXJ2ZXIKI29wdGlvbnMgCU5GU19ST09UCQkjIE5GUyB1c2FibGUgYXMgLywg cmVxdWlyZXMgTkZTQ0xJRU5UCm9wdGlvbnMgCU1TRE9TRlMJCQkjIE1TRE9TIEZpbGVzeXN0ZW0K b3B0aW9ucyAJQ0Q5NjYwCQkJIyBJU08gOTY2MCBGaWxlc3lzdGVtCm9wdGlvbnMgCVBST0NGUwkJ CSMgUHJvY2VzcyBmaWxlc3lzdGVtIChyZXF1aXJlcyBQU0VVRE9GUykKb3B0aW9ucyAJUFNFVURP RlMJCSMgUHNldWRvLWZpbGVzeXN0ZW0gZnJhbWV3b3JrCm9wdGlvbnMgCUdFT01fR1BUCQkjIEdV SUQgUGFydGl0aW9uIFRhYmxlcy4Kb3B0aW9ucyAJQ09NUEFUXzQzCQkjIENvbXBhdGlibGUgd2l0 aCBCU0QgNC4zIFtLRUVQIFRISVMhXQojb3B0aW9ucyAJQ09NUEFUX0ZSRUVCU0Q0CQkjIENvbXBh dGlibGUgd2l0aCBGcmVlQlNENApvcHRpb25zIAlTQ1NJX0RFTEFZPTIwMDAJIyBEZWxheSAoaW4g bXMpIGJlZm9yZSBwcm9iaW5nIFNDU0kKb3B0aW9ucyAJS1RSQUNFCQkJIyBrdHJhY2UoMSkgc3Vw cG9ydApvcHRpb25zIAlTWVNWU0hNCQkJIyBTWVNWLXN0eWxlIHNoYXJlZCBtZW1vcnkKb3B0aW9u cyAJU1lTVk1TRwkJCSMgU1lTVi1zdHlsZSBtZXNzYWdlIHF1ZXVlcwpvcHRpb25zIAlTWVNWU0VN CQkJIyBTWVNWLXN0eWxlIHNlbWFwaG9yZXMKb3B0aW9ucyAJX0tQT1NJWF9QUklPUklUWV9TQ0hF RFVMSU5HICMgUE9TSVggUDEwMDNfMUIgcmVhbC10aW1lIGV4dGVuc2lvbnMKb3B0aW9ucyAJS0JE X0lOU1RBTExfQ0RFVgkjIGluc3RhbGwgYSBDREVWIGVudHJ5IGluIC9kZXYKI29wdGlvbnMgCUFI Q19SRUdfUFJFVFRZX1BSSU5UCSMgUHJpbnQgcmVnaXN0ZXIgYml0ZmllbGRzIGluIGRlYnVnCgkJ CQkJIyBvdXRwdXQuICBBZGRzIH4xMjhrIHRvIGRyaXZlci4KI29wdGlvbnMgCUFIRF9SRUdfUFJF VFRZX1BSSU5UCSMgUHJpbnQgcmVnaXN0ZXIgYml0ZmllbGRzIGluIGRlYnVnCgkJCQkJIyBvdXRw dXQuICBBZGRzIH4yMTVrIHRvIGRyaXZlci4Kb3B0aW9ucyAJUEZJTF9IT09LUwkJIyBwZmlsKDkp IGZyYW1ld29yawpvcHRpb25zIAlBREFQVElWRV9HSUFOVAkJIyBHaWFudCBtdXRleCBpcyBhZGFw dGl2ZS4KCiMgRGVidWdnaW5nIGZvciB1c2UgaW4gLWN1cnJlbnQKI29wdGlvbnMgCUtEQgkJCSMg RW5hYmxlIGtlcm5lbCBkZWJ1Z2dlciBzdXBwb3J0Lgojb3B0aW9ucyAJRERCCQkJIyBTdXBwb3J0 IEREQi4KI29wdGlvbnMgCUdEQgkJCSMgU3VwcG9ydCByZW1vdGUgR0RCLgojb3B0aW9ucyAJSU5W QVJJQU5UUwkJIyBFbmFibGUgY2FsbHMgb2YgZXh0cmEgc2FuaXR5IGNoZWNraW5nCiNvcHRpb25z IAlJTlZBUklBTlRfU1VQUE9SVAkjIEV4dHJhIHNhbml0eSBjaGVja3Mgb2YgaW50ZXJuYWwgc3Ry dWN0dXJlcywgcmVxdWlyZWQgYnkgSU5WQVJJQU5UUwojb3B0aW9ucyAJV0lUTkVTUwkJCSMgRW5h YmxlIGNoZWNrcyB0byBkZXRlY3QgZGVhZGxvY2tzIGFuZCBjeWNsZXMKI29wdGlvbnMgCVdJVE5F U1NfU0tJUFNQSU4JIyBEb24ndCBydW4gd2l0bmVzcyBvbiBzcGlubG9ja3MgZm9yIHNwZWVkCgoj IFRvIG1ha2UgYW4gU01QIGtlcm5lbCwgdGhlIG5leHQgdHdvIGFyZSBuZWVkZWQKb3B0aW9ucyAJ U01QCQkjIFN5bW1ldHJpYyBNdWx0aVByb2Nlc3NvciBLZXJuZWwKZGV2aWNlCQlhcGljCQkjIEkv TyBBUElDCgojIEJ1cyBzdXBwb3J0LiAgRG8gbm90IHJlbW92ZSBpc2EsIGV2ZW4gaWYgeW91IGhh dmUgbm8gaXNhIHNsb3RzCmRldmljZQkJaXNhCiNkZXZpY2UJCWVpc2EKZGV2aWNlCQlwY2kKCiMg RmxvcHB5IGRyaXZlcwpkZXZpY2UJCWZkYwoKIyBBVEEgYW5kIEFUQVBJIGRldmljZXMKZGV2aWNl CQlhdGEKZGV2aWNlCQlhdGFkaXNrCQkjIEFUQSBkaXNrIGRyaXZlcwojZGV2aWNlCQlhdGFyYWlk CQkjIEFUQSBSQUlEIGRyaXZlcwpkZXZpY2UJCWF0YXBpY2QJCSMgQVRBUEkgQ0RST00gZHJpdmVz CiNkZXZpY2UJCWF0YXBpZmQJCSMgQVRBUEkgZmxvcHB5IGRyaXZlcwojZGV2aWNlCQlhdGFwaXN0 CQkjIEFUQVBJIHRhcGUgZHJpdmVzCm9wdGlvbnMgCUFUQV9TVEFUSUNfSUQJIyBTdGF0aWMgZGV2 aWNlIG51bWJlcmluZwoKIyBTQ1NJIENvbnRyb2xsZXJzCiNkZXZpY2UJCWFoYgkJIyBFSVNBIEFI QTE3NDIgZmFtaWx5CmRldmljZQkJYWhjCQkjIEFIQTI5NDAgYW5kIG9uYm9hcmQgQUlDN3h4eCBk ZXZpY2VzCiNkZXZpY2UJCWFoZAkJIyBBSEEzOTMyMC8yOTMyMCBhbmQgb25ib2FyZCBBSUM3OXh4 IGRldmljZXMKI2RldmljZQkJYW1kCQkjIEFNRCA1M0M5NzQgKFRla3JhbSBEQy0zOTAoVCkpCiNk ZXZpY2UJCWlzcAkJIyBRbG9naWMgZmFtaWx5CiNkZXZpY2UJCW1wdAkJIyBMU0ktTG9naWMgTVBU LUZ1c2lvbgojZGV2aWNlCQluY3IJCSMgTkNSL1N5bWJpb3MgTG9naWMKZGV2aWNlCQlzeW0JCSMg TkNSL1N5bWJpb3MgTG9naWMgKG5ld2VyIGNoaXBzZXRzICsgdGhvc2Ugb2YgYG5jcicpCiNkZXZp Y2UJCXRybQkJIyBUZWtyYW0gREMzOTVVL1VXL0YgREMzMTVVIGFkYXB0ZXJzCgojZGV2aWNlCQlh ZHYJCSMgQWR2YW5zeXMgU0NTSSBhZGFwdGVycwojZGV2aWNlCQlhZHcJCSMgQWR2YW5zeXMgd2lk ZSBTQ1NJIGFkYXB0ZXJzCiNkZXZpY2UJCWFoYQkJIyBBZGFwdGVjIDE1NHggU0NTSSBhZGFwdGVy cwojZGV2aWNlCQlhaWMJCSMgQWRhcHRlYyAxNVswMTJdeCBTQ1NJIGFkYXB0ZXJzLCBBSUMtNlsy M102MC4KI2RldmljZQkJYnQJCSMgQnVzbG9naWMvTXlsZXggTXVsdGlNYXN0ZXIgU0NTSSBhZGFw dGVycwoKI2RldmljZQkJbmN2CQkjIE5DUiA1M0M1MDAKI2RldmljZQkJbnNwCQkjIFdvcmtiaXQg TmluamEgU0NTSS0zCiNkZXZpY2UJCXN0ZwkJIyBUTUMgMThDMzAvMThDNTAKCiMgU0NTSSBwZXJp cGhlcmFscwpkZXZpY2UJCXNjYnVzCQkjIFNDU0kgYnVzIChyZXF1aXJlZCBmb3IgU0NTSSkKI2Rl dmljZQkJY2gJCSMgU0NTSSBtZWRpYSBjaGFuZ2VycwpkZXZpY2UJCWRhCQkjIERpcmVjdCBBY2Nl c3MgKGRpc2tzKQpkZXZpY2UJCXNhCQkjIFNlcXVlbnRpYWwgQWNjZXNzICh0YXBlIGV0YykKZGV2 aWNlCQljZAkJIyBDRApkZXZpY2UJCXBhc3MJCSMgUGFzc3Rocm91Z2ggZGV2aWNlIChkaXJlY3Qg U0NTSSBhY2Nlc3MpCiNkZXZpY2UJCXNlcwkJIyBTQ1NJIEVudmlyb25tZW50YWwgU2VydmljZXMg KGFuZCBTQUYtVEUpCgojIFJBSUQgY29udHJvbGxlcnMgaW50ZXJmYWNlZCB0byB0aGUgU0NTSSBz dWJzeXN0ZW0KI2RldmljZQkJYW1yCQkjIEFNSSBNZWdhUkFJRAojZGV2aWNlCQlhc3IJCSMgRFBU IFNtYXJ0UkFJRCBWLCBWSSBhbmQgQWRhcHRlYyBTQ1NJIFJBSUQKI2RldmljZQkJY2lzcwkJIyBD b21wYXEgU21hcnQgUkFJRCA1KgojZGV2aWNlCQlkcHQJCSMgRFBUIFNtYXJ0Y2FjaGUgSUlJLCBJ ViAtIFNlZSBOT1RFUyBmb3Igb3B0aW9ucwojZGV2aWNlCQlpaXIJCSMgSW50ZWwgSW50ZWdyYXRl ZCBSQUlECiNkZXZpY2UJCWlwcwkJIyBJQk0gKEFkYXB0ZWMpIFNlcnZlUkFJRAojZGV2aWNlCQlt bHkJCSMgTXlsZXggQWNjZWxlUkFJRC9lWHRyZW1lUkFJRAojZGV2aWNlCQl0d2EJCSMgM3dhcmUg OTAwMCBzZXJpZXMgUEFUQS9TQVRBIFJBSUQKCiMgUkFJRCBjb250cm9sbGVycwojZGV2aWNlCQlh YWMJCSMgQWRhcHRlYyBGU0EgUkFJRAojZGV2aWNlCQlhYWNwCQkjIFNDU0kgcGFzc3Rocm91Z2gg Zm9yIGFhYyAocmVxdWlyZXMgQ0FNKQojZGV2aWNlCQlpZGEJCSMgQ29tcGFxIFNtYXJ0IFJBSUQK I2RldmljZQkJbWx4CQkjIE15bGV4IERBQzk2MCBmYW1pbHkKI2RldmljZQkJcHN0CQkjIFByb21p c2UgU3VwZXJ0cmFrIFNYNjAwMAojZGV2aWNlCQl0d2UJCSMgM3dhcmUgQVRBIFJBSUQKCiMgYXRr YmRjMCBjb250cm9scyBib3RoIHRoZSBrZXlib2FyZCBhbmQgdGhlIFBTLzIgbW91c2UKZGV2aWNl CQlhdGtiZGMJCSMgQVQga2V5Ym9hcmQgY29udHJvbGxlcgpkZXZpY2UJCWF0a2JkCQkjIEFUIGtl eWJvYXJkCiNkZXZpY2UJCXBzbQkJIyBQUy8yIG1vdXNlCgpkZXZpY2UJCXZnYQkJIyBWR0Egdmlk ZW8gY2FyZCBkcml2ZXIKCmRldmljZQkJc3BsYXNoCQkjIFNwbGFzaCBzY3JlZW4gYW5kIHNjcmVl biBzYXZlciBzdXBwb3J0CgojIHN5c2NvbnMgaXMgdGhlIGRlZmF1bHQgY29uc29sZSBkcml2ZXIs IHJlc2VtYmxpbmcgYW4gU0NPIGNvbnNvbGUKZGV2aWNlCQlzYwoKIyBFbmFibGUgdGhpcyBmb3Ig dGhlIHBjdnQgKFZUMjIwIGNvbXBhdGlibGUpIGNvbnNvbGUgZHJpdmVyCiNkZXZpY2UJCXZ0CiNv cHRpb25zIAlYU0VSVkVSCQkjIHN1cHBvcnQgZm9yIFggc2VydmVyIG9uIGEgdnQgY29uc29sZQoj b3B0aW9ucyAJRkFUX0NVUlNPUgkjIHN0YXJ0IHdpdGggYmxvY2sgY3Vyc29yCgpkZXZpY2UJCWFn cAkJIyBzdXBwb3J0IHNldmVyYWwgQUdQIGNoaXBzZXRzCgojIEZsb2F0aW5nIHBvaW50IHN1cHBv cnQgLSBkbyBub3QgZGlzYWJsZS4KZGV2aWNlCQlucHgKCiMgUG93ZXIgbWFuYWdlbWVudCBzdXBw b3J0IChzZWUgTk9URVMgZm9yIG1vcmUgb3B0aW9ucykKI2RldmljZQkJYXBtCiMgQWRkIHN1c3Bl bmQvcmVzdW1lIHN1cHBvcnQgZm9yIHRoZSBpODI1NC4KI2RldmljZQkJcG10aW1lcgoKIyBQQ0NB UkQgKFBDTUNJQSkgc3VwcG9ydAojIFBDTUNJQSBhbmQgY2FyZGJ1cyBicmlkZ2Ugc3VwcG9ydAoj ZGV2aWNlCQljYmIJCSMgY2FyZGJ1cyAoeWVudGEpIGJyaWRnZQojZGV2aWNlCQlwY2NhcmQJCSMg UEMgQ2FyZCAoMTYtYml0KSBidXMKI2RldmljZQkJY2FyZGJ1cwkJIyBDYXJkQnVzICgzMi1iaXQp IGJ1cwoKIyBTZXJpYWwgKENPTSkgcG9ydHMKZGV2aWNlCQlzaW8JCSMgODI1MCwgMTZbNDVdNTAg YmFzZWQgc2VyaWFsIHBvcnRzCgojIFBhcmFsbGVsIHBvcnQKI2RldmljZQkJcHBjCiNkZXZpY2UJ CXBwYnVzCQkjIFBhcmFsbGVsIHBvcnQgYnVzIChyZXF1aXJlZCkKI2RldmljZQkJbHB0CQkjIFBy aW50ZXIKI2RldmljZQkJcGxpcAkJIyBUQ1AvSVAgb3ZlciBwYXJhbGxlbAojZGV2aWNlCQlwcGkJ CSMgUGFyYWxsZWwgcG9ydCBpbnRlcmZhY2UgZGV2aWNlCiNkZXZpY2UJCXZwbwkJIyBSZXF1aXJl cyBzY2J1cyBhbmQgZGEKCiMgSWYgeW91J3ZlIGdvdCBhICJkdW1iIiBzZXJpYWwgb3IgcGFyYWxs ZWwgUENJIGNhcmQgdGhhdCBpcwojIHN1cHBvcnRlZCBieSB0aGUgcHVjKDQpIGdsdWUgZHJpdmVy LCB1bmNvbW1lbnQgdGhlIGZvbGxvd2luZwojIGxpbmUgdG8gZW5hYmxlIGl0IChjb25uZWN0cyB0 byB0aGUgc2lvIGFuZC9vciBwcGMgZHJpdmVycyk6CiNkZXZpY2UJCXB1YwoKIyBQQ0kgRXRoZXJu ZXQgTklDcy4KI2RldmljZQkJZGUJCSMgREVDL0ludGVsIERDMjF4NHggKGBgVHVsaXAnJykKI2Rl dmljZQkJZW0JCSMgSW50ZWwgUFJPLzEwMDAgYWRhcHRlciBHaWdhYml0IEV0aGVybmV0IENhcmQK I2RldmljZQkJaXhnYgkJIyBJbnRlbCBQUk8vMTBHYkUgRXRoZXJuZXQgQ2FyZAojZGV2aWNlCQl0 eHAJCSMgM0NvbSAzY1I5OTAgKGBgVHlwaG9vbicnKQojZGV2aWNlCQl2eAkJIyAzQ29tIDNjNTkw LCAzYzU5NSAoYGBWb3J0ZXgnJykKCiMgUENJIEV0aGVybmV0IE5JQ3MgdGhhdCB1c2UgdGhlIGNv bW1vbiBNSUkgYnVzIGNvbnRyb2xsZXIgY29kZS4KIyBOT1RFOiBCZSBzdXJlIHRvIGtlZXAgdGhl ICdkZXZpY2UgbWlpYnVzJyBsaW5lIGluIG9yZGVyIHRvIHVzZSB0aGVzZSBOSUNzIQpkZXZpY2UJ CW1paWJ1cwkJIyBNSUkgYnVzIHN1cHBvcnQKI2RldmljZQkJYmZlCQkjIEJyb2FkY29tIEJDTTQ0 MHggMTAvMTAwIEV0aGVybmV0CiNkZXZpY2UJCWJnZQkJIyBCcm9hZGNvbSBCQ001NzB4eCBHaWdh Yml0IEV0aGVybmV0CiNkZXZpY2UJCWRjCQkjIERFQy9JbnRlbCAyMTE0MyBhbmQgdmFyaW91cyB3 b3JrYWxpa2VzCiNkZXZpY2UJCWZ4cAkJIyBJbnRlbCBFdGhlckV4cHJlc3MgUFJPLzEwMEIgKDgy NTU3LCA4MjU1OCkKI2RldmljZQkJcGNuCQkjIEFNRCBBbTc5Qzk3eCBQQ0kgMTAvMTAwIChwcmVj ZWRlbmNlIG92ZXIgJ2xuYycpCiNkZXZpY2UJCXJlCQkjIFJlYWxUZWsgODEzOUMrLzgxNjkvODE2 OVMvODExMFMKI2RldmljZQkJcmwJCSMgUmVhbFRlayA4MTI5LzgxMzkKI2RldmljZQkJc2YJCSMg QWRhcHRlYyBBSUMtNjkxNSAoYGBTdGFyZmlyZScnKQojZGV2aWNlCQlzaXMJCSMgU2lsaWNvbiBJ bnRlZ3JhdGVkIFN5c3RlbXMgU2lTIDkwMC9TaVMgNzAxNgojZGV2aWNlCQlzawkJIyBTeXNLb25u ZWN0IFNLLTk4NHggJiBTSy05ODJ4IGdpZ2FiaXQgRXRoZXJuZXQKI2RldmljZQkJc3RlCQkjIFN1 bmRhbmNlIFNUMjAxIChELUxpbmsgREZFLTU1MFRYKQojZGV2aWNlCQl0aQkJIyBBbHRlb24gTmV0 d29ya3MgVGlnb24gSS9JSSBnaWdhYml0IEV0aGVybmV0CiNkZXZpY2UJCXRsCQkjIFRleGFzIElu c3RydW1lbnRzIFRodW5kZXJMQU4KI2RldmljZQkJdHgJCSMgU01DIEV0aGVyUG93ZXIgSUkgKDgz YzE3MCBgYEVQSUMnJykKI2RldmljZQkJdnIJCSMgVklBIFJoaW5lLCBSaGluZSBJSQojZGV2aWNl CQl3YgkJIyBXaW5ib25kIFc4OUM4NDBGCmRldmljZQkJeGwJCSMgM0NvbSAzYzkweCAoYGBCb29t ZXJhbmcnJywgYGBDeWNsb25lJycpCgojIElTQSBFdGhlcm5ldCBOSUNzLiAgcGNjYXJkIE5JQ3Mg aW5jbHVkZWQuCiNkZXZpY2UJCWNzCQkjIENyeXN0YWwgU2VtaWNvbmR1Y3RvciBDUzg5eDAgTklD CiMgJ2RldmljZSBlZCcgcmVxdWlyZXMgJ2RldmljZSBtaWlidXMnCiNkZXZpY2UJCWVkCQkjIE5F WzEyXTAwMCwgU01DIFVsdHJhLCAzYzUwMywgRFM4MzkwIGNhcmRzCiNkZXZpY2UJCWV4CQkjIElu dGVsIEV0aGVyRXhwcmVzcyBQcm8vMTAgYW5kIFByby8xMCsKI2RldmljZQkJZXAJCSMgRXRoZXJs aW5rIElJSSBiYXNlZCBjYXJkcwojZGV2aWNlCQlmZQkJIyBGdWppdHN1IE1CODY5NnggYmFzZWQg Y2FyZHMKI2RldmljZQkJaWUJCSMgRXRoZXJFeHByZXNzIDgvMTYsIDNDNTA3LCBTdGFyTEFOIDEw IGV0Yy4KI2RldmljZQkJbG5jCQkjIE5FMjEwMCwgTkUzMi1WTCBMYW5jZSBFdGhlcm5ldCBjYXJk cwojZGV2aWNlCQlzbgkJIyBTTUMncyA5MDAwIHNlcmllcyBvZiBFdGhlcm5ldCBjaGlwcwojZGV2 aWNlCQl4ZQkJIyBYaXJjb20gcGNjYXJkIEV0aGVybmV0CgojIElTQSBkZXZpY2VzIHRoYXQgdXNl IHRoZSBvbGQgSVNBIHNoaW1zCiNkZXZpY2UJCWxlCgojIFdpcmVsZXNzIE5JQyBjYXJkcwojZGV2 aWNlCQl3bGFuCQkjIDgwMi4xMSBzdXBwb3J0CiNkZXZpY2UJCWFuCQkjIEFpcm9uZXQgNDUwMC80 ODAwIDgwMi4xMSB3aXJlbGVzcyBOSUNzLgojZGV2aWNlCQlhd2kJCSMgQmF5U3RhY2sgNjYwIGFu ZCBvdGhlcnMKI2RldmljZQkJd2kJCSMgV2F2ZUxBTi9JbnRlcnNpbC9TeW1ib2wgODAyLjExIHdp cmVsZXNzIE5JQ3MuCiNkZXZpY2UJCXdsCQkjIE9sZGVyIG5vbiA4MDIuMTEgV2F2ZWxhbiB3aXJl bGVzcyBOSUMuCgojIFBzZXVkbyBkZXZpY2VzLgpkZXZpY2UJCWxvb3AJCSMgTmV0d29yayBsb29w YmFjawpkZXZpY2UJCW1lbQkJIyBNZW1vcnkgYW5kIGtlcm5lbCBtZW1vcnkgZGV2aWNlcwpkZXZp Y2UJCWlvCQkjIEkvTyBkZXZpY2UKZGV2aWNlCQlyYW5kb20JCSMgRW50cm9weSBkZXZpY2UKZGV2 aWNlCQlldGhlcgkJIyBFdGhlcm5ldCBzdXBwb3J0CiNkZXZpY2UJCXNsCQkjIEtlcm5lbCBTTElQ CiNkZXZpY2UJCXBwcAkJIyBLZXJuZWwgUFBQCiNkZXZpY2UJCXR1bgkJIyBQYWNrZXQgdHVubmVs LgpkZXZpY2UJCXB0eQkJIyBQc2V1ZG8tdHR5cyAodGVsbmV0IGV0YykKZGV2aWNlCQltZAkJIyBN ZW1vcnkgImRpc2tzIgojZGV2aWNlCQlnaWYJCSMgSVB2NiBhbmQgSVB2NCB0dW5uZWxpbmcKI2Rl dmljZQkJZmFpdGgJCSMgSVB2Ni10by1JUHY0IHJlbGF5aW5nICh0cmFuc2xhdGlvbikKCiMgVGhl IGBicGYnIGRldmljZSBlbmFibGVzIHRoZSBCZXJrZWxleSBQYWNrZXQgRmlsdGVyLgojIEJlIGF3 YXJlIG9mIHRoZSBhZG1pbmlzdHJhdGl2ZSBjb25zZXF1ZW5jZXMgb2YgZW5hYmxpbmcgdGhpcyEK ZGV2aWNlCQlicGYJCSMgQmVya2VsZXkgcGFja2V0IGZpbHRlcgoKIyBVU0Igc3VwcG9ydAojZGV2 aWNlCQl1aGNpCQkjIFVIQ0kgUENJLT5VU0IgaW50ZXJmYWNlCiNkZXZpY2UJCW9oY2kJCSMgT0hD SSBQQ0ktPlVTQiBpbnRlcmZhY2UKI2RldmljZQkJdXNiCQkjIFVTQiBCdXMgKHJlcXVpcmVkKQoj ZGV2aWNlCQl1ZGJwCQkjIFVTQiBEb3VibGUgQnVsayBQaXBlIGRldmljZXMKI2RldmljZQkJdWdl bgkJIyBHZW5lcmljCiNkZXZpY2UJCXVoaWQJCSMgIkh1bWFuIEludGVyZmFjZSBEZXZpY2VzIgoj ZGV2aWNlCQl1a2JkCQkjIEtleWJvYXJkCiNkZXZpY2UJCXVscHQJCSMgUHJpbnRlcgojZGV2aWNl CQl1bWFzcwkJIyBEaXNrcy9NYXNzIHN0b3JhZ2UgLSBSZXF1aXJlcyBzY2J1cyBhbmQgZGEKI2Rl dmljZQkJdW1zCQkjIE1vdXNlCiNkZXZpY2UJCXVyaW8JCSMgRGlhbW9uZCBSaW8gNTAwIE1QMyBw bGF5ZXIKI2RldmljZQkJdXNjYW5uZXIJIyBTY2FubmVycwojIFVTQiBFdGhlcm5ldCwgcmVxdWly ZXMgbWlpCiNkZXZpY2UJCWF1ZQkJIyBBRE10ZWsgVVNCIEV0aGVybmV0CiNkZXZpY2UJCWF4ZQkJ IyBBU0lYIEVsZWN0cm9uaWNzIFVTQiBFdGhlcm5ldAojZGV2aWNlCQljdWUJCSMgQ0FUQyBVU0Ig RXRoZXJuZXQKI2RldmljZQkJa3VlCQkjIEthd2FzYWtpIExTSSBVU0IgRXRoZXJuZXQKI2Rldmlj ZQkJcnVlCQkjIFJlYWxUZWsgUlRMODE1MCBVU0IgRXRoZXJuZXQKCiMgRmlyZVdpcmUgc3VwcG9y dAojZGV2aWNlCQlmaXJld2lyZQkjIEZpcmVXaXJlIGJ1cyBjb2RlCiNkZXZpY2UJCXNicAkJIyBT Q1NJIG92ZXIgRmlyZVdpcmUgKFJlcXVpcmVzIHNjYnVzIGFuZCBkYSkKI2RldmljZQkJZndlCQkj IEV0aGVybmV0IG92ZXIgRmlyZVdpcmUgKG5vbi1zdGFuZGFyZCEpCgpkZXZpY2UJCXNtYgpkZXZp Y2UJCXNtYnVzCmRldmljZQkJaW50cG0KZGV2aWNlCQlhdGFwaWNhbQoK --Multipart=_Sun__29_Aug_2004_15_59_45_+0200_b4ptC/ltohPxY+v6 Content-Type: application/octet-stream; name="NUDEL.bak" Content-Disposition: attachment; filename="NUDEL.bak" Content-Transfer-Encoding: base64 IwojIEdFTkVSSUMgLS0gR2VuZXJpYyBrZXJuZWwgY29uZmlndXJhdGlvbiBmaWxlIGZvciBGcmVl QlNEL2kzODYKIwojIEZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHRoaXMgZmlsZSwgcGxlYXNlIHJl YWQgdGhlIGhhbmRib29rIHNlY3Rpb24gb24KIyBLZXJuZWwgQ29uZmlndXJhdGlvbiBGaWxlczoK IwojICAgIGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcvZG9jL2VuX1VTLklTTzg4NTktMS9ib29rcy9o YW5kYm9vay9rZXJuZWxjb25maWctY29uZmlnLmh0bWwKIwojIFRoZSBoYW5kYm9vayBpcyBhbHNv IGF2YWlsYWJsZSBsb2NhbGx5IGluIC91c3Ivc2hhcmUvZG9jL2hhbmRib29rCiMgaWYgeW91J3Zl IGluc3RhbGxlZCB0aGUgZG9jIGRpc3RyaWJ1dGlvbiwgb3RoZXJ3aXNlIGFsd2F5cyBzZWUgdGhl CiMgRnJlZUJTRCBXb3JsZCBXaWRlIFdlYiBzZXJ2ZXIgKGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcv KSBmb3IgdGhlCiMgbGF0ZXN0IGluZm9ybWF0aW9uLgojCiMgQW4gZXhoYXVzdGl2ZSBsaXN0IG9m IG9wdGlvbnMgYW5kIG1vcmUgZGV0YWlsZWQgZXhwbGFuYXRpb25zIG9mIHRoZQojIGRldmljZSBs aW5lcyBpcyBhbHNvIHByZXNlbnQgaW4gdGhlIC4uLy4uL2NvbmYvTk9URVMgYW5kIE5PVEVTIGZp bGVzLiAKIyBJZiB5b3UgYXJlIGluIGRvdWJ0IGFzIHRvIHRoZSBwdXJwb3NlIG9yIG5lY2Vzc2l0 eSBvZiBhIGxpbmUsIGNoZWNrIGZpcnN0IAojIGluIE5PVEVTLgojCiMgJEZyZWVCU0Q6IHNyYy9z eXMvaTM4Ni9jb25mL0dFTkVSSUMsdiAxLjM2OS4yLjIgMjAwMi8xMi8zMSAwNTozNTo0NSBzY290 dGwgRXhwICQKCm1hY2hpbmUJCWkzODYKI2NwdQkJSTQ4Nl9DUFUKI2NwdQkJSTU4Nl9DUFUKY3B1 CQlJNjg2X0NQVQppZGVudAkJTlVERUwKbWF4dXNlcnMJMAoKI1RvIHN0YXRpY2FsbHkgY29tcGls ZSBpbiBkZXZpY2Ugd2lyaW5nIGluc3RlYWQgb2YgL2Jvb3QvZGV2aWNlLmhpbnRzCmhpbnRzCQki TlVERUwuaGludHMiCQkjRGVmYXVsdCBwbGFjZXMgdG8gbG9vayBmb3IgZGV2aWNlcy4KCm1ha2Vv cHRpb25zCURFQlVHPS1nCQkjQnVpbGQga2VybmVsIHdpdGggZ2RiKDEpIGRlYnVnIHN5bWJvbHMK Cm9wdGlvbnMJCVNDSEVEXzRCU0QKb3B0aW9ucyAJSU5FVAkJCSNJbnRlck5FVHdvcmtpbmcKb3B0 aW9ucyAJSU5FVDYJCQkjSVB2NiBjb21tdW5pY2F0aW9ucyBwcm90b2NvbHMKb3B0aW9ucyAJRkZT CQkJI0JlcmtlbGV5IEZhc3QgRmlsZXN5c3RlbQpvcHRpb25zIAlTT0ZUVVBEQVRFUwkJI0VuYWJs ZSBGRlMgc29mdCB1cGRhdGVzIHN1cHBvcnQKb3B0aW9ucyAJVUZTX0FDTAkJCSNTdXBwb3J0IGZv ciBhY2Nlc3MgY29udHJvbCBsaXN0cwpvcHRpb25zIAlVRlNfRElSSEFTSAkJI0ltcHJvdmUgcGVy Zm9ybWFuY2Ugb24gYmlnIGRpcmVjdG9yaWVzCm9wdGlvbnMgCU1EX1JPT1QJCQkjTUQgaXMgYSBw b3RlbnRpYWwgcm9vdCBkZXZpY2UKb3B0aW9ucyAJTkZTQ0xJRU5UCQkjTmV0d29yayBGaWxlc3lz dGVtIENsaWVudApvcHRpb25zIAlORlNTRVJWRVIJCSNOZXR3b3JrIEZpbGVzeXN0ZW0gU2VydmVy Cm9wdGlvbnMgCU5GU19ST09UCQkjTkZTIHVzYWJsZSBhcyByb290IGRldmljZSwgcmVxdWlyZXMg TkZTQ0xJRU5UCm9wdGlvbnMgCU1TRE9TRlMJCQkjTVNET1MgRmlsZXN5c3RlbQpvcHRpb25zIAlD RDk2NjAJCQkjSVNPIDk2NjAgRmlsZXN5c3RlbQpvcHRpb25zIAlQUk9DRlMJCQkjUHJvY2VzcyBm aWxlc3lzdGVtIChyZXF1aXJlcyBQU0VVRE9GUykKb3B0aW9ucyAJUFNFVURPRlMJCSNQc2V1ZG8t ZmlsZXN5c3RlbSBmcmFtZXdvcmsKb3B0aW9ucyAJQ09NUEFUXzQzCQkjQ29tcGF0aWJsZSB3aXRo IEJTRCA0LjMgW0tFRVAgVEhJUyFdCm9wdGlvbnMgCUNPTVBBVF9GUkVFQlNENAkJI0NvbXBhdGli bGUgd2l0aCBGcmVlQlNENApvcHRpb25zIAlTQ1NJX0RFTEFZPTIwMDAJI0RlbGF5IChpbiBtcykg YmVmb3JlIHByb2JpbmcgU0NTSQpvcHRpb25zIAlLVFJBQ0UJCQkja3RyYWNlKDEpIHN1cHBvcnQK b3B0aW9ucyAJU1lTVlNITQkJCSNTWVNWLXN0eWxlIHNoYXJlZCBtZW1vcnkKb3B0aW9ucyAJU1lT Vk1TRwkJCSNTWVNWLXN0eWxlIG1lc3NhZ2UgcXVldWVzCm9wdGlvbnMgCVNZU1ZTRU0JCQkjU1lT Vi1zdHlsZSBzZW1hcGhvcmVzCm9wdGlvbnMgCV9LUE9TSVhfUFJJT1JJVFlfU0NIRURVTElORyAj UG9zaXggUDEwMDNfMUIgcmVhbC10aW1lIGV4dGVuc2lvbnMKb3B0aW9ucyAJS0JEX0lOU1RBTExf Q0RFVgkjIGluc3RhbGwgYSBDREVWIGVudHJ5IGluIC9kZXYKb3B0aW9ucyAJQUhDX1JFR19QUkVU VFlfUFJJTlQJIyBQcmludCByZWdpc3RlciBiaXRmaWVsZHMgaW4gZGVidWcKCQkJCQkjIG91dHB1 dC4gIEFkZHMgfjEyOGsgdG8gZHJpdmVyLgpvcHRpb25zIAlBSERfUkVHX1BSRVRUWV9QUklOVAkj IFByaW50IHJlZ2lzdGVyIGJpdGZpZWxkcyBpbiBkZWJ1ZwoJCQkJCSMgb3V0cHV0LiAgQWRkcyB+ MjE1ayB0byBkcml2ZXIuCgojIERlYnVnZ2luZyBmb3IgdXNlIGluIC1jdXJyZW50CiNvcHRpb25z CQlLREIKI29wdGlvbnMgCUREQgkJCSNFbmFibGUgdGhlIGtlcm5lbCBkZWJ1Z2dlcgojb3B0aW9u cyAJSU5WQVJJQU5UUwkJI0VuYWJsZSBjYWxscyBvZiBleHRyYSBzYW5pdHkgY2hlY2tpbmcKI29w dGlvbnMgCUlOVkFSSUFOVF9TVVBQT1JUCSNFeHRyYSBzYW5pdHkgY2hlY2tzIG9mIGludGVybmFs IHN0cnVjdHVyZXMsIHJlcXVpcmVkIGJ5IElOVkFSSUFOVFMKI29wdGlvbnMgCVdJVE5FU1MJCQkj RW5hYmxlIGNoZWNrcyB0byBkZXRlY3QgZGVhZGxvY2tzIGFuZCBjeWNsZXMKI29wdGlvbnMgCVdJ VE5FU1NfU0tJUFNQSU4JI0Rvbid0IHJ1biB3aXRuZXNzIG9uIHNwaW5sb2NrcyBmb3Igc3BlZWQK CiMgVG8gbWFrZSBhbiBTTVAga2VybmVsLCB0aGUgbmV4dCB0d28gYXJlIG5lZWRlZApvcHRpb25z IAlTTVAJCQkjIFN5bW1ldHJpYyBNdWx0aVByb2Nlc3NvciBLZXJuZWwKZGV2aWNlICAgICAgICAg IGFwaWMgICAgICAgICAgICAgICAgICAgICMgSS9PIEFQSUMKCmRldmljZQkJaXNhCiNkZXZpY2UJ CWVpc2EKZGV2aWNlCQlwY2kKCiMgRmxvcHB5IGRyaXZlcwpkZXZpY2UJCWZkYwoKIyBBVEEgYW5k IEFUQVBJIGRldmljZXMKZGV2aWNlCQlhdGEKZGV2aWNlCQlhdGFkaXNrCQkJIyBBVEEgZGlzayBk cml2ZXMKZGV2aWNlCQlhdGFwaWNkCQkJIyBBVEFQSSBDRFJPTSBkcml2ZXMKZGV2aWNlCQlhdGFw aWZkCQkJIyBBVEFQSSBmbG9wcHkgZHJpdmVzCiNkZXZpY2UJCWF0YXBpc3QJCQkjIEFUQVBJIHRh cGUgZHJpdmVzCm9wdGlvbnMgCUFUQV9TVEFUSUNfSUQJCSNTdGF0aWMgZGV2aWNlIG51bWJlcmlu ZwoKIyBTQ1NJIENvbnRyb2xsZXJzCiNkZXZpY2UJCWFoYgkJIyBFSVNBIEFIQTE3NDIgZmFtaWx5 CmRldmljZQkJYWhjCQkjIEFIQTI5NDAgYW5kIG9uYm9hcmQgQUlDN3h4eCBkZXZpY2VzCiNkZXZp Y2UJCWFoZAkJIyBBSEEzOTMyMC8yOTMyMCBhbmQgb25ib2FyZCBBSUM3OXh4IGRldmljZXMKI2Rl dmljZQkJYW1kCQkjIEFNRCA1M0M5NzQgKFRla3JhbSBEQy0zOTAoVCkpCiNkZXZpY2UJCWlzcAkJ IyBRbG9naWMgZmFtaWx5CiNkZXZpY2UJCW1wdAkJIyBMU0ktTG9naWMgTVBULUZ1c2lvbgojZGV2 aWNlCQluY3IJCSMgTkNSL1N5bWJpb3MgTG9naWMKZGV2aWNlCQlzeW0JCSMgTkNSL1N5bWJpb3Mg TG9naWMgKG5ld2VyIGNoaXBzZXRzICsgdGhvc2Ugb2YgYG5jcicpCgojZGV2aWNlCQlhZHYJCSMg QWR2YW5zeXMgU0NTSSBhZGFwdGVycwojZGV2aWNlCQlhZHcJCSMgQWR2YW5zeXMgd2lkZSBTQ1NJ IGFkYXB0ZXJzCiNkZXZpY2UJCWFoYQkJIyBBZGFwdGVjIDE1NHggU0NTSSBhZGFwdGVycwojZGV2 aWNlCQlhaWMJCSMgQWRhcHRlYyAxNVswMTJdeCBTQ1NJIGFkYXB0ZXJzLCBBSUMtNlsyM102MC4K I2RldmljZQkJYnQJCSMgQnVzbG9naWMvTXlsZXggTXVsdGlNYXN0ZXIgU0NTSSBhZGFwdGVycwoK I2RldmljZQkJbmN2CQkjIE5DUiA1M0M1MDAKI2RldmljZQkJbnNwCQkjIFdvcmtiaXQgTmluamEg U0NTSS0zCiNkZXZpY2UJCXN0ZwkJIyBUTUMgMThDMzAvMThDNTAKCiMgUkFJRCBjb250cm9sbGVy cyBpbnRlcmZhY2VkIHRvIHRoZSBTQ1NJIHN1YnN5c3RlbQojZGV2aWNlCQlhc3IJCSMgRFBUIFNt YXJ0UkFJRCBWLCBWSSBhbmQgQWRhcHRlYyBTQ1NJIFJBSUQKI2RldmljZQkJY2lzcwkJIyBDb21w YXEgU21hcnQgUkFJRCA1KgojZGV2aWNlCQlkcHQJCSMgRFBUIFNtYXJ0Y2FjaGUgSUlJLCBJViAt IFNlZSBOT1RFUyBmb3Igb3B0aW9ucyEKI2RldmljZQkJaWlyCQkjIEludGVsIEludGVncmF0ZWQg UkFJRAojZGV2aWNlCQltbHkJCSMgTXlsZXggQWNjZWxlUkFJRC9lWHRyZW1lUkFJRAoKIyBTQ1NJ IHBlcmlwaGVyYWxzCmRldmljZQkJc2NidXMJCSMgU0NTSSBidXMgKHJlcXVpcmVkKQojZGV2aWNl CQljaAkJIyBTQ1NJIG1lZGlhIGNoYW5nZXJzCmRldmljZQkJZGEJCSMgRGlyZWN0IEFjY2VzcyAo ZGlza3MpCmRldmljZQkJc2EJCSMgU2VxdWVudGlhbCBBY2Nlc3MgKHRhcGUgZXRjKQpkZXZpY2UJ CWNkCQkjIENECmRldmljZQkJcGFzcwkJIyBQYXNzdGhyb3VnaCBkZXZpY2UgKGRpcmVjdCBTQ1NJ IGFjY2VzcykKZGV2aWNlCQlzZXMJCSMgU0NTSSBFbnZpcm9ubWVudGFsIFNlcnZpY2VzIChhbmQg U0FGLVRFKQoKIyBSQUlEIGNvbnRyb2xsZXJzCiNkZXZpY2UJCWFhYwkJIyBBZGFwdGVjIEZTQSBS QUlECiNkZXZpY2UJCWFhY3AJCSMgU0NTSSBwYXNzdGhyb3VnaCBmb3IgYWFjIChyZXF1aXJlcyBD QU0pCiNkZXZpY2UJCWFtcgkJIyBBTUkgTWVnYVJBSUQKI2RldmljZQkJaWRhCQkjIENvbXBhcSBT bWFydCBSQUlECiNkZXZpY2UJCW1seAkJIyBNeWxleCBEQUM5NjAgZmFtaWx5CiNkZXZpY2UJCXBz dAkJIyBQcm9taXNlIFN1cGVydHJhayBTWDYwMDAKI2RldmljZQkJdHdlCQkjIDN3YXJlIEFUQSBS QUlECgojIGF0a2JkYzAgY29udHJvbHMgYm90aCB0aGUga2V5Ym9hcmQgYW5kIHRoZSBQUy8yIG1v dXNlCmRldmljZQkJYXRrYmRjCQkjIEFUIGtleWJvYXJkIGNvbnRyb2xsZXIKZGV2aWNlCQlhdGti ZAkJIyBBVCBrZXlib2FyZAojZGV2aWNlCQlwc20JCSMgUFMvMiBtb3VzZQoKZGV2aWNlCQl2Z2EJ CSMgVkdBIHZpZGVvIGNhcmQgZHJpdmVyCgpkZXZpY2UJCXNwbGFzaAkJIyBTcGxhc2ggc2NyZWVu IGFuZCBzY3JlZW4gc2F2ZXIgc3VwcG9ydAoKIyBzeXNjb25zIGlzIHRoZSBkZWZhdWx0IGNvbnNv bGUgZHJpdmVyLCByZXNlbWJsaW5nIGFuIFNDTyBjb25zb2xlCmRldmljZQkJc2MKCiMgRW5hYmxl IHRoaXMgZm9yIHRoZSBwY3Z0IChWVDIyMCBjb21wYXRpYmxlKSBjb25zb2xlIGRyaXZlcgojZGV2 aWNlCQl2dAojb3B0aW9ucyAJWFNFUlZFUgkJCSMgc3VwcG9ydCBmb3IgWCBzZXJ2ZXIgb24gYSB2 dCBjb25zb2xlCiNvcHRpb25zIAlGQVRfQ1VSU09SCQkjIHN0YXJ0IHdpdGggYmxvY2sgY3Vyc29y CgpkZXZpY2UJCWFncAkJIyBzdXBwb3J0IHNldmVyYWwgQUdQIGNoaXBzZXRzCgojIEZsb2F0aW5n IHBvaW50IHN1cHBvcnQgLSBkbyBub3QgZGlzYWJsZS4KZGV2aWNlCQlucHgKCiMgUG93ZXIgbWFu YWdlbWVudCBzdXBwb3J0IChzZWUgTk9URVMgZm9yIG1vcmUgb3B0aW9ucykKI2RldmljZQkJYXBt CiMgQWRkIHN1c3BlbmQvcmVzdW1lIHN1cHBvcnQgZm9yIHRoZSBpODI1NC4KZGV2aWNlCQlwbXRp bWVyCgojIFBDQ0FSRCAoUENNQ0lBKSBzdXBwb3J0CiMgUGNtY2lhIGFuZCBjYXJkYnVzIGJyaWRn ZSBzdXBwb3J0CiNkZXZpY2UJCWNiYgkJCSMgY2FyZGJ1cyAoeWVudGEpIGJyaWRnZQojZGV2aWNl CQlwY2ljCQkJIyBFeENBIElTQSBhbmQgUENJIGJyaWRnZXMKI2RldmljZQkJcGNjYXJkCQkJIyBQ QyBDYXJkICgxNi1iaXQpIGJ1cwojZGV2aWNlCQljYXJkYnVzCQkJIyBDYXJkQnVzICgzMi1iaXQp IGJ1cwoKIyBTZXJpYWwgKENPTSkgcG9ydHMKZGV2aWNlCQlzaW8JCSMgODI1MCwgMTZbNDVdNTAg YmFzZWQgc2VyaWFsIHBvcnRzCgojIFBhcmFsbGVsIHBvcnQKZGV2aWNlCQlwcGMKZGV2aWNlCQlw cGJ1cwkJIyBQYXJhbGxlbCBwb3J0IGJ1cyAocmVxdWlyZWQpCmRldmljZQkJbHB0CQkjIFByaW50 ZXIKI2RldmljZQkJcGxpcAkJIyBUQ1AvSVAgb3ZlciBwYXJhbGxlbAojZGV2aWNlCQlwcGkJCSMg UGFyYWxsZWwgcG9ydCBpbnRlcmZhY2UgZGV2aWNlCiNkZXZpY2UJCXZwbwkJIyBSZXF1aXJlcyBz Y2J1cyBhbmQgZGEKCgojIFBDSSBFdGhlcm5ldCBOSUNzLgojZGV2aWNlCQlkZQkJIyBERUMvSW50 ZWwgREMyMXg0eCAoYGBUdWxpcCcnKQojZGV2aWNlCQllbQkJIyBJbnRlbCBQUk8vMTAwMCBhZGFw dGVyIEdpZ2FiaXQgRXRoZXJuZXQgQ2FyZAojZGV2aWNlCQl0eHAJCSMgM0NvbSAzY1I5OTAgKGBg VHlwaG9vbicnKQojZGV2aWNlCQl2eAkJIyAzQ29tIDNjNTkwLCAzYzU5NSAoYGBWb3J0ZXgnJykK CiMgUENJIEV0aGVybmV0IE5JQ3MgdGhhdCB1c2UgdGhlIGNvbW1vbiBNSUkgYnVzIGNvbnRyb2xs ZXIgY29kZS4KIyBOT1RFOiBCZSBzdXJlIHRvIGtlZXAgdGhlICdkZXZpY2UgbWlpYnVzJyBsaW5l IGluIG9yZGVyIHRvIHVzZSB0aGVzZSBOSUNzIQpkZXZpY2UJCW1paWJ1cwkJIyBNSUkgYnVzIHN1 cHBvcnQKI2RldmljZQkJZGMJCSMgREVDL0ludGVsIDIxMTQzIGFuZCB2YXJpb3VzIHdvcmthbGlr ZXMKZGV2aWNlCQlmeHAJCSMgSW50ZWwgRXRoZXJFeHByZXNzIFBSTy8xMDBCICg4MjU1NywgODI1 NTgpCiNkZXZpY2UJCXBjbgkJIyBBTUQgQW03OUM5N3ggUENJIDEwLzEwMCAocHJlY2VkZW5jZSBv dmVyICdsbmMnKQojZGV2aWNlCQlybAkJIyBSZWFsVGVrIDgxMjkvODEzOQojZGV2aWNlCQlzZgkJ IyBBZGFwdGVjIEFJQy02OTE1IChgYFN0YXJmaXJlJycpCiNkZXZpY2UJCXNpcwkJIyBTaWxpY29u IEludGVncmF0ZWQgU3lzdGVtcyBTaVMgOTAwL1NpUyA3MDE2CiNkZXZpY2UJCXN0ZQkJIyBTdW5k YW5jZSBTVDIwMSAoRC1MaW5rIERGRS01NTBUWCkKI2RldmljZQkJdGwJCSMgVGV4YXMgSW5zdHJ1 bWVudHMgVGh1bmRlckxBTgojZGV2aWNlCQl0eAkJIyBTTUMgRXRoZXJQb3dlciBJSSAoODNjMTcw IGBgRVBJQycnKQojZGV2aWNlCQl2cgkJIyBWSUEgUmhpbmUsIFJoaW5lIElJCiNkZXZpY2UJCXdi CQkjIFdpbmJvbmQgVzg5Qzg0MEYKI2RldmljZQkJeGwJCSMgM0NvbSAzYzkweCAoYGBCb29tZXJh bmcnJywgYGBDeWNsb25lJycpCiNkZXZpY2UJCWJnZQkJIyBCcm9hZGNvbSBCQ001NzB4eCBHaWdh Yml0IEV0aGVybmV0CgojIElTQSBFdGhlcm5ldCBOSUNzLiAgcGNjYXJkIG5pY3MgaW5jbHVkZWQu CiNkZXZpY2UJCWNzCQkjIENyeXN0YWwgU2VtaWNvbmR1Y3RvciBDUzg5eDAgTklDCiMgJ2Rldmlj ZSBlZCcgcmVxdWlyZXMgJ2RldmljZSBtaWlidXMnCiNkZXZpY2UJCWVkCQkjIE5FWzEyXTAwMCwg U01DIFVsdHJhLCAzYzUwMywgRFM4MzkwIGNhcmRzCiNkZXZpY2UJCWV4CQkjIEludGVsIEV0aGVy RXhwcmVzcyBQcm8vMTAgYW5kIFByby8xMCsKI2RldmljZQkJZXAJCSMgRXRoZXJsaW5rIElJSSBi YXNlZCBjYXJkcwojZGV2aWNlCQlmZQkJIyBGdWppdHN1IE1CODY5NnggYmFzZWQgY2FyZHMKI2Rl dmljZQkJbG5jCQkjIE5FMjEwMCwgTkUzMi1WTCBMYW5jZSBFdGhlcm5ldCBjYXJkcwojZGV2aWNl CQlzbgkJIyBTTUMncyA5MDAwIHNlcmllcyBvZiBldGhlcm5ldCBjaGlwcwojZGV2aWNlCQl4ZQkJ IyBYaXJjb20gcGNjYXJkIGV0aGVybmV0CgojIElTQSBkZXZpY2VzIHRoYXQgdXNlIHRoZSBvbGQg SVNBIHNoaW1zCiNkZXZpY2UJCWxlCgojIFdpcmVsZXNzIE5JQyBjYXJkcwojZGV2aWNlCQlhbgkJ IyBBaXJvbmV0IDQ1MDAvNDgwMCA4MDIuMTEgd2lyZWxlc3MgTklDcy4gCiNkZXZpY2UJCWF3aQkJ IyBCYXlTdGFjayA2NjAgYW5kIG90aGVycwojZGV2aWNlCQl3aQkJIyBXYXZlTEFOL0ludGVyc2ls L1N5bWJvbCA4MDIuMTEgd2lyZWxlc3MgTklDcy4KI2RldmljZQkJd2wJCSMgT2xkZXIgbm9uIDgw Mi4xMSBXYXZlbGFuIHdpcmVsZXNzIE5JQy4KCiMgUHNldWRvIGRldmljZXMgLSB0aGUgbnVtYmVy IGluZGljYXRlcyBob3cgbWFueSB1bml0cyB0byBhbGxvY2F0ZS4KZGV2aWNlCQlyYW5kb20JCSMg RW50cm9weSBkZXZpY2UKZGV2aWNlCQlsb29wCQkjIE5ldHdvcmsgbG9vcGJhY2sKZGV2aWNlCQll dGhlcgkJIyBFdGhlcm5ldCBzdXBwb3J0CiNkZXZpY2UJCXNsCQkjIEtlcm5lbCBTTElQCiNkZXZp Y2UJCXBwcAkJIyBLZXJuZWwgUFBQCiNkZXZpY2UJCXR1bgkJIyBQYWNrZXQgdHVubmVsLgpkZXZp Y2UJCXB0eQkJIyBQc2V1ZG8tdHR5cyAodGVsbmV0IGV0YykKZGV2aWNlCQltZAkJIyBNZW1vcnkg ImRpc2tzIgojZGV2aWNlCQlnaWYJCSMgSVB2NiBhbmQgSVB2NCB0dW5uZWxpbmcKI2RldmljZQkJ ZmFpdGgJCSMgSVB2Ni10by1JUHY0IHJlbGF5aW5nICh0cmFuc2xhdGlvbikKCiMgVGhlIGBicGYn IGRldmljZSBlbmFibGVzIHRoZSBCZXJrZWxleSBQYWNrZXQgRmlsdGVyLgojIEJlIGF3YXJlIG9m IHRoZSBhZG1pbmlzdHJhdGl2ZSBjb25zZXF1ZW5jZXMgb2YgZW5hYmxpbmcgdGhpcyEKZGV2aWNl CQlicGYJCSMgQmVya2VsZXkgcGFja2V0IGZpbHRlcgoKIyBVU0Igc3VwcG9ydAojZGV2aWNlCQl1 aGNpCQkjIFVIQ0kgUENJLT5VU0IgaW50ZXJmYWNlCiNkZXZpY2UJCW9oY2kJCSMgT0hDSSBQQ0kt PlVTQiBpbnRlcmZhY2UKI2RldmljZQkJdXNiCQkjIFVTQiBCdXMgKHJlcXVpcmVkKQojZGV2aWNl CQl1ZGJwCQkjIFVTQiBEb3VibGUgQnVsayBQaXBlIGRldmljZXMKI2RldmljZQkJdWdlbgkJIyBH ZW5lcmljCiNkZXZpY2UJCXVoaWQJCSMgIkh1bWFuIEludGVyZmFjZSBEZXZpY2VzIgojZGV2aWNl CQl1a2JkCQkjIEtleWJvYXJkCiNkZXZpY2UJCXVscHQJCSMgUHJpbnRlcgojZGV2aWNlCQl1bWFz cwkJIyBEaXNrcy9NYXNzIHN0b3JhZ2UgLSBSZXF1aXJlcyBzY2J1cyBhbmQgZGEKI2RldmljZQkJ dW1zCQkjIE1vdXNlCiNkZXZpY2UJCXVyaW8JCSMgRGlhbW9uZCBSaW8gNTAwIE1QMyBwbGF5ZXIK I2RldmljZQkJdXNjYW5uZXIJIyBTY2FubmVycwojIFVTQiBFdGhlcm5ldCwgcmVxdWlyZXMgbWlp CiNkZXZpY2UJCWF1ZQkJIyBBRE10ZWsgVVNCIGV0aGVybmV0CiNkZXZpY2UJCWN1ZQkJIyBDQVRD IFVTQiBldGhlcm5ldAojZGV2aWNlCQlrdWUJCSMgS2F3YXNha2kgTFNJIFVTQiBldGhlcm5ldAoK ZGV2aWNlCQlzbWIKZGV2aWNlCQlzbWJ1cwpkZXZpY2UJCWludHBtCmRldmljZQkJYXRhcGljYW0K I2RldmljZSB2aW51bQojb3B0aW9ucyAgICBWSU5VTURFQlVHCgo= --Multipart=_Sun__29_Aug_2004_15_59_45_+0200_b4ptC/ltohPxY+v6 Content-Type: application/octet-stream; name="CURRY" Content-Disposition: attachment; filename="CURRY" Content-Transfer-Encoding: base64 IwojIEdFTkVSSUMgLS0gR2VuZXJpYyBrZXJuZWwgY29uZmlndXJhdGlvbiBmaWxlIGZvciBGcmVl QlNEL2kzODYKIwojIEZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHRoaXMgZmlsZSwgcGxlYXNlIHJl YWQgdGhlIGhhbmRib29rIHNlY3Rpb24gb24KIyBLZXJuZWwgQ29uZmlndXJhdGlvbiBGaWxlczoK IwojICAgIGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcvZG9jL2VuX1VTLklTTzg4NTktMS9ib29rcy9o YW5kYm9vay9rZXJuZWxjb25maWctY29uZmlnLmh0bWwKIwojIFRoZSBoYW5kYm9vayBpcyBhbHNv IGF2YWlsYWJsZSBsb2NhbGx5IGluIC91c3Ivc2hhcmUvZG9jL2hhbmRib29rCiMgaWYgeW91J3Zl IGluc3RhbGxlZCB0aGUgZG9jIGRpc3RyaWJ1dGlvbiwgb3RoZXJ3aXNlIGFsd2F5cyBzZWUgdGhl CiMgRnJlZUJTRCBXb3JsZCBXaWRlIFdlYiBzZXJ2ZXIgKGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcv KSBmb3IgdGhlCiMgbGF0ZXN0IGluZm9ybWF0aW9uLgojCiMgQW4gZXhoYXVzdGl2ZSBsaXN0IG9m IG9wdGlvbnMgYW5kIG1vcmUgZGV0YWlsZWQgZXhwbGFuYXRpb25zIG9mIHRoZQojIGRldmljZSBs aW5lcyBpcyBhbHNvIHByZXNlbnQgaW4gdGhlIC4uLy4uL2NvbmYvTk9URVMgYW5kIE5PVEVTIGZp bGVzLiAKIyBJZiB5b3UgYXJlIGluIGRvdWJ0IGFzIHRvIHRoZSBwdXJwb3NlIG9yIG5lY2Vzc2l0 eSBvZiBhIGxpbmUsIGNoZWNrIGZpcnN0IAojIGluIE5PVEVTLgojCiMgJEZyZWVCU0Q6IHNyYy9z eXMvaTM4Ni9jb25mL0dFTkVSSUMsdiAxLjM4MiAyMDAzLzA0LzIxIDE2OjQ0OjA0IHNpbW9rYXdh IEV4cCAkCgptYWNoaW5lCQlpMzg2CiNjcHUJCUk0ODZfQ1BVCiNjcHUJCUk1ODZfQ1BVCmNwdQkJ STY4Nl9DUFUKaWRlbnQJCUNVUlJZCgojVG8gc3RhdGljYWxseSBjb21waWxlIGluIGRldmljZSB3 aXJpbmcgaW5zdGVhZCBvZiAvYm9vdC9kZXZpY2UuaGludHMKI2hpbnRzCQkiR0VORVJJQy5oaW50 cyIJCSNEZWZhdWx0IHBsYWNlcyB0byBsb29rIGZvciBkZXZpY2VzLgoKbWFrZW9wdGlvbnMJREVC VUc9LWcJCSNCdWlsZCBrZXJuZWwgd2l0aCBnZGIoMSkgZGVidWcgc3ltYm9scwoKb3B0aW9ucyAJ U0NIRURfNEJTRAkJIzRCU0Qgc2NoZWR1bGVyCm9wdGlvbnMgCUlORVQJCQkjSW50ZXJORVR3b3Jr aW5nCm9wdGlvbnMgCUlORVQ2CQkJI0lQdjYgY29tbXVuaWNhdGlvbnMgcHJvdG9jb2xzCm9wdGlv bnMgCUZGUwkJCSNCZXJrZWxleSBGYXN0IEZpbGVzeXN0ZW0Kb3B0aW9ucyAJU09GVFVQREFURVMJ CSNFbmFibGUgRkZTIHNvZnQgdXBkYXRlcyBzdXBwb3J0Cm9wdGlvbnMgCVVGU19BQ0wJCQkjU3Vw cG9ydCBmb3IgYWNjZXNzIGNvbnRyb2wgbGlzdHMKb3B0aW9ucyAJVUZTX0RJUkhBU0gJCSNJbXBy b3ZlIHBlcmZvcm1hbmNlIG9uIGJpZyBkaXJlY3RvcmllcwpvcHRpb25zIAlNRF9ST09UCQkJI01E IGlzIGEgcG90ZW50aWFsIHJvb3QgZGV2aWNlCm9wdGlvbnMgCU5GU0NMSUVOVAkJI05ldHdvcmsg RmlsZXN5c3RlbSBDbGllbnQKb3B0aW9ucyAJTkZTU0VSVkVSCQkjTmV0d29yayBGaWxlc3lzdGVt IFNlcnZlcgpvcHRpb25zIAlORlNfUk9PVAkJI05GUyB1c2FibGUgYXMgcm9vdCBkZXZpY2UsIHJl cXVpcmVzIE5GU0NMSUVOVApvcHRpb25zIAlNU0RPU0ZTCQkJI01TRE9TIEZpbGVzeXN0ZW0Kb3B0 aW9ucyAJQ0Q5NjYwCQkJI0lTTyA5NjYwIEZpbGVzeXN0ZW0Kb3B0aW9ucyAJUFJPQ0ZTCQkJI1By b2Nlc3MgZmlsZXN5c3RlbSAocmVxdWlyZXMgUFNFVURPRlMpCm9wdGlvbnMgCVBTRVVET0ZTCQkj UHNldWRvLWZpbGVzeXN0ZW0gZnJhbWV3b3JrCm9wdGlvbnMgCUNPTVBBVF80MwkJI0NvbXBhdGli bGUgd2l0aCBCU0QgNC4zIFtLRUVQIFRISVMhXQpvcHRpb25zIAlDT01QQVRfRlJFRUJTRDQJCSND b21wYXRpYmxlIHdpdGggRnJlZUJTRDQKb3B0aW9ucyAJU0NTSV9ERUxBWT0xNTAwMAkjRGVsYXkg KGluIG1zKSBiZWZvcmUgcHJvYmluZyBTQ1NJCm9wdGlvbnMgCUtUUkFDRQkJCSNrdHJhY2UoMSkg c3VwcG9ydApvcHRpb25zIAlTWVNWU0hNCQkJI1NZU1Ytc3R5bGUgc2hhcmVkIG1lbW9yeQpvcHRp b25zIAlTWVNWTVNHCQkJI1NZU1Ytc3R5bGUgbWVzc2FnZSBxdWV1ZXMKb3B0aW9ucyAJU1lTVlNF TQkJCSNTWVNWLXN0eWxlIHNlbWFwaG9yZXMKb3B0aW9ucyAJX0tQT1NJWF9QUklPUklUWV9TQ0hF RFVMSU5HICNQb3NpeCBQMTAwM18xQiByZWFsLXRpbWUgZXh0ZW5zaW9ucwpvcHRpb25zIAlLQkRf SU5TVEFMTF9DREVWCSMgaW5zdGFsbCBhIENERVYgZW50cnkgaW4gL2RldgpvcHRpb25zIAlBSENf UkVHX1BSRVRUWV9QUklOVAkjIFByaW50IHJlZ2lzdGVyIGJpdGZpZWxkcyBpbiBkZWJ1ZwoJCQkJ CSMgb3V0cHV0LiAgQWRkcyB+MTI4ayB0byBkcml2ZXIuCm9wdGlvbnMgCUFIRF9SRUdfUFJFVFRZ X1BSSU5UCSMgUHJpbnQgcmVnaXN0ZXIgYml0ZmllbGRzIGluIGRlYnVnCgkJCQkJIyBvdXRwdXQu ICBBZGRzIH4yMTVrIHRvIGRyaXZlci4KCiMgRGVidWdnaW5nIGZvciB1c2UgaW4gLWN1cnJlbnQK I29wdGlvbnMgCUREQgkJCSNFbmFibGUgdGhlIGtlcm5lbCBkZWJ1Z2dlcgojb3B0aW9ucyAJSU5W QVJJQU5UUwkJI0VuYWJsZSBjYWxscyBvZiBleHRyYSBzYW5pdHkgY2hlY2tpbmcKI29wdGlvbnMg CUlOVkFSSUFOVF9TVVBQT1JUCSNFeHRyYSBzYW5pdHkgY2hlY2tzIG9mIGludGVybmFsIHN0cnVj dHVyZXMsIHJlcXVpcmVkIGJ5IElOVkFSSUFOVFMKI29wdGlvbnMgCVdJVE5FU1MJCQkjRW5hYmxl IGNoZWNrcyB0byBkZXRlY3QgZGVhZGxvY2tzIGFuZCBjeWNsZXMKI29wdGlvbnMgCVdJVE5FU1Nf U0tJUFNQSU4JI0Rvbid0IHJ1biB3aXRuZXNzIG9uIHNwaW5sb2NrcyBmb3Igc3BlZWQKCiMgVG8g bWFrZSBhbiBTTVAga2VybmVsLCB0aGUgbmV4dCB0d28gYXJlIG5lZWRlZAojb3B0aW9ucyAJU01Q CQkJIyBTeW1tZXRyaWMgTXVsdGlQcm9jZXNzb3IgS2VybmVsCiNvcHRpb25zIAlBUElDX0lPCQkJ IyBTeW1tZXRyaWMgKEFQSUMpIEkvTwoKZGV2aWNlCQlpc2EKI2RldmljZQkJZWlzYQpkZXZpY2UJ CXBjaQoKIyBGbG9wcHkgZHJpdmVzCmRldmljZQkJZmRjCgojIEFUQSBhbmQgQVRBUEkgZGV2aWNl cwpkZXZpY2UJCWF0YQpkZXZpY2UJCWF0YWRpc2sJCQkjIEFUQSBkaXNrIGRyaXZlcwpkZXZpY2UJ CWF0YXBpY2QJCQkjIEFUQVBJIENEUk9NIGRyaXZlcwojZGV2aWNlCQlhdGFwaWZkCQkJIyBBVEFQ SSBmbG9wcHkgZHJpdmVzCiNkZXZpY2UJCWF0YXBpc3QJCQkjIEFUQVBJIHRhcGUgZHJpdmVzCm9w dGlvbnMgCUFUQV9TVEFUSUNfSUQJCSNTdGF0aWMgZGV2aWNlIG51bWJlcmluZwoKIyBTQ1NJIENv bnRyb2xsZXJzCiNkZXZpY2UJCWFoYgkJIyBFSVNBIEFIQTE3NDIgZmFtaWx5CiNkZXZpY2UJCWFo YwkJIyBBSEEyOTQwIGFuZCBvbmJvYXJkIEFJQzd4eHggZGV2aWNlcwojZGV2aWNlCQlhaGQJCSMg QUhBMzkzMjAvMjkzMjAgYW5kIG9uYm9hcmQgQUlDNzl4eCBkZXZpY2VzCiNkZXZpY2UJCWFtZAkJ IyBBTUQgNTNDOTc0IChUZWtyYW0gREMtMzkwKFQpKQojZGV2aWNlCQlpc3AJCSMgUWxvZ2ljIGZh bWlseQojZGV2aWNlCQltcHQJCSMgTFNJLUxvZ2ljIE1QVC1GdXNpb24KI2RldmljZQkJbmNyCQkj IE5DUi9TeW1iaW9zIExvZ2ljCiNkZXZpY2UJCXN5bQkJIyBOQ1IvU3ltYmlvcyBMb2dpYyAobmV3 ZXIgY2hpcHNldHMgKyB0aG9zZSBvZiBgbmNyJykKI2RldmljZQkJdHJtCQkjIFRla3JhbSBEQzM5 NVUvVVcvRiBEQzMxNVUgYWRhcHRlcnMKCiNkZXZpY2UJCWFkdgkJIyBBZHZhbnN5cyBTQ1NJIGFk YXB0ZXJzCiNkZXZpY2UJCWFkdwkJIyBBZHZhbnN5cyB3aWRlIFNDU0kgYWRhcHRlcnMKI2Rldmlj ZQkJYWhhCQkjIEFkYXB0ZWMgMTU0eCBTQ1NJIGFkYXB0ZXJzCiNkZXZpY2UJCWFpYwkJIyBBZGFw dGVjIDE1WzAxMl14IFNDU0kgYWRhcHRlcnMsIEFJQy02WzIzXTYwLgojZGV2aWNlCQlidAkJIyBC dXNsb2dpYy9NeWxleCBNdWx0aU1hc3RlciBTQ1NJIGFkYXB0ZXJzCgojZGV2aWNlCQluY3YJCSMg TkNSIDUzQzUwMAojZGV2aWNlCQluc3AJCSMgV29ya2JpdCBOaW5qYSBTQ1NJLTMKI2RldmljZQkJ c3RnCQkjIFRNQyAxOEMzMC8xOEM1MAoKIyBSQUlEIGNvbnRyb2xsZXJzIGludGVyZmFjZWQgdG8g dGhlIFNDU0kgc3Vic3lzdGVtCiNkZXZpY2UJCWFzcgkJIyBEUFQgU21hcnRSQUlEIFYsIFZJIGFu ZCBBZGFwdGVjIFNDU0kgUkFJRAojZGV2aWNlCQljaXNzCQkjIENvbXBhcSBTbWFydCBSQUlEIDUq CiNkZXZpY2UJCWRwdAkJIyBEUFQgU21hcnRjYWNoZSBJSUksIElWIC0gU2VlIE5PVEVTIGZvciBv cHRpb25zIQojZGV2aWNlCQlpaXIJCSMgSW50ZWwgSW50ZWdyYXRlZCBSQUlECiNkZXZpY2UJCW1s eQkJIyBNeWxleCBBY2NlbGVSQUlEL2VYdHJlbWVSQUlECgojIFNDU0kgcGVyaXBoZXJhbHMKZGV2 aWNlCQlzY2J1cwkJIyBTQ1NJIGJ1cyAocmVxdWlyZWQpCiNkZXZpY2UJCWNoCQkjIFNDU0kgbWVk aWEgY2hhbmdlcnMKZGV2aWNlCQlkYQkJIyBEaXJlY3QgQWNjZXNzIChkaXNrcykKI2RldmljZQkJ c2EJCSMgU2VxdWVudGlhbCBBY2Nlc3MgKHRhcGUgZXRjKQojZGV2aWNlCQljZAkJIyBDRAojZGV2 aWNlCQlwYXNzCQkjIFBhc3N0aHJvdWdoIGRldmljZSAoZGlyZWN0IFNDU0kgYWNjZXNzKQojZGV2 aWNlCQlzZXMJCSMgU0NTSSBFbnZpcm9ubWVudGFsIFNlcnZpY2VzIChhbmQgU0FGLVRFKQoKIyBS QUlEIGNvbnRyb2xsZXJzCiNkZXZpY2UJCWFhYwkJIyBBZGFwdGVjIEZTQSBSQUlECiNkZXZpY2UJ CWFhY3AJCSMgU0NTSSBwYXNzdGhyb3VnaCBmb3IgYWFjIChyZXF1aXJlcyBDQU0pCiNkZXZpY2UJ CWFtcgkJIyBBTUkgTWVnYVJBSUQKI2RldmljZQkJaWRhCQkjIENvbXBhcSBTbWFydCBSQUlECiNk ZXZpY2UJCW1seAkJIyBNeWxleCBEQUM5NjAgZmFtaWx5CiNkZXZpY2UJCXBzdAkJIyBQcm9taXNl IFN1cGVydHJhayBTWDYwMDAKI2RldmljZQkJdHdlCQkjIDN3YXJlIEFUQSBSQUlECgojIGF0a2Jk YzAgY29udHJvbHMgYm90aCB0aGUga2V5Ym9hcmQgYW5kIHRoZSBQUy8yIG1vdXNlCmRldmljZQkJ YXRrYmRjCQkjIEFUIGtleWJvYXJkIGNvbnRyb2xsZXIKZGV2aWNlCQlhdGtiZAkJIyBBVCBrZXli b2FyZApkZXZpY2UJCXBzbQkJIyBQUy8yIG1vdXNlCgpkZXZpY2UJCXZnYQkJIyBWR0EgdmlkZW8g Y2FyZCBkcml2ZXIKCmRldmljZQkJc3BsYXNoCQkjIFNwbGFzaCBzY3JlZW4gYW5kIHNjcmVlbiBz YXZlciBzdXBwb3J0CgojIHN5c2NvbnMgaXMgdGhlIGRlZmF1bHQgY29uc29sZSBkcml2ZXIsIHJl c2VtYmxpbmcgYW4gU0NPIGNvbnNvbGUKZGV2aWNlCQlzYwoKIyBFbmFibGUgdGhpcyBmb3IgdGhl IHBjdnQgKFZUMjIwIGNvbXBhdGlibGUpIGNvbnNvbGUgZHJpdmVyCiNkZXZpY2UJCXZ0CiNvcHRp b25zIAlYU0VSVkVSCQkJIyBzdXBwb3J0IGZvciBYIHNlcnZlciBvbiBhIHZ0IGNvbnNvbGUKI29w dGlvbnMgCUZBVF9DVVJTT1IJCSMgc3RhcnQgd2l0aCBibG9jayBjdXJzb3IKCmRldmljZQkJYWdw CQkjIHN1cHBvcnQgc2V2ZXJhbCBBR1AgY2hpcHNldHMKCiMgRmxvYXRpbmcgcG9pbnQgc3VwcG9y dCAtIGRvIG5vdCBkaXNhYmxlLgpkZXZpY2UJCW5weAoKIyBQb3dlciBtYW5hZ2VtZW50IHN1cHBv cnQgKHNlZSBOT1RFUyBmb3IgbW9yZSBvcHRpb25zKQojZGV2aWNlCQlhcG0KIyBBZGQgc3VzcGVu ZC9yZXN1bWUgc3VwcG9ydCBmb3IgdGhlIGk4MjU0LgpkZXZpY2UJCXBtdGltZXIKCiMgUENDQVJE IChQQ01DSUEpIHN1cHBvcnQKIyBQY21jaWEgYW5kIGNhcmRidXMgYnJpZGdlIHN1cHBvcnQKI2Rl dmljZQkJY2JiCQkJIyBjYXJkYnVzICh5ZW50YSkgYnJpZGdlCiNkZXZpY2UJCXBjaWMJCQkjIEV4 Q0EgSVNBIGFuZCBQQ0kgYnJpZGdlcwojZGV2aWNlCQlwY2NhcmQJCQkjIFBDIENhcmQgKDE2LWJp dCkgYnVzCiNkZXZpY2UJCWNhcmRidXMJCQkjIENhcmRCdXMgKDMyLWJpdCkgYnVzCgojIFNlcmlh bCAoQ09NKSBwb3J0cwpkZXZpY2UJCXNpbwkJIyA4MjUwLCAxNls0NV01MCBiYXNlZCBzZXJpYWwg cG9ydHMKCiMgUGFyYWxsZWwgcG9ydApkZXZpY2UJCXBwYwpkZXZpY2UJCXBwYnVzCQkjIFBhcmFs bGVsIHBvcnQgYnVzIChyZXF1aXJlZCkKZGV2aWNlCQlscHQJCSMgUHJpbnRlcgojZGV2aWNlCQlw bGlwCQkjIFRDUC9JUCBvdmVyIHBhcmFsbGVsCiNkZXZpY2UJCXBwaQkJIyBQYXJhbGxlbCBwb3J0 IGludGVyZmFjZSBkZXZpY2UKI2RldmljZQkJdnBvCQkjIFJlcXVpcmVzIHNjYnVzIGFuZCBkYQoK CiMgUENJIEV0aGVybmV0IE5JQ3MuCiNkZXZpY2UJCWRlCQkjIERFQy9JbnRlbCBEQzIxeDR4IChg YFR1bGlwJycpCiNkZXZpY2UJCWVtCQkjIEludGVsIFBSTy8xMDAwIGFkYXB0ZXIgR2lnYWJpdCBF dGhlcm5ldCBDYXJkCiNkZXZpY2UJCXR4cAkJIyAzQ29tIDNjUjk5MCAoYGBUeXBob29uJycpCiNk ZXZpY2UJCXZ4CQkjIDNDb20gM2M1OTAsIDNjNTk1IChgYFZvcnRleCcnKQoKIyBQQ0kgRXRoZXJu ZXQgTklDcyB0aGF0IHVzZSB0aGUgY29tbW9uIE1JSSBidXMgY29udHJvbGxlciBjb2RlLgojIE5P VEU6IEJlIHN1cmUgdG8ga2VlcCB0aGUgJ2RldmljZSBtaWlidXMnIGxpbmUgaW4gb3JkZXIgdG8g dXNlIHRoZXNlIE5JQ3MhCmRldmljZQkJbWlpYnVzCQkjIE1JSSBidXMgc3VwcG9ydAojZGV2aWNl CQlkYwkJIyBERUMvSW50ZWwgMjExNDMgYW5kIHZhcmlvdXMgd29ya2FsaWtlcwpkZXZpY2UJCWZ4 cAkJIyBJbnRlbCBFdGhlckV4cHJlc3MgUFJPLzEwMEIgKDgyNTU3LCA4MjU1OCkKI2RldmljZQkJ cGNuCQkjIEFNRCBBbTc5Qzk3eCBQQ0kgMTAvMTAwIChwcmVjZWRlbmNlIG92ZXIgJ2xuYycpCiNk ZXZpY2UJCXJsCQkjIFJlYWxUZWsgODEyOS84MTM5CiNkZXZpY2UJCXNmCQkjIEFkYXB0ZWMgQUlD LTY5MTUgKGBgU3RhcmZpcmUnJykKI2RldmljZQkJc2lzCQkjIFNpbGljb24gSW50ZWdyYXRlZCBT eXN0ZW1zIFNpUyA5MDAvU2lTIDcwMTYKI2RldmljZQkJc3RlCQkjIFN1bmRhbmNlIFNUMjAxIChE LUxpbmsgREZFLTU1MFRYKQojZGV2aWNlCQl0bAkJIyBUZXhhcyBJbnN0cnVtZW50cyBUaHVuZGVy TEFOCiNkZXZpY2UJCXR4CQkjIFNNQyBFdGhlclBvd2VyIElJICg4M2MxNzAgYGBFUElDJycpCiNk ZXZpY2UJCXZyCQkjIFZJQSBSaGluZSwgUmhpbmUgSUkKI2RldmljZQkJd2IJCSMgV2luYm9uZCBX ODlDODQwRgojZGV2aWNlCQl4bAkJIyAzQ29tIDNjOTB4IChgYEJvb21lcmFuZycnLCBgYEN5Y2xv bmUnJykKI2RldmljZQkJYmdlCQkjIEJyb2FkY29tIEJDTTU3MHh4IEdpZ2FiaXQgRXRoZXJuZXQK CiMgSVNBIEV0aGVybmV0IE5JQ3MuICBwY2NhcmQgbmljcyBpbmNsdWRlZC4KI2RldmljZQkJY3MJ CSMgQ3J5c3RhbCBTZW1pY29uZHVjdG9yIENTODl4MCBOSUMKIyAnZGV2aWNlIGVkJyByZXF1aXJl cyAnZGV2aWNlIG1paWJ1cycKI2RldmljZQkJZWQJCSMgTkVbMTJdMDAwLCBTTUMgVWx0cmEsIDNj NTAzLCBEUzgzOTAgY2FyZHMKI2RldmljZQkJZXgJCSMgSW50ZWwgRXRoZXJFeHByZXNzIFByby8x MCBhbmQgUHJvLzEwKwojZGV2aWNlCQllcAkJIyBFdGhlcmxpbmsgSUlJIGJhc2VkIGNhcmRzCiNk ZXZpY2UJCWZlCQkjIEZ1aml0c3UgTUI4Njk2eCBiYXNlZCBjYXJkcwojZGV2aWNlCQlpZQkJIyBF dGhlckV4cHJlc3MgOC8xNiwgM0M1MDcsIFN0YXJMQU4gMTAgZXRjLgojZGV2aWNlCQlsbmMJCSMg TkUyMTAwLCBORTMyLVZMIExhbmNlIEV0aGVybmV0IGNhcmRzCiNkZXZpY2UJCXNuCQkjIFNNQydz IDkwMDAgc2VyaWVzIG9mIGV0aGVybmV0IGNoaXBzCiNkZXZpY2UJCXhlCQkjIFhpcmNvbSBwY2Nh cmQgZXRoZXJuZXQKCiMgSVNBIGRldmljZXMgdGhhdCB1c2UgdGhlIG9sZCBJU0Egc2hpbXMKI2Rl dmljZQkJbGUKCiMgV2lyZWxlc3MgTklDIGNhcmRzCiNkZXZpY2UJCXdsYW4JCSMgODAyLjExIHN1 cHBvcnQKI2RldmljZQkJYW4JCSMgQWlyb25ldCA0NTAwLzQ4MDAgODAyLjExIHdpcmVsZXNzIE5J Q3MuIAojZGV2aWNlCQlhd2kJCSMgQmF5U3RhY2sgNjYwIGFuZCBvdGhlcnMKI2RldmljZQkJd2kJ CSMgV2F2ZUxBTi9JbnRlcnNpbC9TeW1ib2wgODAyLjExIHdpcmVsZXNzIE5JQ3MuCiNkZXZpY2UJ CXdsCQkjIE9sZGVyIG5vbiA4MDIuMTEgV2F2ZWxhbiB3aXJlbGVzcyBOSUMuCgojIFBzZXVkbyBk ZXZpY2VzIC0gdGhlIG51bWJlciBpbmRpY2F0ZXMgaG93IG1hbnkgdW5pdHMgdG8gYWxsb2NhdGUu CmRldmljZQkJcmFuZG9tCQkjIEVudHJvcHkgZGV2aWNlCmRldmljZQkJbG9vcAkJIyBOZXR3b3Jr IGxvb3BiYWNrCmRldmljZQkJZXRoZXIJCSMgRXRoZXJuZXQgc3VwcG9ydAojZGV2aWNlCQlzbAkJ IyBLZXJuZWwgU0xJUAojZGV2aWNlCQlwcHAJCSMgS2VybmVsIFBQUAojZGV2aWNlCQl0dW4JCSMg UGFja2V0IHR1bm5lbC4KZGV2aWNlCQlwdHkJCSMgUHNldWRvLXR0eXMgKHRlbG5ldCBldGMpCmRl dmljZQkJbWQJCSMgTWVtb3J5ICJkaXNrcyIKI2RldmljZQkJZ2lmCQkjIElQdjYgYW5kIElQdjQg dHVubmVsaW5nCiNkZXZpY2UJCWZhaXRoCQkjIElQdjYtdG8tSVB2NCByZWxheWluZyAodHJhbnNs YXRpb24pCgojIFRoZSBgYnBmJyBkZXZpY2UgZW5hYmxlcyB0aGUgQmVya2VsZXkgUGFja2V0IEZp bHRlci4KIyBCZSBhd2FyZSBvZiB0aGUgYWRtaW5pc3RyYXRpdmUgY29uc2VxdWVuY2VzIG9mIGVu YWJsaW5nIHRoaXMhCmRldmljZQkJYnBmCQkjIEJlcmtlbGV5IHBhY2tldCBmaWx0ZXIKCiMgVVNC IHN1cHBvcnQKZGV2aWNlCQl1aGNpCQkjIFVIQ0kgUENJLT5VU0IgaW50ZXJmYWNlCiNkZXZpY2UJ CW9oY2kJCSMgT0hDSSBQQ0ktPlVTQiBpbnRlcmZhY2UKZGV2aWNlCQl1c2IJCSMgVVNCIEJ1cyAo cmVxdWlyZWQpCmRldmljZQkJdWRicAkJIyBVU0IgRG91YmxlIEJ1bGsgUGlwZSBkZXZpY2VzCmRl dmljZQkJdWdlbgkJIyBHZW5lcmljCmRldmljZQkJdWhpZAkJIyAiSHVtYW4gSW50ZXJmYWNlIERl dmljZXMiCmRldmljZQkJdWtiZAkJIyBLZXlib2FyZApkZXZpY2UJCXVscHQJCSMgUHJpbnRlcgpk ZXZpY2UJCXVtYXNzCQkjIERpc2tzL01hc3Mgc3RvcmFnZSAtIFJlcXVpcmVzIHNjYnVzIGFuZCBk YQpkZXZpY2UJCXVtcwkJIyBNb3VzZQpkZXZpY2UJCXVyaW8JCSMgRGlhbW9uZCBSaW8gNTAwIE1Q MyBwbGF5ZXIKZGV2aWNlCQl1c2Nhbm5lcgkjIFNjYW5uZXJzCiMgVVNCIEV0aGVybmV0LCByZXF1 aXJlcyBtaWkKI2RldmljZQkJYXVlCQkjIEFETXRlayBVU0IgZXRoZXJuZXQKI2RldmljZQkJYXhl CQkjIEFTSVggRWxlY3Ryb25pY3MgVVNCIGV0aGVybmV0CiNkZXZpY2UJCWN1ZQkJIyBDQVRDIFVT QiBldGhlcm5ldAojZGV2aWNlCQlrdWUJCSMgS2F3YXNha2kgTFNJIFVTQiBldGhlcm5ldAoKIyBG aXJlV2lyZSBzdXBwb3J0CiNkZXZpY2UJCWZpcmV3aXJlCSMgRmlyZVdpcmUgYnVzIGNvZGUKI2Rl dmljZQkJc2JwCQkjIFNDU0kgb3ZlciBGaXJlV2lyZSAoUmVxdWlyZXMgc2NidXMgYW5kIGRhKQoj ZGV2aWNlCQlmd2UJCSMgRXRoZXJuZXQgb3ZlciBGaXJlV2lyZSAobm9uLXN0YW5kYXJkISkKCmRl dmljZSAgICAgICAgICBzbWIKZGV2aWNlICAgICAgICAgIHNtYnVzCmRldmljZSAgICAgICAgICBp bnRwbQpvcHRpb25zCQlORVRHUkFQSApkZXZpY2UJCXNvdW5kCmRldmljZQkJc25kX3NiYwo= --Multipart=_Sun__29_Aug_2004_15_59_45_+0200_b4ptC/ltohPxY+v6 Content-Type: application/octet-stream; name="nudel_dmesg.out" Content-Disposition: attachment; filename="nudel_dmesg.out" Content-Transfer-Encoding: base64 Q29weXJpZ2h0IChjKSAxOTkyLTIwMDQgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDUuMy1CRVRBMSAjMDogRnJpIEF1ZyAyNyAyMDoyMDoxMSBD RVNUIDIwMDQKICAgIHJvb3RAbnVkZWwuc2FsYXRzY2h1ZXNzZWwubmV0Oi91c3Ivb2JqL3Vzci9z cmMvc3lzL05VREVMCk1QVGFibGU6IDxFQ1MgICAgICBQNkxYMi1BICAgICA+ClRpbWVjb3VudGVy ICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwCkNQVTogUGVudGl1bSBJSS9Q ZW50aXVtIElJIFhlb24vQ2VsZXJvbiAoMzM0LjA5LU1IeiA2ODYtY2xhc3MgQ1BVKQogIE9yaWdp biA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4NjUyICBTdGVwcGluZyA9IDIKICBGZWF0dXJlcz0w eDE4M2ZiZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxNVFJS LFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYsTU1YLEZYU1I+CnJlYWwgbWVtb3J5ICA9IDI2ODQzNTQ1 NiAoMjU2IE1CKQphdmFpbCBtZW1vcnkgPSAyNTcwODk1MzYgKDI0NSBNQikKRnJlZUJTRC9TTVA6 IE11bHRpcHJvY2Vzc29yIFN5c3RlbSBEZXRlY3RlZDogMiBDUFVzCiBjcHUwIChCU1ApOiBBUElD IElEOiAgMAogY3B1MSAoQVApOiBBUElDIElEOiAgMQppb2FwaWMwOiBBc3N1bWluZyBpbnRiYXNl IG9mIDAKaW9hcGljMCA8VmVyc2lvbiAxLjE+IGlycXMgMC0yMyBvbiBtb3RoZXJib2FyZApucHgw OiBbRkFTVF0KbnB4MDogPG1hdGggcHJvY2Vzc29yPiBvbiBtb3RoZXJib2FyZApucHgwOiBJTlQg MTYgaW50ZXJmYWNlCnBjaWIwOiA8TVBUYWJsZSBIb3N0LVBDSSBicmlkZ2U+IHBjaWJ1cyAwIG9u IG1vdGhlcmJvYXJkCnBjaTA6IDxQQ0kgYnVzPiBvbiBwY2liMApwY2liMDogdW5hYmxlIHRvIHJv dXRlIHNsb3QgNyBJTlRECmFncDA6IDxJbnRlbCA4MjQ0M0xYICg0NDAgTFgpIGhvc3QgdG8gUENJ IGJyaWRnZT4gbWVtIDB4ZTAwMDAwMDAtMHhlMDNmZmZmZiBhdCBkZXZpY2UgMC4wIG9uIHBjaTAK cGNpYjE6IDxNUFRhYmxlIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAKcGNp MTogPFBDSSBidXM+IG9uIHBjaWIxCnBjaTE6IDxkaXNwbGF5LCBWR0E+IGF0IGRldmljZSAwLjAg KG5vIGRyaXZlciBhdHRhY2hlZCkKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNlIDcu MCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphdGFwY2kwOiA8SW50ZWwgUElJWDQg VURNQTMzIGNvbnRyb2xsZXI+IHBvcnQgMHhmMDAwLTB4ZjAwZiwweDM3NiwweDE3MC0weDE3Nyww eDNmNiwweDFmMC0weDFmNyBhdCBkZXZpY2UgNy4xIG9uIHBjaTAKYXRhMDogY2hhbm5lbCAjMCBv biBhdGFwY2kwCmF0YTE6IGNoYW5uZWwgIzEgb24gYXRhcGNpMApwY2kwOiA8c2VyaWFsIGJ1cywg VVNCPiBhdCBkZXZpY2UgNy4yIChubyBkcml2ZXIgYXR0YWNoZWQpCmludHBtMDogPEludGVsIDgy MzcxQUIgUG93ZXIgbWFuYWdlbWVudCBjb250cm9sbGVyPiBwb3J0IDB4NTAwMC0weDUwMGYgaXJx IDkgYXQgZGV2aWNlIDcuMyBvbiBwY2kwCmludHBtMDogSS9PIG1hcHBlZCA1MDAwCmludHBtMDog aW50ciBJUlEgOSBlbmFibGVkIHJldmlzaW9uIDAKaW50cG0wOiBbR0lBTlQtTE9DS0VEXQppbnRz bWIwOiA8SW50ZWwgUElJWDQgU01CVVMgSW50ZXJmYWNlPiBvbiBpbnRwbTAKc21idXMwOiA8U3lz dGVtIE1hbmFnZW1lbnQgQnVzPiBvbiBpbnRzbWIwCnNtYjA6IDxTTUJ1cyBnZW5lcmljIEkvTz4g b24gc21idXMwCmludHBtMDogUE0gSS9PIG1hcHBlZCA2MTAwIApwY2kwOiA8bmV0d29yaywgZXRo ZXJuZXQ+IGF0IGRldmljZSA5LjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKYWhjMDogPEFkYXB0ZWMg Mjk0MCBVbHRyYTIgU0NTSSBhZGFwdGVyIChPRU0pPiBwb3J0IDB4NmMwMC0weDZjZmYgbWVtIDB4 ZTA0MDEwMDAtMHhlMDQwMWZmZiBpcnEgMTcgYXQgZGV2aWNlIDEwLjAgb24gcGNpMAphaGMwOiBb R0lBTlQtTE9DS0VEXQphaWM3ODkwLzkxOiBVbHRyYTIgV2lkZSBDaGFubmVsIEEsIFNDU0kgSWQ9 NywgMzIvMjUzIFNDQnMKc3ltMDogPDg4NT4gcG9ydCAweDcwMDAtMHg3MGZmIG1lbSAweGUwNDAz MDAwLTB4ZTA0MDNmZmYsMHhlMDQwMjAwMC0weGUwNDAyMGZmIGlycSAxOCBhdCBkZXZpY2UgMTEu MCBvbiBwY2kwCnN5bTA6IFN5bWJpb3MgTlZSQU0sIElEIDcsIEZhc3QtMjAsIFNFLCBwYXJpdHkg Y2hlY2tpbmcKc3ltMDogb3BlbiBkcmFpbiBJUlEgbGluZSBkcml2ZXIsIHVzaW5nIG9uLWNoaXAg U1JBTQpzeW0wOiB1c2luZyBMT0FEL1NUT1JFLWJhc2VkIGZpcm13YXJlLgpzeW0wOiBQQ0kgQlVT IGNsb2NrIHNlZW1zIHRvbyBoaWdoOiA0MDQwMSBLSHouCnN5bTA6IFtHSUFOVC1MT0NLRURdCnBj aTA6IDxuZXR3b3JrLCBldGhlcm5ldD4gYXQgZGV2aWNlIDExLjEgKG5vIGRyaXZlciBhdHRhY2hl ZCkKYXRhcGNpMTogPFNpSSAwNjgwIFVETUExMzMgY29udHJvbGxlcj4gcG9ydCAweDg4MDAtMHg4 ODBmLDB4ODQwMC0weDg0MDMsMHg4MDAwLTB4ODAwNywweDdjMDAtMHg3YzAzLDB4NzgwMC0weDc4 MDcgbWVtIDB4ZTA0MDUwMDAtMHhlMDQwNTBmZiBpcnEgMTkgYXQgZGV2aWNlIDEyLjAgb24gcGNp MAphdGEyOiBjaGFubmVsICMwIG9uIGF0YXBjaTEKYXRhMzogY2hhbm5lbCAjMSBvbiBhdGFwY2kx CmNwdTAgb24gbW90aGVyYm9hcmQKY3B1MSBvbiBtb3RoZXJib2FyZApvcm0wOiA8SVNBIE9wdGlv biBST01zPiBhdCBpb21lbSAweGNlMDAwLTB4Y2U3ZmYsMHhjZDAwMC0weGNkN2ZmLDB4Y2MwMDAt MHhjYzdmZiwweGMwMDAwLTB4YzdmZmYgb24gaXNhMApwbXRpbWVyMCBvbiBpc2EwCmZkYzA6IDxF bmhhbmNlZCBmbG9wcHkgY29udHJvbGxlciAoaTgyMDc3LCBORTcyMDY1IG9yIGNsb25lKT4gYXQg cG9ydCAweDNmNywweDNmMC0weDNmNSBpcnEgNiBkcnEgMiBvbiBpc2EwCnNjMDogPFN5c3RlbSBj b25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0dWFsIGNvbnNv bGVzLCBmbGFncz0weDMwMD4KdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0w eDNkZiBpb21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMAphdGtiZGMwOiA8S2V5Ym9hcmQgY29u dHJvbGxlciAoaTgwNDIpPiBhdCBwb3J0IDB4NjQsMHg2MCBpcnEgMSBvbiBpc2EwCmF0a2JkMDog PEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMwCmtiZDAgYXQgYXRrYmQwCmF0a2JkMDogW0dJ QU5ULUxPQ0tFRF0KYWhjMTogTm8gcmVzb3VyY2VzIGFsbG9hdGVkLgphaGMxOiBObyByZXNvdXJj ZXMgYWxsb2F0ZWQuCnVua25vd246IDxQTlAwYTAzPiBjYW4ndCBhc3NpZ24gcmVzb3VyY2VzIChw b3J0KQpzaW8wOiA8MTY1NTBBLWNvbXBhdGlibGUgQ09NIHBvcnQ+IGF0IHBvcnQgMHgzZjgtMHgz ZmYgaXJxIDQgb24gaXNhMApzaW8wOiB0eXBlIDE2NTUwQQp1bmtub3duOiA8UE5QMDcwMD4gY2Fu J3QgYXNzaWduIHJlc291cmNlcyAocG9ydCkKc2lvMTogPDE2NTUwQS1jb21wYXRpYmxlIENPTSBw b3J0PiBhdCBwb3J0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGlzYTAKc2lvMTogdHlwZSAxNjU1MEEK VGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMTAuMDAwIG1zZWMKYWQwOiAxOTA5Mk1CIDxTVDMyMDQx M0EvMy4zOT4gWzM4NzkyLzE2LzYzXSBhdCBhdGEwLW1hc3RlciBVRE1BMzMKYWQ1OiAxNTI2MjdN QiA8U0FNU1VORyBTUDE2MDROL1RNMTAwLTIzPiBbMzEwMTAxLzE2LzYzXSBhdCBhdGEyLXNsYXZl IFVETUExMDAKYWQ2OiAxOTQ3ME1CIDxRVUFOVFVNIEZJUkVCQUxMbGN0MTAgMjAvQTAzLjA5MDA+ IFszOTU2MC8xNi82M10gYXQgYXRhMy1tYXN0ZXIgVURNQTY2CldhaXRpbmcgMiBzZWNvbmRzIGZv ciBTQ1NJIGRldmljZXMgdG8gc2V0dGxlCihub3BlcmlwaDpzeW0wOjA6LTE6LTEpOiBTQ1NJIEJV UyByZXNldCBkZWxpdmVyZWQuClNNUDogQVAgQ1BVICMxIExhdW5jaGVkIQpNb3VudGluZyByb290 IGZyb20gdWZzOi9kZXYvYWQwczFhCnhsMDogPDNDb20gM2M5MDVDLVRYIEZhc3QgRXRoZXJsaW5r IFhMPiBwb3J0IDB4NjgwMC0weDY4N2YgbWVtIDB4ZTA0MDAwMDAtMHhlMDQwMDA3ZiBpcnEgMTYg YXQgZGV2aWNlIDkuMCBvbiBwY2kwCnhsMDogRXRoZXJuZXQgYWRkcmVzczogMDA6MDE6MDI6YjQ6 ZGU6MmYKeGwwOiBbR0lBTlQtTE9DS0VEXQptaWlidXMwOiA8TUlJIGJ1cz4gb24geGwwCnhscGh5 MDogPDNjOTA1QyAxMC8xMDAgaW50ZXJuYWwgUEhZPiBvbiBtaWlidXMwCnhscGh5MDogIDEwYmFz ZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIGF1dG8KeGwwOiB0cmFu c21pc3Npb24gZXJyb3I6IDkwCnhsMDogdHggdW5kZXJydW4sIGluY3JlYXNpbmcgdHggc3RhcnQg dGhyZXNob2xkIHRvIDEyMCBieXRlcwp4bDA6IHRyYW5zbWlzc2lvbiBlcnJvcjogOTAKeGwwOiB0 eCB1bmRlcnJ1biwgaW5jcmVhc2luZyB0eCBzdGFydCB0aHJlc2hvbGQgdG8gMTgwIGJ5dGVzCg== --Multipart=_Sun__29_Aug_2004_15_59_45_+0200_b4ptC/ltohPxY+v6 Content-Type: application/octet-stream; name="curry_dmesg.out" Content-Disposition: attachment; filename="curry_dmesg.out" Content-Transfer-Encoding: base64 Q29weXJpZ2h0IChjKSAxOTkyLTIwMDQgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDUuMy1CRVRBMSAjMDogU2F0IEF1ZyAyMSAxNjo0MDoxOCBD RVNUIDIwMDQKICAgIHJvb3RAY3Vycnkuc2FsYXRzY2h1ZXNzZWwubmV0Oi91c3Ivb2JqL3Vzci9z cmMvc3lzL0NVUlJZClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVh bGl0eSAwCkNQVTogUGVudGl1bSBJSS9QZW50aXVtIElJIFhlb24vQ2VsZXJvbiAoMzMxLjcxLU1I eiA2ODYtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4NjUwICBT dGVwcGluZyA9IDAKICBGZWF0dXJlcz0weDE4M2Y5ZmY8RlBVLFZNRSxERSxQU0UsVFNDLE1TUixQ QUUsTUNFLENYOCxTRVAsTVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LE1NWCxGWFNSPgpyZWFs IG1lbW9yeSAgPSAyMDEzMjY1OTIgKDE5MiBNQikKYXZhaWwgbWVtb3J5ID0gMTkxNTQxMjQ4ICgx ODIgTUIpCm5weDA6IFtGQVNUXQpucHgwOiA8bWF0aCBwcm9jZXNzb3I+IG9uIG1vdGhlcmJvYXJk Cm5weDA6IElOVCAxNiBpbnRlcmZhY2UKcGNpYjA6IDxJbnRlbCA4MjQ0M0JYICg0NDAgQlgpIGhv c3QgdG8gUENJIGJyaWRnZT4gcGNpYnVzIDAgb24gbW90aGVyYm9hcmQKcGlyMDogPFBDSSBJbnRl cnJ1cHQgUm91dGluZyBUYWJsZTogNSBFbnRyaWVzPiBvbiBtb3RoZXJib2FyZApwY2kwOiA8UENJ IGJ1cz4gb24gcGNpYjAKYWdwMDogPEludGVsIDgyNDQzQlggKDQ0MCBCWCkgaG9zdCB0byBQQ0kg YnJpZGdlPiBtZW0gMHg0NDAwMDAwMC0weDQ3ZmZmZmZmIGF0IGRldmljZSAwLjAgb24gcGNpMApw Y2liMTogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAKcGNpMTogPFBDSSBi dXM+IG9uIHBjaWIxCnBjaTE6IDxkaXNwbGF5LCBWR0E+IGF0IGRldmljZSAwLjAgKG5vIGRyaXZl ciBhdHRhY2hlZCkKZnhwMDogPEludGVsIDgyNTU4IFByby8xMDAgRXRoZXJuZXQ+IHBvcnQgMHgy MDAwLTB4MjAxZiBtZW0gMHg0MDEwMDAwMC0weDQwMWZmZmZmLDB4NDAyMDAwMDAtMHg0MDIwMGZm ZiBpcnEgMTEgYXQgZGV2aWNlIDEwLjAgb24gcGNpMAptaWlidXMwOiA8TUlJIGJ1cz4gb24gZnhw MAppbnBoeTA6IDxpODI1NTUgMTAvMTAwIG1lZGlhIGludGVyZmFjZT4gb24gbWlpYnVzMAppbnBo eTA6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCBhdXRv CmZ4cDA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjA4OmM3OjEzOmU4OmM2CmZ4cDA6IFtHSUFOVC1M T0NLRURdCmlzYWIwOiA8UENJLUlTQSBicmlkZ2U+IGF0IGRldmljZSAyMC4wIG9uIHBjaTAKaXNh MDogPElTQSBidXM+IG9uIGlzYWIwCmF0YXBjaTA6IDxJbnRlbCBQSUlYNCBVRE1BMzMgY29udHJv bGxlcj4gcG9ydCAweDIwNDAtMHgyMDRmLDB4Mzc2LDB4MTcwLTB4MTc3LDB4M2Y2LDB4MWYwLTB4 MWY3IGF0IGRldmljZSAyMC4xIG9uIHBjaTAKYXRhMDogY2hhbm5lbCAjMCBvbiBhdGFwY2kwCmF0 YTE6IGNoYW5uZWwgIzEgb24gYXRhcGNpMAp1aGNpMDogPEludGVsIDgyMzcxQUIvRUIgKFBJSVg0 KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweDIwMjAtMHgyMDNmIGlycSAxMSBhdCBkZXZpY2UgMjAu MiBvbiBwY2kwCnVoY2kwOiBbR0lBTlQtTE9DS0VEXQp1c2IwOiA8SW50ZWwgODIzNzFBQi9FQiAo UElJWDQpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMAp1c2IwOiBVU0IgcmV2aXNpb24gMS4wCnVo dWIwOiBJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIg MQp1aHViMDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKaW50cG0wOiA8 SW50ZWwgODIzNzFBQiBQb3dlciBtYW5hZ2VtZW50IGNvbnRyb2xsZXI+IHBvcnQgMHhmYzAwLTB4 ZmMwZiBpcnEgOSBhdCBkZXZpY2UgMjAuMyBvbiBwY2kwCmludHBtMDogSS9PIG1hcHBlZCBmYzAw CmludHBtMDogaW50ciBJUlEgOSBlbmFibGVkIHJldmlzaW9uIDAKaW50cG0wOiBbR0lBTlQtTE9D S0VEXQppbnRzbWIwOiA8SW50ZWwgUElJWDQgU01CVVMgSW50ZXJmYWNlPiBvbiBpbnRwbTAKc21i dXMwOiA8U3lzdGVtIE1hbmFnZW1lbnQgQnVzPiBvbiBpbnRzbWIwCnNtYjA6IDxTTUJ1cyBnZW5l cmljIEkvTz4gb24gc21idXMwCmludHBtMDogUE0gSS9PIG1hcHBlZCBmODAwIApjcHUwIG9uIG1v dGhlcmJvYXJkCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVtIDB4ZTAwMDAtMHhlN2Zm ZiwweGMwMDAwLTB4YzdmZmYgb24gaXNhMApwbXRpbWVyMCBvbiBpc2EwCmF0a2JkYzA6IDxLZXli b2FyZCBjb250cm9sbGVyIChpODA0Mik+IGF0IHBvcnQgMHg2NCwweDYwIG9uIGlzYTAKYXRrYmQw OiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzAKa2JkMCBhdCBhdGtiZDAKYXRrYmQwOiBb R0lBTlQtTE9DS0VEXQpmZGMwOiA8RW5oYW5jZWQgZmxvcHB5IGNvbnRyb2xsZXIgKGk4MjA3Nywg TkU3MjA2NSBvciBjbG9uZSk+IGF0IHBvcnQgMHgzZjcsMHgzZjAtMHgzZjUgaXJxIDYgZHJxIDIg b24gaXNhMApmZGMwOiBGSUZPIGVuYWJsZWQsIDggYnl0ZXMgdGhyZXNob2xkCmZkMDogPDE0NDAt S0IgMy41IiBkcml2ZT4gb24gZmRjMCBkcml2ZSAwCnBwYzA6IDxQYXJhbGxlbCBwb3J0PiBhdCBw b3J0IDB4Mzc4LTB4MzdmIGlycSA3IG9uIGlzYTAKcHBjMDogU01DLWxpa2UgY2hpcHNldCAoRUNQ L0VQUC9QUzIvTklCQkxFKSBpbiBDT01QQVRJQkxFIG1vZGUKcHBjMDogRklGTyB3aXRoIDE2LzE2 LzggYnl0ZXMgdGhyZXNob2xkCnBwYnVzMDogPFBhcmFsbGVsIHBvcnQgYnVzPiBvbiBwcGMwCmxw dDA6IDxQcmludGVyPiBvbiBwcGJ1czAKbHB0MDogSW50ZXJydXB0LWRyaXZlbiBwb3J0CnNjMDog PFN5c3RlbSBjb25zb2xlPiBhdCBmbGFncyAweDEwMCBvbiBpc2EwCnNjMDogVkdBIDwxNiB2aXJ0 dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4Kc2lvMCBhdCBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0 IGZsYWdzIDB4MTAgb24gaXNhMApzaW8wOiB0eXBlIDE2NTUwQQpzaW8xIGF0IHBvcnQgMHgyZjgt MHgyZmYgaXJxIDMgb24gaXNhMApzaW8xOiB0eXBlIDE2NTUwQQp2Z2EwOiA8R2VuZXJpYyBJU0Eg VkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwCnVu a25vd246IDxQTlAwNDAxPiBjYW4ndCBhc3NpZ24gcmVzb3VyY2VzIChwb3J0KQp1bmtub3duOiA8 UE5QMDUwMT4gY2FuJ3QgYXNzaWduIHJlc291cmNlcyAocG9ydCkKdW5rbm93bjogPFBOUDA1MDE+ IGNhbid0IGFzc2lnbiByZXNvdXJjZXMgKHBvcnQpCnVua25vd246IDxQTlAwNzAwPiBjYW4ndCBh c3NpZ24gcmVzb3VyY2VzIChwb3J0KQpzYmMwOiA8RVNTIEVTMTg2OT4gYXQgcG9ydCAweDMzMC0w eDMzMSwweDM4OC0weDM4YiwweDIyMC0weDIyZiBpcnEgNSBkcnEgMCwxIG9uIGlzYTAKc2JjMDog W0dJQU5ULUxPQ0tFRF0KdW5rbm93bjogPFBOUDAzMDM+IGNhbid0IGFzc2lnbiByZXNvdXJjZXMg KHBvcnQpCnVua25vd246IDxQTlAwYzAyPiBjYW4ndCBhc3NpZ24gcmVzb3VyY2VzIChwb3J0KQp1 bmtub3duOiA8UE5QMGMwMj4gY2FuJ3QgYXNzaWduIHJlc291cmNlcyAocG9ydCkKVGltZWNvdW50 ZXIgIlRTQyIgZnJlcXVlbmN5IDMzMTcwNjk5NSBIeiBxdWFsaXR5IDgwMApUaW1lY291bnRlcnMg dGljayBldmVyeSAxMC4wMDAgbXNlYwphZDA6IDYxNDlNQiA8V0RDIEFDMjY0MDBSLzE3LjAxSjE3 PiBbMTMzMjgvMTUvNjNdIGF0IGF0YTAtbWFzdGVyIFVETUEzMwpNb3VudGluZyByb290IGZyb20g dWZzOi9kZXYvYWQwczFhCg== --Multipart=_Sun__29_Aug_2004_15_59_45_+0200_b4ptC/ltohPxY+v6 Content-Type: application/octet-stream; name="vmstat_NUDEL.bak_1CPU" Content-Disposition: attachment; filename="vmstat_NUDEL.bak_1CPU" Content-Transfer-Encoding: base64 aW50ZXJydXB0ICAgICAgICAgICAgICAgICAgICAgICAgICB0b3RhbCAgICAgICByYXRlCmlycTE6 IGF0a2JkMCAgICAgICAgICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgMAppcnEzOiBzaW8x ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAzICAgICAgICAgIDAKaXJxNDogc2lvMCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgMyAgICAgICAgICAwCmlycTY6IGZkYzAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDQgICAgICAgICAgMAppcnE4OiBydGMgICAgICAgICAgICAgICAg ICAgICAgICAgMTYxNTQxICAgICAgICAxMjcKaXJxMTQ6IGF0YTAgICAgICAgICAgICAgICAgICAg ICAgICAxNTA1NyAgICAgICAgIDExCmlycTE2OiB4bDAgICAgICAgICAgICAgICAgICAgICAgICAg NTE3MDkgICAgICAgICA0MAppcnExNzogYWhjMCAgICAgICAgICAgICAgICAgICAgICAgICAgIDMw ICAgICAgICAgIDAKaXJxMTg6IHN5bTAgICAgICAgICAgICAgICAgICAgICAgICAgICA2MCAgICAg ICAgICAwCmlycTE5OiBhdGFwY2kxICAgICAgICAgICAgICAgICAgICAgICA4MTAgICAgICAgICAg MAppcnEwOiBjbGsgICAgICAgICAgICAgICAgICAgICAgICAgMTI2MjE2ICAgICAgICAgOTkKVG90 YWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDM1NTQzNSAgICAgICAgMjgxCgo= --Multipart=_Sun__29_Aug_2004_15_59_45_+0200_b4ptC/ltohPxY+v6 Content-Type: application/octet-stream; name="vmstat_NUDEL.bak_2CPU" Content-Disposition: attachment; filename="vmstat_NUDEL.bak_2CPU" Content-Transfer-Encoding: base64 aW50ZXJydXB0ICAgICAgICAgICAgICAgICAgICAgICAgICB0b3RhbCAgICAgICByYXRlCmlycTE6 IGF0a2JkMCAgICAgICAgICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgMAppcnEzOiBzaW8x ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAyICAgICAgICAgIDAKaXJxNDogc2lvMCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgMyAgICAgICAgICAwCmlycTY6IGZkYzAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDQgICAgICAgICAgMAppcnE4OiBydGMgICAgICAgICAgICAgICAg ICAgICAgICAgIDM0NTAzICAgICAgICAxMjcKaXJxMTQ6IGF0YTAgICAgICAgICAgICAgICAgICAg ICAgICAgMzE2NiAgICAgICAgIDExCmlycTE2OiB4bDAgICAgICAgICAgICAgICAgICAgICAgICAg ICA2MDggICAgICAgICAgMgppcnExNzogYWhjMCAgICAgICAgICAgICAgICAgICAgICAgICAgIDMw ICAgICAgICAgIDAKaXJxMTg6IHN5bTAgICAgICAgICAgICAgICAgICAgICAgICAgICA2MCAgICAg ICAgICAwCmlycTE5OiBhdGFwY2kxICAgICAgICAgICAgICAgICAgICAgICAxMDAgICAgICAgICAg MAppcnEwOiBjbGsgICAgICAgICAgICAgICAgICAgICAgICAgIDI2OTU4ICAgICAgICAgOTkKVG90 YWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA2NTQzNiAgICAgICAgMjQyCgo= --Multipart=_Sun__29_Aug_2004_15_59_45_+0200_b4ptC/ltohPxY+v6 Content-Type: application/octet-stream; name="vmstat_NUDEL_2CPU" Content-Disposition: attachment; filename="vmstat_NUDEL_2CPU" Content-Transfer-Encoding: base64 aW50ZXJydXB0ICAgICAgICAgICAgICAgICAgICAgICAgICB0b3RhbCAgICAgICByYXRlCmlycTE6 IGF0a2JkMCAgICAgICAgICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgMAppcnEzOiBzaW8x ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAzICAgICAgICAgIDAKaXJxNDogc2lvMCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgMyAgICAgICAgICAwCmlycTY6IGZkYzAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDQgICAgICAgICAgMAppcnE4OiBydGMgICAgICAgICAgICAgICAg ICAgICAgICAgMTk5MzEyICAgICAgICAxMjcKaXJxMTQ6IGF0YTAgICAgICAgICAgICAgICAgICAg ICAgICAxMzg1OSAgICAgICAgICA4CmlycTE2OiB4bDAgICAgICAgICAgICAgICAgICAgICAgICAg MTkzMDEgICAgICAgICAxMgppcnExNzogYWhjMCAgICAgICAgICAgICAgICAgICAgICAgICAgIDMw ICAgICAgICAgIDAKaXJxMTg6IHN5bTAgICAgICAgICAgICAgICAgICAgICAgICAgICA2MCAgICAg ICAgICAwCmlycTE5OiBhdGFwY2kxICAgICAgICAgICAgICAgICAgICAgICAxMjYgICAgICAgICAg MAppcnEwOiBjbGsgICAgICAgICAgICAgICAgICAgICAgICAgMTU1NzI4ICAgICAgICAgOTkKVG90 YWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDM4ODQyOCAgICAgICAgMjQ5Cgo= --Multipart=_Sun__29_Aug_2004_15_59_45_+0200_b4ptC/ltohPxY+v6 Content-Type: application/octet-stream; name="vmstat_NUDEL_1CPU" Content-Disposition: attachment; filename="vmstat_NUDEL_1CPU" Content-Transfer-Encoding: base64 aW50ZXJydXB0ICAgICAgICAgICAgICAgICAgICAgICAgICB0b3RhbCAgICAgICByYXRlCmlycTE6 IGF0a2JkMCAgICAgICAgICAgICAgICAgICAgICAgICAgIDQgICAgICAgICAgMAppcnEzOiBzaW8x ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAyICAgICAgICAgIDAKaXJxNDogc2lvMCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgMyAgICAgICAgICAwCmlycTY6IGZkYzAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDQgICAgICAgICAgMAppcnE4OiBydGMgICAgICAgICAgICAgICAg ICAgICAgICAgMTg1NzMxICAgICAgICAxMjcKaXJxMTQ6IGF0YTAgICAgICAgICAgICAgICAgICAg ICAgICAxNTM4NSAgICAgICAgIDEwCmlycTE2OiB4bDAgICAgICAgICAgICAgICAgICAgICAgICAg NDAxNzIgICAgICAgICAyNwppcnExNzogYWhjMCAgICAgICAgICAgICAgICAgICAgICAgICAgIDMw ICAgICAgICAgIDAKaXJxMTg6IHN5bTAgICAgICAgICAgICAgICAgICAgICAgICAgICA2MCAgICAg ICAgICAwCmlycTE5OiBhdGFwY2kxICAgICAgICAgICAgICAgICAgICAgICA2NzAgICAgICAgICAg MAppcnEwOiBjbGsgICAgICAgICAgICAgICAgICAgICAgICAgMTQ1MTE2ICAgICAgICAgOTkKVG90 YWwgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDM4NzE3NyAgICAgICAgMjY2Cgo= --Multipart=_Sun__29_Aug_2004_15_59_45_+0200_b4ptC/ltohPxY+v6-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 14:10:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 036AA16A4CE for ; Sun, 29 Aug 2004 14:10:45 +0000 (GMT) Received: from web50601.mail.yahoo.com (web50601.mail.yahoo.com [206.190.38.88]) by mx1.FreeBSD.org (Postfix) with SMTP id B62A043D45 for ; Sun, 29 Aug 2004 14:10:44 +0000 (GMT) (envelope-from kstailey@yahoo.com) Message-ID: <20040829141044.98464.qmail@web50601.mail.yahoo.com> Received: from [69.138.247.171] by web50601.mail.yahoo.com via HTTP; Sun, 29 Aug 2004 07:10:44 PDT Date: Sun, 29 Aug 2004 07:10:44 -0700 (PDT) From: Kenneth Stailey To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 14:10:45 -0000 Hi, Can a one-line example of how to invoke adduser to add new accounts like "proxy" be added to /usr/src/UPDATING? That way people could just cut-and-paste the accounts into place when upgrading. Thanks, Ken From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 14:19:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8463316A4CE for ; Sun, 29 Aug 2004 14:19:47 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07E5143D45 for ; Sun, 29 Aug 2004 14:19:46 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i7TEJgs5024633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Aug 2004 18:19:42 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i7TEJfZ3024632; Sun, 29 Aug 2004 18:19:41 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Sun, 29 Aug 2004 18:19:41 +0400 From: Gleb Smirnoff To: Kenneth Stailey Message-ID: <20040829141941.GA24612@cell.sick.ru> References: <20040829141044.98464.qmail@web50601.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040829141044.98464.qmail@web50601.mail.yahoo.com> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 14:19:47 -0000 On Sun, Aug 29, 2004 at 07:10:44AM -0700, Kenneth Stailey wrote: K> Can a one-line example of how to invoke adduser to add new accounts like K> "proxy" be added to /usr/src/UPDATING? That way people could just K> cut-and-paste the accounts into place when upgrading. If you run mergemaster when updating, you can easily merge these lines. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 14:21:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93D7E16A4E4; Sun, 29 Aug 2004 14:21:25 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86C4B43D5A; Sun, 29 Aug 2004 14:21:24 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7TELFdd045353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Aug 2004 17:21:16 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i7TELK7m023302; Sun, 29 Aug 2004 17:21:20 +0300 (EEST) (envelope-from ru) Date: Sun, 29 Aug 2004 17:21:17 +0300 From: Ruslan Ermilov To: Wilko Bulte Message-ID: <20040829142117.GB23120@ip.net.ua> References: <20040824183019.GA82339@freebie.xs4all.nl> <20040826154743.GC15146@mathematik.uni-bielefeld.de> <20040828095802.GA27015@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bAmEntskrkuBymla" Content-Disposition: inline In-Reply-To: <20040828095802.GA27015@freebie.xs4all.nl> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: alpha@freebsd.org cc: current@freebsd.org cc: Konstantin Saurbier Subject: Re: 5.3-BETA1 for Alpha available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 14:21:25 -0000 --bAmEntskrkuBymla Content-Type: multipart/mixed; boundary="jho1yZJdad60DJr+" Content-Disposition: inline --jho1yZJdad60DJr+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Wilko, On Sat, Aug 28, 2004 at 11:58:02AM +0200, Wilko Bulte wrote: > Hi, >=20 > DES reported problems with BETA1 on his PWS (aka Miata). >=20 > I would very much appreciate it if another PWS owner > can check if he/she is experiencing the same issues. >=20 > Test status can be found at: >=20 > http://people.freebsd.org/~wilko/testhw.html >=20 My Alpha PC AXPpci33, 166MHz installed and boots fine with 5.3-BETA1. The dmesg.boot file is attached. Please mark my entry in blue. ;) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --jho1yZJdad60DJr+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot" Content-Transfer-Encoding: quoted-printable Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...22 22 17 16 1 0 0 0 done No buffers busy after final sync Uptime: 16m11s GDB: debug ports: sio GDB: current port: sio KDB: debugger backends: ddb gdb KDB: current backend: ddb Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-BETA1 #0: Mon Aug 23 22:50:09 UTC 2004 root@ds10.wbnet:/usr/obj/usr/src/sys/GENERIC DEC AXPpci Alpha PC AXPpci33, 166MHz 8192 byte page size, 1 processor. CPU: LCA Family major=3D4 minor=3D2 OSF PAL rev: 0x100090002012d real memory =3D 48259072 (46 MB) avail memory =3D 36995072 (35 MB) lca0: <21066 Core Logic chipset> pcib0: <21066 PCI host bus adapter> on lca0 pci0: on pcib0 sym0: <810> port 0x10100-0x101ff mem 0x81000100-0x810001ff at device 6.0 on= pci0 sym0: No NVRAM, ID 7, Fast-10, SE, parity checking sym0: interrupting at ISA irq 11 sym0: [GIANT-LOCKED] isab0: at device 7.0 on pci0 isa0: on isab0 rl0: port 0x10000-0x100ff mem 0x81000000-0x8100= 00ff at device 8.0 on pci0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:50:fc:f7:4f:7f rl0: interrupting at ISA irq 5 rl0: [GIANT-LOCKED] ata0 at port 0x3f6,0x1f0-0x1f7 irq 14 on isa0 ata0: interrupting at ISA irq 14 ata1 at port 0x376,0x170-0x177 irq 15 on isa0 ata1: interrupting at ISA irq 15 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 atkbd0: interrupting at ISA irq 1 atkbd0: [GIANT-LOCKED] fdc0: at port 0x3f7= ,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: interrupting at ISA irq 6 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 mcclock0: at port 0x70-0x71 on isa0 ppc0: at port 0x3bc-0x3c3 irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Polled port ppi0: on ppbus0 ppc0: interrupting at ISA irq 7 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio0: interrupting at ISA irq 4 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1 at port 0x2f8-0x2ff irq 3 flags 0x80 on isa0 sio1: type 16550A sio1: interrupting at ISA irq 3 Timecounter "i8254" frequency 1193182 Hz quality 0 Timecounter "alpha" frequency 166825858 Hz quality 0 Timecounters tick every 0.976 msec Waiting 15 seconds for SCSI devices to settle cd0 at sym0 bus 0 target 3 lun 0 cd0: Removable CD-ROM SCSI-2 device=20 cd0: 10.000MB/s transfers (10.000MHz, offset 8) cd0: cd present [141282 x 2048 byte records] da0 at sym0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device=20 da0: 10.000MB/s transfers (10.000MHz, offset 8), Tagged Queueing Enabled da0: 4357MB (8925000 512 byte sectors: 255H 63S/T 555C) Mounting root from ufs:/dev/da0a --jho1yZJdad60DJr+-- --bAmEntskrkuBymla Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBMeZdqRfpzJluFF4RAiZgAJ4oq0uxXsnv7GqSfNDKjMV1vTPLzQCfbdqe bpx1nBlFv+rEYGzOEf+Ly10= =WX+h -----END PGP SIGNATURE----- --bAmEntskrkuBymla-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 14:21:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 307CE16A4CE for ; Sun, 29 Aug 2004 14:21:52 +0000 (GMT) Received: from tensor.xs4all.nl (tensor.xs4all.nl [194.109.160.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6D6C43D41 for ; Sun, 29 Aug 2004 14:21:51 +0000 (GMT) (envelope-from dimitry@andric.com) Received: from kilgore.dim (kilgore.dim [192.168.0.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by tensor.xs4all.nl (Postfix) with ESMTP id AEC4722852; Sun, 29 Aug 2004 16:21:48 +0200 (CEST) Date: Sun, 29 Aug 2004 16:21:39 +0200 From: Dimitry Andric X-Mailer: The Bat! (v2.12.03) Business X-Priority: 3 (Normal) Message-ID: <1866585516.20040829162139@andric.com> To: Kenneth Stailey In-Reply-To: <20040829141044.98464.qmail@web50601.mail.yahoo.com> References: <20040829141044.98464.qmail@web50601.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha1"; boundary="----------4510F02D7026BE" cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 14:21:52 -0000 ------------4510F02D7026BE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On 2004-08-29 at 16:10:44 Kenneth Stailey wrote: > Can a one-line example of how to invoke adduser to add new accounts like > "proxy" be added to /usr/src/UPDATING? That way people could just > cut-and-paste the accounts into place when upgrading. This is what "mergemaster -p" is for, as is already stated under the 20040308 and 20040623 entries in UPDATING. In general, you should always run this before attempting to install the world. ------------4510F02D7026BE Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: GnuPG v1.2.4 (MingW32) iD8DBQFBMeZzsF6jCi4glqMRAgZ7AJ9oc+tmU89pcgafdmhwXJRVO5yWFwCg4fb4 UUBBz7WbHIpEfL+nd5chHdU= =sLHF -----END PGP MESSAGE----- ------------4510F02D7026BE-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 14:25:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8A6A16A4CE; Sun, 29 Aug 2004 14:25:06 +0000 (GMT) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6811143D1F; Sun, 29 Aug 2004 14:25:06 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i7TEP41u022693; Sun, 29 Aug 2004 10:25:05 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: <200408271337.i7RDbXgu052801@pooker.samsco.org> Date: Sun, 29 Aug 2004 10:25:04 -0400 To: re@freebsd.org, current@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) Subject: Re: 5.3-RELEASE TODO - make/kqueue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 14:25:07 -0000 At 8:05 PM -0400 8/28/04, Garance A Drosihn wrote: >At 7:37 AM -0600 8/27/04, Scott Long wrote: >> >>Testing focuses for 5.3-RELEASE > >And update on Issue: > >> |---------------------------------+ >> | make -DUSE_KQUEUE causes lockup | >> | with buildworld -jBIGNUM | >> |---------------------------------+ > >I have done many buildworlds using the WITH_KQUEUE make over the >past week. I have done at least 50 buildworlds in my dual-proc >Althon machine, with -j ranging from 3 to 15. I have not seen >any lockups since the fix for IPI deadlocks went in. > >I do still get the "*** Signal 6"s, ... I should also point out that I get those same Signal 6's with `make' compiled without KQUEUE, so the problem is not with KQUEUE itself. So while I do think there is *some* subtle bug that is still lurking around, I suspect that the issue about KQUEUE and `make' can probably be crossed off the to-do list. That's my experience, at least. YMMV, etc. >... I just now realized that I ended up with 1.76... I guess >I should try it one more time with 1.75 instead of 1.76. I can still generate the bogus Signal 6's with version 1.75. >This failure is "eventually repeatable" for me, in that I can >trigger it within 10 buildworlds. And *seems* that it only >happens if I am also running a "folding-at-home" client at the >same time. That client program is a Linux ELF binary, so maybe >that is significant. Or maybe it's a red herring. Another variable that is perhaps worth noting is that I am still running SCHED_4BSD. This is on a snapshot of 6.x-current from sometime last Thursday afternoon, except for changing the version of src/sys/kern/kern_lock.c . -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 14:34:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A01D16A4D0 for ; Sun, 29 Aug 2004 14:34:05 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56F4943D45 for ; Sun, 29 Aug 2004 14:34:04 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7TEXwCD045521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Aug 2004 17:33:59 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i7TEY4Mt023466; Sun, 29 Aug 2004 17:34:04 +0300 (EEST) (envelope-from ru) Date: Sun, 29 Aug 2004 17:34:03 +0300 From: Ruslan Ermilov To: Barry Bouwsma Message-ID: <20040829143403.GE23120@ip.net.ua> References: <200408281700.i7SH0Q700992@Mail.NOSPAM.DynDNS.dK> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tmoQ0UElFV5VgXgH" Content-Disposition: inline In-Reply-To: <200408281700.i7SH0Q700992@Mail.NOSPAM.DynDNS.dK> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: current@FreeBSD.org Subject: Re: M*K**BJD*RPR*F*X and make.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 14:34:05 -0000 --tmoQ0UElFV5VgXgH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 28, 2004 at 07:00:26PM +0200, Barry Bouwsma wrote: > Hi. You're going to hate me by the end of this message, > in the unlikely chance that you don't hate me already. >=20 > If I'm reading the failure of my attempted crossbuild of > FreeBSD5 on my FBSD-4 machine, the check in Makefile.inc1 > is not looking in the right __MAKE_CONF, which I've tried > specifying both as environment and make-option to cover > all bases. >=20 > Instead, it's looking in /etc/make.conf, which as far as I know > is never used during my crossbuild (I hope), and where as far as > I know it's still not expressly forbidden to use M*K**BJetc ?=3D foo > at the present time under 4.x ... >=20 No, you misinterpreted the check (please see below). [...] > (to rehash a previous thread, here's another reason I liked to be > able to specify M*K**BJD*RPR*F*X in a make.conf, is in order to > automagically get a different obj directory for each build, by > evaluating `uname' and `date' and whatnot, which now requires an > each-time invocation as environment, unlike the set-and-forget in > a suitable make.conf. no, I haven't tried my hand at suitably > replacing this (mis)feature in an acceptable way yet) >=20 Repeat ten times today: MAKEOBJDIRPREFIX is an environment variable, and works properly only if set as environment variable, not as a command-line variable or a global variable (in /etc/make.conf). This is now documented in the following sources: - make(1) manpage - make.conf(5) manpage - /usr/share/mk/bsd.obj.mk - anti-footshooting measure in /usr/src/Makefile Rumors are that this is probably now the best documented feature of BSD make(1). ;) [...] > I fully understand that you hate me now. >=20 I will hate you if, after reading these, you still disagree. ;) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --tmoQ0UElFV5VgXgH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBMelbqRfpzJluFF4RAtmDAJ9c92yMfsz2u0oodmH8KtgV3uawVgCffbNm KsJ3YxFufB7laZbbamfev7k= =gHMh -----END PGP SIGNATURE----- --tmoQ0UElFV5VgXgH-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 14:35:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E413716A4CF; Sun, 29 Aug 2004 14:35:45 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AAC943D46; Sun, 29 Aug 2004 14:35:45 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 7B4B0ACAFE; Sun, 29 Aug 2004 16:35:43 +0200 (CEST) Date: Sun, 29 Aug 2004 16:35:43 +0200 From: Pawel Jakub Dawidek To: FreeBSD Tinderbox Message-ID: <20040829143543.GX30151@darkness.comp.waw.pl> References: <20040829091547.927B07303F@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vLS+sh2tCBRapC7G" Content-Disposition: inline In-Reply-To: <20040829091547.927B07303F@freebsd-current.sentex.ca> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: current@freebsd.org cc: ia64@freebsd.org Subject: Re: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 14:35:46 -0000 --vLS+sh2tCBRapC7G Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 29, 2004 at 05:15:47AM -0400, FreeBSD Tinderbox wrote: +> cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-e= xterns -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -= Wcast-qual -fformat-extensions -std=3Dc99 -nostdinc -I- -I. -I/tinderbox= /CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/d= ev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/= CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/s= rc/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I= /tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/C= URRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/s= ys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -fin= line-limit=3D15000 --param inline-unit-growth=3D100 --param large-function-= growth=3D1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=3Df32-f1= 27 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/= geom/mirror/g_mirror.c +> /tinderbox/CURRENT/ia64/ia64/src/sys/geom/mirror/g_mirror.c: In function= `g_mirror_taste': +> /tinderbox/CURRENT/ia64/ia64/src/sys/geom/mirror/g_mirror.c:2485: warnin= g: 'sc' might be used uninitialized in this function +> *** Error code 1 Fixed, sorry. PS. Can someone show me which compiler flag expose those "bugs"? --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --vLS+sh2tCBRapC7G Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBMem/ForvXbEpPzQRAnXrAKDJg/X+xCZKcGccXeuAKl80/IB4pgCcD8iQ +SbuLwcWTDvmulImR9uSnaI= =gr+v -----END PGP SIGNATURE----- --vLS+sh2tCBRapC7G-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 14:44:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C98B316A4CF for ; Sun, 29 Aug 2004 14:44:02 +0000 (GMT) Received: from mail2.neureal.com (mail2.neureal.com [66.98.170.78]) by mx1.FreeBSD.org (Postfix) with SMTP id 6B34D43D5F for ; Sun, 29 Aug 2004 14:44:02 +0000 (GMT) (envelope-from quaggamail@quaggaspace.org) Received: (qmail 29712 invoked by uid 399); 29 Aug 2004 14:44:01 -0000 Received: from unknown (HELO ?192.168.42.25?) (68.162.100.90) by mail2.neureal.com with SMTP; 29 Aug 2004 14:44:01 -0000 From: Justin Settle To: Chris Laverdure In-Reply-To: <1093742244.3464.1.camel@elemental.DashEvil> References: <1093754957.564.24.camel@amon.quaggaspace.org> <1093742244.3464.1.camel@elemental.DashEvil> Content-Type: text/plain Message-Id: <1093790664.562.3.camel@amon.quaggaspace.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 29 Aug 2004 10:44:24 -0400 Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: APIC causes vr0 watchdog timeouts and Interrupt storms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 14:44:02 -0000 On Sat, 2004-08-28 at 21:17, Chris Laverdure wrote: > On Sun, 2004-08-29 at 04:49, Justin Settle wrote: > > Hello, > > > > I recently installed 5.3-BETA. After booting, I found was unable to use > > my usb mouse or my ethernet (Via-rhine). I started tinkering with the > > kernel and found that if I disabled APIC, this system worked without > > ethernet issues or mouse isssues. After talking with some people they > > suggested I post boot -v, dmesg's of the different kernels so here they > > are: > > > > The first thing I tried was a GENERIC with SMP commented out. It had > > the same issues as GENERIC: > > > ... > > ACPI is on both of these kernels but I've tried both without and the > > results are the same. Should any other information be needed/wanted > > I'll be sure to reply. Thank you for your time. > > > > Jay Settle > > > > I too cannot use my USB mouse with ACPI enabled (yet it works fine > without it). I get a Interrupt Storm when usbd tries to come up, and > then moused fails claiming an "Input/Output error on /dev/ums0". > > I would love to get to the bottom of this. > Just to clarify, my problem isn't with ACPI, its with APIC :). My machine actually works fine with ACPI on (its on at the moment). If I boot it with APIC, however, things go downhill. Jay Settle From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 14:45:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64F1516A4CE for ; Sun, 29 Aug 2004 14:45:31 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9117143D3F for ; Sun, 29 Aug 2004 14:45:30 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i7TEjSpa024831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 29 Aug 2004 18:45:29 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i7TEjS6R024830 for current@freebsd.org; Sun, 29 Aug 2004 18:45:28 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Sun, 29 Aug 2004 18:45:28 +0400 From: Gleb Smirnoff To: current@freebsd.org Message-ID: <20040829144528.GA24815@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: "witness exhausted" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 14:45:31 -0000 What does this message actually mean? I get it on boot after upgrade. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 14:54:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6278416A4CE for ; Sun, 29 Aug 2004 14:54:48 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9079A43D41 for ; Sun, 29 Aug 2004 14:54:47 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i7TEskQa024867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 29 Aug 2004 18:54:46 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i7TEsjnm024866 for current@freebsd.org; Sun, 29 Aug 2004 18:54:45 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Sun, 29 Aug 2004 18:54:45 +0400 From: Gleb Smirnoff To: current@freebsd.org Message-ID: <20040829145445.GB24815@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: mutex Giant not owned at /usr/src/sys/kern/vfs_vnops.c:120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 14:54:48 -0000 #21 0xc055ecc0 in kdb_enter (msg=0x0) at cpufunc.h:56 #22 0xc0542dd5 in panic (fmt=0xc06dd9db "mutex %s not owned at %s:%d") at /usr/src/sys/kern/kern_shutdown.c:536 #23 0xc053914c in _mtx_assert (m=0xc07402a0, what=0, file=0xc06e6fbd "/usr/src/sys/kern/vfs_vnops.c", line=120) at /usr/src/sys/kern/kern_mutex.c:736 #24 0xc05b165c in vn_open_cred (ndp=0xd0aafaa0, flagp=0xd0aaf97c, cmode=0, cred=0xc1ad1300, fdidx=0) at /usr/src/sys/kern/vfs_vnops.c:120 #25 0xc05b1613 in vn_open (ndp=0x0, flagp=0x0, cmode=0, fdidx=0) at /usr/src/sys/kern/vfs_vnops.c:91 #26 0xc05343a0 in linker_hints_lookup ( path=0xc0714020 "/boot/kernel;/boot/modules", pathlen=12, modname=0xd0aafb74 "ng_tee", modnamelen=6, verinfo=0x0) at /usr/src/sys/kern/kern_linker.c:1473 #27 0xc0534947 in linker_search_module (modname=0xd0aafb74 "ng_tee", modnamelen=6, verinfo=0x0) at /usr/src/sys/kern/kern_linker.c:1593 #28 0xc0534b19 in linker_load_module (kldname=0x0, modname=0xd0aafb74 "ng_tee", parent=0x0, verinfo=0x0, lfpp=0xd0aafb70) at /usr/src/sys/kern/kern_linker.c:1682 *** these "??" should be: ngc_send() in /usr/src/sys/netgraph/ng_socket.c #29 0xc1b71d17 in ?? () #30 0x00000000 in ?? () #31 0xd0aafb74 in ?? () #32 0x00000000 in ?? () #33 0x00000000 in ?? () #34 0xd0aafb70 in ?? () #35 0xc1ae6c38 in ?? () #36 0x00000000 in ?? () #37 0xc1789080 in ?? () #38 0xc06dd88c in ?? () #39 0x745f676e in ?? () #40 0xc1006565 in ?? () #41 0xd0aafc48 in ?? () #42 0xd0aafcbc in ?? () #43 0xc0548b25 in uiomove (cp=0xc17a8654, n=0, uio=0xc1692140) at /usr/src/sys/kern/kern_subr.c:164 #44 0xc0585621 in sosend (so=0xc17a8654, addr=0xc156a5d0, uio=0xd0aafc48, top=0xc1609300, control=0x0, flags=0, td=0xc173d840) at /usr/src/sys/kern/uipc_socket.c:799 #45 0xc058c0ac in kern_sendit (td=0xc173d840, s=3, mp=0xd0aafcc4, flags=0, control=0x0) at /usr/src/sys/kern/uipc_syscalls.c:738 #46 0xc058bf3b in sendit (td=0x0, s=0, mp=0xd0aafcc4, flags=0) at /usr/src/sys/kern/uipc_syscalls.c:682 #47 0xc058c22b in sendto (td=0x0, uap=0x0) at /usr/src/sys/kern/uipc_syscalls.c:795 #48 0xc0697c50 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077946376, tf_esi = -1077946382, tf_ebp = -1077945832, tf_isp = -794100364, tf_ebx = 671649088, tf_edx = -1077946384, tf_ecx = 5, tf_eax = 133, tf_trapno = 12, tf_err = 2, tf_eip = 671984639, tf_cs = 31, tf_eflags = 514, tf_esp = -1077946452, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1004 #49 0xc06851bf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:201 -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 14:56:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F3DB16A4CE; Sun, 29 Aug 2004 14:56:03 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BFAC43D4C; Sun, 29 Aug 2004 14:56:02 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7TEtwXL045876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Aug 2004 17:55:59 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i7TEu37H023621; Sun, 29 Aug 2004 17:56:03 +0300 (EEST) (envelope-from ru) Date: Sun, 29 Aug 2004 17:56:03 +0300 From: Ruslan Ermilov To: Pawel Jakub Dawidek Message-ID: <20040829145603.GG23120@ip.net.ua> References: <20040829091547.927B07303F@freebsd-current.sentex.ca> <20040829143543.GX30151@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtJ+CqYNzKB4ukR4" Content-Disposition: inline In-Reply-To: <20040829143543.GX30151@darkness.comp.waw.pl> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: ia64@freebsd.org cc: FreeBSD Tinderbox cc: current@freebsd.org Subject: Re: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 14:56:03 -0000 --vtJ+CqYNzKB4ukR4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 29, 2004 at 04:35:43PM +0200, Pawel Jakub Dawidek wrote: > On Sun, Aug 29, 2004 at 05:15:47AM -0400, FreeBSD Tinderbox wrote: > +> cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested= -externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline= -Wcast-qual -fformat-extensions -std=3Dc99 -nostdinc -I- -I. -I/tinderb= ox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib= /dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbo= x/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64= /src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath = -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox= /CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src= /sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -f= inline-limit=3D15000 --param inline-unit-growth=3D100 --param large-functio= n-growth=3D1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=3Df32-= f127 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sy= s/geom/mirror/g_mirror.c > +> /tinderbox/CURRENT/ia64/ia64/src/sys/geom/mirror/g_mirror.c: In functi= on `g_mirror_taste': > +> /tinderbox/CURRENT/ia64/ia64/src/sys/geom/mirror/g_mirror.c:2485: warn= ing: 'sc' might be used uninitialized in this function > +> *** Error code 1 >=20 > Fixed, sorry. >=20 > PS. Can someone show me which compiler flag expose those "bugs"? >=20 I believe it's -O2 (which is not in default CFLAGS). Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --vtJ+CqYNzKB4ukR4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBMe6DqRfpzJluFF4RAl8CAJ9xkDoSrMC+5WlYc6WYD3iYvS1RdQCfTabX xtMYmMgTUmvySdo7YPtdokQ= =Qujn -----END PGP SIGNATURE----- --vtJ+CqYNzKB4ukR4-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 14:59:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F0D616A4CF; Sun, 29 Aug 2004 14:59:21 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D44A43D49; Sun, 29 Aug 2004 14:59:21 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id F1E5FACAF1; Sun, 29 Aug 2004 16:59:19 +0200 (CEST) Date: Sun, 29 Aug 2004 16:59:19 +0200 From: Pawel Jakub Dawidek To: Ruslan Ermilov Message-ID: <20040829145919.GY30151@darkness.comp.waw.pl> References: <20040829091547.927B07303F@freebsd-current.sentex.ca> <20040829143543.GX30151@darkness.comp.waw.pl> <20040829145603.GG23120@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vowh9qpYCOVF+x5F" Content-Disposition: inline In-Reply-To: <20040829145603.GG23120@ip.net.ua> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: ia64@freebsd.org cc: FreeBSD Tinderbox cc: current@freebsd.org Subject: Re: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 14:59:21 -0000 --vowh9qpYCOVF+x5F Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 29, 2004 at 05:56:03PM +0300, Ruslan Ermilov wrote: +> On Sun, Aug 29, 2004 at 04:35:43PM +0200, Pawel Jakub Dawidek wrote: +> > On Sun, Aug 29, 2004 at 05:15:47AM -0400, FreeBSD Tinderbox wrote: +> > +> cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnes= ted-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winl= ine -Wcast-qual -fformat-extensions -std=3Dc99 -nostdinc -I- -I. -I/tind= erbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/cont= rib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinde= rbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/i= a64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/a= th -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinder= box/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/= src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common= -finline-limit=3D15000 --param inline-unit-growth=3D100 --param large-func= tion-growth=3D1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=3Df= 32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src= /sys/geom/mirror/g_mirror.c +> > +> /tinderbox/CURRENT/ia64/ia64/src/sys/geom/mirror/g_mirror.c: In fun= ction `g_mirror_taste': +> > +> /tinderbox/CURRENT/ia64/ia64/src/sys/geom/mirror/g_mirror.c:2485: w= arning: 'sc' might be used uninitialized in this function +> > +> *** Error code 1 +> >=20 +> > Fixed, sorry. +> >=20 +> > PS. Can someone show me which compiler flag expose those "bugs"? +> >=20 +> I believe it's -O2 (which is not in default CFLAGS). Nope, it was tested with -O2. I made such breakage before, I think, and it was only exposed on non-i386 archs, AFAIR. Why? Where is the difference? --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --vowh9qpYCOVF+x5F Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBMe9HForvXbEpPzQRAjf5AJ0fgGqe7zMJU+zg8U1s8HTdBjD4CACfdOW4 wWkbwhS/b5+sM+F+GFMHjTk= =d0l2 -----END PGP SIGNATURE----- --vowh9qpYCOVF+x5F-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 15:00:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22F7216A4CE; Sun, 29 Aug 2004 15:00:26 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0B9643D1F; Sun, 29 Aug 2004 15:00:25 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smtp3.sentex.ca (8.13.1/8.13.1) with ESMTP id i7TF0Jdm073534; Sun, 29 Aug 2004 11:00:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7TF0LgS032104; Sun, 29 Aug 2004 11:00:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A7CB47303F; Sun, 29 Aug 2004 11:00:21 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040829150021.A7CB47303F@freebsd-current.sentex.ca> Date: Sun, 29 Aug 2004 11:00:21 -0400 (EDT) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 15:00:26 -0000 TB --- 2004-08-29 13:36:55 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-29 13:36:55 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-08-29 13:36:55 - checking out the source tree TB --- 2004-08-29 13:36:55 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2004-08-29 13:36:55 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-29 13:42:02 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-29 13:42:02 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-08-29 13:42:02 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-29 14:46:11 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-29 14:46:11 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-08-29 14:46:11 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Aug 29 14:46:11 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Aug 29 15:00:20 UTC 2004 TB --- 2004-08-29 15:00:20 - generating LINT kernel config TB --- 2004-08-29 15:00:20 - cd /home/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2004-08-29 15:00:20 - /usr/bin/make -B LINT TB --- 2004-08-29 15:00:20 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-29 15:00:20 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-08-29 15:00:20 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 29 15:00:20 UTC 2004 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf; PATH=/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/sbin:/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/bin:/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/legacy/usr/games:/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/sbin:/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/bin:/home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/LINT /tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf/LINT /tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf/LINT: unknown option "HW_WDOG" *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-08-29 15:00:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-29 15:00:21 - ERROR: failed to build lint kernel TB --- 2004-08-29 15:00:21 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 15:10:26 2004 Return-Path: Delivered-To: freebsd-current@mx1.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A41FC16A4D8 for ; Sun, 29 Aug 2004 15:10:26 +0000 (GMT) Received: from bobbi.cse.buffalo.edu (bobbi.cse.Buffalo.EDU [128.205.32.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0884D43D48 for ; Sun, 29 Aug 2004 15:10:25 +0000 (GMT) (envelope-from kensmith@FreeBSD.org) Received: from bobbi.cse.buffalo.edu (localhost.cs.Buffalo.EDU [127.0.0.1]) by bobbi.cse.buffalo.edu (8.13.1/8.12.4) with ESMTP id i7TFAMUd043691 for ; Sun, 29 Aug 2004 11:10:22 -0400 (EDT) Received: (from kensmith@localhost) by bobbi.cse.buffalo.edu (8.13.1/8.13.1/Submit) id i7TFALtu043690 for freebsd-current@freebsd.org; Sun, 29 Aug 2004 11:10:21 -0400 (EDT) (envelope-from kensmith) Date: Sun, 29 Aug 2004 11:10:21 -0400 From: Ken Smith To: freebsd-current@FreeBSD.org Message-ID: <20040829151021.GA43674@bobbi.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: FreeBSD 5.3-BETA2 Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 15:10:26 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The FreeBSD Release Engineering Team is proud to announce the=20 availability of FreeBSD 5.3-BETA2. This is the second BETA of the 5.3 release cycle. It is intended for early adopters and those wishing to help find and/or fix bugs. The 5.3 release cycle will continue with weekly BETA builds while bugs are being fixed and features finalized. The schedule is at http://www.freebsd.org/releases/5.3R/schedule.html. Be sure to check the "Known issues" below, there are known problems still being worked on at this time. Fixes made since BETA1: - IPI fix, this should resolve the SMP problems reported in the BETA1 release notes. - Many tweaks to network stack locking. - Alpha boot loader fixed. - Misc. acpi fixes. - Fix to agp handling that prevented pc98 from building. - TLS fix for static threaded programs. - Netgraph modules built for all architectures. - twa(4) support on amd64. - lnc(4) fix that allows FreeBSD to access the network interface inside VMWare. Known issues in this release: - There are scattered reports of data corruption on SMP systems under high load. This could be due to a known bug in the gvinum subsystem, but it could be due to unknown factors. We are investigating this and hope to correct it soon. - debug.mpsafenet (multi-processor safe network stack) is still turned off by default for BETA2 but will be turned on for BETA3. Testers are encouraged to experiment with turning it on manually to get some early feedback. - pst(4) is known to cause a system panic during the boot time. - Configuring X11 in sysinstall does not work. Just wait until the system is running after the installation finishes to configure the X-windows system. If you use disc1 the X.org packages will have been installed but not configured. See the xorg(1) manual for details (running 'Xorg -configure' may be all it takes). - The Synaptics Touchpad mouse support is known to have issues with responsiveness. It can be disabled with 'hint.psm.0.flags=3D"0x200"' in "/boot/device.hints". This will be resolved for the release. - On sparc64 only, there is a problem using ATA devices in DMA mode. The loader has been temporarily set up to disable DMA in the ATA device driver. The problem has been identified but a fix is still in the works. - Kernel debugging aids (INVARIANTS, WITNESS, etc) are still enabled so do not use this BETA as an indication of speed. A complete list of defects that will be fixed for the release can be found at http://www.freebsd.org/releases/5.3R/todo.html. Availability: For people wishing to upgrade older systems using cvsup(1) and the procedure described in src/UPDATING the CVS tag to use is RELENG_5 at this point. Note that like all RELENG_X branches this is an active development branch. We do not recommend those branches for normal use (for normal use RELENG_X_Y branches are more appropriate, e.g. RELENG_4_10 is the current stable branch). As of this writing: i386: available on most mirror sites, miniinst and disc1 but disc1 package set missing a few packages sparc64: build complete, available on many mirror sites, miniinst only Builds for the other architectures are in varying stages, they should be posted through the next few days. MD5s for the builds that are complete at this time are: MD5 (5.3-BETA2-i386-bootonly.iso) =3D 71a9a573d5592cb4f689da2c19e462dd MD5 (5.3-BETA2-i386-disc1.iso) =3D 94a2e0839e4a02a4361059c964c592d6 MD5 (5.3-BETA2-i386-disc2.iso) =3D 45765c7c1e5bbe592e9e38a0fc0935d1 MD5 (5.3-BETA2-i386-miniinst.iso) =3D 5bc609d1304e6d256b5ac3fae33a0aa0 MD5 (5.3-BETA2-sparc64-bootonly.iso) =3D 7790bdd2c7e4d2779246fc0e1ef1= 15a5 MD5 (5.3-BETA2-sparc64-disc2.iso) =3D 819c4efc64fc066a56a49ba034410f85 MD5 (5.3-BETA2-sparc64-miniinst.iso) =3D edf1b370a86e11b0629a4ac17dc2= 9da1 -ken --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBMfHb/G14VSmup/YRAuQxAJ9NzR45N/wg4kpKkdPLmPew701HZACghOLF FmcDw5TcC5XmLrQk+nAtv4c= =lRqw -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 15:13:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 441FD16A4CE; Sun, 29 Aug 2004 15:13:32 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8011643D2F; Sun, 29 Aug 2004 15:13:31 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7TFDQFx046230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Aug 2004 18:13:27 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i7TFDVwU023938; Sun, 29 Aug 2004 18:13:31 +0300 (EEST) (envelope-from ru) Date: Sun, 29 Aug 2004 18:13:31 +0300 From: Ruslan Ermilov To: Garance A Drosihn , John-Mark Gurney , Brian Feldman Message-ID: <20040829151331.GI23120@ip.net.ua> References: <200408271337.i7RDbXgu052801@pooker.samsco.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="07FIeBX8hApXX6Bi" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: re@FreeBSD.org cc: current@FreeBSD.org Subject: Re: 5.3-RELEASE TODO - make/kqueue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 15:13:32 -0000 --07FIeBX8hApXX6Bi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 29, 2004 at 10:25:04AM -0400, Garance A Drosihn wrote: > At 8:05 PM -0400 8/28/04, Garance A Drosihn wrote: > >At 7:37 AM -0600 8/27/04, Scott Long wrote: > >> > >>Testing focuses for 5.3-RELEASE > > > >And update on Issue: > > > >> |---------------------------------+ > >> | make -DUSE_KQUEUE causes lockup | > >> | with buildworld -jBIGNUM | > >> |---------------------------------+ > > > >I have done many buildworlds using the WITH_KQUEUE make over the > >past week. I have done at least 50 buildworlds in my dual-proc > >Althon machine, with -j ranging from 3 to 15. I have not seen > >any lockups since the fix for IPI deadlocks went in. > > > >I do still get the "*** Signal 6"s, ... >=20 > I should also point out that I get those same Signal 6's with > `make' compiled without KQUEUE, so the problem is not with > KQUEUE itself. So while I do think there is *some* subtle bug > that is still lurking around, I suspect that the issue about > KQUEUE and `make' can probably be crossed off the to-do list. >=20 > That's my experience, at least. YMMV, etc. >=20 About five people tested the make(1) binary with -DUSE_KQUEUE, when I asked, and reported no lockups. The make(1) built with kqueue(2) did not result in any good/bad change in buildworld times, so I felt like switching to this mode wasn't necessary. In any case, I think the status for this item can safely migrate to status.done now. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --07FIeBX8hApXX6Bi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBMfKbqRfpzJluFF4RAnyaAJsGr+yfy3a6N1fmSFs4BBZhmNgbmwCfeBgE bHTWWk5FgVe/xtykmpQfzUc= =NKa8 -----END PGP SIGNATURE----- --07FIeBX8hApXX6Bi-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 15:13:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B190A16A4CE; Sun, 29 Aug 2004 15:13:49 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id B413343D1F; Sun, 29 Aug 2004 15:13:48 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (eihawbaa@localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id i7TFDkMj080747; Sun, 29 Aug 2004 19:13:47 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Sun, 29 Aug 2004 19:13:46 +0400 (MSD) From: Maxim Konovalov To: Gleb Smirnoff In-Reply-To: <20040829144528.GA24815@cell.sick.ru> Message-ID: <20040829191330.Y80735@mp2.macomnet.net> References: <20040829144528.GA24815@cell.sick.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: "witness exhausted" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 15:13:49 -0000 On Sun, 29 Aug 2004, 18:45+0400, Gleb Smirnoff wrote: > What does this message actually mean? I get it on boot after upgrade. http://docs.freebsd.org/cgi/getmsg.cgi?fetch=903862+0+archive/2004/freebsd-current/20040829.freebsd-current -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 15:15:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CBEB16A4EA; Sun, 29 Aug 2004 15:15:29 +0000 (GMT) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8C7743D2F; Sun, 29 Aug 2004 15:15:28 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (5w8kc7fk@localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id i7TFFRt0080763; Sun, 29 Aug 2004 19:15:27 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Sun, 29 Aug 2004 19:15:27 +0400 (MSD) From: Maxim Konovalov To: Gleb Smirnoff In-Reply-To: <20040829145445.GB24815@cell.sick.ru> Message-ID: <20040829191500.Q80735@mp2.macomnet.net> References: <20040829145445.GB24815@cell.sick.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: mutex Giant not owned at /usr/src/sys/kern/vfs_vnops.c:120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 15:15:29 -0000 20040828 in src/UPDATING? -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 15:24:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FB3516A4CE for ; Sun, 29 Aug 2004 15:24:31 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8404243D2F for ; Sun, 29 Aug 2004 15:24:30 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i7TFOS97025030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Aug 2004 19:24:29 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i7TFOSIF025029; Sun, 29 Aug 2004 19:24:28 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Sun, 29 Aug 2004 19:24:28 +0400 From: Gleb Smirnoff To: Maxim Konovalov Message-ID: <20040829152428.GA25007@cell.sick.ru> References: <20040829145445.GB24815@cell.sick.ru> <20040829191500.Q80735@mp2.macomnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040829191500.Q80735@mp2.macomnet.net> User-Agent: Mutt/1.5.6i cc: current@freebsd.org Subject: Re: mutex Giant not owned at /usr/src/sys/kern/vfs_vnops.c:120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 15:24:31 -0000 On Sun, Aug 29, 2004 at 07:15:27PM +0400, Maxim Konovalov wrote: M> 20040828 in src/UPDATING? Surely. The question is: where is correct place to take Giant? linker_load_module()? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 15:25:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 413B316A4CE; Sun, 29 Aug 2004 15:25:10 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64F5343D2F; Sun, 29 Aug 2004 15:25:09 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 9BF1A1FF92F; Sun, 29 Aug 2004 17:25:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id AEEBC1FF91D; Sun, 29 Aug 2004 17:25:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 6598915672; Sun, 29 Aug 2004 15:22:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 5A4F215329; Sun, 29 Aug 2004 15:22:48 +0000 (UTC) Date: Sun, 29 Aug 2004 15:22:48 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Gleb Smirnoff In-Reply-To: <20040829145445.GB24815@cell.sick.ru> Message-ID: References: <20040829145445.GB24815@cell.sick.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: FreeBSD current mailing list Subject: Re: mutex Giant not owned at /usr/src/sys/kern/vfs_vnops.c:120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 15:25:10 -0000 On Sun, 29 Aug 2004, Gleb Smirnoff wrote: Hi, > #21 0xc055ecc0 in kdb_enter (msg=0x0) at cpufunc.h:56 > #22 0xc0542dd5 in panic (fmt=0xc06dd9db "mutex %s not owned at %s:%d") > at /usr/src/sys/kern/kern_shutdown.c:536 > #23 0xc053914c in _mtx_assert (m=0xc07402a0, what=0, > file=0xc06e6fbd "/usr/src/sys/kern/vfs_vnops.c", line=120) > at /usr/src/sys/kern/kern_mutex.c:736 > #24 0xc05b165c in vn_open_cred (ndp=0xd0aafaa0, flagp=0xd0aaf97c, cmode=0, > cred=0xc1ad1300, fdidx=0) at /usr/src/sys/kern/vfs_vnops.c:120 > #25 0xc05b1613 in vn_open (ndp=0x0, flagp=0x0, cmode=0, fdidx=0) > at /usr/src/sys/kern/vfs_vnops.c:91 > #26 0xc05343a0 in linker_hints_lookup ( > path=0xc0714020 "/boot/kernel;/boot/modules", pathlen=12, > modname=0xd0aafb74 "ng_tee", modnamelen=6, verinfo=0x0) > at /usr/src/sys/kern/kern_linker.c:1473 > #27 0xc0534947 in linker_search_module (modname=0xd0aafb74 "ng_tee", > modnamelen=6, verinfo=0x0) at /usr/src/sys/kern/kern_linker.c:1593 > #28 0xc0534b19 in linker_load_module (kldname=0x0, > modname=0xd0aafb74 "ng_tee", parent=0x0, verinfo=0x0, lfpp=0xd0aafb70) > at /usr/src/sys/kern/kern_linker.c:1682 > *** these "??" should be: > ngc_send() in /usr/src/sys/netgraph/ng_socket.c > #29 0xc1b71d17 in ?? () > #30 0x00000000 in ?? () > #31 0xd0aafb74 in ?? () > #32 0x00000000 in ?? () > #33 0x00000000 in ?? () > #34 0xd0aafb70 in ?? () > #35 0xc1ae6c38 in ?? () > #36 0x00000000 in ?? () > #37 0xc1789080 in ?? () > #38 0xc06dd88c in ?? () > #39 0x745f676e in ?? () > #40 0xc1006565 in ?? () > #41 0xd0aafc48 in ?? () > #42 0xd0aafcbc in ?? () > #43 0xc0548b25 in uiomove (cp=0xc17a8654, n=0, uio=0xc1692140) > at /usr/src/sys/kern/kern_subr.c:164 > #44 0xc0585621 in sosend (so=0xc17a8654, addr=0xc156a5d0, uio=0xd0aafc48, > top=0xc1609300, control=0x0, flags=0, td=0xc173d840) > at /usr/src/sys/kern/uipc_socket.c:799 > #45 0xc058c0ac in kern_sendit (td=0xc173d840, s=3, mp=0xd0aafcc4, flags=0, > control=0x0) at /usr/src/sys/kern/uipc_syscalls.c:738 > #46 0xc058bf3b in sendit (td=0x0, s=0, mp=0xd0aafcc4, flags=0) > at /usr/src/sys/kern/uipc_syscalls.c:682 > #47 0xc058c22b in sendto (td=0x0, uap=0x0) > at /usr/src/sys/kern/uipc_syscalls.c:795 > #48 0xc0697c50 in syscall (frame= > {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077946376, tf_esi = -1077946382, tf_ebp = -1077945832, tf_isp = -794100364, tf_ebx = 671649088, tf_edx = -1077946384, tf_ecx = 5, tf_eax = 133, tf_trapno = 12, tf_err = 2, tf_eip = 671984639, tf_cs = 31, tf_eflags = 514, tf_esp = -1077946452, tf_ss = 47}) > at /usr/src/sys/i386/i386/trap.c:1004 > #49 0xc06851bf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:201 this does happen when for you ? sth similar I have seen on an HEAD from some hours ago At this time ng_l2tp should have gotten autoloaded: /u1/src/src/HEAD/compile-20040829-0954/sys/kern/vfs_vnops.c:120^M cpuid = 0^M KDB: enter: panic^M K[thread 100127]^M Stopped at kdb_enter+0x2b: nop^M db> where^M kdb_enter(c06b3845) at kdb_enter+0x2b^M panic(c06b2c1a,c06c5201,c06bcadc,78,eb3cea94) at panic+0x127^M _mtx_assert(c074b080,1,c06bcadc,78) at _mtx_assert+0x5c^M vn_open_cred(eb3cea94,eb3ce970,0,c2858500,ffffffff) at vn_open_cred+0x2b^M vn_open(eb3cea94,eb3ce970,0,ffffffff) at vn_open+0x1e^M linker_hints_lookup(c06f8540,c,eb3ceb78,7,0) at linker_hints_lookup+0x109^M linker_search_module(eb3ceb78,7,0,eb3ceb80,eb3ceb78) at linker_search_module+0x43^M linker_load_module(0,eb3ceb78,0,0,eb3ceb74) at linker_load_module+0x80^M ngc_send(c284a288,0,c258b600,c22457f0,0) at ngc_send+0x128^M sosend(c284a288,c22457f0,eb3cec50,c258b600,0) at sosend+0x5e7^M kern_sendit(c2865840,3,eb3ceccc,0,0) at kern_sendit+0xfa^M sendit(c2865840,3,eb3ceccc,0,80bf498) at sendit+0x159^M sendto(c2865840,eb3ced14,6,0,202) at sendto+0x4d^M syscall(2f,2f,2f,bfa6d48c,bfa6d48a) at syscall+0x217^M Xint0x80_syscall() at Xint0x80_syscall+0x1f^M --- syscall (133, FreeBSD ELF32, sendto), eip = 0x28118c8f, esp = 0xbfa6d444, ebp = 0xbfa6d6b0 ---^M -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 15:25:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 926F316A4CE for ; Sun, 29 Aug 2004 15:25:23 +0000 (GMT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 862F743D4C for ; Sun, 29 Aug 2004 15:25:22 +0000 (GMT) (envelope-from apeiron@comcast.net) Received: from prophecy.velum (pcp08490587pcs.levtwn01.pa.comcast.net[68.83.169.224]) by comcast.net (rwcrmhc13) with SMTP id <2004082915252101500madn7e> (Authid: apeiron@comcast.net); Sun, 29 Aug 2004 15:25:22 +0000 Date: Sun, 29 Aug 2004 11:25:18 -0400 From: Christopher Nehren To: Patrick Hurrelmann Message-ID: <20040829152518.GA17698@prophecy.dyndns.org> References: <200408280145.i7S1jqxl096468@mail.gits.dyndns.org> <4131B0AA.6020402@bytephobia.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ibTvN161/egqYuK8" Content-Disposition: inline In-Reply-To: <4131B0AA.6020402@bytephobia.de> X-Please-CC-Me: In List And Group Replies User-Agent: Mutt/1.5.6i cc: Deng XueFeng cc: cyrille.lefevre@laposte.net cc: current@freebsd.org Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 15:25:23 -0000 --ibTvN161/egqYuK8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 29, 2004 at 06:32:10 EDT, Patrick Hurrelmann scribbled these curious markings: > I tried you patch and it applies cleanly to 5.3-BETA1, but kernelbuild=20 > breaks due to syscons. Does anybody experience the same? > See attached log of kernelbuild. I see the same thing on 6.0-CURRENT.=20 --=20 I abhor a system designed for the "user", if that word is a coded pejorative meaning "stupid and unsophisticated". -- Ken Thompson - Unix is user friendly. However, it isn't idiot friendly. --ibTvN161/egqYuK8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBMfVek/lo7zvzJioRAqCpAJ9mXvQA6GQUO7gH26/iTCRPTGv8pACgnrxy V4WQ1JuYsyZeS9j+49/plhE= =HIVc -----END PGP SIGNATURE----- --ibTvN161/egqYuK8-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 15:28:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5563816A4CE for ; Sun, 29 Aug 2004 15:28:31 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F87943D31 for ; Sun, 29 Aug 2004 15:28:30 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i7TFSTLI025057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Aug 2004 19:28:29 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i7TFSSuE025056; Sun, 29 Aug 2004 19:28:28 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Sun, 29 Aug 2004 19:28:28 +0400 From: Gleb Smirnoff To: "Bjoern A. Zeeb" Message-ID: <20040829152828.GB25007@cell.sick.ru> References: <20040829145445.GB24815@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: FreeBSD current mailing list Subject: Re: mutex Giant not owned at /usr/src/sys/kern/vfs_vnops.c:120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 15:28:31 -0000 On Sun, Aug 29, 2004 at 03:22:48PM +0000, Bjoern A. Zeeb wrote: B> this does happen when for you ? Anytime I create node, whose module is not loaded yet. This is not netgraph specific, any call to linker_load_module() from network stack (Giant-free now) should end with this panic. B> sth similar I have seen on an HEAD from some hours ago B> At this time ng_l2tp should have gotten autoloaded: Yes, you have same panic. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 15:34:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DBF516A4CE; Sun, 29 Aug 2004 15:34:47 +0000 (GMT) Received: from mail.ipnet.kiev.ua (ns.ip.net.ua [82.193.96.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D0AC43D31; Sun, 29 Aug 2004 15:34:46 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by mail.ipnet.kiev.ua (8.12.11/8.12.11) with ESMTP id i7TFYfhR094147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Aug 2004 18:34:42 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i7TFYkmh024240; Sun, 29 Aug 2004 18:34:46 +0300 (EEST) (envelope-from ru) Date: Sun, 29 Aug 2004 18:34:46 +0300 From: Ruslan Ermilov To: Ken Smith , Wilko Bulte Message-ID: <20040829153446.GA24041@ip.net.ua> References: <20040829151021.GA43674@bobbi.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: <20040829151021.GA43674@bobbi.cse.buffalo.edu> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: freebsd-current@FreeBSD.org Subject: Re: FreeBSD 5.3-BETA2 Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 15:34:47 -0000 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 29, 2004 at 11:10:21AM -0400, Ken Smith wrote: >=20 > The FreeBSD Release Engineering Team is proud to announce the=20 > availability of FreeBSD 5.3-BETA2. [...] > Fixes made since BETA1: >=20 [...] > - Alpha boot loader fixed. >=20 Since I've been involved with preparation of 5.3-BETA1 for Alpha, let me clarify this, because it may be confusing. This fix was merged into RELENG_5 prior to rolling the BETA1 for Alpha, so BETA1 already comes with this fix included. The actual commit was made: : revision 1.9.2.1 : date: 2004/08/23 04:26:55; author: marcel; state: Exp; lines: +1 -1 : MFC of alpha boot fixes for binutils 2.15 and gcc-3.4.2. 5.3-BETA1 kernel was built: : FreeBSD 5.3-BETA1 #0: Mon Aug 23 22:50:09 UTC 2004 : root@ds10.wbnet:/usr/obj/usr/src/sys/GENERIC loader(8) was built with this fix included, in approximately the same time during "make release". Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --T4sUOijqQbZv57TR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBMfeWqRfpzJluFF4RAsmAAJ4nmPWitPpyzBeX47Pp3xrPD2D7IACgiF8q 0s4N1wU8bTtd+3KSf6GFIAE= =ekWQ -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 15:35:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF37916A4CE; Sun, 29 Aug 2004 15:35:08 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id A907843D39; Sun, 29 Aug 2004 15:35:08 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id BBAE31FF92F; Sun, 29 Aug 2004 17:35:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id CD3E31FF91D; Sun, 29 Aug 2004 17:35:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id EB04D15672; Sun, 29 Aug 2004 15:31:08 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id E780215329; Sun, 29 Aug 2004 15:31:08 +0000 (UTC) Date: Sun, 29 Aug 2004 15:31:08 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Maxim Konovalov In-Reply-To: <20040829191500.Q80735@mp2.macomnet.net> Message-ID: References: <20040829145445.GB24815@cell.sick.ru> <20040829191500.Q80735@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: Gleb Smirnoff cc: FreeBSD current mailing list Subject: Re: mutex Giant not owned at /usr/src/sys/kern/vfs_vnops.c:120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 15:35:09 -0000 On Sun, 29 Aug 2004, Maxim Konovalov wrote: > 20040828 in src/UPDATING? yes most likely; by setting debug.mpsafenet=0 the problem didn't show up here. forgot to note that in the last message. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 15:38:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3204716A4CE; Sun, 29 Aug 2004 15:38:50 +0000 (GMT) Received: from abigail.blackend.org (blackend.org [212.11.35.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id E275E43D1D; Sun, 29 Aug 2004 15:38:48 +0000 (GMT) (envelope-from marc@blackend.org) Received: from abigail.blackend.org (localhost [127.0.0.1]) i7TFcimK054147; Sun, 29 Aug 2004 17:38:44 +0200 (CEST) (envelope-from marc@abigail.blackend.org) Received: (from marc@localhost) by abigail.blackend.org (8.12.11/8.12.11/Submit) id i7TFchY3054146; Sun, 29 Aug 2004 17:38:44 +0200 (CEST) (envelope-from marc) Date: Sun, 29 Aug 2004 17:38:43 +0200 From: Marc Fonvieille To: freebsd-current@freebsd.org Message-ID: <20040829153843.GA54085@abigail.blackend.org> References: <20040828184118.GA16378@abigail.blackend.org> <20040828200633.GA16742@abigail.blackend.org> <20040829083920.GA48813@abigail.blackend.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040829083920.GA48813@abigail.blackend.org> User-Agent: Mutt/1.4.2.1i X-Useless-Header: blackend.org X-Operating-System: FreeBSD 4.10-PRERELEASE cc: freebsd-current@freebsd.org cc: Robert Watson Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 15:38:50 -0000 Hello, It's now working with hint.psm.0.flags="0x200" In fact, it seems after many reboots with different flags the system was not able to reset the touchpad. So I halted the box, at the next boot, the 0x200 flags have been "accepted". Marc From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 15:40:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DBC016A4CE; Sun, 29 Aug 2004 15:40:00 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id B634543D45; Sun, 29 Aug 2004 15:39:59 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from dhcp53.pn.xcllnt.net (dhcp53.pn.xcllnt.net [192.168.4.253]) by ns1.xcllnt.net (8.13.1/8.13.1) with ESMTP id i7TFdxWh046388; Sun, 29 Aug 2004 08:39:59 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp53.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp53.pn.xcllnt.net (8.13.1/8.13.1) with ESMTP id i7TFdxoK022346; Sun, 29 Aug 2004 08:40:00 -0700 (PDT) (envelope-from marcel@dhcp53.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp53.pn.xcllnt.net (8.13.1/8.13.1/Submit) id i7TFdxmQ022345; Sun, 29 Aug 2004 08:39:59 -0700 (PDT) (envelope-from marcel) Date: Sun, 29 Aug 2004 08:39:59 -0700 From: Marcel Moolenaar To: Pawel Jakub Dawidek Message-ID: <20040829153959.GA22248@dhcp53.pn.xcllnt.net> References: <20040829091547.927B07303F@freebsd-current.sentex.ca> <20040829143543.GX30151@darkness.comp.waw.pl> <20040829145603.GG23120@ip.net.ua> <20040829145919.GY30151@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040829145919.GY30151@darkness.comp.waw.pl> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org cc: ia64@freebsd.org cc: FreeBSD Tinderbox Subject: Re: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 15:40:00 -0000 On Sun, Aug 29, 2004 at 04:59:19PM +0200, Pawel Jakub Dawidek wrote: > +> > > +> I believe it's -O2 (which is not in default CFLAGS). > > Nope, it was tested with -O2. I made such breakage before, I think, and > it was only exposed on non-i386 archs, AFAIR. Why? Where is the difference? In the compiler. Different code transformations at different times and to different extend can create different warnings. The uninitialized variable is probably the most affected warning due to this. -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 15:57:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F49D16A4CE; Sun, 29 Aug 2004 15:57:50 +0000 (GMT) Received: from ns1.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D1C743D1F; Sun, 29 Aug 2004 15:57:50 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from dhcp53.pn.xcllnt.net (dhcp53.pn.xcllnt.net [192.168.4.253]) by ns1.xcllnt.net (8.13.1/8.13.1) with ESMTP id i7TFvjiV046456; Sun, 29 Aug 2004 08:57:50 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp53.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp53.pn.xcllnt.net (8.13.1/8.13.1) with ESMTP id i7TFvjJF022403; Sun, 29 Aug 2004 08:57:45 -0700 (PDT) (envelope-from marcel@dhcp53.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp53.pn.xcllnt.net (8.13.1/8.13.1/Submit) id i7TFvj6L022402; Sun, 29 Aug 2004 08:57:45 -0700 (PDT) (envelope-from marcel) Date: Sun, 29 Aug 2004 08:57:45 -0700 From: Marcel Moolenaar To: Ken Smith Message-ID: <20040829155745.GA22372@dhcp53.pn.xcllnt.net> References: <20040829151021.GA43674@bobbi.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk" Content-Disposition: inline In-Reply-To: <20040829151021.GA43674@bobbi.cse.buffalo.edu> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org cc: freebsd-ia64@freebsd.org Subject: Re: FreeBSD 5.3-BETA2 Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 15:57:50 -0000 --UugvWAfsgieZRqgk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 29, 2004 at 11:10:21AM -0400, Ken Smith wrote: >=20 > As of this writing: >=20 > i386: available on most mirror sites, miniinst and disc1 but > disc1 package set missing a few packages > sparc64: build complete, available on many mirror sites, > miniinst only >=20 > Builds for the other architectures are in varying stages, they should > be posted through the next few days. The ia64 bits have just been uploaded. They should appear on the mirrors within 24 hours. The MD5 checksums are: MD5 (5.3-BETA2-ia64-bootonly.iso) =3D a73534efdba7f07a1e8a04d3ffac45ae MD5 (5.3-BETA2-ia64-disc2.iso) =3D 4934f8eac3afce232d6168799470a9fa MD5 (5.3-BETA2-ia64-miniinst.iso) =3D 762338dcfafa71c77b2be2d447be234f Yes, no disc1.=20 Note also that the BETA1 bits have been removed at the same time. FYI, --=20 Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net --UugvWAfsgieZRqgk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBMfz2pgWlLWHuifYRAsCJAJ9CYdovjAM7a0LYbiMgvgmateQrXgCff4Ic OgZsBYuVkj3tF/y36vG7wFQ= =Uone -----END PGP SIGNATURE----- --UugvWAfsgieZRqgk-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 16:03:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C764216A4CE for ; Sun, 29 Aug 2004 16:03:49 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13DDD43D31 for ; Sun, 29 Aug 2004 16:03:49 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7TG3ioA046917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 29 Aug 2004 19:03:45 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i7TG3o33039018 for current@FreeBSD.org; Sun, 29 Aug 2004 19:03:50 +0300 (EEST) (envelope-from ru) Date: Sun, 29 Aug 2004 19:03:50 +0300 From: Ruslan Ermilov To: current@FreeBSD.org Message-ID: <20040829160349.GA38899@ip.net.ua> References: <200408181910.i7IJAawl081643@bleep.craftncomp.com> <20040818183312.T55263@carver.gumbysoft.com> <20040819085119.GE76085@ip.net.ua> <200408281715.i7SHFF201017@Mail.NOSPAM.DynDNS.dK> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: <200408281715.i7SHFF201017@Mail.NOSPAM.DynDNS.dK> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new Subject: Re: Persisten buildworld errors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 16:03:49 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 28, 2004 at 07:15:15PM +0200, Barry Bouwsma wrote: > [keep replies to the list and I'll catch up next time I'm online, thanks] >=20 > > Please don't suggest people to run "make includes". This will likely > > break upgrades from older systems because headers (most noticeble one > > is /usr/include/osreldate.h) will not match the installed world, and >=20 > Purely for interest, which other includes headers are critical > like this? >=20 > (I ask as I'm crossbuilding DragonFly and I've had to hack to > use up-to-date includes during the crossbuild, and would like > to exclude any from my hack that are important for this reason) >=20 Any headers that pop up in .depend files built during the build-tools, bootstrap-tools, and cross-tools stages of buildworld. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBMf5lqRfpzJluFF4RAmAkAJ9p3coMZi+QfPkNTQAhE05JzkTHlACgjl+A eJ3Eihoi1MfGaRd2JGnxRQE= =+NId -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 16:08:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE6EA16A4CE; Sun, 29 Aug 2004 16:08:19 +0000 (GMT) Received: from abigail.blackend.org (blackend.org [212.11.35.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7A4143D3F; Sun, 29 Aug 2004 16:08:18 +0000 (GMT) (envelope-from marc@blackend.org) Received: from abigail.blackend.org (localhost [127.0.0.1]) i7TG8Hr6054539; Sun, 29 Aug 2004 18:08:17 +0200 (CEST) (envelope-from marc@abigail.blackend.org) Received: (from marc@localhost) by abigail.blackend.org (8.12.11/8.12.11/Submit) id i7TG8GsR054538; Sun, 29 Aug 2004 18:08:17 +0200 (CEST) (envelope-from marc) Date: Sun, 29 Aug 2004 18:08:16 +0200 From: Marc Fonvieille To: Ruslan Ermilov Message-ID: <20040829160815.GB54085@abigail.blackend.org> References: <20040828142503.GA52613@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline In-Reply-To: <20040828142503.GA52613@ip.net.ua> User-Agent: Mutt/1.4.2.1i X-Useless-Header: blackend.org X-Operating-System: FreeBSD 4.10-PRERELEASE cc: Cameron Grant cc: multimedia@FreeBSD.org cc: "Simon L. Nielsen" cc: Seigo Tanimura cc: current@FreeBSD.org Subject: Re: [PATCH] sound(4) related manpages 5.3 TODO item X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 16:08:20 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 28, 2004 at 05:25:03PM +0300, Ruslan Ermilov wrote: > Gang, >=20 > [ Please keep me Cc:ed when replying. ] >=20 > I've picked up the "sound(4) related manual pages" item from > the 5.3-RELEASE TODO list. >=20 > While working on adopting the pcm(4) and related manpages to > the new world order, I have noticed some odds that I'd like > your comments on first, before I proceed further. >=20 > One and most important thing I'm not sure I understand, and > that's causing a lot of confusion, is why "device pcm" was > renamed to "device sound" in the first place? I believe the > reason is that "device sound" is a generic sound driver, > which has support for PCM playback, mixer, /dev/sndstat, > eventually MIDI, sequencer, and so on. Individual sound > drivers are free to implement either of these interfaces. > Most of them implement "pcm" nowadays, so saying that > "pcm was renamed to sound" is not quite correct. In other > words, the sound.ko module provides the infrastructure for > more than just PCM, and the sound(4) manpage should eventually > document more than just PCM. Does that sound correct? > I'm not a sound(4) expert, but I think you're right. However, I see something that may be confusing for the new comer: in the kernel we add: device sound device snd_ich # as example and in /dev/sndstat we see: FreeBSD Audio Driver (newpcm) Installed devices: pcm0: at io 0xd800, 0xdc80 irq 5 bufsz 16384 kld snd_ich (1p/2r/0v channels duplex default) or in dmesg: pcm0: port 0xdc80-0xdcbf,0xd800-0xd8ff irq 5 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: Are the "pcm0" and "newpcm" words totally correct here, why no sound/snd ? > Also, there seems to be some confusion between the modules, > drivers, and devices that they implement, which are different > beasties, and are often named differently, and this causes > some misunderstandings and bugs (see below). >=20 > Anyway, the attached patch adopts the sound(4) related man > pages to the new world order. How to proceed: >=20 > 1. The following repo-copies in /home/ncvs/src/share/man/man4 > should be made (there were made locally to produce the > patch): >=20 > pcm.4,v -> sound.4,v > csa.4,v -> snd_csa.4,v > gusc.4,v -> snd_gusc.4,v=20 > maestro3.4,v -> snd_maestro3.4,v=20 > sbc.4,v -> snd_sbc.4,v > uaudio.4,v -> snd_uaudio.4,v >=20 > 2. The old manpages (on the left) were removed, and aren't > included in the patch. >=20 > 3. After repo-copies and deletes, the attached patch should be > applied. It's mostly mechanical (foo -> snd_foo, pcm -> sound), > with the following notable exceptions: >=20 > - Note that non-PnP ISA cards, such as those handled by snd_mss(4) > and snd_ad1816(4), still require hints of the form >=20 > hint.pcm.0.at=3D"isa" > hint.pcm.0.irq=3D"5" > hint.pcm.0.drq=3D"1" > hint.pcm.0.flags=3D"0x0" >=20 > because they implement device "pcm". Granted, the difference > between module and driver name is confusing enough that Seigo > misspelled hints names in sys/conf/NOTES, and Simon misspelled > them in the new snd_ad1816(4) manpage. The patch corrects the > hints names in the snd_ad1816(4) manpage and NOTES. The patch > removes the "hint.snd_mss" from NOTES because (like was said) > the snd_mss(4) module implements the "pcm" device, hence the > hints start with "hint.pcm", and this is already documented > in the sound(4) manpage. Module snd_sbc(4) and snd_gusc(4) > are special in that they implement PCM support through the > bridge device ("sbc" and "gusc", respectively), with "pcm" > device as a child. For them, ISA hints should be spelled > "hint.sbc" and "hint.gusc", respectively. This is also fixed > in NOTES. >=20 > - The patch also fixes the SYNOPSIS section of the snd_maestro3(4) > manpage to align it with other sound drivers manpages, and adds > missing "device sound" to almost all of the snd_*(4) manpages. >=20 perfect! > Does that look sane? I'd be grateful is someone more fluent with > our sound subsystem could review this. >=20 I'm not more fluent than you, but your changes seem correct. Marc --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBMf9u81T1MWxkgcoRAvz7AJ9mKhPMDSXxP8mg9cMbEKNGW1ivqwCfTuqk jytHD5GGutJSaRkn831R7sQ= =at/T -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 16:25:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7362216A4CF; Sun, 29 Aug 2004 16:25:29 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id F182843D5C; Sun, 29 Aug 2004 16:25:28 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smtp3.sentex.ca (8.13.1/8.13.1) with ESMTP id i7TGPPJE085628; Sun, 29 Aug 2004 12:25:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7TGPS3F015831; Sun, 29 Aug 2004 12:25:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 671F47303F; Sun, 29 Aug 2004 12:25:28 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040829162528.671F47303F@freebsd-current.sentex.ca> Date: Sun, 29 Aug 2004 12:25:28 -0400 (EDT) Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 16:25:29 -0000 TB --- 2004-08-29 15:00:21 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-29 15:00:21 - starting CURRENT tinderbox run for i386/i386 TB --- 2004-08-29 15:00:21 - checking out the source tree TB --- 2004-08-29 15:00:21 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2004-08-29 15:00:21 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-29 15:05:28 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-29 15:05:28 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2004-08-29 15:05:28 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-29 16:09:07 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-29 16:09:07 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2004-08-29 16:09:07 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Aug 29 16:09:07 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Aug 29 16:25:27 UTC 2004 TB --- 2004-08-29 16:25:27 - generating LINT kernel config TB --- 2004-08-29 16:25:27 - cd /home/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- 2004-08-29 16:25:27 - /usr/bin/make -B LINT TB --- 2004-08-29 16:25:27 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-29 16:25:27 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2004-08-29 16:25:27 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 29 16:25:27 UTC 2004 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /tinderbox/CURRENT/i386/i386/src/sys/i386/conf; PATH=/home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/legacy/usr/sbin:/home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/legacy/usr/bin:/home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/legacy/usr/games:/home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/usr/sbin:/home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/usr/bin:/home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/LINT /tinderbox/CURRENT/i386/i386/src/sys/i386/conf/LINT /tinderbox/CURRENT/i386/i386/src/sys/i386/conf/LINT: unknown option "HW_WDOG" *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2004-08-29 16:25:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-29 16:25:28 - ERROR: failed to build lint kernel TB --- 2004-08-29 16:25:28 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 16:35:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 442D816A4CE for ; Sun, 29 Aug 2004 16:35:25 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD54443D39 for ; Sun, 29 Aug 2004 16:35:24 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.102] (ddsl-66-42-172-210.fuse.net [66.42.172.210]) (authenticated bits=0)i7TGM5jr016081 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 29 Aug 2004 12:22:06 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: Allan Fields Date: Sun, 29 Aug 2004 12:36:36 -0400 User-Agent: KMail/1.6.2 References: <200408281252.22651.mistry.7@osu.edu> <20040828234258.GB34157@afields.ca> In-Reply-To: <20040828234258.GB34157@afields.ca> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200408291236.50781.mistry.7@osu.edu> X-Spam-Status: No, hits=-4.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_KMAIL version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-current@freebsd.org Subject: Re: wscons from NetBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 16:35:25 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 28 August 2004 07:43 pm, you wrote: > On Sat, Aug 28, 2004 at 12:52:08PM -0400, Anish Mistry wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > I'm in the process of trying to update a bunch of the USB HID code to be > > back in sync with NetBSD since there are numerous problems with our > > current code that have been fixed for a couple of years now in the NetB= SD > > code. The major problem that I'm running into is their dependency on > > wscons for a few of the drivers. Has there been any work on porting > > wscons to FreeBSD? It would make this import much easier and make futu= re > > imports much simpler too. > > But is that reason enough? Personally I have nothing against wscons. Probably not, but I thought that porting wscons used to be on the 5.x TODO= =20 list, so I'm hoping someone might already have done some work on it and it= =20 wouldn't take too much to finish porting it. > > If it was ported I would suggest it by default at least provide a > scrollback like OpenBSD, and obviously, syscons do. (Unless that is a > feature to it.) > > Is another one needed? In FreeBSD there is currently two: > syscons > pcvt If it can help keep a good chunk of the USB code up to date, I'd say yes si= nce=20 the more I look, the more I see problems with our USB code has been fixed i= n=20 NetBSD. Anyway I'll see what I can get done in the next few weeks. > > > - -- > > Anish Mistry > > -- > Allan Fields =2D --=20 Anish Mistry =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBMgYixqA5ziudZT0RAiejAKCEfgLgqvBi3I7N6Yjk0rs8FhDoLwCgh0qQ MV+7Auc3ryhRd8hvY1mVf3I=3D =3DCpQc =2D----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 17:31:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0993616A4CE for ; Sun, 29 Aug 2004 17:31:59 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FA7843D1D for ; Sun, 29 Aug 2004 17:31:58 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7THVMtZ039879; Sun, 29 Aug 2004 11:31:22 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 29 Aug 2004 11:31:25 -0600 (MDT) Message-Id: <20040829.113125.114271055.imp@bsdimp.com> To: mistry.7@osu.edu From: "M. Warner Losh" In-Reply-To: <200408281252.22651.mistry.7@osu.edu> References: <200408281252.22651.mistry.7@osu.edu> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: wscons from NetBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 17:31:59 -0000 In message: <200408281252.22651.mistry.7@osu.edu> Anish Mistry writes: : I'm in the process of trying to update a bunch of the USB HID code to be back : in sync with NetBSD since there are numerous problems with our current code : that have been fixed for a couple of years now in the NetBSD code. The major : problem that I'm running into is their dependency on wscons for a few of the : drivers. Has there been any work on porting wscons to FreeBSD? It would : make this import much easier and make future imports much simpler too. Only a little, token effort :-( I'm very keen on helping/reviewing this effort... Warner From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 17:35:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C82D216A4CE for ; Sun, 29 Aug 2004 17:35:02 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66E5F43D48 for ; Sun, 29 Aug 2004 17:35:02 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7THXbTp039890; Sun, 29 Aug 2004 11:33:37 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 29 Aug 2004 11:33:40 -0600 (MDT) Message-Id: <20040829.113340.85951483.imp@bsdimp.com> To: bsd@afields.ca From: "M. Warner Losh" In-Reply-To: <20040828234258.GB34157@afields.ca> References: <200408281252.22651.mistry.7@osu.edu> <20040828234258.GB34157@afields.ca> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: wscons from NetBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 17:35:02 -0000 In message: <20040828234258.GB34157@afields.ca> Allan Fields writes: : On Sat, Aug 28, 2004 at 12:52:08PM -0400, Anish Mistry wrote: : > -----BEGIN PGP SIGNED MESSAGE----- : > Hash: SHA1 : > : > I'm in the process of trying to update a bunch of the USB HID code to be back : > in sync with NetBSD since there are numerous problems with our current code : > that have been fixed for a couple of years now in the NetBSD code. The major : > problem that I'm running into is their dependency on wscons for a few of the : > drivers. Has there been any work on porting wscons to FreeBSD? It would : > make this import much easier and make future imports much simpler too. : : But is that reason enough? Personally I have nothing against wscons. : : If it was ported I would suggest it by default at least provide a scrollback : like OpenBSD, and obviously, syscons do. (Unless that is a feature to it.) : : Is another one needed? In FreeBSD there is currently two: : syscons : pcvt The big problem with syscons is that it makes a bunch of assumptions about the underlying hardware, making it awkward to port to new platforms. wscons, on the other hand, doesn't. However, syscons and pcvt have some cool features that wscons doesn't have. Warner From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 17:38:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CCEB16A4F0 for ; Sun, 29 Aug 2004 17:38:05 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 93EC243D39 for ; Sun, 29 Aug 2004 17:38:04 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7THZnE6039906; Sun, 29 Aug 2004 11:35:49 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 29 Aug 2004 11:35:52 -0600 (MDT) Message-Id: <20040829.113552.23413625.imp@bsdimp.com> To: dashevil@sympatico.ca From: "M. Warner Losh" In-Reply-To: <1093742244.3464.1.camel@elemental.DashEvil> References: <1093754957.564.24.camel@amon.quaggaspace.org> <1093742244.3464.1.camel@elemental.DashEvil> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: quaggamail@quaggaspace.org Subject: Re: APIC causes vr0 watchdog timeouts and Interrupt storms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 17:38:05 -0000 In message: <1093742244.3464.1.camel@elemental.DashEvil> Chris Laverdure writes: : On Sun, 2004-08-29 at 04:49, Justin Settle wrote: : > Hello, : > : > I recently installed 5.3-BETA. After booting, I found was unable to use : > my usb mouse or my ethernet (Via-rhine). I started tinkering with the : > kernel and found that if I disabled APIC, this system worked without : > ethernet issues or mouse isssues. After talking with some people they : > suggested I post boot -v, dmesg's of the different kernels so here they : > are: : > : > The first thing I tried was a GENERIC with SMP commented out. It had : > the same issues as GENERIC: : > : ... : > ACPI is on both of these kernels but I've tried both without and the : > results are the same. Should any other information be needed/wanted : > I'll be sure to reply. Thank you for your time. : > : > Jay Settle : > : : I too cannot use my USB mouse with ACPI enabled (yet it works fine : without it). I get a Interrupt Storm when usbd tries to come up, and : then moused fails claiming an "Input/Output error on /dev/ums0". : : I would love to get to the bottom of this. This sounds like an interrupt routing problem... Warner From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 17:41:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E88116A4CE; Sun, 29 Aug 2004 17:41:34 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 313AC43D49; Sun, 29 Aug 2004 17:41:34 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7THe4VD039957; Sun, 29 Aug 2004 11:40:04 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 29 Aug 2004 11:40:07 -0600 (MDT) Message-Id: <20040829.114007.133405872.imp@bsdimp.com> To: pjd@freebsd.org From: "M. Warner Losh" In-Reply-To: <20040829143543.GX30151@darkness.comp.waw.pl> References: <20040829091547.927B07303F@freebsd-current.sentex.ca> <20040829143543.GX30151@darkness.comp.waw.pl> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: ia64@freebsd.org cc: tinderbox@freebsd.org cc: current@freebsd.org Subject: Re: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 17:41:34 -0000 In message: <20040829143543.GX30151@darkness.comp.waw.pl> Pawel Jakub Dawidek writes: : On Sun, Aug 29, 2004 at 05:15:47AM -0400, FreeBSD Tinderbox wrote: : +> cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -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 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/geom/mirror/g_mirror.c : +> /tinderbox/CURRENT/ia64/ia64/src/sys/geom/mirror/g_mirror.c: In function `g_mirror_taste': : +> /tinderbox/CURRENT/ia64/ia64/src/sys/geom/mirror/g_mirror.c:2485: warning: 'sc' might be used uninitialized in this function : +> *** Error code 1 : : Fixed, sorry. : : PS. Can someone show me which compiler flag expose those "bugs"? -O2 Warner From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 17:52:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A824816A4CE for ; Sun, 29 Aug 2004 17:52:35 +0000 (GMT) Received: from alogis.com (firewall2.alogis.com [62.8.223.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9292243D5C for ; Sun, 29 Aug 2004 17:52:33 +0000 (GMT) (envelope-from Holger.Kipp@alogis.com) Received: (from hk@localhost) by alogis.com (8.11.1/8.9.3) id i7THqRM24368; Sun, 29 Aug 2004 19:52:27 +0200 (CEST) (envelope-from hk) Date: Sun, 29 Aug 2004 19:52:27 +0200 From: Holger Kipp To: Kenneth Stailey Message-ID: <20040829195227.A23465@intserv.int1.b.intern> References: <20040829141044.98464.qmail@web50601.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20040829141044.98464.qmail@web50601.mail.yahoo.com>; from kstailey@yahoo.com on Sun, Aug 29, 2004 at 07:10:44AM -0700 cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 17:52:35 -0000 On Sun, Aug 29, 2004 at 07:10:44AM -0700, Kenneth Stailey wrote: > Can a one-line example of how to invoke adduser to add new accounts like > "proxy" be added to /usr/src/UPDATING? That way people could just > cut-and-paste the accounts into place when upgrading. Use mergemaster for this: mergemaster -p (this is in /usr/src/UPDATING (CURRENT) for 20040308) to create required user account 'proxy'. mergemaster -p (this is in /usr/src/UPDATING (STABLE) for 20020404) (iirc this was for sendmail) apart from that, 'man adduser' is your friend :-) I always found it quite interesting(*) to read all UPDATING-Entries starting from the last time I updated my systems - apart from reading (some) mailings to stable- and current-mailinglist - and to always expect the unexpected whilst using current... :-) Regards, Holger Kipp (*) sometimes even enlightening, but due to enhanced stupidity (I'm over 30 now) this does not always work . From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 18:50:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE71C16A4CE for ; Sun, 29 Aug 2004 18:50:44 +0000 (GMT) Received: from huva.hittite.isp.9tel.net (huva.hittite.isp.9tel.net [62.62.156.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A0F643D1F for ; Sun, 29 Aug 2004 18:50:44 +0000 (GMT) (envelope-from clefevr-current@9online.fr) Received: from pc2k (78-240-118-80.kaptech.net [80.118.240.78]) by huva.hittite.isp.9tel.net (Postfix) with SMTP id 0E72514B74B; Sun, 29 Aug 2004 21:04:20 +0200 (CEST) Message-ID: <07ce01c48df9$15eaf7b0$7890a8c0@gits.invalid> From: "Cyrille Lefevre" To: , "Deng XueFeng" References: <200408280145.i7S1jqxl096468@mail.gits.dyndns.org> <20040828114635.0AC4.DSNOFE@msn.com> <1093773446.901.3.camel@localhost> Date: Sun, 29 Aug 2004 20:50:41 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 cc: current@freebsd.org Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support forFreeBSD-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Cyrille Lefevre List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 18:50:44 -0000 "Vladimir Grebenschikov" wrote: > On Sat, 2004-08-28 at 11:46 +0800, Deng XueFeng wrote: > > > > On Aug 27, 2004 01:59:50 am +0000, Deng XueFeng wrote: > > > > First to thanks Sascha Wildner . > > > > he hack syscons to make dfbsd support 1024x768(16/24/32) syscons, > > > > then I ported that to current. and it works well with my ati MOBILITY > > > > 7500[T31]/9200 [NX7000]. > > > > To make console support 1024x768; just type > > > > #vidcontrol MODE_279 > > How about another notebook native resolutions, 1400x1050 for example. you have to take a look at your video card reference guide... AFAIK, maybe except for the standard video mode, the other video mode are vendor dependent, but I may be wrong. Cyrille Lefevre. -- home: mailto:cyrille.lefevre@laposte.net From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 19:01:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D541216A4DC; Sun, 29 Aug 2004 19:01:20 +0000 (GMT) Received: from hak.cnd.mcgill.ca (hak.cnd.McGill.CA [132.216.11.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7072D43D4C; Sun, 29 Aug 2004 19:01:20 +0000 (GMT) (envelope-from mat@hak.cnd.mcgill.ca) Received: from hak.cnd.mcgill.ca (localhost [127.0.0.1]) by hak.cnd.mcgill.ca (8.12.9/8.12.8) with ESMTP id i7TJ8X1M011556; Sun, 29 Aug 2004 15:08:33 -0400 (EDT) (envelope-from mat@hak.cnd.mcgill.ca) Received: (from mat@localhost) by hak.cnd.mcgill.ca (8.12.9/8.12.8/Submit) id i7TJ8X5P011555; Sun, 29 Aug 2004 15:08:33 -0400 (EDT) Date: Sun, 29 Aug 2004 15:08:33 -0400 From: Mathew Kanner To: Ruslan Ermilov Message-ID: <20040829190833.GA9796@cnd.mcgill.ca> References: <20040828142503.GA52613@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040828142503.GA52613@ip.net.ua> User-Agent: Mutt/1.4.1i Organization: I speak for myself, operating in Montreal, CANADA X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.62 X-Spam-Checker-Version: SpamAssassin 2.62 (2004-01-11) on hak.cnd.mcgill.ca cc: Cameron Grant cc: multimedia@freebsd.org cc: "Simon L. Nielsen" cc: Seigo Tanimura cc: current@freebsd.org Subject: Re: [PATCH] sound(4) related manpages 5.3 TODO item X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 19:01:29 -0000 On Aug 28, Ruslan Ermilov wrote: Hello Ruslan, > One and most important thing I'm not sure I understand, and > that's causing a lot of confusion, is why "device pcm" was > renamed to "device sound" in the first place? I believe the > reason is that "device sound" is a generic sound driver, > which has support for PCM playback, mixer, /dev/sndstat, > eventually MIDI, sequencer, and so on. Individual sound > drivers are free to implement either of these interfaces. > Most of them implement "pcm" nowadays, so saying that > "pcm was renamed to sound" is not quite correct. In other > words, the sound.ko module provides the infrastructure for > more than just PCM, and the sound(4) manpage should eventually > document more than just PCM. Does that sound correct? Sounds correct on all accounts. Also, the synopsis should indicate that the preferred method to load sound is to set sound_load="YES" in loader.conf and barely mention kernel options, and otherwise ignore ISA and PNP. > Also, there seems to be some confusion between the modules, > drivers, and devices that they implement, which are different > beasties, and are often named differently, and this causes > some misunderstandings and bugs (see below). Note that sndstat now lists the kld name (if loaded as such) in the device listings. > > Anyway, the attached patch adopts the sound(4) related man > pages to the new world order. How to proceed: > > 1. The following repo-copies in /home/ncvs/src/share/man/man4 > should be made (there were made locally to produce the > patch): > > pcm.4,v -> sound.4,v > csa.4,v -> snd_csa.4,v > gusc.4,v -> snd_gusc.4,v > maestro3.4,v -> snd_maestro3.4,v > sbc.4,v -> snd_sbc.4,v > uaudio.4,v -> snd_uaudio.4,v Good. > > 2. The old manpages (on the left) were removed, and aren't > included in the patch. > > 3. After repo-copies and deletes, the attached patch should be > applied. It's mostly mechanical (foo -> snd_foo, pcm -> sound), > with the following notable exceptions: > > - Note that non-PnP ISA cards, such as those handled by snd_mss(4) > and snd_ad1816(4), still require hints of the form > > hint.pcm.0.at="isa" > hint.pcm.0.irq="5" > hint.pcm.0.drq="1" > hint.pcm.0.flags="0x0" > > because they implement device "pcm". Granted, the difference > between module and driver name is confusing enough that Seigo > misspelled hints names in sys/conf/NOTES, and Simon misspelled > them in the new snd_ad1816(4) manpage. The patch corrects the > hints names in the snd_ad1816(4) manpage and NOTES. The patch > removes the "hint.snd_mss" from NOTES because (like was said) > the snd_mss(4) module implements the "pcm" device, hence the > hints start with "hint.pcm", and this is already documented > in the sound(4) manpage. Module snd_sbc(4) and snd_gusc(4) > are special in that they implement PCM support through the > bridge device ("sbc" and "gusc", respectively), with "pcm" > device as a child. For them, ISA hints should be spelled > "hint.sbc" and "hint.gusc", respectively. This is also fixed > in NOTES. This is a very good catch, I never noticed this. > > - The patch also fixes the SYNOPSIS section of the snd_maestro3(4) > manpage to align it with other sound drivers manpages, and adds > missing "device sound" to almost all of the snd_*(4) manpages. Yes please. > > Does that look sane? I'd be grateful is someone more fluent with > our sound subsystem could review this. I've read the diff and it all looks very good to me, thank you very much for taking this on. --Mat -- Applicants must also have extensive knowledge of UNIX, although they should have sufficiently good programming taste to not consider this an achievement. - MIT AI Lab job ad in the /Boston Globe/ From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 19:06:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A7F0216A4CE; Sun, 29 Aug 2004 19:06:00 +0000 (GMT) Received: from mail.ipnet.kiev.ua (ns.ip.net.ua [82.193.96.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90DD743D53; Sun, 29 Aug 2004 19:05:59 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by mail.ipnet.kiev.ua (8.12.11/8.12.11) with ESMTP id i7TJ5ssd008219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Aug 2004 22:05:55 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i7TJ5xeC039616; Sun, 29 Aug 2004 22:05:59 +0300 (EEST) (envelope-from ru) Date: Sun, 29 Aug 2004 22:05:59 +0300 From: Ruslan Ermilov To: Marc Fonvieille Message-ID: <20040829190559.GA39435@ip.net.ua> References: <20040828142503.GA52613@ip.net.ua> <20040829160815.GB54085@abigail.blackend.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: <20040829160815.GB54085@abigail.blackend.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: Cameron Grant cc: multimedia@freebsd.org cc: "Simon L. Nielsen" cc: Seigo Tanimura cc: current@freebsd.org Subject: Re: [PATCH] sound(4) related manpages 5.3 TODO item X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 19:06:00 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 29, 2004 at 06:08:16PM +0200, Marc Fonvieille wrote: > On Sat, Aug 28, 2004 at 05:25:03PM +0300, Ruslan Ermilov wrote: [...] > > One and most important thing I'm not sure I understand, and > > that's causing a lot of confusion, is why "device pcm" was > > renamed to "device sound" in the first place? I believe the > > reason is that "device sound" is a generic sound driver, > > which has support for PCM playback, mixer, /dev/sndstat, > > eventually MIDI, sequencer, and so on. Individual sound > > drivers are free to implement either of these interfaces. > > Most of them implement "pcm" nowadays, so saying that > > "pcm was renamed to sound" is not quite correct. In other > > words, the sound.ko module provides the infrastructure for > > more than just PCM, and the sound(4) manpage should eventually > > document more than just PCM. Does that sound correct? > > >=20 > I'm not a sound(4) expert, but I think you're right. > However, I see something that may be confusing for the new comer: in the > kernel we add: >=20 > device sound > device snd_ich # as example >=20 > and in /dev/sndstat we see: >=20 > FreeBSD Audio Driver (newpcm) > Installed devices: > pcm0: at io 0xd800, 0xdc80 irq 5 bufsz 16384 kld > snd_ich (1p/2r/0v channels duplex default) >=20 > or in dmesg: >=20 > pcm0: port 0xdc80-0xdcbf,0xd800-0xd8ff irq 5 at > device 31.5 on pci0 > pcm0: [GIANT-LOCKED] > pcm0: >=20 >=20 > Are the "pcm0" and "newpcm" words totally correct here, why no sound/snd ? >=20 It's my current understanding that pcm(4) is only one part of the sound(4) subsystem. midi(4) will be another part of it, and mixer(4) is another such device. The sound(4) man page should eventually document the entire sound subsystem. The snd_foo(4) module can register with the sound(4) system one "pcm" device, one "midi" device, and one "mixer" device. > > Does that look sane? I'd be grateful is someone more fluent with > > our sound subsystem could review this. > >=20 >=20 > I'm not more fluent than you, but your changes seem correct. >=20 Thanks, Marc. I will wait for one more day, then if nothing changes, will order repo-copies and proceed with the patch and merging this to RELENG_5. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBMikXqRfpzJluFF4RAi5vAJ9/INbHV7uoOrB3OSR9RzpEzxFk4QCfYxds Sy1VSmW30qZdcHr4CBf+VbI= =D4bc -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 19:15:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4913416A4CE for ; Sun, 29 Aug 2004 19:15:59 +0000 (GMT) Received: from gvr.gvr.org (gvr-gw.gvr.org [80.126.103.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EB0B43D4C for ; Sun, 29 Aug 2004 19:15:59 +0000 (GMT) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id 2C10738; Sun, 29 Aug 2004 21:15:58 +0200 (CEST) Date: Sun, 29 Aug 2004 21:15:58 +0200 From: Guido van Rooij To: Daniel O'Connor Message-ID: <20040829191558.GA4616@gvr.gvr.org> References: <20040827082929.GA64830@gvr.gvr.org> <200408280201.10816.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408280201.10816.doconnor@gsoft.com.au> cc: freebsd-current@freebsd.org Subject: Re: project evil: signal quality? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 19:15:59 -0000 On Sat, Aug 28, 2004 at 02:01:10AM +0930, Daniel O'Connor wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Fri, 27 Aug 2004 17:59, Guido van Rooij wrote: > > Is there a way to extract signal quality from an ndis wireless device? > > wicontrol ndis0 -l > (and friends) Thanks, The reason I asked is because I normally use wicontrol -i ndis0: ... Comms quality/signal/noise: [ 0 0 0 ] ... As you see, in that screen, it appears comms quality is unavailable.. -Guido From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 19:21:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00AB716A4CE for ; Sun, 29 Aug 2004 19:21:15 +0000 (GMT) Received: from ioskeha.hittite.isp.9tel.net (ioskeha.hittite.isp.9tel.net [62.62.156.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C3D243D1D for ; Sun, 29 Aug 2004 19:21:14 +0000 (GMT) (envelope-from root@gits.dyndns.org) Received: from mail.gits.dyndns.org (78-240-118-80.kaptech.net [80.118.240.78]) by ioskeha.hittite.isp.9tel.net (Postfix) with ESMTP id 3AC0D14B7A8; Sun, 29 Aug 2004 21:34:14 +0200 (CEST) Posted-Date: Sun, 29 Aug 2004 21:13:43 +0200 (CEST) X-Envelope-To: outi@bytephobia.de Received: from mail.gits.dyndns.org (localhost [127.0.0.1]) by mail.gits.dyndns.org (8.13.1/8.12.11) with ESMTP id i7TJDh7K034237; Sun, 29 Aug 2004 21:15:10 +0200 (CEST) (envelope-from root@gits.dyndns.org) Received: (from root@localhost) by mail.gits.dyndns.org (8.13.1/8.12.11/Submit) id i7TImAq8072080; Sun, 29 Aug 2004 20:48:10 +0200 (CEST) (envelope-from root) Message-Id: <200408291848.i7TImAq8072080@mail.gits.dyndns.org> In-Reply-To: <4131B0AA.6020402@bytephobia.de> To: outi@bytephobia.de Date: Sun, 29 Aug 2004 20:48:09 +0200 (CEST) From: Cyrille Lefevre X-Face: V|+c;4!|B?E%BE^{E6); aI.[< cc: current@freebsd.org Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: cyrille.lefevre@laposte.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 19:21:15 -0000 On Aug 29, 2004 12:32:10 pm +0200, Patrick Hurrelmann wrote: > Hi Cyrille, > > I tried you patch and it applies cleanly to 5.3-BETA1, but kernelbuild > breaks due to syscons. Does anybody experience the same? ok, it seems I've missed some static void... don't understand why I don't have the same warnings as yours using today's -current ? thanks anyway. > See attached log of kernelbuild. PS : did you notice the same vidcontrol error messages as Aurelien Nephtali (aka "vidcontrol: showing the mouse: Invalid argument") ? however, here is the build fix (scvgarndr.c only) : Index: scvgarndr.c =================================================================== RCS file: /home/ncvs/src/sys/dev/syscons/scvgarndr.c,v retrieving revision 1.15 diff -u -I$Id.*$ -I$.+BSD.*$ -r1.15 scvgarndr.c --- scvgarndr.c 30 May 2004 20:08:42 -0000 1.15 +++ scvgarndr.c 29 Aug 2004 17:07:28 -0000 @@ -47,7 +47,7 @@ #include #ifndef SC_RENDER_DEBUG -#define SC_RENDER_DEBUG 0 +#define SC_RENDER_DEBUG 0 #endif static vr_clear_t vga_txtclear; @@ -59,7 +59,7 @@ #ifndef SC_NO_CUTPASTE static vr_draw_mouse_t vga_txtmouse; #else -#define vga_txtmouse (vr_draw_mouse_t *)vga_nop +#define vga_txtmouse (vr_draw_mouse_t *)vga_nop #endif #ifdef SC_PIXEL_MODE @@ -73,7 +73,7 @@ #ifndef SC_NO_CUTPASTE static vr_draw_mouse_t vga_pxlmouse; #else -#define vga_pxlmouse (vr_draw_mouse_t *)vga_nop +#define vga_pxlmouse (vr_draw_mouse_t *)vga_nop #endif #endif /* SC_PIXEL_MODE */ @@ -155,6 +155,37 @@ #endif #endif +#ifdef SC_PIXEL_MODE +static uint32_t vga_palette32[16] = { + 0x000000, 0x0000ad, 0x00ad00, 0x00adad, + 0xad0000, 0xad00ad, 0xad5200, 0xadadad, + 0x525252, 0x5252ff, 0x52ff52, 0x52ffff, + 0xff5252, 0xff52ff, 0xffff52, 0xffffff +}; + +static uint16_t vga_palette16[16] = { + 0x0000, 0x0016, 0x0560, 0x0576, 0xb000, 0xb016, 0xb2a0, 0xb576, + 0x52aa, 0x52bf, 0x57ea, 0x57ff, 0xfaaa, 0xfabf, 0xffea, 0xffff +}; + +static uint16_t vga_palette15[16] = { + 0x0000, 0x0016, 0x02c0, 0x02d6, 0x5800, 0x5816, 0x5940, 0x5ad6, + 0x294a, 0x295f, 0x2bea, 0x2bff, 0x7d4a, 0x7d5f, 0x7fea, 0x7fff +}; + +#define VIDEO_MEMORY_POS(scp, pos, x) \ + scp->sc->adp->va_window + \ + x * scp->xoff + \ + scp->yoff * scp->font_size * scp->sc->adp->va_line_width + \ + x * (pos % scp->xsize) + \ + scp->font_size * scp->sc->adp->va_line_width * (pos / scp->xsize) + +#ifndef SC_NO_CUTPASTE +static uint32_t mouse_buf32[256]; +static uint16_t mouse_buf16[256]; +#endif +#endif + static void vga_nop(scr_stat *scp, ...) { @@ -359,8 +390,8 @@ yoffset = y%scp->font_size; for (i = 0; i < 16; ++i) { cursor[i + yoffset] = - (cursor[i + yoffset] & ~(mouse_and_mask[i] >> xoffset)) - | (mouse_or_mask[i] >> xoffset); + (cursor[i + yoffset] & ~(mouse_and_mask[i] >> xoffset)) + | (mouse_or_mask[i] >> xoffset); } for (i = 0; i < scp->font_size; ++i) { font_buf[i] = (cursor[i] & 0xff00) >> 8; @@ -431,7 +462,29 @@ /* pixel (raster text) mode renderer */ static void -vga_pxlclear(scr_stat *scp, int c, int attr) +vga_pxlclear_direct(scr_stat *scp, int c, int attr) +{ + vm_offset_t p; + int line_width; + int pixel_size; + int lines; + int i; + + line_width = scp->sc->adp->va_line_width; + pixel_size = scp->sc->adp->va_info.vi_pixel_size; + lines = scp->ysize * scp->font_size; + p = scp->sc->adp->va_window + + line_width * scp->yoff * scp->font_size + + scp->xoff * 8 * pixel_size; + + for (i = 0; i < lines; ++i) { + bzero_io((void *)p, scp->xsize * 8 * pixel_size); + p += line_width; + } +} + +static void +vga_pxlclear_planar(scr_stat *scp, int c, int attr) { vm_offset_t p; int line_width; @@ -457,7 +510,121 @@ } static void -vga_pxlborder(scr_stat *scp, int color) +vga_pxlclear(scr_stat *scp, int c, int attr) +{ + switch (scp->sc->adp->va_info.vi_mem_model) { + case V_INFO_MM_DIRECT: + vga_pxlclear_direct(scp, c, attr); + break; + case V_INFO_MM_PLANAR: + vga_pxlclear_planar(scp, c, attr); + break; + } +} + +static void +vga_pxlborder_direct(scr_stat *scp, int color, int bpp) +{ + vm_offset_t s; + vm_offset_t e; + vm_offset_t f; + int line_width; + int pixel_size; + int x; + int y; + int i; + + line_width = scp->sc->adp->va_line_width; + pixel_size = scp->sc->adp->va_info.vi_pixel_size; + + if (scp->yoff > 0) { + s = scp->sc->adp->va_window; + e = s + line_width * scp->yoff * scp->font_size; + + for (f = s; f < e; f += pixel_size) { + switch (bpp) { + case 32: + writel(f, vga_palette32[color]); + break; + case 16: + writew(f, vga_palette16[color]); + break; + case 15: + writew(f, vga_palette15[color]); + break; + } + } + } + + y = (scp->yoff + scp->ysize) * scp->font_size; + + if (scp->ypixel > y) { + s = scp->sc->adp->va_window + line_width * y; + e = s + line_width * (scp->ypixel - y); + + for (f = s; f < e; f += pixel_size) { + switch (bpp) { + case 32: + writel(f, vga_palette32[color]); + break; + case 16: + writew(f, vga_palette16[color]); + break; + case 15: + writew(f, vga_palette15[color]); + break; + } + } + } + + y = scp->yoff * scp->font_size; + x = scp->xpixel / 8 - scp->xoff - scp->xsize; + + for (i = 0; i < scp->ysize * scp->font_size; ++i) { + if (scp->xoff > 0) { + s = scp->sc->adp->va_window + line_width * (y + i); + e = s + scp->xoff * 8 * pixel_size; + + for (f = s; f < e; f += pixel_size) { + switch (bpp) { + case 32: + writel(f, vga_palette32[color]); + break; + case 16: + writew(f, vga_palette16[color]); + break; + case 15: + writew(f, vga_palette15[color]); + break; + } + } + } + + if (x > 0) { + s = scp->sc->adp->va_window + line_width * (y + i) + + scp->xoff * 8 * pixel_size + + scp->xsize * 8 * pixel_size; + e = s + x * 8 * pixel_size; + + for (f = s; f < e; f += pixel_size) { + switch (bpp) { + case 32: + writel(f, vga_palette32[color]); + break; + case 16: + writew(f, vga_palette16[color]); + break; + case 15: + writew(f, vga_palette15[color]); + break; + } + } + } + } +} + +static void +vga_pxlborder_planar(scr_stat *scp, int color) { vm_offset_t p; int line_width; @@ -492,6 +659,27 @@ outw(GDCIDX, 0x0001); /* set/reset enable */ } +static void +vga_pxlborder(scr_stat *scp, int color) +{ + int bpp; + + switch (scp->sc->adp->va_info.vi_mem_model) { + case V_INFO_MM_DIRECT: + bpp = scp->sc->adp->va_info.vi_depth; + + if ((bpp == 16) && + (scp->sc->adp->va_info.vi_pixel_fsizes[1] == 5)) + bpp = 15; + + vga_pxlborder_direct(scp, color, bpp); + break; + case V_INFO_MM_PLANAR: + vga_pxlborder_planar(scp, color); + break; + } +} + static void vga_egadraw(scr_stat *scp, int from, int count, int flip) { @@ -506,11 +694,7 @@ u_char c; line_width = scp->sc->adp->va_line_width; - d = scp->sc->adp->va_window - + scp->xoff - + scp->yoff*scp->font_size*line_width - + (from%scp->xsize) - + scp->font_size*line_width*(from/scp->xsize); + d = VIDEO_MEMORY_POS(scp, from, 1); outw(GDCIDX, 0x0005); /* read mode 0, write mode 0 */ outw(GDCIDX, 0x0003); /* data rotate/function select */ @@ -541,7 +725,7 @@ f = &(scp->font[sc_vtb_getc(&scp->vtb, i)*scp->font_size]); for (j = 0; j < scp->font_size; ++j, ++f) { outw(GDCIDX, (*f << 8) | 0x08); /* bit mask */ - writeb(e, 0); + writeb(e, 0); e += line_width; } ++d; @@ -554,8 +738,87 @@ outw(GDCIDX, 0xff08); /* bit mask */ } -static void -vga_vgadraw(scr_stat *scp, int from, int count, int flip) +static void +vga_vgadraw_direct(scr_stat *scp, int from, int count, int flip, int bpp) +{ + vm_offset_t d = 0; + vm_offset_t e; + u_char *f; + u_short col1, col2, idx; + int line_width; + int i, j, k; + int a; + + line_width = scp->sc->adp->va_line_width; + + switch (bpp) { + case 32: + d = VIDEO_MEMORY_POS(scp, from, 32); + break; + case 16: + /* FALLTHROUGH */ + case 15: + d = VIDEO_MEMORY_POS(scp, from, 16); + break; + } + + if (from + count > scp->xsize * scp->ysize) + count = scp->xsize * scp->ysize - from; + + for (i = from; count-- > 0; ++i) { + a = sc_vtb_geta(&scp->vtb, i); + + if (flip) { + col1 = (((a & 0x7000) >> 4) | (a & 0x0800)) >> 8; + col2 = (((a & 0x8000) >> 4) | (a & 0x0700)) >> 8; + } else { + col1 = (a & 0x0f00) >> 8; + col2 = (a & 0xf000) >> 12; + } + + e = d; + f = &(scp->font[sc_vtb_getc(&scp->vtb, i) * scp->font_size]); + + for (j = 0; j < scp->font_size; ++j, ++f) { + for (k = 7; k >= 0; --k) { + idx = *f & (1 << (7 - k)) ? + col1 : col2; + + switch (bpp) { + case 32: + writel(e + 4 * k, vga_palette32[idx]); + break; + case 16: + writew(e + 2 * k, vga_palette16[idx]); + break; + case 15: + writew(e + 2 * k, vga_palette15[idx]); + break; + } + } + + e += line_width; + } + + switch (bpp) { + case 32: + d += 32; + break; + case 16: + /* FALLTHROUGH */ + case 15: + d += 16; + break; + } + + if ((i % scp->xsize) == scp->xsize - 1) + d += scp->xoff * 16 * scp->sc->adp->va_info.vi_pixel_size + + (scp->font_size - 1) * line_width; + } +} + +static void +vga_vgadraw_planar(scr_stat *scp, int from, int count, int flip) { vm_offset_t d; vm_offset_t e; @@ -568,11 +831,7 @@ u_char c; line_width = scp->sc->adp->va_line_width; - d = scp->sc->adp->va_window - + scp->xoff - + scp->yoff*scp->font_size*line_width - + (from%scp->xsize) - + scp->font_size*line_width*(from/scp->xsize); + d = VIDEO_MEMORY_POS(scp, from, 1); outw(GDCIDX, 0x0305); /* read mode 0, write mode 3 */ outw(GDCIDX, 0x0003); /* data rotate/function select */ @@ -604,7 +863,7 @@ e = d; f = &(scp->font[sc_vtb_getc(&scp->vtb, i)*scp->font_size]); for (j = 0; j < scp->font_size; ++j, ++f) { - writeb(e, *f); + writeb(e, *f); e += line_width; } ++d; @@ -617,6 +876,27 @@ outw(GDCIDX, 0x0001); /* set/reset enable */ } +static void +vga_vgadraw(scr_stat *scp, int from, int count, int flip) +{ + int bpp; + + switch (scp->sc->adp->va_info.vi_mem_model) { + case V_INFO_MM_DIRECT: + bpp = scp->sc->adp->va_info.vi_depth; + + if ((bpp == 16) && + (scp->sc->adp->va_info.vi_pixel_fsizes[1] == 5)) + bpp = 15; + + vga_vgadraw_direct(scp, from, count, flip, bpp); + break; + case V_INFO_MM_PLANAR: + vga_vgadraw_planar(scp, from, count, flip); + break; + } +} + static void vga_pxlcursor_shape(scr_stat *scp, int base, int height, int blink) { @@ -629,8 +909,70 @@ #endif } -static void -draw_pxlcursor(scr_stat *scp, int at, int on, int flip) +static void +draw_pxlcursor_direct(scr_stat *scp, int at, int on, int flip, int bpp) +{ + vm_offset_t d = 0; + u_char *f; + int line_width; + int height; + int col1, col2, idx; + int a; + int i, j; + + line_width = scp->sc->adp->va_line_width; + + switch (bpp) { + case 32: + d = VIDEO_MEMORY_POS(scp, at, 32) + + (scp->font_size - scp->curs_attr.base - 1) * line_width; + break; + case 16: + /* FALLTHROUGH */ + case 15: + d = VIDEO_MEMORY_POS(scp, at, 16) + + (scp->font_size - scp->curs_attr.base - 1) * line_width; + break; + } + + a = sc_vtb_geta(&scp->vtb, at); + + if (flip) { + col1 = ((on) ? (a & 0x0f00) : ((a & 0xf000) >> 4)) >> 8; + col2 = ((on) ? ((a & 0xf000) >> 4) : (a & 0x0f00)) >> 8; + } else { + col1 = ((on) ? ((a & 0xf000) >> 4) : (a & 0x0f00)) >> 8; + col2 = ((on) ? (a & 0x0f00) : ((a & 0xf000) >> 4)) >> 8; + } + + f = &(scp->font[sc_vtb_getc(&scp->vtb, at) * scp->font_size + + scp->font_size - scp->curs_attr.base - 1]); + + height = imin(scp->curs_attr.height, scp->font_size); + + for (i = 0; i < height; ++i, --f) { + for (j = 7; j >= 0; --j) { + idx = *f & (1 << (7 - j)) ? col1 : col2; + + switch (bpp) { + case 32: + writel(d + 4 * j, vga_palette32[idx]); + break; + case 16: + writew(d + 2 * j, vga_palette16[idx]); + break; + case 15: + writew(d + 2 * j, vga_palette15[idx]); + break; + } + } + + d -= line_width; + } +} + +static void +draw_pxlcursor_planar(scr_stat *scp, int at, int on, int flip) { vm_offset_t d; u_char *f; @@ -642,12 +984,8 @@ u_char c; line_width = scp->sc->adp->va_line_width; - d = scp->sc->adp->va_window - + scp->xoff - + scp->yoff*scp->font_size*line_width - + (at%scp->xsize) - + scp->font_size*line_width*(at/scp->xsize) - + (scp->font_size - scp->curs_attr.base - 1)*line_width; + d = VIDEO_MEMORY_POS(scp, at, 1) + + (scp->font_size - scp->curs_attr.base - 1) * line_width; outw(GDCIDX, 0x0005); /* read mode 0, write mode 0 */ outw(GDCIDX, 0x0003); /* data rotate/function select */ @@ -673,7 +1011,7 @@ height = imin(scp->curs_attr.height, scp->font_size); for (i = 0; i < height; ++i, --f) { outw(GDCIDX, (*f << 8) | 0x08); /* bit mask */ - writeb(d, 0); + writeb(d, 0); d -= line_width; } outw(GDCIDX, 0x0000); /* set/reset */ @@ -681,6 +1019,27 @@ outw(GDCIDX, 0xff08); /* bit mask */ } +static void +draw_pxlcursor(scr_stat *scp, int at, int on, int flip) +{ + int bpp; + + switch (scp->sc->adp->va_info.vi_mem_model) { + case V_INFO_MM_DIRECT: + bpp = scp->sc->adp->va_info.vi_depth; + + if ((bpp == 16) && + (scp->sc->adp->va_info.vi_pixel_fsizes[1] == 5)) + bpp = 15; + + draw_pxlcursor_direct(scp, at, on, flip, bpp); + break; + case V_INFO_MM_PLANAR: + draw_pxlcursor_planar(scp, at, on, flip); + break; + } +} + static int pxlblinkrate = 0; static void @@ -726,7 +1085,87 @@ #ifndef SC_NO_CUTPASTE static void -draw_pxlmouse(scr_stat *scp, int x, int y) +draw_pxlmouse_direct(scr_stat *scp, int x, int y, int bpp) +{ + vm_offset_t p; + int line_width, pixel_size; + int xend, yend; + static int x_old = 0, xend_old = 0; + static int y_old = 0, yend_old = 0; + int i, j; + uint32_t *u32; + uint16_t *u16; + + line_width = scp->sc->adp->va_line_width; + pixel_size = scp->sc->adp->va_info.vi_pixel_size; + + xend = imin(x + 16, scp->xpixel); + yend = imin(y + 16, scp->ypixel); + + p = scp->sc->adp->va_window + y_old * line_width + x_old * pixel_size; + + for (i = 0; i < (yend_old - y_old); i++) { + for (j = (xend_old - x_old - 1); j >= 0; j--) { + switch (bpp) { + case 32: + u32 = (uint32_t*)(p + j * pixel_size); + writel(u32, mouse_buf32[i * 16 + j]); + break; + case 16: + /* FALLTHROUGH */ + case 15: + u16 = (uint16_t*)(p + j * pixel_size); + writew(u16, mouse_buf16[i * 16 + j]); + break; + } + } + + p += line_width; + } + + p = scp->sc->adp->va_window + y * line_width + x * pixel_size; + + for (i = 0; i < (yend - y); i++) { + for (j = (xend - x - 1); j >= 0; j--) { + switch (bpp) { + case 32: + u32 = (uint32_t*)(p + j * pixel_size); + mouse_buf32[i * 16 + j] = *u32; + if (mouse_or_mask[i] & (1 << (15 - j))) + writel(u32, vga_palette32[15]); + else if (mouse_and_mask[i] & (1 << (15 - j))) + writel(u32, 0); + break; + case 16: + u16 = (uint16_t*)(p + j * pixel_size); + mouse_buf16[i * 16 + j] = *u16; + if (mouse_or_mask[i] & (1 << (15 - j))) + writew(u16, vga_palette16[15]); + else if (mouse_and_mask[i] & (1 << (15 - j))) + writew(u16, 0); + break; + case 15: + u16 = (uint16_t*)(p + j * pixel_size); + mouse_buf16[i * 16 + j] = *u16; + if (mouse_or_mask[i] & (1 << (15 - j))) + writew(u16, vga_palette15[15]); + else if (mouse_and_mask[i] & (1 << (15 - j))) + writew(u16, 0); + break; + } + } + + p += line_width; + } + + x_old = x; + y_old = y; + xend_old = xend; + yend_old = yend; +} + +static void +draw_pxlmouse_planar(scr_stat *scp, int x, int y) { vm_offset_t p; int line_width; @@ -801,7 +1240,28 @@ } static void -remove_pxlmouse(scr_stat *scp, int x, int y) +draw_pxlmouse(scr_stat *scp, int x, int y) +{ + int bpp; + + switch (scp->sc->adp->va_info.vi_mem_model) { + case V_INFO_MM_DIRECT: + bpp = scp->sc->adp->va_info.vi_depth; + + if ((bpp == 16) && + (scp->sc->adp->va_info.vi_pixel_fsizes[1] == 5)) + bpp = 15; + + draw_pxlmouse_direct(scp, x, y, bpp); + break; + case V_INFO_MM_PLANAR: + draw_pxlmouse_planar(scp, x, y); + break; + } +} + +static void +remove_pxlmouse_planar(scr_stat *scp, int x, int y) { vm_offset_t p; int col, row; @@ -857,6 +1317,18 @@ outw(GDCIDX, 0x0001); /* set/reset enable */ } +static void +remove_pxlmouse(scr_stat *scp, int x, int y) +{ + switch (scp->sc->adp->va_info.vi_mem_model) { + case V_INFO_MM_PLANAR: + remove_pxlmouse_planar(scp, x, y); + break; + default: + break; + } +} + static void vga_pxlmouse(scr_stat *scp, int x, int y, int on) { Cyrille Lefevre -- mailto:cyrille.lefevre@laposte.net From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 19:34:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5549A16A4CE for ; Sun, 29 Aug 2004 19:34:55 +0000 (GMT) Received: from huva.hittite.isp.9tel.net (huva.hittite.isp.9tel.net [62.62.156.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20A5243D3F for ; Sun, 29 Aug 2004 19:34:55 +0000 (GMT) (envelope-from clefevr-current@9online.fr) Received: from pc2k (78-240-118-80.kaptech.net [80.118.240.78]) by huva.hittite.isp.9tel.net (Postfix) with SMTP id E8F8414B7B3; Sun, 29 Aug 2004 21:48:32 +0200 (CEST) Message-ID: <080a01c48dff$4248a310$7890a8c0@gits.invalid> From: "Cyrille Lefevre" To: , "Deng XueFeng" Date: Sun, 29 Aug 2004 21:34:52 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 cc: current@freebsd.org Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support forFreeBSD-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Cyrille Lefevre List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 19:34:55 -0000 "Cyrille Lefevre" wrote: > "Vladimir Grebenschikov" wrote: > > On Sat, 2004-08-28 at 11:46 +0800, Deng XueFeng wrote: > > > > > > On Aug 27, 2004 01:59:50 am +0000, Deng XueFeng wrote: > > > > > First to thanks Sascha Wildner . > > > > > he hack syscons to make dfbsd support 1024x768(16/24/32) syscons, > > > > > then I ported that to current. and it works well with my ati MOBILITY > > > > > 7500[T31]/9200 [NX7000]. > > > > > To make console support 1024x768; just type > > > > > #vidcontrol MODE_279 > > > > How about another notebook native resolutions, 1400x1050 for example. > > you have to take a look at your video card reference guide... > AFAIK, maybe except for the standard video mode, the other video > mode are vendor dependent, but I may be wrong. here is the standard video modes (google "video +mode +279 +1024x768") : http://www.techweb.com/encyclopedia/defineterm?term=PCDISPLAYMODES(DETAILS)&exact=1 using google "video +mode +sxga +1400x1050", I find this : http://www.ccd.uab.es/~jordicj/linux/inspiron510m.php3 and using google "vesa +1400x1050", this : http://www.math.ucla.edu/~jimc/insp4100/X-setup.html Cyrille Lefevre. -- home: mailto:cyrille.lefevre@laposte.net From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 19:35:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F1C316A4CE; Sun, 29 Aug 2004 19:35:36 +0000 (GMT) Received: from zaphod.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90CE543D46; Sun, 29 Aug 2004 19:35:35 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 25B2111AB1; Sun, 29 Aug 2004 21:35:34 +0200 (CEST) Date: Sun, 29 Aug 2004 21:35:33 +0200 From: "Simon L. Nielsen" To: Ruslan Ermilov Message-ID: <20040829193533.GA760@zaphod.nitro.dk> References: <20040828142503.GA52613@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: <20040828142503.GA52613@ip.net.ua> User-Agent: Mutt/1.5.6i cc: Cameron Grant cc: current@FreeBSD.org cc: Seigo Tanimura cc: multimedia@FreeBSD.org Subject: Re: [PATCH] sound(4) related manpages 5.3 TODO item X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 19:35:36 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2004.08.28 17:25:03 +0300, Ruslan Ermilov wrote: > I've picked up the "sound(4) related manual pages" item from > the 5.3-RELEASE TODO list. Great :-). I hope to get as many sound device manual in as possible before 5.3, but I also have the Hardware Notes project to get done for 5.3, and I'm starting again at the university tomorrow... so help from others (including non-committers) would be great and I will be happy to review/commit for others. [snip parts I can't answer anyway] > Anyway, the attached patch adopts the sound(4) related man > pages to the new world order. How to proceed: [snip "TODO" list] > Does that look sane? I'd be grateful is someone more fluent with > our sound subsystem could review this. I'm (very) far from an expert on the sound system, but in general this looks very good to me. --=20 Simon L. Nielsen FreeBSD Documentation Team --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBMjAFh9pcDSc1mlERAjqUAJ9fKXYm+ObwhWUh/VeerrCW6PW85gCfZ0ib jQMA1eA7yIj/NF7h42mTxV4= =4veA -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 19:57:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 244E216A4CE for ; Sun, 29 Aug 2004 19:57:05 +0000 (GMT) Received: from tomts16-srv.bellnexxia.net (tomts16.bellnexxia.net [209.226.175.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 693F243D3F for ; Sun, 29 Aug 2004 19:57:04 +0000 (GMT) (envelope-from dashevil@sympatico.ca) Received: from [192.168.2.32] ([65.93.59.22]) by tomts16-srv.bellnexxia.net ESMTP <20040829195703.ZTYR14082.tomts16-srv.bellnexxia.net@[192.168.2.32]>; Sun, 29 Aug 2004 15:57:03 -0400 From: Chris Laverdure To: Justin Settle In-Reply-To: <1093790664.562.3.camel@amon.quaggaspace.org> References: <1093754957.564.24.camel@amon.quaggaspace.org> <1093742244.3464.1.camel@elemental.DashEvil> <1093790664.562.3.camel@amon.quaggaspace.org> Content-Type: text/plain Message-Id: <1093795010.65374.1.camel@elemental.DashEvil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 29 Aug 2004 15:57:03 +0000 Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: APIC causes vr0 watchdog timeouts and Interrupt storms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 19:57:05 -0000 On Sun, 2004-08-29 at 14:44, Justin Settle wrote: > On Sat, 2004-08-28 at 21:17, Chris Laverdure wrote: > > On Sun, 2004-08-29 at 04:49, Justin Settle wrote: > > > Hello, > > > > > > I recently installed 5.3-BETA. After booting, I found was unable to use > > > my usb mouse or my ethernet (Via-rhine). I started tinkering with the > > > kernel and found that if I disabled APIC, this system worked without > > > ethernet issues or mouse isssues. After talking with some people they > > > suggested I post boot -v, dmesg's of the different kernels so here they > > > are: > > > > > > The first thing I tried was a GENERIC with SMP commented out. It had > > > the same issues as GENERIC: > > > > > ... > > > ACPI is on both of these kernels but I've tried both without and the > > > results are the same. Should any other information be needed/wanted > > > I'll be sure to reply. Thank you for your time. > > > > > > Jay Settle > > > > > > > I too cannot use my USB mouse with ACPI enabled (yet it works fine > > without it). I get a Interrupt Storm when usbd tries to come up, and > > then moused fails claiming an "Input/Output error on /dev/ums0". > > > > I would love to get to the bottom of this. > > > Just to clarify, my problem isn't with ACPI, its with APIC :). My machine actually works fine with ACPI on (its on at the moment). If I boot it with APIC, however, things go downhill. > > Jay Settle > Oh, right. Sorry about that. However, I do have APIC compiled into my kernel. Have you tried APIC without ACPI? Should I try ACPI without APIC? From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 19:57:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39F9516A50D; Sun, 29 Aug 2004 19:57:14 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A23EC43D2D; Sun, 29 Aug 2004 19:57:12 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7TJuwvO050476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Aug 2004 22:56:59 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i7TJuwjd039851; Sun, 29 Aug 2004 22:56:58 +0300 (EEST) (envelope-from ru) Date: Sun, 29 Aug 2004 22:56:58 +0300 From: Ruslan Ermilov To: "M. Warner Losh" Message-ID: <20040829195658.GA39813@ip.net.ua> References: <20040825222345.GB79209@ip.net.ua> <20040825.163130.66167637.imp@bsdimp.com> <412D1CE6.3050603@root.org> <20040825.171523.10602123.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+xNpyl7Qekk2NvDX" Content-Disposition: inline In-Reply-To: <20040825.171523.10602123.imp@bsdimp.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: current@FreeBSD.org cc: John Baldwin cc: nate@root.org Subject: Re: No more floppy drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 19:57:14 -0000 --+xNpyl7Qekk2NvDX Content-Type: multipart/mixed; boundary="mxv5cy4qt+RJ9ypb" Content-Disposition: inline --mxv5cy4qt+RJ9ypb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 25, 2004 at 05:15:23PM -0600, M. Warner Losh wrote: > In message: <412D1CE6.3050603@root.org> > Nate Lawson writes: > : M. Warner Losh wrote: > : > In message: <20040825222345.GB79209@ip.net.ua> > : > Ruslan Ermilov writes: > : > : On Wed, Aug 25, 2004 at 04:17:33PM -0600, M. Warner Losh wrote: > : > : > Generally one doesn't want ANY hints when one has pnpisabios or a= cpi > : > : > supplying the hints, unless one really does have an exceptional d= evice > : > : > at that location. > : > : >=20 > : > : A lot of current@ users report missing /dev/fd0 due to this. Can t= his > : > : be fixed somehow? > : >=20 > : > acpi should be providing these hints, but it appears that either that > : > code isn't working, hasn't been committed or there's no fallback to > : > more traditional methods when there's no information about fd drives. > : > This is one of the twistiest, nastiest, ugliest part of PCAT :-( > :=20 > : The code I added merely does: > :=20 > : if (_FDE working) > : add fd[0-2] children accordingly > : if (fdX._FDI working) > : set type on fdX > : else > : unmodified hints probe for fd[0-2] > :=20 > : if (fdX type not set) > : unmodified drive type probe via rtc > :=20 > : Since the probe is unmodified if _FDE is not present, I can't see a new= =20 > : problem here. If this is a new problem, it must be elsewhere. >=20 > I'll take a look at things. I think it may have to do with > presence/absence things. >=20 Update. I tried to experiment a bit more today, and with ACPI, I cannot get fdc(4) working, with or without fdc hints in /boot/device.hints. So the only way to get my floppy working at the moment is: without ACPI and without hint.fdc.0. hints in /device.hints. Attached are verbose boot outputs without and with ACPI. Like I mentioned, with ACPI I'm also getting interrupt storms. Also, Warner, as you probably remember, I have to use the following on my notebook: hw.cbb.start_memory=3D0xd8000 Previously, without this tunable, my PCCARDs just were not properly attached. Now if I remove this line, the kernel panics at boot. Let me know if you're interested in the panic details. Also, could you remind me what this tunable does? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --mxv5cy4qt+RJ9ypb Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot.no_ACPI" Content-Transfer-Encoding: quoted-printable Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-CURRENT #8: Fri Aug 27 13:06:06 EEST 2004 ru@ru.ipnet.kiev.ua:/usr/obj/usr/src/sys/LURKER WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc0758000. Preloaded elf module "/boot/kernel/if_dc.ko" at 0xc0758228. Preloaded elf module "/boot/kernel/miibus.ko" at 0xc07582d4. Preloaded elf module "/boot/kernel/snd_csa.ko" at 0xc0758380. Preloaded elf module "/boot/kernel/sound.ko" at 0xc075842c. Calibrating clock(s) ... i8254 clock: 1193191 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 498273061 Hz CPU: Intel Pentium III (498.27-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x681 Stepping =3D 1 Features=3D0x387f9ff real memory =3D 134021120 (127 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000826000 - 0x0000000007d60fff, 122925056 bytes (30011 pages) avail memory =3D 125685760 (119 MB) bios32: Found BIOS32 Service Directory header at 0xc00fd800 bios32: Entry =3D 0xfd820 (c00fd820) Rev =3D 0 Len =3D 1 pcibios: PCI BIOS entry at 0xfd880+0x0 pnpbios: Found PnP BIOS data at 0xc00fe700 pnpbios: Entry =3D f0000:e724 Rev =3D 1.0 pnpbios: Event flag at 415 Other BIOS signatures found: random: io: mem: Pentium Pro MTRR support enabled null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pci_open(1): mode 1 addr port (0x0cf8) is 0x000038c8 pci_open(1a): mode1res=3D0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=3D060000] [hdr=3D00] is there (id=3D71908086) pcibios: BIOS version 2.10 Found $PIR table, 6 entries at 0xc00f9d00 PCI-Only Interrupts: 11 Location Bus Device Pin Link IRQs embedded 0 7 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 7 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 2 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 2 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 1 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 4 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 4 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 4 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 4 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 6 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 3 A 0x62 3 4 5 6 7 9 10 11 12 14 15 pcib0: pcibus 0 on motherboard pir0: on motherboard $PIR: Links after initial probe: Link IRQ Rtd Ref IRQs 0x60 255 N 5 3 4 5 6 7 9 10 11 12 14 15 0x63 255 N 2 3 4 5 6 7 9 10 11 12 14 15 0x61 255 N 2 3 4 5 6 7 9 10 11 12 14 15 0x62 255 N 2 3 4 5 6 7 9 10 11 12 14 15 $PIR: Found matching pin for 0.7.INTD at func 2: 11 $PIR: Found matching pin for 0.2.INTA at func 0: 11 $PIR: Found matching pin for 0.2.INTB at func 1: 11 $PIR: Found matching pin for 1.0.INTA at func 0: 11 $PIR: Found matching pin for 0.6.INTA at func 0: 11 $PIR: Found matching pin for 0.3.INTA at func 0: 11 $PIR: Links after initial IRQ discovery: Link IRQ Rtd Ref IRQs 0x60 11 Y 5 3 4 5 6 7 9 10 11 12 14 15 0x63 11 Y 2 3 4 5 6 7 9 10 11 12 14 15 0x61 11 Y 2 3 4 5 6 7 9 10 11 12 14 15 0x62 11 Y 2 3 4 5 6 7 9 10 11 12 14 15 $PIR: IRQs used by BIOS: 11 $PIR: Interrupt Weights: [ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ] [ 0 0 0 0 0 0 0 0 0 0 0 11 0 0 0 0 ] pci0: on pcib0 pci0: physical bus=3D0 map[10]: type 3, range 32, base 40000000, size 26, enabled found-> vendor=3D0x8086, dev=3D0x7190, revid=3D0x03 bus=3D0, slot=3D0, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0xa210, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x7191, revid=3D0x03 bus=3D0, slot=3D1, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0220, cachelnsz=3D0 (dwords) lattimer=3D0xa8 (5040 ns), mingnt=3D0x88 (34000 ns), maxlat=3D0x00 (0 ns) map[10]: type 1, range 32, base 50103000, size 12, enabled $PIR: 0:2 INTA routed to irq 11 found-> vendor=3D0x104c, dev=3D0xac1b, revid=3D0x03 bus=3D0, slot=3D2, func=3D0 class=3D06-07-00, hdrtype=3D0x02, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0xa8 (5040 ns), mingnt=3D0xc0 (48000 ns), maxlat=3D0x03 (750 ns) intpin=3Da, irq=3D11 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 50102000, size 12, enabled $PIR: 0:2 INTB routed to irq 11 found-> vendor=3D0x104c, dev=3D0xac1b, revid=3D0x03 bus=3D0, slot=3D2, func=3D1 class=3D06-07-00, hdrtype=3D0x02, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0xa8 (5040 ns), mingnt=3D0xc0 (48000 ns), maxlat=3D0x03 (750 ns) intpin=3Db, irq=3D11 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 50101000, size 8, enabled map[14]: type 4, range 32, base 00004500, size 3, enabled map[18]: type 4, range 32, base 00004400, size 8, enabled $PIR: 0:3 INTA routed to irq 11 found-> vendor=3D0x11c1, dev=3D0x0449, revid=3D0x01 bus=3D0, slot=3D3, func=3D0 class=3D07-80-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x8290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0xfc (63000 ns), maxlat=3D0x0e (3500 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D2 D3 current D0 map[10]: type 1, range 32, base 50100000, size 12, enabled map[14]: type 1, range 32, base 50000000, size 20, enabled $PIR: 0:6 INTA routed to irq 11 found-> vendor=3D0x1013, dev=3D0x6003, revid=3D0x01 bus=3D0, slot=3D6, func=3D0 class=3D04-01-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x0410, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x04 (1000 ns), maxlat=3D0x18 (6000 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 found-> vendor=3D0x8086, dev=3D0x7110, revid=3D0x02 bus=3D0, slot=3D7, func=3D0 class=3D06-80-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x000f, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) map[20]: type 4, range 32, base 0000fcf0, size 4, enabled found-> vendor=3D0x8086, dev=3D0x7111, revid=3D0x01 bus=3D0, slot=3D7, func=3D1 class=3D01-01-80, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x30 (1440 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) map[20]: type 4, range 32, base 00004000, size 5, enabled $PIR: 0:7 INTD routed to irq 11 found-> vendor=3D0x8086, dev=3D0x7112, revid=3D0x01 bus=3D0, slot=3D7, func=3D2 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x30 (1440 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dd, irq=3D11 map[90]: type 4, range 32, base 0000efa0, size 4, enabled found-> vendor=3D0x8086, dev=3D0x7113, revid=3D0x03 bus=3D0, slot=3D7, func=3D3 class=3D06-80-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0003, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) agp0: mem 0x40000000-0x43ffffff= at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0x40000000 agp0: allocating GATT for aperture of size 64M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: memory decode 0x70000000-0xdfffffff pcib1: prefetched decode 0xe0000000-0xf7ffffff pci1: on pcib1 pci1: physical bus=3D1 map[10]: type 3, range 32, base e0000000, size 25, enabled pcib1: device (null) requested decoded memory range 0xe0000000-0xe1ffffff map[14]: type 1, range 32, base 70000000, size 22, enabled pcib1: device (null) requested decoded memory range 0x70000000-0x703fffff map[18]: type 1, range 32, base 70400000, size 20, enabled pcib1: device (null) requested decoded memory range 0x70400000-0x704fffff $PIR: 1:0 INTA routed to irq 11 found-> vendor=3D0x10c8, dev=3D0x0006, revid=3D0x00 bus=3D1, slot=3D0, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x80 (3840 ns), mingnt=3D0x10 (4000 ns), maxlat=3D0xff (63750 n= s) intpin=3Da, irq=3D11 powerspec 1 supports D0 D1 D2 D3 current D0 pci1: at device 0.0 (no driver attached) cbb0: mem 0x50103000-0x50103fff irq 11 at devic= e 2.0 on pci0 cbb0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x50103000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0xac1b104c 0x02100007 0x06070003 0x0082a808=20 0x10: 0x50103000 0x020000a0 0xb0040200 0xfffff000=20 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc=20 0x30: 0x00000000 0x0000fffc 0x00000000 0x0740010b=20 0x40: 0x01301014 0x00000001 0x00000000 0x00000000=20 0x50: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x60: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x70: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x80: 0x00449068 0x00000000 0x80818080 0x00001000=20 0x90: 0x416682c0 0x00000000 0x00000000 0x00000000=20 0xa0: 0x7e110001 0x00c00000 0x00000000 0x00000000=20 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000=20 cbb1: mem 0x50102000-0x50102fff irq 11 at devic= e 2.1 on pci0 cbb1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x50102000 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [MPSAFE] cbb1: PCI Configuration space: 0x00: 0xac1b104c 0x02100007 0x06070003 0x0082a808=20 0x10: 0x50102000 0x220000a0 0xb0070500 0xfffff000=20 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc=20 0x30: 0x00000000 0x0000fffc 0x00000000 0x0740020b=20 0x40: 0x01301014 0x00000001 0x00000000 0x00000000=20 0x50: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x60: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x70: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x80: 0x00449068 0x00000000 0x80818080 0x00001000=20 0x90: 0x416683c0 0x00000000 0x00000000 0x00000000=20 0xa0: 0x7e110001 0x00c00000 0x00000000 0x00000000=20 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000=20 pci0: at device 3.0 (no driver attached) csa0: mem 0x50000000-0x500fffff,0x5010= 0000-0x50100fff irq 11 at device 6.0 on pci0 csa: card is Thinkpad 600X/A20/T20 csa0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x50100000 csa0: Reserved 0x100000 bytes for rid 0x14 type 3 at 0x50000000 csa0: [GIANT-LOCKED] pcm0: on csa0 pcm0: pcm0: Codec features headphone, 20 bit DAC, 18 bit ADC, 6 bit master volume= , Crystal Semi 3D Stereo Enhancement pcm0: Primary codec extended features AMAP pcm0: [GIANT-LOCKED] pcm0: sndbuf_setmap 198000, 1000; 0xc0f44000 -> 198000 pcm0: sndbuf_setmap 19a000, 1000; 0xc0f46000 -> 19a000 PCI-ISA bridge with incorrect subclass 0x80 PCI-ISA bridge with incorrect subclass 0x80 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xfcf0-0xfcff,0x376,0x170-0x1= 77,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfcf0 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 ata0-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0-slave: stat=3D0x00 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=3D03 ostat0=3D51 ostat1=3D01 ata1-master: stat=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata1-slave: stat=3D0x01 err=3D0x24 lsb=3D0x00 msb=3D0x00 ata1: reset tp2 stat0=3D00 stat1=3D01 devices=3D0x4 ata1: [MPSAFE] pci0: at device 7.2 (no driver attached) pci0: at device 7.3 (no driver attached) cpu0 on motherboard pnpbios: 18 devices, largest 122 bytes PNP0200: adding fixed io range 0-0xf, size=3D0x10, align=3D0x1 PNP0200: adding fixed io range 0x80-0x8f, size=3D0x10, align=3D0x1 PNP0200: adding fixed io range 0xc0-0xdf, size=3D0x20, align=3D0x1 PNP0200: adding dma mask 0x10 pnpbios: handle 1 device ID PNP0200 (0002d041) PNP0100: adding irq mask 0x1 PNP0100: adding fixed io range 0x40-0x43, size=3D0x4, align=3D0x1 pnpbios: handle 2 device ID PNP0100 (0001d041) PNP0b00: adding irq mask 0x100 PNP0b00: adding fixed io range 0x70-0x73, size=3D0x4, align=3D0x1 pnpbios: handle 3 device ID PNP0b00 (000bd041) PNP0800: adding fixed io range 0x61-0x61, size=3D0x1, align=3D0x1 pnpbios: handle 4 device ID PNP0800 (0008d041) PNP0303: adding irq mask 0x2 PNP0303: adding fixed io range 0x60-0x60, size=3D0x1, align=3D0x1 PNP0303: adding fixed io range 0x64-0x64, size=3D0x1, align=3D0x1 pnpbios: handle 5 device ID PNP0303 (0303d041) IBM3780: adding irq mask 0x1000 pnpbios: handle 6 device ID IBM3780 (80374d24) PNP0c04: adding fixed io range 0xf0-0xff, size=3D0x10, align=3D0x1 PNP0c04: adding irq mask 0x2000 pnpbios: handle 7 device ID PNP0c04 (040cd041) PNP0700: adding irq mask 0x40 PNP0700: adding io range 0x3f0-0x3f5, size=3D0x6, align=3D0x80 PNP0700: adding dma mask 0x4 pnpbios: handle 8 device ID PNP0700 (0007d041) PNP0a03: adding io range 0xcf8-0xcff, size=3D0x8, align=3D0 pnpbios: handle 9 device ID PNP0a03 (030ad041) PNP0c02: adding io range 0x22-0x22, size=3D0x1, align=3D0 PNP0c02: adding io range 0x2e-0x2f, size=3D0x2, align=3D0 PNP0c02: adding io range 0x92-0x92, size=3D0x1, align=3D0 PNP0c02: adding io range 0xb2-0xb3, size=3D0x2, align=3D0 PNP0c02: adding io range 0x4d0-0x4d1, size=3D0x2, align=3D0 PNP0c02: adding io range 0x15e0-0x15ef, size=3D0x10, align=3D0 PNP0c02: adding io range 0xef00-0xefaf, size=3D0xb0, align=3D0 PNP0c02: adding fixed memory32 range 0-0x9ffff, size=3D0xa0000 PNP0c02: adding fixed memory32 range 0xf0000-0xfffff, size=3D0x10000 PNP0c02: adding fixed memory32 range 0x100000-0x7ffffff, size=3D0x7f00000 PNP0c02: adding fixed memory32 range 0xffff0000-0xffffffff, size=3D0x10000 pnpbios: handle 10 device ID PNP0c02 (020cd041) PNP0400: adding irq mask 0x80 PNP0400: adding io range 0x3bc-0x3bf, size=3D0x4, align=3D0 pnpbios: handle 11 device ID PNP0400 (0004d041) PNP0501: adding irq mask 0x10 PNP0501: adding io range 0x3f8-0x3ff, size=3D0x8, align=3D0 pnpbios: handle 13 device ID PNP0501 (0105d041) IBM0071: adding irq mask 0x8 IBM0071: adding io range 0x2f8-0x2ff, size=3D0x8, align=3D0x1 IBM0071: adding dma mask 0x8 pnpbios: handle 14 device ID IBM0071 (71004d24) PNP0e03: adding io range 0-0x1, size=3D0x2, align=3D0 pnpbios: handle 15 device ID PNP0e03 (030ed041) PNP0680: adding irq mask 0x4000 PNP0680: adding io range 0x1f0-0x1f7, size=3D0x8, align=3D0 PNP0680: adding io range 0x3f6-0x3f7, size=3D0x2, align=3D0 PNP0680: adding io range 0xfcf0-0xfcf7, size=3D0x8, align=3D0 pnpbios: handle 18 device ID PNP0680 (8006d041) PNP0680: adding irq mask 0x8000 PNP0680: adding io range 0x170-0x177, size=3D0x8, align=3D0 PNP0680: adding io range 0x376-0x376, size=3D0x1, align=3D0 PNP0680: adding io range 0xfcf8-0xfcff, size=3D0x8, align=3D0 pnpbios: handle 20 device ID PNP0680 (8006d041) pnpbios: handle 22 device ID PNP0c02 (020cd041) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcbfff on isa0 atkbd: the current kbd controller command byte 0045 atkbd: keyboard ID 0x54ab (2) sc0: on isa0 sc0: VGA <16 virtual consoles, flags=3D0x200> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81=20 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81=20 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81=20 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0045 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) ppc0: parallel port found at 0x3bc ppc0: cannot reserve I/O port range ppc0: failed to probe at port 0x3bc-0x3c3 irq 7 on isa0 sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: irq maps: 0x1 0x9 0x1 0x1 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices unknown: failed to probe at port 0x61 on isa0 unknown: can't assign resources (port) unknown: at port 0x60 on isa0 unknown: can't assign resources (irq) unknown: at irq 12 on isa0 fdc0: ic_type 90 part_id 73 fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on= isa0 fdc0: ic_type 90 part_id 73 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 unknown: can't assign resources (port) unknown: at port 0x4d0-0x4d1,0xb2-0xb3,0x92,0x2e-0x2f,0x22 iomem = 0xffff0000-0xffffffff,0x100000-0x7ffffff,0xf0000-0xfffff,0-0x9ffff on isa0 ppc1: using normal I/O port range ppc1: SPP ppc1: at port 0x3bc-0x3bf irq 7 on isa0 ppc1: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc1 lpt0: on ppbus0 lpt0: Interrupt-driven port unknown: can't assign resources (port) unknown: at port 0x3f8-0x3ff on isa0 unknown: can't assign resources (port) unknown: at port 0x2f8-0x2ff on isa0 unknown: can't assign resources (port) unknown: at port 0-0x1 on isa0 unknown: can't assign resources (port) unknown: at port 0x1f0-0x1f7 on isa0 unknown: can't assign resources (port) unknown: at port 0x170-0x177 on isa0 Device configuration finished. procfs registered Timecounter "TSC" frequency 498273061 Hz quality 800 Timecounters tick every 10.000 msec lo0: bpf attached found-> vendor=3D0x115d, dev=3D0x0003, revid=3D0x03 bus=3D5, slot=3D0, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0000, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0xa8 (5040 ns), mingnt=3D0x14 (5000 ns), maxlat=3D0x28 (10000 n= s) intpin=3Da, irq=3D222 powerspec 1 supports D0 D1 D2 D3 current D0 dc0: port 0x1000-0x107f mem 0xd8000-0xd87ff,0xd= 8800-0xd8fff irq 11 at device 0.0 on cardbus1 miibus0: on dc0 tdkphy0: on miibus0 tdkphy0: OUI 0x00c039, model 0x0014, rev. 11 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: bpf attached dc0: Ethernet address: 00:10:a4:c0:c0:45 dc0: [GIANT-LOCKED] ata0-master: pio=3D0x0c wdma=3D0x22 udma=3D0x44 cable=3D80pin ata0-master: setting PIO4 on Intel PIIX4 chip ata0-master: setting UDMA33 on Intel PIIX4 chip ad0: ATA-4 disk at ata0-master ad0: 11509MB (23572080 sectors), 24944 C, 15 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA33 ata1-master: pio=3D0x0c wdma=3D0x22 udma=3D0xffffffff cable=3D40pin ATAPI_RESET time =3D 10us ata1-master: setting PIO4 on Intel PIIX4 chip acd0: DVDROM drive at ata1 as master acd0: 512KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc GEOM: new disk ad0 [0] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/74/63 s:0 l:23572080 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 0 length 12068904960 end 12068904959 GEOM: Configure ad0a, start 0 length 134217728 end 134217727 GEOM: Configure ad0b, start 134217728 length 134217728 end 268435455 GEOM: Configure ad0c, start 0 length 12068904960 end 12068904959 GEOM: Configure ad0e, start 268435456 length 268435456 end 536870911 GEOM: Configure ad0f, start 536870912 length 268435456 end 805306367 GEOM: Configure ad0g, start 805306368 length 11263598592 end 12068904959 GEOM: Configure ad0s1a, start 0 length 134217728 end 134217727 GEOM: Configure ad0s1b, start 134217728 length 134217728 end 268435455 GEOM: Configure ad0s1c, start 0 length 12068904960 end 12068904959 GEOM: Configure ad0s1e, start 268435456 length 268435456 end 536870911 GEOM: Configure ad0s1f, start 536870912 length 268435456 end 805306367 GEOM: Configure ad0s1g, start 805306368 length 11263598592 end 12068904959 Mounting root from ufs:/dev/ad0a start_init: trying /sbin/init gif0: bpf attached ipfw2 initialized, divert disabled, rule-based forwarding disabled, default= to deny, logging disabled --mxv5cy4qt+RJ9ypb Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="dmesg.boot.ACPI" Content-Transfer-Encoding: quoted-printable Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-CURRENT #8: Fri Aug 27 13:06:06 EEST 2004 ru@ru.ipnet.kiev.ua:/usr/obj/usr/src/sys/LURKER WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel/kernel" at 0xc07b7000. Preloaded elf module "/boot/kernel/if_dc.ko" at 0xc07b7228. Preloaded elf module "/boot/kernel/miibus.ko" at 0xc07b72d4. Preloaded elf module "/boot/kernel/snd_csa.ko" at 0xc07b7380. Preloaded elf module "/boot/kernel/sound.ko" at 0xc07b742c. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc07b74d8. Calibrating clock(s) ... i8254 clock: 1193195 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 498272951 Hz CPU: Intel Pentium III (498.27-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x681 Stepping =3D 1 Features=3D0x387f9ff real memory =3D 134021120 (127 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000826000 - 0x0000000007d60fff, 122925056 bytes (30011 pages) avail memory =3D 125681664 (119 MB) bios32: Found BIOS32 Service Directory header at 0xc00fd800 bios32: Entry =3D 0xfd820 (c00fd820) Rev =3D 0 Len =3D 1 pcibios: PCI BIOS entry at 0xfd880+0x0 pnpbios: Found PnP BIOS data at 0xc00fe700 pnpbios: Entry =3D f0000:e724 Rev =3D 1.0 pnpbios: Event flag at 415 Other BIOS signatures found: mem: Pentium Pro MTRR support enabled null: random: io: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard pci_open(1): mode 1 addr port (0x0cf8) is 0x000038c8 pci_open(1a): mode1res=3D0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=3D060000] [hdr=3D00] is there (id=3D71908086) pcibios: BIOS version 2.10 Found $PIR table, 6 entries at 0xc00f9d00 PCI-Only Interrupts: 11 Location Bus Device Pin Link IRQs embedded 0 7 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 7 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 2 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 2 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 1 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 4 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 4 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 4 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 4 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 6 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 3 A 0x62 3 4 5 6 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 1 func 0 acpi0: [MPSAFE] acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 2 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 2 func 1 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 3 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 7 func 1 acpi0: Power Button (fixed) atpic: Programming IRQ9 as level/low acpi_ec0: port 0x66,0x62 on acpi0 acpi_ec0: info: new max delay is 20 us acpi_ec0: info: new max delay is 30 us acpi_ec0: info: new max delay is 40 us acpi_ec0: info: new max delay is 60 us acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 0 func 1 ACPI timer looks BAD min =3D 2, max =3D 6, width =3D 4 ACPI timer looks BAD min =3D 2, max =3D 6, width =3D 4 ACPI timer looks BAD min =3D 2, max =3D 6, width =3D 4 ACPI timer looks BAD min =3D 2, max =3D 6, width =3D 4 ACPI timer looks BAD min =3D 2, max =3D 6, width =3D 4 ACPI timer looks BAD min =3D 2, max =3D 6, width =3D 4 ACPI timer looks BAD min =3D 2, max =3D 6, width =3D 4 ACPI timer looks BAD min =3D 2, max =3D 6, width =3D 4 ACPI timer looks BAD min =3D 2, max =3D 6, width =3D 4 ACPI timer looks BAD min =3D 2, max =3D 6, width =3D 4 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xef08-0xef0b on acpi0 cpu0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 acpi_tz2: on acpi0 acpi_tz3: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 unknown: not probed (disabled) pcib0: port 0xcf8-0xcff on acpi0 acpi link get: empty IRQ resource acpi link get: empty IRQ resource acpi link get: empty IRQ resource acpi link get: empty IRQ resource ACPI PCI link initial configuration: \\_SB_.LNKD irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 0+ low,level,sharab= le 0.7.3 \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 0+ low,level,sharab= le 0.2.0 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 0+ low,level,sharab= le 0.2.1 \\_SB_.LNKC irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 0+ low,level,sharab= le 0.3.0 \\_SB_.LNKB irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 0+ low,level,sharab= le 0.5.0 \\_SB_.LNKA irq 0: [ 3 4 5 6 7 9 10 11 12 14 15] 0+ low,level,sharab= le 0.6.0 pci0: on pcib0 pci0: physical bus=3D0 map[10]: type 3, range 32, base 40000000, size 26, enabled found-> vendor=3D0x8086, dev=3D0x7190, revid=3D0x03 bus=3D0, slot=3D0, func=3D0 class=3D06-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0006, statreg=3D0xa210, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) found-> vendor=3D0x8086, dev=3D0x7191, revid=3D0x03 bus=3D0, slot=3D1, func=3D0 class=3D06-04-00, hdrtype=3D0x01, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0220, cachelnsz=3D0 (dwords) lattimer=3D0xa8 (5040 ns), mingnt=3D0x88 (34000 ns), maxlat=3D0x00 (0 ns) map[10]: type 1, range 32, base 50103000, size 12, enabled pcib0: matched entry for 0.2.INTA (src \\_SB_.LNKA) pcib0: possible interrupts: 3 4 5 6 7 9 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.LNKA (references 2, priority 22867): interrupts: 11 10 5 9 12 7 6 4 3 15 = 14 penalty: 60 60 110 120 5060 5060 5060 5060 5060 50060 50060 \\_SB_.LNKB (references 2, priority 22867): interrupts: 11 10 5 9 12 7 6 4 3 15 = 14 penalty: 60 60 110 120 5060 5060 5060 5060 5060 50060 50060 \\_SB_.LNKD (references 1, priority 11433): interrupts: 11 10 5 9 12 7 6 4 3 15 = 14 penalty: 60 60 110 120 5060 5060 5060 5060 5060 50060 50060 \\_SB_.LNKC (references 1, priority 11433): interrupts: 11 10 5 9 12 7 6 4 3 15 = 14 penalty: 60 60 110 120 5060 5060 5060 5060 5060 50060 50060 acpi link get: empty IRQ resource acpi link set: _CRS failed for link \\_SB_.LNKA - AE_NULL_ENTRY acpi link set: curr irq 0 !=3D 11 for \\_SB_.LNKA pcib0: slot 2 INTA routed to irq 11 via \\_SB_.LNKA found-> vendor=3D0x104c, dev=3D0xac1b, revid=3D0x03 bus=3D0, slot=3D2, func=3D0 class=3D06-07-00, hdrtype=3D0x02, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0xa8 (5040 ns), mingnt=3D0xc0 (48000 ns), maxlat=3D0x03 (750 ns) intpin=3Da, irq=3D11 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 50102000, size 12, enabled pcib0: matched entry for 0.2.INTB (src \\_SB_.LNKB) pcib0: possible interrupts: 3 4 5 6 7 9 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.LNKB (references 2, priority 23001): interrupts: 10 11 5 9 12 7 6 4 3 15 = 14 penalty: 120 140 170 240 5120 5120 5120 5120 5120 50120 50120 \\_SB_.LNKD (references 1, priority 11500): interrupts: 10 11 5 9 12 7 6 4 3 15 = 14 penalty: 120 140 170 240 5120 5120 5120 5120 5120 50120 50120 \\_SB_.LNKC (references 1, priority 11500): interrupts: 10 11 5 9 12 7 6 4 3 15 = 14 penalty: 120 140 170 240 5120 5120 5120 5120 5120 50120 50120 acpi link get: empty IRQ resource acpi link set: _CRS failed for link \\_SB_.LNKB - AE_NULL_ENTRY acpi link set: curr irq 0 !=3D 10 for \\_SB_.LNKB atpic: Programming IRQ10 as level/low pcib0: slot 2 INTB routed to irq 10 via \\_SB_.LNKB found-> vendor=3D0x104c, dev=3D0xac1b, revid=3D0x03 bus=3D0, slot=3D2, func=3D1 class=3D06-07-00, hdrtype=3D0x02, mfdev=3D1 cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0xa8 (5040 ns), mingnt=3D0xc0 (48000 ns), maxlat=3D0x03 (750 ns) intpin=3Db, irq=3D10 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 50101000, size 8, enabled map[14]: type 4, range 32, base 00004500, size 3, enabled map[18]: type 4, range 32, base 00004400, size 8, enabled pcib0: matched entry for 0.3.INTA (src \\_SB_.LNKC) pcib0: possible interrupts: 3 4 5 6 7 9 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.LNKD (references 1, priority 11568): interrupts: 11 10 5 9 12 7 6 4 3 15 = 14 penalty: 200 200 230 360 5180 5180 5180 5180 5180 50180 50180 \\_SB_.LNKC (references 1, priority 11568): interrupts: 11 10 5 9 12 7 6 4 3 15 = 14 penalty: 200 200 230 360 5180 5180 5180 5180 5180 50180 50180 acpi link get: empty IRQ resource acpi link set: _CRS failed for link \\_SB_.LNKC - AE_NULL_ENTRY acpi link set: curr irq 0 !=3D 11 for \\_SB_.LNKC pcib0: slot 3 INTA routed to irq 11 via \\_SB_.LNKC found-> vendor=3D0x11c1, dev=3D0x0449, revid=3D0x01 bus=3D0, slot=3D3, func=3D0 class=3D07-80-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0107, statreg=3D0x8290, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0xfc (63000 ns), maxlat=3D0x0e (3500 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D2 D3 current D0 map[10]: type 1, range 32, base 50100000, size 12, enabled map[14]: type 1, range 32, base 50000000, size 20, enabled pcib0: matched entry for 0.6.INTA (src \\_SB_.LNKA) pcib0: slot 6 INTA is already routed to irq 11 found-> vendor=3D0x1013, dev=3D0x6003, revid=3D0x01 bus=3D0, slot=3D6, func=3D0 class=3D04-01-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0106, statreg=3D0x0410, cachelnsz=3D0 (dwords) lattimer=3D0x40 (1920 ns), mingnt=3D0x04 (1000 ns), maxlat=3D0x18 (6000 ns) intpin=3Da, irq=3D11 powerspec 2 supports D0 D1 D2 D3 current D0 found-> vendor=3D0x8086, dev=3D0x7110, revid=3D0x02 bus=3D0, slot=3D7, func=3D0 class=3D06-80-00, hdrtype=3D0x00, mfdev=3D1 cmdreg=3D0x000f, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) map[20]: type 4, range 32, base 0000fcf0, size 4, enabled found-> vendor=3D0x8086, dev=3D0x7111, revid=3D0x01 bus=3D0, slot=3D7, func=3D1 class=3D01-01-80, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x30 (1440 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) map[20]: type 4, range 32, base 00004000, size 5, enabled pcib0: matched entry for 0.7.INTD (src \\_SB_.LNKD) pcib0: possible interrupts: 3 4 5 6 7 9 10 11 12 14 15 ACPI PCI link arbitrated settings: \\_SB_.LNKD (references 1, priority 11634): interrupts: 10 11 5 9 12 7 6 4 3 15 = 14 penalty: 260 270 290 480 5240 5240 5240 5240 5240 50240 50240 acpi link get: empty IRQ resource acpi link set: _CRS failed for link \\_SB_.LNKD - AE_NULL_ENTRY acpi link set: curr irq 0 !=3D 10 for \\_SB_.LNKD pcib0: slot 7 INTD routed to irq 10 via \\_SB_.LNKD found-> vendor=3D0x8086, dev=3D0x7112, revid=3D0x01 bus=3D0, slot=3D7, func=3D2 class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0005, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x30 (1440 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) intpin=3Dd, irq=3D10 map[90]: type 4, range 32, base 0000efa0, size 4, enabled found-> vendor=3D0x8086, dev=3D0x7113, revid=3D0x03 bus=3D0, slot=3D7, func=3D3 class=3D06-80-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0003, statreg=3D0x0280, cachelnsz=3D0 (dwords) lattimer=3D0x00 (0 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) agp0: mem 0x40000000-0x43ffffff= at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0x40000000 agp0: allocating GATT for aperture of size 64M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xd000-0xdfff pcib1: memory decode 0x70000000-0xdfffffff pcib1: prefetched decode 0xe0000000-0xf7ffffff ACPI PCI link initial configuration: \\_SB_.LNKA irq*11: [ 3 4 5 6 7 9 10 11 12 14 15] 0+ low,level,sharab= le 1.0.0 \\_SB_.LNKB irq*10: [ 3 4 5 6 7 9 10 11 12 14 15] 0+ low,level,sharab= le 1.0.1 pci1: on pcib1 pci1: physical bus=3D1 map[10]: type 3, range 32, base e0000000, size 25, enabled pcib1: device (null) requested decoded memory range 0xe0000000-0xe1ffffff map[14]: type 1, range 32, base 70000000, size 22, enabled pcib1: device (null) requested decoded memory range 0x70000000-0x703fffff map[18]: type 1, range 32, base 70400000, size 20, enabled pcib1: device (null) requested decoded memory range 0x70400000-0x704fffff pcib1: matched entry for 1.0.INTA (src \\_SB_.LNKA) pcib1: slot 0 INTA is already routed to irq 11 found-> vendor=3D0x10c8, dev=3D0x0006, revid=3D0x00 bus=3D1, slot=3D0, func=3D0 class=3D03-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0007, statreg=3D0x0290, cachelnsz=3D0 (dwords) lattimer=3D0x80 (3840 ns), mingnt=3D0x10 (4000 ns), maxlat=3D0xff (63750 n= s) intpin=3Da, irq=3D11 powerspec 1 supports D0 D1 D2 D3 current D0 pci1: at device 0.0 (no driver attached) cbb0: mem 0x50103000-0x50103fff irq 11 at devic= e 2.0 on pci0 cbb0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x50103000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0xac1b104c 0x02100007 0x06070003 0x0082a808=20 0x10: 0x50103000 0x020000a0 0xb0040200 0xfffff000=20 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc=20 0x30: 0x00000000 0x0000fffc 0x00000000 0x0740010b=20 0x40: 0x01301014 0x00000001 0x00000000 0x00000000=20 0x50: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x60: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x70: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x80: 0x00449069 0x00000000 0x80818080 0x00001000=20 0x90: 0x416602c0 0x00000000 0x00000000 0x00000000=20 0xa0: 0x7e110001 0x00c00000 0x00000000 0x00000000=20 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000=20 cbb1: mem 0x50102000-0x50102fff irq 10 at devic= e 2.1 on pci0 cbb1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x50102000 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [MPSAFE] cbb1: PCI Configuration space: 0x00: 0xac1b104c 0x02100007 0x06070003 0x0082a808=20 0x10: 0x50102000 0x220000a0 0xb0070500 0xfffff000=20 0x20: 0x00000000 0xfffff000 0x00000000 0x0000fffc=20 0x30: 0x00000000 0x0000fffc 0x00000000 0x0740020a=20 0x40: 0x01301014 0x00000001 0x00000000 0x00000000=20 0x50: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x60: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x70: 0x00000000 0x00000000 0x00000000 0x00000000=20 0x80: 0x00449069 0x00000000 0x80818080 0x00001000=20 0x90: 0x416602c0 0x00000000 0x00000000 0x00000000=20 0xa0: 0x7e110001 0x00c00000 0x00000000 0x00000000=20 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000=20 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000=20 pci0: at device 3.0 (no driver attached) csa0: mem 0x50000000-0x500fffff,0x5010= 0000-0x50100fff irq 11 at device 6.0 on pci0 csa: card is Thinkpad 600X/A20/T20 csa0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x50100000 csa0: Reserved 0x100000 bytes for rid 0x14 type 3 at 0x50000000 csa0: [GIANT-LOCKED] pcm0: on csa0 pcm0: pcm0: Codec features headphone, 20 bit DAC, 18 bit ADC, 6 bit master volume= , Crystal Semi 3D Stereo Enhancement pcm0: Primary codec extended features AMAP pcm0: [GIANT-LOCKED] pcm0: sndbuf_setmap 23d000, 1000; 0xc0fa9000 -> 23d000 pcm0: sndbuf_setmap 1db000, 1000; 0xc0fa7000 -> 1db000 PCI-ISA bridge with incorrect subclass 0x80 PCI-ISA bridge with incorrect subclass 0x80 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xfcf0-0xfcff,0x376,0x170-0x1= 77,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xfcf0 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=3D03 ostat0=3D50 ostat1=3D00 ata0-master: stat=3D0x50 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0-slave: stat=3D0x00 err=3D0x01 lsb=3D0x00 msb=3D0x00 ata0: reset tp2 stat0=3D50 stat1=3D00 devices=3D0x1 ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=3D03 ostat0=3D51 ostat1=3D01 ata1-master: stat=3D0x00 err=3D0x01 lsb=3D0x14 msb=3D0xeb ata1-slave: stat=3D0x01 err=3D0x24 lsb=3D0x00 msb=3D0x00 ata1: reset tp2 stat0=3D00 stat1=3D01 devices=3D0x4 ata1: [MPSAFE] pci0: at device 7.2 (no driver attached) pci0: at device 7.3 (no driver attached) unknown: not probed (disabled) fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on= acpi0 fdc0: ic_type 90 part_id 73 sio0: irq maps: 0x601 0x611 0x601 0x601 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A ppc0: using extended I/O port range ppc0: SPP ppc0 port 0x3bc-0x3bf irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port unknown: not probed (disabled) sio1: irq maps: 0x601 0x609 0x601 0x601 sio1 port 0x2f8-0x2ff irq 3 drq 3 on acpi0 sio1: type 16550A unknown: not probed (disabled) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0045 atkbd: keyboard ID 0x54ab (2) kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0 irq 12 on acpi0 psm0: current command byte:0045 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) acpi_cmbat0: on acpi0 unknown: not probed (disabled) acpi_acad0: on acpi0 unknown: not probed (disabled) acpi_ec0: info: new max delay is 70 us unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) unknown: not probed (disabled) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sc: sc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it vga: vga0 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcbfff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=3D0x200> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81=20 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81=20 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81=20 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96=20 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c=20 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff=20 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 498272951 Hz quality 800 Timecounters tick every 10.000 msec lo0: bpf attached Interrupt storm detected on "irq10: cbb1"; throttling interrupt source cpu0: set speed to 100.0% acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% acpi_cmbat0: battery initialization start acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times acpi_tz1: _AC0: temperature 39.8 >=3D setpoint 33.5 acpi_tz1: switched from NONE to _AC0: 39.8C acpi_tz1: _AC0: temperature 39.8 >=3D setpoint 33.5 acpi_tz1: switched from NONE to _AC0: 39.8C found-> vendor=3D0x115d, dev=3D0x0003, revid=3D0x03 bus=3D5, slot=3D0, func=3D0 class=3D02-00-00, hdrtype=3D0x00, mfdev=3D0 cmdreg=3D0x0000, statreg=3D0x0210, cachelnsz=3D8 (dwords) lattimer=3D0xa8 (5040 ns), mingnt=3D0x14 (5000 ns), maxlat=3D0x28 (10000 n= s) intpin=3Da, irq=3D222 powerspec 1 supports D0 D1 D2 D3 current D0 dc0: port 0x1000-0x107f mem 0xd8000-0xd87ff,0xd= 8800-0xd8fff irq 10 at device 0.0 on cardbus1 miibus0: on dc0 tdkphy0: on miibus0 tdkphy0: OUI 0x00c039, model 0x0014, rev. 11 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: bpf attached dc0: Ethernet address: 00:10:a4:c0:c0:45 dc0: [GIANT-LOCKED] fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout ata0-master: pio=3D0x0c wdma=3D0x22 udma=3D0x44 cable=3D80pin acpi_tz1: _AC0: temperature 39.8 >=3D setpoint 33.5 acpi_tz1: switched from NONE to _AC0: 39.8C ata0-master: setting PIO4 on Intel PIIX4 chip ata0-master: setting UDMA33 on Intel PIIX4 chip ad0: ATA-4 disk at ata0-master ad0: 11509MB (23572080 sectors), 24944 C, 15 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA33 GEOM: new disk ad0 ata1-master: pio=3D0x0c wdma=3D0x22 udma=3D0xffffffff cable=3D40pin ATAPI_RESET time =3D 20us ata1-master: setting PIO4 on Intel PIIX4 chip acd0: DVDROM drive at ata1 as master acd0: 512KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc [0] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/74/63 s:0 l:23572080 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 0 length 12068904960 end 12068904959 GEOM: Configure ad0a, start 0 length 134217728 end 134217727 GEOM: Configure ad0b, start 134217728 length 134217728 end 268435455 GEOM: Configure ad0c, start 0 length 12068904960 end 12068904959 GEOM: Configure ad0e, start 268435456 length 268435456 end 536870911 GEOM: Configure ad0f, start 536870912 length 268435456 end 805306367 GEOM: Configure ad0g, start 805306368 length 11263598592 end 12068904959 GEOM: Configure ad0s1a, start 0 length 134217728 end 134217727 GEOM: Configure ad0s1b, start 134217728 length 134217728 end 268435455 GEOM: Configure ad0s1c, start 0 length 12068904960 end 12068904959 GEOM: Configure ad0s1e, start 268435456 length 268435456 end 536870911 GEOM: Configure ad0s1f, start 536870912 length 268435456 end 805306367 GEOM: Configure ad0s1g, start 805306368 length 11263598592 end 12068904959 Mounting root from ufs:/dev/ad0a start_init: trying /sbin/init fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout gif0: bpf attached ipfw2 initialized, divert disabled, rule-based forwarding disabled, default= to deny, logging disabled Interrupt storm detected on "irq11: cbb0 csa0"; throttling interrupt source --mxv5cy4qt+RJ9ypb-- --+xNpyl7Qekk2NvDX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBMjUKqRfpzJluFF4RAsYJAJwIjsR/hywA31NCKxJxGCtm/NTWBwCdGcuM HyWxbpTbBCsJPJ7wEx8bNrU= =Ert3 -----END PGP SIGNATURE----- --+xNpyl7Qekk2NvDX-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 19:59:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BA62916A4CE for ; Sun, 29 Aug 2004 19:59:36 +0000 (GMT) Received: from web.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0976D43D1F for ; Sun, 29 Aug 2004 19:59:36 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.1.100] (xDSL-2-2.united.net.ua [193.111.9.226]) (authenticated bits=0) by web.portaone.com (8.12.8p2/8.12.8) with ESMTP id i7TJxMEj006479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Aug 2004 21:59:25 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <4132358C.6060108@portaone.com> Date: Sun, 29 Aug 2004 22:59:08 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrille Lefevre References: <080a01c48dff$4248a310$7890a8c0@gits.invalid> In-Reply-To: <080a01c48dff$4248a310$7890a8c0@gits.invalid> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: vova@fbsd.ru cc: Deng XueFeng cc: current@freebsd.org Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support forFreeBSD-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 19:59:36 -0000 vidcontrol -i mode is your best friend! ;-) -Maxim Cyrille Lefevre wrote: > "Cyrille Lefevre" wrote: > >>"Vladimir Grebenschikov" wrote: >> >>>On Sat, 2004-08-28 at 11:46 +0800, Deng XueFeng wrote: >>> >>> >>>>>On Aug 27, 2004 01:59:50 am +0000, Deng XueFeng wrote: >>>>> >>>>>>First to thanks Sascha Wildner . >>>>>>he hack syscons to make dfbsd support 1024x768(16/24/32) syscons, >>>>>>then I ported that to current. and it works well with my ati MOBILITY >>>>>>7500[T31]/9200 [NX7000]. >>>>>>To make console support 1024x768; just type >>>>>>#vidcontrol MODE_279 >>> >>>How about another notebook native resolutions, 1400x1050 for example. >> >>you have to take a look at your video card reference guide... >>AFAIK, maybe except for the standard video mode, the other video >>mode are vendor dependent, but I may be wrong. > > > > here is the standard video modes (google "video +mode +279 +1024x768") : > > http://www.techweb.com/encyclopedia/defineterm?term=PCDISPLAYMODES(DETAILS)&exact=1 > > using google "video +mode +sxga +1400x1050", I find this : > > http://www.ccd.uab.es/~jordicj/linux/inspiron510m.php3 > > and using google "vesa +1400x1050", this : > > http://www.math.ucla.edu/~jimc/insp4100/X-setup.html > > Cyrille Lefevre. From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 20:59:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19C7C16A4CE; Sun, 29 Aug 2004 20:59:46 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45BB543D2D; Sun, 29 Aug 2004 20:59:45 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7TKxbTs051278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Aug 2004 23:59:38 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i7TKxgIx040203; Sun, 29 Aug 2004 23:59:42 +0300 (EEST) (envelope-from ru) Date: Sun, 29 Aug 2004 23:59:42 +0300 From: Ruslan Ermilov To: Mathew Kanner Message-ID: <20040829205942.GC39813@ip.net.ua> References: <20040828142503.GA52613@ip.net.ua> <20040829190833.GA9796@cnd.mcgill.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M/SuVGWktc5uNpra" Content-Disposition: inline In-Reply-To: <20040829190833.GA9796@cnd.mcgill.ca> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: Cameron Grant cc: multimedia@FreeBSD.org cc: "Simon L. Nielsen" cc: Seigo Tanimura cc: current@FreeBSD.org Subject: Re: [PATCH] sound(4) related manpages 5.3 TODO item X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 20:59:46 -0000 --M/SuVGWktc5uNpra Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 29, 2004 at 03:08:33PM -0400, Mathew Kanner wrote: > On Aug 28, Ruslan Ermilov wrote: >=20 > Hello Ruslan, >=20 > > One and most important thing I'm not sure I understand, and > > that's causing a lot of confusion, is why "device pcm" was > > renamed to "device sound" in the first place? I believe the > > reason is that "device sound" is a generic sound driver, > > which has support for PCM playback, mixer, /dev/sndstat, > > eventually MIDI, sequencer, and so on. Individual sound > > drivers are free to implement either of these interfaces. > > Most of them implement "pcm" nowadays, so saying that > > "pcm was renamed to sound" is not quite correct. In other > > words, the sound.ko module provides the infrastructure for > > more than just PCM, and the sound(4) manpage should eventually > > document more than just PCM. Does that sound correct? >=20 > Sounds correct on all accounts. Also, the synopsis should > indicate that the preferred method to load sound is to set > sound_load=3D"YES" in loader.conf and barely mention kernel options, and > otherwise ignore ISA and PNP. >=20 Um, what's wrong with ISA and PnP hints, and what's wrong with "device sound"? OK, I've briefly read your midi2-patch-aug22.diff patch, and I see that it implements "device midi" and the midi.ko module, and they are not part of "device sound", as I thought they would be. So I wonder, if it's correct to rename the pcm(4) manpage to sound(4), or will the sound(4) manpage be updated to document midi(4) as well? Also, the pcm(4) manpage (whether it's renamed to sound(4) or not) is seriously outdated. First, it talks only about pcm(4), and unless there are plans to update it with more than PCM, it should probably stay pcm(4). Its SYNOPSIS still assumes that "device pcm" provides all sound drivers (like it does in 4.x). The whole manpage needs to be revised and updated. Are you willing to help? > > 3. After repo-copies and deletes, the attached patch should be > > applied. It's mostly mechanical (foo -> snd_foo, pcm -> sound), > > with the following notable exceptions: > >=20 > > - Note that non-PnP ISA cards, such as those handled by snd_mss(4) > > and snd_ad1816(4), still require hints of the form > >=20 > > hint.pcm.0.at=3D"isa" > > hint.pcm.0.irq=3D"5" > > hint.pcm.0.drq=3D"1" > > hint.pcm.0.flags=3D"0x0" > >=20 > > because they implement device "pcm". Granted, the difference > > between module and driver name is confusing enough that Seigo > > misspelled hints names in sys/conf/NOTES, and Simon misspelled > > them in the new snd_ad1816(4) manpage. The patch corrects the > > hints names in the snd_ad1816(4) manpage and NOTES. The patch > > removes the "hint.snd_mss" from NOTES because (like was said) > > the snd_mss(4) module implements the "pcm" device, hence the > > hints start with "hint.pcm", and this is already documented > > in the sound(4) manpage. Module snd_sbc(4) and snd_gusc(4) > > are special in that they implement PCM support through the > > bridge device ("sbc" and "gusc", respectively), with "pcm" > > device as a child. For them, ISA hints should be spelled > > "hint.sbc" and "hint.gusc", respectively. This is also fixed > > in NOTES. >=20 > This is a very good catch, I never noticed this. >=20 I wish there would be more consistency in naming. Previously, we had the csa(4) manpage, "device csa", and /dev/csa* entries. Now we will have the snd_csa(4) manpage, "device snd_csa", but still /dev/csaX entry. Also, in the old world, "midi" devices were created as children of "pcm" devices, so "hint.pcm.0" hints for non-PnP ISA devices looked correct. In new world with your updated midi(4), what will be the hints for the ISA device that implements PCM and MIDI? hint.pcm.0 and hint.midi.0? ;) All is so plain in the old good 4.x world: /sys/i386/isa/sound/sb_card.c /sys/i386/isa/sound/sb_dsp.c /sys/i386/isa/sound/sb_midi.c /sys/i386/isa/sound/sb_mixer.c Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --M/SuVGWktc5uNpra Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBMkO+qRfpzJluFF4RAkDIAJ42JHH6V+Ocsh31XY0Bv0OlFhleeACfZuBL J3citDWqvci+h45zh6O+mBA= =U25R -----END PGP SIGNATURE----- --M/SuVGWktc5uNpra-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 21:02:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C5CF16A4CE for ; Sun, 29 Aug 2004 21:02:15 +0000 (GMT) Received: from chello080110061116.502.15.vie.surfer.at (chello080110061116.502.15.vie.surfer.at [80.110.61.116]) by mx1.FreeBSD.org (Postfix) with SMTP id D80B143D48 for ; Sun, 29 Aug 2004 21:02:13 +0000 (GMT) (envelope-from 4711@chello.at) Received: (qmail 2971 invoked from network); 29 Aug 2004 21:02:11 -0000 Received: from matrix010.matrix.net (192.168.123.10) by ns.matrix.net with SMTP; 29 Aug 2004 21:02:11 -0000 From: Christian Hiris <4711@chello.at> To: freebsd-current@freebsd.org, Elliot Finley Date: Sun, 29 Aug 2004 23:01:57 +0200 User-Agent: KMail/1.6.2 References: <01fc01c48d1e$d3985e50$32cba1cd@science1> In-Reply-To: <01fc01c48d1e$d3985e50$32cba1cd@science1> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_SRkMBauhmRQVkic"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408292302.11048.4711@chello.at> Subject: Re: 5.3 Beta2 boot problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 21:02:15 -0000 --Boundary-02=_SRkMBauhmRQVkic Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 28 August 2004 18:48, Elliot Finley wrote: > This is on an ASUS P4P800 GENERIC kernel. > > If I let the machine try to boot normally (hands off, or option 1 > [default]) I get: > > ACPI autoload failed - no such file or directory [snip] Did you read src/UPDATING? 20040806: Module loading has been fixed. Some older installations will drop proper module_path initialization and modules will fail to load properly. If you have a line in /boot/loader.rc that says: "initialize drop", do (i386 only): cp /usr/src/sys/boot/i386/loader/loader.rc /boot/loader.rc chown root:wheel /boot/loader.rc chmod 444 /boot/loader.rc Try to boot your old kernel and fix your /boot/loader.rc. Cheers, ch =2D-=20 Christian Hiris <4711@chello.at> | OpenPGP KeyID 0x941B6B0B=20 OpenPGP-Key at hkp://wwwkeys.eu.pgp.net and http://pgp.mit.edu --Boundary-02=_SRkMBauhmRQVkic Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBMkRScyi/EZQbawsRAoz4AJ0eTQ3Ffi9uuJphXXOed8XljtT+lQCdEo8A alR0NqPiE2x1QGeCM7lMQMg= =3F58 -----END PGP SIGNATURE----- --Boundary-02=_SRkMBauhmRQVkic-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 21:14:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D13F916A4D0 for ; Sun, 29 Aug 2004 21:14:34 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5A6243D2F for ; Sun, 29 Aug 2004 21:14:34 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id B831872DD4; Sun, 29 Aug 2004 14:14:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id B2F1172DCB; Sun, 29 Aug 2004 14:14:34 -0700 (PDT) Date: Sun, 29 Aug 2004 14:14:34 -0700 (PDT) From: Doug White To: Willem Jan Withagen In-Reply-To: <41305056.7030905@withagen.nl> Message-ID: <20040829141407.X69068@carver.gumbysoft.com> References: <20040822115345.Y94593@carver.gumbysoft.com> <20040826103652.F36995@carver.gumbysoft.com> <412E23F0.1010006@withagen.nl> <412F30AF.4050404@withagen.nl> <20040827190730.J51306@carver.gumbysoft.com> <41305056.7030905@withagen.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: PLEASE TEST: IPI deadlock avoidance patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 21:14:35 -0000 On Sat, 28 Aug 2004, Willem Jan Withagen wrote: > Doug White wrote: > > >134 = 128 + signal number. Anyway, can you check your rev of > >src/sys/kern/kern_lock.c? If its 1.74, please back up to a working > >kernel, cvsup, and rebuild. That rev is bogus. > > > > > But that has to take me beyond the RELENG_5 marker, right?? > Because after this mornings cvsup I still have: > __FBSDID("$FreeBSD: src/sys/kern/kern_lock.c,v 1.74.2.1 2004/08/26 > 00:00:18 kan > > I'll get myself a -CURRENT tree as well just to track these kinds of things. Thats correct for RELENG_5 -- thats the backout commit. HEAD has a revised version of the original change, but RELENG_5 shouldn't be showing corruption. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 21:34:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id B62B216A4CF; Sun, 29 Aug 2004 21:34:49 +0000 (GMT) Date: Sun, 29 Aug 2004 21:34:49 +0000 From: David O'Brien To: Kenneth Stailey Message-ID: <20040829213449.GA33843@hub.freebsd.org> References: <20040829141044.98464.qmail@web50601.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040829141044.98464.qmail@web50601.mail.yahoo.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.10-STABLE Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 21:34:49 -0000 On Sun, Aug 29, 2004 at 07:10:44AM -0700, Kenneth Stailey wrote: > Can a one-line example of how to invoke adduser to add new accounts like > "proxy" be added to /usr/src/UPDATING? That way people could just > cut-and-paste the accounts into place when upgrading. I've been trying to get RE@ to embelish this script and commit it to RELENG_5 to help with things like this: $ cat /usr/src/upgrade4ot5.sh #! /bin/sh # Some people don't read hier(9) and symlink /tmp and /var/tmp, # and /tmp can get cleared... SENTINEL=/$(basename %0) if [ ! -f ${SENTINEL}.kernel-done ]; then make buildworld && make buildkernel # install /boot/device.hints make installkernel # install new loader touch ${SENTINEL}.kernel-done reboot else mergemaster -p make installworld mergemaster -i rm ${SENTINEL}.* reboot endif From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 22:10:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AB4116A4CF for ; Sun, 29 Aug 2004 22:10:06 +0000 (GMT) Received: from chello080110061116.502.15.vie.surfer.at (chello080110061116.502.15.vie.surfer.at [80.110.61.116]) by mx1.FreeBSD.org (Postfix) with SMTP id 3C00943D45 for ; Sun, 29 Aug 2004 22:10:04 +0000 (GMT) (envelope-from 4711@chello.at) Received: (qmail 3167 invoked from network); 29 Aug 2004 22:10:03 -0000 Received: from matrix010.matrix.net (192.168.123.10) by ns.matrix.net with SMTP; 29 Aug 2004 22:10:03 -0000 From: Christian Hiris <4711@chello.at> To: freebsd-current@freebsd.org Date: Mon, 30 Aug 2004 00:09:50 +0200 User-Agent: KMail/1.6.2 References: <1093754957.564.24.camel@amon.quaggaspace.org> In-Reply-To: <1093754957.564.24.camel@amon.quaggaspace.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_6QlMBpAvclHfU9c"; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200408300010.02817.4711@chello.at> cc: Nate Lawson cc: Justin Settle Subject: Re: APIC causes vr0 watchdog timeouts and Interrupt storms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 22:10:06 -0000 --Boundary-02=_6QlMBpAvclHfU9c Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 29 August 2004 06:49, Justin Settle wrote: > Hello, > > I recently installed 5.3-BETA. After booting, I found was unable to use > my usb mouse or my ethernet (Via-rhine). I started tinkering with the > kernel and found that if I disabled APIC, this system worked without > ethernet issues or mouse isssues. After talking with some people they > suggested I post boot -v, dmesg's of the different kernels so here they > are: > > The first thing I tried was a GENERIC with SMP commented out. It had > the same issues as GENERIC: > > Copyright (c) 1992-2004 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 5.3-BETA2 #0: Sat Aug 28 23:18:57 EDT 2004 > root@amon.quaggaspace.org:/usr/obj/usr/src/sys/GENERICNOSMP [snip] > acpi link set: _CRS failed for link \\_SB_.PCI0.ALKB - AE_NULL_ENTRY > acpi link set: curr irq 0 !=3D 21 for \\_SB_.PCI0.ALKB (ignoring) > unknown: _SRS failed, irq 21 via \\_SB_.PCI0.ALKB > found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0x80 > bus=3D0, slot=3D16, func=3D0 > class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D8 (dwords) > lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Da, irq=3D11 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[20]: type 4, range 32, base 0000d400, size 5, enabled > pcib0: matched entry for 0.16.INTB (src \\_SB_.PCI0.ALKB) > pcib0: slot 16 INTB is already routed to irq 21 > found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0x80 > bus=3D0, slot=3D16, func=3D1 > class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D8 (dwords) > lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Db, irq=3D21 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[20]: type 4, range 32, base 0000d800, size 5, enabled > pcib0: matched entry for 0.16.INTC (src \\_SB_.PCI0.ALKB) > pcib0: slot 16 INTC is already routed to irq 21 > found-> vendor=3D0x1106, dev=3D0x3038, revid=3D0x80 > bus=3D0, slot=3D16, func=3D2 > class=3D0c-03-00, hdrtype=3D0x00, mfdev=3D1 > cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D8 (dwords) > lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Dc, irq=3D21 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type 1, range 32, base ee000000, size 8, enabled > pcib0: matched entry for 0.16.INTD (src \\_SB_.PCI0.ALKB) > pcib0: slot 16 INTD is already routed to irq 21 > found-> vendor=3D0x1106, dev=3D0x3104, revid=3D0x82 > bus=3D0, slot=3D16, func=3D3 > class=3D0c-03-20, hdrtype=3D0x00, mfdev=3D0 > cmdreg=3D0x0007, statreg=3D0x0210, cachelnsz=3D8 (dwords) > lattimer=3D0x20 (960 ns), mingnt=3D0x00 (0 ns), maxlat=3D0x00 (0 ns) > intpin=3Dd, irq=3D21 > powerspec 2 supports D0 D1 D2 D3 current D0 [snip] > Interrupt storm detected on "irq21: uhci1 uhci2"; throttling interrupt > source [snip] I had similar USB problems on a Via KT600 board. In my case, manual irq=20 routing fixed the interrupt strom on irq 21. =20 # cat /boot/device.hints | grep acpi hw.acpi.pci.link.0.16.0.irq=3D21 hw.acpi.pci.link.0.16.1.irq=3D21 hw.acpi.pci.link.0.16.2.irq=3D21 hw.acpi.pci.link.0.16.3.irq=3D21 USB works perfectly now with ACPI and with options SMP/APIC defined in my=20 kernelconfig and ACPI.=20 Nate Lawson comitted some major improvements on the acpi_pci_link.c code=20 regarding the _CRS and _SRS objects and KTxxx bords in the last weeks, so I= =20 think it's a good idea cc'ing him. =20 I can't tell you much about the vr (VT6102) because it's irq routing is=20 different on the KT600 board (device 0.18.0 --> irq 5 ) and the chip=20 initializes without problems here.=20 Cheers,=20 ch=20 =2D-=20 Christian Hiris <4711@chello.at> | OpenPGP KeyID 0x941B6B0B=20 OpenPGP-Key at hkp://wwwkeys.eu.pgp.net and http://pgp.mit.edu --Boundary-02=_6QlMBpAvclHfU9c Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBMlQ6cyi/EZQbawsRAk43AJ49sfOBTbIZSs9HRF48fCnqJOUyFgCfbeqi vVxON1fhoXnGWEMMqbwPyU4= =Yu2k -----END PGP SIGNATURE----- --Boundary-02=_6QlMBpAvclHfU9c-- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 22:29:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FDF716A4CE for ; Sun, 29 Aug 2004 22:29:09 +0000 (GMT) Received: from lakermmtao05.cox.net (lakermmtao05.cox.net [68.230.240.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 115AE43D5A for ; Sun, 29 Aug 2004 22:29:09 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.71.51]) by lakermmtao05.cox.net (InterMail vM.6.01.03.02.01 201-2131-111-104-103-20040709) with ESMTP id <20040829222901.LGXF25497.lakermmtao05.cox.net@dolphin.local.net> for ; Sun, 29 Aug 2004 18:29:01 -0400 Received: from dolphin.local.net (localhost.local.net [127.0.0.1]) by dolphin.local.net (8.13.1/8.13.1) with SMTP id i7TMT1VT018965 for ; Sun, 29 Aug 2004 17:29:02 -0500 (CDT) (envelope-from conrads@cox.net) Date: Sun, 29 Aug 2004 17:28:56 -0500 From: "Conrad J. Sabatier" To: freebsd-current@freebsd.org Message-Id: <20040829172856.413f6e96@dolphin.local.net> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; amd64-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: It appears that ACPI and the nVidia nForce3 chipset just don't get along X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 22:29:09 -0000 Upgraded my system this Friday just past, and ran for a while with ACPI enabled. Sure enough, sound broke again, just as before. Rebooted with ACPI disabled, and have had my MP3 jukebox running continuously now for two days with no problems. It definitely appears that ACPI and the nVidia nForce3 chipset just don't get along for some reason. If anyone would like to see the verbose output from a boot with ACPI enabled, just holler. -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 22:29:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98A6816A4CE for ; Sun, 29 Aug 2004 22:29:46 +0000 (GMT) Received: from tomts10-srv.bellnexxia.net (tomts10.bellnexxia.net [209.226.175.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0701143D60 for ; Sun, 29 Aug 2004 22:29:46 +0000 (GMT) (envelope-from dashevil@sympatico.ca) Received: from [192.168.2.32] ([65.93.59.22]) by tomts10-srv.bellnexxia.net ESMTP <20040829222945.BXOQ29920.tomts10-srv.bellnexxia.net@[192.168.2.32]>; Sun, 29 Aug 2004 18:29:45 -0400 From: Chris Laverdure To: Christian Hiris <4711@chello.at> In-Reply-To: <200408300010.02817.4711@chello.at> References: <1093754957.564.24.camel@amon.quaggaspace.org> <200408300010.02817.4711@chello.at> Content-Type: text/plain Message-Id: <1093804183.11032.1.camel@elemental.DashEvil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 29 Aug 2004 18:29:44 +0000 Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: APIC causes vr0 watchdog timeouts and Interrupt storms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 22:29:46 -0000 On Sun, 2004-08-29 at 22:09, Christian Hiris wrote: > On Sunday 29 August 2004 06:49, Justin Settle wrote: > ... > > I had similar USB problems on a Via KT600 board. In my case, manual irq > routing fixed the interrupt strom on irq 21. > > # cat /boot/device.hints | grep acpi > hw.acpi.pci.link.0.16.0.irq=21 > hw.acpi.pci.link.0.16.1.irq=21 > hw.acpi.pci.link.0.16.2.irq=21 > hw.acpi.pci.link.0.16.3.irq=21 > > USB works perfectly now with ACPI and with options SMP/APIC defined in my > kernelconfig and ACPI. > > Nate Lawson comitted some major improvements on the acpi_pci_link.c code > regarding the _CRS and _SRS objects and KTxxx bords in the last weeks, so I > think it's a good idea cc'ing him. > > I can't tell you much about the vr (VT6102) because it's irq routing is > different on the KT600 board (device 0.18.0 --> irq 5 ) and the chip > initializes without problems here. > > Cheers, > ch After my portupgrade -f kde* is done I'll try that out and see if it does anything for me. (Not sure of the exact model, but I have a VIA motherboard as well) Thanks. From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 22:37:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7724D16A4CE for ; Sun, 29 Aug 2004 22:37:59 +0000 (GMT) Received: from mail2.neureal.com (mail2.neureal.com [66.98.170.78]) by mx1.FreeBSD.org (Postfix) with SMTP id 0EB6C43D46 for ; Sun, 29 Aug 2004 22:37:59 +0000 (GMT) (envelope-from quaggamail@quaggaspace.org) Received: (qmail 9055 invoked by uid 399); 29 Aug 2004 22:37:57 -0000 Received: from unknown (HELO ?192.168.42.25?) (68.162.100.90) by mail2.neureal.com with SMTP; 29 Aug 2004 22:37:57 -0000 From: Justin Settle To: Chris Laverdure In-Reply-To: <1093795010.65374.1.camel@elemental.DashEvil> References: <1093754957.564.24.camel@amon.quaggaspace.org> <1093742244.3464.1.camel@elemental.DashEvil> <1093790664.562.3.camel@amon.quaggaspace.org> <1093795010.65374.1.camel@elemental.DashEvil> Content-Type: text/plain Message-Id: <1093819100.1268.5.camel@amon.quaggaspace.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 29 Aug 2004 18:38:20 -0400 Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: APIC causes vr0 watchdog timeouts and Interrupt storms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 22:37:59 -0000 On Sun, 2004-08-29 at 11:57, Chris Laverdure wrote: > On Sun, 2004-08-29 at 14:44, Justin Settle wrote: > > On Sat, 2004-08-28 at 21:17, Chris Laverdure wrote: > > > On Sun, 2004-08-29 at 04:49, Justin Settle wrote: > > > > Hello, > > > > > > > > I recently installed 5.3-BETA. After booting, I found was unable to use > > > > my usb mouse or my ethernet (Via-rhine). I started tinkering with the > > > > kernel and found that if I disabled APIC, this system worked without > > > > ethernet issues or mouse isssues. After talking with some people they > > > > suggested I post boot -v, dmesg's of the different kernels so here they > > > > are: > > > > > > > > The first thing I tried was a GENERIC with SMP commented out. It had > > > > the same issues as GENERIC: > > > > > > > ... > > > > ACPI is on both of these kernels but I've tried both without and the > > > > results are the same. Should any other information be needed/wanted > > > > I'll be sure to reply. Thank you for your time. > > > > > > > > Jay Settle > > > > > > > > > > I too cannot use my USB mouse with ACPI enabled (yet it works fine > > > without it). I get a Interrupt Storm when usbd tries to come up, and > > > then moused fails claiming an "Input/Output error on /dev/ums0". > > > > > > I would love to get to the bottom of this. > > > > > Just to clarify, my problem isn't with ACPI, its with APIC :). My machine actually works fine with ACPI on (its on at the moment). If I boot it with APIC, however, things go downhill. > > > > Jay Settle > > > > Oh, right. Sorry about that. > > However, I do have APIC compiled into my kernel. Have you tried APIC > without ACPI? Should I try ACPI without APIC? ACPI doesn't seem to matter on my machine. It works fine with it, or without it. I've tried all combinations of ACPI and APIC; only APIC seems to matter. This is a KT400 board if you have something similar. In my case I'm content to just leave APIC off and ACPI on as that works for me. The only downside is that the default kernel comes with device apic on so I have to do a recompile before getting to the net. Jay Settle From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 22:39:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C303616A4D3; Sun, 29 Aug 2004 22:39:06 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80ED343D2F; Sun, 29 Aug 2004 22:39:06 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.13.1/8.12.11) with ESMTP id i7TMd5Da094150; Sun, 29 Aug 2004 15:39:06 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i7TMd52h094149; Sun, 29 Aug 2004 15:39:05 -0700 (PDT) (envelope-from obrien) Date: Sun, 29 Aug 2004 15:39:05 -0700 From: "David O'Brien" To: Gordon Tetlow Message-ID: <20040829223905.GB92947@dragon.nuxi.com> Mail-Followup-To: David O'Brien , Gordon Tetlow , current@freebsd.org References: <200408160104.03708.chris@behanna.org> <20040826005527.GF54515@spiff.melthusia.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040826005527.GF54515@spiff.melthusia.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: current@freebsd.org Subject: Re: Public Access to Perforce? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 22:39:06 -0000 On Wed, Aug 25, 2004 at 05:55:28PM -0700, Gordon Tetlow wrote: > Now Perforce performance demands that as much of the metadata in memory > as possible. We are already starting to see the pressure with the > operations that our developers are doing on the depot. When we ask > Perforce support about ways to improve it, they generally tell us to > throw more memory at the problem but we are limited in how far we can > go with that (the box already has 2GB of memory in it). Ask Perforce to port to 64-bit AMD64. That would allow them to have a lot more memory for their in-memory operations. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 22:40:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51D6A16A52A; Sun, 29 Aug 2004 22:40:50 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D65C43DC9; Sun, 29 Aug 2004 22:40:47 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.13.1/8.12.11) with ESMTP id i7TMekuW094179; Sun, 29 Aug 2004 15:40:46 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i7TMekYu094178; Sun, 29 Aug 2004 15:40:46 -0700 (PDT) (envelope-from obrien) Date: Sun, 29 Aug 2004 15:40:45 -0700 From: "David O'Brien" To: Pawel Jakub Dawidek Message-ID: <20040829224045.GC92947@dragon.nuxi.com> Mail-Followup-To: David O'Brien , Pawel Jakub Dawidek , FreeBSD Tinderbox , current@freebsd.org, ia64@freebsd.org References: <20040829091547.927B07303F@freebsd-current.sentex.ca> <20040829143543.GX30151@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040829143543.GX30151@darkness.comp.waw.pl> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: ia64@FreeBSD.org cc: FreeBSD Tinderbox cc: current@FreeBSD.org Subject: Re: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 22:40:54 -0000 On Sun, Aug 29, 2004 at 04:35:43PM +0200, Pawel Jakub Dawidek wrote: > On Sun, Aug 29, 2004 at 05:15:47AM -0400, FreeBSD Tinderbox wrote: > +> /tinderbox/CURRENT/ia64/ia64/src/sys/geom/mirror/g_mirror.c: In function `g_mirror_taste': > +> /tinderbox/CURRENT/ia64/ia64/src/sys/geom/mirror/g_mirror.c:2485: warning: 'sc' might be used uninitialized in this function > +> *** Error code 1 > > Fixed, sorry. > PS. Can someone show me which compiler flag expose those "bugs"? I've fixed a few of these (one in your code before I think). A simply compile test on Sledge.freebsd.org with default CFLAGS will show the problem. Sledge is really fast to compile on. :-) -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 22:42:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 445D316A4CE; Sun, 29 Aug 2004 22:42:12 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2360D43D5A; Sun, 29 Aug 2004 22:42:12 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.13.1/8.12.11) with ESMTP id i7TMgB9E094227; Sun, 29 Aug 2004 15:42:11 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i7TMgBYr094226; Sun, 29 Aug 2004 15:42:11 -0700 (PDT) (envelope-from obrien) Date: Sun, 29 Aug 2004 15:42:11 -0700 From: "David O'Brien" To: Ruslan Ermilov Message-ID: <20040829224211.GD92947@dragon.nuxi.com> Mail-Followup-To: David O'Brien , Ruslan Ermilov , ia64@freebsd.org, current@freebsd.org References: <20040829091547.927B07303F@freebsd-current.sentex.ca> <20040829143543.GX30151@darkness.comp.waw.pl> <20040829145603.GG23120@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040829145603.GG23120@ip.net.ua> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: ia64@freebsd.org cc: current@freebsd.org Subject: Re: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 22:42:12 -0000 On Sun, Aug 29, 2004 at 05:56:03PM +0300, Ruslan Ermilov wrote: > > +> /tinderbox/CURRENT/ia64/ia64/src/sys/geom/mirror/g_mirror.c:2485: warning: 'sc' might be used uninitialized in this function > > +> *** Error code 1 > > > > Fixed, sorry. > > PS. Can someone show me which compiler flag expose those "bugs"? > > > I believe it's -O2 (which is not in default CFLAGS). All the world is not 'i386'... -O2 is the default on some of our platforms -- amd64, sparc64, ia64 -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 22:49:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 265DD16A4CE; Sun, 29 Aug 2004 22:49:47 +0000 (GMT) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFE7743D1F; Sun, 29 Aug 2004 22:49:46 +0000 (GMT) (envelope-from kientzle@freebsd.org) Received: from freebsd.org (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id i7TMnk90049997; Sun, 29 Aug 2004 15:49:46 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <41325D89.5040806@freebsd.org> Date: Sun, 29 Aug 2004 15:49:45 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: obrien@freebsd.org References: <200408160104.03708.chris@behanna.org> <20040826005527.GF54515@spiff.melthusia.org> <20040829223905.GB92947@dragon.nuxi.com> In-Reply-To: <20040829223905.GB92947@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Gordon Tetlow cc: current@freebsd.org Subject: Re: Public Access to Perforce? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 22:49:47 -0000 David O'Brien wrote: > On Wed, Aug 25, 2004 at 05:55:28PM -0700, Gordon Tetlow wrote: > >>Now Perforce performance demands that as much of the metadata in memory >>as possible. We are already starting to see the pressure with the >>operations that our developers are doing on the depot. When we ask >>Perforce support about ways to improve it, they generally tell us to >>throw more memory at the problem but we are limited in how far we can >>go with that (the box already has 2GB of memory in it). > > > Ask Perforce to port to 64-bit AMD64. That would allow them to have a > lot more memory for their in-memory operations. Another possibility would be to switch from Perforce to something like SVN. I'm not sure how it compares to Perforce, but SVN has much better branch and merge support than CVS does. It's also specifically designed for use over slow networks, which would be a real plus. Tim Kientzle From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 22:53:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 898BB16A4CE; Sun, 29 Aug 2004 22:53:24 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 545E243D54; Sun, 29 Aug 2004 22:53:24 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.13.1/8.12.11) with ESMTP id i7TMrFg3094551; Sun, 29 Aug 2004 15:53:15 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i7TMrEhJ094550; Sun, 29 Aug 2004 15:53:14 -0700 (PDT) (envelope-from obrien) Date: Sun, 29 Aug 2004 15:53:14 -0700 From: "David O'Brien" To: "Conrad J. Sabatier" Message-ID: <20040829225314.GE92947@dragon.nuxi.com> References: <20040809184110.V80973@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-current@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: cvsup on amd64 just broke today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 22:53:24 -0000 On Mon, Aug 09, 2004 at 08:54:43PM -0500, Conrad J. Sabatier wrote: > On 10-Aug-2004 Doug White wrote: > > On Mon, 9 Aug 2004, Conrad J. Sabatier wrote: > >> # make update > >> -------------------------------------------------------------- > >> >>> Running /usr/local/bin/cvsup > >> -------------------------------------------------------------- > >> /usr/local/libexec/cvsup-static.i386.bin: 1: Syntax error: "(" > >> unexpected > >> *** Error code 2 > > > > Can you run cvsup manually? It appears to be trying to execute a > > binary as a shell script here. > > Tried that, got the same result. > > I hadn't noticed it before, but it does strike me as odd that the > binary package for amd64 would include a file with "i386" in the name, > and which is, in fact, an ELF 32 binary. Why is it odd?!? The ability to run legacy 32-bit x86 binaries under a 64-bit OS at full-speed is one of the huge capabilities AMD brought with this architecture. Unless a binary does 64-bit math or addresses >4GB of memory why does something need to be 64-bit??? The fact that all Open Source OS's have a 64-bit userland on all their 64-bit platforms that grew up from 32-bit CPU's shows how unsophisticated our build framework is. "64-bit" Solaris today is really a 64-bit kernel and mostly 32-bit userland. > Did something change today that would effect the handling of such a > file, perhaps? Nope, it has been a 32-bit 'i386' binary since the day the port started supporting FreeBSD/AMD64. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 22:55:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D322F16A4CE for ; Sun, 29 Aug 2004 22:55:21 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7D3343D5A for ; Sun, 29 Aug 2004 22:55:21 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id BD2E172DD4; Sun, 29 Aug 2004 15:55:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id B534572DCB; Sun, 29 Aug 2004 15:55:21 -0700 (PDT) Date: Sun, 29 Aug 2004 15:55:21 -0700 (PDT) From: Doug White To: bettan@nerim.net In-Reply-To: <2336.::ffff:62.212.121.38.1093351830.squirrel@::ffff:62.212.121.38> Message-ID: <20040829155430.C69068@carver.gumbysoft.com> References: <2336.::ffff:62.212.121.38.1093351830.squirrel@::ffff:62.212.121.38> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: altq on freebsd 5.2-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 22:55:22 -0000 Pick an email address :) On Tue, 24 Aug 2004 bettan@nerim.net wrote: > I have patched if_xl.c dans if_vr.c with this patchs > http://people.freebsd.org/~mlaier/ALTQ_driver/ and i have put this rules > in my pf.conf : > > int = "xl0" The first round of ALTQ interface changes were was committed over a month ago. Update to a recent -CURRENT then retry. Otherwise I'd contact mlaier directly. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 22:57:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58FD516A4CF for ; Sun, 29 Aug 2004 22:57:17 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id E309243D3F for ; Sun, 29 Aug 2004 22:57:16 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so50308rnl for ; Sun, 29 Aug 2004 15:57:16 -0700 (PDT) Received: by 10.38.73.36 with SMTP id v36mr681763rna; Sun, 29 Aug 2004 15:57:16 -0700 (PDT) Received: by 10.38.75.25 with HTTP; Sun, 29 Aug 2004 15:57:16 -0700 (PDT) Message-ID: <790a9fff040829155742846d42@mail.gmail.com> Date: Sun, 29 Aug 2004 17:57:16 -0500 From: Scot Hetzel To: freebsd-current@freebsd.org In-Reply-To: <790a9fff040825071252f4e43a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <790a9fff040825071252f4e43a@mail.gmail.com> cc: Søren Schmidt Subject: Re: Kernel Crash in ata_pio_read X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Scot Hetzel List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 22:57:17 -0000 On Wed, 25 Aug 2004 09:12:37 -0500, Scot Hetzel wrote: > I have been experiencing a problem where the computer will boot upon > power up the first time, but a reboot of the system causes a Fatal > trap 12. > Powering the system off for 5-30 mins, still won't allow it to boot > when powered up. But, turn it off at night (12 mid), and then boot it > up in the morning (7:30) and the first boot succeeds. > > Below is a hand transcribe of the dmesg and debugger output: > > ATAPI_RESET time = 330us > ad0: 26105mb [53040/16/63] at ata0-master BIOSPIO > acd0: WARNING - MODE_SENSE_BIG interrupt was seen but taskqueue stalled > acd0: WARNING - MODE_SENSE_BIG DONEDRQ non conformant device > acd0: WARNING - MODE_SENSE_BIG read data overrun 65535>5 > acd0: WARNING no status, reselecting device > acd0: WARNING - MODE_SENSE_BIG DONEDRQ non conformant device > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xc14927f0 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc04ba248 > stack pointer = 0x10:0xc7a69c68 > frame pointer = 0x10:0xc7a69c68 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 28 (swi5: clock sio) > [thread 100000] > stopped at ata_pio_read+0x68: repe insw %dx,%es:(%edi) > I don't experience this problem with a current 5.3 kernel that is using the 6.0 ata driver. Thanks for the fix. Scot From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 23:00:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC37E16A4CE; Sun, 29 Aug 2004 23:00:55 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A167E43D3F; Sun, 29 Aug 2004 23:00:55 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smtp3b.sentex.ca (8.13.1/8.13.1) with ESMTP id i7TN0s3Y077684; Sun, 29 Aug 2004 19:00:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7TN0tsW089913; Sun, 29 Aug 2004 19:00:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id CEF6B7303F; Sun, 29 Aug 2004 19:00:54 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040829230054.CEF6B7303F@freebsd-current.sentex.ca> Date: Sun, 29 Aug 2004 19:00:54 -0400 (EDT) Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 23:00:56 -0000 TB --- 2004-08-29 21:35:27 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-29 21:35:27 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-08-29 21:35:28 - checking out the source tree TB --- 2004-08-29 21:35:28 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2004-08-29 21:35:28 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-29 21:40:20 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-29 21:40:20 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2004-08-29 21:40:20 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-29 22:43:11 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-29 22:43:11 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2004-08-29 22:43:11 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Aug 29 22:43:11 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sun Aug 29 22:54:20 UTC 2004 TB --- 2004-08-29 22:54:20 - generating LINT kernel config TB --- 2004-08-29 22:54:20 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- 2004-08-29 22:54:20 - /usr/bin/make -B LINT TB --- 2004-08-29 22:54:20 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-29 22:54:20 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2004-08-29 22:54:20 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Aug 29 22:54:20 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/md5c.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/sched_4bsd.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/subr_autoconf.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/subr_blist.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/subr_bus.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/subr_bus.c: In function `print_device_short': /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/subr_bus.c:3555: warning: int format, pointer arg (arg 12) /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/subr_bus.c:3555: warning: too many arguments for format *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-08-29 23:00:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-29 23:00:54 - ERROR: failed to build lint kernel TB --- 2004-08-29 23:00:54 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 23:01:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D25E416A4CE for ; Sun, 29 Aug 2004 23:01:41 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C48FD43D53 for ; Sun, 29 Aug 2004 23:01:41 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id B5C1C72DD4; Sun, 29 Aug 2004 16:01:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id B13CB72DCB; Sun, 29 Aug 2004 16:01:41 -0700 (PDT) Date: Sun, 29 Aug 2004 16:01:41 -0700 (PDT) From: Doug White To: Damian Gerow In-Reply-To: <20040824073356.GK25125@afflictions.org> Message-ID: <20040829155924.J69068@carver.gumbysoft.com> References: <20040824073356.GK25125@afflictions.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: RELENG_5 build broken with BKTR_USE_FREEBSD_SMBUS and BKTR_NEW_MSP34XX_DRIVER enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 23:01:42 -0000 On Tue, 24 Aug 2004, Damian Gerow wrote: > In trying to build a kernel with bktr support, I'm using both > BKTR_USE_FREEBSD_SMBUS and BKTR_NEW_MSP34XX_DRIVER. This is what I see on a > compile: > > cc -c -O -pipe -march=pentium4 -Wall -Wredundant-decls -Wnested-externs \ > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline \ > -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. \ > -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica \ > -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter \ > -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath \ > -I/usr/src/sys/contrib/dev/ath/freebsd \ > -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h \ > -fno-common -finline-limit=8000 --param inline-unit-growth=100 \ > --param large-function-growth=1000 -mno-align-long-strings \ > -mpreferred-stack-boundary=2 -ffreestanding -Werror \ > /usr/src/sys/dev/bktr/msp34xx.c > In file included from /usr/src/sys/dev/bktr/msp34xx.c:92: > /usr/src/sys/dev/bktr/bktr_reg.h:451: error: syntax error before "device_t" > *** Error code 1 Please try the patch at: http://people.freebsd.org/~dwhite/msp34xx.c.patch Seems to test out OK on my ancient Hauppauge WinTV card. These options must not be a frequently used combination since its been months since this stuff was touched last. There was a PR that fixed a compile bug in one file related to the smbus option but must not have been tested with the msp stuff too. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 23:07:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 714ED16A4D2 for ; Sun, 29 Aug 2004 23:07:20 +0000 (GMT) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48E5443D1F for ; Sun, 29 Aug 2004 23:07:17 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from midget.dons.net.au ([150.101.45.33])i7TN7B4Y030693; Mon, 30 Aug 2004 08:37:13 +0930 (CST) Received: from inchoate.dons.net.au (root@localhost.dons.net.au [127.0.0.1]) by midget.dons.net.au (8.12.9/8.12.10) with ESMTP id i7TN79n7061689; Mon, 30 Aug 2004 08:37:09 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Guido van Rooij Date: Mon, 30 Aug 2004 08:37:08 +0930 User-Agent: KMail/1.6.2 References: <20040827082929.GA64830@gvr.gvr.org> <200408280201.10816.doconnor@gsoft.com.au> <20040829191558.GA4616@gvr.gvr.org> In-Reply-To: <20040829191558.GA4616@gvr.gvr.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200408300837.08339.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.26 (www . roaringpenguin . com / mimedefang) cc: freebsd-current@freebsd.org Subject: Re: project evil: signal quality X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 23:07:20 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 30 Aug 2004 04:45, Guido van Rooij wrote: > Thanks, The reason I asked is because I normally use wicontrol -i ndis0: > ... > Comms quality/signal/noise: [ 0 0 0 ] > ... > > As you see, in that screen, it appears comms quality is unavailable.. Ahh strange.. It works fine here (Intel Pro 2100). Are newer drivers available? =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 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBMmGc5ZPcIHs/zowRAjZUAKClKgm+f52jEx4mFKidgimAA9luAACgp3Ig 4+6FQdDLvABTu6gXMsE+RYU=3D =3D3Vz8 =2D----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 23:07:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD3C416A4CE; Sun, 29 Aug 2004 23:07:47 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AAC543D54; Sun, 29 Aug 2004 23:07:45 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id F1BAEFD020; Sun, 29 Aug 2004 16:07:44 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15784-06; Sun, 29 Aug 2004 16:07:44 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 837DCFD00B; Sun, 29 Aug 2004 16:07:44 -0700 (PDT) From: Sean McNeil To: obrien@freebsd.org In-Reply-To: <20040829225314.GE92947@dragon.nuxi.com> References: <20040809184110.V80973@carver.gumbysoft.com> <20040829225314.GE92947@dragon.nuxi.com> Content-Type: text/plain Message-Id: <1093820864.65009.9.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 29 Aug 2004 16:07:44 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: "Conrad J. Sabatier" cc: freebsd-current@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: cvsup on amd64 just broke today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 23:07:47 -0000 Hi David, Finally catching up on your email? ;) On Sun, 2004-08-29 at 15:53, David O'Brien wrote: > On Mon, Aug 09, 2004 at 08:54:43PM -0500, Conrad J. Sabatier wrote: > > On 10-Aug-2004 Doug White wrote: > > > On Mon, 9 Aug 2004, Conrad J. Sabatier wrote: > > >> # make update > > >> -------------------------------------------------------------- > > >> >>> Running /usr/local/bin/cvsup > > >> -------------------------------------------------------------- > > >> /usr/local/libexec/cvsup-static.i386.bin: 1: Syntax error: "(" > > >> unexpected > > >> *** Error code 2 > > > > > > Can you run cvsup manually? It appears to be trying to execute a > > > binary as a shell script here. > > > > Tried that, got the same result. > > > > I hadn't noticed it before, but it does strike me as odd that the > > binary package for amd64 would include a file with "i386" in the name, > > and which is, in fact, an ELF 32 binary. > > Why is it odd?!? > The ability to run legacy 32-bit x86 binaries under a 64-bit OS at > full-speed is one of the huge capabilities AMD brought with this > architecture. Unless a binary does 64-bit math or addresses >4GB of > memory why does something need to be 64-bit??? This is a little misleading. You are throwing out the fact that the amd64 has additional features in 64-bit mode that can significantly increase performance. Such as extra registers. > The fact that all Open Source OS's have a 64-bit userland on all their > 64-bit platforms that grew up from 32-bit CPU's shows how unsophisticated > our build framework is. "64-bit" Solaris today is really a 64-bit kernel > and mostly 32-bit userland. Except Solaris has identical architectures that were extended to 64-bit. amd64 is a slightly different story. > > Did something change today that would effect the handling of such a > > file, perhaps? > > Nope, it has been a 32-bit 'i386' binary since the day the port started > supporting FreeBSD/AMD64. This is a huge advantage that will hopefully be exploited more as time goes by. Tim has my extreme gratitude for adding Linux32 support. It has been a great help to me. FreeBSD32 support not so much. But I really miss a JVM and Eclipse. Maybe one day I will have the time to pursue this. Sean (one satisfied amd64 owner) From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 23:23:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D9DA16A4CF; Sun, 29 Aug 2004 23:23:48 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D44A43D45; Sun, 29 Aug 2004 23:23:48 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.13.1/8.12.11) with ESMTP id i7TNNlnS095297; Sun, 29 Aug 2004 16:23:47 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i7TNNl7J095296; Sun, 29 Aug 2004 16:23:47 -0700 (PDT) (envelope-from obrien) Date: Sun, 29 Aug 2004 16:23:46 -0700 From: "David O'Brien" To: Tim Kientzle Message-ID: <20040829232346.GA95117@dragon.nuxi.com> Mail-Followup-To: David O'Brien , Tim Kientzle , current@freebsd.org References: <200408160104.03708.chris@behanna.org> <20040826005527.GF54515@spiff.melthusia.org> <20040829223905.GB92947@dragon.nuxi.com> <41325D89.5040806@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41325D89.5040806@freebsd.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: current@freebsd.org Subject: Re: Public Access to Perforce? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 23:23:48 -0000 On Sun, Aug 29, 2004 at 03:49:45PM -0700, Tim Kientzle wrote: > >Ask Perforce to port to 64-bit AMD64. That would allow them to have a > >lot more memory for their in-memory operations. > > Another possibility would be to switch from Perforce > to something like SVN. > > I'm not sure how it compares to Perforce, It is amazing the number of people that keep suggesting things like this and yet don't compare the two things they suggest to know how they really compare. For what the project uses Perforce for, SVN would offer nothing. > but > SVN has much better branch and merge support > than CVS does. Oh? SVN's own developers say "Currently, Subversion's merge support is essentially the same as CVS's." > It's also specifically designed > for use over slow networks, which would be a real > plus. SVN does nothing better than Perforce, yet removes the advantages of CVS. SVN doesn't remember past merges, so its branching is still embryonic compared to Perforce. Compared to CVS, SVN requires a connection to the main repo, and uses a heavier-weight network transport (requires Apache and HTTP-based WebDAV/DeltaV protocol). -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 23:25:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 988C516A4CE; Sun, 29 Aug 2004 23:25:17 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6F70743D1D; Sun, 29 Aug 2004 23:25:17 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) i7TNPF8T085362; Sun, 29 Aug 2004 16:25:15 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)i7TNPFE0085361; Sun, 29 Aug 2004 16:25:15 -0700 (PDT) (envelope-from sgk) Date: Sun, 29 Aug 2004 16:25:15 -0700 From: Steve Kargl To: Sean McNeil Message-ID: <20040829232515.GB85150@troutmask.apl.washington.edu> References: <20040809184110.V80973@carver.gumbysoft.com> <20040829225314.GE92947@dragon.nuxi.com> <1093820864.65009.9.camel@server.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1093820864.65009.9.camel@server.mcneil.com> User-Agent: Mutt/1.4.1i cc: "Conrad J. Sabatier" cc: freebsd-current@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: cvsup on amd64 just broke today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 23:25:17 -0000 On Sun, Aug 29, 2004 at 04:07:44PM -0700, Sean McNeil wrote: > > This is a huge advantage that will hopefully be exploited more as time > goes by. Tim has my extreme gratitude for adding Linux32 support. It > has been a great help to me. FreeBSD32 support not so much. But I > really miss a JVM and Eclipse. Maybe one day I will have the time to > pursue this. FreeBSD32 support is currently broken for dynamical linked binaries. Linux32 appears to work okay with the exception of malloc(M_WAITOK) of "1024", forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex vm object (standard object) r = 0 (0xffffff019657c620) locked @ /usr/src/sys/compat/linprocfs/linprocfs.c:861 KDB: stack backtrace: kdb_backtrace() at kdb_backtrace+0x37 witness_warn() at witness_warn+0x2e1 uma_zalloc_arg() at uma_zalloc_arg+0x6e malloc() at malloc+0xf5 vn_fullpath() at vn_fullpath+0x5b linprocfs_doprocmaps() at linprocfs_doprocmaps+0x1b4 pfs_read() at pfs_read+0x33a vn_read() at vn_read+0x1a0 dofileread() at dofileread+0xaf read() at read+0x53 ia32_syscall() at ia32_syscall+0x261 Xint0x80_syscall() at Xint0x80_syscall+0x5d -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 23:26:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A19AC16A4CE for ; Sun, 29 Aug 2004 23:26:04 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 714F943D2D for ; Sun, 29 Aug 2004 23:26:04 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.115] (adsl-64-171-186-94.dsl.snfc21.pacbell.net [64.171.186.94]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7TNQ0jn020227; Sun, 29 Aug 2004 16:26:01 -0700 Message-ID: <41326608.7020708@root.org> Date: Sun, 29 Aug 2004 16:26:00 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Hiris <4711@chello.at> References: <1093754957.564.24.camel@amon.quaggaspace.org> <200408300010.02817.4711@chello.at> In-Reply-To: <200408300010.02817.4711@chello.at> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: Justin Settle Subject: Re: APIC causes vr0 watchdog timeouts and Interrupt storms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 23:26:04 -0000 Christian Hiris wrote: > On Sunday 29 August 2004 06:49, Justin Settle wrote: >>I recently installed 5.3-BETA. After booting, I found was unable to use >>my usb mouse or my ethernet (Via-rhine). I started tinkering with the >>kernel and found that if I disabled APIC, this system worked without >>ethernet issues or mouse isssues. After talking with some people they >>suggested I post boot -v, dmesg's of the different kernels so here they >>are: >> >>The first thing I tried was a GENERIC with SMP commented out. It had >>the same issues as GENERIC: >> >>Copyright (c) 1992-2004 The FreeBSD Project. >>Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 >> The Regents of the University of California. All rights reserved. >>FreeBSD 5.3-BETA2 #0: Sat Aug 28 23:18:57 EDT 2004 >> root@amon.quaggaspace.org:/usr/obj/usr/src/sys/GENERICNOSMP > > > [snip] > > >>acpi link set: _CRS failed for link \\_SB_.PCI0.ALKB - AE_NULL_ENTRY >>acpi link set: curr irq 0 != 21 for \\_SB_.PCI0.ALKB (ignoring) >>unknown: _SRS failed, irq 21 via \\_SB_.PCI0.ALKB This has been fixed in -current for a while. I just MFCd the fix to 5.3. Let me know if it doesn't fix your problem. -Nate From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 23:29:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7D8116A4CE for ; Sun, 29 Aug 2004 23:29:22 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 820A643D1F for ; Sun, 29 Aug 2004 23:29:20 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.115] (adsl-64-171-186-94.dsl.snfc21.pacbell.net [64.171.186.94]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7TNTHjn020297; Sun, 29 Aug 2004 16:29:18 -0700 Message-ID: <413266CD.1020107@root.org> Date: Sun, 29 Aug 2004 16:29:17 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <4123FC71.8060308@root.org> <41245804.7060008@DeepCore.dk> <412A20A3.8060600@root.org> <412A5C40.4050100@DeepCore.dk> <412A641A.1030809@root.org> <412AEF2E.7080600@DeepCore.dk> <412E8D3C.4060001@root.org> <4130E1E0.6010000@DeepCore.dk> In-Reply-To: <4130E1E0.6010000@DeepCore.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: current@freebsd.org Subject: Re: suspend/resume panic in ACPI.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 23:29:22 -0000 Søren Schmidt wrote: > Nate Lawson wrote: > >>>>> There is no change, the systems all lock up hard on resume, on the >>>>> two laptops (ASUS & Acer) the backlight doesn't even come on >>>>> anymore.... >>>>> >>>>> Again reverting /sys/dev/acpica and /sys/i386/acpica back to aug >>>>> 1st make things work (well almost, but that might not be ACPI's >>>>> fault)... >>>> >>>> >>>> Please go through acpi_{button,cmbat,lid}.c and comment out the >>>> foo_resume() code in each. Let me know which one is the culprit if >>>> this works. > > OK, I played a bit with it. I commented out the resume code in > acpi_cmbat.c (acpi_button.c and acpi_lid.c already has empty resume > functions). > > Now, if in single user the system comes back on resume, but it will > double panic in a few seconds, if in multiuser it wont come back at all, > backlight off and sytem locked hard. More info about the panic (i.e. message, backtrace, etc.) would help here. > In short no progress, only fix is still to backstep acpi til aug 1st, > then things work pretty well... Try reverting just acpi.c to Aug. 1. Narrowing down which change is causing you a problem would help. -Nate From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 23:36:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17CDD16A4CE; Sun, 29 Aug 2004 23:36:31 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6FBC43D2D; Sun, 29 Aug 2004 23:36:30 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.13.1/8.12.11) with ESMTP id i7TNaSJp095699; Sun, 29 Aug 2004 16:36:29 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i7TNaReX095698; Sun, 29 Aug 2004 16:36:27 -0700 (PDT) (envelope-from obrien) Date: Sun, 29 Aug 2004 16:36:27 -0700 From: "David O'Brien" To: Sean McNeil Message-ID: <20040829233627.GB95117@dragon.nuxi.com> References: <20040809184110.V80973@carver.gumbysoft.com> <20040829225314.GE92947@dragon.nuxi.com> <1093820864.65009.9.camel@server.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1093820864.65009.9.camel@server.mcneil.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-current@freebsd.org cc: freebsd-amd64@freebsd.org Subject: Re: cvsup on amd64 just broke today X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2004 23:36:31 -0000 On Sun, Aug 29, 2004 at 04:07:44PM -0700, Sean McNeil wrote: > Finally catching up on your email? ;) Yeah. :-/ > On Sun, 2004-08-29 at 15:53, David O'Brien wrote: > > Why is it odd?!? > > The ability to run legacy 32-bit x86 binaries under a 64-bit OS at > > full-speed is one of the huge capabilities AMD brought with this > > architecture. Unless a binary does 64-bit math or addresses >4GB of > > memory why does something need to be 64-bit??? > > This is a little misleading. You are throwing out the fact that the > amd64 has additional features in 64-bit mode that can significantly > increase performance. Such as extra registers. I'm not throwing out the fact about the extra registers. In my day-job I track AMD performance. Trust me, for a network-based program such as CVSup isn't going to reap a noticeable benefit from them. What slows down CVSup is network BW and latency, same for the disk BW and latency. CVSup isn't doing Seti@Home calculations. > > The fact that all Open Source OS's have a 64-bit userland on all their > > 64-bit platforms that grew up from 32-bit CPU's shows how unsophisticated > > our build framework is. "64-bit" Solaris today is really a 64-bit kernel > > and mostly 32-bit userland. > > Except Solaris has identical architectures that were extended to > 64-bit. Actually Sparc isn't 100% identical -- performance enhancements were made in 64-bit mode. They just aren't as many and to the extent as done in AMD64. > amd64 is a slightly different story. Solaris for AMD64 will also have a 32-bit userland, and its compiler will default to producing 32-bit binaries. For things like 'vi' and 'ls' 64-bit + extra registers simply doesn't matter. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 23:39:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94EE716A4CF for ; Sun, 29 Aug 2004 23:39:48 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8487F43D39 for ; Sun, 29 Aug 2004 23:39:48 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 698E972DD4; Sun, 29 Aug 2004 16:39:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 66E2472DCB; Sun, 29 Aug 2004 16:39:48 -0700 (PDT) Date: Sun, 29 Aug 2004 16:39:48 -0700 (PDT) From: Doug White To: Daniel O'Connor In-Reply-To: <200408261119.25101.doconnor@gsoft.com.au> Message-ID: <20040829163858.Q69068@carver.gumbysoft.com> References: <20040825150547.GI6962@electra.cse.Buffalo.EDU> <46780.12.148.147.242.1093448890.squirrel@mail.ringofsaturn.com> <200408261119.25101.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: Dan Nelson cc: Rusty Nejdl cc: Ken Smith Subject: Re: X.org configuration in sysinstall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 23:39:48 -0000 On Thu, 26 Aug 2004, Daniel O'Connor wrote: > > Both XFree86 and X.org have the same autoconfig capabilities afaik. > > They always seem to choose the highest resolution supported by the > > card, which usually results in teeny tiny text. > > It finds the highest resolution supported by your card _and_ monitor. .... at 8 bit color, which is the part that really bothers me. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 23:41:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7118816A4CE for ; Sun, 29 Aug 2004 23:41:49 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63DF043D39 for ; Sun, 29 Aug 2004 23:41:49 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 5422B72DD4; Sun, 29 Aug 2004 16:41:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 4F88C72DCB; Sun, 29 Aug 2004 16:41:49 -0700 (PDT) Date: Sun, 29 Aug 2004 16:41:49 -0700 (PDT) From: Doug White To: Elliot Finley In-Reply-To: <015f01c48adf$15029f50$32cba1cd@science1> Message-ID: <20040829164126.E69068@carver.gumbysoft.com> References: <015f01c48adf$15029f50$32cba1cd@science1> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: 5.3 Beta1 failed boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 23:41:49 -0000 On Wed, 25 Aug 2004, Elliot Finley wrote: > I just moved to 5.3 Beta1 on my ASUS P4P800. (-current as of about 3 weeks > ago worked fine) > > I get the following when trying to boot (copied by hand): > > CPU: Intel(R) Pentium(R) 4 CPU 2.60GHz (2598.76-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > > Features=0xbfebfbff ,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Hyperthreading: 2 logical CPUs > real memory = 1072889856 (1023 MB) > avail memory = 1040359424 (992 MB) > MPTable: > ioapic0: Assuming intbase of 0 > ioapic0 irqs 0-23 on motherboard > npx0: [FAST] > npx0: on motherboard > npx0: INT 16 interface > pcib0: pcibus 0 on motherboard > pci0: on pcib0 > agp0: mem 0xf8000000-0xfbffffff at device > 0.0 on pci0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > panic: Multiple entries for PCI IRQ 16 > cpuid = 0; > KDB: enter: panic > [thread 0] > Stopped at kdb_enter+0x2b: nop > db> > > > I've tried default, no-acpi, verbose-logging and I get here every time. Safe mode? That turns off the i/o apic. P4P800s have been a problem for a while... -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 23:57:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12F0616A4CE; Sun, 29 Aug 2004 23:57:07 +0000 (GMT) Received: from mx.us.army.mil (mxoutdr1.us.army.mil [143.69.242.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2F5343D2F; Sun, 29 Aug 2004 23:57:06 +0000 (GMT) (envelope-from jonathan.michael.stewart@us.army.mil) Received: from mta03.int.dr1.us.army.mil (localhost [127.0.0.1]) by mailrouter.us.army.mil (AKO MTA - mta03 ) with ESMTP id <0I38007B6FV68O@mta03.int.dr1.us.army.mil>; Sun, 29 Aug 2004 23:57:06 +0000 (GMT) Received: from [10.70.2.3] ([204.117.152.20]) by mailrouter.us.army.mil (AKO MTA - mta03 ) with ESMTPA id <0I3800LC2FU85H@mta03.int.dr1.us.army.mil>; Sun, 29 Aug 2004 23:57:05 +0000 (GMT) Date: Sun, 29 Aug 2004 19:56:41 -0400 From: Jonathan In-reply-to: <20040829232346.GA95117@dragon.nuxi.com> To: current@freebsd.org Message-id: <41326D39.5020207@us.army.mil> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) References: <200408160104.03708.chris@behanna.org> <20040826005527.GF54515@spiff.melthusia.org> <20040829223905.GB92947@dragon.nuxi.com> <41325D89.5040806@freebsd.org> <20040829232346.GA95117@dragon.nuxi.com> Subject: Re: Public Access to Perforce? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 23:57:07 -0000 David O'Brien wrote: > On Sun, Aug 29, 2004 at 03:49:45PM -0700, Tim Kientzle wrote: > >>>Ask Perforce to port to 64-bit AMD64. That would allow them to have a >>>lot more memory for their in-memory operations. >> >>Another possibility would be to switch from Perforce >>to something like SVN. >> >>I'm not sure how it compares to Perforce, > > > It is amazing the number of people that keep suggesting things like this > and yet don't compare the two things they suggest to know how they really > compare. For what the project uses Perforce for, SVN would offer > nothing. > I can't really say much about this as I don't really know much about Perforce at all. > >>but >>SVN has much better branch and merge support >>than CVS does. > > > Oh? SVN's own developers say "Currently, Subversion's merge support is > essentially the same as CVS's." > Yes, the merge support is pretty much the same in the sense that Subversion does not specifically help with it but because a revision covers the entire repository it is much easier to actually track and perform the merges even though currently you still have to do so manually. > >>It's also specifically designed >>for use over slow networks, which would be a real >>plus. > > > SVN does nothing better than Perforce, yet removes the advantages of CVS. > SVN doesn't remember past merges, so its branching is still embryonic > compared to Perforce. I don't know enough to say anything about this either. > Compared to CVS, SVN requires a connection to the > main repo, and uses a heavier-weight network transport (requires Apache > and HTTP-based WebDAV/DeltaV protocol). I believe when you say SVN requires a connection to the main repo you are referring to the fact the a BDB style subversion repo is not as easily mirrored as a CVS repo, which is the case. However in Subversion 1.1, which is coming out soon, there is an FSFS backend which will be much easier to mirror. Subversion does NOT require Apache or WebDAV/DeltaV at all. Subversion does use the APR (Apache Portable Runtime) which is what Apache is built on because it provides a convenient cross platform library (? can't think of the correct term right now). Also if you don't want to use Apache and WebDAV the is an svnserve server which uses a custom protocol to connect to a SVN server so there is no HTTP or WebDAV overhead. Just trying to clear a few things up, Jonathan P.S. I'm not really even much of a subversion user but I follow the -dev list closely because I consider it an example of a very well run project and enjoy reading about how it is being worked on and what is being tried to make it better and some of things stated previously are common misconceptions. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 00:06:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D4A016A4CE for ; Mon, 30 Aug 2004 00:06:08 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 814A943D45 for ; Mon, 30 Aug 2004 00:06:08 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 73B0F72DD4; Sun, 29 Aug 2004 17:06:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 6F8BA72DCB; Sun, 29 Aug 2004 17:06:08 -0700 (PDT) Date: Sun, 29 Aug 2004 17:06:08 -0700 (PDT) From: Doug White To: Kachun Lee In-Reply-To: <5.0.2.1.2.20040826181101.00b933a0@dvl.pathlink.com> Message-ID: <20040829170534.V69068@carver.gumbysoft.com> References: <5.0.2.1.2.20040826181101.00b933a0@dvl.pathlink.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA1 panic with getnewbuf: locked buf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 00:06:08 -0000 On Thu, 26 Aug 2004, Kachun Lee wrote: > >The server (E7501 single XEON 4G RAM) that I upgraded from 4.10 to > 5.3-BETA few days >ago panic'ed twice on 'getnewbuf: locked buf'. I > included the backtrace and dmesg below. I >searched the lists and found > several similar instances mentioned. Anything I can help to >find the > problem. Thanks in advance for any help. > > I forget to mention that I already rebuilt its kernel with 1.75 kern_lock.c > (from current). 1.75 should fix this problem. If it didn't, make sure you're booting the right kernel and run a full fsck. There is another attempt in rev 1.76 you might try too. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 00:11:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55EBD16A4CE for ; Mon, 30 Aug 2004 00:11:53 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B04243D3F for ; Mon, 30 Aug 2004 00:11:53 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 40BF872DD4; Sun, 29 Aug 2004 17:11:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 3EE1272DCB; Sun, 29 Aug 2004 17:11:53 -0700 (PDT) Date: Sun, 29 Aug 2004 17:11:53 -0700 (PDT) From: Doug White To: =?iso-8859-2?q?S=B3awek_=AFak?= In-Reply-To: <86r7ps912w.fsf@thirst.unx.era.pl> Message-ID: <20040829171048.D69068@carver.gumbysoft.com> References: <86r7ps912w.fsf@thirst.unx.era.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: current@freebsd.org Subject: Re: Random compiler errors on BETA1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 00:11:53 -0000 On Fri, 27 Aug 2004, [iso-8859-2] S=B3awek =AFak wrote: > Hi, > > I've successfuly upgraded one of the servers to BETA1. The stability = is ok > for now (after the patch from 6.0-CURRENT applied), but I get many ra= ndom > Signal 6 and abort traps from GCC. I don't get coredumps either altho= ught I > can make sleep dump core when killed with ABRT. You're falling prey to bugs in BETA1. Try BETA2 when its released, or track RELENG_5. You're hitting both the IPI deadlock and a bogus buf locking change. Both should be fixed in RELENG_5. --=20 Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 00:13:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7747116A4CF for ; Mon, 30 Aug 2004 00:13:31 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65ABE43D54 for ; Mon, 30 Aug 2004 00:13:31 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 5E4A572DD4; Sun, 29 Aug 2004 17:13:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 5CABF72DCB; Sun, 29 Aug 2004 17:13:31 -0700 (PDT) Date: Sun, 29 Aug 2004 17:13:31 -0700 (PDT) From: Doug White To: Tomas Randa In-Reply-To: <1093613358.691.3.camel@ares.office.internetservice.cz> Message-ID: <20040829171200.W69068@carver.gumbysoft.com> References: <1093613358.691.3.camel@ares.office.internetservice.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: Problems compiling kdelibs under RELENG_5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 00:13:31 -0000 On Fri, 27 Aug 2004, Tomas Randa wrote: > I upgraded on RELENG_5, but while compiling kdelibs3, I have the > following error: > > gmake[3]: Entering directory > `/usr/ports/x11/kdelibs3/work/kdelibs-3.2.3/kdecore' > ../dcop/dcopidl/dcopidl ./ksycoca.h > ksycoca.kidl || ( rm -f > ksycoca.kidl ; false ) > Fatal error 'Spinlock called when not threaded.' at line 83 in file > /usr/src/lib/libpthread/thread/thr_spinlock.c (errno = 0) This is the telltale that you have crossed threading libraries. There is lots of information about this in the archives. The short fix is to rebuild these ports in this order: XFree86 (or xorg if you're using that) qmake qt kde* -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 00:18:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF5E616A4CE for ; Mon, 30 Aug 2004 00:18:45 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0AB543D46 for ; Mon, 30 Aug 2004 00:18:45 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id CFBED72DD4; Sun, 29 Aug 2004 17:18:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id CB0B772DCB; Sun, 29 Aug 2004 17:18:45 -0700 (PDT) Date: Sun, 29 Aug 2004 17:18:45 -0700 (PDT) From: Doug White To: Bob Willcox In-Reply-To: <20040827211347.GD183@luke.immure.com> Message-ID: <20040829171652.X69068@carver.gumbysoft.com> References: <20040827183518.GB183@luke.immure.com> <20040827211347.GD183@luke.immure.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current list cc: Claus Guttesen Subject: Re: nfsd slows with age X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 00:18:46 -0000 On Fri, 27 Aug 2004, Bob Willcox wrote: > On Fri, Aug 27, 2004 at 11:00:14PM +0200, Claus Guttesen wrote: > > > I have noticed that on my NFS file server system the > > > nfsd process > > > gradually starts using more and more CPU time ... > > > Stopping and restarting nfsd seems to fix things > > back to > > > normal. > > > > > > Has anyone else seen this behavior? > > > > I'm running a nfs-server with current as of Feb. 18'th > > 2004, serving approx. 5 TB for some web-servers. It's > > also acting as a rsync- and syslog-server. The > > cpu-usage hardly goes above 10 % while doing nfs, > > except when doing internal copying or rsyncing. > > Longest uptime was 118 days before I took it down to > > add more disks. Works _very_ solid (knock-knock) I > > must say. > > > > Are you using tcp or udp? > > I'm using udp. My (rather few) clients use amd to automount stuff (home > dirs, etc.). > > The server system it'self is really lightly loaded as it's for my > home network with usually only me accessing it (via nfs to my home > directory from my workstation). I don't know if the slowdown is related > to activity or not, guess I could run some tests to try to determine > this. I'd keep an eye on automounter and rpc.statd. Automounter on linux at least is very irresponsible and frequent restarts cause dangling mounts which get umount attempts every timeout interval. I haven't tried it on FreeBSD but it may have the same misbehavior. rpc.statd likes to grow without bound, at least on 4.x; you may need to restart it periodically. I've had to bounce statd once or twice on my workstation, which also serves the ports tree to a set of build servers. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 00:21:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24A5F16A4CE; Mon, 30 Aug 2004 00:21:08 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19A1243D45; Mon, 30 Aug 2004 00:21:08 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 0DA5972DD4; Sun, 29 Aug 2004 17:21:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 085A372DCB; Sun, 29 Aug 2004 17:21:08 -0700 (PDT) Date: Sun, 29 Aug 2004 17:21:08 -0700 (PDT) From: Doug White To: Andre Oppermann In-Reply-To: <412FA7E8.80BE87BC@freebsd.org> Message-ID: <20040829172000.F69068@carver.gumbysoft.com> References: <412FA7E8.80BE87BC@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: [Fwd: cvs commit: src/sys/kern sys_generic.c] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 00:21:08 -0000 On Fri, 27 Aug 2004, Andre Oppermann wrote: > Maybe this fixes poll() problems/errors some people have seen on their > machines. I am not sure if this alignment would have caused problems > on non-ia32 architectures but it is certainly more correct now. ;-) Heh. Its possible; I spent a few hours on Saturday trying to trigger any apparent poll() wakeup problems with unix domain sockets and TCP with no joy. The one report that was forwarded to me involved some windowmaker dockapps and the poll()s were probably sitting on the X domain socket. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 00:31:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 556A616A4CE; Mon, 30 Aug 2004 00:31:19 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48CDB43D46; Mon, 30 Aug 2004 00:31:19 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 3A30B72DD4; Sun, 29 Aug 2004 17:31:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 358A372DCB; Sun, 29 Aug 2004 17:31:19 -0700 (PDT) Date: Sun, 29 Aug 2004 17:31:19 -0700 (PDT) From: Doug White To: Gleb Smirnoff In-Reply-To: <20040828110121.GA18497@cell.sick.ru> Message-ID: <20040829173049.I69068@carver.gumbysoft.com> References: <20040828083348.GA17644@cell.sick.ru> <20040828110121.GA18497@cell.sick.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org cc: sos@freebsd.org Subject: Re: two (SATA related?) panics on yesterday's CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 00:31:19 -0000 On Sat, 28 Aug 2004, Gleb Smirnoff wrote: > On Sat, Aug 28, 2004 at 12:33:48PM +0400, Gleb Smirnoff wrote: > T> I have installed CURRENT on a brand new SuperMicro 5013C-M. > T> Motherboard is SuperMicro P4SCi: > T> http://www.supermicro.com/products/motherboard/P4/E7210/P4SCi.cfm > > Seems like 5.3-BETA1 works OK on this hardware. When posting panics, its useful to post the actual panic: string. :) You posted the backtrace but not the panic message. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 00:44:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D94416A4CE; Mon, 30 Aug 2004 00:44:24 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19DCD43D46; Mon, 30 Aug 2004 00:44:24 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smtp3.sentex.ca (8.13.1/8.13.1) with ESMTP id i7U0iKbU052844; Sun, 29 Aug 2004 20:44:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7U0iNb7057501; Sun, 29 Aug 2004 20:44:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 710877303F; Sun, 29 Aug 2004 20:44:23 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040830004423.710877303F@freebsd-current.sentex.ca> Date: Sun, 29 Aug 2004 20:44:23 -0400 (EDT) Subject: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 00:44:24 -0000 TB --- 2004-08-29 23:15:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-29 23:15:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2004-08-29 23:15:01 - checking out the source tree TB --- 2004-08-29 23:15:01 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2004-08-29 23:15:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-29 23:20:22 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-29 23:20:22 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-08-29 23:20:22 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-30 00:24:11 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-30 00:24:11 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-08-30 00:24:11 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Aug 30 00:24:11 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon Aug 30 00:37:02 UTC 2004 TB --- 2004-08-30 00:37:02 - generating LINT kernel config TB --- 2004-08-30 00:37:02 - cd /home/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- 2004-08-30 00:37:02 - /usr/bin/make -B LINT TB --- 2004-08-30 00:37:02 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-30 00:37:02 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-08-30 00:37:02 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Aug 30 00:37:02 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/kern/md5c.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/kern/sched_4bsd.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/kern/subr_autoconf.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/kern/subr_blist.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/kern/subr_bus.c /tinderbox/CURRENT/alpha/alpha/src/sys/kern/subr_bus.c: In function `print_device_short': /tinderbox/CURRENT/alpha/alpha/src/sys/kern/subr_bus.c:3555: warning: int format, pointer arg (arg 12) /tinderbox/CURRENT/alpha/alpha/src/sys/kern/subr_bus.c:3555: warning: too many arguments for format *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2004-08-30 00:44:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-30 00:44:23 - ERROR: failed to build lint kernel TB --- 2004-08-30 00:44:23 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 00:45:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BEE316A4CE; Mon, 30 Aug 2004 00:45:59 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1ED9543D31; Mon, 30 Aug 2004 00:45:59 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 1338772DD4; Sun, 29 Aug 2004 17:45:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 1084372DCB; Sun, 29 Aug 2004 17:45:59 -0700 (PDT) Date: Sun, 29 Aug 2004 17:45:59 -0700 (PDT) From: Doug White To: Garance A Drosihn In-Reply-To: Message-ID: <20040829174521.H69068@carver.gumbysoft.com> References: <200408271337.i7RDbXgu052801@pooker.samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: re@freebsd.org cc: current@freebsd.org Subject: Re: 5.3-RELEASE TODO - make/kqueue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 00:45:59 -0000 On Sat, 28 Aug 2004, Garance A Drosihn wrote: > I do still get the "*** Signal 6"s, even though I am now running > with v1.76 of src/sys/kern/kern_lock.c. Actually I had updated > that one source file, expecting to get revision 1.75 (and thus > backout revision 1.74), as recently mentioned by Doug White. I > just now realized that I ended up with 1.76... I guess I should > try it one more time with 1.75 instead of 1.76. If you're sure you've updated, and have tried rebuilding make to eliminate a corrupted binary, then you might have hardware problems. Are you using gvinum? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 00:47:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0931416A4CE for ; Mon, 30 Aug 2004 00:47:49 +0000 (GMT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id B597943D4C for ; Mon, 30 Aug 2004 00:47:48 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-69-104-103-54.dsl.snfc21.pacbell.net [69.104.103.54])i7U0lkK6133568; Sun, 29 Aug 2004 20:47:46 -0400 Message-ID: <41327931.9090004@elischer.org> Date: Sun, 29 Aug 2004 17:47:45 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: Doug White References: <1093613358.691.3.camel@ares.office.internetservice.cz> <20040829171200.W69068@carver.gumbysoft.com> In-Reply-To: <20040829171200.W69068@carver.gumbysoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Tomas Randa cc: current@freebsd.org Subject: Re: Problems compiling kdelibs under RELENG_5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 00:47:49 -0000 Doug White wrote: > On Fri, 27 Aug 2004, Tomas Randa wrote: > > >>I upgraded on RELENG_5, but while compiling kdelibs3, I have the >>following error: >> >>gmake[3]: Entering directory >>`/usr/ports/x11/kdelibs3/work/kdelibs-3.2.3/kdecore' >>../dcop/dcopidl/dcopidl ./ksycoca.h > ksycoca.kidl || ( rm -f >>ksycoca.kidl ; false ) >>Fatal error 'Spinlock called when not threaded.' at line 83 in file >>/usr/src/lib/libpthread/thread/thr_spinlock.c (errno = 0) > > > This is the telltale that you have crossed threading libraries. There is > lots of information about this in the archives. > > The short fix is to rebuild these ports in this order: But to get working immediatly, use libmap.conf to map everything to the same pthread library. > > XFree86 (or xorg if you're using that) > qmake > qt > kde* > From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 00:48:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A386816A4CE for ; Mon, 30 Aug 2004 00:48:49 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9472943D49 for ; Mon, 30 Aug 2004 00:48:49 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 88EA172DD4; Sun, 29 Aug 2004 17:48:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 862A972DCB; Sun, 29 Aug 2004 17:48:49 -0700 (PDT) Date: Sun, 29 Aug 2004 17:48:49 -0700 (PDT) From: Doug White To: Justin Settle In-Reply-To: <1093819100.1268.5.camel@amon.quaggaspace.org> Message-ID: <20040829174713.R69068@carver.gumbysoft.com> References: <1093754957.564.24.camel@amon.quaggaspace.org> <1093790664.562.3.camel@amon.quaggaspace.org> <1093819100.1268.5.camel@amon.quaggaspace.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Chris Laverdure cc: freebsd-current@freebsd.org Subject: Re: APIC causes vr0 watchdog timeouts and Interrupt storms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 00:48:49 -0000 On Sun, 29 Aug 2004, Justin Settle wrote: > > ACPI doesn't seem to matter on my machine. It works fine with it, or > without it. I've tried all combinations of ACPI and APIC; only APIC > seems to matter. This is a KT400 board if you have something similar. > In my case I'm content to just leave APIC off and ACPI on as that works > for me. The only downside is that the default kernel comes with device > apic on so I have to do a recompile before getting to the net. I can confirm that my Soyo KT400 has I/O APIC problems. It works for a few devices, but adding more than one PCI card starts up the wierdness. Disabling apic makes it happy again. For a while I thought it was just a linksys if_sk being flakey, but taking it out and putting a firewire card in had similar interrupt wierdness. I guess that means I can test any attempts to fix this :) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 01:31:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C0D3016A4CE for ; Mon, 30 Aug 2004 01:31:07 +0000 (GMT) Received: from mail2.neureal.com (mail2.neureal.com [66.98.170.78]) by mx1.FreeBSD.org (Postfix) with SMTP id 6589A43D1F for ; Mon, 30 Aug 2004 01:31:07 +0000 (GMT) (envelope-from quaggamail@quaggaspace.org) Received: (qmail 29747 invoked by uid 399); 30 Aug 2004 01:31:05 -0000 Received: from unknown (HELO ?192.168.42.25?) (68.162.100.90) by mail2.neureal.com with SMTP; 30 Aug 2004 01:31:05 -0000 From: Justin Settle To: Nate Lawson In-Reply-To: <41326608.7020708@root.org> References: <1093754957.564.24.camel@amon.quaggaspace.org> <200408300010.02817.4711@chello.at> <41326608.7020708@root.org> Content-Type: text/plain Message-Id: <1093829490.622.1.camel@amon.quaggaspace.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 29 Aug 2004 21:31:30 -0400 Content-Transfer-Encoding: 7bit cc: Christian Hiris <4711@chello.at> cc: freebsd-current@freebsd.org Subject: Re: APIC causes vr0 watchdog timeouts and Interrupt storms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 01:31:07 -0000 On Sun, 2004-08-29 at 19:26, Nate Lawson wrote: > Christian Hiris wrote: > > On Sunday 29 August 2004 06:49, Justin Settle wrote: > >>I recently installed 5.3-BETA. After booting, I found was unable to use > >>my usb mouse or my ethernet (Via-rhine). I started tinkering with the > >>kernel and found that if I disabled APIC, this system worked without > >>ethernet issues or mouse isssues. After talking with some people they > >>suggested I post boot -v, dmesg's of the different kernels so here they > >>are: > >> > >>The first thing I tried was a GENERIC with SMP commented out. It had > >>the same issues as GENERIC: > >> > >>Copyright (c) 1992-2004 The FreeBSD Project. > >>Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > >> The Regents of the University of California. All rights reserved. > >>FreeBSD 5.3-BETA2 #0: Sat Aug 28 23:18:57 EDT 2004 > >> root@amon.quaggaspace.org:/usr/obj/usr/src/sys/GENERICNOSMP > > > > > > [snip] > > > > > >>acpi link set: _CRS failed for link \\_SB_.PCI0.ALKB - AE_NULL_ENTRY > >>acpi link set: curr irq 0 != 21 for \\_SB_.PCI0.ALKB (ignoring) > >>unknown: _SRS failed, irq 21 via \\_SB_.PCI0.ALKB > > This has been fixed in -current for a while. I just MFCd the fix to > 5.3. Let me know if it doesn't fix your problem. > > -Nate I synced up to 5.3-BETA just now, recompiled the GENERIC kernel and its working with APIC without issue. Thanks again :) Jay From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 01:33:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8915F16A4CE for ; Mon, 30 Aug 2004 01:33:57 +0000 (GMT) Received: from tomts25-srv.bellnexxia.net (tomts25-srv.bellnexxia.net [209.226.175.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6BEC43D3F for ; Mon, 30 Aug 2004 01:33:56 +0000 (GMT) (envelope-from dashevil@sympatico.ca) Received: from [192.168.2.32] ([65.93.59.22]) by tomts25-srv.bellnexxia.net ESMTP <20040830013355.OGDO7925.tomts25-srv.bellnexxia.net@[192.168.2.32]>; Sun, 29 Aug 2004 21:33:55 -0400 From: Chris Laverdure To: Justin Settle In-Reply-To: <1093829490.622.1.camel@amon.quaggaspace.org> References: <1093754957.564.24.camel@amon.quaggaspace.org> <200408300010.02817.4711@chello.at> <41326608.7020708@root.org> <1093829490.622.1.camel@amon.quaggaspace.org> Content-Type: text/plain Message-Id: <1093815236.925.4.camel@elemental.DashEvil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 29 Aug 2004 21:33:57 +0000 Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: APIC causes vr0 watchdog timeouts and Interrupt storms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 01:33:57 -0000 On Mon, 2004-08-30 at 01:31, Justin Settle wrote: > On Sun, 2004-08-29 at 19:26, Nate Lawson wrote: > > Christian Hiris wrote: > > > On Sunday 29 August 2004 06:49, Justin Settle wrote: > > >>I recently installed 5.3-BETA. After booting, I found was unable to use > > >>my usb mouse or my ethernet (Via-rhine). I started tinkering with the > > >>kernel and found that if I disabled APIC, this system worked without > > >>ethernet issues or mouse isssues. After talking with some people they > > >>suggested I post boot -v, dmesg's of the different kernels so here they > > >>are: > > >> > > >>The first thing I tried was a GENERIC with SMP commented out. It had > > >>the same issues as GENERIC: > > >> > > >>Copyright (c) 1992-2004 The FreeBSD Project. > > >>Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > > >> The Regents of the University of California. All rights reserved. > > >>FreeBSD 5.3-BETA2 #0: Sat Aug 28 23:18:57 EDT 2004 > > >> root@amon.quaggaspace.org:/usr/obj/usr/src/sys/GENERICNOSMP > > > > > > > > > [snip] > > > > > > > > >>acpi link set: _CRS failed for link \\_SB_.PCI0.ALKB - AE_NULL_ENTRY > > >>acpi link set: curr irq 0 != 21 for \\_SB_.PCI0.ALKB (ignoring) > > >>unknown: _SRS failed, irq 21 via \\_SB_.PCI0.ALKB > > > > This has been fixed in -current for a while. I just MFCd the fix to > > 5.3. Let me know if it doesn't fix your problem. > > > > -Nate > > I synced up to 5.3-BETA just now, recompiled the GENERIC kernel and its > working with APIC without issue. Thanks again :) > > Jay I second this. My UHID problems have disappeared as of the recent merge. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 01:51:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19E4F16A4CE; Mon, 30 Aug 2004 01:51:32 +0000 (GMT) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7267143D45; Mon, 30 Aug 2004 01:51:31 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from midget.dons.net.au ([150.101.45.33])i7U1pR4Y004689; Mon, 30 Aug 2004 11:21:29 +0930 (CST) Received: from inchoate.gsoft.com.au (root@localhost.dons.net.au [127.0.0.1]) by midget.dons.net.au (8.12.9/8.12.10) with ESMTP id i7U1pMn7063065; Mon, 30 Aug 2004 11:21:23 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: dmlb@freebsd.org Date: Mon, 30 Aug 2004 11:21:22 +0930 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-Id: <200408301121.22260.doconnor@gsoft.com.au> X-Spam-Score: 0.691 () UPPERCASE_25_50 X-Scanned-By: MIMEDefang 2.26 (www . roaringpenguin . com / mimedefang) cc: freebsd-current@freebsd.org Subject: bfe crash with profile.sh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 01:51:32 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am trying this -> https://projects.fsck.ch/profile/wiki/InstallGuide but enabling it makes my bfe panic on boot :( I have some more info in kern/71131 =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 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBMoga5ZPcIHs/zowRAjLDAJ45MaXD6tvhDghux9z1P9SU1ZDzMwCghG6C rjTtU5UU42YzlnSF6lAp6qk=3D =3DqVtk =2D----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 01:58:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC5F316A4CE for ; Mon, 30 Aug 2004 01:58:28 +0000 (GMT) Received: from creme-brulee.marcuscom.com (rrcs-midsouth-24-172-16-118.biz.rr.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4654043D48 for ; Mon, 30 Aug 2004 01:58:28 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) i7U1uVq0004124 for ; Sun, 29 Aug 2004 21:56:31 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: current@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-SAmFexpP4n2nZT2k/Zqo" Organization: MarcusCom, Inc. Message-Id: <1093831099.61516.30.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 29 Aug 2004 21:58:19 -0400 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on creme-brulee.marcuscom.com Subject: Panic on 6.0 building ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 01:58:28 -0000 --=-SAmFexpP4n2nZT2k/Zqo Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On my Tinderbox machine (similar in operation to pointyhat), I was building packages for 4.10-RELEASE and 5.2.1-RELEASE, and the machine panicked. This is a single-CPU Pentium 4 with 2 GB of RAM. The drive being used for builds is a Maxtor SATA drive connected to a Promise SATA controller. Here is the manually transcribed panic and trace: Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x1c fault code =3D supervisor write, page not present instruction pointer =3D 0x8:0xc0533d07 stack pointer =3D 0x10:0xf5f30a4c frame pointer =3D 0x10:0xf5f30a58 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 27441 (cpp0) Stopped at vfs_vmio_release+0x1b: lock cmpxchgl %ecx,0x1c(%edx) vfs_vmio_release(dc1fee68) at vfs_vmio_release+0x1b getnewbuf(0,0,4000,4000,1c000) at getnewbuf+0x2b6 getblk(c8103210,7,0,4000,0) at getblk+0x400 cluster_read(c8103210,7,0,4000,0) at cluster_read+0xde ffs_read(f5f30c14) at ffs_read+0x25e vm_read(c3834e58,f5f30c88,c484f880,0,c5877160) at vn_read+0x178 dofileread(c5877160,c3834e58,7,814f000,2f2ed) at dofileread+0x95 read(c5877160,f5f30d14,3,4,293) at read+0x3b syscall(2f,2f,2f,814f000,2f2ed) at syscall+0x287 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (3, FreeBSD ELF32, read) eip =3D 0x8064924, esp =3D 0xbfbfd394,= ebp =3D 0xbfbfd3c0 --- The machine is running: FreeBSD fugu.marcuscom.com 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Sun Aug 29 01:02:18 EDT 2004 =20 root@new-fugu.marcuscom.com:/space2/obj/usr/src/sys/FUGU i386 Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-SAmFexpP4n2nZT2k/Zqo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBMom7b2iPiv4Uz4cRAiSXAJ9xSFivNnPjqH1Lc9Io7Erpp621JQCfRWCm sFEmij47PHfd2QraL3dcuPo= =Iqc3 -----END PGP SIGNATURE----- --=-SAmFexpP4n2nZT2k/Zqo-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 02:01:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1BADD16A4CE for ; Mon, 30 Aug 2004 02:01:47 +0000 (GMT) Received: from chello080110061116.502.15.vie.surfer.at (chello080110061116.502.15.vie.surfer.at [80.110.61.116]) by mx1.FreeBSD.org (Postfix) with SMTP id 7D00543D62 for ; Mon, 30 Aug 2004 02:01:45 +0000 (GMT) (envelope-from 4711@chello.at) Received: (qmail 4603 invoked from network); 30 Aug 2004 02:01:44 -0000 Received: from matrix010.matrix.net (192.168.123.10) by ns.matrix.net with SMTP; 30 Aug 2004 02:01:44 -0000 From: Christian Hiris <4711@chello.at> To: Justin Settle Date: Mon, 30 Aug 2004 04:01:20 +0200 User-Agent: KMail/1.6.2 References: <1093754957.564.24.camel@amon.quaggaspace.org> <41326608.7020708@root.org> <1093829490.622.1.camel@amon.quaggaspace.org> In-Reply-To: <1093829490.622.1.camel@amon.quaggaspace.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_HqoMBbAAc9gwwFE"; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200408300401.44117.4711@chello.at> cc: freebsd-current@freebsd.org cc: Nate Lawson Subject: Re: APIC causes vr0 watchdog timeouts and Interrupt storms X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 02:01:47 -0000 --Boundary-02=_HqoMBbAAc9gwwFE Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 30 August 2004 03:31, Justin Settle wrote: > On Sun, 2004-08-29 at 19:26, Nate Lawson wrote: [snip] > > >>acpi link set: _CRS failed for link \\_SB_.PCI0.ALKB - AE_NULL_ENTRY > > >>acpi link set: curr irq 0 !=3D 21 for \\_SB_.PCI0.ALKB (ignoring) > > >>unknown: _SRS failed, irq 21 via \\_SB_.PCI0.ALKB > > > > This has been fixed in -current for a while. I just MFCd the fix to > > 5.3. Let me know if it doesn't fix your problem. > > > > -Nate > > I synced up to 5.3-BETA just now, recompiled the GENERIC kernel and its > working with APIC without issue. Thanks again :) I happily can report a simple "me too". No more interrupt storms on irq 21 = on=20 the Epox KT600, works without manual irq routing now.=20 Thanks! =2D-=20 Christian Hiris <4711@chello.at> | OpenPGP KeyID 0x941B6B0B=20 OpenPGP-Key at hkp://wwwkeys.eu.pgp.net and http://pgp.mit.edu --Boundary-02=_HqoMBbAAc9gwwFE Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBMoqHcyi/EZQbawsRAjLRAJ9gu2SQ1ypDmprhSV2vMPmQ/vzKcACgm7uf rIoTj/QpLnBzyaoLXgHzd9I= =mxXV -----END PGP SIGNATURE----- --Boundary-02=_HqoMBbAAc9gwwFE-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 02:06:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E00BF16A4CE for ; Mon, 30 Aug 2004 02:06:14 +0000 (GMT) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 481CA43D41 for ; Mon, 30 Aug 2004 02:06:14 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from midget.dons.net.au ([150.101.45.33])i7U25vHY023739; Mon, 30 Aug 2004 11:36:00 +0930 (CST) Received: from inchoate.gsoft.com.au (root@localhost.dons.net.au [127.0.0.1]) by midget.dons.net.au (8.12.9/8.12.10) with ESMTP id i7U25rn7063234; Mon, 30 Aug 2004 11:35:54 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Doug White Date: Mon, 30 Aug 2004 11:35:53 +0930 User-Agent: KMail/1.6.2 References: <20040825150547.GI6962@electra.cse.Buffalo.EDU> <200408261119.25101.doconnor@gsoft.com.au> <20040829163858.Q69068@carver.gumbysoft.com> In-Reply-To: <20040829163858.Q69068@carver.gumbysoft.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200408301135.53552.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.26 (www . roaringpenguin . com / mimedefang) cc: freebsd-current@freebsd.org cc: Dan Nelson cc: Rusty Nejdl cc: Ken Smith Subject: Re: X.org configuration in sysinstall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 02:06:15 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 30 Aug 2004 09:09, Doug White wrote: > > It finds the highest resolution supported by your card _and_ monitor. > > .... at 8 bit color, which is the part that really bothers me. Yeah that IS kind of dumb. It'd be interesting to now how the heuristic works for that so it can be ma= de=20 more useful for modern hardware.. =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 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBMouB5ZPcIHs/zowRAnfsAKCBJAmp5K0BvCkJq3AEt6y65D5MOQCeJYxP QrWpPWgtfbk8s9Zh3VnV3NE=3D =3DcuHu =2D----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 02:12:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB79716A4CE for ; Mon, 30 Aug 2004 02:12:55 +0000 (GMT) Received: from hotmail.com (bay11-f6.bay11.hotmail.com [64.4.39.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7130143D46 for ; Mon, 30 Aug 2004 02:12:55 +0000 (GMT) (envelope-from dsnofe@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 29 Aug 2004 19:12:55 -0700 Received: from 218.80.194.83 by by11fd.bay11.hotmail.msn.com with HTTP; Mon, 30 Aug 2004 02:12:54 GMT X-Originating-IP: [218.80.194.83] X-Originating-Email: [dsnofe@msn.com] X-Sender: dsnofe@msn.com From: "Deng XueFeng" To: apeiron@comcast.net, outi@bytephobia.de Date: Mon, 30 Aug 2004 02:12:54 +0000 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_79ad_517f_4588" Message-ID: X-OriginalArrivalTime: 30 Aug 2004 02:12:55.0293 (UTC) FILETIME=[DC8EA2D0:01C48E36] X-Content-Filtered-By: Mailman/MimeDel 2.1.1 cc: cyrille.lefevre@laposte.net cc: current@freebsd.org Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 02:12:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_79ad_517f_4588 Content-Type: text/plain; charset=gb2312; format=flowed I sorry. I made a mistake when I upload the patchfile useing IE. here I resend th patch. try again. replace vidcontrol. #cd /usr/src/usr.sbin/vidcontrol #make ;make install;make clean #cd /usr/src/sys/dev/syscons #patch -p < current-syscons.diff then add VESA and PIXEL support in kernel. BTW: the output of "vidcontrol -i mode" show that SXGA+1400x1050, WXGA(1280 x 800), WUXGA(1920 x 1200), WSXGA(1680 x 1050) it not supported.one of my box support 1280x800. But I can only use 1024x768. I will work on that. ALSO: the syscons patch is continue development by Sascha Wildner . >From: Christopher Nehren >To: Patrick Hurrelmann >CC: cyrille.lefevre@laposte.net, Deng XueFeng ,current@freebsd.org >Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT >Date: Sun, 29 Aug 2004 11:25:18 -0400 >MIME-Version: 1.0 >Received: from rwcrmhc13.comcast.net ([204.127.198.39]) by mc8-f27.hotmail.com with Microsoft SMTPSVC(5.0.2195.6824); Sun, 29 Aug 2004 08:25:22 -0700 >Received: from prophecy.velum (pcp08490587pcs.levtwn01.pa.comcast.net[68.83.169.224]) by comcast.net (rwcrmhc13) with SMTP id <2004082915252101500madn7e> (Authid: apeiron@comcast.net); Sun, 29 Aug 2004 15:25:22 +0000 >X-Message-Info: JGTYoYF78jG7EYyTiD9Pohok6rPA+oiT >Message-ID: <20040829152518.GA17698@prophecy.dyndns.org> >References: <200408280145.i7S1jqxl096468@mail.gits.dyndns.org> <4131B0AA.6020402@bytephobia.de> >In-Reply-To: <4131B0AA.6020402@bytephobia.de> >X-Please-CC-Me: In List And Group Replies >User-Agent: Mutt/1.5.6i >Return-Path: apeiron@comcast.net >X-OriginalArrivalTime: 29 Aug 2004 15:25:22.0638 (UTC) FILETIME=[6691F6E0:01C48DDC] > >On Sun, Aug 29, 2004 at 06:32:10 EDT, Patrick Hurrelmann scribbled these >curious markings: > > I tried you patch and it applies cleanly to 5.3-BETA1, but kernelbuild > > breaks due to syscons. Does anybody experience the same? > > See attached log of kernelbuild. > >I see the same thing on 6.0-CURRENT. > >-- >I abhor a system designed for the "user", if that word is a coded >pejorative meaning "stupid and unsophisticated". -- Ken Thompson >- >Unix is user friendly. However, it isn't idiot friendly. ><< attach3 >> _________________________________________________________________ Ãâ·ÑÏÂÔØ MSN Explorer: http://explorer.msn.com/lccn/ ------=_NextPart_000_79ad_517f_4588-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 02:16:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98F3116A4CE; Mon, 30 Aug 2004 02:16:09 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 389BB43D53; Mon, 30 Aug 2004 02:16:09 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smtp3b.sentex.ca (8.13.1/8.13.1) with ESMTP id i7U2G4ds093541; Sun, 29 Aug 2004 22:16:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i7U2G3DW081035; Sun, 29 Aug 2004 22:16:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 70A5C7303F; Sun, 29 Aug 2004 22:16:04 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040830021604.70A5C7303F@freebsd-current.sentex.ca> Date: Sun, 29 Aug 2004 22:16:04 -0400 (EDT) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 02:16:10 -0000 TB --- 2004-08-30 00:44:23 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-30 00:44:23 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-08-30 00:44:23 - checking out the source tree TB --- 2004-08-30 00:44:23 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2004-08-30 00:44:23 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-30 00:49:32 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-30 00:49:32 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-08-30 00:49:32 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-30 01:53:42 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-30 01:53:42 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-08-30 01:53:42 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Aug 30 01:53:42 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon Aug 30 02:07:54 UTC 2004 TB --- 2004-08-30 02:07:54 - generating LINT kernel config TB --- 2004-08-30 02:07:54 - cd /home/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2004-08-30 02:07:54 - /usr/bin/make -B LINT TB --- 2004-08-30 02:07:54 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-30 02:07:54 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-08-30 02:07:54 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Aug 30 02:07:55 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/CURRENT/a md64/amd64/src/sys/kern/md5c.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/CURRENT/a md64/amd64/src/sys/kern/sched_4bsd.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/CURRENT/a md64/amd64/src/sys/kern/subr_autoconf.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/CURRENT/a md64/amd64/src/sys/kern/subr_blist.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/CURRENT/a md64/amd64/src/sys/kern/subr_bus.c /tinderbox/CURRENT/amd64/amd64/src/sys/kern/subr_bus.c: In function `print_device_short': /tinderbox/CURRENT/amd64/amd64/src/sys/kern/subr_bus.c:3555: warning: int format, pointer arg (arg 12) /tinderbox/CURRENT/amd64/amd64/src/sys/kern/subr_bus.c:3555: warning: too many arguments for format *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-08-30 02:16:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-30 02:16:04 - ERROR: failed to build lint kernel TB --- 2004-08-30 02:16:04 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 02:25:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFC8E16A4CE for ; Mon, 30 Aug 2004 02:25:31 +0000 (GMT) Received: from pandora.afflictions.org (asylum.afflictions.org [64.7.134.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC54643D1F for ; Mon, 30 Aug 2004 02:25:28 +0000 (GMT) (envelope-from dgerow@afflictions.org) Received: from localhost (localhost [127.0.0.1]) by pandora.afflictions.org (Postfix) with ESMTP id 2A9F078C8D; Sun, 29 Aug 2004 22:30:40 -0400 (EDT) Received: from dementia.afflictions.org (dementia.afflictions.org [172.19.206.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pandora.afflictions.org (Postfix) with ESMTP id 5C5B978C8C; Sun, 29 Aug 2004 22:30:33 -0400 (EDT) Received: by dementia.afflictions.org (Postfix, from userid 1001) id 115671700B; Sun, 29 Aug 2004 22:25:24 -0400 (EDT) Date: Sun, 29 Aug 2004 22:25:23 -0400 From: Damian Gerow To: Doug White Message-ID: <20040830022523.GD10969@afflictions.org> Mail-Followup-To: Doug White , current@freebsd.org References: <20040824073356.GK25125@afflictions.org> <20040829155924.J69068@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040829155924.J69068@carver.gumbysoft.com> X-Operating-System: FreeBSD 5.3-BETA1 on a i386 X-GPG-Fingerprint: B3D7 D901 A53A 1A99 BFD6 E6DF 9F3B 742B C288 9CC9 User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at afflictions.org cc: current@freebsd.org Subject: Re: RELENG_5 build broken with BKTR_USE_FREEBSD_SMBUS and BKTR_NEW_MSP34XX_DRIVER enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 02:25:32 -0000 Thus spake Doug White (dwhite@gumbysoft.com) [29/08/04 19:07]: : Please try the patch at: : : http://people.freebsd.org/~dwhite/msp34xx.c.patch : : Seems to test out OK on my ancient Hauppauge WinTV card. These options : must not be a frequently used combination since its been months since this : stuff was touched last. There was a PR that fixed a compile bug in one : file related to the smbus option but must not have been tested with the : msp stuff too. Actually, I since found out that using those options (I think it might have been BKTR_USE_FREEBSD_SMBUS, but I'm not sure) completely broke my bktr(4) device. I yanked 'em all, and I'm running just fine. Though I'd like to see if ..._MSP34XX_DRIVER changes anything, as I've got mono sound coming out of a stereo device. Thanks for the patch, I'll try a compile (though I'm sure if it works for you it'll work for me). From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 02:50:29 2004 Return-Path: Delivered-To: freebsd-current@mx1.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4590B16A4CE for ; Mon, 30 Aug 2004 02:50:29 +0000 (GMT) Received: from bobbi.cse.buffalo.edu (bobbi.cse.Buffalo.EDU [128.205.32.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6CB143D5E for ; Mon, 30 Aug 2004 02:50:18 +0000 (GMT) (envelope-from kensmith@FreeBSD.org) Received: from bobbi.cse.buffalo.edu (localhost.cs.Buffalo.EDU [127.0.0.1]) by bobbi.cse.buffalo.edu (8.13.1/8.12.4) with ESMTP id i7U2oH5Z045138 for ; Sun, 29 Aug 2004 22:50:17 -0400 (EDT) Received: (from kensmith@localhost) by bobbi.cse.buffalo.edu (8.13.1/8.13.1/Submit) id i7U2oHWu045137 for freebsd-current@freebsd.org; Sun, 29 Aug 2004 22:50:17 -0400 (EDT) (envelope-from kensmith) Date: Sun, 29 Aug 2004 22:50:16 -0400 From: Ken Smith To: freebsd-current@FreeBSD.org Message-ID: <20040830025016.GA45121@bobbi.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LZvS9be/3tNcYl/X" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: FreeBSD 5.3-BETA2 Available (Addendum) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 02:50:29 -0000 --LZvS9be/3tNcYl/X Content-Type: text/plain; charset=us-ascii Content-Disposition: inline The pc98 builds have completed and it was just loaded on the master FTP site. The mirror sites should begin to pick it up shortly. MD5s are: MD5 (5.3-BETA2-pc98-miniinst.iso) = e2fc0ac5b8a2f06f6613b7e5c6a22cbd MD5 (5.3-BETA2-pc98-disc2.iso) = 2fcdcef4a0dff809b233992dd05e9586 -ken --LZvS9be/3tNcYl/X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBMpXm/G14VSmup/YRAoDRAJ0bvX2kwBNaNvAhuBxTZMf4ntK6TACeIuAJ YjicgT2NEJ8+vKiVB3rEvEw= =TQmo -----END PGP SIGNATURE----- --LZvS9be/3tNcYl/X-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 03:29:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA75916A4CE; Mon, 30 Aug 2004 03:29:12 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2CEDE43D54; Mon, 30 Aug 2004 03:29:12 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id D447B50BD6; Mon, 30 Aug 2004 12:29:10 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id C70E350BC0; Mon, 30 Aug 2004 12:29:08 +0900 (JST) Date: Mon, 30 Aug 2004 12:29:08 +0900 Message-ID: <7m4qml483f.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: Tim Kientzle In-Reply-To: <412EAE44.9010500@freebsd.org> References: <7m3c2e88xk.wl@black.imgsrc.co.jp> <412D6534.9030503@freebsd.org> <412D68AD.7050906@freebsd.org> <7moeky5wyg.wl@black.imgsrc.co.jp> <412D8958.7050707@freebsd.org> <7mllg25qma.wl@black.imgsrc.co.jp> <412EAE44.9010500@freebsd.org> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 cc: Jun Kuriyama cc: Current Subject: Re: bsdtar eats CPU when extracting POSIX tar archive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 03:29:12 -0000 At Thu, 26 Aug 2004 20:45:08 -0700, Tim Kientzle wrote: > >>Looks like it could be network related. I see almost > >>5,000 calls to recvfrom. ..... Is it uid/gid lookups, > >>perhaps? bsdtar does not (yet) do any caching of uid/gid > >>lookups... > > > > Hmm, yes, this box uses NIS as client. I confirmed a lot of NIS > > packets during extraction. > > I just added basic uid/gid caching in libarchive's extract > routines. This should provide a big performance boost > to bsdtar in situations like yours. > > Please try the libarchive/bsdtar that's in HEAD right > now and let me know how that works for you. I confirmed it in my environment and it works great! Thanks! -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 03:49:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6719816A4CE; Mon, 30 Aug 2004 03:49:42 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11EFF43D1F; Mon, 30 Aug 2004 03:49:42 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smtp3b.sentex.ca (8.13.1/8.13.1) with ESMTP id i7U3nf0A007168; Sun, 29 Aug 2004 23:49:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7U3nfW0097218; Sun, 29 Aug 2004 23:49:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 73F0E7303F; Sun, 29 Aug 2004 23:49:41 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040830034941.73F0E7303F@freebsd-current.sentex.ca> Date: Sun, 29 Aug 2004 23:49:41 -0400 (EDT) Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 03:49:42 -0000 TB --- 2004-08-30 02:16:04 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-30 02:16:04 - starting CURRENT tinderbox run for i386/i386 TB --- 2004-08-30 02:16:04 - checking out the source tree TB --- 2004-08-30 02:16:04 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2004-08-30 02:16:04 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-30 02:21:24 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-30 02:21:24 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2004-08-30 02:21:24 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-30 03:25:10 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-30 03:25:10 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2004-08-30 03:25:10 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Aug 30 03:25:10 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon Aug 30 03:41:08 UTC 2004 TB --- 2004-08-30 03:41:08 - generating LINT kernel config TB --- 2004-08-30 03:41:08 - cd /home/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- 2004-08-30 03:41:08 - /usr/bin/make -B LINT TB --- 2004-08-30 03:41:08 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-30 03:41:08 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2004-08-30 03:41:08 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Aug 30 03:41:08 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /tinderbox/CURRENT/i386/i386/src/sys/kern/md5c.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /tinderbox/CURRENT/i386/i386/src/sys/kern/sched_4bsd.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /tinderbox/CURRENT/i386/i386/src/sys/kern/subr_autoconf .c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /tinderbox/CURRENT/i386/i386/src/sys/kern/subr_blist.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/i386/src/sys -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/i386/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /tinderbox/CURRENT/i386/i386/src/sys/kern/subr_bus.c /tinderbox/CURRENT/i386/i386/src/sys/kern/subr_bus.c: In function `print_device_short': /tinderbox/CURRENT/i386/i386/src/sys/kern/subr_bus.c:3555: warning: int format, pointer arg (arg 12) /tinderbox/CURRENT/i386/i386/src/sys/kern/subr_bus.c:3555: warning: too many arguments for format *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2004-08-30 03:49:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-30 03:49:41 - ERROR: failed to build lint kernel TB --- 2004-08-30 03:49:41 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 04:13:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B430116A4CE; Mon, 30 Aug 2004 04:13:30 +0000 (GMT) Received: from cpanel.ezone.ru (cpanel.ezone.ru [213.85.31.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50E2843D2D; Mon, 30 Aug 2004 04:13:29 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from [81.195.3.153] (ppp3-153.pppoe.mtu-net.ru [81.195.3.153]) (authenticated bits=0) by cpanel.ezone.ru (8.13.1/8.12.11) with ESMTP id i7U4DKgm051716; Mon, 30 Aug 2004 08:13:21 +0400 (MSD) (envelope-from mcsi@mcsi.pp.ru) Message-ID: <4132A956.4070604@mcsi.pp.ru> Date: Mon, 30 Aug 2004 08:13:10 +0400 From: Maxim Maximov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040810 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Doug White References: <412FA7E8.80BE87BC@freebsd.org> <20040829172000.F69068@carver.gumbysoft.com> In-Reply-To: <20040829172000.F69068@carver.gumbysoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail3.ezone.ru cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: [Fwd: cvs commit: src/sys/kern sys_generic.c] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 04:13:30 -0000 Doug White wrote: > On Fri, 27 Aug 2004, Andre Oppermann wrote: > > >>Maybe this fixes poll() problems/errors some people have seen on their >>machines. I am not sure if this alignment would have caused problems >>on non-ia32 architectures but it is certainly more correct now. ;-) > > > Heh. Its possible; I spent a few hours on Saturday trying to trigger any > apparent poll() wakeup problems with unix domain sockets and TCP with no > joy. The one report that was forwarded to me involved some windowmaker > dockapps and the poll()s were probably sitting on the X domain socket. > But this commit didn't change anything for me. I'm running your last change mcsi@ultra(ttyp1) [92] ~> ident /boot/kernel/kernel |grep sys_gen $FreeBSD: src/sys/kern/sys_generic.c,v 1.133 2004/08/27 21:23:50 andre Exp $ and experience all the same hangs. -- Maxim Maximov From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 04:28:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D8E316A4CE; Mon, 30 Aug 2004 04:28:11 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1320F43D49; Mon, 30 Aug 2004 04:28:11 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7U4PfET001593; Mon, 30 Aug 2004 00:25:41 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7U4PfMD001590; Mon, 30 Aug 2004 00:25:41 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 30 Aug 2004 00:25:41 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Gleb Smirnoff In-Reply-To: <20040829145445.GB24815@cell.sick.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: mutex Giant not owned at /usr/src/sys/kern/vfs_vnops.c:120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 04:28:11 -0000 Could you try the following patch: Index: ng_socket.c =================================================================== RCS file: /home/ncvs/src/sys/netgraph/ng_socket.c,v retrieving revision 1.53 diff -u -r1.53 ng_socket.c --- ng_socket.c 31 Jul 2004 21:32:55 -0000 1.53 +++ ng_socket.c 30 Aug 2004 04:17:38 -0000 @@ -300,7 +300,9 @@ /* Not found, try to load it as a loadable module */ snprintf(filename, sizeof(filename), "ng_%s", mkp->type); + mtx_lock(&Giant); error = linker_load_module(NULL, filename, NULL, NULL, &lf); + mtx_unlock(&Giant); if (error != 0) { FREE(msg, M_NETGRAPH_MSG); goto release; This causes Giant to be acquired in the event we enter the linker code (and hence VFS code) via netgraph ngc_send(). It should be safe in this context as we enter protocol send routines without mutexes held (i.e., why we're also able to do blocking memory allocation here.) Thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research On Sun, 29 Aug 2004, Gleb Smirnoff wrote: > #21 0xc055ecc0 in kdb_enter (msg=0x0) at cpufunc.h:56 > #22 0xc0542dd5 in panic (fmt=0xc06dd9db "mutex %s not owned at %s:%d") > at /usr/src/sys/kern/kern_shutdown.c:536 > #23 0xc053914c in _mtx_assert (m=0xc07402a0, what=0, > file=0xc06e6fbd "/usr/src/sys/kern/vfs_vnops.c", line=120) > at /usr/src/sys/kern/kern_mutex.c:736 > #24 0xc05b165c in vn_open_cred (ndp=0xd0aafaa0, flagp=0xd0aaf97c, cmode=0, > cred=0xc1ad1300, fdidx=0) at /usr/src/sys/kern/vfs_vnops.c:120 > #25 0xc05b1613 in vn_open (ndp=0x0, flagp=0x0, cmode=0, fdidx=0) > at /usr/src/sys/kern/vfs_vnops.c:91 > #26 0xc05343a0 in linker_hints_lookup ( > path=0xc0714020 "/boot/kernel;/boot/modules", pathlen=12, > modname=0xd0aafb74 "ng_tee", modnamelen=6, verinfo=0x0) > at /usr/src/sys/kern/kern_linker.c:1473 > #27 0xc0534947 in linker_search_module (modname=0xd0aafb74 "ng_tee", > modnamelen=6, verinfo=0x0) at /usr/src/sys/kern/kern_linker.c:1593 > #28 0xc0534b19 in linker_load_module (kldname=0x0, > modname=0xd0aafb74 "ng_tee", parent=0x0, verinfo=0x0, lfpp=0xd0aafb70) > at /usr/src/sys/kern/kern_linker.c:1682 > *** these "??" should be: > ngc_send() in /usr/src/sys/netgraph/ng_socket.c > #29 0xc1b71d17 in ?? () > #30 0x00000000 in ?? () > #31 0xd0aafb74 in ?? () > #32 0x00000000 in ?? () > #33 0x00000000 in ?? () > #34 0xd0aafb70 in ?? () > #35 0xc1ae6c38 in ?? () > #36 0x00000000 in ?? () > #37 0xc1789080 in ?? () > #38 0xc06dd88c in ?? () > #39 0x745f676e in ?? () > #40 0xc1006565 in ?? () > #41 0xd0aafc48 in ?? () > #42 0xd0aafcbc in ?? () > #43 0xc0548b25 in uiomove (cp=0xc17a8654, n=0, uio=0xc1692140) > at /usr/src/sys/kern/kern_subr.c:164 > #44 0xc0585621 in sosend (so=0xc17a8654, addr=0xc156a5d0, uio=0xd0aafc48, > top=0xc1609300, control=0x0, flags=0, td=0xc173d840) > at /usr/src/sys/kern/uipc_socket.c:799 > #45 0xc058c0ac in kern_sendit (td=0xc173d840, s=3, mp=0xd0aafcc4, flags=0, > control=0x0) at /usr/src/sys/kern/uipc_syscalls.c:738 > #46 0xc058bf3b in sendit (td=0x0, s=0, mp=0xd0aafcc4, flags=0) > at /usr/src/sys/kern/uipc_syscalls.c:682 > #47 0xc058c22b in sendto (td=0x0, uap=0x0) > at /usr/src/sys/kern/uipc_syscalls.c:795 > #48 0xc0697c50 in syscall (frame= > {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077946376, tf_esi = -1077946382, tf_ebp = -1077945832, tf_isp = -794100364, tf_ebx = 671649088, tf_edx = -1077946384, tf_ecx = 5, tf_eax = 133, tf_trapno = 12, tf_err = 2, tf_eip = 671984639, tf_cs = 31, tf_eflags = 514, tf_esp = -1077946452, tf_ss = 47}) > at /usr/src/sys/i386/i386/trap.c:1004 > #49 0xc06851bf in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:201 > > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > _______________________________________________ > 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 Aug 30 05:23:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DEAE16A4CE for ; Mon, 30 Aug 2004 05:23:49 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 063E243D5D for ; Mon, 30 Aug 2004 05:23:49 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 23799 invoked from network); 30 Aug 2004 05:23:48 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 30 Aug 2004 05:23:48 -0000 Received: from hydrogen.funkthat.com (bixsto@localhost.funkthat.com [127.0.0.1])i7U5NluU028147; Sun, 29 Aug 2004 22:23:48 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i7U5Nkux028146; Sun, 29 Aug 2004 22:23:46 -0700 (PDT) Date: Sun, 29 Aug 2004 22:23:46 -0700 From: John-Mark Gurney To: freebsd-current@freebsd.org, matthew.thyer@dsto.defence.gov.au Message-ID: <20040830052346.GY29902@funkthat.com> Mail-Followup-To: freebsd-current@freebsd.org, matthew.thyer@dsto.defence.gov.au References: <20040825061706.GE9209@squirm.dsto.defence.gov.au> <20040825201828.GR29902@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040825201828.GR29902@funkthat.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Subject: Re: 5.3-BETA panic .... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 05:23:49 -0000 John-Mark Gurney wrote this message on Wed, Aug 25, 2004 at 13:18 -0700: > Wilkinson, Alex wrote this message on Wed, Aug 25, 2004 at 15:47 +0930: > [...] > > Just a me too, but mine is from syslogd, and was through console device: > System shutdown time has arrived^G^G^M > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0xdeadc136 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc07665fa > stack pointer = 0x10:0xd09717b0 > frame pointer = 0x10:0xd09717bc > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 267 (syslogd) > [thread 100044] > Stopped at commodem+0x12: movl 0x58(%eax),%ebx > db> tr > commodem(c19f0600,0,1,c17c1800,6) at commodem+0x12 > comhardclose(c17c1800) at comhardclose+0x6c > sioopen(c1828300,6,2000,c17f7000,0) at sioopen+0x392 > spec_open(d097186c,d0971928,c06584bd,d097186c,80) at spec_open+0x2c4 > spec_vnoperate(d097186c) at spec_vnoperate+0x13 > vn_open_cred(d097196c,c08e2c18,0,c170d480,ffffffff) at vn_open_cred+0x431 > vn_open(d097196c,c08e2c18,0,ffffffff) at vn_open+0x1e > cn_devopen(c08e2be0,c17f7000,0) at cn_devopen+0xac > cnopen(c08af274,6,2000,c17f7000,0) at cnopen+0x41 > spec_open(d0971a74,d0971b30,c06584bd,d0971a74,80) at spec_open+0x2c4 > spec_vnoperate(d0971a74) at spec_vnoperate+0x13 > vn_open_cred(d0971be4,d0971ce4,0,c170d480,7) at vn_open_cred+0x431 > vn_open(d0971be4,d0971ce4,0,7,c08b24e0) at vn_open+0x1e > kern_open(c17f7000,804f220,0,6,0) at kern_open+0xd2 > open(c17f7000,d0971d14,3,2,292) at open+0x18 > syscall(2f,2f,2f,7,bfbfdff0) at syscall+0x217 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (5, FreeBSD ELF32, open), eip = 0x280d358f, esp = 0xbfbfd9dc, ebp = 0xbfbfda58 --- Just a bit more info about this... This is 100% reproducable on my system.. It's a standard sio0 comconsole, and I just need to run shutdown -r now from ttyd0 (the comconsole), and it panics. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 05:30:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76D5216A4CE; Mon, 30 Aug 2004 05:30:10 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 39B1443D4C; Mon, 30 Aug 2004 05:30:10 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id EDA9A1FF92F; Mon, 30 Aug 2004 07:30:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id E5EC11FF91D; Mon, 30 Aug 2004 07:30:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 28B6715682; Mon, 30 Aug 2004 05:29:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 1DC5C15329; Mon, 30 Aug 2004 05:29:56 +0000 (UTC) Date: Mon, 30 Aug 2004 05:29:56 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Robert Watson In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: Gleb Smirnoff cc: FreeBSD current mailing list Subject: Re: mutex Giant not owned at /usr/src/sys/kern/vfs_vnops.c:120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 05:30:10 -0000 On Mon, 30 Aug 2004, Robert Watson wrote: G'morning, > Could you try the following patch: seems to work fine; my test program crashes somewhen later cause of some pthread probelm but modules got loaded successfully w/o panic. > Index: ng_socket.c > =================================================================== > RCS file: /home/ncvs/src/sys/netgraph/ng_socket.c,v > retrieving revision 1.53 > diff -u -r1.53 ng_socket.c > --- ng_socket.c 31 Jul 2004 21:32:55 -0000 1.53 > +++ ng_socket.c 30 Aug 2004 04:17:38 -0000 > @@ -300,7 +300,9 @@ > > /* Not found, try to load it as a loadable module */ > snprintf(filename, sizeof(filename), "ng_%s", mkp->type); > + mtx_lock(&Giant); > error = linker_load_module(NULL, filename, NULL, NULL, &lf); > + mtx_unlock(&Giant); > if (error != 0) { > FREE(msg, M_NETGRAPH_MSG); > goto release; > > This causes Giant to be acquired in the event we enter the linker code > (and hence VFS code) via netgraph ngc_send(). It should be safe in this > context as we enter protocol send routines without mutexes held (i.e., why > we're also able to do blocking memory allocation here.) please commit. > Thanks! many thanks to you! :-) -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 05:32:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D98F416A4CE; Mon, 30 Aug 2004 05:32:13 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B08243D49; Mon, 30 Aug 2004 05:32:13 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smtp3.sentex.ca (8.13.1/8.13.1) with ESMTP id i7U5WBus091031; Mon, 30 Aug 2004 01:32:11 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i7U5WCN8049439; Mon, 30 Aug 2004 01:32:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B4EB57303F; Mon, 30 Aug 2004 01:32:12 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040830053212.B4EB57303F@freebsd-current.sentex.ca> Date: Mon, 30 Aug 2004 01:32:12 -0400 (EDT) Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 05:32:14 -0000 TB --- 2004-08-30 03:49:41 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-30 03:49:41 - starting CURRENT tinderbox run for i386/pc98 TB --- 2004-08-30 03:49:41 - checking out the source tree TB --- 2004-08-30 03:49:41 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2004-08-30 03:49:41 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-30 03:54:53 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-30 03:54:53 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2004-08-30 03:54:53 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-30 05:11:10 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-30 05:11:10 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2004-08-30 05:11:10 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Aug 30 05:11:12 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon Aug 30 05:25:06 UTC 2004 TB --- 2004-08-30 05:25:06 - generating LINT kernel config TB --- 2004-08-30 05:25:06 - cd /home/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- 2004-08-30 05:25:06 - /usr/bin/make -B LINT TB --- 2004-08-30 05:25:06 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-30 05:25:06 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2004-08-30 05:25:06 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Aug 30 05:25:07 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /tinderbox/CURRENT/i386/pc98/src/sys/kern/md5c.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /tinderbox/CURRENT/i386/pc98/src/sys/kern/sched_4bsd.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /tinderbox/CURRENT/i386/pc98/src/sys/kern/subr_autoconf .c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /tinderbox/CURRENT/i386/pc98/src/sys/kern/subr_blist.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /tinderbox/CURRENT/i386/pc98/src/sys/kern/subr_bus.c /tinderbox/CURRENT/i386/pc98/src/sys/kern/subr_bus.c: In function `print_device_short': /tinderbox/CURRENT/i386/pc98/src/sys/kern/subr_bus.c:3555: warning: int format, pointer arg (arg 12) /tinderbox/CURRENT/i386/pc98/src/sys/kern/subr_bus.c:3555: warning: too many arguments for format *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2004-08-30 05:32:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-30 05:32:12 - ERROR: failed to build lint kernel TB --- 2004-08-30 05:32:12 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 06:00:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0435916A4D0; Mon, 30 Aug 2004 06:00:46 +0000 (GMT) Received: from smtp3.server.rpi.edu (smtp3.server.rpi.edu [128.113.2.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 893B543D46; Mon, 30 Aug 2004 06:00:28 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp3.server.rpi.edu (8.13.0/8.13.0) with ESMTP id i7U60QUm009317; Mon, 30 Aug 2004 02:00:27 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20040829174521.H69068@carver.gumbysoft.com> References: <200408271337.i7RDbXgu052801@pooker.samsco.org> <20040829174521.H69068@carver.gumbysoft.com> Date: Mon, 30 Aug 2004 02:00:25 -0400 To: Doug White From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: CanIt (www . canit . ca) cc: re@freebsd.org cc: current@freebsd.org Subject: Re: 5.3-RELEASE TODO - make/kqueue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 06:00:46 -0000 At 5:45 PM -0700 8/29/04, Doug White wrote: >On Sat, 28 Aug 2004, Garance A Drosihn wrote: > >> I do still get the "*** Signal 6"s, even though I am now running > > with v1.76 of src/sys/kern/kern_lock.c. ... > >If you're sure you've updated, and have tried rebuilding make >to eliminate a corrupted binary, then you might have hardware >problems. This seems much too repeatable to be hardware. The more times I repeat my testing, the more consistent the problem seems. (but I'll spare you the details until I narrow it down even more...). I am sure I have rebuilt make several times, because I am switching between "make WITH_KQUEUE" and make without kqueue, and I do complete recompiles each time I switch. These signal-6's are not coming up in "normal operation" for me. It is only when I have been stress-testing changes to the make command. >Are you using gvinum? No. I am not that adventurous when it comes to filesystems. I use plain UFS2. I even turn off background FSCK-ing because I'm not sure I trust it yet... Please note that I did not mean to make a big deal about these signal 6's. I have to go out-of-my-way to trigger the problem, but now that I know what to do I can trigger it at will. Given that I can repeat it I do intend to keep poking away at it, but I do not consider this a serious issue. So unless a lot of other people start reporting something similar, I do not expect anyone else to spend any of their own time trying to pin it down. It's the kind of annoying little anomaly that will drive me nuts unless I pin it down, but in the greater scheme of things it is probably irrelevant. I do appreciate the suggestions because they give me more ideas of things I want to try when I have the time. But I don't expect anyone to worry about this. Certainly I am not worried about it. The main thing I wished to say was just "Great progress has been made wrt using KQUEUE for make", given how well it has stood up to my repeated hammering of it. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 06:29:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B9F316A4CF for ; Mon, 30 Aug 2004 06:29:39 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45A4043D1D for ; Mon, 30 Aug 2004 06:29:37 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7U6RYAQ045717; Mon, 30 Aug 2004 00:27:36 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 30 Aug 2004 00:27:41 -0600 (MDT) Message-Id: <20040830.002741.22501721.imp@bsdimp.com> To: midian@ihme.org From: "M. Warner Losh" In-Reply-To: <20040829235244.G6505@midi.ihme.net> References: <20040828.134356.21928602.imp@bsdimp.com> <20040828201403.GA797@prophecy.dyndns.org> <20040829235244.G6505@midi.ihme.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: freebsd-current@freebsd.org cc: apeiron@comcast.net Subject: Re: USB keyboard problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 06:29:39 -0000 In message: <20040829235244.G6505@midi.ihme.net> Markus H=E4stbacka writes: : On Sat, 28 Aug 2004, Christopher Nehren wrote: : = : > On Sat, Aug 28, 2004 at 15:43:56 EDT, M. Warner Losh scribbled thes= e : > curious markings: : >> So current from aug 15th works, but current from today with aug 15= th : >> usb doesn't. Is that correct? : > : > Yes. Same for August 14th, and 13th. : > : Maybe this is not a usb problem? Maybe it's a problem in the keyboard= = : driver? The keyboard driver has other problems too, for example: I ha= ve a = : keyboard with all these extra buttons, and if my keyboard is plugged = in = : the ps2 port (whatever version of freebsd, 5.2.1, 4.10 etc.) the keys= = : print some weird letter combinations to the console outside X, but if= it's = : plugged into the usb port the keys don't have any life. FYI: my keybo= ard = : is a Logitech Internet Navigator SE. There's a number of minor incompatibilities between usb key translation and AT keyboard scan codes. This sounds more like that than a system problem. If it were systemic, then you'd not get any keys to work on the keyboard. Also, the keyboard and hid interfaces aren't married (I think latter day versions of NetBSD do this), so hid breaking wouldn't have any impact on the rest. Warner From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 06:34:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC06116A4CE for ; Mon, 30 Aug 2004 06:34:16 +0000 (GMT) Received: from cocoa.syncrontech.com (cocoa-e0.syncrontech.com [62.71.8.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id DCFFD43D5A for ; Mon, 30 Aug 2004 06:34:14 +0000 (GMT) (envelope-from ari@suutari.iki.fi) Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.19])i7U6XxWw066203; Mon, 30 Aug 2004 09:34:01 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Received: from coffee (coffee.syncrontech.com [62.71.8.37]) i7U6Xw0V053125; Mon, 30 Aug 2004 09:33:58 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Message-ID: <007701c48e5b$530485f0$2508473e@sad.syncrontech.com> From: "Ari Suutari" To: "Marc van Kempen" , Date: Mon, 30 Aug 2004 09:33:54 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Scanned-By: MIMEDefang 2.30 (www . roaringpenguin . com / mimedefang) X-Scanned-By: MIMEDefang 2.24 (www . roaringpenguin . com / mimedefang) Subject: Re: ATA write-dma interrupt was seen but timeout fired LBA=53346288 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 06:34:16 -0000 Hi, >> ATA write-dma interrupt was seen but timeout fired LBA=53346288 >> ATA write-dma interrupt was seen but timeout fired LBA=53346288 >> ATA write-dma interrupt was seen but taskqueue stalled LBA=53346288 > > I updated my old Compaq 1500c from 4.10 to -current last week. > I'm seeing similar messages after resume and the system hangs > eventually. > Otherwise the system seems to work ok. Updated to recent current (28.8) seems to fix this. I haven't seen any ATA interrupt/timeout messages after update. I assume that these changes are not on RELENG_5 branch yet, since it looked like it still suffers from the problems above. Only problem left is that sound card is not detected with acpi, but thats minor.... Ari S. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 07:02:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A411816A4CE for ; Mon, 30 Aug 2004 07:02:25 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D73F43D5E for ; Mon, 30 Aug 2004 07:02:25 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1C1gBH-0000MN-Mh; Mon, 30 Aug 2004 11:02:19 +0400 From: Vladimir Grebenschikov To: Maxim Sobolev In-Reply-To: <4132358C.6060108@portaone.com> References: <080a01c48dff$4248a310$7890a8c0@gits.invalid> <4132358C.6060108@portaone.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Mon, 30 Aug 2004 11:02:19 +0400 Message-Id: <1093849339.864.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.93FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: Cyrille Lefevre cc: Deng XueFeng cc: "current@freebsd.org" Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support forFreeBSD-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 07:02:25 -0000 On Sun, 2004-08-29 at 22:59 +0300, Maxim Sobolev wrote: > vidcontrol -i mode is your best friend! ;-) Yes, it shows some corresponding graphical modes: # kldload vesa # vidcontrol -i mode < /dev/ttyv1 | fgrep 1400x1050 320 (0x140) 0x0000000f G 1400x1050x8 1 8x16 0xa0000 64k 64k 0xd8000000 16384k 321 (0x141) 0x0000000f G 1400x1050x15 1 8x16 0xa0000 64k 64k 0xd8000000 16384k 322 (0x142) 0x0000000f G 1400x1050x16 1 8x16 0xa0000 64k 64k 0xd8000000 16384k 323 (0x143) 0x0000000f G 1400x1050x24 1 8x16 0xa0000 64k 64k 0xd8000000 16384k 324 (0x144) 0x0000000f G 1400x1050x32 1 8x16 0xa0000 64k 64k 0xd8000000 16384k but anyway there are a little text modes: # vidcontrol -i mode < /dev/ttyv1 | fgrep T 24 (0x018) 0x00000001 T 80x25 8x16 0xb8000 32k 32k 0x00000000 32k 30 (0x01e) 0x00000001 T 80x50 8x8 0xb8000 32k 32k 0x00000000 32k 32 (0x020) 0x00000001 T 80x30 8x16 0xb8000 32k 32k 0x00000000 32k 34 (0x022) 0x00000001 T 80x60 8x8 0xb8000 32k 32k 0x00000000 32k And the all standard VGA modes, and I can't switch to text mode based 1400x1050 resolution (all Ok with Xorg server, I talk only about syscons in high resolution, text or raster) # vidcontrol VESA_800x600 < /dev/ttyv1 vidcontrol: cannot set videomode: Operation not supported by device usage: vidcontrol [-CdHLPpx] [-b color] [-c appearance] [-f [size] file] [-g geometry] [-h size] [-i adapter | mode] [-l screen_map] [-M char] [-m on | off] [-r foreground background] [-S on | off] [-s number] [-t N | off] [mode] [foreground [background]] [show] # vidcontrol VESA_1400x1050 < /dev/ttyv1 usage: vidcontrol [-CdHLPpx] [-b color] [-c appearance] [-f [size] file] [-g geometry] [-h size] [-i adapter | mode] [-l screen_map] [-M char] [-m on | off] [-r foreground background] [-S on | off] [-s number] [-t N | off] [mode] [foreground [background]] [show] > -Maxim -- Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 07:03:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C001A16A4CE; Mon, 30 Aug 2004 07:03:50 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE67743D46; Mon, 30 Aug 2004 07:03:49 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7U73j5j059655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Aug 2004 10:03:46 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i7U73pxW084657; Mon, 30 Aug 2004 10:03:51 +0300 (EEST) (envelope-from ru) Date: Mon, 30 Aug 2004 10:03:51 +0300 From: Ruslan Ermilov To: "David O'Brien" , ia64@FreeBSD.org, current@FreeBSD.org Message-ID: <20040830070350.GB84337@ip.net.ua> References: <20040829091547.927B07303F@freebsd-current.sentex.ca> <20040829143543.GX30151@darkness.comp.waw.pl> <20040829145603.GG23120@ip.net.ua> <20040829224211.GD92947@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qlTNgmc+xy1dBmNv" Content-Disposition: inline In-Reply-To: <20040829224211.GD92947@dragon.nuxi.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new Subject: Re: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 07:03:50 -0000 --qlTNgmc+xy1dBmNv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 29, 2004 at 03:42:11PM -0700, David O'Brien wrote: > On Sun, Aug 29, 2004 at 05:56:03PM +0300, Ruslan Ermilov wrote: > > > +> /tinderbox/CURRENT/ia64/ia64/src/sys/geom/mirror/g_mirror.c:2485: = warning: 'sc' might be used uninitialized in this function > > > +> *** Error code 1 > > >=20 > > > Fixed, sorry. > > > PS. Can someone show me which compiler flag expose those "bugs"? > > >=20 > > I believe it's -O2 (which is not in default CFLAGS). >=20 > All the world is not 'i386'... > -O2 is the default on some of our platforms -- amd64, sparc64, ia64 >=20 You're right. I was thinking of sys.mk when I wrote this, when I should have thought about kern.pre.mk. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --qlTNgmc+xy1dBmNv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBMtFWqRfpzJluFF4RAvN5AJ9pe5qM/Ow7L/geJssuCLG+ZshG7QCgh8l1 TkMhkqPk2asoOuc8HQuE2U0= =RfYN -----END PGP SIGNATURE----- --qlTNgmc+xy1dBmNv-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 07:04:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6DC916A4CE; Mon, 30 Aug 2004 07:04:46 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 274A643D1D; Mon, 30 Aug 2004 07:04:46 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7U74g2u059665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Aug 2004 10:04:42 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i7U74loa084673; Mon, 30 Aug 2004 10:04:47 +0300 (EEST) (envelope-from ru) Date: Mon, 30 Aug 2004 10:04:47 +0300 From: Ruslan Ermilov To: "David O'Brien" , Pawel Jakub Dawidek , FreeBSD Tinderbox , current@FreeBSD.org, ia64@FreeBSD.org Message-ID: <20040830070447.GC84337@ip.net.ua> References: <20040829091547.927B07303F@freebsd-current.sentex.ca> <20040829143543.GX30151@darkness.comp.waw.pl> <20040829224045.GC92947@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Clx92ZfkiYIKRjnr" Content-Disposition: inline In-Reply-To: <20040829224045.GC92947@dragon.nuxi.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new Subject: Re: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 07:04:47 -0000 --Clx92ZfkiYIKRjnr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 29, 2004 at 03:40:45PM -0700, David O'Brien wrote: > On Sun, Aug 29, 2004 at 04:35:43PM +0200, Pawel Jakub Dawidek wrote: > > On Sun, Aug 29, 2004 at 05:15:47AM -0400, FreeBSD Tinderbox wrote: > > +> /tinderbox/CURRENT/ia64/ia64/src/sys/geom/mirror/g_mirror.c: In func= tion `g_mirror_taste': > > +> /tinderbox/CURRENT/ia64/ia64/src/sys/geom/mirror/g_mirror.c:2485: wa= rning: 'sc' might be used uninitialized in this function > > +> *** Error code 1 > >=20 > > Fixed, sorry. > > PS. Can someone show me which compiler flag expose those "bugs"? >=20 > I've fixed a few of these (one in your code before I think). > A simply compile test on Sledge.freebsd.org with default CFLAGS will show > the problem. Sledge is really fast to compile on. :-) >=20 There's still an option to cross-build, or if your machine is fast, to "make universe", which is now parallel. ;) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --Clx92ZfkiYIKRjnr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBMtGPqRfpzJluFF4RAsWeAJ9LfvY3HpsQ+XTUIygLm5t/V/3a+ACfX5s+ Dhh+RAKbpjZBHr80YGEYayo= =0PFy -----END PGP SIGNATURE----- --Clx92ZfkiYIKRjnr-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 07:11:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E79D416A4CE for ; Mon, 30 Aug 2004 07:11:22 +0000 (GMT) Received: from dd2626.kasserver.com (dd2626.kasserver.com [81.209.184.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0397E43D46 for ; Mon, 30 Aug 2004 07:11:22 +0000 (GMT) (envelope-from outi@bytephobia.de) Received: from [10.0.0.2] (pD9E4B231.dip.t-dialin.net [217.228.178.49]) by dd2626.kasserver.com (Postfix) with ESMTP id 9370A85501; Mon, 30 Aug 2004 09:11:18 +0200 (CEST) From: Patrick Hurrelmann To: cyrille.lefevre@laposte.net In-Reply-To: <200408291848.i7TImAq8072080@mail.gits.dyndns.org> References: <200408291848.i7TImAq8072080@mail.gits.dyndns.org> Content-Type: text/plain Message-Id: <1093845824.822.3.camel@duality.bytephobia.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 30 Aug 2004 08:03:44 +0200 Content-Transfer-Encoding: 7bit cc: Deng XueFeng cc: current@freebsd.org Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: outi@bytephobia.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 07:11:23 -0000 Hi, thanks for reworking this patch. I'll test it later ;) 1024x768 console on my laptop would would be really nat. I see the mentioned error aka "vidcontrol: showing the mouse: Invalid argument", too. But it doesn't seem to affect behaviour of vidcontrol. On Sun, 2004-08-29 at 20:48, Cyrille Lefevre wrote: > On Aug 29, 2004 12:32:10 pm +0200, Patrick Hurrelmann wrote: > > Hi Cyrille, > > > > I tried you patch and it applies cleanly to 5.3-BETA1, but kernelbuild > > breaks due to syscons. Does anybody experience the same? > > ok, it seems I've missed some static void... don't understand why I don't > have the same warnings as yours using today's -current ? thanks anyway. > > > See attached log of kernelbuild. > > PS : did you notice the same vidcontrol error messages as Aurelien Nephtali > (aka "vidcontrol: showing the mouse: Invalid argument") ? > > however, here is the build fix (scvgarndr.c only) : > > Index: scvgarndr.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/syscons/scvgarndr.c,v > retrieving revision 1.15 > diff -u -I$Id.*$ -I$.+BSD.*$ -r1.15 scvgarndr.c > --- scvgarndr.c 30 May 2004 20:08:42 -0000 1.15 > +++ scvgarndr.c 29 Aug 2004 17:07:28 -0000 > @@ -47,7 +47,7 @@ > #include > > #ifndef SC_RENDER_DEBUG > -#define SC_RENDER_DEBUG 0 > +#define SC_RENDER_DEBUG 0 > #endif > > static vr_clear_t vga_txtclear; > @@ -59,7 +59,7 @@ > #ifndef SC_NO_CUTPASTE > static vr_draw_mouse_t vga_txtmouse; > #else > -#define vga_txtmouse (vr_draw_mouse_t *)vga_nop > +#define vga_txtmouse (vr_draw_mouse_t *)vga_nop > #endif > > #ifdef SC_PIXEL_MODE > @@ -73,7 +73,7 @@ > #ifndef SC_NO_CUTPASTE > static vr_draw_mouse_t vga_pxlmouse; > #else > -#define vga_pxlmouse (vr_draw_mouse_t *)vga_nop > +#define vga_pxlmouse (vr_draw_mouse_t *)vga_nop > #endif > #endif /* SC_PIXEL_MODE */ > > @@ -155,6 +155,37 @@ > #endif > #endif > > +#ifdef SC_PIXEL_MODE > +static uint32_t vga_palette32[16] = { > + 0x000000, 0x0000ad, 0x00ad00, 0x00adad, > + 0xad0000, 0xad00ad, 0xad5200, 0xadadad, > + 0x525252, 0x5252ff, 0x52ff52, 0x52ffff, > + 0xff5252, 0xff52ff, 0xffff52, 0xffffff > +}; > + > +static uint16_t vga_palette16[16] = { > + 0x0000, 0x0016, 0x0560, 0x0576, 0xb000, 0xb016, 0xb2a0, 0xb576, > + 0x52aa, 0x52bf, 0x57ea, 0x57ff, 0xfaaa, 0xfabf, 0xffea, 0xffff > +}; > + > +static uint16_t vga_palette15[16] = { > + 0x0000, 0x0016, 0x02c0, 0x02d6, 0x5800, 0x5816, 0x5940, 0x5ad6, > + 0x294a, 0x295f, 0x2bea, 0x2bff, 0x7d4a, 0x7d5f, 0x7fea, 0x7fff > +}; > + > +#define VIDEO_MEMORY_POS(scp, pos, x) \ > + scp->sc->adp->va_window + \ > + x * scp->xoff + \ > + scp->yoff * scp->font_size * scp->sc->adp->va_line_width + \ > + x * (pos % scp->xsize) + \ > + scp->font_size * scp->sc->adp->va_line_width * (pos / scp->xsize) > + > +#ifndef SC_NO_CUTPASTE > +static uint32_t mouse_buf32[256]; > +static uint16_t mouse_buf16[256]; > +#endif > +#endif > + > static void > vga_nop(scr_stat *scp, ...) > { > @@ -359,8 +390,8 @@ > yoffset = y%scp->font_size; > for (i = 0; i < 16; ++i) { > cursor[i + yoffset] = > - (cursor[i + yoffset] & ~(mouse_and_mask[i] >> xoffset)) > - | (mouse_or_mask[i] >> xoffset); > + (cursor[i + yoffset] & ~(mouse_and_mask[i] >> xoffset)) > + | (mouse_or_mask[i] >> xoffset); > } > for (i = 0; i < scp->font_size; ++i) { > font_buf[i] = (cursor[i] & 0xff00) >> 8; > @@ -431,7 +462,29 @@ > /* pixel (raster text) mode renderer */ > > static void > -vga_pxlclear(scr_stat *scp, int c, int attr) > +vga_pxlclear_direct(scr_stat *scp, int c, int attr) > +{ > + vm_offset_t p; > + int line_width; > + int pixel_size; > + int lines; > + int i; > + > + line_width = scp->sc->adp->va_line_width; > + pixel_size = scp->sc->adp->va_info.vi_pixel_size; > + lines = scp->ysize * scp->font_size; > + p = scp->sc->adp->va_window + > + line_width * scp->yoff * scp->font_size + > + scp->xoff * 8 * pixel_size; > + > + for (i = 0; i < lines; ++i) { > + bzero_io((void *)p, scp->xsize * 8 * pixel_size); > + p += line_width; > + } > +} > + > +static void > +vga_pxlclear_planar(scr_stat *scp, int c, int attr) > { > vm_offset_t p; > int line_width; > @@ -457,7 +510,121 @@ > } > > static void > -vga_pxlborder(scr_stat *scp, int color) > +vga_pxlclear(scr_stat *scp, int c, int attr) > +{ > + switch (scp->sc->adp->va_info.vi_mem_model) { > + case V_INFO_MM_DIRECT: > + vga_pxlclear_direct(scp, c, attr); > + break; > + case V_INFO_MM_PLANAR: > + vga_pxlclear_planar(scp, c, attr); > + break; > + } > +} > + > +static void > +vga_pxlborder_direct(scr_stat *scp, int color, int bpp) > +{ > + vm_offset_t s; > + vm_offset_t e; > + vm_offset_t f; > + int line_width; > + int pixel_size; > + int x; > + int y; > + int i; > + > + line_width = scp->sc->adp->va_line_width; > + pixel_size = scp->sc->adp->va_info.vi_pixel_size; > + > + if (scp->yoff > 0) { > + s = scp->sc->adp->va_window; > + e = s + line_width * scp->yoff * scp->font_size; > + > + for (f = s; f < e; f += pixel_size) { > + switch (bpp) { > + case 32: > + writel(f, vga_palette32[color]); > + break; > + case 16: > + writew(f, vga_palette16[color]); > + break; > + case 15: > + writew(f, vga_palette15[color]); > + break; > + } > + } > + } > + > + y = (scp->yoff + scp->ysize) * scp->font_size; > + > + if (scp->ypixel > y) { > + s = scp->sc->adp->va_window + line_width * y; > + e = s + line_width * (scp->ypixel - y); > + > + for (f = s; f < e; f += pixel_size) { > + switch (bpp) { > + case 32: > + writel(f, vga_palette32[color]); > + break; > + case 16: > + writew(f, vga_palette16[color]); > + break; > + case 15: > + writew(f, vga_palette15[color]); > + break; > + } > + } > + } > + > + y = scp->yoff * scp->font_size; > + x = scp->xpixel / 8 - scp->xoff - scp->xsize; > + > + for (i = 0; i < scp->ysize * scp->font_size; ++i) { > + if (scp->xoff > 0) { > + s = scp->sc->adp->va_window + line_width * (y + i); > + e = s + scp->xoff * 8 * pixel_size; > + > + for (f = s; f < e; f += pixel_size) { > + switch (bpp) { > + case 32: > + writel(f, vga_palette32[color]); > + break; > + case 16: > + writew(f, vga_palette16[color]); > + break; > + case 15: > + writew(f, vga_palette15[color]); > + break; > + } > + } > + } > + > + if (x > 0) { > + s = scp->sc->adp->va_window + line_width * (y + i) + > + scp->xoff * 8 * pixel_size + > + scp->xsize * 8 * pixel_size; > + e = s + x * 8 * pixel_size; > + > + for (f = s; f < e; f += pixel_size) { > + switch (bpp) { > + case 32: > + writel(f, vga_palette32[color]); > + break; > + case 16: > + writew(f, vga_palette16[color]); > + break; > + case 15: > + writew(f, vga_palette15[color]); > + break; > + } > + } > + } > + } > +} > + > +static void > +vga_pxlborder_planar(scr_stat *scp, int color) > { > vm_offset_t p; > int line_width; > @@ -492,6 +659,27 @@ > outw(GDCIDX, 0x0001); /* set/reset enable */ > } > > +static void > +vga_pxlborder(scr_stat *scp, int color) > +{ > + int bpp; > + > + switch (scp->sc->adp->va_info.vi_mem_model) { > + case V_INFO_MM_DIRECT: > + bpp = scp->sc->adp->va_info.vi_depth; > + > + if ((bpp == 16) && > + (scp->sc->adp->va_info.vi_pixel_fsizes[1] == 5)) > + bpp = 15; > + > + vga_pxlborder_direct(scp, color, bpp); > + break; > + case V_INFO_MM_PLANAR: > + vga_pxlborder_planar(scp, color); > + break; > + } > +} > + > static void > vga_egadraw(scr_stat *scp, int from, int count, int flip) > { > @@ -506,11 +694,7 @@ > u_char c; > > line_width = scp->sc->adp->va_line_width; > - d = scp->sc->adp->va_window > - + scp->xoff > - + scp->yoff*scp->font_size*line_width > - + (from%scp->xsize) > - + scp->font_size*line_width*(from/scp->xsize); > + d = VIDEO_MEMORY_POS(scp, from, 1); > > outw(GDCIDX, 0x0005); /* read mode 0, write mode 0 */ > outw(GDCIDX, 0x0003); /* data rotate/function select */ > @@ -541,7 +725,7 @@ > f = &(scp->font[sc_vtb_getc(&scp->vtb, i)*scp->font_size]); > for (j = 0; j < scp->font_size; ++j, ++f) { > outw(GDCIDX, (*f << 8) | 0x08); /* bit mask */ > - writeb(e, 0); > + writeb(e, 0); > e += line_width; > } > ++d; > @@ -554,8 +738,87 @@ > outw(GDCIDX, 0xff08); /* bit mask */ > } > > -static void > -vga_vgadraw(scr_stat *scp, int from, int count, int flip) > +static void > +vga_vgadraw_direct(scr_stat *scp, int from, int count, int flip, int bpp) > +{ > + vm_offset_t d = 0; > + vm_offset_t e; > + u_char *f; > + u_short col1, col2, idx; > + int line_width; > + int i, j, k; > + int a; > + > + line_width = scp->sc->adp->va_line_width; > + > + switch (bpp) { > + case 32: > + d = VIDEO_MEMORY_POS(scp, from, 32); > + break; > + case 16: > + /* FALLTHROUGH */ > + case 15: > + d = VIDEO_MEMORY_POS(scp, from, 16); > + break; > + } > + > + if (from + count > scp->xsize * scp->ysize) > + count = scp->xsize * scp->ysize - from; > + > + for (i = from; count-- > 0; ++i) { > + a = sc_vtb_geta(&scp->vtb, i); > + > + if (flip) { > + col1 = (((a & 0x7000) >> 4) | (a & 0x0800)) >> 8; > + col2 = (((a & 0x8000) >> 4) | (a & 0x0700)) >> 8; > + } else { > + col1 = (a & 0x0f00) >> 8; > + col2 = (a & 0xf000) >> 12; > + } > + > + e = d; > + f = &(scp->font[sc_vtb_getc(&scp->vtb, i) * scp->font_size]); > + > + for (j = 0; j < scp->font_size; ++j, ++f) { > + for (k = 7; k >= 0; --k) { > + idx = *f & (1 << (7 - k)) ? > + col1 : col2; > + > + switch (bpp) { > + case 32: > + writel(e + 4 * k, vga_palette32[idx]); > + break; > + case 16: > + writew(e + 2 * k, vga_palette16[idx]); > + break; > + case 15: > + writew(e + 2 * k, vga_palette15[idx]); > + break; > + } > + } > + > + e += line_width; > + } > + > + switch (bpp) { > + case 32: > + d += 32; > + break; > + case 16: > + /* FALLTHROUGH */ > + case 15: > + d += 16; > + break; > + } > + > + if ((i % scp->xsize) == scp->xsize - 1) > + d += scp->xoff * 16 * scp->sc->adp->va_info.vi_pixel_size + > + (scp->font_size - 1) * line_width; > + } > +} > + > +static void > +vga_vgadraw_planar(scr_stat *scp, int from, int count, int flip) > { > vm_offset_t d; > vm_offset_t e; > @@ -568,11 +831,7 @@ > u_char c; > > line_width = scp->sc->adp->va_line_width; > - d = scp->sc->adp->va_window > - + scp->xoff > - + scp->yoff*scp->font_size*line_width > - + (from%scp->xsize) > - + scp->font_size*line_width*(from/scp->xsize); > + d = VIDEO_MEMORY_POS(scp, from, 1); > > outw(GDCIDX, 0x0305); /* read mode 0, write mode 3 */ > outw(GDCIDX, 0x0003); /* data rotate/function select */ > @@ -604,7 +863,7 @@ > e = d; > f = &(scp->font[sc_vtb_getc(&scp->vtb, i)*scp->font_size]); > for (j = 0; j < scp->font_size; ++j, ++f) { > - writeb(e, *f); > + writeb(e, *f); > e += line_width; > } > ++d; > @@ -617,6 +876,27 @@ > outw(GDCIDX, 0x0001); /* set/reset enable */ > } > > +static void > +vga_vgadraw(scr_stat *scp, int from, int count, int flip) > +{ > + int bpp; > + > + switch (scp->sc->adp->va_info.vi_mem_model) { > + case V_INFO_MM_DIRECT: > + bpp = scp->sc->adp->va_info.vi_depth; > + > + if ((bpp == 16) && > + (scp->sc->adp->va_info.vi_pixel_fsizes[1] == 5)) > + bpp = 15; > + > + vga_vgadraw_direct(scp, from, count, flip, bpp); > + break; > + case V_INFO_MM_PLANAR: > + vga_vgadraw_planar(scp, from, count, flip); > + break; > + } > +} > + > static void > vga_pxlcursor_shape(scr_stat *scp, int base, int height, int blink) > { > @@ -629,8 +909,70 @@ > #endif > } > > -static void > -draw_pxlcursor(scr_stat *scp, int at, int on, int flip) > +static void > +draw_pxlcursor_direct(scr_stat *scp, int at, int on, int flip, int bpp) > +{ > + vm_offset_t d = 0; > + u_char *f; > + int line_width; > + int height; > + int col1, col2, idx; > + int a; > + int i, j; > + > + line_width = scp->sc->adp->va_line_width; > + > + switch (bpp) { > + case 32: > + d = VIDEO_MEMORY_POS(scp, at, 32) + > + (scp->font_size - scp->curs_attr.base - 1) * line_width; > + break; > + case 16: > + /* FALLTHROUGH */ > + case 15: > + d = VIDEO_MEMORY_POS(scp, at, 16) + > + (scp->font_size - scp->curs_attr.base - 1) * line_width; > + break; > + } > + > + a = sc_vtb_geta(&scp->vtb, at); > + > + if (flip) { > + col1 = ((on) ? (a & 0x0f00) : ((a & 0xf000) >> 4)) >> 8; > + col2 = ((on) ? ((a & 0xf000) >> 4) : (a & 0x0f00)) >> 8; > + } else { > + col1 = ((on) ? ((a & 0xf000) >> 4) : (a & 0x0f00)) >> 8; > + col2 = ((on) ? (a & 0x0f00) : ((a & 0xf000) >> 4)) >> 8; > + } > + > + f = &(scp->font[sc_vtb_getc(&scp->vtb, at) * scp->font_size + > + scp->font_size - scp->curs_attr.base - 1]); > + > + height = imin(scp->curs_attr.height, scp->font_size); > + > + for (i = 0; i < height; ++i, --f) { > + for (j = 7; j >= 0; --j) { > + idx = *f & (1 << (7 - j)) ? col1 : col2; > + > + switch (bpp) { > + case 32: > + writel(d + 4 * j, vga_palette32[idx]); > + break; > + case 16: > + writew(d + 2 * j, vga_palette16[idx]); > + break; > + case 15: > + writew(d + 2 * j, vga_palette15[idx]); > + break; > + } > + } > + > + d -= line_width; > + } > +} > + > +static void > +draw_pxlcursor_planar(scr_stat *scp, int at, int on, int flip) > { > vm_offset_t d; > u_char *f; > @@ -642,12 +984,8 @@ > u_char c; > > line_width = scp->sc->adp->va_line_width; > - d = scp->sc->adp->va_window > - + scp->xoff > - + scp->yoff*scp->font_size*line_width > - + (at%scp->xsize) > - + scp->font_size*line_width*(at/scp->xsize) > - + (scp->font_size - scp->curs_attr.base - 1)*line_width; > + d = VIDEO_MEMORY_POS(scp, at, 1) + > + (scp->font_size - scp->curs_attr.base - 1) * line_width; > > outw(GDCIDX, 0x0005); /* read mode 0, write mode 0 */ > outw(GDCIDX, 0x0003); /* data rotate/function select */ > @@ -673,7 +1011,7 @@ > height = imin(scp->curs_attr.height, scp->font_size); > for (i = 0; i < height; ++i, --f) { > outw(GDCIDX, (*f << 8) | 0x08); /* bit mask */ > - writeb(d, 0); > + writeb(d, 0); > d -= line_width; > } > outw(GDCIDX, 0x0000); /* set/reset */ > @@ -681,6 +1019,27 @@ > outw(GDCIDX, 0xff08); /* bit mask */ > } > > +static void > +draw_pxlcursor(scr_stat *scp, int at, int on, int flip) > +{ > + int bpp; > + > + switch (scp->sc->adp->va_info.vi_mem_model) { > + case V_INFO_MM_DIRECT: > + bpp = scp->sc->adp->va_info.vi_depth; > + > + if ((bpp == 16) && > + (scp->sc->adp->va_info.vi_pixel_fsizes[1] == 5)) > + bpp = 15; > + > + draw_pxlcursor_direct(scp, at, on, flip, bpp); > + break; > + case V_INFO_MM_PLANAR: > + draw_pxlcursor_planar(scp, at, on, flip); > + break; > + } > +} > + > static int pxlblinkrate = 0; > > static void > @@ -726,7 +1085,87 @@ > #ifndef SC_NO_CUTPASTE > > static void > -draw_pxlmouse(scr_stat *scp, int x, int y) > +draw_pxlmouse_direct(scr_stat *scp, int x, int y, int bpp) > +{ > + vm_offset_t p; > + int line_width, pixel_size; > + int xend, yend; > + static int x_old = 0, xend_old = 0; > + static int y_old = 0, yend_old = 0; > + int i, j; > + uint32_t *u32; > + uint16_t *u16; > + > + line_width = scp->sc->adp->va_line_width; > + pixel_size = scp->sc->adp->va_info.vi_pixel_size; > + > + xend = imin(x + 16, scp->xpixel); > + yend = imin(y + 16, scp->ypixel); > + > + p = scp->sc->adp->va_window + y_old * line_width + x_old * pixel_size; > + > + for (i = 0; i < (yend_old - y_old); i++) { > + for (j = (xend_old - x_old - 1); j >= 0; j--) { > + switch (bpp) { > + case 32: > + u32 = (uint32_t*)(p + j * pixel_size); > + writel(u32, mouse_buf32[i * 16 + j]); > + break; > + case 16: > + /* FALLTHROUGH */ > + case 15: > + u16 = (uint16_t*)(p + j * pixel_size); > + writew(u16, mouse_buf16[i * 16 + j]); > + break; > + } > + } > + > + p += line_width; > + } > + > + p = scp->sc->adp->va_window + y * line_width + x * pixel_size; > + > + for (i = 0; i < (yend - y); i++) { > + for (j = (xend - x - 1); j >= 0; j--) { > + switch (bpp) { > + case 32: > + u32 = (uint32_t*)(p + j * pixel_size); > + mouse_buf32[i * 16 + j] = *u32; > + if (mouse_or_mask[i] & (1 << (15 - j))) > + writel(u32, vga_palette32[15]); > + else if (mouse_and_mask[i] & (1 << (15 - j))) > + writel(u32, 0); > + break; > + case 16: > + u16 = (uint16_t*)(p + j * pixel_size); > + mouse_buf16[i * 16 + j] = *u16; > + if (mouse_or_mask[i] & (1 << (15 - j))) > + writew(u16, vga_palette16[15]); > + else if (mouse_and_mask[i] & (1 << (15 - j))) > + writew(u16, 0); > + break; > + case 15: > + u16 = (uint16_t*)(p + j * pixel_size); > + mouse_buf16[i * 16 + j] = *u16; > + if (mouse_or_mask[i] & (1 << (15 - j))) > + writew(u16, vga_palette15[15]); > + else if (mouse_and_mask[i] & (1 << (15 - j))) > + writew(u16, 0); > + break; > + } > + } > + > + p += line_width; > + } > + > + x_old = x; > + y_old = y; > + xend_old = xend; > + yend_old = yend; > +} > + > +static void > +draw_pxlmouse_planar(scr_stat *scp, int x, int y) > { > vm_offset_t p; > int line_width; > @@ -801,7 +1240,28 @@ > } > > static void > -remove_pxlmouse(scr_stat *scp, int x, int y) > +draw_pxlmouse(scr_stat *scp, int x, int y) > +{ > + int bpp; > + > + switch (scp->sc->adp->va_info.vi_mem_model) { > + case V_INFO_MM_DIRECT: > + bpp = scp->sc->adp->va_info.vi_depth; > + > + if ((bpp == 16) && > + (scp->sc->adp->va_info.vi_pixel_fsizes[1] == 5)) > + bpp = 15; > + > + draw_pxlmouse_direct(scp, x, y, bpp); > + break; > + case V_INFO_MM_PLANAR: > + draw_pxlmouse_planar(scp, x, y); > + break; > + } > +} > + > +static void > +remove_pxlmouse_planar(scr_stat *scp, int x, int y) > { > vm_offset_t p; > int col, row; > @@ -857,6 +1317,18 @@ > outw(GDCIDX, 0x0001); /* set/reset enable */ > } > > +static void > +remove_pxlmouse(scr_stat *scp, int x, int y) > +{ > + switch (scp->sc->adp->va_info.vi_mem_model) { > + case V_INFO_MM_PLANAR: > + remove_pxlmouse_planar(scp, x, y); > + break; > + default: > + break; > + } > +} > + > static void > vga_pxlmouse(scr_stat *scp, int x, int y, int on) > { > > Cyrille Lefevre -- =========================================================================== Patrick Hurrelmann | "Programming today is a race between software Mannheim, Germany | engineers striving to build bigger and better | idiot-proof programs, and the Universe trying outi at bytephobia.de | to produce bigger and better idiots. So far, www.bytephobia.de | the Universe is winning." - Rich Cook From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 07:17:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBD3616A4CE for ; Mon, 30 Aug 2004 07:17:21 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A79243D45 for ; Mon, 30 Aug 2004 07:17:21 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i7U7JtKr001466 for ; Mon, 30 Aug 2004 00:19:55 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i7U7JtYv001465 for current@freebsd.org; Mon, 30 Aug 2004 00:19:55 -0700 Date: Mon, 30 Aug 2004 00:19:55 -0700 From: Brooks Davis To: current@freebsd.org Message-ID: <20040830071955.GC28061@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="96YOpH+ONegL0A3E" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Subject: HEADS-UP: network interface modules need recompile X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 07:17:21 -0000 --96YOpH+ONegL0A3E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable With the following change, all network interface modules as well as most applcations that monitor network interface statistics will need to be recompiled since struct if_data has grown. -- Brooks ----- Forwarded message from Brooks Davis ----- From: Brooks Davis Date: Mon, 30 Aug 2004 06:29:26 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org X-Virus-Status: No Subject: cvs commit: src UPDATING src/sys/sys param.h src/sys/net if.c if.h brooks 2004-08-30 06:29:26 UTC FreeBSD src repository Modified files: . UPDATING=20 sys/sys param.h=20 sys/net if.c if.h=20 Log: Add a new variable, ifi_epoch, to struct if_data. It is set to the last time the interface counters were zeroed, currently the time if_attach() was called. It is indentended to be a valid value for RFC2233's ifCounterDiscontinuityTime and to make it easier for applications to verify that the interface they find at a given index is the one that was there last time they looked. =20 An if_epoch "compatability" macro has not been created as ifi_epoch has never been a member of struct ifnet. =20 Approved by: andre, bms, wollman =20 Revision Changes Path 1.352 +5 -0 src/UPDATING 1.201 +1 -0 src/sys/net/if.c 1.89 +1 -0 src/sys/net/if.h 1.214 +1 -1 src/sys/sys/param.h ----- End forwarded message ----- --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --96YOpH+ONegL0A3E Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBMtUaXY6L6fI4GtQRAipfAKDn6OR0bMWf6kOvDjxjbJDAet+fiwCcD+3y ahyVpGwtmsjf8FojjlFno9s= =KgQ/ -----END PGP SIGNATURE----- --96YOpH+ONegL0A3E-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 07:22:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A779516A4CE for ; Mon, 30 Aug 2004 07:22:46 +0000 (GMT) Received: from gvr.gvr.org (gvr-gw.gvr.org [80.126.103.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5524E43D5A for ; Mon, 30 Aug 2004 07:22:46 +0000 (GMT) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id 9F32738; Mon, 30 Aug 2004 09:22:45 +0200 (CEST) Date: Mon, 30 Aug 2004 09:22:45 +0200 From: Guido van Rooij To: Daniel O'Connor Message-ID: <20040830072245.GA12692@gvr.gvr.org> References: <20040827082929.GA64830@gvr.gvr.org> <200408280201.10816.doconnor@gsoft.com.au> <20040829191558.GA4616@gvr.gvr.org> <200408300837.08339.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408300837.08339.doconnor@gsoft.com.au> cc: freebsd-current@freebsd.org Subject: Re: project evil: signal quality X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 07:22:46 -0000 On Mon, Aug 30, 2004 at 08:37:08AM +0930, Daniel O'Connor wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mon, 30 Aug 2004 04:45, Guido van Rooij wrote: > > Thanks, The reason I asked is because I normally use wicontrol -i ndis0: > > ... > > Comms quality/signal/noise: [ 0 0 0 ] > > ... > > > > As you see, in that screen, it appears comms quality is unavailable.. > > Ahh strange.. > It works fine here (Intel Pro 2100). > > Are newer drivers available? > Given that your ndis0 -l option for wicontrol works here, I doubt that this is a driver issue. I'll try to find time to look why -i ndis0 fails to report the quality.. -Guido From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 07:28:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13F1916A4CE for ; Mon, 30 Aug 2004 07:28:11 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5597A43D45 for ; Mon, 30 Aug 2004 07:28:10 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7U7S65Z060105 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Aug 2004 10:28:07 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i7U7SBb6084955 for current@FreeBSD.org; Mon, 30 Aug 2004 10:28:12 +0300 (EEST) (envelope-from ru) Date: Mon, 30 Aug 2004 10:28:11 +0300 From: Ruslan Ermilov To: current@FreeBSD.org Message-ID: <20040830072811.GA84862@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new Subject: [PATCH] Finding stale files in /usr/src during "make update" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 07:28:11 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable What do you people think about the following patch? It can be very useful to find stale files under /usr/src which may sometimes be unsafe. %%% Index: Makefile.inc1 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/Makefile.inc1,v retrieving revision 1.442 diff -u -r1.442 Makefile.inc1 --- Makefile.inc1 25 Aug 2004 22:06:29 -0000 1.442 +++ Makefile.inc1 30 Aug 2004 07:17:37 -0000 @@ -83,7 +83,7 @@ .endif =20 CVS?=3D cvs -CVSFLAGS?=3D -A -P -d +CVSFLAGS?=3D -A -P -d -I! -ICVS .if defined(CVSTAG) CVSFLAGS+=3D -r ${CVSTAG} .endif %%% Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBMtcLqRfpzJluFF4RAqx4AKCVD19FDH0+Af9Y3/TJYbOK66qbGgCgiMIH WYKjSw0K8vqgFgqyEuihGA4= =vbPo -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 07:31:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F85116A4CE for ; Mon, 30 Aug 2004 07:31:19 +0000 (GMT) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 951F743D5A for ; Mon, 30 Aug 2004 07:31:15 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from midget.dons.net.au ([150.101.45.33])i7U7VAHY054929; Mon, 30 Aug 2004 17:01:12 +0930 (CST) Received: from inchoate.gsoft.com.au (root@localhost.dons.net.au [127.0.0.1]) by midget.dons.net.au (8.12.9/8.12.10) with ESMTP id i7U7V7n7066605; Mon, 30 Aug 2004 17:01:08 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Guido van Rooij Date: Mon, 30 Aug 2004 17:01:07 +0930 User-Agent: KMail/1.6.2 References: <20040827082929.GA64830@gvr.gvr.org> <200408300837.08339.doconnor@gsoft.com.au> <20040830072245.GA12692@gvr.gvr.org> In-Reply-To: <20040830072245.GA12692@gvr.gvr.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200408301701.07731.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.26 (www . roaringpenguin . com / mimedefang) cc: freebsd-current@freebsd.org Subject: Re: project evil: signal quality X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 07:31:19 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 30 Aug 2004 16:52, Guido van Rooij wrote: > > Ahh strange.. > > It works fine here (Intel Pro 2100). > > > > Are newer drivers available? > > Given that your ndis0 -l option for wicontrol works here, I doubt that th= is > is a driver issue. I'll try to find time to look why -i ndis0 fails > to report the quality.. Why do you say that? I am talking about the Windows driver - perhaps it doesn't report signal=20 quality in a standard way. =2D --=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBMte75ZPcIHs/zowRApEaAJ9HL/iw1UZFrZ6cfGIkrApPpwlUCQCgjqm6 rVParApRRNu/xB4Dy/ZaSfI=3D =3DABXZ =2D----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 07:37:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBA7B16A4CF; Mon, 30 Aug 2004 07:37:07 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E65943D49; Mon, 30 Aug 2004 07:37:07 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smtp3.sentex.ca (8.13.1/8.13.1) with ESMTP id i7U7b5Yr003801; Mon, 30 Aug 2004 03:37:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7U7b7cG012227; Mon, 30 Aug 2004 03:37:07 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C33D87303F; Mon, 30 Aug 2004 03:37:06 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040830073706.C33D87303F@freebsd-current.sentex.ca> Date: Mon, 30 Aug 2004 03:37:06 -0400 (EDT) Subject: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 07:37:07 -0000 TB --- 2004-08-30 05:32:12 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-30 05:32:12 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2004-08-30 05:32:12 - checking out the source tree TB --- 2004-08-30 05:32:12 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2004-08-30 05:32:12 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-30 05:35:52 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-30 05:35:52 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2004-08-30 05:35:52 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-30 07:02:25 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-30 07:02:25 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2004-08-30 07:02:25 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Aug 30 07:02:26 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Mon Aug 30 07:26:30 UTC 2004 TB --- 2004-08-30 07:26:30 - generating LINT kernel config TB --- 2004-08-30 07:26:30 - cd /home/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf TB --- 2004-08-30 07:26:30 - /usr/bin/make -B LINT TB --- 2004-08-30 07:26:30 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-30 07:26:30 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2004-08-30 07:26:30 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Aug 30 07:26:31 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -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 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/kern/md5c.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -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 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/kern/sched_4bsd.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -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 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/kern/subr_autoconf.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -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 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/kern/subr_blist.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -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 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/kern/subr_bus.c /tinderbox/CURRENT/ia64/ia64/src/sys/kern/subr_bus.c: In function `print_device_short': /tinderbox/CURRENT/ia64/ia64/src/sys/kern/subr_bus.c:3555: warning: int format, pointer arg (arg 12) /tinderbox/CURRENT/ia64/ia64/src/sys/kern/subr_bus.c:3555: warning: too many arguments for format *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2004-08-30 07:37:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-30 07:37:06 - ERROR: failed to build lint kernel TB --- 2004-08-30 07:37:06 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 08:41:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0368916A4CE for ; Mon, 30 Aug 2004 08:41:39 +0000 (GMT) Received: from hanoi.cronyx.ru (hanoi.cronyx.ru [144.206.181.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4385043D41 for ; Mon, 30 Aug 2004 08:41:38 +0000 (GMT) (envelope-from rik@cronyx.ru) Received: (from root@localhost) by hanoi.cronyx.ru id i7U8cV6Q030047 for current@freebsd.org.checked; (8.12.8/vak/2.1) Mon, 30 Aug 2004 12:38:31 +0400 (MSD) (envelope-from rik@cronyx.ru) Received: from cronyx.ru (hi.cronyx.ru [144.206.181.94]) by hanoi.cronyx.ru with ESMTP id i7U8bg7j029941; (8.12.8/vak/2.1) Mon, 30 Aug 2004 12:37:42 +0400 (MSD) (envelope-from rik@cronyx.ru) Message-ID: <4132E7B6.6010900@cronyx.ru> Date: Mon, 30 Aug 2004 12:39:18 +0400 From: Roman Kurakin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <412D02FE.2080805@root.org> <412F141E.5070102@cronyx.ru> <412F6283.7000900@root.org> <412F692D.7090007@cronyx.ru> <412FAAB2.3000407@root.org> In-Reply-To: <412FAAB2.3000407@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org cc: John Baldwin Subject: Re: Bug reports requested - acpi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 08:41:39 -0000 Nate Lawson wrote: > Roman Kurakin wrote: > >> Nate Lawson wrote: >> >>> Roman Kurakin wrote: >>> >>>> You want it: >>>> >>>> http://docs.freebsd.org/cgi/getmsg.cgi?fetch=2624308+0+/usr/local/www/db/text/2004/freebsd-current/20040822.freebsd-current >>>> >>>> >>>> It seems that problems I have due to acpi code update between >>>> 2004-08-13 and 2004-08-14. >>>> I'll check tomorrow that I didn't mix up sources. >>>> >>>> I've just applied changes in vm code that was made while 13-14, and >>>> after >>>> restart I was able to log in to buggy system. So vm is not the >>>> place of problems. >>>> The only unapplied patch is a acpi changes. >>> >>> Does booting without ACPI fix the problem? >> >> No. Only safe mode. As I understand it also turn off MP. > > > Safe mode disables the APIC in addition to ACPI. Since disabling ACPI > alone doesn't fix your problem, I doubt I can be much more help right > now since I'm not an APIC expert. Why don't you try booting with APIC > disabled but ACPI still active and see how things work? > > set hint.apic.0.disabled="1" at the loader prompt I was unaware of all that safe mode turns off, and than I last time check this I ovelooked that apic is also disabled. It seems that problem with APIC. But could you tell me how changes in ACPICA affect APIC code? rik >> Again, if I set break point at install_ap_tramp this function start >> to work correctly. >> (No trap at write access). And panic occures from other place (And I >> unable to fix >> it by debugging ;-)) in mp_machdep.c. >> >> Now I'll try to understan what part of that ACPI commit I could leave >> and which to >> backout to minimize search area. > > -Nate > _______________________________________________ > 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 Aug 30 08:42:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 899E916A4CF for ; Mon, 30 Aug 2004 08:42:13 +0000 (GMT) Received: from web.portaone.com (mail.russia.cz [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E6FD43D39 for ; Mon, 30 Aug 2004 08:42:12 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.20] (portacare.portaone.com [195.140.247.242]) (authenticated bits=0) by web.portaone.com (8.12.8p2/8.12.8) with ESMTP id i7U8g2Ej052630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Aug 2004 10:42:03 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <4132E84C.9060200@portaone.com> Date: Mon, 30 Aug 2004 11:41:48 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: vova@fbsd.ru References: <080a01c48dff$4248a310$7890a8c0@gits.invalid> <4132358C.6060108@portaone.com> <1093849339.864.5.camel@localhost> In-Reply-To: <1093849339.864.5.camel@localhost> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Cyrille Lefevre cc: Deng XueFeng cc: "current@freebsd.org" Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support forFreeBSD-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 08:42:13 -0000 I think that you have to recompile your kernel with option VESA *and* option SC_PIXEL_MODE. -Maxim Vladimir Grebenschikov wrote: > On Sun, 2004-08-29 at 22:59 +0300, Maxim Sobolev wrote: > > >>vidcontrol -i mode is your best friend! ;-) > > > Yes, it shows some corresponding graphical modes: > # kldload vesa > # vidcontrol -i mode < /dev/ttyv1 | fgrep 1400x1050 > 320 (0x140) 0x0000000f G 1400x1050x8 1 8x16 0xa0000 64k 64k > 0xd8000000 16384k > 321 (0x141) 0x0000000f G 1400x1050x15 1 8x16 0xa0000 64k 64k > 0xd8000000 16384k > 322 (0x142) 0x0000000f G 1400x1050x16 1 8x16 0xa0000 64k 64k > 0xd8000000 16384k > 323 (0x143) 0x0000000f G 1400x1050x24 1 8x16 0xa0000 64k 64k > 0xd8000000 16384k > 324 (0x144) 0x0000000f G 1400x1050x32 1 8x16 0xa0000 64k 64k > 0xd8000000 16384k > > but anyway there are a little text modes: > # vidcontrol -i mode < /dev/ttyv1 | fgrep T > 24 (0x018) 0x00000001 T 80x25 8x16 0xb8000 32k 32k > 0x00000000 32k > 30 (0x01e) 0x00000001 T 80x50 8x8 0xb8000 32k 32k > 0x00000000 32k > 32 (0x020) 0x00000001 T 80x30 8x16 0xb8000 32k 32k > 0x00000000 32k > 34 (0x022) 0x00000001 T 80x60 8x8 0xb8000 32k 32k > 0x00000000 32k > > And the all standard VGA modes, > > and I can't switch to text mode based 1400x1050 resolution (all Ok with > Xorg server, I talk only about syscons in high resolution, text or > raster) > > # vidcontrol VESA_800x600 < /dev/ttyv1 > vidcontrol: cannot set videomode: Operation not supported by device > usage: vidcontrol [-CdHLPpx] [-b color] [-c appearance] [-f [size] file] > [-g geometry] [-h size] [-i adapter | mode] [-l > screen_map] > [-M char] [-m on | off] [-r foreground background] > [-S on | off] [-s number] [-t N | off] [mode] > [foreground [background]] [show] > # vidcontrol VESA_1400x1050 < /dev/ttyv1 > usage: vidcontrol [-CdHLPpx] [-b color] [-c appearance] [-f [size] file] > [-g geometry] [-h size] [-i adapter | mode] [-l > screen_map] > [-M char] [-m on | off] [-r foreground background] > [-S on | off] [-s number] [-t N | off] [mode] > [foreground [background]] [show] > > >>-Maxim > > From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 08:45:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6C4116A4CE for ; Mon, 30 Aug 2004 08:45:33 +0000 (GMT) Received: from hotmail.com (bay11-dav27.bay11.hotmail.com [64.4.39.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E90243D2D for ; Mon, 30 Aug 2004 08:45:33 +0000 (GMT) (envelope-from dsnofe@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 30 Aug 2004 01:45:33 -0700 Received: from 218.80.194.83 by bay11-dav27.bay11.hotmail.com with DAV; Mon, 30 Aug 2004 08:45:33 +0000 X-Originating-IP: [218.80.194.83] X-Originating-Email: [dsnofe@msn.com] X-Sender: dsnofe@msn.com From: "Deng XueFeng" To: "Deng XueFeng" , , References: Date: Mon, 30 Aug 2004 16:45:25 +0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007F_01C48EB0.BFBD0280" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 30 Aug 2004 08:45:33.0492 (UTC) FILETIME=[B6568740:01C48E6D] cc: cyrille.lefevre@laposte.net cc: current@freebsd.org Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 08:45:33 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_007F_01C48EB0.BFBD0280 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkRlbmcgWHVlRmVuZyIgPGRz bm9mZUBtc24uY29tPg0KVG86IDxhcGVpcm9uQGNvbWNhc3QubmV0PjsgPG91dGlAYnl0ZXBob2Jp YS5kZT4NCkNjOiA8Y3lyaWxsZS5sZWZldnJlQGxhcG9zdGUubmV0PjsgPGN1cnJlbnRAZnJlZWJz ZC5vcmc+DQpTZW50OiBNb25kYXksIEF1Z3VzdCAzMCwgMjAwNCAxMDoxMiBBTQ0KU3ViamVjdDog UmU6IFtQQVRDSCBUTyBURVNUXSBWRVNBIFsxMDI0eDc2OF0gbW9kZSBzdXBwb3J0IGZvciBGcmVl QlNELUNVUlJFTlQNCg0KDQo+SSBzb3JyeS4gSSBtYWRlIGEgbWlzdGFrZSB3aGVuIEkgdXBsb2Fk IHRoZSBwYXRjaGZpbGUgdXNlaW5nIElFLg0KISEhISENClRoZSBzYW1lIGVycm9yIGFzIGJlZm9y ZS4gOi0oDQoNCj4gaGVyZSBJIHJlc2VuZCB0aCBwYXRjaC4gdHJ5IGFnYWluLg0KPiByZXBsYWNl IHZpZGNvbnRyb2wuDQo+ICNjZCAvdXNyL3NyYy91c3Iuc2Jpbi92aWRjb250cm9sDQo+ICNtYWtl IDttYWtlIGluc3RhbGw7bWFrZSBjbGVhbg0KPiANCj4gI2NkIC91c3Ivc3JjL3N5cy9kZXYvc3lz Y29ucw0KPiAjcGF0Y2ggLXAgPCBjdXJyZW50LXN5c2NvbnMuZGlmZg0KPiB0aGVuIGFkZCBWRVNB IGFuZCBQSVhFTCBzdXBwb3J0IGluIGtlcm5lbC4NCj4gDQo+IEJUVzogdGhlIG91dHB1dCBvZiAi dmlkY29udHJvbCAtaSBtb2RlIiBzaG93IHRoYXQgU1hHQSsxNDAweDEwNTAsIFdYR0EoMTI4MCAN Cj4geCA4MDApLCBXVVhHQSgxOTIwIHggMTIwMCksIFdTWEdBKDE2ODAgeCAxMDUwKSBpdCBub3Qg c3VwcG9ydGVkLm9uZSBvZiBteSANCj4gYm94IHN1cHBvcnQgMTI4MHg4MDAuIEJ1dCBJIGNhbiBv bmx5IHVzZSAxMDI0eDc2OC4gSSB3aWxsIHdvcmsgb24gdGhhdC4gIA0KPiANCj4gQUxTTzogIHRo ZSBzeXNjb25zIHBhdGNoIGlzIGNvbnRpbnVlIGRldmVsb3BtZW50IGJ5IFNhc2NoYSBXaWxkbmVy IA0KPiA8c2F3QG9ubGluZS5kZT4uDQo+IA0KPiANCj4gDQo+PkZyb206IENocmlzdG9waGVyIE5l aHJlbiA8YXBlaXJvbkBjb21jYXN0Lm5ldD4NCj4+VG86IFBhdHJpY2sgSHVycmVsbWFubiA8b3V0 aUBieXRlcGhvYmlhLmRlPg0KPj5DQzogY3lyaWxsZS5sZWZldnJlQGxhcG9zdGUubmV0LCBEZW5n IFh1ZUZlbmcgDQo+IDxkc25vZmVAbXNuLmNvbT4sY3VycmVudEBmcmVlYnNkLm9yZw0KPj5TdWJq ZWN0OiBSZTogW1BBVENIIFRPIFRFU1RdIFZFU0EgWzEwMjR4NzY4XSBtb2RlIHN1cHBvcnQgZm9y IA0KPiBGcmVlQlNELUNVUlJFTlQNCj4+RGF0ZTogU3VuLCAyOSBBdWcgMjAwNCAxMToyNToxOCAt MDQwMA0KPj5NSU1FLVZlcnNpb246IDEuMA0KPj5SZWNlaXZlZDogZnJvbSByd2NybWhjMTMuY29t Y2FzdC5uZXQgKFsyMDQuMTI3LjE5OC4zOV0pIGJ5IA0KPiBtYzgtZjI3LmhvdG1haWwuY29tIHdp dGggTWljcm9zb2Z0IFNNVFBTVkMoNS4wLjIxOTUuNjgyNCk7IFN1biwgMjkgQXVnIDIwMDQgDQo+ IDA4OjI1OjIyIC0wNzAwDQo+PlJlY2VpdmVkOiBmcm9tIHByb3BoZWN5LnZlbHVtIA0KPiAocGNw MDg0OTA1ODdwY3MubGV2dHduMDEucGEuY29tY2FzdC5uZXRbNjguODMuMTY5LjIyNF0pICAgICAg ICAgIGJ5IA0KPiBjb21jYXN0Lm5ldCAocndjcm1oYzEzKSB3aXRoIFNNVFAgICAgICAgICAgaWQg PDIwMDQwODI5MTUyNTIxMDE1MDBtYWRuN2U+ICAgDQo+ICAgICAgIChBdXRoaWQ6IGFwZWlyb25A Y29tY2FzdC5uZXQpOyAgICAgICAgICBTdW4sIDI5IEF1ZyAyMDA0IDE1OjI1OjIyIA0KPiArMDAw MA0KPj5YLU1lc3NhZ2UtSW5mbzogSkdUWW9ZRjc4akc3RVl5VGlEOVBvaG9rNnJQQStvaVQNCj4+ TWVzc2FnZS1JRDogPDIwMDQwODI5MTUyNTE4LkdBMTc2OThAcHJvcGhlY3kuZHluZG5zLm9yZz4N Cj4+UmVmZXJlbmNlczogPDIwMDQwODI4MDE0NS5pN1MxanF4bDA5NjQ2OEBtYWlsLmdpdHMuZHlu ZG5zLm9yZz4gDQo+IDw0MTMxQjBBQS42MDIwNDAyQGJ5dGVwaG9iaWEuZGU+DQo+PkluLVJlcGx5 LVRvOiA8NDEzMUIwQUEuNjAyMDQwMkBieXRlcGhvYmlhLmRlPg0KPj5YLVBsZWFzZS1DQy1NZTog SW4gTGlzdCBBbmQgR3JvdXAgUmVwbGllcw0KPj5Vc2VyLUFnZW50OiBNdXR0LzEuNS42aQ0KPj5S ZXR1cm4tUGF0aDogYXBlaXJvbkBjb21jYXN0Lm5ldA0KPj5YLU9yaWdpbmFsQXJyaXZhbFRpbWU6 IDI5IEF1ZyAyMDA0IDE1OjI1OjIyLjA2MzggKFVUQykgDQo+IEZJTEVUSU1FPVs2NjkxRjZFMDow MUM0OEREQ10NCj4+DQo+Pk9uIFN1biwgQXVnIDI5LCAyMDA0IGF0IDA2OjMyOjEwIEVEVCwgUGF0 cmljayBIdXJyZWxtYW5uIHNjcmliYmxlZCB0aGVzZQ0KPj5jdXJpb3VzIG1hcmtpbmdzOg0KPj4g PiBJIHRyaWVkIHlvdSBwYXRjaCBhbmQgaXQgYXBwbGllcyBjbGVhbmx5IHRvIDUuMy1CRVRBMSwg YnV0IGtlcm5lbGJ1aWxkDQo+PiA+IGJyZWFrcyBkdWUgdG8gc3lzY29ucy4gRG9lcyBhbnlib2R5 IGV4cGVyaWVuY2UgdGhlIHNhbWU/DQo+PiA+IFNlZSBhdHRhY2hlZCBsb2cgb2Yga2VybmVsYnVp bGQuDQo+Pg0KPj5JIHNlZSB0aGUgc2FtZSB0aGluZyBvbiA2LjAtQ1VSUkVOVC4NCj4+DQo+Pi0t DQo+PkkgYWJob3IgYSBzeXN0ZW0gZGVzaWduZWQgZm9yIHRoZSAidXNlciIsIGlmIHRoYXQgd29y ZCBpcyBhIGNvZGVkDQo+PnBlam9yYXRpdmUgbWVhbmluZyAic3R1cGlkIGFuZCB1bnNvcGhpc3Rp Y2F0ZWQiLiAgLS0gS2VuIFRob21wc29uDQo+Pi0NCj4+VW5peCBpcyB1c2VyIGZyaWVuZGx5LiBI b3dldmVyLCBpdCBpc24ndCBpZGlvdCBmcmllbmRseS4NCj4+PDwgYXR0YWNoMyA+Pg0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gw+K30c/C1NggTVNOIEV4cGxvcmVyOiAgIGh0dHA6Ly9leHBsb3Jlci5tc24u Y29tL2xjY24vICANCj4NCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCj4gX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZnJlZWJzZC1jdXJy ZW50QGZyZWVic2Qub3JnIG1haWxpbmcgbGlzdA0KPiBodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcv bWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLWN1cnJlbnQNCj4gVG8gdW5zdWJzY3JpYmUsIHNlbmQg YW55IG1haWwgdG8gImZyZWVic2QtY3VycmVudC11bnN1YnNjcmliZUBmcmVlYnNkLm9yZyINCj4= ------=_NextPart_000_007F_01C48EB0.BFBD0280 Content-Type: application/octet-stream; name="current-vesa_patch.tar.gz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="current-vesa_patch.tar.gz" H4sIAMDXLkEAA+xce3faSLLPv9an6N3ZzYINGAkE2E5yx7GdjM/6dUKSzZyZHI7QAysWEiMJG3Yn 3/1WVXeLlhAYkuzs3jvDTIzUj+rqev661cKexrEbpvV7N7EGEyu1b/effOtPs9ludk0Tvpt6t6Or 3/LzRG/qess0Wx2z/aSpt03TeMLMb85JyWeapFbM2JPZ1PXccLSy3WP1/0c/9rL+ZVEyT+woTBqO 73lfNUZTbzY77fYK/be67W5H0b/xpGk0O039CWt+ozmu/fzO9Y/KZXVQOWs09qXGo9gf7Sc22oSd Bg2bNdQ7rV6vr2u98/Z2yo6nI2Z0mKEfNtuHbbiAIKDt7e3lSeWaNg9b3cNWjzf9/ntW15tmrcP2 8Evvsu+/19jOzk7sptM4ZGdX16dn74+waBw5LnvOKvbYYU9Zc+Z5VbbHLgfvz/rHg5fH/TNqJfol 9iBx08Eotia3vp0MsHMlsSc1lsI/vKseaXs7jutZ0yA9hMsd32OV8+uT12+u393gIFX2/Dn72/u/ Vdm/sJrq/4Q06i8Su/7CcuDi3hp4gTVKgKH3g+PTm8ElsHvyw/HV67NqlXoVJ7JHpRvMZS8btEKt X8jqV+8uLga60WtW2dOnfAze4plsgUwMLo8/CBa2E8nOZxAj/IO/OPgkdu8H08SNB34Euqxqay1p ZMWhE0tLknerLEnWb2BJpU25JRmKJZnckuCrxS3pOzcEhhff2t53vgdaZ/2Twc35h7MLEpa2B9Eh 9W029cO0ZQxSBgNCmAzcNHVbxk965yNoC82gOePRrMb4leXwK8uRZZYDZdQSy3gpXvGWlmMasmzR 0jTwPyzFb8/jV54nyzz48JZYxkvxirfEWlmGH23vM5mPMie9k5+T3lmaE+de79C32eH3Zpfuh6J+ KOqHhsXvsV7MwLI4r0POfdfl913Bo8XrPWsoeOb1m/JrrufXsPm94dC92eP1Zo/Xmwdtfm85gl/j oE3jGwcm8WMMOT/APt13HV7fdXh9V/DbVfj9DuzID132/vz07HpweXZ5/ebHwc11nzvVJEpqbFZF 99z5GcZcChwPfuhED2wvazFju4xazSJwMV6u9J1jqWjhRWE6SPx/urJAJRwAU0DdSW+BiCRcAX7Y XwV97FlVRt6KpqC1r9IicfheKDzr6npw8u7tzXH/bYlrjSMIJ4Ph1APHMszOx6NlzWdNwE5FE+HA 2bfGRKf7yHc0spUwmoDo4wFWsF1SQqPRqGpgNBgc2i291mV77Y5RMw4oOOzvsok/cwNWia0kdWOW urO0SqGQATRy3BjKdvcxFqqD1ckwZ4EduFZcHBGmwGz+ZaVpDJJRWw8cP3bt9PFOaOf34wGoHGN2 yiYYmrF+oQhZQlMgxaltEnnj81SiKPD5OvVitwXFsrZ+6EWNe3+QH5fGlM3nqhlldkWkyyhKT4B6 Bp+cra0xfdl+4TO7rMd28wKBNl4Us4oPAzePmA9ZkouH7e35IrUP/+nGEeS3SgX1y3aroJKFcS9R 5WlywvaeF7TxGSKDEsjIWPLqnwRWuIHNAFusqH62pH4yarOLRm3qzZpu6GTVn1fZ6zCKwaRLB4+C qGiqm9lo8uDDWoItwyJpJWN3TEgj4LK2rQQC5uD86hVEzMvB6fmbs5O3BL/K3QQGhkFpQJL6MHat u6NlQjcXx1fHb5YJZQJfSWid0rjE1jktCo5fDieTEr8lN1QL3GKBt41nz+TF/Ld1bxzME1omZ3zB msJ5ktUeTYKmQQDcbujVAviSz3rY9Yh54LMufoHDKV4oYLm0QJS/KCLbaBmHHBw/xH7qBhVI43lQ R7r7yK1BsQfRXe+o3R8K3SEvPdLdXNvdXN39M8fgZJjwd47LhIW49pQAW10hvIWmeHZ7weaP66qo oflq5eWI14H4Hzpb1tlaCwdEJlrMuBT3IcXUlURWV/JPeRJbl2eV1JbZwizvtduYQmUOJb6YtrSI x5LuNuZQZg8Fg9jQIlSlFGxiQ6MooWCup1C0ixyFzzn7kBqZfZ0mGBfweuyz1KgUy+SVOvtDmZsr cxPksAbvcci1BdI7MHBvo2Me1AyxSxZN04fK69OT89MPYj9Crx7t7MCyBmjtxy78ZW5oDQOXVjEI DNcwuw4Y/kugDdApt4hvh/uA5DoY4rgTQi3SdSrU/jmYgtz+QgtfzQc3UA8tNPlJ/4hdTbEvxkfW TUF9BeZD4MhRHhr0liC0aAaSWDkGVVE742tad2Q5sfVQphsvjsZSS9MwFYWBP8lWvCbuqBpgMwet Gl/xkhItNLHpwL61YmYfoVHsOCCI8m0MPopOOZ5tATPrRHNFXIPaHTWFKPeYMnfz+WxXGZW3rCBX f1X3MhQKZf12qce+0uOIdjiXPcgUHgSqcfhOQLPGKFaIO3Klko4t0dGxUovFEejK3femoZ36UQj+ GIA1YVfSi9mu9dhet3VQ65W7suc1e4Le0E/Z2EruMheu56yEFnf3X2Qly7FA0Fmz4FlJbt0iyCHY UrYQEla46/Gb5DaKKejo5CcGEHWyJc/y+sivsU81didvrXxoyvKPmnweM/SWUebiIu+ANl4dX1y8 /eHN9bvXP6BC9nJZ5VEv6iz7/XZrN4HukRyka1IBQIlcflfWBzgWb/N8VRtAmkisgDGpiJOv1xGr qJDSImqD+3Q4GLmpVXlK1OC2xkGijNRkZBLdg0pxIVOpWPS8owsOU2UvXrB2lf3KRGGzB4VU2juS vQy1V6+0Vzff6zNzA1BJflzR1BP9C/R5rSep68aRgtcQGzlUgPDnaSWLMT8thGDnhbCEyD/mlkif OIr/JFF8DriDQe/teVJu1P4O2neP2B17Qf3q9bsMV4F7QOWuBxOo6OzZM1bpgkbvQB7/I/ALSeCQ vEliuS0QGqBI1obp3BWRGgy8DU5DOsYSHcBrj9AporUVdMzVdDLMJoDu0qadrHt0Tepg35bx2Nqz LEgUp0Ok9M4SKWWJAH6Y361/nvPhOqRk6k2k1FWA3inbv1/e1cH1ASt8Knl7pFGA2oa7nDJ7rAa9 6yFLHgg7R4UCl+Ngs9MlUNNr6ZBEvxbU/P+HNK1HIU3rG0Cajt7D1Umv25Ork+I2NMsZybZQ5fey AFlCYJm1CplwrLXtUmTJNcvIbrAxzuTm+jROIlDgrTVxy1Q5BG741a3rj26FLodgvXfC1VGU2AqS YJP9+iv1wASXt/cqN65WEx9yHOh6rXOwwrjqfH6StTKmLMFGFOZMK99xDfYt678R7M2h3HIoy8Uk 71YgYEsFvlvv+385NMaJAzDmO0rleYIKUIIDfMTSIG2WZo9vjayRN3TFb8sbT8RrkK6VVhU4vkC6 GdCNQsBgeeB5yCpFqNlWkWsGd0Xf5cZIQqG46KuC3iILW5BZYmEL9rnINsTIIL7Vz3NZsWKlCiWu 5t4DQ/tjP6wUGssIVIgs5dvqwg9xuVMDpC2BeIbbu4jbJQ7/lB0NK4XhnxCGsxIAvunjD0eg70/r 0PdjD0EcAZk/rYPejz0KWUHEXEVE3fB2WH2DB+VsKRCvhpHlgbwcQSqxl1JJ26jpLcglPVNuiamg 8b8HDlrpdmDQSlUoKIhsHAp31Ymtx84UcKuZs35xuP1PbL4td/XWbpmTxfR0fjrVaK7aeF+3W7fW xrdAKb8HALwKiQmrQ4lsD39XRZUC0fU78nQaYxYQgI3BuDiyK2JQNJeu0UGsqjd7Hbm5u+JgXPGU jmSUDr+VWcaMf80VzMoPyq2GrLLLOphacrSsVnb0xA2dGpvDXyxR5DIbRAFB3Rq1kXeFVvNFq3mh lYJod7JTgrtTvtWSnQncndKGyXaY9wvPuuA8JJqYQerDU6TK43qylbnSZq62mWdttEfOuwmhqHER H8KKwseOsVUyOdY5oSqU7+0VEUtltmg2E98Q8zIY86le3/hYBugEKUol7VYrE2D4U8npuAzDQJda 7sinz/eooNvjEGaTvTQwC8kT2snjPD1Upqgr9Yzpep5UMFN+6u9xRS8peVMF8wM2KxWLSv2NFLpC iQh8p9m2KCYI3hBiLSbCn/yPC1SsmxwWi1cjcjZSOHFvZpqglc2CrgXWvBXh5qNmto0JrTAbkkK2 o/sFUhBWWTij/w2kIAivlsI6R/pvEIP57xbDRv4tsxxtxshkRofklKQ3E9lRyXAiYS7vmOdT+OrF ziLrb35WpNeko+660dZrRm/FqeDYHUf37hchjkfa/p6wagGBgTBAEPMvg6gFUxC0NjmvXNDlV5qT HQU1WEU9CGMyO7QAaundmn6w6uRRc2kZtWKp9sgRpUdmtoHlfaWxKXpZKdVyzagvEy4tJMoO92wy KbkYfOTFO99R3uAUN6teuxPVG7x1V9aSXrozOouX7lr4QA4MBL/FizX44Q8xhcg57HnGaHdit1fF Hf+sUuzePWN0ImEX9xIo1YCJZm9Pnl+9P77AFVcdaYP5RGEwx6wjzma1GSqHbxMkzIpdlkwnkyhO XYd9+PABjau+xBVFC/an53SeQGGISCW8ArdSCq9w1vkE93c5SUa2LEIHvVRZZeLdamDRiYBSGKWS HwZCdSPB58NtlLgZFbDLKJ4zWqz4CQuseITvJN1aIeu0/95gL13bAmsBSmDenEDs/jKF0JORGFrh HeMO4IcjlkbMsm03SYCKC36W+igYO3bdsIFiEU+Ad9k/XIVlySn28aIgiB6QlnhvlA98KHtmFOqs 12zOOs1mphTG3YU6KM2gGrI2QFDaK8HMJdokXKw5VeXsZzdvMPs99oItGiDSHmQvoxUJZD6PIb3o 7DwOqM1VCxAbXSXv8YIFQN3Xqp9IfIXuqf/Wit+h1VRh2vKcccEz8XT6KlGXygbLxCOJDZTA0zsp QZxDKPdSnsTZckXLwBytnGNYzY8SUuSb5dKbIUBHEyEkllj3LoQVN7VRTv/pt/e//rPm9x8wykPI jaOgoX/VGOt//8HoNpd//8Fsdv74/Yff4tP4+c8a/GMLZUMottg09QM/nTPcVBhboT+ZBgBSMIBA 2BC4QYQsJ/bBJTRJ6I3r+Eka+8Mp7bFjSMf45IPrRNPYdqlk6EMCIOrjpMYgOt0yGAi/ARcSGQgH vufbFhKpUd6euPHYTzFvT+IIh3YwDBazETDm+NgpITLYcewC9MIbvVHgLmGRJ9my8TnCGKwBg4QF 7CJdawg4D6om8xgDHlGBD8Rt33Zr0ARDMhBEOouRaYp5tmBUO7D8sRs3iIixzAoMqYhFsgJzdabA 3r+JG8YnKkk5kT0dg+9bUnf7oJYIGqAVpG7sW0GyED/pDSmrE2lkloCf7yvfVdU4QhV/eQWh9GX/ 9JAlsb0/TeJGAjPfX7TbV7vU7kFxRrthNPQ2gktjv3mwD0t5wzhs6YdmkzkOO5tN2F847dPYGkXh q2C+BfUWgdZ9+N8wWbNz2DLx1yMcH+QVLmhrjVOHXVpzZnRrxAgUpPgw7OT66u2b6wsGs7sGs+vf sqvjyzOtcTVW3ApuHfSc1B2jcpIoQFVyj0MNwbXnj6YxF73wPyLW//Hq+qZ/3keCMMKEvQrYiXNx M5nJuyE7jjm2kiU2lliTCWAoK7RBv9eR1oByjxpAHWZprQEXnh9gtS17jrB25EbgNfFcFt4uuvAC n52MmeVYE3w7/lcO5URVQG0pWw7G1kQWXxKPt1bG4hhJwFR/BXP1ZGGMrcD+3VEcTUEqcDe07Dt+ Jxv1y3om2DacjoduNkKKRVfQDJt72dQzZvND8YLCaNAzuY0eSA+nZ/2TN+c3b8+vr7S36DOgDjsa j1F74HkQ5RzEV7hyvbdiHxZwLJpwF8QwSm72Ic6iZ1uTZsAjaE0jDGclChQUb4VAjORPqRgdrKpJ MALBcjLF54p4aivCZ4TACq/TCKiwFJwcWoFT3kyQ6Vyk5Kwj0s4YzS2QIGq+hHSQWiNW5wgQEB5E B61xnmaC7POHqBYL3QeF8waNxgHpAvXGrh2NQrAjB0c6JAPsNWfgdTV53WourtutxbWplHfktd4y Fp3xpqXWZN3xxlRrMgLvXx8P2goDeN9bvm818/dm4T5H76DQ/6DQ/0CZmLg3C/UZvbMCP+J+0R9/ 1icnhaxkuc1iFFkC41C8Rl2p6zgsk+y0DBi/2cQiMBdSq/KrGKK5JCrWepoN6xPIFREbQpTD1Qzk heMAOoUQ3+7dYA45nT+6x5bQKJm4NiR8mVX8NBHOzIZzcC00WNEhtMZgr57GU1o8psHpl42eXb27 fHn25gXM6ThLhPdW4IszA5xgIoeMhpjnlTxGEZIiG02K+0SD9V2o6c/YezLuS6TU5y6iDV1wpob0 h3XB5ARWbCNXuDMs8MB7IWvCcnJOqAok2dD6JIO5SNYZLR7YK25j1Pj5KeScX1Sw9nCLhyCqoFiI DkNI1SAmpS+BrYwLMfwqWnMXYwMbBlOk2NDeJS4Xi4yCMmTQtHmsA1Ryb/kBbdRx6lwcsgsIj2PG bNdFiADxBRuBLYS4H5CiJnnPfD7rQzTlL8uJzYM0IoXzG4wyvgyzEAfntKQG3VrBgzVPlFGHXKwq ZM2GO9FO8DchqAGQS3HBPZx6ntLExgmFwKMVQD6hx/3wDcEtjac2WrRUMNIQsXqRfnkwFMXAr+sT pAIz9ENghID1MIjsOwjTvyxG0gjforXyCVpBMCdl8PFJ5X4qzTnw7/jw+HwB8qzzgMGcDyrpKgwz zhSIHl0ZmLLsdIojgFoSf0x4n9AcF4Cj3cS04Qj5RsRzmX5EMoIsxFt/WA81PtjaRWQ5lLAWxR4y KRtXsoxRo/08mnRv1sPwRVd6W8P2/LpDxsqTG56L8YMsqghBT6duiPjewVUGIN7YelCxtgW+92M0 ZVnQmnLDh5VDOK2TsYSUusF6aAg98wTwgQAnk8rRIeLMYUGBQc9HxWPexXn1cV5ooBh4+DqmxsG3 jwEp4XDiASAnA9yFdEdT3Kbx+fF37kO4CQQDZNPk5K+i1OVLIdC8Gwsbt8ECADdITHF5ekzB4OT1 cQ1gvrr1pCWRl5KxIOEGuSyKYVXQwyyAVWcfji9vLs76PApmywyQC5tYIwphecDDMmvKg0z0cYoz aiHME6llOUZiKLlFhjGbH+DC2KPJfg3tJEMbtBUschX1ysSxlLAYoi+5u5lFlC+VRTbPBW4Wc8x0 qMYa3OYHWIZxuioCjwxz1Jd+lyijqUJvrQ8xNqEdOFwdTlMZf8g/uSGIpvn+HLpRZ+wxiZLExxCe 24WUy7s8PRlaMoJFwH8eJikEkmWQyl0TzZnPLevCVEGXW8xFRlY8TVkmn7VdLDVA6nyCdNgQiyDK YUAQWJ3/mJcwK/T6SQRBbiF+OgCa0c2vWPr8cdJSXwpLUSgDFB7ypFSKA45cikcLwPEh5p0d1tMc yx0DdbLzzOptmNtT8CcwYiYPLlq4NMy4mmgnoOBp7OZ0hTkdvhNpa1x3wrjsCBolE9wiCEcayIF7 WjyGmIgCvofQBbKBpjGXE2RPEH7ogOrB2Ca4oJArILlTRA/Tk/XjipEkKU3ozkcoUBKTX4EkHNyM CZLMuq1U49WIPcj1XvFbGI/750s+1ul0PCl4443WR+yI7o9yA58fAk0HGq5nm/gDkILhGhXDGdD8 EaRpTN1hFE4wOXIQJI2Mb7yga2Jr2k/hcwASGp6AxQ0Txa+LS99l8Bi7ABYSceRVwChhqIt+PCTl wOfCgvMr57e43X0Puls8H4A63PHxvIb2D8So+VoMjPiDk4gZxhN0rUjU0oMFhk8iXREqYkQTC6Oi zOaBKhtaBVO19GKfiPC9vfxojarkWl3ayziaxaR0LmUg1gvZZIvL/ywEU+DIrY8liSstcXHnDDIF eiHIBzOw4seC9Iyw8a07sxyA7AgKHX+EaxZ0Xm7V0PYsAANNytLGImVjHsaoxkMuLlpwbUwbfQIt lGNY7X/be9buRHLsPjd/IV+07HEb3BiDX227e5JgTNucsY0DuHs6Hh8G87CZxsBS4Eey/t/5mPuQ VJJKBbh7MpvkoJ11F1XSlXR1dXV1H1LIhpXoAv3B3QPsCKQpCJEbIwGr0hm5t4rd/WjFAa6W4rBc qWmLFWkoSfAcfGM2gfC/wR6v00fRFAUj7AxMBPHz6RGCnfbJ8AMSEhBEQFSDnJNgG0sPlobtKdL4 9H4g36VowqMUdtuElQFlPmwb9n7Q4fpBKhvhEkMSGDfE4LVyP/ulfFQ/2c/JDnqbc1wQ+7mFav9s rJesJyXTHOzGyZaZY+0Kf8fxlLY5td1tWTIdLRNSdpatY0pQUmbTkHAtdGcTZeZbEn7blhXvmoHc GMGUlsNilc+E0ifOUUQKfsTjfYU12Ts+TQ/JuKgpkhhLQvfDfidFkoT0FKA1nSHhXaRK8JzEAvcj YJYwTZ5pggSi3hTw/AlbzfuG056wwGEOPzzKa6Nc5qUv21uRL3v0YSdahD/sej/grIYOl4l33XQm LC6oHSePE0rxd8BlqA+BSEFB2VIkC2xSWgm4AS5JPPqKnJFQlBYR1xQU8OBjU2x0Jq2NcSuLumKS L5x3WdhDwrYxGDJvgVYTLWiiCZgN4/54OhniqtSiHR+TRIK0EtLAg2pqtIzBuE9HLJ6pxRQ7LydN czBRk6Y5eFaLp6seCiizmqSoAwynaSIyTY8enDOYDVncUaCSdQpWPi0lDOWGSgLVPAy48CwxwZVl oD+BR1+LTStWzmuNWrFaO6nU6TOdfi02UYpqvVIOixWicJlXxrNmm+04sMaYsoRflMpI/W7I7t36 HSmPh/OiqOYzexvgovw8ksTRHI9R+mjTbvURZUFcu6YjIKdMYjggw5whWsNWosdYLw9Ep4miAebN 8Ba5N8Y1AyAkFCVSI3XpFim91VaSF2OusccjorOuBlIHpEWpcK1yPmgA3emYePTNePgNFXDDxwH1 inCZwE3soHdzg43lRVQpJQP5G3AIjCeUcgypS4pjrEfpPRiduOvd3s2Gm3DhRjR2IVyD26JQKNbZ S09q5g2OCvwplzjsN1GpVEaVxWF/2qHHzcQxWQjweStRfG7y43aiCjwAn3YSZ7B/B3mWfu0mDseA KHp+D1IhUCg97yGYZ3rcT5ySP4iuIp+Tb8Ka8nn5SleY35RvVL35LfnCrD6/nfhKekn+taNaELJh pUHuEPeSFuE+8CCxp9CHyo0bMpqCCClnl54STJR7jFncc4BYd69JVpF8wIg/6ovk7g60Yy9JLwKp s4U2gFjUGZPTYEGkbJIWuztpVPckpIo1FdIagEqzMrRPfSftqyH7pwz6EftpTeTEN+QGCic57E5Q 0ArucfG56zRxX8vU1hu0+lPyftOsJGGyEikwsrQJrK877RNTJ56ERDoaD9FliPaKqF9U8q0yKRH+ 8jlGE+FaLoaadTQDyZiCA1tSOMSZSZlATChKXpV0qJpGHqQCzl3F3G90XvqYzON6OxV7b06BOMa0 8XiaJMXR3wSs45JdNzjr/ptPpIbg9UCxWt48KGi5N9XOPWCUdne8rQBi4f5J1wBGcVITYm16E4Dw RdOX8rU7I4zDGHJ2u56sjYXP/BFQkN9ij4lRLA5k3jeIizdnnSa2UTX7TT7/ph7uuChgC5obbkll xjf5zTAfeUvF5VPNeYMDHQyao+AO5EiMpjR6Tls/3EUDjmAesL1Kqmceh9N+myUJdNDCPRMIaodt sd6XI+X0c2cLJbWdTYEPe2K7K3a2xU5X5PIit4myWn4f/Vd9SRj/JUKnr7/bZ9n8Xf33GwqWcv82 L/tvCH4vt1D232RrNkHUUUTEJAH4kTMTMRgP5LewSz5azSd8WV1kqJmQVOSPI9YmSzYF8IrKZf3i so4Szafy8WW1QIZtFJUOhzDGddgZi6LplGDJprZDyfdKqj1UN7RZgFYOEB1DTpL8rYk2IGgT7taN BdAwTHeHw8ZNc9yAhthrICpC+s3BNywaqgPVtv+hidxWW+dRaRBufJVRbzCh/UZGPW7rxz1pskMm aQjZJryuCw/mxQC1pGHJZqym1IDTD+GoaSfFYYlRWLVdcZgF3yMydjlDWdcoRjuBNIjR4PZhcFFc b7HOSelpLPcU2RbDvDAxVDqICfgiNyEIS9ob1A4A6Wc64rVE+R1YI4y7DV/rBtNmHyrV5stwO059 N7p9Jz6VUR3v0gn6A20EwOc6yvt9Qw5IsAE0tH7j0g/SbbQMuaJvrCXCQc/OyK1rWEv4RzpQyqK7 0JDgbLFwi8azKK41vWC4joSa7QIXtXf3YjwdkLzQxPVXijGmx1+Xt9SLwZY8vz9Em3wQmr6IZnsh C4gBJjKJZ8lImjc3Y9iGNCcdKYj1pXkfVbQAQlUrZrZa5WL5jUV8nAYZpmNl1EOrGzeUFQssG8wE b0E+A5BDcv5le3a323uSkvyz8ozU4JVQqmuedNofEDPa3meoXJS50bQNGZ7i7Cag9vHMKdmMS9yB WzKjC/TltPet89gLXKQ4IxDDiAasoxgnXG6kFEVq6Lu0Z4knADUTpPbMbW6fMb63s7+eb0yGjdZo e+u9ljOV+yNbXglzs2aFnnUemNmgdS9mOUURdOBT69MR8Od8Lve09T6i1xApKS0jaoIh4Oi0SGrO Tj9I+wfkVsGyvGXmtMPSKzj7eRa+pbo9oXb3vPscdzj8TIRSu9rrIs5QlANEjBM4ev7mjsRHsdHu PGxMJs8POTxRVJWZ02SvUQWoAyZnxDaQcHQZIjQLkaA9RYsynvxB9hWWhfzNvTCbu8XOk6WSKJzW KrRYfLvRefPoS2Ca9OXvb53nmyE2Ylu+kFNC/9SmyYyx/mTslVjB6rdJHbgnfytLn/z5iN72sI1W qJROg6R6hFo31xLhFky56cIndU8bG3rgBdIjbtESLZjGt8Nxr6MwDqvKvUheDFGLV4SB6pD5MCl4 hSxc1k8qVVgjCwNR+zW1AfwNHlp397BSisLfYAUP/lV66maH41vO1wxAMBBfev32ALbS/2jv9WX6 0bRY/Efrh+qYHf/xfnMHvrnxH+9zy/iPPyNtrMFWeQ24gwwqEKlWGrbY+9vr8GdX1P7LYAqYsQDM nTJinFnQGT902ll4j5/+gMgPDHj78cAPgKLjPvAIgh8O+wAgPxhnkZEwlMeX0pIzlga82SJM/jGh IT/eYrXkMKQ/JDAEQG1lBS510oeXmz6FsR+bzpvKO6czaA/R3wFDRsfDe7SZc58ngWpWB7eGbeUi h/Zu5cvGJHV7F5paR7C8jsnEMkGnU6SqAPUpknzrJ+WaqFU+1b8UqiUBzxfVCipKjsThV/hYkuul +O23Qg0+r66KwvkR/P8r7NkuqqVaTVSqCKcM+7cylAIw1cJ5vVyqZUT5vHh6eVQ+P86Iw8u6OK/U xWn5rFyHbPVKhqBHiyGwyidxVqrixbH1wmH5tFz/SrV+KtfPscZP0J6CuChU6+Xi5WmhKi4uqxeV GrQVunBUrhVPC+Wz0hGhvnwO9YrS59J5XdROCqenZqcOS9CgwuFpiUFCpzj4EpsunxhGETACbTnN iNpFqVjGh9IvJWh7ofo1AxggA1np3y4hE3wUR4WzwnGpJlI2BhCWiwRAd/GyWjrD9kG3a5eHtXq5 flkvieNK5QixC8Jc9XO5WKp9EKcVxPcncVkrUcOOCvUCVQ9QADmQAzt1WSsTmsrn9VK1ekmhG2lx UvkCWICWFqD0EeGzco59ZiooVapfETTigzCeEV9OSvC+iiikWJ8CIqZWr5aLdTMbVFmvVKlzYX/F een4tHxcOi+WMEMFAX0p10ppGKNyDTOUqXIY+K+oksOqcWCgbfAYIcwMjaAofxKFo89lbL/MD8Ne K0sSIfQVTyT2FX9+VdhViwOjNrOb2fezo64Q8uuCrhj2bhh0tQsrzsHO+4P8nh10hSG2ib9K+4X4 2Jo8jzrZu382XnXGY/tFvwdrRWC/Cybt3jDyqt+7cd+hN5f9bjoADtZ28j0HG92bCER4izsD33to 5cDzGrvjNhVe44EP1tskyGV32buk8abdwYUL3wGC5HWzOAdq5X8vpZ7SIgV/so9IiPAvRm5v7uxi uHbayH55dtGoFr6QGjlnv67/UqfXeSf7p7N6o1r6jO/JEiv6ndtmv8FWNryJV9/Gi6WTN2h+TGbw YdrBf29xL4UPrecm/Mu5YJuKr+7Z6EfZ0eCIDxTdoPJB4Wd8SXYyBZF+aLD0y4RNL2QF9GzUwrY4 /YXrSrx8SCSkdoV7QWcvku218TB5/kDvgJjp1JDGRMXy0U/+OAUiuMW4EsJQ6OUqb6xVMEnBSWHv DTYK8SdZN38lx14jI1fygtoh+ZzgQ6Kf+Mw8/KGAUR0o1cPoBMZPwK38SYdzqgOm9a1OQUNKI7JM WLv1nkMUGmgCb8izNuQrNF7KV9Qjdlu0cspXYc4PipzQneZDIkQCo4D7GkXNoPNoIiaR2CBOVx6A gNPsozqNamKLleKDsPCUDhy5Z9Qcg0jCXpsgPKAg8tyZULR/G0+jmUDj2wcSgLAOA1DGBP4igzxw avML9g0OzcEoc/E7jI/ZuIPO0AkwMrvrjrmBfofGdzs+hVWZ1geldOG3pNtALRjzUjo6pwfYSaUT krrxGAZ0YUnlMuJzvXFcqsPqVv4MC81bRWXZkPzpuon1fFpboIC1tVL5jCAWhzMcRpCCtTjIBIok 0zAwglHD4Mwpk1VHMMI/w27KmyfNMyPaXnLGgRbjgRFme63Ci7ZYRWMapnHddKvW43IFPYDOzwoX ZqXhRF+4yjByxl+T6p9ZTYRtLFxb6LKnrN2RkXFYDZ3Ngfl/8mZRnCam4ei85Y6MU8H3tD2cqrr9 EV5kNtiitvuHBmbOYtYPZtmQFc0ti1k/+DnbrLKQ2ag2wgHnFeVaX0Ieh1tYwAPxiVs8TeZxTBYZ sssgd3uEHdUjWiJwy05sMJWmwKIh+ZcoVTDAUqRPfIbL3HOghkhJHxLgi0EAW0AOB4BMw/E3qDlt M9VRv4P+L2RaoLOaWWV9f6/UwMx7sgY3Ui1LhKst8oKrrWtFWAZ3ItZUqANzSrWa7fa4MUmjLw20 Q/iYlYTQJe/8bgokOaAroKp/uvpppV1IZuIxPnwIWs2BZDz+8p9mlddENhPE8VwQFBM0C8TJLBCK 5GZCKM+DINtgD8bFXCZo8IV45oFHk541yBhyWIBNkWYEuqJGuZJa/byamcGBxLoFIyPOL09PZZ/5 bB8v0NpMoCGYmd1QbLLbb94G4q06vei4Wrg4KRdraSlEkmSHZJ27jmGm9lFLG3h3glUwP6+gOpPJ cA6JW3ONK4etOjavY7mQUSSKzp+PqnhydTUj1H1DkF4MZsWxo2RyAmFsGmB4IG+30Em5Ne7dkMzQ Vy67ARlZB6Lz1JtIZmEe/kcAUvio2IZD2hYOkpT9wLQUXa3zARrX8HTDYi8+toyYXfzdFVd0S1sy QadZJcnOef3rIGnDF5F0tX6rIxkR0B0hBp96zqkZ+K6v4YfTZ7FazkiwRBhhWA/+MgOCNPDQqXAx 4DULpIrHx+cJhdXwB+rEIvCM0KYroykAAgVhBKHmGo56Ci/hCgmoCpjsdR5Y2TlAA2xzfEsayTA8 1jrQIkWRONK7hNTF6lg00jGTNRUDqyGrgqSWJb4XIoG1wKcU7/8yvJtbW2s+8MmLa71BWx7JOGzx v0jRrYkpWVMm8RHKh5yNjxlLNR+u+HP63btrk8swFDy+LGdyD7VOhlMWCP0JZaWktMXLDgbksqo6 FaA73EoLePywpScm/k0YbZGMLkT3McUe89Kvok2GIzwjrs7ByfiDvbsB66ibphag/59xkkPQoU0R RqFoLwL0rQGkQ8MkttFPB7CNACniOcV4bl5dK5TfhI+t8LEdPq4hZIV2htcN99nyMtCM6CtxwDhO u4kHBAOqEQP6MG2FYPNSxpur342Mv9sZdeZvnLl19c3I/C2aWRfoc4H2Vd8o0PcXwNQMJKPDLsPQ rwT8Pxhf7EqG2pmhBmQIatrg11bteJsnIj21JkGF2wE30VVGqnlpb5aQmCBrbJ3A3Lg6g4pVekn4 f71ImjXoVUQJ9pTDo5h/kt8KcoUmEx6dioMephNT8ETTfEM6iUiiw9weWmqHxBQumlwCc0u9TQv2 EaPGRDn4mbmAmFEploRRkjJT46JQP2EJ48XMecM5VUM8OVohrCS6sSQ9edphHvmNCR/PnQ4nWhOo BUgF6AQkODkqmgthXjngizEhA/U02YcT9gZKaq7DaLK2+xJXZsWs2YT6M0KOSvqtzCbFC6REdbF8 2DA8fRJKmbTHN+LCNiQVQsgzkAwgwwuI8NTqD4MOA7MJ3O29hYGbZlvYWEgaWS06tjbLtiitUCJ3 xvOQb+2WkaRDvYJUKxjVmh0L546Ki7UD6ymg3pktMoeeNaYE5qd/YsAevovXGGzu7DLL1f1ZS9GQ hyMu3uGtuT9pEP/DeItgIBkry5oxXuGgo3PrpE0HboWoI47txZmtKY6qiL3dttVP39tlWwXlIRUa rJ9wqD7KyUoT1V0jqWl4EzSewIpX0+JlASi62DMqFM+HGKWWNKQ9BYUiA2YWEiu5zSfgaYio3rXZ OXOTF1d0q+0WfYmoB8zGhSN+1GFXtY5cUFYDYhtyjKFsgg6GT8nlAnLoScEaazrCO7gx2Su+ShGb H9I/aSThm7SDO7neBTfZwNywWf2VedbznvWQ/XJxKZy3EGJOyW9Rd61EK++KiDPVXBQxYQSJYq2P jh2ENFK9Ic98PlEXwbZwDzgd9dritgW0mVYOf19UPDyd/C7kooaV8pJIB4Hr5aARTLtPV2rW6KzG kvupcl6PWW8x59wlFzMZq66u1J+zba7P3cHEXp8Nw5E0WZhkApDJrGFML0Dv4wfr513408WwJGuO OuZ2/Odehm4gQmaJiEB35hd7f0yJ8m1b+bbj8ok9M9+eNxswKrzSKfeihA+Psl/q9qMsztHrm5ri VzE5PuGNlPvWETYePTIhTo7GQDGEcKSVvKLewHRNru89rSBPsfUj6T9D2FoJDtCHe3XC8eba/R5a o2es1SesBee1luIdvZS8t0yRGW5DUQHaTTEzSK60ua9vH+H/dzQYmw63NlZ3pr/edfaRtrGRRcOq J8wLQB9xGdGv7vDVXdxeSLZbm71VMc/mgiobSsoj0GqyuMmwiZrZ76K5X1iv8mKvYtwoZ+9OgL9P qMSRvlFDTMCVPxNbqDJkaozKmereV/UamG5hNOo/i7vOdNwLJr1WQCuAbjuA/91mNG2pEzTWaT/K cybKJXPGG4NYlhMYkTpspQzVIKZ2qA41RH6LtUdykw6U11oLj7SxlEXT0ebmzNaFW/rfUQaN38t/ By1HSRFJgdv++/UcOlbZ/hzqxYR4AAQgbcirMHy55I0l7mtN/m/+hBnAvI5PxNMzIcrsuEHeTaHx aR6F+raiNl3O24Ga6NDkqgrhjSK8K9VAf2RT6tD+KxF7M3v1YKwZuLOW6d5QI+aHtl0IY8ZO1dPL 6OZVRXSqUwKNQ55MWRdv5DA+NWQxpXQc35p2yEHQaRnk8BcQ01r3oxTkQtmi202mzf5i7pDZRBiw /NycDHsIwd39pLByROLqr7lVvnWGSnwU+bRLCnPGVWvG1QFNTelu/GAa/ucPL0lhh6eF85/r5TP0 B8EGfddAB9Zmk71mRp1xb2hqh6Jjyr40uNvCU6/JXc4dS3l5K35SY6gtOOZQYgbfUOrM0Er2BEim Q7mGJCY9pPraEm9pOpPVUzi/SGHjXFYPiC0DxELioaaAyVCstzQdcAcz8vhYCpg1qo3IizYhFC+r tUq1/vUCKYFkjh+hBMNNyqdjURRgnjIVDnxo/GTjzPjWMM+Mbw0DDaoU1E6czIeWZx8mV42Lyd5W YT2zvqG9WM15Ou1IbrxEkg5CAKYqU+1Lo176pc7neePbM+O38O6iCMZWzgtjK2fD2MrNgLG95YWx vWXD2N6aAWPH344dpx07s9qx64ex68DYjYXBZ51rIAoGv85oGPJI9BlADKyaQAirZ+bvWUAMtJpA CK1n5u9ZQHb8LdlxWhKPVz7J3Qtk1wESj1h9Ej7DASD4prgdEmv4exaMvSiMPQfGTILXJ+5HYCiC D3/PgbEThbHjwIhHqj7ZPwJj14HBOP1rr0t3ect8dAlALOD9KJL2HSTtz0PSfhRJ+w6S9uchaT/k DAYMxRXC33NguIjedxC9Pw/R+1FE7zuI3teI7gzavW4sKHldAQJToI7hHcE+4+e4lpQi5Fs6P7HI N/w9B4aBVVVGYTX8HYuR8FIH1Q18U1RM7sz6PRcKt8WCgm05s37PhbKTi0DBMT6zfs+FshuFsutA mcGijJh5NKVKKPKNhqKO9PZDQe2X+hTqJiehKzks56HMF13uw2+Wq6J6oUw2KMdgWhMXzXHQcaQZ 7Z6RzWZlvo1Q8GLJBd1GQLJxjS0oPw7kNuThirNeg2RFN2AAVnYi2wUq1QtY9LeKXe1cp6P2fC1G 9gZ8eUa847BKDvJok/PWrcnYc7iyLCZT6cJyVO86Sz4j2jHi3btenOrF2JwZWLHgRBCjkhxWndmW +Gb00yoRyoFuitWg2L8ig2Zj4ac4/4uZ4wUlk37tiKJQTGvqeADRGVDQpOfYanK8sg5+VbRLEAxd ohWVYfiQm9hztr+xnuMWLM+WA1PsfjjGGGB3w2MIcDClxsKr1cKPFlnEebSqJJGh/VqtwrYnq9Mh 18rpQqs50BYZd/TnUpsyNcRyv+UbWmus+IYqNif8wMAEER//hSgWT2o0L3cQvckqH3MsaRg2v7/j zlcdV0bdwhtt6Z4BA5I6l6rzNOr3Wj266laWMSqYgZEIwS/gDcwdMvT6JlAF2NLnRqzqmGyN78Lu vpisH6H/rxUV5ja32SaU8sGFgbfNKR10BqjF+2Ej2CEXZ9JxJd68MbJ/pB6SWtnHqkODgR8iO02z Vtq3wNgwjNA4145j9xXj5WZ0lD9b4+DpMn/BPkeaZIBZBAF5LwL0hbzW6C2Ai7zGBccFxuAC54Mx F7z4iHMH93XFzxkwudyBwjn47lHZAHkgVtIp/OJjGdHoxVAlh0k/SKEr/e6dpQdj5wrHExndLYhX cvQBCi6m2yuH8+DKa3iI3KKyEj/I8AKpraRXpqLSdpZi/5v8rtftRok8MqbSCsXtuYKd9BLpqd4Z 72zPkeOOiu3kg668N4iZ2jjsmQyi4o+LK+V0zOmHGOGXrnVW4VERFJqyXpoMJ/YS5I4pJm+oGDdB ZbGjYGPo5Q9ualxzjSbboWLUZDOXQf381x5SdXfI4mMqS/whgzoPMSmGsJ73IscbZve/e8y84X2v GbNaOA35KDcevnlX+0XsIzx4MWEyRiRbZF7MDVyLkOXcOLXIOM6NS4ug0bb96atnItfN/BUGL4oL kolibH2aWlN/QUscCCfAXoPRgMx9yVx+c2t7Z/f93n6SLbSTcb9D39ILuuygpVXFWdpWOLnUDDzW QRIu0QaI7RmAYIFX3S9UnV0VXds37MqTtlW9oVFqwRjLwffZfHQ4u4wG99C6vKXLuOjRHT3+xlTg H8JXMR09oXWzZ0SJGrRqbcI4Dk3SpG4pRfcjK/K0U9qfOAv5+tEjwyYdk4pSwcgQyD0Z9tngjNus DIiHZgf7QBo5Nhb3gTguiyeFauOs8MuiNGnZCc+0nTCHh6nTFop8vkKwFr1Sw7PDUUdeWQ3b3spl rdSgv1jkg5Ftmg2xgo4XgOl0P9b1j0HUT9G/GYv9kKnROYDBS4D6JAZ9m5tLfvTyFeOpe+Z4DQxs p4E4JNZOKl8is3SOA0IcrJPyUSnGKWFR2rjXtCFv1NT3hM21G/8hY7miLqniTiYdzW6k5yYaxb8A LcAAJ8WBSMIg2wSgBxivX2VO5ecueILI4s4gmBtVmU+5/LxhHMSV3PzBQat916DBCnBaKf5c+1Ku F09g0LA93zVmuLfAUVsJ7ENN3MHjDjOucKywfThUfPyGO1WN7ZcKpFWnE1ubMMNZRJr+6ULINVmo gYVSyjNknpNA6EGi3rhuAy/UCm36//kI6P68whbZ5NlRIRljjYCMJ6Vq8fIUT4lLnnTGrWkfr8yK zU33tzJYeJyRsRRmLM3M+DnM+Hlmxovi/p7s0UVxfX/v6WlG5noItR4PdT2fCX8mLwffBnjwk888 4wsiYpT3rrPKsxl2sq6NgCQoKx+QGo+52RRDRW+HGuqyPNb2mqHP4tW0aOjNrRUEMjcU6WEeO3TK PNfIzAVgZbeb7exDs8F7FzJAxXDbwtGFVJw32z/oMu/pksM3pMCU7N6stA9+RV9ko5kyq8qDzyvZ tWClzR7LBxi1KlIr7XRGkLb0IPe08vTrwOYOJCdI33uGTYYcVRHHa/DzdNCb2GX5faiKBdyQbj2N XIauHCQ+Y9do8QeGQNSiqmF/eAO0p589Pn6KNGUH2GEVfaBf0D2K8pfbZ4VDgtFgHTu/M5/V95ve MKAPnnZ00a6hTopC79ThI2E5Y54e5cU718FFVI1cpmE4Zpt1cd4QIl6g2bvtDeaCb7Dnq/UKi3rq kIo/eZsM7k3QHziFCCU6wogFjv4nfXAsbhFOg4BknzLRd8/qHYKSyupoY9Tpt7qDmg7x+NJcOsIr DIvTLC6h1brxLMI4Eg2/0VoEo3O1lzMM0aERk/ZGHxKRHmCOvxJaeI5If0MhPdI5Wec6JMlaIYzx poR44iYAgfyquYSqK+6GGifZNS1YyIgjpJVBW+gZ0R+VOY2s47CFwfWBZou1ultWSkactYDEWifJ KGmvJHjESG8wNWQFgmDW8ReuJK6cfq0QuLLVFikgs9zWUzqpzG7GnLcGFvPtPamwJGWLct2NX2mo Qs/l1eNVxx6kA6Vg5HWIFDynVcAQ/EdbyOjSb+JdX1RlmjLmlNGXVvFPYAuDTmCgw2v0oF7UX92L 72q/34KpR2mlJVbW8zt4bkOL2LGR/7sapGpvOa1pRZoTtmGd6rcrt+ho50msbLa/0Z9opWH/eZmg xdp+ScxdbIh8bnM7Ut6XHwSqwQbmjidtoKhvLl83m8NsyGmOsXjJ5nh2gch+ifNGN4CRbZuUE+y9 W1TMi6rabDBs7Y7ACBcBG8DrN4E9dxOoxLrh2DK1G3iYdIJJg2QHawmypHA3ZPqfrn7KHf86cNmx Ee2/Fz1exQMkv/OJQKk8QHmCddQwXXaDZITwFyiks8YVDgscHxaKPx9XK5fnR7JHnrnWo1Bnx9wG 797t8Z9IATvru71rAtCbE4XOPeBmsQqd1eKRNkXOnMvYr1B77i+hzofLWG/keW+G+KLu/TOc2Pii WDrCHY/i1/fO6OvE7ZtyAQotonwxjbzmli+sDqZ9ebk09VzRqQwGpx09Xri3Zh6BD1XihdzySjAx wvPEjBvA0nR9u4QAa0MPz3hn0xeXNqUuvKpGxgSllOBkHGqBHcdTLeAfHi9/CPf/ofBmvMIH+CGa GzDsrZlSg98K/gPHSZEC/ZJ9mUKXJ/ndxiRt9igE9aroZbxinD1uuAGTjqInGkMYD1+TnyR2jdZ+ CL8+O1/H+DUG9ZIo8cQFKPpdqMdGhhFNHn2a8hdTp2yb4NWCpi5mXGnx/2AxNk/ZzojNCC8JMZEx +m1Kd91ufxrcSTZifmBmTlMvVasfVS7rDTzNAbVUahz9go6B/TUT2X7iIDy4qxUvqLhPMMRioFfY fj2HbzQcyG80nHZ0mliN1rwTeVeu5bxRavSP6iuokgCzFBHjnUYL3jMveM+w4IWYgt8xMcaszBFP KvsTZ3/yhxi37pC5yLG6eoL+Q31rRsm0J3gYCr1F5Wq36zmVi+YGHykGQo97+kik7lXhCs9qfK6e rlU8bbrlhBtHvYnq4969mIwB4TSHRs1WJ+pi1R56UMB1ra9jbRgp6dSER9b1O0wG1CRqM5r5n/hA Paf5o+kkoMwxQ+rMJeNz1DFIRy1Ky6vnpG7XqCSzSHlzOJq4p+Cq80GYt5F1GHOZNkAsZsWNUuaP Cx8euHi0aKyJ56Rcq1fw+o+3HLj8A8Y6D9J8VoBiHxUO8dg2Ed3CvBrVlkQbDXI8rWJnvqsLVE+0 D3bz0RUM7wT2u9Oohsmzd+ge1bXQ8EBnTY4mxuiTEwu01TBja5u0LNLTjf4j5RQTC0RGinroJnPl jiEHR+8JaHamUkSxaJWHhxQjgZ2JkjcHxdZBu3twe3B30DvoH5yeHdwfjC7GB7WD4GBy8JT0+eFI qx1ODHfDj4dRr96sHkT4SMSjAEqz34Wb0+O8z2CLHrA2rb0GWiumkWaA8+vb2PZAtY8jew20rgea DFHmpkVhkcLwJ6HOUjUH+y0eWzpoZxBuJsqaMSkX6LgV3WkEBYl4M8hmxLXyxbOo6UOxWOOPj6/B 1a0HV8axOtwS82Ad7Y+sntEfl6h9M67b8U60mB6b48FTKtkbtIZjugVUHUh8IOi80FhqwqS5SBRV C6PgLoak1fR4PTn3fBC11ub18PoeeNaxoK8HeRoH0j078TVAz2IwaXgavb6l97OAfge8kQeeubfW O6FXwLxYBGb9l/prYI49MD3+rh5W9ZpaajHYNdxMXo/iIG6RkJ6Nr4c4iYHoOyPl9dCfPND5rqL8 QlDknIkCibAn6xQT43wI/yhSrqjf+ozMdPy/7WMMonY0uiDio794bJAvsCwV9f3+KPbS5LccdTHG T964EcMReF5QyMzADOXJ6jgd86E7qF0L9U+B3k9Aq2aEavja4bRXjS3+1YPBw2P4cVsBoPwVw2LJ 88vCiqHeNprFJZzoDxoCWRMsxByOi96WodwdJ3hL95Ec7hD/0Xe8LtMyLdMyLdMyLdMyLdMyLdMy LdMyLdMyLdMyLdMyLdMyLdMyLdMyLdMyLdMyLdMyLdMyLdMyLdMyLdMyLdP/n/Tfn35kcwAYAQA= ------=_NextPart_000_007F_01C48EB0.BFBD0280-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 08:48:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4085B16A4CE; Mon, 30 Aug 2004 08:48:28 +0000 (GMT) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDF8543D31; Mon, 30 Aug 2004 08:48:26 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226])i7U8mLtH015943; Mon, 30 Aug 2004 11:48:23 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) i7U8mDj8005633; Mon, 30 Aug 2004 11:48:13 +0300 (EEST) (envelope-from keramida@linux.gr) Received: (from keramida@localhost)i7U8mC50005632; Mon, 30 Aug 2004 11:48:12 +0300 (EEST) (envelope-from keramida@linux.gr) Date: Mon, 30 Aug 2004 11:48:12 +0300 From: Giorgos Keramidas To: Ruslan Ermilov Message-ID: <20040830084811.GA96014@orion.daedalusnetworks.priv> References: <20040830072811.GA84862@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040830072811.GA84862@ip.net.ua> cc: current@freebsd.org Subject: Re: [PATCH] Finding stale files in /usr/src during "make update" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 08:48:28 -0000 On 2004-08-30 10:28, Ruslan Ermilov wrote: > What do you people think about the following patch? It can > be very useful to find stale files under /usr/src which may > sometimes be unsafe. It's nice, IMHO :) > %%% > Index: Makefile.inc1 > =================================================================== > RCS file: /home/ncvs/src/Makefile.inc1,v > retrieving revision 1.442 > diff -u -r1.442 Makefile.inc1 > --- Makefile.inc1 25 Aug 2004 22:06:29 -0000 1.442 > +++ Makefile.inc1 30 Aug 2004 07:17:37 -0000 > @@ -83,7 +83,7 @@ > .endif > > CVS?= cvs > -CVSFLAGS?= -A -P -d > +CVSFLAGS?= -A -P -d -I! -ICVS > .if defined(CVSTAG) > CVSFLAGS+= -r ${CVSTAG} > .endif > %%% I regularly use the same trick here. When I want to build world and keep a logfile of all that's going on, I use something like this: # cd /root # sh build.sh -cu 2>&1 | tee logfile and one of the things that build.sh does when the -u option is present is: cd /usr/src ... if [ $rc_update -ne 0 ]; then echo '::: Updating the sources from CVS' env CVSROOT=/home/ncvs CVSFLAGS='-APd -I! -I CVS' \ make update unset rc_update fi From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 09:05:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B014616A4CE; Mon, 30 Aug 2004 09:05:29 +0000 (GMT) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D25C43D45; Mon, 30 Aug 2004 09:05:28 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from ns0.nlsystems.com (ns0.nlsystems.com [80.177.232.243]) by itchy.rabson.org (8.12.11/8.12.11) with ESMTP id i7U95PU5094708; Mon, 30 Aug 2004 10:05:25 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-current@freebsd.org, current@freebsd.org Date: Mon, 30 Aug 2004 10:05:58 +0100 User-Agent: KMail/1.6.2 References: <200408160104.03708.chris@behanna.org> <41325D89.5040806@freebsd.org> <20040829232346.GA95117@dragon.nuxi.com> In-Reply-To: <20040829232346.GA95117@dragon.nuxi.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408301005.58602.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on itchy.rabson.org X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on itchy.rabson.org X-Virus-Status: Clean cc: Tim Kientzle Subject: Re: Public Access to Perforce? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 09:05:29 -0000 On Monday 30 August 2004 00:23, David O'Brien wrote: > On Sun, Aug 29, 2004 at 03:49:45PM -0700, Tim Kientzle wrote: > > >Ask Perforce to port to 64-bit AMD64. That would allow them to > > > have a lot more memory for their in-memory operations. > > > > Another possibility would be to switch from Perforce > > to something like SVN. > > > > I'm not sure how it compares to Perforce, > > It is amazing the number of people that keep suggesting things like > this and yet don't compare the two things they suggest to know how > they really compare. For what the project uses Perforce for, SVN > would offer nothing. True. That doesn't mean that subversion isn't better than CVS though. > > > but > > SVN has much better branch and merge support > > than CVS does. > > Oh? SVN's own developers say "Currently, Subversion's merge support > is essentially the same as CVS's." Well it might be the same in a purely technical sense but after actually trying to use both for non-trivial repeated merges, I can say that subversion is a huge improvement over cvs given a small amount of care. The atomic transaction numbers of subversion make it possible to keep track of where your last merge ended. To do the same thing with cvs requires repeated whole-repository tagging which sucks. > > > It's also specifically designed > > for use over slow networks, which would be a real > > plus. > > SVN does nothing better than Perforce, yet removes the advantages of > CVS. SVN doesn't remember past merges, so its branching is still > embryonic compared to Perforce. Compared to CVS, SVN requires a > connection to the main repo, and uses a heavier-weight network > transport (requires Apache and HTTP-based WebDAV/DeltaV protocol). You don't have to use apache or webdav. The svnserve protocol works well and if your project is structured so that developers can have accounts on your repository machine its just about identical to using cvs with CVS_RSH=ssh from a sysadmin point of view. True, no-one has implemented anything like cvsup so that you can have a local read-only copy of the repository. I very much doubt that this would be hard to write - the atomic transactions make it trivial to work out how to bring a read-only slave repository up to date wrt. the master - essentially you get CTM-style deltas for free. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 09:05:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B014616A4CE; Mon, 30 Aug 2004 09:05:29 +0000 (GMT) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D25C43D45; Mon, 30 Aug 2004 09:05:28 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from ns0.nlsystems.com (ns0.nlsystems.com [80.177.232.243]) by itchy.rabson.org (8.12.11/8.12.11) with ESMTP id i7U95PU5094708; Mon, 30 Aug 2004 10:05:25 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: freebsd-current@freebsd.org, current@freebsd.org Date: Mon, 30 Aug 2004 10:05:58 +0100 User-Agent: KMail/1.6.2 References: <200408160104.03708.chris@behanna.org> <41325D89.5040806@freebsd.org> <20040829232346.GA95117@dragon.nuxi.com> In-Reply-To: <20040829232346.GA95117@dragon.nuxi.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408301005.58602.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on itchy.rabson.org X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on itchy.rabson.org X-Virus-Status: Clean cc: Tim Kientzle Subject: Re: Public Access to Perforce? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 09:05:29 -0000 On Monday 30 August 2004 00:23, David O'Brien wrote: > On Sun, Aug 29, 2004 at 03:49:45PM -0700, Tim Kientzle wrote: > > >Ask Perforce to port to 64-bit AMD64. That would allow them to > > > have a lot more memory for their in-memory operations. > > > > Another possibility would be to switch from Perforce > > to something like SVN. > > > > I'm not sure how it compares to Perforce, > > It is amazing the number of people that keep suggesting things like > this and yet don't compare the two things they suggest to know how > they really compare. For what the project uses Perforce for, SVN > would offer nothing. True. That doesn't mean that subversion isn't better than CVS though. > > > but > > SVN has much better branch and merge support > > than CVS does. > > Oh? SVN's own developers say "Currently, Subversion's merge support > is essentially the same as CVS's." Well it might be the same in a purely technical sense but after actually trying to use both for non-trivial repeated merges, I can say that subversion is a huge improvement over cvs given a small amount of care. The atomic transaction numbers of subversion make it possible to keep track of where your last merge ended. To do the same thing with cvs requires repeated whole-repository tagging which sucks. > > > It's also specifically designed > > for use over slow networks, which would be a real > > plus. > > SVN does nothing better than Perforce, yet removes the advantages of > CVS. SVN doesn't remember past merges, so its branching is still > embryonic compared to Perforce. Compared to CVS, SVN requires a > connection to the main repo, and uses a heavier-weight network > transport (requires Apache and HTTP-based WebDAV/DeltaV protocol). You don't have to use apache or webdav. The svnserve protocol works well and if your project is structured so that developers can have accounts on your repository machine its just about identical to using cvs with CVS_RSH=ssh from a sysadmin point of view. True, no-one has implemented anything like cvsup so that you can have a local read-only copy of the repository. I very much doubt that this would be hard to write - the atomic transactions make it trivial to work out how to bring a read-only slave repository up to date wrt. the master - essentially you get CTM-style deltas for free. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 09:15:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6562B16A4CE; Mon, 30 Aug 2004 09:15:41 +0000 (GMT) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EA4343D54; Mon, 30 Aug 2004 09:15:41 +0000 (GMT) (envelope-from brad@stop.mail-abuse.org) Received: from [10.0.1.3] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.11/8.12.3) with ESMTP id i7U9Fc6j032014; Mon, 30 Aug 2004 05:15:39 -0400 (EDT) (envelope-from brad@stop.mail-abuse.org) Mime-Version: 1.0 X-Sender: bs663385@127.0.0.1 Message-Id: In-Reply-To: <200408301005.58602.dfr@nlsystems.com> References: <200408160104.03708.chris@behanna.org> <41325D89.5040806@freebsd.org> <20040829232346.GA95117@dragon.nuxi.com> <200408301005.58602.dfr@nlsystems.com> Date: Mon, 30 Aug 2004 11:15:33 +0200 To: Doug Rabson From: Brad Knowles Content-Type: text/plain; charset="us-ascii" ; format="flowed" cc: Tim Kientzle cc: freebsd-current@freebsd.org cc: current@freebsd.org Subject: Re: Public Access to Perforce? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 09:15:41 -0000 At 10:05 AM +0100 2004-08-30, Doug Rabson quoted David O'Brien: >> For what the project uses Perforce for, SVN >> would offer nothing. > > True. That doesn't mean that subversion isn't better than CVS though. That's not the point. The point is that subversion is not better than Perforce, at least for the functions for which the FreeBSD project uses Perforce. The debate is not between Perforce vs. CVS or subversion vs. CVS, but whether subversion or Perforce is a better replacement for CVS for certain specific functions. This is a debate that can only reasonably occur between people who actually understand both alternative tools to a sufficient degree. I think that the point being made by David O'Brien was that there were a lot of people standing up and being indignant about the way subversion was being treated in this discussion but then saying that they didn't know how it compared to Perforce. This is counter-productive, to say the least. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 09:15:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6562B16A4CE; Mon, 30 Aug 2004 09:15:41 +0000 (GMT) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EA4343D54; Mon, 30 Aug 2004 09:15:41 +0000 (GMT) (envelope-from brad@stop.mail-abuse.org) Received: from [10.0.1.3] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.11/8.12.3) with ESMTP id i7U9Fc6j032014; Mon, 30 Aug 2004 05:15:39 -0400 (EDT) (envelope-from brad@stop.mail-abuse.org) Mime-Version: 1.0 X-Sender: bs663385@127.0.0.1 Message-Id: In-Reply-To: <200408301005.58602.dfr@nlsystems.com> References: <200408160104.03708.chris@behanna.org> <41325D89.5040806@freebsd.org> <20040829232346.GA95117@dragon.nuxi.com> <200408301005.58602.dfr@nlsystems.com> Date: Mon, 30 Aug 2004 11:15:33 +0200 To: Doug Rabson From: Brad Knowles Content-Type: text/plain; charset="us-ascii" ; format="flowed" cc: Tim Kientzle cc: freebsd-current@freebsd.org cc: current@freebsd.org Subject: Re: Public Access to Perforce? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 09:15:41 -0000 At 10:05 AM +0100 2004-08-30, Doug Rabson quoted David O'Brien: >> For what the project uses Perforce for, SVN >> would offer nothing. > > True. That doesn't mean that subversion isn't better than CVS though. That's not the point. The point is that subversion is not better than Perforce, at least for the functions for which the FreeBSD project uses Perforce. The debate is not between Perforce vs. CVS or subversion vs. CVS, but whether subversion or Perforce is a better replacement for CVS for certain specific functions. This is a debate that can only reasonably occur between people who actually understand both alternative tools to a sufficient degree. I think that the point being made by David O'Brien was that there were a lot of people standing up and being indignant about the way subversion was being treated in this discussion but then saying that they didn't know how it compared to Perforce. This is counter-productive, to say the least. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 09:21:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F4AE16A4CE for ; Mon, 30 Aug 2004 09:21:35 +0000 (GMT) Received: from huva.hittite.isp.9tel.net (huva.hittite.isp.9tel.net [62.62.156.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id DACA843D55 for ; Mon, 30 Aug 2004 09:21:34 +0000 (GMT) (envelope-from clefevr-current@9online.fr) Received: from pc2k (78-240-118-80.kaptech.net [80.118.240.78]) by huva.hittite.isp.9tel.net (Postfix) with SMTP id 9929614B689; Mon, 30 Aug 2004 11:35:19 +0200 (CEST) Message-ID: <090e01c48e72$bdea95a0$7890a8c0@gits.invalid> From: "Cyrille Lefevre" To: , "Maxim Sobolev" References: <080a01c48dff$4248a310$7890a8c0@gits.invalid> <4132358C.6060108@portaone.com> <1093849339.864.5.camel@localhost> Date: Mon, 30 Aug 2004 11:21:32 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 cc: Deng XueFeng cc: current@freebsd.org Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support forFreeBSD-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Cyrille Lefevre List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 09:21:35 -0000 ----- Original Message ----- From: "Vladimir Grebenschikov" To: "Maxim Sobolev" Cc: "Cyrille Lefevre" ; "Deng XueFeng" ; Sent: Monday, August 30, 2004 9:02 AM Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support forFreeBSD-CURRENT > On Sun, 2004-08-29 at 22:59 +0300, Maxim Sobolev wrote: > > > vidcontrol -i mode is your best friend! ;-) > > Yes, it shows some corresponding graphical modes: > # kldload vesa > # vidcontrol -i mode < /dev/ttyv1 | fgrep 1400x1050 > 320 (0x140) 0x0000000f G 1400x1050x8 1 8x16 0xa0000 64k 64k > 0xd8000000 16384k > 321 (0x141) 0x0000000f G 1400x1050x15 1 8x16 0xa0000 64k 64k > 0xd8000000 16384k > 322 (0x142) 0x0000000f G 1400x1050x16 1 8x16 0xa0000 64k 64k > 0xd8000000 16384k > 323 (0x143) 0x0000000f G 1400x1050x24 1 8x16 0xa0000 64k 64k > 0xd8000000 16384k > 324 (0x144) 0x0000000f G 1400x1050x32 1 8x16 0xa0000 64k 64k > 0xd8000000 16384k [snip] > and I can't switch to text mode based 1400x1050 resolution (all Ok with > Xorg server, I talk only about syscons in high resolution, text or > raster) > > # vidcontrol VESA_800x600 < /dev/ttyv1 > vidcontrol: cannot set videomode: Operation not supported by device don't know about that :( > # vidcontrol VESA_1400x1050 < /dev/ttyv1 let's try : vidcontrol MODE_323 Cyrille Lefevre. -- home: mailto:cyrille.lefevre@laposte.net From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 09:25:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23EF116A4DA for ; Mon, 30 Aug 2004 09:25:23 +0000 (GMT) Received: from gvr.gvr.org (gvr-gw.gvr.org [80.126.103.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB98243D41 for ; Mon, 30 Aug 2004 09:25:22 +0000 (GMT) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id 3E36738; Mon, 30 Aug 2004 11:25:22 +0200 (CEST) Date: Mon, 30 Aug 2004 11:25:22 +0200 From: Guido van Rooij To: Daniel O'Connor Message-ID: <20040830092522.GA13880@gvr.gvr.org> References: <20040827082929.GA64830@gvr.gvr.org> <200408300837.08339.doconnor@gsoft.com.au> <20040830072245.GA12692@gvr.gvr.org> <200408301701.07731.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408301701.07731.doconnor@gsoft.com.au> cc: freebsd-current@freebsd.org Subject: Re: project evil: signal quality X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 09:25:23 -0000 On Mon, Aug 30, 2004 at 05:01:07PM +0930, Daniel O'Connor wrote: > > > > > > Are newer drivers available? > > > > Given that your ndis0 -l option for wicontrol works here, I doubt that this > > is a driver issue. I'll try to find time to look why -i ndis0 fails > > to report the quality.. > > Why do you say that? > I am talking about the Windows driver - perhaps it doesn't report signal > quality in a standard way. I assumed, and now that seems wrong, that there is only one way the signal quality was retrieved. (the -l option uses an ioctl, whereas the option I used uses a socket. -Guido From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 09:47:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF49516A4CE for ; Mon, 30 Aug 2004 09:47:47 +0000 (GMT) Received: from huva.hittite.isp.9tel.net (huva.hittite.isp.9tel.net [62.62.156.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B4DF43D4C for ; Mon, 30 Aug 2004 09:47:47 +0000 (GMT) (envelope-from clefevr-current@9online.fr) Received: from pc2k (78-240-118-80.kaptech.net [80.118.240.78]) by huva.hittite.isp.9tel.net (Postfix) with SMTP id C275514B7C0; Mon, 30 Aug 2004 12:01:32 +0200 (CEST) Message-ID: <098401c48e76$6772d300$7890a8c0@gits.invalid> From: "Cyrille Lefevre" To: References: <200408291848.i7TImAq8072080@mail.gits.dyndns.org> Date: Mon, 30 Aug 2004 11:47:45 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Cyrille Lefevre List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 09:47:47 -0000 PR#71142 (http://www.freebsd.org/cgi/query-pr.cgi?pr=71142) has just been submitted w/ the "static void" fix. PS : the vidcontrol "showing the mouse: Invalid argument" error message has not been fixed, yet. Cyrille Lefevre. -- home: mailto:cyrille.lefevre@laposte.net From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 09:57:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D859516A4CE; Mon, 30 Aug 2004 09:57:32 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23F4443D1D; Mon, 30 Aug 2004 09:57:32 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i7U9vT1Q030850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Aug 2004 13:57:30 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i7U9vTBB030849; Mon, 30 Aug 2004 13:57:29 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 30 Aug 2004 13:57:29 +0400 From: Gleb Smirnoff To: "Bjoern A. Zeeb" Message-ID: <20040830095729.GD30701@cell.sick.ru> References: Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: Robert Watson cc: FreeBSD current mailing list Subject: Re: mutex Giant not owned at /usr/src/sys/kern/vfs_vnops.c:120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 09:57:33 -0000 Robert, Bjoern, On Mon, Aug 30, 2004 at 05:29:56AM +0000, Bjoern A. Zeeb wrote: B> > Could you try the following patch: B> B> seems to work fine; my test program crashes somewhen later cause of B> some pthread probelm but modules got loaded successfully w/o panic. B> > This causes Giant to be acquired in the event we enter the linker code B> > (and hence VFS code) via netgraph ngc_send(). It should be safe in this B> > context as we enter protocol send routines without mutexes held (i.e., why B> > we're also able to do blocking memory allocation here.) B> B> please commit. I think Giant should be acquired in linker_load_module(), and this way we will prevent this panic in other codepaths. For example in vfs_mount.c, when vfs will be Giant-free. Have I missed something? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 10:32:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6851C16A4CE; Mon, 30 Aug 2004 10:32:19 +0000 (GMT) Received: from obh.snafu.de (obh.snafu.de [213.73.92.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F66143D2F; Mon, 30 Aug 2004 10:32:18 +0000 (GMT) (envelope-from ob@gruft.de) Received: from ob by obh.snafu.de with local (Exim 4.34 (FreeBSD)) id 1C1jSS-000NEP-LZ; Mon, 30 Aug 2004 12:32:16 +0200 Date: Mon, 30 Aug 2004 12:32:16 +0200 From: Oliver Brandmueller To: Andre Oppermann Message-ID: <20040830103216.GA51110@e-Gitt.NET> References: <20040827084306.GB74653@e-Gitt.NET> <412F276A.6080807@freebsd.org> <20040827141354.GC74653@e-Gitt.NET> <412F5307.5040005@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <412F5307.5040005@freebsd.org> User-Agent: Mutt/1.5.6i Sender: Oliver Brandmueller cc: current@freebsd.org Subject: Re: RELENG_5 ipfw problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 10:32:19 -0000 Hello. On Fri, Aug 27, 2004 at 05:28:07PM +0200, Andre Oppermann wrote: > It detects a missing dummynet because it has to pass on configuration > options to dummynet and it can only do that if dummynet is loaded. For > FORWARD this is not the case. Here the ipfw code just tags the packet > for later treatment. And that later treatment is scattered through a > few places where we have to inspect each packet it carries this tag. > > >- How to enable it? > > Put "option IPFIREWALL_FORWARD" into your kernel configuration file and > recompile. I do now have IPFIREWALL and IPFIREWALL_FORWARD in the kernel and am not loading it as a module anymore. The dmesg now states: ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to deny, logging disabled OK, fine. But do still have a problem: The rule is loaded an matched. Instead of just dropping the packet (as before, when rule based forwarding was disabled) the pakets are now accepted, but the forwarding does not work: 00200 fwd 192.168.25.1 tcp from 192.168.25.5 25 to 213.XXX.XXX.0/24 Is still see this on em0 (the public interface in the destination network metioned in rule 200): 12:26:09.674295 IP 192.168.25.5.smtp > 213.XXX.XXX.XXX.41424: S 3583621218:3583621218(0) ack 3993419222 win 65535 # ipfw show 00200 2694 118536 fwd 192.168.25.1 tcp from 192.168.25.5 25 to 213.XXX.XXX.0/24 packets are accepted, but not forwarded. Can anyone else reproduce this? - Oliver -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 10:39:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3296316A4CE for ; Mon, 30 Aug 2004 10:39:49 +0000 (GMT) Received: from hotmail.com (bay11-dav44.bay11.hotmail.com [64.4.39.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2678343D5E for ; Mon, 30 Aug 2004 10:39:49 +0000 (GMT) (envelope-from dsnofe@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 30 Aug 2004 03:39:49 -0700 Received: from 218.80.194.83 by bay11-dav44.bay11.hotmail.com with DAV; Mon, 30 Aug 2004 10:39:48 +0000 X-Originating-IP: [218.80.194.83] X-Originating-Email: [dsnofe@msn.com] X-Sender: dsnofe@msn.com From: "Deng XueFeng" To: "Cyrille Lefevre" , References: <200408291848.i7TImAq8072080@mail.gits.dyndns.org> <098401c48e76$6772d300$7890a8c0@gits.invalid> Date: Mon, 30 Aug 2004 18:39:44 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 30 Aug 2004 10:39:49.0055 (UTC) FILETIME=[AC926CF0:01C48E7D] Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 10:39:49 -0000 dGhlIHBhdGNoIHN0aWxsIG5lZWQgc29tZSBtb3JlIHdvcmtzLg0KDQotLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tIA0KRnJvbTogIkN5cmlsbGUgTGVmZXZyZSIgPGNsZWZldnItY3VycmVudEA5 b25saW5lLmZyPg0KVG86IDxjdXJyZW50QGZyZWVic2Qub3JnPg0KU2VudDogTW9uZGF5LCBBdWd1 c3QgMzAsIDIwMDQgNTo0NyBQTQ0KU3ViamVjdDogUmU6IFtQQVRDSCBUTyBURVNUXSBWRVNBIFsx MDI0eDc2OF0gbW9kZSBzdXBwb3J0IGZvciBGcmVlQlNELUNVUlJFTlQNCg0KDQo+IFBSIzcxMTQy IChodHRwOi8vd3d3LmZyZWVic2Qub3JnL2NnaS9xdWVyeS1wci5jZ2k/cHI9NzExNDIpDQo+IGhh cyBqdXN0IGJlZW4gc3VibWl0dGVkIHcvIHRoZSAic3RhdGljIHZvaWQiIGZpeC4NCj4gDQo+IFBT IDogdGhlIHZpZGNvbnRyb2wgInNob3dpbmcgdGhlIG1vdXNlOiBJbnZhbGlkIGFyZ3VtZW50Ig0K PiBlcnJvciBtZXNzYWdlIGhhcyBub3QgYmVlbiBmaXhlZCwgeWV0Lg0KPiANCj4gQ3lyaWxsZSBM ZWZldnJlLg0KPiAtLSANCj4gaG9tZTogbWFpbHRvOmN5cmlsbGUubGVmZXZyZUBsYXBvc3RlLm5l dA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBm cmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0DQo+IGh0dHA6Ly9saXN0cy5m cmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtY3VycmVudA0KPiBUbyB1bnN1YnNj cmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1jdXJyZW50LXVuc3Vic2NyaWJlQGZyZWVi c2Qub3JnIg0KPg== From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 11:00:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC1AE16A4CE for ; Mon, 30 Aug 2004 11:00:05 +0000 (GMT) Received: from KVIW06.KVI.NL (KVIW06.KVI.nl [129.125.15.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50CF043D45 for ; Mon, 30 Aug 2004 11:00:05 +0000 (GMT) (envelope-from A.S.Usov@KVI.nl) Received: from KVIS10.KVI.nl ("port 49171"@KVIS10.KVI.nl [129.125.27.60]) <01LE9YF1DHX0D3Z2WH@KVI.nl> for freebsd-current@freebsd.org; Mon, 30 Aug 2004 12:59:48 +0200 (MET DST) Received: from KVIW14.KVI.nl by KVIS10.KVI.nl (AvMailGate-2.0.2-8) id 22784-48D8B9FC; Mon, 30 Aug 2004 12:59:47 +0200 Received: from kvip88 ("port 49203"@KVIP88.KVI.nl [129.125.15.152]) <01LE9YESHQHID3Z2X6@KVI.nl> for freebsd-current@freebsd.org; Mon, 30 Aug 2004 12:59:36 +0200 (MET DST) Date: Mon, 30 Aug 2004 12:51:38 +0200 From: "Alexander S. Usov" To: freebsd-current@freebsd.org Message-id: <200408301251.38700.A.S.Usov@kvi.nl> Organization: KVI MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline User-Agent: KMail/1.6.2 X-AntiVirus: checked by AntiVir MailGate (version: 2.0.2-8; AVE: 6.27.0.6; VDF: 6.27.0.37; host: kvi.nl) Subject: 5.3-BETA2 hangs during cdrom detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 11:00:05 -0000 Hi! I have a problems installing 5.3-BETA1 & BETA2 on my pc. The configuration is like this: motherboard -- AOpen AX4GR based on i845G and ICH4. On the first ide channel there is an HDD, and on the second channel -- CDROM. I am not sure about the exact model, but FreeBSD 5.2.1-p9 detects it as . The problem is, that FreeBSD somehow incorrectly detects the absence of the slave device on the second ata channel, and tries to detect it. On 5.2.1 it looks like this: ..... ad0: 76345MB [155114/16/63] at ata0-master UDMA100 ata1-slave: FAILURE - ATA_IDENTIFY no interrupt ata1-slave: FAILURE - ATA_IDENTIFY status=7f error=7f LBA=0 ata1-slave: FAILURE - ATA_IDENTIFY no interrupt acd0: CDROM at ata1-master WDMA2 ...... With 5.3 I am getting only the ata1-slave: FAILURE - ATA_IDENTIFY status=7f error= 7f LBA=0 and it hangs. I have tried replacing the cdrom with different hdd and putting in as a slave on the first channel -- both cases work. Also booting in safe mode or without acpi doesn't helps. Unfortunately it's not too easy to get a dmesg from it, but I can try to write it down. -- Best regards, Alexander. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 11:14:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F39016A4CE for ; Mon, 30 Aug 2004 11:14:33 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id E35C143D60 for ; Mon, 30 Aug 2004 11:14:32 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i7UBEVVr098049; Mon, 30 Aug 2004 13:14:31 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <41330BF7.9080704@DeepCore.dk> Date: Mon, 30 Aug 2004 13:13:59 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alexander S. Usov" References: <200408301251.38700.A.S.Usov@kvi.nl> In-Reply-To: <200408301251.38700.A.S.Usov@kvi.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA2 hangs during cdrom detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 11:14:33 -0000 Alexander S. Usov wrote: > Hi! >=20 > I have a problems installing 5.3-BETA1 & BETA2 on my pc. >=20 > The configuration is like this: > motherboard -- AOpen AX4GR based on i845G and ICH4. > On the first ide channel there is an HDD, and on the second channel -- = CDROM. > I am not sure about the exact model, but FreeBSD 5.2.1-p9 detects it as= =20 > . >=20 > The problem is, that FreeBSD somehow incorrectly detects the absence of= the=20 > slave device on the second ata channel, and tries to detect it. > On 5.2.1 it looks like this: > ..... > ad0: 76345MB [155114/16/63] at ata0-master UDMA100 > ata1-slave: FAILURE - ATA_IDENTIFY no interrupt > ata1-slave: FAILURE - ATA_IDENTIFY status=3D7f CORRECTABLE,INDEX,ERROR> error=3D7f NID_NOT_FOUND,MEDIA_CHANGE_REQEST,ABORTED,NO_MEDIA,ILLEGAL_LENGTH> LBA=3D= 0 > ata1-slave: FAILURE - ATA_IDENTIFY no interrupt > acd0: CDROM at ata1-master WDMA2 > ...... >=20 > With 5.3 I am getting only the=20 > ata1-slave: FAILURE - ATA_IDENTIFY status=3D7f CORRECTABLE,INDEX,ERROR> error=3D 7f NID_NOT_FOUND,MEDIA_CHANGE_REQEST,ABORTED,NO_MEDIA,ILLEGAL_LENGTH> LBA=3D= 0 > and it hangs. > I have tried replacing the cdrom with different hdd and putting in as a= slave=20 > on the first channel -- both cases work. This has been fixed in -current some time ago, but has not been MFC'd to = the RELENG_5 branch yet... -S=F8ren From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 12:40:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA20216A4CF for ; Sun, 29 Aug 2004 12:40:55 +0000 (GMT) Received: from dastardly.newsbastards.org.72.27.172.IN-addr.ARPA.NOSPAM.dyndns.dk (80-219-172-255.dclient.hispeed.ch [80.219.172.255]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4144943D48 for ; Sun, 29 Aug 2004 12:40:54 +0000 (GMT) (envelope-from bounce@NOSPAM.dyndns.dk) Received: from Mail.NOSPAM.DynDNS.dK (ipv6.NOSPAM.dyndns.dk [2002:50db:acff:0:220:afff:fed4:dbcb]) (8.11.6/8.11.6-SPAMMERS-DeLiGHt) with ESMTP id i7TCemL02198 verified NO) for ; Sun, 29 Aug 2004 14:40:52 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Received: (from beer@localhost) by Mail.NOSPAM.DynDNS.dK (8.11.6/FNORD) id i7TCemk02197; Sun, 29 Aug 2004 14:40:48 +0200 (CEST) (envelope-from bounce@NOSPAM.dyndns.dk) Date: Sun, 29 Aug 2004 14:40:48 +0200 (CEST) Message-Id: <200408291240.i7TCemk02197@Mail.NOSPAM.DynDNS.dK> X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: beer set sender to bounce@NOSPAM.dyndns.dk using -f X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed from queue /tmp X-Authentication-Warning: localhost.newsbastards.org.72.27.172.IN-addr.A: Processed by beer with -C /etc/mail/sendmail.cf-LOCAL From: Barry Bouwsma X-Mailman-Approved-At: Mon, 30 Aug 2004 11:38:41 +0000 cc: current@freebsd.org Subject: RELENG_5 buildworld failures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 12:40:56 -0000 [keep replies to the list and I'll catch up next time I'm online, thanks] The beer's on me if this hasn't been fixed -- source updated late 22.Aug, haven't been online since then. I've just updated my source but haven't done a build, and it looks like there's still one problem that has not been addressed, just from reading the latest updates. NOT verified yet. The following makefile seems to need attention to get a crossbuild (from 4.x) to succeed -- failures in _depend step at first... --- /dist/src/FreeBSD5-src/source-hacks/sys/modules/linprocfs/Makefile-ORIG Wed Nov 19 06:08:26 2003 +++ /dist/src/FreeBSD5-src/source-hacks/sys/modules/linprocfs/Makefile-IS_THIS_S TILL_NEEDED Wed Aug 25 07:45:41 2004 @@ -6,4 +6,9 @@ SRCS= vnode_if.h \ linprocfs.c +# XXX HACK from current +opt_compat.h: + touch ${.TARGET} + + .include Note that this is identical to HEAD -- well, kinda. I don't see a MFC to RELENG_5 for this. Maybe it's been handled somewhere else. If so, the beer's on me too. Patch above is ugly and cut-n-pasted. See 1.12 of this file. The other problem that I hit appears to have been addressed in 1.70.2.3 of sys/netinet/ip_fw2.c,v (identical to my hack), so is probably no longer needed. I'll be building again with the source I've just updated and will offer my apologies if the above isn't needed, in about another week. (Slow machines and only sporadic access here) thanks barry bouwsma From owner-freebsd-current@FreeBSD.ORG Sun Aug 29 20:56:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A99816A4CE for ; Sun, 29 Aug 2004 20:56:15 +0000 (GMT) Received: from kiuru.kpnet.fi (kiuru.kpnet.fi [193.184.122.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21A1043D5A for ; Sun, 29 Aug 2004 20:56:14 +0000 (GMT) (envelope-from midian@ihme.org) Received: from [192.168.1.57] (adsl-36-92.regionline.fi [194.211.36.92]) by kiuru.kpnet.fi (8.12.8/8.12.8) with ESMTP id i7TKuD77031959; Sun, 29 Aug 2004 23:56:13 +0300 Date: Sun, 29 Aug 2004 23:56:03 +0300 (EEST) From: =?iso-8859-1?Q?Markus_H=E4stbacka?= X-X-Sender: midian@midi.ihme.net To: Christopher Nehren In-Reply-To: <20040828201403.GA797@prophecy.dyndns.org> Message-ID: <20040829235244.G6505@midi.ihme.net> References: <20040828025829.GA51618@prophecy.dyndns.org> <20040828144822.GA662@prophecy.dyndns.org> <20040828201403.GA797@prophecy.dyndns.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Mon, 30 Aug 2004 11:38:41 +0000 cc: freebsd-current@freebsd.org cc: "M. Warner Losh" Subject: Re: USB keyboard problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 29 Aug 2004 20:56:15 -0000 On Sat, 28 Aug 2004, Christopher Nehren wrote: > On Sat, Aug 28, 2004 at 15:43:56 EDT, M. Warner Losh scribbled these > curious markings: >> So current from aug 15th works, but current from today with aug 15th >> usb doesn't. Is that correct? > > Yes. Same for August 14th, and 13th. > Maybe this is not a usb problem? Maybe it's a problem in the keyboard driver? The keyboard driver has other problems too, for example: I have a keyboard with all these extra buttons, and if my keyboard is plugged in the ps2 port (whatever version of freebsd, 5.2.1, 4.10 etc.) the keys print some weird letter combinations to the console outside X, but if it's plugged into the usb port the keys don't have any life. FYI: my keyboard is a Logitech Internet Navigator SE. Markus From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 00:05:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B31516A4CE for ; Mon, 30 Aug 2004 00:05:46 +0000 (GMT) Received: from shub-internet.kew.com (h00062574bf3c.ne.client2.attbi.com [66.30.223.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id E85EF43D31 for ; Mon, 30 Aug 2004 00:05:44 +0000 (GMT) (envelope-from ahd@kew.com) Received: by shub-internet.kew.com (Postfix, from userid 1015) id 5095712352; Sun, 29 Aug 2004 20:05:44 -0400 (EDT) Received: from kendra (kendra.hh.kew.com [192.168.203.132]) by shub-internet.kew.com (Postfix) with ESMTP id 51580122A7 for ; Sun, 29 Aug 2004 20:05:41 -0400 (EDT) From: "Andrew H. Derbyshire" To: Date: Sun, 29 Aug 2004 20:05:38 -0400 Organization: Kendra Electronic Wonderworks, Stoneham, MA (http://www.kew.com) Message-ID: <012301c48e25$14924180$84cba8c0@hh.kew.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0124_01C48E03.8D80A180" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-Mailman-Approved-At: Mon, 30 Aug 2004 11:38:41 +0000 Subject: PCI SIO devices hog interrupts, cause lock order problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 00:05:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0124_01C48E03.8D80A180 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Attached are two boot logs with sources as of today (Sunday 8/28/2004) = with both the standard GENERIC kernel configuration and the generic kernel modified to include a single additional device, the PUC device. The = system is a Dell GX300 Dual PIII/733 with PCI 3COM Ethernet, a 3COM internal = modem, and 29160 SCSI. =20 Basically, any PCI SIO device hogs its interrupt if the PUC device is = not also in the kernel, and this causes real problems for any environment = like mine where pulling the modem is not trivial. Does the distributed = GENERIC kernel have room for the PUC device? Are there side effects that PUC = should be excluded from GENERIC? As a bonus, there appears to be a bug with kernel locking exposed by the problem. With the stock generic kernel, the XL device reports it = couldn't map the interrupt, and then a lock order reversal is reported. (See the attached log for the gory details). Suggestions? The machine is pure test mode now. I can test either CVS updated source = or private patches. ------=_NextPart_000_0124_01C48E03.8D80A180 Content-Type: application/octet-stream; name="generic.log" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="generic.log" ahd@xena.hh.kew.com:/scratch/xena/obj/scratch/current/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (728.44-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x683 Stepping =3D 3 Features=3D0x383fbff real memory =3D 1073340416 (1023 MB) avail memory =3D 1040789504 (992 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xf0000000-0xf3ffffff at = device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pcib2: at device 30.0 on pci0 pci2: on pcib2 sio0: configured irq 18 not in bitmap of probed irqs 0x80 sio0: port may not be enabled sio0: <3COM PCI FaxModem> port 0xecf8-0xecff irq 18 at device 9.0 on = pci2 sio0: moving to sio4 sio4: type 16550A ahc0: port 0xe800-0xe8ff mem = 0xf8fff000-0xf8ffffff irq 19 at device 10.0 on pci2 ahc0: [GIANT-LOCKED] aic7892: Ultra160 Wide Channel A, SCSI Id=3D7, 32/253 SCBs pcib3: at device 11.0 on pci2 pci3: on pcib3 ohci0: mem 0xfafff000-0xfaffffff irq 16 at = device 8.0 on pci3 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0 usb0: on ohci0 usb0: USB revision 1.0 uhub0: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xfaffe000-0xfaffefff irq 17 at = device 8.1 on pci3 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0 usb1: on ohci1 usb1: USB revision 1.0 uhub1: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci3: at device 8.2 (no driver attached) fwohci0: mem = 0xfaff8000-0xfaffbfff,0xfaffd000-0xfaffd7ff irq 16 at device 12.0 on = pci3 fwohci0: [GIANT-LOCKED] fwohci0: OHCI version 1.10 (ROM=3D1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:50:42:b5:c0:0c:f7:9d fwohci0: Phy 1394a available S400, 3 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:50:42:0c:f7:9d fwe0: Ethernet address: 02:50:42:0c:f7:9d sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=3D0xc800ffc0, gen=3D1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) firewire0: bus manager 0 (me) xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xec00-0xec7f mem = 0xf8ffec00-0xf8ffec7f irq 18 at device 12.0 on pci2 xl0: couldn't map interrupt lock order reversal 1st 0xc24aa2dc xl0 (network driver) @ = /scratch/current/src/sys/pci/if_xl.c:1695 2nd 0xc0ae0060 ACPI root bus (ACPI root bus) @ = /scratch/current/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi.c:841= KDB: stack backtrace: kdb_backtrace(c08b54f3,c0ae0060,c0ada063,c0ada063,c0ada468) at = kdb_backtrace+0x2e witness_checkorder(c0ae0060,9,c0ada468,349,0) at = witness_checkorder+0x6a6 _sx_xlock(c0ae0060,c0ada468,349,c0c217b8,c068f5c0) at _sx_xlock+0x7e acpi_release_resource(c22ee600,c23a2000,3,14,c23abe00) at = acpi_release_resource+0x23 bus_generic_release_resource(c2293b80,c23a2000,3,14,c23abe00) at = bus_generic_release_resource+0x82 resource_list_release(c23a3204,c23a3080,c23a2000,3,14) at = resource_list_release+0x84 bus_generic_rl_release_resource(c23a3080,c23a2000,3,14,c23abe00) at = bus_generic_rl_release_resource+0x86 bus_generic_release_resource(c23a2a80,c23a2000,3,14,c23abe00) at = bus_generic_release_resource+0x82 resource_list_release(c23a3204,c23a2100,c23a2000,3,14) at = resource_list_release+0x13b bus_generic_rl_release_resource(c23a2100,c23a2000,3,14,c23abe00) at = bus_generic_rl_release_resource+0x86 bus_release_resource(c23a2000,3,14,c23abe00,3) at = bus_release_resource+0x7f xl_detach(c23a2000,c08c55bc,c0c2198c,0,ffffffff) at xl_detach+0x189 xl_attach(c23a2000,c2339050,c08dd0d0,c23a2000,c23a2000) at = xl_attach+0xfa1 device_attach(c23a2000,c23a2000,6,c22686c0,c23a2000) at = device_attach+0x6a device_probe_and_attach(c23a2000,c23a2a80,c0c21a3c,c0ac8e6c,c23a2100) at = device_probe_and_attach+0xe1 bus_generic_attach(c23a2100,6,c22686c0,1,c0ac8bf4) at = bus_generic_attach+0x28 acpi_pci_attach(c23a2100,c23a2100,c233adc0,c23a2100,c23a2100) at = acpi_pci_attach+0xec device_attach(c23a2100,c23a2100,2e697063,2e696370,c23a2100) at = device_attach+0x6a device_probe_and_attach(c23a2100,c23a3080,c0c21ac0,c0ac8fc2,c23a2a80) at = device_probe_and_attach+0xe1 bus_generic_attach(c23a2a80,c23a2a80,c23a7570,2,c0ac8839) at = bus_generic_attach+0x28 acpi_pcib_attach(c23a2a80,c23a7570,2,c23a2a80,c22686c0) at = acpi_pcib_attach+0x14e acpi_pcib_pci_attach(c23a2a80,c2370850,c08dd0d0,c23a2a80,c23a2a80) at = acpi_pcib_pci_attach+0x88 device_attach(c23a2a80,c23a2a80,6,c2268800,c23a2a80) at = device_attach+0x6a device_probe_and_attach(c23a2a80,c2293b80,c0c21b74,c0ac8e6c,c23a3080) at = device_probe_and_attach+0xe1 bus_generic_attach(c23a3080,6,c2268800,1,c0ac8bf4) at = bus_generic_attach+0x28 acpi_pci_attach(c23a3080,c2372050,c08dd0d0,c23a3080,c23a3080) at = acpi_pci_attach+0xec device_attach(c23a3080,c23a3080,2e697063,2e696370,c23a3080) at = device_attach+0x6a device_probe_and_attach(c23a3080,c22ee600,c0c21bf8,c0ac8fc2,c2293b80) at = device_probe_and_attach+0xe1 bus_generic_attach(c2293b80,c2293b80,c22d5014,0,c0ac539d) at = bus_generic_attach+0x28 acpi_pcib_attach(c2293b80,c22d5014,0,c08dd0d0,c2293b80) at = acpi_pcib_attach+0x14e acpi_pcib_acpi_attach(c2293b80,c2371050,c08dd0d0,c2293b80,c2293b80) at = acpi_pcib_acpi_attach+0x20a device_attach(c2293b80,c2293b80,c08dd0c0,c0adf5a8,c2293b80) at = device_attach+0x6a device_probe_and_attach(c2293b80,4,c0c21c98,c0ac60eb,c22ee600) at = device_probe_and_attach+0xe1 bus_generic_attach(c22ee600,c22ee600,c22782c0,1,c22ee580) at = bus_generic_attach+0x28 acpi_probe_children(c22ee600,1013749,c22ee600,c22ee600,0) at = acpi_probe_children+0x63 acpi_attach(c22ee600,c2375850,c08dd0d0,c22ee600,c22ee600) at = acpi_attach+0x523 device_attach(c22ee600,c22ee600,c2332bf0,c0c21d08,c22ee600) at = device_attach+0x6a device_probe_and_attach(c22ee600,c22ee780,c0c21d18,c083dc6a,c22ee780) at = device_probe_and_attach+0xe1 bus_generic_attach(c22ee780,c22ee780,c0c21d38,c067e8fa,c22ee780) at = bus_generic_attach+0x28 nexus_attach(c22ee780,c2354850,c08dd0d0,c22ee780,c22ee780) at = nexus_attach+0x1a device_attach(c22ee780,c22ee780,c226aa84,c0947bd0,c22ee780) at = device_attach+0x6a device_probe_and_attach(c22ee780,c226aa84,c0c21d80,c082ace9,c227c780) at = device_probe_and_attach+0xe1 root_bus_configure(c227c780,c08d0cfc,0,c0c21d98,c0638e35) at = root_bus_configure+0x28 configure(0,c1e000,c1ec00,c1e000,0) at configure+0x29 mi_startup() at mi_startup+0xb5 begin() at begin+0x2c device_attach: xl0 attach returned 6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port = 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: port 0xff80-0xff9f irq 19 at = device 31.2 on pci0 uhci0: [GIANT-LOCKED] usb2: on uhci0 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: at device 31.3 (no driver attached) pci0: at device 31.5 (no driver attached) fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on = acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 can't re-use a leaf (%desc)! can't re-use a leaf (%driver)! can't re-use a leaf (%location)! can't re-use a leaf (%pnpinfo)! can't re-use a leaf (%parent)! sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A orm0: at iomem = 0xcf800-0xcffff,0xc9000-0xcf7ff,0xc0000-0xc8fff on isa0 pmtimer0 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 Timecounters tick every 10.000 msec ATAPI_RESET time =3D 30us acd0: DVDROM at ata0-master UDMA66 Waiting 15 seconds for SCSI devices to settle da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged = Queueing Enabled da0: 35003MB (71687370 512 byte sectors: 255H 63S/T 4462C) da1 at ahc0 bus 0 target 2 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 160.000MB/s transfers (80.000MHz, offset 31, 16bit), Tagged = Queueing Enabled da1: 17366MB (35566499 512 byte sectors: 255H 63S/T 2213C) SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/da0s2a ------=_NextPart_000_0124_01C48E03.8D80A180 Content-Type: application/octet-stream; name="generic_puc.log" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="generic_puc.log" ahd@xena.hh.kew.com:/scratch/xena/obj/scratch/current/src/sys/GENERIC_PUC= =0DWARNING: WITNESS option enabled, expect reduced = performance.=0DTimecounter "i8254" frequency 1193182 Hz quality 0=0DCPU: = Intel Pentium III (728.44-MHz 686-class CPU)=0DOrigin =3D "GenuineIntel" = Id =3D 0x683 Stepping =3D = 3=0DFeatures=3D0x383fbff=0Dreal memory =3D 1073340416 = (1023 MB)=0Davail memory =3D 1040789504 (992 MB)=0DACPI APIC Table: = =0DFreeBSD/SMP: Multiprocessor System Detected: 2 = CPUs=0Dcpu0 (BSP): APIC ID: 0=0Dcpu1 (AP): APIC ID: 1=0Dioapic0: = Changing APIC ID to 2=0Dioapic0 irqs 0-23 on = motherboard=0Dnpx0: [FAST]=0Dnpx0: on = motherboard=0Dnpx0: INT 16 interface=0Dacpi0: on = motherboard=0Dacpi0: Power Button (fixed)=0DTimecounter "ACPI-fast" = frequency 3579545 Hz quality 1000=0Dacpi_timer0: <24-bit timer at = 3.579545MHz> port 0x808-0x80b on acpi0=0Dcpu0: on = acpi0=0Dcpu1: on acpi0=0Dpcib0: port = 0xcf8-0xcff on acpi0=0Dpci0: on pcib0=0Dagp0: mem 0xf0000000-0xf3ffffff at device 0.0 on = pci0=0Dpcib1: at device 1.0 on pci0=0Dpci1: = on pcib1=0Dpci1: at device 0.0 (no driver = attached)=0Dpcib2: at device 30.0 on pci0=0Dpci2: = on pcib2=0Dpuc0: port 0xecf8-0xecff irq 18 at device 9.0 on pci2=0Dsio4: on puc0=0Dsio4: type = 16550A=0Dsio4: unable to activate interrupt in fast mode - using normal = mode=0Dahc0: port 0xe800-0xe8ff = mem 0xf8fff000-0xf8ffffff irq 19 at device 10.0 on pci2=0Dahc0: = [GIANT-LOCKED]=0Daic7892: Ultra160 Wide Channel A, SCSI Id=3D7, 32/253 = SCBs=0Dpcib3: at device 11.0 on pci2=0Dpci3: = on pcib3=0Dohci0: mem = 0xfafff000-0xfaffffff irq 16 at device 8.0 on pci3=0Dohci0: = [GIANT-LOCKED]=0Dusb0: OHCI version 1.0=0Dusb0: on ohci0=0Dusb0: USB revision 1.0=0Duhub0: NEC OHCI root = hub, class 9/0, rev 1.00/1.00, addr 1=0Duhub0: 3 ports with 3 removable, = self powered=0Dohci1: mem = 0xfaffe000-0xfaffefff irq 17 at device 8.1 on pci3=0Dohci1: = [GIANT-LOCKED]=0Dusb1: OHCI version 1.0=0Dusb1: on ohci1=0Dusb1: USB revision 1.0=0Duhub1: NEC OHCI root = hub, class 9/0, rev 1.00/1.00, addr 1=0Duhub1: 2 ports with 2 removable, = self powered=0Dpci3: at device 8.2 (no driver = attached)=0Dfwohci0: mem = 0xfaff8000-0xfaffbfff,0xfaffd000-0xfaffd7ff irq 16 at device 12.0 on = pci3=0Dfwohci0: [GIANT-LOCKED]=0Dfwohci0: OHCI version 1.10 = (ROM=3D1)=0Dfwohci0: No. of Isochronous channels is 4.=0Dfwohci0: EUI64 = 00:50:42:b5:c0:0c:f7:9d=0Dfwohci0: Phy 1394a available S400, 3 = ports.=0Dfwohci0: Link S400, max_rec 2048 bytes.=0Dfirewire0: = on fwohci0=0Dfwe0: on = firewire0=0Dif_fwe0: Fake Ethernet address: 02:50:42:0c:f7:9d=0Dfwe0: = Ethernet address: 02:50:42:0c:f7:9d=0Dsbp0: = on firewire0=0Dfwohci0: Initiate bus reset=0Dfwohci0: = node_id=3D0xc800ffc0, gen=3D1, CYCLEMASTER mode=0Dfirewire0: 1 nodes, = maxhop <=3D 0, cable IRM =3D 0 (me)=0Dfirewire0: bus manager 0 = (me)=0Dxl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xec00-0xec7f mem = 0xf8ffec00-0xf8ffec7f irq 18 at device 12.0 on pci2=0Dmiibus0: = on xl0=0Dxlphy0: <3c905C 10/100 internal PHY> on miibus0=0Dxlphy0: = 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto=0Dxl0: Ethernet = address: 00:b0:d0:2b:93:1e=0Dxl0: [GIANT-LOCKED]=0Disab0: at device 31.0 on pci0=0Disa0: on isab0=0Datapci0: = port = 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on = pci0=0Data0: channel #0 on atapci0=0Data1: channel #1 on = atapci0=0Duhci0: port 0xff80-0xff9f = irq 19 at device 31.2 on pci0=0Duhci0: [GIANT-LOCKED]=0Dusb2: on uhci0=0Dusb2: USB revision 1.0=0Duhub2: = Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1=0Duhub2: 2 ports = with 2 removable, self powered=0Dpci0: at device = 31.3 (no driver attached)=0Dpci0: at device 31.5 (no = driver attached)=0Dfdc0: port = 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0=0Dfdc0: FIFO enabled, 8 bytes = threshold=0Dfd0: <1440-KB 3.5" drive> on fdc0 drive 0=0Datkbdc0: = port 0x64,0x60 irq 1 on acpi0=0Datkbd0: = flags 0x1 irq 1 on atkbdc0=0Dkbd0 at atkbd0=0Datkbd0: = [GIANT-LOCKED]=0Dpsm0: irq 12 on atkbdc0=0Dpsm0: = [GIANT-LOCKED]=0Dpsm0: model IntelliMouse, device ID 3=0Dsio0 port = 0x3f8-0x3ff irq 4 on acpi0=0Dsio0: type 16550A=0Dsio1 port 0x2f8-0x2ff = irq 3 on acpi0=0Dsio1: type 16550A=0Dorm0: at iomem = 0xcf800-0xcffff,0xc9000-0xcf7ff,0xc0000-0xc8fff on isa0=0Dpmtimer0 on = isa0=0Dda0 at ahc0 bus 0 target 0 lun 0=0Dipfw2 initialized, divert = disabled, rule-based forwarding disabled, default to deny, logging = disabled=0D ------=_NextPart_000_0124_01C48E03.8D80A180-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 06:30:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 457C316A4CE; Mon, 30 Aug 2004 06:30:26 +0000 (GMT) Received: from matrix.gatewaynet.com (matrix.gatewaynet.com [217.19.69.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D9F543D46; Mon, 30 Aug 2004 06:30:25 +0000 (GMT) (envelope-from achill@matrix.gatewaynet.com) Received: from matrix.gatewaynet.com (localhost.localdomain [127.0.0.1]) by matrix.gatewaynet.com (8.12.8/8.12.8) with ESMTP id i7U5hZsR028746; Mon, 30 Aug 2004 08:43:35 +0300 Received: from localhost (achill@localhost)i7U5hZQk028742; Mon, 30 Aug 2004 08:43:35 +0300 Date: Mon, 30 Aug 2004 08:43:35 +0300 (EEST) From: Achilleus Mantzios To: Tim Robbins In-Reply-To: <20040829120406.GA52614@cat.robbins.dropbear.id.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Mon, 30 Aug 2004 11:38:41 +0000 cc: freebsd-current@freebsd.org Subject: Re: Transition from 5.1-RELEASE-p10 to 5.3-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 06:30:26 -0000 O kyrios Tim Robbins egrapse stis Aug 29, 2004 : > On Sun, Aug 29, 2004 at 09:58:41AM +0300, Achilleus Mantzios wrote: > > Hi, after make buildworld,make buildkernel, make install kernel > > i rebooted single-user, just to find out that > > ls, mount, etc.. gave > > ls exited with signal 12, > > bad system call. > > > > After i rebooted with the old 5.1 kernel and did make buildkernel > > *with* COMPAT_FREEBSD4, i could reboot single user with > > 5.3 and run ls,mount, etc... just fine. > > This was covered by the 20031112 entry in /usr/src/UPDATING. As a general > rule, you should use GENERIC instead of a custom kernel configuration (or a > GENERIC config from a previous release) when updating, at least on branches > that aren't marked -STABLE. > > > What has COMPAT_FREEBSD4 has to do, since i *didnt* have it in my > > 5.1-RELEASE-p10, and no FreeBSD 4.x programs were run? > > I believe the rationale was that no -STABLE releases after FreeBSD 4 > used the old statfs() interface. I agree that the name is misleading. > Thanx. > > Tim > -- -Achilleus From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 07:58:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD46916A4CE; Mon, 30 Aug 2004 07:58:56 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82BAA43D48; Mon, 30 Aug 2004 07:58:50 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1C1h3w-0001S1-4A; Mon, 30 Aug 2004 11:58:48 +0400 From: Vladimir Grebenschikov To: modile@freebsd.org Content-Type: multipart/mixed; boundary="=-FZrzlYyzm566zgo9aokI" Organization: SWsoft Date: Mon, 30 Aug 2004 11:58:47 +0400 Message-Id: <1093852727.864.11.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.93FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov X-Mailman-Approved-At: Mon, 30 Aug 2004 11:38:41 +0000 cc: "current@freebsd.org" Subject: acpi_video on SONY VAIO PCG-Z1 [was: acpi_video users needed] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 07:58:56 -0000 --=-FZrzlYyzm566zgo9aokI Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi Is any chance to make acpi_video work on SONY VAIO PCG-Z1 ? acpi_video.ko loads well, but does not report anything, and does not add hw.acpi.video subtree. Please advise. kernel is latest HEAD (cvsup 28 Aug). acpidump -dt and devinfo -v in attachment. dmesg: Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-CURRENT #1: Sat Aug 28 14:39:19 MSD 2004 root@vbook.fbsd.ru:/usr/obj/usr/src/sys/VBOOK Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1700MHz (1686.97-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x695 Stepping = 5 Features=0xa7e9f9bf real memory = 536281088 (511 MB) avail memory = 515035136 (491 MB) netsmb_dev: loaded acpi0: on motherboard acpi_ec0: port 0x66,0x62 on acpi0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_tz0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) uhci0: port 0x1800-0x181f irq 9 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 9 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhub2: Texas Instruments UT-USB41 hub, class 9/0, rev 1.10/1.10, addr 2 uhub2: 4 ports with 4 removable, self powered ukbd0: BTC USB KMp, rev 1.00/1.00, addr 3, iclass 3/1 kbd1 at ukbd0 ums0: BTC USB KMp, rev 1.00/1.00, addr 3, iclass 3/1 ums0: 3 buttons ums1: Microsoft Microsoft IntelliMouse\M-. Explorer, rev 1.10/1.14, addr 4, iclass 3/1 ums1: 5 buttons and Z dir. uhci2: port 0x1840-0x185f at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered umass0: Sony USB Memory Stick Slot, rev 2.00/1.10, addr 2 umass0: Get Max Lun not supported (STALLED) ehci0: mem 0xd0000000-0xd00003ff at device 29.7 on pci0 ehci0: [GIANT-LOCKED] ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 ehci_pci_attach: companion usb2 usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 6 ports with 6 removable, self powered umass1: Sony USB Memory Stick Slot, rev 2.00/1.10, addr 2 ehci_idone: need toggle update status=80018d40 nstatus=80008c80 ehci_idone: need toggle update status=80028d40 nstatus=80008c80 umass1: Get Max Lun not supported (STALLED) pcib2: at device 30.0 on pci0 ACPI link \\_SB_.PCI0.LPCB.LNKF has invalid initial irq 3, ignoring pci2: on pcib2 cbb0: irq 9 at device 5.0 on pci2 cardbus0: on cbb0 fwohci0: mem 0xd0202000-0xd02027ff at device 5.1 on pci2 fwohci0: [GIANT-LOCKED] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 08:00:46:03:01:8d:e0:3c fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci2: at device 8.0 (no driver attached) ndis0: mem 0xd0201000-0xd0201fff irq 9 at device 11.0 on pci2 ndis0: [GIANT-LOCKED] ndis0: NDIS API version: 5.1 ndis0: NDIS ERROR: c000138d (unknown error) ndis0: NDIS NUMERRORS: 0 ndis0: init handler failed device_attach: ndis0 attach returned 6 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1860-0x186f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pci0: at device 31.3 (no driver attached) pcm0: port 0x18c0-0x18ff,0x1c00-0x1cff mem 0xd0000800-0xd00008ff,0xd0000c00-0xd0000dff irq 9 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: pci0: at device 31.6 (no driver attached) atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 acpi_cmbat0: on acpi0 acpi_acad0: on acpi0 npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pmtimer0 on isa0 orm0: at iomem 0xdc000-0xdffff,0xd8000-0xdbfff,0xc0000-0xcffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 1686966203 Hz quality 800 Timecounters tick every 10.000 msec ipfw2 initialized, divert enabled, rule-based forwarding disabled, default to deny, logging unlimited acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% ad0: 57231MB [116280/16/63] at ata0-master UDMA100 uhub2: at uhub1 port 1 (addr 2) disconnected umass0: at uhub3 port 1 (addr 2) disconnected umass0: detached ukbd0: detached ums0: detached ums1: detached uhub2: detached uhub2: Texas Instruments UT-USB41 hub, class 9/0, rev 1.10/1.10, addr 2 uhub2: 4 ports with 4 removable, self powered ukbd0: BTC USB KMp, rev 1.00/1.00, addr 3, iclass 3/1 kbd1 at ukbd0 ums0: BTC USB KMp, rev 1.00/1.00, addr 3, iclass 3/1 ums0: 3 buttons ums1: Microsoft Microsoft IntelliMouse\M-. Explorer, rev 1.10/1.14, addr 4, iclass 3/1 ums1: 5 buttons and Z dir. ata1-slave: FAILURE - ATAPI_IDENTIFY no interrupt ata1-slave: FAILURE - ATAPI_IDENTIFY no interrupt ATAPI_RESET time = 180us acd0: CDRW at ata1-master UDMA33 da0 at umass-sim1 bus 1 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 3MB (7904 512 byte sectors: 64H 32S/T 3C) Mounting root from ufs:/dev/ad0s3a fxp0: port 0x4000-0x403f mem 0xd0200000-0xd0200fff irq 9 at device 8.0 on pci2 fxp0: Ethernet address: 08:00:46:c8:45:b3 fxp0: [GIANT-LOCKED] ndis0: mem 0xd0201000-0xd0201fff irq 9 at device 11.0 on pci2 ndis0: [GIANT-LOCKED] ndis0: NDIS API version: 5.1 ndis0: Ethernet address: 00:0e:35:03:82:74 ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 5.5Mbps 11Mbps ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto -- Vladimir B. Grebenschikov SWsoft Inc. vova@sw-soft.com --=-FZrzlYyzm566zgo9aokI Content-Disposition: attachment; filename=acpidump-dt.txt Content-Type: text/plain; name=acpidump-dt.txt; charset=KOI8-R Content-Transfer-Encoding: base64 LyoNCiAgUlNEIFBUUjogT0VNPVBUTFRELCBBQ1BJX1Jldj0xLjB4ICgwKQ0KCVJTRFQ9MHgxZmY3 ODA2YiwgY2tzdW09NTYNCiAqLw0KLyoNCiAgUlNEVDogTGVuZ3RoPTQ4LCBSZXZpc2lvbj0xLCBD aGVja3N1bT0yNDksDQoJT0VNSUQ9U09OWSwgT0VNIFRhYmxlIElEPUcwLCBPRU0gUmV2aXNpb249 MHgyMDAzMTEyMSwNCglDcmVhdG9yIElEPVBUTCwgQ3JlYXRvciBSZXZpc2lvbj0weDANCglFbnRy aWVzPXsgMHgxZmY3YmVjMiwgMHgxZmY3YmZkOCwgMHgxZmY3ODA5YiB9DQogKi8NCi8qDQogIEZB Q1A6IExlbmd0aD0xMzIsIFJldmlzaW9uPTIsIENoZWNrc3VtPTEyMywNCglPRU1JRD1TT05ZLCBP RU0gVGFibGUgSUQ9RzAsIE9FTSBSZXZpc2lvbj0weDIwMDMxMTIxLA0KCUNyZWF0b3IgSUQ9UFRM LCBDcmVhdG9yIFJldmlzaW9uPTB4NTANCiAJRkFDUz0weDFmZjdjZmMwLCBEU0RUPTB4MWZmNzg1 MDcNCglJTlRfTU9ERUw9UElDDQoJUHJlZmVycmVkX1BNX1Byb2ZpbGU9VW5zcGVjaWZpZWQgKDAp DQoJU0NJX0lOVD05DQoJU01JX0NNRD0weGIyLCBBQ1BJX0VOQUJMRT0weGYwLCBBQ1BJX0RJU0FC TEU9MHhmMSwgUzRCSU9TX1JFUT0weDANCglQU1RBVEVfQ05UPTB4ODANCglQTTFhX0VWVF9CTEs9 MHgxMDAwLTB4MTAwMw0KCVBNMWFfQ05UX0JMSz0weDEwMDQtMHgxMDA1DQoJUE0yX0NOVF9CTEs9 MHgxMDIwLTB4MTAyMA0KCVBNX1RNUl9CTEs9MHgxMDA4LTB4MTAwYg0KCUdQRTBfQkxLPTB4MTAy OC0weDEwMmYNCglQX0xWTDJfTEFUPTEgdXMsIFBfTFZMM19MQVQ9MTAwMSB1cw0KCUZMVVNIX1NJ WkU9MCwgRkxVU0hfU1RSSURFPTANCglEVVRZX09GRlNFVD0xLCBEVVRZX1dJRFRIPTMNCglEQVlf QUxSTT0xMywgTU9OX0FMUk09MCwgQ0VOVFVSWT01MA0KCUlBUENfQk9PVF9BUkNIPXs4MDQyfQ0K CUZsYWdzPXtXQklOVkQsUFJPQ19DMSxQV1JfQlVUVE9OLFNMUF9CVVRUT04sUlRDX1M0LFJFU0VU X1JFR30NCglSRVNFVF9SRUc9MHg2NDowWzhdIChJTyksIFJFU0VUX1ZBTFVFPTB4ZmUNCiAqLw0K LyoNCiAgRkFDUzoJTGVuZ3RoPTY0LCBId1NpZz0weDAwMDAwMDAwLCBGaXJtX1dha2VfVmVjPTB4 MDAwMDAwMDANCglHbG9iYWxfTG9jaz0NCglGbGFncz0NCglWZXJzaW9uPTANCiAqLw0KLyoNCiAg RFNEVDogTGVuZ3RoPTE0Nzc5LCBSZXZpc2lvbj0xLCBDaGVja3N1bT0xMDEsDQoJT0VNSUQ9U09O WSwgT0VNIFRhYmxlIElEPUcwLCBPRU0gUmV2aXNpb249MHgyMDAzMTEyMSwNCglDcmVhdG9yIElE PVBUTCwgQ3JlYXRvciBSZXZpc2lvbj0weDEwMDAwMGQNCiAqLw0KLyoNCiAgQk9PVDogTGVuZ3Ro PTQwLCBSZXZpc2lvbj0xLCBDaGVja3N1bT03MSwNCglPRU1JRD1TT05ZLCBPRU0gVGFibGUgSUQ9 RzAsIE9FTSBSZXZpc2lvbj0weDIwMDMxMTIxLA0KCUNyZWF0b3IgSUQ9UFRMLCBDcmVhdG9yIFJl dmlzaW9uPTB4MQ0KICovDQovKg0KICBTU0RUOiBMZW5ndGg9NzI4LCBSZXZpc2lvbj0xLCBDaGVj a3N1bT0yMzcsDQoJT0VNSUQ9U09OWSwgT0VNIFRhYmxlIElEPUcwLCBPRU0gUmV2aXNpb249MHgy MDAzMTEyMSwNCglDcmVhdG9yIElEPVBUTCwgQ3JlYXRvciBSZXZpc2lvbj0weDANCiAqLw0KLyoN CiAqIEludGVsIEFDUEkgQ29tcG9uZW50IEFyY2hpdGVjdHVyZQ0KICogQU1MIERpc2Fzc2VtYmxl ciB2ZXJzaW9uIDIwMDQwNTI3DQogKg0KICogRGlzYXNzZW1ibHkgb2YgL3RtcC9hY3BpZHVtcC5R RHlzcFAsIE1vbiBBdWcgMzAgMTE6NTY6MDYgMjAwNA0KICovDQpEZWZpbml0aW9uQmxvY2sgKCJE U0RULmFtbCIsICJEU0RUIiwgMSwgIlNPTlkiLCAiRzAiLCA1MzcwNzE5MDUpDQp7DQogICAgT3Bl cmF0aW9uUmVnaW9uIChQT1JULCBTeXN0ZW1JTywgMHg4MCwgMHgwMSkNCiAgICBGaWVsZCAoUE9S VCwgQnl0ZUFjYywgTm9Mb2NrLCBQcmVzZXJ2ZSkNCiAgICB7DQogICAgICAgIFA4MEgsICAgOA0K ICAgIH0NCg0KICAgIE9wZXJhdGlvblJlZ2lvbiAoSU9fVCwgU3lzdGVtSU8sIDB4MDgwMCwgMHgw OCkNCiAgICBGaWVsZCAoSU9fVCwgQnl0ZUFjYywgTm9Mb2NrLCBQcmVzZXJ2ZSkNCiAgICB7DQog ICAgICAgIFRSUDAsICAgOA0KICAgIH0NCg0KICAgIE9wZXJhdGlvblJlZ2lvbiAoR1BJTywgU3lz dGVtSU8sIDB4MTE4MCwgMHgzQykNCiAgICBGaWVsZCAoR1BJTywgQnl0ZUFjYywgTm9Mb2NrLCBQ cmVzZXJ2ZSkNCiAgICB7DQogICAgICAgIEdVMDAsICAgOCwgDQogICAgICAgIEdVMDEsICAgOCwg DQogICAgICAgIEdVMDIsICAgOCwgDQogICAgICAgIEdVMDMsICAgOCwgDQogICAgICAgIEdJTzAs ICAgOCwgDQogICAgICAgIEdJTzEsICAgOCwgDQogICAgICAgIEdJTzIsICAgOCwgDQogICAgICAg IEdJTzMsICAgOCwgDQogICAgICAgIE9mZnNldCAoMHgwQyksIA0KICAgICAgICBHTDAwLCAgIDgs IA0KICAgICAgICBHTDAxLCAgIDgsIA0KICAgICAgICBHTDAyLCAgIDgsIA0KICAgICAgICBHTDAz LCAgIDgsIA0KICAgICAgICBPZmZzZXQgKDB4MTgpLCANCiAgICAgICAgR0IwMCwgICA4LCANCiAg ICAgICAgR0IwMSwgICA4LCANCiAgICAgICAgR0IwMiwgICA4LCANCiAgICAgICAgR0IwMywgICA4 LCANCiAgICAgICAgT2Zmc2V0ICgweDJDKSwgDQogICAgICAgIEdJVjAsICAgOCwgDQogICAgICAg IEdJVjEsICAgOCwgDQogICAgICAgIEdJVjIsICAgOCwgDQogICAgICAgIEdJVjMsICAgOCwgDQog ICAgICAgIEdVMDQsICAgOCwgDQogICAgICAgIEdVMDUsICAgOCwgDQogICAgICAgIEdVMDYsICAg OCwgDQogICAgICAgIEdVMDcsICAgOCwgDQogICAgICAgIEdJTzQsICAgOCwgDQogICAgICAgIEdJ TzUsICAgOCwgDQogICAgICAgIEdJTzYsICAgOCwgDQogICAgICAgIEdJTzcsICAgOCwgDQogICAg ICAgICAgICAsICAgMSwgDQogICAgICAgICAgICAsICAgMSwgDQogICAgICAgIENQRU4sICAgMSwg DQogICAgICAgIE9mZnNldCAoMHgzOSksIA0KICAgICAgICBHTDA1LCAgIDgsIA0KICAgICAgICBH TDA2LCAgIDgsIA0KICAgICAgICBHTDA3LCAgIDgNCiAgICB9DQoNCiAgICBPcGVyYXRpb25SZWdp b24gKE1OVlMsIFN5c3RlbU1lbW9yeSwgMHgxRkY3Q0FCNywgMHg0MCkNCiAgICBGaWVsZCAoTU5W UywgQW55QWNjLCBMb2NrLCBQcmVzZXJ2ZSkNCiAgICB7DQogICAgICAgIFBTQUMsICAgOCwgDQog ICAgICAgIFBTREMsICAgOA0KICAgIH0NCg0KICAgIE11dGV4IChNVVRYLCAweDAwKQ0KICAgIE5h bWUgKF9TMCwgUGFja2FnZSAoMHgwMykNCiAgICB7DQogICAgICAgIDB4MDAsIA0KICAgICAgICAw eDAwLCANCiAgICAgICAgMHgwMA0KICAgIH0pDQogICAgTmFtZSAoX1MzLCBQYWNrYWdlICgweDAz KQ0KICAgIHsNCiAgICAgICAgMHgwNSwgDQogICAgICAgIDB4MDUsIA0KICAgICAgICAweDAwDQog ICAgfSkNCiAgICBOYW1lIChfUzQsIFBhY2thZ2UgKDB4MDMpDQogICAgew0KICAgICAgICAweDA2 LCANCiAgICAgICAgMHgwNiwgDQogICAgICAgIDB4MDANCiAgICB9KQ0KICAgIE5hbWUgKF9TNSwg UGFja2FnZSAoMHgwMykNCiAgICB7DQogICAgICAgIDB4MDcsIA0KICAgICAgICAweDA3LCANCiAg ICAgICAgMHgwMA0KICAgIH0pDQogICAgU2NvcGUgKFxfUFIpDQogICAgew0KICAgICAgICBQcm9j ZXNzb3IgKENQVTAsIDB4MDAsIDB4MDAwMDEwMTAsIDB4MDYpDQogICAgICAgIHsNCiAgICAgICAg ICAgIFNjb3BlIChcKQ0KICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgIE5hbWUgKEdWU1Ms IE9uZSkNCiAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgU2NvcGUgKFxfUFIuQ1BVMCkNCiAg ICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICBNZXRob2QgKF9DU1QsIDAsIE5vdFNlcmlhbGl6 ZWQpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBJZiAoXF9TQi5QQ0kw LkxQQ0IuRUMwLkVDT0spDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAg ICAgICAgIFN0b3JlIChcX1NCLlBDSTAuTFBDQi5FQzAuQUNBVCwgTG9jYWwwKQ0KICAgICAgICAg ICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgICAgIEVsc2UNCiAgICAgICAgICAgICAgICAg ICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgQW5kIChQSFNEICgweEQ0LCAweDgwKSwgMHgw NDAwLCBMb2NhbDApDQogICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAg ICBJZiAoTG9jYWwwKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAg ICAgICBSZXR1cm4gKEFDU1QpDQogICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAg ICAgICAgRWxzZQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAg ICBJZiAoR1ZTUykNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICBSZXR1cm4gKERDU1QpDQogICAgICAgICAgICAgICAgICAgICAgICB9DQogICAg ICAgICAgICAgICAgICAgICAgICBFbHNlDQogICAgICAgICAgICAgICAgICAgICAgICB7DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgUmV0dXJuIChERFNUKQ0KICAgICAgICAgICAgICAgICAg ICAgICAgfQ0KICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgfQ0KDQogICAg ICAgICAgICAgICAgTmFtZSAoQUNTVCwgUGFja2FnZSAoMHgwMykNCiAgICAgICAgICAgICAgICB7 DQogICAgICAgICAgICAgICAgICAgIDB4MDIsIA0KICAgICAgICAgICAgICAgICAgICBQYWNrYWdl ICgweDA0KQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBS ZXNvdXJjZVRlbXBsYXRlICgpDQogICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgUmVnaXN0ZXIgKEZGaXhlZEhXLCAweDA4LCAweDAwLCAweDAwMDAw MDAwMDAwMDAwMDApDQogICAgICAgICAgICAgICAgICAgICAgICB9LCANCg0KICAgICAgICAgICAg ICAgICAgICAgICAgMHgwMSwgDQogICAgICAgICAgICAgICAgICAgICAgICAweDAxLCANCiAgICAg ICAgICAgICAgICAgICAgICAgIDB4MDNFOA0KICAgICAgICAgICAgICAgICAgICB9LCANCg0KICAg ICAgICAgICAgICAgICAgICBQYWNrYWdlICgweDA0KQ0KICAgICAgICAgICAgICAgICAgICB7DQog ICAgICAgICAgICAgICAgICAgICAgICBSZXNvdXJjZVRlbXBsYXRlICgpDQogICAgICAgICAgICAg ICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgUmVnaXN0ZXIgKFN5c3Rl bUlPLCAweDA4LCAweDAwLCAweDAwMDAwMDAwMDAwMDEwMTQpDQogICAgICAgICAgICAgICAgICAg ICAgICB9LCANCg0KICAgICAgICAgICAgICAgICAgICAgICAgMHgwMiwgDQogICAgICAgICAgICAg ICAgICAgICAgICAweDAxLCANCiAgICAgICAgICAgICAgICAgICAgICAgIDB4MDFGNA0KICAgICAg ICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgfSkNCiAgICAgICAgICAgICAgICBOYW1l IChEQ1NULCBQYWNrYWdlICgweDA1KQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAg ICAgICAgMHgwNCwgDQogICAgICAgICAgICAgICAgICAgIFBhY2thZ2UgKDB4MDQpDQogICAgICAg ICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIFJlc291cmNlVGVtcGxhdGUg KCkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBSZWdpc3RlciAoRkZpeGVkSFcsIDB4MDgsIDB4MDAsIDB4MDAwMDAwMDAwMDAwMDAwMCkNCiAg ICAgICAgICAgICAgICAgICAgICAgIH0sIA0KDQogICAgICAgICAgICAgICAgICAgICAgICAweDAx LCANCiAgICAgICAgICAgICAgICAgICAgICAgIDB4MDEsIA0KICAgICAgICAgICAgICAgICAgICAg ICAgMHgwM0U4DQogICAgICAgICAgICAgICAgICAgIH0sIA0KDQogICAgICAgICAgICAgICAgICAg IFBhY2thZ2UgKDB4MDQpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAg ICAgICAgIFJlc291cmNlVGVtcGxhdGUgKCkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBSZWdpc3RlciAoU3lzdGVtSU8sIDB4MDgsIDB4MDAs IDB4MDAwMDAwMDAwMDAwMTAxNCkNCiAgICAgICAgICAgICAgICAgICAgICAgIH0sIA0KDQogICAg ICAgICAgICAgICAgICAgICAgICAweDAyLCANCiAgICAgICAgICAgICAgICAgICAgICAgIDB4MDEs IA0KICAgICAgICAgICAgICAgICAgICAgICAgMHgwMUY0DQogICAgICAgICAgICAgICAgICAgIH0s IA0KDQogICAgICAgICAgICAgICAgICAgIFBhY2thZ2UgKDB4MDQpDQogICAgICAgICAgICAgICAg ICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIFJlc291cmNlVGVtcGxhdGUgKCkNCiAgICAg ICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZWdpc3Rl ciAoU3lzdGVtSU8sIDB4MDgsIDB4MDAsIDB4MDAwMDAwMDAwMDAwMTAxNSkNCiAgICAgICAgICAg ICAgICAgICAgICAgIH0sIA0KDQogICAgICAgICAgICAgICAgICAgICAgICAweDAzLCANCiAgICAg ICAgICAgICAgICAgICAgICAgIDB4NTUsIA0KICAgICAgICAgICAgICAgICAgICAgICAgMHhGQQ0K ICAgICAgICAgICAgICAgICAgICB9LCANCg0KICAgICAgICAgICAgICAgICAgICBQYWNrYWdlICgw eDA0KQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBSZXNv dXJjZVRlbXBsYXRlICgpDQogICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgUmVnaXN0ZXIgKFN5c3RlbUlPLCAweDA4LCAweDAwLCAweDAwMDAwMDAw MDAwMDEwMTYpDQogICAgICAgICAgICAgICAgICAgICAgICB9LCANCg0KICAgICAgICAgICAgICAg ICAgICAgICAgMHgwMywgDQogICAgICAgICAgICAgICAgICAgICAgICAweEI5LCANCiAgICAgICAg ICAgICAgICAgICAgICAgIDB4NjQNCiAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAg ICAgIH0pDQogICAgICAgICAgICAgICAgTmFtZSAoRERTVCwgUGFja2FnZSAoMHgwNCkNCiAgICAg ICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgIDB4MDMsIA0KICAgICAgICAgICAgICAg ICAgICBQYWNrYWdlICgweDA0KQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAg ICAgICAgICAgICBSZXNvdXJjZVRlbXBsYXRlICgpDQogICAgICAgICAgICAgICAgICAgICAgICB7 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgUmVnaXN0ZXIgKEZGaXhlZEhXLCAweDA4LCAw eDAwLCAweDAwMDAwMDAwMDAwMDAwMDApDQogICAgICAgICAgICAgICAgICAgICAgICB9LCANCg0K ICAgICAgICAgICAgICAgICAgICAgICAgMHgwMSwgDQogICAgICAgICAgICAgICAgICAgICAgICAw eDAxLCANCiAgICAgICAgICAgICAgICAgICAgICAgIDB4MDNFOA0KICAgICAgICAgICAgICAgICAg ICB9LCANCg0KICAgICAgICAgICAgICAgICAgICBQYWNrYWdlICgweDA0KQ0KICAgICAgICAgICAg ICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBSZXNvdXJjZVRlbXBsYXRlICgpDQog ICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgUmVn aXN0ZXIgKFN5c3RlbUlPLCAweDA4LCAweDAwLCAweDAwMDAwMDAwMDAwMDEwMTQpDQogICAgICAg ICAgICAgICAgICAgICAgICB9LCANCg0KICAgICAgICAgICAgICAgICAgICAgICAgMHgwMiwgDQog ICAgICAgICAgICAgICAgICAgICAgICAweDAxLCANCiAgICAgICAgICAgICAgICAgICAgICAgIDB4 MDFGNA0KICAgICAgICAgICAgICAgICAgICB9LCANCg0KICAgICAgICAgICAgICAgICAgICBQYWNr YWdlICgweDA0KQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAg ICBSZXNvdXJjZVRlbXBsYXRlICgpDQogICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgUmVnaXN0ZXIgKFN5c3RlbUlPLCAweDA4LCAweDAwLCAweDAw MDAwMDAwMDAwMDEwMTUpDQogICAgICAgICAgICAgICAgICAgICAgICB9LCANCg0KICAgICAgICAg ICAgICAgICAgICAgICAgMHgwMywgDQogICAgICAgICAgICAgICAgICAgICAgICAweDU1LCANCiAg ICAgICAgICAgICAgICAgICAgICAgIDB4RkENCiAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAg ICAgICAgICAgIH0pDQogICAgICAgICAgICB9DQogICAgICAgIH0NCiAgICB9DQoNCiAgICBOYW1l IChcQ1RZUCwgMHgwMCkNCiAgICBOYW1lIChcRUNPTiwgMHgwMCkNCiAgICBNZXRob2QgKF9QVFMs IDEsIE5vdFNlcmlhbGl6ZWQpDQogICAgew0KICAgICAgICBTdG9yZSAoQXJnMCwgUDgwSCkNCiAg ICAgICAgSWYgKExFcXVhbCAoQXJnMCwgMHgwMykpDQogICAgICAgIHsNCiAgICAgICAgICAgIFN0 b3JlIChcX1NCLlBDSTAuTFBDQi5TUElDLl9DUlMgKCksIFxfU0IuUENJMC5MUENCLlNQSUMuU1NS QykNCiAgICAgICAgfQ0KDQogICAgICAgIElmIChMRXF1YWwgKEFyZzAsIDB4MDQpKQ0KICAgICAg ICB7DQogICAgICAgICAgICBTdG9yZSAoXF9TQi5QQ0kwLkxQQ0IuU1BJQy5fQ1JTICgpLCBcX1NC LlBDSTAuTFBDQi5TUElDLlNTUkMpDQogICAgICAgICAgICBQSFNCICgweEEyLCBcX1NCLk9TVEIp DQogICAgICAgIH0NCiAgICB9DQoNCiAgICBNZXRob2QgKF9XQUssIDEsIE5vdFNlcmlhbGl6ZWQp DQogICAgew0KICAgICAgICBTdG9yZSAoMHgwMCwgUDgwSCkNCiAgICAgICAgXF9TQi5OQ1BVICgp DQogICAgICAgIElmIChMRXF1YWwgKEFyZzAsIDB4MDMpKQ0KICAgICAgICB7DQogICAgICAgICAg ICBcX1NCLlBDSTAuTFBDQi5TUElDLl9TUlMgKFxfU0IuUENJMC5MUENCLlNQSUMuU1NSQykNCiAg ICAgICAgICAgIElmIChMTm90IChcX1NCLlBDSTAuTFBDQi5FQzAuV0FLSSkpDQogICAgICAgICAg ICB7DQogICAgICAgICAgICAgICAgTm90aWZ5IChcX1NCLlBXUkIsIDB4MDIpDQogICAgICAgICAg ICB9DQogICAgICAgIH0NCg0KICAgICAgICBJZiAoTEVxdWFsIChBcmcwLCAweDA0KSkNCiAgICAg ICAgew0KICAgICAgICAgICAgXF9TQi5QQ0kwLkxQQ0IuU1BJQy5fU1JTIChcX1NCLlBDSTAuTFBD Qi5TUElDLlNTUkMpDQogICAgICAgICAgICBQSFNCICgweEEzLCBcX1NCLk9TVEIpDQogICAgICAg ICAgICBOb3RpZnkgKFxfU0IuUFdSQiwgMHgwMikNCiAgICAgICAgfQ0KDQogICAgICAgIFJldHVy biAoWmVybykNCiAgICB9DQoNCiAgICBTY29wZSAoXF9TQikNCiAgICB7DQogICAgICAgIE5hbWUg KE9TVEIsIE9uZXMpDQogICAgICAgIE9wZXJhdGlvblJlZ2lvbiAoT1NUWSwgU3lzdGVtTWVtb3J5 LCAweDFGRjdDQUY3LCAweDAwMDAwMDAxKQ0KICAgICAgICBGaWVsZCAoT1NUWSwgQW55QWNjLCBO b0xvY2ssIFByZXNlcnZlKQ0KICAgICAgICB7DQogICAgICAgICAgICBUUE9TLCAgIDgNCiAgICAg ICAgfQ0KDQogICAgICAgIE1ldGhvZCAoT1NUUCwgMCwgTm90U2VyaWFsaXplZCkNCiAgICAgICAg ew0KICAgICAgICAgICAgSWYgKExFcXVhbCAoXk9TVEIsIE9uZXMpKQ0KICAgICAgICAgICAgew0K ICAgICAgICAgICAgICAgIElmIChDb25kUmVmT2YgKFxfT1NJLCBMb2NhbDApKQ0KICAgICAgICAg ICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgSWYgKFxfT1NJICgiV2luZG93cyAyMDAxLjEi KSkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUg KDB4MjAsIF5PU1RCKQ0KICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKDB4MjAsIF5UUE9T KQ0KICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgICAgIEVsc2UNCiAgICAg ICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgSWYgKFxfT1NJICgiV2lu ZG93cyAyMDAxIFNQMSIpKQ0KICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFN0b3JlICgweDEwLCBeT1NUQikNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBTdG9yZSAoMHgxMCwgXlRQT1MpDQogICAgICAgICAgICAgICAgICAgICAgICB9DQog ICAgICAgICAgICAgICAgICAgICAgICBFbHNlDQogICAgICAgICAgICAgICAgICAgICAgICB7DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgSWYgKFxfT1NJICgiV2luZG93cyAyMDAxIikpDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBTdG9yZSAoMHgwOCwgXk9TVEIpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFN0b3JlICgweDA4LCBeVFBPUykNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB9DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgRWxzZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg IHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKDB4MDAsIF5PU1RCKQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoMHgwMCwgXlRQT1MpDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgICAgICAgfQ0KICAg ICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgIEVs c2UNCiAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgIElmIChDb25kUmVmT2Yg KFxfT1MsIExvY2FsMCkpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAg ICAgICAgIElmICheU0VRTCAoXF9PUywgIk1pY3Jvc29mdCBXaW5kb3dzIikpDQogICAgICAgICAg ICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKDB4MDEs IF5PU1RCKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlICgweDAxLCBeVFBPUykN CiAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAgICAgIEVsc2UN CiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJ ZiAoXlNFUUwgKFxfT1MsICJNaWNyb3NvZnQgV2luZG93c01FOiBNaWxsZW5uaXVtIEVkaXRpb24i KSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFN0b3JlICgweDAyLCBeT1NUQikNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgU3RvcmUgKDB4MDIsIF5UUE9TKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBFbHNlDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJZiAoXlNFUUwgKFxfT1Ms ICJNaWNyb3NvZnQgV2luZG93cyBOVCIpKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoMHgwNCwgXk9T VEIpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoMHgwNCwgXlRQ T1MpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgRWxzZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB7DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoMHgwMCwgXk9TVEIpDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoMHgwMCwgXlRQT1MpDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICB9DQogICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgICAgIH0N CiAgICAgICAgICAgICAgICAgICAgRWxzZQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAg ICAgICAgICAgICAgICAgICBTdG9yZSAoMHgwMCwgXk9TVEIpDQogICAgICAgICAgICAgICAgICAg ICAgICBTdG9yZSAoMHgwMCwgXlRQT1MpDQogICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAg ICAgICAgICB9DQogICAgICAgICAgICB9DQoNCiAgICAgICAgICAgIFJldHVybiAoXk9TVEIpDQog ICAgICAgIH0NCg0KICAgICAgICBNZXRob2QgKFNFUUwsIDIsIFNlcmlhbGl6ZWQpDQogICAgICAg IHsNCiAgICAgICAgICAgIFN0b3JlIChTaXplT2YgKEFyZzApLCBMb2NhbDApDQogICAgICAgICAg ICBTdG9yZSAoU2l6ZU9mIChBcmcxKSwgTG9jYWwxKQ0KICAgICAgICAgICAgSWYgKExOb3QgKExF cXVhbCAoTG9jYWwwLCBMb2NhbDEpKSkNCiAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICBS ZXR1cm4gKFplcm8pDQogICAgICAgICAgICB9DQoNCiAgICAgICAgICAgIE5hbWUgKEJVRjAsIEJ1 ZmZlciAoTG9jYWwwKSB7fSkNCiAgICAgICAgICAgIFN0b3JlIChBcmcwLCBCVUYwKQ0KICAgICAg ICAgICAgTmFtZSAoQlVGMSwgQnVmZmVyIChMb2NhbDApIHt9KQ0KICAgICAgICAgICAgU3RvcmUg KEFyZzEsIEJVRjEpDQogICAgICAgICAgICBTdG9yZSAoWmVybywgTG9jYWwyKQ0KICAgICAgICAg ICAgV2hpbGUgKExMZXNzIChMb2NhbDIsIExvY2FsMCkpDQogICAgICAgICAgICB7DQogICAgICAg ICAgICAgICAgU3RvcmUgKERlcmVmT2YgKEluZGV4IChCVUYwLCBMb2NhbDIpKSwgTG9jYWwzKQ0K ICAgICAgICAgICAgICAgIFN0b3JlIChEZXJlZk9mIChJbmRleCAoQlVGMSwgTG9jYWwyKSksIExv Y2FsNCkNCiAgICAgICAgICAgICAgICBJZiAoTE5vdCAoTEVxdWFsIChMb2NhbDMsIExvY2FsNCkp KQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgUmV0dXJuIChaZXJvKQ0K ICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgIEluY3JlbWVudCAoTG9jYWwyKQ0K ICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICBSZXR1cm4gKE9uZSkNCiAgICAgICAgfQ0KICAg IH0NCg0KICAgIFNjb3BlIChcX0dQRSkNCiAgICB7DQogICAgICAgIE11dGV4IChHTE9LLCAweDAw KQ0KICAgICAgICBNZXRob2QgKF9MMDMsIDAsIE5vdFNlcmlhbGl6ZWQpDQogICAgICAgIHsNCiAg ICAgICAgICAgIE5vdGlmeSAoXF9TQi5QQ0kwLlVTQjAsIDB4MDIpDQogICAgICAgIH0NCg0KICAg ICAgICBNZXRob2QgKF9MMDQsIDAsIE5vdFNlcmlhbGl6ZWQpDQogICAgICAgIHsNCiAgICAgICAg ICAgIE5vdGlmeSAoXF9TQi5QQ0kwLlVTQjEsIDB4MDIpDQogICAgICAgIH0NCg0KICAgICAgICBN ZXRob2QgKF9MMDUsIDAsIE5vdFNlcmlhbGl6ZWQpDQogICAgICAgIHsNCiAgICAgICAgICAgIE5v dGlmeSAoXF9TQi5QQ0kwLk1PRE0sIDB4MDIpDQogICAgICAgIH0NCg0KICAgICAgICBNZXRob2Qg KF9MMEMsIDAsIE5vdFNlcmlhbGl6ZWQpDQogICAgICAgIHsNCiAgICAgICAgICAgIE5vdGlmeSAo XF9TQi5QQ0kwLlVTQjIsIDB4MDIpDQogICAgICAgIH0NCg0KICAgICAgICBNZXRob2QgKF9MMEQs IDAsIE5vdFNlcmlhbGl6ZWQpDQogICAgICAgIHsNCiAgICAgICAgICAgIE5vdGlmeSAoXF9TQi5Q Q0kwLlVTQjcsIDB4MDIpDQogICAgICAgIH0NCg0KICAgICAgICBNZXRob2QgKF9MMEIsIDAsIE5v dFNlcmlhbGl6ZWQpDQogICAgICAgIHsNCiAgICAgICAgICAgIElmIChMTm90IChMTGVzcyAoXF9T Qi5PU1RCLCAweDA4KSkpDQogICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgQWNxdWlyZSAo R0xPSywgMHhGRkZGKQ0KICAgICAgICAgICAgICAgIFNsZWVwICgweDY0KQ0KICAgICAgICAgICAg ICAgIE5vdGlmeSAoXF9TQi5QQ0kwLlBDSUIuQ1JEMCwgMHgwMikNCiAgICAgICAgICAgICAgICBT bGVlcCAoMHg2NCkNCiAgICAgICAgICAgICAgICBSZWxlYXNlIChHTE9LKQ0KICAgICAgICAgICAg ICAgIE5vdGlmeSAoXF9TQi5QQ0kwLlBDSUIsIDB4MDIpDQogICAgICAgICAgICB9DQogICAgICAg ICAgICBFbHNlDQogICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgTm90aWZ5IChcX1NCLlBD STAuUENJQiwgMHgwMikNCiAgICAgICAgICAgIH0NCiAgICAgICAgfQ0KDQogICAgICAgIE1ldGhv ZCAoX0wxRCwgMCwgTm90U2VyaWFsaXplZCkNCiAgICAgICAgew0KICAgICAgICAgICAgTm90aWZ5 IChcX1NCLlBDSTAuTFBDQi5FQzAsIDB4MDIpDQogICAgICAgIH0NCiAgICB9DQoNCiAgICBPcGVy YXRpb25SZWdpb24gKFNNSTAsIFN5c3RlbU1lbW9yeSwgMHgxRkY3Q0FGOCwgMHgwMDAwMDQxNSkN CiAgICBGaWVsZCAoU01JMCwgQW55QWNjLCBOb0xvY2ssIFByZXNlcnZlKQ0KICAgIHsNCiAgICAg ICAgQkNNRCwgICA4LCANCiAgICAgICAgRElELCAgICAzMiwgDQogICAgICAgIElORk8sICAgNDA5 Ng0KICAgIH0NCg0KICAgIEZpZWxkIChTTUkwLCBBbnlBY2MsIE5vTG9jaywgUHJlc2VydmUpDQog ICAgew0KICAgICAgICBPZmZzZXQgKDB4MDUpLCANCiAgICAgICAgSU5GQiwgICA4DQogICAgfQ0K DQogICAgRmllbGQgKFNNSTAsIEFueUFjYywgTm9Mb2NrLCBQcmVzZXJ2ZSkNCiAgICB7DQogICAg ICAgIE9mZnNldCAoMHgwNSksIA0KICAgICAgICBJTkZELCAgIDMyDQogICAgfQ0KDQogICAgRmll bGQgKFNNSTAsIEFueUFjYywgTm9Mb2NrLCBQcmVzZXJ2ZSkNCiAgICB7DQogICAgICAgIE9mZnNl dCAoMHgwNSksIA0KICAgICAgICBTWEJGLCAgIDgzMjANCiAgICB9DQoNCiAgICBGaWVsZCAoU01J MCwgQW55QWNjLCBOb0xvY2ssIFByZXNlcnZlKQ0KICAgIHsNCiAgICAgICAgT2Zmc2V0ICgweDA1 KSwgDQogICAgICAgIElORjEsICAgOCwgDQogICAgICAgIElORjIsICAgOA0KICAgIH0NCg0KICAg IE9wZXJhdGlvblJlZ2lvbiAoU01JMSwgU3lzdGVtSU8sIDB4MDAwMEZFMDAsIDB4MDAwMDAwMDIp DQogICAgRmllbGQgKFNNSTEsIEFueUFjYywgTm9Mb2NrLCBQcmVzZXJ2ZSkNCiAgICB7DQogICAg ICAgIFNNSUMsICAgOA0KICAgIH0NCg0KICAgIE11dGV4IChNUEhTLCAweDAwKQ0KICAgIE1ldGhv ZCAoUEhTMCwgMSwgTm90U2VyaWFsaXplZCkNCiAgICB7DQogICAgICAgIFN0b3JlIChBcmcwLCBC Q01EKQ0KICAgICAgICBTdG9yZSAoWmVybywgU01JQykNCiAgICAgICAgV2hpbGUgKExFcXVhbCAo QkNNRCwgQXJnMCkpIHt9DQogICAgICAgIFN0b3JlICgweDAwLCBCQ01EKQ0KICAgIH0NCg0KICAg IE1ldGhvZCAoUEhTLCAxLCBTZXJpYWxpemVkKQ0KICAgIHsNCiAgICAgICAgQWNxdWlyZSAoTVBI UywgMHhGRkZGKQ0KICAgICAgICBTdG9yZSAoMHgwMCwgRElEKQ0KICAgICAgICBQSFMwIChBcmcw KQ0KICAgICAgICBTdG9yZSAoSU5GRCwgTG9jYWwwKQ0KICAgICAgICBSZWxlYXNlIChNUEhTKQ0K ICAgICAgICBSZXR1cm4gKExvY2FsMCkNCiAgICB9DQoNCiAgICBNZXRob2QgKFBIU0QsIDIsIFNl cmlhbGl6ZWQpDQogICAgew0KICAgICAgICBBY3F1aXJlIChNUEhTLCAweEZGRkYpDQogICAgICAg IFN0b3JlICgweDAwLCBESUQpDQogICAgICAgIFN0b3JlIChBcmcxLCBJTkZEKQ0KICAgICAgICBQ SFMwIChBcmcwKQ0KICAgICAgICBTdG9yZSAoSU5GRCwgTG9jYWwwKQ0KICAgICAgICBSZWxlYXNl IChNUEhTKQ0KICAgICAgICBSZXR1cm4gKExvY2FsMCkNCiAgICB9DQoNCiAgICBNZXRob2QgKFBI U1csIDMsIFNlcmlhbGl6ZWQpDQogICAgew0KICAgICAgICBBY3F1aXJlIChNUEhTLCAweEZGRkYp DQogICAgICAgIFN0b3JlICgweDAwLCBESUQpDQogICAgICAgIFN0b3JlIChBcmcxLCBJTkYxKQ0K ICAgICAgICBTdG9yZSAoQXJnMiwgSU5GMikNCiAgICAgICAgUEhTMCAoQXJnMCkNCiAgICAgICAg U3RvcmUgKElORkIsIExvY2FsMCkNCiAgICAgICAgUmVsZWFzZSAoTVBIUykNCiAgICAgICAgUmV0 dXJuIChMb2NhbDApDQogICAgfQ0KDQogICAgTWV0aG9kIChQSFNCLCAyLCBTZXJpYWxpemVkKQ0K ICAgIHsNCiAgICAgICAgQWNxdWlyZSAoTVBIUywgMHhGRkZGKQ0KICAgICAgICBTdG9yZSAoMHgw MCwgRElEKQ0KICAgICAgICBTdG9yZSAoQXJnMSwgSU5GQikNCiAgICAgICAgUEhTMCAoQXJnMCkN CiAgICAgICAgU3RvcmUgKElORkIsIExvY2FsMCkNCiAgICAgICAgUmVsZWFzZSAoTVBIUykNCiAg ICAgICAgUmV0dXJuIChMb2NhbDApDQogICAgfQ0KDQogICAgTWV0aG9kIChQU0NTLCAxLCBTZXJp YWxpemVkKQ0KICAgIHsNCiAgICAgICAgQWNxdWlyZSAoTVBIUywgMHhGRkZGKQ0KICAgICAgICBT dG9yZSAoQXJnMCwgRElEKQ0KICAgICAgICBQSFMwICgweDAwKQ0KICAgICAgICBTdG9yZSAoSU5G TywgTG9jYWwwKQ0KICAgICAgICBSZWxlYXNlIChNUEhTKQ0KICAgICAgICBSZXR1cm4gKExvY2Fs MCkNCiAgICB9DQoNCiAgICBNZXRob2QgKFBTU1MsIDIsIFNlcmlhbGl6ZWQpDQogICAgew0KICAg ICAgICBBY3F1aXJlIChNUEhTLCAweEZGRkYpDQogICAgICAgIFN0b3JlIChBcmcwLCBESUQpDQog ICAgICAgIFN0b3JlIChBcmcxLCBJTkZPKQ0KICAgICAgICBQSFMwICgweDAxKQ0KICAgICAgICBS ZWxlYXNlIChNUEhTKQ0KICAgIH0NCg0KICAgIE1ldGhvZCAoUFNQUywgMSwgU2VyaWFsaXplZCkN CiAgICB7DQogICAgICAgIEFjcXVpcmUgKE1QSFMsIDB4RkZGRikNCiAgICAgICAgU3RvcmUgKEFy ZzAsIERJRCkNCiAgICAgICAgUEhTMCAoMHgwMikNCiAgICAgICAgU3RvcmUgKElORk8sIExvY2Fs MCkNCiAgICAgICAgUmVsZWFzZSAoTVBIUykNCiAgICAgICAgUmV0dXJuIChMb2NhbDApDQogICAg fQ0KDQogICAgTWV0aG9kIChQU0RJLCAxLCBTZXJpYWxpemVkKQ0KICAgIHsNCiAgICAgICAgQWNx dWlyZSAoTVBIUywgMHhGRkZGKQ0KICAgICAgICBTdG9yZSAoQXJnMCwgRElEKQ0KICAgICAgICBQ SFMwICgweDAzKQ0KICAgICAgICBSZWxlYXNlIChNUEhTKQ0KICAgIH0NCg0KICAgIE1ldGhvZCAo UFNTVCwgMSwgU2VyaWFsaXplZCkNCiAgICB7DQogICAgICAgIEFjcXVpcmUgKE1QSFMsIDB4RkZG RikNCiAgICAgICAgU3RvcmUgKEFyZzAsIERJRCkNCiAgICAgICAgUEhTMCAoMHgwNCkNCiAgICAg ICAgU3RvcmUgKElORkIsIExvY2FsMCkNCiAgICAgICAgUmVsZWFzZSAoTVBIUykNCiAgICAgICAg UmV0dXJuIChMb2NhbDApDQogICAgfQ0KDQogICAgU2NvcGUgKFxfVFopDQogICAgew0KICAgICAg ICBUaGVybWFsWm9uZSAoQVRGMCkNCiAgICAgICAgew0KICAgICAgICAgICAgTWV0aG9kIChLRUxW LCAxLCBOb3RTZXJpYWxpemVkKQ0KICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgIFN0b3Jl IChBcmcwLCBMb2NhbDApDQogICAgICAgICAgICAgICAgTXVsdGlwbHkgKExvY2FsMCwgMHgwQSwg TG9jYWwwKQ0KICAgICAgICAgICAgICAgIEFkZCAoTG9jYWwwLCAweDBBQUIsIExvY2FsMCkNCiAg ICAgICAgICAgICAgICBSZXR1cm4gKExvY2FsMCkNCiAgICAgICAgICAgIH0NCg0KICAgICAgICAg ICAgTWV0aG9kIChfVE1QLCAwLCBOb3RTZXJpYWxpemVkKQ0KICAgICAgICAgICAgew0KICAgICAg ICAgICAgICAgIElmIChMRXF1YWwgKFxfU0IuUENJMC5MUENCLkVDMC5FQ09LLCAweDAwKSkNCiAg ICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgIFN0b3JlIChQSFNEICgweEQ0LCAw eEMwKSwgTG9jYWwxKQ0KICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICBFbHNlDQog ICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBTdG9yZSAoXF9TQi5QQ0kwLkxQ Q0IuRUMwLkExVFAsIExvY2FsMSkNCiAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAg ICBTaGlmdFJpZ2h0IChMb2NhbDEsIDB4MDgsIExvY2FsMCkNCiAgICAgICAgICAgICAgICBJZiAo TEdyZWF0ZXIgKExvY2FsMCwgMHg4MCkpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAg ICAgICAgICBTbGVlcCAoMHgzMikNCiAgICAgICAgICAgICAgICAgICAgSWYgKExFcXVhbCAoXF9T Qi5QQ0kwLkxQQ0IuRUMwLkVDT0ssIDB4MDApKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAg ICAgICAgICAgICAgICAgICAgICBTdG9yZSAoUEhTRCAoMHhENCwgMHhDMCksIExvY2FsMSkNCiAg ICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgICBFbHNlDQogICAgICAgICAg ICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlIChcX1NCLlBDSTAuTFBD Qi5FQzAuQTFUUCwgTG9jYWwxKQ0KICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAg ICAgICAgICAgU2hpZnRSaWdodCAoTG9jYWwxLCAweDA4LCBMb2NhbDApDQogICAgICAgICAgICAg ICAgfQ0KDQogICAgICAgICAgICAgICAgUmV0dXJuIChLRUxWIChMb2NhbDApKQ0KICAgICAgICAg ICAgfQ0KDQogICAgICAgICAgICBNZXRob2QgKF9QU1YsIDAsIE5vdFNlcmlhbGl6ZWQpDQogICAg ICAgICAgICB7DQogICAgICAgICAgICAgICAgSWYgKExFcXVhbCAoXF9TQi5QQ0kwLkxQQ0IuRUMw LkVDT0ssIDB4MDApKQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgU3Rv cmUgKFBIU0QgKDB4RDQsIDB4QzQpLCBMb2NhbDEpDQogICAgICAgICAgICAgICAgfQ0KICAgICAg ICAgICAgICAgIEVsc2UNCiAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgIFN0 b3JlIChcX1NCLlBDSTAuTFBDQi5FQzAuQTFQVCwgTG9jYWwxKQ0KICAgICAgICAgICAgICAgIH0N Cg0KICAgICAgICAgICAgICAgIFNoaWZ0UmlnaHQgKExvY2FsMSwgMHgwOCwgTG9jYWwwKQ0KICAg ICAgICAgICAgICAgIFJldHVybiAoS0VMViAoTG9jYWwwKSkNCiAgICAgICAgICAgIH0NCg0KICAg ICAgICAgICAgTmFtZSAoX1BTTCwgUGFja2FnZSAoMHgwMSkNCiAgICAgICAgICAgIHsNCiAgICAg ICAgICAgICAgICBcX1BSLkNQVTANCiAgICAgICAgICAgIH0pDQogICAgICAgICAgICBNZXRob2Qg KF9DUlQsIDAsIE5vdFNlcmlhbGl6ZWQpDQogICAgICAgICAgICB7DQogICAgICAgICAgICAgICAg SWYgKExFcXVhbCAoXF9TQi5QQ0kwLkxQQ0IuRUMwLkVDT0ssIDB4MDApKQ0KICAgICAgICAgICAg ICAgIHsNCiAgICAgICAgICAgICAgICAgICAgU3RvcmUgKFBIU0QgKDB4RDQsIDB4QzYpLCBMb2Nh bDEpDQogICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgIEVsc2UNCiAgICAgICAgICAg ICAgICB7DQogICAgICAgICAgICAgICAgICAgIFN0b3JlIChcX1NCLlBDSTAuTFBDQi5FQzAuQTFD VCwgTG9jYWwxKQ0KICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgIFNoaWZ0Umln aHQgKExvY2FsMSwgMHgwOCwgTG9jYWwwKQ0KICAgICAgICAgICAgICAgIFJldHVybiAoS0VMViAo TG9jYWwwKSkNCiAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgTmFtZSAoX1RDMSwgMHgwMSkN CiAgICAgICAgICAgIE5hbWUgKF9UQzIsIDB4MDIpDQogICAgICAgICAgICBOYW1lIChfVFNQLCAw eDMyKQ0KICAgICAgICB9DQogICAgfQ0KDQogICAgU2NvcGUgKFxfU0IpDQogICAgew0KICAgICAg ICBEZXZpY2UgKExJRDApDQogICAgICAgIHsNCiAgICAgICAgICAgIE5hbWUgKF9ISUQsIEVpc2FJ ZCAoIlBOUDBDMEQiKSkNCiAgICAgICAgICAgIE1ldGhvZCAoX0xJRCwgMCwgTm90U2VyaWFsaXpl ZCkNCiAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICBJZiAoTEVxdWFsIChcX1NCLlBDSTAu TFBDQi5FQzAuRUNPSywgMHgwMCkpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAg ICAgICBBbmQgKFBIU0IgKDB4RDQsIDB4ODIpLCAweDA0LCBMb2NhbDApDQogICAgICAgICAgICAg ICAgfQ0KICAgICAgICAgICAgICAgIEVsc2UNCiAgICAgICAgICAgICAgICB7DQogICAgICAgICAg ICAgICAgICAgIFN0b3JlIChcX1NCLlBDSTAuTFBDQi5FQzAuTElEUywgTG9jYWwwKQ0KICAgICAg ICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgIFJldHVybiAoTG9jYWwwKQ0KICAgICAgICAg ICAgfQ0KICAgICAgICB9DQoNCiAgICAgICAgRGV2aWNlIChQV1JCKQ0KICAgICAgICB7DQogICAg ICAgICAgICBOYW1lIChfSElELCBFaXNhSWQgKCJQTlAwQzBDIikpDQogICAgICAgICAgICBOYW1l IChfUFJXLCBQYWNrYWdlICgweDAyKQ0KICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgIDB4 MUQsIA0KICAgICAgICAgICAgICAgIDB4MDQNCiAgICAgICAgICAgIH0pDQogICAgICAgIH0NCg0K ICAgICAgICBNdXRleCAoUExPSywgMHgwMCkNCiAgICAgICAgTWV0aG9kIChOQ1BVLCAwLCBOb3RT ZXJpYWxpemVkKQ0KICAgICAgICB7DQogICAgICAgICAgICBBY3F1aXJlIChQTE9LLCAweEZGRkYp DQogICAgICAgICAgICBOb3RpZnkgKFxfUFIuQ1BVMCwgMHg4MCkNCiAgICAgICAgICAgIFNsZWVw ICgweDY0KQ0KICAgICAgICAgICAgTm90aWZ5IChcX1BSLkNQVTAsIDB4ODEpDQogICAgICAgICAg ICBSZWxlYXNlIChQTE9LKQ0KICAgICAgICB9DQoNCiAgICAgICAgRGV2aWNlIChQQ0kwKQ0KICAg ICAgICB7DQogICAgICAgICAgICBNZXRob2QgKF9JTkksIDAsIE5vdFNlcmlhbGl6ZWQpDQogICAg ICAgICAgICB7DQogICAgICAgICAgICAgICAgXF9TQi5PU1RQICgpDQogICAgICAgICAgICB9DQoN CiAgICAgICAgICAgIE1ldGhvZCAoX1MxRCwgMCwgTm90U2VyaWFsaXplZCkNCiAgICAgICAgICAg IHsNCiAgICAgICAgICAgICAgICBSZXR1cm4gKDB4MDIpDQogICAgICAgICAgICB9DQoNCiAgICAg ICAgICAgIE1ldGhvZCAoX1MzRCwgMCwgTm90U2VyaWFsaXplZCkNCiAgICAgICAgICAgIHsNCiAg ICAgICAgICAgICAgICBSZXR1cm4gKDB4MDIpDQogICAgICAgICAgICB9DQoNCiAgICAgICAgICAg IE1ldGhvZCAoX1M0RCwgMCwgTm90U2VyaWFsaXplZCkNCiAgICAgICAgICAgIHsNCiAgICAgICAg ICAgICAgICBSZXR1cm4gKDB4MDIpDQogICAgICAgICAgICB9DQoNCiAgICAgICAgICAgIE5hbWUg KF9ISUQsIEVpc2FJZCAoIlBOUDBBMDMiKSkNCiAgICAgICAgICAgIE5hbWUgKF9BRFIsIDB4MDAp DQogICAgICAgICAgICBOYW1lIChfQkJOLCAweDAwKQ0KICAgICAgICAgICAgT3BlcmF0aW9uUmVn aW9uIChIQlVTLCBQQ0lfQ29uZmlnLCAweDQwLCAweEMwKQ0KICAgICAgICAgICAgRmllbGQgKEhC VVMsIERXb3JkQWNjLCBOb0xvY2ssIFByZXNlcnZlKQ0KICAgICAgICAgICAgew0KICAgICAgICAg ICAgICAgIE9mZnNldCAoMHgyMCksIA0KICAgICAgICAgICAgICAgIERSQjAsICAgOCwgDQogICAg ICAgICAgICAgICAgRFJCMSwgICA4LCANCiAgICAgICAgICAgICAgICBEUkIyLCAgIDgsIA0KICAg ICAgICAgICAgICAgIERSQjMsICAgOCwgDQogICAgICAgICAgICAgICAgT2Zmc2V0ICgweDUwKSwg DQogICAgICAgICAgICAgICAgICAgICwgICA0LCANCiAgICAgICAgICAgICAgICBQTTBILCAgIDIs IA0KICAgICAgICAgICAgICAgIE9mZnNldCAoMHg1MSksIA0KICAgICAgICAgICAgICAgIFBNMUws ICAgMiwgDQogICAgICAgICAgICAgICAgICAgICwgICAyLCANCiAgICAgICAgICAgICAgICBQTTFI LCAgIDIsIA0KICAgICAgICAgICAgICAgIE9mZnNldCAoMHg1MiksIA0KICAgICAgICAgICAgICAg IFBNMkwsICAgMiwgDQogICAgICAgICAgICAgICAgICAgICwgICAyLCANCiAgICAgICAgICAgICAg ICBQTTJILCAgIDIsIA0KICAgICAgICAgICAgICAgIE9mZnNldCAoMHg1MyksIA0KICAgICAgICAg ICAgICAgIFBNM0wsICAgMiwgDQogICAgICAgICAgICAgICAgICAgICwgICAyLCANCiAgICAgICAg ICAgICAgICBQTTNILCAgIDIsIA0KICAgICAgICAgICAgICAgIE9mZnNldCAoMHg1NCksIA0KICAg ICAgICAgICAgICAgIFBNNEwsICAgMiwgDQogICAgICAgICAgICAgICAgICAgICwgICAyLCANCiAg ICAgICAgICAgICAgICBQTTRILCAgIDIsIA0KICAgICAgICAgICAgICAgIE9mZnNldCAoMHg1NSks IA0KICAgICAgICAgICAgICAgIFBNNUwsICAgMiwgDQogICAgICAgICAgICAgICAgICAgICwgICAy LCANCiAgICAgICAgICAgICAgICBQTTVILCAgIDIsIA0KICAgICAgICAgICAgICAgIE9mZnNldCAo MHg1NiksIA0KICAgICAgICAgICAgICAgIFBNNkwsICAgMiwgDQogICAgICAgICAgICAgICAgICAg ICwgICAyLCANCiAgICAgICAgICAgICAgICBQTTZILCAgIDIsIA0KICAgICAgICAgICAgICAgIE9m ZnNldCAoMHg1NyksIA0KICAgICAgICAgICAgICAgIEZESEMsICAgOA0KICAgICAgICAgICAgfQ0K DQogICAgICAgICAgICBOYW1lIChCVUYwLCBSZXNvdXJjZVRlbXBsYXRlICgpDQogICAgICAgICAg ICB7DQogICAgICAgICAgICAgICAgV29yZEJ1c051bWJlciAoUmVzb3VyY2VQcm9kdWNlciwgTWlu Rml4ZWQsIE1heEZpeGVkLCBQb3NEZWNvZGUsDQogICAgICAgICAgICAgICAgICAgIDB4MDAwMCwN CiAgICAgICAgICAgICAgICAgICAgMHgwMDAwLA0KICAgICAgICAgICAgICAgICAgICAweDAwRkYs DQogICAgICAgICAgICAgICAgICAgIDB4MDAwMCwNCiAgICAgICAgICAgICAgICAgICAgMHgwMTAw LCAweDAwKQ0KICAgICAgICAgICAgICAgIERXb3JkSU8gKFJlc291cmNlUHJvZHVjZXIsIE1pbkZp eGVkLCBNYXhGaXhlZCwgUG9zRGVjb2RlLCBFbnRpcmVSYW5nZSwNCiAgICAgICAgICAgICAgICAg ICAgMHgwMDAwMDAwMCwNCiAgICAgICAgICAgICAgICAgICAgMHgwMDAwMDAwMCwNCiAgICAgICAg ICAgICAgICAgICAgMHgwMDAwMENGNywNCiAgICAgICAgICAgICAgICAgICAgMHgwMDAwMDAwMCwN CiAgICAgICAgICAgICAgICAgICAgMHgwMDAwMENGOCwgMHgwMCkNCiAgICAgICAgICAgICAgICBJ TyAoRGVjb2RlMTYsIDB4MENGOCwgMHgwQ0Y4LCAweDAxLCAweDA4KQ0KICAgICAgICAgICAgICAg IERXb3JkSU8gKFJlc291cmNlUHJvZHVjZXIsIE1pbkZpeGVkLCBNYXhGaXhlZCwgUG9zRGVjb2Rl LCBFbnRpcmVSYW5nZSwNCiAgICAgICAgICAgICAgICAgICAgMHgwMDAwMDAwMCwNCiAgICAgICAg ICAgICAgICAgICAgMHgwMDAwMEQwMCwNCiAgICAgICAgICAgICAgICAgICAgMHgwMDAwRkZGRiwN CiAgICAgICAgICAgICAgICAgICAgMHgwMDAwMDAwMCwNCiAgICAgICAgICAgICAgICAgICAgMHgw MDAwRjMwMCwgMHgwMCkNCiAgICAgICAgICAgICAgICBEV29yZE1lbW9yeSAoUmVzb3VyY2VQcm9k dWNlciwgUG9zRGVjb2RlLCBNaW5GaXhlZCwgTWF4Rml4ZWQsIENhY2hlYWJsZSwgUmVhZFdyaXRl LA0KICAgICAgICAgICAgICAgICAgICAweDAwMDAwMDAwLA0KICAgICAgICAgICAgICAgICAgICAw eDAwMEEwMDAwLA0KICAgICAgICAgICAgICAgICAgICAweDAwMEJGRkZGLA0KICAgICAgICAgICAg ICAgICAgICAweDAwMDAwMDAwLA0KICAgICAgICAgICAgICAgICAgICAweDAwMDIwMDAwLCAweDAw KQ0KICAgICAgICAgICAgICAgIERXb3JkTWVtb3J5IChSZXNvdXJjZVByb2R1Y2VyLCBQb3NEZWNv ZGUsIE1pbkZpeGVkLCBNYXhGaXhlZCwgQ2FjaGVhYmxlLCBSZWFkV3JpdGUsDQogICAgICAgICAg ICAgICAgICAgIDB4MDAwMDAwMDAsDQogICAgICAgICAgICAgICAgICAgIDB4MDAwQzAwMDAsDQog ICAgICAgICAgICAgICAgICAgIDB4MDAwQzNGRkYsDQogICAgICAgICAgICAgICAgICAgIDB4MDAw MDAwMDAsDQogICAgICAgICAgICAgICAgICAgIDB4MDAwMDQwMDAsIDB4MDApDQogICAgICAgICAg ICAgICAgRFdvcmRNZW1vcnkgKFJlc291cmNlUHJvZHVjZXIsIFBvc0RlY29kZSwgTWluRml4ZWQs IE1heEZpeGVkLCBDYWNoZWFibGUsIFJlYWRXcml0ZSwNCiAgICAgICAgICAgICAgICAgICAgMHgw MDAwMDAwMCwNCiAgICAgICAgICAgICAgICAgICAgMHgwMDBDNDAwMCwNCiAgICAgICAgICAgICAg ICAgICAgMHgwMDBDN0ZGRiwNCiAgICAgICAgICAgICAgICAgICAgMHgwMDAwMDAwMCwNCiAgICAg ICAgICAgICAgICAgICAgMHgwMDAwNDAwMCwgMHgwMCkNCiAgICAgICAgICAgICAgICBEV29yZE1l bW9yeSAoUmVzb3VyY2VQcm9kdWNlciwgUG9zRGVjb2RlLCBNaW5GaXhlZCwgTWF4Rml4ZWQsIENh Y2hlYWJsZSwgUmVhZFdyaXRlLA0KICAgICAgICAgICAgICAgICAgICAweDAwMDAwMDAwLA0KICAg ICAgICAgICAgICAgICAgICAweDAwMEM4MDAwLA0KICAgICAgICAgICAgICAgICAgICAweDAwMENC RkZGLA0KICAgICAgICAgICAgICAgICAgICAweDAwMDAwMDAwLA0KICAgICAgICAgICAgICAgICAg ICAweDAwMDA0MDAwLCAweDAwKQ0KICAgICAgICAgICAgICAgIERXb3JkTWVtb3J5IChSZXNvdXJj ZVByb2R1Y2VyLCBQb3NEZWNvZGUsIE1pbkZpeGVkLCBNYXhGaXhlZCwgQ2FjaGVhYmxlLCBSZWFk V3JpdGUsDQogICAgICAgICAgICAgICAgICAgIDB4MDAwMDAwMDAsDQogICAgICAgICAgICAgICAg ICAgIDB4MDAwQ0MwMDAsDQogICAgICAgICAgICAgICAgICAgIDB4MDAwQ0ZGRkYsDQogICAgICAg ICAgICAgICAgICAgIDB4MDAwMDAwMDAsDQogICAgICAgICAgICAgICAgICAgIDB4MDAwMDQwMDAs IDB4MDApDQogICAgICAgICAgICAgICAgRFdvcmRNZW1vcnkgKFJlc291cmNlUHJvZHVjZXIsIFBv c0RlY29kZSwgTWluRml4ZWQsIE1heEZpeGVkLCBDYWNoZWFibGUsIFJlYWRXcml0ZSwNCiAgICAg ICAgICAgICAgICAgICAgMHgwMDAwMDAwMCwNCiAgICAgICAgICAgICAgICAgICAgMHgwMDBEMDAw MCwNCiAgICAgICAgICAgICAgICAgICAgMHgwMDBEM0ZGRiwNCiAgICAgICAgICAgICAgICAgICAg MHgwMDAwMDAwMCwNCiAgICAgICAgICAgICAgICAgICAgMHgwMDAwNDAwMCwgMHgwMCkNCiAgICAg ICAgICAgICAgICBEV29yZE1lbW9yeSAoUmVzb3VyY2VQcm9kdWNlciwgUG9zRGVjb2RlLCBNaW5G aXhlZCwgTWF4Rml4ZWQsIENhY2hlYWJsZSwgUmVhZFdyaXRlLA0KICAgICAgICAgICAgICAgICAg ICAweDAwMDAwMDAwLA0KICAgICAgICAgICAgICAgICAgICAweDAwMEQ0MDAwLA0KICAgICAgICAg ICAgICAgICAgICAweDAwMEQ3RkZGLA0KICAgICAgICAgICAgICAgICAgICAweDAwMDAwMDAwLA0K ICAgICAgICAgICAgICAgICAgICAweDAwMDA0MDAwLCAweDAwKQ0KICAgICAgICAgICAgICAgIERX b3JkTWVtb3J5IChSZXNvdXJjZVByb2R1Y2VyLCBQb3NEZWNvZGUsIE1pbkZpeGVkLCBNYXhGaXhl ZCwgQ2FjaGVhYmxlLCBSZWFkV3JpdGUsDQogICAgICAgICAgICAgICAgICAgIDB4MDAwMDAwMDAs DQogICAgICAgICAgICAgICAgICAgIDB4MDAwRDgwMDAsDQogICAgICAgICAgICAgICAgICAgIDB4 MDAwREJGRkYsDQogICAgICAgICAgICAgICAgICAgIDB4MDAwMDAwMDAsDQogICAgICAgICAgICAg ICAgICAgIDB4MDAwMDQwMDAsIDB4MDApDQogICAgICAgICAgICAgICAgRFdvcmRNZW1vcnkgKFJl c291cmNlUHJvZHVjZXIsIFBvc0RlY29kZSwgTWluRml4ZWQsIE1heEZpeGVkLCBDYWNoZWFibGUs IFJlYWRXcml0ZSwNCiAgICAgICAgICAgICAgICAgICAgMHgwMDAwMDAwMCwNCiAgICAgICAgICAg ICAgICAgICAgMHgwMDBEQzAwMCwNCiAgICAgICAgICAgICAgICAgICAgMHgwMDBERkZGRiwNCiAg ICAgICAgICAgICAgICAgICAgMHgwMDAwMDAwMCwNCiAgICAgICAgICAgICAgICAgICAgMHgwMDAw NDAwMCwgMHgwMCkNCiAgICAgICAgICAgICAgICBEV29yZE1lbW9yeSAoUmVzb3VyY2VQcm9kdWNl ciwgUG9zRGVjb2RlLCBNaW5GaXhlZCwgTWF4Rml4ZWQsIENhY2hlYWJsZSwgUmVhZFdyaXRlLA0K ICAgICAgICAgICAgICAgICAgICAweDAwMDAwMDAwLA0KICAgICAgICAgICAgICAgICAgICAweDAw MEUwMDAwLA0KICAgICAgICAgICAgICAgICAgICAweDAwMEUzRkZGLA0KICAgICAgICAgICAgICAg ICAgICAweDAwMDAwMDAwLA0KICAgICAgICAgICAgICAgICAgICAweDAwMDA0MDAwLCAweDAwKQ0K ICAgICAgICAgICAgICAgIERXb3JkTWVtb3J5IChSZXNvdXJjZVByb2R1Y2VyLCBQb3NEZWNvZGUs IE1pbkZpeGVkLCBNYXhGaXhlZCwgQ2FjaGVhYmxlLCBSZWFkV3JpdGUsDQogICAgICAgICAgICAg ICAgICAgIDB4MDAwMDAwMDAsDQogICAgICAgICAgICAgICAgICAgIDB4MDAwRTQwMDAsDQogICAg ICAgICAgICAgICAgICAgIDB4MDAwRTdGRkYsDQogICAgICAgICAgICAgICAgICAgIDB4MDAwMDAw MDAsDQogICAgICAgICAgICAgICAgICAgIDB4MDAwMDQwMDAsIDB4MDApDQogICAgICAgICAgICAg ICAgRFdvcmRNZW1vcnkgKFJlc291cmNlUHJvZHVjZXIsIFBvc0RlY29kZSwgTWluRml4ZWQsIE1h eEZpeGVkLCBDYWNoZWFibGUsIFJlYWRXcml0ZSwNCiAgICAgICAgICAgICAgICAgICAgMHgwMDAw MDAwMCwNCiAgICAgICAgICAgICAgICAgICAgMHgwMDBFODAwMCwNCiAgICAgICAgICAgICAgICAg ICAgMHgwMDBFQkZGRiwNCiAgICAgICAgICAgICAgICAgICAgMHgwMDAwMDAwMCwNCiAgICAgICAg ICAgICAgICAgICAgMHgwMDAwNDAwMCwgMHgwMCkNCiAgICAgICAgICAgICAgICBEV29yZE1lbW9y eSAoUmVzb3VyY2VQcm9kdWNlciwgUG9zRGVjb2RlLCBNaW5GaXhlZCwgTWF4Rml4ZWQsIENhY2hl YWJsZSwgUmVhZFdyaXRlLA0KICAgICAgICAgICAgICAgICAgICAweDAwMDAwMDAwLA0KICAgICAg ICAgICAgICAgICAgICAweDAwMEVDMDAwLA0KICAgICAgICAgICAgICAgICAgICAweDAwMEVGRkZG LA0KICAgICAgICAgICAgICAgICAgICAweDAwMDAwMDAwLA0KICAgICAgICAgICAgICAgICAgICAw eDAwMDA0MDAwLCAweDAwKQ0KICAgICAgICAgICAgICAgIERXb3JkTWVtb3J5IChSZXNvdXJjZVBy b2R1Y2VyLCBQb3NEZWNvZGUsIE1pbkZpeGVkLCBNYXhGaXhlZCwgQ2FjaGVhYmxlLCBSZWFkV3Jp dGUsDQogICAgICAgICAgICAgICAgICAgIDB4MDAwMDAwMDAsDQogICAgICAgICAgICAgICAgICAg IDB4MDAwRjAwMDAsDQogICAgICAgICAgICAgICAgICAgIDB4MDAwRkZGRkYsDQogICAgICAgICAg ICAgICAgICAgIDB4MDAwMDAwMDAsDQogICAgICAgICAgICAgICAgICAgIDB4MDAwMTAwMDAsIDB4 MDApDQogICAgICAgICAgICAgICAgRFdvcmRNZW1vcnkgKFJlc291cmNlUHJvZHVjZXIsIFBvc0Rl Y29kZSwgTWluRml4ZWQsIE1heEZpeGVkLCBDYWNoZWFibGUsIFJlYWRXcml0ZSwNCiAgICAgICAg ICAgICAgICAgICAgMHgwMDAwMDAwMCwNCiAgICAgICAgICAgICAgICAgICAgMHgwMDAwMDAwMCwN CiAgICAgICAgICAgICAgICAgICAgMHhGRUJGRkZGRiwNCiAgICAgICAgICAgICAgICAgICAgMHgw MDAwMDAwMCwNCiAgICAgICAgICAgICAgICAgICAgMHgwMDAwMDAwMCwgMHgwMCkNCiAgICAgICAg ICAgIH0pDQogICAgICAgICAgICBNZXRob2QgKF9DUlMsIDAsIFNlcmlhbGl6ZWQpDQogICAgICAg ICAgICB7DQogICAgICAgICAgICAgICAgSWYgKFBNMUwpDQogICAgICAgICAgICAgICAgew0KICAg ICAgICAgICAgICAgICAgICBDcmVhdGVEV29yZEZpZWxkIChCVUYwLCAweDgwLCBDMExOKQ0KICAg ICAgICAgICAgICAgICAgICBTdG9yZSAoWmVybywgQzBMTikNCiAgICAgICAgICAgICAgICB9DQoN CiAgICAgICAgICAgICAgICBJZiAoTEVxdWFsIChQTTFMLCAweDAxKSkNCiAgICAgICAgICAgICAg ICB7DQogICAgICAgICAgICAgICAgICAgIENyZWF0ZUJpdEZpZWxkIChCVUYwLCAweDAzNzgsIEMw UlcpDQogICAgICAgICAgICAgICAgICAgIFN0b3JlIChaZXJvLCBDMFJXKQ0KICAgICAgICAgICAg ICAgIH0NCg0KICAgICAgICAgICAgICAgIElmIChQTTFIKQ0KICAgICAgICAgICAgICAgIHsNCiAg ICAgICAgICAgICAgICAgICAgQ3JlYXRlRFdvcmRGaWVsZCAoQlVGMCwgMHg5QiwgQzRMTikNCiAg ICAgICAgICAgICAgICAgICAgU3RvcmUgKFplcm8sIEM0TE4pDQogICAgICAgICAgICAgICAgfQ0K DQogICAgICAgICAgICAgICAgSWYgKExFcXVhbCAoUE0xSCwgMHgwMSkpDQogICAgICAgICAgICAg ICAgew0KICAgICAgICAgICAgICAgICAgICBDcmVhdGVCaXRGaWVsZCAoQlVGMCwgMHgwNDUwLCBD NFJXKQ0KICAgICAgICAgICAgICAgICAgICBTdG9yZSAoWmVybywgQzRSVykNCiAgICAgICAgICAg ICAgICB9DQoNCiAgICAgICAgICAgICAgICBJZiAoUE0yTCkNCiAgICAgICAgICAgICAgICB7DQog ICAgICAgICAgICAgICAgICAgIENyZWF0ZURXb3JkRmllbGQgKEJVRjAsIDB4QjYsIEM4TE4pDQog ICAgICAgICAgICAgICAgICAgIFN0b3JlIChaZXJvLCBDOExOKQ0KICAgICAgICAgICAgICAgIH0N Cg0KICAgICAgICAgICAgICAgIElmIChMRXF1YWwgKFBNMkwsIDB4MDEpKQ0KICAgICAgICAgICAg ICAgIHsNCiAgICAgICAgICAgICAgICAgICAgQ3JlYXRlQml0RmllbGQgKEJVRjAsIDB4MDUyOCwg QzhSVykNCiAgICAgICAgICAgICAgICAgICAgU3RvcmUgKFplcm8sIEM4UlcpDQogICAgICAgICAg ICAgICAgfQ0KDQogICAgICAgICAgICAgICAgSWYgKFBNMkgpDQogICAgICAgICAgICAgICAgew0K ICAgICAgICAgICAgICAgICAgICBDcmVhdGVEV29yZEZpZWxkIChCVUYwLCAweEQxLCBDQ0xOKQ0K ICAgICAgICAgICAgICAgICAgICBTdG9yZSAoWmVybywgQ0NMTikNCiAgICAgICAgICAgICAgICB9 DQoNCiAgICAgICAgICAgICAgICBJZiAoTEVxdWFsIChQTTJILCAweDAxKSkNCiAgICAgICAgICAg ICAgICB7DQogICAgICAgICAgICAgICAgICAgIENyZWF0ZUJpdEZpZWxkIChCVUYwLCAweDA2MDAs IENDUlcpDQogICAgICAgICAgICAgICAgICAgIFN0b3JlIChaZXJvLCBDQ1JXKQ0KICAgICAgICAg ICAgICAgIH0NCg0KICAgICAgICAgICAgICAgIElmIChQTTNMKQ0KICAgICAgICAgICAgICAgIHsN CiAgICAgICAgICAgICAgICAgICAgQ3JlYXRlRFdvcmRGaWVsZCAoQlVGMCwgMHhFQywgRDBMTikN CiAgICAgICAgICAgICAgICAgICAgU3RvcmUgKFplcm8sIEQwTE4pDQogICAgICAgICAgICAgICAg fQ0KDQogICAgICAgICAgICAgICAgSWYgKExFcXVhbCAoUE0zTCwgMHgwMSkpDQogICAgICAgICAg ICAgICAgew0KICAgICAgICAgICAgICAgICAgICBDcmVhdGVCaXRGaWVsZCAoQlVGMCwgMHgwNkQ4 LCBEMFJXKQ0KICAgICAgICAgICAgICAgICAgICBTdG9yZSAoWmVybywgRDBSVykNCiAgICAgICAg ICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBJZiAoUE0zSCkNCiAgICAgICAgICAgICAgICB7 DQogICAgICAgICAgICAgICAgICAgIENyZWF0ZURXb3JkRmllbGQgKEJVRjAsIDB4MDEwNywgRDRM TikNCiAgICAgICAgICAgICAgICAgICAgU3RvcmUgKFplcm8sIEQ0TE4pDQogICAgICAgICAgICAg ICAgfQ0KDQogICAgICAgICAgICAgICAgSWYgKExFcXVhbCAoUE0zSCwgMHgwMSkpDQogICAgICAg ICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBDcmVhdGVCaXRGaWVsZCAoQlVGMCwgMHgw N0IwLCBENFJXKQ0KICAgICAgICAgICAgICAgICAgICBTdG9yZSAoWmVybywgRDRSVykNCiAgICAg ICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBJZiAoUE00TCkNCiAgICAgICAgICAgICAg ICB7DQogICAgICAgICAgICAgICAgICAgIENyZWF0ZURXb3JkRmllbGQgKEJVRjAsIDB4MDEyMiwg RDhMTikNCiAgICAgICAgICAgICAgICAgICAgU3RvcmUgKFplcm8sIEQ4TE4pDQogICAgICAgICAg ICAgICAgfQ0KDQogICAgICAgICAgICAgICAgSWYgKExFcXVhbCAoUE00TCwgMHgwMSkpDQogICAg ICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBDcmVhdGVCaXRGaWVsZCAoQlVGMCwg MHgwODg4LCBEOFJXKQ0KICAgICAgICAgICAgICAgICAgICBTdG9yZSAoWmVybywgRDhSVykNCiAg ICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBJZiAoUE00SCkNCiAgICAgICAgICAg ICAgICB7DQogICAgICAgICAgICAgICAgICAgIENyZWF0ZURXb3JkRmllbGQgKEJVRjAsIDB4MDEz RCwgRENMTikNCiAgICAgICAgICAgICAgICAgICAgU3RvcmUgKFplcm8sIERDTE4pDQogICAgICAg ICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgSWYgKExFcXVhbCAoUE00SCwgMHgwMSkpDQog ICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBDcmVhdGVCaXRGaWVsZCAoQlVG MCwgMHgwOTYwLCBEQ1JXKQ0KICAgICAgICAgICAgICAgICAgICBTdG9yZSAoWmVybywgRENSVykN CiAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBJZiAoUE01TCkNCiAgICAgICAg ICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgIENyZWF0ZURXb3JkRmllbGQgKEJVRjAsIDB4 MDE1OCwgRTBMTikNCiAgICAgICAgICAgICAgICAgICAgU3RvcmUgKFplcm8sIEUwTE4pDQogICAg ICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgSWYgKExFcXVhbCAoUE01TCwgMHgwMSkp DQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBDcmVhdGVCaXRGaWVsZCAo QlVGMCwgMHgwQTM4LCBFMFJXKQ0KICAgICAgICAgICAgICAgICAgICBTdG9yZSAoWmVybywgRTBS VykNCiAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBJZiAoUE01SCkNCiAgICAg ICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgIENyZWF0ZURXb3JkRmllbGQgKEJVRjAs IDB4MDE3MywgRTRMTikNCiAgICAgICAgICAgICAgICAgICAgU3RvcmUgKFplcm8sIEU0TE4pDQog ICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgSWYgKExFcXVhbCAoUE01SCwgMHgw MSkpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBDcmVhdGVCaXRGaWVs ZCAoQlVGMCwgMHgwQjEwLCBFNFJXKQ0KICAgICAgICAgICAgICAgICAgICBTdG9yZSAoWmVybywg RTRSVykNCiAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBJZiAoUE02TCkNCiAg ICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgIENyZWF0ZURXb3JkRmllbGQgKEJV RjAsIDB4MDE4RSwgRThMTikNCiAgICAgICAgICAgICAgICAgICAgU3RvcmUgKFplcm8sIEU4TE4p DQogICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgSWYgKExFcXVhbCAoUE02TCwg MHgwMSkpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBDcmVhdGVCaXRG aWVsZCAoQlVGMCwgMHgwQkU4LCBFOFJXKQ0KICAgICAgICAgICAgICAgICAgICBTdG9yZSAoWmVy bywgRThSVykNCiAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBJZiAoUE02SCkN CiAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgIENyZWF0ZURXb3JkRmllbGQg KEJVRjAsIDB4MDFBOSwgRUNMTikNCiAgICAgICAgICAgICAgICAgICAgU3RvcmUgKFplcm8sIEVD TE4pDQogICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgSWYgKExFcXVhbCAoUE02 SCwgMHgwMSkpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBDcmVhdGVC aXRGaWVsZCAoQlVGMCwgMHgwQ0MwLCBFQ1JXKQ0KICAgICAgICAgICAgICAgICAgICBTdG9yZSAo WmVybywgRUNSVykNCiAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBJZiAoUE0w SCkNCiAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgIENyZWF0ZURXb3JkRmll bGQgKEJVRjAsIDB4MDFDNCwgRjBMTikNCiAgICAgICAgICAgICAgICAgICAgU3RvcmUgKFplcm8s IEYwTE4pDQogICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgSWYgKExFcXVhbCAo UE0wSCwgMHgwMSkpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBDcmVh dGVCaXRGaWVsZCAoQlVGMCwgMHgwRDk4LCBGMFJXKQ0KICAgICAgICAgICAgICAgICAgICBTdG9y ZSAoWmVybywgRjBSVykNCiAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBDcmVh dGVEV29yZEZpZWxkIChCVUYwLCAweDAxRDMsIE0xTU4pDQogICAgICAgICAgICAgICAgQ3JlYXRl RFdvcmRGaWVsZCAoQlVGMCwgMHgwMUQ3LCBNMU1YKQ0KICAgICAgICAgICAgICAgIENyZWF0ZURX b3JkRmllbGQgKEJVRjAsIDB4MDFERiwgTTFMTikNCiAgICAgICAgICAgICAgICBNdWx0aXBseSAo MHgwMjAwMDAwMCwgRFJCMywgTTFNTikNCiAgICAgICAgICAgICAgICBBZGQgKFN1YnRyYWN0IChN MU1YLCBNMU1OKSwgMHgwMSwgTTFMTikNCiAgICAgICAgICAgICAgICBSZXR1cm4gKEJVRjApDQog ICAgICAgICAgICB9DQoNCiAgICAgICAgICAgIE1ldGhvZCAoX1BSVCwgMCwgTm90U2VyaWFsaXpl ZCkNCiAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICBSZXR1cm4gKFBhY2thZ2UgKDB4MDkp DQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBQYWNrYWdlICgweDA0KQ0K ICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAweDAwMDFGRkZG LCANCiAgICAgICAgICAgICAgICAgICAgICAgIDB4MDAsIA0KICAgICAgICAgICAgICAgICAgICAg ICAgXF9TQi5QQ0kwLkxQQ0IuTE5LQSwgDQogICAgICAgICAgICAgICAgICAgICAgICAweDAwDQog ICAgICAgICAgICAgICAgICAgIH0sIA0KDQogICAgICAgICAgICAgICAgICAgIFBhY2thZ2UgKDB4 MDQpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIDB4MDAw MUZGRkYsIA0KICAgICAgICAgICAgICAgICAgICAgICAgMHgwMSwgDQogICAgICAgICAgICAgICAg ICAgICAgICBcX1NCLlBDSTAuTFBDQi5MTktCLCANCiAgICAgICAgICAgICAgICAgICAgICAgIDB4 MDANCiAgICAgICAgICAgICAgICAgICAgfSwgDQoNCiAgICAgICAgICAgICAgICAgICAgUGFja2Fn ZSAoMHgwNCkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAg MHgwMDAxRkZGRiwgDQogICAgICAgICAgICAgICAgICAgICAgICAweDAyLCANCiAgICAgICAgICAg ICAgICAgICAgICAgIFxfU0IuUENJMC5MUENCLkxOS0MsIA0KICAgICAgICAgICAgICAgICAgICAg ICAgMHgwMA0KICAgICAgICAgICAgICAgICAgICB9LCANCg0KICAgICAgICAgICAgICAgICAgICBQ YWNrYWdlICgweDA0KQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAg ICAgICAweDAwMDFGRkZGLCANCiAgICAgICAgICAgICAgICAgICAgICAgIDB4MDMsIA0KICAgICAg ICAgICAgICAgICAgICAgICAgXF9TQi5QQ0kwLkxQQ0IuTE5LRCwgDQogICAgICAgICAgICAgICAg ICAgICAgICAweDAwDQogICAgICAgICAgICAgICAgICAgIH0sIA0KDQogICAgICAgICAgICAgICAg ICAgIFBhY2thZ2UgKDB4MDQpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAg ICAgICAgICAgIDB4MDAxREZGRkYsIA0KICAgICAgICAgICAgICAgICAgICAgICAgMHgwMCwgDQog ICAgICAgICAgICAgICAgICAgICAgICBcX1NCLlBDSTAuTFBDQi5MTktBLCANCiAgICAgICAgICAg ICAgICAgICAgICAgIDB4MDANCiAgICAgICAgICAgICAgICAgICAgfSwgDQoNCiAgICAgICAgICAg ICAgICAgICAgUGFja2FnZSAoMHgwNCkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAg ICAgICAgICAgICAgICAgMHgwMDFERkZGRiwgDQogICAgICAgICAgICAgICAgICAgICAgICAweDAx LCANCiAgICAgICAgICAgICAgICAgICAgICAgIFxfU0IuUENJMC5MUENCLkxOS0QsIA0KICAgICAg ICAgICAgICAgICAgICAgICAgMHgwMA0KICAgICAgICAgICAgICAgICAgICB9LCANCg0KICAgICAg ICAgICAgICAgICAgICBQYWNrYWdlICgweDA0KQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAg ICAgICAgICAgICAgICAgICAgICAweDAwMURGRkZGLCANCiAgICAgICAgICAgICAgICAgICAgICAg IDB4MDIsIA0KICAgICAgICAgICAgICAgICAgICAgICAgXF9TQi5QQ0kwLkxQQ0IuTE5LQywgDQog ICAgICAgICAgICAgICAgICAgICAgICAweDAwDQogICAgICAgICAgICAgICAgICAgIH0sIA0KDQog ICAgICAgICAgICAgICAgICAgIFBhY2thZ2UgKDB4MDQpDQogICAgICAgICAgICAgICAgICAgIHsN CiAgICAgICAgICAgICAgICAgICAgICAgIDB4MDAxREZGRkYsIA0KICAgICAgICAgICAgICAgICAg ICAgICAgMHgwMywgDQogICAgICAgICAgICAgICAgICAgICAgICBcX1NCLlBDSTAuTFBDQi5MTktI LCANCiAgICAgICAgICAgICAgICAgICAgICAgIDB4MDANCiAgICAgICAgICAgICAgICAgICAgfSwg DQoNCiAgICAgICAgICAgICAgICAgICAgUGFja2FnZSAoMHgwNCkNCiAgICAgICAgICAgICAgICAg ICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgMHgwMDFGRkZGRiwgDQogICAgICAgICAgICAg ICAgICAgICAgICAweDAxLCANCiAgICAgICAgICAgICAgICAgICAgICAgIFxfU0IuUENJMC5MUENC LkxOS0IsIA0KICAgICAgICAgICAgICAgICAgICAgICAgMHgwMA0KICAgICAgICAgICAgICAgICAg ICB9DQogICAgICAgICAgICAgICAgfSkNCiAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgRGV2 aWNlIChBR1BCKQ0KICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgIE5hbWUgKF9BRFIsIDB4 MDAwMTAwMDApDQogICAgICAgICAgICAgICAgTWV0aG9kIChfUFJULCAwLCBOb3RTZXJpYWxpemVk KQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgUmV0dXJuIChQYWNrYWdl ICgweDAxKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBQ YWNrYWdlICgweDA0KQ0KICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDB4RkZGRiwgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgMHgwMCwg DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgXF9TQi5QQ0kwLkxQQ0IuTE5LQSwgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgMHgwMA0KICAgICAgICAgICAgICAgICAgICAgICAgfQ0K ICAgICAgICAgICAgICAgICAgICB9KQ0KICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAg ICAgIERldmljZSAoVklEMCkNCiAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAg IE5hbWUgKF9BRFIsIDB4MDApDQogICAgICAgICAgICAgICAgICAgIE9wZXJhdGlvblJlZ2lvbiAo VklEUiwgUENJX0NvbmZpZywgMHg0QywgMHgwNCkNCiAgICAgICAgICAgICAgICAgICAgRmllbGQg KFZJRFIsIEJ5dGVBY2MsIE5vTG9jaywgUHJlc2VydmUpDQogICAgICAgICAgICAgICAgICAgIHsN CiAgICAgICAgICAgICAgICAgICAgICAgIFNTSUQsICAgMzINCiAgICAgICAgICAgICAgICAgICAg fQ0KDQogICAgICAgICAgICAgICAgICAgIERldmljZSAoQ1JUKQ0KICAgICAgICAgICAgICAgICAg ICB7DQogICAgICAgICAgICAgICAgICAgICAgICBOYW1lIChfQURSLCAweDAxMDApDQogICAgICAg ICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICBEZXZpY2UgKExDRCkNCiAgICAg ICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgTmFtZSAoX0FEUiwgMHgw MTEwKQ0KICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgRGV2aWNl IChUVikNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgTmFt ZSAoX0FEUiwgMHgwMjAwKQ0KICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAg fQ0KICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICBEZXZpY2UgKFBDSUIpDQogICAgICAgICAg ICB7DQogICAgICAgICAgICAgICAgTmFtZSAoX0FEUiwgMHgwMDFFMDAwMCkNCiAgICAgICAgICAg ICAgICBEZXZpY2UgKExBTkMpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAg ICBOYW1lIChfQURSLCAweDAwMDgwMDAwKQ0KICAgICAgICAgICAgICAgICAgICBOYW1lIChfUFJX LCBQYWNrYWdlICgweDAyKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAg ICAgICAgICAweDBCLCANCiAgICAgICAgICAgICAgICAgICAgICAgIDB4MDMNCiAgICAgICAgICAg ICAgICAgICAgfSkNCiAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBEZXZpY2Ug KFdMQU4pDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBOYW1lIChfQURS LCAweDAwMEIwMDAwKQ0KICAgICAgICAgICAgICAgICAgICBOYW1lIChfUFNDLCAweDAwKQ0KICAg ICAgICAgICAgICAgICAgICBNZXRob2QgKF9QUzAsIDAsIE5vdFNlcmlhbGl6ZWQpDQogICAgICAg ICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlICgweDAwLCBfUFND KQ0KICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgTWV0aG9kIChf UFMzLCAwLCBOb3RTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAg ICAgICAgICAgICAgICBTdG9yZSAoMHgwMywgX1BTQykNCiAgICAgICAgICAgICAgICAgICAgfQ0K DQogICAgICAgICAgICAgICAgICAgIE1ldGhvZCAoX1NUQSwgMCwgTm90U2VyaWFsaXplZCkNCiAg ICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgUmV0dXJuICgweDBG KQ0KICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAg ICAgICAgRGV2aWNlIChDUkQwKQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAg ICAgTmFtZSAoX0FEUiwgMHgwMDA1MDAwMCkNCiAgICAgICAgICAgICAgICAgICAgT3BlcmF0aW9u UmVnaW9uIChDQ1JELCBQQ0lfQ29uZmlnLCAweDAwLCAweEU0KQ0KICAgICAgICAgICAgICAgICAg ICBGaWVsZCAoQ0NSRCwgRFdvcmRBY2MsIE5vTG9jaywgUHJlc2VydmUpDQogICAgICAgICAgICAg ICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIE9mZnNldCAoMHgwNCksIA0KICAgICAg ICAgICAgICAgICAgICAgICAgQ0QwNCwgICAzMiwgDQogICAgICAgICAgICAgICAgICAgICAgICBP ZmZzZXQgKDB4M0UpLCANCiAgICAgICAgICAgICAgICAgICAgICAgIENEM0UsICAgMzIsIA0KICAg ICAgICAgICAgICAgICAgICAgICAgT2Zmc2V0ICgweDQ0KSwgDQogICAgICAgICAgICAgICAgICAg ICAgICBDRDQ0LCAgIDMyLCANCiAgICAgICAgICAgICAgICAgICAgICAgIE9mZnNldCAoMHhFMCks IA0KICAgICAgICAgICAgICAgICAgICAgICAgQ0RFMCwgICA4LCANCiAgICAgICAgICAgICAgICAg ICAgICAgIENERTEsICAgOA0KICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAg ICAgICAgTWV0aG9kIChfSU5JLCAwLCBOb3RTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAgICAg ICB7DQogICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoWmVybywgQ0Q0NCkNCiAgICAgICAg ICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgIE5hbWUgKF9QU0MsIDB4MDApDQog ICAgICAgICAgICAgICAgICAgIE1ldGhvZCAoX1BTMCwgMCwgTm90U2VyaWFsaXplZCkNCiAgICAg ICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKDB4MDAsIF9Q U0MpDQogICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICBNZXRob2Qg KF9QUzMsIDAsIE5vdFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAg ICAgICAgICAgICAgICAgIFN0b3JlICgweDAzLCBfUFNDKQ0KICAgICAgICAgICAgICAgICAgICB9 DQoNCiAgICAgICAgICAgICAgICAgICAgTWV0aG9kIChfU1RBLCAwLCBOb3RTZXJpYWxpemVkKQ0K ICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBSZXR1cm4gKDB4 MEYpDQogICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICBOYW1lIChf UFJXLCBQYWNrYWdlICgweDAyKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAg ICAgICAgICAgICAweDBCLCANCiAgICAgICAgICAgICAgICAgICAgICAgIDB4MDMNCiAgICAgICAg ICAgICAgICAgICAgfSkNCiAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBEZXZp Y2UgKFNEOTQpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBOYW1lIChf QURSLCAweDAwMDUwMDAxKQ0KICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgIE1l dGhvZCAoX1BSVCwgMCwgTm90U2VyaWFsaXplZCkNCiAgICAgICAgICAgICAgICB7DQogICAgICAg ICAgICAgICAgICAgIFJldHVybiAoUGFja2FnZSAoMHgwNSkNCiAgICAgICAgICAgICAgICAgICAg ew0KICAgICAgICAgICAgICAgICAgICAgICAgUGFja2FnZSAoMHgwNCkNCiAgICAgICAgICAgICAg ICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAweDAwMDVGRkZGLCANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAweDAwLCANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICBcX1NCLlBDSTAuTFBDQi5MTktGLCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAw eDAwDQogICAgICAgICAgICAgICAgICAgICAgICB9LCANCg0KICAgICAgICAgICAgICAgICAgICAg ICAgUGFja2FnZSAoMHgwNCkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAweDAwMDVGRkZGLCANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAweDAxLCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBcX1NCLlBDSTAuTFBDQi5MTktH LCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAweDAwDQogICAgICAgICAgICAgICAgICAg ICAgICB9LCANCg0KICAgICAgICAgICAgICAgICAgICAgICAgUGFja2FnZSAoMHgwNCkNCiAgICAg ICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAweDAwMEJG RkZGLCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAweDAwLCANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICBcX1NCLlBDSTAuTFBDQi5MTktELCANCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAweDAwDQogICAgICAgICAgICAgICAgICAgICAgICB9LCANCg0KICAgICAgICAgICAg ICAgICAgICAgICAgUGFja2FnZSAoMHgwNCkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAweDAwMDRGRkZGLCANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAweDAwLCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBcX1NCLlBDSTAu TFBDQi5MTktFLCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAweDAwDQogICAgICAgICAg ICAgICAgICAgICAgICB9LCANCg0KICAgICAgICAgICAgICAgICAgICAgICAgUGFja2FnZSAoMHgw NCkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAweDAwMDhGRkZGLCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAweDAwLCANCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBcX1NCLlBDSTAuTFBDQi5MTktFLCANCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAweDAwDQogICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAg ICAgICAgICAgICAgIH0pDQogICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgfQ0KDQogICAg ICAgICAgICBEZXZpY2UgKExQQ0IpDQogICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgTmFt ZSAoX0FEUiwgMHgwMDFGMDAwMCkNCiAgICAgICAgICAgICAgICBPcGVyYXRpb25SZWdpb24gKExQ QzAsIFBDSV9Db25maWcsIDB4NDAsIDB4QzApDQogICAgICAgICAgICAgICAgRmllbGQgKExQQzAs IEFueUFjYywgTm9Mb2NrLCBQcmVzZXJ2ZSkNCiAgICAgICAgICAgICAgICB7DQogICAgICAgICAg ICAgICAgICAgIE9mZnNldCAoMHgyMCksIA0KICAgICAgICAgICAgICAgICAgICBQSVJBLCAgIDgs IA0KICAgICAgICAgICAgICAgICAgICBQSVJCLCAgIDgsIA0KICAgICAgICAgICAgICAgICAgICBQ SVJDLCAgIDgsIA0KICAgICAgICAgICAgICAgICAgICBQSVJELCAgIDgsIA0KICAgICAgICAgICAg ICAgICAgICBPZmZzZXQgKDB4MjgpLCANCiAgICAgICAgICAgICAgICAgICAgUElSRSwgICA4LCAN CiAgICAgICAgICAgICAgICAgICAgUElSRiwgICA4LCANCiAgICAgICAgICAgICAgICAgICAgUElS RywgICA4LCANCiAgICAgICAgICAgICAgICAgICAgUElSSCwgICA4LCANCiAgICAgICAgICAgICAg ICAgICAgT2Zmc2V0ICgweDkwKSwgDQogICAgICAgICAgICAgICAgICAgIEhQVEUsICAgMzIsIA0K ICAgICAgICAgICAgICAgICAgICBPZmZzZXQgKDB4QTApLCANCiAgICAgICAgICAgICAgICAgICAg TERFMCwgICA4LCANCiAgICAgICAgICAgICAgICAgICAgTERFMSwgICA4DQogICAgICAgICAgICAg ICAgfQ0KDQogICAgICAgICAgICAgICAgRGV2aWNlIChMTktBKQ0KICAgICAgICAgICAgICAgIHsN CiAgICAgICAgICAgICAgICAgICAgTmFtZSAoX0hJRCwgRWlzYUlkICgiUE5QMEMwRiIpKQ0KICAg ICAgICAgICAgICAgICAgICBOYW1lIChfVUlELCAweDAxKQ0KICAgICAgICAgICAgICAgICAgICBN ZXRob2QgKF9ESVMsIDAsIFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAg ICAgICAgICAgICAgICAgICAgIFN0b3JlICgweDgwLCBQSVJBKQ0KICAgICAgICAgICAgICAgICAg ICB9DQoNCiAgICAgICAgICAgICAgICAgICAgTmFtZSAoX1BSUywgUmVzb3VyY2VUZW1wbGF0ZSAo KQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBJUlEgKExl dmVsLCBBY3RpdmVMb3csIFNoYXJlZCkgezl9DQogICAgICAgICAgICAgICAgICAgIH0pDQogICAg ICAgICAgICAgICAgICAgIE1ldGhvZCAoX0NSUywgMCwgU2VyaWFsaXplZCkNCiAgICAgICAgICAg ICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgTmFtZSAoUlRMQSwgUmVzb3VyY2VU ZW1wbGF0ZSAoKQ0KICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgIElSUSAoTGV2ZWwsIEFjdGl2ZUxvdywgU2hhcmVkKSB7fQ0KICAgICAgICAgICAg ICAgICAgICAgICAgfSkNCiAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZVdvcmRGaWVsZCAo UlRMQSwgMHgwMSwgSVJRMCkNCiAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlIChaZXJvLCBJ UlEwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgU2hpZnRMZWZ0ICgweDAxLCBBbmQgKFBJUkEs IDB4MEYpLCBJUlEwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgUmV0dXJuIChSVExBKQ0KICAg ICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgTWV0aG9kIChfU1JTLCAx LCBTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAg ICAgICBDcmVhdGVXb3JkRmllbGQgKEFyZzAsIDB4MDEsIElSUTApDQogICAgICAgICAgICAgICAg ICAgICAgICBGaW5kU2V0UmlnaHRCaXQgKElSUTAsIExvY2FsMCkNCiAgICAgICAgICAgICAgICAg ICAgICAgIERlY3JlbWVudCAoTG9jYWwwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUg KExvY2FsMCwgUElSQSkNCiAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAg ICAgIE1ldGhvZCAoX1NUQSwgMCwgU2VyaWFsaXplZCkNCiAgICAgICAgICAgICAgICAgICAgew0K ICAgICAgICAgICAgICAgICAgICAgICAgSWYgKEFuZCAoUElSQSwgMHg4MCkpDQogICAgICAgICAg ICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgUmV0dXJuICgweDA5 KQ0KICAgICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgICAgICAgRWxz ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAg IFJldHVybiAoMHgwQikNCiAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAg ICAgICAgfQ0KICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgIERldmljZSAoTE5L QikNCiAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgIE5hbWUgKF9ISUQsIEVp c2FJZCAoIlBOUDBDMEYiKSkNCiAgICAgICAgICAgICAgICAgICAgTmFtZSAoX1VJRCwgMHgwMikN CiAgICAgICAgICAgICAgICAgICAgTWV0aG9kIChfRElTLCAwLCBTZXJpYWxpemVkKQ0KICAgICAg ICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoMHg4MCwgUElS QikNCiAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgIE5hbWUgKF9Q UlMsIFJlc291cmNlVGVtcGxhdGUgKCkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAg ICAgICAgICAgICAgICAgSVJRIChMZXZlbCwgQWN0aXZlTG93LCBTaGFyZWQpIHs5fQ0KICAgICAg ICAgICAgICAgICAgICB9KQ0KICAgICAgICAgICAgICAgICAgICBNZXRob2QgKF9DUlMsIDAsIFNl cmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAg IE5hbWUgKFJUTEIsIFJlc291cmNlVGVtcGxhdGUgKCkNCiAgICAgICAgICAgICAgICAgICAgICAg IHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJUlEgKExldmVsLCBBY3RpdmVMb3csIFNo YXJlZCkge30NCiAgICAgICAgICAgICAgICAgICAgICAgIH0pDQogICAgICAgICAgICAgICAgICAg ICAgICBDcmVhdGVXb3JkRmllbGQgKFJUTEIsIDB4MDEsIElSUTApDQogICAgICAgICAgICAgICAg ICAgICAgICBTdG9yZSAoWmVybywgSVJRMCkNCiAgICAgICAgICAgICAgICAgICAgICAgIFNoaWZ0 TGVmdCAoMHgwMSwgQW5kIChQSVJCLCAweDBGKSwgSVJRMCkNCiAgICAgICAgICAgICAgICAgICAg ICAgIFJldHVybiAoUlRMQikNCiAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAg ICAgICAgIE1ldGhvZCAoX1NSUywgMSwgU2VyaWFsaXplZCkNCiAgICAgICAgICAgICAgICAgICAg ew0KICAgICAgICAgICAgICAgICAgICAgICAgQ3JlYXRlV29yZEZpZWxkIChBcmcwLCAweDAxLCBJ UlEwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgRmluZFNldFJpZ2h0Qml0IChJUlEwLCBMb2Nh bDApDQogICAgICAgICAgICAgICAgICAgICAgICBEZWNyZW1lbnQgKExvY2FsMCkNCiAgICAgICAg ICAgICAgICAgICAgICAgIFN0b3JlIChMb2NhbDAsIFBJUkIpDQogICAgICAgICAgICAgICAgICAg IH0NCg0KICAgICAgICAgICAgICAgICAgICBNZXRob2QgKF9TVEEsIDAsIFNlcmlhbGl6ZWQpDQog ICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIElmIChBbmQgKFBJ UkIsIDB4ODApKQ0KICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFJldHVybiAoMHgwOSkNCiAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAg ICAgICAgICAgICAgICAgICAgIEVsc2UNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBSZXR1cm4gKDB4MEIpDQogICAgICAgICAgICAgICAgICAg ICAgICB9DQogICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICB9DQoNCiAgICAg ICAgICAgICAgICBEZXZpY2UgKExOS0MpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAg ICAgICAgICBOYW1lIChfSElELCBFaXNhSWQgKCJQTlAwQzBGIikpDQogICAgICAgICAgICAgICAg ICAgIE5hbWUgKF9VSUQsIDB4MDMpDQogICAgICAgICAgICAgICAgICAgIE1ldGhvZCAoX0RJUywg MCwgU2VyaWFsaXplZCkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAg ICAgICAgU3RvcmUgKDB4ODAsIFBJUkMpDQogICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAg ICAgICAgICAgICAgICBOYW1lIChfUFJTLCBSZXNvdXJjZVRlbXBsYXRlICgpDQogICAgICAgICAg ICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIElSUSAoTGV2ZWwsIEFjdGl2ZUxv dywgU2hhcmVkKSB7OX0NCiAgICAgICAgICAgICAgICAgICAgfSkNCiAgICAgICAgICAgICAgICAg ICAgTWV0aG9kIChfQ1JTLCAwLCBTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAgICAgICB7DQog ICAgICAgICAgICAgICAgICAgICAgICBOYW1lIChSVExDLCBSZXNvdXJjZVRlbXBsYXRlICgpDQog ICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgSVJR IChMZXZlbCwgQWN0aXZlTG93LCBTaGFyZWQpIHt9DQogICAgICAgICAgICAgICAgICAgICAgICB9 KQ0KICAgICAgICAgICAgICAgICAgICAgICAgQ3JlYXRlV29yZEZpZWxkIChSVExDLCAweDAxLCBJ UlEwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKFplcm8sIElSUTApDQogICAgICAg ICAgICAgICAgICAgICAgICBTaGlmdExlZnQgKDB4MDEsIEFuZCAoUElSQywgMHgwRiksIElSUTAp DQogICAgICAgICAgICAgICAgICAgICAgICBSZXR1cm4gKFJUTEMpDQogICAgICAgICAgICAgICAg ICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICBNZXRob2QgKF9TUlMsIDEsIFNlcmlhbGl6ZWQp DQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZVdv cmRGaWVsZCAoQXJnMCwgMHgwMSwgSVJRMCkNCiAgICAgICAgICAgICAgICAgICAgICAgIEZpbmRT ZXRSaWdodEJpdCAoSVJRMCwgTG9jYWwwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgRGVjcmVt ZW50IChMb2NhbDApDQogICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoTG9jYWwwLCBQSVJD KQ0KICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgTWV0aG9kIChf U1RBLCAwLCBTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAg ICAgICAgICAgICBJZiAoQW5kIChQSVJDLCAweDgwKSkNCiAgICAgICAgICAgICAgICAgICAgICAg IHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZXR1cm4gKDB4MDkpDQogICAgICAgICAg ICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgICAgICAgICBFbHNlDQogICAgICAgICAg ICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgUmV0dXJuICgweDBC KQ0KICAgICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgICB9DQogICAg ICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgRGV2aWNlIChMTktEKQ0KICAgICAgICAg ICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgTmFtZSAoX0hJRCwgRWlzYUlkICgiUE5QMEMw RiIpKQ0KICAgICAgICAgICAgICAgICAgICBOYW1lIChfVUlELCAweDA0KQ0KICAgICAgICAgICAg ICAgICAgICBNZXRob2QgKF9ESVMsIDAsIFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgICAg IHsNCiAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlICgweDgwLCBQSVJEKQ0KICAgICAgICAg ICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgTmFtZSAoX1BSUywgUmVzb3VyY2VU ZW1wbGF0ZSAoKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAg ICBJUlEgKExldmVsLCBBY3RpdmVMb3csIFNoYXJlZCkgezl9DQogICAgICAgICAgICAgICAgICAg IH0pDQogICAgICAgICAgICAgICAgICAgIE1ldGhvZCAoX0NSUywgMCwgU2VyaWFsaXplZCkNCiAg ICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgTmFtZSAoUlRMRCwg UmVzb3VyY2VUZW1wbGF0ZSAoKQ0KICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIElSUSAoTGV2ZWwsIEFjdGl2ZUxvdywgU2hhcmVkKSB7fQ0KICAg ICAgICAgICAgICAgICAgICAgICAgfSkNCiAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZVdv cmRGaWVsZCAoUlRMRCwgMHgwMSwgSVJRMCkNCiAgICAgICAgICAgICAgICAgICAgICAgIFN0b3Jl IChaZXJvLCBJUlEwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgU2hpZnRMZWZ0ICgweDAxLCBB bmQgKFBJUkQsIDB4MEYpLCBJUlEwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgUmV0dXJuIChS VExEKQ0KICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgTWV0aG9k IChfU1JTLCAxLCBTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAg ICAgICAgICAgICAgICBDcmVhdGVXb3JkRmllbGQgKEFyZzAsIDB4MDEsIElSUTApDQogICAgICAg ICAgICAgICAgICAgICAgICBGaW5kU2V0UmlnaHRCaXQgKElSUTAsIExvY2FsMCkNCiAgICAgICAg ICAgICAgICAgICAgICAgIERlY3JlbWVudCAoTG9jYWwwKQ0KICAgICAgICAgICAgICAgICAgICAg ICAgU3RvcmUgKExvY2FsMCwgUElSRCkNCiAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAg ICAgICAgICAgICAgIE1ldGhvZCAoX1NUQSwgMCwgU2VyaWFsaXplZCkNCiAgICAgICAgICAgICAg ICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgSWYgKEFuZCAoUElSRCwgMHg4MCkpDQog ICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgUmV0 dXJuICgweDA5KQ0KICAgICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAg ICAgICAgRWxzZQ0KICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFJldHVybiAoMHgwQikNCiAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAg ICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgIERl dmljZSAoTE5LRSkNCiAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgIE5hbWUg KF9ISUQsIEVpc2FJZCAoIlBOUDBDMEYiKSkNCiAgICAgICAgICAgICAgICAgICAgTmFtZSAoX1VJ RCwgMHgwNSkNCiAgICAgICAgICAgICAgICAgICAgTWV0aG9kIChfRElTLCAwLCBTZXJpYWxpemVk KQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAo MHg4MCwgUElSRSkNCiAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAg IE5hbWUgKF9QUlMsIFJlc291cmNlVGVtcGxhdGUgKCkNCiAgICAgICAgICAgICAgICAgICAgew0K ICAgICAgICAgICAgICAgICAgICAgICAgSVJRIChMZXZlbCwgQWN0aXZlTG93LCBTaGFyZWQpIHs5 fQ0KICAgICAgICAgICAgICAgICAgICB9KQ0KICAgICAgICAgICAgICAgICAgICBNZXRob2QgKF9D UlMsIDAsIFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAg ICAgICAgICAgIE5hbWUgKFJUTEUsIFJlc291cmNlVGVtcGxhdGUgKCkNCiAgICAgICAgICAgICAg ICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJUlEgKExldmVsLCBBY3Rp dmVMb3csIFNoYXJlZCkge30NCiAgICAgICAgICAgICAgICAgICAgICAgIH0pDQogICAgICAgICAg ICAgICAgICAgICAgICBDcmVhdGVXb3JkRmllbGQgKFJUTEUsIDB4MDEsIElSUTApDQogICAgICAg ICAgICAgICAgICAgICAgICBTdG9yZSAoWmVybywgSVJRMCkNCiAgICAgICAgICAgICAgICAgICAg ICAgIFNoaWZ0TGVmdCAoMHgwMSwgQW5kIChQSVJFLCAweDBGKSwgSVJRMCkNCiAgICAgICAgICAg ICAgICAgICAgICAgIFJldHVybiAoUlRMRSkNCiAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAg ICAgICAgICAgICAgICAgIE1ldGhvZCAoX1NSUywgMSwgU2VyaWFsaXplZCkNCiAgICAgICAgICAg ICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgQ3JlYXRlV29yZEZpZWxkIChBcmcw LCAweDAxLCBJUlEwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgRmluZFNldFJpZ2h0Qml0IChJ UlEwLCBMb2NhbDApDQogICAgICAgICAgICAgICAgICAgICAgICBEZWNyZW1lbnQgKExvY2FsMCkN CiAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlIChMb2NhbDAsIFBJUkUpDQogICAgICAgICAg ICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICBNZXRob2QgKF9TVEEsIDAsIFNlcmlh bGl6ZWQpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIElm IChBbmQgKFBJUkUsIDB4ODApKQ0KICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFJldHVybiAoMHgwOSkNCiAgICAgICAgICAgICAgICAgICAgICAg IH0NCiAgICAgICAgICAgICAgICAgICAgICAgIEVsc2UNCiAgICAgICAgICAgICAgICAgICAgICAg IHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZXR1cm4gKDB4MEIpDQogICAgICAgICAg ICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICB9 DQoNCiAgICAgICAgICAgICAgICBEZXZpY2UgKExOS0YpDQogICAgICAgICAgICAgICAgew0KICAg ICAgICAgICAgICAgICAgICBOYW1lIChfSElELCBFaXNhSWQgKCJQTlAwQzBGIikpDQogICAgICAg ICAgICAgICAgICAgIE5hbWUgKF9VSUQsIDB4MDYpDQogICAgICAgICAgICAgICAgICAgIE1ldGhv ZCAoX0RJUywgMCwgU2VyaWFsaXplZCkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAg ICAgICAgICAgICAgICAgU3RvcmUgKDB4ODAsIFBJUkYpDQogICAgICAgICAgICAgICAgICAgIH0N Cg0KICAgICAgICAgICAgICAgICAgICBOYW1lIChfUFJTLCBSZXNvdXJjZVRlbXBsYXRlICgpDQog ICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIElSUSAoTGV2ZWws IEFjdGl2ZUxvdywgU2hhcmVkKSB7OX0NCiAgICAgICAgICAgICAgICAgICAgfSkNCiAgICAgICAg ICAgICAgICAgICAgTWV0aG9kIChfQ1JTLCAwLCBTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAg ICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBOYW1lIChSVExGLCBSZXNvdXJjZVRlbXBs YXRlICgpDQogICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgSVJRIChMZXZlbCwgQWN0aXZlTG93LCBTaGFyZWQpIHt9DQogICAgICAgICAgICAgICAg ICAgICAgICB9KQ0KICAgICAgICAgICAgICAgICAgICAgICAgQ3JlYXRlV29yZEZpZWxkIChSVExG LCAweDAxLCBJUlEwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKFplcm8sIElSUTAp DQogICAgICAgICAgICAgICAgICAgICAgICBTaGlmdExlZnQgKDB4MDEsIEFuZCAoUElSRiwgMHgw RiksIElSUTApDQogICAgICAgICAgICAgICAgICAgICAgICBSZXR1cm4gKFJUTEYpDQogICAgICAg ICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICBNZXRob2QgKF9TUlMsIDEsIFNl cmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAg IENyZWF0ZVdvcmRGaWVsZCAoQXJnMCwgMHgwMSwgSVJRMCkNCiAgICAgICAgICAgICAgICAgICAg ICAgIEZpbmRTZXRSaWdodEJpdCAoSVJRMCwgTG9jYWwwKQ0KICAgICAgICAgICAgICAgICAgICAg ICAgRGVjcmVtZW50IChMb2NhbDApDQogICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoTG9j YWwwLCBQSVJGKQ0KICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAg TWV0aG9kIChfU1RBLCAwLCBTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAg ICAgICAgICAgICAgICAgICAgICBJZiAoQW5kIChQSVJGLCAweDgwKSkNCiAgICAgICAgICAgICAg ICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZXR1cm4gKDB4MDkpDQog ICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgICAgICAgICBFbHNlDQog ICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgUmV0 dXJuICgweDBCKQ0KICAgICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAg ICB9DQogICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgRGV2aWNlIChMTktHKQ0K ICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgTmFtZSAoX0hJRCwgRWlzYUlk ICgiUE5QMEMwRiIpKQ0KICAgICAgICAgICAgICAgICAgICBOYW1lIChfVUlELCAweDA3KQ0KICAg ICAgICAgICAgICAgICAgICBNZXRob2QgKF9ESVMsIDAsIFNlcmlhbGl6ZWQpDQogICAgICAgICAg ICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlICgweDgwLCBQSVJHKQ0K ICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgTmFtZSAoX1BSUywg UmVzb3VyY2VUZW1wbGF0ZSAoKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAg ICAgICAgICAgICBJUlEgKExldmVsLCBBY3RpdmVMb3csIFNoYXJlZCkgezl9DQogICAgICAgICAg ICAgICAgICAgIH0pDQogICAgICAgICAgICAgICAgICAgIE1ldGhvZCAoX0NSUywgMCwgU2VyaWFs aXplZCkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgTmFt ZSAoUlRMRywgUmVzb3VyY2VUZW1wbGF0ZSAoKQ0KICAgICAgICAgICAgICAgICAgICAgICAgew0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgIElSUSAoTGV2ZWwsIEFjdGl2ZUxvdywgU2hhcmVk KSB7fQ0KICAgICAgICAgICAgICAgICAgICAgICAgfSkNCiAgICAgICAgICAgICAgICAgICAgICAg IENyZWF0ZVdvcmRGaWVsZCAoUlRMRywgMHgwMSwgSVJRMCkNCiAgICAgICAgICAgICAgICAgICAg ICAgIFN0b3JlIChaZXJvLCBJUlEwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgU2hpZnRMZWZ0 ICgweDAxLCBBbmQgKFBJUkcsIDB4MEYpLCBJUlEwKQ0KICAgICAgICAgICAgICAgICAgICAgICAg UmV0dXJuIChSVExHKQ0KICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAg ICAgTWV0aG9kIChfU1JTLCAxLCBTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAgICAgICB7DQog ICAgICAgICAgICAgICAgICAgICAgICBDcmVhdGVXb3JkRmllbGQgKEFyZzAsIDB4MDEsIElSUTAp DQogICAgICAgICAgICAgICAgICAgICAgICBGaW5kU2V0UmlnaHRCaXQgKElSUTAsIExvY2FsMCkN CiAgICAgICAgICAgICAgICAgICAgICAgIERlY3JlbWVudCAoTG9jYWwwKQ0KICAgICAgICAgICAg ICAgICAgICAgICAgU3RvcmUgKExvY2FsMCwgUElSRykNCiAgICAgICAgICAgICAgICAgICAgfQ0K DQogICAgICAgICAgICAgICAgICAgIE1ldGhvZCAoX1NUQSwgMCwgU2VyaWFsaXplZCkNCiAgICAg ICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgSWYgKEFuZCAoUElSRywg MHg4MCkpDQogICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgUmV0dXJuICgweDA5KQ0KICAgICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAg ICAgICAgICAgICAgICAgRWxzZQ0KICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFJldHVybiAoMHgwQikNCiAgICAgICAgICAgICAgICAgICAgICAg IH0NCiAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAg ICAgICAgIERldmljZSAoTE5LSCkNCiAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAg ICAgIE5hbWUgKF9ISUQsIEVpc2FJZCAoIlBOUDBDMEYiKSkNCiAgICAgICAgICAgICAgICAgICAg TmFtZSAoX1VJRCwgMHgwOCkNCiAgICAgICAgICAgICAgICAgICAgTWV0aG9kIChfRElTLCAwLCBT ZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAg ICBTdG9yZSAoMHg4MCwgUElSSCkNCiAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAg ICAgICAgICAgIE5hbWUgKF9QUlMsIFJlc291cmNlVGVtcGxhdGUgKCkNCiAgICAgICAgICAgICAg ICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgSVJRIChMZXZlbCwgQWN0aXZlTG93LCBT aGFyZWQpIHs5fQ0KICAgICAgICAgICAgICAgICAgICB9KQ0KICAgICAgICAgICAgICAgICAgICBN ZXRob2QgKF9DUlMsIDAsIFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAg ICAgICAgICAgICAgICAgICAgIE5hbWUgKFJUTEgsIFJlc291cmNlVGVtcGxhdGUgKCkNCiAgICAg ICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJUlEgKExl dmVsLCBBY3RpdmVMb3csIFNoYXJlZCkge30NCiAgICAgICAgICAgICAgICAgICAgICAgIH0pDQog ICAgICAgICAgICAgICAgICAgICAgICBDcmVhdGVXb3JkRmllbGQgKFJUTEgsIDB4MDEsIElSUTAp DQogICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoWmVybywgSVJRMCkNCiAgICAgICAgICAg ICAgICAgICAgICAgIFNoaWZ0TGVmdCAoMHgwMSwgQW5kIChQSVJILCAweDBGKSwgSVJRMCkNCiAg ICAgICAgICAgICAgICAgICAgICAgIFJldHVybiAoUlRMSCkNCiAgICAgICAgICAgICAgICAgICAg fQ0KDQogICAgICAgICAgICAgICAgICAgIE1ldGhvZCAoX1NSUywgMSwgU2VyaWFsaXplZCkNCiAg ICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgQ3JlYXRlV29yZEZp ZWxkIChBcmcwLCAweDAxLCBJUlEwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgRmluZFNldFJp Z2h0Qml0IChJUlEwLCBMb2NhbDApDQogICAgICAgICAgICAgICAgICAgICAgICBEZWNyZW1lbnQg KExvY2FsMCkNCiAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlIChMb2NhbDAsIFBJUkgpDQog ICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICBNZXRob2QgKF9TVEEs IDAsIFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAg ICAgICAgIElmIChBbmQgKFBJUkgsIDB4ODApKQ0KICAgICAgICAgICAgICAgICAgICAgICAgew0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJldHVybiAoMHgwOSkNCiAgICAgICAgICAgICAg ICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAgICAgIEVsc2UNCiAgICAgICAgICAgICAg ICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZXR1cm4gKDB4MEIpDQog ICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAg ICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBEZXZpY2UgKFRJTVIpDQogICAgICAgICAgICAg ICAgew0KICAgICAgICAgICAgICAgICAgICBOYW1lIChfSElELCBFaXNhSWQgKCJQTlAwMTAwIikp DQogICAgICAgICAgICAgICAgICAgIE5hbWUgKEJVRjAsIFJlc291cmNlVGVtcGxhdGUgKCkNCiAg ICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgSU8gKERlY29kZTE2 LCAweDAwNDAsIDB4MDA0MCwgMHgwMSwgMHgwNCkNCiAgICAgICAgICAgICAgICAgICAgICAgIElP IChEZWNvZGUxNiwgMHgwMDUwLCAweDAwNTAsIDB4MTAsIDB4MDQpDQogICAgICAgICAgICAgICAg ICAgIH0pDQogICAgICAgICAgICAgICAgICAgIE5hbWUgKEJVRjEsIFJlc291cmNlVGVtcGxhdGUg KCkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgSU8gKERl Y29kZTE2LCAweDAwNDAsIDB4MDA0MCwgMHgwMSwgMHgwNCkNCiAgICAgICAgICAgICAgICAgICAg ICAgIElPIChEZWNvZGUxNiwgMHgwMDUwLCAweDAwNTAsIDB4MTAsIDB4MDQpDQogICAgICAgICAg ICAgICAgICAgICAgICBJUlFOb0ZsYWdzICgpIHswfQ0KICAgICAgICAgICAgICAgICAgICB9KQ0K ICAgICAgICAgICAgICAgICAgICBNZXRob2QgKF9DUlMsIDAsIFNlcmlhbGl6ZWQpDQogICAgICAg ICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIElmIChBbmQgKEhQVEUsIDB4 MDAwMjAwMDApKQ0KICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFJldHVybiAoQlVGMCkNCiAgICAgICAgICAgICAgICAgICAgICAgIH0NCg0KICAg ICAgICAgICAgICAgICAgICAgICAgUmV0dXJuIChCVUYxKQ0KICAgICAgICAgICAgICAgICAgICB9 DQogICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgRGV2aWNlIChJUElDKQ0KICAg ICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgTmFtZSAoX0hJRCwgRWlzYUlkICgi UE5QMDAwMCIpKQ0KICAgICAgICAgICAgICAgICAgICBOYW1lIChfQ1JTLCBSZXNvdXJjZVRlbXBs YXRlICgpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIElP IChEZWNvZGUxNiwgMHgwMDIwLCAweDAwMjAsIDB4MDEsIDB4MDIpDQogICAgICAgICAgICAgICAg ICAgICAgICBJTyAoRGVjb2RlMTYsIDB4MDAyNCwgMHgwMDI0LCAweDAxLCAweDAyKQ0KICAgICAg ICAgICAgICAgICAgICAgICAgSU8gKERlY29kZTE2LCAweDAwMjgsIDB4MDAyOCwgMHgwMSwgMHgw MikNCiAgICAgICAgICAgICAgICAgICAgICAgIElPIChEZWNvZGUxNiwgMHgwMDJDLCAweDAwMkMs IDB4MDEsIDB4MDIpDQogICAgICAgICAgICAgICAgICAgICAgICBJTyAoRGVjb2RlMTYsIDB4MDAz MCwgMHgwMDMwLCAweDAxLCAweDAyKQ0KICAgICAgICAgICAgICAgICAgICAgICAgSU8gKERlY29k ZTE2LCAweDAwMzQsIDB4MDAzNCwgMHgwMSwgMHgwMikNCiAgICAgICAgICAgICAgICAgICAgICAg IElPIChEZWNvZGUxNiwgMHgwMDM4LCAweDAwMzgsIDB4MDEsIDB4MDIpDQogICAgICAgICAgICAg ICAgICAgICAgICBJTyAoRGVjb2RlMTYsIDB4MDAzQywgMHgwMDNDLCAweDAxLCAweDAyKQ0KICAg ICAgICAgICAgICAgICAgICAgICAgSU8gKERlY29kZTE2LCAweDAwQTAsIDB4MDBBMCwgMHgwMSwg MHgwMikNCiAgICAgICAgICAgICAgICAgICAgICAgIElPIChEZWNvZGUxNiwgMHgwMEE0LCAweDAw QTQsIDB4MDEsIDB4MDIpDQogICAgICAgICAgICAgICAgICAgICAgICBJTyAoRGVjb2RlMTYsIDB4 MDBBOCwgMHgwMEE4LCAweDAxLCAweDAyKQ0KICAgICAgICAgICAgICAgICAgICAgICAgSU8gKERl Y29kZTE2LCAweDAwQUMsIDB4MDBBQywgMHgwMSwgMHgwMikNCiAgICAgICAgICAgICAgICAgICAg ICAgIElPIChEZWNvZGUxNiwgMHgwMEIwLCAweDAwQjAsIDB4MDEsIDB4MDIpDQogICAgICAgICAg ICAgICAgICAgICAgICBJTyAoRGVjb2RlMTYsIDB4MDBCNCwgMHgwMEI0LCAweDAxLCAweDAyKQ0K ICAgICAgICAgICAgICAgICAgICAgICAgSU8gKERlY29kZTE2LCAweDAwQjgsIDB4MDBCOCwgMHgw MSwgMHgwMikNCiAgICAgICAgICAgICAgICAgICAgICAgIElPIChEZWNvZGUxNiwgMHgwMEJDLCAw eDAwQkMsIDB4MDEsIDB4MDIpDQogICAgICAgICAgICAgICAgICAgICAgICBJTyAoRGVjb2RlMTYs IDB4MDREMCwgMHgwNEQwLCAweDAxLCAweDAyKQ0KICAgICAgICAgICAgICAgICAgICAgICAgSVJR Tm9GbGFncyAoKSB7Mn0NCiAgICAgICAgICAgICAgICAgICAgfSkNCiAgICAgICAgICAgICAgICB9 DQoNCiAgICAgICAgICAgICAgICBEZXZpY2UgKFJUQykNCiAgICAgICAgICAgICAgICB7DQogICAg ICAgICAgICAgICAgICAgIE5hbWUgKF9ISUQsIEVpc2FJZCAoIlBOUDBCMDAiKSkNCiAgICAgICAg ICAgICAgICAgICAgTmFtZSAoQlVGMCwgUmVzb3VyY2VUZW1wbGF0ZSAoKQ0KICAgICAgICAgICAg ICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBJTyAoRGVjb2RlMTYsIDB4MDA3MCwg MHgwMDcwLCAweDAxLCAweDA4KQ0KICAgICAgICAgICAgICAgICAgICB9KQ0KICAgICAgICAgICAg ICAgICAgICBOYW1lIChCVUYxLCBSZXNvdXJjZVRlbXBsYXRlICgpDQogICAgICAgICAgICAgICAg ICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIElPIChEZWNvZGUxNiwgMHgwMDcwLCAweDAw NzAsIDB4MDEsIDB4MDgpDQogICAgICAgICAgICAgICAgICAgICAgICBJUlFOb0ZsYWdzICgpIHs4 fQ0KICAgICAgICAgICAgICAgICAgICB9KQ0KICAgICAgICAgICAgICAgICAgICBNZXRob2QgKF9D UlMsIDAsIFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAg ICAgICAgICAgIElmIChBbmQgKEhQVEUsIDB4MDAwMjAwMDApKQ0KICAgICAgICAgICAgICAgICAg ICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJldHVybiAoQlVGMCkNCiAgICAg ICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICAgICAgUmV0dXJuIChC VUYxKQ0KICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgfQ0KDQogICAgICAg ICAgICAgICAgRGV2aWNlIChNQVRIKQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAg ICAgICAgTmFtZSAoX0hJRCwgRWlzYUlkICgiUE5QMEMwNCIpKQ0KICAgICAgICAgICAgICAgICAg ICBOYW1lIChfQ1JTLCBSZXNvdXJjZVRlbXBsYXRlICgpDQogICAgICAgICAgICAgICAgICAgIHsN CiAgICAgICAgICAgICAgICAgICAgICAgIElPIChEZWNvZGUxNiwgMHgwMEYwLCAweDAwRjAsIDB4 MDEsIDB4MDEpDQogICAgICAgICAgICAgICAgICAgICAgICBJUlFOb0ZsYWdzICgpIHsxM30NCiAg ICAgICAgICAgICAgICAgICAgfSkNCiAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAg ICBEZXZpY2UgKERNQUMpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBO YW1lIChfSElELCBFaXNhSWQgKCJQTlAwMjAwIikpDQogICAgICAgICAgICAgICAgICAgIE5hbWUg KF9DUlMsIFJlc291cmNlVGVtcGxhdGUgKCkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAg ICAgICAgICAgICAgICAgICAgSU8gKERlY29kZTE2LCAweDAwMDAsIDB4MDAwMCwgMHgwMSwgMHgy MCkNCiAgICAgICAgICAgICAgICAgICAgICAgIElPIChEZWNvZGUxNiwgMHgwMDgxLCAweDAwODEs IDB4MDEsIDB4MEYpDQogICAgICAgICAgICAgICAgICAgICAgICBJTyAoRGVjb2RlMTYsIDB4MDA5 MCwgMHgwMDkwLCAweDAxLCAweDAyKQ0KICAgICAgICAgICAgICAgICAgICAgICAgSU8gKERlY29k ZTE2LCAweDAwOTMsIDB4MDA5MywgMHgwMSwgMHgwRCkNCiAgICAgICAgICAgICAgICAgICAgICAg IElPIChEZWNvZGUxNiwgMHgwMEMwLCAweDAwQzAsIDB4MDEsIDB4MjApDQogICAgICAgICAgICAg ICAgICAgICAgICBETUEgKENvbXBhdGliaWxpdHksIE5vdEJ1c01hc3RlciwgVHJhbnNmZXI4XzE2 KSB7NH0NCiAgICAgICAgICAgICAgICAgICAgfSkNCiAgICAgICAgICAgICAgICB9DQoNCiAgICAg ICAgICAgICAgICBEZXZpY2UgKE1CUkQpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAg ICAgICAgICBOYW1lIChfSElELCBFaXNhSWQgKCJQTlAwQzAyIikpDQogICAgICAgICAgICAgICAg ICAgIE5hbWUgKF9DUlMsIFJlc291cmNlVGVtcGxhdGUgKCkNCiAgICAgICAgICAgICAgICAgICAg ew0KICAgICAgICAgICAgICAgICAgICAgICAgSU8gKERlY29kZTE2LCAweDAwMkUsIDB4MDAyRSwg MHgwMSwgMHgwMikNCiAgICAgICAgICAgICAgICAgICAgICAgIElPIChEZWNvZGUxNiwgMHgwMDYx LCAweDAwNjEsIDB4MDEsIDB4MDEpDQogICAgICAgICAgICAgICAgICAgICAgICBJTyAoRGVjb2Rl MTYsIDB4MDA2MywgMHgwMDYzLCAweDAxLCAweDAxKQ0KICAgICAgICAgICAgICAgICAgICAgICAg SU8gKERlY29kZTE2LCAweDAwNjUsIDB4MDA2NSwgMHgwMSwgMHgwMSkNCiAgICAgICAgICAgICAg ICAgICAgICAgIElPIChEZWNvZGUxNiwgMHgwMDY3LCAweDAwNjcsIDB4MDEsIDB4MDEpDQogICAg ICAgICAgICAgICAgICAgICAgICBJTyAoRGVjb2RlMTYsIDB4MDA4MCwgMHgwMDgwLCAweDAxLCAw eDAxKQ0KICAgICAgICAgICAgICAgICAgICAgICAgSU8gKERlY29kZTE2LCAweDAwOTIsIDB4MDA5 MiwgMHgwMSwgMHgwMSkNCiAgICAgICAgICAgICAgICAgICAgICAgIElPIChEZWNvZGUxNiwgMHgw MEIyLCAweDAwQjIsIDB4MDEsIDB4MDIpDQogICAgICAgICAgICAgICAgICAgICAgICBJTyAoRGVj b2RlMTYsIDB4MDYwMCwgMHgwNjAwLCAweDAxLCAweDEwKQ0KICAgICAgICAgICAgICAgICAgICAg ICAgSU8gKERlY29kZTE2LCAweDA3MDAsIDB4MDcwMCwgMHgwMSwgMHgxMCkNCiAgICAgICAgICAg ICAgICAgICAgICAgIElPIChEZWNvZGUxNiwgMHgxMDAwLCAweDEwMDAsIDB4MDEsIDB4ODApDQog ICAgICAgICAgICAgICAgICAgICAgICBJTyAoRGVjb2RlMTYsIDB4MTE4MCwgMHgxMTgwLCAweDAx LCAweDQwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgSU8gKERlY29kZTE2LCAweEZFMDAsIDB4 RkUwMCwgMHgwMSwgMHgwMikNCiAgICAgICAgICAgICAgICAgICAgICAgIElPIChEZWNvZGUxNiwg MHhGRTEwLCAweEZFMTAsIDB4MDEsIDB4MDgpDQogICAgICAgICAgICAgICAgICAgICAgICBNZW1v cnkzMkZpeGVkIChSZWFkV3JpdGUsIDB4RkVCRkUwMDAsIDB4MDAwMDEwMDApDQogICAgICAgICAg ICAgICAgICAgICAgICBNZW1vcnkzMkZpeGVkIChSZWFkV3JpdGUsIDB4RkVCRkYwMDAsIDB4MDAw MDEwMDApDQogICAgICAgICAgICAgICAgICAgICAgICBNZW1vcnkzMkZpeGVkIChSZWFkV3JpdGUs IDB4RkVDMDAwMDAsIDB4MDAwMDEwMDApDQogICAgICAgICAgICAgICAgICAgIH0pDQogICAgICAg ICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgRGV2aWNlIChGV0hEKQ0KICAgICAgICAgICAg ICAgIHsNCiAgICAgICAgICAgICAgICAgICAgTmFtZSAoX0hJRCwgRWlzYUlkICgiSU5UMDgwMCIp KQ0KICAgICAgICAgICAgICAgICAgICBOYW1lIChfQ1JTLCBSZXNvdXJjZVRlbXBsYXRlICgpDQog ICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIE1lbW9yeTMyRml4 ZWQgKFJlYWRPbmx5LCAweEZGODAwMDAwLCAweDAwODAwMDAwKQ0KICAgICAgICAgICAgICAgICAg ICB9KQ0KICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgIERldmljZSAoRUMwKQ0K ICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgTmFtZSAoX0hJRCwgRWlzYUlk ICgiUE5QMEMwOSIpKQ0KICAgICAgICAgICAgICAgICAgICBOYW1lIChfQ1JTLCBSZXNvdXJjZVRl bXBsYXRlICgpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAg IElPIChEZWNvZGUxNiwgMHgwMDYyLCAweDAwNjIsIDB4MDEsIDB4MDEpDQogICAgICAgICAgICAg ICAgICAgICAgICBJTyAoRGVjb2RlMTYsIDB4MDA2NiwgMHgwMDY2LCAweDAxLCAweDAxKQ0KICAg ICAgICAgICAgICAgICAgICB9KQ0KICAgICAgICAgICAgICAgICAgICBOYW1lIChfR1BFLCAweDFD KQ0KICAgICAgICAgICAgICAgICAgICBOYW1lIChFQ09LLCAweDAwKQ0KICAgICAgICAgICAgICAg ICAgICBNZXRob2QgKF9SRUcsIDIsIE5vdFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgICAg IHsNCiAgICAgICAgICAgICAgICAgICAgICAgIElmIChMRXF1YWwgKEFyZzAsIDB4MDMpKQ0KICAg ICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0b3Jl IChBcmcxLCBFQ09LKQ0KICAgICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAg ICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgTmFtZSAoX1BSVywgUGFja2FnZSAoMHgwMikN CiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgMHgxRCwgDQog ICAgICAgICAgICAgICAgICAgICAgICAweDA1DQogICAgICAgICAgICAgICAgICAgIH0pDQogICAg ICAgICAgICAgICAgICAgIE9wZXJhdGlvblJlZ2lvbiAoRUNSLCBFbWJlZGRlZENvbnRyb2wsIDB4 MDAsIDB4RkYpDQogICAgICAgICAgICAgICAgICAgIEZpZWxkIChFQ1IsIEJ5dGVBY2MsIExvY2ss IFByZXNlcnZlKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAg ICBPZmZzZXQgKDB4ODApLCANCiAgICAgICAgICAgICAgICAgICAgICAgIE1QQlAsICAgMSwgDQog ICAgICAgICAgICAgICAgICAgICAgICBNUEJELCAgIDEsIA0KICAgICAgICAgICAgICAgICAgICAg ICAgRE9LRCwgICAxLCANCiAgICAgICAgICAgICAgICAgICAgICAgIERGQlAsICAgMSwgDQogICAg ICAgICAgICAgICAgICAgICAgICBPZmZzZXQgKDB4ODEpLCANCiAgICAgICAgICAgICAgICAgICAg ICAgIEJUMUEsICAgMSwgDQogICAgICAgICAgICAgICAgICAgICAgICBCVDJBLCAgIDEsIA0KICAg ICAgICAgICAgICAgICAgICAgICAgQUNBVCwgICAxLCANCiAgICAgICAgICAgICAgICAgICAgICAg IE9mZnNldCAoMHg4MiksIA0KICAgICAgICAgICAgICAgICAgICAgICAgUFdSQiwgICAxLCANCiAg ICAgICAgICAgICAgICAgICAgICAgIEpPR0IsICAgMSwgDQogICAgICAgICAgICAgICAgICAgICAg ICBMSURTLCAgIDEsIA0KICAgICAgICAgICAgICAgICAgICAgICAgT2Zmc2V0ICgweDgzKSwgDQog ICAgICAgICAgICAgICAgICAgICAgICBCVDFQLCAgIDEsIA0KICAgICAgICAgICAgICAgICAgICAg ICAgQlQyUCwgICAxLCANCiAgICAgICAgICAgICAgICAgICAgICAgIE9mZnNldCAoMHg4NCksIA0K ICAgICAgICAgICAgICAgICAgICAgICAgQjFTVCwgICA4LCANCiAgICAgICAgICAgICAgICAgICAg ICAgIEIyU1QsICAgOCwgDQogICAgICAgICAgICAgICAgICAgICAgICBPZmZzZXQgKDB4OTApLCAN CiAgICAgICAgICAgICAgICAgICAgICAgIE1BU0ssICAgOCwgDQogICAgICAgICAgICAgICAgICAg ICAgICBCVDFTLCAgIDEsIA0KICAgICAgICAgICAgICAgICAgICAgICAgQlQyUywgICAxLCANCiAg ICAgICAgICAgICAgICAgICAgICAgIE9mZnNldCAoMHg5MiksIA0KICAgICAgICAgICAgICAgICAg ICAgICAgQlQxVywgICAxLCANCiAgICAgICAgICAgICAgICAgICAgICAgIEJUMlcsICAgMSwgDQog ICAgICAgICAgICAgICAgICAgICAgICBPZmZzZXQgKDB4OTMpLCANCiAgICAgICAgICAgICAgICAg ICAgICAgIEZBTjAsICAgOCwgDQogICAgICAgICAgICAgICAgICAgICAgICBDQjBTLCAgIDEsIA0K ICAgICAgICAgICAgICAgICAgICAgICAgQ0IxUywgICAxLCANCiAgICAgICAgICAgICAgICAgICAg ICAgIE9mZnNldCAoMHg5NSksIA0KICAgICAgICAgICAgICAgICAgICAgICAgUEhZTywgICAxLCAN CiAgICAgICAgICAgICAgICAgICAgICAgIE9mZnNldCAoMHg5NiksIA0KICAgICAgICAgICAgICAg ICAgICAgICAgQlJJVCwgICA4LCANCiAgICAgICAgICAgICAgICAgICAgICAgIENPTlQsICAgOCwg DQogICAgICAgICAgICAgICAgICAgICAgICBTTkRVLCAgIDEsIA0KICAgICAgICAgICAgICAgICAg ICAgICAgU05ERCwgICAxLCANCiAgICAgICAgICAgICAgICAgICAgICAgIE9mZnNldCAoMHg5OSks IA0KICAgICAgICAgICAgICAgICAgICAgICAgU01ETSwgICAxLCANCiAgICAgICAgICAgICAgICAg ICAgICAgIE9mZnNldCAoMHg5QSksIA0KICAgICAgICAgICAgICAgICAgICAgICAgT2Zmc2V0ICgw eDlCKSwgDQogICAgICAgICAgICAgICAgICAgICAgICBTSVJRLCAgIDgsIA0KICAgICAgICAgICAg ICAgICAgICAgICAgU0xPQiwgICA4LCANCiAgICAgICAgICAgICAgICAgICAgICAgIFNISUIsICAg OCwgDQogICAgICAgICAgICAgICAgICAgICAgICBNUFdSLCAgIDEsIA0KICAgICAgICAgICAgICAg ICAgICAgICAgV0FLSSwgICAxLCANCiAgICAgICAgICAgICAgICAgICAgICAgIE9mZnNldCAoMHg5 RiksIA0KICAgICAgICAgICAgICAgICAgICAgICAgT2Zmc2V0ICgweEEwKSwgDQogICAgICAgICAg ICAgICAgICAgICAgICBCMVJDLCAgIDE2LCANCiAgICAgICAgICAgICAgICAgICAgICAgIEIxQUIs ICAgMTYsIA0KICAgICAgICAgICAgICAgICAgICAgICAgQjFBQywgICAxNiwgDQogICAgICAgICAg ICAgICAgICAgICAgICBCMVZPLCAgIDE2LCANCiAgICAgICAgICAgICAgICAgICAgICAgIEIyUkMs ICAgMTYsIA0KICAgICAgICAgICAgICAgICAgICAgICAgQjJBQiwgICAxNiwgDQogICAgICAgICAg ICAgICAgICAgICAgICBCMkFDLCAgIDE2LCANCiAgICAgICAgICAgICAgICAgICAgICAgIEIyVk8s ICAgMTYsIA0KICAgICAgICAgICAgICAgICAgICAgICAgQjFEQywgICAxNiwgDQogICAgICAgICAg ICAgICAgICAgICAgICBCMUxGLCAgIDE2LCANCiAgICAgICAgICAgICAgICAgICAgICAgIEIxRFYs ICAgMTYsIA0KICAgICAgICAgICAgICAgICAgICAgICAgQjFETCwgICAxNiwgDQogICAgICAgICAg ICAgICAgICAgICAgICBCMkRDLCAgIDE2LCANCiAgICAgICAgICAgICAgICAgICAgICAgIEIyTEYs ICAgMTYsIA0KICAgICAgICAgICAgICAgICAgICAgICAgQjJEViwgICAxNiwgDQogICAgICAgICAg ICAgICAgICAgICAgICBCMkRMLCAgIDE2LCANCiAgICAgICAgICAgICAgICAgICAgICAgIEExVFAs ICAgMTYsIA0KICAgICAgICAgICAgICAgICAgICAgICAgQTFBVCwgICAxNiwgDQogICAgICAgICAg ICAgICAgICAgICAgICBBMVBULCAgIDE2LCANCiAgICAgICAgICAgICAgICAgICAgICAgIEExQ1Qs ICAgMTYsIA0KICAgICAgICAgICAgICAgICAgICAgICAgQTJUUCwgICAxNiwgDQogICAgICAgICAg ICAgICAgICAgICAgICBBMkFULCAgIDE2LCANCiAgICAgICAgICAgICAgICAgICAgICAgIEEyUFQs ICAgMTYsIA0KICAgICAgICAgICAgICAgICAgICAgICAgQTJDVCwgICAxNg0KICAgICAgICAgICAg ICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgTWV0aG9kIChfUTUwLCAwLCBOb3RTZXJp YWxpemVkKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBO b3RpZnkgKEFDQUQsIDB4ODApDQogICAgICAgICAgICAgICAgICAgICAgICBcX1NCLk5DUFUgKCkN CiAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgIE1ldGhvZCAoX1E1 MSwgMCwgTm90U2VyaWFsaXplZCkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAg ICAgICAgICAgICAgSWYgKEJUMUEpDQogICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgTm90aWZ5IChCQVQxLCAweDAwKQ0KICAgICAgICAgICAgICAg ICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgICAgICAgRWxzZQ0KICAgICAgICAgICAgICAg ICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5vdGlmeSAoQkFUMSwgMHgw MSkNCiAgICAgICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICAgICAg Tm90aWZ5IChCQVQxLCAweDgwKQ0KICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAg ICAgICAgICAgTWV0aG9kIChfUTUzLCAwLCBOb3RTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAg ICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoIl9RNTM6QmF0dGVyeSBTZWxl Y3Rpb24iLCBEZWJ1ZykNCiAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAg ICAgIE1ldGhvZCAoX1E1OCwgMCwgTm90U2VyaWFsaXplZCkNCiAgICAgICAgICAgICAgICAgICAg ew0KICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKCJfUTU4OkFURiB0ZW1wZXJhdHVyZSB0 cmlwIHBvaW50IGNoYW5nZCIsIERlYnVnKQ0KICAgICAgICAgICAgICAgICAgICAgICAgTm90aWZ5 IChcX1RaLkFURjAsIDB4ODEpDQogICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAg ICAgICAgICBNZXRob2QgKF9RNUYsIDAsIE5vdFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAg ICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlICgiX1E1RjpBVEYgdGVtcGVyYXR1 cmUgcmVhY2hlcyB0cmlwIHBvaW50IiwgRGVidWcpDQogICAgICAgICAgICAgICAgICAgICAgICBO b3RpZnkgKFxfVFouQVRGMCwgMHg4MCkNCiAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAg ICAgICAgICAgICAgIE1ldGhvZCAoX1E2MCwgMCwgTm90U2VyaWFsaXplZCkNCiAgICAgICAgICAg ICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgTm90aWZ5IChcX1NCLlBXUkIsIDB4 ODApDQogICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICBNZXRob2Qg KF9RNjYsIDAsIE5vdFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAg ICAgICAgICAgICAgICAgIE5vdGlmeSAoXF9TQi5MSUQwLCAweDgwKQ0KICAgICAgICAgICAgICAg ICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgRGV2aWNlIChCQVQxKQ0KICAgICAgICAgICAg ICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBOYW1lIChfSElELCBFaXNhSWQgKCJQ TlAwQzBBIikpDQogICAgICAgICAgICAgICAgICAgICAgICBOYW1lIChfVUlELCAweDAxKQ0KICAg ICAgICAgICAgICAgICAgICAgICAgTmFtZSAoX1BDTCwgUGFja2FnZSAoMHgwMSkNCiAgICAgICAg ICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBcX1NCDQogICAg ICAgICAgICAgICAgICAgICAgICB9KQ0KICAgICAgICAgICAgICAgICAgICAgICAgTmFtZSAoQkFU SSwgUGFja2FnZSAoMHgwRCkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAweDAwLCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAweDk2 NTAsIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDB4OTY1MCwgDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgMHgwMCwgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgMHgzOUQw LCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAweDAwLCANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAweDc4LCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAweDAwLCANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAweDBBLCANCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAiIiwgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIiIsIA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICJMSU9OIiwgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIlNv bnkgQ29ycC4iDQogICAgICAgICAgICAgICAgICAgICAgICB9KQ0KICAgICAgICAgICAgICAgICAg ICAgICAgTmFtZSAoQkFUUywgUGFja2FnZSAoMHgwNCkNCiAgICAgICAgICAgICAgICAgICAgICAg IHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAweDAyLCANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAweEZGRkZGRkZGLCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAweDBE N0EsIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDB4Mzg0MA0KICAgICAgICAgICAgICAg ICAgICAgICAgfSkNCiAgICAgICAgICAgICAgICAgICAgICAgIE1ldGhvZCAoX1NUQSwgMCwgTm90 U2VyaWFsaXplZCkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICBJZiAoTEVxdWFsIChcX1NCLlBDSTAuTFBDQi5FQzAuRUNPSywgMHgwMCkpDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBBbmQgKFBIU0QgKDB4RDQsIDB4ODApLCAweDAxMDAsIExvY2FsMSkNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgRWxzZQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgU3RvcmUgKEJUMUEsIExvY2FsMSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB9DQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJZiAoTG9jYWwxKQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKDB4 MUYsIExvY2FsMCkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgRWxzZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKDB4MEYsIExvY2FsMCkNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZXR1 cm4gKExvY2FsMCkNCiAgICAgICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAg ICAgICAgICAgTWV0aG9kIChfQklGLCAwLCBOb3RTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAg ICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIElmIChMRXF1YWwgKFxfU0Iu UENJMC5MUENCLkVDMC5FQ09LLCAweDAwKSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB7 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlIChQSFNEICgweEQ0LCAweEIw KSwgTG9jYWwwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoUEhTRCAo MHhENCwgMHhCMiksIExvY2FsMSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3Rv cmUgKFBIU0QgKDB4RDQsIDB4QjYpLCBMb2NhbDIpDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgfQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVsc2UNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlIChCMURD LCBMb2NhbDApDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlIChCMUxGLCBM b2NhbDEpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlIChCMURWLCBMb2Nh bDIpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgTXVsdGlwbHkgKExvY2FsMCwgMHgwQSwgSW5kZXggKEJBVEksIDB4MDEpKQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIE11bHRpcGx5IChMb2NhbDEsIDB4MEEsIEluZGV4IChC QVRJLCAweDAyKSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoTG9jYWwyLCBJ bmRleCAoQkFUSSwgMHgwNCkpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgUmV0dXJuIChC QVRJKQ0KICAgICAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgICAg ICBNZXRob2QgKF9CU1QsIDAsIE5vdFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgICAgICAg ICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgSWYgKExFcXVhbCAoXF9TQi5QQ0kwLkxQ Q0IuRUMwLkVDT0ssIDB4MDApKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKEFuZCAoUEhTRCAoMHhENCwgMHg4NCks IDB4RkYsIExvY2FsMCksIEluZGV4IChCQVRTLCAweDAwKSkNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgU3RvcmUgKFBIU0QgKDB4RDQsIDB4QTYpLCBMb2NhbDApDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIFN0b3JlIChQSFNEICgweEQ0LCAweEE0KSwgTG9jYWwxKQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoUEhTRCAoMHhENCwgMHhBMiks IExvY2FsMikNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgRWxzZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKEIxU1QsIEluZGV4IChCQVRTLCAweDAwKSkN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKEIxVk8sIExvY2FsMCkNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKEIxQUMsIExvY2FsMSkNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKEIxQUIsIExvY2FsMikNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJZiAo TEVxdWFsIChMb2NhbDEsIDB4RkZGRikpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgew0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoMHhGRkZGRkZGRiwgTG9jYWwx KQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICBFbHNlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBJZiAoTE5vdCAoTExlc3MgKExvY2FsMSwgMHg4MDAwKSkpDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFhPciAoTG9jYWwxLCAweEZGRkYsIExvY2FsMSkNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEluY3JlbWVudCAoTG9jYWwxKQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTXVsdGlw bHkgKExvY2FsMCwgTG9jYWwxLCBMb2NhbDEpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIERpdmlkZSAoTG9jYWwxLCAweDAzRTgsICwgTG9jYWwxKQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlIChMb2NhbDEs IEluZGV4IChCQVRTLCAweDAxKSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBNdWx0aXBs eSAoTG9jYWwyLCAweDBBLCBJbmRleCAoQkFUUywgMHgwMikpDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgU3RvcmUgKExvY2FsMCwgSW5kZXggKEJBVFMsIDB4MDMpKQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFJldHVybiAoQkFUUykNCiAgICAgICAgICAgICAgICAgICAgICAgIH0N CiAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgIFNjb3BlIChcKQ0K ICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBOYW1lIChQV1JT LCBPbmVzKQ0KICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgRGV2 aWNlIChBQ0FEKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAg ICBOYW1lIChfSElELCAiQUNQSTAwMDMiKQ0KICAgICAgICAgICAgICAgICAgICAgICAgTmFtZSAo X1BDTCwgUGFja2FnZSAoMHgwMSkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICBcX1NCDQogICAgICAgICAgICAgICAgICAgICAgICB9KQ0KICAg ICAgICAgICAgICAgICAgICAgICAgTWV0aG9kIChfUFNSLCAwLCBOb3RTZXJpYWxpemVkKQ0KICAg ICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIElmIChM RXF1YWwgKFxfU0IuUENJMC5MUENCLkVDMC5FQ09LLCAweDAwKSkNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFuZCAoUEhTRCAo MHhENCwgMHg4MCksIDB4MDQwMCwgTG9jYWwxKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg IH0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBFbHNlDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoQUNBVCwg TG9jYWwxKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFN0b3JlIChMb2NhbDEsIFBXUlMpDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgSWYgKExvY2FsMSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFJldHVybiAoT25lKQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBFbHNlDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZXR1 cm4gKFplcm8pDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAg ICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgICAgICBNZXRob2QgKF9TVEEsIDAsIE5v dFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgUmV0dXJuICgweDBGKQ0KICAgICAgICAgICAgICAgICAgICAgICAgfQ0KICAg ICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAg RGV2aWNlIChTUElDKQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgTmFt ZSAoX0hJRCwgRWlzYUlkICgiU05ZNjAwMSIpKQ0KICAgICAgICAgICAgICAgICAgICBOYW1lIChS U1JDLCBSZXNvdXJjZVRlbXBsYXRlICgpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAg ICAgICAgICAgICAgICAgIElPIChEZWNvZGUxNiwgMHgwMDAwLCAweDAwMDAsIDB4MDEsIDB4MjAp DQogICAgICAgICAgICAgICAgICAgICAgICBJUlFOb0ZsYWdzICgpIHt9DQogICAgICAgICAgICAg ICAgICAgIH0pDQogICAgICAgICAgICAgICAgICAgIE5hbWUgKFNTUkMsIFJlc291cmNlVGVtcGxh dGUgKCkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgSU8g KERlY29kZTE2LCAweDAwMDAsIDB4MDAwMCwgMHgwMSwgMHgyMCkNCiAgICAgICAgICAgICAgICAg ICAgICAgIElSUU5vRmxhZ3MgKCkge30NCiAgICAgICAgICAgICAgICAgICAgfSkNCiAgICAgICAg ICAgICAgICAgICAgTmFtZSAoU0lSVCwgUGFja2FnZSAoMHgwNCkNCiAgICAgICAgICAgICAgICAg ICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgMHgwNiwgDQogICAgICAgICAgICAgICAgICAg ICAgICAweDA5LCANCiAgICAgICAgICAgICAgICAgICAgICAgIDB4MEEsIA0KICAgICAgICAgICAg ICAgICAgICAgICAgMHgwQg0KICAgICAgICAgICAgICAgICAgICB9KQ0KICAgICAgICAgICAgICAg ICAgICBNZXRob2QgKF9DUlMsIDAsIE5vdFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgICAg IHsNCiAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZUJ5dGVGaWVsZCAoUlNSQywgMHgwMiwg SU9NMSkNCiAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZUJ5dGVGaWVsZCAoUlNSQywgMHgw MywgSU9NMikNCiAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZVdvcmRGaWVsZCAoUlNSQywg MHgwMiwgSU8xSSkNCiAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZVdvcmRGaWVsZCAoUlNS QywgMHgwNCwgSU8xQSkNCiAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZVdvcmRGaWVsZCAo UlNSQywgMHgwOSwgSVJRVikNCiAgICAgICAgICAgICAgICAgICAgICAgIElmIChMRXF1YWwgKFxf U0IuUENJMC5MUENCLkVDMC5FQ09LLCAweDAwKSkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoUEhTQiAoMHhENCwgMHg5QyksIElP TTEpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKFBIU0IgKDB4RDQsIDB4OUQp LCBJT00yKQ0KICAgICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgICAg ICAgRWxzZQ0KICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFN0b3JlIChcX1NCLlBDSTAuTFBDQi5FQzAuU0xPQiwgSU9NMSkNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBTdG9yZSAoXF9TQi5QQ0kwLkxQQ0IuRUMwLlNISUIsIElPTTIpDQog ICAgICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIFN0b3Jl IChJTzFJLCBJTzFBKQ0KICAgICAgICAgICAgICAgICAgICAgICAgSWYgKExFcXVhbCAoXF9TQi5Q Q0kwLkxQQ0IuRUMwLkVDT0ssIDB4MDApKQ0KICAgICAgICAgICAgICAgICAgICAgICAgew0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFNoaWZ0UmlnaHQgKFBIU0IgKDB4RDQsIDB4OUIpLCAw eDA0LCBMb2NhbDApDQogICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAg ICAgICAgICBFbHNlDQogICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgU2hpZnRSaWdodCAoXF9TQi5QQ0kwLkxQQ0IuRUMwLlNJUlEsIDB4MDQsIExv Y2FsMCkNCiAgICAgICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgRmluZFNldFJpZ2h0Qml0IChMb2NhbDAsIExvY2FsMSkNCiAgICAgICAgICAgICAgICAgICAg ICAgIElmIChMb2NhbDEpDQogICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgRGVjcmVtZW50IChMb2NhbDEpDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgU3RvcmUgKERlcmVmT2YgKEluZGV4IChTSVJULCBMb2NhbDEpKSwgTG9jYWwwKQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFNoaWZ0TGVmdCAoMHgwMSwgTG9jYWwwLCBJUlFWKQ0K ICAgICAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgICAgICBSZXR1 cm4gKFJTUkMpDQogICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICBN ZXRob2QgKF9TUlMsIDEsIE5vdFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgICAgIHsNCiAg ICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZUJ5dGVGaWVsZCAoQXJnMCwgMHgwMiwgSU9BMSkN CiAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZUJ5dGVGaWVsZCAoQXJnMCwgMHgwMywgSU9B MikNCiAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZVdvcmRGaWVsZCAoQXJnMCwgMHgwOSwg SVJRVikNCiAgICAgICAgICAgICAgICAgICAgICAgIEZpbmRTZXRSaWdodEJpdCAoSVJRViwgTG9j YWwwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgSWYgKExvY2FsMCkNCiAgICAgICAgICAgICAg ICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBEZWNyZW1lbnQgKExvY2Fs MCkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoTWF0Y2ggKFNJUlQsIE1FUSwg TG9jYWwwLCBNVFIsIDB4MDAsIDB4MDApLCBMb2NhbDEpDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgU2hpZnRMZWZ0ICgweDEwLCBMb2NhbDEsIExvY2FsMikNCiAgICAgICAgICAgICAgICAg ICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAgICAgIEVsc2UNCiAgICAgICAgICAgICAgICAg ICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoMHgwMCwgTG9jYWwy KQ0KICAgICAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgICAgICBJ ZiAoTEVxdWFsIChcX1NCLlBDSTAuTFBDQi5FQzAuRUNPSywgMHgwMCkpDQogICAgICAgICAgICAg ICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgUEhTVyAoMHhENSwgMHg5 QiwgTG9jYWwyKQ0KICAgICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAg ICAgICAgRWxzZQ0KICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFN0b3JlIChMb2NhbDIsIFxfU0IuUENJMC5MUENCLkVDMC5TSVJRKQ0KICAgICAg ICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgICAgICBJZiAoTEVxdWFs IChcX1NCLlBDSTAuTFBDQi5FQzAuRUNPSywgMHgwMCkpDQogICAgICAgICAgICAgICAgICAgICAg ICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgUEhTVyAoMHhENSwgMHg5RCwgSU9BMikN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBQSFNXICgweEQ1LCAweDlDLCBJT0ExKQ0KICAg ICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgICAgICAgRWxzZQ0KICAg ICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0b3Jl IChJT0EyLCBcX1NCLlBDSTAuTFBDQi5FQzAuU0hJQikNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICBTdG9yZSAoSU9BMSwgXF9TQi5QQ0kwLkxQQ0IuRUMwLlNMT0IpDQogICAgICAgICAgICAg ICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIFNsZWVwICgweDAxKQ0KICAg ICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgTmFtZSAoX1BSUywgUmVz b3VyY2VUZW1wbGF0ZSAoKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAg ICAgICAgICBTdGFydERlcGVuZGVudEZuTm9QcmkgKCkNCiAgICAgICAgICAgICAgICAgICAgICAg IHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJTyAoRGVjb2RlMTYsIDB4MTA4MCwgMHgx MDgwLCAweDAxLCAweDIwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAg ICAgICAgICAgICAgU3RhcnREZXBlbmRlbnRGbk5vUHJpICgpDQogICAgICAgICAgICAgICAgICAg ICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgSU8gKERlY29kZTE2LCAweDEwQTAs IDB4MTBBMCwgMHgwMSwgMHgyMCkNCiAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAg ICAgICAgICAgICAgICAgIFN0YXJ0RGVwZW5kZW50Rm5Ob1ByaSAoKQ0KICAgICAgICAgICAgICAg ICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIElPIChEZWNvZGUxNiwgMHgx MEMwLCAweDEwQzAsIDB4MDEsIDB4MjApDQogICAgICAgICAgICAgICAgICAgICAgICB9DQogICAg ICAgICAgICAgICAgICAgICAgICBTdGFydERlcGVuZGVudEZuTm9QcmkgKCkNCiAgICAgICAgICAg ICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJTyAoRGVjb2RlMTYs IDB4MTBFMCwgMHgxMEUwLCAweDAxLCAweDIwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgfQ0K ICAgICAgICAgICAgICAgICAgICAgICAgRW5kRGVwZW5kZW50Rm4gKCkNCiAgICAgICAgICAgICAg ICAgICAgICAgIElSUU5vRmxhZ3MgKCkgezYsOSwxMCwxMX0NCiAgICAgICAgICAgICAgICAgICAg fSkNCiAgICAgICAgICAgICAgICAgICAgTWV0aG9kIChfRElTLCAwLCBOb3RTZXJpYWxpemVkKQ0K ICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoX0NS UyAoKSwgU1NSQykNCiAgICAgICAgICAgICAgICAgICAgICAgIElmIChMRXF1YWwgKFxfU0IuUENJ MC5MUENCLkVDMC5FQ09LLCAweDAwKSkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBQSFNXICgweEQ1LCAweDlCLCAweDAwKQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFBIU1cgKDB4RDUsIDB4OUQsIDB4MDApDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgUEhTVyAoMHhENSwgMHg5QywgMHgwMCkNCiAgICAgICAgICAgICAgICAg ICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAgICAgIEVsc2UNCiAgICAgICAgICAgICAgICAg ICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoMHgwMCwgXF9TQi5Q Q0kwLkxQQ0IuRUMwLlNJUlEpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKDB4 MDAsIFxfU0IuUENJMC5MUENCLkVDMC5TSElCKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg IFN0b3JlICgweDAwLCBcX1NCLlBDSTAuTFBDQi5FQzAuU0xPQikNCiAgICAgICAgICAgICAgICAg ICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICAgICAgU2xlZXAgKDB4MDEpDQogICAgICAg ICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICBNZXRob2QgKF9TVEEsIDAsIE5v dFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAg ICAgIElmIChMRXF1YWwgKFxfU0IuUENJMC5MUENCLkVDMC5FQ09LLCAweDAwKSkNCiAgICAgICAg ICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBTaGlmdFJpZ2h0 IChQSFNCICgweEQ0LCAweDlCKSwgMHgwNCwgTG9jYWwwKQ0KICAgICAgICAgICAgICAgICAgICAg ICAgfQ0KICAgICAgICAgICAgICAgICAgICAgICAgRWxzZQ0KICAgICAgICAgICAgICAgICAgICAg ICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNoaWZ0UmlnaHQgKFxfU0IuUENJMC5M UENCLkVDMC5TSVJRLCAweDA0LCBMb2NhbDApDQogICAgICAgICAgICAgICAgICAgICAgICB9DQoN CiAgICAgICAgICAgICAgICAgICAgICAgIEZpbmRTZXRSaWdodEJpdCAoTG9jYWwwLCBMb2NhbDEp DQogICAgICAgICAgICAgICAgICAgICAgICBJZiAoTG9jYWwxKQ0KICAgICAgICAgICAgICAgICAg ICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJldHVybiAoMHgwRikNCiAgICAg ICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAgICAgIEVsc2UNCiAgICAg ICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBSZXR1cm4g KDB4MEQpDQogICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgICAgIH0N CiAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBEZXZpY2UgKFNOQykNCiAgICAg ICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgIE5hbWUgKF9ISUQsIEVpc2FJZCAoIlNO WTUwMDEiKSkNCiAgICAgICAgICAgICAgICAgICAgTWV0aG9kIChHUElELCAwLCBOb3RTZXJpYWxp emVkKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBSZXR1 cm4gKFBIU0IgKDB4QzAsIDB4MDApKQ0KICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAg ICAgICAgICAgICAgTWV0aG9kIChHQlJULCAwLCBOb3RTZXJpYWxpemVkKQ0KICAgICAgICAgICAg ICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBJZiAoTEVxdWFsIChcX1NCLlBDSTAu TFBDQi5FQzAuRUNPSywgMHgwMCkpDQogICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKFBIU0QgKDB4RDQsIDB4OTYpLCBMb2NhbDApDQog ICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgICAgICAgICBFbHNlDQog ICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgU3Rv cmUgKFxfU0IuUENJMC5MUENCLkVDMC5CUklULCBMb2NhbDApDQogICAgICAgICAgICAgICAgICAg ICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIFJldHVybiAoUEhTQiAoMHhDRiwgTG9j YWwwKSkNCiAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgIE1ldGhv ZCAoU0JSVCwgMSwgTm90U2VyaWFsaXplZCkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAg ICAgICAgICAgICAgICAgICAgU3RvcmUgKFBIU0IgKDB4Q0QsIEFyZzApLCBMb2NhbDApDQogICAg ICAgICAgICAgICAgICAgICAgICBJZiAoTEVxdWFsIChcX1NCLlBDSTAuTFBDQi5FQzAuRUNPSywg MHgwMCkpDQogICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgUEhTQiAoMHhDMywgTG9jYWwwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgfQ0KICAg ICAgICAgICAgICAgICAgICAgICAgRWxzZQ0KICAgICAgICAgICAgICAgICAgICAgICAgew0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlIChMb2NhbDAsIFxfU0IuUENJMC5MUENCLkVD MC5CUklUKQ0KICAgICAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAg ICAgICBSZXR1cm4gKFplcm8pDQogICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAg ICAgICAgICBNZXRob2QgKEdQQlIsIDAsIE5vdFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAg ICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIFJldHVybiAoUEhTQiAoMHhDMSwgMHgwMCkp DQogICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICBNZXRob2QgKFNQ QlIsIDEsIE5vdFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAg ICAgICAgICAgICAgIFBIU0IgKDB4QzIsIEFyZzApDQogICAgICAgICAgICAgICAgICAgICAgICBS ZXR1cm4gKFplcm8pDQogICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAg ICBNZXRob2QgKEdDVFIsIDAsIE5vdFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgICAgIHsN CiAgICAgICAgICAgICAgICAgICAgICAgIElmIChMRXF1YWwgKFxfU0IuUENJMC5MUENCLkVDMC5F Q09LLCAweDAwKSkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICBTdG9yZSAoUEhTRCAoMHhENCwgMHg5NyksIExvY2FsMCkNCiAgICAgICAgICAg ICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAgICAgIEVsc2UNCiAgICAgICAgICAg ICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoXF9TQi5Q Q0kwLkxQQ0IuRUMwLkNPTlQsIExvY2FsMCkNCiAgICAgICAgICAgICAgICAgICAgICAgIH0NCg0K ICAgICAgICAgICAgICAgICAgICAgICAgUmV0dXJuIChQSFNCICgweEQwLCBMb2NhbDApKQ0KICAg ICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgTWV0aG9kIChTQ1RSLCAx LCBOb3RTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAg ICAgICAgICBTdG9yZSAoUEhTQiAoMHhDRSwgQXJnMCksIExvY2FsMCkNCiAgICAgICAgICAgICAg ICAgICAgICAgIElmIChMRXF1YWwgKFxfU0IuUENJMC5MUENCLkVDMC5FQ09LLCAweDAwKSkNCiAg ICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBQSFNC ICgweEM2LCBMb2NhbDApDQogICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAg ICAgICAgICAgICBFbHNlDQogICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgU3RvcmUgKExvY2FsMCwgXF9TQi5QQ0kwLkxQQ0IuRUMwLkNPTlQpDQog ICAgICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIFJldHVy biAoWmVybykNCiAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgIE1l dGhvZCAoR1BDUiwgMCwgTm90U2VyaWFsaXplZCkNCiAgICAgICAgICAgICAgICAgICAgew0KICAg ICAgICAgICAgICAgICAgICAgICAgUmV0dXJuIChQSFNCICgweEM0LCAweDAwKSkNCiAgICAgICAg ICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgIE1ldGhvZCAoU1BDUiwgMSwgTm90 U2VyaWFsaXplZCkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAg ICAgUEhTQiAoMHhDNSwgQXJnMCkNCiAgICAgICAgICAgICAgICAgICAgICAgIFJldHVybiAoWmVy bykNCiAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgIE1ldGhvZCAo R0NNSSwgMSwgTm90U2VyaWFsaXplZCkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAg ICAgICAgICAgICAgICAgUmV0dXJuIChQSFNEICgweENBLCBBcmcwKSkNCiAgICAgICAgICAgICAg ICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgIE1ldGhvZCAoU0NNSSwgMSwgTm90U2VyaWFs aXplZCkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgUmV0 dXJuIChQSFNEICgweENCLCBBcmcwKSkNCiAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAg ICAgICAgICAgICAgIE1ldGhvZCAoUFdBSywgMCwgTm90U2VyaWFsaXplZCkNCiAgICAgICAgICAg ICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgQWNxdWlyZSAoUExPSywgMHhGRkZG KQ0KICAgICAgICAgICAgICAgICAgICAgICAgTm90aWZ5IChcX1BSLkNQVTAsIDB4ODApDQogICAg ICAgICAgICAgICAgICAgICAgICBSZWxlYXNlIChQTE9LKQ0KICAgICAgICAgICAgICAgICAgICAg ICAgUmV0dXJuIChaZXJvKQ0KICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAg ICAgICAgTWV0aG9kIChQV1JOLCAwLCBOb3RTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAgICAg ICB7DQogICAgICAgICAgICAgICAgICAgICAgICBOb3RpZnkgKFxfU0IuUFdSQiwgMHg4MCkNCiAg ICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgIE1ldGhvZCAoQ1NYQiwg MSwgTm90U2VyaWFsaXplZCkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAg ICAgICAgICAgQWNxdWlyZSAoTVBIUywgMHhGRkZGKQ0KICAgICAgICAgICAgICAgICAgICAgICAg U3RvcmUgKEFyZzAsIFNYQkYpDQogICAgICAgICAgICAgICAgICAgICAgICBQSFMwICgweENDKQ0K ICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKFNYQkYsIExvY2FsMCkNCiAgICAgICAgICAg ICAgICAgICAgICAgIFJlbGVhc2UgKE1QSFMpDQogICAgICAgICAgICAgICAgICAgICAgICBSZXR1 cm4gKExvY2FsMCkNCiAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAg IE5hbWUgKEJTSVQsIDB4RkZGRikNCiAgICAgICAgICAgICAgICAgICAgTWV0aG9kIChDRFBXLCAx LCBTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAg ICAgICBJZiAoQXJnMCkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICBJZiAoTE5vdCAoQW5kIChcR0wwMywgMHgwOCkpKQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT3IgKEFu ZCAoXF9TQi5QQ0kwLklERUMuSUNSNCwgMHgwMyksIDB4MDQsIFxfU0IuUENJMC5JREVDLklDUjQp DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNsZWVwICgweDBBKQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBPciAoXEdMMDMsIDB4MDgsIFxHTDAzKQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBTbGVlcCAoMHgwMUY0KQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBBbmQgKFxfU0IuUENJMC5JREVDLklDUjQsIDB4MDMsIFxfU0IuUENJMC5J REVDLklDUjQpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlIChCU0lULCBc X1NCLlBDSTAuSURFQy5TRUNUKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAg ICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAgICAgIEVsc2UNCiAgICAg ICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJZiAoQW5k IChcR0wwMywgMHgwOCkpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoXF9TQi5QQ0kwLklERUMuU0VDVCwgQlNJVCkN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKDB4ODAwMCwgXF9TQi5QQ0kw LklERUMuU0VDVCkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT3IgKEFuZCAoXF9T Qi5QQ0kwLklERUMuSUNSNCwgMHgwMyksIDB4MDQsIFxfU0IuUENJMC5JREVDLklDUjQpDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFNsZWVwICgweDBBKQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBBbmQgKFxHTDAzLCAweEY3LCBcR0wwMykNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgU2xlZXAgKDB4MDFGNCkNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICB9DQogICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgICAgIH0N Cg0KICAgICAgICAgICAgICAgICAgICBNZXRob2QgKEdDRFAsIDAsIE5vdFNlcmlhbGl6ZWQpDQog ICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIFJldHVybiAoU2hp ZnRSaWdodCAoQW5kIChcR0wwMywgMHgwOCksIDB4MDMpKQ0KICAgICAgICAgICAgICAgICAgICB9 DQoNCiAgICAgICAgICAgICAgICAgICAgTWV0aG9kIChHV0RQLCAwLCBOb3RTZXJpYWxpemVkKQ0K ICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBSZXR1cm4gKFBI UyAoMHhERikpDQogICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICBN ZXRob2QgKE5QUEMsIDEsIE5vdFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgICAgIHsNCiAg ICAgICAgICAgICAgICAgICAgICAgIE5vb3ANCiAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAg ICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgIERldmljZSAoUFMySykNCiAgICAgICAgICAg ICAgICB7DQogICAgICAgICAgICAgICAgICAgIE5hbWUgKF9ISUQsIEVpc2FJZCAoIlBOUDAzMDMi KSkNCiAgICAgICAgICAgICAgICAgICAgTmFtZSAoX0NSUywgUmVzb3VyY2VUZW1wbGF0ZSAoKQ0K ICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBJTyAoRGVjb2Rl MTYsIDB4MDA2MCwgMHgwMDYwLCAweDAxLCAweDAxKQ0KICAgICAgICAgICAgICAgICAgICAgICAg SU8gKERlY29kZTE2LCAweDAwNjQsIDB4MDA2NCwgMHgwMSwgMHgwMSkNCiAgICAgICAgICAgICAg ICAgICAgICAgIElSUSAoRWRnZSwgQWN0aXZlSGlnaCwgRXhjbHVzaXZlKSB7MX0NCiAgICAgICAg ICAgICAgICAgICAgfSkNCiAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBEZXZp Y2UgKFBTMk0pDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBOYW1lIChf SElELCBFaXNhSWQgKCJTTlk5MDA2IikpDQogICAgICAgICAgICAgICAgICAgIE5hbWUgKF9DSUQs IDB4MTMwRkQwNDEpDQogICAgICAgICAgICAgICAgICAgIE5hbWUgKF9DUlMsIFJlc291cmNlVGVt cGxhdGUgKCkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAg SVJRIChFZGdlLCBBY3RpdmVIaWdoLCBFeGNsdXNpdmUpIHsxMn0NCiAgICAgICAgICAgICAgICAg ICAgfSkNCiAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICB9DQoNCiAgICAgICAgICAgIERl dmljZSAoVVNCMCkNCiAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICBOYW1lIChfQURSLCAw eDAwMUQwMDAwKQ0KICAgICAgICAgICAgICAgIE9wZXJhdGlvblJlZ2lvbiAoVTBDUywgUENJX0Nv bmZpZywgMHhDNCwgMHgwNCkNCiAgICAgICAgICAgICAgICBGaWVsZCAoVTBDUywgRFdvcmRBY2Ms IE5vTG9jaywgUHJlc2VydmUpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAg ICBVMEVOLCAgIDINCiAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBOYW1lIChf UFJXLCBQYWNrYWdlICgweDAyKQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAg ICAgMHgwMywgDQogICAgICAgICAgICAgICAgICAgIDB4MDMNCiAgICAgICAgICAgICAgICB9KQ0K ICAgICAgICAgICAgICAgIE1ldGhvZCAoX1BTVywgMSwgTm90U2VyaWFsaXplZCkNCiAgICAgICAg ICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgIElmIChBcmcwKQ0KICAgICAgICAgICAgICAg ICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoMHgwMywgVTBFTikNCiAgICAg ICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgICBFbHNlDQogICAgICAgICAgICAg ICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlICgweDAwLCBVMEVOKQ0KICAg ICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAg TWV0aG9kIChfUzFELCAwLCBOb3RTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAgIHsNCiAgICAg ICAgICAgICAgICAgICAgUmV0dXJuICgweDAyKQ0KICAgICAgICAgICAgICAgIH0NCg0KICAgICAg ICAgICAgICAgIE1ldGhvZCAoX1MzRCwgMCwgTm90U2VyaWFsaXplZCkNCiAgICAgICAgICAgICAg ICB7DQogICAgICAgICAgICAgICAgICAgIFJldHVybiAoMHgwMikNCiAgICAgICAgICAgICAgICB9 DQoNCiAgICAgICAgICAgICAgICBNZXRob2QgKF9TNEQsIDAsIE5vdFNlcmlhbGl6ZWQpDQogICAg ICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBSZXR1cm4gKDB4MDIpDQogICAgICAg ICAgICAgICAgfQ0KICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICBEZXZpY2UgKFVTQjEpDQog ICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgTmFtZSAoX0FEUiwgMHgwMDFEMDAwMSkNCiAg ICAgICAgICAgICAgICBPcGVyYXRpb25SZWdpb24gKFUxQ1MsIFBDSV9Db25maWcsIDB4QzQsIDB4 MDQpDQogICAgICAgICAgICAgICAgRmllbGQgKFUxQ1MsIERXb3JkQWNjLCBOb0xvY2ssIFByZXNl cnZlKQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgVTFFTiwgICAyDQog ICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgTmFtZSAoX1BSVywgUGFja2FnZSAo MHgwMikNCiAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgIDB4MDQsIA0KICAg ICAgICAgICAgICAgICAgICAweDAzDQogICAgICAgICAgICAgICAgfSkNCiAgICAgICAgICAgICAg ICBNZXRob2QgKF9QU1csIDEsIE5vdFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgew0KICAg ICAgICAgICAgICAgICAgICBJZiAoQXJnMCkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAg ICAgICAgICAgICAgICAgICAgU3RvcmUgKDB4MDMsIFUxRU4pDQogICAgICAgICAgICAgICAgICAg IH0NCiAgICAgICAgICAgICAgICAgICAgRWxzZQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAg ICAgICAgICAgICAgICAgICAgICBTdG9yZSAoMHgwMCwgVTFFTikNCiAgICAgICAgICAgICAgICAg ICAgfQ0KICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgIE1ldGhvZCAoX1MxRCwg MCwgTm90U2VyaWFsaXplZCkNCiAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAg IFJldHVybiAoMHgwMikNCiAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBNZXRo b2QgKF9TM0QsIDAsIE5vdFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAg ICAgICAgICAgICBSZXR1cm4gKDB4MDIpDQogICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAg ICAgICAgTWV0aG9kIChfUzRELCAwLCBOb3RTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAgIHsN CiAgICAgICAgICAgICAgICAgICAgUmV0dXJuICgweDAyKQ0KICAgICAgICAgICAgICAgIH0NCiAg ICAgICAgICAgIH0NCg0KICAgICAgICAgICAgRGV2aWNlIChVU0IyKQ0KICAgICAgICAgICAgew0K ICAgICAgICAgICAgICAgIE5hbWUgKF9BRFIsIDB4MDAxRDAwMDIpDQogICAgICAgICAgICAgICAg T3BlcmF0aW9uUmVnaW9uIChVMkNTLCBQQ0lfQ29uZmlnLCAweEM0LCAweDA0KQ0KICAgICAgICAg ICAgICAgIEZpZWxkIChVMkNTLCBEV29yZEFjYywgTm9Mb2NrLCBQcmVzZXJ2ZSkNCiAgICAgICAg ICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgIFUyRU4sICAgMg0KICAgICAgICAgICAgICAg IH0NCg0KICAgICAgICAgICAgICAgIE5hbWUgKF9QUlcsIFBhY2thZ2UgKDB4MDIpDQogICAgICAg ICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAweDBDLCANCiAgICAgICAgICAgICAgICAg ICAgMHgwMw0KICAgICAgICAgICAgICAgIH0pDQogICAgICAgICAgICAgICAgTWV0aG9kIChfUFNX LCAxLCBOb3RTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAg ICAgSWYgKEFyZzApDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAg ICAgIFN0b3JlICgweDAzLCBVMkVOKQ0KICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAg ICAgICAgICAgIEVsc2UNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAg ICAgICAgU3RvcmUgKDB4MDAsIFUyRU4pDQogICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAg ICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBNZXRob2QgKF9TMUQsIDAsIE5vdFNlcmlhbGl6 ZWQpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBSZXR1cm4gKDB4MDIp DQogICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgTWV0aG9kIChfUzNELCAwLCBO b3RTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgUmV0 dXJuICgweDAyKQ0KICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgIE1ldGhvZCAo X1M0RCwgMCwgTm90U2VyaWFsaXplZCkNCiAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAg ICAgICAgIFJldHVybiAoMHgwMikNCiAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICB9DQoN CiAgICAgICAgICAgIERldmljZSAoVVNCNykNCiAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAg ICBOYW1lIChfQURSLCAweDAwMUQwMDA3KQ0KICAgICAgICAgICAgICAgIE5hbWUgKF9QUlcsIFBh Y2thZ2UgKDB4MDIpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAweDBE LCANCiAgICAgICAgICAgICAgICAgICAgMHgwMw0KICAgICAgICAgICAgICAgIH0pDQogICAgICAg ICAgICB9DQoNCiAgICAgICAgICAgIE5hbWUgKE5BVEEsIFBhY2thZ2UgKDB4MDEpDQogICAgICAg ICAgICB7DQogICAgICAgICAgICAgICAgMHgwMDFGMDAwMQ0KICAgICAgICAgICAgfSkNCiAgICAg ICAgICAgIERldmljZSAoSURFQykNCiAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICBOYW1l IChfQURSLCAweDAwMUYwMDAxKQ0KICAgICAgICAgICAgICAgIE9wZXJhdGlvblJlZ2lvbiAoSURF QywgUENJX0NvbmZpZywgMHg0MCwgMHgxOCkNCiAgICAgICAgICAgICAgICBGaWVsZCAoSURFQywg RFdvcmRBY2MsIE5vTG9jaywgUHJlc2VydmUpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAg ICAgICAgICAgICBQUklULCAgIDE2LCANCiAgICAgICAgICAgICAgICAgICAgU0VDVCwgICAxNiwg DQogICAgICAgICAgICAgICAgICAgIFBTSVQsICAgNCwgDQogICAgICAgICAgICAgICAgICAgIFNT SVQsICAgNCwgDQogICAgICAgICAgICAgICAgICAgIE9mZnNldCAoMHgwOCksIA0KICAgICAgICAg ICAgICAgICAgICBTWU5DLCAgIDQsIA0KICAgICAgICAgICAgICAgICAgICBPZmZzZXQgKDB4MEEp LCANCiAgICAgICAgICAgICAgICAgICAgU0RUMCwgICAyLCANCiAgICAgICAgICAgICAgICAgICAg ICAgICwgICAyLCANCiAgICAgICAgICAgICAgICAgICAgU0RUMSwgICAyLCANCiAgICAgICAgICAg ICAgICAgICAgT2Zmc2V0ICgweDBCKSwgDQogICAgICAgICAgICAgICAgICAgIFNEVDIsICAgMiwg DQogICAgICAgICAgICAgICAgICAgICAgICAsICAgMiwgDQogICAgICAgICAgICAgICAgICAgIFNE VDMsICAgMiwgDQogICAgICAgICAgICAgICAgICAgIE9mZnNldCAoMHgxNCksIA0KICAgICAgICAg ICAgICAgICAgICBJQ1IwLCAgIDQsIA0KICAgICAgICAgICAgICAgICAgICBJQ1IxLCAgIDQsIA0K ICAgICAgICAgICAgICAgICAgICBJQ1IyLCAgIDQsIA0KICAgICAgICAgICAgICAgICAgICBJQ1Iz LCAgIDQsIA0KICAgICAgICAgICAgICAgICAgICBJQ1I0LCAgIDQsIA0KICAgICAgICAgICAgICAg ICAgICBJQ1I1LCAgIDQNCiAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBEZXZp Y2UgKFBSSUQpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBOYW1lIChf QURSLCAweDAwKQ0KICAgICAgICAgICAgICAgICAgICBNZXRob2QgKF9HVE0sIDAsIE5vdFNlcmlh bGl6ZWQpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIE5h bWUgKFBCVUYsIEJ1ZmZlciAoMHgxNCkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAweDAwLCAweDAwLCAweDAwLCAweDAwLCAweDAwLCAweDAw LCAweDAwLCAweDAwLCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAweDAwLCAweDAwLCAw eDAwLCAweDAwLCAweDAwLCAweDAwLCAweDAwLCAweDAwLCANCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAweDAwLCAweDAwLCAweDAwLCAweDAwDQogICAgICAgICAgICAgICAgICAgICAgICB9 KQ0KICAgICAgICAgICAgICAgICAgICAgICAgQ3JlYXRlRFdvcmRGaWVsZCAoUEJVRiwgMHgwMCwg UElPMCkNCiAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZURXb3JkRmllbGQgKFBCVUYsIDB4 MDQsIERNQTApDQogICAgICAgICAgICAgICAgICAgICAgICBDcmVhdGVEV29yZEZpZWxkIChQQlVG LCAweDA4LCBQSU8xKQ0KICAgICAgICAgICAgICAgICAgICAgICAgQ3JlYXRlRFdvcmRGaWVsZCAo UEJVRiwgMHgwQywgRE1BMSkNCiAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZURXb3JkRmll bGQgKFBCVUYsIDB4MTAsIEZMQUcpDQogICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoR0VU UCAoUFJJVCksIFBJTzApDQogICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoR0RNQSAoQW5k IChTWU5DLCAweDAxKSwgQW5kIChJQ1IzLCAweDAxKSwgQW5kIChJQ1IwLCAweDAxKSwgU0RUMCwg QW5kIChJQ1IxLCAweDAxKSksIERNQTApDQogICAgICAgICAgICAgICAgICAgICAgICBJZiAoTEVx dWFsIChETUEwLCAweEZGRkZGRkZGKSkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoUElPMCwgRE1BMCkNCiAgICAgICAgICAgICAg ICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICAgICAgSWYgKEFuZCAoUFJJVCwgMHg0 MDAwKSkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICBJZiAoTEVxdWFsIChBbmQgKFBSSVQsIDB4OTApLCAweDgwKSkNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlICgw eDAzODQsIFBJTzEpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEVsc2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB7DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlIChHRVRUIChQU0lUKSwgUElPMSkNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgICAgICAgICB9DQog ICAgICAgICAgICAgICAgICAgICAgICBFbHNlDQogICAgICAgICAgICAgICAgICAgICAgICB7DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKDB4RkZGRkZGRkYsIFBJTzEpDQogICAg ICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlIChH RE1BIChBbmQgKFNZTkMsIDB4MDIpLCBBbmQgKElDUjMsIDB4MDIpLCBBbmQgKElDUjAsIDB4MDIp LCBTRFQxLCBBbmQgKElDUjEsIDB4MDIpKSwgRE1BMSkNCiAgICAgICAgICAgICAgICAgICAgICAg IElmIChMRXF1YWwgKERNQTEsIDB4RkZGRkZGRkYpKQ0KICAgICAgICAgICAgICAgICAgICAgICAg ew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlIChQSU8xLCBETUExKQ0KICAgICAg ICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoR0VU RiAoQW5kIChTWU5DLCAweDAxKSwgQW5kIChTWU5DLCAweDAyKSwgUFJJVCksIEZMQUcpDQogICAg ICAgICAgICAgICAgICAgICAgICBSZXR1cm4gKFBCVUYpDQogICAgICAgICAgICAgICAgICAgIH0N Cg0KICAgICAgICAgICAgICAgICAgICBNZXRob2QgKF9TVE0sIDMsIE5vdFNlcmlhbGl6ZWQpDQog ICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZURXb3Jk RmllbGQgKEFyZzAsIDB4MDAsIFBJTzApDQogICAgICAgICAgICAgICAgICAgICAgICBDcmVhdGVE V29yZEZpZWxkIChBcmcwLCAweDA0LCBETUEwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgQ3Jl YXRlRFdvcmRGaWVsZCAoQXJnMCwgMHgwOCwgUElPMSkNCiAgICAgICAgICAgICAgICAgICAgICAg IENyZWF0ZURXb3JkRmllbGQgKEFyZzAsIDB4MEMsIERNQTEpDQogICAgICAgICAgICAgICAgICAg ICAgICBDcmVhdGVEV29yZEZpZWxkIChBcmcwLCAweDEwLCBGTEFHKQ0KICAgICAgICAgICAgICAg ICAgICAgICAgT3IgKElDUjIsIDB4MDQsIElDUjIpDQogICAgICAgICAgICAgICAgICAgICAgICBJ ZiAoTEVxdWFsIChTaXplT2YgKEFyZzEpLCAweDAyMDApKQ0KICAgICAgICAgICAgICAgICAgICAg ICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFuZCAoUFJJVCwgMHg0MEYwLCBQUklU KQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFuZCAoU1lOQywgMHgwRSwgU1lOQykNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoMHgwMCwgU0RUMCkNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBBbmQgKElDUjAsIDB4MEUsIElDUjApDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgQW5kIChJQ1IxLCAweDBFLCBJQ1IxKQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEFuZCAoSUNSMywgMHgwRSwgSUNSMykNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBBbmQgKElDUjUsIDB4MEUsIElDUjUpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgQ3Jl YXRlV29yZEZpZWxkIChBcmcxLCAweDYyLCBXNDkwKQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgIENyZWF0ZVdvcmRGaWVsZCAoQXJnMSwgMHg2QSwgVzUzMCkNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICBDcmVhdGVXb3JkRmllbGQgKEFyZzEsIDB4N0UsIFc2MzApDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgQ3JlYXRlV29yZEZpZWxkIChBcmcxLCAweDgwLCBXNjQwKQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZVdvcmRGaWVsZCAoQXJnMSwgMHhCMCwgVzg4 MCkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBDcmVhdGVXb3JkRmllbGQgKEFyZzEsIDB4 QkEsIFc5MzApDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgT3IgKFBSSVQsIDB4ODAwNCwg UFJJVCkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJZiAoTEFuZCAoQW5kIChGTEFHLCAw eDAyKSwgQW5kIChXNDkwLCAweDA4MDApKSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB7 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9yIChQUklULCAweDAyLCBQUklUKQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgIE9yIChQUklULCBTRVRQIChQSU8wLCBXNTMwLCBXNjQwKSwgUFJJVCkNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBJZiAoQW5kIChGTEFHLCAweDAxKSkNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9yIChTWU5DLCAw eDAxLCBTWU5DKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoU0RNQSAo RE1BMCksIFNEVDApDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElmIChMTGVzcyAo RE1BMCwgMHgxRSkpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9yIChJQ1IzLCAweDAxLCBJQ1IzKQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgSWYgKExMZXNzIChETUEwLCAweDNDKSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT3IgKElDUjAsIDB4 MDEsIElDUjApDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBJZiAoQW5kIChXOTMwLCAweDIwMDApKQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBPciAoSUNSMSwgMHgwMSwgSUNSMSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAg ICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICAgICAgSWYgKExFcXVhbCAoU2l6ZU9mIChBcmcy KSwgMHgwMjAwKSkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICBBbmQgKFBSSVQsIDB4M0YwRiwgUFJJVCkNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBTdG9yZSAoMHgwMCwgUFNJVCkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBB bmQgKFNZTkMsIDB4MEQsIFNZTkMpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUg KDB4MDAsIFNEVDEpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgQW5kIChJQ1IwLCAweDBE LCBJQ1IwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFuZCAoSUNSMSwgMHgwRCwgSUNS MSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBBbmQgKElDUjMsIDB4MEQsIElDUjMpDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgQW5kIChJQ1I1LCAweDBELCBJQ1I1KQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZVdvcmRGaWVsZCAoQXJnMiwgMHg2MiwgVzQ5MSkN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBDcmVhdGVXb3JkRmllbGQgKEFyZzIsIDB4NkEs IFc1MzEpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgQ3JlYXRlV29yZEZpZWxkIChBcmcy LCAweDdFLCBXNjMxKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZVdvcmRGaWVs ZCAoQXJnMiwgMHg4MCwgVzY0MSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBDcmVhdGVX b3JkRmllbGQgKEFyZzIsIDB4QjAsIFc4ODEpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg Q3JlYXRlV29yZEZpZWxkIChBcmcyLCAweEJBLCBXOTMxKQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIE9yIChQUklULCAweDgwNDAsIFBSSVQpDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgSWYgKExBbmQgKEFuZCAoRkxBRywgMHgwOCksIEFuZCAoVzQ5MSwgMHgwODAwKSkpDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBPciAoUFJJVCwgMHgyMCwgUFJJVCkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB9DQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJZiAoQW5kIChGTEFHLCAweDEwKSkNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IE9yIChQUklULCAweDQwMDAsIFBSSVQpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IElmIChMR3JlYXRlciAoUElPMSwgMHhGMCkpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9yIChQUklULCAweDgw LCBQUklUKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEVsc2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT3IgKFBSSVQsIDB4MTAsIFBS SVQpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoU0VUVCAoUElP MSwgVzUzMSwgVzY0MSksIFBTSVQpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICBJZiAoQW5kIChGTEFHLCAweDA0KSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB7 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9yIChTWU5DLCAweDAyLCBTWU5DKQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoU0RNQSAoRE1BMSksIFNEVDEp DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElmIChMTGVzcyAoRE1BMCwgMHgxRSkp DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE9yIChJQ1IzLCAweDAyLCBJQ1IzKQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSWYgKExM ZXNzIChETUEwLCAweDNDKSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgew0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT3IgKElDUjAsIDB4MDIsIElDUjApDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBJZiAoQW5kIChXOTMxLCAweDIwMDApKQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPciAoSUNS MSwgMHgwMiwgSUNSMSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAg ICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgIERldmljZSAoUF9EMCkNCiAg ICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgTmFtZSAoX0FEUiwg MHgwMCkNCiAgICAgICAgICAgICAgICAgICAgICAgIE1ldGhvZCAoX0dURiwgMCwgTm90U2VyaWFs aXplZCkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICBOYW1lIChQSUIwLCBCdWZmZXIgKDB4MEUpDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAweDAzLCAweDAwLCAweDAwLCAw eDAwLCAweDAwLCAweEEwLCAweEVGLCAweDAzLCANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgMHgwMCwgMHgwMCwgMHgwMCwgMHgwMCwgMHhBMCwgMHhFRg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgIH0pDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgQ3JlYXRlQnl0ZUZp ZWxkIChQSUIwLCAweDAxLCBQTUQwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0 ZUJ5dGVGaWVsZCAoUElCMCwgMHgwOCwgRE1EMCkNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBJZiAoQW5kIChQUklULCAweDAyKSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB7DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElmIChMRXF1YWwgKEFuZCAoUFJJVCwgMHgw OSksIDB4MDgpKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoMHgwOCwgUE1EMCkNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBF bHNlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFN0b3JlICgweDBBLCBQTUQwKQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgU2hpZnRSaWdodCAoQW5kIChQUklULCAweDAzMDApLCAweDA4LCBM b2NhbDApDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTaGlmdFJpZ2h0IChB bmQgKFBSSVQsIDB4MzAwMCksIDB4MEMsIExvY2FsMSkNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEFkZCAoTG9jYWwwLCBMb2NhbDEsIExvY2FsMikNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIElmIChMRXF1YWwgKDB4MDMsIExvY2FsMikpDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgU3RvcmUgKDB4MEIsIFBNRDApDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElm IChMRXF1YWwgKDB4MDUsIExvY2FsMikpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKDB4 MEMsIFBNRDApDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB9 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgRWxzZQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKDB4MDEsIFBN RDApDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgSWYgKEFuZCAoU1lOQywgMHgwMSkpDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoT3IgKFNEVDAsIDB4 NDApLCBETUQwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJZiAoQW5kIChJQ1Ix LCAweDAxKSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSWYgKEFuZCAoSUNSMCwgMHgwMSkpDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQWRkIChETUQwLCAweDAyLCBETUQwKQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJ ZiAoQW5kIChJQ1IzLCAweDAxKSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoMHg0NSwg RE1EMCkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBFbHNlDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPciAoU3VidHJhY3QgKEFuZCAo UE1EMCwgMHgwNyksIDB4MDIpLCAweDIwLCBETUQwKQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJldHVybiAoUElCMCkNCiAgICAg ICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAg ICAgICAgICAgIE5hbWUgKEZXU08sICJGV1NPIikNCiAgICAgICAgICAgICAgICAgICAgTmFtZSAo X1BTQywgMHgwMCkNCiAgICAgICAgICAgICAgICAgICAgTWV0aG9kIChfUFMwLCAwLCBOb3RTZXJp YWxpemVkKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBT dG9yZSAoMHgwMCwgX1BTQykNCiAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAg ICAgICAgIE1ldGhvZCAoX1BTMywgMCwgTm90U2VyaWFsaXplZCkNCiAgICAgICAgICAgICAgICAg ICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKDB4MDMsIF9QU0MpDQogICAgICAg ICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBEZXZp Y2UgKFNFQ0QpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBOYW1lIChf QURSLCAweDAxKQ0KICAgICAgICAgICAgICAgICAgICBNZXRob2QgKF9HVE0sIDAsIE5vdFNlcmlh bGl6ZWQpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIE5h bWUgKFNCVUYsIEJ1ZmZlciAoMHgxNCkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAweDAwLCAweDAwLCAweDAwLCAweDAwLCAweDAwLCAweDAw LCAweDAwLCAweDAwLCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAweDAwLCAweDAwLCAw eDAwLCAweDAwLCAweDAwLCAweDAwLCAweDAwLCAweDAwLCANCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAweDAwLCAweDAwLCAweDAwLCAweDAwDQogICAgICAgICAgICAgICAgICAgICAgICB9 KQ0KICAgICAgICAgICAgICAgICAgICAgICAgQ3JlYXRlRFdvcmRGaWVsZCAoU0JVRiwgMHgwMCwg UElPMCkNCiAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZURXb3JkRmllbGQgKFNCVUYsIDB4 MDQsIERNQTApDQogICAgICAgICAgICAgICAgICAgICAgICBDcmVhdGVEV29yZEZpZWxkIChTQlVG LCAweDA4LCBQSU8xKQ0KICAgICAgICAgICAgICAgICAgICAgICAgQ3JlYXRlRFdvcmRGaWVsZCAo U0JVRiwgMHgwQywgRE1BMSkNCiAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZURXb3JkRmll bGQgKFNCVUYsIDB4MTAsIEZMQUcpDQogICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoR0VU UCAoU0VDVCksIFBJTzApDQogICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoR0RNQSAoQW5k IChTWU5DLCAweDA0KSwgQW5kIChJQ1IzLCAweDA0KSwgQW5kIChJQ1IwLCAweDA0KSwgU0RUMiwg QW5kIChJQ1IxLCAweDA0KSksIERNQTApDQogICAgICAgICAgICAgICAgICAgICAgICBJZiAoTEVx dWFsIChETUEwLCAweEZGRkZGRkZGKSkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoUElPMCwgRE1BMCkNCiAgICAgICAgICAgICAg ICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICAgICAgSWYgKEFuZCAoU0VDVCwgMHg0 MDAwKSkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICBJZiAoTEVxdWFsIChBbmQgKFNFQ1QsIDB4OTApLCAweDgwKSkNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlICgw eDAzODQsIFBJTzEpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEVsc2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB7DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlIChHRVRUIChTU0lUKSwgUElPMSkNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgICAgICAgICB9DQog ICAgICAgICAgICAgICAgICAgICAgICBFbHNlDQogICAgICAgICAgICAgICAgICAgICAgICB7DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKDB4RkZGRkZGRkYsIFBJTzEpDQogICAg ICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlIChH RE1BIChBbmQgKFNZTkMsIDB4MDgpLCBBbmQgKElDUjMsIDB4MDgpLCBBbmQgKElDUjAsIDB4MDgp LCBTRFQzLCBBbmQgKElDUjEsIDB4MDgpKSwgRE1BMSkNCiAgICAgICAgICAgICAgICAgICAgICAg IElmIChMRXF1YWwgKERNQTEsIDB4RkZGRkZGRkYpKQ0KICAgICAgICAgICAgICAgICAgICAgICAg ew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0b3JlIChQSU8xLCBETUExKQ0KICAgICAg ICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoR0VU RiAoQW5kIChTWU5DLCAweDA0KSwgQW5kIChTWU5DLCAweDA4KSwgU0VDVCksIEZMQUcpDQogICAg ICAgICAgICAgICAgICAgICAgICBSZXR1cm4gKFNCVUYpDQogICAgICAgICAgICAgICAgICAgIH0N Cg0KICAgICAgICAgICAgICAgICAgICBNZXRob2QgKF9TVE0sIDMsIE5vdFNlcmlhbGl6ZWQpDQog ICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZURXb3Jk RmllbGQgKEFyZzAsIDB4MDAsIFBJTzApDQogICAgICAgICAgICAgICAgICAgICAgICBDcmVhdGVE V29yZEZpZWxkIChBcmcwLCAweDA0LCBETUEwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgQ3Jl YXRlRFdvcmRGaWVsZCAoQXJnMCwgMHgwOCwgUElPMSkNCiAgICAgICAgICAgICAgICAgICAgICAg IENyZWF0ZURXb3JkRmllbGQgKEFyZzAsIDB4MEMsIERNQTEpDQogICAgICAgICAgICAgICAgICAg ICAgICBDcmVhdGVEV29yZEZpZWxkIChBcmcwLCAweDEwLCBGTEFHKQ0KICAgICAgICAgICAgICAg ICAgICAgICAgT3IgKElDUjIsIDB4MDQsIElDUjIpDQogICAgICAgICAgICAgICAgICAgICAgICBJ ZiAoTEVxdWFsIChTaXplT2YgKEFyZzEpLCAweDAyMDApKQ0KICAgICAgICAgICAgICAgICAgICAg ICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFuZCAoU0VDVCwgMHg0MEYwLCBTRUNU KQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFuZCAoU1lOQywgMHgwQiwgU1lOQykNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoMHgwMCwgU0RUMikNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBBbmQgKElDUjAsIDB4MEIsIElDUjApDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgQW5kIChJQ1IxLCAweDBCLCBJQ1IxKQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEFuZCAoSUNSMywgMHgwQiwgSUNSMykNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBBbmQgKElDUjUsIDB4MEIsIElDUjUpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgQ3Jl YXRlV29yZEZpZWxkIChBcmcxLCAweDYyLCBXNDkwKQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgIENyZWF0ZVdvcmRGaWVsZCAoQXJnMSwgMHg2QSwgVzUzMCkNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICBDcmVhdGVXb3JkRmllbGQgKEFyZzEsIDB4N0UsIFc2MzApDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgQ3JlYXRlV29yZEZpZWxkIChBcmcxLCAweDgwLCBXNjQwKQ0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZVdvcmRGaWVsZCAoQXJnMSwgMHhCMCwgVzg4 MCkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBDcmVhdGVXb3JkRmllbGQgKEFyZzEsIDB4 QkEsIFc5MzApDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgT3IgKFNFQ1QsIDB4ODAwNCwg U0VDVCkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJZiAoTEFuZCAoQW5kIChGTEFHLCAw eDAyKSwgQW5kIChXNDkwLCAweDA4MDApKSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB7 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9yIChTRUNULCAweDAyLCBTRUNUKQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgIE9yIChTRUNULCBTRVRQIChQSU8wLCBXNTMwLCBXNjQwKSwgU0VDVCkNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICBJZiAoQW5kIChGTEFHLCAweDAxKSkNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9yIChTWU5DLCAw eDA0LCBTWU5DKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoU0RNQSAo RE1BMCksIFNEVDIpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElmIChMTGVzcyAo RE1BMCwgMHgxRSkpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9yIChJQ1IzLCAweDA0LCBJQ1IzKQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgSWYgKExMZXNzIChETUEwLCAweDNDKSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT3IgKElDUjAsIDB4 MDQsIElDUjApDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBJZiAoQW5kIChXOTMwLCAweDIwMDApKQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBPciAoSUNSMSwgMHgwNCwgSUNSMSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAg ICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICAgICAgSWYgKExFcXVhbCAoU2l6ZU9mIChBcmcy KSwgMHgwMjAwKSkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICBBbmQgKFNFQ1QsIDB4M0YwRiwgU0VDVCkNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBTdG9yZSAoMHgwMCwgU1NJVCkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBB bmQgKFNZTkMsIDB4MDcsIFNZTkMpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUg KDB4MDAsIFNEVDMpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgQW5kIChJQ1IwLCAweDA3 LCBJQ1IwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIEFuZCAoSUNSMSwgMHgwNywgSUNS MSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBBbmQgKElDUjMsIDB4MDcsIElDUjMpDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgQW5kIChJQ1I1LCAweDA3LCBJQ1I1KQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZVdvcmRGaWVsZCAoQXJnMiwgMHg2MiwgVzQ5MSkN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBDcmVhdGVXb3JkRmllbGQgKEFyZzIsIDB4NkEs IFc1MzEpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgQ3JlYXRlV29yZEZpZWxkIChBcmcy LCAweDdFLCBXNjMxKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0ZVdvcmRGaWVs ZCAoQXJnMiwgMHg4MCwgVzY0MSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBDcmVhdGVX b3JkRmllbGQgKEFyZzIsIDB4QjAsIFc4ODEpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg Q3JlYXRlV29yZEZpZWxkIChBcmcyLCAweEJBLCBXOTMxKQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIE9yIChTRUNULCAweDgwNDAsIFNFQ1QpDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgSWYgKExBbmQgKEFuZCAoRkxBRywgMHgwOCksIEFuZCAoVzQ5MSwgMHgwODAwKSkpDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBPciAoU0VDVCwgMHgyMCwgU0VDVCkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB9DQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJZiAoQW5kIChGTEFHLCAweDEwKSkNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IE9yIChTRUNULCAweDQwMDAsIFNFQ1QpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IElmIChMR3JlYXRlciAoUElPMSwgMHhGMCkpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9yIChTRUNULCAweDgw LCBTRUNUKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEVsc2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT3IgKFNFQ1QsIDB4MTAsIFNF Q1QpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoU0VUVCAoUElP MSwgVzUzMSwgVzY0MSksIFNTSVQpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICBJZiAoQW5kIChGTEFHLCAweDA0KSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB7 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE9yIChTWU5DLCAweDA4LCBTWU5DKQ0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoU0RNQSAoRE1BMSksIFNEVDMp DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElmIChMTGVzcyAoRE1BMCwgMHgxRSkp DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIE9yIChJQ1IzLCAweDA4LCBJQ1IzKQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSWYgKExM ZXNzIChETUEwLCAweDNDKSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgew0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT3IgKElDUjAsIDB4MDgsIElDUjApDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBJZiAoQW5kIChXOTMxLCAweDIwMDApKQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPciAoSUNS MSwgMHgwOCwgSUNSMSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAg ICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgIERldmljZSAoU19EMCkNCiAg ICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgTmFtZSAoX0FEUiwg MHgwMCkNCiAgICAgICAgICAgICAgICAgICAgICAgIE1ldGhvZCAoX0dURiwgMCwgTm90U2VyaWFs aXplZCkNCiAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICBOYW1lIChTSUIwLCBCdWZmZXIgKDB4MEUpDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAweDAzLCAweDAwLCAweDAwLCAw eDAwLCAweDAwLCAweEEwLCAweEVGLCAweDAzLCANCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgMHgwMCwgMHgwMCwgMHgwMCwgMHgwMCwgMHhBMCwgMHhFRg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgIH0pDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgQ3JlYXRlQnl0ZUZp ZWxkIChTSUIwLCAweDAxLCBQTUQwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIENyZWF0 ZUJ5dGVGaWVsZCAoU0lCMCwgMHgwOCwgRE1EMCkNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBJZiAoQW5kIChTRUNULCAweDAyKSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB7DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElmIChMRXF1YWwgKEFuZCAoU0VDVCwgMHgw OSksIDB4MDgpKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoMHgwOCwgUE1EMCkNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBF bHNlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFN0b3JlICgweDBBLCBQTUQwKQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgU2hpZnRSaWdodCAoQW5kIChTRUNULCAweDAzMDApLCAweDA4LCBM b2NhbDApDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTaGlmdFJpZ2h0IChB bmQgKFNFQ1QsIDB4MzAwMCksIDB4MEMsIExvY2FsMSkNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEFkZCAoTG9jYWwwLCBMb2NhbDEsIExvY2FsMikNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIElmIChMRXF1YWwgKDB4MDMsIExvY2FsMikpDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgU3RvcmUgKDB4MEIsIFBNRDApDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIElm IChMRXF1YWwgKDB4MDUsIExvY2FsMikpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKDB4 MEMsIFBNRDApDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB9DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB9 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgRWxzZQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3RvcmUgKDB4MDEsIFBN RDApDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgSWYgKEFuZCAoU1lOQywgMHgwNCkpDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoT3IgKFNEVDIsIDB4 NDApLCBETUQwKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJZiAoQW5kIChJQ1Ix LCAweDA0KSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgSWYgKEFuZCAoSUNSMCwgMHgwNCkpDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQWRkIChETUQwLCAweDAyLCBETUQwKQ0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBJ ZiAoQW5kIChJQ1IzLCAweDA0KSkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdG9yZSAoMHg0NSwg RE1EMCkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIH0NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBFbHNlDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPciAoU3VidHJhY3QgKEFuZCAo UE1EMCwgMHgwNyksIDB4MDIpLCAweDIwLCBETUQwKQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJldHVybiAoU0lCMCkNCiAgICAg ICAgICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAg ICAgICAgICAgIE1ldGhvZCAoX1BTMCwgMCwgTm90U2VyaWFsaXplZCkNCiAgICAgICAgICAgICAg ICAgICAgew0KICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgTWV0 aG9kIChfUFMzLCAwLCBOb3RTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAg ICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBN ZXRob2QgKEdFVFAsIDEsIFNlcmlhbGl6ZWQpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAg ICAgICAgICAgICBJZiAoTEVxdWFsIChBbmQgKEFyZzAsIDB4MDkpLCAweDAwKSkNCiAgICAgICAg ICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgUmV0dXJuICgweEZGRkZGRkZG KQ0KICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgSWYgKExFcXVh bCAoQW5kIChBcmcwLCAweDA5KSwgMHgwOCkpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAg ICAgICAgICAgICAgICAgICAgIFJldHVybiAoMHgwMzg0KQ0KICAgICAgICAgICAgICAgICAgICB9 DQoNCiAgICAgICAgICAgICAgICAgICAgU2hpZnRSaWdodCAoQW5kIChBcmcwLCAweDAzMDApLCAw eDA4LCBMb2NhbDApDQogICAgICAgICAgICAgICAgICAgIFNoaWZ0UmlnaHQgKEFuZCAoQXJnMCwg MHgzMDAwKSwgMHgwQywgTG9jYWwxKQ0KICAgICAgICAgICAgICAgICAgICBSZXR1cm4gKE11bHRp cGx5ICgweDFFLCBTdWJ0cmFjdCAoMHgwOSwgQWRkIChMb2NhbDAsIExvY2FsMSkpKSkNCiAgICAg ICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICBNZXRob2QgKEdETUEsIDUsIFNlcmlhbGl6 ZWQpDQogICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICBJZiAoQXJnMCkNCiAg ICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgSWYgKExBbmQgKEFy ZzEsIEFyZzQpKQ0KICAgICAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFJldHVybiAoMHgxNCkNCiAgICAgICAgICAgICAgICAgICAgICAgIH0NCg0KICAg ICAgICAgICAgICAgICAgICAgICAgSWYgKExBbmQgKEFyZzIsIEFyZzQpKQ0KICAgICAgICAgICAg ICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJldHVybiAoTXVsdGlw bHkgKFN1YnRyYWN0ICgweDA0LCBBcmczKSwgMHgwRikpDQogICAgICAgICAgICAgICAgICAgICAg ICB9DQoNCiAgICAgICAgICAgICAgICAgICAgICAgIFJldHVybiAoTXVsdGlwbHkgKFN1YnRyYWN0 ICgweDA0LCBBcmczKSwgMHgxRSkpDQogICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAg ICAgICAgICAgICBSZXR1cm4gKDB4RkZGRkZGRkYpDQogICAgICAgICAgICAgICAgfQ0KDQogICAg ICAgICAgICAgICAgTWV0aG9kIChHRVRULCAxLCBTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAg IHsNCiAgICAgICAgICAgICAgICAgICAgUmV0dXJuIChNdWx0aXBseSAoMHgxRSwgU3VidHJhY3Qg KDB4MDksIEFkZCAoQW5kIChTaGlmdFJpZ2h0IChBcmcwLCAweDAyKSwgMHgwMyksIEFuZCAoQXJn MCwgMHgwMykpKSkpDQogICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgTWV0aG9k IChHRVRGLCAzLCBTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAg ICAgICAgTmFtZSAoVE1QRiwgMHgwMCkNCiAgICAgICAgICAgICAgICAgICAgSWYgKEFyZzApDQog ICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIE9yIChUTVBGLCAw eDAxLCBUTVBGKQ0KICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAg SWYgKEFuZCAoQXJnMiwgMHgwMikpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAg ICAgICAgICAgICAgIE9yIChUTVBGLCAweDAyLCBUTVBGKQ0KICAgICAgICAgICAgICAgICAgICB9 DQoNCiAgICAgICAgICAgICAgICAgICAgSWYgKEFyZzEpDQogICAgICAgICAgICAgICAgICAgIHsN CiAgICAgICAgICAgICAgICAgICAgICAgIE9yIChUTVBGLCAweDA0LCBUTVBGKQ0KICAgICAgICAg ICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgSWYgKEFuZCAoQXJnMiwgMHgyMCkp DQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIE9yIChUTVBG LCAweDA4LCBUTVBGKQ0KICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAg ICAgSWYgKEFuZCAoQXJnMiwgMHg0MDAwKSkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAg ICAgICAgICAgICAgICAgICAgT3IgKFRNUEYsIDB4MTAsIFRNUEYpDQogICAgICAgICAgICAgICAg ICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICBSZXR1cm4gKFRNUEYpDQogICAgICAgICAgICAg ICAgfQ0KDQogICAgICAgICAgICAgICAgTWV0aG9kIChTRVRQLCAzLCBTZXJpYWxpemVkKQ0KICAg ICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgSWYgKExHcmVhdGVyIChBcmcwLCAw eEYwKSkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgUmV0 dXJuICgweDA4KQ0KICAgICAgICAgICAgICAgICAgICB9DQogICAgICAgICAgICAgICAgICAgIEVs c2UNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgSWYgKEFu ZCAoQXJnMSwgMHgwMikpDQogICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgSWYgKExBbmQgKExOb3QgKExHcmVhdGVyIChBcmcwLCAweDc4KSksIEFu ZCAoQXJnMiwgMHgwMikpKQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUmV0dXJuICgweDIzMDEpDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgSWYgKExBbmQgKExO b3QgKExHcmVhdGVyIChBcmcwLCAweEI0KSksIEFuZCAoQXJnMiwgMHgwMSkpKQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUmV0 dXJuICgweDIxMDEpDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAg ICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgICAgICBSZXR1cm4gKDB4MTAwMSkN CiAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAg ICAgIE1ldGhvZCAoU0RNQSwgMSwgU2VyaWFsaXplZCkNCiAgICAgICAgICAgICAgICB7DQogICAg ICAgICAgICAgICAgICAgIElmIChMTm90IChMR3JlYXRlciAoQXJnMCwgMHgxNCkpKQ0KICAgICAg ICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBSZXR1cm4gKDB4MDEpDQog ICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgICAgICBJZiAoTE5vdCAoTEdy ZWF0ZXIgKEFyZzAsIDB4MUUpKSkNCiAgICAgICAgICAgICAgICAgICAgew0KICAgICAgICAgICAg ICAgICAgICAgICAgUmV0dXJuICgweDAyKQ0KICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAg ICAgICAgICAgICAgICAgSWYgKExOb3QgKExHcmVhdGVyIChBcmcwLCAweDJEKSkpDQogICAgICAg ICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAgICAgIFJldHVybiAoMHgwMSkNCiAg ICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgICAgIElmIChMTm90IChMR3Jl YXRlciAoQXJnMCwgMHgzQykpKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAg ICAgICAgICAgICBSZXR1cm4gKDB4MDIpDQogICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAg ICAgICAgICAgICAgICBJZiAoTE5vdCAoTEdyZWF0ZXIgKEFyZzAsIDB4NUEpKSkNCiAgICAgICAg ICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgICAgICAgICAgUmV0dXJuICgweDAxKQ0KICAg ICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgUmV0dXJuICgweDAwKQ0K ICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgICAgIE1ldGhvZCAoU0VUVCwgMywgU2Vy aWFsaXplZCkNCiAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgIElmIChBbmQg KEFyZzEsIDB4MDIpKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAg ICAgICBJZiAoTEFuZCAoTE5vdCAoTEdyZWF0ZXIgKEFyZzAsIDB4NzgpKSwgQW5kIChBcmcyLCAw eDAyKSkpDQogICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgUmV0dXJuICgweDBCKQ0KICAgICAgICAgICAgICAgICAgICAgICAgfQ0KDQogICAgICAg ICAgICAgICAgICAgICAgICBJZiAoTEFuZCAoTE5vdCAoTEdyZWF0ZXIgKEFyZzAsIDB4QjQpKSwg QW5kIChBcmcyLCAweDAxKSkpDQogICAgICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgUmV0dXJuICgweDA5KQ0KICAgICAgICAgICAgICAgICAgICAgICAg fQ0KICAgICAgICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgUmV0dXJuICgw eDA0KQ0KICAgICAgICAgICAgICAgIH0NCiAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgRGV2 aWNlIChTQlVTKQ0KICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgIE5hbWUgKF9BRFIsIDB4 MDAxRjAwMDMpDQogICAgICAgICAgICAgICAgT3BlcmF0aW9uUmVnaW9uIChTQlVTLCBTeXN0ZW1J TywgMHgxODgwLCAweDEwKQ0KICAgICAgICAgICAgICAgIEZpZWxkIChTQlVTLCBCeXRlQWNjLCBO b0xvY2ssIFByZXNlcnZlKQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAgICAg SFNUUywgICA4LCANCiAgICAgICAgICAgICAgICAgICAgT2Zmc2V0ICgweDAyKSwgDQogICAgICAg ICAgICAgICAgICAgIEhDT04sICAgOCwgDQogICAgICAgICAgICAgICAgICAgIEhDT00sICAgOCwg DQogICAgICAgICAgICAgICAgICAgIFRYU0EsICAgOCwgDQogICAgICAgICAgICAgICAgICAgIERB VDAsICAgOCwgDQogICAgICAgICAgICAgICAgICAgIERBVDEsICAgOCwgDQogICAgICAgICAgICAg ICAgICAgIEJEQlIsICAgOCwgDQogICAgICAgICAgICAgICAgICAgIE9mZnNldCAoMHgwOSksIA0K ICAgICAgICAgICAgICAgICAgICBSWFNBLCAgIDgsIA0KICAgICAgICAgICAgICAgICAgICBTREFU LCAgIDE2DQogICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgTWV0aG9kIChTQldC LCAzLCBOb3RTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAg ICAgU3RvcmUgKDB4MEEsIExvY2FsMCkNCiAgICAgICAgICAgICAgICAgICAgV2hpbGUgKExBbmQg KEFuZCAoSFNUUywgMHgwMSksIExvY2FsMCkpDQogICAgICAgICAgICAgICAgICAgIHsNCiAgICAg ICAgICAgICAgICAgICAgICAgIFNsZWVwICgweDY0KQ0KICAgICAgICAgICAgICAgICAgICAgICAg RGVjcmVtZW50IChMb2NhbDApDQogICAgICAgICAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAg ICAgICAgICBTdG9yZSAoMHhGRiwgSFNUUykNCiAgICAgICAgICAgICAgICAgICAgU3RvcmUgKEFy ZzAsIFRYU0EpDQogICAgICAgICAgICAgICAgICAgIFN0b3JlIChBcmcxLCBIQ09NKQ0KICAgICAg ICAgICAgICAgICAgICBTdG9yZSAoQXJnMiwgREFUMCkNCiAgICAgICAgICAgICAgICAgICAgU3Rv cmUgKDB4MDAsIERBVDEpDQogICAgICAgICAgICAgICAgICAgIFN0b3JlICgweDA4LCBIQ09OKQ0K ICAgICAgICAgICAgICAgICAgICBTbGVlcCAoMHg2NCkNCiAgICAgICAgICAgICAgICAgICAgU3Rv cmUgKDB4NDgsIEhDT04pDQogICAgICAgICAgICAgICAgfQ0KDQogICAgICAgICAgICAgICAgTWV0 aG9kIChTQlJCLCAyLCBOb3RTZXJpYWxpemVkKQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAg ICAgICAgICAgICAgU3RvcmUgKDB4MEEsIExvY2FsMCkNCiAgICAgICAgICAgICAgICAgICAgV2hp bGUgKExBbmQgKEFuZCAoSFNUUywgMHgwMSksIExvY2FsMCkpDQogICAgICAgICAgICAgICAgICAg IHsNCiAgICAgICAgICAgICAgICAgICAgICAgIFNsZWVwICgweDY0KQ0KICAgICAgICAgICAgICAg ICAgICAgICAgRGVjcmVtZW50IChMb2NhbDApDQogICAgICAgICAgICAgICAgICAgIH0NCg0KICAg ICAgICAgICAgICAgICAgICBTdG9yZSAoMHhGRiwgSFNUUykNCiAgICAgICAgICAgICAgICAgICAg U3RvcmUgKE9yIChBcmcwLCAweDAxKSwgVFhTQSkNCiAgICAgICAgICAgICAgICAgICAgU3RvcmUg KEFyZzEsIEhDT00pDQogICAgICAgICAgICAgICAgICAgIFN0b3JlICgweDA4LCBIQ09OKQ0KICAg ICAgICAgICAgICAgICAgICBTbGVlcCAoMHg2NCkNCiAgICAgICAgICAgICAgICAgICAgU3RvcmUg KDB4NDgsIEhDT04pDQogICAgICAgICAgICAgICAgICAgIFN0b3JlICgweDBBLCBMb2NhbDApDQog ICAgICAgICAgICAgICAgICAgIFdoaWxlIChMQW5kIChBbmQgKEhTVFMsIDB4MDIpLCBMb2NhbDAp KQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgICAgICAgICBTbGVlcCAo MHg2NCkNCiAgICAgICAgICAgICAgICAgICAgICAgIERlY3JlbWVudCAoTG9jYWwwKQ0KICAgICAg ICAgICAgICAgICAgICB9DQoNCiAgICAgICAgICAgICAgICAgICAgUmV0dXJuIChEQVQwKQ0KICAg ICAgICAgICAgICAgIH0NCiAgICAgICAgICAgIH0NCg0KICAgICAgICAgICAgRGV2aWNlIChBVUQw KQ0KICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgIE5hbWUgKF9BRFIsIDB4MDAxRjAwMDUp DQogICAgICAgICAgICB9DQoNCiAgICAgICAgICAgIERldmljZSAoTU9ETSkNCiAgICAgICAgICAg IHsNCiAgICAgICAgICAgICAgICBOYW1lIChfQURSLCAweDAwMUYwMDA2KQ0KICAgICAgICAgICAg ICAgIE5hbWUgKF9QUlcsIFBhY2thZ2UgKDB4MDIpDQogICAgICAgICAgICAgICAgew0KICAgICAg ICAgICAgICAgICAgICAweDA1LCANCiAgICAgICAgICAgICAgICAgICAgMHgwMw0KICAgICAgICAg ICAgICAgIH0pDQogICAgICAgICAgICB9DQogICAgICAgIH0NCiAgICB9DQoNCiAgICBTY29wZSAo X1BSLkNQVTApDQogICAgew0KICAgICAgICBNZXRob2QgKF9QUEMsIDAsIE5vdFNlcmlhbGl6ZWQp DQogICAgICAgIHsNCiAgICAgICAgICAgIElmIChcX1NCLlBDSTAuTFBDQi5FQzAuRUNPSykNCiAg ICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICBTdG9yZSAoXF9TQi5QQ0kwLkxQQ0IuRUMwLkFD QVQsIExvY2FsMCkNCiAgICAgICAgICAgIH0NCiAgICAgICAgICAgIEVsc2UNCiAgICAgICAgICAg IHsNCiAgICAgICAgICAgICAgICBBbmQgKFxQSFNEICgweEQ0LCAweDgwKSwgMHgwNDAwLCBMb2Nh bDApDQogICAgICAgICAgICB9DQoNCiAgICAgICAgICAgIElmIChMb2NhbDApDQogICAgICAgICAg ICB7DQogICAgICAgICAgICAgICAgUmV0dXJuIChQU0FDKQ0KICAgICAgICAgICAgfQ0KICAgICAg ICAgICAgRWxzZQ0KICAgICAgICAgICAgew0KICAgICAgICAgICAgICAgIFJldHVybiAoUFNEQykN CiAgICAgICAgICAgIH0NCiAgICAgICAgfQ0KDQogICAgICAgIE5hbWUgKFBEQzAsIDB4RjAwMDAw MDApDQogICAgICAgIE1ldGhvZCAoX1BEQywgMSwgTm90U2VyaWFsaXplZCkNCiAgICAgICAgew0K ICAgICAgICAgICAgQ3JlYXRlRFdvcmRGaWVsZCAoQXJnMCwgMHgwOCwgQ0FQMCkNCiAgICAgICAg ICAgIFN0b3JlIChDQVAwLCBQREMwKQ0KICAgICAgICB9DQoNCiAgICAgICAgTWV0aG9kIChfUENU LCAwLCBOb3RTZXJpYWxpemVkKQ0KICAgICAgICB7DQogICAgICAgICAgICBJZiAoTEVxdWFsIChB bmQgKFBEQzAsIE9uZSksIE9uZSkpDQogICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgUmV0 dXJuIChQYWNrYWdlICgweDAyKQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAg ICAgUmVzb3VyY2VUZW1wbGF0ZSAoKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAg ICAgICAgICAgICAgICBSZWdpc3RlciAoRkZpeGVkSFcsIDB4MDAsIDB4MDAsIDB4MDAwMDAwMDAw MDAwMDAwMCkNCiAgICAgICAgICAgICAgICAgICAgfSwgDQoNCiAgICAgICAgICAgICAgICAgICAg UmVzb3VyY2VUZW1wbGF0ZSAoKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAgICAg ICAgICAgICAgICBSZWdpc3RlciAoRkZpeGVkSFcsIDB4MDAsIDB4MDAsIDB4MDAwMDAwMDAwMDAw MDAwMCkNCiAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgIH0pDQogICAgICAg ICAgICB9DQogICAgICAgICAgICBFbHNlDQogICAgICAgICAgICB7DQogICAgICAgICAgICAgICAg UmV0dXJuIChQYWNrYWdlICgweDAyKQ0KICAgICAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAg ICAgICAgUmVzb3VyY2VUZW1wbGF0ZSAoKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAg ICAgICAgICAgICAgICAgICBSZWdpc3RlciAoU3lzdGVtSU8sIDB4MTAsIDB4MDAsIDB4MDAwMDAw MDAwMDAwMDBCMikNCiAgICAgICAgICAgICAgICAgICAgfSwgDQoNCiAgICAgICAgICAgICAgICAg ICAgUmVzb3VyY2VUZW1wbGF0ZSAoKQ0KICAgICAgICAgICAgICAgICAgICB7DQogICAgICAgICAg ICAgICAgICAgICAgICBSZWdpc3RlciAoU3lzdGVtSU8sIDB4MDgsIDB4MDAsIDB4MDAwMDAwMDAw MDAwMDBCMykNCiAgICAgICAgICAgICAgICAgICAgfQ0KICAgICAgICAgICAgICAgIH0pDQogICAg ICAgICAgICB9DQogICAgICAgIH0NCg0KICAgICAgICBNZXRob2QgKF9QU1MsIDAsIE5vdFNlcmlh bGl6ZWQpDQogICAgICAgIHsNCiAgICAgICAgICAgIElmIChMRXF1YWwgKEFuZCAoUERDMCwgT25l KSwgT25lKSkNCiAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICBSZXR1cm4gKE5QU1MpDQog ICAgICAgICAgICB9DQogICAgICAgICAgICBFbHNlDQogICAgICAgICAgICB7DQogICAgICAgICAg ICAgICAgUmV0dXJuIChTUFNTKQ0KICAgICAgICAgICAgfQ0KICAgICAgICB9DQoNCiAgICAgICAg TmFtZSAoTlBTUywgUGFja2FnZSAoMHgwNikNCiAgICAgICAgew0KICAgICAgICAgICAgUGFja2Fn ZSAoMHgwNikNCiAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAweDAwMDAwNkE0LCANCiAg ICAgICAgICAgICAgICAweDAwMDA1RkI0LCANCiAgICAgICAgICAgICAgICAweDAwMDAwMDBBLCAN CiAgICAgICAgICAgICAgICAweDAwMDAwMDBBLCANCiAgICAgICAgICAgICAgICAweDAwMDAxMTMx LCANCiAgICAgICAgICAgICAgICAweDAwMDAxMTMxDQogICAgICAgICAgICB9LCANCg0KICAgICAg ICAgICAgUGFja2FnZSAoMHgwNikNCiAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAweDAw MDAwNTc4LCANCiAgICAgICAgICAgICAgICAweDAwMDA0QzJDLCANCiAgICAgICAgICAgICAgICAw eDAwMDAwMDBBLCANCiAgICAgICAgICAgICAgICAweDAwMDAwMDBBLCANCiAgICAgICAgICAgICAg ICAweDAwMDAwRTI2LCANCiAgICAgICAgICAgICAgICAweDAwMDAwRTI2DQogICAgICAgICAgICB9 LCANCg0KICAgICAgICAgICAgUGFja2FnZSAoMHgwNikNCiAgICAgICAgICAgIHsNCiAgICAgICAg ICAgICAgICAweDAwMDAwNEIwLCANCiAgICAgICAgICAgICAgICAweDAwMDAzRTgwLCANCiAgICAg ICAgICAgICAgICAweDAwMDAwMDBBLCANCiAgICAgICAgICAgICAgICAweDAwMDAwMDBBLCANCiAg ICAgICAgICAgICAgICAweDAwMDAwQzIxLCANCiAgICAgICAgICAgICAgICAweDAwMDAwQzIxDQog ICAgICAgICAgICB9LCANCg0KICAgICAgICAgICAgUGFja2FnZSAoMHgwNikNCiAgICAgICAgICAg IHsNCiAgICAgICAgICAgICAgICAweDAwMDAwM0U4LCANCiAgICAgICAgICAgICAgICAweDAwMDAz MkM4LCANCiAgICAgICAgICAgICAgICAweDAwMDAwMDBBLCANCiAgICAgICAgICAgICAgICAweDAw MDAwMDBBLCANCiAgICAgICAgICAgICAgICAweDAwMDAwQTFBLCANCiAgICAgICAgICAgICAgICAw eDAwMDAwQTFBDQogICAgICAgICAgICB9LCANCg0KICAgICAgICAgICAgUGFja2FnZSAoMHgwNikN CiAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAweDAwMDAwMzIwLCANCiAgICAgICAgICAg ICAgICAweDAwMDAyNTFDLCANCiAgICAgICAgICAgICAgICAweDAwMDAwMDBBLCANCiAgICAgICAg ICAgICAgICAweDAwMDAwMDBBLCANCiAgICAgICAgICAgICAgICAweDAwMDAwODEzLCANCiAgICAg ICAgICAgICAgICAweDAwMDAwODEzDQogICAgICAgICAgICB9LCANCg0KICAgICAgICAgICAgUGFj a2FnZSAoMHgwNikNCiAgICAgICAgICAgIHsNCiAgICAgICAgICAgICAgICAweDAwMDAwMjU4LCAN CiAgICAgICAgICAgICAgICAweDAwMDAxNzcwLCANCiAgICAgICAgICAgICAgICAweDAwMDAwMDBB LCANCiAgICAgICAgICAgICAgICAweDAwMDAwMDBBLCANCiAgICAgICAgICAgICAgICAweDAwMDAw NjEwLCANCiAgICAgICAgICAgICAgICAweDAwMDAwNjEwDQogICAgICAgICAgICB9DQogICAgICAg IH0pDQogICAgICAgIE5hbWUgKFNQU1MsIFBhY2thZ2UgKDB4MDYpDQogICAgICAgIHsNCiAgICAg ICAgICAgIFBhY2thZ2UgKDB4MDYpDQogICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgMHgw MDAwMDZBNCwgDQogICAgICAgICAgICAgICAgMHgwMDAwNUZCNCwgDQogICAgICAgICAgICAgICAg MHgwMDAwMDA2NCwgDQogICAgICAgICAgICAgICAgMHgwMDAwMDA2RSwgDQogICAgICAgICAgICAg ICAgMHgwMDAwMDA4MywgDQogICAgICAgICAgICAgICAgMHgwMDAwMDAwMA0KICAgICAgICAgICAg fSwgDQoNCiAgICAgICAgICAgIFBhY2thZ2UgKDB4MDYpDQogICAgICAgICAgICB7DQogICAgICAg ICAgICAgICAgMHgwMDAwMDU3OCwgDQogICAgICAgICAgICAgICAgMHgwMDAwNEMyQywgDQogICAg ICAgICAgICAgICAgMHgwMDAwMDA2NCwgDQogICAgICAgICAgICAgICAgMHgwMDAwMDA2RSwgDQog ICAgICAgICAgICAgICAgMHgwMDAwMDE4MywgDQogICAgICAgICAgICAgICAgMHgwMDAwMDAwMQ0K ICAgICAgICAgICAgfSwgDQoNCiAgICAgICAgICAgIFBhY2thZ2UgKDB4MDYpDQogICAgICAgICAg ICB7DQogICAgICAgICAgICAgICAgMHgwMDAwMDRCMCwgDQogICAgICAgICAgICAgICAgMHgwMDAw M0U4MCwgDQogICAgICAgICAgICAgICAgMHgwMDAwMDA2NCwgDQogICAgICAgICAgICAgICAgMHgw MDAwMDA2RSwgDQogICAgICAgICAgICAgICAgMHgwMDAwMDI4MywgDQogICAgICAgICAgICAgICAg MHgwMDAwMDAwMg0KICAgICAgICAgICAgfSwgDQoNCiAgICAgICAgICAgIFBhY2thZ2UgKDB4MDYp DQogICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgMHgwMDAwMDNFOCwgDQogICAgICAgICAg ICAgICAgMHgwMDAwMzJDOCwgDQogICAgICAgICAgICAgICAgMHgwMDAwMDA2NCwgDQogICAgICAg ICAgICAgICAgMHgwMDAwMDA2RSwgDQogICAgICAgICAgICAgICAgMHgwMDAwMDM4MywgDQogICAg ICAgICAgICAgICAgMHgwMDAwMDAwMw0KICAgICAgICAgICAgfSwgDQoNCiAgICAgICAgICAgIFBh Y2thZ2UgKDB4MDYpDQogICAgICAgICAgICB7DQogICAgICAgICAgICAgICAgMHgwMDAwMDMyMCwg DQogICAgICAgICAgICAgICAgMHgwMDAwMjUxQywgDQogICAgICAgICAgICAgICAgMHgwMDAwMDA2 NCwgDQogICAgICAgICAgICAgICAgMHgwMDAwMDA2RSwgDQogICAgICAgICAgICAgICAgMHgwMDAw MDQ4MywgDQogICAgICAgICAgICAgICAgMHgwMDAwMDAwNA0KICAgICAgICAgICAgfSwgDQoNCiAg ICAgICAgICAgIFBhY2thZ2UgKDB4MDYpDQogICAgICAgICAgICB7DQogICAgICAgICAgICAgICAg MHgwMDAwMDI1OCwgDQogICAgICAgICAgICAgICAgMHgwMDAwMTc3MCwgDQogICAgICAgICAgICAg ICAgMHgwMDAwMDA2NCwgDQogICAgICAgICAgICAgICAgMHgwMDAwMDA2RSwgDQogICAgICAgICAg ICAgICAgMHgwMDAwMDU4MywgDQogICAgICAgICAgICAgICAgMHgwMDAwMDAwNQ0KICAgICAgICAg ICAgfQ0KICAgICAgICB9KQ0KICAgIH0NCn0NCg0K --=-FZrzlYyzm566zgo9aokI Content-Disposition: attachment; filename=devinfo-v.txt Content-Type: text/plain; name=devinfo-v.txt; charset=KOI8-R Content-Transfer-Encoding: base64 bmV4dXMwDQogIGFjcGkwDQogICAgY3B1MCBwbnBpbmZvIF9ISUQ9bm9uZSBfVUlEPTAgYXQgaGFu ZGxlPVxfUFJfLkNQVTANCiAgICBhY3BpX3R6MCBwbnBpbmZvIF9ISUQ9bm9uZSBfVUlEPTAgYXQg aGFuZGxlPVxfVFpfLkFURjANCiAgICBhY3BpX2xpZDAgcG5waW5mbyBfSElEPVBOUDBDMEQgX1VJ RD0wIGF0IGhhbmRsZT1cX1NCXy5MSUQwDQogICAgYWNwaV9idXR0b24wIHBucGluZm8gX0hJRD1Q TlAwQzBDIF9VSUQ9MCBhdCBoYW5kbGU9XF9TQl8uUFdSQg0KICAgIHBjaWIwIHBucGluZm8gX0hJ RD1QTlAwQTAzIF9VSUQ9MCBhdCBoYW5kbGU9XF9TQl8uUENJMA0KICAgICAgcGNpMA0KICAgICAg ICBob3N0YjAgcG5waW5mbyB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDMzNDAgc3VidmVuZG9yPTB4 MTA0ZCBzdWJkZXZpY2U9MHg4MTQwIGNsYXNzPTB4MDYwMDAwIGF0IHNsb3Q9MCBmdW5jdGlvbj0w DQogICAgICAgIHBjaWIxIHBucGluZm8gdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgzMzQxIHN1YnZl bmRvcj0weDAwMDAgc3ViZGV2aWNlPTB4MDAwMCBjbGFzcz0weDA2MDQwMCBhdCBzbG90PTEgZnVu Y3Rpb249MCBoYW5kbGU9XF9TQl8uUENJMC5BR1BCDQogICAgICAgICAgcGNpMQ0KICAgICAgICAg ICAgdW5rbm93biBwbnBpbmZvIHZlbmRvcj0weDEwMDIgZGV2aWNlPTB4NGM1OSBzdWJ2ZW5kb3I9 MHgxMDRkIHN1YmRldmljZT0weDgxNDAgY2xhc3M9MHgwMzAwMDAgYXQgc2xvdD0wIGZ1bmN0aW9u PTAgaGFuZGxlPVxfU0JfLlBDSTAuQUdQQi5WSUQwDQogICAgICAgIHVoY2kwIHBucGluZm8gdmVu ZG9yPTB4ODA4NiBkZXZpY2U9MHgyNGMyIHN1YnZlbmRvcj0weDEwNGQgc3ViZGV2aWNlPTB4ODE0 MCBjbGFzcz0weDBjMDMwMCBhdCBzbG90PTI5IGZ1bmN0aW9uPTAgaGFuZGxlPVxfU0JfLlBDSTAu VVNCMA0KICAgICAgICAgIHVzYjANCiAgICAgICAgICAgIHVodWIwDQogICAgICAgIHVoY2kxIHBu cGluZm8gdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgyNGM0IHN1YnZlbmRvcj0weDEwNGQgc3ViZGV2 aWNlPTB4ODE0MCBjbGFzcz0weDBjMDMwMCBhdCBzbG90PTI5IGZ1bmN0aW9uPTEgaGFuZGxlPVxf U0JfLlBDSTAuVVNCMQ0KICAgICAgICAgIHVzYjENCiAgICAgICAgICAgIHVodWIxDQogICAgICAg ICAgICAgIHVodWIyIHBucGluZm8gdmVuZG9yPTB4MDQ1MSBwcm9kdWN0PTB4MTQ0NiBkZXZjbGFz cz0weDA5IGRldnN1YmNsYXNzPTB4MDAgc2VybnVtPSIiIGF0IHBvcnQ9MA0KICAgICAgICAgICAg ICAgIHVrYmQwIHBucGluZm8gdmVuZG9yPTB4MDQ2ZSBwcm9kdWN0PTB4Njc4MiBkZXZjbGFzcz0w eDAwIGRldnN1YmNsYXNzPTB4MDAgc2VybnVtPSIiIGludGNsYXNzPTB4MDMgaW50c3ViY2xhc3M9 MHgwMSBhdCBwb3J0PTIgaW50ZXJmYWNlPTANCiAgICAgICAgICAgICAgICB1bXMwIHBucGluZm8g dmVuZG9yPTB4MDQ2ZSBwcm9kdWN0PTB4Njc4MiBkZXZjbGFzcz0weDAwIGRldnN1YmNsYXNzPTB4 MDAgc2VybnVtPSIiIGludGNsYXNzPTB4MDMgaW50c3ViY2xhc3M9MHgwMSBhdCBwb3J0PTIgaW50 ZXJmYWNlPTENCiAgICAgICAgICAgICAgICB1bXMxIHBucGluZm8gdmVuZG9yPTB4MDQ1ZSBwcm9k dWN0PTB4MDAxZSBkZXZjbGFzcz0weDAwIGRldnN1YmNsYXNzPTB4MDAgc2VybnVtPSIiIGludGNs YXNzPTB4MDMgaW50c3ViY2xhc3M9MHgwMSBhdCBwb3J0PTMgaW50ZXJmYWNlPTANCiAgICAgICAg dWhjaTIgcG5waW5mbyB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDI0Yzcgc3VidmVuZG9yPTB4MTA0 ZCBzdWJkZXZpY2U9MHg4MTQwIGNsYXNzPTB4MGMwMzAwIGF0IHNsb3Q9MjkgZnVuY3Rpb249MiBo YW5kbGU9XF9TQl8uUENJMC5VU0IyDQogICAgICAgICAgdXNiMg0KICAgICAgICAgICAgdWh1YjMN CiAgICAgICAgZWhjaTAgcG5waW5mbyB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDI0Y2Qgc3VidmVu ZG9yPTB4MTA0ZCBzdWJkZXZpY2U9MHg4MTQwIGNsYXNzPTB4MGMwMzIwIGF0IHNsb3Q9MjkgZnVu Y3Rpb249NyBoYW5kbGU9XF9TQl8uUENJMC5VU0I3DQogICAgICAgICAgdXNiMw0KICAgICAgICAg ICAgdWh1YjQNCiAgICAgICAgICAgICAgdW1hc3MxIHBucGluZm8gdmVuZG9yPTB4MDU0YyBwcm9k dWN0PTB4MDE0ZCBkZXZjbGFzcz0weDAwIGRldnN1YmNsYXNzPTB4MDAgc2VybnVtPSIwMDUyNDQ5 Njc3NDkyMjI0IiBpbnRjbGFzcz0weDA4IGludHN1YmNsYXNzPTB4MDUgYXQgcG9ydD00IGludGVy ZmFjZT0wDQogICAgICAgIHBjaWIyIHBucGluZm8gdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgyNDQ4 IHN1YnZlbmRvcj0weDAwMDAgc3ViZGV2aWNlPTB4MDAwMCBjbGFzcz0weDA2MDQwMCBhdCBzbG90 PTMwIGZ1bmN0aW9uPTAgaGFuZGxlPVxfU0JfLlBDSTAuUENJQg0KICAgICAgICAgIHBjaTINCiAg ICAgICAgICAgIGNiYjAgcG5waW5mbyB2ZW5kb3I9MHgxMTgwIGRldmljZT0weDA0NzUgc3VidmVu ZG9yPTB4MTA0ZCBzdWJkZXZpY2U9MHg4MTQwIGNsYXNzPTB4MDYwNzAwIGF0IHNsb3Q9NSBmdW5j dGlvbj0wIGhhbmRsZT1cX1NCXy5QQ0kwLlBDSUIuQ1JEMA0KICAgICAgICAgICAgICBjYXJkYnVz MA0KICAgICAgICAgICAgICBwY2NhcmQwDQogICAgICAgICAgICBmd29oY2kwIHBucGluZm8gdmVu ZG9yPTB4MTE4MCBkZXZpY2U9MHgwNTUxIHN1YnZlbmRvcj0weDEwNGQgc3ViZGV2aWNlPTB4ODE0 MCBjbGFzcz0weDBjMDAxMCBhdCBzbG90PTUgZnVuY3Rpb249MSBoYW5kbGU9XF9TQl8uUENJMC5Q Q0lCLlNEOTQNCiAgICAgICAgICAgICAgZmlyZXdpcmUwDQogICAgICAgICAgICAgICAgc2JwMA0K ICAgICAgICAgICAgZnhwMCBwbnBpbmZvIHZlbmRvcj0weDgwODYgZGV2aWNlPTB4MTAzZCBzdWJ2 ZW5kb3I9MHgxMDRkIHN1YmRldmljZT0weDgxNDAgY2xhc3M9MHgwMjAwMDAgYXQgc2xvdD04IGZ1 bmN0aW9uPTAgaGFuZGxlPVxfU0JfLlBDSTAuUENJQi5MQU5DDQogICAgICAgICAgICAgIG1paWJ1 czANCiAgICAgICAgICAgICAgICBpbnBoeTANCiAgICAgICAgICAgIG5kaXMwIHBucGluZm8gdmVu ZG9yPTB4ODA4NiBkZXZpY2U9MHg0MjIwIHN1YnZlbmRvcj0weDgwODYgc3ViZGV2aWNlPTB4Mjc1 MSBjbGFzcz0weDAyODAwMCBhdCBzbG90PTExIGZ1bmN0aW9uPTAgaGFuZGxlPVxfU0JfLlBDSTAu UENJQi5XTEFODQogICAgICAgIGlzYWIwIHBucGluZm8gdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHgy NGNjIHN1YnZlbmRvcj0weDAwMDAgc3ViZGV2aWNlPTB4MDAwMCBjbGFzcz0weDA2MDEwMCBhdCBz bG90PTMxIGZ1bmN0aW9uPTAgaGFuZGxlPVxfU0JfLlBDSTAuTFBDQg0KICAgICAgICAgIGlzYTAN CiAgICAgICAgICAgIHBtdGltZXIwDQogICAgICAgICAgICBzYzANCiAgICAgICAgICAgIHZnYTAN CiAgICAgICAgICAgIGFkdjANCiAgICAgICAgICAgIGFoYTANCiAgICAgICAgICAgIGFpYzANCiAg ICAgICAgICAgIGJ0MA0KICAgICAgICAgICAgY3MwDQogICAgICAgICAgICBlZDANCiAgICAgICAg ICAgIGZkYzANCiAgICAgICAgICAgIGZlMA0KICAgICAgICAgICAgaWUwDQogICAgICAgICAgICBs bmMwDQogICAgICAgICAgICBwY2ljMA0KICAgICAgICAgICAgcGNpYzENCiAgICAgICAgICAgIHBw YzANCiAgICAgICAgICAgIHNpbzANCiAgICAgICAgICAgIHNpbzENCiAgICAgICAgICAgIHNpbzIN CiAgICAgICAgICAgIHNpbzMNCiAgICAgICAgICAgIHNuMA0KICAgICAgICAgICAgdnQwDQogICAg ICAgICAgICBvcm0wDQogICAgICAgIGF0YXBjaTAgcG5waW5mbyB2ZW5kb3I9MHg4MDg2IGRldmlj ZT0weDI0Y2Egc3VidmVuZG9yPTB4MTA0ZCBzdWJkZXZpY2U9MHg4MTQwIGNsYXNzPTB4MDEwMThh IGF0IHNsb3Q9MzEgZnVuY3Rpb249MSBoYW5kbGU9XF9TQl8uUENJMC5JREVDDQogICAgICAgICAg YXRhMA0KICAgICAgICAgIGF0YTENCiAgICAgICAgdW5rbm93biBwbnBpbmZvIHZlbmRvcj0weDgw ODYgZGV2aWNlPTB4MjRjMyBzdWJ2ZW5kb3I9MHgxMDRkIHN1YmRldmljZT0weDgxNDAgY2xhc3M9 MHgwYzA1MDAgYXQgc2xvdD0zMSBmdW5jdGlvbj0zIGhhbmRsZT1cX1NCXy5QQ0kwLlNCVVMNCiAg ICAgICAgcGNtMCBwbnBpbmZvIHZlbmRvcj0weDgwODYgZGV2aWNlPTB4MjRjNSBzdWJ2ZW5kb3I9 MHgxMDRkIHN1YmRldmljZT0weDgxNDAgY2xhc3M9MHgwNDAxMDAgYXQgc2xvdD0zMSBmdW5jdGlv bj01IGhhbmRsZT1cX1NCXy5QQ0kwLkFVRDANCiAgICAgICAgdW5rbm93biBwbnBpbmZvIHZlbmRv cj0weDgwODYgZGV2aWNlPTB4MjRjNiBzdWJ2ZW5kb3I9MHgxMDRkIHN1YmRldmljZT0weDgxNDAg Y2xhc3M9MHgwNzAzMDAgYXQgc2xvdD0zMSBmdW5jdGlvbj02IGhhbmRsZT1cX1NCXy5QQ0kwLk1P RE0NCiAgICB1bmtub3duIHBucGluZm8gX0hJRD1ub25lIF9VSUQ9MCBhdCBoYW5kbGU9XF9TQl8u UENJMC5BR1BCLlZJRDAuQ1JUXw0KICAgIHVua25vd24gcG5waW5mbyBfSElEPW5vbmUgX1VJRD0w IGF0IGhhbmRsZT1cX1NCXy5QQ0kwLkFHUEIuVklEMC5MQ0RfDQogICAgdW5rbm93biBwbnBpbmZv IF9ISUQ9bm9uZSBfVUlEPTAgYXQgaGFuZGxlPVxfU0JfLlBDSTAuQUdQQi5WSUQwLlRWX18NCiAg ICB1bmtub3duIHBucGluZm8gX0hJRD1QTlAwQzBGIF9VSUQ9MSBhdCBoYW5kbGU9XF9TQl8uUENJ MC5MUENCLkxOS0ENCiAgICB1bmtub3duIHBucGluZm8gX0hJRD1QTlAwQzBGIF9VSUQ9MiBhdCBo YW5kbGU9XF9TQl8uUENJMC5MUENCLkxOS0INCiAgICB1bmtub3duIHBucGluZm8gX0hJRD1QTlAw QzBGIF9VSUQ9MyBhdCBoYW5kbGU9XF9TQl8uUENJMC5MUENCLkxOS0MNCiAgICB1bmtub3duIHBu cGluZm8gX0hJRD1QTlAwQzBGIF9VSUQ9NCBhdCBoYW5kbGU9XF9TQl8uUENJMC5MUENCLkxOS0QN CiAgICB1bmtub3duIHBucGluZm8gX0hJRD1QTlAwQzBGIF9VSUQ9NSBhdCBoYW5kbGU9XF9TQl8u UENJMC5MUENCLkxOS0UNCiAgICB1bmtub3duIHBucGluZm8gX0hJRD1QTlAwQzBGIF9VSUQ9NiBh dCBoYW5kbGU9XF9TQl8uUENJMC5MUENCLkxOS0YNCiAgICB1bmtub3duIHBucGluZm8gX0hJRD1Q TlAwQzBGIF9VSUQ9NyBhdCBoYW5kbGU9XF9TQl8uUENJMC5MUENCLkxOS0cNCiAgICB1bmtub3du IHBucGluZm8gX0hJRD1QTlAwQzBGIF9VSUQ9OCBhdCBoYW5kbGU9XF9TQl8uUENJMC5MUENCLkxO S0gNCiAgICBhdHRpbWVyMCBwbnBpbmZvIF9ISUQ9UE5QMDEwMCBfVUlEPTAgYXQgaGFuZGxlPVxf U0JfLlBDSTAuTFBDQi5USU1SDQogICAgYXRwaWMwIHBucGluZm8gX0hJRD1QTlAwMDAwIF9VSUQ9 MCBhdCBoYW5kbGU9XF9TQl8uUENJMC5MUENCLklQSUMNCiAgICBhdHRpbWVyMSBwbnBpbmZvIF9I SUQ9UE5QMEIwMCBfVUlEPTAgYXQgaGFuZGxlPVxfU0JfLlBDSTAuTFBDQi5SVENfDQogICAgbnB4 aXNhMCBwbnBpbmZvIF9ISUQ9UE5QMEMwNCBfVUlEPTAgYXQgaGFuZGxlPVxfU0JfLlBDSTAuTFBD Qi5NQVRIDQogICAgYXRkbWEwIHBucGluZm8gX0hJRD1QTlAwMjAwIF9VSUQ9MCBhdCBoYW5kbGU9 XF9TQl8uUENJMC5MUENCLkRNQUMNCiAgICBhY3BpX3N5c3Jlc291cmNlMCBwbnBpbmZvIF9ISUQ9 UE5QMEMwMiBfVUlEPTAgYXQgaGFuZGxlPVxfU0JfLlBDSTAuTFBDQi5NQlJEDQogICAgdW5rbm93 biBwbnBpbmZvIF9ISUQ9SU5UMDgwMCBfVUlEPTAgYXQgaGFuZGxlPVxfU0JfLlBDSTAuTFBDQi5G V0hEDQogICAgYWNwaV9lYzAgcG5waW5mbyBfSElEPVBOUDBDMDkgX1VJRD0wIGF0IGhhbmRsZT1c X1NCXy5QQ0kwLkxQQ0IuRUMwXw0KICAgIGFjcGlfY21iYXQwIHBucGluZm8gX0hJRD1QTlAwQzBB IF9VSUQ9MSBhdCBoYW5kbGU9XF9TQl8uUENJMC5MUENCLkVDMF8uQkFUMQ0KICAgIGFjcGlfYWNh ZDAgcG5waW5mbyBfSElEPUFDUEkwMDAzIF9VSUQ9MCBhdCBoYW5kbGU9XF9TQl8uUENJMC5MUENC LkVDMF8uQUNBRA0KICAgIHVua25vd24gcG5waW5mbyBfSElEPVNOWTYwMDEgX1VJRD0wIGF0IGhh bmRsZT1cX1NCXy5QQ0kwLkxQQ0IuU1BJQw0KICAgIHVua25vd24gcG5waW5mbyBfSElEPVNOWTUw MDEgX1VJRD0wIGF0IGhhbmRsZT1cX1NCXy5QQ0kwLkxQQ0IuU05DXw0KICAgIGF0a2JkYzAgcG5w aW5mbyBfSElEPVBOUDAzMDMgX1VJRD0wIGF0IGhhbmRsZT1cX1NCXy5QQ0kwLkxQQ0IuUFMySw0K ICAgICAgYXRrYmQwDQogICAgICBwc20wDQogICAgcHNtY3BucDAgcG5waW5mbyBfSElEPVNOWTkw MDYgX1VJRD0wIGF0IGhhbmRsZT1cX1NCXy5QQ0kwLkxQQ0IuUFMyTQ0KICAgIHVua25vd24gcG5w aW5mbyBfSElEPW5vbmUgX1VJRD0wIGF0IGhhbmRsZT1cX1NCXy5QQ0kwLklERUMuUFJJRA0KICAg IHVua25vd24gcG5waW5mbyBfSElEPW5vbmUgX1VJRD0wIGF0IGhhbmRsZT1cX1NCXy5QQ0kwLklE RUMuUFJJRC5QX0QwDQogICAgdW5rbm93biBwbnBpbmZvIF9ISUQ9bm9uZSBfVUlEPTAgYXQgaGFu ZGxlPVxfU0JfLlBDSTAuSURFQy5TRUNEDQogICAgdW5rbm93biBwbnBpbmZvIF9ISUQ9bm9uZSBf VUlEPTAgYXQgaGFuZGxlPVxfU0JfLlBDSTAuSURFQy5TRUNELlNfRDANCiAgICBhY3BpX3RpbWVy MCBwbnBpbmZvIHVua25vd24gYXQgdW5rbm93bg0KICBsZWdhY3kwDQogIG5weDANCm== --=-FZrzlYyzm566zgo9aokI-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 11:41:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E724E16A4CE for ; Mon, 30 Aug 2004 11:41:46 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A32143D4C for ; Mon, 30 Aug 2004 11:41:46 +0000 (GMT) (envelope-from israel.herraiz@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so69333rnl for ; Mon, 30 Aug 2004 04:41:39 -0700 (PDT) Received: by 10.38.3.57 with SMTP id 57mr900526rnc; Mon, 30 Aug 2004 04:41:39 -0700 (PDT) Received: by 10.38.164.21 with HTTP; Mon, 30 Aug 2004 04:41:39 -0700 (PDT) Message-ID: <691d00b80408300441530656fc@mail.gmail.com> Date: Mon, 30 Aug 2004 13:41:39 +0200 From: Israel Herraiz To: freebsd-current@freebsd.org In-Reply-To: <007701c48e5b$530485f0$2508473e@sad.syncrontech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <007701c48e5b$530485f0$2508473e@sad.syncrontech.com> Subject: Re: ATA write-dma interrupt was seen but timeout fired LBA=53346288 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Israel Herraiz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 11:41:47 -0000 > >> ATA write-dma interrupt was seen but timeout fired LBA=53346288 > >> ATA write-dma interrupt was seen but timeout fired LBA=53346288 > >> ATA write-dma interrupt was seen but taskqueue stalled LBA=53346288 > > > > I updated my old Compaq 1500c from 4.10 to -current last week. > > I'm seeing similar messages after resume and the system hangs > > eventually. > > Otherwise the system seems to work ok. > > Updated to recent current (28.8) seems to fix this. I haven't seen any > ATA interrupt/timeout messages after update. I assume that these > changes are not on RELENG_5 branch yet, since it looked like it > still suffers from the problems above. With your current kernel sources, only change your /usr/src/sys/dev/ata/ata-queue.c with this [1], and recompile the kernel. I obtained the same messages in my laptop, and with this I fixed it. And I have also sound card support. [1]. http://gpinch.sourceforge.net/freebsd/ata-queue.c -- Israel Herraiz israel.herraiz@gmail.com Ya tengo blog, http://ixra.blogspot.com From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 12:10:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC57616A4CE for ; Mon, 30 Aug 2004 12:10:33 +0000 (GMT) Received: from smtp02.syd.iprimus.net.au (smtp02.syd.iprimus.net.au [210.50.76.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB2AC43D5E for ; Mon, 30 Aug 2004 12:10:33 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (211.26.245.99) by smtp02.syd.iprimus.net.au (7.0.028) id 412F6933000E22B1; Mon, 30 Aug 2004 22:10:32 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 9D836420D; Mon, 30 Aug 2004 22:10:24 +1000 (EST) Date: Mon, 30 Aug 2004 22:10:24 +1000 From: Tim Robbins To: Barry Bouwsma Message-ID: <20040830121024.GA57911@cat.robbins.dropbear.id.au> References: <200408291240.i7TCemk02197@Mail.NOSPAM.DynDNS.dK> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408291240.i7TCemk02197@Mail.NOSPAM.DynDNS.dK> User-Agent: Mutt/1.4.1i cc: current@freebsd.org Subject: Re: RELENG_5 buildworld failures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 12:10:34 -0000 On Sun, Aug 29, 2004 at 02:40:48PM +0200, Barry Bouwsma wrote: > [keep replies to the list and I'll catch up next time I'm online, thanks] > > The beer's on me if this hasn't been fixed -- source updated > late 22.Aug, haven't been online since then. I've just updated > my source but haven't done a build, and it looks like there's > still one problem that has not been addressed, just from reading > the latest updates. NOT verified yet. > > The following makefile seems to need attention to get a crossbuild > (from 4.x) to succeed -- failures in _depend step at first... > > --- /dist/src/FreeBSD5-src/source-hacks/sys/modules/linprocfs/Makefile-ORIG > Wed Nov 19 06:08:26 2003 > +++ /dist/src/FreeBSD5-src/source-hacks/sys/modules/linprocfs/Makefile-IS_THIS_S > TILL_NEEDED Wed Aug 25 07:45:41 2004 > @@ -6,4 +6,9 @@ > SRCS= vnode_if.h \ > linprocfs.c > +# XXX HACK from current > +opt_compat.h: > + touch ${.TARGET} > + > + > .include > > > Note that this is identical to HEAD -- well, kinda. I don't > see a MFC to RELENG_5 for this. Maybe it's been handled > somewhere else. If so, the beer's on me too. Patch above is > ugly and cut-n-pasted. See 1.12 of this file. This should be fixed in RELENG_5 with src/sys/modules/linprocfs/Makefie revision 1.11.4.1. Tim From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 12:12:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9054916A4CE for ; Mon, 30 Aug 2004 12:12:30 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0693E43D45 for ; Mon, 30 Aug 2004 12:12:30 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 77924 invoked from network); 30 Aug 2004 12:10:36 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Aug 2004 12:10:36 -0000 Message-ID: <413319AB.2020509@freebsd.org> Date: Mon, 30 Aug 2004 14:12:27 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Driver for VIA VT3119 Rhine-GE controller? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 12:12:30 -0000 Do we have a driver for the VIA VT3119 Rhine-GE controller? -- Andre From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 12:18:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7819716A4CE; Mon, 30 Aug 2004 12:18:21 +0000 (GMT) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4B0243D5F; Mon, 30 Aug 2004 12:18:20 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from ns0.nlsystems.com (ns0.nlsystems.com [80.177.232.243]) by itchy.rabson.org (8.12.11/8.12.11) with ESMTP id i7UCIG5N096065; Mon, 30 Aug 2004 13:18:17 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Brad Knowles Date: Mon, 30 Aug 2004 13:18:50 +0100 User-Agent: KMail/1.6.2 References: <200408160104.03708.chris@behanna.org> <200408301005.58602.dfr@nlsystems.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408301318.50737.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on itchy.rabson.org X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on itchy.rabson.org X-Virus-Status: Clean cc: Tim Kientzle cc: freebsd-current@freebsd.org cc: current@freebsd.org Subject: Re: Public Access to Perforce? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 12:18:21 -0000 On Monday 30 August 2004 10:15, Brad Knowles wrote: > At 10:05 AM +0100 2004-08-30, Doug Rabson quoted David O'Brien: > >> For what the project uses Perforce for, SVN > >> would offer nothing. > > > > True. That doesn't mean that subversion isn't better than CVS > > though. > > That's not the point. The point is that subversion is not better > than Perforce, at least for the functions for which the FreeBSD > project uses Perforce. > > The debate is not between Perforce vs. CVS or subversion vs. CVS, > but whether subversion or Perforce is a better replacement for CVS > for certain specific functions. This is a debate that can only > reasonably occur between people who actually understand both > alternative tools to a sufficient degree. > > > I think that the point being made by David O'Brien was that there > were a lot of people standing up and being indignant about the way > subversion was being treated in this discussion but then saying that > they didn't know how it compared to Perforce. This is > counter-productive, to say the least. I don't think I was trying to suggest that we should use subversion to replace either cvs or perforce at this point. I just wanted to correct the slightly harsh description of how subversion compares to cvs in real-world usage. Right now, the only thing which perforce has over subversion feature-wise is built-in support for repeated merging. Since that is currently what we use perforce for, subversion is not a suitable replacement. It could replace what we currently do with cvs but there isn't much point if it can't also replace perforce. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 12:18:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7819716A4CE; Mon, 30 Aug 2004 12:18:21 +0000 (GMT) Received: from itchy.rabson.org (mailgate.nlsystems.com [80.177.232.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4B0243D5F; Mon, 30 Aug 2004 12:18:20 +0000 (GMT) (envelope-from dfr@nlsystems.com) Received: from ns0.nlsystems.com (ns0.nlsystems.com [80.177.232.243]) by itchy.rabson.org (8.12.11/8.12.11) with ESMTP id i7UCIG5N096065; Mon, 30 Aug 2004 13:18:17 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: Brad Knowles Date: Mon, 30 Aug 2004 13:18:50 +0100 User-Agent: KMail/1.6.2 References: <200408160104.03708.chris@behanna.org> <200408301005.58602.dfr@nlsystems.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408301318.50737.dfr@nlsystems.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on itchy.rabson.org X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on itchy.rabson.org X-Virus-Status: Clean cc: Tim Kientzle cc: freebsd-current@freebsd.org cc: current@freebsd.org Subject: Re: Public Access to Perforce? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 12:18:21 -0000 On Monday 30 August 2004 10:15, Brad Knowles wrote: > At 10:05 AM +0100 2004-08-30, Doug Rabson quoted David O'Brien: > >> For what the project uses Perforce for, SVN > >> would offer nothing. > > > > True. That doesn't mean that subversion isn't better than CVS > > though. > > That's not the point. The point is that subversion is not better > than Perforce, at least for the functions for which the FreeBSD > project uses Perforce. > > The debate is not between Perforce vs. CVS or subversion vs. CVS, > but whether subversion or Perforce is a better replacement for CVS > for certain specific functions. This is a debate that can only > reasonably occur between people who actually understand both > alternative tools to a sufficient degree. > > > I think that the point being made by David O'Brien was that there > were a lot of people standing up and being indignant about the way > subversion was being treated in this discussion but then saying that > they didn't know how it compared to Perforce. This is > counter-productive, to say the least. I don't think I was trying to suggest that we should use subversion to replace either cvs or perforce at this point. I just wanted to correct the slightly harsh description of how subversion compares to cvs in real-world usage. Right now, the only thing which perforce has over subversion feature-wise is built-in support for repeated merging. Since that is currently what we use perforce for, subversion is not a suitable replacement. It could replace what we currently do with cvs but there isn't much point if it can't also replace perforce. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 12:25:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BBB916A4CE for ; Mon, 30 Aug 2004 12:25:11 +0000 (GMT) Received: from KVIW14.KVI.nl (KVIW14.KVI.nl [129.125.15.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9649B43D45 for ; Mon, 30 Aug 2004 12:25:10 +0000 (GMT) (envelope-from A.S.Usov@KVI.nl) Received: from KVIR52.KVI.nl ("port 59609"@KVIR52.KVI.nl [129.125.37.116]) <01LEA1DD791UD3Z2X6@KVI.nl> for freebsd-current@freebsd.org; Mon, 30 Aug 2004 14:24:45 +0200 (MET DST) Received: from KVIW13.KVI.nl by KVIR52.KVI.nl (AvMailGate-2.0.2-8) id 16168-4A5F1C9C; Mon, 30 Aug 2004 14:24:44 +0200 Received: from kvip88 ("port 49224"@KVIP88.KVI.nl [129.125.15.152]) by KVI.nl (PMDF V6.2-X17 #30869) with ESMTP id <01LEA1D99U5AD3Z2XZ@KVI.nl>; Mon, 30 Aug 2004 14:24:40 +0200 (MET DST) Date: Mon, 30 Aug 2004 14:24:39 +0200 From: "Alexander S. Usov" In-reply-to: <41330BF7.9080704@DeepCore.dk> To: freebsd-current@freebsd.org Message-id: <200408301424.39192.A.S.Usov@kvi.nl> Organization: KVI MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-disposition: inline User-Agent: KMail/1.6.2 X-AntiVirus: checked by AntiVir MailGate (version: 2.0.2-8; AVE: 6.27.0.6; VDF: 6.27.0.38; host: kvi.nl) References: <200408301251.38700.A.S.Usov@kvi.nl> <41330BF7.9080704@DeepCore.dk> cc: =?iso-8859-1?q?S=F8ren_Schmidt?= Subject: Re: 5.3-BETA2 hangs during cdrom detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 12:25:11 -0000 On Monday 30 August 2004 13:13, S=F8ren Schmidt wrote: > This has been fixed in -current some time ago, but has not been MFC'd to > the RELENG_5 branch yet... Does this means that the easiest solution is to put this cdrom as ata0-slav= e=20 and to wait for a few more beta's? BTW, I just downloaded and tried cdboot-6.0-CURRENT-20040830-SESNAP.iso It wrote: ata1-slave: FAILURE - ATA_IDENTIFY no interrupt ata1-slave: FAILURE - ATA_IDENTIFY no interrupt ATAPI_RESET time : 40us acd0: CDROM at ata1-master PIO4 and then hanged again :( =2D-=20 Best regards, Alexander. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 12:26:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1282616A4CE for ; Mon, 30 Aug 2004 12:26:37 +0000 (GMT) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08C5643D39 for ; Mon, 30 Aug 2004 12:26:34 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from midget.dons.net.au ([150.101.45.33])i7UCQU4Y054452; Mon, 30 Aug 2004 21:56:32 +0930 (CST) Received: from inchoate.dons.net.au (root@localhost.dons.net.au [127.0.0.1]) by midget.dons.net.au (8.12.9/8.12.10) with ESMTP id i7UCQRn7069582; Mon, 30 Aug 2004 21:56:28 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Guido van Rooij Date: Mon, 30 Aug 2004 21:56:21 +0930 User-Agent: KMail/1.6.2 References: <20040827082929.GA64830@gvr.gvr.org> <200408301701.07731.doconnor@gsoft.com.au> <20040830092522.GA13880@gvr.gvr.org> In-Reply-To: <20040830092522.GA13880@gvr.gvr.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200408302156.27235.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.26 (www . roaringpenguin . com / mimedefang) cc: freebsd-current@freebsd.org Subject: Re: project evil: signal quality X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 12:26:37 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 30 Aug 2004 18:55, Guido van Rooij wrote: > > Why do you say that? > > I am talking about the Windows driver - perhaps it doesn't report signal > > quality in a standard way. > > I assumed, and now that seems wrong, that there is only one > way the signal quality was retrieved. (the -l option uses an ioctl, where= as > the option I used uses a socket. Ahh OK. I would assume they get the info from the same palce but you never know :) =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 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBMxzy5ZPcIHs/zowRAuLtAJ9ZV02dj1VvKsfna+86fm5PD7+u1ACdGxZ8 bmHZUgJnkERuw8w0JjxNs7o=3D =3DsZYd =2D----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 12:32:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2C6A16A4CE for ; Mon, 30 Aug 2004 12:32:51 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 562E943D45 for ; Mon, 30 Aug 2004 12:32:51 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i7UCWon3098706; Mon, 30 Aug 2004 14:32:50 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <41331E52.6080305@DeepCore.dk> Date: Mon, 30 Aug 2004 14:32:18 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alexander S. Usov" References: <200408301251.38700.A.S.Usov@kvi.nl> <41330BF7.9080704@DeepCore.dk> <200408301424.39192.A.S.Usov@kvi.nl> In-Reply-To: <200408301424.39192.A.S.Usov@kvi.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA2 hangs during cdrom detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 12:32:52 -0000 Alexander S. Usov wrote: > On Monday 30 August 2004 13:13, S=F8ren Schmidt wrote: >=20 >>This has been fixed in -current some time ago, but has not been MFC'd t= o >>the RELENG_5 branch yet... >=20 >=20 > Does this means that the easiest solution is to put this cdrom as ata0-= slave=20 > and to wait for a few more beta's? >=20 > BTW, I just downloaded and tried cdboot-6.0-CURRENT-20040830-SESNAP.iso= > It wrote: > ata1-slave: FAILURE - ATA_IDENTIFY no interrupt > ata1-slave: FAILURE - ATA_IDENTIFY no interrupt > ATAPI_RESET time : 40us > acd0: CDROM at ata1-master PIO4 >=20 > and then hanged again :( Does it continue if you disconnect the CDROM entirely ? -S=F8ren From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 12:45:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71F5816A4CE for ; Mon, 30 Aug 2004 12:45:37 +0000 (GMT) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6B7C43D1D for ; Mon, 30 Aug 2004 12:45:36 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from pelsia.ninth-nine.com (pelsia.ninth-nine.com [219.127.74.123]) (authenticated bits=0) by sakura.ninth-nine.com (8.12.11/8.12.11/NinthNine) with ESMTP id i7UCjZrE027532 for ; Mon, 30 Aug 2004 21:45:36 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Mon, 30 Aug 2004 21:45:35 +0900 (JST) Message-Id: <200408301245.i7UCjZrE027532@sakura.ninth-nine.com> From: Norikatsu Shigemura To: freebsd-current@FreeBSD.org X-Mailer: Sylpheed version 0.9.12-gtk2-20040622 (GTK+ 2.4.4; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.5.6 (sakura.ninth-nine.com [219.127.74.121]); Mon, 30 Aug 2004 21:45:36 +0900 (JST) Subject: ping6 -f panic with mpsafenet=1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 12:45:37 -0000 I contacted a panic on current with debug.mpsafenet=1. - - - - - - - - - - # ping6 -f othermachine (about 1-5sec after...) panic: free: address 0xc0819200(0xc0819000) has not been allocated. cpuid = 0 KDB: enter: panic [thread 100012] Stopped at kdb_enter+0x30: leave db> gdb Step to enter the remote GDB backend. db> s - - - - - - - - - - So I did gdb6 -k. I got following result: - - - - - - - - - - # gdb6 -k /boot/kernel.NADESICO/kernel.debug GNU gdb 20040720 [GDB v6.x for FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-portbld-freebsd5.2"...target remote:65535 (kgdb) target remote:XXXXX Remote debugging using :XXXXX 0xc0569201 in kdb_enter (msg=???) at /export/home/nork/p4/src/sys/kern/subr_kdb.c:241 241 } warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. warning: shared library handler failed to enable breakpoint (kgdb) where #0 0xc0569201 in kdb_enter (msg=???) at /export/home/nork/p4/src/sys/kern/subr_kdb.c:241 #1 0xc053bff5 in free (addr=0x1, type=???) at /export/home/nork/p4/src/sys/kern/kern_malloc.c:334 #2 0xc0635bd5 in _key_delsp (sp=0xc0819200) at /export/home/nork/p4/src/sys/netipsec/key.c:1311 #3 0xc0635918 in key_delsp (sp=0x100) at /export/home/nork/p4/src/sys/netipsec/key.c:1225 #4 0xc06356a4 in _key_freesp (spp=0xe3a6ebf4, where=???, tag=???) at /export/home/nork/p4/src/sys/netipsec/key.c:1098 #5 0xc0631265 in ipsec6_in_reject (m=0xc2d0f600, inp=???) at /export/home/nork/p4/src/sys/netipsec/ipsec.c:1476 #6 0xc0619d3a in ip6_input (m=0xc2d0f600) at /export/home/nork/p4/src/sys/netinet6/ip6_input.c:813 #7 0xc05d5ef9 in netisr_processqueue (ni=0xc0811904) at /export/home/nork/p4/src/sys/net/netisr.c:234 #8 0xc05d63c9 in swi_net (dummy=0x0) at /export/home/nork/p4/src/sys/net/netisr.c:341 #9 0xc052e188 in ithread_loop (arg=0xc2704b80) at /export/home/nork/p4/src/sys/kern/kern_intr.c:546 #10 0xc052ce60 in fork_exit (callout=0xc052dfd0 , arg=???, frame=???) at /export/home/nork/p4/src/sys/kern/kern_fork.c:820 #11 0xc070845c in fork_trampoline () at /export/home/nork/p4/src/sys/i386/i386/exception.s:209 - - - - - - - - - - # Oops, I heared INET6 with FAST_IPSEC is not good. # I'll try to use INET6 with KAME_IPSEC. And I noticed about xmms behavior. xmms is BGM player and is not forcused (out of screen by WindowMaker), then xmms cannot play *next* music. But I give forcus to xmms, as soon as xmms is re-playing BGM. | libpthread | libthr | libc_r ---------------+------------+--------+-------- w/o PREEMPTION | NG | NG | OK w/ PREEMPTION | NG | NG | OK I think that KSE has a problem. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 12:47:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9167016A4CE for ; Mon, 30 Aug 2004 12:47:40 +0000 (GMT) Received: from veldy.net (fuggle.veldy.net [209.98.200.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46EF243D5A for ; Mon, 30 Aug 2004 12:47:40 +0000 (GMT) (envelope-from veldy@veldy.net) Received: from localhost (localhost [127.0.0.1]) by veldy.net (Postfix) with ESMTP id 4B0B03176; Mon, 30 Aug 2004 07:47:39 -0500 (CDT) Received: from veldy.net ([127.0.0.1]) by localhost (fuggle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04121-06; Mon, 30 Aug 2004 07:47:34 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by veldy.net (Postfix) with ESMTP id 6C65B3175; Mon, 30 Aug 2004 07:47:34 -0500 (CDT) Message-ID: <413321E2.7070603@veldy.net> Date: Mon, 30 Aug 2004 07:47:30 -0500 From: "Thomas T. Veldhouse" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <200408301251.38700.A.S.Usov@kvi.nl> <41330BF7.9080704@DeepCore.dk> <200408301424.39192.A.S.Usov@kvi.nl> <41331E52.6080305@DeepCore.dk> In-Reply-To: <41331E52.6080305@DeepCore.dk> X-Enigmail-Version: 0.85.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF40AC78699DF3D80D101B1D3" Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new at veldy.net cc: freebsd-current@freebsd.org cc: "Alexander S. Usov" Subject: Re: 5.3-BETA2 hangs during cdrom detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 12:47:40 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF40AC78699DF3D80D101B1D3 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Søren Schmidt wrote: > Alexander S. Usov wrote: > >> On Monday 30 August 2004 13:13, Søren Schmidt wrote: >> >>> This has been fixed in -current some time ago, but has not been >>> MFC'd to >>> the RELENG_5 branch yet... >> >> >> >> Does this means that the easiest solution is to put this cdrom as >> ata0-slave and to wait for a few more beta's? >> >> BTW, I just downloaded and tried cdboot-6.0-CURRENT-20040830-SESNAP.iso >> It wrote: >> ata1-slave: FAILURE - ATA_IDENTIFY no interrupt >> ata1-slave: FAILURE - ATA_IDENTIFY no interrupt >> ATAPI_RESET time : 40us >> acd0: CDROM at ata1-master PIO4 >> >> and then hanged again :( > > > Does it continue if you disconnect the CDROM entirely ? > > -Søren > I am still getting the same hang on DVD/CDROM detection that I reported a couple of weeks ago. I am still getting the hang with 5.3-BETA2. Tom Veldhouse --------------enigF40AC78699DF3D80D101B1D3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFBMyHlARgTFXYf0wARAgwCAJ4q9GFwXoAcHUqCRBhp/Qt9sj8qYACfax91 ukM/XQJg8LCIMhrpW4uRaKQ= =SqDR -----END PGP SIGNATURE----- --------------enigF40AC78699DF3D80D101B1D3-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 12:54:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 131AF16A4CE for ; Mon, 30 Aug 2004 12:54:38 +0000 (GMT) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B02443D58 for ; Mon, 30 Aug 2004 12:54:37 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from pelsia.ninth-nine.com (pelsia.ninth-nine.com [219.127.74.123]) (authenticated bits=0) by sakura.ninth-nine.com (8.12.11/8.12.11/NinthNine) with ESMTP id i7UCsald027733 for ; Mon, 30 Aug 2004 21:54:36 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Mon, 30 Aug 2004 21:54:36 +0900 (JST) Message-Id: <200408301254.i7UCsald027733@sakura.ninth-nine.com> From: Norikatsu Shigemura To: freebsd-current@FreeBSD.org In-Reply-To: <200408301245.i7UCjZrE027532@sakura.ninth-nine.com> References: <200408301245.i7UCjZrE027532@sakura.ninth-nine.com> X-Mailer: Sylpheed version 0.9.12-gtk2-20040622 (GTK+ 2.4.4; i386-portbld-freebsd5.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-1.5.6 (sakura.ninth-nine.com [219.127.74.121]); Mon, 30 Aug 2004 21:54:37 +0900 (JST) Subject: Re: ping6 -f panic with mpsafenet=1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 12:54:38 -0000 On Mon, 30 Aug 2004 21:45:35 +0900 (JST) Norikatsu Shigemura wrote: > And I noticed about xmms behavior. xmms is BGM player and is > not forcused (out of screen by WindowMaker), then xmms cannot > play *next* music. But I give forcus to xmms, as soon as xmms > is re-playing BGM. > | libpthread | libthr | libc_r > ---------------+------------+--------+-------- > w/o PREEMPTION | NG | NG | OK > w/ PREEMPTION | NG | NG | OK > I think that KSE has a problem. I confirmed same result with w/ SCHED_ULE and w/ SCHED_4BSD. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 12:57:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F66B16A4CE for ; Mon, 30 Aug 2004 12:57:53 +0000 (GMT) Received: from KVIW08.KVI.nl (KVIW08.KVI.nl [129.125.15.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 018AD43D48 for ; Mon, 30 Aug 2004 12:57:53 +0000 (GMT) (envelope-from A.S.Usov@KVI.nl) Received: from KVIS10.KVI.nl ("port 49351"@KVIS10.KVI.nl [129.125.27.60]) <01LEA2J7R6NOD3Z2YW@KVI.nl> for freebsd-current@freebsd.org; Mon, 30 Aug 2004 14:57:44 +0200 (MET DST) Received: from KVIW06.KVI.NL by KVIS10.KVI.nl (AvMailGate-2.0.2-8) id 07324-7951714E; Mon, 30 Aug 2004 14:57:41 +0200 Received: from kvip88 ("port 49156"@KVIP88.KVI.nl [129.125.15.152]) by KVI.nl (PMDF V6.2-X17 #30869) with ESMTP id <01LEA2IXX880D3Z2XZ@KVI.nl>; Mon, 30 Aug 2004 14:57:29 +0200 (MET DST) Date: Mon, 30 Aug 2004 14:57:28 +0200 From: "Alexander S. Usov" In-reply-to: <41331E52.6080305@DeepCore.dk> To: =?iso-8859-1?q?S=F8ren_Schmidt?= Message-id: <200408301457.28559.A.S.Usov@kvi.nl> Organization: KVI MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-disposition: inline User-Agent: KMail/1.6.2 X-AntiVirus: checked by AntiVir MailGate (version: 2.0.2-8; AVE: 6.27.0.6; VDF: 6.27.0.38; host: kvi.nl) References: <200408301251.38700.A.S.Usov@kvi.nl> <200408301424.39192.A.S.Usov@kvi.nl> <41331E52.6080305@DeepCore.dk> cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA2 hangs during cdrom detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 12:57:53 -0000 On Monday 30 August 2004 14:32, S=F8ren Schmidt wrote: > Alexander S. Usov wrote: > > On Monday 30 August 2004 13:13, S=F8ren Schmidt wrote: > >>This has been fixed in -current some time ago, but has not been MFC'd to > >>the RELENG_5 branch yet... > > > > Does this means that the easiest solution is to put this cdrom as > > ata0-slave and to wait for a few more beta's? > > > > BTW, I just downloaded and tried cdboot-6.0-CURRENT-20040830-SESNAP.iso > > It wrote: > > ata1-slave: FAILURE - ATA_IDENTIFY no interrupt > > ata1-slave: FAILURE - ATA_IDENTIFY no interrupt > > ATAPI_RESET time : 40us > > acd0: CDROM at ata1-master PIO4 > > > > and then hanged again :( > > Does it continue if you disconnect the CDROM entirely ? Almoust :) I have just tried two combinations: - moving the cdrom to ata0-slave - disconnecting it at all. As long, as I boot the 6.0 from HDD, it works fine in both cases. I didn't= =20 tried this woth CD as ata1-master, but suppose it will also work. However booting it from CD causes hang right after CD detection as describe= d=20 above. =2D-=20 Best regards, Alexander. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 13:04:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FEE116A4CE for ; Mon, 30 Aug 2004 13:04:10 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id E37CA43D2F for ; Mon, 30 Aug 2004 13:04:09 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i7UD48nn098970; Mon, 30 Aug 2004 15:04:08 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <413325A8.3070509@DeepCore.dk> Date: Mon, 30 Aug 2004 15:03:36 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Thomas T. Veldhouse" References: <200408301251.38700.A.S.Usov@kvi.nl> <41330BF7.9080704@DeepCore.dk> <200408301424.39192.A.S.Usov@kvi.nl> <41331E52.6080305@DeepCore.dk> <413321E2.7070603@veldy.net> In-Reply-To: <413321E2.7070603@veldy.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: freebsd-current@freebsd.org cc: "Alexander S. Usov" Subject: Re: 5.3-BETA2 hangs during cdrom detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 13:04:10 -0000 Thomas T. Veldhouse wrote: > S=F8ren Schmidt wrote: >=20 >> Alexander S. Usov wrote: >> >>> On Monday 30 August 2004 13:13, S=F8ren Schmidt wrote: >>> >>>> This has been fixed in -current some time ago, but has not been=20 >>>> MFC'd to >>>> the RELENG_5 branch yet... >>> >>> >>> >>> >>> Does this means that the easiest solution is to put this cdrom as=20 >>> ata0-slave and to wait for a few more beta's? >>> >>> BTW, I just downloaded and tried cdboot-6.0-CURRENT-20040830-SESNAP.i= so >>> It wrote: >>> ata1-slave: FAILURE - ATA_IDENTIFY no interrupt >>> ata1-slave: FAILURE - ATA_IDENTIFY no interrupt >>> ATAPI_RESET time : 40us >>> acd0: CDROM at ata1-master PIO4 >>> >>> and then hanged again :( >> >> >> >> Does it continue if you disconnect the CDROM entirely ? >> >> -S=F8ren >> > I am still getting the same hang on DVD/CDROM detection that I reported= =20 > a couple of weeks ago. I am still getting the hang with 5.3-BETA2. Read above: "This has been fixed in -current some time ago, but has not been MFC'd=20 to the RELENG_5 branch yet" Now, one could wonder why it was so urgent to cut beta2... -S=F8ren From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 13:05:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85E8516A4D0 for ; Mon, 30 Aug 2004 13:05:09 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA4F843D49 for ; Mon, 30 Aug 2004 13:05:08 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i7UD57Ff098995; Mon, 30 Aug 2004 15:05:07 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <413325E4.7090302@DeepCore.dk> Date: Mon, 30 Aug 2004 15:04:36 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alexander S. Usov" References: <200408301251.38700.A.S.Usov@kvi.nl> <200408301424.39192.A.S.Usov@kvi.nl> <41331E52.6080305@DeepCore.dk> <200408301457.28559.A.S.Usov@kvi.nl> In-Reply-To: <200408301457.28559.A.S.Usov@kvi.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA2 hangs during cdrom detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 13:05:09 -0000 Alexander S. Usov wrote: > On Monday 30 August 2004 14:32, S=F8ren Schmidt wrote: >=20 >>Alexander S. Usov wrote: >> >>>On Monday 30 August 2004 13:13, S=F8ren Schmidt wrote: >>> >>>>This has been fixed in -current some time ago, but has not been MFC'd= to >>>>the RELENG_5 branch yet... >>> >>>Does this means that the easiest solution is to put this cdrom as >>>ata0-slave and to wait for a few more beta's? >>> >>>BTW, I just downloaded and tried cdboot-6.0-CURRENT-20040830-SESNAP.is= o >>>It wrote: >>>ata1-slave: FAILURE - ATA_IDENTIFY no interrupt >>>ata1-slave: FAILURE - ATA_IDENTIFY no interrupt >>>ATAPI_RESET time : 40us >>>acd0: CDROM at ata1-master PIO4 >>> >>>and then hanged again :( >> >>Does it continue if you disconnect the CDROM entirely ? >=20 >=20 > Almoust :) >=20 > I have just tried two combinations: > - moving the cdrom to ata0-slave > - disconnecting it at all. >=20 > As long, as I boot the 6.0 from HDD, it works fine in both cases. I did= n't=20 > tried this woth CD as ata1-master, but suppose it will also work. > However booting it from CD causes hang right after CD detection as desc= ribed=20 > above. Hmm, this sounds like something else then, but I have no idea what :/ -S=F8ren From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 13:22:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16FC616A4CE; Mon, 30 Aug 2004 13:22:21 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id A149643D5D; Mon, 30 Aug 2004 13:22:20 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1C1m70-0000U6-V8; Mon, 30 Aug 2004 17:22:19 +0400 From: Vladimir Grebenschikov To: Colin Percival In-Reply-To: <6.1.0.6.1.20040816074348.03f99338@popserver.sfu.ca> References: <6.1.0.6.1.20040816074348.03f99338@popserver.sfu.ca> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Mon, 30 Aug 2004 17:22:18 +0400 Message-Id: <1093872138.1503.1.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.93FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: freebsd-current@freebsd.org cc: freebsd-mobile Subject: Re: Enhanced SpeedStep driver available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 13:22:21 -0000 On Mon, 2004-08-16 at 08:06 -0700, Colin Percival wrote: > Thanks to everyone who has been sending me data about their > processors (and in particular, the 90nm versions), I now have > a first draft of a Enhanced SpeedStep driver available. For > people with the appropriate processors (Pentium M only), this > makes it possible to adjust the cpu frequency via a new sysctl > (hw.est_curfreq), and have the cpu voltage adjusted at the > same time. > I've also put together a very simple control daemon which > reads kern.cp_time every second and adjusts the cpu frequency > based on the fraction of cpu time which is idle. This increases > my laptop's battery life by around 40%. > All the code is online at > http://www.daemonology.net/freebsd-est/ > Assuming I don't hear any major bug reports in the next few > days, I'll package these into ports and hopefully get them into > the ports tree in time for 5.3-RELEASE. Amazing, only issue, flood of speed changing messages in dmesg, please add: % cat /usr/ports/sysutils/est/files/patch-est.c-no-flood --- est.c.orig Mon Aug 30 16:53:43 2004 +++ est.c Mon Aug 30 16:54:38 2004 @@ -505,8 +505,9 @@ if (f->mhz == 0) return (EOPNOTSUPP); - printf("Changing CPU frequency from %d MHz to %d MHz\n", - mhz, mhz_wanted); + if (bootverbose) + printf("Changing CPU frequency from %d MHz to %d MHz\n", + mhz, mhz_wanted); msr = rdmsr(MSR_PERF_CTL); msr = (msr & ~(uint64_t)(0xffff)) | % or like > Colin Percival -- Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 13:24:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6308516A4CE for ; Mon, 30 Aug 2004 13:24:54 +0000 (GMT) Received: from freesbee.dk (freesbee.dk [194.192.25.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 887A043D62 for ; Mon, 30 Aug 2004 13:24:53 +0000 (GMT) (envelope-from signout@signout.dk) Received: from signoutscraptop (localhost [127.0.0.1]) by freesbee.dk (Postfix) with SMTP id 301D42B76D for ; Mon, 30 Aug 2004 15:24:51 +0200 (CEST) Message-ID: <0be501c48e94$ba63c060$87075050@signoutscraptop> From: =?iso-8859-1?Q?Dennis_Kj=E6r_Jensen?= To: Date: Mon, 30 Aug 2004 15:24:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.181 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Subject: 5.3-BETA2 problems booting HP NetServer E60 both ACPI and non-ACPI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 13:24:54 -0000 I have console dumps from boot both with and without ACPI enabled on http://signout.dk/FreeBSD/20040830-E60 If AGP is in the kernel the system simply halts during boot after detecting agp0. On a generic 4.7 kernel this wasn't a problem. On 4.8 it is. Somewhere between 4.7 and 4.8 something bad happened. I suspect this to be the same issue. Please advise. I currently run 4.7-RELEASE-p27 on the machine. ... Dennis From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 13:30:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1081316A4CE for ; Mon, 30 Aug 2004 13:30:06 +0000 (GMT) Received: from KVIW06.KVI.NL (KVIW06.KVI.nl [129.125.15.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5231C43D5D for ; Mon, 30 Aug 2004 13:30:05 +0000 (GMT) (envelope-from A.S.Usov@KVI.nl) Received: from KVIS10.KVI.nl ("port 49393"@KVIS10.KVI.nl [129.125.27.60]) <01LEA3N1TWQWD3Z2YW@KVI.nl> for freebsd-current@freebsd.org; Mon, 30 Aug 2004 15:29:49 +0200 (MET DST) Received: from KVIW14.KVI.nl by KVIS10.KVI.nl (AvMailGate-2.0.2-8) id 11283-4473B2AE; Mon, 30 Aug 2004 15:29:48 +0200 Received: from kvip88 ("port 49164"@KVIP88.KVI.nl [129.125.15.152]) by KVI.nl (PMDF V6.2-X17 #30869) with ESMTP id <01LEA3MT1PO0D3Z2YW@KVI.nl>; Mon, 30 Aug 2004 15:29:37 +0200 (MET DST) Date: Mon, 30 Aug 2004 15:29:37 +0200 From: "Alexander S. Usov" In-reply-to: <413325E4.7090302@DeepCore.dk> To: =?iso-8859-1?q?S=F8ren_Schmidt?= Message-id: <200408301529.37015.A.S.Usov@kvi.nl> Organization: KVI MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Content-disposition: inline User-Agent: KMail/1.6.2 X-AntiVirus: checked by AntiVir MailGate (version: 2.0.2-8; AVE: 6.27.0.6; VDF: 6.27.0.38; host: kvi.nl) References: <200408301251.38700.A.S.Usov@kvi.nl> <200408301457.28559.A.S.Usov@kvi.nl> <413325E4.7090302@DeepCore.dk> cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA2 hangs during cdrom detection X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 13:30:06 -0000 On Monday 30 August 2004 15:04, S=F8ren Schmidt wrote: > Alexander S. Usov wrote: > > On Monday 30 August 2004 14:32, S=F8ren Schmidt wrote: > >>Alexander S. Usov wrote: > >>>On Monday 30 August 2004 13:13, S=F8ren Schmidt wrote: > >>>>This has been fixed in -current some time ago, but has not been MFC'd > >>>> to the RELENG_5 branch yet... > >>> > >>>Does this means that the easiest solution is to put this cdrom as > >>>ata0-slave and to wait for a few more beta's? > >>> > >>>BTW, I just downloaded and tried cdboot-6.0-CURRENT-20040830-SESNAP.iso > >>>It wrote: > >>>ata1-slave: FAILURE - ATA_IDENTIFY no interrupt > >>>ata1-slave: FAILURE - ATA_IDENTIFY no interrupt > >>>ATAPI_RESET time : 40us > >>>acd0: CDROM at ata1-master PIO4 > >>> > >>>and then hanged again :( > >> > >>Does it continue if you disconnect the CDROM entirely ? > > > > Almoust :) > > > > I have just tried two combinations: > > - moving the cdrom to ata0-slave > > - disconnecting it at all. > > > > As long, as I boot the 6.0 from HDD, it works fine in both cases. I > > didn't tried this woth CD as ata1-master, but suppose it will also work. > > However booting it from CD causes hang right after CD detection as > > described above. > > Hmm, this sounds like something else then, but I have no idea what :/ Ok. For the moment it work with the CD on ata0-slave. I will try it some few weeks later, to see if it is still there and will wr= ite=20 once more. =2D-=20 Best regards, Alexander. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 13:45:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A33016A4D2 for ; Mon, 30 Aug 2004 13:45:03 +0000 (GMT) Received: from web50608.mail.yahoo.com (web50608.mail.yahoo.com [206.190.38.95]) by mx1.FreeBSD.org (Postfix) with SMTP id C2C0243D6B for ; Mon, 30 Aug 2004 13:45:02 +0000 (GMT) (envelope-from kstailey@yahoo.com) Message-ID: <20040830134502.16634.qmail@web50608.mail.yahoo.com> Received: from [69.138.247.171] by web50608.mail.yahoo.com via HTTP; Mon, 30 Aug 2004 06:45:02 PDT Date: Mon, 30 Aug 2004 06:45:02 -0700 (PDT) From: Kenneth Stailey To: Gleb Smirnoff In-Reply-To: <20040829141941.GA24612@cell.sick.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 13:45:03 -0000 --- Gleb Smirnoff wrote: > On Sun, Aug 29, 2004 at 07:10:44AM -0700, Kenneth Stailey wrote: > K> Can a one-line example of how to invoke adduser to add new accounts like > K> "proxy" be added to /usr/src/UPDATING? That way people could just > K> cut-and-paste the accounts into place when upgrading. > > If you run mergemaster when updating, you can easily merge these lines. > > -- > Totus tuus, Glebius. > GLEBIUS-RIPN GLEB-RIPE > I know about mergemaster it's just that: 1. /etc/passwd is a critical file and can get hairy on production systems. 2. It's about convenience and safety, why not dispense with adduser, etc and tell people to just use vipw? From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 13:52:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 040C616A4CE; Mon, 30 Aug 2004 13:52:32 +0000 (GMT) Received: from av5-1-sn4.m-sp.skanova.net (av5-1-sn4.m-sp.skanova.net [81.228.10.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id B36BB43D4C; Mon, 30 Aug 2004 13:52:31 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av5-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 1CBA737E5A; Mon, 30 Aug 2004 15:52:31 +0200 (CEST) Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av5-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 0C98537E43; Mon, 30 Aug 2004 15:52:31 +0200 (CEST) Received: from gadget (h130n1fls11o822.telia.com [213.64.66.130]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id C18DD37E42; Mon, 30 Aug 2004 15:52:30 +0200 (CEST) From: "Daniel Eriksson" To: "'Lukas Ertl'" , "'Craig Boston'" , Date: Mon, 30 Aug 2004 15:52:31 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20040827012953.T556@korben.in.tern> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSLxU/8rJMyEu00TqmQagezZGSQFQC0H+oQ Subject: RE: PLEASE TEST: IPI deadlock avoidance patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 13:52:32 -0000 Lukas Ertl wrote: > I've identified and fixed (hopefully) a source of possible > data corruption on RAID5 plexes three days ago. You need > rev. 1.6 of geom_vinum_raid5.c. I have now tested with 6-CURRENT compiled from sources dated 2004.08.29.21.00.00 (which includes your patch), and I must unfortunately report that it does not fix the problem. I tested by duplicating a bunch (9GB+) of binary files with known crc checksums on the same filesystem, and I ended up with ~10% corrupt files. Running the exact same test under a kernel compiled without SMP worked without any problems. (Testbed: SMP machine with 4 SATA discs in a gvinum RAID-5 array) I have managed to secure some more testing time on the server today, so I will be trying this with regular vinum later to see if that makes a difference. I'll report back here on the list. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 14:04:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97DC116A4CE for ; Mon, 30 Aug 2004 14:04:46 +0000 (GMT) Received: from gravy.kishka.net (pcp04097789pcs.neave01.pa.comcast.net [68.81.192.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3438143D62 for ; Mon, 30 Aug 2004 14:04:46 +0000 (GMT) (envelope-from bryan@kishka.net) Received: from [192.168.1.2] (gravy.kishka.net [192.168.1.2]) by gravy.kishka.net (8.13.1/8.13.1) with ESMTP id i7UE4h6T000706; Mon, 30 Aug 2004 10:04:43 -0400 (EDT) (envelope-from bryan@kishka.net) Message-ID: <413333FB.5020905@kishka.net> Date: Mon, 30 Aug 2004 10:04:43 -0400 From: Bryan Liesner User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040808 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrille Lefevre , current@freebsd.org References: <200408291848.i7TImAq8072080@mail.gits.dyndns.org> <098401c48e76$6772d300$7890a8c0@gits.invalid> In-Reply-To: <098401c48e76$6772d300$7890a8c0@gits.invalid> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 14:04:46 -0000 Cyrille Lefevre wrote: > PR#71142 (http://www.freebsd.org/cgi/query-pr.cgi?pr=71142) > has just been submitted w/ the "static void" fix. > > PS : the vidcontrol "showing the mouse: Invalid argument" > error message has not been fixed, yet. > > Cyrille Lefevre. It works great! One exception - I'm using green_saver and it doesn't blank the screen anymore. The text stays where it is on the screen and the cursor disappears. When I hit a key, the console responds by blanking for a second, then back to normal operation. The patch as listed in the PR is mangled - some spaces are rendered as =20, equal signs rendered as =3D, and escape chars as =1B. I did manage to fix the patch and get it to apply cleanly. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 14:34:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48B5616A4CE for ; Mon, 30 Aug 2004 14:34:21 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id B15B943D41 for ; Mon, 30 Aug 2004 14:34:20 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1C1nEe-0000go-7O; Mon, 30 Aug 2004 18:34:16 +0400 From: Vladimir Grebenschikov To: Bryan Liesner In-Reply-To: <413333FB.5020905@kishka.net> References: <200408291848.i7TImAq8072080@mail.gits.dyndns.org> <413333FB.5020905@kishka.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Mon, 30 Aug 2004 18:34:15 +0400 Message-Id: <1093876455.1503.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.93FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: Cyrille Lefevre cc: "current@freebsd.org" Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 14:34:21 -0000 On Mon, 2004-08-30 at 10:04 -0400, Bryan Liesner wrote: > Cyrille Lefevre wrote: > > PR#71142 (http://www.freebsd.org/cgi/query-pr.cgi?pr=71142) > > has just been submitted w/ the "static void" fix. > > > > PS : the vidcontrol "showing the mouse: Invalid argument" > > error message has not been fixed, yet. > > > > Cyrille Lefevre. > > It works great! One exception - I'm using green_saver and it doesn't > blank the screen anymore. The text stays where it is on the screen and > the cursor disappears. When I hit a key, the console responds by > blanking for a second, then back to normal operation. Yes it works for me in 1400x1050, great ! As for another vgl applications - there is problem, after app exit screen locked in some video mode and then can't be switched to any mode by vidcontrol or X (X do not show anything). (I have tried games/digger-vgl to test, after start F10 to exit) -- Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 14:37:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1933116A4CE; Mon, 30 Aug 2004 14:37:36 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD4CF43D5C; Mon, 30 Aug 2004 14:37:35 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7UEZ5Sn019446; Mon, 30 Aug 2004 10:35:05 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7UEZ5uL019443; Mon, 30 Aug 2004 10:35:05 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 30 Aug 2004 10:35:05 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Gleb Smirnoff In-Reply-To: <20040830095729.GD30701@cell.sick.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: "Bjoern A. Zeeb" cc: FreeBSD current mailing list Subject: Re: mutex Giant not owned at /usr/src/sys/kern/vfs_vnops.c:120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 14:37:36 -0000 On Mon, 30 Aug 2004, Gleb Smirnoff wrote: > B> > This causes Giant to be acquired in the event we enter the linker code > B> > (and hence VFS code) via netgraph ngc_send(). It should be safe in this > B> > context as we enter protocol send routines without mutexes held (i.e., why > B> > we're also able to do blocking memory allocation here.) > B> > B> please commit. > > I think Giant should be acquired in linker_load_module(), and this way > we will prevent this panic in other codepaths. For example in > vfs_mount.c, when vfs will be Giant-free. Have I missed something? Well, one of the primary reasons the linker needs Giant here is its use of VFS. I think for now I'd like to acquire Giant in netgraph so as to expose the use of Giant in that piece of the network stack in the calling code. We might want to add GIANT_REQUIRED assertions in the linker code to make sure we trigger assertions even if the linker doesn't hit VFS to make sure potentially hitting Giant is caught. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 14:39:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91F7216A4CE for ; Mon, 30 Aug 2004 14:39:50 +0000 (GMT) Received: from ptcnat.era.pl (ptcnat.era.pl [213.158.197.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0A4143D3F for ; Mon, 30 Aug 2004 14:39:49 +0000 (GMT) (envelope-from zaks@era.pl) Received: by localhost (Postfix, from userid 1001) id 1F1F2117DB; Mon, 30 Aug 2004 16:39:48 +0200 (CEST) From: =?iso-8859-2?q?S=B3awek_=AFak?= To: current@freebsd.org Date: Mon, 30 Aug 2004 16:39:47 +0200 Message-ID: <86acwc7kr0.fsf@thirst.unx.era.pl> User-Agent: Gnus/5.110003 (No Gnus v0.3) XEmacs/21.4 (Reasonable Discussion, berkeley-unix) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: IPSec related crash? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 14:39:50 -0000 --=-=-= Hi, Happened on BETA1. 2 processor SMP. DDB after-crash queries attacched. --=-=-= Content-Type: application/octet-stream Content-Disposition: attachment; filename=crash.bz2 Content-Transfer-Encoding: base64 QlpoOTFBWSZTWXt7wPIAGT9fgGgQQG5/8zilfoq/7//wYA9ceFx92Jr3tvgXfE9do5QOvXp6 pTppp3yu+32KFql6bjFN2CGIRNNGgQBJtCn6TU9QAADQBqYE2oImmkmVPU/UgAAAAABqntqC o1Tam9UeoAAA00AAAASaURJphNqmTTUPUaAANAeUyABEpqCJmhEeo9QyYmj1AyNABtTQCpJN BJmkJ6A1PVM1MJ6INBoYTI06yGhISKikgRVVVVFkJCIP38/Py/vl7dvR59X84zxPgVfztFcW EpaAH76+73Xg4vTlvM9gv8f1njz7M76+LRBZ5slZILARQgyEAiQCEUOH5dH9AnC13qvwOqdW zTvhjlvz1q49+HcToBEANr0xSQCRGRJAJBQkRkE9InCwij0UCZ4SKSSJJFgNW8FKhlhwz3Ci xQkZAZCQZBVVVVSRVkgeHz/WQA3aOmJAifHw+nX3Pr78+vf3+MEkkkkkkkkkkkkkkkkkkkkk kkkkkkkkkkkkkkkkkkzEREEmqVSxdHd5hR/K1hXP6QotYC0YpLujGIM5X+3f2AbuX3X4FYno s9njMeOTS0MOF+buAbrWJa1iWggZRQdDjycwRUCQA91rPJRJbwCQb8/+QE+1b7ABYALYEPA+ fn5+cfOuhXySSSSSqqSSSSXd3ckkkmZmZmSSSSSaqqqqqiSqqUQglCS5LqpJNzRKB3Jm8pMa tlB5QBSlHpionZIay/CwgEQAmAPHEsEVWVGxRdVDLro/CzfyzzVeoOCg4lBjjivlUjJWVX7+ WN/05ZyNK0xW5r4PPsQMIiT2uLpOavPFAr1/3C4HZLMm+VtRF+MfL0UIBSHCGKJAPZeXAZyz wyYY5xs7aIbIauSAb8bBoaEIoc9i5cK34brpcoKYwXTfZs4catxpy07tqkZ66FV69nHo7+3j 1dnP8MtKKOsUHrRAUQUh9HDh7cfbn79PfG1bEEAxKRtrO2NrWvthTCHbgbwAQAAIAAAAAQAA IAAEAACAABAAAgAAQ00wAIh6QJtkYxzEvWq41dtxXJdzVtvMybt226rLu8by4Bzau27qLu6o dTOVGXZbzG3jY3gCm7wDJpxSx5Zvhc0KFEaJLRw9neb6ydajW71xvG3igG6kWKwDKyjIonLo LrqM6isRScy8My5rOUi5IIJuvSTZYszMzJtttttttttq21T2IqqKxEcDlFayhBthSOiAAAD7 p8KdnmN8UOCeCTu975ve991x1ps5xjGMYxxxrWtjje85zWdLxBOsUU3q90Vm41ul3I1vMs99 o+0rjKxuL8LWkzl0TeZwUjjbczPLHHdLbHW4MceRjnssIEQEGSRIIsITok32wUUVRWcCCSAV gHLqooDRBTPWyhJE4iJUQtdbIBLshVOzMIaTfLCsNMFw6iVRUECKhzSVcBAFqp1UIlkJoCdK 4yrf9/XTS8gYbU1ytaLpF+OWI1gGy5XUXPJJWXaCRN8BIgEiIARBQJYkAsOvbflFehB6a6Rt bXlv3w1RfWt9bq151wXT1xaK5KcYytPlGA1D25PMAgmiQHVRGE8azabU5sRenWadZxDhQ0Rm Xjo0pMITvlTPbEK99AiA4TGOXdtNh3aJ5nLx39azv6LfVyid+1/C8ceUSU+Pjn37rZ3zvXKI iCwqqvVEnjCjpB9W2bWApNeMDZsec8QYoCSRwzYHHHjMTpKUUlG05qcolJDKXObw93d3bQeo 7taav4vMUoh1dsVjjn32fgY4CX4IVofz4mZmZmZQX+jlLAC2071y9HnXt5qpR2WnqiaH0rGm 6eV8FuPih7e3I63D3u73taOnfu9/V5N+w7u973zawF7ypZr3jRmUjjht5RPPnD6gaXFZQQgE JZNea8Tv2JtpEQa0oAobIFkiGLyBaRMu9h4nXj1y3OdX31rRp2FrWsGL0TjBwlHCBmbnHaKq qqqqqq6STTrO687wNtuBDt67xm7SUiUEyt/S9FHO48zMxMyVBCYjOQYvdRdAGbMVcKqqiKna iqqd3KoSTUXCktQtFF6xAlcKsQJsc71qvTX6PF2tZxmBuyL5f0V8gTLsABSCSIkuKbNQiLIK yAoZZ/Do2bL82rT3eSzU9XqrnlcDzvO69JzDa8NuL2sLDtLADPWpmaq8zCT6EVJsLAlvvZzN haoxqX72ieOr+I6WQH1DAi1XFjhbMQtFIpAhFUvDi9GlLROaUpUu3EqUSyBLIKQVV5xodhs8 sGZl1gD0gtri+d7i++4vpfjPdwwIxREVDA5lA8hsQJvOYSDvrxra2z63XjybzDo5MyTfGFx8 J34G0RECIiWREREQIET255fP0SMk2Htc0BES7CbrEOzM7v9EhwopGs0ZtaWDtKjvSNIhEC7L bbDjkjcTVE2LYu2tAtSPXTMGZpSrbC79cu2cdaz3VIlVeqJPHn26L5wiVWNWtwnOHD3Hhbcs tlGeFaEEREO8KIhY9TaIira5UktYV5GVkrB6VRVOZoqZDpWVfI7yKRrCW9VfxcpNANTOjiUH bTK2RwEUeeucDvWW1muu8VVVeqomTS9CeG6SO0RERERERERERERBgSZukZ7tM8pJ1K+qnIQG eEzlnUOzrWKs9zpawoRVcUtJT2e7wmIEPKqfIgREaDjjbYfvlfOO38Po3ROvPlOM0mLWFrCO 45xzk3zlb1VVFUS+p2gXHo8OXdwvc+LTUpakQVtGkzSTdcAMB4kPEePHna31DLw3fTMzSeLW ys8KuxGbNiGzenu+OZnd8EkzMzMySSSSSSSSSSSSXuTLpE3L9AZsL8+Ge+Q1uTwVA3V3nem4 +qoFlQPY+oR/HzEfEoR9BH0z9ygj6SQXPraSDfESe8Rcj4d/fyv/sRxqEWJUPxAsvqeWS+c1 WpSpa1NmrWsncc52lx5A4dAr3MPgqmb2PfhpVXLpCfeZkDS+bc8vinVhJRtzR6A9Nb+fsrbd zroM6jpLXAUP1tUPdor0Dfw0579V8OW/uDr1NaNKWnebB64HLVNBn2DuzqbJbbOPe+f9at5A +Ptyem+fv8PLI6kQZq5dtY7uvP4Le0eHWIh4ldOjxKJ8R4MwQgJADoWEigiLCbq5OGH3pEvv wKiDePj6+rXTjcGCmx7FfH/Dhjv9vWT5vqeO7tzabY8FVVVVVUVG+pFRVFVYoqqL2zd6vT39 3dZ5eTUs5gb0GRJeGAhuiFirkF1N4A2x235SS3YXabrgMB0m3SBsFVBVAWFgMrAsBkEgMKkp AQqoqrIqxVbAtVVSK2BlgYwqqqqxVVWwoS5GIYDCDhVVaWqq0wDJjCq6ZOnGaDIJBtMdMEza BmqRW+r3IHLXVbStPzDRfDPozwvwYc7RlJ2iJ57nqPWIm5x3FpmJ/iERpAFymBB/33+fz3+R tRGmuKUx27eXw5Um3G6TrleTBykJ5o40mCoyUiyilsVmxzpCTAWt3ofmAYeeWFA7X1d3dGcq uMD6eg7DwQ5kKe3x5kAAez+8QSAB1PjbuABnVn23pevhd4+Lu9L6cVKubbjj2xao76DYtaYX tF6GHYhiwwwSO6boSJzUqkgHFAMTaHOaSEN13FZ2sxRyX3/edbgUyrWVNxqVJCa1s2cLZN2c 68bk9zbqaznZejkcGE3OXjXrTyJ9nq35vB4PVeqs7oXGmZ9RGfr8R38Ybs/l2lw+BB7v3lBd 2EkCIEQlDkyYwFiwFWCgCXhnM0M6S4jRREVUVVEUw5TKTFM1MsJiYzZAw1gZ8bJJt23DCChB 1hYCkImO07rICqsevzZ3nk50wwhWrky1hEqgk5HjWFF8EUm1Tn2Rj7UekgYcRs1pN3RjVVVU B5WxvcW/o8H2dPkSE27ejebanmSBrjki5joCcN3Q8OkNg6p6QgBvW9o+j5S9nHXPTGyUQKW2 FsO1FdvR2pkxIGHhwt+yjRjt6LJhti0b3kWt1WLrdkQN0xswas0gbqgT78NntfieOXGwbikh sN6kNWEiUzbAEADvIacHMEDBOTdCQknU7FV1mFWS4g5yFlQrZwNmTqdCQMpz47eW+SSc2vCq 5nXs52rKETAo3dOOB2HMjKd/C2mqlGdlWVI3JCddqowvlWnSX44CC3ca0qi0wYzTml7MuGV5 CVUhNuO0ybTS+Suq7TaaOloQM8oUjskK3c8fLF8TjllpmjUw4tGRdXR8rWAFla3qFBcxiakP HYxoTMtearv+LuSKcKEg9veB5A== --=-=-=-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 14:40:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A860A16A4CE; Mon, 30 Aug 2004 14:40:44 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF5D943D3F; Mon, 30 Aug 2004 14:40:43 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i7UEegM6033788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Aug 2004 18:40:42 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i7UEefoZ033787; Mon, 30 Aug 2004 18:40:41 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Mon, 30 Aug 2004 18:40:41 +0400 From: Gleb Smirnoff To: Robert Watson Message-ID: <20040830144041.GA33772@cell.sick.ru> References: <20040830095729.GD30701@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i cc: "Bjoern A. Zeeb" cc: FreeBSD current mailing list Subject: Re: mutex Giant not owned at /usr/src/sys/kern/vfs_vnops.c:120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 14:40:44 -0000 On Mon, Aug 30, 2004 at 10:35:05AM -0400, Robert Watson wrote: R> > B> > This causes Giant to be acquired in the event we enter the linker code R> > B> > (and hence VFS code) via netgraph ngc_send(). It should be safe in this R> > B> > context as we enter protocol send routines without mutexes held (i.e., why R> > B> > we're also able to do blocking memory allocation here.) R> > B> R> > B> please commit. R> > R> > I think Giant should be acquired in linker_load_module(), and this way R> > we will prevent this panic in other codepaths. For example in R> > vfs_mount.c, when vfs will be Giant-free. Have I missed something? R> R> Well, one of the primary reasons the linker needs Giant here is its use of R> VFS. I think for now I'd like to acquire Giant in netgraph so as to R> expose the use of Giant in that piece of the network stack in the calling R> code. We might want to add GIANT_REQUIRED assertions in the linker code R> to make sure we trigger assertions even if the linker doesn't hit VFS to R> make sure potentially hitting Giant is caught. OK. Then commit it pls. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 14:45:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC45C16A4CF; Mon, 30 Aug 2004 14:45:22 +0000 (GMT) Received: from av7-1-sn1.fre.skanova.net (av7-1-sn1.fre.skanova.net [81.228.11.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E5B343D39; Mon, 30 Aug 2004 14:45:13 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av7-1-sn1.fre.skanova.net (Postfix, from userid 502) id F24AC37EDA; Mon, 30 Aug 2004 16:45:09 +0200 (CEST) Received: from smtp3-1-sn1.fre.skanova.net (smtp3-1-sn1.fre.skanova.net [81.228.11.163]) by av7-1-sn1.fre.skanova.net (Postfix) with ESMTP id E0F1E37E70; Mon, 30 Aug 2004 16:45:09 +0200 (CEST) Received: from gadget (h130n1fls11o822.telia.com [213.64.66.130]) by smtp3-1-sn1.fre.skanova.net (Postfix) with ESMTP id B9EE537E5F; Mon, 30 Aug 2004 16:45:09 +0200 (CEST) From: "Daniel Eriksson" To: "'Lukas Ertl'" , Date: Mon, 30 Aug 2004 16:45:10 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcSLxU/8rJMyEu00TqmQagezZGSQFQC0H+oQAAJUN0A= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: RE: PLEASE TEST: IPI deadlock avoidance patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 14:45:23 -0000 I wrote: > Running the exact same test under a kernel compiled without > SMP worked without any problems. Hmm, after running the test a second time, I actually got a crc error even when using a UP kernel. The test set is 9GB+ in ~270 files. With SMP I seem to get around 10% corrupt files after simply making a duplicate of the folder. With UP I have gotten 1 corrupt file in 2 tries (~550 files copied). I'll report back here after I have tested "classic" vinum. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 14:59:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 569B716A4CE for ; Mon, 30 Aug 2004 14:59:45 +0000 (GMT) Received: from sana.init-main.com (104.194.138.210.bn.2iij.net [210.138.194.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5269343D5A for ; Mon, 30 Aug 2004 14:59:44 +0000 (GMT) (envelope-from takawata@init-main.com) Received: from init-main.com (localhost [127.0.0.1]) by sana.init-main.com (8.13.1/8.13.1) with ESMTP id i7UEweiu045002; Mon, 30 Aug 2004 23:58:42 +0900 (JST) (envelope-from takawata@init-main.com) Message-Id: <200408301458.i7UEweiu045002@sana.init-main.com> To: Vladimir Grebenschikov From: takawata@jp.freebsd.org In-reply-to: Your message of "Mon, 30 Aug 2004 11:58:47 +0400." <1093852727.864.11.camel@localhost> Date: Mon, 30 Aug 2004 23:58:40 +0900 Sender: takawata@init-main.com cc: freebsd-current@freebsd.org Subject: Re: acpi_video on SONY VAIO PCG-Z1 [was: acpi_video users needed] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 14:59:45 -0000 In message <1093852727.864.11.camel@localhost>, Vladimir Grebenschikov $B$5$s$$$o(B $B$/(B: > >--=-FZrzlYyzm566zgo9aokI >Content-Type: text/plain >Content-Transfer-Encoding: 7bit > > >Hi > >Is any chance to make acpi_video work on SONY VAIO PCG-Z1 ? >acpi_video.ko loads well, but does not report anything, and does not add >hw.acpi.video subtree. > >Please advise. Because the ACPI device object has not enough interfaces to get the acpi_video driver work. Acpi_video driver does not check PCI device class: it checks the interfaces instead. You don't need to bother attaching acpi_video driver. ###### Device (VID0) { Name (_ADR, 0x00) OperationRegion (VIDR, PCI_Config, 0x4C, 0x04) Field (VIDR, ByteAcc, NoLock, Preserve) { SSID, 32 } Device (CRT) { Name (_ADR, 0x0100) } Device (LCD) { Name (_ADR, 0x0110) } Device (TV) { Name (_ADR, 0x0200) } } } ##### From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 15:02:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E641B16A4CE for ; Mon, 30 Aug 2004 15:02:01 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B08943D53 for ; Mon, 30 Aug 2004 15:02:01 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7UF1vB7069139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Aug 2004 18:01:58 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i7UF225D064261; Mon, 30 Aug 2004 18:02:02 +0300 (EEST) (envelope-from ru) Date: Mon, 30 Aug 2004 18:02:02 +0300 From: Ruslan Ermilov To: Dennis Kj?r Jensen Message-ID: <20040830150202.GB65719@ip.net.ua> References: <0be501c48e94$ba63c060$87075050@signoutscraptop> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <0be501c48e94$ba63c060$87075050@signoutscraptop> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA2 problems booting HP NetServer E60 both ACPI and non-ACPI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 15:02:02 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 30, 2004 at 03:24:49PM +0200, Dennis Kj?r Jensen wrote: > I have console dumps from boot both with and without ACPI enabled on > http://signout.dk/FreeBSD/20040830-E60 >=20 > If AGP is in the kernel the system simply halts during boot after detecti= ng > agp0. > On a generic 4.7 kernel this wasn't a problem. On 4.8 it is. > Somewhere between 4.7 and 4.8 something bad happened. I suspect this to be > the same issue. >=20 > Please advise. I currently run 4.7-RELEASE-p27 on the machine. >=20 You can disable AGP with hints on recent -CURRENT versions. Set hint.agp.0.disabled=3D1 while in the loader(8), and see if that helps. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBM0FqqRfpzJluFF4RAvzYAJ0RQ/mzE8eaNKvYITUlqJ++JJEmUwCdHa1/ RMbAw9rOVJy/AYKXgXgXQic= =qcNK -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 15:02:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17F5716A4D0 for ; Mon, 30 Aug 2004 15:02:23 +0000 (GMT) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B35E43D55 for ; Mon, 30 Aug 2004 15:02:22 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.12.11/8.12.11/NinthNine) with SMTP id i7UF2L7f030909 for ; Tue, 31 Aug 2004 00:02:21 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Tue, 31 Aug 2004 00:02:21 +0900 (JST) Message-Id: <200408301502.i7UF2L7f030909@sakura.ninth-nine.com> From: Norikatsu Shigemura To: freebsd-current@FreeBSD.org In-Reply-To: <200408301245.i7UCjZrE027532@sakura.ninth-nine.com> References: <200408301245.i7UCjZrE027532@sakura.ninth-nine.com> X-Mailer: Sylpheed version 0.9.12-gtk2-20040622 (GTK+ 2.4.9; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (sakura.ninth-nine.com [219.127.74.121]); Tue, 31 Aug 2004 00:02:21 +0900 (JST) Subject: Re: ping6 -f panic with mpsafenet=1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 15:02:23 -0000 On Mon, 30 Aug 2004 21:45:35 +0900 (JST) Norikatsu Shigemura wrote: > I contacted a panic on current with debug.mpsafenet=1. > - - - - - - - - - - > # ping6 -f othermachine (snip) INET6 with FAST_IPSEC will contact panic. But INET6 with KAME_IPSEC is safe, because forced disable mpsafenet on boot. I tried to use INET6 without FAST_IPSEC/KAME_IPSEC. I didn't contact panic... Maybe safe... Probabry... :-). From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 15:07:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1C4D16A4CE for ; Mon, 30 Aug 2004 15:07:36 +0000 (GMT) Received: from web50603.mail.yahoo.com (web50603.mail.yahoo.com [206.190.38.90]) by mx1.FreeBSD.org (Postfix) with SMTP id 8386243D41 for ; Mon, 30 Aug 2004 15:07:36 +0000 (GMT) (envelope-from kstailey@yahoo.com) Message-ID: <20040830135311.11040.qmail@web50603.mail.yahoo.com> Received: from [69.138.247.171] by web50603.mail.yahoo.com via HTTP; Mon, 30 Aug 2004 06:53:11 PDT Date: Mon, 30 Aug 2004 06:53:11 -0700 (PDT) From: Kenneth Stailey To: freebsd-current@freebsd.org In-Reply-To: <20040829213449.GA33843@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 15:07:37 -0000 --- David O'Brien wrote: > On Sun, Aug 29, 2004 at 07:10:44AM -0700, Kenneth Stailey wrote: > > Can a one-line example of how to invoke adduser to add new accounts like > > "proxy" be added to /usr/src/UPDATING? That way people could just > > cut-and-paste the accounts into place when upgrading. > > I've been trying to get RE@ to embelish this script and commit it to > RELENG_5 to help with things like this: > > $ cat /usr/src/upgrade4ot5.sh > #! /bin/sh > > # Some people don't read hier(9) and symlink /tmp and /var/tmp, > # and /tmp can get cleared... > > SENTINEL=/$(basename %0) > > if [ ! -f ${SENTINEL}.kernel-done ]; then > make buildworld && make buildkernel > # install /boot/device.hints > make installkernel > # install new loader > touch ${SENTINEL}.kernel-done > reboot > else > mergemaster -p > make installworld > mergemaster -i > rm ${SENTINEL}.* > reboot > endif mergemasters is gross. Have you ever tried to run it on an 80-column display? I absolutely hate the "left" "right" stuff. You push the "l" with your right hand and the "r" with your left for crying out loud. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 15:09:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 521AF16A4CE for ; Mon, 30 Aug 2004 15:09:56 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id A41AB43D48 for ; Mon, 30 Aug 2004 15:09:55 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so77756rnl for ; Mon, 30 Aug 2004 08:09:55 -0700 (PDT) Received: by 10.38.83.80 with SMTP id g80mr310749rnb; Mon, 30 Aug 2004 08:09:55 -0700 (PDT) Received: by 10.38.75.25 with HTTP; Mon, 30 Aug 2004 08:09:55 -0700 (PDT) Message-ID: <790a9fff040830080978bcefb7@mail.gmail.com> Date: Mon, 30 Aug 2004 10:09:55 -0500 From: Scot Hetzel To: Ken Smith In-Reply-To: <20040829151021.GA43674@bobbi.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040829151021.GA43674@bobbi.cse.buffalo.edu> cc: freebsd-current@freebsd.org cc: sos@freebsd.org Subject: Re: FreeBSD 5.3-BETA2 Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Scot Hetzel List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 15:09:56 -0000 On Sun, 29 Aug 2004 11:10:21 -0400, Ken Smith wrote: We are missing one known problem with the release: > Known issues in this release: > - the ATA driver may fail in unexpected ways on some hardware, this has been fixed in the 6.0-CURRENT ATA driver. see the following message for my crash info: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=1790822+0+archive/2004/freebsd-current/20040829.freebsd-current I have no problems with the 6.0-CURRENT ATA driver in my 5.3 kernel. Could someone MFC these changes to the RELENG_5 branch. Thanks, Scot From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 15:17:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9956216A549; Mon, 30 Aug 2004 15:17:42 +0000 (GMT) Received: from av2-1-sn3.vrr.skanova.net (av2-1-sn3.vrr.skanova.net [81.228.9.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 261C043D4C; Mon, 30 Aug 2004 15:17:39 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av2-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 53C6137E7F; Mon, 30 Aug 2004 17:17:38 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av2-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 41EB137E4C; Mon, 30 Aug 2004 17:17:38 +0200 (CEST) Received: from gadget (h130n1fls11o822.telia.com [213.64.66.130]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id F275838004; Mon, 30 Aug 2004 17:17:37 +0200 (CEST) From: "Daniel Eriksson" To: Date: Mon, 30 Aug 2004 17:17:35 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C48EB5.3E33BF60" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcSOpHpLYDw92kl8Rc6HHA/r6a8q2g== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 cc: 'Pawel Jakub Dawidek' cc: =?iso-8859-1?Q?'S=F8ren_Schmidt'?= Subject: ataraid + geom_stripe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 15:17:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C48EB5.3E33BF60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit A few days ago I decided to try to switch from gvinum in RAID-0 mode to geom_stripe on one of my arrays (4 x 36GB SCSI). Unfortunately I never managed to get it to work since the machine protested loudly and crashed all of my ataraid arrays whenever geom_stripe tried to start up its array. This was on a 6-CURRENT system compiled from sources dated 2004.08.26.(something). Has anyone tried to use both ataraid and geom_stripe on the same machine? I also use gvinum on this machine, but it is not loaded during boot so it should not affect this. Attached is a dmesg from the machine (but with a slightly newer kernel, no other changes were made though other than to remove geom_stripe). It should provide info on what hardware is used. Here's how it looked on the console when I tried it 3 days ago. The ataraid discs all hang off of two HighPoint RocketRAID 454 cards. Once all the atariad arrays had been crashed I could delete and re-create them without any problems. I didn't dare to try to access them however (live data on the filesystems). ar0: 476950MB [60802/255/63] status: READY subdisks: disk0 READY on ad4 at ata2-master disk1 READY on ad5 at ata2-slave ar1: 478744MB [61031/255/63] status: READY subdisks: disk0 READY on ad6 at ata3-master disk1 READY on ad7 at ata3-slave ar2: 388962MB [49585/255/63] status: READY subdisks: disk0 READY on ad9 at ata4-slave disk1 READY on ad8 at ata4-master ar3: 228946MB [29186/255/63] status: READY subdisks: disk0 READY on ad23 at ata11-slave disk1 READY on ad24 at ata12-master Waiting 5 seconds for SCSI devices to settle sa0 at ahc0 bus 0 target 5 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 10.000MB/s transfers (10.000MHz, offset 15) da0 at ahc0 bus 0 target 10 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) da1 at ahc0 bus 0 target 11 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da1: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) da2 at ahc0 bus 0 target 12 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da2: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) da3 at ahc0 bus 0 target 13 lun 0 da3: Fixed Direct Access SCSI-3 device da3: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da3: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) Mounting root from ufs:/dev/ad0s1a Enter full pathname of shell or RETURN for /bin/sh: # kldload geom_stripe # GEOM_STRIPE: Device testraid created (id=3167252550). GEOM_STRIPE: Disk da3 attached to racingraid. GEOM_STRIPE: Disk da2 attached to racingraid. GEOM_STRIPE: Disk da1 attached to racingraid. GEOM_STRIPE: Disk da0 attached to racingraid. GEOM_STRIPE: Device testraid activated. Interrupt storm detected on "irq16: atapci0+++"; throttling interrupt source ad24: TIMEOUT - READ_DMA retrying (2 retries left) LBA=234441657 ad24: TIMEOUT - READ_DMA retrying (1 retry left) LBA=234441657 ad24: FAILURE - READ_DMA timed out ar3: ERROR - array broken ad8: TIMEOUT - READ_DMA retrying (2 retries left) LBA=398297097 ad8: TIMEOUT - READ_DMA retrying (1 retry left) LBA=398297097 ad8: FAILURE - READ_DMA timed out ar2: ERROR - array broken ad7: TIMEOUT - READ_DMA retrying (2 retries left) LBA=490234761 ad7: TIMEOUT - READ_DMA retrying (1 retry left) LBA=490234761 ad7: FAILURE - READ_DMA timed out ar1: ERROR - array broken ad5: TIMEOUT - READ_DMA retrying (2 retries left) LBA=488397177 ad5: TIMEOUT - READ_DMA retrying (1 retry left) LBA=488397177 ad5: FAILURE - READ_DMA timed out ar0: ERROR - array broken /Daniel Eriksson ------=_NextPart_000_0000_01C48EB5.3E33BF60 Content-Type: application/octet-stream; name="dmesg.boot" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.boot" Copyright (c) 1992-2004 The FreeBSD Project.=0A= Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994=0A= The Regents of the University of California. All rights reserved.=0A= FreeBSD 6.0-CURRENT #0: Sat Aug 28 16:54:46 CEST 2004=0A= daniel@xxx.xxx.xxx:/usr/obj/usr/src/sys/FORTIFY=0A= Timecounter "i8254" frequency 1193182 Hz quality 0=0A= CPU: AMD Athlon(TM) XP 2500+ (1999.78-MHz 686-class CPU)=0A= Origin =3D "AuthenticAMD" Id =3D 0x6a0 Stepping =3D 0=0A= = Features=3D0x383fbff=0A= AMD Features=3D0xc0400000=0A= real memory =3D 1342156800 (1279 MB)=0A= avail memory =3D 1304903680 (1244 MB)=0A= ACPI APIC Table: =0A= ioapic0: Changing APIC ID to 2=0A= ioapic0 irqs 0-23 on motherboard=0A= npx0: [FAST]=0A= npx0: on motherboard=0A= npx0: INT 16 interface=0A= acpi0: on motherboard=0A= acpi0: Power Button (fixed)=0A= Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000=0A= acpi_timer0: <32-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0=0A= cpu0: on acpi0=0A= acpi_button0: on acpi0=0A= pcib0: port 0xcf8-0xcff on acpi0=0A= pci0: on pcib0=0A= agp0: mem = 0xf8000000-0xfbffffff at device 0.0 on pci0=0A= pcib1: at device 1.0 on pci0=0A= pci1: on pcib1=0A= pci1: at device 0.0 (no driver attached)=0A= atapci0: port = 0xb400-0xb4ff,0xb800-0xb803,0xd000-0xd007,0xd400-0xd403,0xd800-0xd807 = irq 16 at device 10.0 on pci0=0A= ata2: channel #0 on atapci0=0A= ata3: channel #1 on atapci0=0A= atapci1: port = 0x9800-0x98ff,0xa000-0xa003,0xa400-0xa407,0xa800-0xa803,0xb000-0xb007 = irq 16 at device 10.1 on pci0=0A= ata4: channel #0 on atapci1=0A= ata5: channel #1 on atapci1=0A= atapci2: port = 0x8800-0x887f,0x9000-0x900f,0x9400-0x943f mem = 0xed000000-0xed01ffff,0xed800000-0xed800fff irq 19 at device 11.0 on pci0=0A= atapci2: failed: rid 0x20 is memory, requested 4=0A= ata6: channel #0 on atapci2=0A= ata7: channel #1 on atapci2=0A= ata8: channel #2 on atapci2=0A= ata9: channel #3 on atapci2=0A= ahc0: port 0x8400-0x84ff mem = 0xec800000-0xec800fff irq 19 at device 12.0 on pci0=0A= ahc0: [GIANT-LOCKED]=0A= aic7892: Ultra160 Wide Channel A, SCSI Id=3D7, 32/253 SCBs=0A= atapci3: port = 0x6800-0x68ff,0x7000-0x7003,0x7400-0x7407,0x7800-0x7803,0x8000-0x8007 = irq 16 at device 13.0 on pci0=0A= ata10: channel #0 on atapci3=0A= ata11: channel #1 on atapci3=0A= atapci4: port = 0x5000-0x50ff,0x5400-0x5403,0x5800-0x5807,0x6000-0x6003,0x6400-0x6407 = irq 16 at device 13.1 on pci0=0A= ata12: channel #0 on atapci4=0A= ata13: channel #1 on atapci4=0A= atapci5: port = 0x3000-0x30ff,0x3400-0x340f,0x3800-0x3803,0x4000-0x4007,0x4400-0x4403,0x4= 800-0x4807 irq 20 at device 15.0 on pci0=0A= ata14: channel #0 on atapci5=0A= ata15: channel #1 on atapci5=0A= atapci6: port = 0x2800-0x280f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 irq 20 at device 15.1 = on pci0=0A= ata0: channel #0 on atapci6=0A= ata1: channel #1 on atapci6=0A= isab0: at device 17.0 on pci0=0A= isa0: on isab0=0A= vr0: port 0x1000-0x10ff mem = 0xeb800000-0xeb8000ff irq 23 at device 18.0 on pci0=0A= miibus0: on vr0=0A= rlphy0: on miibus0=0A= rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto=0A= vr0: Ethernet address: 00:0e:a6:1f:29:1e=0A= vr0: [GIANT-LOCKED]=0A= re0: port 0x800-0x8ff mem = 0xeb000000-0xeb0000ff irq 18 at device 19.0 on pci0=0A= miibus1: on re0=0A= rgephy0: on miibus1=0A= rgephy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, = 1000baseTX-FDX, auto=0A= re0: Ethernet address: 00:50:fc:f8:c6:81=0A= re0: [GIANT-LOCKED]=0A= speaker0 port 0x61 on acpi0=0A= fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on = acpi0=0A= fd0: <1440-KB 3.5" drive> on fdc0 drive 0=0A= sio0: configured irq 4 not in bitmap of probed irqs 0=0A= sio0: port may not be enabled=0A= sio0 port 0x3f8-0x3ff irq 4 on acpi0=0A= sio0: type 16550A, console=0A= atkbdc0: port 0x64,0x60 irq 1 on acpi0=0A= atkbd0: irq 1 on atkbdc0=0A= kbd0 at atkbd0=0A= atkbd0: [GIANT-LOCKED]=0A= orm0: at iomem 0xc0000-0xcafff on isa0=0A= pmtimer0 on isa0=0A= ppc0: parallel port not found.=0A= sc0: at flags 0x100 on isa0=0A= sc0: VGA <16 virtual consoles, flags=3D0x100>=0A= sio1: configured irq 3 not in bitmap of probed irqs 0=0A= sio1: port may not be enabled=0A= vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0=0A= Timecounter "TSC" frequency 1999783189 Hz quality 800=0A= Timecounters tick every 1.000 msec=0A= ipfw2 initialized, divert enabled, rule-based forwarding disabled, = default to accept, logging unlimited=0A= ad0: 114473MB [232581/16/63] at ata0-master UDMA100=0A= ad1: 114473MB [232581/16/63] at ata0-slave UDMA100=0A= ad2: 117800MB [239340/16/63] at ata1-master = UDMA100=0A= ad3: 117800MB [239340/16/63] at ata1-slave = UDMA100=0A= ad4: 238475MB [484521/16/63] at = ata2-master UDMA100=0A= ad5: 238475MB [484521/16/63] at = ata2-slave UDMA100=0A= ad6: 239372MB [486344/16/63] at ata3-master = UDMA133=0A= ad7: 239372MB [486344/16/63] at ata3-slave = UDMA133=0A= ad8: 194481MB [395136/16/63] at ata4-master = UDMA133=0A= ad9: 194481MB [395136/16/63] at ata4-slave = UDMA133=0A= ad10: 194481MB [395136/16/63] at ata5-master = UDMA133=0A= ad11: 239372MB [486344/16/63] at ata5-slave = UDMA133=0A= ad12: 239372MB [486344/16/63] at ata6-master = SATA150=0A= ad14: 238475MB [484521/16/63] at = ata7-master SATA150=0A= ad20: 117800MB [239340/16/63] at = ata10-master UDMA100=0A= ad21: 117800MB [239340/16/63] at ata10-slave = UDMA100=0A= ad22: 117246MB [238216/16/63] at ata11-master = UDMA133=0A= ad23: 117246MB [238216/16/63] at ata11-slave = UDMA133=0A= ad24: 114473MB [232581/16/63] at = ata12-master UDMA100=0A= ad25: 117800MB [239340/16/63] at ata12-slave = UDMA100=0A= ad26: 26059MB [52946/16/63] at ata13-master = UDMA66=0A= ar0: 476950MB [60802/255/63] status: READY subdisks:=0A= disk0 READY on ad4 at ata2-master=0A= disk1 READY on ad5 at ata2-slave=0A= ar1: 478744MB [61031/255/63] status: READY subdisks:=0A= disk0 READY on ad6 at ata3-master=0A= disk1 READY on ad7 at ata3-slave=0A= ar2: 388962MB [49585/255/63] status: READY subdisks:=0A= disk0 READY on ad9 at ata4-slave=0A= disk1 READY on ad8 at ata4-master=0A= ar3: 228946MB [29186/255/63] status: READY subdisks:=0A= disk0 READY on ad23 at ata11-slave=0A= disk1 READY on ad24 at ata12-master=0A= Waiting 5 seconds for SCSI devices to settle=0A= sa0 at ahc0 bus 0 target 5 lun 0=0A= sa0: Removable Sequential Access SCSI-2 device =0A= sa0: 10.000MB/s transfers (10.000MHz, offset 15)=0A= da0 at ahc0 bus 0 target 10 lun 0=0A= da0: Fixed Direct Access SCSI-3 device =0A= da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged = Queueing Enabled=0A= da0: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C)=0A= da1 at ahc0 bus 0 target 11 lun 0=0A= da1: Fixed Direct Access SCSI-3 device =0A= da1: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged = Queueing Enabled=0A= da1: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C)=0A= da2 at ahc0 bus 0 target 12 lun 0=0A= da2: Fixed Direct Access SCSI-3 device =0A= da2: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged = Queueing Enabled=0A= da2: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C)=0A= da3 at ahc0 bus 0 target 13 lun 0=0A= da3: Fixed Direct Access SCSI-3 device =0A= da3: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged = Queueing Enabled=0A= da3: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C)=0A= Mounting root from ufs:/dev/ad0s1a=0A= =0A= ------=_NextPart_000_0000_01C48EB5.3E33BF60-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 15:30:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7211B16A4CE for ; Mon, 30 Aug 2004 15:30:41 +0000 (GMT) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0A5743D31 for ; Mon, 30 Aug 2004 15:30:40 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from buffy.york.ac.uk (buffy.york.ac.uk [144.32.226.160]) by mail-gw0.york.ac.uk (8.12.10/8.12.10) with ESMTP id i7UFUc6q019859; Mon, 30 Aug 2004 16:30:38 +0100 (BST) Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.1/8.12.11) with ESMTP id i7UFUcP6030717; Mon, 30 Aug 2004 16:30:38 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.1/8.12.11/Submit) id i7UFUcba030716; Mon, 30 Aug 2004 16:30:38 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: RoKlein@roklein.de In-Reply-To: <200408281223.22399.RoKlein@roklein.de> References: <200408281223.22399.RoKlein@roklein.de> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1093879837.30583.7.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 30 Aug 2004 16:30:37 +0100 X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA hangs on Acer TM290 series Laptop X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 15:30:41 -0000 On Sat, 2004-08-28 at 11:23, Robert Klein wrote: > Hi, > > I tried to boot 5.3-BETA on my TM291 (Centrino, "hotpluggable" > DVD/CDRW-Combo, bg2200 WLAN). > > It hangs after the first few lines of boot messages and has to be > rebooted the hard way (press power-off for four seconds).. Ah, yes. This problem. Sadly, it seems almost all new laptops that I have played with suffer from this... Pretty much every new Toshiba or Centrino laptop I've tried, anyway. Try switching any "Plug and Play OS" type options in your BIOS to "No" or similar. This fixes at least one laptop I've tried. Also, try breaking to the loader prompt at the Beastie menu, and typing set hw.pci.enable_io_modes="1" boot Please test one, then the other, then both. Hopefully at least one of the combinations will work. Please can you report back here with the results? Sadly, I haven't been able to get hold of an affected laptop long enough to narrow the problem down further. Gavin > --- "boot -v" screen messages --- > cmdreg=0x0006, statreg=0x2090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x3584, revid=0x02 > bus=0, slot=0, func=1 > class=08-80-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x0080, cachelnsz=0 (dwords) > lattimer=0x00 (0ns), mingnt=0x00 (0ns), maxlat=0x00 (0 ns) > found-> vendor=0x8086, dev=0x3585, revid=0x02 > bus=0, slot=0, func=3 > class=08-80-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0006, statreg=0x0080, cachelnsz=0 (dwords) > lattimer=0x00 (0ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > map[10]: type 3, range 32, base b0000000, size 27, enabled > map[14]: type 1, range 32, base f0000000, size 19, enabled > map[18]: type 4, range 32, base 0000e000, size 3, enabled > $PIR: 0:2 INTA routed to IRQ 11 > found-> vendor=0x8086, dev=0x3582, revid=0x02 > bus=0, slot=2, func=0 > class=03-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=11 > powerspec 1 supports D0 D1 D3 current D0 > map[10]: type 3, range 32, base 00000000, size 27, memory > disabled > > --- "boot" screen messages --- > GDB: no debug ports present > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2004 The FreeBSD Project. > Copyight (x) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, > 1993, 1994 > The Regents of the University of California. All rights > reserved. > FreeBSD 5.3-BETA1 #0: Fri Aug 27 06:47:29 UTC 2004 > root@mango.internal.hasta.se:/usr/obj/usr/src/sys/GENERIC > WARNING: WITNESS option enabled, expect reduced performance. > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: Intel(R) Pentium(R) M processor 1400 MHz (1398.82-MHz > 686-class CPU) > Origin = "GenuineIntel" ID = 0x695 Stepping = 5 > Features=0xa7e9f9bf > real memory = 520028160 (495 MB) > avail memory = 495034368 (472 MB) > npx0: [FAST > npx0: on motherboard > npx0: INT 16 interface > pcib0: pcibus 0 on motherboard > pir0: on motherboard > pci0: on pcib0 > _______________________________________________ > 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 Aug 30 15:58:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 625BD16A4CE for ; Mon, 30 Aug 2004 15:58:03 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98BF543D49 for ; Mon, 30 Aug 2004 15:58:02 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 79364 invoked from network); 30 Aug 2004 15:56:08 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Aug 2004 15:56:08 -0000 Message-ID: <41334E8F.377FFD80@freebsd.org> Date: Mon, 30 Aug 2004 17:58:07 +0200 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Oliver Brandmueller References: <20040827084306.GB74653@e-Gitt.NET> <412F276A.6080807@freebsd.org> <20040827141354.GC74653@e-Gitt.NET> <412F5307.5040005@freebsd.org> <20040830103216.GA51110@e-Gitt.NET> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: RELENG_5 ipfw problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 15:58:03 -0000 Oliver Brandmueller wrote: > > Hello. > > On Fri, Aug 27, 2004 at 05:28:07PM +0200, Andre Oppermann wrote: > > It detects a missing dummynet because it has to pass on configuration > > options to dummynet and it can only do that if dummynet is loaded. For > > FORWARD this is not the case. Here the ipfw code just tags the packet > > for later treatment. And that later treatment is scattered through a > > few places where we have to inspect each packet it carries this tag. > > > > >- How to enable it? > > > > Put "option IPFIREWALL_FORWARD" into your kernel configuration file and > > recompile. > > I do now have IPFIREWALL and IPFIREWALL_FORWARD in the kernel and am not > loading it as a module anymore. The dmesg now states: > > ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to deny, logging disabled > > OK, fine. But do still have a problem: > > The rule is loaded an matched. Instead of just dropping the packet (as > before, when rule based forwarding was disabled) the pakets are now > accepted, but the forwarding does not work: > > 00200 fwd 192.168.25.1 tcp from 192.168.25.5 25 to 213.XXX.XXX.0/24 > > Is still see this on em0 (the public interface in the destination > network metioned in rule 200): > > 12:26:09.674295 IP 192.168.25.5.smtp > 213.XXX.XXX.XXX.41424: S > 3583621218:3583621218(0) ack 3993419222 win 65535 > > # ipfw show > 00200 2694 118536 fwd 192.168.25.1 tcp from 192.168.25.5 25 to 213.XXX.XXX.0/24 > > packets are accepted, but not forwarded. Can anyone else reproduce this? Ok, it seems you suffer from a small logic change I made when redoing the ipfw fwd option. This was supposed to prevent foot-shooting but also prevents your setup from working. Try the attached patch (probably white- space mangled). -- Andre Index: ip_output.c =================================================================== RCS file: /home/ncvs/src/sys/netinet/ip_output.c,v retrieving revision 1.229 diff -u -p -r1.229 ip_output.c --- ip_output.c 27 Aug 2004 15:39:34 -0000 1.229 +++ ip_output.c 30 Aug 2004 15:55:42 -0000 @@ -710,7 +710,7 @@ spd_done: /* Or forward to some other address? */ fwd_tag = m_tag_find(m, PACKET_TAG_IPFORWARD, NULL); if (fwd_tag) { - if (!in_localip(ip->ip_src) && !in_localaddr(ip->ip_dst)) { + if (!in_localip(ip->ip_src)) { dst = (struct sockaddr_in *)&ro->ro_dst; bcopy((fwd_tag+1), dst, sizeof(struct sockaddr_in)); m->m_flags |= M_SKIP_FIREWALL; From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 15:58:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5016016A4CE; Mon, 30 Aug 2004 15:58:08 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 809EC43D46; Mon, 30 Aug 2004 15:58:07 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i7UFw57a000502; Mon, 30 Aug 2004 17:58:05 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <41334E6D.4030601@DeepCore.dk> Date: Mon, 30 Aug 2004 17:57:33 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eriksson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: freebsd-current@FreeBSD.org cc: 'Pawel Jakub Dawidek' Subject: Re: ataraid + geom_stripe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 15:58:08 -0000 Daniel Eriksson wrote: > A few days ago I decided to try to switch from gvinum in RAID-0 mode to= > geom_stripe on one of my arrays (4 x 36GB SCSI). Unfortunately I never > managed to get it to work since the machine protested loudly and crashe= d all > of my ataraid arrays whenever geom_stripe tried to start up its array. = This > was on a 6-CURRENT system compiled from sources dated > 2004.08.26.(something). >=20 > Has anyone tried to use both ataraid and geom_stripe on the same machin= e? >=20 > I also use gvinum on this machine, but it is not loaded during boot so = it > should not affect this. >=20 > Attached is a dmesg from the machine (but with a slightly newer kernel,= no > other changes were made though other than to remove geom_stripe). It sh= ould > provide info on what hardware is used. >=20 > Here's how it looked on the console when I tried it 3 days ago. The ata= raid > discs all hang off of two HighPoint RocketRAID 454 cards. Once all the > atariad arrays had been crashed I could delete and re-create them witho= ut > any problems. I didn't dare to try to access them however (live data on= the > filesystems). >=20 > ar0: 476950MB [60802/255/63] status: READY subdisks: > disk0 READY on ad4 at ata2-master > disk1 READY on ad5 at ata2-slave > ar1: 478744MB [61031/255/63] status: READY subdisks: > disk0 READY on ad6 at ata3-master > disk1 READY on ad7 at ata3-slave > ar2: 388962MB [49585/255/63] status: READY subdisks: > disk0 READY on ad9 at ata4-slave > disk1 READY on ad8 at ata4-master > ar3: 228946MB [29186/255/63] status: READY subdisks: > disk0 READY on ad23 at ata11-slave > disk1 READY on ad24 at ata12-master > Waiting 5 seconds for SCSI devices to settle > sa0 at ahc0 bus 0 target 5 lun 0 > sa0: Removable Sequential Access SCSI-2 device= =20 > sa0: 10.000MB/s transfers (10.000MHz, offset 15) > da0 at ahc0 bus 0 target 10 lun 0 > da0: Fixed Direct Access SCSI-3 device=20 > da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queuei= ng > Enabled > da0: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) > da1 at ahc0 bus 0 target 11 lun 0 > da1: Fixed Direct Access SCSI-3 device=20 > da1: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queuei= ng > Enabled > da1: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) > da2 at ahc0 bus 0 target 12 lun 0 > da2: Fixed Direct Access SCSI-3 device=20 > da2: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queuei= ng > Enabled > da2: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) > da3 at ahc0 bus 0 target 13 lun 0 > da3: Fixed Direct Access SCSI-3 device=20 > da3: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queuei= ng > Enabled > da3: 35003MB (71687340 512 byte sectors: 255H 63S/T 4462C) > Mounting root from ufs:/dev/ad0s1a > Enter full pathname of shell or RETURN for /bin/sh:=20 > # kldload geom_stripe > # GEOM_STRIPE: Device testraid created (id=3D3167252550). > GEOM_STRIPE: Disk da3 attached to racingraid. > GEOM_STRIPE: Disk da2 attached to racingraid. > GEOM_STRIPE: Disk da1 attached to racingraid. > GEOM_STRIPE: Disk da0 attached to racingraid. > GEOM_STRIPE: Device testraid activated. > Interrupt storm detected on "irq16: atapci0+++"; throttling interrupt s= ource Hmm, looks like you re triggering the throtteling code, that will lead=20 to catastophic failure as it tosses out interrupts causing this: > ad24: TIMEOUT - READ_DMA retrying (2 retries left) LBA=3D234441657 > ad24: TIMEOUT - READ_DMA retrying (1 retry left) LBA=3D234441657 > ad24: FAILURE - READ_DMA timed out > ar3: ERROR - array broken > ad8: TIMEOUT - READ_DMA retrying (2 retries left) LBA=3D398297097 > ad8: TIMEOUT - READ_DMA retrying (1 retry left) LBA=3D398297097 > ad8: FAILURE - READ_DMA timed out > ar2: ERROR - array broken > ad7: TIMEOUT - READ_DMA retrying (2 retries left) LBA=3D490234761 > ad7: TIMEOUT - READ_DMA retrying (1 retry left) LBA=3D490234761 > ad7: FAILURE - READ_DMA timed out > ar1: ERROR - array broken > ad5: TIMEOUT - READ_DMA retrying (2 retries left) LBA=3D488397177 > ad5: TIMEOUT - READ_DMA retrying (1 retry left) LBA=3D488397177 > ad5: FAILURE - READ_DMA timed out > ar0: ERROR - array broken Anyhow you would want up to date -current ATA sources as quite a few=20 problems has been solved.. -S=F8ren From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 15:58:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D74C16A4CE for ; Mon, 30 Aug 2004 15:58:19 +0000 (GMT) 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 BDD6143D2F for ; Mon, 30 Aug 2004 15:58:18 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.1/8.13.1) with ESMTP id i7UFwHEx004839 for ; Mon, 30 Aug 2004 08:58:17 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.1/8.13.1/Submit) id i7UFwH9w004838 for freebsd-current@freebsd.org; Mon, 30 Aug 2004 08:58:17 -0700 (PDT) (envelope-from david) Date: Mon, 30 Aug 2004 08:58:17 -0700 (PDT) From: David Wolfskill Message-Id: <200408301558.i7UFwH9w004838@bunrab.catwhisker.org> To: freebsd-current@freebsd.org In-Reply-To: <20040830135311.11040.qmail@web50603.mail.yahoo.com> Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 15:58:19 -0000 >Date: Mon, 30 Aug 2004 06:53:11 -0700 (PDT) >From: Kenneth Stailey >To: freebsd-current@freebsd.org >Subject: Re: suggestion for /usr/src/UPDATING >Sender: owner-freebsd-current@freebsd.org >mergemasters is gross. Have you ever tried to run it on an 80-column display? Of course; I run in in an 80x24 xterm routinely, twice/day for each of 2 machines, for well over a year. Within script(1), under screen(1). I see mergemaster as a vast improvement over what came before it. >I absolutely hate the "left" "right" stuff. You push the "l" with your right >hand and the "r" with your left for crying out loud. If that offends you so much, use a different keyboard layout. Or submit patches, so you can enter a character of your choosing to mean "left" (and (a different) one for "right"). Peace, david -- David H. Wolfskill david@catwhisker.org Evidence of curmudgeonliness: becoming irritated with the usage of the word "speed" in contexts referring to quantification of network performance, as opposed to "bandwidth" or "latency." From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 16:31:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18E9E16A4CE for ; Mon, 30 Aug 2004 16:31:08 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB1CA43D49 for ; Mon, 30 Aug 2004 16:31:07 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.13.1/8.12.11) with ESMTP id i7UGV78C019288; Mon, 30 Aug 2004 09:31:07 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i7UGV6ih019287; Mon, 30 Aug 2004 09:31:06 -0700 (PDT) (envelope-from obrien) Date: Mon, 30 Aug 2004 09:31:06 -0700 From: "David O'Brien" To: Kenneth Stailey Message-ID: <20040830163106.GA19044@dragon.nuxi.com> References: <20040829213449.GA33843@hub.freebsd.org> <20040830135311.11040.qmail@web50603.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040830135311.11040.qmail@web50603.mail.yahoo.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 16:31:08 -0000 On Mon, Aug 30, 2004 at 06:53:11AM -0700, Kenneth Stailey wrote: > mergemasters is gross. Have you ever tried to run it on an 80-column display? > > I absolutely hate the "left" "right" stuff. You push the "l" with your right > hand and the "r" with your left for crying out loud. LOL!! Note, though, that this output has nothing to do with mergemaster -- it is sdiff(1) that is used. What you don't like is sdiff(1)'s output format. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 16:32:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DBED16A4CF; Mon, 30 Aug 2004 16:32:26 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFC4043D49; Mon, 30 Aug 2004 16:32:23 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7UGWJjn006652; Mon, 30 Aug 2004 09:32:20 -0700 Message-ID: <41335688.1060805@root.org> Date: Mon, 30 Aug 2004 09:32:08 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <20040825222345.GB79209@ip.net.ua> <20040825.163130.66167637.imp@bsdimp.com> <412D1CE6.3050603@root.org> <20040825.171523.10602123.imp@bsdimp.com> In-Reply-To: <20040825.171523.10602123.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: phk@phk.freebsd.dk cc: current@freebsd.org Subject: Re: No more floppy drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 16:32:26 -0000 M. Warner Losh wrote: > In message: <412D1CE6.3050603@root.org> > Nate Lawson writes: > : M. Warner Losh wrote: > : > In message: <20040825222345.GB79209@ip.net.ua> > : > Ruslan Ermilov writes: > : > : On Wed, Aug 25, 2004 at 04:17:33PM -0600, M. Warner Losh wrote: > : > : > Generally one doesn't want ANY hints when one has pnpisabios or acpi > : > : > supplying the hints, unless one really does have an exceptional device > : > : > at that location. > : > : > > : > : A lot of current@ users report missing /dev/fd0 due to this. Can this > : > : be fixed somehow? > : > > : > acpi should be providing these hints, but it appears that either that > : > code isn't working, hasn't been committed or there's no fallback to > : > more traditional methods when there's no information about fd drives. > : > This is one of the twistiest, nastiest, ugliest part of PCAT :-( > : > : The code I added merely does: > : > : if (_FDE working) > : add fd[0-2] children accordingly > : if (fdX._FDI working) > : set type on fdX > : else > : unmodified hints probe for fd[0-2] > : > : if (fdX type not set) > : unmodified drive type probe via rtc > : > : Since the probe is unmodified if _FDE is not present, I can't see a new > : problem here. If this is a new problem, it must be elsewhere. > > I'll take a look at things. I think it may have to do with > presence/absence things. > > Warner Ok, as suspected, our floppy driver is being overly ambitious in allocating IO ports. See these messages for how it was solved in Linux (and Windows). http://www.ussg.iu.edu/hypermail/linux/kernel/0202.0/1286.html http://www.ussg.iu.edu/hypermail/linux/kernel/0202.0/1603.html http://www.ussg.iu.edu/hypermail/linux/kernel/0202.0/1606.html Basically, systems that have AML that claim 0x3f2-0x3f5,0x3f7 are correct and we need to only allocate those ports. In fact, we shouldn't allocate 0x3f0-0x3f1 unless on a PS/2 system. However, our floppy code assumes a base of 0x3f0 and that's why people report error messages like: fdc0: port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3 irq 6 drq 2 on acpi0 fdc0: output ready timeout fdc0: cmd 3 failed at out byte 1 of 3 device_attach: fdc0 attach returned 6 -Nate From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 16:36:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED45616A4CE for ; Mon, 30 Aug 2004 16:36:33 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D83843D5D for ; Mon, 30 Aug 2004 16:36:33 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 81F8BACAF1; Mon, 30 Aug 2004 18:36:31 +0200 (CEST) Date: Mon, 30 Aug 2004 18:36:31 +0200 From: Pawel Jakub Dawidek To: =?iso-8859-2?Q?S=B3awek_=AFak?= Message-ID: <20040830163631.GM30151@darkness.comp.waw.pl> References: <86acwc7kr0.fsf@thirst.unx.era.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MY4sEYl+yXp4+5u8" Content-Disposition: inline In-Reply-To: <86acwc7kr0.fsf@thirst.unx.era.pl> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: current@freebsd.org Subject: Re: IPSec related crash? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 16:36:34 -0000 --MY4sEYl+yXp4+5u8 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 30, 2004 at 04:39:47PM +0200, S=B3awek =AFak wrote: +> Happened on BETA1. 2 processor SMP. DDB after-crash queries attacche= d. Could you provide panic message? --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --MY4sEYl+yXp4+5u8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBM1ePForvXbEpPzQRAl40AJ0ehHgt2Ir4fsZiqkujlUH7wkd79wCg8dFQ 2z7Ue85M/dBcG/6u3IxXXTE= =SCcG -----END PGP SIGNATURE----- --MY4sEYl+yXp4+5u8-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 16:41:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EBC916A4CE for ; Mon, 30 Aug 2004 16:41:37 +0000 (GMT) Received: from web41409.mail.yahoo.com (web41409.mail.yahoo.com [66.218.93.75]) by mx1.FreeBSD.org (Postfix) with SMTP id 7033E43D66 for ; Mon, 30 Aug 2004 16:41:37 +0000 (GMT) (envelope-from davemac11@yahoo.com) Message-ID: <20040830164137.91119.qmail@web41409.mail.yahoo.com> Received: from [168.91.4.66] by web41409.mail.yahoo.com via HTTP; Mon, 30 Aug 2004 09:41:37 PDT Date: Mon, 30 Aug 2004 09:41:37 -0700 (PDT) From: Dave McCammon To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: 5.3 beta2 bridging X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 16:41:37 -0000 I couldn't get bridging to work in beta1. I just upgraded to beta2 and still can't get bridging to work. here is original message except now it is -BETA2 http://docs.FreeBSD.org/cgi/mid.cgi?20040826204237.44644.qmail _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 16:47:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 744F916A4CE; Mon, 30 Aug 2004 16:47:25 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 158CE43D45; Mon, 30 Aug 2004 16:47:25 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7UGlHcn052963; Mon, 30 Aug 2004 10:47:17 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 30 Aug 2004 10:47:23 -0600 (MDT) Message-Id: <20040830.104723.66164724.imp@bsdimp.com> To: nate@root.org From: "M. Warner Losh" In-Reply-To: <41335688.1060805@root.org> References: <412D1CE6.3050603@root.org> <20040825.171523.10602123.imp@bsdimp.com> <41335688.1060805@root.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: phk@phk.freebsd.dk cc: current@freebsd.org Subject: Re: No more floppy drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 16:47:25 -0000 In message: <41335688.1060805@root.org> Nate Lawson writes: : Basically, systems that have AML that claim 0x3f2-0x3f5,0x3f7 are : correct and we need to only allocate those ports. In fact, we shouldn't : allocate 0x3f0-0x3f1 unless on a PS/2 system. However, our floppy code : assumes a base of 0x3f0 and that's why people report error messages like: Yes. That's right. I've understood that from early in the conversations. However, we don't have much of a choice for systems that tell us 0x3f0-0x3f5, which is what the traditional range for these ports really is. This is a very recent development, and needs some tcl to get right. I have some patches in the works, but they aren't ready yet. Please be patient. Warner From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 16:58:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60C6816A588; Mon, 30 Aug 2004 16:58:07 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BA0743D46; Mon, 30 Aug 2004 16:58:07 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i7UGw5jn007068; Mon, 30 Aug 2004 09:58:05 -0700 Message-ID: <41335C9D.7040204@root.org> Date: Mon, 30 Aug 2004 09:58:05 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <412D1CE6.3050603@root.org> <20040825.171523.10602123.imp@bsdimp.com> <41335688.1060805@root.org> <20040830.104723.66164724.imp@bsdimp.com> In-Reply-To: <20040830.104723.66164724.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: phk@phk.freebsd.dk cc: current@freebsd.org Subject: Re: No more floppy drive X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 16:58:07 -0000 M. Warner Losh wrote: > In message: <41335688.1060805@root.org> > Nate Lawson writes: > : Basically, systems that have AML that claim 0x3f2-0x3f5,0x3f7 are > : correct and we need to only allocate those ports. In fact, we shouldn't > : allocate 0x3f0-0x3f1 unless on a PS/2 system. However, our floppy code > : assumes a base of 0x3f0 and that's why people report error messages like: > > Yes. That's right. I've understood that from early in the > conversations. However, we don't have much of a choice for systems > that tell us 0x3f0-0x3f5, which is what the traditional range for > these ports really is. This is a very recent development, and needs > some tcl to get right. I have some patches in the works, but they > aren't ready yet. Please be patient. Ok, glad you knew this. Thanks for working on it. -- Nate From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 16:59:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64DB316A4CE for ; Mon, 30 Aug 2004 16:59:43 +0000 (GMT) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8CB843D31 for ; Mon, 30 Aug 2004 16:59:42 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.102] (ddsl-66-42-172-210.fuse.net [66.42.172.210]) (authenticated bits=0)i7UGkJjr029695 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 30 Aug 2004 12:46:20 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: Matthew Reimer Date: Mon, 30 Aug 2004 13:01:05 -0400 User-Agent: KMail/1.6.2 References: <413354D5.1040308@vpop.net> In-Reply-To: <413354D5.1040308@vpop.net> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200408301301.15140.mistry.7@osu.edu> X-Spam-Status: No, hits=-4.9 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,PGP_SIGNATURE, QUOTED_EMAIL_TEXT,RCVD_IN_ORBS,REFERENCES, REPLY_WITH_QUOTES,USER_AGENT_KMAIL version=2.55 X-Spam-Checker-Version: SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) cc: freebsd-current@freebsd.org Subject: Re: wscons from NetBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 16:59:43 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 30 August 2004 12:24 pm, you wrote: > Anish Mistry wrote: > > =3D2D----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > I'm in the process of trying to update a bunch of the USB HID code to be > > ba=3D ck=3D20 > > in sync with NetBSD since there are numerous problems with our current > > code=3D =3D20 > > that have been fixed for a couple of years now in the NetBSD code. The > > maj=3D or=3D20 > > problem that I'm running into is their dependency on wscons for a few of > > th=3D e=3D20 > > drivers. Has there been any work on porting wscons to FreeBSD? It > > would=3D20 make this import much easier and make future imports much > > simpler too. =3D2D --=3D20 > > Anish Mistry > > Are you also planning to bring over uhidev, so our USB keyboards with > the nifty extra keys will work? > That's the whole point! :) =2D --=20 Anish Mistry =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBM11ZxqA5ziudZT0RAmfxAJ9WRlq6psG9IjSiUiqQ9l4Y+zgCYQCdFf2O pNV1Ky7WzCWLc79oc4h/1gw=3D =3DJ4WK =2D----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 17:16:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89B5116A4E8; Mon, 30 Aug 2004 17:16:37 +0000 (GMT) Received: from av1-2-sn4.m-sp.skanova.net (av1-2-sn4.m-sp.skanova.net [81.228.10.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B3E943D41; Mon, 30 Aug 2004 17:16:37 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av1-2-sn4.m-sp.skanova.net (Postfix, from userid 502) id 98A7D37EF3; Mon, 30 Aug 2004 19:16:36 +0200 (CEST) Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av1-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 87EAA37E45; Mon, 30 Aug 2004 19:16:36 +0200 (CEST) Received: from gadget (h130n1fls11o822.telia.com [213.64.66.130]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id 5A13D37E5C; Mon, 30 Aug 2004 19:16:36 +0200 (CEST) From: "Daniel Eriksson" To: =?iso-8859-1?Q?'S=F8ren_Schmidt'?= Date: Mon, 30 Aug 2004 19:16:37 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <41334E6D.4030601@DeepCore.dk> Thread-Index: AcSOq1A9HbG2ov99QU60w3KrOD3gzgAB/iTg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 cc: freebsd-current@freebsd.org cc: 'Pawel Jakub Dawidek' Subject: RE: ataraid + geom_stripe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 17:16:37 -0000 S=F8ren Schmidt wrote: > Hmm, looks like you re triggering the throtteling code, that=20 > will lead to catastophic failure as it tosses out interrupts > causing this: Yes, that is very likely to be the source of my problems. However, the = root cause is still not clear to me. Why would I get an interrupt storm when geom_stripe tastes the discs when everything else works like a charm? I have hw.intr_storm_threshold=3D5000 set in /boot/loader.conf so the = storm is probably pretty "big". I added that setting back in June when, after installing a second RocketRAID 454 card, I started getting interrupt = storms at boot during device probing. It didn't really help, but ACPI changes = at the beginning of August seems to finally have removed those problems. > Anyhow you would want up to date -current ATA sources as quite a few=20 > problems has been solved.. Hmm, anything in the last 4 days that could affect this (kernel/userland = was from 4 days ago)? I don't recall seeing any commits that would be = relevant. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 17:47:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5267016A4CE; Mon, 30 Aug 2004 17:47:58 +0000 (GMT) Received: from web.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7771B43D2D; Mon, 30 Aug 2004 17:47:57 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.20] (portacare.portaone.com [195.140.247.242]) (authenticated bits=0) by web.portaone.com (8.12.8p2/8.12.8) with ESMTP id i7UHlsPR095815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 30 Aug 2004 19:47:56 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <4133683A.3090201@portaone.com> Date: Mon, 30 Aug 2004 20:47:38 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sos@freebsd.org, "current@freebsd.org" Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: burncd(8) usability: why `-s max' isn't default? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 17:47:58 -0000 Hi, I wonder if there are any compelling reasons why `-s max' is not default behaviour of burncd(8). IMHO, there is no point to have default of 4. Usually, today's drives are smart enough to select the maximum speed supported both by drive and by the medium. -Maxim From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 17:50:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C6BE16A4CE for ; Mon, 30 Aug 2004 17:50:53 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FE7B43D31 for ; Mon, 30 Aug 2004 17:50:53 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 41DEC72DD5; Mon, 30 Aug 2004 10:50:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 4025272DCB; Mon, 30 Aug 2004 10:50:53 -0700 (PDT) Date: Mon, 30 Aug 2004 10:50:53 -0700 (PDT) From: Doug White To: Damian Gerow In-Reply-To: <20040830022523.GD10969@afflictions.org> Message-ID: <20040830104925.E85743@carver.gumbysoft.com> References: <20040824073356.GK25125@afflictions.org> <20040829155924.J69068@carver.gumbysoft.com> <20040830022523.GD10969@afflictions.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: RELENG_5 build broken with BKTR_USE_FREEBSD_SMBUS and BKTR_NEW_MSP34XX_DRIVER enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 17:50:53 -0000 On Sun, 29 Aug 2004, Damian Gerow wrote: > Actually, I since found out that using those options (I think it might have > been BKTR_USE_FREEBSD_SMBUS, but I'm not sure) completely broke my bktr(4) > device. I yanked 'em all, and I'm running just fine. Though I'd like to > see if ..._MSP34XX_DRIVER changes anything, as I've got mono sound coming > out of a stereo device. You'll have better luck than me tracking this down -- my ancient card has a Philips text decocder instead of the msp. :) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 17:55:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C84C16A4D7; Mon, 30 Aug 2004 17:55:38 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB3ED43D5F; Mon, 30 Aug 2004 17:55:33 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id CDCE572DD4; Mon, 30 Aug 2004 10:55:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id CBC9272DCB; Mon, 30 Aug 2004 10:55:33 -0700 (PDT) Date: Mon, 30 Aug 2004 10:55:33 -0700 (PDT) From: Doug White To: Maxim Maximov In-Reply-To: <4132A956.4070604@mcsi.pp.ru> Message-ID: <20040830105333.L85743@carver.gumbysoft.com> References: <412FA7E8.80BE87BC@freebsd.org> <20040829172000.F69068@carver.gumbysoft.com> <4132A956.4070604@mcsi.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: Andre Oppermann Subject: Re: [Fwd: cvs commit: src/sys/kern sys_generic.c] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 17:55:38 -0000 On Mon, 30 Aug 2004, Maxim Maximov wrote: > But this commit didn't change anything for me. I'm running your last change > > mcsi@ultra(ttyp1) [92] ~> ident /boot/kernel/kernel |grep sys_gen > $FreeBSD: src/sys/kern/sys_generic.c,v 1.133 2004/08/27 21:23:50 > andre Exp $ > > and experience all the same hangs. Have you been able to reproduce this with a non-X application? I have a couple of simple Python scripts that you can try running if you want to -- they generate a bunch of poll() churn. What X server are you running? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 18:01:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E51616A4CE for ; Mon, 30 Aug 2004 18:01:09 +0000 (GMT) Received: from shim1.irt.drexel.edu (shim1.irt.drexel.edu [144.118.29.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id F248243D60 for ; Mon, 30 Aug 2004 18:01:08 +0000 (GMT) (envelope-from jsmith@drexel.edu) Received: from conversion-daemon.shim1.irt.drexel.edu by shim1.irt.drexel.edu (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I3900H01TWVSN@shim1.irt.drexel.edu> for current@freebsd.org; Mon, 30 Aug 2004 14:01:07 -0400 (EDT) Received: from vorpal.math.drexel.edu (vorpal.math.drexel.edu [129.25.6.250]) by shim1.irt.drexel.edu (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I3900K5XU1SB9@shim1.irt.drexel.edu> for current@freebsd.org; Mon, 30 Aug 2004 14:01:04 -0400 (EDT) Received: from [IPv6:::1] (vorpal.math.drexel.edu [129.25.6.250]) i7UI13vt000179 for ; Mon, 30 Aug 2004 14:01:03 -0400 (EDT envelope-from jsmith@drexel.edu) Date: Mon, 30 Aug 2004 14:01:02 -0400 From: Justin Smith To: "current@freebsd.org" Message-id: <41336B5E.7080000@drexel.edu> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040806) Subject: Thread problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 18:01:09 -0000 FreeBSD jsmith.org 5.3-BETA2 FreeBSD 5.3-BETA2 #0: Mon Aug 30 06:37:58 EDT 2004 root@:/usr/obj/usr/src/sys/MYKERNEL i386 The pan newsreader (recompiled) crashes on startup: GThread-ERROR **: file gthread-posix.c: line 137 (): error 'No such process' during 'pthread_getschedparam (pthread_self(), &policy, &sched)' aborting... Abort trap (core dumped) -bash-2.05b$ -- Time blows wildly against my door | Justin R. Smith Stirring discarded sorrows | Mathematics Department Like dead leaves of summers past | Drexel University Shadows of what went before | Philadelphia, PA 19104 Making way for new tomorrows | New hopes, new fears, | Office: (215) 895-1847 and new ways that last | URL: vorpal.math.drexel.edu From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 18:06:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F361B16A4CE for ; Mon, 30 Aug 2004 18:06:10 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E302043D1D for ; Mon, 30 Aug 2004 18:06:10 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id CFB1F72DD4; Mon, 30 Aug 2004 11:06:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id CA94272DCB; Mon, 30 Aug 2004 11:06:10 -0700 (PDT) Date: Mon, 30 Aug 2004 11:06:10 -0700 (PDT) From: Doug White To: Daniel O'Connor In-Reply-To: <200408301135.53552.doconnor@gsoft.com.au> Message-ID: <20040830105944.Y85743@carver.gumbysoft.com> References: <20040825150547.GI6962@electra.cse.Buffalo.EDU> <20040829163858.Q69068@carver.gumbysoft.com> <200408301135.53552.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: Dan Nelson cc: Rusty Nejdl cc: Ken Smith Subject: Re: X.org configuration in sysinstall X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 18:06:11 -0000 On Mon, 30 Aug 2004, Daniel O'Connor wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mon, 30 Aug 2004 09:09, Doug White wrote: > > > It finds the highest resolution supported by your card _and_ monitor. > > > > .... at 8 bit color, which is the part that really bothers me. > > Yeah that IS kind of dumb. > > It'd be interesting to now how the heuristic works for that so it can be made > more useful for modern hardware.. It uses DDC to download your monitor's specs from the monitor itself, then matches it up to a set of builtin modelines at the given bitdepth. I think it prefers resolution over refresh, but it depends on the limiting factor, the card's clock or the monitor's frequency ranges. Looking at the output in /var/log/Xorg.0.log should illuminate its choices. I generally end up adding a DefaultDepth and a Modes line at that depth to force the resolution a specific way. I haven't ever tried Xorg -configure -depth 24 and see if it spits out a DefaultDepth line... -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 18:11:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87E8216A4CE; Mon, 30 Aug 2004 18:11:59 +0000 (GMT) Received: from av4-2-sn3.vrr.skanova.net (av4-2-sn3.vrr.skanova.net [81.228.9.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB0EB43D58; Mon, 30 Aug 2004 18:11:58 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av4-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 061BF37E9E; Mon, 30 Aug 2004 20:11:58 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av4-2-sn3.vrr.skanova.net (Postfix) with ESMTP id E8DC237E4B; Mon, 30 Aug 2004 20:11:57 +0200 (CEST) Received: from gadget (h130n1fls11o822.telia.com [213.64.66.130]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id A2BB438004; Mon, 30 Aug 2004 20:11:57 +0200 (CEST) From: "Daniel Eriksson" To: "'Daniel Eriksson'" , "'Lukas Ertl'" , Date: Mon, 30 Aug 2004 20:11:58 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0017_01C48ECD.9AA793D0" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: Thread-Index: AcSLxU/8rJMyEu00TqmQagezZGSQFQC0H+oQAAJUN0AABcgMAA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: RE: PLEASE TEST: IPI deadlock avoidance patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 18:11:59 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0017_01C48ECD.9AA793D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I wrote: > Hmm, after running the test a second time, I actually got a > crc error even when using a UP kernel. The test set is 9GB+ > in ~270 files. With SMP I seem to get around 10% corrupt > files after simply making a duplicate of the folder. With > UP I have gotten 1 corrupt file in 2 tries (~550 files > copied). > > I'll report back here after I have tested "classic" vinum. Ok, I've run a few more tests now, and the results are not looking very good for gvinum in RAID-5 mode: Testbed: -------- * FreeBSD 6-CURRENT, 2004.08.29.21.00.00 * ASUS P2B-DS mobo, 2 x 700MHz P3, 1GB ECC RAM * OS disc: Some old 9GB ATA connected to on-board Intel BX chipset * Data discs: 4 x 120GB Maxtor SATA discs connected to a HighPoint RocketRAID 1540 card (HPT374 chipset) * RAID-5 array created using "vinum raid5" command (so disklabel was edited) Testset: -------- * 9.1GB data in 273 files (mostly zip-files, rar-files and exe-files) * crc checksums created and checked with /usr/ports/security/cksfv * cd /space/raid5/ && cp -Rp testdir testdir.copy Results: -------- gvinum / SMP: 117 corrupt files in 4 tests (~10.7% error) gvinum / UP : 3 corrupt files in 5 tests (~0.2% error) vinum / SMP : no corrupt files in 3 tests Observation: vinum seems to offer more than 3x the read performance compared to gvinum (measured by timing the crc-checksumming). Write performance seems about equal. /Daniel Eriksson ------=_NextPart_000_0017_01C48ECD.9AA793D0 Content-Type: application/octet-stream; name="dmesg.boot" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="dmesg.boot" Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-CURRENT #2: Mon Aug 30 17:14:22 CEST 2004 daniel@xxx.xxx.xxx:/usr/obj/usr/src/sys/SENTINEL WARNING: MPSAFE network stack disabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (701.59-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x681 Stepping =3D 1 = Features=3D0x383fbff real memory =3D 1073729536 (1023 MB) avail memory =3D 1041174528 (992 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 1 cpu1 (AP): APIC ID: 0 ioapic0 irqs 0-23 on motherboard npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem = 0xe4000000-0xe7ffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 4.0 on pci0 isa0: on isab0 atapci0: port = 0xb800-0xb80f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 4.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: port 0xb400-0xb41f irq = 19 at device 4.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 4.3 (no driver attached) ahc0: port 0xb000-0xb0ff mem = 0xe1000000-0xe1000fff irq 19 at device 6.0 on pci0 ahc0: [GIANT-LOCKED] aic7890/91: Ultra2 Wide Channel A, SCSI Id=3D15, 32/253 SCBs atapci1: port = 0x9400-0x94ff,0x9800-0x9803,0xa000-0xa007,0xa400-0xa403,0xa800-0xa807 = irq 19 at device 9.0 on pci0 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 atapci2: port = 0x7800-0x78ff,0x8000-0x8003,0x8400-0x8407,0x8800-0x8803,0x9000-0x9007 = irq 19 at device 9.1 on pci0 ata4: channel #0 on atapci2 ata5: channel #1 on atapci2 xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0x7400-0x747f mem = 0xe0800000-0xe080007f irq 18 at device 10.0 on pci0 miibus0: on xl0 xlphy0: <3c905C 10/100 internal PHY> on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:01:02:73:f4:f5 xl0: [GIANT-LOCKED] xl1: <3Com 3c905C-TX Fast Etherlink XL> port 0x7000-0x707f mem = 0xe0000000-0xe000007f irq 17 at device 11.0 on pci0 miibus1: on xl1 xlphy1: <3c905C 10/100 internal PHY> on miibus1 xlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl1: Ethernet address: 00:50:da:8d:d2:af xl1: [GIANT-LOCKED] fxp0: port 0x6800-0x683f mem = 0xdf000000-0xdf0fffff,0xdf800000-0xdf800fff irq 16 at device 12.0 on = pci0 miibus2: on fxp0 inphy0: on miibus2 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:03:47:09:6f:51 fxp0: [GIANT-LOCKED] speaker0 port 0x61 on acpi0 fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on = acpi0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 pmtimer0 on isa0 orm0: at iomem = 0xd4000-0xd57ff,0xd0000-0xd07ff,0xcc000-0xcc7ff,0xc0000-0xc7fff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=3D0x200> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled Timecounters tick every 1.000 msec ipfw2 initialized, divert enabled, rule-based forwarding disabled, = default to accept, logging unlimited ad0: 8693MB [17662/16/63] at ata0-master = UDMA33 ATAPI_RESET time =3D 50us acd0: CDROM at ata1-master PIO4 ad4: 117246MB [238216/16/63] at ata2-master = SATA150 ad6: 117246MB [238216/16/63] at ata3-master = SATA150 ad8: 117246MB [238216/16/63] at ata4-master = SATA150 ad10: 117246MB [238216/16/63] at ata5-master = SATA150 Waiting 2 seconds for SCSI devices to settle SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/ad0s1a ------=_NextPart_000_0017_01C48ECD.9AA793D0-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 18:16:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B62DF16A4CE for ; Mon, 30 Aug 2004 18:16:09 +0000 (GMT) Received: from linwhf.opal.com (102.79.171.66.subscriber.vzavenue.net [66.171.79.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDF6943D53 for ; Mon, 30 Aug 2004 18:16:08 +0000 (GMT) (envelope-from jr@opal.com) Received: (jr@localhost) by linwhf.opal.com (8.12.11/jr6.1/Submit) for id i7UIFesK000866; Mon, 30 Aug 2004 14:15:40 -0400 (EDT) Date: Mon, 30 Aug 2004 14:15:40 -0400 From: "J.R. Oldroyd" To: =?iso-8859-1?Q?S=F8ren?= Schmidt Message-ID: <20040830181540.GA809@linwhf.opal.com> References: <412F5A10.8080907@drexel.edu> <412F7292.6000804@DeepCore.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <412F7292.6000804@DeepCore.dk> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: Current 8/27/2004, DVD problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 18:16:09 -0000 Still not working here, I'm afraid. Mine's the NEC DVD which reports on the 5.2.1 generic kernel as: acd0: DVDR <_NEC DVD_RW ND-1300A> at ata1-slave PIO4 But I just tried the -current as of 2004/08/04 13:30 GMT and it still doesn't boot beyond the probe of the ata devices. Boot with the DVD unplugged and I get: ad0: 38166MB [77545/16/63] at ata0-master UDMA100 ad1: 238475MB [484521/16/63] at ata0-slave UDMA100 ata1-master: DMA limited to UDMA33, non-ATA66 cable or device ad2: 32253MB [65531/16/63] at ata1-master UDMA33 SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/ad0s1a Boot it with the DVD powered, and I get: ad0: 38166MB [77545/16/63] at ata0-master UDMA100 ad1: 238475MB [484521/16/63] at ata0-slave UDMA100 ATAPI_RESET time = 30us ata1-master: DMA limited to UDMA33, non-ATA66 cable or device ad2: 32253MB [65531/16/63] at ata1-master UDMA33 ... and it hangs... Note that I do NOT get the ATAPI_RESET message when the DVD isn't present. -jr On Aug 27, 19:42, Søren Schmidt wrote: > Justin Smith wrote: > >FreeBSD jsmith.org 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Fri Aug 27 > >10:56:28 EDT 2004 jsmith@jsmith.org:/usr/obj/usr/src/sys/MYKERNEL i386 > > > > > >My machine hangs on boot, with > > > >ACD1 DVDROM AT ATA1-SLAVE UDMA40 > > > >then I get a lot of messages > > > >ATAPI_RESET time=50us > >ATAPI_RESET time=180us > > > >and eventually > > > >SETFEATURES SET TRANSFER MODE INTERRUPT WAS SEEN BUT taskqueue > >(something, I'm not sure of the last word) > > > >I can only boot after unplugging the DVD drive. > > Upgrade /sys/dev/ata to the latest from -current and let me know how > that turns out please.. > > -Søren > > > _______________________________________________ > 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 Aug 30 18:19:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED86B16A4CE; Mon, 30 Aug 2004 18:19:56 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC3F443D31; Mon, 30 Aug 2004 18:19:56 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id CE54972DD4; Mon, 30 Aug 2004 11:19:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id CCC0A72DCB; Mon, 30 Aug 2004 11:19:56 -0700 (PDT) Date: Mon, 30 Aug 2004 11:19:56 -0700 (PDT) From: Doug White To: Garance A Drosihn In-Reply-To: Message-ID: <20040830111532.H85743@carver.gumbysoft.com> References: <200408271337.i7RDbXgu052801@pooker.samsco.org> <20040829174521.H69068@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: re@freebsd.org cc: current@freebsd.org Subject: Re: 5.3-RELEASE TODO - make/kqueue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 18:19:57 -0000 On Mon, 30 Aug 2004, Garance A Drosihn wrote: > At 5:45 PM -0700 8/29/04, Doug White wrote: > >On Sat, 28 Aug 2004, Garance A Drosihn wrote: > > > >> I do still get the "*** Signal 6"s, even though I am now running > > > with v1.76 of src/sys/kern/kern_lock.c. ... > > > >If you're sure you've updated, and have tried rebuilding make > >to eliminate a corrupted binary, then you might have hardware > >problems. > > This seems much too repeatable to be hardware. The more times I > repeat my testing, the more consistent the problem seems. (but > I'll spare you the details until I narrow it down even more...). > > I am sure I have rebuilt make several times, because I am switching > between "make WITH_KQUEUE" and make without kqueue, and I do > complete recompiles each time I switch. These signal-6's are not > coming up in "normal operation" for me. It is only when I have > been stress-testing changes to the make command. What counts as a 'stress-test'? I can attempt to reproduce it here. So far my machines build world OK, but I don't have WITH_KQUEUE set yet. It doesn't sound like the kqueue option follows the problem, though.... > Please note that I did not mean to make a big deal about these > signal 6's. Well you shouldn't be getting them, and it'd be nice to fix it now while we have a known broken case. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 18:20:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B950616A4CF for ; Mon, 30 Aug 2004 18:20:08 +0000 (GMT) Received: from casper.imasy.or.jp (casper.imasy.or.jp [210.161.150.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 334C243D5C for ; Mon, 30 Aug 2004 18:20:08 +0000 (GMT) (envelope-from ume@FreeBSD.org) Received: from cheer.mahoroba.org (IDENT:PHIdqD4O7mRtwrbMOo3bBjU/fS/VTsdiy+c2Kso+cS5KDb6ZH4G3MJRBRqMt8dQC@cheer.mahoroba.org [IPv6:2001:200:301:0:240:c7ff:fe97:6f89]) (user=mahoroba mech=DIGEST-MD5 bits=128)i7UIJjDD087256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 31 Aug 2004 03:19:51 +0900 (JST) (envelope-from ume@FreeBSD.org) Received: from lyrics.mahoroba.org (IDENT:HI/w0U94RCZzYbBaJbV2gLbUuAmFSmSrwjpgRq5ohpiz+5sJWLUfJ0o11JyaeO6O@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0)i7UIJdaG038470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Aug 2004 03:19:39 +0900 (JST) (envelope-from ume@FreeBSD.org) Date: Tue, 31 Aug 2004 03:19:39 +0900 Message-ID: From: Hajimu UMEMOTO To: "bettan" In-Reply-To: <011801c48a12$184bc600$0401a8c0@frederic> References: <20040824185742.45B945D04@ptavv.es.net> <011801c48a12$184bc600$0401a8c0@frederic> User-Agent: xcite1.38> Wanderlust/2.11.3 (Wonderwall) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.3-BETA1 MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cheer.mahoroba.org cc: freebsd-current@freebsd.org Subject: Re: altq on freebsd 5.2-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 18:20:08 -0000 Hi, >>>>> On Tue, 24 Aug 2004 21:39:39 +0200 >>>>> "bettan" said: bettan> altq works good on freebsd 5.63-beta1 now.But I have a other problem with bettan> 5.3-beta-1 with ipv6.I put this lines en my rc.conf but ping6 fails : bettan> ipv6_ifconfig_xl0="2001:7a8:3d26::1 prefixlen 64" bettan> rtadvd_enable="YES" bettan> rtadvd_interfaces="xl0" bettan> ipv6_gateway_enable="YES" bettan> ipv6_defaultrouter="NO" bettan> ipv6_static_routes="tun0" bettan> ipv6_route_tun0="default -interface tun0" You are trying to set an IPv6 route to a pseudo interface statically. It will success only when the interface has a link-local address (an IPv6 address). So, you need to make sure that an IPV6CP is established at the time. Why don't you set from /etc/ppp/ppp.conf by `add default HISADDR6'? 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 Mon Aug 30 18:21:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 930E616A4CE; Mon, 30 Aug 2004 18:21:48 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AE6343D49; Mon, 30 Aug 2004 18:21:48 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 07D2D7A3F9; Mon, 30 Aug 2004 11:21:48 -0700 (PDT) Message-ID: <4133703B.4050601@elischer.org> Date: Mon, 30 Aug 2004 11:21:47 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Gleb Smirnoff References: <20040830095729.GD30701@cell.sick.ru> <20040830144041.GA33772@cell.sick.ru> In-Reply-To: <20040830144041.GA33772@cell.sick.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit cc: "Bjoern A. Zeeb" cc: Robert Watson cc: FreeBSD current mailing list Subject: Re: mutex Giant not owned at /usr/src/sys/kern/vfs_vnops.c:120 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 18:21:48 -0000 One option is to remove the functionality of making netgraph load kernel modules.. I think this is outside the scope of netgraph really.... Gleb Smirnoff wrote: >On Mon, Aug 30, 2004 at 10:35:05AM -0400, Robert Watson wrote: >R> > B> > This causes Giant to be acquired in the event we enter the linker code >R> > B> > (and hence VFS code) via netgraph ngc_send(). It should be safe in this >R> > B> > context as we enter protocol send routines without mutexes held (i.e., why >R> > B> > we're also able to do blocking memory allocation here.) >R> > B> >R> > B> please commit. >R> > >R> > I think Giant should be acquired in linker_load_module(), and this way >R> > we will prevent this panic in other codepaths. For example in >R> > vfs_mount.c, when vfs will be Giant-free. Have I missed something? >R> >R> Well, one of the primary reasons the linker needs Giant here is its use of >R> VFS. I think for now I'd like to acquire Giant in netgraph so as to >R> expose the use of Giant in that piece of the network stack in the calling >R> code. We might want to add GIANT_REQUIRED assertions in the linker code >R> to make sure we trigger assertions even if the linker doesn't hit VFS to >R> make sure potentially hitting Giant is caught. > >OK. Then commit it pls. > > > From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 18:28:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08BE316A4D0; Mon, 30 Aug 2004 18:28:32 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9D3343D60; Mon, 30 Aug 2004 18:28:31 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id DBEBA72DD4; Mon, 30 Aug 2004 11:28:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id D674C72DCB; Mon, 30 Aug 2004 11:28:31 -0700 (PDT) Date: Mon, 30 Aug 2004 11:28:31 -0700 (PDT) From: Doug White To: Daniel O'Connor In-Reply-To: <200408301121.22260.doconnor@gsoft.com.au> Message-ID: <20040830112608.L85743@carver.gumbysoft.com> References: <200408301121.22260.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: dmlb@freebsd.org Subject: Re: bfe crash with profile.sh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 18:28:32 -0000 On Mon, 30 Aug 2004, Daniel O'Connor wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I am trying this -> > https://projects.fsck.ch/profile/wiki/InstallGuide > > but enabling it makes my bfe panic on boot :( > > I have some more info in kern/71131 Can you put the crashdump and the corresponding kernel.debug somewhere we can get at it? ifconfig must be handing bogus data to bfe or enables some wierd option that the driver doesn't digest right. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 18:32:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B005116A4CF for ; Mon, 30 Aug 2004 18:32:14 +0000 (GMT) Received: from sana.init-main.com (104.194.138.210.bn.2iij.net [210.138.194.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id C885643D48 for ; Mon, 30 Aug 2004 18:32:13 +0000 (GMT) (envelope-from takawata@init-main.com) Received: from init-main.com (localhost [127.0.0.1]) by sana.init-main.com (8.13.1/8.13.1) with ESMTP id i7UIVICs047312; Tue, 31 Aug 2004 03:31:19 +0900 (JST) (envelope-from takawata@init-main.com) Message-Id: <200408301831.i7UIVICs047312@sana.init-main.com> To: Vladimir Grebenschikov From: takawata@jp.freebsd.org In-reply-to: Your message of "Mon, 30 Aug 2004 19:39:33 +0400." <1093880373.3257.6.camel@localhost> Date: Tue, 31 Aug 2004 03:31:18 +0900 Sender: takawata@init-main.com cc: freebsd-current@freebsd.org Subject: Re: acpi_video on SONY VAIO PCG-Z1 [was: acpi_video users needed] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 18:32:14 -0000 In message <1093880373.3257.6.camel@localhost>, Vladimir Grebenschikov $B$5$s$$$o(B $B$/(B: >On Mon, 2004-08-30 at 23:58 +0900, takawata@jp.freebsd.org wrote: > >> >Hi >> > >> >Is any chance to make acpi_video work on SONY VAIO PCG-Z1 ? >> >acpi_video.ko loads well, but does not report anything, and does not add >> >hw.acpi.video subtree. >> > >> >Please advise. >> >> Because the ACPI device object has not enough interfaces to get the >> acpi_video driver work. >> Acpi_video driver does not check PCI device class: it checks the >> interfaces instead. >> You don't need to bother attaching acpi_video driver. > >Ok, And what conclusion "no-way" ? You may hack the driver to do so.:-) But, in your machine, the driver does not work anything but recognize that the video adaptor has 3 way output. And you can't use acpi_video, if you want to use DRM or nvidia kernel module. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 18:32:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1102C16A4CE for ; Mon, 30 Aug 2004 18:32:54 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53F6A43D53 for ; Mon, 30 Aug 2004 18:32:53 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i7UIWpmN001840; Mon, 30 Aug 2004 20:32:52 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <413372B3.5010603@DeepCore.dk> Date: Mon, 30 Aug 2004 20:32:19 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "J.R. Oldroyd" References: <412F5A10.8080907@drexel.edu> <412F7292.6000804@DeepCore.dk> <20040830181540.GA809@linwhf.opal.com> In-Reply-To: <20040830181540.GA809@linwhf.opal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: current@freebsd.org Subject: Re: Current 8/27/2004, DVD problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 18:32:54 -0000 J.R. Oldroyd wrote: > Still not working here, I'm afraid. >=20 > Mine's the NEC DVD which reports on the 5.2.1 generic kernel as: >=20 > acd0: DVDR <_NEC DVD_RW ND-1300A> at ata1-slave PIO4 >=20 > But I just tried the -current as of 2004/08/04 13:30 GMT and it > still doesn't boot beyond the probe of the ata devices. Boot with > the DVD unplugged and I get: Hmm, is this current of 2004/08/04 or 2004/08/27 ? Anyhow there was some critical update on the 27'th, so you should make=20 certain you have the absolute latest from -current. -S=F8ren From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 18:34:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 765D816A4CE for ; Mon, 30 Aug 2004 18:34:15 +0000 (GMT) Received: from smtp003.bizmail.yahoo.com (smtp003.bizmail.yahoo.com [216.136.130.195]) by mx1.FreeBSD.org (Postfix) with SMTP id F24A943D55 for ; Mon, 30 Aug 2004 18:34:14 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from unknown (HELO optimator.noacks.org) (noackjr@supercrime.org@70.240.217.225 with login) by smtp003.bizmail.yahoo.com with SMTP; 30 Aug 2004 18:34:14 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id 5ED5761AA; Mon, 30 Aug 2004 13:34:13 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05080-01; Mon, 30 Aug 2004 13:34:12 -0500 (CDT) Received: from www.noacks.org (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id DF0A6610C; Mon, 30 Aug 2004 13:34:11 -0500 (CDT) Received: from 69.53.57.66 (SquirrelMail authenticated user noackjr); by www.noacks.org with HTTP; Mon, 30 Aug 2004 13:34:11 -0500 (CDT) Message-ID: <62946.69.53.57.66.1093890851.squirrel@69.53.57.66> In-Reply-To: <4133683A.3090201@portaone.com> References: <4133683A.3090201@portaone.com> Date: Mon, 30 Aug 2004 13:34:11 -0500 (CDT) From: "Jon Noack" To: "Maxim Sobolev" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at noacks.org cc: "current@freebsd.org" cc: sos@freebsd.org Subject: Re: burncd(8) usability: why `-s max' isn't default? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 18:34:15 -0000 Maxim Sobolev wrote: > I wonder if there are any compelling reasons why `-s max' is not default > behaviour of burncd(8). IMHO, there is no point to have default of 4. > Usually, today's drives are smart enough to select the maximum speed > supported both by drive and by the medium. In the past we did not have ATAPI DMA default to on. You're just asking for trouble trying to write at high speed with PIO, regardless of Burn Proof. Now that we do have ATAPI DMA on, we could (relatively) safely change burncd to default at max speed. However, there may be issues I am not aware of that would prevent this change. Jon From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 18:35:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87B8216A4D5 for ; Mon, 30 Aug 2004 18:35:25 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C11543D58 for ; Mon, 30 Aug 2004 18:35:09 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 4B09272DD4; Mon, 30 Aug 2004 11:35:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 45F9072DCB; Mon, 30 Aug 2004 11:35:09 -0700 (PDT) Date: Mon, 30 Aug 2004 11:35:09 -0700 (PDT) From: Doug White To: Joe Marcus Clarke In-Reply-To: <1093831099.61516.30.camel@shumai.marcuscom.com> Message-ID: <20040830113344.Y85743@carver.gumbysoft.com> References: <1093831099.61516.30.camel@shumai.marcuscom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: Panic on 6.0 building ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 18:35:26 -0000 On Sun, 29 Aug 2004, Joe Marcus Clarke wrote: > On my Tinderbox machine (similar in operation to pointyhat), I was > building packages for 4.10-RELEASE and 5.2.1-RELEASE, and the machine > panicked. This is a single-CPU Pentium 4 with 2 GB of RAM. The drive > being used for builds is a Maxtor SATA drive connected to a Promise SATA > controller. I'm guessing you didn't get a crashdump. Can you try loading up your kernel.debug with kgdb and get line numbers for the first few lines in the trace? l *vfs_vmio_release+0x1b should work. > > Here is the manually transcribed panic and trace: > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x1c > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc0533d07 > stack pointer = 0x10:0xf5f30a4c > frame pointer = 0x10:0xf5f30a58 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 27441 (cpp0) > Stopped at vfs_vmio_release+0x1b: lock cmpxchgl %ecx,0x1c(%edx) > > vfs_vmio_release(dc1fee68) at vfs_vmio_release+0x1b > getnewbuf(0,0,4000,4000,1c000) at getnewbuf+0x2b6 > getblk(c8103210,7,0,4000,0) at getblk+0x400 > cluster_read(c8103210,7,0,4000,0) at cluster_read+0xde > ffs_read(f5f30c14) at ffs_read+0x25e > vm_read(c3834e58,f5f30c88,c484f880,0,c5877160) at vn_read+0x178 > dofileread(c5877160,c3834e58,7,814f000,2f2ed) at dofileread+0x95 > read(c5877160,f5f30d14,3,4,293) at read+0x3b > syscall(2f,2f,2f,814f000,2f2ed) at syscall+0x287 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (3, FreeBSD ELF32, read) eip = 0x8064924, esp = 0xbfbfd394, ebp = 0xbfbfd3c0 --- > > The machine is running: > > FreeBSD fugu.marcuscom.com 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Sun Aug > 29 01:02:18 EDT 2004 > root@new-fugu.marcuscom.com:/space2/obj/usr/src/sys/FUGU i386 > > Joe > > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 18:35:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62CC416A4CE for ; Mon, 30 Aug 2004 18:35:30 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0860943D2D for ; Mon, 30 Aug 2004 18:35:30 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id 55161ACAE6; Mon, 30 Aug 2004 20:35:28 +0200 (CEST) Date: Mon, 30 Aug 2004 20:35:28 +0200 From: Pawel Jakub Dawidek To: Daniel Eriksson Message-ID: <20040830183528.GN30151@darkness.comp.waw.pl> References: <41334E6D.4030601@DeepCore.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KWqj/C5KzoWE0Q2t" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-current@freebsd.org cc: 'S?ren Schmidt' Subject: Re: ataraid + geom_stripe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 18:35:30 -0000 --KWqj/C5KzoWE0Q2t Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 30, 2004 at 07:16:37PM +0200, Daniel Eriksson wrote: +> S?ren Schmidt wrote: +>=20 +> > Hmm, looks like you re triggering the throtteling code, that=20 +> > will lead to catastophic failure as it tosses out interrupts +> > causing this: +>=20 +> Yes, that is very likely to be the source of my problems. However, the r= oot +> cause is still not clear to me. Why would I get an interrupt storm when +> geom_stripe tastes the discs when everything else works like a charm? When new provider is created it is given for taste to other classes. This interrupt storm could be a result of some kind of abuse from=20 one of existing classes. Could you provide output of command: # sysctl -b kern.geom.conftxt | awk '{print $2}' | sort | uniq It will be good if you could try unload some classes (gvinum, etc.) before loading geom_stripe, just to be sure. Increasing kern.geom.stripe.debug could be also interesting. --=20 Pawel Jakub Dawidek http://www.FreeBSD.org pjd@FreeBSD.org http://garage.freebsd.pl FreeBSD committer Am I Evil? Yes, I Am! --KWqj/C5KzoWE0Q2t Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBM3NwForvXbEpPzQRAlmEAJ9JnJYqIRolAXhaoVWrmgDU/GJqZgCgxOHF bEdUzCKX6+SfUCy65f8KB+4= =SLOm -----END PGP SIGNATURE----- --KWqj/C5KzoWE0Q2t-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 18:41:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8B5D16A4D0 for ; Mon, 30 Aug 2004 18:41:08 +0000 (GMT) Received: from creme-brulee.marcuscom.com (rrcs-midsouth-24-172-16-118.biz.rr.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31D4543D58 for ; Mon, 30 Aug 2004 18:41:08 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from [10.2.1.4] (vpn-client-4.marcuscom.com [10.2.1.4]) i7UId6ef012605; Mon, 30 Aug 2004 14:39:06 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Doug White In-Reply-To: <20040830113344.Y85743@carver.gumbysoft.com> References: <1093831099.61516.30.camel@shumai.marcuscom.com> <20040830113344.Y85743@carver.gumbysoft.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VnFw5hFliJsimTt/8FuV" Organization: MarcusCom, Inc. Message-Id: <1093891285.722.57.camel@gyros> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 30 Aug 2004 14:41:25 -0400 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on creme-brulee.marcuscom.com cc: current@freebsd.org Subject: Re: Panic on 6.0 building ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 18:41:08 -0000 --=-VnFw5hFliJsimTt/8FuV Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2004-08-30 at 14:35, Doug White wrote: > On Sun, 29 Aug 2004, Joe Marcus Clarke wrote: >=20 > > On my Tinderbox machine (similar in operation to pointyhat), I was > > building packages for 4.10-RELEASE and 5.2.1-RELEASE, and the machine > > panicked. This is a single-CPU Pentium 4 with 2 GB of RAM. The drive > > being used for builds is a Maxtor SATA drive connected to a Promise SAT= A > > controller. >=20 > I'm guessing you didn't get a crashdump. Can you try loading up your > kernel.debug with kgdb and get line numbers for the first few lines in th= e > trace? l *vfs_vmio_release+0x1b should work. Sorry, I thought I had included that. The result was a little funny.=20 It said that the address pointed to vfs_vmio_release in atomic.h line 154. I tried to ``panic'' the system to get the core dump (I have dumps configured), but it locked up, and not even a ``continue'' would work.=20 Since then, I'm on a slightly newer kernel, and so far, no crash. If it dies again, I'll send more details, and hopefully get a core dump.=20 Thanks for the follow up. Joe >=20 > > > > Here is the manually transcribed panic and trace: > > > > Fatal trap 12: page fault while in kernel mode > > cpuid =3D 0; apic id =3D 00 > > fault virtual address =3D 0x1c > > fault code =3D supervisor write, page not present > > instruction pointer =3D 0x8:0xc0533d07 > > stack pointer =3D 0x10:0xf5f30a4c > > frame pointer =3D 0x10:0xf5f30a58 > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, def32 1, gran 1 > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > current process =3D 27441 (cpp0) > > Stopped at vfs_vmio_release+0x1b: lock cmpxchgl %ecx,0x1c(%edx) > > > > vfs_vmio_release(dc1fee68) at vfs_vmio_release+0x1b > > getnewbuf(0,0,4000,4000,1c000) at getnewbuf+0x2b6 > > getblk(c8103210,7,0,4000,0) at getblk+0x400 > > cluster_read(c8103210,7,0,4000,0) at cluster_read+0xde > > ffs_read(f5f30c14) at ffs_read+0x25e > > vm_read(c3834e58,f5f30c88,c484f880,0,c5877160) at vn_read+0x178 > > dofileread(c5877160,c3834e58,7,814f000,2f2ed) at dofileread+0x95 > > read(c5877160,f5f30d14,3,4,293) at read+0x3b > > syscall(2f,2f,2f,814f000,2f2ed) at syscall+0x287 > > Xint0x80_syscall() at Xint0x80_syscall+0x1f > > --- syscall (3, FreeBSD ELF32, read) eip =3D 0x8064924, esp =3D 0xbfbfd= 394, ebp =3D 0xbfbfd3c0 --- > > > > The machine is running: > > > > FreeBSD fugu.marcuscom.com 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Sun Aug > > 29 01:02:18 EDT 2004 > > root@new-fugu.marcuscom.com:/space2/obj/usr/src/sys/FUGU i386 > > > > Joe > > > > --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-VnFw5hFliJsimTt/8FuV Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBM3TVb2iPiv4Uz4cRAptJAKCOKrj2IKYHc+wsbKHNwkM5JrjBXQCfSQUJ GcZ42LXKhrLU7qHjBbI3Eew= =yZqr -----END PGP SIGNATURE----- --=-VnFw5hFliJsimTt/8FuV-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 18:42:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C512E16A4CE for ; Mon, 30 Aug 2004 18:42:55 +0000 (GMT) Received: from meitner.wh.uni-dortmund.de (meitner.wh.Uni-Dortmund.DE [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DDBA43D3F for ; Mon, 30 Aug 2004 18:42:55 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id 0C8531675AD; Mon, 30 Aug 2004 20:42:54 +0200 (CEST) Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id i7UIgqZj091706 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 30 Aug 2004 20:42:52 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock To: freebsd-current@freebsd.org Date: Mon, 30 Aug 2004 20:42:51 +0200 User-Agent: KMail/1.7 References: <20040824073356.GK25125@afflictions.org> <20040829155924.J69068@carver.gumbysoft.com> <20040830022523.GD10969@afflictions.org> In-Reply-To: <20040830022523.GD10969@afflictions.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1828835.HJDjgO7WAD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200408302042.51804.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new cc: Damian Gerow Subject: Re: RELENG_5 build broken with BKTR_USE_FREEBSD_SMBUS and BKTR_NEW_MSP34XX_DRIVER enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 18:42:55 -0000 --nextPart1828835.HJDjgO7WAD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 30 August 2004 04:25, Damian Gerow wrote: > Actually, I since found out that using those options (I think it might ha= ve > been BKTR_USE_FREEBSD_SMBUS, but I'm not sure)=20 Probably - I couldn't make that one work either, but I'm using device bktr options BKTR_NEW_MSP34XX_DRIVER with great success - I finally get stereo sound out of my PCTVpro. =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart1828835.HJDjgO7WAD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBM3UrXhc68WspdLARAmHnAJ9eH5pH9/S0eidxL8Hfn5G3b/HcZACgqTPZ 8MVtnWjSOcZAu5wJsgUW5jg= =fp8U -----END PGP SIGNATURE----- --nextPart1828835.HJDjgO7WAD-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 18:44:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 355C716A4CE for ; Mon, 30 Aug 2004 18:44:05 +0000 (GMT) Received: from cpanel.ezone.ru (cpanel.ezone.ru [213.85.31.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1661743D2F for ; Mon, 30 Aug 2004 18:44:04 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from [81.195.3.51] (ppp3-51.pppoe.mtu-net.ru [81.195.3.51]) (authenticated bits=0) by cpanel.ezone.ru (8.13.1/8.12.11) with ESMTP id i7UIhs6K068629; Mon, 30 Aug 2004 22:43:55 +0400 (MSD) (envelope-from mcsi@mcsi.pp.ru) Message-ID: <41337564.7090905@mcsi.pp.ru> Date: Mon, 30 Aug 2004 22:43:48 +0400 From: Maxim Maximov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040810 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Doug White References: <412FA7E8.80BE87BC@freebsd.org> <20040829172000.F69068@carver.gumbysoft.com> <4132A956.4070604@mcsi.pp.ru> <20040830105333.L85743@carver.gumbysoft.com> In-Reply-To: <20040830105333.L85743@carver.gumbysoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail3.ezone.ru cc: freebsd-current@freebsd.org Subject: Re: [Fwd: cvs commit: src/sys/kern sys_generic.c] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 18:44:05 -0000 Doug White wrote: > On Mon, 30 Aug 2004, Maxim Maximov wrote: > > >>But this commit didn't change anything for me. I'm running your last change >> >>mcsi@ultra(ttyp1) [92] ~> ident /boot/kernel/kernel |grep sys_gen >> $FreeBSD: src/sys/kern/sys_generic.c,v 1.133 2004/08/27 21:23:50 >>andre Exp $ >> >>and experience all the same hangs. > > > Have you been able to reproduce this with a non-X application? I have a > couple of simple Python scripts that you can try running if you want to -- > they generate a bunch of poll() churn. No, I haven't seen that. Please send them, I'll give them a try. > > What X server are you running? This is Xorg 6.7.0. Maybe I should try to rebuild it on current system? mcsi@ultra(ttyp1) [92] ~> Xorg -version Release Date: 18 December 2003 X Protocol Version 11, Revision 0, Release 6.7 Build Operating System: FreeBSD 5.2 i386 [ELF] Current Operating System: FreeBSD ultra.domain 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Sat Aug 28 08:43:11 MSD 2004 mcsi@ultra.domain:/usr/obj/usr/src/sys/ULTRA i386 Build Date: 24 July 2004 Before reporting problems, check http://wiki.X.Org to make sure that you have the latest version. Module Loader present -- Maxim Maximov From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 18:44:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0014916A4CE for ; Mon, 30 Aug 2004 18:44:33 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C16243D4C for ; Mon, 30 Aug 2004 18:44:33 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7UIfY3s054623; Mon, 30 Aug 2004 12:41:35 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 30 Aug 2004 12:41:41 -0600 (MDT) Message-Id: <20040830.124141.44509158.imp@bsdimp.com> To: ahd@kew.com From: "M. Warner Losh" In-Reply-To: <012301c48e25$14924180$84cba8c0@hh.kew.com> References: <012301c48e25$14924180$84cba8c0@hh.kew.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: PCI SIO devices hog interrupts, cause lock order problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 18:44:34 -0000 In message: <012301c48e25$14924180$84cba8c0@hh.kew.com> "Andrew H. Derbyshire" writes: : Basically, any PCI SIO device hogs its interrupt if the PUC device is not : also in the kernel, and this causes real problems for any environment like : mine where pulling the modem is not trivial. Does the distributed GENERIC : kernel have room for the PUC device? Are there side effects that PUC should : be excluded from GENERIC? puc should be in GENERIC, imho. : As a bonus, there appears to be a bug with kernel locking exposed by the : problem. With the stock generic kernel, the XL device reports it couldn't : map the interrupt, and then a lock order reversal is reported. (See the : attached log for the gory details). This is a known problem. Warner From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 18:44:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6B5916A4CF; Mon, 30 Aug 2004 18:44:58 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4317743D1F; Mon, 30 Aug 2004 18:44:58 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7UIgWb3054631; Mon, 30 Aug 2004 12:42:32 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 30 Aug 2004 12:42:38 -0600 (MDT) Message-Id: <20040830.124238.106608377.imp@bsdimp.com> To: tjr@freebsd.org From: "M. Warner Losh" In-Reply-To: <20040830121024.GA57911@cat.robbins.dropbear.id.au> References: <200408291240.i7TCemk02197@Mail.NOSPAM.DynDNS.dK> <20040830121024.GA57911@cat.robbins.dropbear.id.au> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-misuser@NOSPAM.dyndns.dk cc: current@freebsd.org Subject: Re: RELENG_5 buildworld failures X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 18:44:58 -0000 In message: <20040830121024.GA57911@cat.robbins.dropbear.id.au> Tim Robbins writes: : On Sun, Aug 29, 2004 at 02:40:48PM +0200, Barry Bouwsma wrote: : > [keep replies to the list and I'll catch up next time I'm online, thanks] : > : > The beer's on me if this hasn't been fixed -- source updated : > late 22.Aug, haven't been online since then. I've just updated : > my source but haven't done a build, and it looks like there's : > still one problem that has not been addressed, just from reading : > the latest updates. NOT verified yet. : > : > The following makefile seems to need attention to get a crossbuild : > (from 4.x) to succeed -- failures in _depend step at first... : > : > --- /dist/src/FreeBSD5-src/source-hacks/sys/modules/linprocfs/Makefile-ORIG : > Wed Nov 19 06:08:26 2003 : > +++ /dist/src/FreeBSD5-src/source-hacks/sys/modules/linprocfs/Makefile-IS_THIS_S : > TILL_NEEDED Wed Aug 25 07:45:41 2004 : > @@ -6,4 +6,9 @@ : > SRCS= vnode_if.h \ : > linprocfs.c : > +# XXX HACK from current : > +opt_compat.h: : > + touch ${.TARGET} : > + : > + : > .include : > : > : > Note that this is identical to HEAD -- well, kinda. I don't : > see a MFC to RELENG_5 for this. Maybe it's been handled : > somewhere else. If so, the beer's on me too. Patch above is : > ugly and cut-n-pasted. See 1.12 of this file. : : This should be fixed in RELENG_5 with src/sys/modules/linprocfs/Makefie : revision 1.11.4.1. I wonder why the opt_compat.h hack is needed at all. Basically, if you add it to the SRCS list, it happens automatically. Can you try that too? Warner From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 18:53:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B4FC16A4CE for ; Mon, 30 Aug 2004 18:53:05 +0000 (GMT) Received: from ns.atcom.spb.ru (ns.atcom.spb.ru [213.182.169.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 423C043D4C for ; Mon, 30 Aug 2004 18:53:05 +0000 (GMT) (envelope-from toxa@cterra.ru) Received: by ns.atcom.spb.ru (Postfix, from userid 1042) id 7E6B7334; Mon, 30 Aug 2004 22:53:03 +0400 (MSD) Received: from localhost (ppp-dialup-11.atcom.spb.ru [213.182.168.11]) by ns.atcom.spb.ru (Postfix) with ESMTP id 62C282FC for ; Mon, 30 Aug 2004 22:53:01 +0400 (MSD) Date: Mon, 30 Aug 2004 22:50:01 +0400 From: Toxa To: freebsd-current@freebsd.org X-Comment-To: "Anton Karpov" Message-ID: <20040830185001.GA1263@laptoxa.toxa.lan> Mail-Followup-To: freebsd-current@freebsd.org References: <1093852727.864.11.camel@localhost> <200408301458.i7UEweiu045002@sana.init-main.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200408301458.i7UEweiu045002@sana.init-main.com> User-Agent: Outluck Express 1.5.6i for MS-DOS 6.22-SMP X-Mailer: See User-Agent above :) X-Operating-System: MS-DOS 6.22-CURRENT on Sony VAIO laptop X-PGP-Public-Key: http://toxahost.org/gpg/pubkey.asc X-Useless-Header: Do Androids Dream of Electric Sheep? Subject: Re: acpi_video on SONY VAIO PCG-Z1 [was: acpi_video users needed] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 18:53:05 -0000 On Mon, Aug 30, 2004 at 11:58:40PM +0900, takawata@jp.freebsd.org wrote: > Because the ACPI device object has not enough interfaces to get the > acpi_video driver work. > Acpi_video driver does not check PCI device class: it checks the > interfaces instead. > You don't need to bother attaching acpi_video driver. > ###### > Device (VID0) > { > Name (_ADR, 0x00) > OperationRegion (VIDR, PCI_Config, 0x4C, 0x04) > Field (VIDR, ByteAcc, NoLock, Preserve) > { > SSID, 32 > } > Device (CRT) > { > Name (_ADR, 0x0100) > } > Device (LCD) > { > Name (_ADR, 0x0110) > } > Device (TV) > { > Name (_ADR, 0x0200) > } > } > } Well I have such Device in my asl file. But still has no video sysctl variables. It seems to me that video is the only thing which doesn't works after resuming from suspend, I can log in remotely via ssh but monitor looks "dead" (or "frozen"). -- Anton A. Karpov PGP key: http://www.toxahost.org/pgp/pubkey.asc You can finger me @toxahost.org for my current status =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~= Hi! I am a .signature virus! Copy me into your ~/.signature to help me spread! =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~= From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 19:02:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E91416A4CE for ; Mon, 30 Aug 2004 19:02:26 +0000 (GMT) Received: from imap.univie.ac.at (mailbox-lmtp.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F2A443D48 for ; Mon, 30 Aug 2004 19:02:25 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from [192.168.0.4] (adslle.cc.univie.ac.at [131.130.102.11]) by imap.univie.ac.at (8.12.10/8.12.10) with ESMTP id i7UJ2IuD219290; Mon, 30 Aug 2004 21:02:20 +0200 Date: Mon, 30 Aug 2004 21:02:22 +0200 (CEST) From: Lukas Ertl To: Daniel Eriksson In-Reply-To: Message-ID: <20040830210124.T550@korben.in.tern> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-DCC-ZID-Univie-Metrics: imap 4248; Body=2 Fuz1=2 Fuz2=2 cc: freebsd-current@FreeBSD.org Subject: RE: PLEASE TEST: IPI deadlock avoidance patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 19:02:26 -0000 On Mon, 30 Aug 2004, Daniel Eriksson wrote: > Ok, I've run a few more tests now, and the results are not looking very good > for gvinum in RAID-5 mode: OK, I'm looking into it. It wasn't able to reproduce these corruption yet, but I'll try to stress it a bit. Thanks for the tests and the reports. cheers, le -- Lukas Ertl http://homepage.univie.ac.at/l.ertl/ le@FreeBSD.org http://people.freebsd.org/~le/ From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 19:06:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 379D616A4CE; Mon, 30 Aug 2004 19:06:13 +0000 (GMT) Received: from av1-1-sn3.vrr.skanova.net (av1-1-sn3.vrr.skanova.net [81.228.9.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA38443D54; Mon, 30 Aug 2004 19:06:12 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av1-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 1DFC037F48; Mon, 30 Aug 2004 21:06:12 +0200 (CEST) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 0A93F37E47; Mon, 30 Aug 2004 21:06:12 +0200 (CEST) Received: from gadget (h130n1fls11o822.telia.com [213.64.66.130]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id D87C438022; Mon, 30 Aug 2004 21:06:10 +0200 (CEST) From: "Daniel Eriksson" To: "'Pawel Jakub Dawidek'" Date: Mon, 30 Aug 2004 21:06:12 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcSOxGo3Qh8ZmE8rShyHRnaXT0MkLQ== cc: freebsd-current@freebsd.org Subject: RE: ataraid + geom_stripe problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 19:06:13 -0000 Pawel Jakub Dawidek wrote: > When new provider is created it is given for taste to other classes. > This interrupt storm could be a result of some kind of abuse from > one of existing classes. > > Could you provide output of command: > > # sysctl -b kern.geom.conftxt | awk '{print $2}' | sort | uniq This is the output from the current system (no geom_stripe, and gvinum started): # sysctl -b kern.geom.conftxt | awk '{print $2}' | sort | uniq BSD DISK MBR VINUMDRIVE VINUMPLEX VINUMVOLUME > It will be good if you could try unload some classes (gvinum, > etc.) before loading geom_stripe, just to be sure. At the time of the error, no other modules were loaded (except acpi). This was right after booting the machine in single-user mode. > Increasing kern.geom.stripe.debug could be also interesting. When (if?) I try this again, I'll be sure to increase that setting. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 19:13:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E23F216A4CE; Mon, 30 Aug 2004 19:13:33 +0000 (GMT) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5616043D41; Mon, 30 Aug 2004 19:13:33 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr2.xs4all.nl (8.12.11/8.12.11) with ESMTP id i7UJDRdI004468; Mon, 30 Aug 2004 21:13:30 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.11/8.12.9) with ESMTP id i7UJDQ5q053069; Mon, 30 Aug 2004 21:13:26 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.12.11/8.12.11/Submit) id i7UJDP43053064; Mon, 30 Aug 2004 21:13:25 +0200 (CEST) (envelope-from wb) Date: Mon, 30 Aug 2004 21:13:25 +0200 From: Wilko Bulte To: Ken Smith Message-ID: <20040830191325.GA53006@freebie.xs4all.nl> References: <20040829151021.GA43674@bobbi.cse.buffalo.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="dDRMvlgZJXvWKvBx" Content-Disposition: inline In-Reply-To: <20040829151021.GA43674@bobbi.cse.buffalo.edu> User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.10-STABLE X-PGP: finger wilko@freebsd.org X-Virus-Scanned: by XS4ALL Virus Scanner cc: freebsd-current@freebsd.org cc: freebsd-alpha@freebsd.org Subject: Addendum: FreeBSD 5.3-BETA2 for Alpha/AXP Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 19:13:34 -0000 --dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Coming soon to an ftp-server near you: FreeBSD 5.3-BETA2 for the Alpha architecture: MD5 (5.3-BETA2-alpha-bootonly.iso) =3D 1354f160d76f4aa55734bd16e6588f1e MD5 (5.3-BETA2-alpha-disc2.iso) =3D 8f872b6efbbad457578b78e915a0a0c8 MD5 (5.3-BETA2-alpha-miniinst.iso) =3D cdbb21822df84c94d3a1912d8d7ea2bb Test status I try to keep up to date at: http://people.freebsd.org/~wilko/testhw.html Enjoy.. --=20 Wilko Bulte wilko@FreeBSD.org --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 5.0i for non-commercial use MessageID: WB8ZZervluJdpivMpbYSITLN7n2j1GKp Comment: Requires PGP version 2.6 or later. iQCVAwUBQTN8VPymwUj/iuMFAQGimQP9GnAJxNo9SBpAZl9qIAMQPzvh5hK5PfnV IEQxLA4TGG0KOxvi32YFqRHCjEZWEkt9R5RLK8cJbPCgNLA8i4cgHK+nDiWBgRh5 wQSWgurElQPOCxljKDYouuCoC5UTKu8N+2pVqRo28eEjWp5J6RSkcHpkXzPydYfw N1rl97w78Pg= =rkhu -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 19:22:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 636AC16A4D4 for ; Mon, 30 Aug 2004 19:22:48 +0000 (GMT) Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8C6843D55 for ; Mon, 30 Aug 2004 19:22:45 +0000 (GMT) (envelope-from dashevil@sympatico.ca) Received: from [192.168.2.32] ([65.93.59.22]) by tomts5-srv.bellnexxia.net ESMTP <20040830192244.FMB18869.tomts5-srv.bellnexxia.net@[192.168.2.32]> for ; Mon, 30 Aug 2004 15:22:44 -0400 From: Chris Laverdure To: freebsd-current@freebsd.org Content-Type: text/plain Message-Id: <1093879363.74399.7.camel@elemental.DashEvil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 30 Aug 2004 15:22:44 +0000 Content-Transfer-Encoding: 7bit Subject: smb mount panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 19:22:48 -0000 I'm not actually sure if this is a samba problem, but anyway: I have all of my mp3s stored on another box and shared with samba. Most of the time on first boot I execute the following command: mount -t smbfs //incubus@sylvia/root /Network/Sylvia For some reason whenever I do that now I get some sort of kld related error (even though netsmb_dev loads), and then I have to do it again for it to actually mount the share. More importantly, and this seems to be dependant on how long I have my box up, if I do this with say.. 48 minutes of uptime, I am greated to a beautiful kernel panic. I'm sorry for not providing any debug messages or anything of that sort -- I'm about to hit the shower. But if anyone is interested I can provide any information they wish. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 19:23:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12B8616A4CE for ; Mon, 30 Aug 2004 19:23:17 +0000 (GMT) Received: from shub-internet.kew.com (h00062574bf3c.ne.client2.attbi.com [66.30.223.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id E180143D58 for ; Mon, 30 Aug 2004 19:23:16 +0000 (GMT) (envelope-from ahd@kew.com) Received: by shub-internet.kew.com (Postfix, from userid 1001) id 6B6CD12351; Mon, 30 Aug 2004 15:23:16 -0400 (EDT) To: freebsd-current@freebsd.org In-Reply-To: <20040830.124141.44509158.imp@bsdimp.com> Message-Id: <20040830192316.6B6CD12351@shub-internet.kew.com> Date: Mon, 30 Aug 2004 15:23:16 -0400 (EDT) From: ahd@kew.com (Drew Derbyshire) Subject: Re: PCI SIO devices hog interrupts, cause lock order problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 19:23:17 -0000 > From imp@bsdimp.com Mon Aug 30 14:50:50 2004 > : Basically, any PCI SIO device hogs its interrupt if the PUC device is not > : also in the kernel, and this causes real problems for any environment like > : mine where pulling the modem is not trivial. Does the distributed GENERIC > : kernel have room for the PUC device? Are there side effects that PUC should > : be excluded from GENERIC? > > puc should be in GENERIC, imho. Who makes the call (or the commit)? The cost is ~ 55K on disk (which seems excessive) with current build, I assume that's bloated by the current kernel options. > : As a bonus, there appears to be a bug with kernel locking exposed by the > : problem. With the stock generic kernel, the XL device reports it couldn't > : map the interrupt, and then a lock order reversal is reported. (See the > : attached log for the gory details). > > This is a known problem. Well, it at least it didn't panic on me, which previous experiments (months ago) were prone to do. -ahd- p.s. Sorry about the original mail being ugly MS HTML. I needed the MIME, not the HTML. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 19:25:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFEB316A4CF for ; Mon, 30 Aug 2004 19:25:20 +0000 (GMT) Received: from mallaury.noc.nerim.net (smtp-101-monday.noc.nerim.net [62.4.17.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7D6043D5F for ; Mon, 30 Aug 2004 19:25:02 +0000 (GMT) (envelope-from bettan@nerim.net) Received: from frederic (linux-win.com [62.212.121.38]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 0B1E962E1C; Mon, 30 Aug 2004 21:24:59 +0200 (CEST) Message-ID: <000e01c48ec7$0b6597e0$0401a8c0@frederic> From: "bettan" To: "Dave McCammon" , References: <20040830164137.91119.qmail@web41409.mail.yahoo.com> Date: Mon, 30 Aug 2004 21:25:00 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Antivirus: avast! (VPS 0435-2, 28/08/2004), Outbound message X-Antivirus-Status: Clean Subject: Re: 5.3 beta2 bridging X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 19:25:20 -0000 Don't use sysctl for bridge but ng_bridge in freebsd with this script /usr/share/examples/netgraph/ether.bridge and it will work good. ----- Original Message ----- From: "Dave McCammon" To: Sent: Monday, August 30, 2004 6:41 PM Subject: 5.3 beta2 bridging > I couldn't get bridging to work in beta1. I just > upgraded to beta2 and still can't get bridging to > work. > > here is original message except now it is -BETA2 > > http://docs.FreeBSD.org/cgi/mid.cgi?20040826204237.44644.qmail > > > > > > _______________________________ > Do you Yahoo!? > Win 1 of 4,000 free domain names from Yahoo! Enter now. > http://promotions.yahoo.com/goldrush > _______________________________________________ > 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 Aug 30 19:28:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D41416A4CE; Mon, 30 Aug 2004 19:28:45 +0000 (GMT) Received: from obh.snafu.de (obh.snafu.de [213.73.92.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFA7843D46; Mon, 30 Aug 2004 19:28:44 +0000 (GMT) (envelope-from ob@gruft.de) Received: from ob by obh.snafu.de with local (Exim 4.34 (FreeBSD)) id 1C1rpb-000FQH-EG; Mon, 30 Aug 2004 21:28:43 +0200 Date: Mon, 30 Aug 2004 21:28:43 +0200 From: Oliver Brandmueller To: Andre Oppermann Message-ID: <20040830192843.GB51110@e-Gitt.NET> References: <20040827084306.GB74653@e-Gitt.NET> <412F276A.6080807@freebsd.org> <20040827141354.GC74653@e-Gitt.NET> <412F5307.5040005@freebsd.org> <20040830103216.GA51110@e-Gitt.NET> <41334E8F.377FFD80@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41334E8F.377FFD80@freebsd.org> User-Agent: Mutt/1.5.6i Sender: Oliver Brandmueller cc: current@freebsd.org Subject: Re: RELENG_5 ipfw problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 19:28:45 -0000 Hi. On Mon, Aug 30, 2004 at 05:58:07PM +0200, Andre Oppermann wrote: > Ok, it seems you suffer from a small logic change I made when redoing the > ipfw fwd option. This was supposed to prevent foot-shooting but also > prevents your setup from working. Try the attached patch (probably white- > space mangled). [...] > - if (!in_localip(ip->ip_src) && !in_localaddr(ip->ip_dst)) { > + if (!in_localip(ip->ip_src)) { I changed the line in this file, recompiled and booted the kernel - but I cannot see any change in the behaviour, sorry. - Oliver -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 19:32:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF97C16A4CE for ; Mon, 30 Aug 2004 19:32:52 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id E94D043D79 for ; Mon, 30 Aug 2004 19:32:51 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i7UJWoHE056851; Mon, 30 Aug 2004 21:32:51 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: ahd@kew.com (Drew Derbyshire) From: "Poul-Henning Kamp" In-Reply-To: Your message of "Mon, 30 Aug 2004 15:23:16 EDT." <20040830192316.6B6CD12351@shub-internet.kew.com> Date: Mon, 30 Aug 2004 21:32:50 +0200 Message-ID: <56850.1093894370@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: freebsd-current@freebsd.org Subject: Re: PCI SIO devices hog interrupts, cause lock order problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 19:32:52 -0000 In message <20040830192316.6B6CD12351@shub-internet.kew.com>, Drew Derbyshire w rites: >> puc should be in GENERIC, imho. I agree. >Who makes the call (or the commit)? The cost is ~ 55K on disk >(which seems excessive) with current build, I assume that's bloated >by the current kernel options. This could be vastly improved if the data structure puc uses were more intelligent. Man cards could be described simply by their PCI ID and "fill resource #1 with sio ports" rather than the very space consuming and errorprone stuff we do now. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 19:38:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 618) id 508F816A4D0; Mon, 30 Aug 2004 19:38:09 +0000 (GMT) In-Reply-To: <20040825095742.Y88889@zone3.gcu-squad.org> from iMil at "Aug 25, 2004 10:09:42 am" To: imil@home.imil.net (iMil) Date: Mon, 30 Aug 2004 19:38:09 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20040830193809.508F816A4D0@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) cc: current@freebsd.org Subject: Re: Project Evil on a WG311v2: working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 19:38:09 -0000 > here comes: > cvs up is from Aug 20, > ndis0: flags=8843 mtu 1500 > ndis0: mem > 0xef000000-0xef01ffff,0xef020000-0xef021fff irq 12 at device 18.0 on pci0 > ndis0: [GIANT-LOCKED] > ndis0: NDIS API version: 5.0 <------ > ndis0: Ethernet address: 00:09:5b:8f:d7:df > everything fine here, now : > # ifconfig ndis0 ssid "MY SSID" mediaopt adhoc up > ifconfig: SIOCS80211: Invalid argument Grrrrr. Go back to the driver CD that came with your card and use the Windows XP driver like you were supposed to. If you do, you should see this instead: twi0: mem 0xf4020000-0xf403ffff,0xf4008000-0xf4009fff irq 10 at device 14.0 on pci0 twi0: NDIS API version: 5.1 <-------- twi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps twi0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps You never bothered to mention just which Windows driver from the CD that you used, but now I know it wasn't the XP one. You probably picked the Win2000 one instead. Minus 10 points for you. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 20:09:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7B9F16A4CE for ; Mon, 30 Aug 2004 20:09:56 +0000 (GMT) Received: from smtp.tal.de (s05.tal.de [81.92.0.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12E6543D1D for ; Mon, 30 Aug 2004 20:09:56 +0000 (GMT) (envelope-from markus@brueffer.de) Received: from ramses.kicks-ass.net (unknown [82.139.198.15]) by smtp.tal.de (SMTP.TAL.DE) with ESMTP id 1C9E526E92 for ; Mon, 30 Aug 2004 22:09:54 +0200 (CEST) Received: from cheops.phoenix (cheops.phoenix [192.168.1.3]) by ramses.kicks-ass.net (Postfix) with ESMTP id E5A26B81B for ; Mon, 30 Aug 2004 22:09:53 +0200 (CEST) From: Markus Brueffer To: current@freebsd.org Date: Mon, 30 Aug 2004 22:10:07 +0200 User-Agent: KMail/1.6.82 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1256158.ynV9h8UqLN"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200408302210.20652.markus@brueffer.de> Subject: Interrupt storm on uhciX with acpi_pci_link.c 1.24.2.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 20:09:57 -0000 --nextPart1256158.ynV9h8UqLN Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, I'm running latest RELENG_5 (already with acpi_pci_link.c 1.24.2.3) and get: 'Interrupt storm detected on "irq5: uhci0 uhci1"; throttling interrupt sour= ce' stortly after the login prompt appears. Without acpi everything seems to wo= rk=20 fine. Mainboard is an ASUS CUV4X-D with latest BIOS (1016) and 2 PIII 1GHz. dmesgs of verbose boots are here: http://ramses.kicks-ass.net/markus/markus-dmesg-with-acpi http://ramses.kicks-ass.net/markus/markus-dmesg-without-acpi acpidump: http://ramses.kicks-ass.net/markus/markus-cuv4x-d.asl Kernelconfig: http://ramses.kicks-ass.net/markus/GALAXY brueffer@ramses:~ # sysctl hw.acpi hw.acpi.supported_sleep_state: S1 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 1 hw.acpi.reset_video: 1 hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% If you need any more information, please let me know. Markus =2D-=20 Markus Brueffer | GPG-Key: http://people.FreeBSD.org/~markus/markus.asc markus@brueffer.de | FP: 3F9B EBE8 F290 E5CC 1447 8760 D48D 1072 78F8 A8D4 markus@FreeBSD.org | FreeBSD: The Power to Serve! --nextPart1256158.ynV9h8UqLN Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBBM4ms1I0Qcnj4qNQRAvydAJ46RahDTOXlzufsPgJw7CYSQaB0AwCg/KBm rA02EB+jNbWnRcY1e4UHjDw= =v4Ez -----END PGP SIGNATURE----- --nextPart1256158.ynV9h8UqLN-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 20:41:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C0FE16A4CE for ; Mon, 30 Aug 2004 20:41:00 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E7C943D58 for ; Mon, 30 Aug 2004 20:40:59 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i7UKevri002989; Mon, 30 Aug 2004 22:40:57 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <413390B9.5050705@DeepCore.dk> Date: Mon, 30 Aug 2004 22:40:25 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "J.R. Oldroyd" References: <412F5A10.8080907@drexel.edu> <412F7292.6000804@DeepCore.dk> <20040830181540.GA809@linwhf.opal.com> <413372B3.5010603@DeepCore.dk> <20040830192224.GB809@linwhf.opal.com> In-Reply-To: <20040830192224.GB809@linwhf.opal.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: "J.R. Oldroyd" cc: current@freebsd.org Subject: Re: Current 8/27/2004, DVD problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 20:41:00 -0000 J.R. Oldroyd wrote: > Well, I am not sure what was going on when I typed that, but I had > just cvsup'd the latest -current, so what I had meant to type was that > it was the current of today, 2004/08/30 at 13:30 GMT. Have you tried disabling ATAPI DMA in loader.conf ? -S=F8ren From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 20:51:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 346E416A4CF; Mon, 30 Aug 2004 20:51:47 +0000 (GMT) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3388F43D5F; Mon, 30 Aug 2004 20:51:46 +0000 (GMT) (envelope-from q@uni.de) Received: from wrzx34.rz.uni-wuerzburg.de (wrzx34.rz.uni-wuerzburg.de [132.187.3.34]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id F386BD1525; Mon, 30 Aug 2004 22:51:44 +0200 (CEST) Received: from virusscan (localhost [127.0.0.1]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id D6B059ACAD; Mon, 30 Aug 2004 22:51:44 +0200 (CEST) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id B4C1C9ABF0; Mon, 30 Aug 2004 22:51:44 +0200 (CEST) Received: from coyote.q.local (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id A11C1D1525; Mon, 30 Aug 2004 22:51:44 +0200 (CEST) Received: from igor.q.local (igor [192.168.0.148]) by coyote.q.local (8.12.10/8.12.10) with ESMTP id i7UKpiTH035367; Mon, 30 Aug 2004 22:51:44 +0200 (CEST) (envelope-from q@igor.q.local) Received: from igor.q.local (localhost [127.0.0.1]) by igor.q.local (8.13.1/8.13.1) with ESMTP id i7UKpiHI004351; Mon, 30 Aug 2004 22:51:44 +0200 (CEST) (envelope-from q@igor.q.local) Received: (from q@localhost) by igor.q.local (8.13.1/8.13.1/Submit) id i7UKpheS004350; Mon, 30 Aug 2004 22:51:43 +0200 (CEST) (envelope-from q) Date: Mon, 30 Aug 2004 22:51:43 +0200 From: Ulrich Spoerlein To: Oliver Brandmueller Message-ID: <20040830205143.GA749@galgenberg.net> Mail-Followup-To: Oliver Brandmueller , Andre Oppermann , current@freebsd.org References: <20040827084306.GB74653@e-Gitt.NET> <412F276A.6080807@freebsd.org> <20040827141354.GC74653@e-Gitt.NET> <412F5307.5040005@freebsd.org> <20040830103216.GA51110@e-Gitt.NET> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: <20040830103216.GA51110@e-Gitt.NET> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) cc: Andre Oppermann cc: current@freebsd.org Subject: Re: RELENG_5 ipfw problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 20:51:47 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 30.08.2004 at 12:32:16 +0200, Oliver Brandmueller wrote: > # ipfw show > 00200 2694 118536 fwd 192.168.25.1 tcp from 192.168.25.5 25 to 213.XX= X.XXX.0/24 >=20 > packets are accepted, but not forwarded. Can anyone else reproduce this? I ran into the same issue on 5.1 with ipfw2. For me, fwd never worked with IPFW2, even on -STABLE when compiled with -DIPFW2 the fwd directive didn't work. I'm not using it anymore, so I can't reproduce the problem. Ulrich Spoerlein --=20 PGP Key ID: F0DB9F44 Get it while it's hot! PGP Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBM5NfmArGtfDbn0QRAjbKAKDTGROjOD2gObwnZFY5yOUMlrDFZQCbBmPH SMgPd+Aw3H2mRVe6pheWbVg= =A8bu -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 20:55:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31AB516A4DF for ; Mon, 30 Aug 2004 20:55:27 +0000 (GMT) Received: from www.sofsis.cl (pc-200-74-65-184.asturias1.pc.metropolis-inter.com [200.74.65.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF58243D58 for ; Mon, 30 Aug 2004 20:55:23 +0000 (GMT) (envelope-from bob@sofsis.cl) Received: from [10.0.0.100] (pc-200-74-65-184.asturias1.pc.metropolis-inter.com [200.74.65.184]) (authenticated bits=0) by www.sofsis.cl (8.12.10/8.12.10) with ESMTP id i7UKuVEg050013 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Aug 2004 16:56:45 -0400 (CLT) (envelope-from bob@sofsis.cl) From: User A To: current@freebsd.org Content-Type: text/plain Message-Id: <1093884893.20957.3.camel@book> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 30 Aug 2004 16:54:53 +0000 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version devel-20040712, clamav-milter version 0.74a on www.sofsis.cl X-Virus-Status: Clean X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on www.sofsis.cl Subject: net.inet.ip.portrange.randomized=RANDOM_IP_ID ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 20:55:27 -0000 Hello, has option RANDOM_IP_ID been replaced with net.inet.ip.portrange.randomized? or they are different things? thanks, From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 21:08:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F50316A4CE; Mon, 30 Aug 2004 21:08:20 +0000 (GMT) Received: from wrzx35.rz.uni-wuerzburg.de (wrzx35.rz.uni-wuerzburg.de [132.187.3.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD25B43D49; Mon, 30 Aug 2004 21:08:19 +0000 (GMT) (envelope-from q@uni.de) Received: from wrzx30.rz.uni-wuerzburg.de (wrzx30.rz.uni-wuerzburg.de [132.187.1.30]) by wrzx35.rz.uni-wuerzburg.de (Postfix) with ESMTP id 89F7DD9C5A; Mon, 30 Aug 2004 23:08:18 +0200 (CEST) Received: from virusscan (localhost [127.0.0.1]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id 6313480275; Mon, 30 Aug 2004 23:08:18 +0200 (CEST) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id 4177A76764; Mon, 30 Aug 2004 23:08:18 +0200 (CEST) Received: from coyote.q.local (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id 2D214D18A6; Mon, 30 Aug 2004 23:08:18 +0200 (CEST) Received: from igor.q.local (igor [192.168.0.148]) by coyote.q.local (8.12.10/8.12.10) with ESMTP id i7UL8ITH035444; Mon, 30 Aug 2004 23:08:18 +0200 (CEST) (envelope-from q@igor.q.local) Received: from igor.q.local (localhost [127.0.0.1]) by igor.q.local (8.13.1/8.13.1) with ESMTP id i7UL8HQd004529; Mon, 30 Aug 2004 23:08:17 +0200 (CEST) (envelope-from q@igor.q.local) Received: (from q@localhost) by igor.q.local (8.13.1/8.13.1/Submit) id i7UL8HGU004528; Mon, 30 Aug 2004 23:08:17 +0200 (CEST) (envelope-from q) Date: Mon, 30 Aug 2004 23:08:17 +0200 From: Ulrich Spoerlein To: "David O'Brien" Message-ID: <20040830210817.GB749@galgenberg.net> Mail-Followup-To: David O'Brien , Kenneth Stailey , freebsd-current@freebsd.org References: <20040829213449.GA33843@hub.freebsd.org> <20040830135311.11040.qmail@web50603.mail.yahoo.com> <20040830163106.GA19044@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yNb1oOkm5a9FJOVX" Content-Disposition: inline In-Reply-To: <20040830163106.GA19044@dragon.nuxi.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) cc: Kenneth Stailey cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 21:08:20 -0000 --yNb1oOkm5a9FJOVX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 30.08.2004 at 09:31:06 -0700, David O'Brien wrote: > > mergemasters is gross. Have you ever tried to run it on an 80-column d= isplay? > > I absolutely hate the "left" "right" stuff. You push the "l" with your= right > > hand and the "r" with your left for crying out loud. >=20 > LOL!! This is not funny. I myself have to think loud about which button to press. 'r' is on the left keyboard side and 'l' is to the right. Not good. Better would be something like unison, where you use ,/. or (but this >< thing is on the same key on a german keyboard...) > Note, though, that this output has nothing to do with mergemaster -- it > is sdiff(1) that is used. What you don't like is sdiff(1)'s output > format. Looks like one can't configure the used keys... Ulrich Spoerlein --=20 PGP Key ID: F0DB9F44 Get it while it's hot! PGP Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin --yNb1oOkm5a9FJOVX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBM5dBmArGtfDbn0QRAmXsAKDK75+eYcj+ZF3KswAgpK4gnhp6rACgsCrH PBTMWZLliXNBE1TwpF1W+Dc= =6GCj -----END PGP SIGNATURE----- --yNb1oOkm5a9FJOVX-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 21:09:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 095AF16A4CE for ; Mon, 30 Aug 2004 21:09:26 +0000 (GMT) Received: from web41405.mail.yahoo.com (web41405.mail.yahoo.com [66.218.93.71]) by mx1.FreeBSD.org (Postfix) with SMTP id F232943D5C for ; Mon, 30 Aug 2004 21:09:25 +0000 (GMT) (envelope-from davemac11@yahoo.com) Message-ID: <20040830210925.37659.qmail@web41405.mail.yahoo.com> Received: from [168.91.4.66] by web41405.mail.yahoo.com via HTTP; Mon, 30 Aug 2004 14:09:25 PDT Date: Mon, 30 Aug 2004 14:09:25 -0700 (PDT) From: Dave McCammon To: bettan , freebsd-current@freebsd.org In-Reply-To: <000e01c48ec7$0b6597e0$0401a8c0@frederic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: 5.3 beta2 bridging X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 21:09:26 -0000 --- bettan wrote: > Don't use sysctl for bridge but ng_bridge in freebsd > with this script > /usr/share/examples/netgraph/ether.bridge and it > will work good. didn't. __________________________________ Do you Yahoo!? Y! Messenger - Communicate in real time. Download now. http://messenger.yahoo.com From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 21:12:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C42A016A4CF for ; Mon, 30 Aug 2004 21:12:18 +0000 (GMT) Received: from www.sofsis.cl (pc-200-74-65-184.asturias1.pc.metropolis-inter.com [200.74.65.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E4F043D64 for ; Mon, 30 Aug 2004 21:12:17 +0000 (GMT) (envelope-from bob@sofsis.cl) Received: from [10.0.0.100] (pc-200-74-65-184.asturias1.pc.metropolis-inter.com [200.74.65.184]) (authenticated bits=0) by www.sofsis.cl (8.12.10/8.12.10) with ESMTP id i7ULDSEg050132 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO) for ; Mon, 30 Aug 2004 17:13:35 -0400 (CLT) (envelope-from bob@sofsis.cl) From: User A To: current@freebsd.org In-Reply-To: <1093884893.20957.3.camel@book> References: <1093884893.20957.3.camel@book> Content-Type: text/plain; charset=iso8859-15 Message-Id: <1093885911.71655.0.camel@book> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 30 Aug 2004 17:11:51 +0000 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamd / ClamAV version devel-20040712, clamav-milter version 0.74a on www.sofsis.cl X-Virus-Status: Clean X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on www.sofsis.cl Subject: Re: net.inet.ip.portrange.randomized=RANDOM_IP_ID ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 21:12:18 -0000 im so sorry its net.inet.ip.random_id bye. El lun, 30-08-2004 a las 16:54, User A escribió: > Hello, > > > has option RANDOM_IP_ID been replaced with > net.inet.ip.portrange.randomized? > > or they are different things? > > thanks, > > _______________________________________________ > 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 Aug 30 21:16:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1F9A16A4CE for ; Mon, 30 Aug 2004 21:16:17 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.183]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9097C43D49 for ; Mon, 30 Aug 2004 21:16:17 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.155] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1C1tVg-0004X6-00; Mon, 30 Aug 2004 23:16:16 +0200 Received: from [84.128.139.129] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1C1tVf-0005Ol-00; Mon, 30 Aug 2004 23:16:16 +0200 From: Max Laier To: freebsd-current@freebsd.org Date: Mon, 30 Aug 2004 23:14:41 +0200 User-Agent: KMail/1.6.2 References: <1093884893.20957.3.camel@book> In-Reply-To: <1093884893.20957.3.camel@book> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_Jj5MBCBuD7YtSpN"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408302314.49170.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: User A Subject: Re: net.inet.ip.portrange.randomized=RANDOM_IP_ID ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 21:16:18 -0000 --Boundary-02=_Jj5MBCBuD7YtSpN Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 30 August 2004 18:54, User A wrote: > Hello, > > has option RANDOM_IP_ID been replaced with src/UPDATING: 20040814: The RANDOM_IP_ID option has been replaced by the sysctl net.inet.ip.random_id. If you had RANDOM_IP_ID in your kernel then you may want to add "net.inet.ip.random_id=3D1" to /etc/sysctl.conf. > net.inet.ip.portrange.randomized? No, that's got nothing to do with it. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-02=_Jj5MBCBuD7YtSpN Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBM5jJXyyEoT62BG0RAuuCAJ9L55z8+9S2BidzH1smPkJShu6XOACfVzYx GKMzU9uhZMwBm1fb8zd9B4E= =g6mD -----END PGP SIGNATURE----- --Boundary-02=_Jj5MBCBuD7YtSpN-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 21:22:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7ED716A4CE for ; Mon, 30 Aug 2004 21:22:46 +0000 (GMT) Received: from grummit.biaix.org (86.Red-213-97-212.pooles.rima-tde.net [213.97.212.86]) by mx1.FreeBSD.org (Postfix) with SMTP id 2A2A443D1F for ; Mon, 30 Aug 2004 21:22:45 +0000 (GMT) (envelope-from lists-freebsd-current@biaix.org) Received: (qmail 46781 invoked by uid 1000); 30 Aug 2004 21:20:55 -0000 Date: Mon, 30 Aug 2004 23:20:54 +0200 From: Joan Picanyol To: "current@freebsd.org" Message-ID: <20040830212054.GA42772@grummit.biaix.org> Mail-Followup-To: "current@freebsd.org" References: <41336B5E.7080000@drexel.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41336B5E.7080000@drexel.edu> User-Agent: Mutt/1.4.1i Subject: Re: Thread problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 21:22:46 -0000 * Justin Smith [20040830 20:01]: > FreeBSD jsmith.org 5.3-BETA2 FreeBSD 5.3-BETA2 #0: Mon Aug 30 06:37:58 > EDT 2004 root@:/usr/obj/usr/src/sys/MYKERNEL i386 > > The pan newsreader (recompiled) crashes on startup: > > > GThread-ERROR **: file gthread-posix.c: line 137 (): error 'No such > process' during 'pthread_getschedparam (pthread_self(), &policy, &sched)' > aborting... > Abort trap (core dumped) ldd `whereis pan` will show that your binary is linked against to thread libraries. A quick workaround is to add the following to libmap.conf: libc_r.so.5 libpthread.so.1 # Everything that uses 'libc_r' libc_r.so libpthread.so # now uses 'libpthread' qvb -- pica From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 21:27:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 235AE16A4CE for ; Mon, 30 Aug 2004 21:27:59 +0000 (GMT) Received: from linwhf.opal.com (70.79.171.66.subscriber.vzavenue.net [66.171.79.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A14E43D41 for ; Mon, 30 Aug 2004 21:27:58 +0000 (GMT) (envelope-from jr@opal.com) Received: (jr@localhost) by linwhf.opal.com (8.12.11/jr6.1/Submit) for id i7ULRgEi000919; Mon, 30 Aug 2004 17:27:42 -0400 (EDT) Date: Mon, 30 Aug 2004 17:27:42 -0400 From: "J.R. Oldroyd" To: =?iso-8859-1?Q?S=F8ren?= Schmidt Message-ID: <20040830212742.GA893@linwhf.opal.com> References: <412F5A10.8080907@drexel.edu> <412F7292.6000804@DeepCore.dk> <20040830181540.GA809@linwhf.opal.com> <413372B3.5010603@DeepCore.dk> <20040830192224.GB809@linwhf.opal.com> <413390B9.5050705@DeepCore.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <413390B9.5050705@DeepCore.dk> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: Current 8/27/2004, DVD problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 21:27:59 -0000 I had not done so with this -current, so I just did, but it still makes no difference. I now have hw.ata.atapi_dma=0 in /boot/loader.conf. Same ATAPI_RESET message and hang at the DVD probe. I also tried with and without media. No difference either. -jr On Aug 30, 22:40, Søren Schmidt wrote: > J.R. Oldroyd wrote: > >Well, I am not sure what was going on when I typed that, but I had > >just cvsup'd the latest -current, so what I had meant to type was that > >it was the current of today, 2004/08/30 at 13:30 GMT. > > Have you tried disabling ATAPI DMA in loader.conf ? > > -Søren > From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 21:33:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB8AF16A4CE for ; Mon, 30 Aug 2004 21:33:40 +0000 (GMT) Received: from smtp.housing.ufl.edu (smtp.housing.ufl.edu [128.227.47.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4869F43D58 for ; Mon, 30 Aug 2004 21:33:40 +0000 (GMT) (envelope-from WillS@housing.ufl.edu) Received: (qmail 90117 invoked by uid 98); 30 Aug 2004 17:33:39 -0400 Received: from WillS@housing.ufl.edu by smtp.housing.ufl.edu by uid 1003 with qmail-scanner-1.20 (spamassassin: 2.63. Clear:RC:1(128.227.47.18):. Processed in 0.013352 secs); 30 Aug 2004 21:33:39 -0000 X-Qmail-Scanner-Mail-From: WillS@housing.ufl.edu via smtp.housing.ufl.edu X-Qmail-Scanner: 1.20 (Clear:RC:1(128.227.47.18):. Processed in 0.013352 secs) Received: from bragi.housing.ufl.edu (128.227.47.18) by smtp.housing.ufl.edu with (RC4-MD5 encrypted) SMTP; 30 Aug 2004 17:33:39 -0400 Received: bragi.housing.ufl.edu 128.227.47.18 from 10.2.3.199 10.2.3.199 via HTTP with MS-WebStorage 6.0.6249 User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Mon, 30 Aug 2004 17:31:57 -0400 From: Will Saxon To: "freebsd-current@freebsd.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: 5.3-BETA2 boot hang, maybe acpi related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 21:33:41 -0000 I have a problem similar to the 'hang during CDROM detection' thread that is also going on right now. When I try to boot from either a 5.3-BETA2 CD or a 5.3-BETA2 installation on my hard drive, I experience a boot hang. I have one hard drive with FreeBSD connected as the master drive on the first PATA channel. I have an optical drive connected as the slave drive on the second PATA channel. I have one drive connected to the first channel on the SATA controller. I have the SATA controller selected in the BIOS as my boot device. I have been booting FreeBSD via a boot menu on the SATA drive. I get all the way to: ad0: 8223MB at ata1-slave UDMA33 At which point bootup hangs. If I boot with verbose logging, I can see that ata2 gets reset a couple of times and then nothing. There may be other interesting messages, but they pass too quickly for me to read. If I disable ACPI, I can boot normally. If I disable my SATA controller, I can boot normally. If I remove the drive connected to the SATA controller, I can boot normally. This all worked fine with 5.2.1-RELEASE. I think this might relate to pr/70925, so I posted a followup there also. -Will From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 21:36:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21A6016A4CF for ; Mon, 30 Aug 2004 21:36:41 +0000 (GMT) Received: from shrike.submonkey.net (cpc2-cdif3-6-0-cust204.cdif.cable.ntl.com [81.103.67.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CD2D43D41 for ; Mon, 30 Aug 2004 21:36:40 +0000 (GMT) (envelope-from setantae@submonkey.net) Received: from setantae by shrike.submonkey.net with local (Exim 4.42 (FreeBSD)) id 1C1tpP-0003A5-PH; Mon, 30 Aug 2004 22:36:39 +0100 Date: Mon, 30 Aug 2004 22:36:39 +0100 From: Ceri Davies To: Ulrich Spoerlein Message-ID: <20040830213639.GJ36133@submonkey.net> Mail-Followup-To: Ceri Davies , Ulrich Spoerlein , current@FreeBSD.org References: <20040829213449.GA33843@hub.freebsd.org> <20040830135311.11040.qmail@web50603.mail.yahoo.com> <20040830163106.GA19044@dragon.nuxi.com> <20040830210817.GB749@galgenberg.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k3qmt+ucFURmlhDS" Content-Disposition: inline In-Reply-To: <20040830210817.GB749@galgenberg.net> X-PGP: finger ceri@FreeBSD.org User-Agent: Mutt/1.5.6i Sender: Ceri Davies cc: current@FreeBSD.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 21:36:41 -0000 --k3qmt+ucFURmlhDS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 30, 2004 at 11:08:17PM +0200, Ulrich Spoerlein wrote: > On Mon, 30.08.2004 at 09:31:06 -0700, David O'Brien wrote: > > > mergemasters is gross. Have you ever tried to run it on an 80-column= display? > > > I absolutely hate the "left" "right" stuff. You push the "l" with yo= ur right > > > hand and the "r" with your left for crying out loud. > >=20 > > LOL!! >=20 > This is not funny. I myself have to think loud about which button to > press. 'r' is on the left keyboard side and 'l' is to the right. Maybe you should hack yourself up a keymap to use while running mergemaster only. Ceri --=20 It is not tinfoil, it is my new skin. I am a robot. --k3qmt+ucFURmlhDS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBM53nocfcwTS3JF8RAowrAKCKLrb3RN8gDfhtwTPa2WbHzkmLLACfUQZz 0PcXAfZAKHS7Lhn+CrnKM0I= =AVtJ -----END PGP SIGNATURE----- --k3qmt+ucFURmlhDS-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 21:38:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 986A016A4CE for ; Mon, 30 Aug 2004 21:38:00 +0000 (GMT) Received: from mallaury.noc.nerim.net (smtp-101-monday.noc.nerim.net [62.4.17.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1258843D5F for ; Mon, 30 Aug 2004 21:38:00 +0000 (GMT) (envelope-from bettan@nerim.net) Received: from frederic (linux-win.com [62.212.121.38]) by mallaury.noc.nerim.net (Postfix) with ESMTP id F1A3662D6F for ; Mon, 30 Aug 2004 23:37:55 +0200 (CEST) Message-ID: <003801c48ed9$9e3c83f0$0401a8c0@frederic> From: "bettan" To: Date: Mon, 30 Aug 2004 23:37:58 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Antivirus: avast! (VPS 0435-2, 28/08/2004), Outbound message X-Antivirus-Status: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: bug with altq in freebsd-5.3-beta1 && 2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 21:38:00 -0000 Altq works goofd in my freebsd but when i reboot my kernel crash and he = says there is an error in altq_cbq.c.I must disabled pf before reboot = for resolv this problems.Anyone have the same problem ? From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 21:39:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17E5416A56E; Mon, 30 Aug 2004 21:39:46 +0000 (GMT) Received: from meitner.wh.uni-dortmund.de (meitner.wh.Uni-Dortmund.DE [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1AB6843D64; Mon, 30 Aug 2004 21:39:29 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id 2FF5E1675AE; Mon, 30 Aug 2004 23:39:28 +0200 (CEST) Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id i7ULdNZj023698 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 30 Aug 2004 23:39:24 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock To: freebsd-current@freebsd.org Date: Mon, 30 Aug 2004 23:39:17 +0200 User-Agent: KMail/1.7 References: <20040829213449.GA33843@hub.freebsd.org> <20040830163106.GA19044@dragon.nuxi.com> <20040830210817.GB749@galgenberg.net> In-Reply-To: <20040830210817.GB749@galgenberg.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2851343.p113QLvfa4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200408302339.21728.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new cc: Kenneth Stailey Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 21:39:46 -0000 --nextPart2851343.p113QLvfa4 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 30 August 2004 23:08, Ulrich Spoerlein wrote: > On Mon, 30.08.2004 at 09:31:06 -0700, David O'Brien wrote: > > > mergemasters is gross. Have you ever tried to run it on an 80-column > > > display? I absolutely hate the "left" "right" stuff. You push the "l" > > > with your right hand and the "r" with your left for crying out loud. > > > > LOL!! > > This is not funny. I myself have to think loud about which button to > press. 'r' is on the left keyboard side and 'l' is to the right. > > Not good. Sissy :). FWIW, it's probably good to do some thinking aloud while merging= =20 configs. =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart2851343.p113QLvfa4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBM56JXhc68WspdLARAnL1AKCYII0EvcMHRLoV2YnH+oNbruCyLgCdHCFA kzsSVZgjqKg75gZyJk9Wa84= =YwyD -----END PGP SIGNATURE----- --nextPart2851343.p113QLvfa4-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 21:58:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 462B116A4CE for ; Mon, 30 Aug 2004 21:58:57 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id E658043D1D for ; Mon, 30 Aug 2004 21:58:56 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.207] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1C1uAy-0006W8-00; Mon, 30 Aug 2004 23:58:56 +0200 Received: from [84.128.139.129] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1C1uAx-0005Nf-00; Mon, 30 Aug 2004 23:58:56 +0200 From: Max Laier To: freebsd-current@freebsd.org Date: Mon, 30 Aug 2004 23:57:20 +0200 User-Agent: KMail/1.6.2 References: <003801c48ed9$9e3c83f0$0401a8c0@frederic> In-Reply-To: <003801c48ed9$9e3c83f0$0401a8c0@frederic> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_IL6MB0AucziEb36"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408302357.28054.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 cc: bettan Subject: Re: bug with altq in freebsd-5.3-beta1 && 2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 21:58:57 -0000 --Boundary-02=_IL6MB0AucziEb36 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 30 August 2004 23:37, bettan wrote: > Altq works goofd in my freebsd but when i reboot my kernel crash and he > says there is an error in altq_cbq.c.I must disabled pf before reboot for > resolv this problems.Anyone have the same problem ? Could you be a bit mor specific about the "... says there is an error in=20 altq_cbq.c ..." part? From the information you are giving I can't even gues= s. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-02=_IL6MB0AucziEb36 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBM6LIXyyEoT62BG0RAuwyAJsE2APKTxRn3MXPJBIX48UYK8JrgQCfUkDO LBg1mqTwLm/+rotqxK88OmU= =Hwla -----END PGP SIGNATURE----- --Boundary-02=_IL6MB0AucziEb36-- From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 22:00:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1C1416A4CF for ; Mon, 30 Aug 2004 22:00:14 +0000 (GMT) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74B1043D45 for ; Mon, 30 Aug 2004 22:00:14 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Mon, 30 Aug 2004 15:00:14 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id A33055D09; Mon, 30 Aug 2004 15:00:13 -0700 (PDT) To: Ceri Davies In-reply-to: Your message of "Mon, 30 Aug 2004 22:36:39 BST." <20040830213639.GJ36133@submonkey.net> Date: Mon, 30 Aug 2004 15:00:13 -0700 From: "Kevin Oberman" Message-Id: <20040830220013.A33055D09@ptavv.es.net> cc: current@FreeBSD.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 22:00:14 -0000 > Date: Mon, 30 Aug 2004 22:36:39 +0100 > From: Ceri Davies > Sender: owner-freebsd-current@freebsd.org > > > --k3qmt+ucFURmlhDS > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Mon, Aug 30, 2004 at 11:08:17PM +0200, Ulrich Spoerlein wrote: > > On Mon, 30.08.2004 at 09:31:06 -0700, David O'Brien wrote: > > > > mergemasters is gross. Have you ever tried to run it on an 80-column > > > > display? I absolutely hate the "left" "right" stuff. You push the "l" > > > > with your right hand and the "r" with your left for crying out loud. > > > > > > LOL!! > > > > This is not funny. I myself have to think loud about which button to > > press. 'r' is on the left keyboard side and 'l' is to the right. > > Maybe you should hack yourself up a keymap to use while running > mergemaster only. Simpler to follow the old TV repair rule: Only use one hand. Much easier and much less prone to "unpleasant" errors. Just a bit slower. For those who type with only two fingers, it's barely a slowdown. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 22:10:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 710FD16A4CE for ; Mon, 30 Aug 2004 22:10:26 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EC3D43D1F for ; Mon, 30 Aug 2004 22:10:26 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so102396rnl for ; Mon, 30 Aug 2004 15:10:22 -0700 (PDT) Received: by 10.38.73.36 with SMTP id v36mr1196978rna; Mon, 30 Aug 2004 15:10:22 -0700 (PDT) Received: by 10.38.75.25 with HTTP; Mon, 30 Aug 2004 15:10:22 -0700 (PDT) Message-ID: <790a9fff04083015106294ba71@mail.gmail.com> Date: Mon, 30 Aug 2004 17:10:22 -0500 From: Scot Hetzel To: Will Saxon In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA2 boot hang, maybe acpi related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Scot Hetzel List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 22:10:26 -0000 On Mon, 30 Aug 2004 17:31:57 -0400, Will Saxon wrote: > I have a problem similar to the 'hang during CDROM detection' thread that is > also going on right now. When I try to boot from either a 5.3-BETA2 CD or a > 5.3-BETA2 installation on my hard drive, I experience a boot hang. > Your problem may be fixed in the 6.0-CURRENT ata driver. Try the following: cd /usr/src/sys/dev/ata cvs [-d ] update -PAd -r HEAD cd /usr/src make buildkernel make installkernel reboot the system and see if you still have the boot hang. The 6.0-CURRENT ata driver fixes my crash on boot problem (after a reboot). Scot From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 22:20:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9178416A4D0 for ; Mon, 30 Aug 2004 22:20:07 +0000 (GMT) Received: from smtp-vbr13.xs4all.nl (smtp-vbr13.xs4all.nl [194.109.24.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E70F43D41 for ; Mon, 30 Aug 2004 22:20:07 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) i7UMJwq9093291; Tue, 31 Aug 2004 00:20:00 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.11/8.12.9) with ESMTP id i7UMJvSD054274; Tue, 31 Aug 2004 00:19:57 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.12.11/8.12.11/Submit) id i7UMJuvw054273; Tue, 31 Aug 2004 00:19:56 +0200 (CEST) (envelope-from wb) Date: Tue, 31 Aug 2004 00:19:56 +0200 From: Wilko Bulte To: Kevin Oberman Message-ID: <20040830221956.GA54258@freebie.xs4all.nl> References: <20040830213639.GJ36133@submonkey.net> <20040830220013.A33055D09@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040830220013.A33055D09@ptavv.es.net> User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.10-STABLE X-PGP: finger wilko@freebsd.org X-Virus-Scanned: by XS4ALL Virus Scanner cc: Ceri Davies cc: current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 22:20:07 -0000 On Mon, Aug 30, 2004 at 03:00:13PM -0700, Kevin Oberman wrote.. > > Date: Mon, 30 Aug 2004 22:36:39 +0100 > > From: Ceri Davies > > Sender: owner-freebsd-current@freebsd.org > > > > > > --k3qmt+ucFURmlhDS > > Content-Type: text/plain; charset=us-ascii > > Content-Disposition: inline > > Content-Transfer-Encoding: quoted-printable > > > > On Mon, Aug 30, 2004 at 11:08:17PM +0200, Ulrich Spoerlein wrote: > > > On Mon, 30.08.2004 at 09:31:06 -0700, David O'Brien wrote: > > > > > > mergemasters is gross. Have you ever tried to run it on an 80-column > > > > > display? I absolutely hate the "left" "right" stuff. You push the "l" > > > > > with your right hand and the "r" with your left for crying out loud. > > > > > > > > > LOL!! > > > > > > This is not funny. I myself have to think loud about which button to > > > press. 'r' is on the left keyboard side and 'l' is to the right. > > > > Maybe you should hack yourself up a keymap to use while running > > mergemaster only. > > Simpler to follow the old TV repair rule: Only use one hand. Much easier > and much less prone to "unpleasant" errors. Just a bit slower. For those > who type with only two fingers, it's barely a slowdown. For TVs the added bonus is that you will live to see your grandchildren ;) -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 22:37:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E680016A4CE for ; Mon, 30 Aug 2004 22:37:23 +0000 (GMT) Received: from linda.pathlink.com (linda.pathlink.com [129.250.170.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACC8E43D4C for ; Mon, 30 Aug 2004 22:37:23 +0000 (GMT) (envelope-from kachun@pathlink.com) Received: from kachun.pathlink.com (dvl-1.pathlink.com [129.250.170.211]) by linda.pathlink.com (8.12.8p1/8.12.8) with ESMTP id i7UMbMoG056602; Mon, 30 Aug 2004 15:37:22 -0700 (PDT) (envelope-from kachun@pathlink.com) Message-Id: <5.0.2.1.2.20040830145556.00b8a500@dvl.pathlink.com> X-Sender: kachun@dvl.pathlink.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 30 Aug 2004 15:36:44 -0700 To: freebsd-current@freebsd.org From: Kachun Lee Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: 5.3-BETA1 panic with getnewbuf: locked buf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 22:37:24 -0000 "Doug White" wrote in message news:<20040829170534.V69068@carver.gumbysoft.com>... On Thu, 26 Aug 2004, Kachun Lee wrote: > >The server (E7501 single XEON 4G RAM) that I upgraded from 4.10 to > 5.3-BETA few days >ago panic'ed twice on 'getnewbuf: locked buf'. I > included the backtrace and dmesg below. I >searched the lists and found > several similar instances mentioned. Anything I can help to >find the > problem. Thanks in advance for any help. > > I forget to mention that I already rebuilt its kernel with 1.75 kern_lock.c > (from current). 1.75 should fix this problem. If it didn't, make sure you're booting the right kernel and run a full fsck. There is another attempt in rev 1.76 you might try too. Hi, Thanks for the info! Maybe, with the time line of events, you can see if I am on the right track... 1. 5.3-BETA1 cvsup'ed on Tue (kern_lock.c v1.74). Upgraded a server from 4.10 to 5.3-BETA1. Server panic'ed at end of dmesg. 2. Wed morning... got help from list to add ACPI. Server came up with 5.3-BETA1. 3. Wed ~6pm... kernel panic'ed with kmem_map too small. Increased VM_KMEM_SIZE_MAX from 512M (which ran fine with 4.10) to 768M. 3. Server panic'ed on Thur ~6pm with getnewbuf. I located the related messages on the list and bought in kern_lock.c v1.75 from current. Rebooted server without full fsck. 4. Server crashed at ~5am Fri... bought server back up and send this head message for help. 5. Later in the morning, found kern_lock.c v1.76 and built 5.3-BETA1 with it. Installed into server at around 2pm Fri, but did do full fsck this time before going into multi-user mode. 6. Server has run through the weekend. My remained concern in this issue was the server did panic'ed with kern_lock.c v1.75. According to your reply, that probably because I did not do a full fsck before bringing the system up. This is still a concern because, as far as I can tell, v1.74.2.1 in BETA2 is the same as v1.75. Another problem... I tried enable PAE this morning, but the server hanged right after the loader. I found in the archive that someone had similar problem few months back, but could not find the resolution... http://lists.freebsd.org/pipermail/freebsd-current/2003-October/011452.html I did not try removing ACPI, as the server would panic without it (see my earlier message). Any insight on this issue. Regards Kachun Lee PS: I just upgraded the server to 5.3-BETA2 without PAE. I will try PAE with 5.3-BETA2 tomorrow. From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 22:38:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A01016A4CE for ; Mon, 30 Aug 2004 22:38:21 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB80643D41 for ; Mon, 30 Aug 2004 22:38:20 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) i7UMcKbl093401 for ; Mon, 30 Aug 2004 15:38:20 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)i7UMcKsG093400 for freebsd-current@freebsd.org; Mon, 30 Aug 2004 15:38:20 -0700 (PDT) (envelope-from sgk) Date: Mon, 30 Aug 2004 15:38:20 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20040830223820.GA93366@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: TLS seems to hae broken profiling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 22:38:21 -0000 dhcp-78-96:sgk[264] cat > h.c #include int main(void) { printf("Hello world.\n"); return 0; } dhcp-78-96:sgk[265] gcc -o h -O2 h.c dhcp-78-96:sgk[266] ./h Hello world. dhcp-78-96:sgk[267] gcc -o h -O2 -pg h.c /usr/lib/gcrt1.o(.text+0x65): In function `_start': : undefined reference to `_init_tls' collect2: ld returned 1 exit status Is this a known issues or should I send-pr? -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 22:50:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F58816A4D0 for ; Mon, 30 Aug 2004 22:50:07 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id E664343D3F for ; Mon, 30 Aug 2004 22:50:06 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id C24DE7A3D2; Mon, 30 Aug 2004 15:50:06 -0700 (PDT) Message-ID: <4133AF1E.4090005@elischer.org> Date: Mon, 30 Aug 2004 15:50:06 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Steve Kargl References: <20040830223820.GA93366@troutmask.apl.washington.edu> In-Reply-To: <20040830223820.GA93366@troutmask.apl.washington.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: TLS seems to hae broken profiling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 22:50:07 -0000 Steve Kargl wrote: >dhcp-78-96:sgk[264] cat > h.c >#include >int main(void) { > printf("Hello world.\n"); > return 0; >} >dhcp-78-96:sgk[265] gcc -o h -O2 h.c >dhcp-78-96:sgk[266] ./h >Hello world. >dhcp-78-96:sgk[267] gcc -o h -O2 -pg h.c >/usr/lib/gcrt1.o(.text+0x65): In function `_start': >: undefined reference to `_init_tls' >collect2: ld returned 1 exit status > >Is this a known issues or should I send-pr? > do you need to compile a profiled libc? > > > From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 22:54:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 096F816A4CE for ; Mon, 30 Aug 2004 22:54:48 +0000 (GMT) Received: from TRANG.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id A385843D55 for ; Mon, 30 Aug 2004 22:54:47 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by TRANG.nuxi.com (8.13.1/8.12.11) with ESMTP id i7UMslLG028643; Mon, 30 Aug 2004 15:54:47 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id i7UMskVg028642; Mon, 30 Aug 2004 15:54:46 -0700 (PDT) (envelope-from obrien) Date: Mon, 30 Aug 2004 15:54:46 -0700 From: "David O'Brien" To: Steve Kargl Message-ID: <20040830225446.GA28521@dragon.nuxi.com> References: <20040804232854.GC9742@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040804232854.GC9742@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 cc: freebsd-current@freebsd.org Subject: Re: something strange with amd64 or fetch or ports or gcc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2004 22:54:48 -0000 On Wed, Aug 04, 2004 at 04:28:54PM -0700, Steve Kargl wrote: > While trying to build math/octave, make(1) stopped with > > lapack.tgz 99% of 4874 kB 2448 kBps > fetch: lapack.tgz appears to be truncated: 4991991/4991992 bytes > >> Couldn't fetch it - please try to retrieve this > >> port manually into /usr/ports/distfiles/lapack and try again. > *** Error code 1 ... > I haven't seen other reports of this behaviour. This could > be amd64 specific, caused by the new gcc, a 64-bit issue with > fetch (I doubt this it, but...), or some problem in the > ports system *.mk glue. What is your 'uname -a'? Does "strings -a /usr/bin/fetch | fgrep '$FreeBSD'" show: src/usr.bin/fetch/fetch.c,v rev 1.72 or later? -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 22:55:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72BAD16A4CE for ; Mon, 30 Aug 2004 22:55:46 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55B9443D58 for ; Mon, 30 Aug 2004 22:55:46 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) i7UMtin0093549; Mon, 30 Aug 2004 15:55:44 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)i7UMtiJ2093548; Mon, 30 Aug 2004 15:55:44 -0700 (PDT) (envelope-from sgk) Date: Mon, 30 Aug 2004 15:55:44 -0700 From: Steve Kargl To: Julian Elischer Message-ID: <20040830225544.GA93502@troutmask.apl.washington.edu> References: <20040830223820.GA93366@troutmask.apl.washington.edu> <4133AF1E.4090005@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4133AF1E.4090005@elischer.org> User-Agent: Mutt/1.4.1i cc: freebsd-current@freebsd.org Subject: Re: TLS seems to hae broken profiling X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 22:55:46 -0000 On Mon, Aug 30, 2004 at 03:50:06PM -0700, Julian Elischer wrote: > > > Steve Kargl wrote: > > >dhcp-78-96:sgk[264] cat > h.c > >#include > >int main(void) { > > printf("Hello world.\n"); > > return 0; > >} > >dhcp-78-96:sgk[265] gcc -o h -O2 h.c > >dhcp-78-96:sgk[266] ./h > >Hello world. > >dhcp-78-96:sgk[267] gcc -o h -O2 -pg h.c > >/usr/lib/gcrt1.o(.text+0x65): In function `_start': > >: undefined reference to `_init_tls' > >collect2: ld returned 1 exit status > > > >Is this a known issues or should I send-pr? > > > > do you need to compile a profiled libc? > Crude, you may be right. I disabled the building of profiled libraries a few weeks ago and forgot to update the *_p.a when TLS went into the system. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 23:07:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 044E316A4CE for ; Mon, 30 Aug 2004 23:07:23 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6C1B43D1D for ; Mon, 30 Aug 2004 23:07:22 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) i7UN7MW1093603 for ; Mon, 30 Aug 2004 16:07:22 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)i7UN7MBb093602 for freebsd-current@freebsd.org; Mon, 30 Aug 2004 16:07:22 -0700 (PDT) (envelope-from sgk) Date: Mon, 30 Aug 2004 16:07:22 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20040830230722.GB93502@troutmask.apl.washington.edu> References: <20040804232854.GC9742@troutmask.apl.washington.edu> <20040830225446.GA28521@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040830225446.GA28521@dragon.nuxi.com> User-Agent: Mutt/1.4.1i Subject: Re: something strange with amd64 or fetch or ports or gcc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 23:07:23 -0000 On Mon, Aug 30, 2004 at 03:54:46PM -0700, David O'Brien wrote: > On Wed, Aug 04, 2004 at 04:28:54PM -0700, Steve Kargl wrote: > > While trying to build math/octave, make(1) stopped with > > > > lapack.tgz 99% of 4874 kB 2448 kBps > > fetch: lapack.tgz appears to be truncated: 4991991/4991992 bytes > > >> Couldn't fetch it - please try to retrieve this > > >> port manually into /usr/ports/distfiles/lapack and try again. > > *** Error code 1 > ... > > I haven't seen other reports of this behaviour. This could > > be amd64 specific, caused by the new gcc, a 64-bit issue with > > fetch (I doubt this it, but...), or some problem in the > > ports system *.mk glue. > > What is your 'uname -a'? dhcp-78-96:kargl[220] uname -a FreeBSD dhcp-78-96.apl.washington.edu 6.0-CURRENT FreeBSD 6.0-CURRENT #16: Fri Aug 27 11:28:55 PDT 2004 kargl@dhcp-78-96.apl.washington.edu:/home/obj/usr/src/sys/SPEW amd64 > Does "strings -a /usr/bin/fetch | fgrep '$FreeBSD'" > show: src/usr.bin/fetch/fetch.c,v rev 1.72 or later? > Yes. $FreeBSD: src/usr.bin/fetch/fetch.c,v 1.73 2004/08/26 15:51:10 des Exp $ I built world on the 27 Aug. A quick check suggests that whatever the problem, it is now fixed. I haven't built any ports since 4 Aug when I reported the problem, so I did not realize that this was fixed. -- steve From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 23:25:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAFA916A4CF for ; Mon, 30 Aug 2004 23:25:14 +0000 (GMT) Received: from nolink.net (electra.nolink.net [195.139.204.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9464943D58 for ; Mon, 30 Aug 2004 23:25:13 +0000 (GMT) (envelope-from lerik@nolink.net) Received: (qmail 41321 invoked from network); 30 Aug 2004 23:25:12 -0000 Received: from unknown (HELO electra.nolink.net) (195.139.204.207) by electra.nolink.net with SMTP; 30 Aug 2004 23:25:12 -0000 Date: Tue, 31 Aug 2004 01:25:11 +0200 (CEST) From: Lars Erik Gullerud To: "freebsd-current@freebsd.org" In-Reply-To: <20040830210817.GB749@galgenberg.net> Message-ID: <20040831011815.C40736-100000@electra.nolink.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 23:25:14 -0000 On Mon, 30 Aug 2004, Ulrich Spoerlein wrote: > On Mon, 30.08.2004 at 09:31:06 -0700, David O'Brien wrote: > > > mergemasters is gross. Have you ever tried to run it on an 80-column display? > > > I absolutely hate the "left" "right" stuff. You push the "l" with your right > > > hand and the "r" with your left for crying out loud. > > > > LOL!! > > This is not funny. I myself have to think loud about which button to > press. 'r' is on the left keyboard side and 'l' is to the right. I second the "don't laugh" - you have no idea how many times I have to select "redo the merge" when upgrading servers usually during a late-night maintenance window, with a brain only functioning due to large amounts of caffeine in the bloodstream... (Not that I have any suggestions for other keys to use, mind you - but the mind's wiring does have a problem with getting used to pressing a key with the left hand to select the right side of the screen and vice versa...) /leg From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 23:52:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25FB016A4CE for ; Mon, 30 Aug 2004 23:52:55 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id B88D843D3F for ; Mon, 30 Aug 2004 23:52:54 +0000 (GMT) (envelope-from max@love2party.net) Received: from [212.227.126.205] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1C1vxF-0005jq-00; Tue, 31 Aug 2004 01:52:53 +0200 Received: from [84.128.139.129] (helo=donor.laier.local) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1C1vxE-0006Wq-00; Tue, 31 Aug 2004 01:52:53 +0200 From: Max Laier To: freebsd-current@freebsd.org Date: Tue, 31 Aug 2004 01:51:07 +0200 User-Agent: KMail/1.6.2 References: <20040831011815.C40736-100000@electra.nolink.net> In-Reply-To: <20040831011815.C40736-100000@electra.nolink.net> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_417MBCs91LhZ2aI"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408310151.20363.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:61c499deaeeba3ba5be80f48ecc83056 Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 23:52:55 -0000 --Boundary-02=_417MBCs91LhZ2aI Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 31 August 2004 01:25, Lars Erik Gullerud wrote: > On Mon, 30 Aug 2004, Ulrich Spoerlein wrote: > > On Mon, 30.08.2004 at 09:31:06 -0700, David O'Brien wrote: > > > > mergemasters is gross. Have you ever tried to run it on an 80-colu= mn > > > > display? I absolutely hate the "left" "right" stuff. You push the > > > > "l" with your right hand and the "r" with your left for crying out > > > > loud. > > > > > > LOL!! > > > > This is not funny. I myself have to think loud about which button to > > press. 'r' is on the left keyboard side and 'l' is to the right. > > I second the "don't laugh" - you have no idea how many times I have to > select "redo the merge" when upgrading servers usually during a > late-night maintenance window, with a brain only functioning due to > large amounts of caffeine in the bloodstream... > > (Not that I have any suggestions for other keys to use, mind you - but > the mind's wiring does have a problem with getting used to pressing a > key with the left hand to select the right side of the screen and > vice versa...) I suggest (lowercase H)"h"(=3Dleft) and (lowercase L)"l"(=3Dright) ... that= 'd make=20 it a lot more familiar to all the *hack*ers out there ... *lol* (couldn't resist) =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-02=_417MBCs91LhZ2aI Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBM714XyyEoT62BG0RAjniAJoDzx1TSMuK38vvVDlQU9d5akmCvwCfcsUI 0pxFhhm3i5dVQuOOQg67fV8= =RnwC -----END PGP SIGNATURE----- --Boundary-02=_417MBCs91LhZ2aI-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 00:16:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66F1716A4CE for ; Tue, 31 Aug 2004 00:16:24 +0000 (GMT) Received: from omoikane.mb.skyweb.ca (64-42-246-34.mb.skyweb.ca [64.42.246.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id C939643D1F for ; Tue, 31 Aug 2004 00:16:22 +0000 (GMT) (envelope-from mark@skyweb.ca) Received: by omoikane.mb.skyweb.ca (Postfix, from userid 1001) id 8282561E4B; Mon, 30 Aug 2004 19:16:22 -0500 (CDT) From: Mark Johnston To: current@freebsd.org, freebsd-cvs-summary@lists.enderunix.org Date: Mon, 30 Aug 2004 19:16:22 -0500 User-Agent: KMail/1.6.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200408301916.22240.mjohnston@skyweb.ca> Subject: cvs-src summary for August 23-30 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 00:16:24 -0000 Here's this week's summary. As a side note, I discovered Synergy (http://synergy2.sf.net) today, and it made the summary-writing much more pleasant, letting me flip my mouse cursor between the desktop I write the summary on and the laptop I read the mail on, copying and pasting transparently. I highly recommend it if you run any kind of multi-PC-on-one-desktop configuration. FreeBSD cvs-src summary for 23/08/04 to 30/08/04 ++++++++++++++++++++++++++++++++++++++++++++++++ This is a regular weekly summary of FreeBSD's cutting-edge development. It is intended to help the FreeBSD community keep up with the fast-paced work going on in FreeBSD-CURRENT by distilling the deluge of data from the CVS mailing list into a (hopefully) easy-to-read newsletter. This newsletter is marked up in reStructuredText_, so any odd punctuation that you see is likely intended for the reST parser. .. _reStructuredText: http://docutils.sourceforge.net/rst.html You can get old summaries, and an HTML version of this one, at http://www.xl0.org/FreeBSD/. Please send any comments to Mark Johnston (mark at xl0.org). If you would like to get the summary without subscribing to current@, please send mail to freebsd-cvs-summary-subscribe@lists.enderunix.org. Thanks to Omer Faruk Sen and EnderUNIX for hosting this list. For Lukasz Dudek and Szymon Roczniak's Polish translations of these summaries, which may lag the English ones slightly, please see http://mocart.pinco.pl/FreeBSD/. .. contents:: ============ New features ============ Networking now runs without Giant by default -------------------------------------------- Robert Watson (rwatson) changed the default value of the sysctl debug.mpsafenet to 1, meaning that the network stack will run without the Giant system lock. This means that networking will be more parallelizable and will be faster on SMP systems. To counteract this change, you can set debug.mpsafenet to 0 in loader.conf, or add a kernel option, "NET_WITH_GIANT", that restores the default to 0. The networking subsystem has been the focus of a huge amount of effort to reach this point, and there is still some work left to do in locking individual drivers (which have been marked specifically as needing Giant). Nevertheless, this change represents a big step towards SMPng. Congratulations and thanks to Robert and all involved in the locking work! http://www.freebsd.org/cgi/mid.cgi?200408281511.i7SFBDYa009794 PFIL_HOOKS integrated into the kernel ------------------------------------- Andre Oppermann (andre) changed PFIL_HOOKS, the API for packet filters to hook the functions they use, to be a permanent part of the kernel. The PFIL_HOOKS kernel compile option has been removed. He also made a tweak that eliminates the performance impact that PFIL_HOOKS used to have when no packet filters were loaded. http://www.freebsd.org/cgi/mid.cgi?200408271516.i7RFGO8L061926 Module loader now supported on amd64 ------------------------------------ Ian Dowse (iedowse) committed support for loading modules via the module loader on amd64. http://www.freebsd.org/cgi/mid.cgi?200408290121.i7T1Lppf030605 Mouse sync recovery improved for Belkin KVM switches ---------------------------------------------------- Justin T. Gibbs (gibbs) improved the sync recovery in the mouse code, cutting down on spurious mouse moves and clicks with Belkin KVM switches. Large portions of the code he committed were written by Brian Somers. http://www.freebsd.org/cgi/mid.cgi?200408272125.i7RLPG3K076074 =============== Notable changes =============== 5.3-BETA2 begins ---------------- Scott Long (scottl) updated the system version to 5.3-BETA2, marking another step on the way to 5.3-RELEASE. http://www.freebsd.org/cgi/mid.cgi?200408270532.i7R5W3BC044152 Count device support removed from config ---------------------------------------- Peter Wemm (peter) removed support from config, the kernel configuration processing tool, for counted devices. Counted devices are device lines that incorporate a count of how many devices to support. Peter changed over the last few devices using this option to have the count passed as an option. This means that quotes are no longer required around options with numbers in them, like snd_emu10k1. http://www.freebsd.org/cgi/mid.cgi?200408302303.i7UN3wnR032136 X configuration removed from sysinstall --------------------------------------- Ken Smith (kensmith) removed support from sysinstall for configuring the X server. This was discussed on -current, and the consensus was that X configuration is best left for post-install. http://www.freebsd.org/cgi/mid.cgi?200408302103.i7UL397X027511 ================= Discussion topics ================= Use of KASSERT() vs. other error checking ----------------------------------------- Pawel Jakub Dawidek (pjd) made a change to GEOM to skip providers with an undefined sector size. Poul-Henning Kamp (phk) responded to this change, saying, "This is wrong. A provider with a non-zero access count should always have a sector size." Pawel answered, "I know that it should be done this way, but I'm not going to fix atapi-cd.c, scsi_da.c and scsi_cd.c and who knows what else." Roman Kurakin (rik) asked, "Does your code print any warning message in that case? That could force authors of 'buggy' code to fix it." Pawel answered, "No, this should be KASSERT() inside g_error_provider()". Brian Fundakowski Feldman (green) replied, "I don't like that one bit." He gave the following suggestions for error types (reformatted): "KASSERT() should be reserved for serious programming errors -- guarding against side cases that show major error. panic() should be reserved for cases where error recovery is impossible and errors are detected under the normal course of error checking. printf() should be used when there are simple mistakes that do not cause system instability if you recover from them." Poul-Henning answered, "In GEOM I have generously sprinkled KASSERTs for the very purpose of stopping programmer misunderstandings or attempts to be smart. The intent is that the programmer will find his bugs even during light testing and that the KASSERTs will help clarify the intentional use of APIs." Brian asked, "Why in the world would you crash the machine when you don't have to?", continuing, "I use KASSERT()s quite liberally, too, you know, but running into crashes in half-finished kernel code that's in the tree -- as a user -- is far inferior to running into errors and warnings that do not halt the whole system." Poul-Henning answered his question, "To prevent bogus code from being committed in the first place." Brian replied, "You cannot presume testing will expose every possible state/condition." M. Warner Losh (imp) responded, "I beg to differ. newbus has lots of asserts in it that could be recovered from, but instead are panics. These panics have been very helpful in shaking out bugs [ . . . ]." Poul-Henning also replied to Brian's post, saying, "If you hit any of the KASSERTS in geom, your code is very broken and if your testing doesn't uncover that (with the help of the KASSERTS) then you have no business being a committer." http://www.freebsd.org/cgi/mid.cgi?200408261242.i7QCgl7m012027 Hot-plugging PS/2 keyboards --------------------------- As mentioned in `Mouse sync recovery improved for Belkin KVM switches`_, Justin Gibbs (gibbs) improved the mouse code. On a console-related note, Andre Oppermann (andre) asked, "Do have an idea how to get a PS2 keyboard recognized if none was connected when the machine booted?" M. Warner Losh (imp) replied with some text from the sc man page, showing that hint.sc.0.flags="0x100" will instruct the driver to periodically scan for a keyboard device. He also noted that bit 0 must not be set in the atkbd driver flags (hint.atkbd.0.flags). Daniel O'Connor noted, "This prevents USB keyboards from working (I think) because the system will only talk to it's (possibly not connected) PS/2 keyboard even when you plug a USB one in.." Warner replied, "It doesn't prevent usb keyboards from working, you can always use the kbdcontrol to set the usb keyboard as the primary one." Brian Fundakowski Feldman (green) also suggested, "See the keyboard directive I recently added to rc.conf(5)." The entry in question reads:: keyboard (str) If set to a non-null string, the virtual console's key- board input is set to this device. http://www.freebsd.org/cgi/mid.cgi?200408272125.i7RLPG3K076074 =================== Important bug fixes =================== Denial-of-service vulnerability in zlib fixed --------------------------------------------- Jacques Vidrine (nectar) fixed a denial-of-service vulnerability in zlib, the compression library. This was submitted by Dmitry V. Levin, and originally found by Johan Thelmen as reported in `Debian bug 252253`_. .. _`Debian bug 252253`: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=252253 http://www.freebsd.org/cgi/mid.cgi?200408261937.i7QJb6VC026752 =============== Other bug fixes =============== John Baldwin (jhb) committed a patch from Georg-W. Koltermann fixing a bug that was preventing the IBM Linux JDK from running. This closes `PR 68079`_. .. _`PR 68079`: http://www.freebsd.org/cgi/query-pr.cgi?pr=68079 http://www.freebsd.org/cgi/mid.cgi?200408242052.i7OKqrcc035220 From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 00:42:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0166316A4CE for ; Tue, 31 Aug 2004 00:42:19 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79ABC43D1F for ; Tue, 31 Aug 2004 00:42:18 +0000 (GMT) (envelope-from jon.drews@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so112889rnl for ; Mon, 30 Aug 2004 17:42:17 -0700 (PDT) Received: by 10.38.73.36 with SMTP id v36mr1266851rna; Mon, 30 Aug 2004 17:42:17 -0700 (PDT) Received: by 10.38.89.49 with HTTP; Mon, 30 Aug 2004 17:42:17 -0700 (PDT) Message-ID: <8cb27cbf0408301742153796cc@mail.gmail.com> Date: Mon, 30 Aug 2004 18:42:17 -0600 From: Jon Drews To: freebsd-current@freebsd.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jon Drews List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 00:42:19 -0000 OK: I put this in device.hints and my mouse works in X but not at the xterm. FreeBSD 5.3 B2 no longer locks up when configuring the mouse with sysinstall. hint.psm.0.flags="0x200" On Sat, 28 Aug 2004 15:39:06 -0400 (EDT), Robert Watson wrote: > I'm using this entry in /boot/device.hints: > > hint.psm.0.flags="0x200" > > Which appears to tell the psm driver to ignore all that and be boring with > respect to synaptics features (i.e., work). > From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 01:12:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC76116A4CE for ; Tue, 31 Aug 2004 01:12:31 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4362043D1D for ; Tue, 31 Aug 2004 01:12:31 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) i7V1CT3R018036; Mon, 30 Aug 2004 21:12:30 -0400 (EDT) Date: Mon, 30 Aug 2004 21:12:29 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Jon Drews In-Reply-To: <8cb27cbf0408301742153796cc@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: freebsd-current@freebsd.org Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 01:12:31 -0000 On Mon, 30 Aug 2004, Jon Drews wrote: > OK: > > I put this in device.hints and my mouse works in X but not at the > xterm. FreeBSD 5.3 B2 no longer locks up when configuring the mouse > with sysinstall. > > hint.psm.0.flags="0x200" > > > On Sat, 28 Aug 2004 15:39:06 -0400 (EDT), Robert Watson > wrote: > > I'm using this entry in /boot/device.hints: > > > > hint.psm.0.flags="0x200" > > > > Which appears to tell the psm driver to ignore all that and be boring with > > respect to synaptics features (i.e., work). Can we get the synaptics support disabled by default for the release please? It seems to affect every laptop I have access to (2 Dells and an IBM). -- Dan Eischen From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 01:35:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC4F616A4CE for ; Tue, 31 Aug 2004 01:35:04 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8530643D3F for ; Tue, 31 Aug 2004 01:35:03 +0000 (GMT) (envelope-from wilkinsa@squirm.dsto.defence.gov.au) Received: from ednmsw503.dsto.defence.gov.au (ednmsw503.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id i7V1YG5D011196 for ; Tue, 31 Aug 2004 11:04:16 +0930 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw503.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Tue, 31 Aug 2004 11:04:54 +0930 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id i7V1R0503182 for ; Tue, 31 Aug 2004 10:57:00 +0930 (CST) Received: from squirm.dsto.defence.gov.au ([131.185.40.211]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id RZ20GMZX; Tue, 31 Aug 2004 10:56:49 +0930 Received: from squirm.dsto.defence.gov.au (localhost [127.0.0.1]) by squirm.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id i7V1RQAk023000 for ; Tue, 31 Aug 2004 10:57:26 +0930 (CST) (envelope-from wilkinsa@squirm.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squirm.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id i7V1RQhm022999 for current@freebsd.org; Tue, 31 Aug 2004 10:57:26 +0930 (CST) (envelope-from wilkinsa) Date: Tue, 31 Aug 2004 10:57:26 +0930 From: "Wilkinson, Alex" To: current@freebsd.org Message-ID: <20040831012726.GA22918@squirm.dsto.defence.gov.au> Mail-Followup-To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline X-Message-Flag: "Beware of Outlook! It Bites You Eventually" User-Agent: Mutt/1.5.6i Subject: shutdown -r from console panic [5.3-BETA] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 01:35:05 -0000 This is over a serial console via tip(1). # shutdown -r now Shutdown NOW! shutdown: [pid 927] *** FINAL System shutdown message from root@ *** System going down IMMEDIATELY Aug 30 18:12:49 shutdown: reboot by root: # # System shutdown time has arrived Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xdeadc136 fault code = supervisor read, page not present instruction pointer = 0x8:0xc076670e stack pointer = 0x10:0xde47c7b0 frame pointer = 0x10:0xde47c7bc code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 253 (syslogd) [thread 100085] Stopped at commodem+0x12: movl 0x58(%eax),%ebx db> tr commodem(c1ae2800,0,1,c1a37800,6) at commodem+0x12 comhardclose(c1a37800) at comhardclose+0x6c sioopen(c08b21a4,6,2000,c1c34b00,0) at sioopen+0x392 spec_open(de47c86c,de47c928,c0658d75,de47c86c,80) at spec_open+0x2c4 spec_vnoperate(de47c86c) at spec_vnoperate+0x13 vn_open_cred(de47c96c,c08e3b38,0,c193e480,ffffffff) at vn_open_cred+0x431 vn_open(de47c96c,c08e3b38,0,ffffffff) at vn_open+0x1e cn_devopen(c08e3b00,c1c34b00,0) at cn_devopen+0xac cnopen(c08b0278,6,2000,c1c34b00,0) at cnopen+0x41 spec_open(de47ca74,de47cb30,c0658d75,de47ca74,80) at spec_open+0x2c4 spec_vnoperate(de47ca74) at spec_vnoperate+0x13 vn_open_cred(de47cbe4,de47cce4,0,c193e480,7) at vn_open_cred+0x431 vn_open(de47cbe4,de47cce4,0,7,c08b3400) at vn_open+0x1e kern_open(c1c34b00,804f220,0,6,0) at kern_open+0xd2 open(c1c34b00,de47cd14,3,7,246) at open+0x18 syscall(2f,2f,2f,7,bfbfd300) at syscall+0x217 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (5, FreeBSD ELF32, open), eip = 0x280d2c7b, esp = 0xbfbfcb8c, ebp = 0xbfbfcc08 --- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 01:54:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A90416A4CE for ; Tue, 31 Aug 2004 01:54:03 +0000 (GMT) Received: from mx.us.army.mil (mxoutdr1.us.army.mil [143.69.242.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4004C43D31 for ; Tue, 31 Aug 2004 01:54:03 +0000 (GMT) (envelope-from jonathan.michael.stewart@us.army.mil) Received: from mta05.int.dr1.us.army.mil (localhost [127.0.0.1]) by mailrouter.us.army.mil (AKO MTA - mta05 ) with ESMTP id <0I3A0047YFWPNY@mta05.int.dr1.us.army.mil> for current@freebsd.org; Tue, 31 Aug 2004 01:53:13 +0000 (GMT) Received: from [10.70.2.3] ([204.117.152.20]) by mailrouter.us.army.mil (AKO MTA - mta05 ) with ESMTPA id <0I3A00BHYFWJ9T@mta05.int.dr1.us.army.mil> for current@freebsd.org; Tue, 31 Aug 2004 01:53:13 +0000 (GMT) Date: Mon, 30 Aug 2004 21:53:08 -0400 From: Jonathan In-reply-to: <200408301916.22240.mjohnston@skyweb.ca> To: current@freebsd.org Message-id: <4133DA04.4030103@us.army.mil> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) References: <200408301916.22240.mjohnston@skyweb.ca> Subject: Re: cvs-src summary for August 23-30 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 01:54:03 -0000 Mark Johnston wrote: > Here's this week's summary. As a side note, I discovered Synergy > (http://synergy2.sf.net) today, and it made the summary-writing much more > pleasant, letting me flip my mouse cursor between the desktop I write the > summary on and the laptop I read the mail on, copying and pasting > transparently. I highly recommend it if you run any kind of > multi-PC-on-one-desktop configuration. > This is one of the coolest and most handy things I have ever seen! I can't say how well it works on the X side as my server is headless but on my XP desktop and laptop it ROCKS :D Sorry for the extra noise but if you have not looked at this and even occasionally use two computers at once it's well worth checking out!) Excited with new program, Jonathan From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 02:14:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8E9C16A4CE for ; Tue, 31 Aug 2004 02:14:56 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id DD95843D41 for ; Tue, 31 Aug 2004 02:14:55 +0000 (GMT) (envelope-from lists@MHoerich.de) Received: (qmail 15523 invoked by uid 0); 31 Aug 2004 02:14:54 -0000 Received: from 80.138.86.250 by www8.gmx.net with HTTP; Tue, 31 Aug 2004 04:14:54 +0200 (MEST) Date: Tue, 31 Aug 2004 04:14:54 +0200 (MEST) From: "Mario Hoerich" To: "Bjoern A. Zeeb" MIME-Version: 1.0 References: X-Priority: 3 (Normal) X-Authenticated: #5114400 Message-ID: <32047.1093918494@www8.gmx.net> X-Mailer: WWW-Mail 1.6 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit cc: current@FreeBSD.org Subject: Re: [FIXED] Re: [5.3-B2] PPPoE broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 02:14:57 -0000 # Bjoern A. Zeeb: [ http://docs.FreeBSD.org/cgi/mid.cgi?200408271833.i7RIX8fw068973 ] > > > > Manually applying the diffs and rebuilding world+kernel seems > > to have fixed it. Great. Thanks for the really fast help. :) > > this doesn't make much sense at all. > > Are you sure you had a complete and clean new RELENG_5 > world and kernel before ? Hm. I think so. I can't claim to actually understand what the above commit does, but I didn't expect it to affect my system either. Rebuilding solved the problem however, so I just blamed it on the diffs. ;) Giving it some second thought, I recently read about -j4 being considered safe for buildworlds. The failing world _was_ built with that flag, but I'm quite sure I didn't specify it after merging the diffs into my local source tree. I just didn't suspect this to result in runtime errors, but I can't recall anything else I might have varied. Does that sound like a more probable cause to you? Cheers, Mario From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 02:29:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52CF016A4CF for ; Tue, 31 Aug 2004 02:29:17 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25A1443D5E for ; Tue, 31 Aug 2004 02:29:17 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id A65FCFD099; Mon, 30 Aug 2004 19:29:16 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00379-05; Mon, 30 Aug 2004 19:29:15 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id C866DFD00B; Mon, 30 Aug 2004 19:29:15 -0700 (PDT) From: Sean McNeil To: Oliver Brandmueller Content-Type: text/plain Message-Id: <1093919355.39775.2.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 30 Aug 2004 19:29:15 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: current@freebsd.org Subject: Re: RELENG_5 ipfw problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 02:29:17 -0000 Just curious... How are you compiling ipfw2? I have it built into my kernel and have no issues at all. Are you using it as a loadable module or part of the kernel? Sean From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 02:34:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A63316A4CE for ; Tue, 31 Aug 2004 02:34:10 +0000 (GMT) Received: from pandora.afflictions.org (asylum.afflictions.org [64.7.134.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id E821443D2D for ; Tue, 31 Aug 2004 02:34:09 +0000 (GMT) (envelope-from dgerow@afflictions.org) Received: from localhost (localhost [127.0.0.1]) by pandora.afflictions.org (Postfix) with ESMTP id 85EB278C8D; Mon, 30 Aug 2004 22:39:26 -0400 (EDT) Received: from dementia.afflictions.org (dementia.afflictions.org [172.19.206.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pandora.afflictions.org (Postfix) with ESMTP id A2EDA78C8C; Mon, 30 Aug 2004 22:39:24 -0400 (EDT) Received: by dementia.afflictions.org (Postfix, from userid 1001) id B3867170C9; Mon, 30 Aug 2004 22:34:01 -0400 (EDT) Date: Mon, 30 Aug 2004 22:34:01 -0400 From: Damian Gerow To: Doug White Message-ID: <20040831023401.GB22579@afflictions.org> Mail-Followup-To: Doug White , current@freebsd.org References: <20040824073356.GK25125@afflictions.org> <20040829155924.J69068@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040829155924.J69068@carver.gumbysoft.com> X-Operating-System: FreeBSD 5.3-BETA2 on a i386 X-GPG-Fingerprint: B3D7 D901 A53A 1A99 BFD6 E6DF 9F3B 742B C288 9CC9 User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at afflictions.org cc: current@freebsd.org Subject: Re: RELENG_5 build broken with BKTR_USE_FREEBSD_SMBUS and BKTR_NEW_MSP34XX_DRIVER enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 02:34:10 -0000 Thus spake Doug White (dwhite@gumbysoft.com) [29/08/04 19:09]: : Please try the patch at: : : http://people.freebsd.org/~dwhite/msp34xx.c.patch : : Seems to test out OK on my ancient Hauppauge WinTV card. These options : must not be a frequently used combination since its been months since this : stuff was touched last. There was a PR that fixed a compile bug in one : file related to the smbus option but must not have been tested with the : msp stuff too. The patch not only lets me compile, but I'm now running with BKTR_USE_FREEBSD_SMBUS and BKTR_NEW_MSP34XX_DRIVER, successfully. Thanks! From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 02:36:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6001016A4CE for ; Tue, 31 Aug 2004 02:36:54 +0000 (GMT) Received: from huva.hittite.isp.9tel.net (huva.hittite.isp.9tel.net [62.62.156.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id D9B2343D45 for ; Tue, 31 Aug 2004 02:36:53 +0000 (GMT) (envelope-from clefevr-current@9online.fr) Received: from pc2k (78-240-118-80.kaptech.net [80.118.240.78]) by huva.hittite.isp.9tel.net (Postfix) with SMTP id 2B00414B5B9; Tue, 31 Aug 2004 04:50:47 +0200 (CEST) Message-ID: <0b2001c48f03$5f69f570$7890a8c0@gits.invalid> From: "Cyrille Lefevre" To: "Bryan Liesner" , References: <200408291848.i7TImAq8072080@mail.gits.dyndns.org> <098401c48e76$6772d300$7890a8c0@gits.invalid> <413333FB.5020905@kishka.net> Date: Tue, 31 Aug 2004 04:36:51 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Cyrille Lefevre List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 02:36:54 -0000 "Bryan Liesner" wrote: > Cyrille Lefevre wrote: > > PR#71142 (http://www.freebsd.org/cgi/query-pr.cgi?pr=71142) > > has just been submitted w/ the "static void" fix. > > > > PS : the vidcontrol "showing the mouse: Invalid argument" > > error message has not been fixed, yet. > > It works great! One exception - I'm using green_saver and it doesn't > blank the screen anymore. The text stays where it is on the screen and > the cursor disappears. When I hit a key, the console responds by > blanking for a second, then back to normal operation. don't know how to handle this ! > The patch as listed in the PR is mangled - some spaces are rendered as > =20, equal signs rendered as =3D, and escape chars as =1B. > > I did manage to fix the patch and get it to apply cleanly. I've followed-up to the PR a small awk program which may help to get rid of those =XX. Cyrille Lefevre. -- home: mailto:cyrille.lefevre@laposte.net From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 02:43:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5740616A4CE; Tue, 31 Aug 2004 02:43:44 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0774D43D48; Tue, 31 Aug 2004 02:43:44 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i7V2fCIK036736; Mon, 30 Aug 2004 22:41:12 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i7V2fCCV036733; Mon, 30 Aug 2004 22:41:12 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Mon, 30 Aug 2004 22:41:12 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Norikatsu Shigemura In-Reply-To: <200408301502.i7UF2L7f030909@sakura.ninth-nine.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@FreeBSD.org Subject: Re: ping6 -f panic with mpsafenet=1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 02:43:44 -0000 On Tue, 31 Aug 2004, Norikatsu Shigemura wrote: > On Mon, 30 Aug 2004 21:45:35 +0900 (JST) > Norikatsu Shigemura wrote: > > I contacted a panic on current with debug.mpsafenet=1. > > - - - - - - - - - - > > # ping6 -f othermachine > (snip) > > INET6 with FAST_IPSEC will contact panic. But INET6 with > KAME_IPSEC is safe, because forced disable mpsafenet on boot. Do you get a panic with INET6 and FAST_IPSEC yet with mpsafenet disabled? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research > > I tried to use INET6 without FAST_IPSEC/KAME_IPSEC. I didn't > contact panic... Maybe safe... Probabry... :-). > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 02:48:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B7D516A4CE for ; Tue, 31 Aug 2004 02:48:57 +0000 (GMT) Received: from hotmail.com (bay11-dav23.bay11.hotmail.com [64.4.39.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A09443D39 for ; Tue, 31 Aug 2004 02:48:57 +0000 (GMT) (envelope-from dsnofe@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 30 Aug 2004 19:48:57 -0700 Received: from 218.80.194.83 by bay11-dav23.bay11.hotmail.com with DAV; Tue, 31 Aug 2004 02:48:57 +0000 X-Originating-IP: [218.80.194.83] X-Originating-Email: [dsnofe@msn.com] X-Sender: dsnofe@msn.com From: "Deng XueFeng" To: "Cyrille Lefevre" References: <200408291848.i7TImAq8072080@mail.gits.dyndns.org><098401c48e76$6772d300$7890a8c0@gits.invalid> <0b4a01c48f04$99f64030$7890a8c0@gits.invalid> Date: Tue, 31 Aug 2004 10:48:54 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 31 Aug 2004 02:48:57.0456 (UTC) FILETIME=[0FB84700:01C48F05] cc: current@freebsd.org Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 02:48:57 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkN5cmlsbGUgTGVmZXZyZSIg PGN5cmlsbGUubGVmZXZyZUA5b25saW5lLmZyPg0KVG86ICJEZW5nIFh1ZUZlbmciIDxkc25vZmVA bXNuLmNvbT4NClNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAzMSwgMjAwNCAxMDo0NSBBTQ0KU3ViamVj dDogUmU6IFtQQVRDSCBUTyBURVNUXSBWRVNBIFsxMDI0eDc2OF0gbW9kZSBzdXBwb3J0IGZvciBG cmVlQlNELUNVUlJFTlQNCg0KDQo+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQo+IEZy b206ICJEZW5nIFh1ZUZlbmciIDxkc25vZmVAbXNuLmNvbT4NCj4gVG86ICJDeXJpbGxlIExlZmV2 cmUiIDxjbGVmZXZyZS1saXN0c0A5b25saW5lLmZyPjsgPGN1cnJlbnRAZnJlZWJzZC5vcmc+DQo+ IFNlbnQ6IE1vbmRheSwgQXVndXN0IDMwLCAyMDA0IDEyOjM5IFBNDQo+IFN1YmplY3Q6IFJlOiBb UEFUQ0ggVE8gVEVTVF0gVkVTQSBbMTAyNHg3NjhdIG1vZGUgc3VwcG9ydCBmb3IgRnJlZUJTRC1D VVJSRU5UDQo+IA0KPiANCj4+IHRoZSBwYXRjaCBzdGlsbCBuZWVkIHNvbWUgbW9yZSB3b3Jrcy4N Cj4gDQo+IA0KPiBhcmUgeW91IHRhbGtpbmcgYWJvdXQgdGhvc2UgcXVvdGVkLXByaW50YWJsZSBN SU1FICg9WFgpIHN0dWZmcyA/DQpuby4gaSBtZWFucy4gdGhpcyB2ZXNhIHBhdGNoIGlzIGp1c3Qg YSBiZXRhIHZlcnNpb24uIGFuZCBuZWVkIHNvbWUgbW9yZSB3b3JrIHRvIGRvLg0KOi0pDQo+IA0K PiBDeXJpbGxlIExlZmV2cmUuDQo+IC0tIA0KPiBob21lOiBtYWlsdG86Y3lyaWxsZS5sZWZldnJl QGxhcG9zdGUubmV0DQo+ From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 03:10:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1337A16A4CE; Tue, 31 Aug 2004 03:10:06 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A134943D39; Tue, 31 Aug 2004 03:10:05 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smtp3.sentex.ca (8.13.1/8.13.1) with ESMTP id i7V3A4th085335; Mon, 30 Aug 2004 23:10:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7V3A5FF012164; Mon, 30 Aug 2004 23:10:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D41017303F; Mon, 30 Aug 2004 23:10:04 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040831031004.D41017303F@freebsd-current.sentex.ca> Date: Mon, 30 Aug 2004 23:10:04 -0400 (EDT) Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 03:10:06 -0000 TB --- 2004-08-31 01:51:33 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-31 01:51:33 - starting CURRENT tinderbox run for i386/i386 TB --- 2004-08-31 01:51:33 - checking out the source tree TB --- 2004-08-31 01:51:33 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2004-08-31 01:51:33 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-31 01:56:41 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-31 01:56:41 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2004-08-31 01:56:41 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-31 03:00:25 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-31 03:00:25 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2004-08-31 03:00:25 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Aug 31 03:00:26 UTC 2004 >>> 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 [...] ===> coda cc -O2 -pipe -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -g -I/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /tinderbox/CURRENT/i386/i386/src/sys/modules/coda/../../coda/coda_fbsd.c /tinderbox/CURRENT/i386/i386/src/sys/modules/coda/../../coda/coda_fbsd.c: In function `coda_fbsd_drvinit': /tinderbox/CURRENT/i386/i386/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: `NVCODA' undeclared (first use in this function) /tinderbox/CURRENT/i386/i386/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/i386/i386/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: for each function it appears in.) /tinderbox/CURRENT/i386/i386/src/sys/modules/coda/../../coda/coda_fbsd.c: In function `coda_fbsd_drvuninit': /tinderbox/CURRENT/i386/i386/src/sys/modules/coda/../../coda/coda_fbsd.c:215: error: `NVCODA' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/sys/modules/coda. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2004-08-31 03:10:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-31 03:10:04 - ERROR: failed to build generic kernel TB --- 2004-08-31 03:10:04 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 03:13:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7667216A4CE; Tue, 31 Aug 2004 03:13:48 +0000 (GMT) Received: from smtp1.adl2.internode.on.net (smtp1.adl2.internode.on.net [203.16.214.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96F6443D5E; Tue, 31 Aug 2004 03:13:45 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from midget.dons.net.au ([150.101.45.33])i7V3De4Y034664; Tue, 31 Aug 2004 12:43:42 +0930 (CST) Received: from inchoate.gsoft.com.au (root@localhost.dons.net.au [127.0.0.1]) by midget.dons.net.au (8.12.9/8.12.10) with ESMTP id i7V3Dbn7084826; Tue, 31 Aug 2004 12:43:38 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Doug White Date: Tue, 31 Aug 2004 12:43:36 +0930 User-Agent: KMail/1.6.2 References: <200408301121.22260.doconnor@gsoft.com.au> <20040830112608.L85743@carver.gumbysoft.com> In-Reply-To: <20040830112608.L85743@carver.gumbysoft.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200408311243.37065.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.26 (www . roaringpenguin . com / mimedefang) cc: freebsd-current@freebsd.org cc: dmlb@freebsd.org Subject: Re: bfe crash with profile.sh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 03:13:48 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 31 Aug 2004 03:58, Doug White wrote: > > I am trying this -> > > https://projects.fsck.ch/profile/wiki/InstallGuide > > > > but enabling it makes my bfe panic on boot :( > > > > I have some more info in kern/71131 > > Can you put the crashdump and the corresponding kernel.debug somewhere we > can get at it? ifconfig must be handing bogus data to bfe or enables some > wierd option that the driver doesn't digest right. The kernel+if_bfe.ko and vmcore is about 10Mb.. http://www.gsoft.com.au/~doconnor/vmcore.3.bz2 http://www.gsoft.com.au/~doconnor/kernel.3.tbz2 =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 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBM+zh5ZPcIHs/zowRAki9AJ0Y0eH3GsivLKX767nxY/uoWMEj1wCgg1Lh ZmTHsAntEyJkYUWALkxXkEs=3D =3DY+2A =2D----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 03:23:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 015C616A4CE; Tue, 31 Aug 2004 03:23:59 +0000 (GMT) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 573FC43D39; Tue, 31 Aug 2004 03:23:58 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from midget.dons.net.au ([150.101.45.33])i7V3NsHY009542; Tue, 31 Aug 2004 12:53:56 +0930 (CST) Received: from inchoate.gsoft.com.au (root@localhost.dons.net.au [127.0.0.1]) by midget.dons.net.au (8.12.9/8.12.10) with ESMTP id i7V3Npn7084910; Tue, 31 Aug 2004 12:53:51 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Doug White Date: Tue, 31 Aug 2004 12:53:50 +0930 User-Agent: KMail/1.6.2 References: <200408301121.22260.doconnor@gsoft.com.au> <20040830112608.L85743@carver.gumbysoft.com> <200408311243.37065.doconnor@gsoft.com.au> In-Reply-To: <200408311243.37065.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200408311253.50651.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.26 (www . roaringpenguin . com / mimedefang) cc: freebsd-current@freebsd.org cc: dmlb@freebsd.org Subject: Re: bfe crash with profile.sh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 03:23:59 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 31 Aug 2004 12:43, Daniel O'Connor wrote: > On Tue, 31 Aug 2004 03:58, Doug White wrote: > > > I am trying this -> > > > https://projects.fsck.ch/profile/wiki/InstallGuide > > > > > > but enabling it makes my bfe panic on boot :( > > > > > > I have some more info in kern/71131 > > > > Can you put the crashdump and the corresponding kernel.debug somewhere = we > > can get at it? ifconfig must be handing bogus data to bfe or enables > > some wierd option that the driver doesn't digest right. > > The kernel+if_bfe.ko and vmcore is about 10Mb.. Actually I'll upload it to our ISP's web server.. faster that way :) Try here http://www.users.on.net/~genesissoftware/ MD5 (kernel.3.tbz2) =3D fb2f7c992a3488a0bd484433579714a0 MD5 (vmcore.3.bz2) =3D 0f8dcf830d9a22e52c10c295a9953eb0 =2D -rw-r--r-- 1 doconnor wheel 1164996 Aug 31 12:41 kernel.3.tbz2 =2D -rw-r--r-- 1 doconnor wheel 7431232 Aug 31 12:38 vmcore.3.bz2 =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 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBM+9G5ZPcIHs/zowRAquNAJ4qTmBayq3ONc5m33j5q7CCFK2R9gCfa2Ig Z4LkhgtsUUhPzxjtMWTNvFI=3D =3DD2jr =2D----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 04:27:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A9AE16A4CE for ; Tue, 31 Aug 2004 04:27:08 +0000 (GMT) Received: from mx2.synetsystems.com (mx2.synetsystems.com [216.226.140.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6551443D1D for ; Tue, 31 Aug 2004 04:27:07 +0000 (GMT) (envelope-from rmtodd@servalan.servalan.com) Received: by mx2.synetsystems.com (Postfix, from userid 66) id 8B01A3C9; Tue, 31 Aug 2004 00:27:06 -0400 (EDT) Received: from rmtodd by servalan.servalan.com with local (Exim 4.41 (FreeBSD)) id 1C1zlS-00039w-D6; Mon, 30 Aug 2004 22:56:58 -0500 To: freebsd-current@freebsd.org Orig-To: Richard Todd References: <20040820211618.62A1C7E4@mx2.synetsystems.com> Message-Id: From: Richard Todd Date: Mon, 30 Aug 2004 22:56:58 -0500 Subject: Re: Panic 'kernel trap doesn't have ucred' in last night's -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 04:27:08 -0000 In the freebsd-current mailing list I wrote last week: >Hi. Upgraded to -current last night and got the following panic. The panic >seems to be fairly repeatable and is triggered by a minute or so's worth of >database activity with mysqld. The version of mysql is 3.23.58_1 from ports, >linked against libpthread; using libmap.conf to force usage of libc_r avoids >the panic, so it's definitely a thread/KSE issue. (Also note the oddness >of the backtrace in the frames between doreti_ast and sched_switch -- is this >normal, is the stack mangled, or is gdb just hallucinating?) My kernel config I've had a chance to do a bit more followup on this, and have found the following: 1) The bug is still there in -current as of last night. 2) I can fairly reliably reproduce the bug by starting mysqld (with it using libpthread.so) and start several mysqldumps of the same database as near simultaneously as possible. Got a coredump from this most recent attempt, about which more below. 3) Yeah, apparently gdb was a little confused w.r.t. the stack backtrace, as a backtrace from DDB on the console at the time of the panic looks different, and more plausible: the DDB backtrace shows that thread_alloc_spare() called crhold() (which it does), whereas the gdb backtrace is under the delusion that thread_alloc_spare() calls thr_suspend(). 4) Looking at the (sane) DDB backtrace as well as poking around in upper frames, the final sequence of events leading to trouble is now clearer: 1. ast calls thread_user_enter(). The thread passed to thread_user_enter, thread 0xc28c39a0, has a NULL td_ucred pointer. (Why? Good question.) 2. thread_user_enter() calls thread_alloc_spare(). 3. thread_alloc_spare() does its business, creating another thread, and at the end tries to give the new thread a reference to the orig. thread's cred by calling crhold(). Unfortunately, the orig. thread's td_ucred is NULL. 4. crhold() cheerfully takes the NULL pointer offered to it and tries to lock the mutex pointed to by the cred structure at 0x00000000. This causes an immediate segfault, hence the trap 12. 5. trap() goes about its business, notices the current thread has no td_ucred, and panics. So the real question is how come that thread had a NULL td_ucred when it got there? Wish I knew. If it'll help anyone figure this out, I had ktr(4) enabled and logging a bunch of stuff (KTR_GEN|KTR_LOCK|KTR_PROC) and can supply a ktrdump from that core file; I didn't include it here because it's rather long. Script started on Mon Aug 30 22:01:46 2004 ichotolot# gdb6 -k kernel.debug /var/crash/vmcore.106 GNU gdb 20040803 [GDB v6.x for FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-portbld-freebsd6.0"... panic: kernel trap doesn't have ucred panic messages: --- panic: kernel trap doesn't have ucred cpuid = 0 KDB: stack backtrace: kdb_backtrace(100,c28c36e0,c,c28c36e0,0) at kdb_backtrace+0x29 panic(c083022d,6c,0,0,df512c9c) at panic+0x114 trap(c0600018,c0970010,10,c28c36e0,c28c36e0) at trap+0x2f0 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc060e8e3, esp = 0xdf512cbc, ebp = 0xdf512ccc --- crhold(0,c28c39e4,c4,c2886e40,c28c36e0) at crhold+0x13 thread_alloc_spare(c28c36e0) at thread_alloc_spare+0x3b thread_user_enter(c25e2c40,c28c36e0) at thread_user_enter+0x63 ast(df512d48) at ast+0x94 doreti_ast() at doreti_ast+0x17 boot() called on cpu#0 Uptime: 1h22m58s Dumping 638 MB [CTRL-C to abort] 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 --- #0 doadump () at pcpu.h:159 159 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); doadump () at pcpu.h:159 159 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:159 #1 0xc06115dc in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:384 #2 0xc06118f5 in panic (fmt=0xc083022d "kernel trap doesn't have ucred") at /usr/src/sys/kern/kern_shutdown.c:540 #3 0xc07a187c in trap (frame= {tf_fs = -1067450344, tf_es = -1063845872, tf_ds = 16, tf_edi = -1030998304, tf_esi = -1030998304, tf_ebp = -548328244, tf_isp = -548328280, tf_ebx = 0, tf_edx = 4, tf_ecx = 0, tf_eax = -1034015680, tf_trapno = 12, tf_err = 0, tf_eip = -1067390749, tf_cs = 8, tf_eflags = 66118, tf_esp = 0, tf_ss = -1065293200}) at /usr/src/sys/i386/i386/trap.c:413 #4 0xc0790bda in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #5 0xc0600018 in thr_suspend (td=0xc28c36e0, uap=0x0) at /usr/src/sys/kern/kern_thr.c:282 #6 0xc060189f in thread_alloc_spare (td=0x6cb) at /usr/src/sys/kern/kern_kse.c:1021 #7 0xc0601bbf in thread_user_enter (p=0x0, td=0xc28c39a0) at /usr/src/sys/kern/kern_kse.c:1170 #8 0xc062f640 in ast (framep=0xdf512d48) at /usr/src/sys/kern/subr_trap.c:166 #9 0xc079154d in doreti_ast () at /usr/src/sys/i386/i386/exception.s:294 #10 0xdf512d48 in ?? () #11 0x0000002f in ?? () #12 0x0000002f in ?? () #13 0x0000002f in ?? () #14 0x0b13f400 in ?? () #15 0x08340000 in ?? () #16 0xbfbfe3d8 in ?? () #17 0xdf512d74 in ?? () #18 0x2033d81c in ?? () #19 0x0b108a00 in ?? () #20 0x0833a900 in ?? () #21 0x00000000 in ?? () #22 0x00000016 in ?? () #23 0x00000002 in ?? () #24 0x20339d2f in ?? () #25 0x0000001f in ?? () #26 0x00000202 in ?? () #27 0xbfbfe3ac in ?? () #28 0x0000002f in ?? () #29 0x00000000 in ?? () #30 0x00000000 in ?? () #31 0x00000000 in ?? () #32 0x00000000 in ?? () #33 0x1ef8e000 in ?? () #34 0xc25e4c60 in ?? () #35 0xc1ca05f0 in ?? () #36 0xdf512c9c in ?? () #37 0xdf512c84 in ?? () #38 0xc28c36e0 in ?? () #39 0xc062141b in sched_switch (td=0x2033d81c, newtd=0xb13f400) ---Type to continue, or q to quit---q at /usr/src/sys/Quit (kgdb) fr 7 #7 0xc0601bbf in thread_user_enter (p=0x0, td=0xc28c39a0) at /usr/src/sys/kern/kern_kse.c:1170 1170 thread_alloc_spare(td); (kgdb) p td $1 = (struct thread *) 0xc28c39a0 (kgdb) p *td $2 = {td_proc = 0xc25e2c40, td_ksegrp = 0x0, td_plist = { tqe_next = 0xc2778420, tqe_prev = 0xc28c32c8}, td_kglist = { tqe_next = 0x0, tqe_prev = 0xc28c32d0}, td_slpq = {tqe_next = 0xc200ab00, tqe_prev = 0xc200a178}, td_lockq = {tqe_next = 0x0, tqe_prev = 0x0}, td_runq = {tqe_next = 0x0, tqe_prev = 0xc08726cc}, td_selq = { tqh_first = 0x0, tqh_last = 0xc28c39d0}, td_sleepqueue = 0xc1fbace0, td_turnstile = 0xc23c0bc0, td_tid = 100205, td_flags = 0, td_inhibitors = 0, td_pflags = 0, td_last_kse = 0x0, td_kse = 0x0, td_dupfd = 0, td_wchan = 0x0, td_wmesg = 0x0, td_lastcpu = 0 '\0', td_oncpu = 0 '\0', td_locks = 0, td_blocked = 0x0, td_ithd = 0x0, td_lockname = 0x0, td_contested = {lh_first = 0x0}, td_sleeplocks = 0x0, td_intr_nesting_level = 0, td_pinned = 0, td_mailbox = 0x0, td_ucred = 0x0, td_standin = 0x0, td_prticks = 0, td_upcall = 0x0, td_sticks = 0, td_uuticks = 0, td_usticks = 0, td_intrval = 0, td_oldsigmask = {__bits = { 0, 0, 0, 0}}, td_sigmask = {__bits = {0, 0, 0, 0}}, td_siglist = { __bits = {0, 0, 0, 0}}, td_waitset = 0x0, td_umtx = {tqe_next = 0x0, tqe_prev = 0x0}, td_generation = 0, td_sigstk = {ss_sp = 0x0, ss_size = 0, ss_flags = 0}, td_kflags = 0, td_xsig = 0, td_profil_addr = 0, td_profil_ticks = 0, td_base_pri = 160 ' ', td_priority = 160 ' ', td_pcb = 0xdf518da0, td_state = TDS_INACTIVE, td_retval = {1, 137600624}, td_slpcallout = {c_links = {sle = {sle_next = 0xc28c33dc}, tqe = { tqe_next = 0xc28c33dc, tqe_prev = 0xce9ed370}}, c_time = 500970, c_arg = 0xc28c39a0, c_func = 0, c_flags = 8}, td_frame = 0xdf518d48, td_kstack_obj = 0xc2895948, td_kstack = 3746656256, td_kstack_pages = 2, td_altkstack_obj = 0x0, td_altkstack = 0, td_altkstack_pages = 0, td_critnest = 1, td_md = {md_savecrit = 582}, td_sched = 0xc28c3afc} (kgdb) p td->td_ucred $3 = (struct ucred *) 0x0 (kgdb) q ichotolot# exit exit Script done on Mon Aug 30 22:04:29 2004 From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 04:28:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 240CA16A4CE; Tue, 31 Aug 2004 04:28:38 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id D588E43D49; Tue, 31 Aug 2004 04:28:37 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smtp3.sentex.ca (8.13.1/8.13.1) with ESMTP id i7V4SahU095848; Tue, 31 Aug 2004 00:28:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7V4Sbk2074328; Tue, 31 Aug 2004 00:28:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 039B57303F; Tue, 31 Aug 2004 00:28:36 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040831042836.039B57303F@freebsd-current.sentex.ca> Date: Tue, 31 Aug 2004 00:28:36 -0400 (EDT) Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 04:28:38 -0000 TB --- 2004-08-31 03:10:05 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-31 03:10:05 - starting CURRENT tinderbox run for i386/pc98 TB --- 2004-08-31 03:10:05 - checking out the source tree TB --- 2004-08-31 03:10:05 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2004-08-31 03:10:05 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-31 03:15:18 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-31 03:15:18 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2004-08-31 03:15:18 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-31 04:19:33 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-31 04:19:33 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2004-08-31 04:19:33 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Aug 31 04:19:33 UTC 2004 >>> 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 [...] ===> coda cc -O2 -pipe -DPC98 -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -g -I/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /tinderbox/CURRENT/i386/pc98/src/sys/modules/coda/../../coda/coda_fbsd.c /tinderbox/CURRENT/i386/pc98/src/sys/modules/coda/../../coda/coda_fbsd.c: In function `coda_fbsd_drvinit': /tinderbox/CURRENT/i386/pc98/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: `NVCODA' undeclared (first use in this function) /tinderbox/CURRENT/i386/pc98/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/i386/pc98/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: for each function it appears in.) /tinderbox/CURRENT/i386/pc98/src/sys/modules/coda/../../coda/coda_fbsd.c: In function `coda_fbsd_drvuninit': /tinderbox/CURRENT/i386/pc98/src/sys/modules/coda/../../coda/coda_fbsd.c:215: error: `NVCODA' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/sys/modules/coda. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2004-08-31 04:28:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-31 04:28:36 - ERROR: failed to build generic kernel TB --- 2004-08-31 04:28:36 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 04:32:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D689316A4CE for ; Tue, 31 Aug 2004 04:32:31 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5EE243D49 for ; Tue, 31 Aug 2004 04:32:30 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7V4UCj0060677; Mon, 30 Aug 2004 22:30:12 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 30 Aug 2004 22:30:21 -0600 (MDT) Message-Id: <20040830.223021.70219797.imp@bsdimp.com> To: phk@phk.freebsd.dk From: "M. Warner Losh" In-Reply-To: <56850.1093894370@critter.freebsd.dk> References: <20040830192316.6B6CD12351@shub-internet.kew.com> <56850.1093894370@critter.freebsd.dk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: ahd@kew.com Subject: Re: PCI SIO devices hog interrupts, cause lock order problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 04:32:32 -0000 In message: <56850.1093894370@critter.freebsd.dk> "Poul-Henning Kamp" writes: : In message <20040830192316.6B6CD12351@shub-internet.kew.com>, Drew Derbyshire w : rites: : : >> puc should be in GENERIC, imho. : : I agree. : : >Who makes the call (or the commit)? The cost is ~ 55K on disk : >(which seems excessive) with current build, I assume that's bloated : >by the current kernel options. : : This could be vastly improved if the data structure puc uses were : more intelligent. Man cards could be described simply by their : PCI ID and "fill resource #1 with sio ports" rather than the very : space consuming and errorprone stuff we do now. The stuff we do now is trying to be too smart. Most single port cards are like phk says, but multiport is where things really go wonkies... Warner From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 04:56:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 804BA16A4CE; Tue, 31 Aug 2004 04:56:48 +0000 (GMT) Received: from ngwee.ugcs.caltech.edu (ngwee.ugcs.caltech.edu [131.215.43.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E3BC43D39; Tue, 31 Aug 2004 04:56:48 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by ngwee.ugcs.caltech.edu (Postfix, from userid 3640) id 40125CC071; Mon, 30 Aug 2004 21:56:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ngwee.ugcs.caltech.edu (Postfix) with ESMTP id DC364BD0A5; Mon, 30 Aug 2004 21:56:46 -0700 (PDT) Date: Mon, 30 Aug 2004 21:56:46 -0700 (PDT) From: "Jonathan A. Dama" To: David O'Brien In-Reply-To: <20040830163106.GA19044@dragon.nuxi.com> Message-ID: References: <20040829213449.GA33843@hub.freebsd.org> <20040830163106.GA19044@dragon.nuxi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Kenneth Stailey cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 04:56:48 -0000 What's stopping sysutils/etcmerge from replacing mergemaster in the base system? "etcmerge is a tool for keeping /etc up to date when updating. The primary difference from mergemaster is that etcmerge requires much less manual work than mergemaster, due to the use of a three way merge." - port description From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 05:02:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C90EA16A4CE for ; Tue, 31 Aug 2004 05:02:40 +0000 (GMT) Received: from axe-inc.co.jp (axegw.axe-inc.co.jp [61.199.217.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E086B43D55 for ; Tue, 31 Aug 2004 05:02:39 +0000 (GMT) (envelope-from takawata@axe-inc.co.jp) Received: from localhost (localhost [127.0.0.1]) by axe-inc.co.jp (8.9.3+3.2W/3.7W) with SMTP id OAA20287; Tue, 31 Aug 2004 14:02:36 +0900 (JST) Message-Id: <200408310502.OAA20287@axe-inc.co.jp> X-Authentication-Warning: axegw.axe-inc.co.jp: localhost [127.0.0.1] didn't use HELO protocol To: Vladimir Grebenschikov From: takawata@jp.freebsd.org In-reply-to: Your message of "Mon, 30 Aug 2004 22:52:50 +0400." <1093891970.1195.25.camel@localhost> Date: Tue, 31 Aug 2004 14:02:35 +0900 Sender: takawata@axe-inc.co.jp cc: current@freebsd.org Subject: Re: acpi_video on SONY VAIO PCG-Z1 [was: acpi_video users needed] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 05:02:40 -0000 In message <1093891970.1195.25.camel@localhost>, Vladimir Grebenschikov wrote: >On Tue, 2004-08-31 at 03:31 +0900, takawata@jp.freebsd.org wrote: > >> >> >Is any chance to make acpi_video work on SONY VAIO PCG-Z1 ? >> >> >acpi_video.ko loads well, but does not report anything, and does not add >> >> >hw.acpi.video subtree. >> >> > >> >> >Please advise. >> >> >> >> Because the ACPI device object has not enough interfaces to get the >> >> acpi_video driver work. >> >> Acpi_video driver does not check PCI device class: it checks the >> >> interfaces instead. >> >> You don't need to bother attaching acpi_video driver. >> > >> >Ok, And what conclusion "no-way" ? >> >> You may hack the driver to do so.:-) > >Oh ... first i need to hack WinXP driver to find how to control LCD >brightniness. > >> But, in your machine, the driver does not work anything but >> recognize that the video adaptor has 3 way output. And >> you can't use acpi_video, if you want to use DRM or nvidia kernel module. > >I have ATI RADEON MOBILITY, so no need nvidia module. > >Can you provide me a bit of theory ? > >Who usual responsible for LCD bacllight control ? > video-chip(ATI) / chipset(Intel) / special device on bus ? It seems to be controlled by Special device on bus called embedded controller. You can use it with setbrightness in ports/sysutils/sjog or ports/graphics/picturebook. But these tools are a bit dangerous because it will conflict with ACPI(These tools are based on disassembled AML before ACPI support is not populler in free unicies.) . I just wrote a driver for it. I hope it will help you. http://www.init-main.com/acpi_snc.tar.gz >Is this problem related to inability to "wakeup" after suspend: >"notebook alive, response on keys, but screen is not initialized >changing syscons/X doesn't help" >? > >Is "learning" acpidumps of other SONY notebooks, compatible with >acpi_video, can help ? > >I suspect there is no public spec for such kind of things, isn't it ? You may want to look into Device(SNC). From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 06:17:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74C3B16A4CE for ; Tue, 31 Aug 2004 06:17:37 +0000 (GMT) Received: from mail.uksolutions.net (customer-relay-1.mail.uksolutions.net [217.10.128.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED42D43D53 for ; Tue, 31 Aug 2004 06:17:36 +0000 (GMT) (envelope-from bruce@cran.org.uk) Received: from 82-41-13-158.cable.ubr02.edin.blueyonder.co.uk ([82.41.13.158] helo=[10.0.0.10]) by mail.uksolutions.net with asmtp (Exim 4.34) id 1C21Xl-0005Z7-B2; Tue, 31 Aug 2004 06:50:57 +0100 In-Reply-To: <200408301121.22260.doconnor@gsoft.com.au> References: <200408301121.22260.doconnor@gsoft.com.au> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <71D8B360-FB15-11D8-914A-000D93ACEE20@cran.org.uk> Content-Transfer-Encoding: 7bit From: Bruce Cran Date: Tue, 31 Aug 2004 07:17:33 +0100 To: "Daniel O'Connor" X-Mailer: Apple Mail (2.619) cc: current@freebsd.org Subject: Re: bfe crash with profile.sh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 06:17:37 -0000 On 30 Aug 2004, at 02:51, Daniel O'Connor wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I am trying this -> > https://projects.fsck.ch/profile/wiki/InstallGuide > > but enabling it makes my bfe panic on boot :( > > I have some more info in kern/71131 > > I'm also getting a panic in bfe, but this is when trying to install 5.3-BETA2 on a laptop. It panics in sysinstall after installing lots of distributions, when it tries to bring the interface up: _bus_dmamap_sync bfe_list_newbuf bfe_list_rx_init bfe_init ether_ioctl bfe_ioctl in6_ifinit in6_update_ifa in6_ifattach_linklocal in6_ifattach ... Is there any way I can get a kernel dump when I've booted from the installation CD-ROM, apart from building a custom CD? -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 06:38:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A381C16A4CE; Tue, 31 Aug 2004 06:38:37 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64F4E43D72; Tue, 31 Aug 2004 06:38:37 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smtp3b.sentex.ca (8.13.1/8.13.1) with ESMTP id i7V6capP067927; Tue, 31 Aug 2004 02:38:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i7V6caJM099997; Tue, 31 Aug 2004 02:38:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 805A37303F; Tue, 31 Aug 2004 02:38:36 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040831063836.805A37303F@freebsd-current.sentex.ca> Date: Tue, 31 Aug 2004 02:38:36 -0400 (EDT) Subject: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 06:38:37 -0000 TB --- 2004-08-31 04:28:37 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-31 04:28:37 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2004-08-31 04:28:37 - checking out the source tree TB --- 2004-08-31 04:28:37 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2004-08-31 04:28:37 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-31 04:41:31 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-31 04:41:31 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2004-08-31 04:41:31 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-31 06:27:39 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-31 06:27:39 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2004-08-31 06:27:39 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Aug 31 06:27:39 UTC 2004 >>> 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 [...] ===> coda cc -O2 -pipe -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=15000 -fno-common -g -I/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /tinderbox/CURRENT/ia64/ia64/src/sys/modules/coda/../../coda/coda_fbsd.c /tinderbox/CURRENT/ia64/ia64/src/sys/modules/coda/../../coda/coda_fbsd.c: In function `coda_fbsd_drvinit': /tinderbox/CURRENT/ia64/ia64/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: `NVCODA' undeclared (first use in this function) /tinderbox/CURRENT/ia64/ia64/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/ia64/ia64/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: for each function it appears in.) /tinderbox/CURRENT/ia64/ia64/src/sys/modules/coda/../../coda/coda_fbsd.c: In function `coda_fbsd_drvuninit': /tinderbox/CURRENT/ia64/ia64/src/sys/modules/coda/../../coda/coda_fbsd.c:215: error: `NVCODA' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/sys/modules/coda. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2004-08-31 06:38:36 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-31 06:38:36 - ERROR: failed to build generic kernel TB --- 2004-08-31 06:38:36 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 06:49:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1D6716A4CE; Tue, 31 Aug 2004 06:49:59 +0000 (GMT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D16043D53; Tue, 31 Aug 2004 06:49:59 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-69-104-103-54.dsl.snfc21.pacbell.net [69.104.103.54])i7V6nvK6205234; Tue, 31 Aug 2004 02:49:58 -0400 Message-ID: <41341F94.6000803@elischer.org> Date: Mon, 30 Aug 2004 23:49:56 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: Richard Todd References: <20040820211618.62A1C7E4@mx2.synetsystems.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: David Xu Subject: Re: Panic 'kernel trap doesn't have ucred' in last night's -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 06:50:00 -0000 Richard Todd wrote: > In the freebsd-current mailing list I wrote last week: > >>Hi. Upgraded to -current last night and got the following panic. The panic >>seems to be fairly repeatable and is triggered by a minute or so's worth of >>database activity with mysqld. The version of mysql is 3.23.58_1 from ports, >>linked against libpthread; using libmap.conf to force usage of libc_r avoids >>the panic, so it's definitely a thread/KSE issue. (Also note the oddness >>of the backtrace in the frames between doreti_ast and sched_switch -- is this >>normal, is the stack mangled, or is gdb just hallucinating?) My kernel config > I've been working on this and have some fixes on the way.. you might try tomorrow's -current as I just committed a possibly relevent change. From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 07:31:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D53D516A4CE for ; Tue, 31 Aug 2004 07:31:16 +0000 (GMT) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 21AFF43D5E for ; Tue, 31 Aug 2004 07:31:14 +0000 (GMT) (envelope-from RoKlein@roklein.de) Received: from [212.227.126.209] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1C236n-0007cd-00; Tue, 31 Aug 2004 09:31:13 +0200 Received: from [80.129.57.187] (helo=z105.roklein.de) by mrelayng.kundenserver.de with asmtp (TLSv1:RC4-MD5:128) (Exim 3.35 #1) id 1C236m-0006FJ-00; Tue, 31 Aug 2004 09:31:12 +0200 From: Robert Klein Organization: roklein.de To: Gavin Atkinson Date: Tue, 31 Aug 2004 09:31:05 +0200 User-Agent: KMail/1.6.1 References: <200408281223.22399.RoKlein@roklein.de> <1093879837.30583.7.camel@buffy.york.ac.uk> In-Reply-To: <1093879837.30583.7.camel@buffy.york.ac.uk> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <200408310931.06000.RoKlein@roklein.de> X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:ed18d71deac0f49a40655750752d3db9 cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA hangs on Acer TM290 series Laptop X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: RoKlein@roklein.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, 31 Aug 2004 07:31:16 -0000 On Montag, 30. August 2004 17:30, Gavin Atkinson wrote: > On Sat, 2004-08-28 at 11:23, Robert Klein wrote: > > I tried to boot 5.3-BETA on my TM291 (Centrino, > > "hotpluggable" DVD/CDRW-Combo, bg2200 WLAN). > > > > It hangs after the first few lines of boot messages and has > > to be rebooted the hard way (press power-off for four > > seconds).. > Try switching any "Plug and Play OS" type options in your BIOS > to "No" or similar. This fixes at least one laptop I've tried. There are no "Plug an Play" options in the BIOS. It is one of those "I know better" BIOSes... > Also, try breaking to the loader prompt at the Beastie menu, > and typing > > set hw.pci.enable_io_modes="1" > boot No, this does not help, but setting it to "0" gets me one step further. The boot process succeeds at the PCI detection phase (or whatever it is called) and proceeds through agp0, pci0 again (display), uhci0, and gets a fatal trap 12 at (or after) uhci1. The output from "boot -v" and output of "trace" command is below. Btw, this is still using the 5-3-beta1 snapshot from AUG-27 from snapshots.se.freebsd.org. PS: I just tried the same with 5.2-RELEASE and I get the trap at the same place... Thanks and best regards, Robert --- output from "boot -v" with set hw.pci.enable_io_modes="0" --- uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1600-0x161f at device 19.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1600 $PIR: Fount IRQ 10 for link 0x63 from 5 10 11 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xe7e02 fault code = supervior read, page not present instruction pointer = 0x8:0xc00e9d05 stack pointer = 0x10:0xc10219ec frame pointer = 0x10:0xc10219ec code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread 0] Stopped at 0xc00e9d05: cmpb %cs:0x1(%esi),%bl db> trace kernbase(c0812ff4,c20,c07f2384,a0b,e9) at 0xc00e9d05 end(cb9d08c4,c4f6ec8b,81067540,ffffe5,e67f2400) at 0xc1021a44 db> From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 07:43:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D66E616A4CE; Tue, 31 Aug 2004 07:43:53 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2866743D45; Tue, 31 Aug 2004 07:43:53 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1C23J0-000607-VL; Tue, 31 Aug 2004 11:43:51 +0400 From: Vladimir Grebenschikov To: Jonathan In-Reply-To: <4133DA04.4030103@us.army.mil> References: <200408301916.22240.mjohnston@skyweb.ca> <4133DA04.4030103@us.army.mil> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Tue, 31 Aug 2004 11:43:50 +0400 Message-Id: <1093938230.961.8.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.93FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: kevlo@FreeBSD.org cc: "current@freebsd.org" Subject: Re: cvs-src summary for August 23-30 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 07:43:54 -0000 On Mon, 2004-08-30 at 21:53 -0400, Jonathan wrote: > Mark Johnston wrote: > > > Here's this week's summary. As a side note, I discovered Synergy > > (http://synergy2.sf.net) today, and it made the summary-writing much more > > pleasant, letting me flip my mouse cursor between the desktop I write the > > summary on and the laptop I read the mail on, copying and pasting > > transparently. I highly recommend it if you run any kind of > > multi-PC-on-one-desktop configuration. > > > > This is one of the coolest and most handy things I have ever seen! I > can't say how well it works on the X side as my server is headless but > on my XP desktop and laptop it ROCKS :D Sorry for the extra noise but if > you have not looked at this and even occasionally use two computers at > once it's well worth checking out!) Yes, but port does not work on -CURRENT: (server part of port) $ synergys terminate called after throwing an instance of 'std::bad_alloc' what(): St9bad_alloc Abort (core dumped) $ Also port version is 1.0.14 when latest stable version 1.1.7. Fresh version not builds due to 'alloca' redefinition. > Excited with new program, > Jonathan -- Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 08:07:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 776F016A4CE for ; Tue, 31 Aug 2004 08:07:04 +0000 (GMT) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6CFB43D1F for ; Tue, 31 Aug 2004 08:07:03 +0000 (GMT) (envelope-from q@uni.de) Received: from wrzx30.rz.uni-wuerzburg.de (wrzx30.rz.uni-wuerzburg.de [132.187.1.30]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id 04716D19B8; Tue, 31 Aug 2004 10:07:03 +0200 (CEST) Received: from virusscan (localhost [127.0.0.1]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id E2F4785BBF; Tue, 31 Aug 2004 10:07:02 +0200 (CEST) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id C33CF85BC2; Tue, 31 Aug 2004 10:07:02 +0200 (CEST) Received: from coyote.q.local (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id A82D3D19B8; Tue, 31 Aug 2004 10:07:02 +0200 (CEST) Received: from igor.q.local (igor [192.168.0.148]) by coyote.q.local (8.12.10/8.12.10) with ESMTP id i7V872TH068246; Tue, 31 Aug 2004 10:07:02 +0200 (CEST) (envelope-from q@igor.q.local) Received: from igor.q.local (localhost [127.0.0.1]) by igor.q.local (8.13.1/8.13.1) with ESMTP id i7V872ds000965; Tue, 31 Aug 2004 10:07:02 +0200 (CEST) (envelope-from q@igor.q.local) Received: (from q@localhost) by igor.q.local (8.13.1/8.13.1/Submit) id i7V871E2000964; Tue, 31 Aug 2004 10:07:01 +0200 (CEST) (envelope-from q) Date: Tue, 31 Aug 2004 10:07:01 +0200 From: Ulrich Spoerlein To: Michael Nottebrock Message-ID: <20040831080701.GA703@galgenberg.net> Mail-Followup-To: Michael Nottebrock , freebsd-current@freebsd.org References: <20040829213449.GA33843@hub.freebsd.org> <20040830163106.GA19044@dragon.nuxi.com> <20040830210817.GB749@galgenberg.net> <200408302339.21728.michaelnottebrock@gmx.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: <200408302339.21728.michaelnottebrock@gmx.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 08:07:04 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, 30.08.2004 at 23:39:17 +0200, Michael Nottebrock wrote: > > This is not funny. I myself have to think loud about which button to > > press. 'r' is on the left keyboard side and 'l' is to the right. > > > > Not good. >=20 > Sissy :). FWIW, it's probably good to do some thinking aloud while mergin= g=20 > configs. Yes of course, but the thinking is not spend on which side to merge, but which key to press! Do you swap the definition of true and false in your code, so that people should think twice about whats true and false only for the purpose of them thinking twice? Anyway, I think there are more important matters to attend right now in FreeBSD. This probably only affects people with a QWERTY or similiar (the german QWERTZ) layout. Ulrich Spoerlein --=20 PGP Key ID: F0DB9F44 Get it while it's hot! PGP Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBNDGlmArGtfDbn0QRAg8gAJ4qJiWXePz9SMjCOIkwPJkH/B0f9QCg6sAr ZWupR0lhZ4jyiIXxOiWdIgw= =XnTA -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 08:14:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F256716A4CE; Tue, 31 Aug 2004 08:14:42 +0000 (GMT) Received: from zone3.gcu-squad.org (zone3.gcu-squad.org [217.19.50.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46E0543D3F; Tue, 31 Aug 2004 08:14:42 +0000 (GMT) (envelope-from imil@home.imil.net) Received: from localhost.gcu-squad.org (IDENT:imil@localhost.gcu-squad.org [127.0.0.1]) by zone3.gcu-squad.org (8.13.1/8.13.1) with ESMTP id i7V85isS004633; Tue, 31 Aug 2004 10:05:44 +0200 (CEST) (envelope-from imil@home.imil.net) Date: Tue, 31 Aug 2004 10:05:41 +0200 (CEST) From: iMil X-X-Sender: imil@zone3.gcu-squad.org To: Bill Paul In-Reply-To: <20040830193809.508F816A4D0@hub.freebsd.org> Message-ID: <20040831095219.A88889@zone3.gcu-squad.org> References: <20040830193809.508F816A4D0@hub.freebsd.org> X-GPG-Fingerprint: 8431 79E4 A08B D1B7 0DC8 0BDF 146D C194 65B2 CD42 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: current@FreeBSD.ORG Subject: Re: Project Evil on a WG311v2: working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 08:14:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Go back to the driver CD that came with your card and use the Windows XP > driver like you were supposed to. If you do, you should see this ^^^^^^^^^^^^^^^^^^^^^^^^^ I'll try this asap, but was it written somewhere ? as a non-windows user I was not aware of such a prerequisite, I guess a good and complete doc on the subject could save time to everybody, I can work on this if nobody sees objection. Regards, - ------------------------- iMil _ http://gcu-squad.org ASCII ribbon campaign ( ) - against HTML email X & vCards / \ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBNDFYFG3BlGWyzUIRAsloAJ44WI3LGAc6OQKdwkcCvuKv5j4wrACfQlpM tFgyQKg5kAoLXEY6+BHYx6I= =kIKU -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 08:24:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A750316A4CE for ; Tue, 31 Aug 2004 08:24:39 +0000 (GMT) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 615DF43D46 for ; Tue, 31 Aug 2004 08:24:39 +0000 (GMT) (envelope-from brad@stop.mail-abuse.org) Received: from [10.0.1.3] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.11/8.12.3) with ESMTP id i7V8OaHK009876; Tue, 31 Aug 2004 04:24:37 -0400 (EDT) (envelope-from brad@stop.mail-abuse.org) Mime-Version: 1.0 X-Sender: bs663385@127.0.0.1 Message-Id: In-Reply-To: <20040831080701.GA703@galgenberg.net> References: <20040829213449.GA33843@hub.freebsd.org> <20040830163106.GA19044@dragon.nuxi.com> <20040830210817.GB749@galgenberg.net> <200408302339.21728.michaelnottebrock@gmx.net> <20040831080701.GA703@galgenberg.net> Date: Tue, 31 Aug 2004 10:24:29 +0200 To: Ulrich Spoerlein From: Brad Knowles Content-Type: text/plain; charset="us-ascii" ; format="flowed" cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 08:24:39 -0000 At 10:07 AM +0200 2004-08-31, Ulrich Spoerlein wrote: > Anyway, I think there are more important matters to attend right now in > FreeBSD. This probably only affects people with a QWERTY or similiar (the > german QWERTZ) layout. Or for whom "L" equals left, and "R" equals right. Think French. Gauche and Droite. [0] Does hard-coding "g" and "d" into the program make any more sense than hard-coding "l" and "r"? Why not make the program fully internationalized, so that the key bindings for left and right are dependant on your language specification within your environment? How about using "1" and "0"? One is on the left side of the keyboard and the other is on the right side, and I think that this overall sideded-ness is consistent across all different keyboard types I've ever seen. It also makes a certain silly binary sense. [0] I can't believe that I'm actually saying something positive about French! Pierre Beyssac is going to freak! ;) -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 08:36:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFABD16A4CE; Tue, 31 Aug 2004 08:36:11 +0000 (GMT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 47D0243D62; Tue, 31 Aug 2004 08:36:11 +0000 (GMT) (envelope-from des@des.no) Received: from dwp.des.no (37.80-203-228.nextgentel.com [80.203.228.37]) by mail.broadpark.no (Postfix) with ESMTP id AC76B454A; Tue, 31 Aug 2004 10:36:48 +0200 (MEST) Received: by dwp.des.no (Postfix, from userid 2602) id 37A34B874; Tue, 31 Aug 2004 10:36:10 +0200 (CEST) To: David O'Brien References: <20040829213449.GA33843@hub.freebsd.org> <20040830135311.11040.qmail@web50603.mail.yahoo.com> <20040830163106.GA19044@dragon.nuxi.com> <20040830210817.GB749@galgenberg.net> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Tue, 31 Aug 2004 10:36:10 +0200 In-Reply-To: <20040830210817.GB749@galgenberg.net> (Ulrich Spoerlein's message of "Mon, 30 Aug 2004 23:08:17 +0200") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: Kenneth Stailey cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 08:36:11 -0000 Ulrich Spoerlein writes: > On Mon, 30.08.2004 at 09:31:06 -0700, David O'Brien wrote: > > Note, though, that this output has nothing to do with mergemaster -- it > > is sdiff(1) that is used. What you don't like is sdiff(1)'s output > > format. > Looks like one can't configure the used keys... Feel free to submit a patch. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 08:40:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72DFA16A4CE; Tue, 31 Aug 2004 08:40:35 +0000 (GMT) Received: from meitner.wh.uni-dortmund.de (meitner.wh.Uni-Dortmund.DE [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0ED1943D39; Tue, 31 Aug 2004 08:40:35 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id 1D6461674DF; Tue, 31 Aug 2004 10:40:34 +0200 (CEST) Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id i7V8eThm061089 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 31 Aug 2004 10:40:30 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock To: freebsd-current@freebsd.org Date: Tue, 31 Aug 2004 10:40:27 +0200 User-Agent: KMail/1.7 References: <20040830193809.508F816A4D0@hub.freebsd.org> <20040831095219.A88889@zone3.gcu-squad.org> In-Reply-To: <20040831095219.A88889@zone3.gcu-squad.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1698831.cmYioXIz6W"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200408311040.28793.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new cc: iMil cc: Bill Paul Subject: Re: Project Evil on a WG311v2: working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 08:40:35 -0000 --nextPart1698831.cmYioXIz6W Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 31 August 2004 10:05, iMil wrote: > I was not aware of such a prerequisite, I guess a good and complete doc > on the subject could save time to everybody, I can work on this if nobody > sees objection. God forbid, proper docs on the NDISulator would prevent Bill from mopping d= own=20 users on the mailing lists. =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart1698831.cmYioXIz6W Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBNDl8Xhc68WspdLARAnNBAJ9xnDH2EMSvz47h9LbRBE/RYLkAtACcCxsO no7Y6Z3zAP2wlOKopGyAWE8= =F6Zj -----END PGP SIGNATURE----- --nextPart1698831.cmYioXIz6W-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 08:48:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9570A16A4CE; Tue, 31 Aug 2004 08:48:44 +0000 (GMT) Received: from freesbee.dk (freesbee.dk [194.192.25.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 009C243D5A; Tue, 31 Aug 2004 08:48:44 +0000 (GMT) (envelope-from signout@signout.dk) Received: from signoutscraptop (localhost [127.0.0.1]) by freesbee.dk (Postfix) with SMTP id D3A0B2BBF7; Tue, 31 Aug 2004 10:48:41 +0200 (CEST) Message-ID: <012a01c48f37$510d5ce0$87075050@signoutscraptop> From: =?iso-8859-1?Q?Dennis_Kj=E6r_Jensen?= To: "Ruslan Ermilov" References: <0be501c48e94$ba63c060$87075050@signoutscraptop> <20040830150202.GB65719@ip.net.ua> Date: Tue, 31 Aug 2004 10:48:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.181 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA2 problems booting HP NetServer E60 both ACPI and non-ACPI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 08:48:44 -0000 >> I have console dumps from boot both with and without ACPI enabled on >> http://signout.dk/FreeBSD/20040830-E60 >> >> If AGP is in the kernel the system simply halts during boot after detecting >> agp0. >> > You can disable AGP with hints on recent -CURRENT versions. Set > hint.agp.0.disabled=1 while in the loader(8), and see if that helps. Same same - the system locks up both with and without acpi ... Dennis From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 08:52:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72C0016A4CE for ; Tue, 31 Aug 2004 08:52:13 +0000 (GMT) Received: from mxout6.cac.washington.edu (mxout6.cac.washington.edu [140.142.33.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41FDB43D1F for ; Tue, 31 Aug 2004 08:52:13 +0000 (GMT) (envelope-from dsyphers@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.33.9]) ESMTP id i7V8qCek016638 for ; Tue, 31 Aug 2004 01:52:12 -0700 Received: from [192.168.1.105] (c-24-18-235-11.client.comcast.net [24.18.235.11]) (authenticated bits=0)i7V8qCC4022082 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 31 Aug 2004 01:52:12 -0700 From: David Syphers To: freebsd-current@freebsd.org Date: Tue, 31 Aug 2004 01:52:22 -0700 User-Agent: KMail/1.6.2 References: <20040829213449.GA33843@hub.freebsd.org> <20040831080701.GA703@galgenberg.net> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408310152.22649.dsyphers@u.washington.edu> Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 08:52:13 -0000 On Tuesday 31 August 2004 01:24 am, Brad Knowles wrote: > At 10:07 AM +0200 2004-08-31, Ulrich Spoerlein wrote: > > Anyway, I think there are more important matters to attend right now in > > FreeBSD. This probably only affects people with a QWERTY or similiar > > (the german QWERTZ) layout. ... > Think French. Gauche and Droite. [0] > Does hard-coding "g" and "d" into the program make any more sense No, unfortunately, because on QWERTY "d" is to the left of "g". Same problem as with "r" and "l". But, and I just thought of this, why not turn your keyboard upside down? That's the non-techie fix... (I realize this doesn't work for laptops.) Mmm... I think we're about ready for chat@ here... -David -- +++ Divide By Cucumber Error. Please Reinstall Universe And Reboot. +++ From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 09:12:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D44D16A4CF; Tue, 31 Aug 2004 09:12:06 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2965043D3F; Tue, 31 Aug 2004 09:12:06 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smtp3b.sentex.ca (8.13.1/8.13.1) with ESMTP id i7V9C56R080908; Tue, 31 Aug 2004 05:12:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i7V9C4ZA054317; Tue, 31 Aug 2004 05:12:04 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2AEAA7303F; Tue, 31 Aug 2004 05:12:05 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040831091205.2AEAA7303F@freebsd-current.sentex.ca> Date: Tue, 31 Aug 2004 05:12:05 -0400 (EDT) Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 09:12:06 -0000 TB --- 2004-08-31 07:58:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-31 07:58:01 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-08-31 07:58:01 - checking out the source tree TB --- 2004-08-31 07:58:01 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2004-08-31 07:58:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-31 08:02:56 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-31 08:02:56 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2004-08-31 08:02:56 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-31 09:05:53 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-31 09:05:53 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2004-08-31 09:05:53 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Aug 31 09:05:53 UTC 2004 >>> 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 [...] ===> coda cc -O2 -pipe -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=15000 -fno-common -g -I/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC -mcmodel=medlow -msoft-float -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/coda/../../coda/coda_fbsd.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/coda/../../coda/coda_fbsd.c: In function `coda_fbsd_drvinit': /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: `NVCODA' undeclared (first use in this function) /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: for each function it appears in.) /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/coda/../../coda/coda_fbsd.c: In function `coda_fbsd_drvuninit': /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/coda/../../coda/coda_fbsd.c:215: error: `NVCODA' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/coda. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-08-31 09:12:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-31 09:12:04 - ERROR: failed to build generic kernel TB --- 2004-08-31 09:12:04 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 10:28:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D70C916A4CE for ; Tue, 31 Aug 2004 10:28:55 +0000 (GMT) Received: from obh.snafu.de (obh.snafu.de [213.73.92.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B97B43D3F for ; Tue, 31 Aug 2004 10:28:55 +0000 (GMT) (envelope-from ob@gruft.de) Received: from ob by obh.snafu.de with local (Exim 4.34 (FreeBSD)) id 1C25sg-000Hit-8o; Tue, 31 Aug 2004 12:28:50 +0200 Date: Tue, 31 Aug 2004 12:28:50 +0200 From: Oliver Brandmueller To: Sean McNeil Message-ID: <20040831102849.GD52217@e-Gitt.NET> References: <1093919355.39775.2.camel@server.mcneil.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1093919355.39775.2.camel@server.mcneil.com> User-Agent: Mutt/1.5.6i Sender: Oliver Brandmueller cc: current@freebsd.org Subject: Re: RELENG_5 ipfw problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 10:28:56 -0000 Hi. On Mon, Aug 30, 2004 at 07:29:15PM -0700, Sean McNeil wrote: > How are you compiling ipfw2? I have it built into my kernel and have no > issues at all. Are you using it as a loadable module or part of the > kernel? Meanwhile (as I wrote in the thread) I have IPFW compiled in by using options IPFIREWALL and options IPFIREWALL_FORWARD - which is now mandatory to have forwarding support. When you say "no issues at all", do you also use forwarding to change the next hop of IP packets? This seems to be the only problem and is a very special setup. Greetings, Oliver -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 10:30:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9110816A4CE for ; Tue, 31 Aug 2004 10:30:07 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id E358B43D4C for ; Tue, 31 Aug 2004 10:30:06 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1C25rt-000Ple-Dm for current@freebsd.org; Tue, 31 Aug 2004 14:28:01 +0400 From: Vladimir Grebenschikov To: "current@freebsd.org" Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Tue, 31 Aug 2004 14:28:00 +0400 Message-Id: <1093948080.29903.14.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.93FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Subject: sysutils/strace wilderness on 6-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 10:30:07 -0000 Hi (fresh -CURREMT and fresh strace from ports, UP machine) It silmple does nothing - sleeps foreaver in suspended: # strace /bin/ls ^T load: 0.14 cmd: strace 98957 [suspended] 0.00u 0.00s 0% 760k ^C # child program does not executed too. But if do sometimes (often) if I do # truss strace /bin/ls (it works as expected) and then # strace /bin/ls execve(0xbfbfe0e0, [0xbfbfe5c4], [/* 0 vars */]) = 0 mmap(0, 3880, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0) = 0x28071000 munmap(0x28071000, 3880) = 0 __sysctl([...], 0x2806da4c, 0xbfbfe378, NULL, 0) = 0 mmap(0, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) = 0x28071000 issetugid(0) = 0 open("/etc/libmap.conf", O_RDONLY) = 3 ... strace start work as expected, but only one time, second time it stick again. view from KDB: [thread 100016] Stopped at kdb_enter+0x30: leave db> ps pid proc uarea uid ppid pgrp flag stat wmesg wchan cmd 99035 c32448c0 d6a85000 207 99034 99034 0020002 stop[SUSP] strace 99034 c21f8a80 d7911000 207 98930 99034 0004002 [SLPQ pioctl 0xc32449e8][SLP] strace -- Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 10:30:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D9B116A4CE; Tue, 31 Aug 2004 10:30:00 +0000 (GMT) Received: from web.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2C8E43D31; Tue, 31 Aug 2004 10:29:59 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.20] (portacare.portaone.com [195.140.247.242]) (authenticated bits=0) by web.portaone.com (8.12.8p2/8.12.8) with ESMTP id i7VATlPR064400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Aug 2004 12:29:54 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <4134530C.6020309@portaone.com> Date: Tue, 31 Aug 2004 13:29:32 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?RGFnLUVybGluZyBTbdCscmdyYXY=?= References: <4133683A.3090201@portaone.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit cc: current@freebsd.org cc: sos@freebsd.org Subject: Re: burncd(8) usability: why `-s max' isn't default? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 10:30:00 -0000 Dag-Erling SmÞrgrav wrote: > Maxim Sobolev writes: > >>I wonder if there are any compelling reasons why `-s max' is not >>default behaviour of burncd(8). IMHO, there is no point to have >>default of 4. Usually, today's drives are smart enough to select the >>maximum speed supported both by drive and by the medium. > > > Plenty of drives aren't, especially with cheap media. Do you have any evidence? I know what I am talking about. We are working on the mass-product based on FreeBSD. This product will have to burn data CDs. We have tried compatibility of various media with `-s max', including very cheap ones and have never seen any corruption due to speed mismatch. Virtually all media available on the market today has a special track, which records its speed rating and manufacturer. Granted, some very old burners may not be able to correctly read and understand this data, but for the same age reason those drives are not likely to be able to write at more than 8x anyway (most likely even 4x). You will have big problems finding any CD-R media (even very cheap one) with rating < 32 on the market today, so that chances to "overspeed" the media with those ancient burners are quite theoretical. Based on that I think -s max is reasonable default. -Maxim From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 10:30:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EFB016A4CE for ; Tue, 31 Aug 2004 10:30:43 +0000 (GMT) Received: from ank-pki.ru (mercury.ank-pki.ru [213.170.76.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77A3143D2D for ; Tue, 31 Aug 2004 10:30:42 +0000 (GMT) (envelope-from toxa@cterra.ru) Received: (qmail 14348 invoked by uid 0); 31 Aug 2004 14:30:40 +0400 Received: from toxa@cterra.ru by mercury.ank-pki.ru by uid 0 with qmail-scanner-1.22 (clamscan: 0.75.1. spamassassin: 2.64. Clear:RC:1(213.170.76.150):. Processed in 0.031393 secs); 31 Aug 2004 10:30:40 -0000 Received: from unknown (HELO localhost) (toxa@213.170.76.150) by ank.nwudc.ru with SMTP; 31 Aug 2004 14:30:40 +0400 Date: Tue, 31 Aug 2004 14:27:31 +0400 From: Toxa To: current@freebsd.org X-Comment-To: "Anton Karpov" Message-ID: <20040831102731.GA1344@laptoxa.toxa.lan> Mail-Followup-To: current@freebsd.org, takawata@jp.freebsd.org References: <1093891970.1195.25.camel@localhost> <200408310502.OAA20287@axe-inc.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200408310502.OAA20287@axe-inc.co.jp> User-Agent: Outluck Express 1.5.6i for MS-DOS 6.22-SMP X-Mailer: See User-Agent above :) X-Operating-System: MS-DOS 6.22-CURRENT on Sony VAIO laptop X-PGP-Public-Key: http://toxahost.org/gpg/pubkey.asc X-Useless-Header: Do Androids Dream of Electric Sheep? Subject: Re: acpi_video on SONY VAIO PCG-Z1 [was: acpi_video users needed] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 10:30:43 -0000 On Tue, Aug 31, 2004 at 02:02:35PM +0900, takawata@jp.freebsd.org wrote: > . > I just wrote a driver for it. I hope it will help you. > http://www.init-main.com/acpi_snc.tar.gz On sony vaio pcg-v505bx, after kldload'ing two modules: acpi_sny0: on acpi0 [(14:26)(62.55%)(p1):~/tmp/acpi_snc ] sysctl -a|grep sny dev.acpi_sny.0.%desc: Sony system controller dev.acpi_sny.0.%driver: acpi_sny dev.acpi_sny.0.%location: handle=\_SB_.PCI0.LPC0.SNC_ dev.acpi_sny.0.%pnpinfo: _HID=SNY5001 _UID=0 dev.acpi_sny.0.%parent: acpi0 dev.acpi_sny.0.brightness: 94 [(14:26)(62.78%)(p1):~/tmp/acpi_snc ] sudo sysctl dev.acpi_sny.0.brightness=10 sysctl: oid 'dev.acpi_sny.0.brightness' is read only nothing happens... -- Anton A. Karpov PGP key: http://www.toxahost.org/pgp/pubkey.asc You can finger me @toxahost.org for my current status =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~= Hi! I am a .signature virus! Copy me into your ~/.signature to help me spread! =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~= From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 10:31:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C9D716A4CE; Tue, 31 Aug 2004 10:31:41 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A7C843D3F; Tue, 31 Aug 2004 10:31:41 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smtp3.sentex.ca (8.13.1/8.13.1) with ESMTP id i7VAVe3F038433; Tue, 31 Aug 2004 06:31:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7VAVeBm019996; Tue, 31 Aug 2004 06:31:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id BC36D7303F; Tue, 31 Aug 2004 06:31:40 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040831103140.BC36D7303F@freebsd-current.sentex.ca> Date: Tue, 31 Aug 2004 06:31:40 -0400 (EDT) Subject: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 10:31:41 -0000 TB --- 2004-08-31 09:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-31 09:15:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2004-08-31 09:15:00 - checking out the source tree TB --- 2004-08-31 09:15:00 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2004-08-31 09:15:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-31 09:20:22 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-31 09:20:22 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-08-31 09:20:22 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-31 10:24:21 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-31 10:24:21 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-08-31 10:24:21 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Aug 31 10:24:21 UTC 2004 >>> 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 [...] ===> coda cc -O2 -pipe -mcpu=ev4 -mtune=ev5 -mieee -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=15000 -fno-common -g -I/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /tinderbox/CURRENT/alpha/alpha/src/sys/modules/coda/../../coda/coda_fbsd.c /tinderbox/CURRENT/alpha/alpha/src/sys/modules/coda/../../coda/coda_fbsd.c: In function `coda_fbsd_drvinit': /tinderbox/CURRENT/alpha/alpha/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: `NVCODA' undeclared (first use in this function) /tinderbox/CURRENT/alpha/alpha/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/alpha/alpha/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: for each function it appears in.) /tinderbox/CURRENT/alpha/alpha/src/sys/modules/coda/../../coda/coda_fbsd.c: In function `coda_fbsd_drvuninit': /tinderbox/CURRENT/alpha/alpha/src/sys/modules/coda/../../coda/coda_fbsd.c:215: error: `NVCODA' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/sys/modules/coda. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2004-08-31 10:31:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-31 10:31:40 - ERROR: failed to build generic kernel TB --- 2004-08-31 10:31:40 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 10:39:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DD7916A4CE for ; Tue, 31 Aug 2004 10:39:26 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE13C43D45 for ; Tue, 31 Aug 2004 10:39:25 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1C262t-0003YL-Su for current@freebsd.org; Tue, 31 Aug 2004 14:39:23 +0400 From: Vladimir Grebenschikov To: current@freebsd.org In-Reply-To: <200408310502.OAA20287@axe-inc.co.jp> References: <200408310502.OAA20287@axe-inc.co.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Tue, 31 Aug 2004 14:39:22 +0400 Message-Id: <1093948763.29903.16.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.93FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Subject: Re: acpi_video on SONY VAIO PCG-Z1 [was: acpi_video users needed] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 10:39:26 -0000 On Tue, 2004-08-31 at 14:02 +0900, takawata@jp.freebsd.org wrote: > In message <1093891970.1195.25.camel@localhost>, Vladimir Grebenschikov wrote: > >On Tue, 2004-08-31 at 03:31 +0900, takawata@jp.freebsd.org wrote: > > > >> >> >Is any chance to make acpi_video work on SONY VAIO PCG-Z1 ? > >> >> >acpi_video.ko loads well, but does not report anything, and does not add > >> >> >hw.acpi.video subtree. > >> >> > > >> >> >Please advise. > >> >> > >> >> Because the ACPI device object has not enough interfaces to get the > >> >> acpi_video driver work. > >> >> Acpi_video driver does not check PCI device class: it checks the > >> >> interfaces instead. > >> >> You don't need to bother attaching acpi_video driver. > >> > > >> >Ok, And what conclusion "no-way" ? > >> > >> You may hack the driver to do so.:-) > > > >Oh ... first i need to hack WinXP driver to find how to control LCD > >brightniness. > > > >> But, in your machine, the driver does not work anything but > >> recognize that the video adaptor has 3 way output. And > >> you can't use acpi_video, if you want to use DRM or nvidia kernel module. > > > >I have ATI RADEON MOBILITY, so no need nvidia module. > > > >Can you provide me a bit of theory ? > > > >Who usual responsible for LCD bacllight control ? > > video-chip(ATI) / chipset(Intel) / special device on bus ? > > It seems to be controlled by Special device on bus called embedded controller. > You can use it with setbrightness in ports/sysutils/sjog or > ports/graphics/picturebook. But these tools are a bit dangerous because > it will conflict with ACPI(These tools are based on disassembled AML before > ACPI support is not populler in free unicies.) > . > I just wrote a driver for it. I hope it will help you. > http://www.init-main.com/acpi_snc.tar.gz Yes, it works, now I can control LCD backlight brightness. $ setbrightness 50 $ setbrightness 255 # sysctl dev.acpi_snc dev.acpi_snc.0.%desc: Sony system controller dev.acpi_snc.0.%driver: acpi_snc dev.acpi_snc.0.%location: handle=\_SB_.PCI0.LPCB.SNC_ dev.acpi_snc.0.%pnpinfo: _HID=SNY5001 _UID=0 dev.acpi_snc.0.%parent: acpi0 dev.acpi_snc.0.brightness: 60 # Now only issue I am warry about "How to awake screen after suspend ?" -- Vladimir B. Grebenschikov SWsoft Inc. vova@sw-soft.com -- Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 10:41:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1F2816A4CE for ; Tue, 31 Aug 2004 10:41:17 +0000 (GMT) Received: from axe-inc.co.jp (axegw.axe-inc.co.jp [61.199.217.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 06B3D43D45 for ; Tue, 31 Aug 2004 10:41:17 +0000 (GMT) (envelope-from takawata@axe-inc.co.jp) Received: from localhost (localhost [127.0.0.1]) by axe-inc.co.jp (8.9.3+3.2W/3.7W) with SMTP id TAA25051; Tue, 31 Aug 2004 19:41:11 +0900 (JST) Message-Id: <200408311041.TAA25051@axe-inc.co.jp> X-Authentication-Warning: axegw.axe-inc.co.jp: localhost [127.0.0.1] didn't use HELO protocol To: Toxa From: takawata@jp.freebsd.org In-reply-to: Your message of "Tue, 31 Aug 2004 14:27:31 +0400." <20040831102731.GA1344@laptoxa.toxa.lan> Date: Tue, 31 Aug 2004 19:41:11 +0900 Sender: takawata@axe-inc.co.jp cc: current@freebsd.org Subject: Re: acpi_video on SONY VAIO PCG-Z1 [was: acpi_video users needed] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 10:41:17 -0000 In message <20040831102731.GA1344@laptoxa.toxa.lan>, Toxa wrote: >On Tue, Aug 31, 2004 at 02:02:35PM +0900, takawata@jp.freebsd.org wrote: >> . >> I just wrote a driver for it. I hope it will help you. >> http://www.init-main.com/acpi_snc.tar.gz > > >On sony vaio pcg-v505bx, after kldload'ing two modules: > >acpi_sny0: on acpi0 > >[(14:26)(62.55%)(p1):~/tmp/acpi_snc ] sysctl -a|grep sny >dev.acpi_sny.0.%desc: Sony system controller >dev.acpi_sny.0.%driver: acpi_sny >dev.acpi_sny.0.%location: handle=\_SB_.PCI0.LPC0.SNC_ >dev.acpi_sny.0.%pnpinfo: _HID=SNY5001 _UID=0 >dev.acpi_sny.0.%parent: acpi0 >dev.acpi_sny.0.brightness: 94 > >[(14:26)(62.78%)(p1):~/tmp/acpi_snc ] sudo sysctl >dev.acpi_sny.0.brightness=10 >sysctl: oid 'dev.acpi_sny.0.brightness' is read only > >nothing happens... Sorry, please refetch it from http://www.init-main.com/acpi_snc.tar.gz From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 10:43:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65D5516A4CE for ; Tue, 31 Aug 2004 10:43:45 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D23843D55 for ; Tue, 31 Aug 2004 10:43:45 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1C2675-0003Yk-RZ; Tue, 31 Aug 2004 14:43:43 +0400 From: Vladimir Grebenschikov To: Bryan Liesner In-Reply-To: <1093876455.1503.7.camel@localhost> References: <200408291848.i7TImAq8072080@mail.gits.dyndns.org> <413333FB.5020905@kishka.net> <1093876455.1503.7.camel@localhost> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Tue, 31 Aug 2004 14:43:43 +0400 Message-Id: <1093949023.29903.21.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.93FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: "current@freebsd.org" Subject: Re: [PATCH TO TEST] VESA [1024x768] mode support for FreeBSD-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 10:43:45 -0000 On Mon, 2004-08-30 at 18:34 +0400, Vladimir Grebenschikov wrote: > On Mon, 2004-08-30 at 10:04 -0400, Bryan Liesner wrote: > > Cyrille Lefevre wrote: > > > PR#71142 (http://www.freebsd.org/cgi/query-pr.cgi?pr=71142) > > > has just been submitted w/ the "static void" fix. > > > > > > PS : the vidcontrol "showing the mouse: Invalid argument" > > > error message has not been fixed, yet. > > > > > > Cyrille Lefevre. > > > > It works great! One exception - I'm using green_saver and it doesn't > > blank the screen anymore. The text stays where it is on the screen and > > the cursor disappears. When I hit a key, the console responds by > > blanking for a second, then back to normal operation. > > Yes it works for me in 1400x1050, great ! > As for another vgl applications - there is problem, after app exit > screen locked in some video mode and then can't be switched to any mode > by vidcontrol or X (X do not show anything). And one more minor issue - DDB interface pager do not use real console window rows number and as result you need press space four times to get one sceen of ps listing. But it is real minor issue. It is really great to see DDB ps without wraparounds and with almost all processes on one screen. -- Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 10:50:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E59A16A4CE; Tue, 31 Aug 2004 10:50:35 +0000 (GMT) Received: from mail.broadpark.no (mail.broadpark.no [217.13.4.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9336643D1D; Tue, 31 Aug 2004 10:50:32 +0000 (GMT) (envelope-from des@des.no) Received: from dwp.des.no (37.80-203-228.nextgentel.com [80.203.228.37]) by mail.broadpark.no (Postfix) with ESMTP id 147AE2C88; Tue, 31 Aug 2004 12:51:10 +0200 (MEST) Received: by dwp.des.no (Postfix, from userid 2602) id 79E67B874; Tue, 31 Aug 2004 12:50:31 +0200 (CEST) To: Maxim Sobolev References: <4133683A.3090201@portaone.com> <4134530C.6020309@portaone.com> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Tue, 31 Aug 2004 12:50:31 +0200 In-Reply-To: <4134530C.6020309@portaone.com> (Maxim Sobolev's message of "Tue, 31 Aug 2004 13:29:32 +0300") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable cc: current@freebsd.org cc: sos@freebsd.org Subject: Re: burncd(8) usability: why `-s max' isn't default? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 10:50:35 -0000 Maxim Sobolev writes: > Dag-Erling Sm=F8rgrav wrote: > > Maxim Sobolev writes: > > > I wonder if there are any compelling reasons why `-s max' is not > > > default behaviour of burncd(8). IMHO, there is no point to have > > > default of 4. Usually, today's drives are smart enough to select the > > > maximum speed supported both by drive and by the medium. > > Plenty of drives aren't, especially with cheap media. > Do you have any evidence? Yes. My laptop's DVD/CD-RW drive (Hitachi something-or-other) turns out coasters if I try to use -s max with no-brand CD-R media. > You will have big problems finding any CD-R media (even very > cheap one) with rating < 32 on the market today, so that chances to > "overspeed" the media with those ancient burners are quite theoretical. What planet do you live on? Back here on Earth, the most widely available CD-R media is 16x or 24x, and prices rise steeply once you cross that boundary. For CD-RW media, that boundary is even lower (8x or 12x). DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 10:59:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C054516A4CE; Tue, 31 Aug 2004 10:59:59 +0000 (GMT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DA5043D55; Tue, 31 Aug 2004 10:59:58 +0000 (GMT) (envelope-from kappa@rambler-co.ru) Received: from capella.park.rambler.ru ([81.19.65.30]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id i7VAxtir073016; Tue, 31 Aug 2004 14:59:55 +0400 (MSD) (envelope-from kappa@rambler-co.ru) Received: by capella.park.rambler.ru (Postfix, from userid 1001) id DB1214382; Tue, 31 Aug 2004 14:59:55 +0400 (MSD) Date: Tue, 31 Aug 2004 14:59:55 +0400 From: Alex Kapranoff To: Maxim Sobolev Message-ID: <20040831105955.GA73813@capella.park.rambler.ru> References: <4133683A.3090201@portaone.com> <4134530C.6020309@portaone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4134530C.6020309@portaone.com> X-Operating-System: FreeBSD 5.3-ALPHA i386 Organization: Inner Mongolia User-Agent: Mutt/1.5.6i X-DCC-RAMBLER-Metrics: park.rambler.ru 32700; Body=4 Fuz1=4 Fuz2=4 cc: Dag-Erling =?koi8-r?Q?Sm=F8rgrav?= cc: current@freebsd.org cc: sos@freebsd.org Subject: Re: burncd(8) usability: why `-s max' isn't default? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 10:59:59 -0000 * Maxim Sobolev [August 31 2004, 14:29]: > >>I wonder if there are any compelling reasons why `-s max' is not > >>default behaviour of burncd(8). IMHO, there is no point to have > >>default of 4. Usually, today's drives are smart enough to select the > >>maximum speed supported both by drive and by the medium. > >Plenty of drives aren't, especially with cheap media. > > Do you have any evidence? Most of the Audio CDs, e.g., written in -s max mode on relatively high-speed burners fail to read in most customer cd players. I always burn audio on 4x and data on 8x regardless of burner hardware and media just because too many old readers refuse to read discs written on higher speeds. My own good old 12x cd-drive in dell lattitude c600 laptop does not (reliably) read anything written on >8x. I tried modern Mitsumi 52x and Teac 48x burners with the most expensive Verbatim and TDK CD-R blanks. > Granted, some very old burners may not be able to correctly read and > understand this data, but for the same age reason those drives are not > likely to be able to write at more than 8x anyway (most likely even 4x). > You will have big problems finding any CD-R media (even very cheap one) > with rating < 32 on the market today, so that chances to "overspeed" the > media with those ancient burners are quite theoretical. I think the problem is not in old burners and bad CD-Rs but in old readers which will just fail to read those discs. Anyway, I always use the '-s' option and new default value won't bite me :) -- Alex Kapranoff. From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 11:11:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 961C616A4CE for ; Tue, 31 Aug 2004 11:11:30 +0000 (GMT) Received: from encontacto.net (dsl-200-95-35-64.prod-infinitum.com.mx [200.95.35.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id E49BD43D4C for ; Tue, 31 Aug 2004 11:11:29 +0000 (GMT) (envelope-from eculp@encontacto.net) Received: from localhost (localhost [127.0.0.1]) (uid 80) by encontacto.net with local; Tue, 31 Aug 2004 06:11:29 -0500 Received: from dsl-200-95-35-64.prod-infinitum.com.mx (dsl-200-95-35-64.prod-infinitum.com.mx [200.95.35.64]) by mail.encontacto.net (Horde) with HTTP for ; Tue, 31 Aug 2004 06:11:28 -0500 Message-ID: <20040831061128.skwogkc8kw0ksoss@mail.encontacto.net> Date: Tue, 31 Aug 2004 06:11:28 -0500 From: Edwin Culp To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) 4.0-cvs X-Originating-IP: 200.95.35.64 Subject: /coda/coda_fbsd.c:215: error: `NVCODA' undeclared when building kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 11:11:30 -0000 This may already be fixed but building kernel with this morning's sources seemed to break in module/coda, cc -O -pipe -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /usr/obj/usr/src/sys/ENCONTACTO/opt_global.h -I. -I@ -I@/contrib/altq -I@/../inc lude -finline-limit=8000 -fno-common -I/usr/obj/usr/src/sys/ENCONTACTO -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding - Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions - std=c99 -c /usr/src/sys/modules/coda/../../coda/coda_fbsd.c /usr/src/sys/modules/coda/../../coda/coda_fbsd.c: In function `coda_fbsd_drvinit': /usr/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: `NVCODA' undeclared (first use in this function) /usr/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: (Each undeclared identifier is reported only once /usr/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: for each function it appears in.) /usr/src/sys/modules/coda/../../coda/coda_fbsd.c: In function `coda_fbsd_drvuninit': /usr/src/sys/modules/coda/../../coda/coda_fbsd.c:215: error: `NVCODA' undeclared (first use in this function) *** Error code 1 Stop in /usr/src/sys/modules/coda. *** Error code 1 From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 11:18:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F168E16A4CE for ; Tue, 31 Aug 2004 11:18:43 +0000 (GMT) Received: from av6-1-sn2.hy.skanova.net (av6-1-sn2.hy.skanova.net [81.228.8.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49D1343D5E for ; Tue, 31 Aug 2004 11:18:43 +0000 (GMT) (envelope-from ertr1013@student.uu.se) Received: by av6-1-sn2.hy.skanova.net (Postfix, from userid 502) id E38FC37E4B; Tue, 31 Aug 2004 13:18:41 +0200 (CEST) Received: from smtp2-1-sn2.hy.skanova.net (smtp2-1-sn2.hy.skanova.net [81.228.8.177]) by av6-1-sn2.hy.skanova.net (Postfix) with ESMTP id D047437E4A for ; Tue, 31 Aug 2004 13:18:41 +0200 (CEST) Received: from falcon.midgard.homeip.net (h201n1fls24o1048.bredband.comhem.se [212.181.162.201]) by smtp2-1-sn2.hy.skanova.net (Postfix) with SMTP id 838E137E49 for ; Tue, 31 Aug 2004 13:18:41 +0200 (CEST) Received: (qmail 74539 invoked by uid 1001); 31 Aug 2004 11:18:40 -0000 Date: Tue, 31 Aug 2004 13:18:40 +0200 From: Erik Trulsson To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20040831111840.GA74510@falcon.midgard.homeip.net> Mail-Followup-To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , Maxim Sobolev , current@freebsd.org, sos@freebsd.org References: <4133683A.3090201@portaone.com> <4134530C.6020309@portaone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: User-Agent: Mutt/1.5.6i cc: Maxim Sobolev cc: current@freebsd.org cc: sos@freebsd.org Subject: Re: burncd(8) usability: why `-s max' isn't default? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 11:18:44 -0000 On Tue, Aug 31, 2004 at 12:50:31PM +0200, Dag-Erling Sm=F8rgrav wrote: > Maxim Sobolev writes: > > Dag-Erling Sm=F8rgrav wrote: > > > Maxim Sobolev writes: > > > > I wonder if there are any compelling reasons why `-s max' is not > > > > default behaviour of burncd(8). IMHO, there is no point to have > > > > default of 4. Usually, today's drives are smart enough to select the > > > > maximum speed supported both by drive and by the medium. > > > Plenty of drives aren't, especially with cheap media. > > Do you have any evidence? >=20 > Yes. My laptop's DVD/CD-RW drive (Hitachi something-or-other) turns > out coasters if I try to use -s max with no-brand CD-R media. >=20 > > You will have big problems finding any CD-R media (even very > > cheap one) with rating < 32 on the market today, so that chances to > > "overspeed" the media with those ancient burners are quite theoretical. >=20 > What planet do you live on? Back here on Earth, the most widely > available CD-R media is 16x or 24x, and prices rise steeply once you > cross that boundary. For CD-RW media, that boundary is even lower (8x > or 12x). He probably lives on the same planet as I, while you seem to live on some alternate Earth. =20 Around here the most widely available CD-R media is labelled as 48x, and you do have to look around a bit to find slower media (and CD-R media slower than 24x is almost impossible to find), and the slower media is usually not noticably cheaper anyway.=20 For CD-RW media it is true that most widely available media seem to be in the 4x-10x range, but again the faster ones (labelled as 24x or 32x) tends to be only slightly more expensive than the slower ones. --=20 Erik Trulsson ertr1013@student.uu.se From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 11:49:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DE1A16A4CE; Tue, 31 Aug 2004 11:49:48 +0000 (GMT) Received: from smtp3b.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3CE643D60; Tue, 31 Aug 2004 11:49:45 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smtp3b.sentex.ca (8.13.1/8.13.1) with ESMTP id i7VBnjCi095164; Tue, 31 Aug 2004 07:49:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7VBnjgv076947; Tue, 31 Aug 2004 07:49:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4E8397303F; Tue, 31 Aug 2004 07:49:45 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040831114945.4E8397303F@freebsd-current.sentex.ca> Date: Tue, 31 Aug 2004 07:49:45 -0400 (EDT) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 11:49:48 -0000 TB --- 2004-08-31 10:31:40 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-31 10:31:40 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-08-31 10:31:40 - checking out the source tree TB --- 2004-08-31 10:31:40 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2004-08-31 10:31:40 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-31 10:36:49 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-31 10:36:49 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-08-31 10:36:49 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-31 11:40:59 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-31 11:40:59 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-08-31 11:40:59 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Aug 31 11:40:59 UTC 2004 >>> 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 [...] ===> coda cc -O2 -pipe -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -g -fno-omit-frame-pointer -I/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/GENERIC -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /tinderbox/CURRENT/amd64/amd64/src/sys/modules/coda/../../coda/coda_fbsd.c /tinderbox/CURRENT/amd64/amd64/src/sys/modules/coda/../../coda/coda_fbsd.c: In function `coda_fbsd_drvinit': /tinderbox/CURRENT/amd64/amd64/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: `NVCODA' undeclared (first use in this function) /tinderbox/CURRENT/amd64/amd64/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/amd64/amd64/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: for each function it appears in.) /tinderbox/CURRENT/amd64/amd64/src/sys/modules/coda/../../coda/coda_fbsd.c: In function `coda_fbsd_drvuninit': /tinderbox/CURRENT/amd64/amd64/src/sys/modules/coda/../../coda/coda_fbsd.c:215: error: `NVCODA' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/sys/modules/coda. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-08-31 11:49:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-31 11:49:45 - ERROR: failed to build generic kernel TB --- 2004-08-31 11:49:45 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 11:50:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E05B16A4CE; Tue, 31 Aug 2004 11:50:09 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 800C743D2D; Tue, 31 Aug 2004 11:50:08 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [172.18.2.1] (csc-gw1.novi.dk [130.225.63.24]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i7VBo6OC010548; Tue, 31 Aug 2004 13:50:06 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <413465C4.9020800@DeepCore.dk> Date: Tue, 31 Aug 2004 13:49:24 +0200 From: =?UTF-8?B?U8O4cmVuIFNjaG1pZHQ=?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Maxim Sobolev References: <4133683A.3090201@portaone.com> <4134530C.6020309@portaone.com> In-Reply-To: <4134530C.6020309@portaone.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable cc: =?UTF-8?B?RGFnLUVybGluZyBTbdCscmdyYXY=?= cc: current@FreeBSD.ORG cc: sos@FreeBSD.ORG Subject: Re: burncd(8) usability: why `-s max' isn't default? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 11:50:09 -0000 Maxim Sobolev wrote: > Dag-Erling Sm=C3=83=C2=B8rgrav wrote: >=20 >> Maxim Sobolev writes: >> >>> I wonder if there are any compelling reasons why `-s max' is not >>> default behaviour of burncd(8). IMHO, there is no point to have >>> default of 4. Usually, today's drives are smart enough to select the >>> maximum speed supported both by drive and by the medium. >> >> Plenty of drives aren't, especially with cheap media. >=20 > Do you have any evidence? >=20 > I know what I am talking about. We are working on the mass-product base= d=20 > on FreeBSD. This product will have to burn data CDs. We have tried=20 > compatibility of various media with `-s max', including very cheap ones= =20 > and have never seen any corruption due to speed mismatch. Virtually all= =20 > media available on the market today has a special track, which records = > its speed rating and manufacturer. If you know what you are talking about, and is in the process of making a= FreeBSD product, I'm sure you also know how to patch FreeBSD to do what you want for that product. For the "free" version of FreeBSD I'd prefer we stick to what we have, th= ere are way too many crappy burners/media out there that will produce bad res= ults, and that translates into mails in my inbox with complaints that I can eas= ily live without.... -S=C3=B8ren From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 15:28:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26CDF16A4CE; Mon, 30 Aug 2004 15:28:52 +0000 (GMT) Received: from rt0-ext.kdcg.net (rt0-ext.kdcg.net [81.2.114.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id E3D6243D2F; Mon, 30 Aug 2004 15:28:50 +0000 (GMT) (envelope-from cg@ijcg.net) Received: from localhost (localhost [127.0.0.1]) by rt0-ext.kdcg.net (Postfix) with ESMTP id BF41E4AB901D; Mon, 30 Aug 2004 16:31:27 +0100 (BST) Received: from rt0-ext.kdcg.net ([127.0.0.1]) by localhost (alexandria.rings [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 48510-06; Mon, 30 Aug 2004 16:31:26 +0100 (BST) Received: from tacitblue3.rings (tacitblue.rings [10.1.0.2]) by rt0-ext.kdcg.net (Postfix) with ESMTP id A75EC4AB9018; Mon, 30 Aug 2004 16:31:26 +0100 (BST) Date: Mon, 30 Aug 2004 16:28:52 +0100 From: cg To: "Ruslan Ermilov" , "Mathew Kanner" References: <20040828142503.GA52613@ip.net.ua> <20040829190833.GA9796@cnd.mcgill.ca> <20040829205942.GC39813@ip.net.ua> Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-15 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20040829205942.GC39813@ip.net.ua> User-Agent: Opera M2/7.54 (Win32, build 3869) X-Virus-Scanned: by amavisd-new at badexample.com X-Mailman-Approved-At: Tue, 31 Aug 2004 11:58:53 +0000 cc: Cameron Grant cc: multimedia@freebsd.org cc: "Simon L. Nielsen" cc: Seigo Tanimura cc: current@freebsd.org Subject: Re: [PATCH] sound(4) related manpages 5.3 TODO item X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 15:28:52 -0000 On Sun, 29 Aug 2004 23:59:42 +0300, Ruslan Ermilov wrote: > I wish there would be more consistency in naming. Previously, > we had the csa(4) manpage, "device csa", and /dev/csa* entries. > Now we will have the snd_csa(4) manpage, "device snd_csa", but > still /dev/csaX entry. > > Also, in the old world, "midi" devices were created as children > of "pcm" devices, so "hint.pcm.0" hints for non-PnP ISA devices > looked correct. In new world with your updated midi(4), what > will be the hints for the ISA device that implements PCM and > MIDI? hint.pcm.0 and hint.midi.0? the intention behind the renaming was to simplify the naming scheme, and to glue pcm and midi together such that card drivers didn't have to separate out their pcm, midi and independant code. if you look at any of the current card drivers, you'll find that they make several calls into the pcm code. those supporting midi, likewise, call into midi code. having midi and pcm as seperate devices gives the impression that they're independant, but if we allowed that to be the case the drivers would have to become far more complex. ie, they each would require a separate module for their pcm, midi and general parts because if say, only midi was compiled into the kernel then the pcm code in the drivers would fail to link. likewise, drivers supporting midi would fail to link if only pcm was present. for modules, this problem can be solved with dependancies, but the only solution for a static kernel would be to declare that if you wish to compile a driver that supports pac and midi, both device pcm and device midi must be specified. rather than leave the situation that way, we elected to combine the pcm and midi devices into one, so the card drivers could assume both were present. renaming the card modules is a different story, and although i was in favour of it, i now feel it wasn't such a good idea in its current form. because pcm is just a framework rather than an actual device from the kernel's point of view, the driver name would show up in dmesg etc as snd_emu10k1 or whatever. while that in itself wouldn't cause a problem, it would result in each driver using a different devclass - and there are some fairly fundamental assumptions in the pcm code that is designed around being able to translate a unit number to a device_t. if the drivers were changed to register as snd_* rather than pcm, but remain sharing their devclass, there would be interesting results: either all sound devices would show up with the name of the one that attached first (eg an ich and emu10k1 as snd_ich0 and snd_ich1) or the unit numbers would be shared across devices (eg, snd_ich0, snd_maestro1, snd_cmi2...) both of those possible outcomes would be worse than the current situation, in my opinion. what we can - and should - do is rename the "pcm" devclass to "sound". this would make sound devices show up as sound0 etc, and make the hints/sysctls be hw.sound0.*. we also need to make sure that the sound.ko module contains both pcm and midi. it might be nice to have a meta device called sound_all which pulled in all the drivers plus the pcm and midi code, and a corresponding kld. i wonder if we still have the opportunity to rename snd* to sound*? or possibly sound to snd which would mesh better with /dev/sndstat. > ;) All is so plain in the old good 4.x world: heh. -cg From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 15:39:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D7D916A4CE for ; Mon, 30 Aug 2004 15:39:36 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6791243D5E for ; Mon, 30 Aug 2004 15:39:35 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1C1oFq-0000uZ-7S; Mon, 30 Aug 2004 19:39:34 +0400 From: Vladimir Grebenschikov To: takawata@jp.freebsd.org In-Reply-To: <200408301458.i7UEweiu045002@sana.init-main.com> References: <200408301458.i7UEweiu045002@sana.init-main.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Mon, 30 Aug 2004 19:39:33 +0400 Message-Id: <1093880373.3257.6.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.93FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov X-Mailman-Approved-At: Tue, 31 Aug 2004 11:58:53 +0000 cc: freebsd-current@freebsd.org Subject: Re: acpi_video on SONY VAIO PCG-Z1 [was: acpi_video users needed] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 15:39:36 -0000 On Mon, 2004-08-30 at 23:58 +0900, takawata@jp.freebsd.org wrote: > >Hi > > > >Is any chance to make acpi_video work on SONY VAIO PCG-Z1 ? > >acpi_video.ko loads well, but does not report anything, and does not add > >hw.acpi.video subtree. > > > >Please advise. > > Because the ACPI device object has not enough interfaces to get the > acpi_video driver work. > Acpi_video driver does not check PCI device class: it checks the > interfaces instead. > You don't need to bother attaching acpi_video driver. Ok, And what conclusion "no-way" ? > ###### > > > Device (VID0) > { > Name (_ADR, 0x00) > OperationRegion (VIDR, PCI_Config, 0x4C, 0x04) > Field (VIDR, ByteAcc, NoLock, Preserve) > { > SSID, 32 > } > > Device (CRT) > { > Name (_ADR, 0x0100) > } > > Device (LCD) > { > Name (_ADR, 0x0110) > } > > Device (TV) > { > Name (_ADR, 0x0200) > } > } > } > > ##### > _______________________________________________ > 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" -- Vladimir B. Grebenschikov SWsoft Inc. vova@sw-soft.com From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 16:24:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7030D16A4CE for ; Mon, 30 Aug 2004 16:24:50 +0000 (GMT) Received: from boromir.vpop.net (dns1.vpop.net [207.178.248.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CFD143D54 for ; Mon, 30 Aug 2004 16:24:50 +0000 (GMT) (envelope-from mreimer@vpop.net) Received: from [70.56.77.194] (unknown [70.56.77.194]) by boromir.vpop.net (Postfix) with ESMTP id 7061E3A5E05; Mon, 30 Aug 2004 09:24:48 -0700 (PDT) Message-ID: <413354D5.1040308@vpop.net> Date: Mon, 30 Aug 2004 09:24:53 -0700 From: Matthew Reimer User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040816) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 31 Aug 2004 11:58:53 +0000 Subject: Re: wscons from NetBSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 16:24:50 -0000 Anish Mistry wrote: > =2D----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'm in the process of trying to update a bunch of the USB HID code to be ba= > ck=20 > in sync with NetBSD since there are numerous problems with our current code= > =20 > that have been fixed for a couple of years now in the NetBSD code. The maj= > or=20 > problem that I'm running into is their dependency on wscons for a few of th= > e=20 > drivers. Has there been any work on porting wscons to FreeBSD? It would=20 > make this import much easier and make future imports much simpler too. > =2D --=20 > Anish Mistry Are you also planning to bring over uhidev, so our USB keyboards with the nifty extra keys will work? Matt From owner-freebsd-current@FreeBSD.ORG Mon Aug 30 19:23:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 260BF16A4CE for ; Mon, 30 Aug 2004 19:23:32 +0000 (GMT) Received: from linwhf.opal.com (102.79.171.66.subscriber.vzavenue.net [66.171.79.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7364E43D53 for ; Mon, 30 Aug 2004 19:23:31 +0000 (GMT) (envelope-from jr@opal.com) Received: (jr@localhost) by linwhf.opal.com (8.12.11/jr6.1/Submit) for id i7UJMOcf001323; Mon, 30 Aug 2004 15:22:24 -0400 (EDT) Date: Mon, 30 Aug 2004 15:22:24 -0400 From: "J.R. Oldroyd" To: =?iso-8859-1?Q?S=F8ren?= Schmidt Message-ID: <20040830192224.GB809@linwhf.opal.com> References: <412F5A10.8080907@drexel.edu> <412F7292.6000804@DeepCore.dk> <20040830181540.GA809@linwhf.opal.com> <413372B3.5010603@DeepCore.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <413372B3.5010603@DeepCore.dk> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Tue, 31 Aug 2004 11:58:53 +0000 cc: "J.R. Oldroyd" cc: current@freebsd.org Subject: Re: Current 8/27/2004, DVD problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 30 Aug 2004 19:23:32 -0000 Well, I am not sure what was going on when I typed that, but I had just cvsup'd the latest -current, so what I had meant to type was that it was the current of today, 2004/08/30 at 13:30 GMT. -jr On Aug 30, 20:32, Søren Schmidt wrote: > J.R. Oldroyd wrote: > >Still not working here, I'm afraid. > > > >Mine's the NEC DVD which reports on the 5.2.1 generic kernel as: > > > >acd0: DVDR <_NEC DVD_RW ND-1300A> at ata1-slave PIO4 > > > >But I just tried the -current as of 2004/08/04 13:30 GMT and it > >still doesn't boot beyond the probe of the ata devices. Boot with > >the DVD unplugged and I get: > > Hmm, is this current of 2004/08/04 or 2004/08/27 ? > > Anyhow there was some critical update on the 27'th, so you should make > certain you have the absolute latest from -current. > > -Søren > From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 08:00:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79C9416A4CF for ; Tue, 31 Aug 2004 08:00:26 +0000 (GMT) Received: from ithil.ics.muni.cz (ithil.ics.muni.cz [147.251.4.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4CF843D53 for ; Tue, 31 Aug 2004 08:00:25 +0000 (GMT) (envelope-from hopet@ics.muni.cz) Received: from KLOBOUCEK (kloboucek.ics.muni.cz [147.251.3.38]) (user=hopet@META mech=LOGIN bits=0) by ithil.ics.muni.cz (8.12.1/8.12.1) with ESMTP id i7V80NAb010663 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 31 Aug 2004 10:00:23 +0200 From: "Petr Holub" To: Date: Tue, 31 Aug 2004 10:00:12 +0200 Message-ID: <07d201c48f30$8b2f46b0$02e86cc2@KLOBOUCEK> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Muni-Spam-TestIP: 147.251.3.38 X-Muni-Virus-Test: Clean X-Mailman-Approved-At: Tue, 31 Aug 2004 11:58:53 +0000 Subject: drm: ATI FireGL Mobility T2 patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 08:00:26 -0000 Hi, here's a short patch to make drm recognize ATI FireGL Mobility T2 card present in IBM T41p notebook. Petr ================================================================ Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 4 Institute of Compt. Science 162 00 Praha 6, CZ Masaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: Petr.Holub@cesnet.cz phone: +420-549493944 fax: +420-541212747 e-mail: hopet@ics.muni.cz --- sys/dev/drm/radeon.h.bak Mon Aug 30 15:22:05 2004 +++ sys/dev/drm/radeon.h Mon Aug 30 15:23:46 2004 @@ -129,6 +129,7 @@ {0x1002, 0x4C65, 0, "ATI Radeon Le R250 Mobility 9000 M9"}, \ {0x1002, 0x4C66, 0, "ATI Radeon Lf R250 Mobility 9000 M9"}, \ {0x1002, 0x4C67, 0, "ATI Radeon Lg R250 Mobility 9000 M9"}, \ + {0x1002, 0x4E54, 0, "ATI FireGL Mobility T2 M10 NT"}, \ {0x1002, 0x5144, 0, "ATI Radeon QD R100"}, \ {0x1002, 0x5145, 0, "ATI Radeon QE R100"}, \ {0x1002, 0x5146, 0, "ATI Radeon QF R100"}, \ From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 08:44:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 091A516A4D1 for ; Tue, 31 Aug 2004 08:44:31 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FE7D43D2F for ; Tue, 31 Aug 2004 08:44:30 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1C24Ff-0002xw-Pq; Tue, 31 Aug 2004 12:44:27 +0400 From: Vladimir Grebenschikov To: takawata@jp.freebsd.org In-Reply-To: <200408310502.OAA20287@axe-inc.co.jp> References: <200408310502.OAA20287@axe-inc.co.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Tue, 31 Aug 2004 12:44:27 +0400 Message-Id: <1093941867.29903.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.93FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov X-Mailman-Approved-At: Tue, 31 Aug 2004 11:58:53 +0000 cc: "current@freebsd.org" Subject: Re: acpi_video on SONY VAIO PCG-Z1 [was: acpi_video users needed] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 08:44:31 -0000 On Tue, 2004-08-31 at 14:02 +0900, takawata@jp.freebsd.org wrote: > In message <1093891970.1195.25.camel@localhost>, Vladimir Grebenschikov wrote: > >On Tue, 2004-08-31 at 03:31 +0900, takawata@jp.freebsd.org wrote: > > > >> >> >Is any chance to make acpi_video work on SONY VAIO PCG-Z1 ? > >> >> >acpi_video.ko loads well, but does not report anything, and does not add > >> >> >hw.acpi.video subtree. > >> >> > > >> >> >Please advise. > >> >> > >> >> Because the ACPI device object has not enough interfaces to get the > >> >> acpi_video driver work. > >> >> Acpi_video driver does not check PCI device class: it checks the > >> >> interfaces instead. > >> >> You don't need to bother attaching acpi_video driver. > >> > > >> >Ok, And what conclusion "no-way" ? > >> > >> You may hack the driver to do so.:-) > > > >Oh ... first i need to hack WinXP driver to find how to control LCD > >brightniness. > > > >> But, in your machine, the driver does not work anything but > >> recognize that the video adaptor has 3 way output. And > >> you can't use acpi_video, if you want to use DRM or nvidia kernel module. > > > >I have ATI RADEON MOBILITY, so no need nvidia module. > > > >Can you provide me a bit of theory ? > > > >Who usual responsible for LCD bacllight control ? > > video-chip(ATI) / chipset(Intel) / special device on bus ? > > It seems to be controlled by Special device on bus called embedded controller. > You can use it with setbrightness in ports/sysutils/sjog or > ports/graphics/picturebook. But these tools are a bit dangerous because > it will conflict with ACPI(These tools are based on disassembled AML before > ACPI support is not populler in free unicies.) > . > I just wrote a driver for it. I hope it will help you. > http://www.init-main.com/acpi_snc.tar.gz Yes, it works, now I can control LCD backlight brightness. $ setbrightness 50 $ setbrightness 255 # sysctl dev.acpi_snc dev.acpi_snc.0.%desc: Sony system controller dev.acpi_snc.0.%driver: acpi_snc dev.acpi_snc.0.%location: handle=\_SB_.PCI0.LPCB.SNC_ dev.acpi_snc.0.%pnpinfo: _HID=SNY5001 _UID=0 dev.acpi_snc.0.%parent: acpi0 dev.acpi_snc.0.brightness: 60 # Now only issue I am warry about "How to awake screen after suspend ?" -- Vladimir B. Grebenschikov SWsoft Inc. vova@sw-soft.com From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 09:05:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 836F416A4CE for ; Tue, 31 Aug 2004 09:05:46 +0000 (GMT) Received: from hotmail.com (bay5-f12.bay5.hotmail.com [65.54.173.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7262643D5D for ; Tue, 31 Aug 2004 09:05:46 +0000 (GMT) (envelope-from cell_46@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 02:05:46 -0700 Received: from 62.212.121.38 by by5fd.bay5.hotmail.msn.com with HTTP; Tue, 31 Aug 2004 09:05:45 GMT X-Originating-IP: [62.212.121.38] X-Originating-Email: [cell_46@msn.com] X-Sender: cell_46@msn.com From: "splinter cell" To: freebsd-current@freebsd.org Date: Tue, 31 Aug 2004 11:05:45 +0200 Message-ID: X-OriginalArrivalTime: 31 Aug 2004 09:05:46.0279 (UTC) FILETIME=[B3A0E370:01C48F39] X-Mailman-Approved-At: Tue, 31 Aug 2004 12:12:22 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 09:05:46 -0000 Hello , my kernel has crashed because i have nad lines in my loader.conf : netgraph_load="YES" if_tap_load="YES" ng_ether_load="YES" ng_bridge_load="YES" ng_socket_load="YES" and i don't how to delete this lines because i am on ddb now.The message of the panic : panic: mutex "tapmtx" 0x0a27d80 already initialised.Anyone have a solution for delete this lines in my /boot/loader.conf ? _________________________________________________________________ Trouvez l'âme soeur sur MSN Rencontres. [1]Cliquez-ici References 1. http://g.msn.com/8HMBFRFR/2746??PS=47575 From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 12:05:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F311016A4CE; Tue, 31 Aug 2004 12:05:39 +0000 (GMT) Received: from mail09.syd.optusnet.com.au (mail09.syd.optusnet.com.au [211.29.132.190]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D41F43D45; Tue, 31 Aug 2004 12:05:38 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) i7VC5UZJ020320 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 31 Aug 2004 22:05:31 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])i7VC5TxP058818; Tue, 31 Aug 2004 22:05:30 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)i7VC5TgM058817; Tue, 31 Aug 2004 22:05:29 +1000 (EST) (envelope-from pjeremy) Date: Tue, 31 Aug 2004 22:05:29 +1000 From: Peter Jeremy To: Wilko Bulte Message-ID: <20040831120529.GB58440@cirb503493.alcatel.com.au> References: <20040829151021.GA43674@bobbi.cse.buffalo.edu> <20040830191325.GA53006@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040830191325.GA53006@freebie.xs4all.nl> User-Agent: Mutt/1.4.2i cc: freebsd-current@freebsd.org cc: freebsd-alpha@freebsd.org Subject: Re: Addendum: FreeBSD 5.3-BETA2 for Alpha/AXP Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 12:05:40 -0000 On Mon, 2004-Aug-30 21:13:25 +0200, Wilko Bulte wrote: >FreeBSD 5.3-BETA2 for the Alpha architecture: disk2 boots and seems to run on my AS400 4/233. Some slight glitches: 1) tl0: port 0x10180-0x1018f irq 9 at device 12.0 on pci0 reports "tl0: adapter check: 100007" when I do an ifconfig up, though the interface works OK. 2) Running fsck reports: Fixit# fsck /dev/da0[ade] fstab: /etc/fstab:0: No such file or directory fstab: /etc/fstab:0: No such file or directory fsck: exec fsck_4.2bsd for /dev/da0a in /sbin:/usr/sbin: No such file or directory fstab: /etc/fstab:0: No such file or directory fstab: /etc/fstab:0: No such file or directory fsck: exec fsck_4.2bsd for /dev/da0d in /sbin:/usr/sbin: No such file or directory fstab: /etc/fstab:0: No such file or directory fstab: /etc/fstab:0: No such file or directory fsck: exec fsck_4.2bsd for /dev/da0e in /sbin:/usr/sbin: No such file or directory Explicitly using fsck_ffs works OK. 3) "mount 192.168.123.200:/back /mnt" reports: boot_crunch: nfs not compiled in usage: boot_crunch ..., where is one of: hostname pwd rm sh -sh test [ cpio dhclient fsck_ffs ifconfig mount_nfs newfs route rtsol slattach tunefs camcontrol find minigzip gzip gunzip zcat sed arp ppp sysinstall usbd usbdevs boot_crunch Fixit# Again, using /sbin/mount_nfs works OK. I've installed 5.3-BETA2 from the miniinst CD and it seems to be running nicely. I've left it doing a buildworld with /usr/{src,obj} mounted via NFS (due to lack of local diskspace). I don't expect it to finish for a while and will report back if there are problems. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 12:16:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9889016A4CF; Tue, 31 Aug 2004 12:16:40 +0000 (GMT) Received: from web.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBDE943D4C; Tue, 31 Aug 2004 12:16:39 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.20] (portacare.portaone.com [195.140.247.242]) (authenticated bits=0) by web.portaone.com (8.12.8p2/8.12.8) with ESMTP id i7VCGXPR073504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Aug 2004 14:16:35 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <41346C0F.5010109@portaone.com> Date: Tue, 31 Aug 2004 15:16:15 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?UTF-8?B?U8O4cmVuIFNjaG1pZHQ=?= References: <4133683A.3090201@portaone.com> <4134530C.6020309@portaone.com> <413465C4.9020800@DeepCore.dk> In-Reply-To: <413465C4.9020800@DeepCore.dk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit cc: =?UTF-8?B?RGFnLUVybGluZyBTbdCscmdyYXY=?= cc: current@FreeBSD.ORG cc: sos@FreeBSD.ORG Subject: Re: burncd(8) usability: why `-s max' isn't default? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 12:16:40 -0000 SÞren Schmidt wrote: > Maxim Sobolev wrote: > >> Dag-Erling SmÞrgrav wrote: >> >>> Maxim Sobolev writes: >>> >>>> I wonder if there are any compelling reasons why `-s max' is not >>>> default behaviour of burncd(8). IMHO, there is no point to have >>>> default of 4. Usually, today's drives are smart enough to select the >>>> maximum speed supported both by drive and by the medium. >>> >>> >>> Plenty of drives aren't, especially with cheap media. >> >> >> Do you have any evidence? >> >> I know what I am talking about. We are working on the mass-product >> based on FreeBSD. This product will have to burn data CDs. We have >> tried compatibility of various media with `-s max', including very >> cheap ones and have never seen any corruption due to speed mismatch. >> Virtually all media available on the market today has a special track, >> which records its speed rating and manufacturer. > > > If you know what you are talking about, and is in the process of making a > FreeBSD product, I'm sure you also know how to patch FreeBSD to do what > you want for that product. Yes, I know how to do it, but it is not the topic of this discussion. Apart from my commercial activity, I am running quite large FreeBSD user group in my country, so that improving OOB FreeBSD useability concerns me. > For the "free" version of FreeBSD I'd prefer we stick to what we have, > there > are way too many crappy burners/media out there that will produce bad > results, > and that translates into mails in my inbox with complaints that I can > easily > live without.... Few of my friends were quite surprised when I've told them about '-s max' option and how useful it is. I wonder how many FreeBSD users out there don't know about it as well and wonder why FreeBSD is so slow when burning at their brand-new zillon-speed CD-RW drive. BTW, maybe it would be better to add logic to read media's max speed into burncd/atapicd and throttle burning accordingly? For example with cdrdao(8) it is possible to do something like the following using atapicam: -bash-2.05b$ sudo cdrdao disk-info -v 0 --device 1,0,0 --driver generic-mmc | grep ^Reco Recording Speed : 0X - 8X -bash-2.05b$ We've confirmed that it produces accurate results for all types and speeds we've been able to find on market. -Maxim From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 12:20:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FD7116A4CE for ; Tue, 31 Aug 2004 12:20:25 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B0DC43D2F for ; Tue, 31 Aug 2004 12:20:16 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7VCKBjQ091577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 31 Aug 2004 15:20:12 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i7VCKHRx032741 for current@freebsd.org; Tue, 31 Aug 2004 15:20:17 +0300 (EEST) (envelope-from ru) Date: Tue, 31 Aug 2004 15:20:17 +0300 From: Ruslan Ermilov To: current@freebsd.org Message-ID: <20040831122017.GC31981@ip.net.ua> References: <20040831091205.2AEAA7303F@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+pHx0qQiF2pBVqBT" Content-Disposition: inline In-Reply-To: <20040831091205.2AEAA7303F@freebsd-current.sentex.ca> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new Subject: [FIXED] Re: [current tinderbox] failure on */* X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 12:20:25 -0000 --+pHx0qQiF2pBVqBT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 31, 2004 at 05:12:05AM -0400, FreeBSD Tinderbox wrote: > [...] > =3D=3D=3D> coda > cc -O2 -pipe -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /tinderbox/= CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/s= ys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-li= mit=3D15000 -fno-common -g -I/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64= /tinderbox/CURRENT/sparc64/sparc64/src/sys/GENERIC -mcmodel=3Dmedlow -msoft= -float -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-pro= totypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fforma= t-extensions -std=3Dc99 -c /tinderbox/CURRENT/sparc64/sparc64/src/sys/modul= es/coda/../../coda/coda_fbsd.c > /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/coda/../../coda/coda_f= bsd.c: In function `coda_fbsd_drvinit': > /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/coda/../../coda/coda_f= bsd.c:205: error: `NVCODA' undeclared (first use in this function) > /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/coda/../../coda/coda_f= bsd.c:205: error: (Each undeclared identifier is reported only once > /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/coda/../../coda/coda_f= bsd.c:205: error: for each function it appears in.) > /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/coda/../../coda/coda_f= bsd.c: In function `coda_fbsd_drvuninit': > /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/coda/../../coda/coda_f= bsd.c:215: error: `NVCODA' undeclared (first use in this function) > *** Error code 1 >=20 > Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sys/modules/coda. > *** Error code 1 >=20 [...] > TB --- 2004-08-31 09:12:04 - WARNING: /usr/bin/make returned exit code 1= =20 > TB --- 2004-08-31 09:12:04 - ERROR: failed to build generic kernel > TB --- 2004-08-31 09:12:04 - tinderbox aborted >=20 I've just committed a fix to sys/modules/coda/Makefile. Peter probably just forgot to commit it. ;) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --+pHx0qQiF2pBVqBT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBNG0BqRfpzJluFF4RAgebAKCMXROyp16ecMpmyM5RN8FdbPOqOwCffZle EuZkDgk6v2KhTPsbwFnb124= =gsyf -----END PGP SIGNATURE----- --+pHx0qQiF2pBVqBT-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 12:31:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C618116A4CE; Tue, 31 Aug 2004 12:31:52 +0000 (GMT) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD16343D4C; Tue, 31 Aug 2004 12:31:51 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from midget.dons.net.au ([150.101.45.33])i7VCVgHY028407; Tue, 31 Aug 2004 22:01:44 +0930 (CST) Received: from inchoate.dons.net.au (root@localhost.dons.net.au [127.0.0.1]) by midget.dons.net.au (8.12.9/8.12.10) with ESMTP id i7VCVdn7089776; Tue, 31 Aug 2004 22:01:39 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Tue, 31 Aug 2004 22:01:30 +0930 User-Agent: KMail/1.6.2 References: <4133683A.3090201@portaone.com> <4134530C.6020309@portaone.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200408312201.38748.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.26 (www . roaringpenguin . com / mimedefang) cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= cc: Maxim Sobolev cc: current@freebsd.org cc: sos@freebsd.org Subject: Re: burncd(8) usability: why `-s max' isn't default? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 12:31:52 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 31 Aug 2004 20:20, Dag-Erling Sm=F8rgrav wrote: > > Do you have any evidence? > > Yes. My laptop's DVD/CD-RW drive (Hitachi something-or-other) turns > out coasters if I try to use -s max with no-brand CD-R media. Tried newer firmware? > > You will have big problems finding any CD-R media (even very > > cheap one) with rating < 32 on the market today, so that chances to > > "overspeed" the media with those ancient burners are quite theoretical. > > What planet do you live on? Back here on Earth, the most widely > available CD-R media is 16x or 24x, and prices rise steeply once you > cross that boundary. For CD-RW media, that boundary is even lower (8x > or 12x). The drive reads ATIP info from the disk to determine the maximum writable=20 speed (Among other useful things) Of course the media could be lying about the maximum speed it's rated for, = but=20 I haven't seen media like that. I buy Verbatim 48x spindles of 50 disks whi= ch=20 are fairly cheap but don't produce coasters. CD-RW media is slower but that's a function of the way CD-RW's are made and= =20 their smaller volume. =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 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBNG+q5ZPcIHs/zowRAgDcAJ9w+nrttfrdHDVT02CthdYUQwU3egCfahst gyZ7SDzrclqoXiOuJXEtTrg=3D =3DQb5/ =2D----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 12:31:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C618116A4CE; Tue, 31 Aug 2004 12:31:52 +0000 (GMT) Received: from smtp3.adl2.internode.on.net (smtp3.adl2.internode.on.net [203.16.214.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD16343D4C; Tue, 31 Aug 2004 12:31:51 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from midget.dons.net.au ([150.101.45.33])i7VCVgHY028407; Tue, 31 Aug 2004 22:01:44 +0930 (CST) Received: from inchoate.dons.net.au (root@localhost.dons.net.au [127.0.0.1]) by midget.dons.net.au (8.12.9/8.12.10) with ESMTP id i7VCVdn7089776; Tue, 31 Aug 2004 22:01:39 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Tue, 31 Aug 2004 22:01:30 +0930 User-Agent: KMail/1.6.2 References: <4133683A.3090201@portaone.com> <4134530C.6020309@portaone.com> In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200408312201.38748.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.26 (www . roaringpenguin . com / mimedefang) cc: Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?= cc: Maxim Sobolev cc: current@freebsd.org cc: sos@freebsd.org Subject: Re: burncd(8) usability: why `-s max' isn't default? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 12:31:53 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 31 Aug 2004 20:20, Dag-Erling Sm=F8rgrav wrote: > > Do you have any evidence? > > Yes. My laptop's DVD/CD-RW drive (Hitachi something-or-other) turns > out coasters if I try to use -s max with no-brand CD-R media. Tried newer firmware? > > You will have big problems finding any CD-R media (even very > > cheap one) with rating < 32 on the market today, so that chances to > > "overspeed" the media with those ancient burners are quite theoretical. > > What planet do you live on? Back here on Earth, the most widely > available CD-R media is 16x or 24x, and prices rise steeply once you > cross that boundary. For CD-RW media, that boundary is even lower (8x > or 12x). The drive reads ATIP info from the disk to determine the maximum writable=20 speed (Among other useful things) Of course the media could be lying about the maximum speed it's rated for, = but=20 I haven't seen media like that. I buy Verbatim 48x spindles of 50 disks whi= ch=20 are fairly cheap but don't produce coasters. CD-RW media is slower but that's a function of the way CD-RW's are made and= =20 their smaller volume. =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 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBNG+q5ZPcIHs/zowRAgDcAJ9w+nrttfrdHDVT02CthdYUQwU3egCfahst gyZ7SDzrclqoXiOuJXEtTrg=3D =3DQb5/ =2D----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 12:38:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6407016A4CE for ; Tue, 31 Aug 2004 12:38:04 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id F391643D45 for ; Tue, 31 Aug 2004 12:38:03 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id i7VCc3Jt019810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 31 Aug 2004 08:38:03 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i7VCbwcm041408; Tue, 31 Aug 2004 08:37:58 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16692.28966.142456.796633@grasshopper.cs.duke.edu> Date: Tue, 31 Aug 2004 08:37:58 -0400 (EDT) To: freebsd-current@freebsd.org X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Subject: RELENG_5 deadlocks on quad amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 12:38:04 -0000 I'm running RELENG_5 (from Friday, just after ALC's mfc of the IPI deadlock fix). Older dmesg at http://people.freebsd.org/~gallatin/quartet/dmesg Occasionally, it will deadlock. Usually while building something (kernel, world, our product, it seems pretty random). When it is in this state, its unpingable and sometimes (but not always) responds to breaks on the serial port. Enabling debugging options like WITNESS is enough to prevent the deadlock. It locked up this morning after a cvsup and a make depend in my kernel build directory. I've appended some diagnostic info. I'll leave it in this state for a while, in case anybody wants more info. Thanks, Drew [halt sent] KDB: enter: Line break on console [thread 100056] db> tr kdb_enter() at kdb_enter+0x2f siointr1() at siointr1+0x3f6 siointr() at siointr+0x5b intr_execute_handlers() at intr_execute_handlers+0x112 lapic_handle_intr() at lapic_handle_intr+0x21 Xapic_isr1() at Xapic_isr1+0x7d --- interrupt, rip = 0xffffffff8025f184, rsp = 0xffffffffb30c1b40, rbp = 0xffffffffb30c1b70 --- _mtx_lock_sleep() at _mtx_lock_sleep+0x114 softclock() at softclock+0x3c2 ithread_loop() at ithread_loop+0xde fork_exit() at fork_exit+0x8f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xffffffffb30c1d00, rbp = 0 --- db> show pcpu cpuid = 3 curthread = 0xffffff00d8a184a0: pid 54 "swi5: clock sio" curpcb = 0xffffffffb30c1d10 fpcurthread = none idlethread = 0xffffff00d8a526f0: pid 11 "idle: cpu3" db> show pcpu 0 cpuid = 0 curthread = 0xffffff00d8a35000: pid 14 "idle: cpu0" curpcb = 0xffffffffb2f9ad10 fpcurthread = none idlethread = 0xffffff00d8a35000: pid 14 "idle: cpu0" db> show pcpu 1 cpuid = 1 curthread = 0xffffff00d8a52b90: pid 13 "idle: cpu1" curpcb = 0xffffffffb2f95d10 fpcurthread = none idlethread = 0xffffff00d8a52b90: pid 13 "idle: cpu1" db> show pcpu 2 cpuid = 2 curthread = 0xffffff00aa4426f0: pid 3328 "cc1" curpcb = 0xffffffffb6096d10 fpcurthread = 0xffffff00aa4426f0: pid 3328 "cc1" idlethread = 0xffffff00d8a52940: pid 12 "idle: cpu2" db> tr 3328 fork_trampoline() at fork_trampoline db> ps pid proc uarea uid ppid pgrp flag stat wmesg wchan cmd 3328 ffffff00a8cfc000 ffffffffb6109000 0 2634 2616 0004002 [CPU 2] cc1 2634 ffffff00a47e12e0 ffffffffb61a0000 0 2633 2616 0004002 [SLPQ wait 0xffffff00a47e12e0][SLP] cc 2633 ffffff006b13a2e0 ffffffffb5e80000 0 2630 2616 0004002 [SLPQ wait 0xffffff006b13a2e0][SLP] sh 2630 ffffff00a9387b80 ffffffffb6194000 0 2628 2616 0004002 [SLPQ wait 0xffffff00a9387b80][SLP] xargs 2628 ffffff006d7135c0 ffffffffb5f49000 0 2622 2616 0004002 [SLPQ wait 0xffffff006d7135c0][SLP] sh 2622 ffffff00d85c52e0 ffffffffb3ac9000 0 2616 2616 0004002 [SLPQ wait 0xffffff00d85c52e0][SLP] make 2616 ffffff00a87aa000 ffffffffb619a000 0 2591 2616 0004002 [SLPQ wait 0xffffff00a87aa000][SLP] make 2591 ffffff006d64a8a0 ffffffffb5f40000 8107 2590 2591 0004002 [SLPQ pause 0xffffff006d64a910][SLP] csh 2590 ffffff0016a27000 ffffffffb5e2f000 8107 2587 2587 0000100 [SLPQ select 0xffffffff805d1550][SLP] sshd 2587 ffffff00a93872e0 ffffffffb6191000 0 466 2587 0000100 [SLPQ sbwait 0xffffff00ab466568][SLP] sshd 528 ffffff00d8a21b80 ffffffffb316a000 0 1 528 0004002 [SLPQ ttyin 0xffffff0000e29c10][SLP] getty 527 ffffff00abed28a0 ffffffffb6017000 0 1 527 0004002 [SLPQ ttyin 0xffffff0000bb1c10][SLP] getty 526 ffffff00abcb35c0 ffffffffb601b000 0 1 526 0004002 [SLPQ ttyin 0xffffff0000bb2010][SLP] getty 525 ffffff00abcb38a0 ffffffffb601c000 0 1 525 0004002 [SLPQ ttyin 0xffffff0000bb2410][SLP] getty 524 ffffff00abeed5c0 ffffffffb5fb7000 0 1 524 0004002 [SLPQ ttyin 0xffffff0000b73810][SLP] getty 523 ffffff00abeed8a0 ffffffffb6012000 0 1 523 0004002 [SLPQ ttyin 0xffffff0000af6010][SLP] getty 522 ffffff00abeedb80 ffffffffb6013000 0 1 522 0004002 [SLPQ ttyin 0xffffff0000b73c10][SLP] getty 521 ffffff00abeed2e0 ffffffffb5fb6000 0 1 521 0004002 [SLPQ ttyin 0xffffff0000b72c10][SLP] getty 520 ffffff00abeed000 ffffffffb5fb5000 0 1 520 0004002 [SLPQ ttyin 0xffffff0000b73010][SLP] getty 489 ffffff00abed2000 ffffffffb6014000 0 1 489 0000000 [SLPQ nanslp 0xffffffff805c4cc0][SLP] cron 476 ffffff00abed25c0 ffffffffb6016000 25 1 476 0000100 [SLPQ pause 0xffffff00abed2630][SLP] sendmail 472 ffffff00abed2b80 ffffffffb6018000 0 1 472 0000100 [SLPQ select 0xffffffff805d1550][SLP] sendmail 466 ffffff00abcb3000 ffffffffb6019000 0 1 466 0000100 [SLPQ select 0xffffffff805d1550][SLP] sshd 452 ffffff00abbd4000 ffffffffb601e000 0 1 452 0000000 [SLPQ select 0xffffffff805d1550][SLP] ntpd 379 ffffff006d64a5c0 ffffffffb5f3f000 0 1 379 0000000 [SLPQ select 0xffffffff805d1550][SLP] amd 350 ffffff006d72e000 ffffffffb5f42000 0 1 350 0000000 [SLPQ select 0xffffffff805d1550][SLP] ypbind 347 ffffff00acb925c0 ffffffffb5fb2000 0 1 347 0000000 [SLPQ select 0xffffffff805d1550][SLP] rpcbind 310 ffffff00d819e000 ffffffffb3a69000 0 1 310 0000000 [SLPQ select 0xffffffff805d1550][SLP] syslogd 290 ffffff006d64a2e0 ffffffffb5ee4000 0 1 290 0000000 [SLPQ select 0xffffffff805d1550][SLP] devd 260 ffffff006d72e5c0 ffffffffb5f44000 0 1 260 0000000 [SLPQ select 0xffffffff805d1550][SLP] dhclient 207 ffffff00d85c5000 ffffffffb3ac8000 0 1 207 0000000 [SLPQ pause 0xffffff00d85c5070][SLP] adjkerntz 77 ffffff00d85c5b80 ffffffffb3acc000 0 0 0 0000204 [SLPQ - 0xffffffff805dad18][SLP] nfsiod 3 76 ffffff00d8a038a0 ffffffffb311e000 0 0 0 0000204 [SLPQ - 0xffffffff805dad10][SLP] nfsiod 2 75 ffffff00d8a03b80 ffffffffb311f000 0 0 0 0000204 [SLPQ - 0xffffffff805dad08][SLP] nfsiod 1 74 ffffff00d8a1d000 ffffffffb3120000 0 0 0 0000204 [SLPQ - 0xffffffff805dad00][SLP] nfsiod 0 73 ffffff00d8a1d2e0 ffffffffb3121000 0 0 0 0000204 [SLPQ vlruwt 0xffffff00d8a1d2e0][SLP] vnlru 72 ffffff00d8a1d5c0 ffffffffb3122000 0 0 0 0000204 [SLPQ syncer 0xffffffff805c49c0][SLP] syncer 71 ffffff00d8a1d8a0 ffffffffb3123000 0 0 0 0000204 [SLPQ psleep 0xffffffff805d1e7c][SLP] bufdaemon 70 ffffff00d8a1db80 ffffffffb3124000 0 0 0 000020c [SLPQ pgzero 0xffffffff805e36b0][SLP] pagezero 69 ffffff00d8a5e000 ffffffffb3125000 0 0 0 0000204 [SLPQ psleep 0xffffffff805e371c][SLP] vmdaemon 68 ffffff00d8a5e2e0 ffffffffb3162000 0 0 0 0000204 [SLPQ psleep 0xffffffff805e36cc][SLP] pagedaemon 67 ffffff00d8a5e5c0 ffffffffb3163000 0 0 0 0000204 [IWAIT] swi0: sio 66 ffffff00d8a5e8a0 ffffffffb3164000 0 0 0 0000204 [SLPQ usbevt 0xffffffff80823420][SLP] usb1 65 ffffff00d8a5eb80 ffffffffb3165000 0 0 0 0000204 [SLPQ usbtsk 0xffffffff805b81d0][SLP] usbtask 64 ffffff00d8a21000 ffffffffb3166000 0 0 0 0000204 [SLPQ usbevt 0xffffffff80821420][SLP] usb0 9 ffffff00d8a592e0 ffffffffb30d6000 0 0 0 0000204 [SLPQ actask 0xffffffff805b57c0][SLP] acpi_task2 8 ffffff00d8a595c0 ffffffffb30d7000 0 0 0 0000204 [SLPQ actask 0xffffffff805b57c0][SLP] acpi_task1 7 ffffff00d8a598a0 ffffffffb30d8000 0 0 0 0000204 [SLPQ actask 0xffffffff805b57c0][SLP] acpi_task0 63 ffffff00d8a59b80 ffffffffb30d9000 0 0 0 0000204 [IWAIT] swi6: acpitaskq 62 ffffff00d8a5f000 ffffffffb30da000 0 0 0 0000204 [IWAIT] swi3: cambio 61 ffffff00d8a5f2e0 ffffffffb30db000 0 0 0 0000204 [IWAIT] swi2: camnet 60 ffffff00d8a5f5c0 ffffffffb30dc000 0 0 0 0000204 [IWAIT] swi6: task queue 59 ffffff00d8a5f8a0 ffffffffb3119000 0 0 0 0000204 [IWAIT] swi6:+ 6 ffffff00d8a5fb80 ffffffffb311a000 0 0 0 0000204 [SLPQ - 0xffffff00009aa280][SLP] thread taskq 58 ffffff00d8a03000 ffffffffb311b000 0 0 0 0000204 [IWAIT] swi6:+ 5 ffffff00d8a032e0 ffffffffb311c000 0 0 0 0000204 [SLPQ - 0xffffff00009aa400][SLP] kqueue taskq 57 ffffff00d8a035c0 ffffffffb311d000 0 0 0 0000204 [SLPQ - 0xffffffff805b5f40][SLP] yarrow 4 ffffff00d8a15000 ffffffffb308f000 0 0 0 0000204 [SLPQ - 0xffffffff805bbce8][SLP] g_down 3 ffffff00d8a152e0 ffffffffb3090000 0 0 0 0000204 [SLPQ - 0xffffffff805bbce0][SLP] g_up 2 ffffff00d8a155c0 ffffffffb3091000 0 0 0 0000204 [SLPQ - 0xffffffff805bbcd0][SLP] g_event 56 ffffff00d8a158a0 ffffffffb3092000 0 0 0 0000204 [IWAIT] swi1: net 55 ffffff00d8a15b80 ffffffffb3093000 0 0 0 0000204 [IWAIT] swi4: vm 54 ffffff00d8a56000 ffffffffb3094000 0 0 0 000020c [CPU 3] swi5: clock sio 53 ffffff00d8a562e0 ffffffffb30d1000 0 0 0 0000204 [IWAIT] irq39: 52 ffffff00d8a565c0 ffffffffb30d2000 0 0 0 0000204 [IWAIT] irq38: 51 ffffff00d8a568a0 ffffffffb30d3000 0 0 0 0000204 [IWAIT] irq37: 50 ffffff00d8a56b80 ffffffffb30d4000 0 0 0 0000204 [IWAIT] irq36: 49 ffffff00d8a59000 ffffffffb30d5000 0 0 0 0000204 [IWAIT] irq35: 48 ffffff00d8a23000 ffffffffb3049000 0 0 0 0000204 [IWAIT] irq34: 47 ffffff00d8a232e0 ffffffffb304a000 0 0 0 0000204 [IWAIT] irq33: 46 ffffff00d8a235c0 ffffffffb304b000 0 0 0 0000204 [IWAIT] irq32: 45 ffffff00d8a238a0 ffffffffb304c000 0 0 0 0000204 [RUNQ] irq31: bge0 44 ffffff00d8a23b80 ffffffffb304d000 0 0 0 0000204 [IWAIT] irq30: mpt1 43 ffffff00d8a27000 ffffffffb308a000 0 0 0 0000204 [IWAIT] irq29: mpt0 42 ffffff00d8a272e0 ffffffffb308b000 0 0 0 0000204 [IWAIT] irq28: bge1 41 ffffff00d8a275c0 ffffffffb308c000 0 0 0 0000204 [IWAIT] irq27: 40 ffffff00d8a278a0 ffffffffb308d000 0 0 0 0000204 [IWAIT] irq26: 39 ffffff00d8a27b80 ffffffffb308e000 0 0 0 0000204 [IWAIT] irq25: 38 ffffff00d8a0b2e0 ffffffffb3004000 0 0 0 0000204 [IWAIT] irq24: 37 ffffff00d8a0b5c0 ffffffffb3005000 0 0 0 0000204 [IWAIT] irq23: 36 ffffff00d8a0b8a0 ffffffffb3006000 0 0 0 0000204 [IWAIT] irq22: 35 ffffff00d8a0bb80 ffffffffb3007000 0 0 0 0000204 [IWAIT] irq21: 34 ffffff00d8a37000 ffffffffb3044000 0 0 0 0000204 [IWAIT] irq20: 33 ffffff00d8a372e0 ffffffffb3045000 0 0 0 0000204 [RUNQ] irq19: ohci0 ohci1 32 ffffff00d8a375c0 ffffffffb3046000 0 0 0 0000204 [IWAIT] irq18: 31 ffffff00d8a378a0 ffffffffb3047000 0 0 0 0000204 [IWAIT] irq17: 30 ffffff00d8a37b80 ffffffffb3048000 0 0 0 0000204 [IWAIT] irq16: 29 ffffff00d8a208a0 ffffffffb2fde000 0 0 0 0000204 [IWAIT] irq15: ata1 28 ffffff00d8a20b80 ffffffffb2fdf000 0 0 0 0000204 [IWAIT] irq14: ata0 27 ffffff00d8a28000 ffffffffb2fe0000 0 0 0 0000204 [IWAIT] irq13: 26 ffffff00d8a282e0 ffffffffb2fff000 0 0 0 0000204 [IWAIT] irq12: 25 ffffff00d8a285c0 ffffffffb3000000 0 0 0 0000204 [IWAIT] irq11: 24 ffffff00d8a288a0 ffffffffb3001000 0 0 0 0000204 [IWAIT] irq10: 23 ffffff00d8a28b80 ffffffffb3002000 0 0 0 0000204 [IWAIT] irq9: acpi0 22 ffffff00d8a0b000 ffffffffb3003000 0 0 0 0000204 [IWAIT] irq8: rtc 21 ffffff00d8a5b2e0 ffffffffb2fb9000 0 0 0 0000204 [IWAIT] irq7: 20 ffffff00d8a5b5c0 ffffffffb2fba000 0 0 0 0000204 [IWAIT] irq6: fdc0 19 ffffff00d8a5b8a0 ffffffffb2fd9000 0 0 0 0000204 [IWAIT] irq5: 18 ffffff00d8a5bb80 ffffffffb2fda000 0 0 0 0000204 [IWAIT] irq4: sio0 17 ffffff00d8a20000 ffffffffb2fdb000 0 0 0 0000204 [IWAIT] irq3: 16 ffffff00d8a202e0 ffffffffb2fdc000 0 0 0 0000204 [IWAIT] irq0: clk 15 ffffff00d8a205c0 ffffffffb2fdd000 0 0 0 0000204 [IWAIT] irq1: 14 ffffff00d8a51000 ffffffffb2f77000 0 0 0 000020c [CPU 0] idle: cpu0 13 ffffff00d8a512e0 ffffffffb2fb4000 0 0 0 000020c [CPU 1] idle: cpu1 12 ffffff00d8a515c0 ffffffffb2fb5000 0 0 0 000020c [Can run] idle: cpu2 11 ffffff00d8a518a0 ffffffffb2fb6000 0 0 0 000020c [Can run] idle: cpu3 1 ffffff00d8a51b80 ffffffffb2fb7000 0 0 1 0004200 [SLPQ wait 0xffffff00d8a51b80][SLP] init 10 ffffff00d8a5b000 ffffffffb2fb8000 0 0 0 0000204 [SLPQ ktrace 0xffffffff805c1610][SLP] ktrace 0 ffffffff805bbe60 ffffffff806b2000 0 0 0 0000200 [SLPQ sched 0xffffffff805bbe60][SLP] swapper From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 12:42:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76C1016A4CE for ; Tue, 31 Aug 2004 12:42:43 +0000 (GMT) Received: from web50106.mail.yahoo.com (web50106.mail.yahoo.com [206.190.38.34]) by mx1.FreeBSD.org (Postfix) with SMTP id 11F9E43D45 for ; Tue, 31 Aug 2004 12:42:43 +0000 (GMT) (envelope-from cell_468@yahoo.fr) Message-ID: <20040831124242.45154.qmail@web50106.mail.yahoo.com> Received: from [62.212.121.38] by web50106.mail.yahoo.com via HTTP; Tue, 31 Aug 2004 14:42:42 CEST Date: Tue, 31 Aug 2004 14:42:42 +0200 (CEST) From: =?iso-8859-1?q?fghjgf=20gfgfgjjg?= To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: bug with freebsd-5.3-beta2 when i boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 12:42:43 -0000 Hello , my kernel has crashed because i have nad lines in my loader.conf : netgraph_load="YES" if_tap_load="YES" ng_ether_load="YES" ng_bridge_load="YES" ng_socket_load="YES" and i don't how to delete this lines because i am on ddb now.The message of the panic : panic: mutex "tapmtx" 0x0a27d80 already initialised.Anyone have a solution for delete this lines in my /boot/loader.conf ? --------------------------------- Créez gratuitement votre Yahoo! Mail avec 100 Mo de stockage ! Créez votre Yahoo! Mail Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis.Téléchargez GRATUITEMENT ici ! From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 12:49:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F0D716A4DE for ; Tue, 31 Aug 2004 12:49:10 +0000 (GMT) Received: from mail2.neureal.com (mail2.neureal.com [66.98.170.78]) by mx1.FreeBSD.org (Postfix) with SMTP id B009843D3F for ; Tue, 31 Aug 2004 12:49:09 +0000 (GMT) (envelope-from quaggamail@quaggaspace.org) Received: (qmail 17353 invoked by uid 399); 31 Aug 2004 12:49:08 -0000 Received: from unknown (HELO ?192.168.42.25?) (141.152.240.193) by mail2.neureal.com with SMTP; 31 Aug 2004 12:49:08 -0000 From: Justin Settle To: vova@fbsd.ru In-Reply-To: <1093938230.961.8.camel@localhost> References: <200408301916.22240.mjohnston@skyweb.ca> <4133DA04.4030103@us.army.mil> <1093938230.961.8.camel@localhost> Content-Type: text/plain Message-Id: <1093956564.676.14.camel@amon.quaggaspace.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 31 Aug 2004 08:49:24 -0400 Content-Transfer-Encoding: 7bit cc: Jonathan cc: "current@freebsd.org" Subject: Re: cvs-src summary for August 23-30 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 12:49:10 -0000 On Tue, 2004-08-31 at 03:43, Vladimir Grebenschikov wrote: > On Mon, 2004-08-30 at 21:53 -0400, Jonathan wrote: > > Mark Johnston wrote: > > > > > Here's this week's summary. As a side note, I discovered Synergy > > > (http://synergy2.sf.net) today, and it made the summary-writing much more > > > pleasant, letting me flip my mouse cursor between the desktop I write the > > > summary on and the laptop I read the mail on, copying and pasting > > > transparently. I highly recommend it if you run any kind of > > > multi-PC-on-one-desktop configuration. > > > > > > > This is one of the coolest and most handy things I have ever seen! I > > can't say how well it works on the X side as my server is headless but > > on my XP desktop and laptop it ROCKS :D Sorry for the extra noise but if > > you have not looked at this and even occasionally use two computers at > > once it's well worth checking out!) > > Yes, but port does not work on -CURRENT: (server part of port) > > $ synergys > terminate called after throwing an instance of 'std::bad_alloc' > what(): St9bad_alloc > Abort (core dumped) > $ Hmm, I have FreeBSD BETA1 laptop hooked to my FreeBSD-BETA2(ish) desktop as the server and they're both working very nicely. I compiled it on the desktop and used the package on the laptop. However, that's not exactly -current. :) > Also port version is 1.0.14 when latest stable version 1.1.7. Hmm, it looks like the whole 1.1 series is under the "experimental" category on their sourceforge page. That said, the 1.1 version does have a lot of improvements going by the changelog. 1.1.6 has a changelog entry "Fixes for FreeBSD." It is a really nice program all together though :). From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 13:06:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D66D16A4CE for ; Tue, 31 Aug 2004 13:06:53 +0000 (GMT) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 224CE43D53 for ; Tue, 31 Aug 2004 13:06:53 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from buffy.york.ac.uk (buffy.york.ac.uk [144.32.226.160]) by mail-gw0.york.ac.uk (8.12.10/8.12.10) with ESMTP id i7VD6oLj016391; Tue, 31 Aug 2004 14:06:50 +0100 (BST) Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.1/8.12.11) with ESMTP id i7VD6ota034352; Tue, 31 Aug 2004 14:06:50 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.1/8.12.11/Submit) id i7VD6of9034351; Tue, 31 Aug 2004 14:06:50 +0100 (BST) (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: fghjgf gfgfgjjg In-Reply-To: <20040831124242.45154.qmail@web50106.mail.yahoo.com> References: <20040831124242.45154.qmail@web50106.mail.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1093957609.33464.19.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 31 Aug 2004 14:06:49 +0100 X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk cc: freebsd-current@freebsd.org Subject: Re: bug with freebsd-5.3-beta2 when i boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 13:06:53 -0000 On Tue, 2004-08-31 at 13:42, fghjgf gfgfgjjg wrote: > Hello , my kernel has crashed because i have nad lines in my loader.conf : > netgraph_load="YES" > if_tap_load="YES" > ng_ether_load="YES" > ng_bridge_load="YES" > ng_socket_load="YES" > > and i don't how to delete this lines because i am on ddb now.The message of the panic : > panic: mutex "tapmtx" 0x0a27d80 already initialised.Anyone have a solution for delete this lines in my /boot/loader.conf ? You should be able to break into the loader and enter something like: unload load /boot/kernel/kernel boot To get it to boot. I suspect the problem is the second line - if_tap_load="YES". Try just removing that and seeing if it boots. Gavin From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 13:08:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EA0116A4CE; Tue, 31 Aug 2004 13:08:28 +0000 (GMT) Received: from smtp3.sentex.ca (smtp3.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id E057B43D45; Tue, 31 Aug 2004 13:08:27 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smtp3.sentex.ca (8.13.1/8.13.1) with ESMTP id i7VD8PPc067994; Tue, 31 Aug 2004 09:08:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i7VD8RrU041954; Tue, 31 Aug 2004 09:08:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4D65A7303F; Tue, 31 Aug 2004 09:08:27 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040831130827.4D65A7303F@freebsd-current.sentex.ca> Date: Tue, 31 Aug 2004 09:08:27 -0400 (EDT) Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 13:08:28 -0000 TB --- 2004-08-31 11:49:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-31 11:49:45 - starting CURRENT tinderbox run for i386/i386 TB --- 2004-08-31 11:49:45 - checking out the source tree TB --- 2004-08-31 11:49:45 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2004-08-31 11:49:45 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-31 11:54:54 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-31 11:54:54 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2004-08-31 11:54:54 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-31 12:58:46 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-31 12:58:46 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2004-08-31 12:58:46 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Aug 31 12:58:46 UTC 2004 >>> 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 [...] ===> coda cc -O2 -pipe -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -g -I/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /tinderbox/CURRENT/i386/i386/src/sys/modules/coda/../../coda/coda_fbsd.c /tinderbox/CURRENT/i386/i386/src/sys/modules/coda/../../coda/coda_fbsd.c: In function `coda_fbsd_drvinit': /tinderbox/CURRENT/i386/i386/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: `NVCODA' undeclared (first use in this function) /tinderbox/CURRENT/i386/i386/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/i386/i386/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: for each function it appears in.) /tinderbox/CURRENT/i386/i386/src/sys/modules/coda/../../coda/coda_fbsd.c: In function `coda_fbsd_drvuninit': /tinderbox/CURRENT/i386/i386/src/sys/modules/coda/../../coda/coda_fbsd.c:215: error: `NVCODA' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/sys/modules/coda. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2004-08-31 13:08:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-31 13:08:27 - ERROR: failed to build generic kernel TB --- 2004-08-31 13:08:27 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 13:19:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 904D816A4CE for ; Tue, 31 Aug 2004 13:19:48 +0000 (GMT) Received: from ank-pki.ru (mercury.ank-pki.ru [213.170.76.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE93743D49 for ; Tue, 31 Aug 2004 13:19:46 +0000 (GMT) (envelope-from toxa@cterra.ru) Received: (qmail 60979 invoked by uid 0); 31 Aug 2004 17:19:38 +0400 Received: from toxa@cterra.ru by mercury.ank-pki.ru by uid 0 with qmail-scanner-1.22 (clamscan: 0.75.1. spamassassin: 2.64. Clear:RC:1(213.170.76.150):. Processed in 0.167007 secs); 31 Aug 2004 13:19:38 -0000 Received: from unknown (HELO localhost) (toxa@213.170.76.150) by ank.nwudc.ru with SMTP; 31 Aug 2004 17:19:38 +0400 Date: Tue, 31 Aug 2004 17:16:28 +0400 From: Toxa To: current@freebsd.org X-Comment-To: "Anton Karpov" Message-ID: <20040831131628.GA2156@laptoxa.toxa.lan> Mail-Followup-To: current@freebsd.org, takawata@jp.freebsd.org References: <20040831102731.GA1344@laptoxa.toxa.lan> <200408311041.TAA25051@axe-inc.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Description: ev.acpi_snc.0.%desc: Sony system controllerev.acpi_snc.0.%driver: acpi_sncev.acpi_snc.0.%location: handle=\_SB_.PCI0.LPC0.SNC_ev.acpi_snc.0.%pnpinfo: _HID=SNY5001 _UID=0ev.acpi_snc.0.%parent: acpi0ev.acpi_snc.0.brightness: 94ev.acpi_snc.0.brightness: 94 -> 10ev.acpi_snc.0.brightness: 10 -> 100 Content-Disposition: inline In-Reply-To: <200408311041.TAA25051@axe-inc.co.jp> User-Agent: Outluck Express 1.5.6i for MS-DOS 6.22-SMP X-Mailer: See User-Agent above :) X-Operating-System: MS-DOS 6.22-CURRENT on Sony VAIO laptop X-PGP-Public-Key: http://toxahost.org/gpg/pubkey.asc X-Useless-Header: Do Androids Dream of Electric Sheep? Subject: Re: acpi_video on SONY VAIO PCG-Z1 [was: acpi_video users needed] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 13:19:48 -0000 On Tue, Aug 31, 2004 at 07:41:11PM +0900, takawata@jp.freebsd.org wrote: > >dev.acpi_sny.0.brightness=10 > >sysctl: oid 'dev.acpi_sny.0.brightness' is read only > > > >nothing happens... > Sorry, please refetch it from > http://www.init-main.com/acpi_snc.tar.gz acpi_sny0: detached acpi_snc0: on acpi0 [(17:12)(49.34%)(p6):~/tmp/acpi_snc ] sysctl -a|grep snc dev.acpi_snc.0.%desc: Sony system controller dev.acpi_snc.0.%driver: acpi_snc dev.acpi_snc.0.%location: handle=\_SB_.PCI0.LPC0.SNC_ dev.acpi_snc.0.%pnpinfo: _HID=SNY5001 _UID=0 dev.acpi_snc.0.%parent: acpi0 dev.acpi_snc.0.brightness: 94 [(17:12)(49.34%)(p6):~/tmp/acpi_snc ] sudo sysctl dev.acpi_snc.0.brightness=10 dev.acpi_snc.0.brightness: 94 -> 10 [(17:13)(49.51%)(p6):~/tmp/acpi_snc ] sudo sysctl dev.acpi_snc.0.brightness=100 dev.acpi_snc.0.brightness: 10 -> 100 [(17:13)(49.51%)(p6):~/tmp/acpi_snc ] Yes, it works, thanks a lot! Now I'm wondering how to resume lid from suspending. Machine resumes well and I can log in remotely but monitor looks "dead" -- Anton A. Karpov PGP key: http://www.toxahost.org/pgp/pubkey.asc You can finger me @toxahost.org for my current status =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~= "Anyone who quotes me in their sig is an idiot." Rusty Russell. =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~= From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 13:25:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F54416A55E; Tue, 31 Aug 2004 13:25:26 +0000 (GMT) Received: from freesbee.dk (freesbee.dk [194.192.25.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3E8043D3F; Tue, 31 Aug 2004 13:25:25 +0000 (GMT) (envelope-from signout@signout.dk) Received: from signoutscraptop (localhost [127.0.0.1]) by freesbee.dk (Postfix) with SMTP id A52042BE36; Tue, 31 Aug 2004 15:25:23 +0200 (CEST) Message-ID: <01c701c48f5d$f86b7960$87075050@signoutscraptop> From: =?iso-8859-1?Q?Dennis_Kj=E6r_Jensen?= To: =?iso-8859-1?Q?Dennis_Kj=E6r_Jensen?= , "Ruslan Ermilov" References: <0be501c48e94$ba63c060$87075050@signoutscraptop><20040830150202.GB65719@ip.net.ua> <012a01c48f37$510d5ce0$87075050@signoutscraptop> Date: Tue, 31 Aug 2004 15:25:23 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.3790.181 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA2 problems booting HP NetServer E60 both ACPI andnon-ACPI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 13:25:26 -0000 > > You can disable AGP with hints on recent -CURRENT versions. Set > > hint.agp.0.disabled=1 while in the loader(8), and see if that helps. > > Same same - the system locks up both with and without acpi I actually managed to get it running without even having to turn any knobs in loader(8) BIOS upgrade from 4.06.25 PN to 4.06.26 PN solved the case. According to HP: "Fix hang problem during Windows 2000 installation on E60 systems with motherboard containing a new version of Winbond Super I/O chipset (W83977EF)" Apparently this also fixes hang problem with FreeBSD newer than 4.7 Why it broke somewhere between 4.7 and 4.8 is beyond me, but I don't really care about that now :) ... Dennis From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 13:36:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55CE316A4CE; Tue, 31 Aug 2004 13:36:57 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BDF543D6E; Tue, 31 Aug 2004 13:36:56 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7VDaoTx093256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Aug 2004 16:36:51 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i7VDat7N033180; Tue, 31 Aug 2004 16:36:55 +0300 (EEST) (envelope-from ru) Date: Tue, 31 Aug 2004 16:36:54 +0300 From: Ruslan Ermilov To: cg Message-ID: <20040831133654.GF31981@ip.net.ua> References: <20040828142503.GA52613@ip.net.ua> <20040829190833.GA9796@cnd.mcgill.ca> <20040829205942.GC39813@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k3qmt+ucFURmlhDS" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: Seigo Tanimura cc: Cameron Grant cc: "Simon L. Nielsen" cc: multimedia@FreeBSD.org cc: Mathew Kanner cc: current@FreeBSD.org Subject: Re: [PATCH] sound(4) related manpages 5.3 TODO item X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 13:36:57 -0000 --k3qmt+ucFURmlhDS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Please keep me Cc:ed when replying ] On Mon, Aug 30, 2004 at 04:28:52PM +0100, cg wrote: > On Sun, 29 Aug 2004 23:59:42 +0300, Ruslan Ermilov wrote: >=20 > >I wish there would be more consistency in naming. Previously, > >we had the csa(4) manpage, "device csa", and /dev/csa* entries. > >Now we will have the snd_csa(4) manpage, "device snd_csa", but > >still /dev/csaX entry. > > > >Also, in the old world, "midi" devices were created as children > >of "pcm" devices, so "hint.pcm.0" hints for non-PnP ISA devices > >looked correct. In new world with your updated midi(4), what > >will be the hints for the ISA device that implements PCM and > >MIDI? hint.pcm.0 and hint.midi.0? >=20 > the intention behind the renaming was to simplify the naming scheme, and = =20 > to glue pcm and midi together such that card drivers didn't have to =20 > separate out their pcm, midi and independant code. >=20 > if you look at any of the current card drivers, you'll find that they mak= e =20 > several calls into the pcm code. those supporting midi, likewise, call = =20 > into midi code. having midi and pcm as seperate devices gives the =20 > impression that they're independant, but if we allowed that to be the cas= e =20 > the drivers would have to become far more complex. ie, they each would = =20 > require a separate module for their pcm, midi and general parts because i= f =20 > say, only midi was compiled into the kernel then the pcm code in the =20 > drivers would fail to link. likewise, drivers supporting midi would fail= =20 > to link if only pcm was present. >=20 > for modules, this problem can be solved with dependancies, but the only = =20 > solution for a static kernel would be to declare that if you wish to =20 > compile a driver that supports pac and midi, both device pcm and device = =20 > midi must be specified. >=20 > rather than leave the situation that way, we elected to combine the pcm = =20 > and midi devices into one, so the card drivers could assume both were =20 > present. >=20 > renaming the card modules is a different story, and although i was in =20 > favour of it, i now feel it wasn't such a good idea in its current form. = =20 > because pcm is just a framework rather than an actual device from the =20 > kernel's point of view, the driver name would show up in dmesg etc as =20 > snd_emu10k1 or whatever. while that in itself wouldn't cause a problem, = =20 > it would result in each driver using a different devclass - and there are= =20 > some fairly fundamental assumptions in the pcm code that is designed =20 > around being able to translate a unit number to a device_t. >=20 > if the drivers were changed to register as snd_* rather than pcm, but =20 > remain sharing their devclass, there would be interesting results: either= =20 > all sound devices would show up with the name of the one that attached = =20 > first (eg an ich and emu10k1 as snd_ich0 and snd_ich1) or the unit number= s =20 > would be shared across devices (eg, snd_ich0, snd_maestro1, snd_cmi2...) >=20 > both of those possible outcomes would be worse than the current situation= , =20 > in my opinion. >=20 > what we can - and should - do is rename the "pcm" devclass to "sound". = =20 > this would make sound devices show up as sound0 etc, and make the =20 > hints/sysctls be hw.sound0.*. we also need to make sure that the sound.k= o =20 > module contains both pcm and midi. >=20 I agree that renaming the "pcm" devclass to "snd" or "sound" is a good idea, and I like the "snd" more for a couple of reasons (please see below). Let me now check if I got you right. Assuming it will be renamed to "snd", what about the /dev entries, will they be still /dev/pcm{unit}, /dev/mixer{unit}, and /dev/midi{unit}? If, for example, I have two sound cards installed, first without MIDI, and second with MIDI, what will I have in /dev? pcm0, mixer0, *no* midi0, pcm1, mixer1, and midi1? And these devices ("pcm", "mixer", and "midi") will be all children of the "snd" device. And for the ISA sound card with MIDI support, the following device hints and corresponding /dev entries? hint.snd.0.at=3D"isa" hint.snd.0.irq=3D"5" hint.snd.0.drq=3D"1" hint.snd.0.flags=3D"0x0" /dev/pcm0 /dev/mixer0 /dev/midi0 > it might be nice to have a meta device called sound_all which pulled in = =20 > all the drivers plus the pcm and midi code, and a corresponding kld. >=20 The snd_driver.ko module already provides this feature. Should we need such a "config(8) device" is another question. I don't personally see a fit in it -- the GENERIC kernel can already have all snd_* devices and the generic "snd" device. > i wonder if we still have the opportunity to rename snd* to sound*? or = =20 > possibly sound to snd which would mesh better with /dev/sndstat. >=20 Yes, please, the latter. ;) So, to summarize, I'd have liked to see the following happen: - "snd" is the generic sound device (module snd.ko) - "snd_foo" is the sound driver for foo (module snd_foo.ko) - "pcm" devclass renamed to "snd" - "pcm", "mixer", and "midi" devices are created as children of "snd" - ISA device hints become snd..{at,irq,drq,flags,...} - the hw.snd. sysctl tree stays unmodified, including the following convention: PCM-related sysctls will have the hw.snd.pcm prefix, and MIDI-related sysctls (should there be any) will have the hw.snd.midi prefix. And one final question: if the plan is as described here, it probably makes sense to do it now, before 5.3, or postpone the "manpage and handbook" sound related TODO items until it's actually done and merged into RELENG_5. I'd like to avoid repo-copying the pcm(4) manpage to sound(4) now, only to repo-copy it later to snd(4). If this doesn't happen in time for 5.3, I suggest the following emergency plan for now: - repo-copy (and tweak as necessary) all bridge drivers manpages, as shown in my patch; - do *not* repo-copy pcm(4) to sound(4) yet, just link it, possibly mentioning in the manpage that the generic driver will soon be renamed from "sound" to "snd", - fix hints in NOTES (as in my patch) to match reality. When "sound" -> "snd" conversion is actually done, repo-copy pcm(4) to sound(4), tweak as necessary, documenting what the "sound" device really is, mentioning "pcm", "mixer", and "midi" sub-devices, link sound(4) to pcm(4), mixer(4), and midi(4). Please let me know how to proceed... Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --k3qmt+ucFURmlhDS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBNH72qRfpzJluFF4RAqu0AJ4oyJ18J59CS5x9aXP4VZSOBe/p2wCePTMl ZJv5LomHgJ0dVtITkt/YIWo= =ZMN9 -----END PGP SIGNATURE----- --k3qmt+ucFURmlhDS-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 13:37:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1B02C16A53A for ; Tue, 31 Aug 2004 13:37:55 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32CC743D2D for ; Tue, 31 Aug 2004 13:37:54 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7VDbnT4093284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Aug 2004 16:37:50 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i7VDbtwu033202; Tue, 31 Aug 2004 16:37:55 +0300 (EEST) (envelope-from ru) Date: Tue, 31 Aug 2004 16:37:55 +0300 From: Ruslan Ermilov To: Dennis Kj?r Jensen Message-ID: <20040831133755.GG31981@ip.net.ua> References: <012a01c48f37$510d5ce0$87075050@signoutscraptop> <01c701c48f5d$f86b7960$87075050@signoutscraptop> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IvGM3kKqwtniy32b" Content-Disposition: inline In-Reply-To: <01c701c48f5d$f86b7960$87075050@signoutscraptop> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA2 problems booting HP NetServer E60 both ACPI andnon-ACPI X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 13:37:56 -0000 --IvGM3kKqwtniy32b Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 31, 2004 at 03:25:23PM +0200, Dennis Kj?r Jensen wrote: > > > You can disable AGP with hints on recent -CURRENT versions. Set > > > hint.agp.0.disabled=3D1 while in the loader(8), and see if that helps. > > > > Same same - the system locks up both with and without acpi >=20 > I actually managed to get it running without even having to turn any knobs > in loader(8) >=20 > BIOS upgrade from 4.06.25 PN to 4.06.26 PN solved the case. >=20 > According to HP: > "Fix hang problem during Windows 2000 installation on E60 systems with > motherboard containing a new version of Winbond Super I/O chipset > (W83977EF)" >=20 > Apparently this also fixes hang problem with FreeBSD newer than 4.7 > Why it broke somewhere between 4.7 and 4.8 is beyond me, but I don't real= ly > care about that now :) >=20 Thank you a lot for following up, Dennis! Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --IvGM3kKqwtniy32b Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBNH8zqRfpzJluFF4RApzLAJ9HW9c0xcEmEyfRVrY5a++DedKnBwCfUIk9 ErF5ZO4fd7lxxaEyiz/xOe0= =+74i -----END PGP SIGNATURE----- --IvGM3kKqwtniy32b-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 13:44:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3468316A4CE for ; Tue, 31 Aug 2004 13:44:08 +0000 (GMT) Received: from vhost109.his.com (vhost109.his.com [216.194.225.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB71243D39 for ; Tue, 31 Aug 2004 13:44:07 +0000 (GMT) (envelope-from brad@stop.mail-abuse.org) Received: from [10.0.1.3] (localhost.his.com [127.0.0.1]) by vhost109.his.com (8.12.11/8.12.3) with ESMTP id i7VDi5dB029010; Tue, 31 Aug 2004 09:44:06 -0400 (EDT) (envelope-from brad@stop.mail-abuse.org) Mime-Version: 1.0 X-Sender: bs663385@127.0.0.1 Message-Id: In-Reply-To: <200408310152.22649.dsyphers@u.washington.edu> References: <20040829213449.GA33843@hub.freebsd.org> <20040831080701.GA703@galgenberg.net> <200408310152.22649.dsyphers@u.washington.edu> Date: Tue, 31 Aug 2004 15:43:56 +0200 To: David Syphers From: Brad Knowles Content-Type: text/plain; charset="us-ascii" ; format="flowed" cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 13:44:08 -0000 At 1:52 AM -0700 2004-08-31, David Syphers wrote: >> Think French. Gauche and Droite. [0] >> Does hard-coding "g" and "d" into the program make any more sense > > No, unfortunately, because on QWERTY "d" is to the left of "g". Same problem > as with "r" and "l". Uhh, you haven't seen French keyboards, have you? They don't use QWERTY. They use AZERTY -- Although I can't recall off the top of my head where "d" and "g" fall on the layout. For that matter, Swiss French keyboards are slightly different from Belgian/French French keyboards. I've gone through four or five different keyboards on this damn laptop I'm using at the moment, including Swiss French, Belgian/French French, German QWERTZU, and I don't remember what all else. Trust me, they're all slightly different. For some of them, if you want to type numbers, you have to hold down a function key and then hit one of the keys on the top row which are otherwise reserved for other characters/character modifiers which are not typically found within the English/Roman alphabet. Now imagine what happens when you start talking about Slavic languages which have some characters that I imagine almost no American or native English-speaker in Europe has ever seen. Or the middle eastern languages like Farsi. Or Hebrew. Or Hindi. Or the three different written versions of Japanese. Or Chinese. Things get really interesting when you start talking about ideograph-based languages for which an adult might be expected to remember 5000-8000 different unique characters, and for which keyboards might have 200 or more keys. So, when talking about these issues, you not only need to think about language, but also keyboard layouts. If you're going to be serious about proposing alternatives, you need to address those issues as well as others. And you need to be willing to come up with the necessary internationalization infrastructure to deal with all the possible permutations and combinations. Or, you can decide to just live with what is hard-coded into the current version of the program. > Mmm... I think we're about ready for chat@ here... That was kind of my point. I was being sarcastic, but I guess that didn't come through. -- Brad Knowles, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See for more info. From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 13:45:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 444C216A522 for ; Tue, 31 Aug 2004 13:45:17 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77D8543D1D for ; Tue, 31 Aug 2004 13:45:16 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1C28wb-000PyM-Mt; Tue, 31 Aug 2004 17:45:05 +0400 From: Vladimir Grebenschikov To: Justin Settle In-Reply-To: <1093956564.676.14.camel@amon.quaggaspace.org> References: <200408301916.22240.mjohnston@skyweb.ca> <4133DA04.4030103@us.army.mil> <1093938230.961.8.camel@localhost> <1093956564.676.14.camel@amon.quaggaspace.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Tue, 31 Aug 2004 17:45:05 +0400 Message-Id: <1093959905.98824.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.93FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: Jonathan cc: "current@freebsd.org" Subject: Re: cvs-src summary for August 23-30 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 13:45:17 -0000 On Tue, 2004-08-31 at 08:49 -0400, Justin Settle wrote: > On Tue, 2004-08-31 at 03:43, Vladimir Grebenschikov wrote: > > On Mon, 2004-08-30 at 21:53 -0400, Jonathan wrote: > > > Mark Johnston wrote: > > > > > > > Here's this week's summary. As a side note, I discovered Synergy > > > > (http://synergy2.sf.net) today, and it made the summary-writing much more > > > > pleasant, letting me flip my mouse cursor between the desktop I write the > > > > summary on and the laptop I read the mail on, copying and pasting > > > > transparently. I highly recommend it if you run any kind of > > > > multi-PC-on-one-desktop configuration. > > > > > > > > > > This is one of the coolest and most handy things I have ever seen! I > > > can't say how well it works on the X side as my server is headless but > > > on my XP desktop and laptop it ROCKS :D Sorry for the extra noise but if > > > you have not looked at this and even occasionally use two computers at > > > once it's well worth checking out!) > > > > Yes, but port does not work on -CURRENT: (server part of port) > > > > $ synergys > > terminate called after throwing an instance of 'std::bad_alloc' > > what(): St9bad_alloc > > Abort (core dumped) > > $ > > Hmm, I have FreeBSD BETA1 laptop hooked to my FreeBSD-BETA2(ish) desktop > as the server and they're both working very nicely. I compiled it on > the desktop and used the package on the laptop. However, that's not > exactly -current. :) Strange, friend of mine just build synergy from ports on 5.3-BETA1 and synergys (server) died just I have post before, client seems to be ok on both 6-CURRENT and 5.3-BETA1. I have also tried to install package (pkg_add -r synergy) and it died with same diagnostic. No idea why it happens so. -- Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 13:49:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D106416A4CE for ; Tue, 31 Aug 2004 13:49:15 +0000 (GMT) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CBE743D1F for ; Tue, 31 Aug 2004 13:49:15 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (andy@localhost [127.0.0.1]) i7VDlq8A048687; Tue, 31 Aug 2004 09:47:52 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)i7VDlpKf048684; Tue, 31 Aug 2004 09:47:51 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Tue, 31 Aug 2004 09:47:51 -0400 (EDT) From: Andre Guibert de Bruet To: Edwin Culp In-Reply-To: <20040831061128.skwogkc8kw0ksoss@mail.encontacto.net> Message-ID: <20040831094518.D5951@alpha.siliconlandmark.com> References: <20040831061128.skwogkc8kw0ksoss@mail.encontacto.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean cc: current@freebsd.org Subject: Re: /coda/coda_fbsd.c:215: error: `NVCODA' undeclared when building kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 13:49:16 -0000 On Tue, 31 Aug 2004, Edwin Culp wrote: > cc -O -pipe -D_KERNEL -DKLD_MODULE -nostdinc -I- -include > /usr/obj/usr/src/sys/ENCONTACTO/opt_global.h -I. -I@ > -I@/contrib/altq -I@/../inc > lude -finline-limit=8000 -fno-common > -I/usr/obj/usr/src/sys/ENCONTACTO -mno-align-long-strings > -mpreferred-stack-boundary=2 -ffreestanding - > Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > -fformat-extensions - > std=c99 -c /usr/src/sys/modules/coda/../../coda/coda_fbsd.c > /usr/src/sys/modules/coda/../../coda/coda_fbsd.c: In function > `coda_fbsd_drvinit': > /usr/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: > `NVCODA' undeclared (first use in this function) > /usr/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: > (Each undeclared identifier is reported only once > /usr/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: for > each function it appears in.) > /usr/src/sys/modules/coda/../../coda/coda_fbsd.c: In function > `coda_fbsd_drvuninit': > /usr/src/sys/modules/coda/../../coda/coda_fbsd.c:215: error: > `NVCODA' undeclared (first use in this function) > *** Error code 1 > > Stop in /usr/src/sys/modules/coda. > *** Error code 1 "Me too". I cvsup'ed again, and it does the same thing using: Edit src/sys/modules/coda/Makefile,v Add delta 1.14 2004.08.31.12.17.47 ru Regards, | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 13:59:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B794616A4CE for ; Tue, 31 Aug 2004 13:59:30 +0000 (GMT) Received: from atlas.informatik.rwth-aachen.de (atlas.informatik.RWTH-Aachen.DE [137.226.194.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2664F43D58 for ; Tue, 31 Aug 2004 13:59:30 +0000 (GMT) (envelope-from stolz@i2.informatik.rwth-aachen.de) Received: from i2.informatik.rwth-aachen.de (menelaos.informatik.RWTH-Aachen.DE [137.226.194.73]) with ESMTP id i7VDxTZB014946 for ; Tue, 31 Aug 2004 15:59:29 +0200 Received: (from stolz@localhost)i7VDxSu5024605 for current@freebsd.org; Tue, 31 Aug 2004 15:59:28 +0200 (CEST) (envelope-from stolz) Date: Tue, 31 Aug 2004 15:59:28 +0200 From: Volker Stolz To: current@freebsd.org Message-ID: <20040831135928.GY64543@i2.informatik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: finger vs@foldr.org X-PGP-Id: 0x3FD1B6B5 User-Agent: Mutt/1.5.6i Subject: NFS mounted full disk gives funny stats on 5.3B2 (negative Avail?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 13:59:30 -0000 The negative Avail-stats seem to be mistranslated. Is this worth send-pr'ing or is it a known problem? Please cc: replies. Volker NFS-Client: FreeBSD monster.theater.foldr.org 5.3-BETA2 FreeBSD 5.3-BETA2 #2: Fri Aug 27 22:22:56 CEST 2004 root@monster.theater.foldr.org:/usr/obj/usr/src/sys/GENERIC i386 Server: FreeBSD theater.foldr.org 4.8-STABLE FreeBSD 4.8-STABLE #0: Sun Aug 17 17:17:06 CEST 2003 root@monster.theater.foldr.org:/opt/obj/opt/src/sys/GATE i386 files@monster [15:53:34]> df -k Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad2s2a 253678 204948 28436 88% / devfs 1 1 0 100% /dev /dev/ad2s2e 253678 22 233362 0% /tmp /dev/ad2s2f 7764558 1417994 5725400 20% /usr /dev/ad2s2d 253678 7852 225532 3% /var /dev/ad0s2f 9694536 7651705 1267269 86% /opt/stable 192.168.3.1:/usr/ports 12654059 12254446 18014398508869273 0% /usr/ports 192.168.3.1:/opt2/distfiles 1367567 1097140 161022 87% /mnt/distfiles 192.168.3.1:/opt2/freebsdcvs 1367567 1097140 161022 87% /opt2/freebsdcvs theater:[ports]> df -k Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 49583 25924 19693 57% / /dev/ad0s1f 270431 175139 73658 70% /usr /dev/ad0s1e 19815 14584 3646 80% /var /dev/ad2s1e 12654059 12254446 -612711 105% /opt /dev/ad1s1f 1367567 1097140 161022 87% /opt2 procfs 4 4 0 100% /proc linprocfs 4 4 0 100% /opt/compat/linux/proc localhost:/ 0 0 0 100% /crypt theater:[ports]> ls -l /usr/ports lrwxr-xr-x 1 root wheel 10 Aug 6 21:42 /usr/ports -> /opt/ports -- http://www-i2.informatik.rwth-aachen.de/stolz/ *** PGP *** S/MIME L-Attriwutgrammatik From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 14:25:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99AA816A4CE; Tue, 31 Aug 2004 14:25:15 +0000 (GMT) Received: from smarthost2.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D018443D3F; Tue, 31 Aug 2004 14:25:14 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id i7VEOikS001184; Tue, 31 Aug 2004 10:24:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i7VEPDjU095990; Tue, 31 Aug 2004 10:25:14 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E10F57303F; Tue, 31 Aug 2004 10:25:13 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040831142513.E10F57303F@freebsd-current.sentex.ca> Date: Tue, 31 Aug 2004 10:25:13 -0400 (EDT) Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 14:25:15 -0000 TB --- 2004-08-31 13:08:27 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-08-31 13:08:27 - starting CURRENT tinderbox run for i386/pc98 TB --- 2004-08-31 13:08:27 - checking out the source tree TB --- 2004-08-31 13:08:27 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2004-08-31 13:08:27 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-08-31 13:13:40 - building world (CFLAGS=-O2 -pipe) TB --- 2004-08-31 13:13:40 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2004-08-31 13:13:40 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-08-31 14:17:54 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-08-31 14:17:54 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2004-08-31 14:17:54 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Aug 31 14:17:54 UTC 2004 >>> 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 [...] ===> coda cc -O2 -pipe -DPC98 -D_KERNEL -DKLD_MODULE -nostdinc -I- -include /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -g -I/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /tinderbox/CURRENT/i386/pc98/src/sys/modules/coda/../../coda/coda_fbsd.c /tinderbox/CURRENT/i386/pc98/src/sys/modules/coda/../../coda/coda_fbsd.c: In function `coda_fbsd_drvinit': /tinderbox/CURRENT/i386/pc98/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: `NVCODA' undeclared (first use in this function) /tinderbox/CURRENT/i386/pc98/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/i386/pc98/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: for each function it appears in.) /tinderbox/CURRENT/i386/pc98/src/sys/modules/coda/../../coda/coda_fbsd.c: In function `coda_fbsd_drvuninit': /tinderbox/CURRENT/i386/pc98/src/sys/modules/coda/../../coda/coda_fbsd.c:215: error: `NVCODA' undeclared (first use in this function) *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/sys/modules/coda. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2004-08-31 14:25:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-08-31 14:25:13 - ERROR: failed to build generic kernel TB --- 2004-08-31 14:25:13 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 14:42:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDC7416A4CE for ; Tue, 31 Aug 2004 14:42:17 +0000 (GMT) Received: from linwhf.opal.com (105.79.171.66.subscriber.vzavenue.net [66.171.79.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6D0E43D1F for ; Tue, 31 Aug 2004 14:42:16 +0000 (GMT) (envelope-from jr@opal.com) Received: (jr@localhost) by linwhf.opal.com (8.12.11/jr6.1/Submit) for id i7VEg5VS001001; Tue, 31 Aug 2004 10:42:05 -0400 (EDT) Date: Tue, 31 Aug 2004 10:42:05 -0400 From: "J.R. Oldroyd" To: =?iso-8859-1?Q?S=F8ren?= Schmidt Message-ID: <20040831144205.GA817@linwhf.opal.com> References: <412F5A10.8080907@drexel.edu> <412F7292.6000804@DeepCore.dk> <20040830181540.GA809@linwhf.opal.com> <413372B3.5010603@DeepCore.dk> <20040830192224.GB809@linwhf.opal.com> <413390B9.5050705@DeepCore.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <413390B9.5050705@DeepCore.dk> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: Current 8/27/2004, DVD problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 14:42:18 -0000 Some follow-up. Similar to other folks with this problem, the system will boot in verbose mode. However, ONLY with no medium. If medium is present, it still hangs. If the tray is empty, it will boot in either DMA or PIO mode. And if I then insert a disc, I can read it OK. Here's the disk probe part of the dmesg from such a boot... ... ata0-slave: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata0-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata0-master: setting PIO4 on Intel ICH5 chip ata0-master: setting UDMA100 on Intel ICH5 chip ata0-slave: setting PIO4 on Intel ICH5 chip ata0-slave: setting UDMA100 on Intel ICH5 chip ad0: ATA-5 disk at ata0-master ad0: 38166MB (78165360 sectors), 77545 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA100 GEOM: new disk ad0 ar: FreeBSD check1 failed [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:78156162 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 32256 length 40015954944 end 40015987199 ad1: ATA-6 disk at ata0-slave ad1: 238475MB (488397168 sectors), 484521 C, 16 H, 63 S, 512 B ad1: 16 secs/int, 1 depth queue, UDMA100 GEOM: Configure ad0s1a, start 0 length 268435456 end 268435455 GEOM: Configure ad0s1b, start 268435456 length 4250181632 end 4518617087 GEOM: Configure ad0s1c, start 0 length 40015954944 end 40015954943 GEOM: Configure ad0s1d, start 4518617088 length 268435456 end 4787052543 GEOM: Configure ad0s1e, start 4787052544 length 536870912 end 5323923455 GEOM: Configure ad0s1f, start 5323923456 length 268435456 end 5592358911 GEOM: Configure ad0s1g, start 5592358912 length 268435456 end 5860794367 GEOM: Configure ad0s1h, start 5860794368 length 34155160576 end 40015954943 GEOM: new disk ad1 ar: FreeBSD check1 failed ata1-slave: pio=0x0c wdma=0x22 udma=0x42 cable=40pin ATAPI_RESET time = 30us ata1-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata1-master: setting PIO4 on Intel ICH5 chip ata1-master: DMA limited to UDMA33, non-ATA66 cable or device ata1-master: setting UDMA33 on Intel ICH5 chip ata1-slave: setting PIO4 on Intel ICH5 chip ata1-slave: setting UDMA33 on Intel ICH5 chip ad2: ATA-6 disk at ata1-master ad2: 32253MB (66055248 sectors), 65531 C, 16 H, 63 S, 512 B ad2: 16 secs/int, 1 depth queue, UDMA33 ar: FreeBSD check1 failed acd0: <_NEC DVD_RW ND-1300A/1.05> DVDR drive at ata1 as slave acd0: read 6890KB/s (6890KB/s) write 2755KB/s (2755KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc pcm0: measured ac97 link rate at 47998 Hz, will use 48000 Hz [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):168/15/63 s:63 l:488397105 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad1s1, start 32256 length 250059317760 end 250059350015 GEOM: new disk ad2 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/15/63 s:63 l:66055185 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad2s1, start 32256 length 33820254720 end 33820286975 GEOM: Configure ad2s1c, start 0 length 33820254720 end 33820254719 GEOM: Configure ad2s1d, start 0 length 5368709120 end 5368709119 GEOM: Configure ad2s1e, start 5368709120 length 28451545600 end 33820254719 (probe0:sbp0:0:0:0): error 22 (probe0:sbp0:0:0:0): Unretryable Error (probe1:sbp0:0:1:0): error 22 (probe1:sbp0:0:1:0): Unretryable Error (probe2:sbp0:0:2:0): error 22 (probe2:sbp0:0:2:0): Unretryable Error (probe3:sbp0:0:3:0): error 22 (probe3:sbp0:0:3:0): Unretryable Error (probe4:sbp0:0:4:0): error 22 (probe4:sbp0:0:4:0): Unretryable Error (probe5:sbp0:0:5:0): error 22 (probe5:sbp0:0:5:0): Unretryable Error (probe6:sbp0:0:6:0): error 22 (probe6:sbp0:0:6:0): Unretryable Error SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00050014 LDR: 0x02000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00010400 TPR: 0x00000000 SVR: 0x000001ff ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ... From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 14:44:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8666516A4CE for ; Tue, 31 Aug 2004 14:44:03 +0000 (GMT) Received: from mail.halls.colostate.edu (halls-mailgw.acns.colostate.edu [129.82.100.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE81143D5D for ; Tue, 31 Aug 2004 14:44:02 +0000 (GMT) (envelope-from end@endif.cjb.net) Received: from sed (inge068149.halls.colostate.edu [129.82.68.149]) i7VEi11k015592; Tue, 31 Aug 2004 08:44:02 -0600 Date: Tue, 31 Aug 2004 08:42:18 -0600 From: Robin Schoonover To: "Petr Holub" Message-Id: <20040831084218.08086b9f@sed> In-Reply-To: <07d201c48f30$8b2f46b0$02e86cc2@KLOBOUCEK> References: <07d201c48f30$8b2f46b0$02e86cc2@KLOBOUCEK> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.71, clamav-milter version 0.71 X-Virus-Status: Clean cc: current@freebsd.org Subject: Re: drm: ATI FireGL Mobility T2 patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 14:44:03 -0000 On Tue, 31 Aug 2004 10:00:12 +0200 "Petr Holub" wrote: > Hi, > > here's a short patch to make drm recognize ATI FireGL Mobility T2 > card present in IBM T41p notebook. > Last I knew, dri support in xorg/xfree did not include the FireGL cards. If this is the case, is this really at all useful? -- Robin Schoonover (aka End) # # Save the Rainforest! Eat a vegetarian! # From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 14:58:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B571916A4CE for ; Tue, 31 Aug 2004 14:58:45 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D27E943D1F for ; Tue, 31 Aug 2004 14:58:44 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7VEwSxp001382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Aug 2004 17:58:28 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i7VEwXEK034074; Tue, 31 Aug 2004 17:58:33 +0300 (EEST) (envelope-from ru) Date: Tue, 31 Aug 2004 17:58:33 +0300 From: Ruslan Ermilov To: Andre Guibert de Bruet Message-ID: <20040831145833.GA33987@ip.net.ua> References: <20040831061128.skwogkc8kw0ksoss@mail.encontacto.net> <20040831094518.D5951@alpha.siliconlandmark.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <20040831094518.D5951@alpha.siliconlandmark.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: current@freebsd.org Subject: Re: /coda/coda_fbsd.c:215: error: `NVCODA' undeclared when building kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 14:58:45 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 31, 2004 at 09:47:51AM -0400, Andre Guibert de Bruet wrote: >=20 > On Tue, 31 Aug 2004, Edwin Culp wrote: >=20 > >cc -O -pipe -D_KERNEL -DKLD_MODULE -nostdinc -I- -include > >/usr/obj/usr/src/sys/ENCONTACTO/opt_global.h -I. -I@ > >-I@/contrib/altq -I@/../inc > >lude -finline-limit=3D8000 -fno-common > >-I/usr/obj/usr/src/sys/ENCONTACTO -mno-align-long-strings > >-mpreferred-stack-boundary=3D2 -ffreestanding - > >Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes > >-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual > >-fformat-extensions - > >std=3Dc99 -c /usr/src/sys/modules/coda/../../coda/coda_fbsd.c > >/usr/src/sys/modules/coda/../../coda/coda_fbsd.c: In function > >`coda_fbsd_drvinit': > >/usr/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: > >`NVCODA' undeclared (first use in this function) > >/usr/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: > >(Each undeclared identifier is reported only once > >/usr/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: for > >each function it appears in.) > >/usr/src/sys/modules/coda/../../coda/coda_fbsd.c: In function > >`coda_fbsd_drvuninit': > >/usr/src/sys/modules/coda/../../coda/coda_fbsd.c:215: error: > >`NVCODA' undeclared (first use in this function) > >*** Error code 1 > > > >Stop in /usr/src/sys/modules/coda. > >*** Error code 1 >=20 > "Me too". I cvsup'ed again, and it does the same thing using: >=20 > Edit src/sys/modules/coda/Makefile,v > Add delta 1.14 2004.08.31.12.17.47 ru >=20 Was this a -DNOCLEAN build maybe? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBNJIZqRfpzJluFF4RAuncAKCfCB5qTg8gRZ26CCZlx1lBW5Fk9gCcDAtJ LAmXQF/PhjHjMHo5YVfyUSw= =PPMV -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 15:05:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74CEF16A4CE; Tue, 31 Aug 2004 15:05:53 +0000 (GMT) Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91F1443D48; Tue, 31 Aug 2004 15:05:52 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id i7VF5oY2076430; Tue, 31 Aug 2004 17:05:50 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Ruslan Ermilov , peter@freebsd.org From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 31 Aug 2004 17:58:33 +0300." <20040831145833.GA33987@ip.net.ua> Date: Tue, 31 Aug 2004 17:05:50 +0200 Message-ID: <76429.1093964750@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: current@freebsd.org Subject: Re: /coda/coda_fbsd.c:215: error: `NVCODA' undeclared when building kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 15:05:53 -0000 The problem is that NVCODA is not defined for the coda module. This is a fallout from peter@'s config(8) work. In message <20040831145833.GA33987@ip.net.ua>, Ruslan Ermilov writes: > >--M9NhX3UHpAaciwkO >Content-Type: text/plain; charset=us-ascii >Content-Disposition: inline >Content-Transfer-Encoding: quoted-printable > >On Tue, Aug 31, 2004 at 09:47:51AM -0400, Andre Guibert de Bruet wrote: >>=20 >> On Tue, 31 Aug 2004, Edwin Culp wrote: >>=20 >> >cc -O -pipe -D_KERNEL -DKLD_MODULE -nostdinc -I- -include >> >/usr/obj/usr/src/sys/ENCONTACTO/opt_global.h -I. -I@ >> >-I@/contrib/altq -I@/../inc >> >lude -finline-limit=3D8000 -fno-common >> >-I/usr/obj/usr/src/sys/ENCONTACTO -mno-align-long-strings >> >-mpreferred-stack-boundary=3D2 -ffreestanding - >> >Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes >> >-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual >> >-fformat-extensions - >> >std=3Dc99 -c /usr/src/sys/modules/coda/../../coda/coda_fbsd.c >> >/usr/src/sys/modules/coda/../../coda/coda_fbsd.c: In function >> >`coda_fbsd_drvinit': >> >/usr/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: >> >`NVCODA' undeclared (first use in this function) >> >/usr/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: >> >(Each undeclared identifier is reported only once >> >/usr/src/sys/modules/coda/../../coda/coda_fbsd.c:205: error: for >> >each function it appears in.) >> >/usr/src/sys/modules/coda/../../coda/coda_fbsd.c: In function >> >`coda_fbsd_drvuninit': >> >/usr/src/sys/modules/coda/../../coda/coda_fbsd.c:215: error: >> >`NVCODA' undeclared (first use in this function) >> >*** Error code 1 >> > >> >Stop in /usr/src/sys/modules/coda. >> >*** Error code 1 >>=20 >> "Me too". I cvsup'ed again, and it does the same thing using: >>=20 >> Edit src/sys/modules/coda/Makefile,v >> Add delta 1.14 2004.08.31.12.17.47 ru >>=20 >Was this a -DNOCLEAN build maybe? > > >Cheers, >--=20 >Ruslan Ermilov >ru@FreeBSD.org >FreeBSD committer > >--M9NhX3UHpAaciwkO >Content-Type: application/pgp-signature >Content-Disposition: inline > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.2.5 (FreeBSD) > >iD8DBQFBNJIZqRfpzJluFF4RAuncAKCfCB5qTg8gRZ26CCZlx1lBW5Fk9gCcDAtJ >LAmXQF/PhjHjMHo5YVfyUSw= >=PPMV >-----END PGP SIGNATURE----- > >--M9NhX3UHpAaciwkO-- > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 15:08:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAA8416A4CE; Tue, 31 Aug 2004 15:08:00 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D13C43D53; Tue, 31 Aug 2004 15:08:00 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7VF7tUk004154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Aug 2004 18:07:56 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i7VF81va034285; Tue, 31 Aug 2004 18:08:01 +0300 (EEST) (envelope-from ru) Date: Tue, 31 Aug 2004 18:08:01 +0300 From: Ruslan Ermilov To: Poul-Henning Kamp Message-ID: <20040831150801.GA34264@ip.net.ua> References: <20040831145833.GA33987@ip.net.ua> <76429.1093964750@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <76429.1093964750@critter.freebsd.dk> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: peter@freebsd.org cc: current@freebsd.org Subject: Re: /coda/coda_fbsd.c:215: error: `NVCODA' undeclared when building kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 15:08:01 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 31, 2004 at 05:05:50PM +0200, Poul-Henning Kamp wrote: >=20 > The problem is that NVCODA is not defined for the coda module. >=20 > This is a fallout from peter@'s config(8) work. >=20 Yes, but my fix to sys/modules/coda/Makefile was supposed to fix it. > In message <20040831145833.GA33987@ip.net.ua>, Ruslan Ermilov writes: > >On Tue, Aug 31, 2004 at 09:47:51AM -0400, Andre Guibert de Bruet wrote: > >> >/usr/src/sys/modules/coda/../../coda/coda_fbsd.c:215: error: > >> >`NVCODA' undeclared (first use in this function) > >> >*** Error code 1 > >> > > >> >Stop in /usr/src/sys/modules/coda. > >> >*** Error code 1 > >> "Me too". I cvsup'ed again, and it does the same thing using: > >>=20 [...] > >> Edit src/sys/modules/coda/Makefile,v > >> Add delta 1.14 2004.08.31.12.17.47 ru > >>=20 > >Was this a -DNOCLEAN build maybe? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBNJRRqRfpzJluFF4RApkSAJ0cWvFvBIf9qOd/6wXUuzOsf3jiLgCfUYV5 Y6pcnSBbuJGgGVN5znNt/4U= =Y1vK -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 15:14:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2425316A4CE for ; Tue, 31 Aug 2004 15:14:50 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8D1543D2D for ; Tue, 31 Aug 2004 15:14:49 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.11/8.12.11) id i7VFEbW1013401; Tue, 31 Aug 2004 10:14:37 -0500 (CDT) (envelope-from dan) Date: Tue, 31 Aug 2004 10:14:37 -0500 From: Dan Nelson To: Vladimir Grebenschikov Message-ID: <20040831151437.GE33896@dan.emsphone.com> References: <1093948080.29903.14.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1093948080.29903.14.camel@localhost> X-OS: FreeBSD 5.3-BETA2 X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: "current@freebsd.org" Subject: Re: sysutils/strace wilderness on 6-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 15:14:50 -0000 In the last episode (Aug 31), Vladimir Grebenschikov said: > (fresh -CURREMT and fresh strace from ports, UP machine) > > It silmple does nothing - sleeps foreaver in suspended: > > # strace /bin/ls > ^T > load: 0.14 cmd: strace 98957 [suspended] 0.00u 0.00s 0% 760k > ^C > # This has happened on 5.x for ages. The quick fix is to ^Z, then fg, or kill -CONT the hung strace process from another vty. I don't know what strace does different from truss that makes it hang. Nowadays, truss does almost as good a job as strace, so I don't use it as often as I used to. The only thing I miss is strace's ability to print the name of blocking syscalls (read or sleep for example) as it waits. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 15:21:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5AE7016A4CE; Tue, 31 Aug 2004 15:21:19 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8257443D69; Tue, 31 Aug 2004 15:21:18 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from pooker.samsco.org (scottl@localhost [127.0.0.1]) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i7VFKtpi071605; Tue, 31 Aug 2004 09:20:55 -0600 (MDT) (envelope-from scottl@freebsd.org) Received: from localhost (scottl@localhost)i7VFKscE071602; Tue, 31 Aug 2004 09:20:54 -0600 (MDT) (envelope-from scottl@freebsd.org) X-Authentication-Warning: pooker.samsco.org: scottl owned process doing -bs Date: Tue, 31 Aug 2004 09:20:54 -0600 (MDT) From: Scott Long Sender: scottl@pooker.samsco.org To: Ruslan Ermilov In-Reply-To: <20040831150801.GA34264@ip.net.ua> Message-ID: <20040831091908.E59291@pooker.samsco.org> References: <20040831145833.GA33987@ip.net.ua> <76429.1093964750@critter.freebsd.dk> <20040831150801.GA34264@ip.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Poul-Henning Kamp cc: current@freebsd.org cc: peter@freebsd.org Subject: Re: /coda/coda_fbsd.c:215: error: `NVCODA' undeclared when building kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 15:21:19 -0000 On Tue, 31 Aug 2004, Ruslan Ermilov wrote: > On Tue, Aug 31, 2004 at 05:05:50PM +0200, Poul-Henning Kamp wrote: > > > > The problem is that NVCODA is not defined for the coda module. > > > > This is a fallout from peter@'s config(8) work. > > > Yes, but my fix to sys/modules/coda/Makefile was supposed to fix it. Both the coda and coda5 modules needed fixing. I fixed coda5 and did a successful 'make kernel' afterwards. It would be nice if the coda code was actually fixed to not need NVCODA at all. Scott From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 15:23:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 27C1B16A4CE; Tue, 31 Aug 2004 15:23:58 +0000 (GMT) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5EBC43D5D; Tue, 31 Aug 2004 15:23:57 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (andy@localhost [127.0.0.1]) i7VFNs3b049243; Tue, 31 Aug 2004 11:23:54 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)i7VFNsRJ049240; Tue, 31 Aug 2004 11:23:54 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Tue, 31 Aug 2004 11:23:54 -0400 (EDT) From: Andre Guibert de Bruet To: Ruslan Ermilov In-Reply-To: <20040831150801.GA34264@ip.net.ua> Message-ID: <20040831112257.B5951@alpha.siliconlandmark.com> References: <20040831145833.GA33987@ip.net.ua> <76429.1093964750@critter.freebsd.dk> <20040831150801.GA34264@ip.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean cc: Poul-Henning Kamp cc: current@freebsd.org cc: peter@freebsd.org Subject: Re: /coda/coda_fbsd.c:215: error: `NVCODA' undeclared when building kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 15:23:58 -0000 On Tue, 31 Aug 2004, Ruslan Ermilov wrote: > On Tue, Aug 31, 2004 at 05:05:50PM +0200, Poul-Henning Kamp wrote: >> >> The problem is that NVCODA is not defined for the coda module. >> >> This is a fallout from peter@'s config(8) work. >> > Yes, but my fix to sys/modules/coda/Makefile was supposed to fix it. Breakage occurs even when using freshly clean'ed sources. Regards, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 15:25:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1A4116A4CE; Tue, 31 Aug 2004 15:25:18 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 708BA43D46; Tue, 31 Aug 2004 15:25:18 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i7VFPRwW020339; Tue, 31 Aug 2004 08:25:27 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i7VFPRsQ020338; Tue, 31 Aug 2004 08:25:27 -0700 Date: Tue, 31 Aug 2004 08:25:27 -0700 From: Brooks Davis To: Scott Long Message-ID: <20040831152527.GA19278@odin.ac.hmc.edu> References: <20040831145833.GA33987@ip.net.ua> <76429.1093964750@critter.freebsd.dk> <20040831150801.GA34264@ip.net.ua> <20040831091908.E59291@pooker.samsco.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <20040831091908.E59291@pooker.samsco.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Poul-Henning Kamp cc: current@freebsd.org cc: peter@freebsd.org Subject: Re: /coda/coda_fbsd.c:215: error: `NVCODA' undeclared when building kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 15:25:18 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 31, 2004 at 09:20:54AM -0600, Scott Long wrote: >=20 >=20 > On Tue, 31 Aug 2004, Ruslan Ermilov wrote: >=20 > > On Tue, Aug 31, 2004 at 05:05:50PM +0200, Poul-Henning Kamp wrote: > > > > > > The problem is that NVCODA is not defined for the coda module. > > > > > > This is a fallout from peter@'s config(8) work. > > > > > Yes, but my fix to sys/modules/coda/Makefile was supposed to fix it. >=20 > Both the coda and coda5 modules needed fixing. I fixed coda5 and did > a successful 'make kernel' afterwards. It would be nice if the coda > code was actually fixed to not need NVCODA at all. I have code to fix this, but no way to test it: http://people.freebsd.org/~brooks/patches/coda.diff The patch probably doesn't quite apply cleanly, but the rejects should be trivial. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBNJhmXY6L6fI4GtQRAkXDAJ9Lyvc9Am+XUz/TpO7gTMuGyjSVBACfew8B 7p6tZiqDoBvilvk9c0wDt2M= =1/qf -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 15:31:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F00DC16A4CF for ; Tue, 31 Aug 2004 15:31:12 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F97A43D1D for ; Tue, 31 Aug 2004 15:31:12 +0000 (GMT) (envelope-from phil.brennan@gmail.com) Received: by mproxy.gmail.com with SMTP id v18so180241rnb for ; Tue, 31 Aug 2004 08:31:12 -0700 (PDT) Received: by 10.38.8.48 with SMTP id 48mr2043968rnh; Tue, 31 Aug 2004 08:31:11 -0700 (PDT) Received: by 10.38.179.6 with HTTP; Tue, 31 Aug 2004 08:31:11 -0700 (PDT) Message-ID: Date: Tue, 31 Aug 2004 16:31:11 +0100 From: Phil Brennan To: Wilko Bulte In-Reply-To: <20040830191325.GA53006@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040829151021.GA43674@bobbi.cse.buffalo.edu> <20040830191325.GA53006@freebie.xs4all.nl> cc: freebsd-current@freebsd.org cc: freebsd-alpha@freebsd.org cc: Ken Smith Subject: Re: Addendum: FreeBSD 5.3-BETA2 for Alpha/AXP Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Phil Brennan List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 15:31:13 -0000 On an alphaserver 200 4/66, it locks solid on "entering kernel". Will be trying on an alphaserver 800 shortly. On Mon, 30 Aug 2004 21:13:25 +0200, Wilko Bulte wrote: > Coming soon to an ftp-server near you: > > FreeBSD 5.3-BETA2 for the Alpha architecture: > > MD5 (5.3-BETA2-alpha-bootonly.iso) = 1354f160d76f4aa55734bd16e6588f1e > MD5 (5.3-BETA2-alpha-disc2.iso) = 8f872b6efbbad457578b78e915a0a0c8 > MD5 (5.3-BETA2-alpha-miniinst.iso) = cdbb21822df84c94d3a1912d8d7ea2bb > > Test status I try to keep up to date at: > > http://people.freebsd.org/~wilko/testhw.html > > Enjoy.. > > -- > Wilko Bulte wilko@FreeBSD.org > > > From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 15:34:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 444BA16A4CE for ; Tue, 31 Aug 2004 15:34:09 +0000 (GMT) Received: from wrzx35.rz.uni-wuerzburg.de (wrzx35.rz.uni-wuerzburg.de [132.187.3.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0C6343D5D for ; Tue, 31 Aug 2004 15:34:06 +0000 (GMT) (envelope-from q@uni.de) Received: from wrzx34.rz.uni-wuerzburg.de (wrzx34.rz.uni-wuerzburg.de [132.187.3.34]) by wrzx35.rz.uni-wuerzburg.de (Postfix) with ESMTP id B6B87D9D4E; Tue, 31 Aug 2004 17:34:05 +0200 (CEST) Received: from virusscan (localhost [127.0.0.1]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id 95E5BA24D3; Tue, 31 Aug 2004 17:34:05 +0200 (CEST) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx34.rz.uni-wuerzburg.de (Postfix) with ESMTP id 6F3B39E6AD; Tue, 31 Aug 2004 17:34:05 +0200 (CEST) Received: from coyote.q.local (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id 5DC11D3E10; Tue, 31 Aug 2004 17:34:05 +0200 (CEST) Received: from igor.q.local (igor [192.168.0.148]) by coyote.q.local (8.12.10/8.12.10) with ESMTP id i7VFY5TH070550; Tue, 31 Aug 2004 17:34:05 +0200 (CEST) (envelope-from q@igor.q.local) Received: from igor.q.local (localhost [127.0.0.1]) by igor.q.local (8.13.1/8.13.1) with ESMTP id i7VFY59A081098; Tue, 31 Aug 2004 17:34:05 +0200 (CEST) (envelope-from q@igor.q.local) Received: (from q@localhost) by igor.q.local (8.13.1/8.13.1/Submit) id i7VFY4ml081097; Tue, 31 Aug 2004 17:34:04 +0200 (CEST) (envelope-from q) Date: Tue, 31 Aug 2004 17:34:04 +0200 From: Ulrich Spoerlein To: splinter cell Message-ID: <20040831153404.GD703@galgenberg.net> Mail-Followup-To: splinter cell , freebsd-current@freebsd.org References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="c3bfwLpm8qysLVxt" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) cc: freebsd-current@freebsd.org Subject: Re: your mail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 15:34:09 -0000 --c3bfwLpm8qysLVxt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 31.08.2004 at 11:05:45 +0200, splinter cell wrote: > Hello , my kernel has crashed because i have nad lines in my > loader.conf : > netgraph_load=3D"YES" > if_tap_load=3D"YES" > ng_ether_load=3D"YES" > ng_bridge_load=3D"YES" > ng_socket_load=3D"YES" > and i don't how to delete this lines because i am on ddb now.The > message of the panic : > panic: mutex "tapmtx" 0x0a27d80 already initialised.Anyone have a > solution for delete this lines in my /boot/loader.conf ? In the loader, escape to the prompt, 'unload', 'load kernel', 'boot -s', then 'mount -u /; mount /usr; vi /boot/loader.conf' You did read UPDATING about recompiling the Netgraph modules? Ulrich Spoerlein --=20 PGP Key ID: F0DB9F44 Get it while it's hot! PGP Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin --c3bfwLpm8qysLVxt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBNJpsmArGtfDbn0QRAtpYAJ9/bOWyriIGArKKiJiiA88UjcgDVQCfcq/j eYqZJQJ8MBcI6XyiXYV+fFw= =934V -----END PGP SIGNATURE----- --c3bfwLpm8qysLVxt-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 15:38:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21C5B16A4CE for ; Tue, 31 Aug 2004 15:38:28 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 863E643D31 for ; Tue, 31 Aug 2004 15:38:27 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so150524rnl for ; Tue, 31 Aug 2004 08:38:26 -0700 (PDT) Received: by 10.38.83.80 with SMTP id g80mr923112rnb; Tue, 31 Aug 2004 08:38:26 -0700 (PDT) Received: by 10.38.75.25 with HTTP; Tue, 31 Aug 2004 08:38:26 -0700 (PDT) Message-ID: <790a9fff0408310838554f37fb@mail.gmail.com> Date: Tue, 31 Aug 2004 10:38:26 -0500 From: Scot Hetzel To: splinter cell In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: cc: freebsd-current@freebsd.org Subject: Re: X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Scot Hetzel List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 15:38:28 -0000 On Tue, 31 Aug 2004 11:05:45 +0200, splinter cell wrote: > > Hello , my kernel has crashed because i have nad lines in my > loader.conf : > netgraph_load="YES" > if_tap_load="YES" > ng_ether_load="YES" > ng_bridge_load="YES" > ng_socket_load="YES" > and i don't how to delete this lines because i am on ddb now.The > message of the panic : > panic: mutex "tapmtx" 0x0a27d80 already initialised.Anyone have a > solution for delete this lines in my /boot/loader.conf ? > You just need to hit the space bar as the loader is booting the system (before the kernel loads), then at the loader prompt you need to set these to NO with: set if_tap_load="NO" : set ng_socket_load="NO" boot Scot From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 15:40:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 856C216A4CE; Tue, 31 Aug 2004 15:40:11 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26C5843D31; Tue, 31 Aug 2004 15:40:11 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from pooker.samsco.org (scottl@localhost [127.0.0.1]) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i7VFdmN1071724; Tue, 31 Aug 2004 09:39:48 -0600 (MDT) (envelope-from scottl@freebsd.org) Received: from localhost (scottl@localhost)i7VFdmSv071721; Tue, 31 Aug 2004 09:39:48 -0600 (MDT) (envelope-from scottl@freebsd.org) X-Authentication-Warning: pooker.samsco.org: scottl owned process doing -bs Date: Tue, 31 Aug 2004 09:39:48 -0600 (MDT) From: Scott Long Sender: scottl@pooker.samsco.org To: Andre Guibert de Bruet In-Reply-To: <20040831112257.B5951@alpha.siliconlandmark.com> Message-ID: <20040831093846.R59291@pooker.samsco.org> References: <20040831145833.GA33987@ip.net.ua> <76429.1093964750@critter.freebsd.dk> <20040831112257.B5951@alpha.siliconlandmark.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Poul-Henning Kamp cc: current@freebsd.org cc: peter@freebsd.org Subject: Re: /coda/coda_fbsd.c:215: error: `NVCODA' undeclared when building kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 15:40:11 -0000 On Tue, 31 Aug 2004, Andre Guibert de Bruet wrote: > > On Tue, 31 Aug 2004, Ruslan Ermilov wrote: > > > On Tue, Aug 31, 2004 at 05:05:50PM +0200, Poul-Henning Kamp wrote: > >> > >> The problem is that NVCODA is not defined for the coda module. > >> > >> This is a fallout from peter@'s config(8) work. > >> > > Yes, but my fix to sys/modules/coda/Makefile was supposed to fix it. > > Breakage occurs even when using freshly clean'ed sources. > > Regards, > Andy It should be fixed now that both coda and coda5 have been addressed. If it's not, make sure that you have rev 1.2 of /sys/modules/coda5/Makefile. Scott From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 15:45:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A007D16A4CE for ; Tue, 31 Aug 2004 15:45:59 +0000 (GMT) Received: from mail.if.lt (hermes.ifnet.lt [195.190.141.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1005443D5A for ; Tue, 31 Aug 2004 15:45:58 +0000 (GMT) (envelope-from vd@vmunix.lt) Received: from zeus.sampo.vlan (p2.ifnet.lt [195.190.141.35]) by mail.if.lt (IF NOC MAIL) with ESMTP id DA92B481F7 for ; Tue, 31 Aug 2004 18:45:24 +0300 (EEST) Date: Tue, 31 Aug 2004 18:45:24 +0300 (EEST) From: Vaidas Damosevicius To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Message-Id: <20040831154524.DA92B481F7@mail.if.lt> Subject: Strange boot block/loader problems with SATA on -BETA1,2 and -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 15:45:59 -0000 Hello, I have very strange problem on 3 different i386 boxes. All of them is running -CURRENT and powered by SATA. After the reboot on 3 different boxes I see the same error: Missing Operating System. I've tried to restore boot block using LiveCD, but after the reboot problem comes back to me. Same situation with 5.3-BETA1 and BETA2. vd From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 16:08:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6341516A503 for ; Tue, 31 Aug 2004 16:08:08 +0000 (GMT) Received: from cqgigw.cqg.com (cqgigw.cqg.com [208.48.16.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3897D43D2F for ; Tue, 31 Aug 2004 16:08:08 +0000 (GMT) (envelope-from tomc@cqg.com) Received: from cqgmail.cqg.com (int.cqg.com [96.0.0.2])i7VG86bG027077 for ; Tue, 31 Aug 2004 10:08:06 -0600 Received: from d3stomc ([192.168.17.154]) by cqgmail.cqg.com (8.12.8/8.12.8) with ESMTP id i7VG83S6011926 for ; Tue, 31 Aug 2004 10:08:03 -0600 From: "Tom Connolly" To: Date: Tue, 31 Aug 2004 10:08:03 -0600 Message-ID: <009801c48f74$b1ddadd0$9a11a8c0@d3stomc> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.181 Importance: Normal X-MailScanner: Found to be clean, Found to be clean X-MailScanner-Information: Please contact the ISP for more information X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=0.201, required 3, HTML_60_70 0.10, HTML_FONTCOLOR_UNKNOWN 0.10, HTML_MESSAGE 0.00) Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: cvsup current question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 16:08:08 -0000 =20 I just installed FreeBSD 5.2.1 and I'm a little confused about the = branches. >From my research I have deduced that this is a current branch and that = there is no stable branch. Is this correct? I would like to CVSup the most stable version of 5.2.1 source as well as the ports. I've tried = CVSupping the ports but none of my packages will build. I've been using the make install clean method. Can someone explain to me how exactly to do this? =20 Thanks in advance, Thomas From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 16:11:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41E5716A4CE for ; Tue, 31 Aug 2004 16:11:51 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 931A743D46 for ; Tue, 31 Aug 2004 16:11:50 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7VG9pto067493; Tue, 31 Aug 2004 10:09:51 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 31 Aug 2004 10:09:59 -0600 (MDT) Message-Id: <20040831.100959.74233910.imp@bsdimp.com> To: RoKlein@roklein.de From: "M. Warner Losh" In-Reply-To: <200408310931.06000.RoKlein@roklein.de> References: <200408281223.22399.RoKlein@roklein.de> <1093879837.30583.7.camel@buffy.york.ac.uk> <200408310931.06000.RoKlein@roklein.de> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA hangs on Acer TM290 series Laptop X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 16:11:51 -0000 In message: <200408310931.06000.RoKlein@roklein.de> Robert Klein writes: : > Try switching any "Plug and Play OS" type options in your BIOS : > to "No" or similar. This fixes at least one laptop I've tried. : : There are no "Plug an Play" options in the BIOS. It is one of : those "I know better" BIOSes... FreeBSD should operate correctly with PnP set to 'YES' starting in 5.3 or so. This problem looks like something else, however.. Warner From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 16:14:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1ED3316A4CE; Tue, 31 Aug 2004 16:14:25 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C20C43D4C; Tue, 31 Aug 2004 16:14:24 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i7VGEKgQ017510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Aug 2004 19:14:21 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i7VGEQ2P073012; Tue, 31 Aug 2004 19:14:26 +0300 (EEST) (envelope-from ru) Date: Tue, 31 Aug 2004 19:14:25 +0300 From: Ruslan Ermilov To: Andre Guibert de Bruet Message-ID: <20040831161425.GA70056@ip.net.ua> References: <20040831145833.GA33987@ip.net.ua> <76429.1093964750@critter.freebsd.dk> <20040831150801.GA34264@ip.net.ua> <20040831112257.B5951@alpha.siliconlandmark.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vtzGhvizbBRQ85DL" Content-Disposition: inline In-Reply-To: <20040831112257.B5951@alpha.siliconlandmark.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: Poul-Henning Kamp cc: current@freebsd.org cc: peter@freebsd.org Subject: Re: /coda/coda_fbsd.c:215: error: `NVCODA' undeclared when building kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 16:14:25 -0000 --vtzGhvizbBRQ85DL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 31, 2004 at 11:23:54AM -0400, Andre Guibert de Bruet wrote: >=20 > On Tue, 31 Aug 2004, Ruslan Ermilov wrote: >=20 > >On Tue, Aug 31, 2004 at 05:05:50PM +0200, Poul-Henning Kamp wrote: > >> > >>The problem is that NVCODA is not defined for the coda module. > >> > >>This is a fallout from peter@'s config(8) work. > >> > >Yes, but my fix to sys/modules/coda/Makefile was supposed to fix it. >=20 > Breakage occurs even when using freshly clean'ed sources. >=20 Are you sure that it happened in sys/modules/coda and not sys/modules/coda5? Both needed fixing, and Scott fixed coda5 (using my fix as a template, thanks Scott!) a bit later. I will not be able to test it myself in the next two hours. :-( Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --vtzGhvizbBRQ85DL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBNKPhqRfpzJluFF4RAimdAJwPXQbxk/CaA+YXNezhYCLM3GmIRACghd59 3tKp3HY7j35zIJtdw8mQITE= =1adM -----END PGP SIGNATURE----- --vtzGhvizbBRQ85DL-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 16:15:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B175C16A4CE for ; Tue, 31 Aug 2004 16:15:55 +0000 (GMT) Received: from mailhost.nmt.edu (mailhost.nmt.edu [129.138.4.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCD2543D5D for ; Tue, 31 Aug 2004 16:15:54 +0000 (GMT) (envelope-from wcolburn@nmt.edu) Received: from icewing.nmt.edu (icewing.nmt.edu [129.138.4.102]) by mailhost.nmt.edu (8.13.0/8.13.0) with ESMTP id i7VGFlRY025738 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 31 Aug 2004 10:15:48 -0600 Received: from icewing.nmt.edu (localhost [127.0.0.1]) by icewing.nmt.edu (8.12.8/8.12.8) with ESMTP id i7VGFlgp026949; Tue, 31 Aug 2004 10:15:47 -0600 Received: (from wcolburn@localhost) by icewing.nmt.edu (8.12.8/8.12.8/Submit) id i7VGFi7s026947; Tue, 31 Aug 2004 10:15:44 -0600 Date: Tue, 31 Aug 2004 10:15:44 -0600 From: "William D. Colburn (aka Schlake)" To: Tom Connolly Message-ID: <20040831161544.GA26930@nmt.edu> References: <009801c48f74$b1ddadd0$9a11a8c0@d3stomc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <009801c48f74$b1ddadd0$9a11a8c0@d3stomc> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: cvsup current question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 16:15:55 -0000 The stablest 5 I've found is to use RELENG_5_2 as your release when you cvsup. The lockd dies in that version, so use a release of just . and src-sbin instead of src-all if you need lockd support. Also, don't run samba and quotas or you panic the kernel. Also, experimentation reveals that questions about 5.2 asked here are ignored, but if you ask them in the freebsd-stable list then people will answer you (but also chastise you for not asking them here where they actually belong). That is how I got all my help at least. :/ On Tue, Aug 31, 2004 at 10:08:03AM -0600, Tom Connolly wrote: >I just installed FreeBSD 5.2.1 and I'm a little confused about the branches. >>From my research I have deduced that this is a current branch and that there >is no stable branch. Is this correct? I would like to CVSup the most >stable version of 5.2.1 source as well as the ports. I've tried CVSupping >the ports but none of my packages will build. I've been using the make >install clean method. Can someone explain to me how exactly to do this? > > > >Thanks in advance, > >Thomas > >_______________________________________________ >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" -- William Colburn, "Sysprog" Computer Center, New Mexico Institute of Mining and Technology http://www.nmt.edu/tcc/ http://www.nmt.edu/~wcolburn From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 16:34:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3174716A4CE; Tue, 31 Aug 2004 16:34:19 +0000 (GMT) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D805343D60; Tue, 31 Aug 2004 16:34:18 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (andy@localhost [127.0.0.1]) i7VGYDIG049808; Tue, 31 Aug 2004 12:34:13 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)i7VGYDjb049805; Tue, 31 Aug 2004 12:34:13 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Tue, 31 Aug 2004 12:34:13 -0400 (EDT) From: Andre Guibert de Bruet To: Ruslan Ermilov In-Reply-To: <20040831161425.GA70056@ip.net.ua> Message-ID: <20040831122623.U5951@alpha.siliconlandmark.com> References: <20040831145833.GA33987@ip.net.ua> <76429.1093964750@critter.freebsd.dk> <20040831112257.B5951@alpha.siliconlandmark.com> <20040831161425.GA70056@ip.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-MailScanner-Information: Please contact the ISP for more information X-MailScanner: Found to be clean cc: Poul-Henning Kamp cc: current@freebsd.org cc: peter@freebsd.org Subject: Re: /coda/coda_fbsd.c:215: error: `NVCODA' undeclared when building kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 16:34:19 -0000 On Tue, 31 Aug 2004, Ruslan Ermilov wrote: > On Tue, Aug 31, 2004 at 11:23:54AM -0400, Andre Guibert de Bruet wrote: >> On Tue, 31 Aug 2004, Ruslan Ermilov wrote: >>> On Tue, Aug 31, 2004 at 05:05:50PM +0200, Poul-Henning Kamp wrote: >>>> >>>> The problem is that NVCODA is not defined for the coda module. >>>> >>>> This is a fallout from peter@'s config(8) work. >>>> >>> Yes, but my fix to sys/modules/coda/Makefile was supposed to fix it. >> >> Breakage occurs even when using freshly clean'ed sources. >> > Are you sure that it happened in sys/modules/coda and not > sys/modules/coda5? Both needed fixing, and Scott fixed > coda5 (using my fix as a template, thanks Scott!) a bit > later. I will not be able to test it myself in the next > two hours. :-( Unfortunately, I didn't build under script and do not have the message on hand. It is quite possible that it broke in coda5 the second time around, as Scott's commit appears to have made it go through. Good work guys! :) Regards, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 16:39:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09DFE16A4E7 for ; Tue, 31 Aug 2004 16:39:46 +0000 (GMT) Received: from mail.halls.colostate.edu (halls-mailgw.acns.colostate.edu [129.82.100.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1C4043D58 for ; Tue, 31 Aug 2004 16:39:45 +0000 (GMT) (envelope-from end@endif.cjb.net) Received: from sed (inge068149.halls.colostate.edu [129.82.68.149]) i7VGdiXt016186; Tue, 31 Aug 2004 10:39:45 -0600 Date: Tue, 31 Aug 2004 10:38:02 -0600 From: Robin Schoonover To: "Petr Holub" Message-Id: <20040831103802.24c58839@sed> In-Reply-To: <084901c48f6d$36fbdee0$02e86cc2@KLOBOUCEK> References: <20040831084218.08086b9f@sed> <084901c48f6d$36fbdee0$02e86cc2@KLOBOUCEK> X-Mailer: Sylpheed-Claws 0.9.12 (GTK+ 1.2.10; i386-portbld-freebsd5.2.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version 0.71, clamav-milter version 0.71 X-Virus-Status: Clean cc: current@freebsd.org Subject: Re: drm: ATI FireGL Mobility T2 patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 16:39:46 -0000 On Tue, 31 Aug 2004 17:14:30 +0200 "Petr Holub" wrote: > > Last I knew, dri support in xorg/xfree did not include the FireGL > > cards. If this is the case, is this really at all useful? > > Yep. But it will be ready when the support is added to xorg/xfree. > That's the reason of the patch. > I had no idea anyone had enough information to work on support for -any- of the newer ati cards. But if someone is actually working on the dri side, then I say awesome. -- Robin Schoonover (aka End) # # To define recursion, we must first define recursion. # From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 17:24:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3479B16A4CF for ; Tue, 31 Aug 2004 17:24:01 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBEF543D64 for ; Tue, 31 Aug 2004 17:24:00 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.11/8.12.11) id i7VHNtAB073920; Tue, 31 Aug 2004 12:23:55 -0500 (CDT) (envelope-from dan) Date: Tue, 31 Aug 2004 12:23:55 -0500 From: Dan Nelson To: Gary Jennejohn Message-ID: <20040831172354.GF33896@dan.emsphone.com> References: <20040831151437.GE33896@dan.emsphone.com> <200408311705.i7VH5R2A073646@peedub.jennejohn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200408311705.i7VH5R2A073646@peedub.jennejohn.org> X-OS: FreeBSD 5.3-BETA2 X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: Vladimir Grebenschikov cc: "current@freebsd.org" Subject: Re: sysutils/strace wilderness on 6-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 17:24:01 -0000 In the last episode (Aug 31), Gary Jennejohn said: > Dan Nelson writes: > > In the last episode (Aug 31), Vladimir Grebenschikov said: > > > It silmple does nothing - sleeps foreaver in suspended: > > > > > > # strace /bin/ls > > > > This has happened on 5.x for ages. The quick fix is to ^Z, then > > fg, or kill -CONT the hung strace process from another vty. I > > don't know what strace does different from truss that makes it > > hang. Nowadays, truss does almost as good a job as strace, so I > > don't use it as often as I used to. The only thing I miss is > > strace's ability to print the name of blocking syscalls (read or > > sleep for example) as it waits. > > > > I fixed a bug like this in strace for Linux. The SIGCHLD handler was > being set too late and the child (through some wacky handling of > SIGCHLD in the Linux kernel) got into a state where it never returned > the expected status in wait(). Both the child and strace ended up > hanging. kill -CONT also got things going there. Maybe FreeBSD has a > similar problem? Dunno. Strace is a port built from the sources at sourceforge, so I assume that any Linux fixes would also be included. I see the port is at 4.5.1 but sourceforge is up to 4.5.7. Maybe a newer version works better? -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 17:37:05 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD8DE16A4CF; Tue, 31 Aug 2004 17:37:05 +0000 (GMT) Received: from smtp-vbr5.xs4all.nl (smtp-vbr5.xs4all.nl [194.109.24.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2287543D45; Tue, 31 Aug 2004 17:37:05 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr5.xs4all.nl (8.12.11/8.12.11) with ESMTP id i7VHb407002443; Tue, 31 Aug 2004 19:37:04 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.11/8.12.9) with ESMTP id i7VHb4YJ059477; Tue, 31 Aug 2004 19:37:04 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.12.11/8.12.11/Submit) id i7VHb4lo059476; Tue, 31 Aug 2004 19:37:04 +0200 (CEST) (envelope-from wb) Date: Tue, 31 Aug 2004 19:37:04 +0200 From: Wilko Bulte To: Phil Brennan Message-ID: <20040831173704.GB59433@freebie.xs4all.nl> References: <20040829151021.GA43674@bobbi.cse.buffalo.edu> <20040830191325.GA53006@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.10-STABLE X-PGP: finger wilko@freebsd.org X-Virus-Scanned: by XS4ALL Virus Scanner cc: freebsd-current@freebsd.org cc: freebsd-alpha@freebsd.org cc: Ken Smith Subject: Re: Addendum: FreeBSD 5.3-BETA2 for Alpha/AXP Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 17:37:06 -0000 On Tue, Aug 31, 2004 at 04:31:11PM +0100, Phil Brennan wrote.. > On an alphaserver 200 4/66, it locks solid on "entering kernel". Will > be trying on an alphaserver 800 shortly. :-( Are you sure your console setting is correct, what does SHOW CONSOLE at the >>> prompt tell you? > On Mon, 30 Aug 2004 21:13:25 +0200, Wilko Bulte wrote: > > Coming soon to an ftp-server near you: > > > > FreeBSD 5.3-BETA2 for the Alpha architecture: > > > > MD5 (5.3-BETA2-alpha-bootonly.iso) = 1354f160d76f4aa55734bd16e6588f1e > > MD5 (5.3-BETA2-alpha-disc2.iso) = 8f872b6efbbad457578b78e915a0a0c8 > > MD5 (5.3-BETA2-alpha-miniinst.iso) = cdbb21822df84c94d3a1912d8d7ea2bb > > > > Test status I try to keep up to date at: > > > > http://people.freebsd.org/~wilko/testhw.html > > > > Enjoy.. > > > > -- > > Wilko Bulte wilko@FreeBSD.org > > > > > > --- end of quoted text --- -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 17:44:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43B6D16A4CE; Tue, 31 Aug 2004 17:44:16 +0000 (GMT) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6D5143D66; Tue, 31 Aug 2004 17:44:15 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.12.11/8.12.11/NinthNine) with SMTP id i7VHiEWl009249; Wed, 1 Sep 2004 02:44:14 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Wed, 1 Sep 2004 02:44:14 +0900 (JST) Message-Id: <200408311744.i7VHiEWl009249@sakura.ninth-nine.com> From: Norikatsu Shigemura To: Robert Watson In-Reply-To: References: <200408301502.i7UF2L7f030909@sakura.ninth-nine.com> X-Mailer: Sylpheed version 0.9.12-gtk2-20040622 (GTK+ 2.4.9; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (sakura.ninth-nine.com [219.127.74.121]); Wed, 01 Sep 2004 02:44:14 +0900 (JST) cc: freebsd-current@FreeBSD.org cc: nork@FreeBSD.org Subject: Re: ping6 -f panic with mpsafenet=1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 17:44:16 -0000 On Mon, 30 Aug 2004 22:41:12 -0400 (EDT) Robert Watson wrote: > > > I contacted a panic on current with debug.mpsafenet=1. > > > - - - - - - - - - - > > > # ping6 -f othermachine > > (snip) > > INET6 with FAST_IPSEC will contact panic. But INET6 with > > KAME_IPSEC is safe, because forced disable mpsafenet on boot. > Do you get a panic with INET6 and FAST_IPSEC yet with mpsafenet disabled? Yes, I confirmed that INET6 and FAST_IPSEC with debug.mpsafenet=0 doesn't causes panic. From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 17:52:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1D8316A4CE; Tue, 31 Aug 2004 17:52:12 +0000 (GMT) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FF8A43D2D; Tue, 31 Aug 2004 17:52:12 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.12.11/8.12.11/NinthNine) with SMTP id i7VHqB6B009470; Wed, 1 Sep 2004 02:52:11 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Wed, 1 Sep 2004 02:52:11 +0900 (JST) Message-Id: <200408311752.i7VHqB6B009470@sakura.ninth-nine.com> From: Norikatsu Shigemura To: rwatson@FreeBSD.org In-Reply-To: <200408311744.i7VHiEWl009249@sakura.ninth-nine.com> References: <200408301502.i7UF2L7f030909@sakura.ninth-nine.com> <200408311744.i7VHiEWl009249@sakura.ninth-nine.com> X-Mailer: Sylpheed version 0.9.12-gtk2-20040622 (GTK+ 2.4.9; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (sakura.ninth-nine.com [219.127.74.121]); Wed, 01 Sep 2004 02:52:11 +0900 (JST) cc: freebsd-current@FreeBSD.org cc: nork@FreeBSD.org Subject: Re: ping6 -f panic with mpsafenet=1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 17:52:12 -0000 On Wed, 1 Sep 2004 02:44:14 +0900 (JST) Norikatsu Shigemura wrote: > > > > I contacted a panic on current with debug.mpsafenet=1. > > > > - - - - - - - - - - > > > > # ping6 -f othermachine > > > (snip) > > > INET6 with FAST_IPSEC will contact panic. But INET6 with > > > KAME_IPSEC is safe, because forced disable mpsafenet on boot. > > Do you get a panic with INET6 and FAST_IPSEC yet with mpsafenet disabled? > Yes, I confirmed that INET6 and FAST_IPSEC with debug.mpsafenet=0 ~~~ Oops "No" > doesn't causes panic. Pointed out by: hrs From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 18:18:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3391016A4CE for ; Tue, 31 Aug 2004 18:18:47 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FA8543D46 for ; Tue, 31 Aug 2004 18:18:45 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 7AC1AFD06B; Tue, 31 Aug 2004 11:18:44 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44662-02; Tue, 31 Aug 2004 11:18:43 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 81CA4FD011; Tue, 31 Aug 2004 11:18:43 -0700 (PDT) From: Sean McNeil To: Oliver Brandmueller In-Reply-To: <20040831102849.GD52217@e-Gitt.NET> References: <1093919355.39775.2.camel@server.mcneil.com> <20040831102849.GD52217@e-Gitt.NET> Content-Type: text/plain Message-Id: <1093976323.44906.2.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 31 Aug 2004 11:18:43 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: current@freebsd.org Subject: Re: RELENG_5 ipfw problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 18:18:47 -0000 On Tue, 2004-08-31 at 03:28, Oliver Brandmueller wrote: > Hi. > > On Mon, Aug 30, 2004 at 07:29:15PM -0700, Sean McNeil wrote: > > How are you compiling ipfw2? I have it built into my kernel and have no > > issues at all. Are you using it as a loadable module or part of the > > kernel? > > Meanwhile (as I wrote in the thread) I have IPFW compiled in by using > options IPFIREWALL and options IPFIREWALL_FORWARD - which is now > mandatory to have forwarding support. Sorry, this must have been clipped out of the messages I saw. > When you say "no issues at all", do you also use forwarding to change > the next hop of IP packets? This seems to be the only problem and is a > very special setup. I am not changing the next hop myself. I'm using NAT on the forwarding side. Guess this is changing the packets differently than your special case. Sean From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 18:52:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43F9416A4CE for ; Tue, 31 Aug 2004 18:52:50 +0000 (GMT) Received: from web41403.mail.yahoo.com (web41403.mail.yahoo.com [66.218.93.69]) by mx1.FreeBSD.org (Postfix) with SMTP id 16F4643D49 for ; Tue, 31 Aug 2004 18:52:50 +0000 (GMT) (envelope-from davemac11@yahoo.com) Message-ID: <20040831185249.85083.qmail@web41403.mail.yahoo.com> Received: from [168.91.4.66] by web41403.mail.yahoo.com via HTTP; Tue, 31 Aug 2004 11:52:49 PDT Date: Tue, 31 Aug 2004 11:52:49 -0700 (PDT) From: Dave McCammon To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: 5.3 Beta2 bridging (update) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 18:52:50 -0000 original message with (syctl variables, ipfw output and dmesg) http://docs.FreeBSD.org/cgi/mid.cgi?20040826204237.44644.qmail Test: move cable from ip'd port to non-ip'd port and ping known address. ip'd port = em0 non ip'd port = em1 cvsupped sources today and rebuilt world and kernel installed kernel rebooted and installed world and mergemastered. ng_bridge now works...but i need ipfw to filter per interface and, by the man page, ng_bridge and ipfw don't play together like that yet. So, I need to use bridge(4) and that still doesn't work. What I have found is I can ping the ip'd port(em0) when the cable is plugged into the non-ip'd port(em1) but cannot ping out em1 to other machines. tcpdump -i em1 shows broadcast packets from other machines but no ping packets during the above ping "out" attempt. I attempted to force 100baseTX full-duplex instead of auto-negotiate but it didn't work. (I thought maybe something is quirky with the em driver and the switch.) Any help or tips is greatly appreciated. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 19:13:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7266916A4CE for ; Tue, 31 Aug 2004 19:13:01 +0000 (GMT) Received: from mail.loquefaltaba.com (78.Red-213-96-97.pooles.rima-tde.net [213.96.97.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04E6043D53 for ; Tue, 31 Aug 2004 19:13:00 +0000 (GMT) (envelope-from sico@loquefaltaba.com) Received: from localhost (localhost.loquefaltaba.com [127.0.0.1]) by sico.loquefaltaba.com (Postfix) with ESMTP id 33367AB0A for ; Tue, 31 Aug 2004 20:52:28 +0200 (CEST) Received: from sico.loquefaltaba.com ([127.0.0.1]) by localhost (sico.loquefaltaba.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34940-05 for ; Tue, 31 Aug 2004 20:52:24 +0200 (CEST) Received: from webmail.loquefaltaba.com (localhost.loquefaltaba.com [127.0.0.1]) by sico.loquefaltaba.com (Postfix) with SMTP id CC8E0AAF2 for ; Tue, 31 Aug 2004 20:52:24 +0200 (CEST) Received: from 192.168.0.98 (SquirrelMail authenticated user sico) by webmail.loquefaltaba.com with HTTP; Tue, 31 Aug 2004 20:52:24 +0200 (CEST) Message-ID: <49283.192.168.0.98.1093978344.squirrel@webmail.loquefaltaba.com> Date: Tue, 31 Aug 2004 20:52:24 +0200 (CEST) From: "David Barbero" To: current@freebsd.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Virus-Scanned: by amavisd-new at loquefaltaba.com Subject: Problem with sound in 5.3-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 19:13:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all. I have a problem with the sound driver snd_fm801, I tryed load snd_fm801 as module and compile in to the kernel but this not recognize this card. This card work properly on FreeBSD 4.7. Version of FreeBSD: FreeBSD michelle.loquefaltaba.com 5.3-BETA2 FreeBSD 5.3-BETA2 #5: Tue Aug 31 17:47:29 CEST 2004 root@michelle.loquefaltaba.com:/usr/obj/usr/src/sys/MICHELLE i386 cvsup day 31-08-2004 with RELENG_5 Information of Sound Card: Terratec 512i pciconf information: none10@pci1:7:0: class=0x040100 card=0x13191319 chip=0x08011319 rev=0xb2 hdr=0x00 vendor = 'Forte Media, Inc.' device = 'FM801 Xwave PCI audio controller' class = multimedia subclass = audio fm801.c version: $FreeBSD: src/sys/dev/sound/pci/fm801.c,v 1.23 2004/07/16 03:59:27 tanimura Exp $ Thk for all. - -- "Linux is for people who hate Windows, BSD is for people who love UNIX" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iQIVAwUBQTTI6FzCah3DrEDZAQJ37A//bGQwGjQW5jTEcFlYaR5WMnl4NsQebqC2 PFlgMtEhubNTgrrqFirG2L/WNT42omd3vqd9j57moHjlNf+mHZCvkwuQdRJ0FuJp ikmixSOZ5a/2movAwjMPpYrBdWj1FxOYAQeUPnclLxWsGsf3vxUrL+Lnq/koyYTU CEmBvcAAjmvrtPY7YxfS5TqP6FDnkUx34fNQvtzWBsEOePDyl4PrCY75AVUgU2Yk AtgZvj22hKh40XmK55JkSeFhcknU8mQBDZQN1hkscNs+f2eN1c3SgX9ZXxxAoYVS wDtcTGDAch6ICRlOxKPdgIXlLiheFNZ01CFWU/9sjoDSD+RlHPVLob9gjQBAljjj SqnJQysInRepuCWlgKq2yblRdNKQsWyV63YLX65GkQnNxkxVJQ4jLUOh61xcGL87 CTVWj9e3jWlmVNTBkxfTp7TWuv5TnJJuUaOXzRFwMgw5gYPwlppkko9z70xHnMUt QuK8/jqB7uYY7JwBrycQT8azZ55nejxuYfQTSlhhywPVbOGXrkjXkwNM6UioRjN6 N6qvse23YOhd5/ecgHtLBkxhjM8Uz0X+4Vh+hiIYbaPYSI0d7RZMSozgrLJ0CIfE pImQfkCQjn8Ct9BhUOQidosWtkVtM9zyHtrclXufowt24CK+LTkzYhduYqbpQn8Y A2gq990VAGQ= =rAlX -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 19:16:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B88C16A4CE for ; Tue, 31 Aug 2004 19:16:10 +0000 (GMT) Received: from viefep19-int.chello.at (viefep11-int.chello.at [213.46.255.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 105B143D31 for ; Tue, 31 Aug 2004 19:16:09 +0000 (GMT) (envelope-from tom@kmem.org) Received: from shuttle.kmem.org ([213.245.62.139]) by viefep19-int.chello.atSMTP <20040831191607.GRIS19938.viefep19-int.chello.at@shuttle.kmem.org> for ; Tue, 31 Aug 2004 21:16:07 +0200 Received: (qmail 67712 invoked by uid 6003); 31 Aug 2004 19:16:06 -0000 Received: from tom@kmem.org by j2.kmem.org by uid 89 with qmail-scanner-1.22-st-qms (clamdscan: 0.73. spamassassin: 2.63. Clear:RC:1(192.168.1.13):. Processed in 0.844325 secs); 31 Aug 2004 19:16:06 -0000 X-Antivirus-MYDOMAIN-Mail-From: tom@kmem.org via j2.kmem.org X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:1(192.168.1.13):. Processed in 0.844325 secs Process 67707) Received: from j2.kmem.org (HELO webmail.kmem.org) (192.168.1.13) by shuttle.kmem.org with SMTP; 31 Aug 2004 19:16:05 -0000 Received: from 83.146.61.204 (SquirrelMail authenticated user tom@kmem.org) by j2.kmem.org with HTTP; Tue, 31 Aug 2004 19:16:05 -0000 (GMT) Message-ID: <2215.83.146.61.204.1093979765.squirrel@j2.kmem.org> Date: Tue, 31 Aug 2004 19:16:05 -0000 (GMT) From: "Tom Dymond" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Subject: odd question with /dev/tty X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: tom@kmem.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 19:16:10 -0000 Hello group I've got a strange problem on this machine : FreeBSD bat.xxx.xxx.org 5.3-BETA2 FreeBSD 5.3-BETA2 #0: Mon Aug 30 19:03:00 BST 2004 tom@xxx.xxx.org:/usr/obj/usr/src/sys/GENERIC i386 On this machine i installed a few jails, each jail has it's own root, procfs, devfs so the typical jail is like this : /dev/ad0s3f 4.8G 546M 3.9G 12% /usr/jails/j3 procfs 4.0K 4.0K 0B 100% /usr/jails/j3/proc devfs 1.0K 1.0K 0B 100% /usr/jails/j3/dev I installed vncserver from ports along with xorg to give users a graphical workspace I installed blackbox windowmanager from ports I launch vncserver after modifying my xstartup script and it powers up blackbox with a xterm. but impossible to open another xterm from the blackbox menu... it doesn't do anything nor produce any output, so i look in the I first think of maybe the $PATH wasn't set correctly so i modified the menu so it uses the absolute path, but that didn't change anything and on the initial xterm, i did a quick echo $PATH which reported this : 19:53|tom@bat:~/.vnc> echo $PATH /sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/home/tom/bin 19:57|tom@bat:~/.vnc> which xterm /usr/X11R6/bin/xterm So i checked the VNC log, and saw this cat $HOME/.vnc/`hostname`:1.log xterm: Error 14, errno 2: No such file or directory Reason: spawn: open() failed on /dev/tty xterm: Error 14, errno 2: No such file or directory Reason: spawn: open() failed on /dev/tty xterm: Error 14, errno 2: No such file or directory Reason: spawn: open() failed on /dev/tty xterm: Error 14, errno 2: No such file or directory Reason: spawn: open() failed on /dev/tty xterm: Error 14, errno 2: No such file or directory Reason: spawn: open() failed on /dev/tty Thanks in advance for *any* help on this. -tom From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 19:43:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FAC116A4CE for ; Tue, 31 Aug 2004 19:43:31 +0000 (GMT) Received: from mailserv1.neuroflux.com (mailserv1.neuroflux.com [204.228.228.92]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5ED743D48 for ; Tue, 31 Aug 2004 19:43:30 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 41930 invoked by uid 89); 31 Aug 2004 19:49:21 -0000 Received: from unknown (HELO www2.neuroflux.com) (127.0.0.1) by localhost with SMTP; 31 Aug 2004 19:49:21 -0000 Received: from 208.4.77.15 (SquirrelMail authenticated user ryans@gamersimpact.com) by www2.neuroflux.com with HTTP; Tue, 31 Aug 2004 13:49:21 -0600 (MDT) Message-ID: <50241.208.4.77.15.1093981761.squirrel@www2.neuroflux.com> Date: Tue, 31 Aug 2004 13:49:21 -0600 (MDT) From: "Ryan Sommers" To: current@freebsd.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Subject: Periodic security X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 19:43:31 -0000 Slight modification to the loginfail script for periodics. This will catch sshd, proftpd and su errors, as well as other programs, better. --- 800.loginfail Mon Aug 30 21:50:50 2004 +++ 800.loginfail Mon Aug 30 21:51:53 2004 @@ -59,7 +59,7 @@ [Yy][Ee][Ss]) echo "" echo "${host} login failures:" - n=$(catmsgs | grep -ia "^$yesterday.*fail" | + n=$(catmsgs | egrep -ia "^$yesterday.*(fail|invalid|bad|illegal)" | tee /dev/stderr | wc -l) [ $n -gt 0 ] && rc=1 || rc=0;; *) rc=0;; -- Ryan "leadZERO" Sommers Gamer's Impact President ryans@gamersimpact.com ICQ: 1019590 AIM/MSN: leadZERO -= http://www.gamersimpact.com =- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 19:49:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8428E16A4CE for ; Tue, 31 Aug 2004 19:49:55 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F9AE43D2D for ; Tue, 31 Aug 2004 19:49:53 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin07-en2 [10.13.10.152]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7VJnoJd008282; Tue, 31 Aug 2004 12:49:50 -0700 (PDT) Received: from [192.168.1.6] (pool-68-160-193-218.ny325.east.verizon.net [68.160.193.218]) (authenticated bits=0)i7VJnSWd022597; Tue, 31 Aug 2004 12:49:35 -0700 (PDT) In-Reply-To: References: <20040829213449.GA33843@hub.freebsd.org> <20040830135311.11040.qmail@web50603.mail.yahoo.com> <20040830163106.GA19044@dragon.nuxi.com> <20040830210817.GB749@galgenberg.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Charles Swiger Date: Tue, 31 Aug 2004 15:49:28 -0400 To: des@des.no (=?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?=) X-Mailer: Apple Mail (2.619) cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 19:49:55 -0000 On Aug 31, 2004, at 4:36 AM, Dag-Erling Sm=F8rgrav wrote: > Ulrich Spoerlein writes: >> On Mon, 30.08.2004 at 09:31:06 -0700, David O'Brien wrote: >>> Note, though, that this output has nothing to do with mergemaster --=20= >>> it >>> is sdiff(1) that is used. What you don't like is sdiff(1)'s output >>> format. >> Looks like one can't configure the used keys... > > Feel free to submit a patch. OK. Submitted as gnu/71210, diffs to the code are at: http://www.pkix.net/~chuck/sdiff.diff ...since the PR may have space-stuffed tabs. --=20 -Chuck From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 19:53:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 816A316A4CE for ; Tue, 31 Aug 2004 19:53:22 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64FE043D4C for ; Tue, 31 Aug 2004 19:53:22 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i7VJrUea024353; Tue, 31 Aug 2004 12:53:30 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i7VJrTmk024351; Tue, 31 Aug 2004 12:53:29 -0700 Date: Tue, 31 Aug 2004 12:53:29 -0700 From: Brooks Davis To: Charles Swiger Message-ID: <20040831195329.GB21995@odin.ac.hmc.edu> References: <20040829213449.GA33843@hub.freebsd.org> <20040830135311.11040.qmail@web50603.mail.yahoo.com> <20040830163106.GA19044@dragon.nuxi.com> <20040830210817.GB749@galgenberg.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xXmbgvnjoT4axfJE" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 19:53:22 -0000 --xXmbgvnjoT4axfJE Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 31, 2004 at 03:49:28PM -0400, Charles Swiger wrote: > On Aug 31, 2004, at 4:36 AM, Dag-Erling Sm=F8rgrav wrote: > >Ulrich Spoerlein writes: > >>On Mon, 30.08.2004 at 09:31:06 -0700, David O'Brien wrote: > >>>Note, though, that this output has nothing to do with mergemaster --= =20 > >>>it > >>>is sdiff(1) that is used. What you don't like is sdiff(1)'s output > >>>format. > >>Looks like one can't configure the used keys... > > > >Feel free to submit a patch. >=20 > OK. Submitted as gnu/71210, diffs to the code are at: >=20 > http://www.pkix.net/~chuck/sdiff.diff >=20 > ...since the PR may have space-stuffed tabs. The environment variable seems like a good idea. Changing the default is a very bad one. My finger memory is just fine with sdiff and a change would suck. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --xXmbgvnjoT4axfJE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBNNc4XY6L6fI4GtQRAi4ZAJ4wpeBuoyCoVgzByjtnXz90I46YsgCdErnA k0HKjRFPz+y5wPM0GhsHrBQ= =0k48 -----END PGP SIGNATURE----- --xXmbgvnjoT4axfJE-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 20:18:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E11216A4CE for ; Tue, 31 Aug 2004 20:18:35 +0000 (GMT) Received: from postal3.es.net (postal3.es.net [198.128.3.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B68A43D48 for ; Tue, 31 Aug 2004 20:18:35 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal3.es.net (Postal Node 3) with ESMTP (SSL) id IBA74465; Tue, 31 Aug 2004 13:18:34 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id BF6FA5D0A; Tue, 31 Aug 2004 13:18:34 -0700 (PDT) To: "David Barbero" In-reply-to: Your message of "Tue, 31 Aug 2004 20:52:24 +0200." <49283.192.168.0.98.1093978344.squirrel@webmail.loquefaltaba.com> Date: Tue, 31 Aug 2004 13:18:34 -0700 From: "Kevin Oberman" Message-Id: <20040831201834.BF6FA5D0A@ptavv.es.net> cc: current@freebsd.org Subject: Re: Problem with sound in 5.3-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 20:18:35 -0000 > Date: Tue, 31 Aug 2004 20:52:24 +0200 (CEST) > From: "David Barbero" > Sender: owner-freebsd-current@freebsd.org > > Hi all. > > I have a problem with the sound driver snd_fm801, I tryed load snd_fm801 > as module and compile in to the kernel but this not recognize this card. > This card work properly on FreeBSD 4.7. I don't think the patch that allows devices ending in numerics to work properly has been committed to RELENG_5, so you need to enclose the name in quotation marks. This is fixed in CURRENT and I suspect it will be in RELENG_5 fairly soon. Until then, kldload "snd_fm801" has a better chance of working. (Or device "snd_fm801" if you are building it into the kernel.) If you actually tried to load with the quotation marks, please ignore this. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 20:20:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D90216A4CE for ; Tue, 31 Aug 2004 20:20:47 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECDC443D41 for ; Tue, 31 Aug 2004 20:20:46 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7VKKjIT011640; Tue, 31 Aug 2004 13:20:45 -0700 (PDT) Received: from [192.168.1.6] (pool-68-160-193-218.ny325.east.verizon.net [68.160.193.218]) (authenticated bits=0)i7VKKMd2004335; Tue, 31 Aug 2004 13:20:28 -0700 (PDT) In-Reply-To: <20040831195329.GB21995@odin.ac.hmc.edu> References: <20040829213449.GA33843@hub.freebsd.org> <20040830135311.11040.qmail@web50603.mail.yahoo.com> <20040830163106.GA19044@dragon.nuxi.com> <20040830210817.GB749@galgenberg.net> <20040831195329.GB21995@odin.ac.hmc.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2F14AAB9-FB8B-11D8-B6F3-003065A20588@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Tue, 31 Aug 2004 16:20:21 -0400 To: Brooks Davis X-Mailer: Apple Mail (2.619) cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 20:20:47 -0000 On Aug 31, 2004, at 3:53 PM, Brooks Davis wrote: > On Tue, Aug 31, 2004 at 03:49:28PM -0400, Charles Swiger wrote: >> OK. Submitted as gnu/71210, diffs to the code are at: >> >> http://www.pkix.net/~chuck/sdiff.diff >> >> ...since the PR may have space-stuffed tabs. > > The environment variable seems like a good idea. Changing the default > is a very bad one. My finger memory is just fine with sdiff and a > change would suck. While I agree that preserving reasonable defaults should be done, there seems to be serious disagreement as to whether the current defaults actually do make sense. :-) I am content to let any interested committer make that decision, but I ask that whoever first go through a trial mergemaster session using '1' & '2' as the keys. 'q' and 'e' are right there, and I found the improvement compared to using 'l' & 'r' immediately obvious and more intuitive. Your mileage may vary. -- -Chuck From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 20:23:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 362D216A4CE for ; Tue, 31 Aug 2004 20:23:58 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8680C43D48 for ; Tue, 31 Aug 2004 20:23:57 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i7VKNt4N014164; Tue, 31 Aug 2004 22:23:56 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <4134DE3C.7080303@DeepCore.dk> Date: Tue, 31 Aug 2004 22:23:24 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "J.R. Oldroyd" References: <412F5A10.8080907@drexel.edu> <412F7292.6000804@DeepCore.dk> <20040830181540.GA809@linwhf.opal.com> <413372B3.5010603@DeepCore.dk> <20040830192224.GB809@linwhf.opal.com> <413390B9.5050705@DeepCore.dk> <20040831144205.GA817@linwhf.opal.com> In-Reply-To: <20040831144205.GA817@linwhf.opal.com> Content-Type: multipart/mixed; boundary="------------020100020404000900040006" cc: current@freebsd.org Subject: Re: Current 8/27/2004, DVD problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 20:23:58 -0000 This is a multi-part message in MIME format. --------------020100020404000900040006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable J.R. Oldroyd wrote: > Some follow-up. >=20 > Similar to other folks with this problem, the system will boot in > verbose mode. However, ONLY with no medium. If medium is present, > it still hangs. If the tray is empty, it will boot in either DMA or > PIO mode. And if I then insert a disc, I can read it OK. Hmm does the attached patch change behavior in any way ? -S=F8ren --------------020100020404000900040006 Content-Type: text/plain; name="ata_wait-patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ata_wait-patch" Index: ata-lowlevel.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ata/ata-lowlevel.c,v retrieving revision 1.44 diff -u -r1.44 ata-lowlevel.c --- ata-lowlevel.c 16 Aug 2004 09:32:35 -0000 1.44 +++ ata-lowlevel.c 24 Aug 2004 07:25:32 -0000 @@ -721,6 +721,12 @@ rman_get_start(atadev->channel->r_io[ATA_DATA].res), command, (intmax_t)lba, count, feature); + /* ready to issue command ? */ + if (ata_wait(atadev, 0) < 0) { + ata_prtdev(atadev, "timeout waiting for ready command=%02x\n", command); + return -1; + } + /* select device */ ATA_IDX_OUTB(atadev->channel, ATA_DRIVE, ATA_D_IBM | atadev->unit); --------------020100020404000900040006-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 20:31:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9A3816A4CE for ; Tue, 31 Aug 2004 20:31:21 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5C8843D53 for ; Tue, 31 Aug 2004 20:31:21 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i7VKVVGC029744; Tue, 31 Aug 2004 13:31:31 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i7VKVVSx029742; Tue, 31 Aug 2004 13:31:31 -0700 Date: Tue, 31 Aug 2004 13:31:31 -0700 From: Brooks Davis To: Charles Swiger Message-ID: <20040831203131.GA25134@odin.ac.hmc.edu> References: <20040829213449.GA33843@hub.freebsd.org> <20040830135311.11040.qmail@web50603.mail.yahoo.com> <20040830163106.GA19044@dragon.nuxi.com> <20040830210817.GB749@galgenberg.net> <20040831195329.GB21995@odin.ac.hmc.edu> <2F14AAB9-FB8B-11D8-B6F3-003065A20588@mac.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: <2F14AAB9-FB8B-11D8-B6F3-003065A20588@mac.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 20:31:22 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 31, 2004 at 04:20:21PM -0400, Charles Swiger wrote: > On Aug 31, 2004, at 3:53 PM, Brooks Davis wrote: > >On Tue, Aug 31, 2004 at 03:49:28PM -0400, Charles Swiger wrote: > >>OK. Submitted as gnu/71210, diffs to the code are at: > >> > >>http://www.pkix.net/~chuck/sdiff.diff > >> > >>...since the PR may have space-stuffed tabs. > > > >The environment variable seems like a good idea. Changing the default > >is a very bad one. My finger memory is just fine with sdiff and a > >change would suck. >=20 > While I agree that preserving reasonable defaults should be done, there= =20 > seems to be serious disagreement as to whether the current defaults=20 > actually do make sense. :-) >=20 > I am content to let any interested committer make that decision, but I=20 > ask that whoever first go through a trial mergemaster session using=20 > '1' & '2' as the keys. 'q' and 'e' are right there, and I found the=20 > improvement compared to using 'l' & 'r' immediately obvious and more=20 > intuitive. I agree the current default is confusing and counterintuitive, at least at first. That's not the point. The point is that it's been that way for ages and changing it would gratuitously screw all the users who have adapted to it. There's no reason why you couldn't preserve the old behavior by default and in fact I'd request a back out of any commit that didn't. I don't opposes adding a second set of keys such as 1 and 2, just breaking the old behavior. On the personal preference front, on a bad RSI day, forcing me to use my left hand in that corner of the keyboard for a large merge (say the whitespace at EOL or nojail changes) would cause me serious pain. :-P -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBNOAiXY6L6fI4GtQRAuhOAJ9gq+m/AQc5wjyo0zzC92rT2a7CFwCgrSOA pFk7zZUcH/gqEJXq+RY/ibw= =6zgZ -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 20:39:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBF0916A4CE for ; Tue, 31 Aug 2004 20:39:03 +0000 (GMT) Received: from mail.loquefaltaba.com (78.Red-213-96-97.pooles.rima-tde.net [213.96.97.78]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6EDC143D5E for ; Tue, 31 Aug 2004 20:39:03 +0000 (GMT) (envelope-from sico@loquefaltaba.com) Received: from localhost (localhost.loquefaltaba.com [127.0.0.1]) by mail.loquefaltaba.com (Postfix) with ESMTP id D8FADAB14; Tue, 31 Aug 2004 22:39:08 +0200 (CEST) Received: from mail.loquefaltaba.com ([127.0.0.1]) by localhost (sico.loquefaltaba.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37052-01; Tue, 31 Aug 2004 22:39:06 +0200 (CEST) Received: from [192.168.0.98] (unknown [192.168.0.98]) by mail.loquefaltaba.com (Postfix) with ESMTP id 35C8CAAEE; Tue, 31 Aug 2004 22:39:06 +0200 (CEST) In-Reply-To: <20040831201834.BF6FA5D0A@ptavv.es.net> References: <20040831201834.BF6FA5D0A@ptavv.es.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: David Barbero Date: Tue, 31 Aug 2004 22:38:47 +0200 To: "Kevin Oberman" X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at loquefaltaba.com cc: current@freebsd.org Subject: Re: Problem with sound in 5.3-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 20:39:04 -0000 when i compile the kernel, i see LINT and take exactly this line for=20 the card: device "snd_fm801" device sound but don't work... I try to recompile kernel and load as module with kldload "snd_fm801". if this don't work, I upgrade to -CURRENT and try. the version of fm801.c work on 4.7 is: FreeBSD: src/sys/dev/sound/pci/fm801.c,v 1.3.2.6 2002/08/30 14:52:45=20 sobomax Exp Thk. --=20 "Linux is for people who hate Windows, BSD is for people who love UNIX" El 31/08/2004, a las 22:18, Kevin Oberman escribi=F3: > I don't think the patch that allows devices ending in numerics to work > properly has been committed to RELENG_5, so you need to enclose the=20 > name > in quotation marks. This is fixed in CURRENT and I suspect it will be=20= > in > RELENG_5 fairly soon. > > Until then, kldload "snd_fm801" has a better chance of working. (Or > device "snd_fm801" > if you are building it into the kernel.) > > If you actually tried to load with the quotation marks, please ignore > this. From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 20:39:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6A1116A4CE for ; Tue, 31 Aug 2004 20:39:42 +0000 (GMT) Received: from 82-168-140-74-bbxl.xdsl.tiscali.nl (82-168-140-74-bbxl.xdsl.tiscali.nl [82.168.140.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6ED6043D45 for ; Tue, 31 Aug 2004 20:39:41 +0000 (GMT) (envelope-from rene@82-168-140-74-bbxl.xdsl.tiscali.nl) Received: from 82-168-140-74-bbxl.xdsl.tiscali.nl (atmosphere.local [127.0.0.1])i7VKeCZK001131 for ; Tue, 31 Aug 2004 22:40:12 +0200 (CEST) (envelope-from rene@82-168-140-74-bbxl.xdsl.tiscali.nl) Received: (from rene@localhost)i7VKeCeH001130 for freebsd-current@freebsd.org; Tue, 31 Aug 2004 22:40:12 +0200 (CEST) (envelope-from rene) Date: Tue, 31 Aug 2004 22:40:12 +0200 From: Rene Ladan To: freebsd-current@freebsd.org Message-ID: <20040831204011.GA705@82-168-140-74-bbxl.xdsl.tiscali.nl> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: ACPI panic on Fujitsu-Siemens C6175 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 20:39:42 -0000 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, With ACPI enabled, I get the following panic scenario. This only happens in multi-user mode, on a Fujitsu Siemens C6175. BIOS revision 1.31 (latest). On a 5.2.1 system, it worked correctly. FreeBSD 5.3-BETA2 #0: Fri Aug 27 18:32:00 CEST 2004 =20 #zzz (when using APM instead of ACPI this gives a "ioctl(APMIO_SUSPEND): invalid argument" message) I then get these kernel messages: (N,x,y,z vary) --- usb0: interrupt while not operating ignored ATAPI_RESET time=3D320us ad0: WARNING - WRITE_DMA interrupt was seen but timeout fired LBA=3DN ad0: WARNING - WRITE_DMA interrupt was seen but timeout fired LBA=3DN slab at 0xc1xxxxxx, freei 12 =3D 0 panic: Duplicate free item 0xc1yyyyyy from zone 0xc1zzzzzz (g_bio) [thread 100024] Stopped at kdb_enter+0x30: leave db> panic Dumping 191MB Dump failed writing header (5) --- The "dump failed" message is strange, as 191MB should fit on a 384MB swap partition. Could this be usb-related? usbd was still running when I suspended the laptop. I also get some error messages from the AML compiler when trying to compile the AML code from acpidump -d dmesg: Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-BETA2 #0: Fri Aug 27 18:32:00 CEST 2004 root@82-168-140-74-bbxl.xdsl.tiscali.nl:/usr/obj/usr/src-releng_5/sys/R= ENE_2004-08-22d WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Celeron (497.56-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x683 Stepping =3D 3 Features=3D0x383f9ff real memory =3D 201261056 (191 MB) avail memory =3D 187260928 (178 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) acpi_ec0: port 0x66,0x62 on acpi0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe0000000-0xe3ffffff= at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pci0: at device 4.0 (no driver attached) pci0: at device 4.1 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1080-0x108f,0x376,0x170-0x1= 77,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: port 0x10a0-0x10bf irq 9 a= t device 7.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered intpm0: port 0xff80-0xff8f irq = 9 at device 7.3 on pci0 intpm0: I/O mapped ff80 intpm0: intr IRQ 9 enabled revision 0 intpm0: [GIANT-LOCKED] intsmb0: on intpm0 smbus0: on intsmb0 smb0: on smbus0 intpm0: PM I/O mapped 1000=20 pcm0: mem 0xfc110000-0xfc11ffff,0xfc101000-0= xfc101fff irq 5 at device 8.0 on pci0 pcm0: [GIANT-LOCKED] pcm0: fxp0: port 0x1040-0x107f mem 0xfc000000-0xfc= 0fffff,0xfc100000-0xfc100fff irq 9 at device 16.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:d0:59:01:ed:22 fxp0: [GIANT-LOCKED] speaker0 port 0x61 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x3 irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: flags 0x2040 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=3D0x200> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0 at vga0 Timecounter "TSC" frequency 497559355 Hz quality 800 Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. witness_get: witness exhausted acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% ad0: 5729MB [12416/15/63] at ata0-master UDMA33 ATAPI_RESET time =3D 330us acd0: CDROM at ata1-master UDMA33 Mounting root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted KDB: enter: manual escape to debugger --mYCpIKhGyMATD0i+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBNOIrbWa3bO9NFoMRAnXWAKDD+H7vEu9VV0rkJqshKgN83ju48wCeOVw0 Fazz77AYcIRb5JXa8zsbkp0= =o+Ry -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 20:41:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3177016A4E0 for ; Tue, 31 Aug 2004 20:41:12 +0000 (GMT) Received: from ns1.gluerecord.net (crimp.gluerecord.net [194.68.48.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4308743D5F for ; Tue, 31 Aug 2004 20:41:07 +0000 (GMT) (envelope-from magnus@carlebjork.se) Received: from localhost (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ns1.gluerecord.net (Postfix) with ESMTP id 6C3553F41E for ; Tue, 31 Aug 2004 22:41:05 +0200 (CEST) Date: Tue, 31 Aug 2004 22:41:05 +0200 (CEST) From: =?ISO-8859-1?Q?Magnus_Carlebj=F6rk?= X-X-Sender: mca@crimp.gluerecord.net To: current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: HighPoint RocketRAID 1820 Driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 20:41:13 -0000 Hi. Are there any plans to import the source code for the highpoint 1820? http://www.highpoint-tech.com/BIOS%20%2B%20Driver/rr1820/FreeBSD/rr182x-bsd-openbuild-v101.tgz Quoting from the readme.txt in the driver source: "THERE ARE NO RESTRICTIONS ON THE USE OF THIS FREE SOURCE CODE" Wouldn't it be nice to have a native driver? Regards, -- Magnus Carlebjork MCA14-RIPE Stockholm, Sweden +46 70 2060216 From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 20:52:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C8C316A4CE for ; Tue, 31 Aug 2004 20:52:46 +0000 (GMT) Received: from regina.plastikos.com (plastikos.com [69.38.58.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 372DF43D53 for ; Tue, 31 Aug 2004 20:52:46 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from mortis.over-yonder.net (adsl-222-87-93.jan.bellsouth.net [68.222.87.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by regina.plastikos.com (Postfix) with ESMTP id 1ACC76EF20; Tue, 31 Aug 2004 16:52:45 -0400 (EDT) Received: by mortis.over-yonder.net (Postfix, from userid 100) id 5CF4A20F83; Tue, 31 Aug 2004 15:52:43 -0500 (CDT) Date: Tue, 31 Aug 2004 15:52:43 -0500 From: "Matthew D. Fuller" To: Brooks Davis Message-ID: <20040831205243.GJ53236@over-yonder.net> References: <20040829213449.GA33843@hub.freebsd.org> <20040830135311.11040.qmail@web50603.mail.yahoo.com> <20040830163106.GA19044@dragon.nuxi.com> <20040830210817.GB749@galgenberg.net> <20040831195329.GB21995@odin.ac.hmc.edu> <2F14AAB9-FB8B-11D8-B6F3-003065A20588@mac.com> <20040831203131.GA25134@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040831203131.GA25134@odin.ac.hmc.edu> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.6i-fullermd.2 cc: Dag-Erling Sm?rgrav cc: Charles Swiger cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 20:52:46 -0000 On Tue, Aug 31, 2004 at 01:31:31PM -0700 I heard the voice of Brooks Davis, and lo! it spake thus: > > I agree the current default is confusing and counterintuitive, at > least at first. I don't! It's been a whole lotta years since I ever put any conscious thought into which hand I'm using to type a letter. I just decide to type that letter. 'l' for the left side, and 'r' for the right side make perfect sense; it would never even occur to me to think about which hand is being used. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 20:53:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A09FF16A4CE for ; Tue, 31 Aug 2004 20:53:06 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 449B543D31 for ; Tue, 31 Aug 2004 20:53:04 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.0.12] (g4.samsco.home [192.168.0.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i7VKqccr072924; Tue, 31 Aug 2004 14:52:38 -0600 (MDT) (envelope-from scottl@freebsd.org) Message-ID: <4134E4E1.7020406@freebsd.org> Date: Tue, 31 Aug 2004 14:51:45 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Magnus_Carlebj=F6rk?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: current@freebsd.org Subject: Re: HighPoint RocketRAID 1820 Driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 20:53:06 -0000 Magnus Carlebjörk wrote: > Hi. Are there any plans to import the source code for the highpoint 1820? > > http://www.highpoint-tech.com/BIOS%20%2B%20Driver/rr1820/FreeBSD/rr182x-bsd-openbuild-v101.tgz > > > Quoting from the readme.txt in the driver source: > > "THERE ARE NO RESTRICTIONS ON THE USE OF THIS FREE SOURCE CODE" > > Wouldn't it be nice to have a native driver? > > Myself and several others are discussing this with HighPoint right now. Some issues have come up that we are working through, but we hope to import the driver soon. Scott From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 20:53:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62D3C16A4CE for ; Tue, 31 Aug 2004 20:53:18 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5167143D58 for ; Tue, 31 Aug 2004 20:53:18 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 3236D7A3F9; Tue, 31 Aug 2004 13:53:18 -0700 (PDT) Message-ID: <4134E53E.8010809@elischer.org> Date: Tue, 31 Aug 2004 13:53:18 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: =?ISO-8859-1?Q?Magnus_Carlebj=F6rk?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: current@freebsd.org Subject: Re: HighPoint RocketRAID 1820 Driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 20:53:18 -0000 No that I know of, but you would be the person who would be most likely to succeed.. (Magnus runs away shouting "AAARGGGHHH I should have kept my mouth shut") We'll expect a driver from you in, say, 2 months? :-) Magnus Carlebjörk wrote: > Hi. Are there any plans to import the source code for the highpoint 1820? > > http://www.highpoint-tech.com/BIOS%20%2B%20Driver/rr1820/FreeBSD/rr182x-bsd-openbuild-v101.tgz > > Quoting from the readme.txt in the driver source: > > "THERE ARE NO RESTRICTIONS ON THE USE OF THIS FREE SOURCE CODE" > > Wouldn't it be nice to have a native driver? > > > Regards, > -- > Magnus Carlebjork MCA14-RIPE > Stockholm, Sweden +46 70 2060216 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 20:54:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C7B5E16A4CE for ; Tue, 31 Aug 2004 20:54:44 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B16743D3F for ; Tue, 31 Aug 2004 20:54:44 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i7VKsd5x014431; Tue, 31 Aug 2004 22:54:39 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <4134E56F.3020707@DeepCore.dk> Date: Tue, 31 Aug 2004 22:54:07 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Magnus_Carlebj=F6rk?= References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: current@freebsd.org Subject: Re: HighPoint RocketRAID 1820 Driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 20:54:44 -0000 Magnus Carlebj=F6rk wrote: > Hi. Are there any plans to import the source code for the highpoint 182= 0? >=20 > http://www.highpoint-tech.com/BIOS%20%2B%20Driver/rr1820/FreeBSD/rr182x= -bsd-openbuild-v101.tgz=20 >=20 >=20 > Quoting from the readme.txt in the driver source: >=20 > "THERE ARE NO RESTRICTIONS ON THE USE OF THIS FREE SOURCE CODE" >=20 > Wouldn't it be nice to have a native driver? Well it would be if it had source code with it. All the interesting bits = are in a binary .o file. That said, I'm close to finishing support for the Marvell chip used in=20 that controller as part of the ATA driver, so native support will happen = when I get time to get it finished and out the door :) -S=F8ren From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 20:55:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F251216A4D2 for ; Tue, 31 Aug 2004 20:55:35 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDBD943D1D for ; Tue, 31 Aug 2004 20:55:35 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 16634 invoked from network); 31 Aug 2004 20:55:35 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 31 Aug 2004 20:55:34 -0000 Received: from [10.50.41.228] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i7VKtUsI053946; Tue, 31 Aug 2004 16:55:31 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Tue, 31 Aug 2004 16:55:26 -0400 User-Agent: KMail/1.6.2 References: <20040826161900.GA31925@prophecy.dyndns.org> <20040828025829.GA51618@prophecy.dyndns.org> <20040827.212912.43023076.imp@bsdimp.com> In-Reply-To: <20040827.212912.43023076.imp@bsdimp.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200408311655.26332.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: midian@ihme.org cc: apeiron@comcast.net cc: "M. Warner Losh" Subject: Re: USB keyboard problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 20:55:36 -0000 On Friday 27 August 2004 11:29 pm, M. Warner Losh wrote: > In message: <20040828025829.GA51618@prophecy.dyndns.org> > > Christopher Nehren writes: > : On Fri, Aug 27, 2004 at 22:41:32 EDT, M. Warner Losh scribbled these > : > : curious markings: > : > I guess it all depends on what you mean by recently. I'd thought that > : > some of my recent changes had broken it, but the breakage goes back > : > further than that. 5.2 release isn't 'recent', and I fully believe > : > that things may have changed since then... I see a major uhid upgrade > : > in that time frame, which may be the time of breakage... > : > : I understand your point, but that doesn't sit well with the fact that my > : joypad broke *after* I updated from 5.2-CURRENT of ~ August 15 to > : 6.0-CURRENT of ~ August 19. Logically, if it had been busted by the uhid > : upgrade in March, then it could not possibly have worked with 5.2-CURRENT > : (which it did, just as well as it did with 5.2.1-RELEASE[1]), correct? > : > : [1] Better, in fact, as the device wasn't detected at boot time in 5.2.1 > : but was in 5.2-CURRENT. > > Then I'm very confused... Time to dig deeper... Alfred turned the atkbd probing off a while back: alfred 2004/04/01 13:48:31 PST FreeBSD src repository Modified files: sys/i386/conf GENERIC.hints Log: Fix booting with ps2 keyboards. Revision Changes Path 1.13 +0 -1 src/sys/i386/conf/GENERIC.hints This didn't actually affect booting with a PS/2 keyboard, but only meant that you could boot up without a PS/2 keyboard and then plug it in, at the cost of breaking all uses of USB keyboards unless you use explicit kbdcontrol commands. The instant-MFC was backed out of RELENG_4 at the request of re@ due to POLA. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 21:09:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB30A16A4CF for ; Tue, 31 Aug 2004 21:09:17 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 753E743D1F for ; Tue, 31 Aug 2004 21:09:17 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i7VL9HkN009051; Tue, 31 Aug 2004 14:09:17 -0700 (PDT) Received: from [192.168.1.6] (pool-68-160-193-218.ny325.east.verizon.net [68.160.193.218]) (authenticated bits=0)i7VL8uCv022754; Tue, 31 Aug 2004 14:09:01 -0700 (PDT) In-Reply-To: <20040831203131.GA25134@odin.ac.hmc.edu> References: <20040829213449.GA33843@hub.freebsd.org> <20040830135311.11040.qmail@web50603.mail.yahoo.com> <20040830163106.GA19044@dragon.nuxi.com> <20040830210817.GB749@galgenberg.net> <20040831195329.GB21995@odin.ac.hmc.edu> <2F14AAB9-FB8B-11D8-B6F3-003065A20588@mac.com> <20040831203131.GA25134@odin.ac.hmc.edu> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Tue, 31 Aug 2004 17:08:55 -0400 To: Brooks Davis X-Mailer: Apple Mail (2.619) cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 21:09:17 -0000 On Aug 31, 2004, at 4:31 PM, Brooks Davis wrote: >> I am content to let any interested committer make that decision, but I >> ask that whoever first go through a trial mergemaster session using >> '1' & '2' as the keys. 'q' and 'e' are right there, and I found the >> improvement compared to using 'l' & 'r' immediately obvious and more >> intuitive. > > I agree the current default is confusing and counterintuitive, at least > at first. That's not the point. The point is that it's been that way > for ages and changing it would gratuitously screw all the users who > have > adapted to it. There's no reason why you couldn't preserve the old > behavior by default and in fact I'd request a back out of any commit > that didn't. I don't opposes adding a second set of keys such as 1 and > 2, just breaking the old behavior. I am more interested in permitting users to choose which keys they prefer to use than I am in arguing what should be the default behavior of sdiff. It seems likely that if I'd commented out line 10 of my diff rather than line 9, I'd be dodging brickbats from the other side, but what the hell, the diff is the way it is because I wanted to test and see whether the changes actually made a noticable difference in usability. I came to a conclusion, but the code I submitted is more friendly about supporting individual opinions than the prior code, and your suggestion to support multiple keys for choosing left and right also sounds like a good idea-- probably more doable if one started with my changes. -- -Chuck PS: I was going to ask, Brooks, whether you could describe a process you'd tolerate for changing the default behavior of a program with unreasonable defaults? From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 21:10:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FEEB16A4CE for ; Tue, 31 Aug 2004 21:10:48 +0000 (GMT) Received: from mail2.neureal.com (mail2.neureal.com [66.98.170.78]) by mx1.FreeBSD.org (Postfix) with SMTP id 45A8343D1F for ; Tue, 31 Aug 2004 21:10:48 +0000 (GMT) (envelope-from quaggamail@quaggaspace.org) Received: (qmail 30928 invoked by uid 399); 31 Aug 2004 21:10:46 -0000 Received: from unknown (HELO ?192.168.42.25?) (141.152.240.193) by mail2.neureal.com with SMTP; 31 Aug 2004 21:10:46 -0000 From: Justin Settle To: Charles Swiger In-Reply-To: <2F14AAB9-FB8B-11D8-B6F3-003065A20588@mac.com> References: <20040829213449.GA33843@hub.freebsd.org> <20040830135311.11040.qmail@web50603.mail.yahoo.com> <20040830163106.GA19044@dragon.nuxi.com> <20040830210817.GB749@galgenberg.net> <20040831195329.GB21995@odin.ac.hmc.edu> <2F14AAB9-FB8B-11D8-B6F3-003065A20588@mac.com> Content-Type: text/plain Message-Id: <1093986646.4466.8.camel@amon.quaggaspace.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 31 Aug 2004 17:10:47 -0400 Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 21:10:48 -0000 On Tue, 2004-08-31 at 16:20, Charles Swiger wrote: > On Aug 31, 2004, at 3:53 PM, Brooks Davis wrote: > > On Tue, Aug 31, 2004 at 03:49:28PM -0400, Charles Swiger wrote: > >> OK. Submitted as gnu/71210, diffs to the code are at: > >> > >> http://www.pkix.net/~chuck/sdiff.diff > >> > >> ...since the PR may have space-stuffed tabs. > > > > The environment variable seems like a good idea. Changing the default > > is a very bad one. My finger memory is just fine with sdiff and a > > change would suck. Anyway, I'd thought I'd just say your patch is working very well here for me. I've gone with "f" and "j" as that makes far more sense to me. Use pointer finger to point which one I want and all of that. Thank you! Jay Settle From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 21:17:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F31B16A4CE for ; Tue, 31 Aug 2004 21:17:55 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 529DE43D39 for ; Tue, 31 Aug 2004 21:17:55 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i7VLI5ex004820; Tue, 31 Aug 2004 14:18:05 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i7VLI5VO004819; Tue, 31 Aug 2004 14:18:05 -0700 Date: Tue, 31 Aug 2004 14:18:05 -0700 From: Brooks Davis To: "Matthew D. Fuller" Message-ID: <20040831211805.GD25134@odin.ac.hmc.edu> References: <20040829213449.GA33843@hub.freebsd.org> <20040830135311.11040.qmail@web50603.mail.yahoo.com> <20040830163106.GA19044@dragon.nuxi.com> <20040830210817.GB749@galgenberg.net> <20040831195329.GB21995@odin.ac.hmc.edu> <2F14AAB9-FB8B-11D8-B6F3-003065A20588@mac.com> <20040831203131.GA25134@odin.ac.hmc.edu> <20040831205243.GJ53236@over-yonder.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OROCMA9jn6tkzFBc" Content-Disposition: inline In-Reply-To: <20040831205243.GJ53236@over-yonder.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Dag-Erling Sm?rgrav cc: Charles Swiger cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 21:17:55 -0000 --OROCMA9jn6tkzFBc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 31, 2004 at 03:52:43PM -0500, Matthew D. Fuller wrote: > On Tue, Aug 31, 2004 at 01:31:31PM -0700 I heard the voice of > Brooks Davis, and lo! it spake thus: > >=20 > > I agree the current default is confusing and counterintuitive, at > > least at first. >=20 > I don't! >=20 > It's been a whole lotta years since I ever put any conscious thought > into which hand I'm using to type a letter. I just decide to type > that letter. 'l' for the left side, and 'r' for the right side make > perfect sense; it would never even occur to me to think about which > hand is being used. The problem I found the first couple times I used sdiff was that the letters are neumonic. Once I got over that, I've been quite happy with them. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --OROCMA9jn6tkzFBc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBNOsMXY6L6fI4GtQRAtMBAJ4yaAxz8bq69SLEChyXnQXpbqDZiACfQDrg Ad8pcnVqzGbmS0J3iKrWQ/4= =8HA7 -----END PGP SIGNATURE----- --OROCMA9jn6tkzFBc-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 21:18:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB0FB16A4CE for ; Tue, 31 Aug 2004 21:18:56 +0000 (GMT) Received: from ack.Berkeley.EDU (ack.berkeley.edu [128.32.206.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94CE643D39 for ; Tue, 31 Aug 2004 21:18:56 +0000 (GMT) (envelope-from mhunter@ack.Berkeley.EDU) Received: (from mhunter@localhost) by ack.Berkeley.EDU (8.11.3/8.11.3) id i7VLIYm17076; Tue, 31 Aug 2004 14:18:34 -0700 (PDT) Date: Tue, 31 Aug 2004 14:18:34 -0700 From: Mike Hunter To: "Matthew D. Fuller" Message-ID: <20040831211834.GA16465@ack.Berkeley.EDU> References: <20040829213449.GA33843@hub.freebsd.org> <20040830135311.11040.qmail@web50603.mail.yahoo.com> <20040830163106.GA19044@dragon.nuxi.com> <20040830210817.GB749@galgenberg.net> <20040831195329.GB21995@odin.ac.hmc.edu> <2F14AAB9-FB8B-11D8-B6F3-003065A20588@mac.com> <20040831203131.GA25134@odin.ac.hmc.edu> <20040831205243.GJ53236@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040831205243.GJ53236@over-yonder.net> X-Troll-Content: High User-Agent: Mutt/1.5.6i cc: Dag-Erling Sm?rgrav cc: Charles Swiger cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 21:18:56 -0000 On Aug 31, "Matthew D. Fuller" wrote: > On Tue, Aug 31, 2004 at 01:31:31PM -0700 I heard the voice of > Brooks Davis, and lo! it spake thus: > > > > I agree the current default is confusing and counterintuitive, at > > least at first. > > I don't! > > It's been a whole lotta years since I ever put any conscious thought > into which hand I'm using to type a letter. I just decide to type > that letter. 'l' for the left side, and 'r' for the right side make > perfect sense; it would never even occur to me to think about which > hand is being used. I also think it's very important to consider neurology here. Quoting a medical text: * Nerves from the brain cross over at neck-level to the opposite side of the * body, and nerves from the other side of the brain reciprocate. The end * result is that the opposite sides of the body are supplied by the opposite * sides of the brain. So it's deceptive to think that using the left hand would correspond to the *idea* of something on the left. You see linux people making these kind of arguments all the time, and I'd really hate to see FreeBSD run with this idea just to "keep up with the Torvaldses." Mike From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 21:19:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B694A16A4CE for ; Tue, 31 Aug 2004 21:19:23 +0000 (GMT) Received: from ns1.gluerecord.net (crimp.gluerecord.net [194.68.48.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E89B43D2F for ; Tue, 31 Aug 2004 21:19:23 +0000 (GMT) (envelope-from magnus@carlebjork.se) Received: from localhost (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ns1.gluerecord.net (Postfix) with ESMTP id 784B53F41D for ; Tue, 31 Aug 2004 23:19:22 +0200 (CEST) Date: Tue, 31 Aug 2004 23:19:22 +0200 (CEST) From: Magnus Carlebjork X-X-Sender: mca@crimp.gluerecord.net In-Reply-To: <4134E56F.3020707@DeepCore.dk> Message-ID: References: <4134E56F.3020707@DeepCore.dk> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="0-1704024747-1093986920=:71630" Content-ID: cc: current@freebsd.org Subject: Re: HighPoint RocketRAID 1820 Driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 21:19:23 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1704024747-1093986920=:71630 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: On Tue, 31 Aug 2004, S=F8ren Schmidt wrote: > Magnus Carlebj=F6rk wrote: >> Hi. Are there any plans to import the source code for the highpoint 1820= ? >>=20 >> http://www.highpoint-tech.com/BIOS%20%2B%20Driver/rr1820/FreeBSD/rr182x-= bsd-openbuild-v101.tgz=20 >>=20 >> Quoting from the readme.txt in the driver source: >>=20 >> "THERE ARE NO RESTRICTIONS ON THE USE OF THIS FREE SOURCE CODE" >>=20 >> Wouldn't it be nice to have a native driver? > > Well it would be if it had source code with it. All the interesting bits = are=20 > in a binary .o file. Ah, I see, they do a 'cp -f raid.obj raid.o'. Interesting ;) > That said, I'm close to finishing support for the Marvell chip used in th= at=20 > controller as part of the ATA driver, so native support will happen when = I=20 > get time to get it finished and out the door :) Thank you for replying, I look forward to trying the driver once it is fini= shed! Regards, -- Magnus Carlebjork=09MCA14-RIPE Stockholm, Sweden=09+46 70 2060216 --0-1704024747-1093986920=:71630-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 21:19:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9556B16A4CF; Tue, 31 Aug 2004 21:19:48 +0000 (GMT) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A13243D45; Tue, 31 Aug 2004 21:19:48 +0000 (GMT) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (mail, from userid 1001) id 181722A9AE; Tue, 31 Aug 2004 16:19:48 -0500 (CDT) Date: Tue, 31 Aug 2004 16:19:45 -0500 From: Craig Boston To: Daniel Eriksson Message-ID: <20040831211944.GA65532@nowhere> Mail-Followup-To: Craig Boston , Daniel Eriksson , 'Lukas Ertl' , freebsd-current@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: PLEASE TEST: IPI deadlock avoidance patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 21:19:48 -0000 On Mon, Aug 30, 2004 at 08:11:58PM +0200, Daniel Eriksson wrote: > Ok, I've run a few more tests now, and the results are not looking very good > for gvinum in RAID-5 mode: I'm afraid I have to confirm these results. It took a while to get everything back up and running (had problems building world for a while because of a few key utilities that got bitten by the corruption). I have it sorted out now, and have successfully built world a few times with SMP enabled, but using regular vinum instead of gvinum -- no sign of any corrupt files. So it seems that gvinum RAID-5 is a key factor in the corruption, and SMP greatly increases the odds of it happening... Is it worth creating a PR so this doesn't get lost amid the release madness? Craig From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 21:37:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DDB916A4CE for ; Tue, 31 Aug 2004 21:37:26 +0000 (GMT) Received: from web50604.mail.yahoo.com (web50604.mail.yahoo.com [206.190.38.91]) by mx1.FreeBSD.org (Postfix) with SMTP id 9BAF443D31 for ; Tue, 31 Aug 2004 21:37:25 +0000 (GMT) (envelope-from kstailey@yahoo.com) Message-ID: <20040831213725.23604.qmail@web50604.mail.yahoo.com> Received: from [69.138.247.171] by web50604.mail.yahoo.com via HTTP; Tue, 31 Aug 2004 14:37:25 PDT Date: Tue, 31 Aug 2004 14:37:25 -0700 (PDT) From: Kenneth Stailey To: Mike Hunter , "Matthew D. Fuller" In-Reply-To: <20040831211834.GA16465@ack.Berkeley.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: Dag-Erling Sm?rgrav cc: Charles Swiger cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 21:37:26 -0000 --- Mike Hunter wrote: > On Aug 31, "Matthew D. Fuller" wrote: > > > On Tue, Aug 31, 2004 at 01:31:31PM -0700 I heard the voice of > > Brooks Davis, and lo! it spake thus: > > > > > > I agree the current default is confusing and counterintuitive, at > > > least at first. > > > > I don't! > > > > It's been a whole lotta years since I ever put any conscious thought > > into which hand I'm using to type a letter. I just decide to type > > that letter. 'l' for the left side, and 'r' for the right side make > > perfect sense; it would never even occur to me to think about which > > hand is being used. > > I also think it's very important to consider neurology here. Quoting a > medical text: > > * Nerves from the brain cross over at neck-level to the opposite side of the > * body, and nerves from the other side of the brain reciprocate. The end > * result is that the opposite sides of the body are supplied by the opposite > * sides of the brain. > > So it's deceptive to think that using the left hand would correspond to > the *idea* of something on the left. You see linux people making these > kind of arguments all the time, and I'd really hate to see FreeBSD run > with this idea just to "keep up with the Torvaldses." > > Mike I'm starting to feel sorry I said anything. I'm also starting to like Gentoo just a tiny bit more. From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 21:39:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF57816A4CE for ; Tue, 31 Aug 2004 21:39:39 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD81443D2F for ; Tue, 31 Aug 2004 21:39:39 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/MantshX 2.0) with ESMTP id i7VLddao026849; Tue, 31 Aug 2004 14:39:39 -0700 (PDT) Received: from [192.168.1.6] (pool-68-160-193-218.ny325.east.verizon.net [68.160.193.218]) (authenticated bits=0)i7VLdAki017371; Tue, 31 Aug 2004 14:39:18 -0700 (PDT) In-Reply-To: <20040831211834.GA16465@ack.Berkeley.EDU> References: <20040829213449.GA33843@hub.freebsd.org> <20040830135311.11040.qmail@web50603.mail.yahoo.com> <20040830163106.GA19044@dragon.nuxi.com> <20040830210817.GB749@galgenberg.net> <20040831195329.GB21995@odin.ac.hmc.edu> <2F14AAB9-FB8B-11D8-B6F3-003065A20588@mac.com> <20040831203131.GA25134@odin.ac.hmc.edu> <20040831205243.GJ53236@over-yonder.net> <20040831211834.GA16465@ack.Berkeley.EDU> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <312EE189-FB96-11D8-B6F3-003065A20588@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Tue, 31 Aug 2004 17:39:09 -0400 To: Mike Hunter X-Mailer: Apple Mail (2.619) cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 21:39:40 -0000 On Aug 31, 2004, at 5:18 PM, Mike Hunter wrote: [ ...bits about neurology... ] > So it's deceptive to think that using the left hand would correspond to > the *idea* of something on the left. You see linux people making these > kind of arguments all the time, and I'd really hate to see FreeBSD run > with this idea just to "keep up with the Torvaldses." For me, what seems intuitive comes from looking at column 1 and column 2 on the screen (or the comm command). Having them right next to e helps, and I use the right hand for hitting return. It seems to go much quicker for me. The thing is, there are enough people used to the current behavior and/or find it intuitive that I don't want to argue about whether to change or keep the current defaults. Such arguments drain energy and keep anybody from moving forward. -- -Chuck From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 21:49:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F26D916A4CE for ; Tue, 31 Aug 2004 21:49:50 +0000 (GMT) Received: from web50602.mail.yahoo.com (web50602.mail.yahoo.com [206.190.38.89]) by mx1.FreeBSD.org (Postfix) with SMTP id 8D4E143D39 for ; Tue, 31 Aug 2004 21:49:50 +0000 (GMT) (envelope-from kstailey@yahoo.com) Message-ID: <20040831214945.47235.qmail@web50602.mail.yahoo.com> Received: from [69.138.247.171] by web50602.mail.yahoo.com via HTTP; Tue, 31 Aug 2004 14:49:45 PDT Date: Tue, 31 Aug 2004 14:49:45 -0700 (PDT) From: Kenneth Stailey To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Problem with SiI3114 SATA RAID using 5.3-BETA1-20040823 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 21:49:51 -0000 I'm trying to upgrade a TYAN Tiger K8WS S2875S from FreeBSD-5.2.1-p8 to 5.3-BETA1-20040823. It fails because instead of seeing the SiI3114 as ar0 (RAID-1) it sees two separate disks: ad4: 194481MB [395136/16/63] at ata2-master SATA150 ad6: 194481MB [395136/16/63] at ata3-master SATA150 I don't think I should upgrade just one half of the mirror so I abort the upgrade. When booting 5.2.1-p8 GEOM: create disk ad4 dp=0xffffff003b2f6aa0 ad4: 194481MB [395136/16/63] at ata2-master UDMA100 GEOM: create disk ad6 dp=0xffffff003b2f62a0 ad6: 194481MB [395136/16/63] at ata3-master UDMA100 GEOM: create disk ar0 dp=0xffffff0000d7fa70 ar0: 194480MB [24792/255/63] status: READY subdisks: disk0 READY on ad4 at ata2-master disk1 READY on ad6 at ata3-master Mounting root from ufs:/dev/ar0s1a When booting 5.3-BETA1 Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-BETA1-20040823 #0: Mon Aug 23 11:03:37 UTC 2004 root@quynh.NUXI.org:/usr/obj/usr/src/sys/GENERIC WARNING: WITNESS option enabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Opteron(tm) Processor 246 (1993.31-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0xf58 Stepping = 8 Features=0x78bfbff AMD Features=0xe0500800 real memory = 1073676288 (1023 MB) avail memory = 1020493824 (973 MB) MADT: Forcing active-low polarity and level trigger for SCI ioapic0 irqs 0-23 on motherboard acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x5008-0x500b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pcib1: at device 1.0 on pci0 pci2: on pcib1 pci2: at device 0.0 (no driver attached) pci2: at device 0.1 (no driver attached) pcib2: at device 6.0 on pci0 pci1: on pcib2 ohci0: mem 0xff4fc000-0xff4fcfff irq 19 at device 0.0 on pci1 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xff4fd000-0xff4fdfff irq 19 at device 0.1 on pci1 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered em0: port 0x8880-0x88bf mem 0xff4a0000-0xff4bffff,0xff4c0000-0xff4dffff irq 18 at device 3.0 on pci1 em0: [GIANT-LOCKED] em0: Ethernet address: 00:e0:81:28:99:c4 em0: Speed:N/A Duplex:N/A atapci0: port 0x9400-0x940f,0x9480-0x9483,0x9800-0x9807,0x9880-0x9883,0x9c00-0x9c07 mem 0xff4ffc00-0xff4fffff irq 19 at device 5.0 on pci1 ata2: channel #0 on atapci0 ata3: channel #1 on atapci0 ata4: channel #2 on atapci0 ata5: channel #3 on atapci0 fwohci0: port 0x8c00-0x8c7f mem 0xff4ff000-0xff4ff7ff irq 17 at device 10.0 on pci1 fwohci0: [GIANT-LOCKED] fwohci0: OHCI version 1.0 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:e0:81:00:00:30:12:53 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:e0:81:30:12:53 fwe0: Ethernet address: 02:e0:81:30:12:53 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) uhci0: port 0x9000-0x901f irq 17 at device 11.0 on pci1 uhci0: [GIANT-LOCKED] usb2: on uhci0 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci1: port 0x9080-0x909f irq 18 at device 11.1 on pci1 uhci1: [GIANT-LOCKED] usb3: on uhci1 usb3: USB revision 1.0 uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered pci1: at device 11.2 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci1: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 ata0: channel #0 on atapci1 ata1: channel #1 on atapci1 pci0: at device 7.2 (no driver attached) pci0: at device 7.3 (no driver attached) pci0: at device 7.5 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 orm0: at iomem 0xcb000-0xcf7ff,0xc0000-0xcafff 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 Timecounter "TSC" frequency 1993314155 Hz quality 800 Timecounters tick every 0.976 msec md0: Preloaded image 4194304 bytes at 0xffffffff808e5db0 acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% ATAPI_RESET time = 40us acd0: CDRW at ata0-master UDMA33 ad4: 194481MB [395136/16/63] at ata2-master SATA150 ad6: 194481MB [395136/16/63] at ata3-master SATA150 Mounting root from ufs:/dev/md0 em0: Link is up 100 Mbps Full Duplex Thanks for any advice as how to upgrade this system. From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 21:51:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A10516A4CF for ; Tue, 31 Aug 2004 21:51:15 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3197643D46 for ; Tue, 31 Aug 2004 21:51:15 +0000 (GMT) (envelope-from phil.brennan@gmail.com) Received: by mproxy.gmail.com with SMTP id v30so22190rnb for ; Tue, 31 Aug 2004 14:51:14 -0700 (PDT) Received: by 10.38.1.62 with SMTP id 62mr177847rna; Tue, 31 Aug 2004 14:51:14 -0700 (PDT) Received: by 10.38.179.6 with HTTP; Tue, 31 Aug 2004 14:51:13 -0700 (PDT) Message-ID: Date: Tue, 31 Aug 2004 22:51:13 +0100 From: Phil Brennan To: Wilko Bulte In-Reply-To: <20040831173704.GB59433@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040829151021.GA43674@bobbi.cse.buffalo.edu> <20040830191325.GA53006@freebie.xs4all.nl> <20040831173704.GB59433@freebie.xs4all.nl> cc: freebsd-current@freebsd.org cc: freebsd-alpha@freebsd.org cc: Ken Smith Subject: Re: Addendum: FreeBSD 5.3-BETA2 for Alpha/AXP Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Phil Brennan List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 21:51:15 -0000 I'll post that output up tomorrow, when I get access to that machine again. In the meantime, the alphaserver 800 installed fine, but dc0 reports no carrier, there isn't even a link light on the card. This machine was working perfectly with 4.10, and reasonably with 5.2.1. Is this dc problem a known problem? On Tue, 31 Aug 2004 19:37:04 +0200, Wilko Bulte wrote: > On Tue, Aug 31, 2004 at 04:31:11PM +0100, Phil Brennan wrote.. > > On an alphaserver 200 4/66, it locks solid on "entering kernel". Will > > be trying on an alphaserver 800 shortly. > > :-( > > Are you sure your console setting is correct, what does SHOW CONSOLE at > the >>> prompt tell you? > > > On Mon, 30 Aug 2004 21:13:25 +0200, Wilko Bulte wrote: > > > Coming soon to an ftp-server near you: > > > > > > FreeBSD 5.3-BETA2 for the Alpha architecture: > > > > > > MD5 (5.3-BETA2-alpha-bootonly.iso) = 1354f160d76f4aa55734bd16e6588f1e > > > MD5 (5.3-BETA2-alpha-disc2.iso) = 8f872b6efbbad457578b78e915a0a0c8 > > > MD5 (5.3-BETA2-alpha-miniinst.iso) = cdbb21822df84c94d3a1912d8d7ea2bb > > > > > > Test status I try to keep up to date at: > > > > > > http://people.freebsd.org/~wilko/testhw.html > > > > > > Enjoy.. > > > > > > -- > > > Wilko Bulte wilko@FreeBSD.org > > > > > > > > > > --- end of quoted text --- > > > > -- > Wilko Bulte wilko@FreeBSD.org > From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 21:52:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EA9E16A4CE; Tue, 31 Aug 2004 21:52:28 +0000 (GMT) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id D69FC43D41; Tue, 31 Aug 2004 21:52:27 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr4.xs4all.nl (8.12.11/8.12.11) with ESMTP id i7VLqQHd012172; Tue, 31 Aug 2004 23:52:26 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.11/8.12.9) with ESMTP id i7VLqQ7V061384; Tue, 31 Aug 2004 23:52:26 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.12.11/8.12.11/Submit) id i7VLqQ9U061383; Tue, 31 Aug 2004 23:52:26 +0200 (CEST) (envelope-from wb) Date: Tue, 31 Aug 2004 23:52:26 +0200 From: Wilko Bulte To: Phil Brennan Message-ID: <20040831215226.GA61346@freebie.xs4all.nl> References: <20040829151021.GA43674@bobbi.cse.buffalo.edu> <20040830191325.GA53006@freebie.xs4all.nl> <20040831173704.GB59433@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.10-STABLE X-PGP: finger wilko@freebsd.org X-Virus-Scanned: by XS4ALL Virus Scanner cc: freebsd-current@freebsd.org cc: freebsd-alpha@freebsd.org cc: Ken Smith Subject: Re: Addendum: FreeBSD 5.3-BETA2 for Alpha/AXP Available X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 21:52:28 -0000 On Tue, Aug 31, 2004 at 10:51:13PM +0100, Phil Brennan wrote.. > I'll post that output up tomorrow, when I get access to that machine again. > In the meantime, the alphaserver 800 installed fine, but dc0 reports > no carrier, there isn't even a link light on the card. This machine > was working perfectly with 4.10, and reasonably with 5.2.1. Is this dc > problem a known problem? No, dc(4) is onboard on my DS10 and I use it all the time. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 21:56:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00CCB16A4CE; Tue, 31 Aug 2004 21:56:45 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1C5A43D1F; Tue, 31 Aug 2004 21:56:44 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i7VLusil010932; Tue, 31 Aug 2004 14:56:54 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i7VLusuT010931; Tue, 31 Aug 2004 14:56:54 -0700 Date: Tue, 31 Aug 2004 14:56:54 -0700 From: Brooks Davis To: John Baldwin Message-ID: <20040831215654.GF25134@odin.ac.hmc.edu> References: <20040826161900.GA31925@prophecy.dyndns.org> <20040828025829.GA51618@prophecy.dyndns.org> <20040827.212912.43023076.imp@bsdimp.com> <200408311655.26332.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="B0nZA57HJSoPbsHY" Content-Disposition: inline In-Reply-To: <200408311655.26332.jhb@FreeBSD.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: apeiron@comcast.net cc: freebsd-current@freebsd.org cc: midian@ihme.org cc: "M. Warner Losh" Subject: Re: USB keyboard problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 21:56:45 -0000 --B0nZA57HJSoPbsHY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 31, 2004 at 04:55:26PM -0400, John Baldwin wrote: > On Friday 27 August 2004 11:29 pm, M. Warner Losh wrote: > > In message: <20040828025829.GA51618@prophecy.dyndns.org> > > > > Christopher Nehren writes: > > : On Fri, Aug 27, 2004 at 22:41:32 EDT, M. Warner Losh scribbled these > > : > > : curious markings: > > : > I guess it all depends on what you mean by recently. I'd thought t= hat > > : > some of my recent changes had broken it, but the breakage goes back > > : > further than that. 5.2 release isn't 'recent', and I fully believe > > : > that things may have changed since then... I see a major uhid upgr= ade > > : > in that time frame, which may be the time of breakage... > > : > > : I understand your point, but that doesn't sit well with the fact that= my > > : joypad broke *after* I updated from 5.2-CURRENT of ~ August 15 to > > : 6.0-CURRENT of ~ August 19. Logically, if it had been busted by the u= hid > > : upgrade in March, then it could not possibly have worked with 5.2-CUR= RENT > > : (which it did, just as well as it did with 5.2.1-RELEASE[1]), correct? > > : > > : [1] Better, in fact, as the device wasn't detected at boot time in 5.= 2.1 > > : but was in 5.2-CURRENT. > > > > Then I'm very confused... Time to dig deeper... >=20 > Alfred turned the atkbd probing off a while back: >=20 > alfred 2004/04/01 13:48:31 PST >=20 > FreeBSD src repository >=20 > Modified files: > sys/i386/conf GENERIC.hints > Log: > Fix booting with ps2 keyboards. >=20 > Revision Changes Path > 1.13 +0 -1 src/sys/i386/conf/GENERIC.hints >=20 > This didn't actually affect booting with a PS/2 keyboard, but only meant = that=20 > you could boot up without a PS/2 keyboard and then plug it in, at the cos= t of=20 > breaking all uses of USB keyboards unless you use explicit kbdcontrol=20 > commands. The instant-MFC was backed out of RELENG_4 at the request of r= e@=20 > due to POLA. The following entries in my devd.conf make things much happier on my laptop. Maybe we should commit something like this to the default file: # When a keyboard arrives, attach it as the console keyboard attach 100 { device-name "ukbd0"; action "test -c /dev/kbd1 && kbdcontrol -k /dev/kbd1 < /dev/console"; } detach 100 { device-name "ukbd0"; action "kbdcontrol -k /dev/kbd0 < /dev/console"; } It has the slightly weird effect that the built in keyboard stops working for console when you plug a USB keyboard in, but IMO that's less lame then the current setup. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --B0nZA57HJSoPbsHY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBNPQlXY6L6fI4GtQRAv50AJ0aXJ+vIY5DbzErcXky5qFv5yZ3vwCfTd0t sYxcIZTv+UwrWqF2+VMPOV8= =0jyM -----END PGP SIGNATURE----- --B0nZA57HJSoPbsHY-- From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 22:02:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 103CE16A4CE; Tue, 31 Aug 2004 22:02:57 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FE6543D31; Tue, 31 Aug 2004 22:02:56 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i7VM1ii9071729; Tue, 31 Aug 2004 16:01:45 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 31 Aug 2004 16:01:54 -0600 (MDT) Message-Id: <20040831.160154.100262831.imp@bsdimp.com> To: brooks@one-eyed-alien.net From: "M. Warner Losh" In-Reply-To: <20040831215654.GF25134@odin.ac.hmc.edu> References: <20040827.212912.43023076.imp@bsdimp.com> <200408311655.26332.jhb@FreeBSD.org> <20040831215654.GF25134@odin.ac.hmc.edu> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: apeiron@comcast.net cc: freebsd-current@freebsd.org cc: midian@ihme.org Subject: Re: USB keyboard problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 22:02:57 -0000 In message: <20040831215654.GF25134@odin.ac.hmc.edu> Brooks Davis writes: : On Tue, Aug 31, 2004 at 04:55:26PM -0400, John Baldwin wrote: : > On Friday 27 August 2004 11:29 pm, M. Warner Losh wrote: : > > In message: <20040828025829.GA51618@prophecy.dyndns.org> : > > : > > Christopher Nehren writes: : > > : On Fri, Aug 27, 2004 at 22:41:32 EDT, M. Warner Losh scribbled these : > > : : > > : curious markings: : > > : > I guess it all depends on what you mean by recently. I'd thought that : > > : > some of my recent changes had broken it, but the breakage goes back : > > : > further than that. 5.2 release isn't 'recent', and I fully believe : > > : > that things may have changed since then... I see a major uhid upgrade : > > : > in that time frame, which may be the time of breakage... : > > : : > > : I understand your point, but that doesn't sit well with the fact that my : > > : joypad broke *after* I updated from 5.2-CURRENT of ~ August 15 to : > > : 6.0-CURRENT of ~ August 19. Logically, if it had been busted by the uhid : > > : upgrade in March, then it could not possibly have worked with 5.2-CURRENT : > > : (which it did, just as well as it did with 5.2.1-RELEASE[1]), correct? : > > : : > > : [1] Better, in fact, as the device wasn't detected at boot time in 5.2.1 : > > : but was in 5.2-CURRENT. : > > : > > Then I'm very confused... Time to dig deeper... : > : > Alfred turned the atkbd probing off a while back: : > : > alfred 2004/04/01 13:48:31 PST : > : > FreeBSD src repository : > : > Modified files: : > sys/i386/conf GENERIC.hints : > Log: : > Fix booting with ps2 keyboards. : > : > Revision Changes Path : > 1.13 +0 -1 src/sys/i386/conf/GENERIC.hints : > : > This didn't actually affect booting with a PS/2 keyboard, but only meant that : > you could boot up without a PS/2 keyboard and then plug it in, at the cost of : > breaking all uses of USB keyboards unless you use explicit kbdcontrol : > commands. The instant-MFC was backed out of RELENG_4 at the request of re@ : > due to POLA. : : The following entries in my devd.conf make things much happier on my : laptop. Maybe we should commit something like this to the default file: : : # When a keyboard arrives, attach it as the console keyboard : attach 100 { : device-name "ukbd0"; : action "test -c /dev/kbd1 && kbdcontrol -k /dev/kbd1 < /dev/console"; : } : detach 100 { : device-name "ukbd0"; : action "kbdcontrol -k /dev/kbd0 < /dev/console"; : } : : It has the slightly weird effect that the built in keyboard stops : working for console when you plug a USB keyboard in, but IMO that's less : lame then the current setup. Agreed. The irony is that the keyboard mux in the kernel wouldn't take much to be 'all physical keyboards feed the same logical keyboard' rather than 'ONE keyboard feeds the logical keyboard'. Just no one has gone and done it. Warner From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 22:22:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76CD916A4CE for ; Tue, 31 Aug 2004 22:22:39 +0000 (GMT) Received: from hotmail.com (bay8-f35.bay8.hotmail.com [64.4.27.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E68E43D39 for ; Tue, 31 Aug 2004 22:22:39 +0000 (GMT) (envelope-from evantd@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 15:22:39 -0700 Received: from 67.171.32.75 by by8fd.bay8.hotmail.msn.com with HTTP; Tue, 31 Aug 2004 22:22:38 GMT X-Originating-IP: [67.171.32.75] X-Originating-Email: [evantd@hotmail.com] X-Sender: evantd@hotmail.com From: "Evan Dower" To: cswiger@mac.com, brooks@one-eyed-alien.net Date: Tue, 31 Aug 2004 15:22:38 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Aug 2004 22:22:39.0223 (UTC) FILETIME=[065D2870:01C48FA9] cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 22:22:39 -0000 This seems to me like a very good idea. Some people are very accustomed to the current defaults. They can just leave things alone. I personally have to think about which key to press, so I might change the keys to something more suitable to me. Perhaps an /etc/mergemaster.conf is in order or any other mechanism for allowing key (or more accurately character) customization. I see no reason not to let everybody win. In fact, I'd be perfectly happy if you couldn't change the default keys but could only add to them. That is, r and l would always work, but you could configure it so that other letters/keys would also have the same functions. Just a thought and an opinion, -- Evan Dower Undergraduate, Computer Science University of Washington Public key: http://students.washington.edu/evantd/pgp-pub-key.txt Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D >From: Charles Swiger >To: Brooks Davis >CC: freebsd-current@freebsd.org >Subject: Re: suggestion for /usr/src/UPDATING >Date: Tue, 31 Aug 2004 17:08:55 -0400 > >On Aug 31, 2004, at 4:31 PM, Brooks Davis wrote: >>>I am content to let any interested committer make that decision, but I >>>ask that whoever first go through a trial mergemaster session using >>>'1' & '2' as the keys. 'q' and 'e' are right there, and I found the >>>improvement compared to using 'l' & 'r' immediately obvious and more >>>intuitive. >> >>I agree the current default is confusing and counterintuitive, at least >>at first. That's not the point. The point is that it's been that way >>for ages and changing it would gratuitously screw all the users who have >>adapted to it. There's no reason why you couldn't preserve the old >>behavior by default and in fact I'd request a back out of any commit >>that didn't. I don't opposes adding a second set of keys such as 1 and >>2, just breaking the old behavior. > >I am more interested in permitting users to choose which keys they prefer >to use than I am in arguing what should be the default behavior of sdiff. > >It seems likely that if I'd commented out line 10 of my diff rather than >line 9, I'd be dodging brickbats from the other side, but what the hell, >the diff is the way it is because I wanted to test and see whether the >changes actually made a noticable difference in usability. > >I came to a conclusion, but the code I submitted is more friendly about >supporting individual opinions than the prior code, and your suggestion to >support multiple keys for choosing left and right also sounds like a good >idea-- probably more doable if one started with my changes. > >-- >-Chuck > >PS: I was going to ask, Brooks, whether you could describe a process you'd >tolerate for changing the default behavior of a program with unreasonable >defaults? > >_______________________________________________ >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" _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 22:26:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0241B16A4CE; Tue, 31 Aug 2004 22:26:37 +0000 (GMT) Received: from hotmail.com (bay8-f89.bay8.hotmail.com [64.4.27.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD27E43D49; Tue, 31 Aug 2004 22:26:36 +0000 (GMT) (envelope-from evantd@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 15:26:36 -0700 Received: from 67.171.32.75 by by8fd.bay8.hotmail.msn.com with HTTP; Tue, 31 Aug 2004 22:26:36 GMT X-Originating-IP: [67.171.32.75] X-Originating-Email: [evantd@hotmail.com] X-Sender: evantd@hotmail.com From: "Evan Dower" To: wpaul@FreeBSD.ORG Date: Tue, 31 Aug 2004 15:26:36 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 31 Aug 2004 22:26:36.0725 (UTC) FILETIME=[93ED1650:01C48FA9] cc: freebsd-current@freebsd.org Subject: Re: Evil: TI ACX111 non-success X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 22:26:37 -0000 Ah well, if it's going to associate at 11g speeds anyway, then I'm perfectly happy without setting the mode. Also, I don't really care about setting the stationname. It would just make it the tiniest bit easier to identify it in the APs web config. Thanks again for getting it to work, -- Evan Dower Undergraduate, Computer Science University of Washington Public key: http://students.washington.edu/evantd/pgp-pub-key.txt Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D >From: wpaul@FreeBSD.ORG (Bill Paul) >To: evantd@hotmail.com (Evan Dower) >CC: freebsd-current@freebsd.org >Subject: Re: Evil: TI ACX111 non-success >Date: Fri, 20 Aug 2004 15:20:09 +0000 (GMT) > > > Hurray! I also got it to work, though I do get the following errors: > > # ifconfig ndis0 stationname lojak > > ifconfig: SIOCS80211: Invalid argument > >Setting the stationname isn't supported yet. I think you're supposed >to set the OID_GEN_MACHINE_NAME for that, but I never got around to >adding that to the ndis_ioctl() handler. > > > # ifconfig ndis0 mode 11g > > ifconfig: SIOCSIFMEDIA (mode): Invalid argument > >Also not supported. I'm not quite sure how to duplicate the 'mode' >behavior with NDIS. > > > Neither of these are particularly important (though I would very much >like > > the speed associate with g) because: > >Because what? Have you actually tested transfer speed with the device? >It should still associate at 802.11g speeds even though it doesn't tell >you. > >-Bill > >-- >============================================================================= >-Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu > wpaul@windriver.com | Wind River Systems >============================================================================= > you're just BEGGING to face the moose >============================================================================= _________________________________________________________________ On the road to retirement? Check out MSN Life Events for advice on how to get there! http://lifeevents.msn.com/category.aspx?cid=Retirement From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 22:44:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 855D816A4CE for ; Tue, 31 Aug 2004 22:44:25 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29C1C43D41 for ; Tue, 31 Aug 2004 22:44:25 +0000 (GMT) (envelope-from israel.herraiz@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so178231rnl for ; Tue, 31 Aug 2004 15:44:24 -0700 (PDT) Received: by 10.38.11.77 with SMTP id 77mr1832474rnk; Tue, 31 Aug 2004 15:44:24 -0700 (PDT) Received: by 10.38.164.21 with HTTP; Tue, 31 Aug 2004 15:44:22 -0700 (PDT) Message-ID: <691d00b804083115447dfb5adc@mail.gmail.com> Date: Wed, 1 Sep 2004 00:44:22 +0200 From: Israel Herraiz To: freebsd-current@freebsd.org In-Reply-To: <20040831204011.GA705@82-168-140-74-bbxl.xdsl.tiscali.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20040831204011.GA705@82-168-140-74-bbxl.xdsl.tiscali.nl> Subject: Re: ACPI panic on Fujitsu-Siemens C6175 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Israel Herraiz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 22:44:25 -0000 See this [1]. [1]. http://lists.freebsd.org/pipermail/freebsd-current/2004-August/035984.html -- Israel Herraiz israel.herraiz@gmail.com Ya tengo blog, http://ixra.blogspot.com From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 23:06:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5A8B16A4CE for ; Tue, 31 Aug 2004 23:06:17 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79C9443D48 for ; Tue, 31 Aug 2004 23:06:17 +0000 (GMT) (envelope-from jon.drews@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so179206rnl for ; Tue, 31 Aug 2004 16:06:16 -0700 (PDT) Received: by 10.38.164.76 with SMTP id m76mr1843643rne; Tue, 31 Aug 2004 16:06:16 -0700 (PDT) Received: by 10.38.89.49 with HTTP; Tue, 31 Aug 2004 16:06:16 -0700 (PDT) Message-ID: <8cb27cbf04083116067547930f@mail.gmail.com> Date: Tue, 31 Aug 2004 18:06:16 -0500 From: Jon Drews To: freebsd-current@freebsd.org In-Reply-To: <8cb27cbf0408301742153796cc@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <8cb27cbf0408301742153796cc@mail.gmail.com> Subject: Re: [PLEASE TEST] Better support for Synaptics Touchpads X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Jon Drews List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2004 23:06:17 -0000 On Mon, 30 Aug 2004 18:42:17 -0600, Jon Drews wrote: > OK: > > I put this in device.hints and my mouse works in X but not at the > xterm. FreeBSD 5.3 B2 no longer locks up when configuring the mouse > with sysinstall. > > hint.psm.0.flags="0x200" OK the mouse is working in the console now. I am still using the above hint. From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 23:35:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70B5C16A4CE for ; Tue, 31 Aug 2004 23:35:55 +0000 (GMT) Received: from linwhf.opal.com (81.79.171.66.subscriber.vzavenue.net [66.171.79.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72EF243D5C for ; Tue, 31 Aug 2004 23:35:54 +0000 (GMT) (envelope-from jr@opal.com) Received: (jr@localhost) by linwhf.opal.com (8.13.1/jr6.1/Submit) for id i7VNZh1G000990; Tue, 31 Aug 2004 19:35:43 -0400 (EDT) Date: Tue, 31 Aug 2004 19:35:43 -0400 From: "J.R. Oldroyd" To: =?iso-8859-1?Q?S=F8ren?= Schmidt Message-ID: <20040831233543.GA836@linwhf.opal.com> References: <412F5A10.8080907@drexel.edu> <412F7292.6000804@DeepCore.dk> <20040830181540.GA809@linwhf.opal.com> <413372B3.5010603@DeepCore.dk> <20040830192224.GB809@linwhf.opal.com> <413390B9.5050705@DeepCore.dk> <20040831144205.GA817@linwhf.opal.com> <4134DE3C.7080303@DeepCore.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4134DE3C.7080303@DeepCore.dk> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: Current 8/27/2004, DVD problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 23:35:55 -0000 Afraid not. Just to confirm since my line numbers seem to be a few off yours... I have: __FBSDID("$FreeBSD: src/sys/dev/ata/ata-lowlevel.c,v 1.46 2004/08/27 22:14:45 sos Exp $"); And after adding the extra call to ata_wait() there are now TWO ata_wait()s: int ata_generic_command(struct ata_device *atadev, u_int8_t command, u_int64_t lba, u_int16_t count, u_int16_t feature) { if (atadebug) ata_prtdev(atadev, "ata_command: addr=%04lx, command=%02x, " "lba=%jd, count=%d, feature=%d\n", rman_get_start(atadev->channel->r_io[ATA_DATA].res), command, (intmax_t)lba, count, feature); /* ready to issue command ? */ if (ata_wait(atadev, 0) < 0) { ata_prtdev(atadev, "timeout waiting for ready command=%02x\n", command); return -1; } /* select device */ ATA_IDX_OUTB(atadev->channel, ATA_DRIVE, ATA_D_IBM | atadev->unit); /* ready to issue command ? */ if (ata_wait(atadev, 0) < 0) { ata_prtdev(atadev, "timeout sending command=%02x\n", command); return -1; } /* enable interrupt */ ATA_IDX_OUTB(atadev->channel, ATA_ALTSTAT, ATA_A_4BIT); Same result. Hangs at the CD probe with a normal boot. Hangs also in verbose mode with a disc in. Does boot in verbose mode with no disc in. -jr On Aug 31, 22:23, Søren Schmidt wrote: > J.R. Oldroyd wrote: > >Some follow-up. > > > >Similar to other folks with this problem, the system will boot in > >verbose mode. However, ONLY with no medium. If medium is present, > >it still hangs. If the tray is empty, it will boot in either DMA or > >PIO mode. And if I then insert a disc, I can read it OK. > > Hmm does the attached patch change behavior in any way ? > > -Søren > Index: ata-lowlevel.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/ata/ata-lowlevel.c,v > retrieving revision 1.44 > diff -u -r1.44 ata-lowlevel.c > --- ata-lowlevel.c 16 Aug 2004 09:32:35 -0000 1.44 > +++ ata-lowlevel.c 24 Aug 2004 07:25:32 -0000 > @@ -721,6 +721,12 @@ > rman_get_start(atadev->channel->r_io[ATA_DATA].res), > command, (intmax_t)lba, count, feature); > > + /* ready to issue command ? */ > + if (ata_wait(atadev, 0) < 0) { > + ata_prtdev(atadev, "timeout waiting for ready command=%02x\n", command); > + return -1; > + } > + > /* select device */ > ATA_IDX_OUTB(atadev->channel, ATA_DRIVE, ATA_D_IBM | atadev->unit); > From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 23:35:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AD6616A4CE for ; Tue, 31 Aug 2004 23:35:57 +0000 (GMT) Received: from imap.univie.ac.at (mail.univie.ac.at [131.130.1.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CE3E43D1F for ; Tue, 31 Aug 2004 23:35:56 +0000 (GMT) (envelope-from le@FreeBSD.org) Received: from [192.168.0.4] (adslle.cc.univie.ac.at [131.130.102.11]) by imap.univie.ac.at (8.12.10/8.12.10) with ESMTP id i7VNZiu1179244; Wed, 1 Sep 2004 01:35:46 +0200 Date: Wed, 1 Sep 2004 01:35:48 +0200 (CEST) From: Lukas Ertl To: Craig Boston In-Reply-To: <20040831211944.GA65532@nowhere> Message-ID: <20040901013402.K557@korben.in.tern> References: <20040831211944.GA65532@nowhere> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-DCC-ZID-Univie-Metrics: mx7.univie.ac.at 4249; Body=3 Fuz1=3 Fuz2=3 cc: freebsd-current@FreeBSD.org cc: Daniel Eriksson Subject: Re: PLEASE TEST: IPI deadlock avoidance patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 23:35:57 -0000 On Tue, 31 Aug 2004, Craig Boston wrote: > So it seems that gvinum RAID-5 is a key factor in the corruption, and > SMP greatly increases the odds of it happening... > > Is it worth creating a PR so this doesn't get lost amid the release > madness? PR isn't necessary, it's my number one task right now (which isn't easy, since the corruption isn't really repeatable at will). Gimme a little more time. thanks, le -- Lukas Ertl http://homepage.univie.ac.at/l.ertl/ le@FreeBSD.org http://people.freebsd.org/~le/ From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 23:37:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FE6916A4CE for ; Tue, 31 Aug 2004 23:37:58 +0000 (GMT) Received: from web50605.mail.yahoo.com (web50605.mail.yahoo.com [206.190.38.92]) by mx1.FreeBSD.org (Postfix) with SMTP id 8831743D5A for ; Tue, 31 Aug 2004 23:37:57 +0000 (GMT) (envelope-from kstailey@yahoo.com) Message-ID: <20040831233756.51771.qmail@web50605.mail.yahoo.com> Received: from [69.138.247.171] by web50605.mail.yahoo.com via HTTP; Tue, 31 Aug 2004 16:37:56 PDT Date: Tue, 31 Aug 2004 16:37:56 -0700 (PDT) From: Kenneth Stailey To: freebsd-current@freebsd.org In-Reply-To: <20040831214945.47235.qmail@web50602.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: Problem with SiI3114 SATA RAID using 5.3-BETA1-20040823 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 23:37:58 -0000 One more detail. When booted from 5.2.1-p8 hermes# atacontrol list ATA channel 0: Master: acd0 ATA/ATAPI rev 5 Slave: no device present ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: ad4 ATA/ATAPI rev 7 Slave: no device present ATA channel 3: Master: ad6 ATA/ATAPI rev 7 Slave: no device present ATA channel 4: Master: no device present Slave: no device present ATA channel 5: Master: no device present Slave: no device present hermes# atacontrol status ar0 ar0: ATA RAID1 subdisks: ad4 ad6 status: READY hermes# When booted from 5.3-BETA1 Fixit# atacontrol list ATA channel 0: Master: acd0 ATA/ATAPI revision 5 Slave: no device present ATA channel 1: Master: no device present Slave: no device present ATA channel 2: Master: ad4 Slave: no device present ATA channel 3: Master: ad6 Slave: no device present ATA channel 4: Master: no device present Slave: no device present ATA channel 5: Master: no device present Slave: no device present Fixit# atacontrol status ar0 atacontrol: ioctl(ATARAIDSTATUS): Device not configured Fixit# --- Kenneth Stailey wrote: > I'm trying to upgrade a TYAN Tiger K8WS S2875S from FreeBSD-5.2.1-p8 to > 5.3-BETA1-20040823. > > It fails because instead of seeing the SiI3114 as ar0 (RAID-1) it sees two > separate disks: > > ad4: 194481MB [395136/16/63] at ata2-master SATA150 > ad6: 194481MB [395136/16/63] at ata3-master SATA150 > > I don't think I should upgrade just one half of the mirror so I abort the > upgrade. > > When booting 5.2.1-p8 > > GEOM: create disk ad4 dp=0xffffff003b2f6aa0 > ad4: 194481MB [395136/16/63] at ata2-master UDMA100 > GEOM: create disk ad6 dp=0xffffff003b2f62a0 > ad6: 194481MB [395136/16/63] at ata3-master UDMA100 > GEOM: create disk ar0 dp=0xffffff0000d7fa70 > ar0: 194480MB [24792/255/63] status: READY subdisks: > disk0 READY on ad4 at ata2-master > disk1 READY on ad6 at ata3-master > Mounting root from ufs:/dev/ar0s1a > > When booting 5.3-BETA1 > > Copyright (c) 1992-2004 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 5.3-BETA1-20040823 #0: Mon Aug 23 11:03:37 UTC 2004 > root@quynh.NUXI.org:/usr/obj/usr/src/sys/GENERIC > WARNING: WITNESS option enabled, expect reduced performance. > ACPI APIC Table: > Timecounter "i8254" frequency 1193182 Hz quality 0 > CPU: AMD Opteron(tm) Processor 246 (1993.31-MHz K8-class CPU) > Origin = "AuthenticAMD" Id = 0xf58 Stepping = 8 > > Features=0x78bfbff > AMD Features=0xe0500800 > real memory = 1073676288 (1023 MB) > avail memory = 1020493824 (973 MB) > MADT: Forcing active-low polarity and level trigger for SCI > ioapic0 irqs 0-23 on motherboard > acpi0: on motherboard > acpi0: Power Button (fixed) > Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x5008-0x500b on acpi0 > cpu0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > pcib1: at device 1.0 on pci0 > pci2: on pcib1 > pci2: at device 0.0 (no driver attached) > pci2: at device 0.1 (no driver attached) > pcib2: at device 6.0 on pci0 > pci1: on pcib2 > ohci0: mem 0xff4fc000-0xff4fcfff irq 19 at > device 0.0 on pci1 > ohci0: [GIANT-LOCKED] > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub0: 3 ports with 3 removable, self powered > ohci1: mem 0xff4fd000-0xff4fdfff irq 19 at > device 0.1 on pci1 > ohci1: [GIANT-LOCKED] > usb1: OHCI version 1.0, legacy support > usb1: SMM does not respond, resetting > usb1: on ohci1 > usb1: USB revision 1.0 > uhub1: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub1: 3 ports with 3 removable, self powered > em0: port > 0x8880-0x88bf mem 0xff4a0000-0xff4bffff,0xff4c0000-0xff4dffff irq 18 at > device > 3.0 on pci1 > em0: [GIANT-LOCKED] > em0: Ethernet address: 00:e0:81:28:99:c4 > em0: Speed:N/A Duplex:N/A > atapci0: port > 0x9400-0x940f,0x9480-0x9483,0x9800-0x9807,0x9880-0x9883,0x9c00-0x9c07 mem > 0xff4ffc00-0xff4fffff irq 19 at device 5.0 on pci1 > ata2: channel #0 on atapci0 > ata3: channel #1 on atapci0 > ata4: channel #2 on atapci0 > ata5: channel #3 on atapci0 > fwohci0: port 0x8c00-0x8c7f mem 0xff4ff000-0xff4ff7ff > irq 17 at device 10.0 on pci1 > fwohci0: [GIANT-LOCKED] > fwohci0: OHCI version 1.0 (ROM=1) > fwohci0: No. of Isochronous channels is 4. > fwohci0: EUI64 00:e0:81:00:00:30:12:53 > fwohci0: Phy 1394a available S400, 2 ports. > fwohci0: Link S400, max_rec 2048 bytes. > firewire0: on fwohci0 > fwe0: on firewire0 > if_fwe0: Fake Ethernet address: 02:e0:81:30:12:53 > fwe0: Ethernet address: 02:e0:81:30:12:53 > sbp0: on firewire0 > fwohci0: Initiate bus reset > fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode > firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) > firewire0: bus manager 0 (me) > uhci0: port 0x9000-0x901f irq 17 at device 11.0 > on > pci1 > uhci0: [GIANT-LOCKED] > usb2: on uhci0 > usb2: USB revision 1.0 > uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub2: 2 ports with 2 removable, self powered > uhci1: port 0x9080-0x909f irq 18 at device 11.1 > on > pci1 > uhci1: [GIANT-LOCKED] > usb3: on uhci1 > usb3: USB revision 1.0 > uhub3: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > uhub3: 2 ports with 2 removable, self powered > pci1: at device 11.2 (no driver attached) > isab0: at device 7.0 on pci0 > isa0: on isab0 > atapci1: port > 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 > ata0: channel #0 on atapci1 > ata1: channel #1 on atapci1 > pci0: at device 7.2 (no driver attached) > pci0: at device 7.3 (no driver attached) > pci0: at device 7.5 (no driver attached) > acpi_button0: on acpi0 > atkbdc0: port 0x64,0x60 irq 1 on acpi0 > atkbd0: flags 0x1 irq 1 on atkbdc0 > kbd0 at atkbd0 > atkbd0: [GIANT-LOCKED] > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model IntelliMouse, device ID 3 > sio0: configured irq 4 not in bitmap of probed irqs 0 > sio0: port may not be enabled > sio0 port 0x3f8-0x3ff irq 4 on acpi0 > sio0: type 16550A > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio1 port 0x2f8-0x2ff irq 3 on acpi0 > sio1: type 16550A > fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on > acpi0 > fdc0: FIFO enabled, 8 bytes threshold > fd0: <1440-KB 3.5" drive> on fdc0 drive 0 > ppc0 port 0x378-0x37f irq 7 on acpi0 > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppbus0: on ppc0 > plip0: on ppbus0 > lpt0: on ppbus0 > lpt0: Interrupt-driven port > ppi0: on ppbus0 > orm0: at iomem 0xcb000-0xcf7ff,0xc0000-0xcafff 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 > Timecounter "TSC" frequency 1993314155 Hz quality 800 > Timecounters tick every 0.976 msec > md0: Preloaded image 4194304 bytes at 0xffffffff808e5db0 > acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% > ATAPI_RESET time = 40us > acd0: CDRW at ata0-master UDMA33 > ad4: 194481MB [395136/16/63] at ata2-master SATA150 > ad6: 194481MB [395136/16/63] at ata3-master SATA150 > Mounting root from ufs:/dev/md0 > em0: Link is up 100 Mbps Full Duplex > > Thanks for any advice as how to upgrade this system. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 23:53:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FE4A16A4CE for ; Tue, 31 Aug 2004 23:53:47 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9149B43D2F for ; Tue, 31 Aug 2004 23:53:47 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i7VNrlmL003241; Tue, 31 Aug 2004 16:53:47 -0700 (PDT) Received: from [192.168.1.6] (pool-68-160-193-218.ny325.east.verizon.net [68.160.193.218]) (authenticated bits=0)i7VNraCv009846; Tue, 31 Aug 2004 16:53:39 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Tue, 31 Aug 2004 19:53:35 -0400 To: Evan Dower X-Mailer: Apple Mail (2.619) cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 23:53:47 -0000 On Aug 31, 2004, at 6:22 PM, Evan Dower wrote: > This seems to me like a very good idea. Some people are very > accustomed to the current defaults. They can just leave things alone. > [ ... ] In fact, I'd be perfectly happy if you couldn't change the > default keys but could only add to them. That is, r and l would always > work, but you could configure it so that other letters/keys would also > have the same functions. OK. I am happy with the notion of "everybody wins", so I've updated the code as you've suggested, and also made more effort to retain GNU-style spacing in the changes: http://www.pkix.net/~chuck/sdiff2.diff -- -Chuck From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 00:23:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F0BF16A4CE; Wed, 1 Sep 2004 00:23:16 +0000 (GMT) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 323DC43D5C; Wed, 1 Sep 2004 00:23:16 +0000 (GMT) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.248.106) by smtp01.syd.iprimus.net.au (7.0.028) id 412F6C1400164E8D; Wed, 1 Sep 2004 10:23:15 +1000 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 53B5D420D; Wed, 1 Sep 2004 10:23:04 +1000 (EST) Date: Wed, 1 Sep 2004 10:23:04 +1000 From: Tim Robbins To: Volker Stolz Message-ID: <20040901002304.GA66469@cat.robbins.dropbear.id.au> References: <20040831135928.GY64543@i2.informatik.rwth-aachen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040831135928.GY64543@i2.informatik.rwth-aachen.de> User-Agent: Mutt/1.4.1i cc: current@freebsd.org Subject: Re: NFS mounted full disk gives funny stats on 5.3B2 (negative Avail?) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 00:23:16 -0000 On Tue, Aug 31, 2004 at 03:59:28PM +0200, Volker Stolz wrote: > The negative Avail-stats seem to be mistranslated. Is this worth send-pr'ing > or is it a known problem? Please cc: replies. See PR kern/18874. Tim From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 01:20:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 304E416A4D0 for ; Wed, 1 Sep 2004 01:20:07 +0000 (GMT) Received: from hotmail.com (bay11-dav3.bay11.hotmail.com [64.4.38.107]) by mx1.FreeBSD.org (Postfix) with ESMTP id 216D043D49 for ; Wed, 1 Sep 2004 01:20:07 +0000 (GMT) (envelope-from dsnofe@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 31 Aug 2004 18:20:06 -0700 Received: from 218.80.194.83 by bay11-dav3.bay11.hotmail.com with DAV; Wed, 01 Sep 2004 01:20:06 +0000 X-Originating-IP: [218.80.194.83] X-Originating-Email: [dsnofe@msn.com] X-Sender: dsnofe@msn.com From: "Deng XueFeng" To: "Sascha Wildner" References: <4132EDFD.4050804@erpicon.de> <20040830221036.85DE.DSNOFE@msn.com> <413350D9.4070909@online.de> <4134A1BF.1080304@online.de> Date: Wed, 1 Sep 2004 09:20:04 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: X-OriginalArrivalTime: 01 Sep 2004 01:20:06.0987 (UTC) FILETIME=[D0ED01B0:01C48FC1] cc: Cyrille Lefevre cc: current@freebsd.org Subject: Re: [BETA PATCH] VESA mode support for syscons X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 01:20:07 -0000 DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIlNhc2NoYSBXaWxkbmVyIiA8 c2F3QG9ubGluZS5kZT4NClRvOiAiRGVuZyBYdWVGZW5nIiA8ZHNub2ZlQG1zbi5jb20+DQpTZW50 OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwMSwgMjAwNCAxMjowNSBBTQ0KU3ViamVjdDogUmU6IFtC RVRBIFBBVENIXSBWRVNBIG1vZGUgc3VwcG9ydCBmb3Igc3lzY29ucw0KDQoNCj4gRGVuZyBYdWVG ZW5nIHdyb3RlOg0KPiANCj4+PlRoYW5rcy4gSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgbW9kZXMg eW91IHdlcmUgd3JpdGluZyBhYm91dCBhcmUgbm90IA0KPj4+dHJ1ZSBWRVNBIG1vZGVzIChhdCBs ZWFzdCB0aGUgY2FyZCBkb2Vzbid0IHJldHVybiBpbmZvIG9uIHRoZW0pLiBJIGd1ZXNzIA0KPj4g DQo+PiB3aGF0J3MgaW5mbz8NCj4+IGNvdWxkIHlvdSBnaXZlIGEgZXhhbXBsZSBvciB5b3UgZG1l c2cgZmlsZT8NCj4gDQo+IERlbmcsDQo+IA0KPiBkdXJpbmcga2VybmVsIGluaXRpYWxpemF0aW9u IHRoZSBWRVNBIG1vZHVsZSBwcm9iZXMgYWxsIHBvc3NpYmxlIG1vZGUgDQo+IG51bWJlcnMgYW5k IGxvb2tzIGlmIHRoZSBhZGFwdGVyIHJldHVybnMgYSB2YWxpZCBtb2RlLiBJbiB5b3VyIGRtZXNn IHlvdSANCj4gY2FuIHNlZSB0aGF0IG5vIFdYR0EgbW9kZXMgYXJlIHJlY29nbml6ZWQgYW5kIHRo ZXkgYXJlIGFsc28gbm90IA0KPiByZWplY3RlZC4gU28gSSB0aGluayB0aGlzIGlzIGJlY2F1c2Ug dGhlc2UgbW9kZXMgYXJlIG9ubHkgYWNjZXNzaWJsZSB0byANCj4gaGFyZHdhcmUgc3BlY2lmaWMg ZHJpdmVycy4NClRoYW5rcyB0byBleHBsYWluIHRoaXMuIEkgd2FubmEgdHJ5IGxpbnV4IHRvIHNl ZSB3aGF0IG1vZGUgIGl0IHN1cHBvcnQuDQoNCj4gDQo+IE9oLCBJIHNhdyB0aGF0IHRoZXJlIGFy ZSB0aHJlYWRzIG9uIGZyZWVic2QtY3VycmVudC4gVGhlIGlzc3VlcyBwZW9wbGUgDQo+IGFyZSBo YXZpbmcgdGhlcmUgd2l0aCB0aGVpciBtb3VzZWQgY29tcGxhaW5pbmcgYXJlIGR1ZSB0byBzb21l IGNoYW5nZXMgDQo+IGluIHZpZGNvbnRyb2wgdGhhdCBEcmFnb25GbHkgaGFzIGRvbmUuIFNpbmNl IHRoZSBtb3VzZSBwb2ludGVyIGlzIGNvbW1vbiANCj4gdG8gYWxsIHRlcm1pbmFscyBpdCBjYW4g YmUgdHVybmVkIG9uIChhbmQgb2ZmKSBvbmx5IG9uY2UuIEFmdGVyIHRoYXQsIGl0IA0KPiBoYXMg dG8gYmUgdHVybmVkIG9mZiBhZ2Fpbi4gbW91c2VkIFJDTkcgdHJpZXMgdG8gdHVybiBpdCBvbiBt dWx0aXBsZSANCj4gdGltZXMuIFRoaXMgaXMgYSBidWcuIENvbXBhcmUgb3VyIHZlcnNpb24gb2Yg bW91c2VkIFJDTkcgYXQgDQo+IGh0dHA6Ly93d3cuZHJhZ29uZmx5YnNkLm9yZy9jZ2ktYmluL2N2 c3dlYi5jZ2kvc3JjL2V0Yy9yYy5kL21vdXNlZD9yZXY9MS4zJmNvbnRlbnQtdHlwZT10ZXh0L3gt Y3Zzd2ViLW1hcmt1cCANCj4gdG8geW91cnMgdG8gc2VlIHdoZXJlIHRoZSBwcm9ibGVtIGxpZXMu DQpJIGhhdmUgc2VuZCB0aGUgcGF0Y2ggdG8gQ3lyaWxsZSBMZWZldnJlIDxjbGVmZXZyLWN1cnJl bnRAOW9ubGluZS5mcj4gd2hvIHNlbmRwci4NCmJ1dCBmb3JnZXQgQ2MgdG8gbWFpbGxpc3QuDQoN Cj4gDQo+IEknbSBnb25uYSBwdXQgdXAgYSBuZXcgdmVyc2lvbiBvZiB0aGUgcGF0Y2ggbGF0ZXIg dGhpcyBldmVuaW5nIHRvIGJlIA0KPiBjb21taXR0ZWQgd2l0aGluIHRoZSBuZXh0IGZldyBkYXlz LiBJdCBoYXMgYmVlbiBjbGVhbmVkIHVwIGFuZCBleHRlbmRlZCANCj4gc28gdGhhdCAxNSBhbmQg MjQgYml0IG1vZGVzIGFyZSBhbHNvIHN1cHBvcnRlZC4gSSB0aGluayBpdCdzIGFsc28gYSBiaXQg DQo+IGZhc3Rlci4gSSdkIHJlY29tbWVuZCB0aGF0IEZyZWVCU0QgKGlmIHRoZXkgd2FudCBvdXIg c3R1ZmYpIHRha2UgdGhpcyANCj4gcGF0Y2ggaW5zdGVhZCBvZiB0aGUgZmlyc3Qgb25lLg0KQ29v bC4gSSB3aWxsIG1lcmdlIHRoZSBwYXRjaCBhbmQgc2VuZHByLg0KPiANCj4gSWYgcGVvcGxlIG9u IGZyZWVic2QtY3VycmVudCBoYXZlIGFueSBxdWVzdGlvbnMgb3IgY29tbWVudHMgdG8gdGhpcyAN Cj4gc3R1ZmYsIHRoZXkgYXJlIHdlbGNvbWUgdG8ganVzdCBhc2sgbWUgYnkgbWFpbC4gSSBkb24n dCBzdWJzY3JpYmUgdG8gDQo+IGZyZWVic2QtY3VycmVudCBjdXJyZW50bHkuDQo+DQpJIHdpbGwg Q2MgdGhpcyBtYWlsIHRvIGZyZWVic2QtY3VycmVudC4gdGhhbmtzIGEgbG90Lg0KIA0KPiBSZWdh cmRzLA0KPiBTYXNjaGENCj4gDQo+IC0tIA0KPiBodHRwOi8veW95b2R5bmUuYXRoLmN4DQo+DQoN ClNpbmNlcmVseSwNCkRlbmcgWHVlRmVuZw0KTVNOOiBkc25vZmVAbXNuLmNvbQ0KaHR0cDovL3d3 dy5kZW5naC5jb20= From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 02:14:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09F6316A4CE; Wed, 1 Sep 2004 02:14:04 +0000 (GMT) Received: from smarthost2.sentex.ca (smtp3b.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1DBB43D2F; Wed, 1 Sep 2004 02:14:03 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id i812E20x097614; Tue, 31 Aug 2004 22:14:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i812E20T013862; Tue, 31 Aug 2004 22:14:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B20867303F; Tue, 31 Aug 2004 22:14:02 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040901021402.B20867303F@freebsd-current.sentex.ca> Date: Tue, 31 Aug 2004 22:14:02 -0400 (EDT) Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 02:14:04 -0000 TB --- 2004-09-01 00:51:34 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-01 00:51:34 - starting CURRENT tinderbox run for i386/pc98 TB --- 2004-09-01 00:51:34 - checking out the source tree TB --- 2004-09-01 00:51:34 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2004-09-01 00:51:34 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-01 00:56:44 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-01 00:56:44 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2004-09-01 00:56:44 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-09-01 02:00:44 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-01 02:00:44 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2004-09-01 02:00:44 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Sep 1 02:00:44 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Wed Sep 1 02:14:02 UTC 2004 TB --- 2004-09-01 02:14:02 - generating LINT kernel config TB --- 2004-09-01 02:14:02 - cd /home/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- 2004-09-01 02:14:02 - /usr/bin/make -B LINT TB --- 2004-09-01 02:14:02 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-01 02:14:02 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2004-09-01 02:14:02 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Sep 1 02:14:02 UTC 2004 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf; PATH=/home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/i386/legacy/usr/sbin:/home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/i386/legacy/usr/bin:/home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/i386/legacy/usr/games:/home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/i386/usr/sbin:/home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/i386/usr/bin:/home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/LINT /tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf/LINT config: /tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf/LINT:744: syntax error *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2004-09-01 02:14:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-01 02:14:02 - ERROR: failed to build lint kernel TB --- 2004-09-01 02:14:02 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 02:40:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CACA416A4CE; Wed, 1 Sep 2004 02:40:09 +0000 (GMT) Received: from sana.init-main.com (104.194.138.210.bn.2iij.net [210.138.194.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19F2943D46; Wed, 1 Sep 2004 02:40:09 +0000 (GMT) (envelope-from takawata@init-main.com) Received: from init-main.com (localhost [127.0.0.1]) by sana.init-main.com (8.13.1/8.13.1) with ESMTP id i812cv4K054209; Wed, 1 Sep 2004 11:38:59 +0900 (JST) (envelope-from takawata@init-main.com) Message-Id: <200409010238.i812cv4K054209@sana.init-main.com> To: Toxa From: takawata@jp.freebsd.org In-reply-to: Your message of "Tue, 31 Aug 2004 17:16:28 +0400." <20040831131628.GA2156@laptoxa.toxa.lan> Date: Wed, 01 Sep 2004 11:38:57 +0900 Sender: takawata@init-main.com cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: acpi_video on SONY VAIO PCG-Z1 [was: acpi_video users needed] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 02:40:09 -0000 In message <20040831131628.GA2156@laptoxa.toxa.lan>, Toxa $B$5$s$$$o$/(B: >On Tue, Aug 31, 2004 at 07:41:11PM +0900, takawata@jp.freebsd.org wrote: >> >dev.acpi_sny.0.brightness=10 >> >sysctl: oid 'dev.acpi_sny.0.brightness' is read only >> > >> >nothing happens... > >> Sorry, please refetch it from > >> http://www.init-main.com/acpi_snc.tar.gz > >acpi_sny0: detached >acpi_snc0: on acpi0 >[(17:12)(49.34%)(p6):~/tmp/acpi_snc ] sysctl -a|grep snc >dev.acpi_snc.0.%desc: Sony system controller >dev.acpi_snc.0.%driver: acpi_snc >dev.acpi_snc.0.%location: handle=\_SB_.PCI0.LPC0.SNC_ >dev.acpi_snc.0.%pnpinfo: _HID=SNY5001 _UID=0 >dev.acpi_snc.0.%parent: acpi0 >dev.acpi_snc.0.brightness: 94 >[(17:12)(49.34%)(p6):~/tmp/acpi_snc ] sudo sysctl >dev.acpi_snc.0.brightness=10 >dev.acpi_snc.0.brightness: 94 -> 10 >[(17:13)(49.51%)(p6):~/tmp/acpi_snc ] sudo sysctl >dev.acpi_snc.0.brightness=100 >dev.acpi_snc.0.brightness: 10 -> 100 >[(17:13)(49.51%)(p6):~/tmp/acpi_snc ] > >Yes, it works, thanks a lot! Now I'm wondering how to resume lid from >suspending. Machine resumes well and I can log in remotely but monitor >looks "dead" I don't imagine why. But any other method in SNC may do something. I modified the driver so that it exports more methods. http://www.init-main.com/acpi_snc2.tar.gz Testers wanted. From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 05:20:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 465E816A4CE for ; Wed, 1 Sep 2004 05:20:56 +0000 (GMT) Received: from mail2.numachi.com (mail2.numachi.com [198.175.254.8]) by mx1.FreeBSD.org (Postfix) with SMTP id 6BF7343D2D for ; Wed, 1 Sep 2004 05:20:55 +0000 (GMT) (envelope-from reichert@numachi.com) Received: (qmail 68521 invoked from network); 1 Sep 2004 05:20:54 -0000 Received: from natto.numachi.com (198.175.254.216) by mail2.numachi.com with SMTP; 1 Sep 2004 05:20:54 -0000 Received: (qmail 31785 invoked by uid 1001); 1 Sep 2004 05:20:54 -0000 Date: Wed, 1 Sep 2004 05:20:54 +0000 From: Brian Reichert To: freebsd-current@freebsd.org Message-ID: <20040901052054.GV4846@numachi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: how 'supported' are 3ware Escalade controllers? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 05:20:56 -0000 I'm speccing a budget RAID fileserver, and stumbled across some interesting prospects. This page describes a eight-channel ATA RAID card, the 7506-8: This page says there is support for other cards in this family, but doesn't explicitly cite the 7506-8, and cites some firmwar issues: The manpage for the driver itself seems prety broad: Can someone explicitly tie these references together? Is the 7506-8 going to cut it? Of course, I'm open to any anti-recommendations WRT this card, as well, so feel free to chuck me any feedback... -- Brian Reichert 37 Crystal Ave. #303 Daytime number: (603) 434-6842 Derry NH 03038-1713 USA BSD admin/developer at large From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 06:17:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8583A16A4CF for ; Wed, 1 Sep 2004 06:17:38 +0000 (GMT) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 4A93543D31 for ; Wed, 1 Sep 2004 06:17:38 +0000 (GMT) (envelope-from nate@root.org) Received: (qmail 2349 invoked by uid 1000); 1 Sep 2004 06:17:40 -0000 Date: Tue, 31 Aug 2004 23:17:40 -0700 (PDT) From: Nate Lawson To: takawata@jp.freebsd.org In-Reply-To: <200409010238.i812cv4K054209@sana.init-main.com> Message-ID: <20040831231101.N2314@root.org> References: <200409010238.i812cv4K054209@sana.init-main.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org cc: Toxa Subject: Re: acpi_video on SONY VAIO PCG-Z1 [was: acpi_video users needed] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 06:17:38 -0000 On Wed, 1 Sep 2004 takawata@jp.freebsd.org wrote: > In message <20040831131628.GA2156@laptoxa.toxa.lan>, Toxa =A4=B5=A4=F3=A4= =A4=A4=EF=A4=AF: > >On Tue, Aug 31, 2004 at 07:41:11PM +0900, takawata@jp.freebsd.org wrote: > >> >dev.acpi_sny.0.brightness=3D10 > >> >sysctl: oid 'dev.acpi_sny.0.brightness' is read only > >> > > >> >nothing happens... > > > >> Sorry, please refetch it from > > > >> http://www.init-main.com/acpi_snc.tar.gz > > > >acpi_sny0: detached > >acpi_snc0: on acpi0 > >[(17:12)(49.34%)(p6):~/tmp/acpi_snc ] sysctl -a|grep snc > >dev.acpi_snc.0.%desc: Sony system controller > >dev.acpi_snc.0.%driver: acpi_snc > >dev.acpi_snc.0.%location: handle=3D\_SB_.PCI0.LPC0.SNC_ > >dev.acpi_snc.0.%pnpinfo: _HID=3DSNY5001 _UID=3D0 > >dev.acpi_snc.0.%parent: acpi0 > >dev.acpi_snc.0.brightness: 94 > >[(17:12)(49.34%)(p6):~/tmp/acpi_snc ] sudo sysctl > >dev.acpi_snc.0.brightness=3D10 > >dev.acpi_snc.0.brightness: 94 -> 10 > >[(17:13)(49.51%)(p6):~/tmp/acpi_snc ] sudo sysctl > >dev.acpi_snc.0.brightness=3D100 > >dev.acpi_snc.0.brightness: 10 -> 100 > >[(17:13)(49.51%)(p6):~/tmp/acpi_snc ] > > > >Yes, it works, thanks a lot! Now I'm wondering how to resume lid from > >suspending. Machine resumes well and I can log in remotely but monitor > >looks "dead" > > I don't imagine why. But any other method in SNC may do something. > I modified the driver so that it exports more methods. > http://www.init-main.com/acpi_snc2.tar.gz > > Testers wanted. The PWAK method looks like you should call it on resume and the PWRN method looks like it should be called by a power button handler. However, there already are control method power and sleep buttons in the AML. It looks like CDPW turns on or off power to the CD drive (1 means on, 0 off). GCDP returns the power state of the CD drive. However, most of these functions are hidden in SMI mode so the only way to find out is to try. -Nate From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 06:20:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C0DA16A4CE for ; Wed, 1 Sep 2004 06:20:01 +0000 (GMT) Received: from msr29.hinet.net (msr29.hinet.net [168.95.4.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 089C643D58 for ; Wed, 1 Sep 2004 06:20:01 +0000 (GMT) (envelope-from kevlo@FreeBSD.org) Received: from [192.168.1.118] (220-130-133-26.HINET-IP.hinet.net [220.130.133.26]) by msr29.hinet.net (8.9.3/8.9.3) with ESMTP id OAA21984; Wed, 1 Sep 2004 14:19:46 +0800 (CST) From: Kevin Lo To: vova@fbsd.ru In-Reply-To: <1093938230.961.8.camel@localhost> References: <200408301916.22240.mjohnston@skyweb.ca> <4133DA04.4030103@us.army.mil> <1093938230.961.8.camel@localhost> Content-Type: text/plain Message-Id: <1094019760.2672.2.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Date: Wed, 01 Sep 2004 14:22:40 +0800 Content-Transfer-Encoding: 7bit cc: Jonathan cc: "current@freebsd.org" Subject: Re: cvs-src summary for August 23-30 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 06:20:01 -0000 Vladimir Grebenschikov wrote: > On Mon, 2004-08-30 at 21:53 -0400, Jonathan wrote: > > Mark Johnston wrote: > > > > > Here's this week's summary. As a side note, I discovered Synergy > > > (http://synergy2.sf.net) today, and it made the summary-writing much more > > > pleasant, letting me flip my mouse cursor between the desktop I write the > > > summary on and the laptop I read the mail on, copying and pasting > > > transparently. I highly recommend it if you run any kind of > > > multi-PC-on-one-desktop configuration. > > > > > > > This is one of the coolest and most handy things I have ever seen! I > > can't say how well it works on the X side as my server is headless but > > on my XP desktop and laptop it ROCKS :D Sorry for the extra noise but if > > you have not looked at this and even occasionally use two computers at > > once it's well worth checking out!) > > Yes, but port does not work on -CURRENT: (server part of port) > > $ synergys > terminate called after throwing an instance of 'std::bad_alloc' > what(): St9bad_alloc > Abort (core dumped) > $ > > Also port version is 1.0.14 when latest stable version 1.1.7. > > Fresh version not builds due to 'alloca' redefinition. I just updated to synergy 1.1.8. Please update the ports tree :-) > > Excited with new program, > > Jonathan Kevin From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 06:40:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 529DF16A4CE for ; Wed, 1 Sep 2004 06:40:59 +0000 (GMT) Received: from mail.bitfreak.org (mail.bitfreak.org [65.75.198.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 158BD43D55 for ; Wed, 1 Sep 2004 06:40:59 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from speck.loki.lan (c-24-21-241-225.client.comcast.net [24.21.241.225]) by mail.bitfreak.org (Postfix) with ESMTP id 0923D19F3A; Tue, 31 Aug 2004 23:40:58 -0700 (PDT) Received: from spud (d2.loki.lan [172.21.42.22]) by speck.loki.lan (Postfix) with ESMTP id 8C56C17022; Tue, 31 Aug 2004 23:40:49 -0700 (PDT) From: "Darren Pilgrim" To: "'Brian Reichert'" , Date: Tue, 31 Aug 2004 23:40:39 -0700 Message-ID: <000001c48fee$9b90c100$162a15ac@spud> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <20040901052054.GV4846@numachi.com> Importance: Normal Subject: RE: how 'supported' are 3ware Escalade controllers? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 06:40:59 -0000 > From: Brian Reichert >=20 > I'm speccing a budget RAID fileserver, and stumbled across some > interesting prospects. >=20 > This page describes a eight-channel ATA RAID card, the 7506-8: >=20 > >=20 > This page says there is support for other cards in this family, but > doesn't explicitly cite the 7506-8, and cites some firmwar issues: >=20 > The page says that other 3ware cards use the same PCI IDs, so they will also get picked up by the twe driver. The twe man page in 4.8 only lists the 5xxx and 6xxx series cards, but it attached my 7506 just fine. The page seems rather out of date, with the cited firmware issues tied to cards made two years ago. FWIW, I just installed a 7506-4LP in a 32-bit 33 MHz slot on a 500MHz P3 Celeron machine (i810), with a pair of WD1200JB drives in a RAID1, running up-to-date RELENG_4_8. The performance is excellent for a pair of "typical" ATA drives in a RAID 1. I had a the "PCI parity error" problem when it was installed in a test machine with an older mainboard. > Of course, I'm open to any anti-recommendations WRT this card, as > well, so feel free to chuck me any feedback... Quite the contrary. I'm very pleased with my experience thus far. 3ware's phone support has some longish hold times (20 minutes) and their queueing routine is broken (longest "5 minutes" I've ever seen), but it's wonderful to have a support team that doesn't squirm when you're honest about the OS you're running. :) From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 07:15:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDE4616A4CE for ; Wed, 1 Sep 2004 07:15:22 +0000 (GMT) Received: from mxsf14.cluster1.charter.net (mxsf14.cluster1.charter.net [209.225.28.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3349A43D4C for ; Wed, 1 Sep 2004 07:15:22 +0000 (GMT) (envelope-from MrL0L@charter.net) Received: from mxip19.cluster1.charter.net (mxip19a.cluster1.charter.net [209.225.28.149])i817FKwY022462 for ; Wed, 1 Sep 2004 03:15:21 -0400 Received: from unknown (HELO [172.16.64.36]) (68.189.127.165) by mxip19.cluster1.charter.net with ESMTP; 01 Sep 2004 03:15:21 -0400 X-Ironport-AV: i="3.84,120,1091419200"; d="scan'208"; a="254500132:sNHT13476600" From: Remi To: current@freebsd.org Content-Type: text/plain Message-Id: <1094022914.15312.4.camel@baby> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 01 Sep 2004 00:15:19 -0700 Content-Transfer-Encoding: 7bit Subject: AMD64 make buildworld failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 07:15:23 -0000 I've recently encountered a problem upgrading from FBSD-5.3-B1. I cvs'ed 4 hours ago and here's what I get while doing a clean make buildworld. My CFLAGS are -march=k8 -O2 -pipe. Anyone else experiencing this problem or know how to fix it? In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_alloc.cc:37: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_aux_runtime.cc:34: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_catch.cc:32: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_exception.cc:34: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_globals.cc:33: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_personality.cc:34: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_personality.cc:38:23: unwind-pe.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_term_handler.cc:30: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_terminate.cc:34: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_throw.cc:32: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_type.cc:32: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_unex_handler.cc:30: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/pure.cc:31: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory In file included from /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/vec.cc:37: /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/unwind-cxx.h:41:20: unwind.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/gnu/lib/libstdc++. *** Error code 1 Stop in /usr/src/gnu/lib. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 08:31:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9B5716A4CE for ; Wed, 1 Sep 2004 08:31:03 +0000 (GMT) Received: from mallaury.noc.nerim.net (smtp-103-wednesday.noc.nerim.net [62.4.17.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED07B43D49 for ; Wed, 1 Sep 2004 08:31:02 +0000 (GMT) (envelope-from bettan@nerim.net) Received: from danielle (linux-win.com [62.212.121.38]) by mallaury.noc.nerim.net (Postfix) with SMTP id 47B3962DA7 for ; Wed, 1 Sep 2004 10:31:00 +0200 (CEST) Message-ID: <000a01c48ffe$04493bf0$0301a8c0@danielle> From: "bettan" To: Date: Wed, 1 Sep 2004 10:31:02 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: wg311 v2 on freebsd 5.2-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 08:31:03 -0000 hello, i buy this wireless card but it isn't recognized on freebsd 5.2 = -current.I have compiled my kernel with device wlan , device ath and = device ath_hal however.Anyone have a solution for this wireless card ? From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 08:47:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A957A16A4CF for ; Wed, 1 Sep 2004 08:47:13 +0000 (GMT) Received: from ank-pki.ru (mercury.ank-pki.ru [213.170.76.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEE9F43D62 for ; Wed, 1 Sep 2004 08:47:12 +0000 (GMT) (envelope-from toxa@cterra.ru) Received: (qmail 30541 invoked by uid 0); 1 Sep 2004 12:47:11 +0400 Received: from toxa@cterra.ru by mercury.ank-pki.ru by uid 0 with qmail-scanner-1.22 Clear:RC:0(213.170.76.149):SA:0(0.0/7.0):. Processed in 10.719587 secs); 01 Sep 2004 08:47:11 -0000 Received: from unknown (HELO localhost) (toxa@213.170.76.149) by ank.nwudc.ru with SMTP; 1 Sep 2004 12:47:00 +0400 Date: Wed, 1 Sep 2004 12:43:49 +0400 From: Toxa To: freebsd-current@freebsd.org, freebsd-acpi@freebsd.org X-Comment-To: "Anton Karpov" Message-ID: <20040901084349.GA1039@laptoxa.toxa.lan> Mail-Followup-To: freebsd-current@freebsd.org, freebsd-acpi@freebsd.org, takawata@jp.freebsd.org References: <20040831131628.GA2156@laptoxa.toxa.lan> <200409010238.i812cv4K054209@sana.init-main.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <200409010238.i812cv4K054209@sana.init-main.com> User-Agent: Outluck Express 1.5.6i for MS-DOS 6.22-SMP X-Mailer: See User-Agent above :) X-Operating-System: MS-DOS 6.22-CURRENT on Sony VAIO laptop X-PGP-Public-Key: http://toxahost.org/gpg/pubkey.asc X-Useless-Header: Do Androids Dream of Electric Sheep? X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mercury.ank-pki.ru X-Spam-Level: X-Spam-Status: No, hits=0.0 required=7.0 tests=none autolearn=no version=2.64 Subject: Re: acpi_video on SONY VAIO PCG-Z1 [was: acpi_video users needed] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 08:47:13 -0000 On Wed, Sep 01, 2004 at 11:38:57AM +0900, takawata@jp.freebsd.org wrote: > I don't imagine why. But any other method in SNC may do something. > I modified the driver so that it exports more methods. > http://www.init-main.com/acpi_snc2.tar.gz > Testers wanted. acpi_snc0: on acpi0 acpi_snc0: PID 0 ACPI-1303: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SNC_.GCMI] (Node 0xc1a2b380), AE_AML_UNINITIALIZED_ARG ACPI-1303: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SNC_.GCMI] (Node 0xc1a2b380), AE_AML_UNINITIALIZED_ARG ACPI-1303: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SNC_.GCMI] (Node 0xc1a2b380), AE_AML_UNINITIALIZED_ARG ACPI-1303: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SNC_.GCMI] (Node 0xc1a2b380), AE_AML_UNINITIALIZED_ARG [(12:40)(63.96%)(p0):~/tmp/acpi_snc ] sysctl -a|grep snc dev.acpi_snc.0.brightness: 100 dev.acpi_snc.0.ctr: 0 dev.acpi_snc.0.pcr: 24 dev.acpi_snc.0.cmi: -1039508252 dev.acpi_snc.0.wdp: 256 dev.acpi_snc.0.cdp: 1 dev.acpi_snc.0.%desc: Sony notebook controller dev.acpi_snc.0.%driver: acpi_snc dev.acpi_snc.0.%location: handle=\_SB_.PCI0.LPC0.SNC_ dev.acpi_snc.0.%pnpinfo: _HID=SNY5001 _UID=0 dev.acpi_snc.0.%parent: acpi0 [(12:43)(62.90%)(p0):~/tmp/acpi_snc ] sudo sysctl dev.acpi_snc.0.brightness=100 dev.acpi_snc.0.brightness: 10 -> 100 [(12:43)(62.90%)(p0):~/tmp/acpi_snc ] sony vaio pcg-v505bx... -- Anton A. Karpov PGP key: http://www.toxahost.org/pgp/pubkey.asc You can finger me @toxahost.org for my current status =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~= "Anyone who quotes me in their sig is an idiot." Rusty Russell. =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~= From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 09:43:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F78316A4CE; Wed, 1 Sep 2004 09:43:36 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC55A43D39; Wed, 1 Sep 2004 09:43:35 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1C2ReP-0002Nc-Nh; Wed, 01 Sep 2004 13:43:33 +0400 From: Vladimir Grebenschikov To: Toxa In-Reply-To: <20040901084349.GA1039@laptoxa.toxa.lan> References: <20040831131628.GA2156@laptoxa.toxa.lan> <200409010238.i812cv4K054209@sana.init-main.com> <20040901084349.GA1039@laptoxa.toxa.lan> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Wed, 01 Sep 2004 13:43:33 +0400 Message-Id: <1094031813.903.13.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.93FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: acpi_video on SONY VAIO PCG-Z1 [was: acpi_video users needed] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 09:43:36 -0000 On Wed, 2004-09-01 at 12:43 +0400, Toxa wrote: > On Wed, Sep 01, 2004 at 11:38:57AM +0900, takawata@jp.freebsd.org wrote: > > > I don't imagine why. But any other method in SNC may do something. > > I modified the driver so that it exports more methods. > > http://www.init-main.com/acpi_snc2.tar.gz > > > Testers wanted. > > acpi_snc0: on acpi0 > acpi_snc0: PID 0 > ACPI-1303: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SNC_.GCMI] (Node 0xc1a2b380), AE_AML_UNINITIALIZED_ARG > ACPI-1303: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SNC_.GCMI] (Node 0xc1a2b380), AE_AML_UNINITIALIZED_ARG > ACPI-1303: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SNC_.GCMI] (Node 0xc1a2b380), AE_AML_UNINITIALIZED_ARG > ACPI-1303: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.SNC_.GCMI] (Node 0xc1a2b380), AE_AML_UNINITIALIZED_ARG > > [(12:40)(63.96%)(p0):~/tmp/acpi_snc ] sysctl -a|grep snc > dev.acpi_snc.0.brightness: 100 > dev.acpi_snc.0.ctr: 0 > dev.acpi_snc.0.pcr: 24 > dev.acpi_snc.0.cmi: -1039508252 > dev.acpi_snc.0.wdp: 256 > dev.acpi_snc.0.cdp: 1 > dev.acpi_snc.0.%desc: Sony notebook controller > dev.acpi_snc.0.%driver: acpi_snc > dev.acpi_snc.0.%location: handle=\_SB_.PCI0.LPC0.SNC_ > dev.acpi_snc.0.%pnpinfo: _HID=SNY5001 _UID=0 > dev.acpi_snc.0.%parent: acpi0 > > [(12:43)(62.90%)(p0):~/tmp/acpi_snc ] sudo sysctl > dev.acpi_snc.0.brightness=100 > dev.acpi_snc.0.brightness: 10 -> 100 > [(12:43)(62.90%)(p0):~/tmp/acpi_snc ] > > > sony vaio pcg-v505bx... sony vzio pcg-z1aw almost same: # sysctl dev.acpi_snc dev.acpi_snc.0.brightness: 98 dev.acpi_snc.0.ctr: 0 dev.acpi_snc.0.pcr: 0 dev.acpi_snc.0.cmi: -1044294180 dev.acpi_snc.0.wdp: 1281 dev.acpi_snc.0.cdp: 1 dev.acpi_snc.0.%desc: Sony notebook controller dev.acpi_snc.0.%driver: acpi_snc dev.acpi_snc.0.%location: handle=\_SB_.PCI0.LPCB.SNC_ dev.acpi_snc.0.%pnpinfo: _HID=SNY5001 _UID=0 dev.acpi_snc.0.%parent: acpi0 # dmesg message appears: ACPI-1303: *** Error: Method execution failed [\ \_SB_.PCI0.LPCB.SNC_.GCMI] (Node 0xc1a3a6a0), AE_AML_UNINITIALIZED_ARG on each # sysctl dev.acpi_snc.0.cmi # sysctl dev.acpi_snc.0.cdp=0 really turns CD drive off value of dev.acpi_snc.0.brightness change real brightness of screen but by very strange law: # i=1; while [ $i -le 100 ]; do echo "try $i"; sysctl dev.acpi_snc.0.brightness=$i; echo -n 'read value '; setbrightness -- read; i=$(($i+1)); done try 1 dev.acpi_snc.0.brightness: 100 -> 1 read value 23 try 2 dev.acpi_snc.0.brightness: 1 -> 2 read value 35 try 3 dev.acpi_snc.0.brightness: 2 -> 3 read value 50 try 4 dev.acpi_snc.0.brightness: 3 -> 4 read value 70 try 5 dev.acpi_snc.0.brightness: 4 -> 5 read value 95 try 6 dev.acpi_snc.0.brightness: 5 -> 6 read value 125 try 7 dev.acpi_snc.0.brightness: 6 -> 7 read value 5 try 8 dev.acpi_snc.0.brightness: 7 -> 8 read value 255 try 9 dev.acpi_snc.0.brightness: 8 -> 9 read value 5 try 10 dev.acpi_snc.0.brightness: 9 -> 10 read value 13 try 11 dev.acpi_snc.0.brightness: 10 -> 11 read value 1 try 12 dev.acpi_snc.0.brightness: 11 -> 12 read value 6 try 13 dev.acpi_snc.0.brightness: 12 -> 13 read value 141 try 14 dev.acpi_snc.0.brightness: 13 -> 14 read value 54 try 15 dev.acpi_snc.0.brightness: 14 -> 15 read value 83 try 16 dev.acpi_snc.0.brightness: 15 -> 16 read value 57 try 17 dev.acpi_snc.0.brightness: 16 -> 17 read value 5 try 18 dev.acpi_snc.0.brightness: 17 -> 18 read value 138 try 19 dev.acpi_snc.0.brightness: 18 -> 19 read value 68 try 20 dev.acpi_snc.0.brightness: 19 -> 9 read value 5 try 21 dev.acpi_snc.0.brightness: 9 -> 17 read value 46 try 22 dev.acpi_snc.0.brightness: 17 -> 18 read value 138 try 23 dev.acpi_snc.0.brightness: 18 -> 23 read value 45 try 24 dev.acpi_snc.0.brightness: 23 -> 17 read value 46 try 25 dev.acpi_snc.0.brightness: 17 -> 18 read value 138 try 26 dev.acpi_snc.0.brightness: 18 -> 26 read value 92 try 27 dev.acpi_snc.0.brightness: 26 -> 27 read value 5 try 28 dev.acpi_snc.0.brightness: 27 -> 28 read value 195 try 29 dev.acpi_snc.0.brightness: 28 -> 29 read value 232 try 30 dev.acpi_snc.0.brightness: 29 -> 30 read value 237 try 31 dev.acpi_snc.0.brightness: 30 -> 8 read value 255 try 32 dev.acpi_snc.0.brightness: 8 -> 32 read value 203 try 33 dev.acpi_snc.0.brightness: 32 -> 0 read value 0 try 34 dev.acpi_snc.0.brightness: 0 -> 34 read value 188 try 35 dev.acpi_snc.0.brightness: 34 -> 16 read value 57 try 36 dev.acpi_snc.0.brightness: 16 -> 11 read value 1 try 37 dev.acpi_snc.0.brightness: 11 -> 28 read value 195 try 38 dev.acpi_snc.0.brightness: 28 -> 16 read value 57 try 39 dev.acpi_snc.0.brightness: 16 -> 27 read value 2 try 40 dev.acpi_snc.0.brightness: 27 -> 40 read value 220 try 41 dev.acpi_snc.0.brightness: 40 -> 16 read value 57 try 42 dev.acpi_snc.0.brightness: 16 -> 9 read value 5 try 43 dev.acpi_snc.0.brightness: 9 -> 43 read value 235 try 44 dev.acpi_snc.0.brightness: 43 -> 16 read value 57 try 45 dev.acpi_snc.0.brightness: 16 -> 45 read value 9 try 46 dev.acpi_snc.0.brightness: 45 -> 46 read value 45 try 47 dev.acpi_snc.0.brightness: 46 -> 47 read value 58 try 48 dev.acpi_snc.0.brightness: 47 -> 48 read value 10 try 49 dev.acpi_snc.0.brightness: 48 -> 49 read value 73 try 50 dev.acpi_snc.0.brightness: 49 -> 47 read value 58 try 51 dev.acpi_snc.0.brightness: 47 -> 51 read value 11 try 52 dev.acpi_snc.0.brightness: 51 -> 52 read value 107 try 53 dev.acpi_snc.0.brightness: 52 -> 47 read value 58 try 54 dev.acpi_snc.0.brightness: 47 -> 54 read value 61 try 55 dev.acpi_snc.0.brightness: 54 -> 55 read value 8 try 56 dev.acpi_snc.0.brightness: 55 -> 56 read value 78 try 57 dev.acpi_snc.0.brightness: 56 -> 57 read value 5 try 58 dev.acpi_snc.0.brightness: 57 -> 58 read value 33 try 59 dev.acpi_snc.0.brightness: 58 -> 59 read value 86 try 60 dev.acpi_snc.0.brightness: 59 -> 60 read value 190 try 61 dev.acpi_snc.0.brightness: 60 -> 61 read value 126 try 62 dev.acpi_snc.0.brightness: 61 -> 16 read value 57 try 63 dev.acpi_snc.0.brightness: 16 -> 17 read value 46 try 64 dev.acpi_snc.0.brightness: 17 -> 64 read value 56 try 65 dev.acpi_snc.0.brightness: 64 -> 65 read value 28 try 66 dev.acpi_snc.0.brightness: 65 -> 66 read value 116 try 67 dev.acpi_snc.0.brightness: 66 -> 67 read value 5 try 68 dev.acpi_snc.0.brightness: 67 -> 68 read value 131 try 69 dev.acpi_snc.0.brightness: 68 -> 69 read value 198 try 70 dev.acpi_snc.0.brightness: 69 -> 70 read value 3 try 71 dev.acpi_snc.0.brightness: 70 -> 71 read value 129 try 72 dev.acpi_snc.0.brightness: 71 -> 72 read value 254 try 73 dev.acpi_snc.0.brightness: 72 -> 73 read value 147 try 74 dev.acpi_snc.0.brightness: 73 -> 16 read value 57 try 75 dev.acpi_snc.0.brightness: 16 -> 57 read value 117 try 76 dev.acpi_snc.0.brightness: 57 -> 76 read value 242 try 77 dev.acpi_snc.0.brightness: 76 -> 77 read value 5 try 78 dev.acpi_snc.0.brightness: 77 -> 3 read value 50 try 79 dev.acpi_snc.0.brightness: 3 -> 79 read value 228 try 80 dev.acpi_snc.0.brightness: 79 -> 43 read value 235 try 81 dev.acpi_snc.0.brightness: 43 -> 45 read value 9 try 82 dev.acpi_snc.0.brightness: 45 -> 17 read value 46 try 83 dev.acpi_snc.0.brightness: 17 -> 8 read value 255 try 84 dev.acpi_snc.0.brightness: 8 -> 84 read value 84 try 85 dev.acpi_snc.0.brightness: 84 -> 11 read value 1 try 86 dev.acpi_snc.0.brightness: 11 -> 77 read value 94 try 87 dev.acpi_snc.0.brightness: 77 -> 87 read value 5 try 88 dev.acpi_snc.0.brightness: 87 -> 27 read value 2 try 89 dev.acpi_snc.0.brightness: 27 -> 3 read value 50 try 90 dev.acpi_snc.0.brightness: 3 -> 90 read value 192 try 91 dev.acpi_snc.0.brightness: 90 -> 91 read value 207 try 92 dev.acpi_snc.0.brightness: 91 -> 92 read value 233 try 93 dev.acpi_snc.0.brightness: 92 -> 93 read value 202 try 94 dev.acpi_snc.0.brightness: 93 -> 94 read value 25 try 95 dev.acpi_snc.0.brightness: 94 -> 29 read value 232 try 96 dev.acpi_snc.0.brightness: 29 -> 96 read value 171 try 97 dev.acpi_snc.0.brightness: 96 -> 8 read value 5 try 98 dev.acpi_snc.0.brightness: 8 -> 98 read value 180 try 99 dev.acpi_snc.0.brightness: 98 -> 56 read value 78 try 100 dev.acpi_snc.0.brightness: 56 -> 100 read value 248 Real display brightness changed according "read value %d", so while this operations screen brightness was jumping. Playing with other values gives not result. -- Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 09:51:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B162E16A4CE for ; Wed, 1 Sep 2004 09:51:08 +0000 (GMT) Received: from zone3.gcu-squad.org (zone3.gcu-squad.org [217.19.50.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1067D43D1F for ; Wed, 1 Sep 2004 09:51:06 +0000 (GMT) (envelope-from imil@home.imil.net) Received: from localhost.gcu-squad.org (IDENT:imil@localhost.gcu-squad.org [127.0.0.1]) by zone3.gcu-squad.org (8.13.1/8.13.1) with ESMTP id i819oDhL050095; Wed, 1 Sep 2004 11:50:13 +0200 (CEST) (envelope-from imil@home.imil.net) Date: Wed, 1 Sep 2004 11:50:10 +0200 (CEST) From: iMil X-X-Sender: imil@zone3.gcu-squad.org To: bettan In-Reply-To: <000a01c48ffe$04493bf0$0301a8c0@danielle> Message-ID: <20040901114529.V88889@zone3.gcu-squad.org> References: <000a01c48ffe$04493bf0$0301a8c0@danielle> X-GPG-Fingerprint: 8431 79E4 A08B D1B7 0DC8 0BDF 146D C194 65B2 CD42 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@freebsd.org Subject: Re: wg311 v2 on freebsd 5.2-current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 09:51:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 1 Sep 2004, bettan wrote: > hello, i buy this wireless card but it isn't recognized on freebsd 5.2 > -current.I have compiled my kernel with device wlan , device ath and > device ath_hal however.Anyone have a solution for this wireless card ? WG311v2 has an acx111 chip, not an Atheros as one could imagine. You must use the NDISulator (google search Project Evil WG311v2) to get this card working on FreeBSD. Regards, - ------------------------- iMil _ http://gcu-squad.org ASCII ribbon campaign ( ) - against HTML email X & vCards / \ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBNZtVFG3BlGWyzUIRAjDDAJ4pjBvTuSvyBAMnXapZ9HgYi3q4KgCfVG8O jqsJztyWcXAKhAG0EH1KKGA= =JL5b -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 09:52:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E74C116A4CE; Wed, 1 Sep 2004 09:52:14 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87AF843D62; Wed, 1 Sep 2004 09:52:14 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id i819qDDx050420; Wed, 1 Sep 2004 05:52:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i819qDNI027934; Wed, 1 Sep 2004 05:52:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id ABC217303F; Wed, 1 Sep 2004 05:52:13 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040901095213.ABC217303F@freebsd-current.sentex.ca> Date: Wed, 1 Sep 2004 05:52:13 -0400 (EDT) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 09:52:15 -0000 TB --- 2004-09-01 09:25:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-01 09:25:01 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-09-01 09:25:01 - checking out the source tree TB --- 2004-09-01 09:25:01 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2004-09-01 09:25:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-01 09:30:12 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-01 09:30:12 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-09-01 09:30:12 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ./machine/param.h:101:23: opt_sched.h: No such file or directory In file included from /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include/sys/param.h:109, from /tinderbox/CURRENT/amd64/amd64/src/lib/libstand/cd9660.c:43: ./machine/param.h:101:23: opt_sched.h: No such file or directory In file included from /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include/sys/param.h:109, from /tinderbox/CURRENT/amd64/amd64/src/lib/libstand/ext2fs.c:92: ./machine/param.h:101:23: opt_sched.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/lib/libstand. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/lib. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-09-01 09:52:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-01 09:52:13 - ERROR: failed to build world TB --- 2004-09-01 09:52:13 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 10:06:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 202BB16A4CE; Wed, 1 Sep 2004 10:06:02 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8C7543D5D; Wed, 1 Sep 2004 10:06:01 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id i81A61SF052767; Wed, 1 Sep 2004 06:06:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i81A602j032490; Wed, 1 Sep 2004 06:06:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DF2EB7303F; Wed, 1 Sep 2004 06:06:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040901100600.DF2EB7303F@freebsd-current.sentex.ca> Date: Wed, 1 Sep 2004 06:06:00 -0400 (EDT) Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 10:06:02 -0000 TB --- 2004-09-01 09:52:13 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-01 09:52:13 - starting CURRENT tinderbox run for i386/i386 TB --- 2004-09-01 09:52:13 - checking out the source tree TB --- 2004-09-01 09:52:13 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2004-09-01 09:52:13 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-01 09:56:15 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-01 09:56:15 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2004-09-01 09:56:15 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] echo '#endif /* GCC_TM_H */' >> tm.h rm -f .depend mkdep -f .depend -a -DCRT_BEGIN -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -I/tinderbox/CURRENT/i386/i386/src/gnu/lib/csu/../../../contrib/gcc/config -I/tinderbox/CURRENT/i386/i386/src/gnu/lib/csu/../../../contrib/gcc -I. -I/tinderbox/CURRENT/i386/i386/src/gnu/lib/csu/../../usr.bin/cc/cc_tools /tinderbox/CURRENT/i386/i386/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c In file included from /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/usr/include/sys/param.h:109, from /tinderbox/CURRENT/i386/i386/src/gnu/lib/csu/../../usr.bin/cc/cc_tools/auto-host.h:4, from /tinderbox/CURRENT/i386/i386/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:60: /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/usr/include/machine/param.h:101:23: opt_sched.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/gnu/lib/csu. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2004-09-01 10:06:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-01 10:06:00 - ERROR: failed to build world TB --- 2004-09-01 10:06:00 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 10:18:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 833F116A4CE; Wed, 1 Sep 2004 10:18:35 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23B6E43D64; Wed, 1 Sep 2004 10:18:35 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id i81AIYF3052589; Wed, 1 Sep 2004 06:18:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i81AIYdp036785; Wed, 1 Sep 2004 06:18:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6D3477303F; Wed, 1 Sep 2004 06:18:34 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040901101834.6D3477303F@freebsd-current.sentex.ca> Date: Wed, 1 Sep 2004 06:18:34 -0400 (EDT) Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 10:18:35 -0000 TB --- 2004-09-01 10:06:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-01 10:06:01 - starting CURRENT tinderbox run for i386/pc98 TB --- 2004-09-01 10:06:01 - checking out the source tree TB --- 2004-09-01 10:06:01 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2004-09-01 10:06:01 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-01 10:08:34 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-01 10:08:34 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2004-09-01 10:08:34 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] echo '#endif /* GCC_TM_H */' >> tm.h rm -f .depend mkdep -f .depend -a -DCRT_BEGIN -DIN_GCC -DHAVE_LD_EH_FRAME_HDR -I/tinderbox/CURRENT/i386/pc98/src/gnu/lib/csu/../../../contrib/gcc/config -I/tinderbox/CURRENT/i386/pc98/src/gnu/lib/csu/../../../contrib/gcc -I. -I/tinderbox/CURRENT/i386/pc98/src/gnu/lib/csu/../../usr.bin/cc/cc_tools /tinderbox/CURRENT/i386/pc98/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c In file included from /home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/i386/usr/include/sys/param.h:109, from /tinderbox/CURRENT/i386/pc98/src/gnu/lib/csu/../../usr.bin/cc/cc_tools/auto-host.h:4, from /tinderbox/CURRENT/i386/pc98/src/gnu/lib/csu/../../../contrib/gcc/crtstuff.c:60: /home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/i386/usr/include/machine/param.h:101:23: opt_sched.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/gnu/lib/csu. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2004-09-01 10:18:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-01 10:18:34 - ERROR: failed to build world TB --- 2004-09-01 10:18:34 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 10:26:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0ABEF16A4CE; Wed, 1 Sep 2004 10:26:09 +0000 (GMT) Received: from axe-inc.co.jp (axegw.axe-inc.co.jp [61.199.217.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 05D1143D67; Wed, 1 Sep 2004 10:26:08 +0000 (GMT) (envelope-from takawata@axe-inc.co.jp) Received: from localhost (localhost [127.0.0.1]) by axe-inc.co.jp (8.9.3+3.2W/3.7W) with SMTP id TAA11139; Wed, 1 Sep 2004 19:25:55 +0900 (JST) Message-Id: <200409011025.TAA11139@axe-inc.co.jp> X-Authentication-Warning: axegw.axe-inc.co.jp: localhost [127.0.0.1] didn't use HELO protocol To: vova@fbsd.ru From: takawata@jp.freebsd.org In-reply-to: Your message of "Wed, 01 Sep 2004 13:43:33 +0400." <1094031813.903.13.camel@localhost> Date: Wed, 01 Sep 2004 19:25:54 +0900 Sender: takawata@axe-inc.co.jp cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: acpi_video on SONY VAIO PCG-Z1 [was: acpi_video users needed] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 10:26:09 -0000 In message <1094031813.903.13.camel@localhost>, Vladimir Grebenschikov wrote: >On Wed, 2004-09-01 at 12:43 +0400, Toxa wrote: >> On Wed, Sep 01, 2004 at 11:38:57AM +0900, takawata@jp.freebsd.org wrote: >> >> > I don't imagine why. But any other method in SNC may do something. >> > I modified the driver so that it exports more methods. >> > http://www.init-main.com/acpi_snc2.tar.gz >> >> > Testers wanted. >> >> sony vaio pcg-v505bx... > >sony vzio pcg-z1aw > >almost same: > ># sysctl dev.acpi_snc >dev.acpi_snc.0.brightness: 98 >dev.acpi_snc.0.ctr: 0 >dev.acpi_snc.0.pcr: 0 >dev.acpi_snc.0.cmi: -1044294180 >dev.acpi_snc.0.wdp: 1281 >dev.acpi_snc.0.cdp: 1 >dev.acpi_snc.0.%desc: Sony notebook controller >dev.acpi_snc.0.%driver: acpi_snc >dev.acpi_snc.0.%location: handle=\_SB_.PCI0.LPCB.SNC_ >dev.acpi_snc.0.%pnpinfo: _HID=SNY5001 _UID=0 >dev.acpi_snc.0.%parent: acpi0 ># > >dmesg message appears: > ACPI-1303: *** Error: Method execution failed [\ >\_SB_.PCI0.LPCB.SNC_.GCMI] (Node 0xc1a3a6a0), AE_AML_UNINITIALIZED_ARG > > >on each ># sysctl dev.acpi_snc.0.cmi This value should not exported in this way, it seems. Please comment out the entry in the array for defining sysctl value. >value of >dev.acpi_snc.0.brightness >change real brightness of screen but by very strange law: > ># i=1; while [ $i -le 100 ]; do echo "try $i"; sysctl >dev.acpi_snc.0.brightness=$i; echo -n 'read value '; setbrightness -- >read; i=$(($i+1)); done >read value 248 (snip) >Real display brightness changed according "read value %d", so while this >operations screen brightness was jumping. setbritness is dangerous with this driver, because it use same register without locking. How about real brightness change? From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 10:35:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B4A916A4CE for ; Wed, 1 Sep 2004 10:35:38 +0000 (GMT) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.145.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 947CE43D2D for ; Wed, 1 Sep 2004 10:35:36 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id A67BB4EFCD6; Wed, 1 Sep 2004 18:35:32 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 9CC754EFCCF for ; Wed, 1 Sep 2004 18:35:32 +0800 (CST) Date: Wed, 1 Sep 2004 18:35:32 +0800 (CST) From: Tai-hwa Liang To: current@freebsd.org Message-ID: <04090118343018.53624@www.mmlab.cse.yzu.edu.tw> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: kldload(2) smbfs failed in -CURRENT but kernel function returns 0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 10:35:38 -0000 Greetings, Apparently the first time mount_smbfs was executed, smbfs related modules will be loaded by kldload(2); however, the result of the first kldload(2) was always ENOENT even if smbfs.ko was successfully loaded. Only the later run of mount_smbfs works. It also interesting since manually "kldload smbfs" or even load smbfs in /boot/loader.conf never run into ENOENT error. Furthermore, according to various debugging printf() inserted in kldload() or linker_load_module(), the return code is definitely zero. Any ideas about how this could happen? f22 /root# mount_smbfs //user@smbshare/upload /mnt mount_smbfs: kldload(smbfs): No such file or directory f22 /root# mount_smbfs //user@smbshare/upload /mnt Password: relevant ktrace information: 598 mount_smbfs CALL kldload(0x80496a6) 598 mount_smbfs NAMI "/boot/kernel/linker.hints" 598 mount_smbfs NAMI "/boot/kernel/smbfs" 598 mount_smbfs NAMI "/boot/kernel/smbfs.ko" 598 mount_smbfs NAMI "/boot/kernel/smbfs.ko" 598 mount_smbfs NAMI "/boot/kernel/linker.hints" 598 mount_smbfs NAMI "/boot/kernel/libiconv.ko" 598 mount_smbfs NAMI "/boot/kernel/libiconv.ko" 598 mount_smbfs NAMI "/boot/kernel/linker.hints" 598 mount_smbfs NAMI "/boot/kernel/libmchain.ko" 598 mount_smbfs NAMI "/boot/kernel/libmchain.ko" 598 mount_smbfs RET kldload 18/0x12 598 mount_smbfs CALL fstat(0x1,0xbfbfd990) 598 mount_smbfs RET fstat 0 598 mount_smbfs CALL ioctl(0x1,TIOCGETA,0xbfbfd9d0) 598 mount_smbfs RET ioctl 0 598 mount_smbfs CALL write(0x1,0x804d000,0xa) 598 mount_smbfs GIO fd 1 wrote 10 bytes "error = 2 " 598 mount_smbfs RET write 10/0xa From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 10:45:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1684A16A4CE for ; Wed, 1 Sep 2004 10:45:09 +0000 (GMT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id B56CF43D1F for ; Wed, 1 Sep 2004 10:45:07 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id i81Aj5is054573 for ; Wed, 1 Sep 2004 14:45:05 +0400 (MSD) (envelope-from is@rambler-co.ru) Date: Wed, 1 Sep 2004 14:47:59 +0400 (MSD) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: freebsd-current@freebsd.org Message-ID: <20040901144705.K97970@is.park.rambler.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: panic caused by EVFILT_SIGNAL detaching in rfork()ed thread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 10:45:09 -0000 5.3-BETA2 still may panic as described in http://freebsd.rambler.ru/bsdmail/freebsd-hackers_2004/msg02732.html #0 doadump () at pcpu.h:159 #1 0xc05ffbf4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:396 #2 0xc05fff13 in panic (fmt=0xc07bca72 "from debugger") at /usr/src/sys/kern/kern_shutdown.c:558 #3 0xc045fe89 in db_panic (addr=-1067481728, have_addr=0, count=-1, modif=0xeacfd92c "") at /usr/src/sys/ddb/db_command.c:435 #4 0xc045fe20 in db_command (last_cmdp=0xc0894604, cmd_table=0x0, aux_cmd_tablep=0xc08150d4, aux_cmd_tablep_end=0xc08150f0) at /usr/src/sys/ddb/db_command.c:349 #5 0xc045fee8 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #6 0xc0461a4d in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_main.c:221 #7 0xc0616b03 in kdb_trap (type=12, code=0, tf=0x1) at /usr/src/sys/kern/subr_kdb.c:418 #8 0xc0787efd in trap_fatal (frame=0xeacfdac4, eva=28) at /usr/src/sys/i386/i386/trap.c:807 #9 0xc0787c5b in trap_pfault (frame=0xeacfdac4, usermode=0, eva=28) at /usr/src/sys/i386/i386/trap.c:730 #10 0xc07878a1 in trap (frame= {tf_fs = -1067319272, tf_es = -1064632304, tf_ds = -1010368496, tf_edi = -1065428340, tf_esi = 1502, tf_ebp = -355476720, tf_isp = -355476752, tf_ebx = 0, tf_edx = 4, tf_ecx = 2, tf_eax = -1013504780, tf_trapno = 12, tf_err = 0, tf_eip = -1067481728, tf_cs = 8, tf_eflags = 66118, tf_esp = -1008610988, tf_ss = 0}) at /usr/src/sys/i386/i386/trap.c:417 #11 0xc077631a in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #12 0xc0620018 in removechild (parent=0x0, child=0x5de) at /usr/src/sys/kern/subr_witness.c:1443 #13 0xc05e86ab in knlist_remove_kq (knl=0xc39724f4, kn=0x0, knlislocked=-1065428340, kqislocked=0) at /usr/src/sys/kern/kern_event.c:1502 #14 0xc05e87b3 in knlist_remove (knl=0xc39724f4, kn=0xc3e1d154, islocked=0) at /usr/src/sys/kern/kern_event.c:1527 #15 0xc060451b in filt_sigdetach (kn=0x0) at /usr/src/sys/kern/kern_sig.c:2733 #16 0xc05e826a in kqueue_close (fp=0xc394ebb0, td=0xc3a22420) at /usr/src/sys/kern/kern_event.c:1372 #17 0xc05e5524 in fdrop_locked (fp=0xc394ebb0, td=0xc3a22420) at file.h:289 #18 0xc05e47b8 in fdrop (fp=0xc394ebb0, td=0xc3a22420) at /usr/src/sys/kern/kern_descrip.c:1897 #19 0xc05e478b in closef (fp=0xc394ebb0, td=0xc3a22420) at /usr/src/sys/kern/kern_descrip.c:1883 #20 0xc05e40e7 in fdfree (td=0xc3a22420) at /usr/src/sys/kern/kern_descrip.c:1610 #21 0xc05ea896 in exit1 (td=0xc3a22420, rv=0) at /usr/src/sys/kern/kern_exit.c:242 #22 0xc05ea494 in sys_exit (td=0xc3a22420, uap=0x0) at /usr/src/sys/kern/kern_exit.c:94 #23 0xc07881cf in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 2, tf_esi = 134873108, tf_ebp = -1077941784, tf_isp = -355476108, tf_ebx = 672658924, tf_edx = 10, tf_ecx = 672658608, tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 672162923, tf_cs = 31, tf_eflags = 662, tf_esp = -1077941812, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1004 #24 0xc077636f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:201 [ ... ] (kgdb) fr 15 #15 0xc060451b in filt_sigdetach (kn=0x0) at /usr/src/sys/kern/kern_sig.c:2733 2733 knlist_remove(&p->p_klist, kn, 0); (kgdb) down #14 0xc05e87b3 in knlist_remove (knl=0xc39724f4, kn=0xc3e1d154, islocked=0) at /usr/src/sys/kern/kern_event.c:1527 1527 knlist_remove_kq(knl, kn, islocked, 0); (kgdb) p *knl $1 = {kl_lock = 0x0, kl_list = {slh_first = 0x0}} However, I do not know is it safe to test !SLIST_EMPTY(&p->p_klist) in filt_sigdetach() because in 5.3-BETA2 kqueue uses own mutex. Unfortunately, I could not just now to write a small test case to allow everyone to reproduce the panic but my user-level server always causes panic on exit on unpatched 5.x and sometimes on unpatched 4.10. Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 10:49:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80D8916A4CE; Wed, 1 Sep 2004 10:49:19 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C8D443D5D; Wed, 1 Sep 2004 10:49:18 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1C2Sg0-0002Xg-2d; Wed, 01 Sep 2004 14:49:16 +0400 From: Vladimir Grebenschikov To: takawata@jp.freebsd.org In-Reply-To: <200409011025.TAA11139@axe-inc.co.jp> References: <200409011025.TAA11139@axe-inc.co.jp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Wed, 01 Sep 2004 14:49:15 +0400 Message-Id: <1094035755.903.19.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.93FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: freebsd-acpi@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: acpi_video on SONY VAIO PCG-Z1 [was: acpi_video users needed] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 10:49:19 -0000 On Wed, 2004-09-01 at 19:25 +0900, takawata@jp.freebsd.org wrote: > In message <1094031813.903.13.camel@localhost>, Vladimir Grebenschikov wrote: > >On Wed, 2004-09-01 at 12:43 +0400, Toxa wrote: > >> On Wed, Sep 01, 2004 at 11:38:57AM +0900, takawata@jp.freebsd.org wrote: > >> > >> > I don't imagine why. But any other method in SNC may do something. > >> > I modified the driver so that it exports more methods. > >> > http://www.init-main.com/acpi_snc2.tar.gz > >> > >> > Testers wanted. > >> > >> sony vaio pcg-v505bx... > > > >sony vzio pcg-z1aw > > > >almost same: > > > ># sysctl dev.acpi_snc > >dev.acpi_snc.0.brightness: 98 > >dev.acpi_snc.0.ctr: 0 > >dev.acpi_snc.0.pcr: 0 > >dev.acpi_snc.0.cmi: -1044294180 > >dev.acpi_snc.0.wdp: 1281 > >dev.acpi_snc.0.cdp: 1 > >dev.acpi_snc.0.%desc: Sony notebook controller > >dev.acpi_snc.0.%driver: acpi_snc > >dev.acpi_snc.0.%location: handle=\_SB_.PCI0.LPCB.SNC_ > >dev.acpi_snc.0.%pnpinfo: _HID=SNY5001 _UID=0 > >dev.acpi_snc.0.%parent: acpi0 > ># > > > >dmesg message appears: > > ACPI-1303: *** Error: Method execution failed [\ > >\_SB_.PCI0.LPCB.SNC_.GCMI] (Node 0xc1a3a6a0), AE_AML_UNINITIALIZED_ARG > > > > > >on each > ># sysctl dev.acpi_snc.0.cmi > > This value should not exported in this way, it seems. > Please comment out the entry in the array for defining sysctl value. > > >value of > >dev.acpi_snc.0.brightness > >change real brightness of screen but by very strange law: > > > ># i=1; while [ $i -le 100 ]; do echo "try $i"; sysctl > >dev.acpi_snc.0.brightness=$i; echo -n 'read value '; setbrightness -- > >read; i=$(($i+1)); done > >read value 248 > > (snip) > > >Real display brightness changed according "read value %d", so while this > >operations screen brightness was jumping. > > setbritness is dangerous with this driver, because it use same register > without locking. yes, i am use it only for reference > How about real change? real brightness correspond values reported by 'brightness --read' so sequential setbrightness with increasing values (1 - 255) - gives expected thing - brightness changed from low to high. If I do same thing with dev.acpi_snc.0.brightness - real brightness jumps, see values in my previous post, "read" value for corresponds physical screen brightness (in range 255 means 100%) -- Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 11:23:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 419A916A4CF for ; Wed, 1 Sep 2004 11:23:27 +0000 (GMT) Received: from ank-pki.ru (mercury.ank-pki.ru [213.170.76.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CFD343D31 for ; Wed, 1 Sep 2004 11:23:26 +0000 (GMT) (envelope-from toxa@cterra.ru) Received: (qmail 61629 invoked by uid 0); 1 Sep 2004 15:23:25 +0400 Received: from toxa@cterra.ru by mercury.ank-pki.ru by uid 0 with qmail-scanner-1.22 Clear:RC:0(213.170.76.149):SA:0(0.0/7.0):. Processed in 10.307437 secs); 01 Sep 2004 11:23:25 -0000 Received: from unknown (HELO localhost) (toxa@213.170.76.149) by ank.nwudc.ru with SMTP; 1 Sep 2004 15:23:14 +0400 Date: Wed, 1 Sep 2004 15:20:04 +0400 From: Toxa To: current@freebsd.org X-Comment-To: "Anton Karpov" Message-ID: <20040901112004.GA2625@laptoxa.toxa.lan> Mail-Followup-To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Outluck Express 1.5.6i for MS-DOS 6.22-SMP X-Mailer: See User-Agent above :) X-Operating-System: MS-DOS 6.22-CURRENT on Sony VAIO laptop X-PGP-Public-Key: http://toxahost.org/gpg/pubkey.asc X-Useless-Header: Do Androids Dream of Electric Sheep? X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mercury.ank-pki.ru X-Spam-Level: X-Spam-Status: No, hits=0.0 required=7.0 tests=none autolearn=no version=2.64 Subject: something like net.link.ether.bridge_pf? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 11:23:27 -0000 I guess that pf now cannot be used on bridge, I can't see something similar to net.link.ether.bridge_pf (only net.link.ether.bridge_ipfw and net.link.ether.bridge_ipf), as the result, my fbsd machine can act as bridge, but pf rules actually doesn't work, simply allowing all connections. Is it possible to use pf on bridge? I want to move my bridge back from obsd to fbsd. -- Anton A. Karpov PGP key: http://www.toxahost.org/pgp/pubkey.asc You can finger me @toxahost.org for my current status =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~= "Anyone who quotes me in their sig is an idiot." Rusty Russell. =~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~=~= From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 11:35:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 59F3F16A4CE; Wed, 1 Sep 2004 11:35:34 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1500C43D5A; Wed, 1 Sep 2004 11:35:34 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.42 (FreeBSD)) id 1C2TOm-0002gp-MZ; Wed, 01 Sep 2004 15:35:32 +0400 From: Vladimir Grebenschikov To: Kevin Lo In-Reply-To: <1094019760.2672.2.camel@localhost.localdomain> References: <200408301916.22240.mjohnston@skyweb.ca> <4133DA04.4030103@us.army.mil> <1093938230.961.8.camel@localhost> <1094019760.2672.2.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: SWsoft Date: Wed, 01 Sep 2004 15:35:32 +0400 Message-Id: <1094038532.903.23.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 1.5.93FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: Jonathan cc: "current@freebsd.org" Subject: Re: cvs-src summary for August 23-30 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 11:35:34 -0000 On Wed, 2004-09-01 at 14:22 +0800, Kevin Lo wrote: > > Also port version is 1.0.14 when latest stable version 1.1.7. > > > > Fresh version not builds due to 'alloca' redefinition. > > I just updated to synergy 1.1.8. Please update the ports tree :-) Thank you, fresh version works good. > Kevin -- Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 11:57:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0006416A4CE; Wed, 1 Sep 2004 11:57:25 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 846F143D5A; Wed, 1 Sep 2004 11:57:25 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id i81BvON4063508; Wed, 1 Sep 2004 07:57:24 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i81BvNEe074941; Wed, 1 Sep 2004 07:57:23 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3122E7303F; Wed, 1 Sep 2004 07:57:23 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040901115723.3122E7303F@freebsd-current.sentex.ca> Date: Wed, 1 Sep 2004 07:57:23 -0400 (EDT) Subject: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 11:57:26 -0000 TB --- 2004-09-01 10:18:34 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-01 10:18:34 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2004-09-01 10:18:34 - checking out the source tree TB --- 2004-09-01 10:18:34 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2004-09-01 10:18:34 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-01 10:21:30 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-01 10:21:30 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2004-09-01 10:21:30 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-09-01 11:47:55 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-01 11:47:55 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2004-09-01 11:47:55 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Sep 1 11:47:56 UTC 2004 >>> 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 [...] /tinderbox/CURRENT/ia64/ia64/src/sys/kern/subr_smp.c:498: undefined reference to `all_cpus' uma_core.o(.text+0x3fa1): In function `zone_timeout': /tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:382: undefined reference to `all_cpus' uma_core.o(.text+0x6a21): In function `zone_dtor': /tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:1423: undefined reference to `all_cpus' uma_core.o(.text+0x8730): In function `uma_print_zone': /tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:2657: undefined reference to `all_cpus' uma_core.o(.text+0x8c31):/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:2710: more undefined references to `all_cpus' follow *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2004-09-01 11:57:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-01 11:57:23 - ERROR: failed to build generic kernel TB --- 2004-09-01 11:57:23 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 15:14:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBDBC16A4CE for ; Tue, 31 Aug 2004 15:14:46 +0000 (GMT) Received: from ithil.ics.muni.cz (ithil.ics.muni.cz [147.251.4.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B3E043D49 for ; Tue, 31 Aug 2004 15:14:46 +0000 (GMT) (envelope-from hopet@ics.muni.cz) Received: from KLOBOUCEK (kloboucek.ics.muni.cz [147.251.3.38]) (user=hopet@META mech=LOGIN bits=0) by ithil.ics.muni.cz (8.12.1/8.12.1) with ESMTP id i7VFEgAb014900 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 31 Aug 2004 17:14:42 +0200 From: "Petr Holub" To: "Robin Schoonover" Date: Tue, 31 Aug 2004 17:14:30 +0200 Message-ID: <084901c48f6d$36fbdee0$02e86cc2@KLOBOUCEK> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal In-Reply-To: <20040831084218.08086b9f@sed> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Muni-Spam-TestIP: 147.251.3.38 X-Muni-Virus-Test: Clean X-Mailman-Approved-At: Wed, 01 Sep 2004 12:16:11 +0000 cc: current@freebsd.org Subject: RE: drm: ATI FireGL Mobility T2 patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 15:14:46 -0000 > Last I knew, dri support in xorg/xfree did not include the FireGL cards. > If this is the case, is this really at all useful? Yep. But it will be ready when the support is added to xorg/xfree. That's the reason of the patch. Petr ================================================================ Petr Holub CESNET z.s.p.o. Supercomputing Center Brno Zikova 4 Institute of Compt. Science 162 00 Praha 6, CZ Masaryk University Czech Republic Botanicka 68a, 60200 Brno, CZ e-mail: Petr.Holub@cesnet.cz phone: +420-549493944 fax: +420-541212747 e-mail: hopet@ics.muni.cz From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 17:05:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB44D16A4CE for ; Tue, 31 Aug 2004 17:05:46 +0000 (GMT) Received: from peedub.jennejohn.org (Gec41.g.pppool.de [80.185.236.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FB5543D2F for ; Tue, 31 Aug 2004 17:05:46 +0000 (GMT) (envelope-from garyj@www.jennejohn.org) Received: from www.jennejohn.org (localhost [127.0.0.1]) by peedub.jennejohn.org (8.13.1/8.11.6) with ESMTP id i7VH5R2A073646; Tue, 31 Aug 2004 19:05:27 +0200 (CEST) (envelope-from garyj@www.jennejohn.org) Message-Id: <200408311705.i7VH5R2A073646@peedub.jennejohn.org> X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Dan Nelson In-Reply-To: Message from Dan Nelson <20040831151437.GE33896@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 31 Aug 2004 19:05:27 +0200 From: Gary Jennejohn X-Mailman-Approved-At: Wed, 01 Sep 2004 12:16:11 +0000 cc: Vladimir Grebenschikov cc: "current@freebsd.org" Subject: Re: sysutils/strace wilderness on 6-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 17:05:46 -0000 Dan Nelson writes: > In the last episode (Aug 31), Vladimir Grebenschikov said: > > (fresh -CURREMT and fresh strace from ports, UP machine) > > > > It silmple does nothing - sleeps foreaver in suspended: > > > > # strace /bin/ls > > ^T > > load: 0.14 cmd: strace 98957 [suspended] 0.00u 0.00s 0% 760k > > ^C > > # > > This has happened on 5.x for ages. The quick fix is to ^Z, then fg, or > kill -CONT the hung strace process from another vty. I don't know what > strace does different from truss that makes it hang. Nowadays, truss > does almost as good a job as strace, so I don't use it as often as I > used to. The only thing I miss is strace's ability to print the name > of blocking syscalls (read or sleep for example) as it waits. > I fixed a bug like this in strace for Linux. The SIGCHLD handler was being set too late and the child (through some wacky handling of SIGCHLD in the Linux kernel) got into a state where it never returned the expected status in wait(). Both the child and strace ended up hanging. kill -CONT also got things going there. Maybe FreeBSD has a similar problem? --- Gary Jennejohn / garyj[at]jennejohn.org gj[at]freebsd.org gj[at]denx.de From owner-freebsd-current@FreeBSD.ORG Tue Aug 31 22:24:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4759E16A4CE for ; Tue, 31 Aug 2004 22:24:21 +0000 (GMT) Received: from wxinmail01.webexc.com (wxinmail01.webexc.com [209.43.0.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD6C643D31 for ; Tue, 31 Aug 2004 22:24:20 +0000 (GMT) (envelope-from nerd@netmonkey.net) Received: from localhost (localhost [127.0.0.1]) by wxinmail01.webexc.com (Postfix) with ESMTP id 7EF0C7C608 for ; Tue, 31 Aug 2004 17:24:16 -0500 (EST) Received: from wxinmail01.webexc.com ([127.0.0.1]) by localhost (wxinmail01.webexc.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18074-04 for ; Tue, 31 Aug 2004 17:24:14 -0500 (EST) Received: from [172.17.76.105] (209-212-209-89.office.webexc.com [209.212.209.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by wxinmail01.webexc.com (Postfix) with ESMTP id 51DD17C63B for ; Tue, 31 Aug 2004 17:24:14 -0500 (EST) Message-ID: <4134FA91.1090005@netmonkey.net> Date: Tue, 31 Aug 2004 17:24:17 -0500 From: Matt Barton User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by ClamAV (via amavisd-new) on wxinmail01.webexc.com X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=5.9 tests=BAYES_00 X-Spam-Level: X-Mailman-Approved-At: Wed, 01 Sep 2004 12:16:11 +0000 Subject: Re: USB keyboard problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 31 Aug 2004 22:24:21 -0000 John Cagle wrote: > Paul Saab helped me find the solution... I had to do this in the > loader from the 5.3BETA install CD: > > set hint.atkbd.0.flags="0x1" > > Can this be fixed in 5.3? 5.2.1 worked fine with this PC. I'm having a problem with my USB keyboard, whereas the caps-, scroll-, and num-lock keys work just fine, but I'm not able to type anything. I attempted to do the above "hint," but that did not do the trick. I am attaching a copy of my dmesg output. Sources were cvsup'd sometime in the evening (EST) on August 29th. ====< SNIP >==== Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-BETA2 #0: Mon Aug 30 00:22:56 EST 2004 matt@uranus.baghdad.netmonkey.net:/usr/obj/usr/src/sys/URANUS Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 2000+ (1670.46-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x681 Stepping = 1 Features=0x383fbff AMD Features=0xc0400000 real memory = 536805376 (511 MB) avail memory = 511430656 (487 MB) netsmb_dev: loaded npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 acpi link get: empty IRQ resource acpi link get: empty IRQ resource acpi link get: empty IRQ resource acpi link get: empty IRQ resource acpi link get: empty IRQ resource acpi link get: empty IRQ resource acpi link get: empty IRQ resource acpi link get: empty IRQ resource acpi link get: empty IRQ resource acpi link get: empty IRQ resource pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xe8001000-0xe8001fff irq 3 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xe8002000-0xe8002fff irq 7 at device 2.1 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: SMM does not respond, resetting usb1: on ohci1 usb1: USB revision 1.0 uhub1: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ehci0: mem 0xe8003000-0xe80030ff irq 5 at device 2.2 on pci0 ehci0: [GIANT-LOCKED] ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 usb2: EHCI version 1.0 usb2: companion controllers, 4 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 6 ports with 6 removable, self powered pcm0: port 0xe400-0xe47f,0xe000-0xe0ff mem 0xe8000000-0xe8000fff irq 10 at device 6 .0 on pci0 pcm0: [GIANT-LOCKED] pcm0: pcib1: at device 8.0 on pci0 pci1: on pcib1 sis0: port 0xd000-0xd0ff mem 0xe7000000-0xe7000fff irq 11 at devic e 7.0 on pci1 sis0: Silicon Revision: DP83816A miibus0: on sis0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto sis0: Ethernet address: 00:09:5b:1f:76:ef sis0: [GIANT-LOCKED] atapci0: port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 9.0 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pcib2: at device 30.0 on pci0 pci2: on pcib2 nvidia0: mem 0xd8000000-0xd807ffff,0xd0000000-0xd7ffffff,0xe4000000-0xe4ffffff irq 11 at device 0.0 on pci2 nvidia0: [GIANT-LOCKED] fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 pmtimer0 on isa0 orm0: at iomem 0xd0000-0xd3fff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 device_attach: atkbd0 attach returned 6 Timecounter "TSC" frequency 1670462942 Hz quality 800 Timecounters tick every 10.000 msec IPsec: Initialized Security Association Processing. ad0: 78167MB [158816/16/63] at ata0-master UDMA133 ATAPI_RESET time = 120us acd0: DVDROM at ata1-master UDMA33 Mounting root from ufs:/dev/ad0s2a uhub3: Philips Semiconductors hub, class 9/0, rev 1.10/1.10, addr 2 uhub3: 5 ports with 5 removable, self powered uhub4: Microsoft Internet Keyboard Pro, class 9/0, rev 1.10/5.00, addr 3 uhub4: 3 ports with 2 removable, bus powered ukbd0: Microsoft Microsoft Natural Keyboard Pro, rev 1.10/1.14, addr 4, iclass 3/1 kbd0 at ukbd0 uhid0: Microsoft Microsoft Natural Keyboard Pro, rev 1.10/1.14, addr 4, iclass 3/1 ums0: Microsoft Microsoft IntelliMouse\M-. Optical, rev 1.10/1.21, addr 5, iclass 3/1 ums0: 5 buttons and Z dir. uhub3: device problem, disabling port 5 uhub3: at uhub0 port 2 (addr 2) disconnected ukbd0: detached uhid0: detached uhub4: detached ums0: detached uhub3: detached -- Matt Barton nerd@netmonkey.net From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 01:16:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1A3C816A4CE; Wed, 1 Sep 2004 01:16:45 +0000 (GMT) Received: from corbulon.video-collage.com (corbulon.video-collage.com [64.35.99.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF0EE43D3F; Wed, 1 Sep 2004 01:16:44 +0000 (GMT) (envelope-from mi+mxmoz@aldan.algebra.com) Received: from 250-217.customer.cloud9.net (195-11.customer.cloud9.net [168.100.195.11])i811GggA088436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 31 Aug 2004 21:16:43 -0400 (EDT) (envelope-from mi+mxmoz@aldan.algebra.com) Received: from [127.0.0.1] (mteterin@localhost [127.0.0.1]) i811GUGs055998; Tue, 31 Aug 2004 21:16:30 -0400 (EDT) (envelope-from mi+mxmoz@aldan.algebra.com) Message-ID: <413522EE.5080806@aldan.algebra.com> Date: Tue, 31 Aug 2004 21:16:30 -0400 From: Mikhail Teterin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; uk-UA; rv:1.7) Gecko/20040702 X-Accept-Language: uk, en-us, en MIME-Version: 1.0 To: current@FreeBSD.org, freebsd-amd64@FreeBSD.org Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version devel-20040615, clamav-milter version 0.73a on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Wed, 01 Sep 2004 12:16:11 +0000 Subject: -current buildworld fails on amd64 (5.2.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 01:16:45 -0000 Starting with an empty /usr/obj: cc -DHAVE_CONFIG_H -DCOMPILE_ONLY -I/usr/src/lib/libmagic -I/usr/src/lib/libmagic/../../contrib/file -o mkmagic /usr/src/lib/libmagic/../../contrib/file/apprentice.c /usr/src/lib/libmagic/../../contrib/file/funcs.c /usr/src/lib/libmagic/../../contrib/file/magic.c /usr/src/lib/libmagic/../../contrib/file/print.c /usr/obj/usr/src/amd64/usr/bin/ld: cannot find -lc *** Error code 1 [...] Any clues? Thanks! -mi From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 01:19:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E03F16A4CE for ; Wed, 1 Sep 2004 01:19:14 +0000 (GMT) Received: from digitalfreaks.org (digitalfreaks.org [216.151.95.156]) by mx1.FreeBSD.org (Postfix) with SMTP id DE44F43D45 for ; Wed, 1 Sep 2004 01:19:13 +0000 (GMT) (envelope-from ziccardi@digitalfreaks.org) Received: (qmail 15400 invoked by uid 1000); 1 Sep 2004 01:18:53 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 1 Sep 2004 01:18:53 -0000 Date: Tue, 31 Aug 2004 21:18:53 -0400 (EDT) From: Chad Ziccardi To: current@freebsd.org In-Reply-To: <20040831054536.D46320@digitalfreaks.org> Message-ID: <20040831211626.L9079@digitalfreaks.org> References: <20040831054536.D46320@digitalfreaks.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 01 Sep 2004 12:16:11 +0000 Subject: Re: vinum root issue on 5.3-Beta2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 01:19:14 -0000 just an additional note to this, if I boot it the 1st way, and add a new set of drives (mirror -n m-usr -v /dev/ad0s1d /dev/ad2s1d) it does that one correctly, again.. until I reboot using that setup, which the vinumdriveX associated with /dev/ad2 all show referenced. begin quote from Chad Ziccardi written 2004-08-31: > > I'm working on setting up a mirrored root filesystem as explained in: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/vinum-root.html > > I've gotten it to boot then noticed something broken about it on my setup. > > More info on my setup is at the bottom of this message. > > If it boots to the vinum partition it does not properly load vinum. > How to explain that better.. > booting normal as described in the handbook (loader.conf settings) > it appears to only read ad0s1h for data, thus never fully comes up. > > I get among the various warnings (a slice is missing!) > > vinum: incompatible sector sizes. m-root.p1 has 0, m-root has 512. Ignored. > Mounting root from ufs:/dev/vinum/m-root > vinum -> ld > D vinumdrive0 State: up /dev/ad0s1h A: 0/1023 MB (0%) > D vinumdrive1 State: referenced unknown A: 0/0 MB > since it can't see vinumdrive1 the plex and subdisks are faulty. > > > > > However booting to the a slice without using vinum (removed from loader.conf) > booted up on ad0s1a(or ad0s1h)(half of the mirror) > > then doing vinum start after logging in I get: > > vinum: reading configuration from /dev/ad2s1h > vinum: updating configuration from /dev/ad0s1h > Aug 31 05:55:06 kernel: vinum: reading configuration from /dev/ad2s1h > Aug 31 05:55:06 kernel: vinum: updating configuration from /dev/ad0s1h > > vinum -> ld > D vinumdrive1 State: up /dev/ad2s1h A: 0/1023 MB (0%) > D vinumdrive0 State: up /dev/ad0s1h A: 0/1023 MB (0%) > > > > Is this a known issue? Is there something wrong with how I've set it up? > > > > > info from dmesg: > ---------------- > FreeBSD 5.3-BETA2 #0: Tue Aug 31 01:21:06 UTC 2004 > root@:/usr/obj/usr/src/sys/ARBITOR > ... > ad0: 157066MB [319120/16/63] at ata0-master UDMA66 > ATAPI_RESET time = 34920us > ata1-master: DMA limited to UDMA33, non-ATA66 cable or device > ad2: 157066MB [319120/16/63] at ata1-master UDMA33 > acd0: CDROM at ata1-slave PIO4 > > > > disklabels: > ----------- > # /dev/ad0s1: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 2096871 281 4.2BSD 2048 16384 11761 > b: 4999480 316669952 swap > c: 321669432 0 unused 0 0 # "raw" part, don't > edit > d: 16777216 2097152 4.2BSD 2048 16384 28552 > e: 4194304 18874368 4.2BSD 0 0 0 > f: 188743680 23068672 4.2BSD 0 0 0 > g: 104857600 211812352 4.2BSD 0 0 0 > h: 2097136 16 vinum > > # /dev/ad2s1: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 2096871 281 4.2BSD 2048 16384 11761 > b: 4999480 316669952 swap > c: 321669432 0 unused 0 0 # "raw" part, don't > edit > d: 16777216 2097152 4.2BSD 2048 16384 28552 > e: 4194304 18874368 4.2BSD 0 0 0 > f: 188743680 23068672 4.2BSD 0 0 0 > g: 104857600 211812352 4.2BSD 0 0 0 > h: 2097136 16 vinum > > > > -- Chad Ziccardi, Professional Slacker cz@digitalfreaks.org "Some cause happiness wherever they go; others whenever they go." From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 06:49:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 785EB16A4CF for ; Wed, 1 Sep 2004 06:49:25 +0000 (GMT) Received: from web11506.mail.yahoo.com (web11506.mail.yahoo.com [216.136.172.38]) by mx1.FreeBSD.org (Postfix) with SMTP id 4F76943D39 for ; Wed, 1 Sep 2004 06:49:25 +0000 (GMT) (envelope-from gesperon@yahoo.com) Message-ID: <20040901064925.11682.qmail@web11506.mail.yahoo.com> Received: from [68.155.78.144] by web11506.mail.yahoo.com via HTTP; Tue, 31 Aug 2004 23:49:25 PDT Date: Tue, 31 Aug 2004 23:49:25 -0700 (PDT) From: Gabor Esperon To: freebsd-questions@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Wed, 01 Sep 2004 12:16:11 +0000 cc: freebsd-current@freebsd.org Subject: Problem with Intel 82540EM Gigabit Ethernet Controller X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 06:49:25 -0000 Hi! I have an Intel 82540EM Gigabit Ethernet Controller working at 100Mb/s on FreeBSD 5-CURRENT and FreeBSD 5-BETA3: em0: flags=8843 mtu 1500 options=1b inet 192.168.1.32 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:07:e9:09:a7:37 media: Ethernet autoselect (100baseTX ) status: active thats ok, but in both systems I can only get transfers at 2.xMb/s (MBytes) as the following "netstat -w1 -I em0" show: input (em0) output packets errs bytes packets errs bytes colls 782 0 46920 1438 0 2177132 0 788 0 53500 1452 0 2209768 0 886 0 53160 1628 0 2464792 0 788 0 53904 1452 0 2208882 0 799 0 50672 1452 0 2198328 0 789 0 53572 1451 0 2206080 0 785 0 47100 1442 0 2186216 0 795 0 53944 1462 0 2218898 0 787 0 47220 1451 0 2195386 0 780 0 53004 1437 0 2189490 0 797 0 47820 1466 0 2216496 0 790 0 53692 1452 0 2209900 0 787 0 47220 1448 0 2195300 0 792 0 53832 1456 0 2210390 0 766 0 45960 1408 0 2131712 0 789 0 53472 1452 0 2211110 0 790 0 47400 1452 0 2198168 0 784 0 53352 1445 0 2198982 0 786 0 47160 1444 0 2183992 0 791 0 53652 1452 0 2209708 0 What could be the problem here? ===== Gabor Net/Sys Admin _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 12:36:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B397616A4CF for ; Wed, 1 Sep 2004 12:36:59 +0000 (GMT) Received: from huva.hittite.isp.9tel.net (huva.hittite.isp.9tel.net [62.62.156.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F57143D48 for ; Wed, 1 Sep 2004 12:36:59 +0000 (GMT) (envelope-from clefevr-current@9online.fr) Received: from pc2k (53-244-118-80.kaptech.net [80.118.244.53]) by huva.hittite.isp.9tel.net (Postfix) with SMTP id 40FF014BC10; Wed, 1 Sep 2004 14:51:10 +0200 (CEST) Message-ID: <002f01c49020$5e9df560$7890a8c0@gits.invalid> From: "Cyrille Lefevre" To: "Deng XueFeng" , "Sascha Wildner" References: <4132EDFD.4050804@erpicon.de> <20040830221036.85DE.DSNOFE@msn.com> <413350D9.4070909@online.de> <4134A1BF.1080304@online.de> Date: Wed, 1 Sep 2004 14:36:54 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 cc: current@freebsd.org Subject: Re: [BETA PATCH] VESA mode support for syscons X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Cyrille Lefevre List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 12:36:59 -0000 "Deng XueFeng" wrote: "Sascha Wildner" wrote: > > Deng XueFeng wrote: [snip] > > Oh, I saw that there are threads on freebsd-current. The issues people > > are having there with their moused complaining are due to some changes > > in vidcontrol that DragonFly has done. Since the mouse pointer is common > > to all terminals it can be turned on (and off) only once. After that, it > > has to be turned off again. moused RCNG tries to turn it on multiple > > times. This is a bug. Compare our version of moused RCNG at > > http://www.dragonflybsd.org/cgi-bin/cvsweb.cgi/src/etc/rc.d/moused?rev=1.3&content-type=text/x-cvsweb-markup > > to yours to see where the problem lies. > I have send the patch to Cyrille Lefevre who sendpr. > but forget Cc to maillist. I'll followup to this patch to the existing PR. > > I'm gonna put up a new version of the patch later this evening to be > > committed within the next few days. It has been cleaned up and extended > > so that 15 and 24 bit modes are also supported. I think it's also a bit > > faster. I'd recommend that FreeBSD (if they want our stuff) take this > > patch instead of the first one. > Cool. I will merge the patch and sendpr. please, don't send-pr again, but followup to the existing one, instead, thanks. Cyrille Lefevre. -- home: mailto:cyrille.lefevre@laposte.net From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 13:10:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AE44F16A4CE; Wed, 1 Sep 2004 13:10:39 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 254BC43D60; Wed, 1 Sep 2004 13:10:39 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id i81DAcWI072986; Wed, 1 Sep 2004 09:10:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i81DAcvk009385; Wed, 1 Sep 2004 09:10:38 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4706D7303F; Wed, 1 Sep 2004 09:10:38 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040901131038.4706D7303F@freebsd-current.sentex.ca> Date: Wed, 1 Sep 2004 09:10:38 -0400 (EDT) Subject: [current tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 13:10:39 -0000 TB --- 2004-09-01 11:57:24 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-01 11:57:24 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2004-09-01 11:57:24 - checking out the source tree TB --- 2004-09-01 11:57:24 - cd /home/tinderbox/CURRENT/powerpc/powerpc TB --- 2004-09-01 11:57:24 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-01 12:02:17 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-01 12:02:17 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2004-09-01 12:02:17 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-09-01 13:07:00 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-01 13:07:00 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2004-09-01 13:07:00 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Wed Sep 1 13:07:00 UTC 2004 >>> 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 [...] ./machine/cpufunc.h:165: undefined reference to `all_cpus' subr_smp.o(.text+0x32):./machine/cpufunc.h:165: undefined reference to `all_cpus' uma_core.o(.text+0x1e8e): In function `zone_timeout': /tinderbox/CURRENT/powerpc/powerpc/src/sys/vm/uma_core.c:383: undefined reference to `all_cpus' uma_core.o(.text+0x1ebe):/tinderbox/CURRENT/powerpc/powerpc/src/sys/vm/uma_core.c:384: undefined reference to `all_cpus' uma_core.o(.text+0x32c2): In function `zone_dtor': /tinderbox/CURRENT/powerpc/powerpc/src/sys/vm/uma_core.c:609: undefined reference to `all_cpus' uma_core.o(.text+0x32e6):/tinderbox/CURRENT/powerpc/powerpc/src/sys/vm/uma_core.c:610: more undefined references to `all_cpus' follow *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/obj/powerpc/tinderbox/CURRENT/powerpc/powerpc/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2004-09-01 13:10:38 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-01 13:10:38 - ERROR: failed to build generic kernel TB --- 2004-09-01 13:10:38 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 13:14:36 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6632616A4CE for ; Wed, 1 Sep 2004 13:14:36 +0000 (GMT) Received: from avscan2.sentex.ca (avscan2.sentex.ca [199.212.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1BD243D1F for ; Wed, 1 Sep 2004 13:14:35 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan2.sentex.ca (8.12.11/8.12.11) with ESMTP id i81DEZf1065269; Wed, 1 Sep 2004 09:14:35 -0400 (EDT) (envelope-from mike@sentex.net) Received: from avscan2.sentex.ca ([127.0.0.1]) by localhost (avscan2.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 65053-03; Wed, 1 Sep 2004 09:14:35 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan2.sentex.ca (8.12.11/8.12.11) with ESMTP id i81DEZfq065247; Wed, 1 Sep 2004 09:14:35 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i81DESZI061056; Wed, 1 Sep 2004 09:14:28 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.1.2.0.0.20040901090639.08d11060@64.7.153.2> X-Sender: mdtpop@64.7.153.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 01 Sep 2004 09:20:01 -0400 To: Brian Reichert , freebsd-current@freebsd.org From: Mike Tancsa In-Reply-To: <20040901052054.GV4846@numachi.com> References: <20040901052054.GV4846@numachi.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan2b Subject: Re: how 'supported' are 3ware Escalade controllers? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 13:14:36 -0000 At 01:20 AM 01/09/2004, Brian Reichert wrote: >This page says there is support for other cards in this family, but >doesn't explicitly cite the 7506-8, and cites some firmwar issues: > > The above URL is out of date. The 3ware people have been very helpful as of late providing official driver support. I have also had to open a ticket with them in the past and they did indeed provide official FreeBSD support on the phone and web (it was for their management daemon) That being said, the critical part for me is performance and reliability. I have been using various 3ware cards for some time and I have had VERY good results with them and I highly recommend them on Intel platforms. (i.e I have zero experience with them on the AMD64). We use them on FreeBSD, LINUX and Windows. Most of our deployments are 2 drive RAID1s but I have a number of busy application servers running RAID10 (mail/pop3 and another SQL), RAID5 (offsite backup) and RAID0 (news spools). I have only had one card (out of ~ 50 in 4yrs) go bad and that was out of the box. If you are putting together a new system, I would look at the SATA series of their cards, the 8000. I dont have any experience yet with their newer generation 9000 cards and they use newer drivers so I dont know how well tested they are. However, the older 7506-8 we are currently using in our pop3 server has been working very well for us for the past year. It has 4 drives in RAID 10 and 2 drives in RAID1. The firmware we are using Monitor version: ME7X 1.01.00.038 Firmware version: FE7X 1.05.00.063 BIOS version: BE7X 1.08.00.048 PCB version: Rev4 Achip version: 3.20 Pchip version: 1.30-66 Model: 7506-8 Unit count: 2 Lately we have been using Seagate Drives. I would stay away from Maxtor as I have seen reports of problems with those drives. ---Mike From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 13:46:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AF3516A4CE for ; Wed, 1 Sep 2004 13:46:18 +0000 (GMT) Received: from pophost.wldelft.nl (sunray.wldelft.nl [145.9.132.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5C0D43D48 for ; Wed, 1 Sep 2004 13:46:17 +0000 (GMT) (envelope-from leroy.vanlogchem@wldelft.nl) Received: (from root@localhost) by pophost.wldelft.nl (8.9.3/8.9.3vc) id PAA03925 for freebsd-current@freebsd.org; Wed, 1 Sep 2004 15:46:16 +0200 (MET DST) Received: from [145.9.150.200] (beasty [145.9.150.200]) by pophost.wldelft.nl (8.9.3/8.9.3) with ESMTP id PAA03629; Wed, 1 Sep 2004 15:46:12 +0200 (MET DST) Message-ID: <4135D2A4.2070902@wldelft.nl> Date: Wed, 01 Sep 2004 15:46:12 +0200 From: Leroy van Logchem Organization: WL | Delft Hydraulics User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20040901052054.GV4846@numachi.com> <6.1.2.0.0.20040901090639.08d11060@64.7.153.2> In-Reply-To: <6.1.2.0.0.20040901090639.08d11060@64.7.153.2> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Mike Tancsa Subject: Re: how 'supported' are 3ware Escalade controllers? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 13:46:18 -0000 Mike Tancsa wrote: > At 01:20 AM 01/09/2004, Brian Reichert wrote: > >> This page says there is support for other cards in this family, but >> doesn't explicitly cite the 7506-8, and cites some firmwar issues: >> >> > I have a server running (AMD64) with two 7506-12's. Never had troubles with it only the CLI tool is not useable when a drive fails since it's written for the 9000 series. I hope 3Ware will support the cards a little older too. Besides that I can use the CLI to assign new hot spares when it used one etc. commands like info c0 and info c1 works. From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 14:28:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6B4016A4CF for ; Wed, 1 Sep 2004 14:28:04 +0000 (GMT) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BACF43D54 for ; Wed, 1 Sep 2004 14:28:04 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id i81ES3Uf047989; Wed, 1 Sep 2004 10:28:03 -0400 (EDT) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca ([127.0.0.1]) by localhost (avscan1.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 47906-01; Wed, 1 Sep 2004 10:28:03 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id i81ES2dU047978; Wed, 1 Sep 2004 10:28:03 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i81ERpd6061424; Wed, 1 Sep 2004 10:27:51 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.1.2.0.0.20040901102526.0733ad50@64.7.153.2> X-Sender: mdtpop@64.7.153.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Wed, 01 Sep 2004 10:32:07 -0400 To: Leroy van Logchem , freebsd-current@freebsd.org From: Mike Tancsa In-Reply-To: <4135D2A4.2070902@wldelft.nl> References: <20040901052054.GV4846@numachi.com> <6.1.2.0.0.20040901090639.08d11060@64.7.153.2> <4135D2A4.2070902@wldelft.nl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan1b Subject: Re: how 'supported' are 3ware Escalade controllers? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 14:28:04 -0000 At 09:46 AM 01/09/2004, Leroy van Logchem wrote: >Mike Tancsa wrote: > >>At 01:20 AM 01/09/2004, Brian Reichert wrote: >> >>>This page says there is support for other cards in this family, but >>>doesn't explicitly cite the 7506-8, and cites some firmwar issues: >>> >>> >I have a server running (AMD64) with two 7506-12's. Never had troubles >with it only the CLI tool is not useable when a drive fails since it's >written for the 9000 series. I hope 3Ware will support the cards a little >older too. The 3dm2 works with the 7xxx and 8xxx cards. The web page is a little misleading as you have to say you are downloading for a 9000 card, when in fact its is designed to work with the 7xxx and 8xxx series as well. If there is something broken on the CLI, you should let the 3ware folks know. ---Mike From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 14:36:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33F2C16A4CE for ; Wed, 1 Sep 2004 14:36:21 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78A4B43D2F for ; Wed, 1 Sep 2004 14:36:20 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 95502 invoked from network); 1 Sep 2004 14:34:05 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 1 Sep 2004 14:34:05 -0000 Message-ID: <4135DE61.2010009@freebsd.org> Date: Wed, 01 Sep 2004 16:36:17 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Toxa References: <20040901112004.GA2625@laptoxa.toxa.lan> In-Reply-To: <20040901112004.GA2625@laptoxa.toxa.lan> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: something like net.link.ether.bridge_pf? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 14:36:21 -0000 Toxa wrote: > I guess that pf now cannot be used on bridge, I can't see something > similar to net.link.ether.bridge_pf (only net.link.ether.bridge_ipfw and > net.link.ether.bridge_ipf), as the result, my fbsd machine can act as > bridge, but pf rules actually doesn't work, simply allowing all > connections. > Is it possible to use pf on bridge? I want to move my bridge back from obsd to fbsd. I have a generic PFIL_HOOKS mechnism in the works that will replace the current direct dispatch into the packet filters with a generic way to hooks into bridging and ether_input/output. Although it won't make it into 5.3R but it should be in 6.0-current soon. -- Andre From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 14:50:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8437916A4CE; Wed, 1 Sep 2004 14:50:11 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4190243D49; Wed, 1 Sep 2004 14:50:11 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i81EoVTr021704; Wed, 1 Sep 2004 07:50:31 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i81EoVgS021703; Wed, 1 Sep 2004 07:50:31 -0700 Date: Wed, 1 Sep 2004 07:50:31 -0700 From: Brooks Davis To: Gabor Esperon Message-ID: <20040901145031.GB20311@odin.ac.hmc.edu> References: <20040901064925.11682.qmail@web11506.mail.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="i0/AhcQY5QxfSsSZ" Content-Disposition: inline In-Reply-To: <20040901064925.11682.qmail@web11506.mail.yahoo.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-current@freebsd.org cc: freebsd-questions@freebsd.org Subject: Re: Problem with Intel 82540EM Gigabit Ethernet Controller X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 14:50:11 -0000 --i0/AhcQY5QxfSsSZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 31, 2004 at 11:49:25PM -0700, Gabor Esperon wrote: > Hi! >=20 > I have an Intel 82540EM Gigabit Ethernet Controller > working at 100Mb/s on FreeBSD 5-CURRENT and FreeBSD > 5-BETA3: >=20 > em0: > flags=3D8843 mtu > 1500 > =20 > options=3D1b > inet 192.168.1.32 netmask 0xffffff00 broadcast > 192.168.1.255 > ether 00:07:e9:09:a7:37 > media: Ethernet autoselect (100baseTX > ) > status: active >=20 > thats ok, but in both systems I can only get transfers > at 2.xMb/s (MBytes) as the following "netstat -w1 -I > em0" show: > input (em0) output > packets errs bytes packets errs =20 > bytes colls > 782 0 46920 1438 0 =20 > 2177132 0 > 788 0 53500 1452 0 =20 > 2209768 0 > 886 0 53160 1628 0 =20 > 2464792 0 > ... > > What could be the problem here? This looks like a potential duplex mismatch to me. Please make sure your hub/switch is running full-duplex. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --i0/AhcQY5QxfSsSZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBNeG2XY6L6fI4GtQRAp4+AKDn+6hvzi+fEIP+7rXQ4fvy0N702wCg24T8 yMCUtMzpDQ0sZq8M+MWJptk= =XGFb -----END PGP SIGNATURE----- --i0/AhcQY5QxfSsSZ-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 14:54:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A61116A4CE for ; Wed, 1 Sep 2004 14:54:35 +0000 (GMT) Received: from altus-escon.com (altesco.xs4all.nl [213.84.124.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B0C443D2F for ; Wed, 1 Sep 2004 14:54:34 +0000 (GMT) (envelope-from ben@stuyts.com) Received: from [193.78.231.14] (benjoam.altus-escon.com [193.78.231.14]) by altus-escon.com (8.12.11/8.12.11) with ESMTP id i81EsWPe013297 for ; Wed, 1 Sep 2004 16:54:32 +0200 (CEST) (envelope-from ben@stuyts.com) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: current@freebsd.org From: Ben Stuyts Date: Wed, 1 Sep 2004 16:54:31 +0200 X-Mailer: Apple Mail (2.619) X-Virus-Scanned: clamd / ClamAV version 0.75.1, clamav-milter version 0.75c on earth.altus-escon.com X-Virus-Status: Clean Subject: atacontrol rebuild, how? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 14:54:35 -0000 Hi, I have installed beta-2 (31082004) on a Supermicro 5013C-T (P4SCE motherboard with ICH5R, and two WD 74 GB Raptor SATA drives, which I want to mirror). I know the ICH5R is not a real raid controller, but I'm trying to get it to work using atacontrol and the built-in RAID1 support. Using the procedure described in http://www.techno-obscura.com/~delgado/notes/fbsd-ich5SATAraid.html (thanks!) I managed to get FreeBSD installed on RAID1 on ar0. Next I tried to remove a drive (atacontrol detach), and even zeroed the first area of the disk. After reattaching the drive, I cannot get atacontrol to rebuild the drive. If I do atacontrol rebuild ar0, it does absolutely nothing. From browsing this mailing list I see that this seems to be a problem with using non-raid controllers, but will this be improved in the future? Or am I doing something wrong? What other options do I have? Is geom-vinum ready for this? All I want is a fully mirrored system (incl root and swap). I could put a simple raid controller in, like the Promise S150 TX2Plus or TX4, but if I can get it to work with the ICH5R controller that would be great. Thanks, Ben From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 15:06:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C50416A4CE; Wed, 1 Sep 2004 15:06:52 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id D143343D39; Wed, 1 Sep 2004 15:06:50 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226])i81F6mVm003051; Wed, 1 Sep 2004 18:06:48 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) i81F6cXq007156; Wed, 1 Sep 2004 18:06:38 +0300 (EEST) (envelope-from keramida@linux.gr) Received: (from keramida@localhost)i81F6cow007155; Wed, 1 Sep 2004 18:06:38 +0300 (EEST) (envelope-from keramida@linux.gr) Date: Wed, 1 Sep 2004 18:06:38 +0300 From: Giorgos Keramidas To: FreeBSD Tinderbox Message-ID: <20040901150638.GA7118@orion.daedalusnetworks.priv> References: <20040901115723.3122E7303F@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040901115723.3122E7303F@freebsd-current.sentex.ca> cc: current@freebsd.org cc: ia64@freebsd.org Subject: Re: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 15:06:52 -0000 On 2004-09-01 07:57, FreeBSD Tinderbox wrote: > >>> stage 3.2: building everything > [...] > /tinderbox/CURRENT/ia64/ia64/src/sys/kern/subr_smp.c:498: undefined reference to `all_cpus' > uma_core.o(.text+0x3fa1): In function `zone_timeout': > /tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:382: undefined reference to `all_cpus' > uma_core.o(.text+0x6a21): In function `zone_dtor': > /tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:1423: undefined reference to `all_cpus' > uma_core.o(.text+0x8730): In function `uma_print_zone': > /tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:2657: undefined reference to `all_cpus' > uma_core.o(.text+0x8c31):/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:2710: more undefined references to `all_cpus' follow > *** Error code 1 > > Stop in /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC. > *** Error code 1 > > Stop in /tinderbox/CURRENT/ia64/ia64/src. > *** Error code 1 > > Stop in /tinderbox/CURRENT/ia64/ia64/src. > TB --- 2004-09-01 11:57:23 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2004-09-01 11:57:23 - ERROR: failed to build generic kernel > TB --- 2004-09-01 11:57:23 - tinderbox aborted Until Julian or another src-committer fixes the build error, this patch unbreaks the build for me on non-SMP i386/i386. Since the affected code is not specific to i386, it probably fixes the other architectures too: %%% Index: sys/smp.h =================================================================== RCS file: /home/ncvs/src/sys/sys/smp.h,v retrieving revision 1.80 diff -u -r1.80 smp.h --- sys/smp.h 1 Sep 2004 06:42:02 -0000 1.80 +++ sys/smp.h 1 Sep 2004 14:00:30 -0000 @@ -49,23 +49,26 @@ extern int smp_cpus; extern volatile cpumask_t started_cpus; extern volatile cpumask_t stopped_cpus; +extern cpumask_t all_cpus; +extern cpumask_t idle_cpus_mask; +extern cpumask_t hlt_cpus_mask; +extern cpumask_t logical_cpus_mask; #endif /* SMP */ extern u_int mp_maxid; extern int mp_ncpus; extern volatile int smp_started; -extern cpumask_t all_cpus; -extern cpumask_t idle_cpus_mask; -extern cpumask_t hlt_cpus_mask; -extern cpumask_t logical_cpus_mask; - /* * Macro allowing us to determine whether a CPU is absent at any given * time, thus permitting us to configure sparse maps of cpuid-dependent * (per-CPU) structures. */ +#ifdef SMP #define CPU_ABSENT(x_cpu) ((all_cpus & (1 << (x_cpu))) == 0) +#else +#define CPU_ABSENT(x_cpu) (0) +#endif #ifdef SMP /* Index: kern/subr_smp.c =================================================================== RCS file: /home/ncvs/src/sys/kern/subr_smp.c,v retrieving revision 1.191 diff -u -r1.191 subr_smp.c --- kern/subr_smp.c 1 Sep 2004 06:42:01 -0000 1.191 +++ kern/subr_smp.c 1 Sep 2004 11:12:38 -0000 @@ -495,7 +495,6 @@ { mp_ncpus = 1; mp_maxid = PCPU_GET(cpuid); - all_cpus = PCPU_GET(cpumask); KASSERT(PCPU_GET(cpuid) == 0, ("UP must have a CPU ID of zero")); } SYSINIT(cpu_mp_setvariables, SI_SUB_TUNABLES, SI_ORDER_FIRST, %%% From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 15:43:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E80DC16A4CE; Wed, 1 Sep 2004 15:43:38 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E089743D5C; Wed, 1 Sep 2004 15:43:37 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i81FhTCb091736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Sep 2004 18:43:30 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i81FhZCi015855; Wed, 1 Sep 2004 18:43:35 +0300 (EEST) (envelope-from ru) Date: Wed, 1 Sep 2004 18:43:35 +0300 From: Ruslan Ermilov To: Mikhail Teterin Message-ID: <20040901154335.GA15802@ip.net.ua> References: <413522EE.5080806@aldan.algebra.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="MGYHOYXEY6WxJCY8" Content-Disposition: inline In-Reply-To: <413522EE.5080806@aldan.algebra.com> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: current@FreeBSD.org cc: freebsd-amd64@FreeBSD.org Subject: Re: -current buildworld fails on amd64 (5.2.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 15:43:39 -0000 --MGYHOYXEY6WxJCY8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Aug 31, 2004 at 09:16:30PM -0400, Mikhail Teterin wrote: > Starting with an empty /usr/obj: >=20 > cc -DHAVE_CONFIG_H -DCOMPILE_ONLY -I/usr/src/lib/libmagic=20 > -I/usr/src/lib/libmagic/../../contrib/file -o mkmagic=20 > /usr/src/lib/libmagic/../../contrib/file/apprentice.c=20 > /usr/src/lib/libmagic/../../contrib/file/funcs.c=20 > /usr/src/lib/libmagic/../../contrib/file/magic.c=20 > /usr/src/lib/libmagic/../../contrib/file/print.c > /usr/obj/usr/src/amd64/usr/bin/ld: cannot find -lc > *** Error code 1 >=20 > [...] >=20 > Any clues? Thanks! >=20 Assuming that this happened in the "building libraries" stage of buildworld (please give more context next time!), I'd say it's likely that your computer's date/time is set incorrectly, or some source files have modification time pointing to the future. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --MGYHOYXEY6WxJCY8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBNe4nqRfpzJluFF4RAgu3AKCT9Ff0CBZcWTAcUo/66TXaF+/u9ACfWwt2 8xrV86c5yUwpXxthhVfKoyA= =OB0L -----END PGP SIGNATURE----- --MGYHOYXEY6WxJCY8-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 15:53:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 76B9D16A4CE for ; Wed, 1 Sep 2004 15:53:07 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4998E43D49 for ; Wed, 1 Sep 2004 15:53:07 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 1465 invoked from network); 1 Sep 2004 15:53:06 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 1 Sep 2004 15:53:06 -0000 Received: from hydrogen.funkthat.com (patmze@localhost.funkthat.com [127.0.0.1])i81Fr5uU080232; Wed, 1 Sep 2004 08:53:05 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i81Fr4D0080231; Wed, 1 Sep 2004 08:53:04 -0700 (PDT) Date: Wed, 1 Sep 2004 08:53:04 -0700 From: John-Mark Gurney To: Igor Sysoev Message-ID: <20040901155304.GD29902@funkthat.com> Mail-Followup-To: Igor Sysoev , freebsd-current@freebsd.org References: <20040901144705.K97970@is.park.rambler.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040901144705.K97970@is.park.rambler.ru> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-current@freebsd.org Subject: Re: panic caused by EVFILT_SIGNAL detaching in rfork()ed thread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 15:53:07 -0000 Igor Sysoev wrote this message on Wed, Sep 01, 2004 at 14:47 +0400: > 5.3-BETA2 still may panic as described in > http://freebsd.rambler.ru/bsdmail/freebsd-hackers_2004/msg02732.html Well, between then an now, I have committed kqueue locking, though I can't say they are similar since you completely dropped the panic message from your email... > #11 0xc077631a in calltrap () at /usr/src/sys/i386/i386/exception.s:140 > #12 0xc0620018 in removechild (parent=0x0, child=0x5de) > at /usr/src/sys/kern/subr_witness.c:1443 > #13 0xc05e86ab in knlist_remove_kq (knl=0xc39724f4, kn=0x0, > knlislocked=-1065428340, kqislocked=0) > at /usr/src/sys/kern/kern_event.c:1502 > #14 0xc05e87b3 in knlist_remove (knl=0xc39724f4, kn=0xc3e1d154, islocked=0) > at /usr/src/sys/kern/kern_event.c:1527 > #15 0xc060451b in filt_sigdetach (kn=0x0) at /usr/src/sys/kern/kern_sig.c:2733 I love how bt's can not find the value of some arguments.. :( > #16 0xc05e826a in kqueue_close (fp=0xc394ebb0, td=0xc3a22420) > at /usr/src/sys/kern/kern_event.c:1372 > #17 0xc05e5524 in fdrop_locked (fp=0xc394ebb0, td=0xc3a22420) at file.h:289 > #18 0xc05e47b8 in fdrop (fp=0xc394ebb0, td=0xc3a22420) > at /usr/src/sys/kern/kern_descrip.c:1897 > #19 0xc05e478b in closef (fp=0xc394ebb0, td=0xc3a22420) > at /usr/src/sys/kern/kern_descrip.c:1883 > #20 0xc05e40e7 in fdfree (td=0xc3a22420) > at /usr/src/sys/kern/kern_descrip.c:1610 > #21 0xc05ea896 in exit1 (td=0xc3a22420, rv=0) > at /usr/src/sys/kern/kern_exit.c:242 > #22 0xc05ea494 in sys_exit (td=0xc3a22420, uap=0x0) > at /usr/src/sys/kern/kern_exit.c:94 > #23 0xc07881cf in syscall (frame= > {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 2, tf_esi = 134873108, tf_ebp = -1077941784, tf_isp = -355476108, tf_ebx = 672658924, tf_edx = 10, tf_ecx = 672658608, tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 672162923, tf_cs = 31, tf_eflags = 662, tf_esp = -1077941812, tf_ss = 47}) > at /usr/src/sys/i386/i386/trap.c:1004 > #24 0xc077636f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:201 > > [ ... ] > > (kgdb) fr 15 > #15 0xc060451b in filt_sigdetach (kn=0x0) at /usr/src/sys/kern/kern_sig.c:2733 > 2733 knlist_remove(&p->p_klist, kn, 0); > (kgdb) down > #14 0xc05e87b3 in knlist_remove (knl=0xc39724f4, kn=0xc3e1d154, islocked=0) > at /usr/src/sys/kern/kern_event.c:1527 > 1527 knlist_remove_kq(knl, kn, islocked, 0); > (kgdb) p *knl > $1 = {kl_lock = 0x0, kl_list = {slh_first = 0x0}} > > > However, I do not know is it safe to test !SLIST_EMPTY(&p->p_klist) in It is possible to call SLIST_EMPTY, but you need to make you have proper locks held between the time you call SLIST_EMPTY, and knlist_remove... But I don't think that's the problem, the problem is else where... > filt_sigdetach() because in 5.3-BETA2 kqueue uses own mutex. Unfortunately, > I could not just now to write a small test case to allow everyone to > reproduce the panic but my user-level server always causes panic on exit on > unpatched 5.x and sometimes on unpatched 4.10. Could you print *kn? also in frame 16: print kq print *kq The problem is some how that the knote is being removed from the list (or was never on the list), but not being marked detached... Hmmm. what are the options you are using for rfork? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 16:14:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C32DA16A4CE for ; Wed, 1 Sep 2004 16:14:30 +0000 (GMT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4065043D1D for ; Wed, 1 Sep 2004 16:14:29 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id i81GEQis075239; Wed, 1 Sep 2004 20:14:26 +0400 (MSD) (envelope-from is@rambler-co.ru) Date: Wed, 1 Sep 2004 20:17:20 +0400 (MSD) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: John-Mark Gurney In-Reply-To: <20040901155304.GD29902@funkthat.com> Message-ID: <20040901200709.H97970@is.park.rambler.ru> References: <20040901144705.K97970@is.park.rambler.ru> <20040901155304.GD29902@funkthat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: panic caused by EVFILT_SIGNAL detaching in rfork()ed thread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 16:14:30 -0000 On Wed, 1 Sep 2004, John-Mark Gurney wrote: > Igor Sysoev wrote this message on Wed, Sep 01, 2004 at 14:47 +0400: > > 5.3-BETA2 still may panic as described in > > http://freebsd.rambler.ru/bsdmail/freebsd-hackers_2004/msg02732.html > > Well, between then an now, I have committed kqueue locking, though > I can't say they are similar since you completely dropped the panic > message from your email... It's the same panic caused by the empty p->p_klist. As to the panic message I do not know where to get it in the kgdb. > > #11 0xc077631a in calltrap () at /usr/src/sys/i386/i386/exception.s:140 > > #12 0xc0620018 in removechild (parent=0x0, child=0x5de) > > at /usr/src/sys/kern/subr_witness.c:1443 > > #13 0xc05e86ab in knlist_remove_kq (knl=0xc39724f4, kn=0x0, > > knlislocked=-1065428340, kqislocked=0) > > at /usr/src/sys/kern/kern_event.c:1502 > > #14 0xc05e87b3 in knlist_remove (knl=0xc39724f4, kn=0xc3e1d154, islocked=0) > > at /usr/src/sys/kern/kern_event.c:1527 > > #15 0xc060451b in filt_sigdetach (kn=0x0) at /usr/src/sys/kern/kern_sig.c:2733 > > I love how bt's can not find the value of some arguments.. :( > > > #16 0xc05e826a in kqueue_close (fp=0xc394ebb0, td=0xc3a22420) > > at /usr/src/sys/kern/kern_event.c:1372 > > #17 0xc05e5524 in fdrop_locked (fp=0xc394ebb0, td=0xc3a22420) at file.h:289 > > #18 0xc05e47b8 in fdrop (fp=0xc394ebb0, td=0xc3a22420) > > at /usr/src/sys/kern/kern_descrip.c:1897 > > #19 0xc05e478b in closef (fp=0xc394ebb0, td=0xc3a22420) > > at /usr/src/sys/kern/kern_descrip.c:1883 > > #20 0xc05e40e7 in fdfree (td=0xc3a22420) > > at /usr/src/sys/kern/kern_descrip.c:1610 > > #21 0xc05ea896 in exit1 (td=0xc3a22420, rv=0) > > at /usr/src/sys/kern/kern_exit.c:242 > > #22 0xc05ea494 in sys_exit (td=0xc3a22420, uap=0x0) > > at /usr/src/sys/kern/kern_exit.c:94 > > #23 0xc07881cf in syscall (frame= > > {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 2, tf_esi = 134873108, tf_ebp = -1077941784, tf_isp = -355476108, tf_ebx = 672658924, tf_edx = 10, tf_ecx = 672658608, tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 672162923, tf_cs = 31, tf_eflags = 662, tf_esp = -1077941812, tf_ss = 47}) > > at /usr/src/sys/i386/i386/trap.c:1004 > > #24 0xc077636f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:201 > > > > [ ... ] > > > > (kgdb) fr 15 > > #15 0xc060451b in filt_sigdetach (kn=0x0) at /usr/src/sys/kern/kern_sig.c:2733 > > 2733 knlist_remove(&p->p_klist, kn, 0); > > (kgdb) down > > #14 0xc05e87b3 in knlist_remove (knl=0xc39724f4, kn=0xc3e1d154, islocked=0) > > at /usr/src/sys/kern/kern_event.c:1527 > > 1527 knlist_remove_kq(knl, kn, islocked, 0); > > (kgdb) p *knl > > $1 = {kl_lock = 0x0, kl_list = {slh_first = 0x0}} > > > > > > However, I do not know is it safe to test !SLIST_EMPTY(&p->p_klist) in > > It is possible to call SLIST_EMPTY, but you need to make you have proper > locks held between the time you call SLIST_EMPTY, and knlist_remove... > But I don't think that's the problem, the problem is else where... The problem is to test the empty p->p_klist before the calling knlist_remove(). > > filt_sigdetach() because in 5.3-BETA2 kqueue uses own mutex. Unfortunately, > > I could not just now to write a small test case to allow everyone to > > reproduce the panic but my user-level server always causes panic on exit on > > unpatched 5.x and sometimes on unpatched 4.10. > > Could you print *kn? (kgdb) fr 14 #14 0xc05e87b3 in knlist_remove (knl=0xc39724f4, kn=0xc3e1d154, islocked=0) at /usr/src/sys/kern/kern_event.c:1527 1527 knlist_remove_kq(knl, kn, islocked, 0); (kgdb) p *kn $1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0x0}, kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev = 0xc3c780ac}, kn_kq = 0xc3c78080, kn_kevent = {ident = 64, filter = -6, flags = 32817, fflags = 0, data = 1, udata = 0x0}, kn_status = 27, kn_sfflags = 0, kn_sdata = 0, kn_ptr = {p_fp = 0xc3972380, p_proc = 0xc3972380}, kn_fop = 0xc084d320, kn_hook = 0x0} > also in frame 16: > print kq (kgdb) fr 16 #16 0xc05e826a in kqueue_close (fp=0xc394ebb0, td=0xc3a22420) at /usr/src/sys/kern/kern_event.c:1372 1372 kn->kn_fop->f_detach(kn); (kgdb) p kq $2 = (struct kqueue *) 0xc3c78080 > print *kq (kgdb) p *kq $3 = {kq_lock = {mtx_object = {lo_class = 0xc084c4dc, lo_name = 0xc07eda71 "kqueue", lo_type = 0xc07eda71 "kqueue", lo_flags = 4390912, lo_list = {tqe_next = 0xc3c78000, tqe_prev = 0xc3b46c38}, lo_witness = 0xc08bd1c0}, mtx_lock = 4, mtx_recurse = 0}, kq_refcnt = 1, kq_list = {sle_next = 0x0}, kq_head = { tqh_first = 0xc3e1d154, tqh_last = 0xc3e1d160}, kq_count = 1, kq_sel = { si_thrlist = {tqe_next = 0x0, tqe_prev = 0x0}, si_thread = 0x0, si_note = { kl_lock = 0xc3c78080, kl_list = {slh_first = 0x0}}, si_flags = 0}, kq_sigio = 0x0, kq_fdp = 0xc3b46c00, kq_state = 16, kq_knlistsize = 0, kq_knlist = 0x0, kq_knhashmask = 63, kq_knhash = 0xc3c6ac00, kq_task = { ta_link = {stqe_next = 0x0}, ta_pending = 0, ta_priority = 0, ta_func = 0xc05e7908 , ta_context = 0xc3c78080}} > The problem is some how that the knote is being removed from the list > (or was never on the list), but not being marked detached... > > Hmmm. what are the options you are using for rfork? The worker process starts two worker threads created by rfork(RFPROC|RFTHREAD|RFMEM). Each thread opens kqueue and adds the EVFILT_SIGNAL event. If you like I can send to you the source tarball (I do not distribute the server right now, because it has not the documentation). The build process is simple. Then you need to press ^C and you will get the panic. Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 16:24:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A63416A4CE for ; Wed, 1 Sep 2004 16:24:53 +0000 (GMT) Received: from hellhound.ceribus.net (c-24-21-90-79.client.comcast.net [24.21.90.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9915F43D45 for ; Wed, 1 Sep 2004 16:24:52 +0000 (GMT) (envelope-from grover@ceribus.net) Received: (qmail 52103 invoked by uid 1002); 1 Sep 2004 16:25:29 -0000 Received: from grover@ceribus.net by hellhound.ceribus.net by uid 89 with qmail-scanner-1.22 (clamscan: 0.73. spamassassin: 2.63. Clear:RC:1(192.168.200.200):. Processed in 0.944921 secs); 01 Sep 2004 16:25:29 -0000 Received: from unknown (HELO ?192.168.200.219?) (grover@ceribus.net@192.168.200.200) by 192.168.200.225 with SMTP; 1 Sep 2004 16:25:28 -0000 Message-ID: <4135F7D1.7090104@ceribus.net> Date: Wed, 01 Sep 2004 09:24:49 -0700 From: Grover Lines User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040714 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Nvidia driver make fails 6-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 16:24:53 -0000 I'm getting this error when making the Nvidia driver in 6-CURRENT from yesterda(fp= awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h awk -f @/tools/vnode_if.awk @/kern/vnode_if.src -h cc -O2 -pipe -march=pentium4 -I/src -DNV_MAJOR_VERSION=1 -DNV_MINOR_VERSION=0 -DNV_PATCHLEVEL=6113 -DNVCPU_X86 -DNV_BSD -DNV_INT64_OK -DNV_UNIX -D__KERNEL__ -UDEBUG -U_DEBUG -DNDEBUG -O -fno-common -D_KERNEL -DKLD_MODULE -nostdinc -I- -I/src -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include -finline-limit=8000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c nvidia_ctl.c In file included from @/sys/param.h:109, from ./nv-freebsd.h:22, from nvidia_ctl.c:14: ./machine/param.h:102:23: opt_sched.h: No such file or directory *** Error code 1 Stop in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-6113/src. *** Error code 1 Stop in /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86-1.0-6113. *** Error code 1 Stop in /usr/ports/x11/nvidia-driver. -- Grover Lines From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 16:41:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA84D16A4CE for ; Wed, 1 Sep 2004 16:41:00 +0000 (GMT) Received: from web41414.mail.yahoo.com (web41414.mail.yahoo.com [66.218.93.80]) by mx1.FreeBSD.org (Postfix) with SMTP id 8BDFB43D3F for ; Wed, 1 Sep 2004 16:41:00 +0000 (GMT) (envelope-from davemac11@yahoo.com) Message-ID: <20040901164100.47063.qmail@web41414.mail.yahoo.com> Received: from [168.91.4.66] by web41414.mail.yahoo.com via HTTP; Wed, 01 Sep 2004 09:41:00 PDT Date: Wed, 1 Sep 2004 09:41:00 -0700 (PDT) From: Dave McCammon To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: 5.3 Beta2 bridging (update 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 16:41:01 -0000 Got the bridging to work after cvsup yesterday(I think it was the rebuild but not for sure). em0 - has ip em1 - no ip Anyway, with both cables plugged in, traffic passes through the box. Weird thing is, the box can't get to (ssh, ping) other machines on the em1 side but can get to machines on the em0 side. Machines on the em1 side can get to machines on the em0 side. Machines on the em0 side can get to machines on the em1 side and can get to the bridging box. Ok, I just went and plugged the cables back in(removed them last night) and traffic didn't get through. I'm now wondering if it isn't something to do with the em driver. This is completely confusing. I built a different kernel to test bridging without ipfw. Bridging kernels with and without ipfw worked last night. Now nothing. Ok, after some more fiddling around, what needs to happen is that em1 can't be plugged in until the machine has come up(with em0 plugged in). After that, traffic passes as stated above. Which doesn't bode well if machine gets rebooted. __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 17:06:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D16716A4CE for ; Wed, 1 Sep 2004 17:06:06 +0000 (GMT) Received: from mallaury.noc.nerim.net (smtp-103-wednesday.noc.nerim.net [62.4.17.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B45443D1F for ; Wed, 1 Sep 2004 17:06:06 +0000 (GMT) (envelope-from bettan@nerim.net) Received: from frederic (linux-win.com [62.212.121.38]) by mallaury.noc.nerim.net (Postfix) with SMTP id 54F2062D44 for ; Wed, 1 Sep 2004 19:06:03 +0200 (CEST) Message-ID: <005d01c49045$f5f31bf0$0401a8c0@frederic> From: "cell" To: Date: Wed, 1 Sep 2004 19:06:01 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: netgear wg311 v2 configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 17:06:06 -0000 hello i have installed driver nisd for this card and it works but when i = do "ifconfig ndis0 192.168.1.9 netmask 255.255.255.0 up " i have = "ifconfig: ioctl (SIOCAIFADDR): File exists" and i don't understand why. From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 17:16:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C49CA16A4CE; Wed, 1 Sep 2004 17:16:11 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC80443D1F; Wed, 1 Sep 2004 17:16:11 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 9477D72DD4; Wed, 1 Sep 2004 10:16:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 8FA6272DCB; Wed, 1 Sep 2004 10:16:11 -0700 (PDT) Date: Wed, 1 Sep 2004 10:16:11 -0700 (PDT) From: Doug White To: Lukas Ertl In-Reply-To: <20040901013402.K557@korben.in.tern> Message-ID: <20040901101520.P6696@carver.gumbysoft.com> References: <20040831211944.GA65532@nowhere> <20040901013402.K557@korben.in.tern> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Craig Boston cc: freebsd-current@FreeBSD.org cc: Daniel Eriksson Subject: Vinum corruption and performance issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 17:16:11 -0000 I'm changing the subject of this thread since its no longer related to the IPI issue. Please update your reply chain :) On Wed, 1 Sep 2004, Lukas Ertl wrote: > On Tue, 31 Aug 2004, Craig Boston wrote: > > > So it seems that gvinum RAID-5 is a key factor in the corruption, and > > SMP greatly increases the odds of it happening... > > > > Is it worth creating a PR so this doesn't get lost amid the release > > madness? > > PR isn't necessary, it's my number one task right now (which isn't easy, > since the corruption isn't really repeatable at will). Gimme a little more > time. > > thanks, > le > > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 17:17:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8378316A4CE for ; Wed, 1 Sep 2004 17:17:30 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79E1843D48 for ; Wed, 1 Sep 2004 17:17:30 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 716CF72DD4; Wed, 1 Sep 2004 10:17:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 6F46172DCB; Wed, 1 Sep 2004 10:17:30 -0700 (PDT) Date: Wed, 1 Sep 2004 10:17:30 -0700 (PDT) From: Doug White To: Damian Gerow In-Reply-To: <20040831023401.GB22579@afflictions.org> Message-ID: <20040901101655.W6696@carver.gumbysoft.com> References: <20040824073356.GK25125@afflictions.org> <20040829155924.J69068@carver.gumbysoft.com> <20040831023401.GB22579@afflictions.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: RELENG_5 build broken with BKTR_USE_FREEBSD_SMBUS and BKTR_NEW_MSP34XX_DRIVER enabled X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 17:17:30 -0000 On Mon, 30 Aug 2004, Damian Gerow wrote: > Thus spake Doug White (dwhite@gumbysoft.com) [29/08/04 19:09]: > : Please try the patch at: > : > : http://people.freebsd.org/~dwhite/msp34xx.c.patch > > The patch not only lets me compile, but I'm now running with > BKTR_USE_FREEBSD_SMBUS and BKTR_NEW_MSP34XX_DRIVER, successfully. Good to hear. I'll toss this up on multimedia@ for a review. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 17:24:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9179016A4CE for ; Wed, 1 Sep 2004 17:24:07 +0000 (GMT) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1295543D2D for ; Wed, 1 Sep 2004 17:24:05 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.12.11/8.12.11/NinthNine) with SMTP id i81HO3BE065038 for ; Thu, 2 Sep 2004 02:24:03 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Thu, 2 Sep 2004 02:24:03 +0900 (JST) Message-Id: <200409011724.i81HO3BE065038@sakura.ninth-nine.com> From: Norikatsu Shigemura To: freebsd-current@FreeBSD.org In-Reply-To: <200408301254.i7UCsald027733@sakura.ninth-nine.com> References: <200408301245.i7UCjZrE027532@sakura.ninth-nine.com> <200408301254.i7UCsald027733@sakura.ninth-nine.com> X-Mailer: Sylpheed version 0.9.12-gtk2-20040622 (GTK+ 2.4.9; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.5.6 (sakura.ninth-nine.com [219.127.74.121]); Thu, 02 Sep 2004 02:24:04 +0900 (JST) Subject: Re: ping6 -f panic with mpsafenet=1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 17:24:07 -0000 On Mon, 30 Aug 2004 21:54:36 +0900 (JST) Norikatsu Shigemura wrote: > > And I noticed about xmms behavior. xmms is BGM player and is > > not forcused (out of screen by WindowMaker), then xmms cannot > > play *next* music. But I give forcus to xmms, as soon as xmms > > is re-playing BGM. > > | libpthread | libthr | libc_r > > ---------------+------------+--------+-------- > > w/o PREEMPTION | NG | NG | OK > > w/ PREEMPTION | NG | NG | OK > > I think that KSE has a problem. > I confirmed same result with w/ SCHED_ULE and w/ SCHED_4BSD. Humm.. This problem was fixed on more new kernel. This is closed:-). Thank you. From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 17:24:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FD9316A4CE for ; Wed, 1 Sep 2004 17:24:37 +0000 (GMT) Received: from hotmail.com (bay11-dav42.bay11.hotmail.com [64.4.39.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28CDE43D2F for ; Wed, 1 Sep 2004 17:24:37 +0000 (GMT) (envelope-from dsnofe@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 1 Sep 2004 10:24:37 -0700 Received: from 222.64.53.190 by bay11-dav42.bay11.hotmail.com with DAV; Wed, 01 Sep 2004 17:24:36 +0000 X-Originating-IP: [222.64.53.190] X-Originating-Email: [dsnofe@msn.com] X-Sender: dsnofe@msn.com Date: Thu, 02 Sep 2004 01:24:34 +0800 From: Deng XueFeng To: "Cyrille Lefevre" In-Reply-To: <002f01c49020$5e9df560$7890a8c0@gits.invalid> References: <002f01c49020$5e9df560$7890a8c0@gits.invalid> Message-Id: <20040902012216.E864.DSNOFE@msn.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------_41360548E86503B477C0_MULTIPART_MIXED_" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.11.02 [CN] X-OriginalArrivalTime: 01 Sep 2004 17:24:37.0085 (UTC) FILETIME=[8E3130D0:01C49048] cc: Sascha Wildner cc: current@freebsd.org Subject: Re: [BETA PATCH] VESA mode support for syscons X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 17:24:37 -0000 --------_41360548E86503B477C0_MULTIPART_MIXED_ Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit This is the new patch. but i haven't test du to the limit of opt_sche.h you can try this patch after current is not broken. I wanna go to sleep. so sleepy. Zzzzzzzz... Sincerely, Deng XueFeng MSN: dsnofe@msn.com http://www.dengh.com --------_41360548E86503B477C0_MULTIPART_MIXED_ Content-Type: application/octet-stream; name="freebsd-syscons-patch-0902.diff" Content-Disposition: attachment; filename="freebsd-syscons-patch-0902.diff" Content-Transfer-Encoding: base64 PyBmcmVlYnNkLXN5c2NvbnMtcGF0Y2gtMDkwMi5kaWZmCj8gbmV3LmRpZmYKPyBzeXNjb25zLmRp ZmYKSW5kZXg6IHNjdmVzYWN0bC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3Jj L3N5cy9kZXYvc3lzY29ucy9zY3Zlc2FjdGwuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4yMApk aWZmIC11IC1yMS4yMCBzY3Zlc2FjdGwuYwotLS0gc2N2ZXNhY3RsLmMJMTYgSnVuIDIwMDQgMDk6 NDY6NTggLTAwMDAJMS4yMAorKysgc2N2ZXNhY3RsLmMJMSBTZXAgMjAwNCAxNzowNDoxNSAtMDAw MApAQCAtMiw2ICsyLDkgQEAKICAqIENvcHlyaWdodCAoYykgMTk5OCBLYXp1dGFrYSBZT0tPVEEg PHlva290YUB6b2RpYWMubWVjaC51dHN1bm9taXlhLXUuYWMuanA+CiAgKiBBbGwgcmlnaHRzIHJl c2VydmVkLgogICoKKyAqIFRoaXMgY29kZSBpcyBkZXJpdmVkIGZyb20gc29mdHdhcmUgY29udHJp YnV0ZWQgdG8gVGhlIERyYWdvbkZseSBQcm9qZWN0CisgKiBieSBTYXNjaGEgV2lsZG5lciA8c2F3 QG9ubGluZS5kZT4KKyAqCiAgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQg YmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKICAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1p dHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucwogICogYXJlIG1ldDoK QEAgLTEwNSw2ICsxMDgsMTcgQEAKIAkJCXJldHVybiBFTk9ERVY7CiAJCW1vZGUgPSAoY21kICYg MHhmZikgKyBNX1ZFU0FfQkFTRTsKIAkJcmV0dXJuIHNjX3NldF9ncmFwaGljc19tb2RlKHNjcCwg dHAsIG1vZGUpOworCWRlZmF1bHQ6CisJCWlmIChJT0NHUk9VUChjbWQpID09ICdWJykgeworCQkJ aWYgKCEoc2NwLT5zYy0+YWRwLT52YV9mbGFncyAmIFZfQURQX01PREVDSEFOR0UpKQorCQkJCXJl dHVybiBFTk9ERVY7CisKKwkJCW1vZGUgPSAoY21kICYgMHhmZikgKyBNX1ZFU0FfQkFTRTsKKwor CQkJaWYgKChtb2RlID4gTV9WRVNBX0ZVTExfMTI4MCkgJiYKKwkJCSAgICAobW9kZSA8IE1fVkVT QV9NT0RFX01BWCkpCisJCQkJcmV0dXJuIHNjX3NldF9ncmFwaGljc19tb2RlKHNjcCwgdHAsIG1v ZGUpOworCQl9CiAJfQogCiAJaWYgKHByZXZfdXNlcl9pb2N0bCkKSW5kZXg6IHNjdmdhcm5kci5j Cj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9kZXYvc3lzY29ucy9zY3Zn YXJuZHIuYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4xNQpkaWZmIC11IC1yMS4xNSBzY3ZnYXJu ZHIuYwotLS0gc2N2Z2FybmRyLmMJMzAgTWF5IDIwMDQgMjA6MDg6NDIgLTAwMDAJMS4xNQorKysg c2N2Z2FybmRyLmMJMSBTZXAgMjAwNCAxNzowNDoxNiAtMDAwMApAQCAtMiw2ICsyLDkgQEAKICAq IENvcHlyaWdodCAoYykgMTk5OSBLYXp1dGFrYSBZT0tPVEEgPHlva290YUB6b2RpYWMubWVjaC51 dHN1bm9taXlhLXUuYWMuanA+CiAgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgogICoKKyAqIFRoaXMg Y29kZSBpcyBkZXJpdmVkIGZyb20gc29mdHdhcmUgY29udHJpYnV0ZWQgdG8gVGhlIERyYWdvbkZs eSBQcm9qZWN0CisgKiBieSBTYXNjaGEgV2lsZG5lciA8c2F3QG9ubGluZS5kZT4KKyAqCiAgKiBS ZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9y IHdpdGhvdXQKICAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRo ZSBmb2xsb3dpbmcgY29uZGl0aW9ucwogICogYXJlIG1ldDoKQEAgLTYzLDE1ICs2NiwyMiBAQAog I2VuZGlmCiAKICNpZmRlZiBTQ19QSVhFTF9NT0RFCi1zdGF0aWMgdnJfY2xlYXJfdAkJdmdhX3B4 bGNsZWFyOwotc3RhdGljIHZyX2RyYXdfYm9yZGVyX3QJCXZnYV9weGxib3JkZXI7CitzdGF0aWMg dnJfaW5pdF90CQl2Z2Ffcm5kcmluaXQ7CitzdGF0aWMgdnJfY2xlYXJfdAkJdmdhX3B4bGNsZWFy X2RpcmVjdDsKK3N0YXRpYyB2cl9jbGVhcl90CQl2Z2FfcHhsY2xlYXJfcGxhbmFyOworc3RhdGlj IHZyX2RyYXdfYm9yZGVyX3QJCXZnYV9weGxib3JkZXJfZGlyZWN0Oworc3RhdGljIHZyX2RyYXdf Ym9yZGVyX3QJCXZnYV9weGxib3JkZXJfcGxhbmFyOwogc3RhdGljIHZyX2RyYXdfdAkJdmdhX2Vn YWRyYXc7Ci1zdGF0aWMgdnJfZHJhd190CQl2Z2FfdmdhZHJhdzsKK3N0YXRpYyB2cl9kcmF3X3QJ CXZnYV92Z2FkcmF3X2RpcmVjdDsKK3N0YXRpYyB2cl9kcmF3X3QJCXZnYV92Z2FkcmF3X3BsYW5h cjsKIHN0YXRpYyB2cl9zZXRfY3Vyc29yX3QJCXZnYV9weGxjdXJzb3Jfc2hhcGU7Ci1zdGF0aWMg dnJfZHJhd19jdXJzb3JfdAkJdmdhX3B4bGN1cnNvcjsKLXN0YXRpYyB2cl9ibGlua19jdXJzb3Jf dAl2Z2FfcHhsYmxpbms7CitzdGF0aWMgdnJfZHJhd19jdXJzb3JfdAkJdmdhX3B4bGN1cnNvcl9k aXJlY3Q7CitzdGF0aWMgdnJfZHJhd19jdXJzb3JfdAkJdmdhX3B4bGN1cnNvcl9wbGFuYXI7Citz dGF0aWMgdnJfYmxpbmtfY3Vyc29yX3QJdmdhX3B4bGJsaW5rX2RpcmVjdDsKK3N0YXRpYyB2cl9i bGlua19jdXJzb3JfdAl2Z2FfcHhsYmxpbmtfcGxhbmFyOwogI2lmbmRlZiBTQ19OT19DVVRQQVNU RQotc3RhdGljIHZyX2RyYXdfbW91c2VfdAkJdmdhX3B4bG1vdXNlOworc3RhdGljIHZyX2RyYXdf bW91c2VfdAkJdmdhX3B4bG1vdXNlX2RpcmVjdDsKK3N0YXRpYyB2cl9kcmF3X21vdXNlX3QJCXZn YV9weGxtb3VzZV9wbGFuYXI7CiAjZWxzZQogI2RlZmluZSB2Z2FfcHhsbW91c2UJCSh2cl9kcmF3 X21vdXNlX3QgKil2Z2Ffbm9wCiAjZW5kaWYKQEAgLTg0LDYgKzk0LDcgQEAKIHN0YXRpYyB2b2lk CQkJdmdhX25vcChzY3Jfc3RhdCAqc2NwLCAuLi4pOwogCiBzdGF0aWMgc2Nfcm5kcl9zd190IHR4 dHJuZHJzdyA9IHsKKwkodnJfaW5pdF90ICopdmdhX25vcCwKIAl2Z2FfdHh0Y2xlYXIsCiAJdmdh X3R4dGJvcmRlciwKIAl2Z2FfdHh0ZHJhdywJCkBAIC0xMDAsMzIgKzExMSwzNSBAQAogCiAjaWZk ZWYgU0NfUElYRUxfTU9ERQogc3RhdGljIHNjX3JuZHJfc3dfdCBlZ2FybmRyc3cgPSB7Ci0Jdmdh X3B4bGNsZWFyLAotCXZnYV9weGxib3JkZXIsCisJKHZyX2luaXRfdCAqKXZnYV9ub3AsCisJdmdh X3B4bGNsZWFyX3BsYW5hciwKKwl2Z2FfcHhsYm9yZGVyX3BsYW5hciwKIAl2Z2FfZWdhZHJhdywK IAl2Z2FfcHhsY3Vyc29yX3NoYXBlLAotCXZnYV9weGxjdXJzb3IsCi0JdmdhX3B4bGJsaW5rLAor CXZnYV9weGxjdXJzb3JfcGxhbmFyLAorCXZnYV9weGxibGlua19wbGFuYXIsCiAJKHZyX3NldF9t b3VzZV90ICopdmdhX25vcCwKLQl2Z2FfcHhsbW91c2UsCisJdmdhX3B4bG1vdXNlX3BsYW5hciwK IH07CiBSRU5ERVJFUihlZ2EsIFBJWEVMX01PREUsIGVnYXJuZHJzdywgdmdhX3NldCk7CiAKIHN0 YXRpYyBzY19ybmRyX3N3X3Qgdmdhcm5kcnN3ID0gewotCXZnYV9weGxjbGVhciwKLQl2Z2FfcHhs Ym9yZGVyLAotCXZnYV92Z2FkcmF3LAorCXZnYV9ybmRyaW5pdCwKKwkodnJfY2xlYXJfdCAqKXZn YV9ub3AsCisJKHZyX2RyYXdfYm9yZGVyX3QgKil2Z2Ffbm9wLAorCSh2cl9kcmF3X3QgKil2Z2Ff bm9wLAogCXZnYV9weGxjdXJzb3Jfc2hhcGUsCi0JdmdhX3B4bGN1cnNvciwKLQl2Z2FfcHhsYmxp bmssCisJKHZyX2RyYXdfY3Vyc29yX3QgKil2Z2Ffbm9wLAorCSh2cl9ibGlua19jdXJzb3JfdCAq KXZnYV9ub3AsCiAJKHZyX3NldF9tb3VzZV90ICopdmdhX25vcCwKLQl2Z2FfcHhsbW91c2UsCisJ KHZyX2RyYXdfbW91c2VfdCAqKXZnYV9ub3AsCiB9OwogUkVOREVSRVIodmdhLCBQSVhFTF9NT0RF LCB2Z2FybmRyc3csIHZnYV9zZXQpOwogI2VuZGlmIC8qIFNDX1BJWEVMX01PREUgKi8KIAogI2lm bmRlZiBTQ19OT19NT0RFX0NIQU5HRQogc3RhdGljIHNjX3JuZHJfc3dfdCBncnJuZHJzdyA9IHsK KwkodnJfaW5pdF90ICopdmdhX25vcCwKIAkodnJfY2xlYXJfdCAqKXZnYV9ub3AsCiAJdmdhX2dy Ym9yZGVyLAogCSh2cl9kcmF3X3QgKil2Z2Ffbm9wLApAQCAtMTU1LDYgKzE2OSw1NCBAQAogI2Vu ZGlmCiAjZW5kaWYKIAorI2lmZGVmIFNDX1BJWEVMX01PREUKKyNkZWZpbmUJVklERU9fTUVNT1JZ X1BPUyhzY3AsIHBvcywgeCkgCQkJCQlcCisJc2NwLT5zYy0+YWRwLT52YV93aW5kb3cgKwkJCQkJ XAorCXggKiBzY3AtPnhvZmYgKwkJCQkJCQlcCisJc2NwLT55b2ZmICogc2NwLT5mb250X3NpemUg KiBzY3AtPnNjLT5hZHAtPnZhX2xpbmVfd2lkdGggKwlcCisJeCAqIChwb3MgJSBzY3AtPnhzaXpl KSArCQkJCQlcCisJc2NwLT5mb250X3NpemUgKiBzY3AtPnNjLT5hZHAtPnZhX2xpbmVfd2lkdGgg KiAocG9zIC8gc2NwLT54c2l6ZSkKKworI2RlZmluZQl2Z2FfZHJhd3B4bChwb3MsIGNvbG9yKQkJ CQkJCVwKKwlzd2l0Y2ggKHNjcC0+c2MtPmFkcC0+dmFfaW5mby52aV9kZXB0aCkgewkJCVwKKwkJ Y2FzZSAzMjoJCQkJCQlcCisJCWNhc2UgMjQ6CQkJCQkJXAorCQkJd3JpdGVsKHBvcywgdmdhX3Bh bGV0dGUzMltjb2xvcl0pOwkJXAorCQkJYnJlYWs7CQkJCQkJXAorCQljYXNlIDE2OgkJCQkJCVwK KwkJCWlmIChzY3AtPnNjLT5hZHAtPnZhX2luZm8udmlfcGl4ZWxfZnNpemVzWzFdID09IDUpXAor CQkJCXdyaXRldyhwb3MsIHZnYV9wYWxldHRlMTVbY29sb3JdKTsJXAorCQkJZWxzZQkJCQkJCVwK KwkJCQl3cml0ZXcocG9zLCB2Z2FfcGFsZXR0ZTE2W2NvbG9yXSk7CVwKKwkJCWJyZWFrOwkJCQkJ CVwKKwkJY2FzZSAxNToJCQkJCQlcCisJCQl3cml0ZXcocG9zLCB2Z2FfcGFsZXR0ZTE1W2NvbG9y XSk7CQlcCisJCQlicmVhazsJCQkJCQlcCisJCX0KKwkKK3N0YXRpYyB1aW50MzJfdCB2Z2FfcGFs ZXR0ZTMyWzE2XSA9IHsKKwkweDAwMDAwMCwgMHgwMDAwYWQsIDB4MDBhZDAwLCAweDAwYWRhZCwK KwkweGFkMDAwMCwgMHhhZDAwYWQsIDB4YWQ1MjAwLCAweGFkYWRhZCwKKwkweDUyNTI1MiwgMHg1 MjUyZmYsIDB4NTJmZjUyLCAweDUyZmZmZiwKKwkweGZmNTI1MiwgMHhmZjUyZmYsIDB4ZmZmZjUy LCAweGZmZmZmZgorfTsKKworc3RhdGljIHVpbnQxNl90IHZnYV9wYWxldHRlMTZbMTZdID0gewor CTB4MDAwMCwgMHgwMDE2LCAweDA1NjAsIDB4MDU3NiwgMHhiMDAwLCAweGIwMTYsIDB4YjJhMCwg MHhiNTc2LAorCTB4NTJhYSwgMHg1MmJmLCAweDU3ZWEsIDB4NTdmZiwgMHhmYWFhLCAweGZhYmYs IDB4ZmZlYSwgMHhmZmZmCit9OworCitzdGF0aWMgdWludDE2X3QgdmdhX3BhbGV0dGUxNVsxNl0g PSB7CisJMHgwMDAwLCAweDAwMTYsIDB4MDJjMCwgMHgwMmQ2LCAweDU4MDAsIDB4NTgxNiwgMHg1 OTQwLCAweDVhZDYsCisJMHgyOTRhLCAweDI5NWYsIDB4MmJlYSwgMHgyYmZmLCAweDdkNGEsIDB4 N2Q1ZiwgMHg3ZmVhLCAweDdmZmYKK307CisKKyNpZm5kZWYgU0NfTk9fQ1VUUEFTVEUKK3N0YXRp YyB1aW50MzJfdCBtb3VzZV9idWYzMlsyNTZdOworc3RhdGljIHVpbnQxNl90IG1vdXNlX2J1ZjE2 WzI1Nl07CisjZW5kaWYKKyNlbmRpZgorCiBzdGF0aWMgdm9pZAogdmdhX25vcChzY3Jfc3RhdCAq c2NwLCAuLi4pCiB7CkBAIC00MzEsNyArNDkzLDQ5IEBACiAvKiBwaXhlbCAocmFzdGVyIHRleHQp IG1vZGUgcmVuZGVyZXIgKi8KIAogc3RhdGljIHZvaWQKLXZnYV9weGxjbGVhcihzY3Jfc3RhdCAq c2NwLCBpbnQgYywgaW50IGF0dHIpCit2Z2Ffcm5kcmluaXQoc2NyX3N0YXQgKnNjcCkKK3sKKwlp ZiAoc2NwLT5zYy0+YWRwLT52YV9pbmZvLnZpX21lbV9tb2RlbCA9PSBWX0lORk9fTU1fUExBTkFS KSB7CisJCXNjcC0+cm5kci0+Y2xlYXIgPSB2Z2FfcHhsY2xlYXJfcGxhbmFyOworCQlzY3AtPnJu ZHItPmRyYXdfYm9yZGVyID0gdmdhX3B4bGJvcmRlcl9wbGFuYXI7CisJCXNjcC0+cm5kci0+ZHJh dyA9IHZnYV92Z2FkcmF3X3BsYW5hcjsKKwkJc2NwLT5ybmRyLT5kcmF3X2N1cnNvciA9IHZnYV9w eGxjdXJzb3JfcGxhbmFyOworCQlzY3AtPnJuZHItPmJsaW5rX2N1cnNvciA9IHZnYV9weGxibGlu a19wbGFuYXI7CisJCXNjcC0+cm5kci0+ZHJhd19tb3VzZSA9IHZnYV9weGxtb3VzZV9wbGFuYXI7 CisJfSBlbHNlIGlmIChzY3AtPnNjLT5hZHAtPnZhX2luZm8udmlfbWVtX21vZGVsID09IFZfSU5G T19NTV9ESVJFQ1QpIHsKKwkJc2NwLT5ybmRyLT5jbGVhciA9IHZnYV9weGxjbGVhcl9kaXJlY3Q7 CisJCXNjcC0+cm5kci0+ZHJhd19ib3JkZXIgPSB2Z2FfcHhsYm9yZGVyX2RpcmVjdDsKKwkJc2Nw LT5ybmRyLT5kcmF3ID0gdmdhX3ZnYWRyYXdfZGlyZWN0OworCQlzY3AtPnJuZHItPmRyYXdfY3Vy c29yID0gdmdhX3B4bGN1cnNvcl9kaXJlY3Q7CisJCXNjcC0+cm5kci0+YmxpbmtfY3Vyc29yID0g dmdhX3B4bGJsaW5rX2RpcmVjdDsKKwkJc2NwLT5ybmRyLT5kcmF3X21vdXNlID0gdmdhX3B4bG1v dXNlX2RpcmVjdDsKKwl9Cit9CisKK3N0YXRpYyB2b2lkCit2Z2FfcHhsY2xlYXJfZGlyZWN0KHNj cl9zdGF0ICpzY3AsIGludCBjLCBpbnQgYXR0cikKK3sKKwl2bV9vZmZzZXRfdCBwOworCWludCBs aW5lX3dpZHRoOworCWludCBwaXhlbF9zaXplOworCWludCBsaW5lczsKKwlpbnQgaTsKKworCWxp bmVfd2lkdGggPSBzY3AtPnNjLT5hZHAtPnZhX2xpbmVfd2lkdGg7CisJcGl4ZWxfc2l6ZSA9IHNj cC0+c2MtPmFkcC0+dmFfaW5mby52aV9waXhlbF9zaXplOworCWxpbmVzID0gc2NwLT55c2l6ZSAq IHNjcC0+Zm9udF9zaXplOyAKKwlwID0gc2NwLT5zYy0+YWRwLT52YV93aW5kb3cgKworCSAgICBs aW5lX3dpZHRoICogc2NwLT55b2ZmICogc2NwLT5mb250X3NpemUgKworCSAgICBzY3AtPnhvZmYg KiA4ICogcGl4ZWxfc2l6ZTsKKworCWZvciAoaSA9IDA7IGkgPCBsaW5lczsgKytpKSB7CisJCWJ6 ZXJvX2lvKCh2b2lkICopcCwgc2NwLT54c2l6ZSAqIDggKiBwaXhlbF9zaXplKTsKKwkJcCArPSBs aW5lX3dpZHRoOworCX0KK30KKworc3RhdGljIHZvaWQKK3ZnYV9weGxjbGVhcl9wbGFuYXIoc2Ny X3N0YXQgKnNjcCwgaW50IGMsIGludCBhdHRyKQogewogCXZtX29mZnNldF90IHA7CiAJaW50IGxp bmVfd2lkdGg7CkBAIC00NTcsNyArNTYxLDY0IEBACiB9CiAKIHN0YXRpYyB2b2lkCi12Z2FfcHhs Ym9yZGVyKHNjcl9zdGF0ICpzY3AsIGludCBjb2xvcikKK3ZnYV9weGxib3JkZXJfZGlyZWN0KHNj cl9zdGF0ICpzY3AsIGludCBjb2xvcikKK3sKKwl2bV9vZmZzZXRfdCBzOworCXZtX29mZnNldF90 IGU7CisJdm1fb2Zmc2V0X3QgZjsKKwlpbnQgbGluZV93aWR0aDsKKwlpbnQgcGl4ZWxfc2l6ZTsK KwlpbnQgeDsKKwlpbnQgeTsKKwlpbnQgaTsKKworCWxpbmVfd2lkdGggPSBzY3AtPnNjLT5hZHAt PnZhX2xpbmVfd2lkdGg7CisJcGl4ZWxfc2l6ZSA9IHNjcC0+c2MtPmFkcC0+dmFfaW5mby52aV9w aXhlbF9zaXplOworCisJaWYgKHNjcC0+eW9mZiA+IDApIHsKKwkJcyA9IHNjcC0+c2MtPmFkcC0+ dmFfd2luZG93OworCQllID0gcyArIGxpbmVfd2lkdGggKiBzY3AtPnlvZmYgKiBzY3AtPmZvbnRf c2l6ZTsKKworCQlmb3IgKGYgPSBzOyBmIDwgZTsgZiArPSBwaXhlbF9zaXplKQorCQkJdmdhX2Ry YXdweGwoZiwgY29sb3IpOworCX0KKworCXkgPSAoc2NwLT55b2ZmICsgc2NwLT55c2l6ZSkgKiBz Y3AtPmZvbnRfc2l6ZTsKKworCWlmIChzY3AtPnlwaXhlbCA+IHkpIHsKKwkJcyA9IHNjcC0+c2Mt PmFkcC0+dmFfd2luZG93ICsgbGluZV93aWR0aCAqIHk7CisJCWUgPSBzICsgbGluZV93aWR0aCAq IChzY3AtPnlwaXhlbCAtIHkpOworCisJCWZvciAoZiA9IHM7IGYgPCBlOyBmICs9IHBpeGVsX3Np emUpCisJCQl2Z2FfZHJhd3B4bChmLCBjb2xvcik7CisJfQorCisJeSA9IHNjcC0+eW9mZiAqIHNj cC0+Zm9udF9zaXplOworCXggPSBzY3AtPnhwaXhlbCAvIDggLSBzY3AtPnhvZmYgLSBzY3AtPnhz aXplOworCisJZm9yIChpID0gMDsgaSA8IHNjcC0+eXNpemUgKiBzY3AtPmZvbnRfc2l6ZTsgKytp KSB7CisJCWlmIChzY3AtPnhvZmYgPiAwKSB7CisJCQlzID0gc2NwLT5zYy0+YWRwLT52YV93aW5k b3cgKyBsaW5lX3dpZHRoICogKHkgKyBpKTsKKwkJCWUgPSBzICsgc2NwLT54b2ZmICogOCAqIHBp eGVsX3NpemU7CisKKwkJCWZvciAoZiA9IHM7IGYgPCBlOyBmICs9IHBpeGVsX3NpemUpCisJCQkJ dmdhX2RyYXdweGwoZiwgY29sb3IpOworCQl9CisKKwkJaWYgKHggPiAwKSB7CisJCQlzID0gc2Nw LT5zYy0+YWRwLT52YV93aW5kb3cgKyBsaW5lX3dpZHRoICogKHkgKyBpKSArCisJCQkgICAgc2Nw LT54b2ZmICogOCAqIHBpeGVsX3NpemUgKworCQkJICAgIHNjcC0+eHNpemUgKiA4ICogcGl4ZWxf c2l6ZTsKKwkJCWUgPSBzICsgeCAqIDggKiBwaXhlbF9zaXplOworCisJCQlmb3IgKGYgPSBzOyBm IDwgZTsgZiArPSBwaXhlbF9zaXplKQorCQkJCXZnYV9kcmF3cHhsKGYsIGNvbG9yKTsKKwkJfQor CX0KK30KKworc3RhdGljIHZvaWQKK3ZnYV9weGxib3JkZXJfcGxhbmFyKHNjcl9zdGF0ICpzY3As IGludCBjb2xvcikKIHsKIAl2bV9vZmZzZXRfdCBwOwogCWludCBsaW5lX3dpZHRoOwpAQCAtNTA2 LDExICs2NjcsOCBAQAogCXVfY2hhciBjOwogCiAJbGluZV93aWR0aCA9IHNjcC0+c2MtPmFkcC0+ dmFfbGluZV93aWR0aDsKLQlkID0gc2NwLT5zYy0+YWRwLT52YV93aW5kb3cKLQkJKyBzY3AtPnhv ZmYgCi0JCSsgc2NwLT55b2ZmKnNjcC0+Zm9udF9zaXplKmxpbmVfd2lkdGggCi0JCSsgKGZyb20l c2NwLT54c2l6ZSkgCi0JCSsgc2NwLT5mb250X3NpemUqbGluZV93aWR0aCooZnJvbS9zY3AtPnhz aXplKTsKKworCWQgPSBWSURFT19NRU1PUllfUE9TKHNjcCwgZnJvbSwgMSk7CiAKIAlvdXR3KEdE Q0lEWCwgMHgwMDA1KTsJCS8qIHJlYWQgbW9kZSAwLCB3cml0ZSBtb2RlIDAgKi8KIAlvdXR3KEdE Q0lEWCwgMHgwMDAzKTsJCS8qIGRhdGEgcm90YXRlL2Z1bmN0aW9uIHNlbGVjdCAqLwpAQCAtNTU0 LDggKzcxMiw1OCBAQAogCW91dHcoR0RDSURYLCAweGZmMDgpOwkJLyogYml0IG1hc2sgKi8KIH0K IAotc3RhdGljIHZvaWQgCi12Z2FfdmdhZHJhdyhzY3Jfc3RhdCAqc2NwLCBpbnQgZnJvbSwgaW50 IGNvdW50LCBpbnQgZmxpcCkKK3N0YXRpYyB2b2lkCit2Z2FfdmdhZHJhd19kaXJlY3Qoc2NyX3N0 YXQgKnNjcCwgaW50IGZyb20sIGludCBjb3VudCwgaW50IGZsaXApCit7CisJdm1fb2Zmc2V0X3Qg ZCA9IDA7CisJdm1fb2Zmc2V0X3QgZTsKKwl1X2NoYXIgKmY7CisJdV9zaG9ydCBjb2wxLCBjb2wy LCBjb2xvcjsKKwlpbnQgbGluZV93aWR0aCwgcGl4ZWxfc2l6ZTsKKwlpbnQgaSwgaiwgazsKKwlp bnQgYTsKKworCWxpbmVfd2lkdGggPSBzY3AtPnNjLT5hZHAtPnZhX2xpbmVfd2lkdGg7CisJcGl4 ZWxfc2l6ZSA9IHNjcC0+c2MtPmFkcC0+dmFfaW5mby52aV9waXhlbF9zaXplOworCisJZCA9IFZJ REVPX01FTU9SWV9QT1Moc2NwLCBmcm9tLCA4ICogcGl4ZWxfc2l6ZSk7CisKKwlpZiAoZnJvbSAr IGNvdW50ID4gc2NwLT54c2l6ZSAqIHNjcC0+eXNpemUpCisJCWNvdW50ID0gc2NwLT54c2l6ZSAq IHNjcC0+eXNpemUgLSBmcm9tOworCisJZm9yIChpID0gZnJvbTsgY291bnQtLSA+IDA7ICsraSkg eworCQlhID0gc2NfdnRiX2dldGEoJnNjcC0+dnRiLCBpKTsKKworCQlpZiAoZmxpcCkgeworCQkJ Y29sMSA9ICgoKGEgJiAweDcwMDApID4+IDQpIHwgKGEgJiAweDA4MDApKSA+PiA4OworCQkJY29s MiA9ICgoKGEgJiAweDgwMDApID4+IDQpIHwgKGEgJiAweDA3MDApKSA+PiA4OworCQl9IGVsc2Ug eworCQkJY29sMSA9IChhICYgMHgwZjAwKSA+PiA4OworCQkJY29sMiA9IChhICYgMHhmMDAwKSA+ PiAxMjsKKwkJfQorCisJCWUgPSBkOworCQlmID0gJihzY3AtPmZvbnRbc2NfdnRiX2dldGMoJnNj cC0+dnRiLCBpKSAqIHNjcC0+Zm9udF9zaXplXSk7CisKKwkJZm9yIChqID0gMDsgaiA8IHNjcC0+ Zm9udF9zaXplOyArK2osICsrZikgeworCQkJZm9yIChrID0gMDsgayA8IDg7ICsraykgeworCQkJ CWNvbG9yID0gKmYgJiAoMSA8PCAoNyAtIGspKSA/IGNvbDEgOiBjb2wyOworCQkJCXZnYV9kcmF3 cHhsKGUgKyBwaXhlbF9zaXplICogaywgY29sb3IpOworCQkJfQorCisJCQllICs9IGxpbmVfd2lk dGg7CisJCX0KKworCQlkICs9IDggKiBwaXhlbF9zaXplOworCisJCWlmICgoaSAlIHNjcC0+eHNp emUpID09IHNjcC0+eHNpemUgLSAxKQorCQkJZCArPSBzY3AtPnhvZmYgKiAxNiAqIHBpeGVsX3Np emUgKworCQkJICAgICAoc2NwLT5mb250X3NpemUgLSAxKSAqIGxpbmVfd2lkdGg7CisJfQorfQor CitzdGF0aWMgdm9pZAordmdhX3ZnYWRyYXdfcGxhbmFyKHNjcl9zdGF0ICpzY3AsIGludCBmcm9t LCBpbnQgY291bnQsIGludCBmbGlwKQogewogCXZtX29mZnNldF90IGQ7CiAJdm1fb2Zmc2V0X3Qg ZTsKQEAgLTU2NywxMiArNzc1LDkgQEAKIAlpbnQgYTsKIAl1X2NoYXIgYzsKIAorCWQgPSBWSURF T19NRU1PUllfUE9TKHNjcCwgZnJvbSwgMSk7CisKIAlsaW5lX3dpZHRoID0gc2NwLT5zYy0+YWRw LT52YV9saW5lX3dpZHRoOwotCWQgPSBzY3AtPnNjLT5hZHAtPnZhX3dpbmRvdwotCQkrIHNjcC0+ eG9mZiAKLQkJKyBzY3AtPnlvZmYqc2NwLT5mb250X3NpemUqbGluZV93aWR0aCAKLQkJKyAoZnJv bSVzY3AtPnhzaXplKSAKLQkJKyBzY3AtPmZvbnRfc2l6ZSpsaW5lX3dpZHRoKihmcm9tL3NjcC0+ eHNpemUpOwogCiAJb3V0dyhHRENJRFgsIDB4MDMwNSk7CQkvKiByZWFkIG1vZGUgMCwgd3JpdGUg bW9kZSAzICovCiAJb3V0dyhHRENJRFgsIDB4MDAwMyk7CQkvKiBkYXRhIHJvdGF0ZS9mdW5jdGlv biBzZWxlY3QgKi8KQEAgLTYzMCw3ICs4MzUsNDkgQEAKIH0KIAogc3RhdGljIHZvaWQgCi1kcmF3 X3B4bGN1cnNvcihzY3Jfc3RhdCAqc2NwLCBpbnQgYXQsIGludCBvbiwgaW50IGZsaXApCitkcmF3 X3B4bGN1cnNvcl9kaXJlY3Qoc2NyX3N0YXQgKnNjcCwgaW50IGF0LCBpbnQgb24sIGludCBmbGlw KQoreworCXZtX29mZnNldF90IGQgPSAwOworCXVfY2hhciAqZjsKKwlpbnQgbGluZV93aWR0aCwg cGl4ZWxfc2l6ZTsKKwlpbnQgaGVpZ2h0OworCWludCBjb2wxLCBjb2wyLCBjb2xvcjsKKwlpbnQg YTsKKwlpbnQgaSwgajsKKworCWxpbmVfd2lkdGggPSBzY3AtPnNjLT5hZHAtPnZhX2xpbmVfd2lk dGg7CisJcGl4ZWxfc2l6ZSA9IHNjcC0+c2MtPmFkcC0+dmFfaW5mby52aV9waXhlbF9zaXplOwor CisJZCA9IFZJREVPX01FTU9SWV9QT1Moc2NwLCBhdCwgOCAqIHBpeGVsX3NpemUpICsKKwkgICAg KHNjcC0+Zm9udF9zaXplIC0gc2NwLT5jdXJzX2F0dHIuYmFzZSAtIDEpICogbGluZV93aWR0aDsK KworCWEgPSBzY192dGJfZ2V0YSgmc2NwLT52dGIsIGF0KTsKKworCWlmIChmbGlwKSB7CisJCWNv bDEgPSAoKG9uKSA/IChhICYgMHgwZjAwKSA6ICgoYSAmIDB4ZjAwMCkgPj4gNCkpID4+IDg7CisJ CWNvbDIgPSAoKG9uKSA/ICgoYSAmIDB4ZjAwMCkgPj4gNCkgOiAoYSAmIDB4MGYwMCkpID4+IDg7 CisJfSBlbHNlIHsKKwkJY29sMSA9ICgob24pID8gKChhICYgMHhmMDAwKSA+PiA0KSA6IChhICYg MHgwZjAwKSkgPj4gODsKKwkJY29sMiA9ICgob24pID8gKGEgJiAweDBmMDApIDogKChhICYgMHhm MDAwKSA+PiA0KSkgPj4gODsKKwl9CisKKwlmID0gJihzY3AtPmZvbnRbc2NfdnRiX2dldGMoJnNj cC0+dnRiLCBhdCkgKiBzY3AtPmZvbnRfc2l6ZSArCisJICAgICAgc2NwLT5mb250X3NpemUgLSBz Y3AtPmN1cnNfYXR0ci5iYXNlIC0gMV0pOworCisJaGVpZ2h0ID0gaW1pbihzY3AtPmN1cnNfYXR0 ci5oZWlnaHQsIHNjcC0+Zm9udF9zaXplKTsKKworCWZvciAoaSA9IDA7IGkgPCBoZWlnaHQ7ICsr aSwgLS1mKSB7CisJCWZvciAoaiA9IDA7IGogPCA4OyArK2opIHsKKwkJCWNvbG9yID0gKmYgJiAo MSA8PCAoNyAtIGopKSA/IGNvbDEgOiBjb2wyOworCQkJdmdhX2RyYXdweGwoZCArIHBpeGVsX3Np emUgKiBqLCBjb2xvcik7CisJCX0KKworCQlkIC09IGxpbmVfd2lkdGg7CisJfQorfQorCitzdGF0 aWMgdm9pZCAKK2RyYXdfcHhsY3Vyc29yX3BsYW5hcihzY3Jfc3RhdCAqc2NwLCBpbnQgYXQsIGlu dCBvbiwgaW50IGZsaXApCiB7CiAJdm1fb2Zmc2V0X3QgZDsKIAl1X2NoYXIgKmY7CkBAIC02NDIs MTIgKzg4OSw5IEBACiAJdV9jaGFyIGM7CiAKIAlsaW5lX3dpZHRoID0gc2NwLT5zYy0+YWRwLT52 YV9saW5lX3dpZHRoOwotCWQgPSBzY3AtPnNjLT5hZHAtPnZhX3dpbmRvdwotCQkrIHNjcC0+eG9m ZiAKLQkJKyBzY3AtPnlvZmYqc2NwLT5mb250X3NpemUqbGluZV93aWR0aCAKLQkJKyAoYXQlc2Nw LT54c2l6ZSkgCi0JCSsgc2NwLT5mb250X3NpemUqbGluZV93aWR0aCooYXQvc2NwLT54c2l6ZSkK LQkJKyAoc2NwLT5mb250X3NpemUgLSBzY3AtPmN1cnNfYXR0ci5iYXNlIC0gMSkqbGluZV93aWR0 aDsKKworCWQgPSBWSURFT19NRU1PUllfUE9TKHNjcCwgYXQsIDEpICsKKwkgICAgKHNjcC0+Zm9u dF9zaXplIC0gc2NwLT5jdXJzX2F0dHIuYmFzZSAtIDEpICogbGluZV93aWR0aDsKIAogCW91dHco R0RDSURYLCAweDAwMDUpOwkJLyogcmVhZCBtb2RlIDAsIHdyaXRlIG1vZGUgMCAqLwogCW91dHco R0RDSURYLCAweDAwMDMpOwkJLyogZGF0YSByb3RhdGUvZnVuY3Rpb24gc2VsZWN0ICovCkBAIC02 ODQsNyArOTI4LDM1IEBACiBzdGF0aWMgaW50IHB4bGJsaW5rcmF0ZSA9IDA7CiAKIHN0YXRpYyB2 b2lkIAotdmdhX3B4bGN1cnNvcihzY3Jfc3RhdCAqc2NwLCBpbnQgYXQsIGludCBibGluaywgaW50 IG9uLCBpbnQgZmxpcCkKK3ZnYV9weGxjdXJzb3JfZGlyZWN0KHNjcl9zdGF0ICpzY3AsIGludCBh dCwgaW50IGJsaW5rLCBpbnQgb24sIGludCBmbGlwKQoreworCWlmIChzY3AtPmN1cnNfYXR0ci5o ZWlnaHQgPD0gMCkJLyogdGhlIHRleHQgY3Vyc29yIGlzIGRpc2FibGVkICovCisJCXJldHVybjsK KworCWlmIChvbikgeworCQlpZiAoIWJsaW5rKSB7CisJCQlzY3AtPnN0YXR1cyB8PSBWUl9DVVJT T1JfT047CisJCQlkcmF3X3B4bGN1cnNvcl9kaXJlY3Qoc2NwLCBhdCwgb24sIGZsaXApOworCQl9 IGVsc2UgaWYgKCsrcHhsYmxpbmtyYXRlICYgNCkgeworCQkJcHhsYmxpbmtyYXRlID0gMDsKKwkJ CXNjcC0+c3RhdHVzIF49IFZSX0NVUlNPUl9PTjsKKwkJCWRyYXdfcHhsY3Vyc29yX2RpcmVjdChz Y3AsIGF0LAorCQkJCQkgICAgICBzY3AtPnN0YXR1cyAmIFZSX0NVUlNPUl9PTiwKKwkJCQkJICAg ICAgZmxpcCk7CisJCX0KKwl9IGVsc2UgeworCQlpZiAoc2NwLT5zdGF0dXMgJiBWUl9DVVJTT1Jf T04pCisJCQlkcmF3X3B4bGN1cnNvcl9kaXJlY3Qoc2NwLCBhdCwgb24sIGZsaXApOworCQlzY3At PnN0YXR1cyAmPSB+VlJfQ1VSU09SX09OOworCX0KKwlpZiAoYmxpbmspCisJCXNjcC0+c3RhdHVz IHw9IFZSX0NVUlNPUl9CTElOSzsKKwllbHNlCisJCXNjcC0+c3RhdHVzICY9IH5WUl9DVVJTT1Jf QkxJTks7Cit9CisKK3N0YXRpYyB2b2lkIAordmdhX3B4bGN1cnNvcl9wbGFuYXIoc2NyX3N0YXQg KnNjcCwgaW50IGF0LCBpbnQgYmxpbmssIGludCBvbiwgaW50IGZsaXApCiB7CiAJaWYgKHNjcC0+ Y3Vyc19hdHRyLmhlaWdodCA8PSAwKQkvKiB0aGUgdGV4dCBjdXJzb3IgaXMgZGlzYWJsZWQgKi8K IAkJcmV0dXJuOwpAQCAtNjkyLDE3ICs5NjQsMTcgQEAKIAlpZiAob24pIHsKIAkJaWYgKCFibGlu aykgewogCQkJc2NwLT5zdGF0dXMgfD0gVlJfQ1VSU09SX09OOwotCQkJZHJhd19weGxjdXJzb3Io c2NwLCBhdCwgb24sIGZsaXApOworCQkJZHJhd19weGxjdXJzb3JfcGxhbmFyKHNjcCwgYXQsIG9u LCBmbGlwKTsKIAkJfSBlbHNlIGlmICgrK3B4bGJsaW5rcmF0ZSAmIDQpIHsKIAkJCXB4bGJsaW5r cmF0ZSA9IDA7CiAJCQlzY3AtPnN0YXR1cyBePSBWUl9DVVJTT1JfT047Ci0JCQlkcmF3X3B4bGN1 cnNvcihzY3AsIGF0LAotCQkJCSAgICAgICBzY3AtPnN0YXR1cyAmIFZSX0NVUlNPUl9PTiwKLQkJ CQkgICAgICAgZmxpcCk7CisJCQlkcmF3X3B4bGN1cnNvcl9wbGFuYXIoc2NwLCBhdCwKKwkJCQkJ ICAgICAgc2NwLT5zdGF0dXMgJiBWUl9DVVJTT1JfT04sCisJCQkJCSAgICAgIGZsaXApOwogCQl9 CiAJfSBlbHNlIHsKIAkJaWYgKHNjcC0+c3RhdHVzICYgVlJfQ1VSU09SX09OKQotCQkJZHJhd19w eGxjdXJzb3Ioc2NwLCBhdCwgb24sIGZsaXApOworCQkJZHJhd19weGxjdXJzb3JfcGxhbmFyKHNj cCwgYXQsIG9uLCBmbGlwKTsKIAkJc2NwLT5zdGF0dXMgJj0gflZSX0NVUlNPUl9PTjsKIAl9CiAJ aWYgKGJsaW5rKQpAQCAtNzEyLDcgKzk4NCw3IEBACiB9CiAKIHN0YXRpYyB2b2lkCi12Z2FfcHhs Ymxpbmsoc2NyX3N0YXQgKnNjcCwgaW50IGF0LCBpbnQgZmxpcCkKK3ZnYV9weGxibGlua19kaXJl Y3Qoc2NyX3N0YXQgKnNjcCwgaW50IGF0LCBpbnQgZmxpcCkKIHsKIAlpZiAoIShzY3AtPnN0YXR1 cyAmIFZSX0NVUlNPUl9CTElOSykpCiAJCXJldHVybjsKQEAgLTcyMCwxMyArOTkyLDI1IEBACiAJ CXJldHVybjsKIAlweGxibGlua3JhdGUgPSAwOwogCXNjcC0+c3RhdHVzIF49IFZSX0NVUlNPUl9P TjsKLQlkcmF3X3B4bGN1cnNvcihzY3AsIGF0LCBzY3AtPnN0YXR1cyAmIFZSX0NVUlNPUl9PTiwg ZmxpcCk7CisJZHJhd19weGxjdXJzb3JfZGlyZWN0KHNjcCwgYXQsIHNjcC0+c3RhdHVzICYgVlJf Q1VSU09SX09OLCBmbGlwKTsKK30KKworc3RhdGljIHZvaWQKK3ZnYV9weGxibGlua19wbGFuYXIo c2NyX3N0YXQgKnNjcCwgaW50IGF0LCBpbnQgZmxpcCkKK3sKKwlpZiAoIShzY3AtPnN0YXR1cyAm IFZSX0NVUlNPUl9CTElOSykpCisJCXJldHVybjsKKwlpZiAoISgrK3B4bGJsaW5rcmF0ZSAmIDQp KQorCQlyZXR1cm47CisJcHhsYmxpbmtyYXRlID0gMDsKKwlzY3AtPnN0YXR1cyBePSBWUl9DVVJT T1JfT047CisJZHJhd19weGxjdXJzb3JfcGxhbmFyKHNjcCwgYXQsIHNjcC0+c3RhdHVzICYgVlJf Q1VSU09SX09OLCBmbGlwKTsKIH0KIAogI2lmbmRlZiBTQ19OT19DVVRQQVNURQogCiBzdGF0aWMg dm9pZAotZHJhd19weGxtb3VzZShzY3Jfc3RhdCAqc2NwLCBpbnQgeCwgaW50IHkpCitkcmF3X3B4 bG1vdXNlX3BsYW5hcihzY3Jfc3RhdCAqc2NwLCBpbnQgeCwgaW50IHkpCiB7CiAJdm1fb2Zmc2V0 X3QgcDsKIAlpbnQgbGluZV93aWR0aDsKQEAgLTgwMSw3ICsxMDg1LDcgQEAKIH0KIAogc3RhdGlj IHZvaWQKLXJlbW92ZV9weGxtb3VzZShzY3Jfc3RhdCAqc2NwLCBpbnQgeCwgaW50IHkpCityZW1v dmVfcHhsbW91c2VfcGxhbmFyKHNjcl9zdGF0ICpzY3AsIGludCB4LCBpbnQgeSkKIHsKIAl2bV9v ZmZzZXRfdCBwOwogCWludCBjb2wsIHJvdzsKQEAgLTg1OCwxMiArMTE0MiwxMDEgQEAKIH0KIAog c3RhdGljIHZvaWQgCi12Z2FfcHhsbW91c2Uoc2NyX3N0YXQgKnNjcCwgaW50IHgsIGludCB5LCBp bnQgb24pCit2Z2FfcHhsbW91c2VfZGlyZWN0KHNjcl9zdGF0ICpzY3AsIGludCB4LCBpbnQgeSwg aW50IG9uKQoreworCXZtX29mZnNldF90IHA7CisJaW50IGxpbmVfd2lkdGgsIHBpeGVsX3NpemU7 CisJaW50IHhlbmQsIHllbmQ7CisJc3RhdGljIGludCB4X29sZCA9IDAsIHhlbmRfb2xkID0gMDsK KwlzdGF0aWMgaW50IHlfb2xkID0gMCwgeWVuZF9vbGQgPSAwOworCWludCBpLCBqOworCXVpbnQz Ml90ICp1MzI7CisJdWludDE2X3QgKnUxNjsKKwlpbnQgYnBwOworCisJaWYgKCFvbikKKwkJcmV0 dXJuOworCisJYnBwID0gc2NwLT5zYy0+YWRwLT52YV9pbmZvLnZpX2RlcHRoOworCisJaWYgKChi cHAgPT0gMTYpICYmIChzY3AtPnNjLT5hZHAtPnZhX2luZm8udmlfcGl4ZWxfZnNpemVzWzFdID09 IDUpKQorCQlicHAgPSAxNTsKKworCWxpbmVfd2lkdGggPSBzY3AtPnNjLT5hZHAtPnZhX2xpbmVf d2lkdGg7CisJcGl4ZWxfc2l6ZSA9IHNjcC0+c2MtPmFkcC0+dmFfaW5mby52aV9waXhlbF9zaXpl OworCisJeGVuZCA9IGltaW4oeCArIDE2LCBzY3AtPnhwaXhlbCk7CisJeWVuZCA9IGltaW4oeSAr IDE2LCBzY3AtPnlwaXhlbCk7CisKKwlwID0gc2NwLT5zYy0+YWRwLT52YV93aW5kb3cgKyB5X29s ZCAqIGxpbmVfd2lkdGggKyB4X29sZCAqIHBpeGVsX3NpemU7CisKKwlmb3IgKGkgPSAwOyBpIDwg KHllbmRfb2xkIC0geV9vbGQpOyBpKyspIHsKKwkJZm9yIChqID0gKHhlbmRfb2xkIC0geF9vbGQg LSAxKTsgaiA+PSAwOyBqLS0pIHsKKwkJCXN3aXRjaCAoYnBwKSB7CisJCQljYXNlIDMyOgorCQkJ CXUzMiA9ICh1aW50MzJfdCopKHAgKyBqICogcGl4ZWxfc2l6ZSk7CisJCQkJd3JpdGVsKHUzMiwg bW91c2VfYnVmMzJbaSAqIDE2ICsgal0pOworCQkJCWJyZWFrOworCQkJY2FzZSAxNjoKKwkJCQkv KiBGQUxMVEhST1VHSCAqLworCQkJY2FzZSAxNToKKwkJCQl1MTYgPSAodWludDE2X3QqKShwICsg aiAqIHBpeGVsX3NpemUpOworCQkJCXdyaXRldyh1MTYsIG1vdXNlX2J1ZjE2W2kgKiAxNiArIGpd KTsKKwkJCQlicmVhazsKKwkJCX0KKwkJfQorCisJCXAgKz0gbGluZV93aWR0aDsKKwl9CisKKwlw ID0gc2NwLT5zYy0+YWRwLT52YV93aW5kb3cgKyB5ICogbGluZV93aWR0aCArIHggKiBwaXhlbF9z aXplOworCisJZm9yIChpID0gMDsgaSA8ICh5ZW5kIC0geSk7IGkrKykgeworCQlmb3IgKGogPSAo eGVuZCAtIHggLSAxKTsgaiA+PSAwOyBqLS0pIHsKKwkJCXN3aXRjaCAoYnBwKSB7CisJCQljYXNl IDMyOgorCQkJCXUzMiA9ICh1aW50MzJfdCopKHAgKyBqICogcGl4ZWxfc2l6ZSk7CisJCQkJbW91 c2VfYnVmMzJbaSAqIDE2ICsgal0gPSAqdTMyOworCQkJCWlmIChtb3VzZV9vcl9tYXNrW2ldICYg KDEgPDwgKDE1IC0gaikpKQorCQkJCQl3cml0ZWwodTMyLCB2Z2FfcGFsZXR0ZTMyWzE1XSk7CisJ CQkJZWxzZSBpZiAobW91c2VfYW5kX21hc2tbaV0gJiAoMSA8PCAoMTUgLSBqKSkpCisJCQkJCXdy aXRlbCh1MzIsIDApOworCQkJCWJyZWFrOworCQkJY2FzZSAxNjoKKwkJCQl1MTYgPSAodWludDE2 X3QqKShwICsgaiAqIHBpeGVsX3NpemUpOworCQkJCW1vdXNlX2J1ZjE2W2kgKiAxNiArIGpdID0g KnUxNjsKKwkJCQlpZiAobW91c2Vfb3JfbWFza1tpXSAmICgxIDw8ICgxNSAtIGopKSkKKwkJCQkJ d3JpdGV3KHUxNiwgdmdhX3BhbGV0dGUxNlsxNV0pOworCQkJCWVsc2UgaWYgKG1vdXNlX2FuZF9t YXNrW2ldICYgKDEgPDwgKDE1IC0gaikpKQorCQkJCQl3cml0ZXcodTE2LCAwKTsKKwkJCQlicmVh azsKKwkJCWNhc2UgMTU6CisJCQkJdTE2ID0gKHVpbnQxNl90KikocCAgKyBqICogcGl4ZWxfc2l6 ZSk7CisJCQkJbW91c2VfYnVmMTZbaSAqIDE2ICsgal0gPSAqdTE2OworCQkJCWlmIChtb3VzZV9v cl9tYXNrW2ldICYgKDEgPDwgKDE1IC0gaikpKQorCQkJCQl3cml0ZXcodTE2LCB2Z2FfcGFsZXR0 ZTE1WzE1XSk7CisJCQkJZWxzZSBpZiAobW91c2VfYW5kX21hc2tbaV0gJiAoMSA8PCAoMTUgLSBq KSkpCisJCQkJCXdyaXRldyh1MTYsIDApOworCQkJCWJyZWFrOworCQkJfQorCQl9CisKKwkJcCAr PSBsaW5lX3dpZHRoOworCX0KKworCXhfb2xkID0geDsKKwl5X29sZCA9IHk7CisJeGVuZF9vbGQg PSB4ZW5kOworCXllbmRfb2xkID0geWVuZDsKK30KKworc3RhdGljIHZvaWQgCit2Z2FfcHhsbW91 c2VfcGxhbmFyKHNjcl9zdGF0ICpzY3AsIGludCB4LCBpbnQgeSwgaW50IG9uKQogewogCWlmIChv bikKLQkJZHJhd19weGxtb3VzZShzY3AsIHgsIHkpOworCQlkcmF3X3B4bG1vdXNlX3BsYW5hcihz Y3AsIHgsIHkpOwogCWVsc2UKLQkJcmVtb3ZlX3B4bG1vdXNlKHNjcCwgeCwgeSk7CisJCXJlbW92 ZV9weGxtb3VzZV9wbGFuYXIoc2NwLCB4LCB5KTsKIH0KIAogI2VuZGlmIC8qIFNDX05PX0NVVFBB U1RFICovCkluZGV4OiBzY3ZpZGN0bC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9ob21lL25jdnMv c3JjL3N5cy9kZXYvc3lzY29ucy9zY3ZpZGN0bC5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjMy CmRpZmYgLXUgLXIxLjMyIHNjdmlkY3RsLmMKLS0tIHNjdmlkY3RsLmMJMTMgSnVsIDIwMDQgMTY6 MDY6MTkgLTAwMDAJMS4zMgorKysgc2N2aWRjdGwuYwkxIFNlcCAyMDA0IDE3OjA0OjE2IC0wMDAw CkBAIC0yLDYgKzIsOSBAQAogICogQ29weXJpZ2h0IChjKSAxOTk4IEthenV0YWthIFlPS09UQSA8 eW9rb3RhQHpvZGlhYy5tZWNoLnV0c3Vub21peWEtdS5hYy5qcD4KICAqIEFsbCByaWdodHMgcmVz ZXJ2ZWQuCiAgKgorICogVGhpcyBjb2RlIGlzIGRlcml2ZWQgZnJvbSBzb2Z0d2FyZSBjb250cmli dXRlZCB0byBUaGUgRHJhZ29uRmx5IFByb2plY3QKKyAqIGJ5IFNhc2NoYSBXaWxkbmVyIDxzYXdA b25saW5lLmRlPgorICoKICAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBi aW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAogICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0 dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCiAgKiBhcmUgbWV0OgpA QCAtMzY3LDE2ICszNzAsMjkgQEAKICAgICBpZiAoKGluZm8udmlfd2lkdGggPCB4c2l6ZSo4KSB8 fCAoaW5mby52aV9oZWlnaHQgPCB5c2l6ZSpmb250c2l6ZSkpCiAJcmV0dXJuIEVJTlZBTDsKIAot ICAgIC8qIG9ubHkgMTYgY29sb3IsIDQgcGxhbmUgbW9kZXMgYXJlIHN1cHBvcnRlZCBYWFggKi8K LSAgICBpZiAoKGluZm8udmlfZGVwdGggIT0gNCkgfHwgKGluZm8udmlfcGxhbmVzICE9IDQpKQot CXJldHVybiBFTk9ERVY7Ci0KICAgICAvKgotICAgICAqIHNldF9waXhlbF9tb2RlKCkgY3VycmVu dGx5IGRvZXMgbm90IHN1cHBvcnQgdmlkZW8gbW9kZXMgd2hvc2UKLSAgICAgKiBtZW1vcnkgc2l6 ZSBpcyBsYXJnZXIgdGhhbiA2NEsuIEJlY2F1c2Ugc3VjaCBtb2RlcyByZXF1aXJlCi0gICAgICog YmFuayBzd2l0Y2hpbmcgdG8gYWNjZXNzIHRoZSBlbnRpcmUgc2NyZWVuLiBYWFgKKyAgICAgKiBX ZSBjdXJyZW50bHkgc3VwcG9ydCB0aGUgZm9sbG93aW5nIGdyYXBoaWMgbW9kZXM6CisgICAgICoK KyAgICAgKiAtIDQgYnBwIHBsYW5hciBtb2RlcyB3aG9zZSBtZW1vcnkgc2l6ZSBkb2VzIG5vdCBl eGNlZWQgNjRLCisgICAgICogLSAxNSwgMTYsIDI0IGFuZCAzMiBicHAgbGluZWFyIG1vZGVzCiAg ICAgICovCi0gICAgaWYgKGluZm8udmlfd2lkdGgqaW5mby52aV9oZWlnaHQvOCA+IGluZm8udmlf d2luZG93X3NpemUpCisKKyAgICBpZiAoaW5mby52aV9tZW1fbW9kZWwgPT0gVl9JTkZPX01NX1BM QU5BUikgeworCWlmIChpbmZvLnZpX3BsYW5lcyAhPSA0KQorCSAgICByZXR1cm4gRU5PREVWOwor CisJLyoKKwkgKiBBIG1lbW9yeSBzaXplID42NEsgcmVxdWlyZXMgYmFuayBzd2l0Y2hpbmcgdG8g YWNjZXNzIHRoZSBlbnRpcmUKKwkgKiBzY3JlZW4uIFhYWAorCSAqLworCisJaWYgKGluZm8udmlf d2lkdGggKiBpbmZvLnZpX2hlaWdodCAvIDggPiBpbmZvLnZpX3dpbmRvd19zaXplKQorCSAgICBy ZXR1cm4gRU5PREVWOworICAgIH0gZWxzZSBpZiAoaW5mby52aV9tZW1fbW9kZWwgPT0gVl9JTkZP X01NX0RJUkVDVCkgeworCWlmICgoaW5mby52aV9kZXB0aCAhPSAxNSkgJiYgKGluZm8udmlfZGVw dGggIT0gMTYpICYmCisJICAgIChpbmZvLnZpX2RlcHRoICE9IDI0KSAmJiAoaW5mby52aV9kZXB0 aCAhPSAzMikpCisJICAgIHJldHVybiBFTk9ERVY7CisgICAgfSBlbHNlCiAJcmV0dXJuIEVOT0RF VjsKIAogICAgIC8qIHN0b3Agc2NyZWVuIHNhdmVyLCBldGMgKi8KSW5kZXg6IHN5c2NvbnMuYwo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09ClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMvZGV2L3N5c2NvbnMvc3lzY29u cy5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjQyNwpkaWZmIC11IC1yMS40Mjcgc3lzY29ucy5j Ci0tLSBzeXNjb25zLmMJNSBBdWcgMjAwNCAyMzo1NDowNCAtMDAwMAkxLjQyNworKysgc3lzY29u cy5jCTEgU2VwIDIwMDQgMTc6MDQ6MTggLTAwMDAKQEAgLTIsNiArMiw5IEBACiAgKiBDb3B5cmln aHQgKGMpIDE5OTItMTk5OCBT+HJlbiBTY2htaWR0CiAgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgog ICoKKyAqIFRoaXMgY29kZSBpcyBkZXJpdmVkIGZyb20gc29mdHdhcmUgY29udHJpYnV0ZWQgdG8g VGhlIERyYWdvbkZseSBQcm9qZWN0CisgKiBieSBTYXNjaGEgV2lsZG5lciA8c2F3QG9ubGluZS5k ZT4KKyAqCiAgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZv cm1zLCB3aXRoIG9yIHdpdGhvdXQKICAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92 aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucwogICogYXJlIG1ldDoKQEAgLTMwMzYs NiArMzAzOSw3IEBACiAgICAgaWYgKHN3ID09IHNjcC0+dHN3KSB7CiAJZXJyb3IgPSAoKnN3LT50 ZV9pbml0KShzY3AsICZzY3AtPnRzLCBTQ19URV9XQVJNX0lOSVQpOwogCXNjcC0+cm5kciA9IHJu ZHI7CisJc2NwLT5ybmRyLT5pbml0KHNjcCk7CiAJc2NfY2xlYXJfc2NyZWVuKHNjcCk7CiAJLyog YXNzZXJ0KGVycm9yID09IDApOyAqLwogCXJldHVybiBlcnJvcjsKQEAgLTMwNTYsNiArMzA2MCw3 IEBACiAgICAgc2NwLT50c3cgPSBzdzsKICAgICBzY3AtPnRzID0gcDsKICAgICBzY3AtPnJuZHIg PSBybmRyOworICAgIHNjcC0+cm5kci0+aW5pdChzY3ApOwogCiAgICAgLyogWFhYICovCiAgICAg KCpzdy0+dGVfZGVmYXVsdF9hdHRyKShzY3AsIHVzZXJfZGVmYXVsdC5zdGRfY29sb3IsIHVzZXJf ZGVmYXVsdC5yZXZfY29sb3IpOwpAQCAtMzQxNCw2ICszNDE5LDcgQEAKIAogICAgIC8qIHNldHVw IHZpZGVvIGhhcmR3YXJlIGZvciB0aGUgZ2l2ZW4gbW9kZSAqLwogICAgICgqdmlkc3dbc2NwLT5z Yy0+YWRhcHRlcl0tPnNldF9tb2RlKShzY3AtPnNjLT5hZHAsIHNjcC0+bW9kZSk7CisgICAgc2Nw LT5ybmRyLT5pbml0KHNjcCk7CiAjaWZuZGVmIF9fc3BhcmM2NF9fCiAgICAgc2NfdnRiX2luaXQo JnNjcC0+c2NyLCBWVEJfRlJBTUVCVUZGRVIsIHNjcC0+eHNpemUsIHNjcC0+eXNpemUsCiAJCSh2 b2lkICopc2NwLT5zYy0+YWRwLT52YV93aW5kb3csIEZBTFNFKTsKSW5kZXg6IHN5c2NvbnMuaAo9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09ClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMvZGV2L3N5c2NvbnMvc3lzY29u cy5oLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjgwCmRpZmYgLXUgLXIxLjgwIHN5c2NvbnMuaAot LS0gc3lzY29ucy5oCTI4IEp1bCAyMDA0IDA2OjI5OjAyIC0wMDAwCTEuODAKKysrIHN5c2NvbnMu aAkxIFNlcCAyMDA0IDE3OjA0OjE4IC0wMDAwCkBAIC0xLDYgKzEsOCBAQAogLyotCiAgKiBDb3B5 cmlnaHQgKGMpIDE5OTUtMTk5OCBT+HJlbiBTY2htaWR0CiAgKiBBbGwgcmlnaHRzIHJlc2VydmVk LgorICogVGhpcyBjb2RlIGlzIGRlcml2ZWQgZnJvbSBzb2Z0d2FyZSBjb250cmlidXRlZCB0byBU aGUgRHJhZ29uRmx5IFByb2plY3QKKyAqIGJ5IFNhc2NoYSBXaWxkbmVyIDxzYXdAb25saW5lLmRl PgogICoKICAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9y bXMsIHdpdGggb3Igd2l0aG91dAogICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3Zp ZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCkBAIC00MDUsNiArNDA3LDcgQEAKIAkJ ICAgICAgIFNJX1NVQl9EUklWRVJTLCBTSV9PUkRFUl9NSURETEUpCiAKIC8qIHJlbmRlcmVyIGZ1 bmN0aW9uIHRhYmxlICovCit0eXBlZGVmIHZvaWQJdnJfaW5pdF90KHNjcl9zdGF0ICpzY3ApOwog dHlwZWRlZiB2b2lkCXZyX2NsZWFyX3Qoc2NyX3N0YXQgKnNjcCwgaW50IGMsIGludCBhdHRyKTsK IHR5cGVkZWYgdm9pZAl2cl9kcmF3X2JvcmRlcl90KHNjcl9zdGF0ICpzY3AsIGludCBjb2xvcik7 CiB0eXBlZGVmIHZvaWQJdnJfZHJhd190KHNjcl9zdGF0ICpzY3AsIGludCBmcm9tLCBpbnQgY291 bnQsIGludCBmbGlwKTsKQEAgLTQxNiw2ICs0MTksNyBAQAogdHlwZWRlZiB2b2lkCXZyX2RyYXdf bW91c2VfdChzY3Jfc3RhdCAqc2NwLCBpbnQgeCwgaW50IHksIGludCBvbik7CiAKIHR5cGVkZWYg c3RydWN0IHNjX3JuZHJfc3cgeworCXZyX2luaXRfdAkJKmluaXQ7CiAJdnJfY2xlYXJfdAkJKmNs ZWFyOwogCXZyX2RyYXdfYm9yZGVyX3QJKmRyYXdfYm9yZGVyOwogCXZyX2RyYXdfdAkJKmRyYXc7 Cg== --------_41360548E86503B477C0_MULTIPART_MIXED_-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 17:33:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEA2A16A4CE; Wed, 1 Sep 2004 17:33:18 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6667043D2F; Wed, 1 Sep 2004 17:33:18 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 2A1BF7A439; Wed, 1 Sep 2004 10:33:18 -0700 (PDT) Message-ID: <413607DD.9040702@elischer.org> Date: Wed, 01 Sep 2004 10:33:17 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Giorgos Keramidas References: <20040901115723.3122E7303F@freebsd-current.sentex.ca> <20040901150638.GA7118@orion.daedalusnetworks.priv> In-Reply-To: <20040901150638.GA7118@orion.daedalusnetworks.priv> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: ia64@freebsd.org cc: FreeBSD Tinderbox cc: current@freebsd.org Subject: Re: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 17:33:19 -0000 my bad.. I tested it on SMP compiel and forgot a UP compile.. of course UP has no reason to access those fields to the fact that it breaks exposes another bug.. Giorgos Keramidas wrote: >On 2004-09-01 07:57, FreeBSD Tinderbox wrote: > > >>>>>stage 3.2: building everything >>>>> >>>>> >>[...] >>/tinderbox/CURRENT/ia64/ia64/src/sys/kern/subr_smp.c:498: undefined reference to `all_cpus' >>uma_core.o(.text+0x3fa1): In function `zone_timeout': >>/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:382: undefined reference to `all_cpus' >>uma_core.o(.text+0x6a21): In function `zone_dtor': >>/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:1423: undefined reference to `all_cpus' >>uma_core.o(.text+0x8730): In function `uma_print_zone': >>/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:2657: undefined reference to `all_cpus' >>uma_core.o(.text+0x8c31):/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:2710: more undefined references to `all_cpus' follow >>*** Error code 1 >> >>Stop in /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sys/GENERIC. >>*** Error code 1 >> >>Stop in /tinderbox/CURRENT/ia64/ia64/src. >>*** Error code 1 >> >>Stop in /tinderbox/CURRENT/ia64/ia64/src. >>TB --- 2004-09-01 11:57:23 - WARNING: /usr/bin/make returned exit code 1 >>TB --- 2004-09-01 11:57:23 - ERROR: failed to build generic kernel >>TB --- 2004-09-01 11:57:23 - tinderbox aborted >> >> > >Until Julian or another src-committer fixes the build error, this patch >unbreaks the build for me on non-SMP i386/i386. Since the affected code >is not specific to i386, it probably fixes the other architectures too: > >%%% >Index: sys/smp.h >=================================================================== >RCS file: /home/ncvs/src/sys/sys/smp.h,v >retrieving revision 1.80 >diff -u -r1.80 smp.h >--- sys/smp.h 1 Sep 2004 06:42:02 -0000 1.80 >+++ sys/smp.h 1 Sep 2004 14:00:30 -0000 >@@ -49,23 +49,26 @@ > extern int smp_cpus; > extern volatile cpumask_t started_cpus; > extern volatile cpumask_t stopped_cpus; >+extern cpumask_t all_cpus; >+extern cpumask_t idle_cpus_mask; >+extern cpumask_t hlt_cpus_mask; >+extern cpumask_t logical_cpus_mask; > #endif /* SMP */ > > extern u_int mp_maxid; > extern int mp_ncpus; > extern volatile int smp_started; > >-extern cpumask_t all_cpus; >-extern cpumask_t idle_cpus_mask; >-extern cpumask_t hlt_cpus_mask; >-extern cpumask_t logical_cpus_mask; >- > /* > * Macro allowing us to determine whether a CPU is absent at any given > * time, thus permitting us to configure sparse maps of cpuid-dependent > * (per-CPU) structures. > */ >+#ifdef SMP > #define CPU_ABSENT(x_cpu) ((all_cpus & (1 << (x_cpu))) == 0) >+#else >+#define CPU_ABSENT(x_cpu) (0) >+#endif > > #ifdef SMP > /* >Index: kern/subr_smp.c >=================================================================== >RCS file: /home/ncvs/src/sys/kern/subr_smp.c,v >retrieving revision 1.191 >diff -u -r1.191 subr_smp.c >--- kern/subr_smp.c 1 Sep 2004 06:42:01 -0000 1.191 >+++ kern/subr_smp.c 1 Sep 2004 11:12:38 -0000 >@@ -495,7 +495,6 @@ > { > mp_ncpus = 1; > mp_maxid = PCPU_GET(cpuid); >- all_cpus = PCPU_GET(cpumask); > KASSERT(PCPU_GET(cpuid) == 0, ("UP must have a CPU ID of zero")); > } > SYSINIT(cpu_mp_setvariables, SI_SUB_TUNABLES, SI_ORDER_FIRST, >%%% > >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 17:37:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 919CA16A4CE for ; Wed, 1 Sep 2004 17:37:47 +0000 (GMT) Received: from linda.pathlink.com (linda.pathlink.com [129.250.170.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DA9D43D53 for ; Wed, 1 Sep 2004 17:37:47 +0000 (GMT) (envelope-from kachun@pathlink.com) Received: from kachun.pathlink.com (dvl-1.pathlink.com [129.250.170.211]) by linda.pathlink.com (8.12.8p1/8.12.8) with ESMTP id i81HbkoG090156 for ; Wed, 1 Sep 2004 10:37:46 -0700 (PDT) (envelope-from kachun@pathlink.com) Message-Id: <5.0.2.1.2.20040901102427.00b92060@dvl.pathlink.com> X-Sender: kachun@dvl.pathlink.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Wed, 01 Sep 2004 10:37:46 -0700 To: freebsd-current@freebsd.org From: Kachun Lee Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: 5.3B2 with PAE won't boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 17:37:47 -0000 Hi, I embedded this problem in my previous thread. I got a E7501 single XEON 3GHz 6G RAM upgraded from 4.10 to 5.3B2. It was running without problem since Friday. I tried enabling PAE and it hanged during the turning icon (before displaying even 'KDB: debugger...). This morning, I tried all other boot options (safe mode, no ACPI, single user, extra log) in the beastie screen but they all hanged without any extra output. Any hints in what should I try. Regards Kachun From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 17:38:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 959A716A4D6 for ; Wed, 1 Sep 2004 17:38:01 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6151843D2F for ; Wed, 1 Sep 2004 17:38:01 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 24757 invoked from network); 1 Sep 2004 17:38:01 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail4.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 1 Sep 2004 17:38:00 -0000 Received: from hydrogen.funkthat.com (dilcle@localhost.funkthat.com [127.0.0.1])i81HbxuU081877; Wed, 1 Sep 2004 10:38:00 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i81HbvnV081876; Wed, 1 Sep 2004 10:37:57 -0700 (PDT) Date: Wed, 1 Sep 2004 10:37:57 -0700 From: John-Mark Gurney To: Igor Sysoev Message-ID: <20040901173757.GF29902@funkthat.com> Mail-Followup-To: Igor Sysoev , freebsd-current@freebsd.org References: <20040901144705.K97970@is.park.rambler.ru> <20040901155304.GD29902@funkthat.com> <20040901200709.H97970@is.park.rambler.ru> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="uxuisgdDHaNETlh8" Content-Disposition: inline In-Reply-To: <20040901200709.H97970@is.park.rambler.ru> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-current@freebsd.org Subject: Re: panic caused by EVFILT_SIGNAL detaching in rfork()ed thread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 17:38:01 -0000 --uxuisgdDHaNETlh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Igor Sysoev wrote this message on Wed, Sep 01, 2004 at 20:17 +0400: > On Wed, 1 Sep 2004, John-Mark Gurney wrote: > > > Igor Sysoev wrote this message on Wed, Sep 01, 2004 at 14:47 +0400: > > > #14 0xc05e87b3 in knlist_remove (knl=0xc39724f4, kn=0xc3e1d154, islocked=0) > > > at /usr/src/sys/kern/kern_event.c:1527 > > > 1527 knlist_remove_kq(knl, kn, islocked, 0); > > > (kgdb) p *knl > > > $1 = {kl_lock = 0x0, kl_list = {slh_first = 0x0}} > > > > > > > > > However, I do not know is it safe to test !SLIST_EMPTY(&p->p_klist) in > > > > It is possible to call SLIST_EMPTY, but you need to make you have proper > > locks held between the time you call SLIST_EMPTY, and knlist_remove... > > But I don't think that's the problem, the problem is else where... > > The problem is to test the empty p->p_klist before the calling > knlist_remove(). Nope.. The problem is that I was not testing the KN_DETACHED flag.. I haven't verified this fix for other processes, but I believe this should fix the problem... The KN_DETACHED flag implies if it is on the knlist of the object or not.. if it is not set, then the object is on the object, and needs to be removed... This fix should also mean that we can get rid of the test for KN_DETACHED in filt_procdetach... (which wasn't in filt_sigdetach).. Another "proper" fix to this panic, would be to add the if (kn->kn_status & KN_DETACHED) return; check to filt_sigdetach... There can be a situation where the list is not empty, but the knote is not on the list (already detached), and then we'd get another panic by falling off the end of the list... > > > filt_sigdetach() because in 5.3-BETA2 kqueue uses own mutex. Unfortunately, > > > I could not just now to write a small test case to allow everyone to > > > reproduce the panic but my user-level server always causes panic on exit on > > > unpatched 5.x and sometimes on unpatched 4.10. > > > > Could you print *kn? > > (kgdb) fr 14 > #14 0xc05e87b3 in knlist_remove (knl=0xc39724f4, kn=0xc3e1d154, islocked=0) > at /usr/src/sys/kern/kern_event.c:1527 > 1527 knlist_remove_kq(knl, kn, islocked, 0); > (kgdb) p *kn > $1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0x0}, > kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev = 0xc3c780ac}, > kn_kq = 0xc3c78080, kn_kevent = {ident = 64, filter = -6, flags = 32817, > fflags = 0, data = 1, udata = 0x0}, kn_status = 27, kn_sfflags = 0, 27 == 0x1b == 0b11011: KN_ACTIVE|KN_QUEUED|KN_DETACHED|KN_INFLUX [...] > > The problem is some how that the knote is being removed from the list > > (or was never on the list), but not being marked detached... > > > > Hmmm. what are the options you are using for rfork? > > The worker process starts two worker threads created by > rfork(RFPROC|RFTHREAD|RFMEM). Each thread opens kqueue and > adds the EVFILT_SIGNAL event. > > If you like I can send to you the source tarball (I do not distribute > the server right now, because it has not the documentation). The build > process is simple. Then you need to press ^C and you will get the panic. I believe this panic may be possible w/o rfork, but I'm not possitive.. It's probably an artifact of the fact that the kq was living longer than the proc that had the signal kevent associated with it, which normally does not happen... Attached is a patch.. And let me know if it fixes your panic... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." --uxuisgdDHaNETlh8 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kq.detach.diff" Index: kern_event.c =================================================================== RCS file: /home/ncvs/src/sys/kern/kern_event.c,v retrieving revision 1.79 diff -u -r1.79 kern_event.c --- kern_event.c 16 Aug 2004 03:08:38 -0000 1.79 +++ kern_event.c 1 Sep 2004 17:27:22 -0000 @@ -859,7 +859,8 @@ } else if (kev->flags & EV_DELETE) { kn->kn_status |= KN_INFLUX; KQ_UNLOCK(kq); - kn->kn_fop->f_detach(kn); + if (!(kn->kn_status & KN_DETACHED)) + kn->kn_fop->f_detach(kn); knote_drop(kn, td); goto done; } @@ -1158,7 +1159,8 @@ * it _INFLUX. */ *kevp = kn->kn_kevent; - kn->kn_fop->f_detach(kn); + if (!(kn->kn_status & KN_DETACHED)) + kn->kn_fop->f_detach(kn); knote_drop(kn, td); KQ_LOCK(kq); kn = NULL; @@ -1357,7 +1359,8 @@ ("KN_INFLUX set when not suppose to be")); kn->kn_status |= KN_INFLUX; KQ_UNLOCK(kq); - kn->kn_fop->f_detach(kn); + if (!(kn->kn_status & KN_DETACHED)) + kn->kn_fop->f_detach(kn); knote_drop(kn, td); KQ_LOCK(kq); } @@ -1369,7 +1372,8 @@ ("KN_INFLUX set when not suppose to be")); kn->kn_status |= KN_INFLUX; KQ_UNLOCK(kq); - kn->kn_fop->f_detach(kn); + if (!(kn->kn_status & KN_DETACHED)) + kn->kn_fop->f_detach(kn); knote_drop(kn, td); KQ_LOCK(kq); } @@ -1672,7 +1676,8 @@ } kn->kn_status |= KN_INFLUX; KQ_UNLOCK(kq); - kn->kn_fop->f_detach(kn); + if (!(kn->kn_status & KN_DETACHED)) + kn->kn_fop->f_detach(kn); knote_drop(kn, td); influx = 1; KQ_LOCK(kq); --uxuisgdDHaNETlh8-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 18:02:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C396816A4CE for ; Wed, 1 Sep 2004 18:02:58 +0000 (GMT) Received: from the-macgregors.org (82-33-59-105.cable.ubr06.stav.blueyonder.co.uk [82.33.59.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADF4A43D2D for ; Wed, 1 Sep 2004 18:02:57 +0000 (GMT) (envelope-from freebsd.macgregor@blueyonder.co.uk) X-Urban-Legend: Mail headers contain urban legends Received: from fire (rob@fire.macgregor [192.168.32.100]) (authenticated bits=0) by the-macgregors.org (8.13.1/8.13.1) with ESMTP id i81I2uAR024741 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 1 Sep 2004 18:02:56 GMT Message-Id: <200409011802.i81I2uAR024741@the-macgregors.org> From: "Rob MacGregor" To: Date: Wed, 1 Sep 2004 19:02:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 thread-index: AcSQTehcbhjM7cmYTheScA/Ynu0Klw== X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) Subject: 5.3-BETA1, jails and devfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 18:02:58 -0000 Probably a stupid question, however... I've got my first jail running under 5.3-BETA1 and am trying to lock down /dev, as per the advice in the jail man page. All attempts fail however: # devfs ruleset 10 devfs ruleset: ioctl DEVFSIO_SUSE: Operation not permitted # devfs rule apply hide devfs rule: ioctl DEVFSIO_RAPPLY: Operation not permitted I'm pretty sure I've missed something obvious in a man page, but having re-read them a few dozen times I'm darned if I can work it out. Any help appreciated. TIA -- Rob MacGregor (BOFH) [PGP key ID 0x1E51BF5A] If I cannot bend Heaven, I shall move Hell. -- Publius Vergilius Maro (Virgil). From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 18:13:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F82916A4CE for ; Wed, 1 Sep 2004 18:13:22 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A14C43D3F for ; Wed, 1 Sep 2004 18:13:22 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so231666rnl for ; Wed, 01 Sep 2004 11:13:21 -0700 (PDT) Received: by 10.38.83.80 with SMTP id g80mr1666775rnb; Wed, 01 Sep 2004 11:13:21 -0700 (PDT) Received: by 10.38.75.25 with HTTP; Wed, 1 Sep 2004 11:13:21 -0700 (PDT) Message-ID: <790a9fff04090111132a67ac3e@mail.gmail.com> Date: Wed, 1 Sep 2004 13:13:21 -0500 From: Scot Hetzel To: Rob MacGregor In-Reply-To: <200409011802.i81I2uAR024741@the-macgregors.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200409011802.i81I2uAR024741@the-macgregors.org> cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA1, jails and devfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Scot Hetzel List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 18:13:22 -0000 On Wed, 1 Sep 2004 19:02:56 +0100, Rob MacGregor wrote: > Probably a stupid question, however... > > I've got my first jail running under 5.3-BETA1 and am trying to lock down /dev, > as per the advice in the jail man page. All attempts fail however: > > # devfs ruleset 10 > devfs ruleset: ioctl DEVFSIO_SUSE: Operation not permitted > # devfs rule apply hide > devfs rule: ioctl DEVFSIO_RAPPLY: Operation not permitted > > I'm pretty sure I've missed something obvious in a man page, but having re-read > them a few dozen times I'm darned if I can work it out. Any help appreciated. > How are you applying the devfs rules (on the host, or inside the jail)? If you are applying them from inside the jail, I don't believe that is supported. You need to apply the rules before starting the jail. Scot From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 18:16:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C00D916A4CE for ; Wed, 1 Sep 2004 18:16:34 +0000 (GMT) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CC0F43D31 for ; Wed, 1 Sep 2004 18:16:34 +0000 (GMT) (envelope-from q@uni.de) Received: from wrzx30.rz.uni-wuerzburg.de (wrzx30.rz.uni-wuerzburg.de [132.187.1.30]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id 328A2D0EAF for ; Wed, 1 Sep 2004 20:16:33 +0200 (CEST) Received: from virusscan (localhost [127.0.0.1]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id 166E470606 for ; Wed, 1 Sep 2004 20:16:33 +0200 (CEST) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id C40C96FFB5 for ; Wed, 1 Sep 2004 20:16:32 +0200 (CEST) Received: from coyote.q.local (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id AE4B0D0EAF for ; Wed, 1 Sep 2004 20:16:32 +0200 (CEST) Received: from igor.q.local (igor [192.168.0.148]) by coyote.q.local (8.12.10/8.12.10) with ESMTP id i81IGWTH007904 for ; Wed, 1 Sep 2004 20:16:32 +0200 (CEST) (envelope-from q@igor.q.local) Received: from igor.q.local (localhost [127.0.0.1]) by igor.q.local (8.13.1/8.13.1) with ESMTP id i81IGUew004407 for ; Wed, 1 Sep 2004 20:16:30 +0200 (CEST) (envelope-from q@igor.q.local) Received: (from q@localhost) by igor.q.local (8.13.1/8.13.1/Submit) id i81IGTLh004406 for current@freebsd.org; Wed, 1 Sep 2004 20:16:29 +0200 (CEST) (envelope-from q) Date: Wed, 1 Sep 2004 20:16:29 +0200 From: Ulrich Spoerlein To: current@freebsd.org Message-ID: <20040901181629.GB953@galgenberg.net> Mail-Followup-To: current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AqsLC8rIMeq19msA" Content-Disposition: inline User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) Subject: panic: Duplicate free of item 0xc3474084 from zone 0xc1044c60(g_bio) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 18:16:34 -0000 --AqsLC8rIMeq19msA Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, I discovered the following panic yesterday after fiddling with suspend and lid close on my laptop. First the odd thing: After several suspend+resume cycles there were no more ACPI Events. Pressing Fn+ESC (suspend), closing the lid, even pressing the power button did nothing. I restarted devd -D -d and it didn't "see" any events happening. acpiconf -s 1 still worked, and pressing the power button correctly resumed the laptop. Even 'sysctl hw.acpi.video.lcd0.active=3D0/1' worked as expected. It's just that the buttons on the laptop did nothing. I can't remember what I did next, I think it was after sysctl hw.acpi.video.lcd0.active=3D1 that the laptop crashed with this message and trace panic: Duplicate free of item 0xc3474084 from zone 0xc1044c60(g_bio) (kgdb) bt #0 doadump () at pcpu.h:159 #1 0xc048e0bb in db_fncall (dummy1=3D-482686232, dummy2=3D0, dummy3=3D-482= 686332,=20 dummy4=3D0xe33aca80 "z=E0n=C0") at /usr/src/sys/ddb/db_command.c:531 #2 0xc048e45c in db_command_loop () at /usr/src/sys/ddb/db_command.c:349 #3 0xc048fbe1 in db_trap (type=3D3, code=3D0) at /usr/src/sys/ddb/db_main.= c:221 #4 0xc057a245 in kdb_trap (type=3D3, code=3D0, tf=3D0xe33acba0) at /usr/sr= c/sys/kern/subr_kdb.c:418 #5 0xc06bb5f3 in trap (frame=3D {tf_fs =3D -482738152, tf_es =3D -1068040176, tf_ds =3D -1066336240, = tf_edi =3D 256, tf_esi =3D -1066180656, tf_ebp =3D -482685984, tf_isp =3D -= 482686004, tf_ebx =3D -482685944, tf_edx =3D 0, tf_ecx =3D -1066288042, tf_= eax =3D -1066296234, tf_trapno =3D 3, tf_err =3D 0, tf_eip =3D -1067999498,= tf_cs =3D 8, tf_eflags =3D 646, tf_esp =3D -482685956, tf_ss =3D -10680839= 65}) at /usr/src/sys/i386/i386/trap.c:576 #6 0xc06b027a in calltrap () at /usr/src/sys/i386/i386/exception.s:140 #7 0xe33a0018 in ?? () #8 0xc0570010 in softclock (dummy=3D0xc0719c56) at /usr/src/sys/kern/kern_= timeout.c:201 #9 0xc0565503 in panic (fmt=3D---Can't read userspace from dump, or kernel= process---) at /usr/src/sys/kern/kern_shutdown.c:542 #10 0xc068cd4b in uma_dbg_free (zone=3D0xc1044c60, slab=3D0xc3474f70, item= =3D0xc3474084) at /usr/src/sys/vm/uma_dbg.c:276 #11 0xc068b7d8 in uma_zfree_arg (zone=3D0xc1044c60, item=3D0xc3474084, udat= a=3D0x0) at /usr/src/sys/vm/uma_core.c:2228 #12 0xc05323c2 in g_destroy_bio (bp=3D0xc3474084) at uma.h:302 #13 0xc0530b0b in g_disk_done (bp=3D0xc3474084) at /usr/src/sys/geom/geom_d= isk.c:203 #14 0xc04af06d in ad_done (request=3D0xc25a1000) at /usr/src/sys/dev/ata/at= a-disk.c:322 #15 0xc04a2fd5 in ata_completed (context=3D0xc25a1000, dummy=3D0) at /usr/s= rc/sys/dev/ata/ata-queue.c:404 #16 0xc04a30de in ata_timeout (request=3D0xc25a1000) at /usr/src/sys/dev/at= a/ata-queue.c:442 #17 0xc0570153 in softclock (dummy=3D0x0) at /usr/src/sys/kern/kern_timeout= =2Ec:259 #18 0xc0554b8b in ithread_loop (arg=3D0xc22d4580) at /usr/src/sys/kern/kern= _intr.c:546 #19 0xc05540a2 in fork_exit (callout=3D0xc0554a79 , arg=3D0xc= 22d4580, frame=3D0xe33acd48) at /usr/src/sys/kern/kern_fork.c:820 #20 0xc06b02dc in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:= 209 (kgdb) f 10 #10 0xc068cd4b in uma_dbg_free (zone=3D0xc1044c60, slab=3D0xc3474f70, item= =3D0xc3474084) at /usr/src/sys/vm/uma_dbg.c:276 276 panic("Duplicate free of item %p from zone %p(%s)\n= ", (kgdb) l 271 } 272 273 if (slab->us_freelist[freei].us_item !=3D 255) { 274 printf("Slab at %p, freei %d =3D %d.\n", 275 slab, freei, slab->us_freelist[freei].us_item); 276 panic("Duplicate free of item %p from zone %p(%s)\n= ", 277 item, zone, zone->uz_name); 278 } 279 280 /* (kgdb) p item $1 =3D (void *) 0xc3474084 (kgdb) p *item Attempt to dereference a generic pointer. (kgdb) p zone $2 =3D 0xc1044c60 (kgdb) p *zone $3 =3D {uz_name =3D 0xc0713f19 "g_bio", uz_lock =3D 0xc101e5a8, uz_keg =3D = 0xc101e5a0, uz_link =3D { le_next =3D 0x0, le_prev =3D 0xc101e5d8}, uz_full_bucket =3D {lh_first = =3D 0xc362d418},=20 uz_free_bucket =3D {lh_first =3D 0x0}, uz_ctor =3D 0, uz_dtor =3D 0, uz_i= nit =3D 0, uz_fini =3D 0,=20 uz_allocs =3D 1495977, uz_fills =3D 0, uz_count =3D 128, uz_cpu =3D {{uc_= freebucket =3D 0xc28d7a3c,=20 uc_allocbucket =3D 0xc3cc0418, uc_allocs =3D 40}}} I will update to the latest RELENG_5 and try to reproduce this panic. An older dmesg and the DSDT and ASL can be found here http://www.galgenberg.net/~q/freebsd/ Ulrich Spoerlein --=20 PGP Key ID: F0DB9F44 Get it while it's hot! PGP Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin --AqsLC8rIMeq19msA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD4DBQFBNhH9mArGtfDbn0QRAkSiAJjWgPCgQ6DBOLfBM8kbMtwq4L9pAKCWD5F5 8qC6Ruf9DqduXQhslVMHkg== =UqRC -----END PGP SIGNATURE----- --AqsLC8rIMeq19msA-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 18:19:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC1C616A4D0 for ; Wed, 1 Sep 2004 18:19:28 +0000 (GMT) Received: from ganymede.hub.org (blk-222-46-91.eastlink.ca [24.222.46.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17A8443D5F for ; Wed, 1 Sep 2004 18:19:28 +0000 (GMT) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id E3ADA33E31; Wed, 1 Sep 2004 15:19:27 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id DBA5833DCE for ; Wed, 1 Sep 2004 15:19:27 -0300 (ADT) Date: Wed, 1 Sep 2004 15:19:27 -0300 (ADT) From: "Marc G. Fournier" To: freebsd-current@freebsd.org Message-ID: <20040901151405.G47186@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: vnode leak in FFS code ... ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 18:19:29 -0000 I don't know if this is applicable to -current as well, but so far, anything like this I've uncovered in 4.x has needed an equivalent fix in 5.x, so figured it can't hurt to ask, especially with everyone working towards a STABLE 5.x branch ... I do not have a 5.x machine running this sort of load at the moment, so can't test, or provide feedback there ... all my 5.x machines are more or less desktops ... On Saturday, I'm going to try an unmount of the bigger file system, to see if it frees everything up without a reboot ... but if someone can suggest something to check to see if it is a) a leak and b) is fixable between now and then, please let me know ... again, this is a 4.10 system, but most of the work that Tor and David have done (re: vnodes) in the past relating to my servers have been applied to 5.x first, and MFC'd afterwards, so I suspect that this too many be something that applies to both branches ... ----------------- I have two servers, both running 4.10 of within a few days (Aug 5 for venus, Aug 7 for neptune) ... both running jail environments ... one with ~60 running, the other with ~80 ... the one with 60 has been running for ~25 days now, and is at the border of running out of vnodes: Aug 31 20:58:00 venus root: debug.numvnodes: 519920 - debug.freevnodes: 11058 - debug.vnlru_nowhere: 256463 - vlrup Aug 31 20:59:01 venus root: debug.numvnodes: 519920 - debug.freevnodes: 13155 - debug.vnlru_nowhere: 256482 - vlrup Aug 31 21:00:03 venus root: debug.numvnodes: 519920 - debug.freevnodes: 13092 - debug.vnlru_nowhere: 256482 - vlruwt while the other one has been up for ~1 days, but is using alot less, for more processes: Aug 31 20:58:00 neptune root: debug.numvnodes: 344062 - debug.freevnodes: 208655 - debug.vnlru_nowhere: 0 - vlruwt Aug 31 20:59:00 neptune root: debug.numvnodes: 344062 - debug.freevnodes: 208602 - debug.vnlru_nowhere: 0 - vlruwt Aug 31 21:00:03 neptune root: debug.numvnodes: 344062 - debug.freevnodes: 208319 - debug.vnlru_nowhere: 0 - vlruwt I've tried shutting down all of the VMs on venus, and umount'd all of the unionfs mounts, as well as the one nfs mount we have ... the above #s are after the VMs (and mounts are recreated ... Now, my understanding of the vnodes is that for every file opened, a vnode is created ... in my case, since I'm using unionfs, there are two vnodes per file ... if it possible that there are 'stale' vnodes that aren't being freed up? Is there some way of 'viewing' the vnode structure? For instance, fstat shows: venus# fstat | wc -l 19531 So, obviously it isn't just open files that I'm dealing with here, for even if I double that, that is nowhere near 519920 ... So, where else are the vnodes going? Is there a 'leak'? What can I look at to try and narrow this down / provide more information? Even some way of determining a specific process that is sucking back alot of them, to move that to a different machine ... ? Looking at vmstat -m .. specifically the work that David did on seperating the union vs regular vnodes: UNION mount 60 2K 3K204800K 162 0 0 32 undcac 0 0K 1K204800K343638713 0 0 16 unpath 13146 227K 1025K204800K 43541149 0 0 16,32,64,128 Export Host 1 1K 1K204800K 164 0 0 256 vnodes 141 7K 8K204800K 613 0 0 16,32,64,128,256 Why does 'vnodes' show only 141 InUse? Or, in this case, should I be looking at: FFS node496600124150K 127870K204800K401059293 0 0 256 496k FFS nodes, if I'm reading right? vs neptune, which is showing only: FFS node300433 75109K 80257K204800K 3875307 0 0 256 Hrmmm, maybe I'm mis-reading all of this, and going down the wrong paths here, so hopefully someone will correct if I am ... but, for now ... Looking at vmstat -m a bit further, the top of the report has: Memory statistics by bucket size Size In Use Free Requests HighWater Couldfree 16 13116 28356 2063580697 1280 7822 32 77734 7002 168084205 640 316065 64 465006 48402 2804541088 320 637084 128 100182 60010 591859866 160 1850304 256 500029 12163 1178322001 80 123078 Now, the only things that are using alot of the '256 Size' memory are: FFS node494513123629K 127870K204800K401104542 0 0 256 vfscache449709 29178K 32434K204800K737673766 0 0 64,128,256,512K Since only 500029 are 'InUse', and since FFS node is exclusively 256 ... I'm going to guess that most of vfscache is using something else ... so, my question becomes if 123000 'Could be Freed', why aren't they? Assuming, of course, I'm not on the wrong trail here :( From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 18:26:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E7BA16A4CE for ; Wed, 1 Sep 2004 18:26:31 +0000 (GMT) Received: from the-macgregors.org (82-33-59-105.cable.ubr06.stav.blueyonder.co.uk [82.33.59.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 854A143D31 for ; Wed, 1 Sep 2004 18:26:30 +0000 (GMT) (envelope-from freebsd.macgregor@blueyonder.co.uk) X-Urban-Legend: Mail headers contain urban legends Received: from fire (rob@fire.macgregor [192.168.32.100]) (authenticated bits=0) by the-macgregors.org (8.13.1/8.13.1) with ESMTP id i81IQTs4030534 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 1 Sep 2004 18:26:29 GMT Message-Id: <200409011826.i81IQTs4030534@the-macgregors.org> From: "Rob MacGregor" To: Date: Wed, 1 Sep 2004 19:26:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <790a9fff04090111132a67ac3e@mail.gmail.com> thread-index: AcSQT5A9/LR5a7vOTBaDxcS2/JnG3wAAULCA X-Virus-Scanned: by amavisd-milter (http://www.amavis.org/) Subject: RE: 5.3-BETA1, jails and devfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 18:26:31 -0000 On Wednesday, September 01, 2004 7:13 PM, Scot Hetzel unleashed the infinite monkeys and produced: > If you are applying them from inside the jail, I don't believe that is > supported. You need to apply the rules before starting the jail. Ah, that'll be my error then. Next dumb question - how do I apply them to *only* the jail, not the host? What I'm trying to do is lock it down such that the jail has no access to any devices on the host. Not sure what that list will be, but I'm happy to break things finding out :) TIA -- Rob | Oh my God! They killed init! You bastards! From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 18:28:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A64D116A4CE for ; Wed, 1 Sep 2004 18:28:24 +0000 (GMT) Received: from smtp05.web.de (smtp05.web.de [217.72.192.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44EDD43D45 for ; Wed, 1 Sep 2004 18:28:24 +0000 (GMT) (envelope-from Roland.Dittel@web.de) Received: from [217.232.245.247] (helo=freebsd.localnet) by smtp05.web.de with esmtp (TLSv1:DES-CBC3-SHA:168) (WEB.DE 4.101 #44) id 1C2ZqI-0007Gg-00 for freebsd-current@freebsd.org; Wed, 01 Sep 2004 20:28:22 +0200 Received: from [192.168.99.22] (notebook.localnet [192.168.99.22]) by freebsd.localnet (8.13.1/8.13.1) with ESMTP id i81ISJAR015241 for ; Wed, 1 Sep 2004 20:28:20 +0200 (CEST) (envelope-from Roland.Dittel@web.de) Message-ID: <413614C4.6040804@web.de> Date: Wed, 01 Sep 2004 20:28:20 +0200 From: Roland Dittel User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040809) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: Roland.Dittel@web.de X-Sender: Roland.Dittel@web.de Subject: Epson USB scanner doesn't work X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 18:28:25 -0000 Hi, I try using my Epson USB Scanner with FreeBSD 5.3beta2, but it's only possible to communitcate with the scanner and sane one time then it hangs. The scanner is listed as supported (GT-7000 is the european model of the Perfection 636U). bash-3.00# scanimage -L device `epson:/dev/uscanner0' is a Epson GT-7000 flatbed scanner bash-3.00# scanimage -L ^C bash-3.00# scanimage -L ^C These are the last lines of the debug output befor scanimage hangs: Aug 30 23:09:12 notebook kernel: uscanner0: uscannerread Aug 30 23:09:12 notebook kernel: uscannerread: start transfer 1 bytes Aug 30 23:09:12 notebook kernel: usbd_bulk_transfer: start transfer 1 bytes Aug 30 23:09:12 notebook kernel: usbd_transfer: xfer=0xc206c100, flags=4, pipe=0xc2516a00, running=0 Aug 30 23:09:12 notebook kernel: usbd_dump_queue: pipe=0xc2516a00 Aug 30 23:09:12 notebook kernel: usb_allocmem: use frag=0xc1667f40 size=1 Aug 30 23:09:12 notebook kernel: usb_insert_transfer: pipe=0xc2516a00 running=0 timeout=0 Aug 30 23:09:12 notebook kernel: uhci_device_bulk_start: xfer=0xc206c100 len=1 flags=4 ii=0xc206c170 Aug 30 23:09:12 notebook kernel: uhci_alloc_std_chain: addr=2 endpt=1 len=1 speed=2 flags=0x4 Aug 30 23:09:12 notebook kernel: uhci_alloc_std_chain: maxp=64 ntd=1 Aug 30 23:09:12 notebook kernel: uhci_alloc_std_chain: nexttog=1 Aug 30 23:09:12 notebook kernel: uhci_device_bulk_transfer: data(1) Aug 30 23:09:12 notebook kernel: TD(0xc1643f80) at 001b7f80 = link=0x00000005 status=0x398003ff token=0x00008269 buffer=0x0023bf40 Aug 30 23:09:12 notebook kernel: 5 398003ff,errcnt=3,actlen=0 pid=69,addr=2,endpt=1,D=0,maxlen=1 Aug 30 23:09:12 notebook kernel: uhci_add_bulk: sqh=0xc1642f20 Aug 30 23:09:12 notebook kernel: uhci_start_loop: add Aug 30 23:09:12 notebook kernel: uhci_device_bulk_transfer: data(2) Aug 30 23:09:12 notebook kernel: TD(0xc1643f80) at 001b7f80 = link=0x00000005 status=0x398003ff token=0x00008269 buffer=0x0023bf40 Aug 30 23:09:12 notebook kernel: 5 398003ff,errcnt=3,actlen=0 pid=69,addr=2,endpt=1,D=0,maxlen=1 Does anyone have a clue what happen to cause this? Thanks in advance Roland From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 18:57:03 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B787716A4CE; Wed, 1 Sep 2004 18:57:03 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45D2743D3F; Wed, 1 Sep 2004 18:57:03 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id i81IuxRE022546; Wed, 1 Sep 2004 14:56:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i81Iv2Ea091959; Wed, 1 Sep 2004 14:57:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 842D37303F; Wed, 1 Sep 2004 14:57:02 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040901185702.842D37303F@freebsd-current.sentex.ca> Date: Wed, 1 Sep 2004 14:57:02 -0400 (EDT) Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 18:57:03 -0000 TB --- 2004-09-01 18:21:12 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-01 18:21:12 - starting CURRENT tinderbox run for i386/i386 TB --- 2004-09-01 18:21:12 - checking out the source tree TB --- 2004-09-01 18:21:12 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2004-09-01 18:21:12 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-01 18:26:21 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-01 18:26:21 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2004-09-01 18:26:21 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies [...] echo kgmon: /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/usr/lib/libc.a /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/usr/lib/libkvm.a >> .depend ===> usr.sbin/kgzip rm -f .depend mkdep -f .depend -a /tinderbox/CURRENT/i386/i386/src/usr.sbin/kgzip/kgzip.c /tinderbox/CURRENT/i386/i386/src/usr.sbin/kgzip/aouthdr.c /tinderbox/CURRENT/i386/i386/src/usr.sbin/kgzip/elfhdr.c /tinderbox/CURRENT/i386/i386/src/usr.sbin/kgzip/kgzcmp.c /tinderbox/CURRENT/i386/i386/src/usr.sbin/kgzip/kgzld.c /tinderbox/CURRENT/i386/i386/src/usr.sbin/kgzip/xio.c In file included from /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/usr/include/sys/param.h:109, from /tinderbox/CURRENT/i386/i386/src/usr.sbin/kgzip/kgzcmp.c:30: /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/usr/include/machine/param.h:102:23: opt_sched.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/usr.sbin/kgzip. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/usr.sbin. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2004-09-01 18:57:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-01 18:57:02 - ERROR: failed to build world TB --- 2004-09-01 18:57:02 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 19:04:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C8FD16A4CE for ; Wed, 1 Sep 2004 19:04:52 +0000 (GMT) Received: from park.rambler.ru (park.rambler.ru [81.19.64.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD58443D31 for ; Wed, 1 Sep 2004 19:04:50 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by park.rambler.ru (8.12.6/8.12.6) with ESMTP id i81J4mis084811; Wed, 1 Sep 2004 23:04:48 +0400 (MSD) (envelope-from is@rambler-co.ru) Date: Wed, 1 Sep 2004 23:07:42 +0400 (MSD) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: John-Mark Gurney In-Reply-To: <20040901173757.GF29902@funkthat.com> Message-ID: <20040901224828.Q97970@is.park.rambler.ru> References: <20040901144705.K97970@is.park.rambler.ru> <20040901155304.GD29902@funkthat.com> <20040901173757.GF29902@funkthat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: panic caused by EVFILT_SIGNAL detaching in rfork()ed thread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 19:04:52 -0000 On Wed, 1 Sep 2004, John-Mark Gurney wrote: > > > The problem is some how that the knote is being removed from the list > > > (or was never on the list), but not being marked detached... > > > > > > Hmmm. what are the options you are using for rfork? > > > > The worker process starts two worker threads created by > > rfork(RFPROC|RFTHREAD|RFMEM). Each thread opens kqueue and > > adds the EVFILT_SIGNAL event. > > > > If you like I can send to you the source tarball (I do not distribute > > the server right now, because it has not the documentation). The build > > process is simple. Then you need to press ^C and you will get the panic. > > I believe this panic may be possible w/o rfork, but I'm not possitive.. > It's probably an artifact of the fact that the kq was living longer > than the proc that had the signal kevent associated with it, which > normally does not happen... > > Attached is a patch.. And let me know if it fixes your panic... The patch fixed the panic (I tested on 5.3-BETA2, GENERIC, SMP, HTT, SCHED_ULE). Thank you. Could you make the similar patch for 4.x ? And one more, could you rename http://people.freebsd.org/~jmg/kqueue.man.html into kqueue_preliminary.man.html and place a modern (or at least from 4.1-RELEASE) kqueue man page in kqueue.man.html ? Google shows your man page at first position and it confuses people. I saw several times when people said that kqueue has the incompatible interface between BSDs and even between various FreeBSD verisons referring to this man page. Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 19:10:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65C7B16A4CE for ; Wed, 1 Sep 2004 19:10:33 +0000 (GMT) Received: from mallaury.noc.nerim.net (smtp-103-wednesday.noc.nerim.net [62.4.17.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id D938243D31 for ; Wed, 1 Sep 2004 19:10:32 +0000 (GMT) (envelope-from bettan@nerim.net) Received: from danielle (linux-win.com [62.212.121.38]) by mallaury.noc.nerim.net (Postfix) with SMTP id 5C07262F8C for ; Wed, 1 Sep 2004 21:10:29 +0200 (CEST) Message-ID: <00e601c49057$5b317960$0301a8c0@danielle> From: "bettan" To: Date: Wed, 1 Sep 2004 21:10:32 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: netgear wg311 v2 and configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 19:10:33 -0000 hello , i tried to configure my wireless card and when i do : ifconfig ndis0 ssid linux-win.com channel 11 media DS/54Mbps mediaopt = hostap up stationname "FreeBSD AP" I have : ifconfig: unknown media subtype: DS/54Mbps and i don't understand why.FreeBSD supports 54 Mbps no ? Have you a = solution ? From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 19:22:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB54E16A4CE for ; Wed, 1 Sep 2004 19:22:44 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9F1243D41 for ; Wed, 1 Sep 2004 19:22:44 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i81JMVjn005284; Wed, 1 Sep 2004 12:22:32 -0700 Message-ID: <41362174.7030900@root.org> Date: Wed, 01 Sep 2004 12:22:28 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <20040716231556.7D2225D08@ptavv.es.net> In-Reply-To: <20040716231556.7D2225D08@ptavv.es.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: ATA DVD playback hanging in physrd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 19:22:45 -0000 Kevin Oberman wrote: >>Date: Fri, 16 Jul 2004 15:50:03 -0700 >>From: Nate Lawson >>Sender: owner-freebsd-current@freebsd.org > >>While playing back a DVD on my Thinkpad, it hangs at some point (2-5 >>minutes after beginning playback). The player is hung in "physrd" and >>the drive stops spinning. This hang happens when the drive is in PIO4 >>or DMA mode. >> >>However, starting another process (i.e. cat /dev/acd0) spins up the >>drive and it works (and the other process begins running again). >>What's interesting is that I can quickly trigger this hang by starting >>IO on a completely different channel (i.e. dd if=/dev/ad0 of=/dev/null >>bs=1m). This indicates that it may be a driver issue since the DVD >>drive that hangs is on a different channel and irq than the hard >>drive. >> >>Devices: >>atapci0: port >>0x1860-0x186f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 >>ata0: at 0x1f0 irq 14 on atapci0 >>ata1: at 0x170 irq 15 on atapci0 >>[...] >>ad0: 19077MB [41344/15/63] at ata0-master UDMA100 >>ata1-master: FAILURE - ATAPI_RESET no interrupt >>acd0: DVDROM at ata1-master PIO4 >> >>The same behavior also happens on my DVD/CDRW drive. >>ata1-slave: FAILURE - ATAPI_IDENTIFY no interrupt >>ata1-slave: FAILURE - ATAPI_IDENTIFY no interrupt >>ata1-master: FAILURE - ATAPI_RESET no interrupt >>acd0: CDRW at ata1-master PIO4 > > I have been seeing the same thing on my ThinkPad for a couple of > weeks. It may have been there for longer as I had not heavily used the > DVD for a while. There have been similar reports from others, but this > is the most exact match to what I have been seeing. Mine is a Toshiba > DVD/CDRW (DW-28E) at ata1-master UDMA33. I don't know if others reported back on this yet, but the problem is fixed. I believe Soeren's race fix was the key. Thanks! -Nate From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 19:31:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58FE916A4CE; Wed, 1 Sep 2004 19:31:23 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFE4A43D5A; Wed, 1 Sep 2004 19:31:22 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id i81JVIqT027210; Wed, 1 Sep 2004 15:31:18 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i81JVMuG010173; Wed, 1 Sep 2004 15:31:22 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 58F1F7303F; Wed, 1 Sep 2004 15:31:22 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040901193122.58F1F7303F@freebsd-current.sentex.ca> Date: Wed, 1 Sep 2004 15:31:22 -0400 (EDT) Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 19:31:23 -0000 TB --- 2004-09-01 18:57:02 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-01 18:57:02 - starting CURRENT tinderbox run for i386/pc98 TB --- 2004-09-01 18:57:02 - checking out the source tree TB --- 2004-09-01 18:57:02 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2004-09-01 18:57:02 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-01 19:01:25 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-01 19:01:25 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2004-09-01 19:01:25 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies [...] from /tinderbox/CURRENT/i386/pc98/src/sys/boot/pc98/boot2/boot.h:30, from /tinderbox/CURRENT/i386/pc98/src/sys/boot/pc98/boot2/disk.c:45: ./machine/param.h:102:23: opt_sched.h: No such file or directory In file included from /tinderbox/CURRENT/i386/pc98/src/sys/boot/pc98/boot2/../../../sys/param.h:109, from /tinderbox/CURRENT/i386/pc98/src/sys/boot/pc98/boot2/boot.h:30, from /tinderbox/CURRENT/i386/pc98/src/sys/boot/pc98/boot2/sys.c:36: ./machine/param.h:102:23: opt_sched.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/sys/boot/pc98/boot2. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/sys/boot/pc98. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/sys/boot. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/sys. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2004-09-01 19:31:22 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-01 19:31:22 - ERROR: failed to build world TB --- 2004-09-01 19:31:22 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 19:50:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E226816A4CF for ; Wed, 1 Sep 2004 19:50:06 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BBD643D54 for ; Wed, 1 Sep 2004 19:50:06 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i81JlTI6028115; Wed, 1 Sep 2004 15:47:30 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i81JlTpO028112; Wed, 1 Sep 2004 15:47:29 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 1 Sep 2004 15:47:29 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Mike Tancsa In-Reply-To: <6.1.2.0.0.20040901090639.08d11060@64.7.153.2> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: how 'supported' are 3ware Escalade controllers? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 19:50:07 -0000 On Wed, 1 Sep 2004, Mike Tancsa wrote: > That being said, the critical part for me is performance and > reliability. I have been using various 3ware cards for some time and I > have had VERY good results with them and I highly recommend them on > Intel platforms. (i.e I have zero experience with them on the AMD64). > We use them on FreeBSD, LINUX and Windows. I've had pretty good experience the 7xxx line, but would advise anyone using them make sure they're running at the latest firmware revision. On earlier firmware revisions, I ran into problems with array rebuilds aborting for reasons that seemed obscure to me at the time. With the most recent firmware, I had no problem at all. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 19:56:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D1A716A4CE for ; Wed, 1 Sep 2004 19:56:23 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5585543D58 for ; Wed, 1 Sep 2004 19:56:23 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Wed, 01 Sep 2004 12:56:23 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id C7FD75D0B; Wed, 1 Sep 2004 12:56:22 -0700 (PDT) To: Nate Lawson In-reply-to: Your message of "Wed, 01 Sep 2004 12:22:28 PDT." <41362174.7030900@root.org> Date: Wed, 01 Sep 2004 12:56:22 -0700 From: "Kevin Oberman" Message-Id: <20040901195622.C7FD75D0B@ptavv.es.net> cc: current@freebsd.org cc: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Subject: Re: ATA DVD playback hanging in physrd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 19:56:23 -0000 > Date: Wed, 01 Sep 2004 12:22:28 -0700 > From: Nate Lawson > > Kevin Oberman wrote: > >>Date: Fri, 16 Jul 2004 15:50:03 -0700 > >>From: Nate Lawson > >>Sender: owner-freebsd-current@freebsd.org > > > >>While playing back a DVD on my Thinkpad, it hangs at some point (2-5 > >>minutes after beginning playback). The player is hung in "physrd" and > >>the drive stops spinning. This hang happens when the drive is in PIO4 > >>or DMA mode. > >> > >>However, starting another process (i.e. cat /dev/acd0) spins up the > >>drive and it works (and the other process begins running again). > >>What's interesting is that I can quickly trigger this hang by starting > >>IO on a completely different channel (i.e. dd if=/dev/ad0 of=/dev/null > >>bs=1m). This indicates that it may be a driver issue since the DVD > >>drive that hangs is on a different channel and irq than the hard > >>drive. > >> > >>Devices: > >>atapci0: port > >>0x1860-0x186f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 > >>ata0: at 0x1f0 irq 14 on atapci0 > >>ata1: at 0x170 irq 15 on atapci0 > >>[...] > >>ad0: 19077MB [41344/15/63] at ata0-master UDMA100 > >>ata1-master: FAILURE - ATAPI_RESET no interrupt > >>acd0: DVDROM at ata1-master PIO4 > >> > >>The same behavior also happens on my DVD/CDRW drive. > >>ata1-slave: FAILURE - ATAPI_IDENTIFY no interrupt > >>ata1-slave: FAILURE - ATAPI_IDENTIFY no interrupt > >>ata1-master: FAILURE - ATAPI_RESET no interrupt > >>acd0: CDRW at ata1-master PIO4 > > > > I have been seeing the same thing on my ThinkPad for a couple of > > weeks. It may have been there for longer as I had not heavily used the > > DVD for a while. There have been similar reports from others, but this > > is the most exact match to what I have been seeing. Mine is a Toshiba > > DVD/CDRW (DW-28E) at ata1-master UDMA33. > > I don't know if others reported back on this yet, but the problem is > fixed. I believe Soeren's race fix was the key. Thanks for the note, Nate. I actually heard from someone else (I don't remember who) that this bug had vanished, although the note di not indicate what had fixed it. I suspected either a race or a lost interrupt. In any case, I have not seen the problem for a couple of weeks. (I'm guessing that it was ata-lowlevel.c 1.41 (and patches to most of the rest of ata) in HEAD. Thanks for the note! -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 19:58:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C84A616A4CF for ; Wed, 1 Sep 2004 19:58:59 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08AAF43D48 for ; Wed, 1 Sep 2004 19:58:59 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i81JwoW6026070; Wed, 1 Sep 2004 21:58:50 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <413629D9.6090606@DeepCore.dk> Date: Wed, 01 Sep 2004 21:58:17 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <20040716231556.7D2225D08@ptavv.es.net> <41362174.7030900@root.org> In-Reply-To: <41362174.7030900@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: current@freebsd.org Subject: Re: ATA DVD playback hanging in physrd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 19:58:59 -0000 Nate Lawson wrote: > Kevin Oberman wrote: >=20 >>> Date: Fri, 16 Jul 2004 15:50:03 -0700 >>> From: Nate Lawson >>> Sender: owner-freebsd-current@freebsd.org >> >> >>> While playing back a DVD on my Thinkpad, it hangs at some point (2-5 >>> minutes after beginning playback). The player is hung in "physrd" an= d >>> the drive stops spinning. This hang happens when the drive is in PIO= 4 >>> or DMA mode. >>> >>> However, starting another process (i.e. cat /dev/acd0) spins up the >>> drive and it works (and the other process begins running again). >>> What's interesting is that I can quickly trigger this hang by startin= g >>> IO on a completely different channel (i.e. dd if=3D/dev/ad0 of=3D/dev= /null >>> bs=3D1m). This indicates that it may be a driver issue since the DVD= >>> drive that hangs is on a different channel and irq than the hard >>> drive. >>> >>> Devices: >>> atapci0: port >>> 0x1860-0x186f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on p= ci0 >>> ata0: at 0x1f0 irq 14 on atapci0 >>> ata1: at 0x170 irq 15 on atapci0 >>> [...] >>> ad0: 19077MB [41344/15/63] at ata0-master UDMA100 >>> ata1-master: FAILURE - ATAPI_RESET no interrupt >>> acd0: DVDROM at ata1-master PIO4 >>> >>> The same behavior also happens on my DVD/CDRW drive. >>> ata1-slave: FAILURE - ATAPI_IDENTIFY no interrupt >>> ata1-slave: FAILURE - ATAPI_IDENTIFY no interrupt >>> ata1-master: FAILURE - ATAPI_RESET no interrupt >>> acd0: CDRW at ata1-master PIO4 >> >> >> I have been seeing the same thing on my ThinkPad for a couple of >> weeks. It may have been there for longer as I had not heavily used the= >> DVD for a while. There have been similar reports from others, but this= >> is the most exact match to what I have been seeing. Mine is a Toshiba >> DVD/CDRW (DW-28E) at ata1-master UDMA33. >=20 > I don't know if others reported back on this yet, but the problem is=20 > fixed. I believe Soeren's race fix was the key. Yes, this was the race that could get a request lost.. > Thanks! NP! -S=F8ren From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 20:02:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77FA316A4CE for ; Wed, 1 Sep 2004 20:02:58 +0000 (GMT) Received: from afields.ca (afields.ca [216.194.67.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 484F343D3F for ; Wed, 1 Sep 2004 20:02:58 +0000 (GMT) (envelope-from afields@afields.ca) Received: from afields.ca (localhost.afields.ca [127.0.0.1]) by afields.ca (8.12.11/8.12.11) with ESMTP id i81K2v4o093639; Wed, 1 Sep 2004 16:02:57 -0400 (EDT) (envelope-from afields@afields.ca) Received: (from afields@localhost) by afields.ca (8.12.11/8.12.11/Submit) id i81K2vgh093638; Wed, 1 Sep 2004 16:02:57 -0400 (EDT) (envelope-from afields) Date: Wed, 1 Sep 2004 16:02:57 -0400 From: Allan Fields To: "Marc G. Fournier" Message-ID: <20040901200257.GA92717@afields.ca> References: <20040901151405.G47186@ganymede.hub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040901151405.G47186@ganymede.hub.org> User-Agent: Mutt/1.4i cc: freebsd-current@freebsd.org Subject: Re: vnode leak in FFS code ... ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 20:02:58 -0000 On Wed, Sep 01, 2004 at 03:19:27PM -0300, Marc G. Fournier wrote: > I don't know if this is applicable to -current as well, but so far, > anything like this I've uncovered in 4.x has needed an equivalent fix in > 5.x, so figured it can't hurt to ask, especially with everyone working > towards a STABLE 5.x branch ... I do not have a 5.x machine running this > sort of load at the moment, so can't test, or provide feedback there ... > all my 5.x machines are more or less desktops ... > > On Saturday, I'm going to try an unmount of the bigger file system, to see > if it frees everything up without a reboot ... but if someone can suggest > something to check to see if it is a) a leak and b) is fixable between now > and then, please let me know ... again, this is a 4.10 system, but most of > the work that Tor and David have done (re: vnodes) in the past relating to > my servers have been applied to 5.x first, and MFC'd afterwards, so I > suspect that this too many be something that applies to both branches ... Unmounting the filesystems will call vflush() and should flush all vnodes from under that mount point. I'm not entirely sure if this is the best you can do w/o rebooting. -- Allan Fields, AFRSL - http://afields.ca 2D4F 6806 D307 0889 6125 C31D F745 0D72 39B4 5541 From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 20:23:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C289A16A4CE for ; Wed, 1 Sep 2004 20:23:21 +0000 (GMT) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id B043343D4C for ; Wed, 1 Sep 2004 20:23:21 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Wed, 01 Sep 2004 13:23:21 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 345035D04; Wed, 1 Sep 2004 13:23:21 -0700 (PDT) To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= In-reply-to: Your message of "Wed, 01 Sep 2004 21:58:17 +0200." <413629D9.6090606@DeepCore.dk> Date: Wed, 01 Sep 2004 13:23:21 -0700 From: "Kevin Oberman" Message-Id: <20040901202321.345035D04@ptavv.es.net> cc: current@freebsd.org cc: Nate Lawson Subject: Re: ATA DVD playback hanging in physrd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 20:23:21 -0000 Nate, By the way, as of the moment, almost everything on my T30 for S3 suspend/resume is working correctly. I can suspend and resume repeatedly with no problem except for the failure of the ICH3/AD1881A sound device to properly re-initialize. It worked for about a week when Warner first put in the PCI power stuff, but it never worked again after he backed out the initial attempt and re-committed stuff bit by bit over time. I assume that this is really a PCI issue and not really ACPI. I'll remind Warner of the problem some day after 5.3 is released and the ensuing confusion fades. Still, this is a major improvement as the system is generally usable after a suspend. Just no listen-able music. :-( Thanks for all of the efforts on making ACPI work on the morass of buggy, uncomplete, and just plain obstinate implementations out there. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 20:24:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B14ED16A4CE; Wed, 1 Sep 2004 20:24:39 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74B9443D53; Wed, 1 Sep 2004 20:24:38 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i81KOWPK040215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Sep 2004 23:24:33 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i81KOWvs000535; Wed, 1 Sep 2004 23:24:32 +0300 (EEST) (envelope-from ru) Date: Wed, 1 Sep 2004 23:24:32 +0300 From: Ruslan Ermilov To: cg Message-ID: <20040901202432.GB416@ip.net.ua> References: <20040828142503.GA52613@ip.net.ua> <20040829190833.GA9796@cnd.mcgill.ca> <20040829205942.GC39813@ip.net.ua> <20040831133654.GF31981@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="L6iaP+gRLNZHKoI4" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: Seigo Tanimura cc: Cameron Grant cc: "Simon L. Nielsen" cc: multimedia@freebsd.org cc: Mathew Kanner cc: current@freebsd.org Subject: Re: [PATCH] sound(4) related manpages 5.3 TODO item X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 20:24:39 -0000 --L6iaP+gRLNZHKoI4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 01, 2004 at 08:16:33PM +0100, cg wrote: [...] > the /dev entries are /dev/dsp* and /dev/audio*, /dev/sndstat, /dev/mixer*= , =20 > plus the midi ones: /dev/midi* and /dev/sequencer. all of these names ar= e =20 > mandated by the oss spec. >=20 Oh, of course I meant /dev/dsp* when I wrote /dev/pcm*. ;) > i'm not sure about midi device numbering; i believe some cards can =20 > implement multiple midi devices, eg an fm synth, io port and a wavetable = =20 > synth simultaneously. >=20 > pcm won't be a separate device as such; it won't appear in dmesg. this = =20 > probably applies to midi too. >=20 OK. > >So, to summarize, I'd have liked to see the following happen: > > > >- "snd" is the generic sound device (module snd.ko) > >- "snd_foo" is the sound driver for foo (module snd_foo.ko) > >- "pcm" devclass renamed to "snd" > >- "pcm", "mixer", and "midi" devices are created as children of "snd" >=20 > no. pcm and midi will effectively be part of snd. making them separate = =20 > newbus drivers would be tricky and require every driver to be modified. >=20 OK, sounds very good. But what about PCM-related sysctls then? How will hw.snd.pcm0.vchans be represented, for example? hw.snd.0.vchans maybe? > >- repo-copy (and tweak as necessary) all bridge drivers manpages, > > as shown in my patch; > > > >- do *not* repo-copy pcm(4) to sound(4) yet, just link it, possibly > > mentioning in the manpage that the generic driver will soon be > > renamed from "sound" to "snd", > > > >- fix hints in NOTES (as in my patch) to match reality. >=20 > this sounds ok to me. >=20 OK, I will it then. > >When "sound" -> "snd" conversion is actually done, repo-copy > >pcm(4) to sound(4), tweak as necessary, documenting what the > >"sound" device really is, mentioning "pcm", "mixer", and "midi" > >sub-devices, link sound(4) to pcm(4), mixer(4), and midi(4). > > > >Please let me know how to proceed... >=20 > i don't think i can cope with the pressure of getting it into 5.3, so it'= d =20 > be better to postpone it until 5.4 i think. >=20 Sure, that's fine. ;) Can you please send me some plain text paragraph for the pcm(4) manpage that will be linked to the sound(4) manpage, documenting future plans like renaming "sound" to "snd", so people stay tuned? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --L6iaP+gRLNZHKoI4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBNjAAqRfpzJluFF4RAonZAJwLgPFwLuUVr8NKDNdmbRqij/fDdgCgk7Sj 2O3Po8WlV2Aj45TPXMO67aE= =YKeJ -----END PGP SIGNATURE----- --L6iaP+gRLNZHKoI4-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 20:36:04 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E880016A4CE for ; Wed, 1 Sep 2004 20:36:04 +0000 (GMT) Received: from hotmail.com (bay8-f47.bay8.hotmail.com [64.4.27.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id D829A43D2D for ; Wed, 1 Sep 2004 20:36:04 +0000 (GMT) (envelope-from evantd@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 1 Sep 2004 13:36:04 -0700 Received: from 67.171.32.75 by by8fd.bay8.hotmail.msn.com with HTTP; Wed, 01 Sep 2004 20:36:04 GMT X-Originating-IP: [67.171.32.75] X-Originating-Email: [evantd@hotmail.com] X-Sender: evantd@hotmail.com From: "Evan Dower" To: bettan@nerim.net, freebsd-current@freebsd.org Date: Wed, 01 Sep 2004 13:36:04 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Sep 2004 20:36:04.0687 (UTC) FILETIME=[4D5625F0:01C49063] Subject: RE: netgear wg311 v2 and configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 20:36:05 -0000 I don't believe there is any need to specify the media (or mode for that matter). It will simply go as fast as it can. Furthermore, setting the stationname is still unsupported and will fail. Cheers, -- Evan Dower Undergraduate, Computer Science University of Washington Public key: http://students.washington.edu/evantd/pgp-pub-key.txt Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D >From: "bettan" >To: >Subject: netgear wg311 v2 and configuration >Date: Wed, 1 Sep 2004 21:10:32 +0200 > >hello , i tried to configure my wireless card and when i do : >ifconfig ndis0 ssid linux-win.com channel 11 media DS/54Mbps mediaopt >hostap up stationname "FreeBSD AP" > >I have : ifconfig: unknown media subtype: DS/54Mbps > > and i don't understand why.FreeBSD supports 54 Mbps no ? Have you a >solution ? >_______________________________________________ >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" _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! hthttp://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 20:39:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2770216A4CF for ; Wed, 1 Sep 2004 20:39:42 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 745D143D39 for ; Wed, 1 Sep 2004 20:39:41 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i81KdXlM026399; Wed, 1 Sep 2004 22:39:33 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <41363364.2070103@DeepCore.dk> Date: Wed, 01 Sep 2004 22:39:00 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Oberman References: <20040901202321.345035D04@ptavv.es.net> In-Reply-To: <20040901202321.345035D04@ptavv.es.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: current@freebsd.org cc: Nate Lawson Subject: Re: ATA DVD playback hanging in physrd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 20:39:42 -0000 Kevin Oberman wrote: > Nate, >=20 > By the way, as of the moment, almost everything on my T30 for S3 > suspend/resume is working correctly. I can suspend and resume repeatedl= y > with no problem except for the failure of the ICH3/AD1881A sound device= > to properly re-initialize. It worked for about a week when Warner first= > put in the PCI power stuff, but it never worked again after he backed > out the initial attempt and re-committed stuff bit by bit over time. >=20 > I assume that this is really a PCI issue and not really ACPI. I'll > remind Warner of the problem some day after 5.3 is released and the > ensuing confusion fades. >=20 > Still, this is a major improvement as the system is generally usable > after a suspend. Just no listen-able music. :-( >=20 > Thanks for all of the efforts on making ACPI work on the morass of > buggy, uncomplete, and just plain obstinate implementations out there. On that note ACPI still locks hard both my laptops (ASUS/Acer) on=20 resume, with and upto date -current its back to not even switching on=20 the backlight, so I have no way to tell what happens. On the ASUS that=20 has a serial port even that is totally dead. However, commenting out the resume code in acpi_cmbat.c make it get so=20 far as to give me a prompt in singleuser mode, but just a simple ls=20 makes in crash with a double fault in the image activation of the ls=20 command, it looks like the vm system is way out to lunch somehow. -S=F8ren From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 20:59:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E825216A4CE for ; Wed, 1 Sep 2004 20:59:37 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id B480D43D2F for ; Wed, 1 Sep 2004 20:59:37 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i81KxSjn006958; Wed, 1 Sep 2004 13:59:29 -0700 Message-ID: <4136382D.9010106@root.org> Date: Wed, 01 Sep 2004 13:59:25 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <20040901202321.345035D04@ptavv.es.net> <41363364.2070103@DeepCore.dk> In-Reply-To: <41363364.2070103@DeepCore.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: current@freebsd.org Subject: Re: ATA DVD playback hanging in physrd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 20:59:38 -0000 Søren Schmidt wrote: > Kevin Oberman wrote: > >> Nate, >> >> By the way, as of the moment, almost everything on my T30 for S3 >> suspend/resume is working correctly. I can suspend and resume repeatedly >> with no problem except for the failure of the ICH3/AD1881A sound device >> to properly re-initialize. It worked for about a week when Warner first >> put in the PCI power stuff, but it never worked again after he backed >> out the initial attempt and re-committed stuff bit by bit over time. >> >> I assume that this is really a PCI issue and not really ACPI. I'll >> remind Warner of the problem some day after 5.3 is released and the >> ensuing confusion fades. >> >> Still, this is a major improvement as the system is generally usable >> after a suspend. Just no listen-able music. :-( >> >> Thanks for all of the efforts on making ACPI work on the morass of >> buggy, uncomplete, and just plain obstinate implementations out there. > > > On that note ACPI still locks hard both my laptops (ASUS/Acer) on > resume, with and upto date -current its back to not even switching on > the backlight, so I have no way to tell what happens. On the ASUS that > has a serial port even that is totally dead. > > However, commenting out the resume code in acpi_cmbat.c make it get so > far as to give me a prompt in singleuser mode, but just a simple ls > makes in crash with a double fault in the image activation of the ls > command, it looks like the vm system is way out to lunch somehow. Try taking /sys/i386/acpi_wakeup.c back to 1.36. If that doesn't work, try reverting /sys/dev/acpica/acpi.c back to 2004/8/1 (mentioned previously). It is important to isolate the cause. I'm working on the cmbat resume part for you. The reason why this is not an easy problem to debug is that different systems have different AML and that AML is run by various methods, including cmbat. If it does weird things like writing to various runtime registers or acquiring mutexes, it can cause failures independent of our code. My laptop suspends/resumes fine with -current, including hotplugging the batteries, etc. -Nate From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 21:03:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9213E16A4CE for ; Wed, 1 Sep 2004 21:03:38 +0000 (GMT) Received: from mx1.imp.ch (mx1.imp.ch [157.161.9.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4704143D49 for ; Wed, 1 Sep 2004 21:03:37 +0000 (GMT) (envelope-from pg@imp.ch) Received: from mx2.imp.ch (mx2o [157.161.9.17]) by mx1.imp.ch (8.12.11/8.12.11) with ESMTP id i81L3R9h064705 for ; Wed, 1 Sep 2004 23:03:28 +0200 (CEST) (envelope-from pg@imp.ch) Received: from mx2.imp.ch (localhost [127.0.0.1]) by mx2.imp.ch (8.12.11/8.12.11/Submit) with ESMTP id i81L3P3U040731 for ; Wed, 1 Sep 2004 23:03:25 +0200 (CEST) (envelope-from pg@imp.ch) Received: (from clamav@localhost) by mx2.imp.ch (8.12.11/8.12.11/Submit) id i81L3Pri040721 for ; Wed, 1 Sep 2004 23:03:25 +0200 (CEST) (envelope-from pg@imp.ch) Received: from nbs.imp.ch (nbs.imp.ch [157.161.4.7]) by ns1.imp.ch (MIMEDefang) with ESMTP id i81L3Jq9093966; Wed, 01 Sep 2004 23:03:25 +0200 (CEST) Received: from murphy.imp.ch (murphy.imp.ch [157.161.4.77]) by nbs.imp.ch (8.12.10/8.12.3) with ESMTP id i81L3Jir43782957; Wed, 1 Sep 2004 23:03:19 +0200 (MES) Date: Wed, 1 Sep 2004 22:59:25 +0000 (UTC) From: Patrick Guelat X-X-Sender: patg@murphy.imp.ch To: pg@imp.ch In-Reply-To: <20040825235718.T60526@murphy.imp.ch> Message-ID: <20040901223721.S82908@murphy.imp.ch> References: <20040825235718.T60526@murphy.imp.ch> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-803614730-1094079565=:82908" X-Spam-Resent: Yes X-Spam-Checksum: ce6a2919388fbcec1dbfe9ee2367172e X-Virus-Message-Status: No X-Virus-Status: No, scantime="0.0010 seconds" X-Spam-Status: No, hits=-4.9 required=5 scantime="5.2472 seconds" tests=BAYES_00 X-Scanned-By: MIMEDefang 2.44 cc: freebsd-current@freebsd.org Subject: Panic in propagate_priority() [5.3-BETA2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 21:03:38 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-803614730-1094079565=:82908 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Since nobody answered to the problem yet that I reported a few days ago I did some more tests and got several panics since then... I'm trying to run OSPF6 on a gif-tunnel between a Cisco-7206VXR and a box running 5.3-BETA2 and get a panic everytime I start ospf6d (from /usr/ports/net/quagga). It always ends in a panic in propagate_priority(), sometimes I get the following panic-message: panic: process 37 (swi1: net):1 holds rip but isn't blocked on a lock "rip" is the lock defined in netinet/raw_ip.c which is also used by the netinet6/raw_ip6.c. Tracing the userland-part nearly always ends at the sendmsg(2) call on the raw socket, but sometimes the panic also occurs some time before ospf6d sends it's first hello message (maybe during the reception of the ipv6 ospf packet from the cisco ?) Regards Patrick -- Patrick Guélat, ImproWare AG Network Services, CH-4133 Pratteln Mail: Patrick.Guelat@imp.ch - Phone: +41 61 826 93 00 (ext: 13) --0-803614730-1094079565=:82908-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 21:06:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A80A416A4CE for ; Wed, 1 Sep 2004 21:06:27 +0000 (GMT) Received: from smtp-vbr4.xs4all.nl (smtp-vbr4.xs4all.nl [194.109.24.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id F17C343D5D for ; Wed, 1 Sep 2004 21:06:26 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr4.xs4all.nl (8.12.11/8.12.11) with ESMTP id i81L6Pie073113 for ; Wed, 1 Sep 2004 23:06:25 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.11/8.12.9) with ESMTP id i81L6PY7067703 for ; Wed, 1 Sep 2004 23:06:25 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.12.11/8.12.11/Submit) id i81L6Phn067702 for current@freebsd.org; Wed, 1 Sep 2004 23:06:25 +0200 (CEST) (envelope-from wb) Date: Wed, 1 Sep 2004 23:06:25 +0200 From: Wilko Bulte To: current@freebsd.org Message-ID: <20040901210625.GA67683@freebie.xs4all.nl> References: <20040828153451.GA38901@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040828153451.GA38901@freebie.xs4all.nl> User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.10-STABLE X-PGP: finger wilko@freebsd.org X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: 5.3-BETA displaying cd0 as an install target? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 21:06:27 -0000 On Sat, Aug 28, 2004 at 05:34:51PM +0200, Wilko Bulte wrote.. > Did anyone see sysinstall listing cd0 as an install target > on BETA1, on any other architecture than Alpha? > > On Alpha, sysinstall presents one with the option on partition > and install on cd0. Which is slightly daft.. It only happens with SCSI CD drives, so things that turn up as cd0. ATA CD drives aka acd0 do not get displayed by sysinstall. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 21:13:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E199716A4CF for ; Wed, 1 Sep 2004 21:13:40 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 899A443D3F for ; Wed, 1 Sep 2004 21:13:40 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 3885 invoked from network); 1 Sep 2004 21:13:40 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 1 Sep 2004 21:13:39 -0000 Received: from [10.50.41.228] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i81LDVpB062794; Wed, 1 Sep 2004 17:13:35 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-ia64@FreeBSD.org Date: Wed, 1 Sep 2004 14:50:00 -0400 User-Agent: KMail/1.6.2 References: <20040901115723.3122E7303F@freebsd-current.sentex.ca> <20040901150638.GA7118@orion.daedalusnetworks.priv> <413607DD.9040702@elischer.org> In-Reply-To: <413607DD.9040702@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409011450.00269.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: FreeBSD Tinderbox cc: current@FreeBSD.org cc: Julian Elischer cc: Giorgos Keramidas cc: ia64@FreeBSD.org Subject: Re: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 21:13:41 -0000 On Wednesday 01 September 2004 01:33 pm, Julian Elischer wrote: > my bad.. > I tested it on SMP compiel and forgot a UP compile.. > of course UP has no reason to access those fields to the fact that it > breaks exposes another bug.. Code in modules such as acpi.ko that needs to be agnostic and work on both SMP and UP kernels while still dealing with individual CPUs certainly does need this information. > Giorgos Keramidas wrote: > >On 2004-09-01 07:57, FreeBSD Tinderbox wrote: > >>>>>stage 3.2: building everything > >> > >>[...] > >>/tinderbox/CURRENT/ia64/ia64/src/sys/kern/subr_smp.c:498: undefined > >> reference to `all_cpus' uma_core.o(.text+0x3fa1): In function > >> `zone_timeout': > >>/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:382: undefined > >> reference to `all_cpus' uma_core.o(.text+0x6a21): In function > >> `zone_dtor': > >>/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:1423: undefined > >> reference to `all_cpus' uma_core.o(.text+0x8730): In function > >> `uma_print_zone': > >>/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_core.c:2657: undefined > >> reference to `all_cpus' > >> uma_core.o(.text+0x8c31):/tinderbox/CURRENT/ia64/ia64/src/sys/vm/uma_cor > >>e.c:2710: more undefined references to `all_cpus' follow *** Error code 1 > >> > >>Stop in > >> /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sy > >>s/GENERIC. *** Error code 1 > >> > >>Stop in /tinderbox/CURRENT/ia64/ia64/src. > >>*** Error code 1 > >> > >>Stop in /tinderbox/CURRENT/ia64/ia64/src. > >>TB --- 2004-09-01 11:57:23 - WARNING: /usr/bin/make returned exit code 1 > >>TB --- 2004-09-01 11:57:23 - ERROR: failed to build generic kernel > >>TB --- 2004-09-01 11:57:23 - tinderbox aborted > > > >Until Julian or another src-committer fixes the build error, this patch > >unbreaks the build for me on non-SMP i386/i386. Since the affected code > >is not specific to i386, it probably fixes the other architectures too: > > > >%%% > >Index: sys/smp.h > >=================================================================== > >RCS file: /home/ncvs/src/sys/sys/smp.h,v > >retrieving revision 1.80 > >diff -u -r1.80 smp.h > >--- sys/smp.h 1 Sep 2004 06:42:02 -0000 1.80 > >+++ sys/smp.h 1 Sep 2004 14:00:30 -0000 > >@@ -49,23 +49,26 @@ > > extern int smp_cpus; > > extern volatile cpumask_t started_cpus; > > extern volatile cpumask_t stopped_cpus; > >+extern cpumask_t all_cpus; > >+extern cpumask_t idle_cpus_mask; > >+extern cpumask_t hlt_cpus_mask; > >+extern cpumask_t logical_cpus_mask; > > #endif /* SMP */ > > > > extern u_int mp_maxid; > > extern int mp_ncpus; > > extern volatile int smp_started; > > > >-extern cpumask_t all_cpus; > >-extern cpumask_t idle_cpus_mask; > >-extern cpumask_t hlt_cpus_mask; > >-extern cpumask_t logical_cpus_mask; > >- > > /* > > * Macro allowing us to determine whether a CPU is absent at any given > > * time, thus permitting us to configure sparse maps of cpuid-dependent > > * (per-CPU) structures. > > */ > >+#ifdef SMP > > #define CPU_ABSENT(x_cpu) ((all_cpus & (1 << (x_cpu))) == 0) > >+#else > >+#define CPU_ABSENT(x_cpu) (0) > >+#endif > > > > #ifdef SMP > > /* > >Index: kern/subr_smp.c > >=================================================================== > >RCS file: /home/ncvs/src/sys/kern/subr_smp.c,v > >retrieving revision 1.191 > >diff -u -r1.191 subr_smp.c > >--- kern/subr_smp.c 1 Sep 2004 06:42:01 -0000 1.191 > >+++ kern/subr_smp.c 1 Sep 2004 11:12:38 -0000 > >@@ -495,7 +495,6 @@ > > { > > mp_ncpus = 1; > > mp_maxid = PCPU_GET(cpuid); > >- all_cpus = PCPU_GET(cpumask); > > KASSERT(PCPU_GET(cpuid) == 0, ("UP must have a CPU ID of zero")); > > } > > SYSINIT(cpu_mp_setvariables, SI_SUB_TUNABLES, SI_ORDER_FIRST, > >%%% > > > >_______________________________________________ > >freebsd-current@freebsd.org mailing list > >http://lists.freebsd.org/mailman/listinfo/freebsd-current > >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-ia64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ia64 > To unsubscribe, send any mail to "freebsd-ia64-unsubscribe@freebsd.org" -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 21:13:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C74E16A4E1 for ; Wed, 1 Sep 2004 21:13:52 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03A3543D1F for ; Wed, 1 Sep 2004 21:13:52 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 991 invoked from network); 1 Sep 2004 21:13:51 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 1 Sep 2004 21:13:50 -0000 Received: from [10.50.41.228] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i81LDVpF062794; Wed, 1 Sep 2004 17:13:47 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org, Elliot Finley Date: Wed, 1 Sep 2004 15:56:51 -0400 User-Agent: KMail/1.6.2 References: <015f01c48adf$15029f50$32cba1cd@science1> In-Reply-To: <015f01c48adf$15029f50$32cba1cd@science1> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409011556.51722.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx Subject: Re: 5.3 Beta1 failed boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 21:13:52 -0000 On Wednesday 25 August 2004 04:07 pm, Elliot Finley wrote: > I just moved to 5.3 Beta1 on my ASUS P4P800. (-current as of about 3 weeks > ago worked fine) > > I get the following when trying to boot (copied by hand): > > CPU: Intel(R) Pentium(R) 4 CPU 2.60GHz (2598.76-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > > Features=0xbfebfbffA ,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > Hyperthreading: 2 logical CPUs > real memory = 1072889856 (1023 MB) > avail memory = 1040359424 (992 MB) > MPTable: > ioapic0: Assuming intbase of 0 > ioapic0 irqs 0-23 on motherboard > npx0: [FAST] > npx0: on motherboard > npx0: INT 16 interface > pcib0: pcibus 0 on motherboard > pci0: on pcib0 > agp0: mem 0xf8000000-0xfbffffff at device > 0.0 on pci0 > pcib1: at device 1.0 on pci0 > pci1: on pcib1 > panic: Multiple entries for PCI IRQ 16 > cpuid = 0; > KDB: enter: panic > [thread 0] > Stopped at kdb_enter+0x2b: nop > db> > > > I've tried default, no-acpi, verbose-logging and I get here every time. > > What steps can I take to help resolve this? Can you provide mptable output? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 21:13:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A28616A5CC for ; Wed, 1 Sep 2004 21:13:59 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E5CE43D46 for ; Wed, 1 Sep 2004 21:13:59 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24139 invoked from network); 1 Sep 2004 21:13:59 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 1 Sep 2004 21:13:58 -0000 Received: from [10.50.41.228] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i81LDVpG062794; Wed, 1 Sep 2004 17:13:50 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Wed, 1 Sep 2004 16:03:59 -0400 User-Agent: KMail/1.6.2 References: <20040825235718.T60526@murphy.imp.ch> In-Reply-To: <20040825235718.T60526@murphy.imp.ch> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409011603.59676.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: pg@imp.ch Subject: Re: RELENG_5 : Page fault when running quagga ospf with IPv6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 21:13:59 -0000 On Wednesday 25 August 2004 05:57 pm, pg@imp.ch wrote: > System with RELENG_5 (Aug 25) > > When starting /usr/local/sbin/ospf6d (from /usr/ports/net/quagga) > I instantly get a kernel page fault. Reproducable. Trace: > > #0 doadump () at pcpu.h:159 > [...] > #22 0x0000000c in ?? () > #23 0x00000000 in ?? () > #24 0xc055954e in propagate_priority (td=0xc1dcc420) at > /usr/src/sys/kern/subr_turnstile.c:243 > #25 0xc0559ded in turnstile_wait (ts=0xc1dc5500, lock=0xc076b640, > owner=0x0) at /usr/src/sys/kern/subr_turnstile.c:556 > #26 0xc0529ca7 in _mtx_lock_sleep (m=0xc076b640, td=0xc1d8e6e0, opts=0, > file=0x0, line=0) > at /usr/src/sys/kern/kern_mutex.c:540 > #27 0xc051ac9f in ithread_loop (arg=0xc1d9e880) at > /usr/src/sys/kern/kern_intr.c:545 > #28 0xc0519afd in fork_exit (callout=0xc051ab03 , arg=0x0, > frame=0x0) > at /usr/src/sys/kern/kern_fork.c:820 > #29 0xc06bc8ac in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:209 > > Frame 24: > 238 ts->ts_lockobj->lo_name)); > 239 > 240 /* > 241 * Pick up the lock that td is blocked on. > 242 */ > 243 ts = td->td_blocked; > 244 MPASS(ts != NULL); > 245 tc = TC_LOOKUP(ts->ts_lockobj); > 246 mtx_lock_spin(&tc->tc_lock); > 247 > > ts->td_blocked is NULL ... > > kgdb) print *td > $2 = {td_proc = 0xc1ddc000, td_ksegrp = 0xc1d97000, td_plist = {tqe_next = > 0x0, tqe_prev = 0xc1ddc010}, td_kglist = { > tqe_next = 0x0, tqe_prev = 0xc1d9701c}, td_slpq = {tqe_next = 0x0, > tqe_prev = 0x0}, td_lockq = {tqe_next = 0x0, > tqe_prev = 0x0}, td_runq = {tqe_next = 0x0, tqe_prev = 0x0}, td_selq = > {tqh_first = 0x0, tqh_last = 0x0}, > td_sleepqueue = 0xc1dc7360, td_turnstile = 0xc1dc5540, td_tid = 100036, > td_flags = 0, td_inhibitors = 16, > td_pflags = 0, td_last_kse = 0xc1d95690, td_kse = 0xc1d95690, td_dupfd = > 0, td_wchan = 0x0, td_wmesg = 0x0, > td_lastcpu = 0 '\0', td_oncpu = 255 ', td_locks = 0, td_blocked = 0x0, > td_ithd = 0xc1d8cc00, td_lockname = 0x0, > td_contested = {lh_first = 0xc2a72400}, td_sleeplocks = 0x0, > td_intr_nesting_level = 0, td_pinned = 0, > td_mailbox = 0x0, td_ucred = 0xc1d7c200, td_standin = 0x0, td_prticks = > 0, td_upcall = 0x0, td_sticks = 0, > td_uuticks = 0, td_usticks = 0, td_intrval = 0, td_oldsigmask = {__bits > = {0, 0, 0, 0}}, td_sigmask = {__bits = {0, > 0, 0, 0}}, td_siglist = {__bits = {0, 0, 0, 0}}, td_waitset = 0x0, > td_umtx = {tqe_next = 0x0, tqe_prev = 0x0}, > td_generation = 7664, td_sigstk = {ss_sp = 0x0, ss_size = 0, ss_flags = > 0}, td_kflags = 0, td_xsig = 0, > td_profil_addr = 0, td_profil_ticks = 0, td_base_pri = 40 '(', > td_priority = 24 '\030', td_pcb = 0xd55c7da0, > td_state = TDS_INHIBITED, td_retval = {0, 0}, td_slpcallout = {c_links = > {sle = {sle_next = 0x0}, tqe = { > tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func > = 0, c_flags = 8}, td_frame = 0xd55c7d48, > td_kstack_obj = 0xc143e210, td_kstack = 3579600896, td_kstack_pages = 2, > td_altkstack_obj = 0x0, td_altkstack = 0, > td_altkstack_pages = 0, td_critnest = 1, td_md = {md_savecrit = 582}, > td_sched = 0xc1dcc57c} > > Any ideas ? Seems the thread has an inhibitor of TDI_IWAIT which it should never be in when it gets to this point. Perhaps a lock was leaked from an interrupt handler. Running with INVARIANTS + WITNESS might help to catch this. WITNESS especially might help as it would give a warning about what handler returns with a lock held and which lock and where the lock was acquired. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 21:14:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B82E16A602 for ; Wed, 1 Sep 2004 21:14:02 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 266AF43D41 for ; Wed, 1 Sep 2004 21:14:02 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24222 invoked from network); 1 Sep 2004 21:14:02 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 1 Sep 2004 21:14:01 -0000 Received: from [10.50.41.228] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i81LDVpH062794; Wed, 1 Sep 2004 17:13:57 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Wed, 1 Sep 2004 16:32:59 -0400 User-Agent: KMail/1.6.2 References: <412FB9FC.8030505@root.org> In-Reply-To: <412FB9FC.8030505@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409011632.59507.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: current@FreeBSD.org cc: gallatin@cs.duke.edu cc: Nate Lawson Subject: Re: spurrious interrupt problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 21:14:02 -0000 On Friday 27 August 2004 06:47 pm, Nate Lawson wrote: > I don't see anything wrong with your acpi pci link routing. In fact, > all your irqs are hardwired meaning acpi shouldn't touch them. This > must be something with ioapic. (BTW, acpi is non-optional on amd64). Talk to phk@. He had an opteron motherboard that had a busted BIOS that left the links between PCI IRQs that are used in atpic mode setup even when in apic mode so that you get 'alias' IRQs in apic mode. In his case the vendor provided a BIOS update that fixed the issue. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 21:14:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79F8016A601 for ; Wed, 1 Sep 2004 21:14:02 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2539043D2F for ; Wed, 1 Sep 2004 21:14:02 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24222 invoked from network); 1 Sep 2004 21:14:02 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 1 Sep 2004 21:14:01 -0000 Received: from [10.50.41.228] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i81LDVpH062794; Wed, 1 Sep 2004 17:13:57 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Wed, 1 Sep 2004 16:32:59 -0400 User-Agent: KMail/1.6.2 References: <412FB9FC.8030505@root.org> In-Reply-To: <412FB9FC.8030505@root.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409011632.59507.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: current@FreeBSD.org cc: gallatin@cs.duke.edu cc: Nate Lawson Subject: Re: spurrious interrupt problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 21:14:02 -0000 On Friday 27 August 2004 06:47 pm, Nate Lawson wrote: > I don't see anything wrong with your acpi pci link routing. In fact, > all your irqs are hardwired meaning acpi shouldn't touch them. This > must be something with ioapic. (BTW, acpi is non-optional on amd64). Talk to phk@. He had an opteron motherboard that had a busted BIOS that left the links between PCI IRQs that are used in atpic mode setup even when in apic mode so that you get 'alias' IRQs in apic mode. In his case the vendor provided a BIOS update that fixed the issue. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 21:14:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EC5816A65D for ; Wed, 1 Sep 2004 21:14:08 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79E7143D48 for ; Wed, 1 Sep 2004 21:14:08 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 7049 invoked from network); 1 Sep 2004 21:14:08 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 1 Sep 2004 21:14:07 -0000 Received: from [10.50.41.228] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i81LDVpI062794; Wed, 1 Sep 2004 17:14:01 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Wed, 1 Sep 2004 16:36:22 -0400 User-Agent: KMail/1.6.2 References: <41303747.4050104@elischer.org> In-Reply-To: <41303747.4050104@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409011636.22089.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Julian Elischer cc: FreeBSD current mailing list Subject: Re: hlt_cpus_mask X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 21:14:08 -0000 On Saturday 28 August 2004 03:41 am, Julian Elischer wrote: > This is defined static in i386 and amd64, > but as it is not exported it can not be used in > subr_smp.c, which probably should mask against it when trying to > forward roundrobin and signals. > > should this be a globally available thing? > Otherwise we are sending IPIs to threads that are > not capable of doing anything with them. More correct might be to add an 'active_cpus' mask that contains the set of active CPUs and use that in place of all_cpus where appropriate. active_cpus would basically be 'all_cpus & ~hlt_cpus_mask', but it probably makes more sense from an MI perspective since 'hlt' is fairly x86-specific. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 21:14:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A552F16A65E for ; Wed, 1 Sep 2004 21:14:08 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A53E43D49 for ; Wed, 1 Sep 2004 21:14:08 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 7049 invoked from network); 1 Sep 2004 21:14:08 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 1 Sep 2004 21:14:07 -0000 Received: from [10.50.41.228] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i81LDVpI062794; Wed, 1 Sep 2004 17:14:01 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Wed, 1 Sep 2004 16:36:22 -0400 User-Agent: KMail/1.6.2 References: <41303747.4050104@elischer.org> In-Reply-To: <41303747.4050104@elischer.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409011636.22089.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Julian Elischer cc: FreeBSD current mailing list Subject: Re: hlt_cpus_mask X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 21:14:08 -0000 On Saturday 28 August 2004 03:41 am, Julian Elischer wrote: > This is defined static in i386 and amd64, > but as it is not exported it can not be used in > subr_smp.c, which probably should mask against it when trying to > forward roundrobin and signals. > > should this be a globally available thing? > Otherwise we are sending IPIs to threads that are > not capable of doing anything with them. More correct might be to add an 'active_cpus' mask that contains the set of active CPUs and use that in place of all_cpus where appropriate. active_cpus would basically be 'all_cpus & ~hlt_cpus_mask', but it probably makes more sense from an MI perspective since 'hlt' is fairly x86-specific. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 21:29:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAF1116A4CE for ; Wed, 1 Sep 2004 21:29:39 +0000 (GMT) Received: from mproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 897AE43D39 for ; Wed, 1 Sep 2004 21:29:39 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by mproxy.gmail.com with SMTP id 77so245073rnl for ; Wed, 01 Sep 2004 14:29:35 -0700 (PDT) Received: by 10.38.70.76 with SMTP id s76mr661105rna; Wed, 01 Sep 2004 14:29:35 -0700 (PDT) Received: by 10.38.75.25 with HTTP; Wed, 1 Sep 2004 14:29:35 -0700 (PDT) Message-ID: <790a9fff04090114294b50b600@mail.gmail.com> Date: Wed, 1 Sep 2004 16:29:35 -0500 From: Scot Hetzel To: Rob MacGregor In-Reply-To: <200409011826.i81IQTs4030534@the-macgregors.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200409011826.i81IQTs4030534@the-macgregors.org> cc: freebsd-current@freebsd.org Subject: Re: 5.3-BETA1, jails and devfs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Scot Hetzel List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 21:29:39 -0000 On Wed, 1 Sep 2004 19:26:29 +0100, Rob MacGregor > Next dumb question - how do I apply them to *only* the jail, not the host? > You just need to add the following to your /etc/rc.conf jail_example_devfs_enable="YES" # mount devfs in the jail jail_example_devfs_ruleset="devfsrules_jail" # devfs ruleset to apply to jail to use the default jail ruleset (devfsrules_jail), or replace it with the name of your ruleset from /etc/devfs.rules. Scot From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 21:42:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 810D116A4CE for ; Wed, 1 Sep 2004 21:42:27 +0000 (GMT) Received: from ganymede.hub.org (blk-222-46-91.eastlink.ca [24.222.46.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E5F843D46 for ; Wed, 1 Sep 2004 21:42:27 +0000 (GMT) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id 53CAD375FD; Wed, 1 Sep 2004 18:42:27 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 4CCF6374CD; Wed, 1 Sep 2004 18:42:27 -0300 (ADT) Date: Wed, 1 Sep 2004 18:42:27 -0300 (ADT) From: "Marc G. Fournier" To: Allan Fields In-Reply-To: <20040901200257.GA92717@afields.ca> Message-ID: <20040901184050.J47186@ganymede.hub.org> References: <20040901151405.G47186@ganymede.hub.org> <20040901200257.GA92717@afields.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@freebsd.org Subject: Re: vnode leak in FFS code ... ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 21:42:27 -0000 On Wed, 1 Sep 2004, Allan Fields wrote: > On Wed, Sep 01, 2004 at 03:19:27PM -0300, Marc G. Fournier wrote: >> I don't know if this is applicable to -current as well, but so far, >> anything like this I've uncovered in 4.x has needed an equivalent fix in >> 5.x, so figured it can't hurt to ask, especially with everyone working >> towards a STABLE 5.x branch ... I do not have a 5.x machine running this >> sort of load at the moment, so can't test, or provide feedback there ... >> all my 5.x machines are more or less desktops ... >> >> On Saturday, I'm going to try an unmount of the bigger file system, to see >> if it frees everything up without a reboot ... but if someone can suggest >> something to check to see if it is a) a leak and b) is fixable between now >> and then, please let me know ... again, this is a 4.10 system, but most of >> the work that Tor and David have done (re: vnodes) in the past relating to >> my servers have been applied to 5.x first, and MFC'd afterwards, so I >> suspect that this too many be something that applies to both branches ... > > Unmounting the filesystems will call vflush() and should flush all > vnodes from under that mount point. I'm not entirely sure if this > is the best you can do w/o rebooting. Understood, and agreed ... *but* ... is there a way, before I do that, of determining if this is something that needs to be fixed at the OS level? Is there a leak here that I can somehow identify while its in this state? The server has *only* been up 25 days ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 21:44:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7FE716A4CE for ; Wed, 1 Sep 2004 21:44:29 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF06943D2D for ; Wed, 1 Sep 2004 21:44:29 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 17945 invoked from network); 1 Sep 2004 21:44:29 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 1 Sep 2004 21:44:28 -0000 Received: from [10.50.41.228] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i81LiO8C063061; Wed, 1 Sep 2004 17:44:25 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Wed, 1 Sep 2004 17:18:41 -0400 User-Agent: KMail/1.6.2 References: <20040828153451.GA38901@freebie.xs4all.nl> <20040901210625.GA67683@freebie.xs4all.nl> In-Reply-To: <20040901210625.GA67683@freebie.xs4all.nl> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409011718.41943.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Wilko Bulte cc: current@FreeBSD.org Subject: Re: 5.3-BETA displaying cd0 as an install target? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 21:44:30 -0000 On Wednesday 01 September 2004 05:06 pm, Wilko Bulte wrote: > On Sat, Aug 28, 2004 at 05:34:51PM +0200, Wilko Bulte wrote.. > > > Did anyone see sysinstall listing cd0 as an install target > > on BETA1, on any other architecture than Alpha? > > > > On Alpha, sysinstall presents one with the option on partition > > and install on cd0. Which is slightly daft.. > > It only happens with SCSI CD drives, so things that turn up as cd0. > ATA CD drives aka acd0 do not get displayed by sysinstall. This is probably GEOM related. I wonder if cd0 uses the DISK class unlike acd0 which uses its own ACD class. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 21:44:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBF4416A4CF for ; Wed, 1 Sep 2004 21:44:29 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id C488943D2F for ; Wed, 1 Sep 2004 21:44:29 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 17945 invoked from network); 1 Sep 2004 21:44:29 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 1 Sep 2004 21:44:28 -0000 Received: from [10.50.41.228] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i81LiO8C063061; Wed, 1 Sep 2004 17:44:25 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Wed, 1 Sep 2004 17:18:41 -0400 User-Agent: KMail/1.6.2 References: <20040828153451.GA38901@freebie.xs4all.nl> <20040901210625.GA67683@freebie.xs4all.nl> In-Reply-To: <20040901210625.GA67683@freebie.xs4all.nl> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409011718.41943.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Wilko Bulte cc: current@FreeBSD.org Subject: Re: 5.3-BETA displaying cd0 as an install target? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 21:44:30 -0000 On Wednesday 01 September 2004 05:06 pm, Wilko Bulte wrote: > On Sat, Aug 28, 2004 at 05:34:51PM +0200, Wilko Bulte wrote.. > > > Did anyone see sysinstall listing cd0 as an install target > > on BETA1, on any other architecture than Alpha? > > > > On Alpha, sysinstall presents one with the option on partition > > and install on cd0. Which is slightly daft.. > > It only happens with SCSI CD drives, so things that turn up as cd0. > ATA CD drives aka acd0 do not get displayed by sysinstall. This is probably GEOM related. I wonder if cd0 uses the DISK class unlike acd0 which uses its own ACD class. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 22:14:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB3ED16A4CE; Wed, 1 Sep 2004 22:14:23 +0000 (GMT) Received: from smtp-vbr3.xs4all.nl (smtp-vbr3.xs4all.nl [194.109.24.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A40943D39; Wed, 1 Sep 2004 22:14:23 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr3.xs4all.nl (8.12.11/8.12.11) with ESMTP id i81MELwU084896; Thu, 2 Sep 2004 00:14:22 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.11/8.12.9) with ESMTP id i81MEL7b068358; Thu, 2 Sep 2004 00:14:21 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.12.11/8.12.11/Submit) id i81MELEZ068357; Thu, 2 Sep 2004 00:14:21 +0200 (CEST) (envelope-from wb) Date: Thu, 2 Sep 2004 00:14:21 +0200 From: Wilko Bulte To: John Baldwin Message-ID: <20040901221421.GA68334@freebie.xs4all.nl> References: <20040828153451.GA38901@freebie.xs4all.nl> <20040901210625.GA67683@freebie.xs4all.nl> <200409011718.41943.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409011718.41943.jhb@FreeBSD.org> User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.10-STABLE X-PGP: finger wilko@freebsd.org X-Virus-Scanned: by XS4ALL Virus Scanner cc: freebsd-current@FreeBSD.org cc: current@FreeBSD.org Subject: Re: 5.3-BETA displaying cd0 as an install target? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 22:14:24 -0000 On Wed, Sep 01, 2004 at 05:18:41PM -0400, John Baldwin wrote.. > On Wednesday 01 September 2004 05:06 pm, Wilko Bulte wrote: > > On Sat, Aug 28, 2004 at 05:34:51PM +0200, Wilko Bulte wrote.. > > > > > Did anyone see sysinstall listing cd0 as an install target > > > on BETA1, on any other architecture than Alpha? > > > > > > On Alpha, sysinstall presents one with the option on partition > > > and install on cd0. Which is slightly daft.. > > > > It only happens with SCSI CD drives, so things that turn up as cd0. > > ATA CD drives aka acd0 do not get displayed by sysinstall. > > This is probably GEOM related. I wonder if cd0 uses the DISK class unlike > acd0 which uses its own ACD class. I asked phk and he had no obvious issue in mind. But I am not sure if he has seen my email on the acd versus cd difference yet. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 22:14:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB3ED16A4CE; Wed, 1 Sep 2004 22:14:23 +0000 (GMT) Received: from smtp-vbr3.xs4all.nl (smtp-vbr3.xs4all.nl [194.109.24.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A40943D39; Wed, 1 Sep 2004 22:14:23 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr3.xs4all.nl (8.12.11/8.12.11) with ESMTP id i81MELwU084896; Thu, 2 Sep 2004 00:14:22 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.12.11/8.12.9) with ESMTP id i81MEL7b068358; Thu, 2 Sep 2004 00:14:21 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.12.11/8.12.11/Submit) id i81MELEZ068357; Thu, 2 Sep 2004 00:14:21 +0200 (CEST) (envelope-from wb) Date: Thu, 2 Sep 2004 00:14:21 +0200 From: Wilko Bulte To: John Baldwin Message-ID: <20040901221421.GA68334@freebie.xs4all.nl> References: <20040828153451.GA38901@freebie.xs4all.nl> <20040901210625.GA67683@freebie.xs4all.nl> <200409011718.41943.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409011718.41943.jhb@FreeBSD.org> User-Agent: Mutt/1.4.1i X-OS: FreeBSD 4.10-STABLE X-PGP: finger wilko@freebsd.org X-Virus-Scanned: by XS4ALL Virus Scanner cc: freebsd-current@FreeBSD.org cc: current@FreeBSD.org Subject: Re: 5.3-BETA displaying cd0 as an install target? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 22:14:24 -0000 On Wed, Sep 01, 2004 at 05:18:41PM -0400, John Baldwin wrote.. > On Wednesday 01 September 2004 05:06 pm, Wilko Bulte wrote: > > On Sat, Aug 28, 2004 at 05:34:51PM +0200, Wilko Bulte wrote.. > > > > > Did anyone see sysinstall listing cd0 as an install target > > > on BETA1, on any other architecture than Alpha? > > > > > > On Alpha, sysinstall presents one with the option on partition > > > and install on cd0. Which is slightly daft.. > > > > It only happens with SCSI CD drives, so things that turn up as cd0. > > ATA CD drives aka acd0 do not get displayed by sysinstall. > > This is probably GEOM related. I wonder if cd0 uses the DISK class unlike > acd0 which uses its own ACD class. I asked phk and he had no obvious issue in mind. But I am not sure if he has seen my email on the acd versus cd difference yet. -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 22:32:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 074A716A4CE; Wed, 1 Sep 2004 22:32:49 +0000 (GMT) Received: from thunderbird.etv.net (thunderbird.etv.net [208.14.190.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2279543D54; Wed, 1 Sep 2004 22:32:47 +0000 (GMT) (envelope-from lists@efinley.com) Received: from [205.161.203.50] (helo=science1) by thunderbird.etv.net with smtp (Exim 4.34 (FreeBSD)) id 1C2deo-0003gi-86; Wed, 01 Sep 2004 16:32:46 -0600 Message-ID: <003301c49073$9a7871c0$32cba1cd@science1> From: "Elliot Finley" To: "John Baldwin" , References: <015f01c48adf$15029f50$32cba1cd@science1> <200409011556.51722.jhb@FreeBSD.org> Date: Wed, 1 Sep 2004 16:32:45 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Subject: Re: 5.3 Beta1 failed boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Elliot Finley List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 22:32:49 -0000 The problem turned out to be that I had missed an entry in UPDATING. Specifically the entry made on 20040806. After following those instructions, my machine(s) boot fine. Thanks Elliot ----- Original Message ----- From: "John Baldwin" To: ; "Elliot Finley" Sent: Wednesday, September 01, 2004 1:56 PM Subject: Re: 5.3 Beta1 failed boot > On Wednesday 25 August 2004 04:07 pm, Elliot Finley wrote: > > I just moved to 5.3 Beta1 on my ASUS P4P800. (-current as of about 3 weeks > > ago worked fine) > > > > I get the following when trying to boot (copied by hand): > > > > CPU: Intel(R) Pentium(R) 4 CPU 2.60GHz (2598.76-MHz 686-class CPU) > > Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 > > > > Features=0xbfebfbff >A ,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> > > Hyperthreading: 2 logical CPUs > > real memory = 1072889856 (1023 MB) > > avail memory = 1040359424 (992 MB) > > MPTable: > > ioapic0: Assuming intbase of 0 > > ioapic0 irqs 0-23 on motherboard > > npx0: [FAST] > > npx0: on motherboard > > npx0: INT 16 interface > > pcib0: pcibus 0 on motherboard > > pci0: on pcib0 > > agp0: mem 0xf8000000-0xfbffffff at device > > 0.0 on pci0 > > pcib1: at device 1.0 on pci0 > > pci1: on pcib1 > > panic: Multiple entries for PCI IRQ 16 > > cpuid = 0; > > KDB: enter: panic > > [thread 0] > > Stopped at kdb_enter+0x2b: nop > > db> > > > > > > I've tried default, no-acpi, verbose-logging and I get here every time. > > > > What steps can I take to help resolve this? > > Can you provide mptable output? > > -- > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 22:50:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BAC716A4D0 for ; Wed, 1 Sep 2004 22:50:52 +0000 (GMT) Received: from maeko.hayai.de (maeko.hayai.de [217.172.178.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id C564E43D3F for ; Wed, 1 Sep 2004 22:50:51 +0000 (GMT) (envelope-from mail@maeko.hayai.de) Received: from maeko.hayai.de (IDENT:ident@localhost [127.0.0.1]) by maeko.hayai.de (8.12.11/8.12.11) with ESMTP id i81Mon3K031654 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 2 Sep 2004 00:50:50 +0200 Received: (from mail@localhost) by maeko.hayai.de (8.12.11/8.12.11/Submit) id i81ModGg031653; Thu, 2 Sep 2004 00:50:39 +0200 Date: Thu, 2 Sep 2004 00:50:39 +0200 From: Marco Wertejuk To: Ryan Sommers Message-ID: <20040901225038.GA31574@maeko.hayai.de> References: <50241.208.4.77.15.1093981761.squirrel@www2.neuroflux.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50241.208.4.77.15.1093981761.squirrel@www2.neuroflux.com> User-Agent: Mutt/1.5.4i cc: current@freebsd.org Subject: Re: Periodic security X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 22:50:52 -0000 On Tue, Aug 31, 2004 at 01:49:21PM -0600, Ryan Sommers wrote: | Slight modification to the loginfail script for periodics. This will catch | sshd, proftpd and su errors, as well as other programs, better. I think you should file a bug to get this improvement applied. From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 23:03:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41DAD16A4CE; Wed, 1 Sep 2004 23:03:13 +0000 (GMT) Received: from mail.imp.ch (ns1.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DF0443D4C; Wed, 1 Sep 2004 23:03:12 +0000 (GMT) (envelope-from pg@imp.ch) Received: from nbs.imp.ch (nbs.imp.ch [157.161.4.7]) by mail.imp.ch (8.12.9p2/8.12.3) with ESMTP id i81N35q9012951; Thu, 2 Sep 2004 01:03:07 +0200 (CEST) (envelope-from pg@imp.ch) Received: from murphy.imp.ch (murphy.imp.ch [157.161.4.77]) by nbs.imp.ch (8.12.10/8.12.3) with ESMTP id i81N35ir43516478; Thu, 2 Sep 2004 01:03:05 +0200 (MES) Date: Thu, 2 Sep 2004 00:59:07 +0000 (UTC) From: Patrick Guelat X-X-Sender: patg@murphy.imp.ch To: jhb@FreeBSD.org Message-ID: <20040902005757.T45986@murphy.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checksum: 65d1d954f099d1efbe277194812b8a7f X-Virus-Message-Status: No X-Virus-Status: No, scantime="0.0014 seconds" X-Spam-Status: No, hits=-4.9 required=5 scantime="1.3474 seconds" tests=BAYES_00 X-Scanned-By: MIMEDefang 2.44 cc: freebsd-current@FreeBSD.org Subject: Re: Panic in propagate_priority() [5.3-BETA2] (fwd) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 23:03:13 -0000 On Wed, 1 Sep 2004, John Baldwin wrote: > Seems the thread has an inhibitor of TDI_IWAIT which it should never be in > when it gets to this point. Perhaps a lock was leaked from an interrupt > handler. Running with INVARIANTS + WITNESS might help to catch this. > WITNESS especially might help as it would give a warning about what handler > returns with a lock held and which lock and where the lock was acquired. Tried with INVARIANTS and WITNESS .. no lor etc. happening, just the panic in propagate_priority(). This 'rip' lock is used both by netinet and netinet6, might this be a problem in this case ? OSPF6 uses a raw-ip socket to send ipv6 dgrams which are then encapsulated in gif0 in a raw ipv4 packet maybe using the lock twice ? BTW: This was working on 5.2-CURRENT with a kernel from around mid june. -Patrick I wrote: > I'm trying to run OSPF6 on a gif-tunnel between a Cisco-7206VXR > and a box running 5.3-BETA2 and get a panic everytime I start ospf6d (from > /usr/ports/net/quagga). > > It always ends in a panic in propagate_priority(), sometimes I get the > following panic-message: > > panic: process 37 (swi1: net):1 holds rip but isn't blocked on a lock > > "rip" is the lock defined in netinet/raw_ip.c which is also used by > the netinet6/raw_ip6.c. > > Tracing the userland-part nearly always ends at the sendmsg(2) > call on the raw socket, but sometimes the panic also occurs some time before > ospf6d sends it's first hello message (maybe during > the reception of the ipv6 ospf packet from the cisco ?) From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 23:14:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7E7716A4CE for ; Wed, 1 Sep 2004 23:14:59 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id F363A43D31 for ; Wed, 1 Sep 2004 23:14:56 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.201] ([192.168.0.201]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i81NEWuj078920; Wed, 1 Sep 2004 17:14:33 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <41365746.2030605@samsco.org> Date: Wed, 01 Sep 2004 17:12:06 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Marc G. Fournier" References: <20040901151405.G47186@ganymede.hub.org> <20040901200257.GA92717@afields.ca> <20040901184050.J47186@ganymede.hub.org> In-Reply-To: <20040901184050.J47186@ganymede.hub.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Allan Fields cc: freebsd-current@freebsd.org Subject: Re: vnode leak in FFS code ... ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 23:14:59 -0000 Marc G. Fournier wrote: > On Wed, 1 Sep 2004, Allan Fields wrote: > >> On Wed, Sep 01, 2004 at 03:19:27PM -0300, Marc G. Fournier wrote: >> >>> I don't know if this is applicable to -current as well, but so far, >>> anything like this I've uncovered in 4.x has needed an equivalent fix in >>> 5.x, so figured it can't hurt to ask, especially with everyone working >>> towards a STABLE 5.x branch ... I do not have a 5.x machine running this >>> sort of load at the moment, so can't test, or provide feedback there ... >>> all my 5.x machines are more or less desktops ... >>> >>> On Saturday, I'm going to try an unmount of the bigger file system, >>> to see >>> if it frees everything up without a reboot ... but if someone can >>> suggest >>> something to check to see if it is a) a leak and b) is fixable >>> between now >>> and then, please let me know ... again, this is a 4.10 system, but >>> most of >>> the work that Tor and David have done (re: vnodes) in the past >>> relating to >>> my servers have been applied to 5.x first, and MFC'd afterwards, so I >>> suspect that this too many be something that applies to both branches >>> ... >> >> >> Unmounting the filesystems will call vflush() and should flush all >> vnodes from under that mount point. I'm not entirely sure if this >> is the best you can do w/o rebooting. > > > Understood, and agreed ... *but* ... is there a way, before I do that, > of determining if this is something that needs to be fixed at the OS > level? Is there a leak here that I can somehow identify while its in > this state? > > The server has *only* been up 25 days > It's really hard to tell if there is a vnode leak here. The vnode pool is fairly fluid and has nothing to do with the number of files that are actually 'open'. Vnodes get created when the VFS layer wants to access an object that isn't already in the cache, and only get destroyed when the object is destroyed. A vnode that reprents a file that was opened will stay 'active' in the system long after the file has been closed, because it's cheaper to keep it active in the cache than it is to discard it and then risk having to go through the pain of a namei() and VOP_LOOKUP() again later. Only if the maxvnode limit is hit will old vnodes start getting recycled to represent other objects. So in other words, just becuase you open a file and then close it does not mean the the vfs.numvnodes counter will increase by 1 and then decrease by 1. It'll increase by 1 and then stay there until something causes the vnode to be destroyed. Unmounting a filesystem is one way to destroy vnodes, and unlinking files is another was (IIRC, my memory might not be correct here). So you've obviously bumped up kern.maxvnodes well above the limits that are normally generated from the auto-tuner. Why did you do that, if not because you knew that you'd have a large working set of referenced (but maybe not open all at once) filesystem objects? In reality, a number that large is pretty impractical unless you're doing something specialized like a very large (and active) squid cache, or a large NNTP server. In those cases, you'll likely reach the maxvnode limit relatively quickly, after which you'll be relying on the system to do it's best at keeping the cache hot with useful objects. If you don't have a case like that then numvnodes might not ever grow to meet maxvnodes, or will only do so over a good deal of time. Taking 25 days to grow is not terribly unusual if you are serving a large website, fileserver, file-based database, etc. However, for slow-growth cases like this, a large maxvnodes is likely uneeded and is a waste of kernel RAM. If unmounting the filesystem doesn't result in numvnodes decreasing, then there definitely might be a leak. Unfortunately, you haven't provided that kind of information yet. Scott From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 23:38:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FF5F16A4CE for ; Wed, 1 Sep 2004 23:38:18 +0000 (GMT) Received: from reason.levels.unisa.edu.au (reason.levels.unisa.edu.au [130.220.33.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id D697643D2F for ; Wed, 1 Sep 2004 23:38:16 +0000 (GMT) (envelope-from cisbjc@cs.unisa.edu.au) Received: from [192.168.0.55] (cis202068.levels.unisa.edu.au [130.220.37.202]) i81NcEZk020097; Thu, 2 Sep 2004 09:08:14 +0930 (CST) Message-ID: <41365CA5.2000300@cs.unisa.edu.au> Date: Thu, 02 Sep 2004 09:05:01 +0930 From: Benjamin Close User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040819 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Stuyts References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: atacontrol rebuild, how? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 01 Sep 2004 23:38:18 -0000 Perhaps something worth trying is the following - It's what I have to do to get the promisc card I use to rebuild: - Identify the channel the drive is on (ie ad6 on ata3) atacontrol detach ata3 atacontrol attach ata3 atacontrol addspare ar0 ad6 atacontrol rebuild The command exits straight away but if you run: atacontrol status ar0 I get a 'REBUILDING 0%' message Also checking the ps output shows a rebuild thread. Might work, for you. Cheers, Benjamin Ben Stuyts wrote: > Hi, > > I have installed beta-2 (31082004) on a Supermicro 5013C-T (P4SCE > motherboard with ICH5R, and two WD 74 GB Raptor SATA drives, which I > want to mirror). > > I know the ICH5R is not a real raid controller, but I'm trying to get > it to work using atacontrol and the built-in RAID1 support. > > Using the procedure described in > http://www.techno-obscura.com/~delgado/notes/fbsd-ich5SATAraid.html > (thanks!) I managed to get FreeBSD installed on RAID1 on ar0. > > Next I tried to remove a drive (atacontrol detach), and even zeroed > the first area of the disk. After reattaching the drive, I cannot get > atacontrol to rebuild the drive. If I do atacontrol rebuild ar0, it > does absolutely nothing. From browsing this mailing list I see that > this seems to be a problem with using non-raid controllers, but will > this be improved in the future? Or am I doing something wrong? > > What other options do I have? Is geom-vinum ready for this? All I want > is a fully mirrored system (incl root and swap). > > I could put a simple raid controller in, like the Promise S150 TX2Plus > or TX4, but if I can get it to work with the ICH5R controller that > would be great. > > Thanks, > Ben > > _______________________________________________ > 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" -- 3D Research Associate / System Administrator +61 8 8302 3669 School of Computer and Information Science Room D1-07, ML Campus University of South Australia Mawson Lakes Blvd. Benjamin.Close@cs.unisa.edu.au South Australia, 5095 F00D C83D 5F7E 5561 DF91 B74D E602 CAA3 4842 B5B4 From owner-freebsd-current@FreeBSD.ORG Wed Sep 1 23:56:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28FD316A4CE for ; Wed, 1 Sep 2004 23:56:58 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF66843D45 for ; Wed, 1 Sep 2004 23:56:57 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 30548 invoked from network); 1 Sep 2004 23:56:57 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 1 Sep 2004 23:56:57 -0000 Received: from hydrogen.funkthat.com (vkbczg@localhost.funkthat.com [127.0.0.1])i81NutuU087783; Wed, 1 Sep 2004 16:56:56 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i81Nusi7087782; Wed, 1 Sep 2004 16:56:54 -0700 (PDT) Date: Wed, 1 Sep 2004 16:56:54 -0700 From: John-Mark Gurney To: Igor Sysoev Message-ID: <20040901235654.GG29902@funkthat.com> Mail-Followup-To: Igor Sysoev , freebsd-current@freebsd.org References: <20040901144705.K97970@is.park.rambler.ru> <20040901155304.GD29902@funkthat.com> <20040901173757.GF29902@funkthat.com> <20040901224828.Q97970@is.park.rambler.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040901224828.Q97970@is.park.rambler.ru> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-current@freebsd.org Subject: Re: panic caused by EVFILT_SIGNAL detaching in rfork()ed thread X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2004 23:56:58 -0000 Igor Sysoev wrote this message on Wed, Sep 01, 2004 at 23:07 +0400: > On Wed, 1 Sep 2004, John-Mark Gurney wrote: > > > > > The problem is some how that the knote is being removed from the list > > > > (or was never on the list), but not being marked detached... > > > > > > > > Hmmm. what are the options you are using for rfork? > > > > > > The worker process starts two worker threads created by > > > rfork(RFPROC|RFTHREAD|RFMEM). Each thread opens kqueue and > > > adds the EVFILT_SIGNAL event. > > > > > > If you like I can send to you the source tarball (I do not distribute > > > the server right now, because it has not the documentation). The build > > > process is simple. Then you need to press ^C and you will get the panic. > > > > I believe this panic may be possible w/o rfork, but I'm not possitive.. > > It's probably an artifact of the fact that the kq was living longer > > than the proc that had the signal kevent associated with it, which > > normally does not happen... > > > > Attached is a patch.. And let me know if it fixes your panic... > > The patch fixed the panic (I tested on 5.3-BETA2, GENERIC, SMP, HTT, > SCHED_ULE). Thank you. Could you make the similar patch for 4.x ? I'm not familar enough with kqueue in 4.x, so I would just add a similar if (kn->kn_status & KN_DETACHED) return; to the filt_sigdetach function like the other detach functions... > And one more, could you rename http://people.freebsd.org/~jmg/kqueue.man.html > into kqueue_preliminary.man.html and place a modern (or at least from > 4.1-RELEASE) kqueue man page in kqueue.man.html ? Google shows your > man page at first position and it confuses people. I saw several times > when people said that kqueue has the incompatible interface between BSDs > and even between various FreeBSD verisons referring to this man page. I've renamed it, but I will send admins an email to try to add a redirect so that broken links won't plauge the net... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 00:08:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D099F16A4CE for ; Thu, 2 Sep 2004 00:08:19 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1B9D643D2F for ; Thu, 2 Sep 2004 00:08:19 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 99112 invoked from network); 2 Sep 2004 00:05:59 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Sep 2004 00:05:59 -0000 Message-ID: <4136646F.1010207@freebsd.org> Date: Thu, 02 Sep 2004 02:08:15 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave McCammon References: <20040901164100.47063.qmail@web41414.mail.yahoo.com> In-Reply-To: <20040901164100.47063.qmail@web41414.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: 5.3 Beta2 bridging (update 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 00:08:19 -0000 Dave McCammon wrote: > Got the bridging to work after cvsup yesterday(I think > it was the rebuild but not for sure). > > em0 - has ip > em1 - no ip > > Anyway, with both cables plugged in, traffic passes > through the box. Weird thing is, the box can't get to > (ssh, ping) other machines on the em1 side but can get > to machines on the em0 side. > Machines on the em1 side can get to machines on the > em0 side. Machines on the em0 side can get to machines > on the em1 side and can get to the bridging box. > > Ok, I just went and plugged the cables back in(removed > them last night) and traffic didn't get through. I'm > now wondering if it isn't something to do with the em > driver. > This is completely confusing. > I built a different kernel to test bridging without > ipfw. Bridging kernels with and without ipfw worked > last night. Now nothing. > > Ok, after some more fiddling around, what needs to > happen is that em1 can't be plugged in until the > machine has come up(with em0 plugged in). > After that, traffic passes as stated above. Which > doesn't bode well if machine gets rebooted. This seems to be some sort of problem within the bridging code and learning of MAC address maybe. I don't know the bridge code well enough to help you on the spot and I have too much things on my TODO to go in there. You should ask luigi@freebsd.org what to do. He is the author of this code. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 00:08:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6139016A4CE for ; Thu, 2 Sep 2004 00:08:48 +0000 (GMT) Received: from web41414.mail.yahoo.com (web41414.mail.yahoo.com [66.218.93.80]) by mx1.FreeBSD.org (Postfix) with SMTP id 3F1E343D2D for ; Thu, 2 Sep 2004 00:08:48 +0000 (GMT) (envelope-from davemac11@yahoo.com) Message-ID: <20040902000848.32670.qmail@web41414.mail.yahoo.com> Received: from [168.91.4.66] by web41414.mail.yahoo.com via HTTP; Wed, 01 Sep 2004 17:08:48 PDT Date: Wed, 1 Sep 2004 17:08:48 -0700 (PDT) From: Dave McCammon To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: pccard not working on 5.3 beta2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 00:08:48 -0000 I got a 3com 3c575b pccard that used to work on 5.2.1-release-p9 but doesn't on 5.3-beta2. I've got in /boot/loader.conf hw.cbb.debug=1 bw.cardbus.debug=1 Any and all help is greatly appreciated 5.3 Beta2 dmesg.boot below Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 2 0 0 done No buffers busy after final sync Uptime: 28m53s cbb1: cbb_power: 0V cbb1: bad Vcc request. ctrl=0x7720700, status=0x7730775 cbb_power: 0V Rebooting... Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-BETA2 #0: Tue Aug 31 10:54:22 EST 2004 root@ion:/usr/obj/usr/src/sys/GREY Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium/P55C (quarter-micron) (199.31-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x581 Stepping = 1 Features=0x8001bf real memory = 67108864 (64 MB) avail memory = 60239872 (57 MB) Intel Pentium detected, installing workaround for F00F bug npx0: [FAST] npx0: on motherboard npx0: INT 16 interface apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 isab0: at device 1.0 on pci0 isa0: on isab0 atapci0: port 0xfcf0-0xfcff,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 1.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: port 0xfcc0-0xfcdf at device 1.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: at device 1.3 (no driver attached) pci0: at device 2.0 (no driver attached) cbb0: at device 4.0 on pci0 cbb0: Found memory at 00000000 cbb0: Secondary bus is 0 cbb0: Secondary bus set to 2 subbus 3 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: cbb_power: 0V cbb0: bad Vcc request. ctrl=0xf000ff00, status=0xf000e2c3 cbb_power: 0V cbb1: at device 4.1 on pci0 cbb1: Found memory at 00001000 cbb1: Secondary bus is 0 cbb1: Secondary bus set to 4 subbus 5 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: cbb_power: 0V cpu0 on motherboard orm0: at iomem 0xc0000-0xcbfff on isa0 pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] Unsupported (pre-v4) Touchpad detected psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/7 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (port) Timecounters tick every 10.000 msec Interrupt storm detected on "irq10: uhci0"; throttling interrupt source Status is 0xf000e2c3 Status is 0x200020 cbb1: card inserted: event=0x07b30020, state=00200020 cbb1: Unknown card voltage cbb1: CardBus card activation failed ad0: 2067MB [4200/16/63] at ata0-master WDMA2 ATAPI_RESET time = 10us acd0: CDROM at ata1-master PIO4 Mounting root from ufs:/dev/ad0s1a __________________________________ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 00:33:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E323016A4CE; Thu, 2 Sep 2004 00:33:20 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FEBC43D39; Thu, 2 Sep 2004 00:33:20 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.10/8.12.10) with ESMTP id i820XJJt009632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Sep 2004 20:33:19 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id i820XEGE043865; Wed, 1 Sep 2004 20:33:14 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16694.27210.415965.951382@grasshopper.cs.duke.edu> Date: Wed, 1 Sep 2004 20:33:14 -0400 (EDT) To: John Baldwin In-Reply-To: <200409011632.59507.jhb@FreeBSD.org> References: <412FB9FC.8030505@root.org> <200409011632.59507.jhb@FreeBSD.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: freebsd-current@FreeBSD.org Subject: Re: spurrious interrupt problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 00:33:21 -0000 John Baldwin writes: > On Friday 27 August 2004 06:47 pm, Nate Lawson wrote: > > I don't see anything wrong with your acpi pci link routing. In fact, > > all your irqs are hardwired meaning acpi shouldn't touch them. This > > must be something with ioapic. (BTW, acpi is non-optional on amd64). > > Talk to phk@. He had an opteron motherboard that had a busted BIOS that left > the links between PCI IRQs that are used in atpic mode setup even when in > apic mode so that you get 'alias' IRQs in apic mode. In his case the vendor > provided a BIOS update that fixed the issue. I had our onsite guy update the bios, but that ended up disabling USB. So its "fixed".. ;) Drew From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 00:51:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9405B16A4CE for ; Thu, 2 Sep 2004 00:51:21 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD56543D41 for ; Thu, 2 Sep 2004 00:51:20 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 99405 invoked from network); 2 Sep 2004 00:49:00 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Sep 2004 00:49:00 -0000 Message-ID: <41366E85.6030302@freebsd.org> Date: Thu, 02 Sep 2004 02:51:17 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave McCammon References: <20040901164100.47063.qmail@web41414.mail.yahoo.com> In-Reply-To: <20040901164100.47063.qmail@web41414.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: 5.3 Beta2 bridging (update 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 00:51:21 -0000 Dave McCammon wrote: > Got the bridging to work after cvsup yesterday(I think > it was the rebuild but not for sure). > > em0 - has ip > em1 - no ip > > Anyway, with both cables plugged in, traffic passes > through the box. Weird thing is, the box can't get to > (ssh, ping) other machines on the em1 side but can get > to machines on the em0 side. > Machines on the em1 side can get to machines on the > em0 side. Machines on the em0 side can get to machines > on the em1 side and can get to the bridging box. > > Ok, I just went and plugged the cables back in(removed > them last night) and traffic didn't get through. I'm > now wondering if it isn't something to do with the em > driver. > This is completely confusing. > I built a different kernel to test bridging without > ipfw. Bridging kernels with and without ipfw worked > last night. Now nothing. > > Ok, after some more fiddling around, what needs to > happen is that em1 can't be plugged in until the > machine has come up(with em0 plugged in). > After that, traffic passes as stated above. Which > doesn't bode well if machine gets rebooted. You might be lucky here. About two hours ago pdeuskar committed some fixes to the 'em' driver including one talking about bridging problems. Try to pull the changes to sys/dev/em/if_em* into your 5.3-BETA2 tree. -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 01:35:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E265E16A4CE for ; Thu, 2 Sep 2004 01:35:34 +0000 (GMT) Received: from afields.ca (afields.ca [216.194.67.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id A33B443D45 for ; Thu, 2 Sep 2004 01:35:34 +0000 (GMT) (envelope-from afields@afields.ca) Received: from afields.ca (localhost.afields.ca [127.0.0.1]) by afields.ca (8.12.11/8.12.11) with ESMTP id i821ZYqO094811 for ; Wed, 1 Sep 2004 21:35:34 -0400 (EDT) (envelope-from afields@afields.ca) Received: (from afields@localhost) by afields.ca (8.12.11/8.12.11/Submit) id i821ZYUC094810 for freebsd-current@freebsd.org; Wed, 1 Sep 2004 21:35:34 -0400 (EDT) (envelope-from afields) Date: Wed, 1 Sep 2004 21:35:34 -0400 From: Allan Fields To: freebsd-current@freebsd.org Message-ID: <20040902013534.GD9327@afields.ca> References: <20040901151405.G47186@ganymede.hub.org> <20040901200257.GA92717@afields.ca> <20040901184050.J47186@ganymede.hub.org> <41365746.2030605@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41365746.2030605@samsco.org> User-Agent: Mutt/1.4i Subject: Re: vnode leak in FFS code ... ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 01:35:35 -0000 On Wed, Sep 01, 2004 at 05:12:06PM -0600, Scott Long wrote: > Marc G. Fournier wrote: > >On Wed, 1 Sep 2004, Allan Fields wrote: > > > >>On Wed, Sep 01, 2004 at 03:19:27PM -0300, Marc G. Fournier wrote: > >> > >>>I don't know if this is applicable to -current as well, but so far, > >>>anything like this I've uncovered in 4.x has needed an equivalent fix in > >>>5.x, so figured it can't hurt to ask, especially with everyone working > >>>towards a STABLE 5.x branch ... I do not have a 5.x machine running this > >>>sort of load at the moment, so can't test, or provide feedback there ... > >>>all my 5.x machines are more or less desktops ... > >>> > >>>On Saturday, I'm going to try an unmount of the bigger file system, > >>>to see > >>>if it frees everything up without a reboot ... but if someone can > >>>suggest > >>>something to check to see if it is a) a leak and b) is fixable > >>>between now > >>>and then, please let me know ... again, this is a 4.10 system, but > >>>most of > >>>the work that Tor and David have done (re: vnodes) in the past > >>>relating to > >>>my servers have been applied to 5.x first, and MFC'd afterwards, so I > >>>suspect that this too many be something that applies to both branches > >>>... > >> > >> > >>Unmounting the filesystems will call vflush() and should flush all > >>vnodes from under that mount point. I'm not entirely sure if this > >>is the best you can do w/o rebooting. > > > > > >Understood, and agreed ... *but* ... is there a way, before I do that, > >of determining if this is something that needs to be fixed at the OS > >level? Is there a leak here that I can somehow identify while its in > >this state? > > > >The server has *only* been up 25 days > > > > It's really hard to tell if there is a vnode leak here. The vnode pool > is fairly fluid and has nothing to do with the number of files that are > actually 'open'. Vnodes get created when the VFS layer wants to access > an object that isn't already in the cache, and only get destroyed when > the object is destroyed. A vnode that reprents a file that was opened > will stay 'active' in the system long after the file has been closed, > because it's cheaper to keep it active in the cache than it is to > discard it and then risk having to go through the pain of a namei() > and VOP_LOOKUP() again later. Only if the maxvnode limit is hit will > old vnodes start getting recycled to represent other objects. [...] > > So you've obviously bumped up kern.maxvnodes well above the limits that > are normally generated from the auto-tuner. Why did you do that, if not > because you knew that you'd have a large working set of referenced (but > maybe not open all at once) filesystem objects? [...] There was a pevious thread I've found which also helps explains this further: http://lists.freebsd.org/pipermail/freebsd-stable/2003-May/001266.html Really the same issue now as then? > If unmounting the filesystem doesn't result in numvnodes decreasing, > then there definitely might be a leak. Unfortunately, you haven't > provided that kind of information yet. > > Scott -- Allan Fields, AFRSL - http://afields.ca 2D4F 6806 D307 0889 6125 C31D F745 0D72 39B4 5541 From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 01:38:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF2BC16A4CE for ; Thu, 2 Sep 2004 01:38:06 +0000 (GMT) Received: from sam.stral.net (sam.stral.net [61.14.141.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF74243D5D for ; Thu, 2 Sep 2004 01:38:05 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from localhost.localdomain ([127.0.0.1] helo=webmail.bensley.net) by sam.stral.net with esmtp (Exim 3.36 #1 (Debian)) id 1C1w2b-000863-00; Tue, 31 Aug 2004 09:58:25 +1000 Received: from 134.148.20.1 (proxying for 134.148.100.153) (SquirrelMail authenticated user sam); by webmail.bensley.net with HTTP; Tue, 31 Aug 2004 09:58:25 +1000 (EST) Message-ID: <57506.134.148.20.1.1093910305.squirrel@134.148.20.1> In-Reply-To: <20040831011815.C40736-100000@electra.nolink.net> References: <20040830210817.GB749@galgenberg.net> <20040831011815.C40736-100000@electra.nolink.net> Date: Tue, 31 Aug 2004 09:58:25 +1000 (EST) From: "Sam Lawrance" To: "Lars Erik Gullerud" User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal cc: "freebsd-current@freebsd.org" Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 01:38:06 -0000 > On Mon, 30 Aug 2004, Ulrich Spoerlein wrote: > >> On Mon, 30.08.2004 at 09:31:06 -0700, David O'Brien wrote: >> > > mergemasters is gross. Have you ever tried to run it on an >> 80-column display? >> > > I absolutely hate the "left" "right" stuff. You push the "l" with >> your right >> > > hand and the "r" with your left for crying out loud. >> > >> > LOL!! >> >> This is not funny. I myself have to think loud about which button to >> press. 'r' is on the left keyboard side and 'l' is to the right. > > I second the "don't laugh" - you have no idea how many times I have to > select "redo the merge" when upgrading servers usually during a > late-night maintenance window, with a brain only functioning due to > large amounts of caffeine in the bloodstream... > > (Not that I have any suggestions for other keys to use, mind you - but > the mind's wiring does have a problem with getting used to pressing a > key with the left hand to select the right side of the screen and > vice versa...) I think it would be nice if the 'merge then edit' command merged entire files at once instead of just parts, cvs conflict style. From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 01:49:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FF2216A4CE for ; Thu, 2 Sep 2004 01:49:39 +0000 (GMT) Received: from hotmail.com (bay8-f93.bay8.hotmail.com [64.4.27.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 36B4A43D58 for ; Thu, 2 Sep 2004 01:49:39 +0000 (GMT) (envelope-from evantd@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 1 Sep 2004 18:49:38 -0700 Received: from 67.171.32.75 by by8fd.bay8.hotmail.msn.com with HTTP; Thu, 02 Sep 2004 01:49:38 GMT X-Originating-IP: [67.171.32.75] X-Originating-Email: [evantd@hotmail.com] X-Sender: evantd@hotmail.com From: "Evan Dower" To: bettan@nerim.net Date: Wed, 01 Sep 2004 18:49:38 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Sep 2004 01:49:38.0972 (UTC) FILETIME=[1B8635C0:01C4908F] cc: freebsd-current@freebsd.org Subject: Re: netgear wg311 v2 and configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 01:49:39 -0000 You may very well be able to. I have no idea whether setting "mediaopt hostap" will work. I have no experience with it. I do know that you cannot set "mode 11g", but that there is no need, because it will automatically associate at the highest speed it can. Since it is not a native driver, things may not work exactly as expected. You should have several sysctls to play with, and you may need to use these instead of doing things the normal way. I really have no idea. The expert would be Bill Paul (wpaul), since he just recently added the support for this card. Perhaps he'll chime in... Sorry I couldn't be of more assistance, -- Evan Dower Undergraduate, Computer Science University of Washington Public key: http://students.washington.edu/evantd/pgp-pub-key.txt Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D >From: "bettan" >To: "Evan Dower" >Subject: Re: netgear wg311 v2 and configuration >Date: Wed, 1 Sep 2004 22:52:09 +0200 > >I can't do an access point with this card ? >----- Original Message ----- >From: "Evan Dower" >To: ; >Sent: Wednesday, September 01, 2004 10:36 PM >Subject: RE: netgear wg311 v2 and configuration > > > > I don't believe there is any need to specify the media (or mode for that > > matter). It will simply go as fast as it can. Furthermore, setting the > > stationname is still unsupported and will fail. > > Cheers, > > -- > > Evan Dower > > Undergraduate, Computer Science > > University of Washington > > Public key: http://students.washington.edu/evantd/pgp-pub-key.txt > > Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D > > > > > > > > > > > > >From: "bettan" > > >To: > > >Subject: netgear wg311 v2 and configuration > > >Date: Wed, 1 Sep 2004 21:10:32 +0200 > > > > > >hello , i tried to configure my wireless card and when i do : > > >ifconfig ndis0 ssid linux-win.com channel 11 media DS/54Mbps mediaopt > > >hostap up stationname "FreeBSD AP" > > > > > >I have : ifconfig: unknown media subtype: DS/54Mbps > > > > > > and i don't understand why.FreeBSD supports 54 Mbps no ? Have you a > > >solution ? > > >_______________________________________________ > > >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" > > > > _________________________________________________________________ > > Express yourself instantly with MSN Messenger! Download today - it's >FREE! > > hthttp://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > > _________________________________________________________________ Don’t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 01:56:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DDAC16A4D0 for ; Thu, 2 Sep 2004 01:56:24 +0000 (GMT) Received: from Tserver.TrueStep.com (Tserver.TrueStep.com [64.253.96.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6180343D31 for ; Thu, 2 Sep 2004 01:56:19 +0000 (GMT) (envelope-from rorya@TrueStep.com) Received: from [10.101.1.4] (Yosemite.lan [10.101.1.4])i821uDqH000399 for ; Wed, 1 Sep 2004 21:56:14 -0400 (EDT) (envelope-from rorya@TrueStep.com) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <4473E94E-FC83-11D8-81BE-0005028F6AEB@TrueStep.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-current@freebsd.org From: Rory Arms Date: Wed, 1 Sep 2004 21:56:12 -0400 X-Mailer: Apple Mail (2.619) X-Spam-Status: No, hits=0.3 required=4.0 tests=UPPERCASE_25_50 autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on Tserver.TrueStep.com Subject: [BETA2 panic] _mtx_lock_sleep: recursed on non-recursive mutex sbc0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 01:56:24 -0000 As soon as I try to use the sound card, the system panics. This is with 5.3-BETA2. Everything used to work fine with a -CURRENT from mid June. Also, worth noting, I'm unable to boot the kernel w/o ACPI. This one has been blacklisted (though it is the latest BIOS), so I have to add a directive in /boot/loader.conf to force it to use ACPI, it's the only way it will boot now. This is a Dual 333 Mhz Tyan S1836 (Thunder 100), with 256 MB of RAM. The onboard sound is an ISA, on-board Sound Blaster Vibra 16 chipset. Here's the backtrace, using a core file. I had to use kgdb(1), since gdb(1) complained the -k flag is not valid. I suppose this is a change in the new version of GDB: Neutron> cd /usr/obj/usr/src/sys/NEUTRON/ Neutron> sudo kgdb kernel.debug /usr/local/crash/vmcore.0 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". doadump () at pcpu.h:159 (kgdb) bt #0 doadump () at pcpu.h:159 #1 0xc04f8182 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:396 #2 0xc04f8570 in panic ( fmt=0xc06c317d "_mtx_lock_sleep: recursed on non-recursive mutex %s @ %s:%d\n") at /usr/src/sys/kern/kern_shutdown.c:558 #3 0xc04ee484 in _mtx_lock_sleep (m=0xc164ce80, td=0xc178f000, opts=0, file=0x0, line=0) at /usr/src/sys/kern/kern_mutex.c:446 #4 0xc04ee080 in _mtx_lock_flags (m=0xc164ce80, opts=0, file=0xc08046a8 "/usr/src/sys/modules/sound/driver/sbc/../../../../dev/sound/isa/ sbc.c", line=131) at /usr/src/sys/kern/kern_mutex.c:263 #5 0xc080346c in ?? () #6 0xc164ce80 in ?? () #7 0x00000000 in ?? () #8 0xc08046a8 in ?? () #9 0x00000083 in ?? () #10 0xd179ba94 in ?? () #11 0xc07fe4cc in ?? () #12 0xc1655900 in ?? () #13 0xd179bab0 in ?? () #14 0xc07fe6ee in ?? () #15 0xc1655700 in ?? () #16 0xd179bab0 in ?? () #17 0xc165572c in ?? () ---Type to continue, or q to quit--- #18 0xc1655700 in ?? () #19 0x0000007f in ?? () #20 0xd179bad0 in ?? () #21 0xc07ff35a in ?? () #22 0xc1655700 in ?? () #23 0x00000000 in ?? () #24 0x0000007f in ?? () #25 0xc1655700 in ?? () #26 0x00000000 in ?? () #27 0xc165572c in ?? () #28 0xd179bae4 in ?? () #29 0xc07ff555 in ?? () #30 0xc1655700 in ?? () #31 0xc1652530 in ?? () #32 0x00000001 in ?? () #33 0xd179bb08 in ?? () #34 0xc0813e8a in ?? () #35 0xc1652530 in ?? () #36 0xc165572c in ?? () #37 0x00000001 in ?? () #38 0x00000465 in ?? () #39 0xc1655580 in ?? () #40 0x00001000 in ?? () ---Type to continue, or q to quit--- #41 0xc15ad400 in ?? () #42 0xd179bb2c in ?? () #43 0xc08128d7 in ?? () #44 0xc1655580 in ?? () #45 0x00000001 in ?? () #46 0xc081e068 in ?? () #47 0x00000207 in ?? () #48 0x00000000 in ?? () #49 0x00001000 in ?? () #50 0x00000000 in ?? () #51 0xd179bb58 in ?? () #52 0xc08121ee in ?? () #53 0xc1655580 in ?? () #54 0x00000000 in ?? () #55 0x00001000 in ?? () #56 0x0000014f in ?? () #57 0xc15ade00 in ?? () #58 0x00000064 in ?? () #59 0xc177e94c in ?? () #60 0xc1667900 in ?? () #61 0xc081fc60 in ?? () #62 0xd179bb80 in ?? () #63 0xc08150e5 in ?? () ---Type to continue, or q to quit--- #64 0xc1655580 in ?? () #65 0xd179bc80 in ?? () #66 0xd179bb74 in ?? () #67 0x20000000 in ?? () #68 0x00000000 in ?? () #69 0xc1655580 in ?? () #70 0xc177e94c in ?? () #71 0xc1667900 in ?? () #72 0xd179bbd0 in ?? () #73 0xc04b6db0 in spec_write (ap=0xc1655900) at /usr/src/sys/fs/specfs/spec_vnops.c:317 Previous frame inner to this frame (corrupt stack?) (kgdb) Neutron> uname -a FreeBSD Neutron.lan 5.3-BETA2 FreeBSD 5.3-BETA2 #1: Wed Sep 1 18:16:25 EDT 2004 Neutron> pciconf -l agp0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x71a08086 rev=0x00 hdr=0x00 pcib1@pci0:1:0: class=0x060400 card=0x00000000 chip=0x71a18086 rev=0x00 hdr=0x01 isab0@pci0:7:0: class=0x060100 card=0x00000000 chip=0x71108086 rev=0x02 hdr=0x00 none0@pci0:7:1: class=0x010180 card=0x00000000 chip=0x71118086 rev=0x01 hdr=0x00 uhci0@pci0:7:2: class=0x0c0300 card=0x00000000 chip=0x71128086 rev=0x01 hdr=0x00 none1@pci0:7:3: class=0x068000 card=0x00000000 chip=0x71138086 rev=0x02 hdr=0x00 pcib2@pci0:16:0: class=0x060400 card=0x000000dc chip=0x00241011 rev=0x03 hdr=0x01 fxp0@pci0:17:0: class=0x020000 card=0x00088086 chip=0x12298086 rev=0x05 hdr=0x00 ahc0@pci0:18:0: class=0x010000 card=0x78959004 chip=0x78959004 rev=0x04 hdr=0x00 ahc1@pci0:18:1: class=0x010000 card=0x78959004 chip=0x78959004 rev=0x04 hdr=0x00 none2@pci1:0:0: class=0x030000 card=0x00611002 chip=0x47421002 rev=0x5c hdr=0x00 bktr0@pci2:4:0: class=0x040000 card=0x00000000 chip=0x0350109e rev=0x11 hdr=0x00 Neutron> sudo mptable Password: ======================================================================== ======= MPTable, version 2.0.15 ------------------------------------------------------------------------ ------- MP Floating Pointer Structure: location: BIOS physical address: 0x000fb470 signature: '_MP_' length: 16 bytes version: 1.4 checksum: 0x5b mode: Virtual Wire ------------------------------------------------------------------------ ------- MP Config Table Header: physical address: 0x000f66d0 signature: 'PCMP' base table length: 308 version: 1.4 checksum: 0x89 OEM ID: 'INTEL ' Product ID: '440GX ' OEM table pointer: 0x00000000 OEM table size: 0 entry count: 30 local APIC address: 0xfee00000 extended table length: 24 extended table checksum: 94 ------------------------------------------------------------------------ ------- MP Config Base Table Entries: -- Processors: APIC ID Version State Family Model Step Flags 0 0x11 BSP, usable 6 3 3 0x80fbff 1 0x11 AP, usable 6 3 3 0x80fbff -- Bus: Bus ID Type 0 PCI 1 PCI 2 PCI 3 ISA -- I/O APICs: APIC ID Version State Address 2 0x11 usable 0xfec00000 -- I/O Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT conforms conforms 3 0 2 0 INT conforms conforms 3 1 2 1 INT conforms conforms 3 0 2 2 INT conforms conforms 3 3 2 3 INT conforms conforms 3 4 2 4 INT conforms conforms 3 5 2 5 INT conforms conforms 3 6 2 6 INT conforms conforms 3 7 2 7 INT active-hi edge 3 8 2 8 INT conforms conforms 3 9 2 9 INT conforms conforms 3 12 2 12 INT conforms conforms 3 13 2 13 INT conforms conforms 3 14 2 14 INT conforms conforms 3 15 2 15 INT active-lo level 2 4:A 2 16 INT active-lo level 1 0:A 2 16 INT active-lo level 0 18:B 2 16 INT active-lo level 0 18:A 2 16 INT active-lo level 0 17:A 2 19 INT active-lo level 0 7:D 2 19 SMI conforms conforms 3 0 2 23 -- Local Ints: Type Polarity Trigger Bus ID IRQ APIC ID PIN# ExtINT conforms conforms 0 0:A 255 0 NMI conforms conforms 0 0:A 255 1 ------------------------------------------------------------------------ ------- MP Config Extended Table Entries: Extended Table HOSED! Neutron> dmesg Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.3-BETA2 #1: Wed Sep 1 18:16:25 EDT 2004 root:/usr/obj/usr/src/sys/NEUTRON WARNING: WITNESS option enabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Pentium II/Pentium II Xeon/Celeron (150.02-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x633 Stepping = 3 Features=0x80fbff real memory = 268304384 (255 MB) avail memory = 252882944 (241 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 irqs 0-23 on motherboard bktr_mem: memory holder loaded npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 20 acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 cpu1: on acpi0 cpu1: Failed to attach throttling P_CNT pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xf8000000-0xfbffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at device 7.1 (no driver attached) uhci0: port 0xef80-0xef9f irq 19 at device 7.2 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Microsoft Microsoft IntelliMouse\M-. Explorer, rev 1.10/1.07, addr 2, iclass 3/1 ums0: 5 buttons and Z dir. pci0: at device 7.3 (no driver attached) pcib2: at device 16.0 on pci0 pci2: on pcib2 bktr0: mem 0xf43ff000-0xf43fffff irq 16 at device 4.0 on pci2 bktr0: [GIANT-LOCKED] bktr0: Hauppauge Model 56131 E bktr0: Hauppauge WinCast/TV, Philips FR1236 NTSC FM tuner, dbx stereo. fxp0: port 0xef40-0xef5f mem 0xfea00000-0xfeafffff,0xfc4ff000-0xfc4fffff irq 19 at device 17.0 on pci0 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:e0:81:10:29:4f fxp0: [GIANT-LOCKED] ahc0: port 0xe400-0xe4ff mem 0xfebfe000-0xfebfefff irq 16 at device 18.0 on pci0 ahc0: [GIANT-LOCKED] aic7895C: Ultra Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: port 0xe800-0xe8ff mem 0xfebff000-0xfebfffff irq 16 at device 18.1 on pci0 ahc1: [GIANT-LOCKED] aic7895C: Ultra Wide Channel B, SCSI Id=7, 32/253 SCBs acpi_button0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 fdc0: port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3 irq 6 drq 2 on acpi0 fdc0: ready for input in output fdc0: cmd 3 failed at out byte 1 of 3 device_attach: fdc0 attach returned 6 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A fdc0: port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3 irq 6 drq 2 on acpi0 fdc0: ready for input in output fdc0: cmd 3 failed at out byte 1 of 3 device_attach: fdc0 attach returned 6 pmtimer0 on isa0 orm0: at iomem 0xcc000-0xd07ff,0xc0000-0xcbfff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=0x200> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sbc0: at port 0x388-0x38b,0x330-0x331,0x220-0x22f irq 5 drq 3,1 on isa0 sbc0: [GIANT-LOCKED] pcm0: on sbc0 pcm0: [GIANT-LOCKED] Timecounters tick every 10.000 msec Waiting 15 seconds for SCSI devices to settle acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% da0 at ahc0 bus 0 target 5 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 8669MB (17755614 512 byte sectors: 255H 63S/T 1105C) da1 at ahc1 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 8748MB (17916240 512 byte sectors: 255H 63S/T 1115C) SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/da0s1a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted ahc0: Recovery Initiated >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahc0: Dumping Card State while idle, at SEQADDR 0x7 Card was paused ACCUM = 0xc6, SINDEX = 0x42, DINDEX = 0xe4, ARG_2 = 0x0 HCNT = 0x0 SCBPTR = 0x1f SCSISIGI[0x0] ERROR[0x0] SCSIBUSL[0x0] LASTPHASE[0x1]:(P_BUSFREE) SCSISEQ[0x12]:(ENAUTOATNP|ENRSELI) SBLKCTL[0x2]:(SELWIDE) SCSIRATE[0x0] SEQCTL[0x10]:(FASTMODE) SEQ_FLAGS[0xc0]:(NO_CDB_SENT|NOT_IDENTIFIED) SSTAT0[0x5]:(DMADONE|SDONE) SSTAT1[0xa]:(PHASECHG|BUSFREE) SSTAT2[0x0] SSTAT3[0x0] SIMODE0[0x0] SIMODE1[0xa4]:(ENSCSIPERR|ENSCSIRST|ENSELTIMO) SXFRCTL0[0x80]:(DFON) DFCNTRL[0x0] DFSTATUS[0x2d]:(FIFOEMP|DFTHRESH|HDONE|FIFOQWDEMP) STACK: 0x0 0x15a 0xff 0x3 SCB count = 130 Kernel NEXTQSCB = 122 Card NEXTQSCB = 122 QINFIFO entries: Waiting Queue entries: Disconnected Queue entries: 30:36 29:37 28:38 27:39 26:20 25:21 16:22 15:23 23:5 14:12 13:18 11:9 12:10 2:25 4:8 18:6 10:3 6:24 1:19 3:15 19:4 8:26 17:28 9:17 0:27 24:16 22:2 20:13 7:0 5:11 21:1 QOUTFIFO entries: Sequencer Free SCB List: 31 Sequencer SCB Info: 0 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x1b] 1 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x13] 2 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x19] 3 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0xf] 4 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x8] 5 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0xb] 6 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x18] 7 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x0] 8 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x1a] 9 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x11] 10 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x3] 11 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x9] 12 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0xa] 13 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x12] 14 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0xc] 15 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x17] 16 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x16] 17 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x1c] 18 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x6] 19 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x4] 20 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0xd] 21 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x1] 22 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x2] 23 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x5] 24 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x10] 25 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x15] 26 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x14] 27 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x27] 28 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x26] 29 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x25] 30 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x24] 31 SCB_CONTROL[0xe0]:(TAG_ENB|DISCENB|TARGET_SCB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0xff] Pending list: 67 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 68 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 69 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 50 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 51 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 52 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 53 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 54 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 55 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 56 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 57 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 58 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 59 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 40 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 41 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 42 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 43 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 44 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 45 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 46 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 47 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 48 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 14 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 49 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 30 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 31 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 32 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 33 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 34 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 35 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 36 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 37 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 38 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 39 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 20 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 21 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 22 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 23 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 5 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 12 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 18 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 9 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 10 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 25 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 8 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 6 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 3 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 24 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 19 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 15 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 4 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 26 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 28 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 17 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 27 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 16 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 2 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 13 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 0 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 11 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 1 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] Kernel Free SCB list: 66 123 124 125 126 127 128 129 110 111 112 113 114 115 116 117 118 119 100 101 102 103 104 105 106 107 108 109 90 91 92 93 94 7 95 96 97 98 99 80 81 82 83 84 85 86 87 88 89 70 29 71 72 73 74 75 76 77 78 79 60 61 62 63 64 65 121 120 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> (da0:ahc0:0:5:0): SCB 0x1e - timed out sg[0] - Addr 0xbb87000 : Length 4096 sg[1] - Addr 0xbc08000 : Length 4096 sg[2] - Addr 0xbb89000 : Length 4096 sg[3] - Addr 0xba2a000 : Length 4096 (da0:ahc0:0:5:0): Queuing a BDR SCB (da0:ahc0:0:5:0): Bus Device Reset Message Sent ahc0: Recovery Initiated >>>>>>>>>>>>>>>>>> Dump Card State Begins <<<<<<<<<<<<<<<<< ahc0: Dumping Card State in Message-out phase, at SEQADDR 0x162 Card was paused ACCUM = 0xa0, SINDEX = 0x61, DINDEX = 0xe4, ARG_2 = 0x7 HCNT = 0x0 SCBPTR = 0x1f SCSISIGI[0x0] ERROR[0x0] SCSIBUSL[0x0] LASTPHASE[0xa0]:(MSGI|CDI) SCSISEQ[0x12]:(ENAUTOATNP|ENRSELI) SBLKCTL[0x2]:(SELWIDE) SCSIRATE[0xf]:(SXFR_ULTRA2) SEQCTL[0x10]:(FASTMODE) SEQ_FLAGS[0x40]:(NO_CDB_SENT) SSTAT0[0x5]:(DMADONE|SDONE) SSTAT1[0xa]:(PHASECHG|BUSFREE) SSTAT2[0x0] SSTAT3[0x0] SIMODE0[0x0] SIMODE1[0xac]:(ENSCSIPERR|ENBUSFREE|ENSCSIRST|ENSELTIMO) SXFRCTL0[0x88]:(SPIOEN|DFON) DFCNTRL[0x0] DFSTATUS[0x2d]:(FIFOEMP|DFTHRESH|HDONE|FIFOQWDEMP) STACK: 0xd7 0x0 0x15a 0x170 SCB count = 130 Kernel NEXTQSCB = 122 Card NEXTQSCB = 122 QINFIFO entries: Waiting Queue entries: Disconnected Queue entries: 30:36 29:37 28:38 27:39 26:20 25:21 16:22 15:23 23:5 14:12 13:18 11:9 12:10 2:25 4:8 18:6 10:3 6:24 1:19 3:15 19:4 8:26 17:28 9:17 0:27 24:16 22:2 20:13 7:0 5:11 21:1 QOUTFIFO entries: Sequencer Free SCB List: Sequencer SCB Info: 0 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x1b] 1 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x13] 2 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x19] 3 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0xf] 4 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x8] 5 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0xb] 6 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x18] 7 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x0] 8 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x1a] 9 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x11] 10 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x3] 11 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x9] 12 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0xa] 13 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x12] 14 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0xc] 15 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x17] 16 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x16] 17 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x1c] 18 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x6] 19 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x4] 20 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0xd] 21 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x1] 22 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x2] 23 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x5] 24 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x10] 25 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x15] 26 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x14] 27 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x27] 28 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x26] 29 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x25] 30 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x24] 31 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] SCB_TAG[0x1e] Pending list: 67 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 68 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 69 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 50 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 51 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 52 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 53 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 54 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 55 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 56 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 57 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 58 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 59 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 40 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 41 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 42 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 43 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 44 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 45 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 46 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 47 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 48 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 14 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 49 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 30 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 31 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 32 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 33 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 34 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 35 SCB_CONTROL[0x64]:(DISCONNECTED|TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 36 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 37 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 38 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 39 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 20 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 21 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 22 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 23 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 5 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 12 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 18 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 9 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 10 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 25 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 8 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 6 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 3 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 24 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 19 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 15 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 4 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 26 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 28 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 17 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 27 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 16 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 2 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 13 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 0 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 11 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] 1 SCB_CONTROL[0x60]:(TAG_ENB|DISCENB) SCB_SCSIID[0x57] SCB_LUN[0x0] Kernel Free SCB list: 66 123 124 125 126 127 128 129 110 111 112 113 114 115 116 117 118 119 100 101 102 103 104 105 106 107 108 109 90 91 92 93 94 7 95 96 97 98 99 80 81 82 83 84 85 86 87 88 89 70 29 71 72 73 74 75 76 77 78 79 60 61 62 63 64 65 121 120 <<<<<<<<<<<<<<<<< Dump Card State Ends >>>>>>>>>>>>>>>>>> (da0:ahc0:0:5:0): SCB 0x31 - timed out sg[0] - Addr 0xc28f000 : Length 4096 sg[1] - Addr 0xc210000 : Length 4096 sg[2] - Addr 0xbf51000 : Length 4096 sg[3] - Addr 0xbe52000 : Length 4096 (da0:ahc0:0:5:0): Other SCB Timeout (da0:ahc0:0:5:0): no longer in timeout, status = 24e ahc0: Issued Channel A Bus Reset. 61 SCBs aborted ahc0: Timedout SCBs already complete. Interrupts may not be functioning. (da0:ahc0:0:5:0): WRITE(10). CDB: 2a 0 0 92 f f 0 0 80 0 (da0:ahc0:0:5:0): CAM Status: SCSI Status Error (da0:ahc0:0:5:0): SCSI Status: Check Condition (da0:ahc0:0:5:0): UNIT ATTENTION asc:29,0 (da0:ahc0:0:5:0): Power on, reset, or bus device reset occurred field replaceable unit: 1 (da0:ahc0:0:5:0): Retrying Command (per Sense Data) From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 02:07:46 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A23A416A4CE for ; Thu, 2 Sep 2004 02:07:46 +0000 (GMT) Received: from ganymede.hub.org (blk-222-46-91.eastlink.ca [24.222.46.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E67043D2F for ; Thu, 2 Sep 2004 02:07:45 +0000 (GMT) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id 77F903690D; Wed, 1 Sep 2004 23:07:46 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 744D53553B; Wed, 1 Sep 2004 23:07:46 -0300 (ADT) Date: Wed, 1 Sep 2004 23:07:46 -0300 (ADT) From: "Marc G. Fournier" To: Allan Fields In-Reply-To: <20040902013534.GD9327@afields.ca> Message-ID: <20040901224632.O72978@ganymede.hub.org> References: <20040901151405.G47186@ganymede.hub.org> <20040901200257.GA92717@afields.ca><41365746.2030605@samsco.org> <20040902013534.GD9327@afields.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@freebsd.org Subject: Re: vnode leak in FFS code ... ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 02:07:46 -0000 On Wed, 1 Sep 2004, Allan Fields wrote: >> It's really hard to tell if there is a vnode leak here. The vnode pool >> is fairly fluid and has nothing to do with the number of files that are >> actually 'open'. Vnodes get created when the VFS layer wants to access >> an object that isn't already in the cache, and only get destroyed when >> the object is destroyed. A vnode that reprents a file that was opened >> will stay 'active' in the system long after the file has been closed, >> because it's cheaper to keep it active in the cache than it is to >> discard it and then risk having to go through the pain of a namei() >> and VOP_LOOKUP() again later. Only if the maxvnode limit is hit will >> old vnodes start getting recycled to represent other objects. [...] >> >> So you've obviously bumped up kern.maxvnodes well above the limits that >> are normally generated from the auto-tuner. Why did you do that, if not >> because you knew that you'd have a large working set of referenced (but >> maybe not open all at once) filesystem objects? [...] > > There was a pevious thread I've found which also helps explains > this further: > http://lists.freebsd.org/pipermail/freebsd-stable/2003-May/001266.html > > Really the same issue now as then? I'm not getting the hangs now, it is freeing up vnodes ... but its having to work very hard to do so, or so it seems: venus# ps aux | grep vnlru root 7 3.0 0.0 0 0 ?? DL 5Aug04 606:34.54 (vnlru) I started up the script for monitoring this on Aug 29th ... since then, there have been 4331 entries to the log file, of which 1927 are in 'vlrup', which I believe is vnlru running through its lists trying to find some to free up, if I recall the code ... ? venus# grep vnode /var/log/syswatch | wc -l 4331 venus# grep vnode /var/log/syswatch | grep vlrup | wc -l 1927 and this is based on a check every minute ... The other server, running ~19 more VMs (~100 more processes), only up 2 days now, seems to be fairing better: debug.numvnodes: 344062 - debug.freevnodes: 168285 - debug.vnlru_nowhere: 0 - vlruwt I've schedualed 'maintenance' on that server for Saturday ... am going to shut down all 'non-host server' processes, and unmount the large file system (where all the VMs run off of) ... see if that cleans up any of the vnodes without having to do a reboot ... If that doesn't work, I could cause a panic and have it dump core, if that would provide for easier/better debugging ... ? I have limited flexibility with the server, but it is a 'real' server without a fake load on it, and as solid as I've always considered FreeBSD to be, I seem to have a knack for pushing it and breaking it :( ... so whatever data I can provide to make it that much more solid, even if it involves a little bit of downtime to get a good core dump, I'm willing to do ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 03:16:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9BF816A4CE for ; Thu, 2 Sep 2004 03:16:22 +0000 (GMT) Received: from mx2.synetsystems.com (mx2.synetsystems.com [216.226.140.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id B0B2443D4C for ; Thu, 2 Sep 2004 03:16:22 +0000 (GMT) (envelope-from rmtodd@servalan.servalan.com) Received: by mx2.synetsystems.com (Postfix, from userid 66) id 0BAF31DB; Wed, 1 Sep 2004 23:16:22 -0400 (EDT) Received: from rmtodd by servalan.servalan.com with local (Exim 4.41 (FreeBSD)) id 1C2hEL-0003Hy-Jb; Wed, 01 Sep 2004 21:21:41 -0500 Date: Wed, 1 Sep 2004 21:21:41 -0500 From: Richard Todd To: Julian Elischer Message-ID: <20040902022141.GA12192@ichotolot.servalan.com> References: <20040820211618.62A1C7E4@mx2.synetsystems.com> <41341F94.6000803@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41341F94.6000803@elischer.org> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: Panic 'kernel trap doesn't have ucred' in last night's -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 03:16:23 -0000 On Mon, Aug 30, 2004 at 11:49:56PM -0700, Julian Elischer wrote: > Richard Todd wrote: > >In the freebsd-current mailing list I wrote last week: > > > >>Hi. Upgraded to -current last night and got the following panic. The > >>panic > >>seems to be fairly repeatable and is triggered by a minute or so's worth > >>of > >>database activity with mysqld. The version of mysql is 3.23.58_1 from > >>ports, [...] > I've been working on this and have some fixes on the way.. > > you might try tomorrow's -current as I just committed a possibly relevent > change. I've upgraded to current as of last night, and ran the test I mentioned in my original mail 20 times without causing a panic; I've now been up for a couple hours in "normal" operation with mysqld using libpthread busily handling requests from the various amavisd/spamassasin copies running without triggering a panic (which it did repeatedly before.) Looks like the bug's fixed. Thanks. From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 03:32:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1CDF16A4CE for ; Thu, 2 Sep 2004 03:32:55 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5970B43D1F for ; Thu, 2 Sep 2004 03:32:55 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i823UIRe036131; Wed, 1 Sep 2004 23:30:18 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i823UIh3036128; Wed, 1 Sep 2004 23:30:18 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 1 Sep 2004 23:30:18 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Patrick Guelat In-Reply-To: <20040901223721.S82908@murphy.imp.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE cc: freebsd-current@freebsd.org Subject: Re: Panic in propagate_priority() [5.3-BETA2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 03:32:55 -0000 On Wed, 1 Sep 2004, Patrick Guelat wrote: > Since nobody answered to the problem yet that I reported a few days > ago I did some more tests and got several panics since then... >=20 > I'm trying to run OSPF6 on a gif-tunnel between a Cisco-7206VXR and a > box running 5.3-BETA2 and get a panic everytime I start ospf6d (from > /usr/ports/net/quagga).=20 >=20 > It always ends in a panic in propagate_priority(), sometimes I get the > following panic-message:=20 >=20 > panic: process 37 (swi1: net):1 holds rip but isn't blocked on a > lock >=20 > "rip" is the lock defined in netinet/raw_ip.c which is also used by the > netinet6/raw_ip6.c.=20 A couple of questions: - Is this an SMP box? - Is PREEMPTION enabled on the box? - Are you using net.isr.enable=3D1 or debug.mpsafenet=3D1? Is WITNESS compiled into your kernel, and if so, when you drop to DDB from panic(), what does "show pcpu", "show locks", and "show locks 37" indicate? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research >=20 > Tracing the userland-part nearly always ends at the sendmsg(2) > call on the raw socket, but sometimes the panic also occurs=20 > some time before ospf6d sends it's first hello message (maybe during > the reception of the ipv6 ospf packet from the cisco ?) >=20 > Regards >=20 > Patrick > -- > Patrick Gu=E9lat, ImproWare AG Network Services, CH-4133 Pratteln > Mail: Patrick.Guelat@imp.ch - Phone: +41 61 826 93 00 (ext: 13) From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 05:31:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFAF316A4CE for ; Thu, 2 Sep 2004 05:31:38 +0000 (GMT) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.145.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8D7F43D58 for ; Thu, 2 Sep 2004 05:31:38 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 843044EFCDE; Thu, 2 Sep 2004 13:31:30 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 50C074EFCDD; Thu, 2 Sep 2004 13:31:30 +0800 (CST) Date: Thu, 2 Sep 2004 13:31:30 +0800 (CST) From: Tai-hwa Liang To: cell In-Reply-To: <005d01c49045$f5f31bf0$0401a8c0@frederic> Message-ID: <04090213304212.68936@www.mmlab.cse.yzu.edu.tw> References: <005d01c49045$f5f31bf0$0401a8c0@frederic> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: netgear wg311 v2 configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 05:31:39 -0000 On Wed, 1 Sep 2004, cell wrote: > hello i have installed driver nisd for this card and it works but when i do "ifconfig ndis0 192.168.1.9 netmask 255.255.255.0 up " i have "ifconfig: ioctl (SIOCAIFADDR): File exists" and i don't understand why. Perhaps you have another NIC on the same box sitting in the same subnet. Try to "ifconfig other_nic delete" first. From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 05:57:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F78416A4CE for ; Thu, 2 Sep 2004 05:57:07 +0000 (GMT) Received: from mail.if.lt (hermes.ifnet.lt [195.190.141.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id B66F643D41 for ; Thu, 2 Sep 2004 05:57:05 +0000 (GMT) (envelope-from vd@vmunix.lt) Received: from zeus.sampo.vlan (p2.ifnet.lt [195.190.141.35]) by mail.if.lt (IF NOC MAIL) with ESMTP id 4081A3D11C for ; Thu, 2 Sep 2004 08:56:33 +0300 (EEST) Date: Thu, 2 Sep 2004 08:56:33 +0300 (EEST) From: Vaidas Damosevicius To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Message-Id: <20040902055633.4081A3D11C@mail.if.lt> Subject: [BETA2] lock order reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 05:57:07 -0000 ..., lock order reversal 1st 0xc1a756e8 re0 (network driver) @ /usr/src/sys/dev/re/if_re.c:830 2nd 0xc0a18060 ACPI root bus (ACPI root bus) @ /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi.c:841 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c08bd990,c08bdf58,c084d9cc) at kdb_backtrace+0x29 witness_checkorder(c0a18060,9,c0a124e8,349) at witness_checkorder+0x544 _sx_xlock(c0a18060,c0a124e8,349,c08be868,7) at _sx_xlock+0x50 acpi_release_resource(c19ec600,c1a99700,4,10,c1adc180) at acpi_release_resource+0x23 bus_generic_release_resource(c19ec300,c1a99700,4,10,c1adc180) at bus_generic_release_resource+0x64 resource_list_release(c1a99784,c1a98a00,c1a99700,4,10) at resource_list_release+0x6e bus_generic_rl_release_resource(c1a98a00,c1a99700,4,10,c1adc180) at bus_generic_rl_release_resource+0x5e bus_generic_release_resource(c1a99280,c1a99700,4,10,c1adc180) at bus_generic_release_resource+0x64 resource_list_release(c1a99784,c1a99900,c1a99700,4,10) at resource_list_release+0xfb bus_generic_rl_release_resource(c1a99900,c1a99700,4,10,c1adc180) at bus_generic_rl_release_resource+0x5e bus_release_resource(c1a99700,4,10,c1adc180,c1a99700) at bus_release_resource+0x61 re_probe(c1a99700) at re_probe+0x1b5 device_probe_child(c1a99900,c1a99700,c19ba520,c1a99700,c1a99900) at device_probe_child+0xc4 device_probe_and_attach(c1a99700) at device_probe_and_attach+0x51 bus_generic_attach(c1a99900,6,c19ba520,1,c0a00c80) at bus_generic_attach+0x16 acpi_pci_attach(c1a99900) at acpi_pci_attach+0xec device_attach(c1a99900,2e696370,c1a99900,c1a99280,0) at device_attach+0x58 device_probe_and_attach(c1a99900) at device_probe_and_attach+0xb4 bus_generic_attach(c1a99280,c1a99280,c1ad90b0,2,c0a008c5) at bus_generic_attach+0x16 acpi_pcib_attach(c1a99280,c1ad90b0,2,c1a99280,c19ba520) at acpi_pcib_attach+0x14e acpi_pcib_pci_attach(c1a99280) at acpi_pcib_pci_attach+0x88 device_attach(c1a99280,c1a99200,c1a99280,c1a98a00,c1a98a00) at device_attach+0x58 device_probe_and_attach(c1a99280) at device_probe_and_attach+0xb4 bus_generic_attach(c1a98a00,6,c19ba680,1,c0a00c80) at bus_generic_attach+0x16 acpi_pci_attach(c1a98a00) at acpi_pci_attach+0xec device_attach(c1a98a00,2e696370,c1a98a00,c19ec300,0) at device_attach+0x58 device_probe_and_attach(c1a98a00) at device_probe_and_attach+0xb4 bus_generic_attach(c19ec300,c19ec300,c1a9a054,0,0) at bus_generic_attach+0x16 acpi_pcib_attach(c19ec300,c1a9a054,0,c0c21c5c,c0616da4) at acpi_pcib_attach+0x14e acpi_pcib_acpi_attach(c19ec300) at acpi_pcib_acpi_attach+0x20a device_attach(c19ec300,c1994a80,c19ec300,c19ec600,0) at device_attach+0x58 device_probe_and_attach(c19ec300) at device_probe_and_attach+0xb4 bus_generic_attach(c19ec600,c19ec600,c1976120,1,c19ec580) at bus_generic_attach+0x16 acpi_probe_children(c19ec600,1b250,c19ec600,c19ec600,0) at acpi_probe_children+0x63 acpi_attach(c19ec600) at acpi_attach+0x523 device_attach(c19ec600,c0a16620,c19ec600,c19ec780,0) at device_attach+0x58 device_probe_and_attach(c19ec600) at device_probe_and_attach+0xb4 bus_generic_attach(c19ec780,c19ec780,c19ec780,c0c21d44,c061318c) at bus_generic_attach+0x16 nexus_attach(c19ec780) at nexus_attach+0x13 device_attach(c19ec780,c0885d50,c19ec780,c0885d50,c29000) at device_attach+0x58 device_probe_and_attach(c19ec780) at device_probe_and_attach+0xb4 root_bus_configure(c197e780,c080ef08,0) at root_bus_configure+0x16 configure(0,c1ec00,c1e000,0,c043f3d5) at configure+0x1b mi_startup() at mi_startup+0x96 begin() at begin+0x2c From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 06:32:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 836A316A4CE; Thu, 2 Sep 2004 06:32:53 +0000 (GMT) Received: from mail.imp.ch (ns1.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D05B43D2D; Thu, 2 Sep 2004 06:32:52 +0000 (GMT) (envelope-from pg@imp.ch) Received: from nbs.imp.ch (nbs.imp.ch [157.161.4.7]) by mail.imp.ch (8.12.9p2/8.12.3) with ESMTP id i826Wfq9083796; Thu, 2 Sep 2004 08:32:43 +0200 (CEST) (envelope-from pg@imp.ch) Received: from murphy.imp.ch (murphy.imp.ch [157.161.4.77]) by nbs.imp.ch (8.12.10/8.12.3) with ESMTP id i826Weir43663403; Thu, 2 Sep 2004 08:32:41 +0200 (MES) Date: Thu, 2 Sep 2004 08:28:29 +0000 (UTC) From: Patrick Guelat X-X-Sender: patg@murphy.imp.ch To: Robert Watson , jhb@freebsd.org In-Reply-To: Message-ID: <20040902081926.J48093@murphy.imp.ch> References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1160686353-1094113709=:48093" X-Spam-Checksum: 88bfcbf7483fb70d71b9c89243752bdc X-Virus-Message-Status: No X-Virus-Status: No, scantime="0.0015 seconds" X-Spam-Status: No, hits=-4.9 required=5 scantime="3.4020 seconds" tests=BAYES_00 X-Scanned-By: MIMEDefang 2.44 cc: freebsd-current@freebsd.org Subject: Re: Panic in propagate_priority() [5.3-BETA2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 06:32:53 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1160686353-1094113709=:48093 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 1 Sep 2004, Robert Watson wrote: >> "rip" is the lock defined in netinet/raw_ip.c which is also used by the >> netinet6/raw_ip6.c. > > A couple of questions: > > - Is this an SMP box? > - Is PREEMPTION enabled on the box? > - Are you using net.isr.enable=1 or debug.mpsafenet=1? No PREEMPTION, more or less vanilla 5.3-BETA2 GENERIC, w/o mpsafenet and net.isr.enable=0, UP machine (no SMP) > Is WITNESS compiled into your kernel, and if so, when you drop to DDB from > panic(), what does "show pcpu", "show locks", and "show locks 37" > indicate? db> show pcpu cpu_id = 0 curthread = 0xc19c16c0: pid 37 "swi1: net" curpcb = 0xd53f1da0 fpcurthread = none idlethread = 0xc197b580: pid 11 "idle" APIC ID = 0 currentldt = 0x68 spin locks held: db> show locks exclusive sleep mutex rip r=1 (0xc079e70c) locked @ /usr/src53/sys/netinet6/raw_ip.c:255 db> show locks 37 exclusive sleep mutex rip r=1 (0xc079e70c) locked @ /usr/src53/sys/netinet6/raw_ip.c:255 -Patrick -- Patrick Guélat, ImproWare AG Network Services, CH-4133 Pratteln Mail: Patrick.Guelat@imp.ch - Phone: +41 61 826 93 00 (ext: 13) --0-1160686353-1094113709=:48093-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 07:33:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 482DA16A4CE for ; Thu, 2 Sep 2004 07:33:52 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 975A643D48 for ; Thu, 2 Sep 2004 07:33:51 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [172.18.2.1] (csc-gw1.novi.dk [130.225.63.24]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i827XnVT031859; Thu, 2 Sep 2004 09:33:49 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <4136CCBB.8090604@DeepCore.dk> Date: Thu, 02 Sep 2004 09:33:15 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <20040901202321.345035D04@ptavv.es.net> <41363364.2070103@DeepCore.dk> <4136382D.9010106@root.org> In-Reply-To: <4136382D.9010106@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: current@freebsd.org Subject: Re: ATA DVD playback hanging in physrd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 07:33:52 -0000 Nate Lawson wrote: > S=F8ren Schmidt wrote: >> On that note ACPI still locks hard both my laptops (ASUS/Acer) on=20 >> resume, with and upto date -current its back to not even switching on = >> the backlight, so I have no way to tell what happens. On the ASUS that= =20 >> has a serial port even that is totally dead. >> >> However, commenting out the resume code in acpi_cmbat.c make it get so= =20 >> far as to give me a prompt in singleuser mode, but just a simple ls=20 >> makes in crash with a double fault in the image activation of the ls=20 >> command, it looks like the vm system is way out to lunch somehow. >>=20 > Try taking /sys/i386/acpi_wakeup.c back to 1.36. That makes things worse actually, now I dont get back from resume, I do=20 get my backlight turned on though :) If that doesn't work, > try reverting /sys/dev/acpica/acpi.c back to 2004/8/1 (mentioned=20 > previously). It is important to isolate the cause. That doesn't work, the rest of the code has changed so it wont compile.. > I'm working on the cmbat resume part for you. The reason why this is=20 > not an easy problem to debug is that different systems have different=20 > AML and that AML is run by various methods, including cmbat. If it doe= s=20 > weird things like writing to various runtime registers or acquiring=20 > mutexes, it can cause failures independent of our code. My laptop=20 > suspends/resumes fine with -current, including hotplugging the=20 > batteries, etc. On that note, it doesn't see when I hotplug my second battery, however=20 doing a acpiconf -i 0/1 makes it appear properly.. -S=F8ren From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 07:39:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33E1016A4CE for ; Thu, 2 Sep 2004 07:39:11 +0000 (GMT) Received: from Sammael.Blosphere.net (sammael.Blosphere.net [193.66.203.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C52543D3F for ; Thu, 2 Sep 2004 07:39:10 +0000 (GMT) (envelope-from sty@iki.fi) Received: from [172.16.112.227] (bsifw11.brain.riken.go.jp [134.160.173.1]) by Sammael.Blosphere.net (Postfix) with ESMTP id 275193FFCA for ; Thu, 2 Sep 2004 10:39:06 +0300 (EEST) Message-ID: <4136CE19.5020804@iki.fi> Date: Thu, 02 Sep 2004 16:39:05 +0900 From: =?ISO-8859-1?Q?Tommi_L=E4tti?= User-Agent: Mozilla Thunderbird 0.7.2 (Windows/20040707) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------010405040006080204010306" Subject: strange crashes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 07:39:11 -0000 This is a multi-part message in MIME format. --------------010405040006080204010306 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit The box I run is crashing semi-frequently, at least once a week. The hardware is dual-pIII 800MHz with 512 megs of ECC ram. I'm running it without SMP since that makes it crash every day. It has been doing so since last February. I thought this might have been fixed in the future releases I didn't pay it much heed (running 5.2.1 currently) but it seems that nothing has changed in the last 6 months or so... There's nothing on any logs, and I cannot get to the console due the fact that I happen to live the other side of the world currently :) The crashes seem to happen during high load/io-load. I can go thru buildworld but sometimes it cannot get thru that even. Definetly portsdb -Uu crahes it in the very end or updating locatedb. It seems that I also cannot get any kernel dumps after crashes, there's only the following message on logs: Sep 1 20:42:19 Sammael kernel: dumpon: Sep 1 20:42:19 Sammael kernel: ioctl(DIOCSKERNELDUMP) Sep 1 20:42:19 Sammael kernel: : Sep 1 20:42:19 Sammael kernel: Operation not supported by device Maybe the Mylex raid controller is not applicable dump device. I can maybe resize one of the ide drivers from the console to get a dump. But anyways, I'd really would appreciate some help here. Attached the full log from boot. -- br, Tommi --------------010405040006080204010306 Content-Type: text/plain; name="all.log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="all.log" Sep 1 20:42:17 xxx syslogd: restart Sep 1 20:42:17 xxx syslogd: kernel boot file is /boot/kernel/kernel Sep 1 20:42:17 xxx kernel: Copyright (c) 1992-2004 The FreeBSD Project. Sep 1 20:42:17 xxx kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Sep 1 20:42:17 xxx kernel: The Regents of the University of California. All rights reserved. Sep 1 20:42:17 xxx kernel: FreeBSD 5.2.1-RELEASE-p8 #5: Tue Aug 3 16:51:16 EEST 2004 Sep 1 20:42:17 xxx kernel: xxx:/usr/obj/usr/src/sys/CUSTOM Sep 1 20:42:17 xxx kernel: Preloaded elf kernel "/boot/kernel/kernel" at 0xc0785000. Sep 1 20:42:17 xxx kernel: Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0785244. Sep 1 20:42:17 xxx kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Sep 1 20:42:17 xxx kernel: CPU: Intel Pentium III (796.54-MHz 686-class CPU) Sep 1 20:42:17 xxx kernel: Origin = "GenuineIntel" Id = 0x683 Stepping = 3 Sep 1 20:42:17 xxx kernel: Features=0x383fbff Sep 1 20:42:17 xxx kernel: real memory = 536805376 (511 MB) Sep 1 20:42:17 xxx kernel: avail memory = 515940352 (492 MB) Sep 1 20:42:17 xxx kernel: Pentium Pro MTRR support enabled Sep 1 20:42:17 xxx kernel: npx0: [FAST] Sep 1 20:42:17 xxx kernel: npx0: on motherboard Sep 1 20:42:17 xxx kernel: npx0: INT 16 interface Sep 1 20:42:17 xxx kernel: acpi0: on motherboard Sep 1 20:42:17 xxx kernel: acpi0: Power Button (fixed) Sep 1 20:42:17 xxx kernel: Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 Sep 1 20:42:17 xxx kernel: pcibios: BIOS version 2.10 Sep 1 20:42:17 xxx kernel: Using $PIR table, 12 entries at 0xc00fdf00 Sep 1 20:42:17 xxx kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0xc08-0xc0b on acpi0 Sep 1 20:42:17 xxx kernel: acpi_cpu0: on acpi0 Sep 1 20:42:17 xxx kernel: acpi_cpu1: on acpi0 Sep 1 20:42:17 xxx kernel: device_probe_and_attach: acpi_cpu1 attach returned 6 Sep 1 20:42:17 xxx kernel: pcib0: port 0xcf8-0xcff on acpi0 Sep 1 20:42:17 xxx kernel: pci0: on pcib0 Sep 1 20:42:17 xxx kernel: pcib0: slot 11 INTA is routed to irq 7 Sep 1 20:42:17 xxx kernel: pcib0: slot 12 INTA is routed to irq 5 Sep 1 20:42:17 xxx kernel: pcib0: slot 12 INTA is routed to irq 5 Sep 1 20:42:17 xxx kernel: pcib0: slot 14 INTA is routed to irq 11 Sep 1 20:42:17 xxx kernel: pcib0: slot 18 INTD is routed to irq 11 Sep 1 20:42:17 xxx kernel: agp0: mem 0xf8000000-0xfbffffff at device 0.0 on pci0 Sep 1 20:42:17 xxx kernel: pcib1: at device 1.0 on pci0 Sep 1 20:42:17 xxx kernel: pci1: on pcib1 Sep 1 20:42:18 xxx kernel: pcib2: at device 15.0 on pci1 Sep 1 20:42:18 xxx kernel: pci2: on pcib2 Sep 1 20:42:18 xxx kernel: pcib0: slot 1 INTC is routed to irq 10 Sep 1 20:42:18 xxx kernel: pcib1: slot 15 INTD is routed to irq 10 Sep 1 20:42:18 xxx kernel: pcib2: slot 7 INTA is routed to irq 10 Sep 1 20:42:18 xxx kernel: atapci0: port 0x3000-0x30ff,0x3400-0x3403,0x3408-0x340f,0x3404-0x3407,0x3410-0x3417 irq 10 at device 7.0 on pci2 Sep 1 20:42:18 xxx kernel: atapci0: [MPSAFE] Sep 1 20:42:18 xxx kernel: ata2: at 0x3410 on atapci0 Sep 1 20:42:18 xxx kernel: ata2: [MPSAFE] Sep 1 20:42:18 xxx kernel: ata3: at 0x3408 on atapci0 Sep 1 20:42:18 xxx kernel: ata3: [MPSAFE] Sep 1 20:42:18 xxx kernel: pcib3: at device 11.0 on pci0 Sep 1 20:42:18 xxx kernel: pci3: on pcib3 Sep 1 20:42:18 xxx kernel: mlx0: mem 0xf4104000-0xf4105fff irq 7 at device 11.1 on pci0 Sep 1 20:42:18 xxx kernel: mlx0: DAC960PTL1, 1 channel, firmware 4.08-0-37, 8MB RAM Sep 1 20:42:18 xxx kernel: mlxd0: on mlx0 Sep 1 20:42:18 xxx kernel: mlxd0: 17518MB (35876864 sectors) RAID 5 (online) Sep 1 20:42:18 xxx kernel: GEOM: create disk mlxd0 dp=0xc43e010c Sep 1 20:42:18 xxx kernel: pci0: at device 12.0 (no driver attached) Sep 1 20:42:18 xxx kernel: pci0: at device 12.1 (no driver attached) Sep 1 20:42:18 xxx kernel: fxp0: port 0x2000-0x203f mem 0xf4000000-0xf40fffff,0xf4100000-0xf4100fff irq 11 at device 14.0 on pci0 Sep 1 20:42:18 xxx kernel: fxp0: Ethernet address 00:d0:b7:a9:c8:e5 Sep 1 20:42:18 xxx kernel: miibus0: on fxp0 Sep 1 20:42:18 xxx kernel: inphy0: on miibus0 Sep 1 20:42:18 xxx kernel: inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Sep 1 20:42:18 xxx kernel: isab0: at device 18.0 on pci0 Sep 1 20:42:18 xxx kernel: isa0: on isab0 Sep 1 20:42:18 xxx kernel: atapci1: port 0x2040-0x204f at device 18.1 on pci0 Sep 1 20:42:18 xxx kernel: ata0: at 0x1f0 irq 14 on atapci1 Sep 1 20:42:18 xxx kernel: ata0: [MPSAFE] Sep 1 20:42:18 xxx kernel: ata1: at 0x170 irq 15 on atapci1 Sep 1 20:42:19 xxx kernel: ata1: [MPSAFE] Sep 1 20:42:19 xxx kernel: pci0: at device 18.2 (no driver attached) Sep 1 20:42:19 xxx kernel: pci0: at device 18.3 (no driver attached) Sep 1 20:42:19 xxx kernel: pci0: at device 20.0 (no driver attached) Sep 1 20:42:19 xxx kernel: atkbdc0: port 0x64,0x60 irq 1 on acpi0 Sep 1 20:42:19 xxx kernel: fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 Sep 1 20:42:19 xxx kernel: fdc0: FIFO enabled, 8 bytes threshold Sep 1 20:42:19 xxx kernel: fd0: <1440-KB 3.5" drive> on fdc0 drive 0 Sep 1 20:42:19 xxx kernel: acpi_cpu1: on acpi0 Sep 1 20:42:19 xxx kernel: device_probe_and_attach: acpi_cpu1 attach returned 6 Sep 1 20:42:19 xxx kernel: pmtimer0 on isa0 Sep 1 20:42:19 xxx kernel: orm0: VESA: information block 56 45 53 41 00 02 00 01 00 01 01 00 00 00 40 00 00 01 20 00 00 01 16 01 00 01 31 01 00 01 4a 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 16 mode(s) found VESA: v2.0, 2048k memory, flags:0x1, mode table:0xc06e18c0 (1000040) VESA: CHIPS 69000 Super VGA VESA: Chips & Technologies, Inc. 69000 Display Controller 2 npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pci_open(1): mode 1 addr port (0x0cf8) is 0x80000058 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=71928086) pcibios: BIOS version 2.10 apm0: on motherboard apm0: found APM BIOS v1.2, connected at v1.2 pcib0: pcibus 0 on motherboard pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base 50000000, size 28, enabled found-> vendor=0x8086, dev=0x7192, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2200, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x7110, revid=0x02 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x010f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 00001020, size 4, enabled found-> vendor=0x8086, dev=0x7111, revid=0x01 bus=0, slot=7, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 00001000, size 5, enabled found-> vendor=0x8086, dev=0x7112, revid=0x01 bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 map[90]: type 4, range 32, base 00000d00, size 4, enabled found-> vendor=0x8086, dev=0x7113, revid=0x02 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 1, range 32, base 40000000, size 24, enabled found-> vendor=0x102c, dev=0x00c0, revid=0x64 bus=0, slot=8, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0083, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[10]: type 1, range 32, base 7fffe000, size 12, enabled found-> vendor=0x104c, dev=0xac17, revid=0x02 bus=0, slot=17, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x42 (1980 ns), mingnt=0xc0 (48000 ns), maxlat=0x03 (750 ns) intpin=a, irq=11 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 7ffff000, size 12, enabled found-> vendor=0x104c, dev=0xac17, revid=0x02 bus=0, slot=17, func=1 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x42 (1980 ns), mingnt=0xc0 (48000 ns), maxlat=0x03 (750 ns) intpin=a, irq=11 powerspec 1 supports D0 D1 D2 D3 current D0 isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0x1020-0x102f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x1020 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 ata0-master: stat=0x80 err=0x80 lsb=0x80 msb=0x80 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=51 ostat1=01 ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0xc ata1: [MPSAFE] uhci0: port 0x1000-0x101f irq 11 at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0x1000 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.10, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. intpm0: port 0xd00-0xd0f irq 9 at device 7.3 on pci0 intpm0: Reserved 0x10 bytes for rid 0x90 type 4 at 0xd00 intpm0: I/O mapped d00 intpm0: intr IRQ 9 enabled revision 0 intpm0: [GIANT-LOCKED] intsmb0: on intpm0 smbus0: on intsmb0 intpm0: PM I/O mapped f00 pci0: at device 8.0 (no driver attached) cbb0: mem 0x7fffe000-0x7fffefff irq 11 at device 17.0 on pci0 cbb0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x7fffe000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0xac17104c 0x02100007 0x06070002 0x00824208 0x10: 0x7fffe000 0x020000a0 0x20010100 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010b 0x40: 0xb0470e11 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x28049060 0x00000000 0x00000000 0x01001c72 0x90: 0x61648280 0x00000000 0x00000000 0x00000000 0xa0: 0x7e210001 0x00800000 0x00000801 0x00000007 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 cbb1: mem 0x7ffff000-0x7fffffff irq 11 at device 17.1 on pci0 cbb1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0x7ffff000 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [MPSAFE] cbb1: PCI Configuration space: 0x00: 0xac17104c 0x02100007 0x06070002 0x00824208 0x10: 0x7ffff000 0x020000a0 0x20020200 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010b 0x40: 0xb0470e11 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x2804b060 0x00000000 0x00000000 0x01001c72 0x90: 0x61648280 0x00000000 0x00000000 0x00000000 0xa0: 0x7e210001 0x00800000 0x00000801 0x00000007 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 cpu0 on motherboard ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 pnpbios: 18 devices, largest 250 bytes PNP0401: adding irq mask 0x80 PNP0401: adding dma mask 0x8 PNP0401: adding io range 0x378-0x37f, size=0x8, align=0 PNP0401: adding io range 0x778-0x77a, size=0x3, align=0 pnpbios: handle 1 device ID PNP0401 (0104d041) PNP0501: adding io range 0x3f8-0x3ff, size=0x8, align=0 PNP0501: adding irq mask 0x10 pnpbios: handle 2 device ID PNP0501 (0105d041) pnpbios: handle 3 device ID PNP0511 (1105d041) PNP0700: adding irq mask 0x40 PNP0700: adding dma mask 0x4 PNP0700: adding io range 0x3f0-0x3f5, size=0x6, align=0 pnpbios: handle 4 device ID PNP0700 (0007d041) ESS0006: adding io range 0x250-0x257, size=0x8, align=0 pnpbios: handle 5 device ID ESS0006 (06007316) CPQb0ac: adding io range 0x220-0x22f, size=0x10, align=0 CPQb0ac: adding io range 0x388-0x38b, size=0x4, align=0 CPQb0ac: adding io range 0x330-0x331, size=0x2, align=0 CPQb0ac: adding irq mask 0x20 CPQb0ac: adding dma mask 0x2 CPQb0ac: adding dma mask 0x20 pnpbios: handle 6 device ID CPQb0ac (acb0110e) PNP0c01: adding fixed memory32 range 0-0x9ffff, size=0xa0000 PNP0c01: adding fixed memory32 range 0xf0000-0xfffff, size=0x10000 PNP0c01: adding fixed memory32 range 0x100000-0xbffffff, size=0xbf00000 pnpbios: handle 7 device ID PNP0c01 (010cd041) PNP0c04: adding io range 0xf0-0xff, size=0x10, align=0 PNP0c04: adding irq mask 0x2000 pnpbios: handle 8 device ID PNP0c04 (040cd041) PNP0100: adding io range 0x40-0x43, size=0x4, align=0 PNP0100: adding irq mask 0x1 pnpbios: handle 10 device ID PNP0100 (0001d041) PNP0200: adding io range 0-0xf, size=0x10, align=0 PNP0200: adding io range 0x80-0x8f, size=0x10, align=0 PNP0200: adding io range 0xc0-0xdf, size=0x20, align=0 PNP0200: adding dma mask 0x10 pnpbios: handle 11 device ID PNP0200 (0002d041) PNP0800: adding io range 0x61-0x61, size=0x1, align=0 pnpbios: handle 12 device ID PNP0800 (0008d041) PNP0b00: adding io range 0x70-0x71, size=0x2, align=0 PNP0b00: adding io range 0x72-0x73, size=0x2, align=0 PNP0b00: adding irq mask 0x100 pnpbios: handle 13 device ID PNP0b00 (000bd041) PNP0303: adding io range 0x60-0x60, size=0x1, align=0 PNP0303: adding io range 0x64-0x64, size=0x1, align=0 PNP0303: adding irq mask 0x2 pnpbios: handle 14 device ID PNP0303 (0303d041) PNP0f13: adding irq mask 0x1000 pnpbios: handle 15 device ID PNP0f13 (130fd041) PNP0a03: adding io range 0xcf8-0xcff, size=0x8, align=0 pnpbios: handle 16 device ID PNP0a03 (030ad041) PNP0c02: adding fixed memory32 range 0xfffc0000-0xffffffff, size=0x40000 PNP0c02: adding fixed memory32 range 0xcb000-0xcbfff, size=0x1000 PNP0c02: adding io range 0x22-0x3f, size=0x1e, align=0 PNP0c02: adding io range 0x44-0x5f, size=0x1c, align=0 PNP0c02: adding io range 0x62-0x63, size=0x2, align=0 PNP0c02: adding io range 0x65-0x6f, size=0xb, align=0 PNP0c02: adding io range 0x74-0x74, size=0x1, align=0 PNP0c02: adding io range 0x75-0x75, size=0x1, align=0 PNP0c02: adding io range 0x76-0x76, size=0x1, align=0 PNP0c02: adding io range 0x77-0x77, size=0x1, align=0 PNP0c02: adding io range 0x90-0x91, size=0x2, align=0 PNP0c02: adding io range 0x92-0x92, size=0x1, align=0 PNP0c02: adding io range 0x93-0x9f, size=0xd, align=0 PNP0c02: adding io range 0xa2-0xbf, size=0x1e, align=0 PNP0c02: adding io range 0xe0-0xe1, size=0x2, align=0 PNP0c02: adding io range 0xe2-0xe3, size=0x2, align=0 PNP0c02: adding io range 0x100-0x107, size=0x8, align=0 PNP0c02: adding io range 0x260-0x263, size=0x4, align=0 PNP0c02: adding io range 0x4d0-0x4d1, size=0x2, align=0 PNP0c02: adding io range 0xf00-0xf3f, size=0x40, align=0 PNP0c02: adding io range 0xd00-0xd0f, size=0x10, align=0 pnpbios: handle 18 device ID PNP0c02 (020cd041) PNP0e03: adding io range 0x3e0-0x3e1, size=0x2, align=0 pnpbios: handle 19 device ID PNP0e03 (030ed041) sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xcafff on isa0 pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0065 psm0: flags 0xc000 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 2 buttons psm0: config:0000c000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: parallel port found at 0x378 ppc0: using extended I/O port range ppc0: EPP SPP ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port fb: new array size 4 sc0: at flags 0x100 on isa0 sc0: VGA <12 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio0: irq maps: 0x1 0x11 0x1 0x1 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x700ff fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff isa_probe_children: probing PnP devices unknown: can't assign resources (port) unknown: at port 0x378-0x37f on isa0 unknown: can't assign resources (port) unknown: at port 0x3f8-0x3ff on isa0 unknown: failed to probe on isa0 unknown: can't assign resources (port) unknown: at port 0x3f0-0x3f5 on isa0 sbc0: at port 0x330-0x331,0x388-0x38b,0x220-0x22f irq 5 drq 5,1 on isa0 sbc0: [GIANT-LOCKED] pcm0: on sbc0 pcm0: ESS1869 detected, newspeed pcm0: [GIANT-LOCKED] pcm0: sndbuf_setmap ffe000, 1000; 0xc991c000 -> ffe000 pcm0: sndbuf_setmap ffd000, 1000; 0xc991d000 -> ffd000 unknown: failed to probe at port 0x61 on isa0 unknown: can't assign resources (port) unknown: at port 0x60 on isa0 unknown: can't assign resources (irq) unknown: at irq 12 on isa0 unknown: can't assign resources (port) unknown: at port 0x4d0-0x4d1,0x260-0x263,0x100-0x107,0xe2-0xe3,0xe0-0xe1,0xa2-0xbf,0x93-0x9f,0x92,0x90-0x91,0x77,0x76,0x75,0x74,0x65-0x6f,0x62-0x63,0x44-0x5f,0x22-0x3f iomem 0xcb000-0xcbfff,0xfffc0000-0xffffffff on isa0 unknown: failed to probe at port 0x3e0-0x3e1 on isa0 Device configuration finished. TSC timecounter disabled: APM enabled. Timecounter "TSC" frequency 300011828 Hz quality -1000 Timecounters tick every 10.000 msec lo0: bpf attached ata0-master: pio=0x0c wdma=0x22 udma=0x42 cable=40pin ata0-master: setting PIO4 on Intel PIIX4 chip ata0-master: setting UDMA33 on Intel PIIX4 chip ad0: ATA-4 disk at ata0-master ad0: 6194MB (12685680 sectors), 13424 C, 15 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA33 GEOM: new disk ad0 [0] f:80 typ:11 s(CHS):1/0/1 e(CHS):278/239/63 s:15120 l:4203360 [1] f:00 typ:18 s(CHS):0/1/1 e(CHS):0/239/63 s:63 l:15057 [2] f:00 typ:165 s(CHS):279/0/1 e(CHS):838/239/63 s:4218480 l:8467200 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 7741440 length 2152120320 end 2159861759 GEOM: Configure ad0s2, start 32256 length 7709184 end 7741439 GEOM: Configure ad0s3, start 2159861760 length 4335206400 end 6495068159 GEOM: Configure ad0s3a, start 0 length 134217728 end 134217727 GEOM: Configure ad0s3b, start 134217728 length 536870912 end 671088639 GEOM: Configure ad0s3c, start 0 length 4335206400 end 4335206399 GEOM: Configure ad0s3d, start 671088640 length 872415232 end 1543503871 GEOM: Configure ad0s3e, start 1543503872 length 134217728 end 1677721599 GEOM: Configure ad0s3f, start 1677721600 length 2657484800 end 4335206399 pccard1: CIS version PC Card Standard 5.0 pccard1: CIS info: Xircom, CreditCard 10/100, CE3-10/100, 1.00 pccard1: Manufacturer code 0x105, product 0x10a pccard1: function 0: network adapter, ccr addr 800 mask 3 pccard1: function 0, config table entry 1: I/O card; irq mask 8ebc; iomask 4, iospace 0-f; memspace 0-fff; mwait_required rdybsy_active io8 io16 irqpulse irqlevel powerdown xe0: at port 0x100-0x10f irq 11 function 0 config 1 on pccard1 xe0: [GIANT-LOCKED] xe0: Xircom CreditCard 10/100, version 0x45/0x04, 100Mbps capable xe0: bpf attached xe0: Ethernet address: 00:80:c7:7a:d2:73 ata1-slave: FAILURE - ATAPI_IDENTIFY no interrupt ata1-slave: FAILURE - ATAPI_IDENTIFY no interrupt ata1-master: pio=0x0c wdma=0x22 udma=0xffffffff cable=40pin ATAPI_RESET time = 2910us ata1-master: setting PIO4 on Intel PIIX4 chip acd0: CDROM drive at ata1 as master acd0: read 4134KB/s (4134KB/s), 128KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA acd0: Writes: acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc Mounting root from ufs:/dev/ad0s3a start_init: trying /sbin/init --------------010005020904090605040706-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 17:53:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DF5716A4CF for ; Thu, 2 Sep 2004 17:53:01 +0000 (GMT) Received: from av9-1-sn4.m-sp.skanova.net (av9-1-sn4.m-sp.skanova.net [81.228.10.108]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D00E43D55 for ; Thu, 2 Sep 2004 17:53:01 +0000 (GMT) (envelope-from pawel.worach@telia.com) Received: by av9-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 6ABE637F37; Thu, 2 Sep 2004 19:53:00 +0200 (CEST) Received: from smtp2-1-sn4.m-sp.skanova.net (smtp2-1-sn4.m-sp.skanova.net [81.228.10.183]) by av9-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 50D0637E69; Thu, 2 Sep 2004 19:53:00 +0200 (CEST) Received: from corona.sajd.net (h197n2fls31o265.telia.com [217.208.189.197]) by smtp2-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id 2433537E45; Thu, 2 Sep 2004 19:53:00 +0200 (CEST) Received: from [127.0.0.1] (sajd@localhost [127.0.0.1]) by corona.sajd.net (8.13.1/8.13.1) with ESMTP id i82Hqwa9038008; Thu, 2 Sep 2004 19:52:58 +0200 (CEST) (envelope-from pawel.worach@telia.com) Message-ID: <41375DF9.2060105@telia.com> Date: Thu, 02 Sep 2004 19:52:57 +0200 From: Pawel Worach User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040815) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave McCammon References: <20040902151913.98772.qmail@web41414.mail.yahoo.com> In-Reply-To: <20040902151913.98772.qmail@web41414.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: 5.3 Beta2 bridging (update 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 17:53:01 -0000 Dave McCammon wrote: > When the machine boots with both cables plugged in, > traffic passes through just fine. > Except, machines on the em1(no ip) can't connect to > the bridge machine but can to machines on the other To connect to the em0 address from a host behind em1 you need to set this sysctl, net.inet.ip.check_interface=0 -- Pawel From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 18:05:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4C7A16A4CE for ; Thu, 2 Sep 2004 18:05:41 +0000 (GMT) Received: from hotmail.com (bay8-f87.bay8.hotmail.com [64.4.27.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id B60FB43D45 for ; Thu, 2 Sep 2004 18:05:41 +0000 (GMT) (envelope-from evantd@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 2 Sep 2004 11:05:41 -0700 Received: from 67.171.32.75 by by8fd.bay8.hotmail.msn.com with HTTP; Thu, 02 Sep 2004 18:05:41 GMT X-Originating-IP: [67.171.32.75] X-Originating-Email: [evantd@hotmail.com] X-Sender: evantd@hotmail.com From: "Evan Dower" To: bettan@nerim.net Date: Thu, 02 Sep 2004 11:05:41 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Sep 2004 18:05:41.0614 (UTC) FILETIME=[759438E0:01C49117] cc: freebsd-current@freebsd.org Subject: Re: netgear wg311 v2 and configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 18:05:41 -0000 No I haven't gotten around to adding WEP encryption to my network quite yet though it is on my list of things to do. In the future, please use "Reply to All" to respond to these emails so that a copy gets sent to the list. -- Evan Dower Undergraduate, Computer Science University of Washington Public key: http://students.washington.edu/evantd/pgp-pub-key.txt Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D >From: "cell" >To: "Evan Dower" >Subject: Re: netgear wg311 v2 and configuration >Date: Thu, 2 Sep 2004 17:11:25 +0200 > >And you have found how to give an webkey to this card ? >Because i obtain ndis0 : set webkey failed :/ >----- Original Message ----- >From: "Evan Dower" >To: >Cc: >Sent: Thursday, September 02, 2004 4:40 PM >Subject: Re: netgear wg311 v2 and configuration > > > > I had no problem giving it an ssid. I did however find that some things > > worked better after fresh after a restart. That is I put the appropriate > > command in /etc/start_if.ndis0 (which gets run automatically) and > > ifconfig_ndis0="DHCP" in /etc/rc.conf. When I restarted, it seemed to me > > that it picked up things it had ignored previously. Of course, you'll >need > > to autoload the firmware then as well. > > Cheers, > > -- > > Evan Dower > > Undergraduate, Computer Science > > University of Washington > > Public key: http://students.washington.edu/evantd/pgp-pub-key.txt > > Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D > > > > > > > > > > > > >From: "bettan" > > >To: "Evan Dower" > > >Subject: Re: netgear wg311 v2 and configuration > > >Date: Thu, 2 Sep 2004 10:02:27 +0200 > > > > > >Can you give a ssid with NDSulator ? I would like know if other people >can > > >because when i do "ifconfig ndis0 inet 192.168.2.1 netmask >255.255.255.0 > > >ssid test" i have with ifconfig ndis0 : > > > > > >ndis0: flags=8843 mtu 1500 > > > inet6 fe80::209:5bff:fe8f:fa5d%ndis0 prefixlen 64 scopeid 0x8 > > > inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 > > > ether 00:09:5b:8f:fa:5d > > > media: IEEE 802.11 Wireless Ethernet autoselect > > > status: no carrier > > > ssid "" > > > channel 6 authmode OPEN powersavemode OFF powersavesleep 100 > > > rtsthreshold 2312 protmode CTS > > > wepmode OFF weptxkey 1 > > > > > >ssid "" ? > > >----- Original Message ----- > > >From: "Evan Dower" > > >To: > > >Cc: > > >Sent: Thursday, September 02, 2004 3:49 AM > > >Subject: Re: netgear wg311 v2 and configuration > > > > > > > > > > You may very well be able to. I have no idea whether setting >"mediaopt > > > > hostap" will work. I have no experience with it. I do know that you > > >cannot > > > > set "mode 11g", but that there is no need, because it will >automatically > > > > associate at the highest speed it can. Since it is not a native >driver, > > > > things may not work exactly as expected. You should have several >sysctls > > >to > > > > play with, and you may need to use these instead of doing things the > > >normal > > > > way. I really have no idea. The expert would be Bill Paul (wpaul), >since > > >he > > > > just recently added the support for this card. Perhaps he'll chime >in... > > > > Sorry I couldn't be of more assistance, > > > > -- > > > > Evan Dower > > > > Undergraduate, Computer Science > > > > University of Washington > > > > Public key: http://students.washington.edu/evantd/pgp-pub-key.txt > > > > Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D > > > > > > > > > > > > > > > > > > > > > > > > >From: "bettan" > > > > >To: "Evan Dower" > > > > >Subject: Re: netgear wg311 v2 and configuration > > > > >Date: Wed, 1 Sep 2004 22:52:09 +0200 > > > > > > > > > >I can't do an access point with this card ? > > > > >----- Original Message ----- > > > > >From: "Evan Dower" > > > > >To: ; > > > > >Sent: Wednesday, September 01, 2004 10:36 PM > > > > >Subject: RE: netgear wg311 v2 and configuration > > > > > > > > > > > > > > > > I don't believe there is any need to specify the media (or mode >for > > >that > > > > > > matter). It will simply go as fast as it can. Furthermore, >setting > > >the > > > > > > stationname is still unsupported and will fail. > > > > > > Cheers, > > > > > > -- > > > > > > Evan Dower > > > > > > Undergraduate, Computer Science > > > > > > University of Washington > > > > > > Public key: >http://students.washington.edu/evantd/pgp-pub-key.txt > > > > > > Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F >887D > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >From: "bettan" > > > > > > >To: > > > > > > >Subject: netgear wg311 v2 and configuration > > > > > > >Date: Wed, 1 Sep 2004 21:10:32 +0200 > > > > > > > > > > > > > >hello , i tried to configure my wireless card and when i do : > > > > > > >ifconfig ndis0 ssid linux-win.com channel 11 media DS/54Mbps > > >mediaopt > > > > > > >hostap up stationname "FreeBSD AP" > > > > > > > > > > > > > >I have : ifconfig: unknown media subtype: DS/54Mbps > > > > > > > > > > > > > > and i don't understand why.FreeBSD supports 54 Mbps no ? Have >you > > >a > > > > > > >solution ? > > > > > > >_______________________________________________ > > > > > > >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" > > > > > > > > > > > > >_________________________________________________________________ > > > > > > Express yourself instantly with MSN Messenger! Download today - >it's > > > > >FREE! > > > > > > >hthttp://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > Don't just search. Find. Check out the new MSN Search! > > > > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > > > > > > > _______________________________________________ > > > > 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" > > > > > > > _________________________________________________________________ > > Don't just search. Find. Check out the new MSN Search! > > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > > > _______________________________________________ > > 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" > _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar – get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 18:12:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D8FE16A4CF for ; Thu, 2 Sep 2004 18:12:59 +0000 (GMT) Received: from hotmail.com (bay8-f87.bay8.hotmail.com [64.4.27.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0261F43D5D for ; Thu, 2 Sep 2004 18:12:59 +0000 (GMT) (envelope-from evantd@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 2 Sep 2004 11:12:58 -0700 Received: from 67.171.32.75 by by8fd.bay8.hotmail.msn.com with HTTP; Thu, 02 Sep 2004 18:12:58 GMT X-Originating-IP: [67.171.32.75] X-Originating-Email: [evantd@hotmail.com] X-Sender: evantd@hotmail.com From: "Evan Dower" To: bettan@nerim.net Date: Thu, 02 Sep 2004 11:12:58 -0700 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Sep 2004 18:12:58.0896 (UTC) FILETIME=[7A382900:01C49118] cc: freebsd-current@freebsd.org Subject: Re: netgear wg311 v2 and configuration X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 18:12:59 -0000 If you want everything ready to go at startup, then you will need to autoload ndis.ko, firmware.ko, and if_ndis.ko unless any of them are built into the kernel statically. Please us "Reply All" to have your emails sent to the list. Also, please read this message thread from the freebsd-current list from a couple weeks ago: http://docs.freebsd.org/cgi/mid.cgi?BAY8-F44VVZp3SIbwXO0000f1d9 -- Evan Dower Undergraduate, Computer Science University of Washington Public key: http://students.washington.edu/evantd/pgp-pub-key.txt Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D >From: "cell" >To: "Evan Dower" >Subject: Re: netgear wg311 v2 and configuration >Date: Thu, 2 Sep 2004 17:03:39 +0200 > >For run ndis0 , i kldload the firmware.ko then i kldload if_ndis.I must >autload that ? What are your command that you use in /etc/start_if.ndis0 >which gets run automatically ? > >----- Original Message ----- >From: "Evan Dower" >To: >Cc: >Sent: Thursday, September 02, 2004 4:40 PM >Subject: Re: netgear wg311 v2 and configuration > > > > I had no problem giving it an ssid. I did however find that some things > > worked better after fresh after a restart. That is I put the appropriate > > command in /etc/start_if.ndis0 (which gets run automatically) and > > ifconfig_ndis0="DHCP" in /etc/rc.conf. When I restarted, it seemed to me > > that it picked up things it had ignored previously. Of course, you'll >need > > to autoload the firmware then as well. > > Cheers, > > -- > > Evan Dower > > Undergraduate, Computer Science > > University of Washington > > Public key: http://students.washington.edu/evantd/pgp-pub-key.txt > > Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D > > > > > > > > > > > > >From: "bettan" > > >To: "Evan Dower" > > >Subject: Re: netgear wg311 v2 and configuration > > >Date: Thu, 2 Sep 2004 10:02:27 +0200 > > > > > >Can you give a ssid with NDSulator ? I would like know if other people >can > > >because when i do "ifconfig ndis0 inet 192.168.2.1 netmask >255.255.255.0 > > >ssid test" i have with ifconfig ndis0 : > > > > > >ndis0: flags=8843 mtu 1500 > > > inet6 fe80::209:5bff:fe8f:fa5d%ndis0 prefixlen 64 scopeid 0x8 > > > inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 > > > ether 00:09:5b:8f:fa:5d > > > media: IEEE 802.11 Wireless Ethernet autoselect > > > status: no carrier > > > ssid "" > > > channel 6 authmode OPEN powersavemode OFF powersavesleep 100 > > > rtsthreshold 2312 protmode CTS > > > wepmode OFF weptxkey 1 > > > > > >ssid "" ? > > >----- Original Message ----- > > >From: "Evan Dower" > > >To: > > >Cc: > > >Sent: Thursday, September 02, 2004 3:49 AM > > >Subject: Re: netgear wg311 v2 and configuration > > > > > > > > > > You may very well be able to. I have no idea whether setting >"mediaopt > > > > hostap" will work. I have no experience with it. I do know that you > > >cannot > > > > set "mode 11g", but that there is no need, because it will >automatically > > > > associate at the highest speed it can. Since it is not a native >driver, > > > > things may not work exactly as expected. You should have several >sysctls > > >to > > > > play with, and you may need to use these instead of doing things the > > >normal > > > > way. I really have no idea. The expert would be Bill Paul (wpaul), >since > > >he > > > > just recently added the support for this card. Perhaps he'll chime >in... > > > > Sorry I couldn't be of more assistance, > > > > -- > > > > Evan Dower > > > > Undergraduate, Computer Science > > > > University of Washington > > > > Public key: http://students.washington.edu/evantd/pgp-pub-key.txt > > > > Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F 887D > > > > > > > > > > > > > > > > > > > > > > > > >From: "bettan" > > > > >To: "Evan Dower" > > > > >Subject: Re: netgear wg311 v2 and configuration > > > > >Date: Wed, 1 Sep 2004 22:52:09 +0200 > > > > > > > > > >I can't do an access point with this card ? > > > > >----- Original Message ----- > > > > >From: "Evan Dower" > > > > >To: ; > > > > >Sent: Wednesday, September 01, 2004 10:36 PM > > > > >Subject: RE: netgear wg311 v2 and configuration > > > > > > > > > > > > > > > > I don't believe there is any need to specify the media (or mode >for > > >that > > > > > > matter). It will simply go as fast as it can. Furthermore, >setting > > >the > > > > > > stationname is still unsupported and will fail. > > > > > > Cheers, > > > > > > -- > > > > > > Evan Dower > > > > > > Undergraduate, Computer Science > > > > > > University of Washington > > > > > > Public key: >http://students.washington.edu/evantd/pgp-pub-key.txt > > > > > > Key fingerprint = D321 FA24 4BDA F82D 53A9 5B27 7D15 5A4F 033F >887D > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >From: "bettan" > > > > > > >To: > > > > > > >Subject: netgear wg311 v2 and configuration > > > > > > >Date: Wed, 1 Sep 2004 21:10:32 +0200 > > > > > > > > > > > > > >hello , i tried to configure my wireless card and when i do : > > > > > > >ifconfig ndis0 ssid linux-win.com channel 11 media DS/54Mbps > > >mediaopt > > > > > > >hostap up stationname "FreeBSD AP" > > > > > > > > > > > > > >I have : ifconfig: unknown media subtype: DS/54Mbps > > > > > > > > > > > > > > and i don't understand why.FreeBSD supports 54 Mbps no ? Have >you > > >a > > > > > > >solution ? > > > > > > >_______________________________________________ > > > > > > >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" > > > > > > > > > > > > >_________________________________________________________________ > > > > > > Express yourself instantly with MSN Messenger! Download today - >it's > > > > >FREE! > > > > > > >hthttp://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > Don't just search. Find. Check out the new MSN Search! > > > > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > > > > > > > _______________________________________________ > > > > 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" > > > > > > > _________________________________________________________________ > > Don't just search. Find. Check out the new MSN Search! > > http://search.msn.click-url.com/go/onm00200636ave/direct/01/ > > > > _______________________________________________ > > 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" > _________________________________________________________________ Get ready for school! Find articles, homework help and more in the Back to School Guide! http://special.msn.com/network/04backtoschool.armx From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 18:30:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41A2E16A4CE for ; Thu, 2 Sep 2004 18:30:32 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2C4243D39 for ; Thu, 2 Sep 2004 18:30:31 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i82IUSDl000347; Thu, 2 Sep 2004 11:30:29 -0700 Message-ID: <413766C4.6040407@root.org> Date: Thu, 02 Sep 2004 11:30:28 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?S=F8ren_Schmidt?= References: <20040901202321.345035D04@ptavv.es.net> <41363364.2070103@DeepCore.dk> <4136382D.9010106@root.org> <4136CCBB.8090604@DeepCore.dk> In-Reply-To: <4136CCBB.8090604@DeepCore.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: current@freebsd.org Subject: Re: ATA DVD playback hanging in physrd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 18:30:32 -0000 Søren Schmidt wrote: > Nate Lawson wrote: >> Søren Schmidt wrote: >>> On that note ACPI still locks hard both my laptops (ASUS/Acer) on >>> resume, with and upto date -current its back to not even switching on >>> the backlight, so I have no way to tell what happens. On the ASUS >>> that has a serial port even that is totally dead. >>> >>> However, commenting out the resume code in acpi_cmbat.c make it get >>> so far as to give me a prompt in singleuser mode, but just a simple >>> ls makes in crash with a double fault in the image activation of the >>> ls command, it looks like the vm system is way out to lunch somehow. >>> >> Try taking /sys/i386/acpi_wakeup.c back to 1.36. > > That makes things worse actually, now I dont get back from resume, I do > get my backlight turned on though :) Did you do this change alone or with leave cmbat resume commented out? > If that doesn't work, > >> try reverting /sys/dev/acpica/acpi.c back to 2004/8/1 (mentioned >> previously). It is important to isolate the cause. > > That doesn't work, the rest of the code has changed so it wont compile.. It shouldn't require too much munging to work by itself. >> I'm working on the cmbat resume part for you. The reason why this is >> not an easy problem to debug is that different systems have different >> AML and that AML is run by various methods, including cmbat. If it >> does weird things like writing to various runtime registers or >> acquiring mutexes, it can cause failures independent of our code. My >> laptop suspends/resumes fine with -current, including hotplugging the >> batteries, etc. > > On that note, it doesn't see when I hotplug my second battery, however > doing a acpiconf -i 0/1 makes it appear properly.. That is working correctly for the current implementation. Full hotplug support including docking is in a private tree but won't be committed until after 5.3. -- Nate From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 18:38:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3B0116A4CE for ; Thu, 2 Sep 2004 18:38:38 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99F5643D39 for ; Thu, 2 Sep 2004 18:38:38 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i82IcYDl000439; Thu, 2 Sep 2004 11:38:36 -0700 Message-ID: <413768A9.4020904@root.org> Date: Thu, 02 Sep 2004 11:38:33 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (Windows/20040803) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus Brueffer Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: Interrupt storm on uhciX with acpi_pci_link.c 1.24.2.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 18:38:38 -0000 Your ASL is at fault here. It defines a mixed set of APIC and PCI link irq devices. (See the _PRT for PCI0, the APIC object). The MPtable is correct. Here is the part that is wrong: Name (APIC, Package (0x18) { ... Package (0x04) { 0x0004FFFF, 0x03, \_SB.LNKC, 0x00 }, This one should be: Package (0x04) { 0x0004FFFF, 0x03, 0x00, 0x12, } It should be possible to add this to /boot/loader.conf: hw.acpi.pci.link.0.4.3.irq="18" But since 18 won't be in your list of valid irqs, your best bet is to patch your ASL as above and recompile with iasl. Perhaps a BIOS upgrade will have this fixed? -- Nate From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 19:23:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED89716A4CF; Thu, 2 Sep 2004 19:23:52 +0000 (GMT) Received: from mail.imp.ch (ns1.imp.ch [157.161.1.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9587F43D1D; Thu, 2 Sep 2004 19:23:51 +0000 (GMT) (envelope-from pg@imp.ch) Received: from nbs.imp.ch (nbs.imp.ch [157.161.4.7]) by mail.imp.ch (8.12.9p2/8.12.3) with ESMTP id i82JNgGG050663; Thu, 2 Sep 2004 21:23:43 +0200 (CEST) (envelope-from pg@imp.ch) Received: from murphy.imp.ch (murphy.imp.ch [157.161.4.77]) by nbs.imp.ch (8.12.10/8.12.3) with ESMTP id i82JNfir43576804; Thu, 2 Sep 2004 21:23:41 +0200 (MES) Date: Thu, 2 Sep 2004 21:20:23 +0000 (UTC) From: Patrick Guelat X-X-Sender: patg@murphy.imp.ch To: Robert Watson In-Reply-To: Message-ID: <20040902211406.I19478@murphy.imp.ch> References: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-705649812-1094160023=:19478" X-Spam-Checksum: bd23584c245387dee10c005bccc2bcce X-Virus-Message-Status: No X-Virus-Status: No, scantime="0.0014 seconds" X-Spam-Status: No, hits=-5.9 required=5 scantime="2.8912 seconds" tests=BAYES_00, SMILEY X-Scanned-By: MIMEDefang 2.44 cc: freebsd-current@freebsd.org Subject: Re: Panic in propagate_priority() [5.3-BETA2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 19:23:53 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-705649812-1094160023=:19478 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Thu, 2 Sep 2004, Robert Watson wrote: >> exclusive sleep mutex rip r=1 (0xc079e70c) locked @ /usr/src53/sys/netinet6/raw_ip.c:255 > > Ah, indeed, there's an incorrect "lock" instead of "unlock" there. Could > you try the attached patch: Thanks. Your patch works like a dream. I looked a that line a dozen times and didn't realize it was a lock instead of an unlock ;-) I was just wondering why you're using the same lock in IPv4 and IPv6 and if this probably may cause problems in ipv6 over ipv4 situations. Tested on RELENG_5 -Patrick > > Index: raw_ip6.c > =================================================================== > RCS file: /data/fbsd-cvs/ncvs/src/sys/netinet6/raw_ip6.c,v > retrieving revision 1.45 > diff -u -r1.45 raw_ip6.c > --- raw_ip6.c 12 Aug 2004 18:31:36 -0000 1.45 > +++ raw_ip6.c 2 Sep 2004 12:55:19 -0000 > @@ -252,7 +252,7 @@ > } > ip6stat.ip6s_delivered--; > } > - INP_INFO_RLOCK(&ripcbinfo); > + INP_INFO_RUNLOCK(&ripcbinfo); > return IPPROTO_DONE; > } -- Patrick Guélat, ImproWare AG Network Services, CH-4133 Pratteln Mail: Patrick.Guelat@imp.ch - Phone: +41 61 826 93 00 (ext: 13) --0-705649812-1094160023=:19478-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 19:44:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEB2716A4CE for ; Thu, 2 Sep 2004 19:44:29 +0000 (GMT) Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9928943D31 for ; Thu, 2 Sep 2004 19:44:29 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 16417 invoked from network); 2 Sep 2004 19:44:29 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 2 Sep 2004 19:44:27 -0000 Received: from [10.50.41.228] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i82JiGS6069754; Thu, 2 Sep 2004 15:44:24 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Andrew Gallatin Date: Thu, 2 Sep 2004 14:17:03 -0400 User-Agent: KMail/1.6.2 References: <412FB9FC.8030505@root.org> <200409011632.59507.jhb@FreeBSD.org> <16694.27210.415965.951382@grasshopper.cs.duke.edu> In-Reply-To: <16694.27210.415965.951382@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409021417.03152.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: freebsd-current@FreeBSD.org Subject: Re: spurrious interrupt problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 19:44:29 -0000 On Wednesday 01 September 2004 08:33 pm, Andrew Gallatin wrote: > John Baldwin writes: > > On Friday 27 August 2004 06:47 pm, Nate Lawson wrote: > > > I don't see anything wrong with your acpi pci link routing. In fact, > > > all your irqs are hardwired meaning acpi shouldn't touch them. This > > > must be something with ioapic. (BTW, acpi is non-optional on amd64). > > > > Talk to phk@. He had an opteron motherboard that had a busted BIOS that > > left the links between PCI IRQs that are used in atpic mode setup even > > when in apic mode so that you get 'alias' IRQs in apic mode. In his > > case the vendor provided a BIOS update that fixed the issue. > > I had our onsite guy update the bios, but that ended up disabling USB. > So its "fixed".. ;) Ouch. :-P -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 19:55:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F04B16A4CF for ; Thu, 2 Sep 2004 19:55:45 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC87143D66 for ; Thu, 2 Sep 2004 19:55:44 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i82JuJxW012669 for ; Thu, 2 Sep 2004 12:56:19 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i82JuJ9c012668 for current@freebsd.org; Thu, 2 Sep 2004 12:56:19 -0700 Date: Thu, 2 Sep 2004 12:56:19 -0700 From: Brooks Davis To: current@freebsd.org Message-ID: <20040902195619.GC10756@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hOcCNbCCxyk/YU74" Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Subject: HEADS UP: ifi_epoch backout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 19:55:45 -0000 --hOcCNbCCxyk/YU74 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I've backed out the addition of ifi_epoch to struct if_data. The ABI breakage was causing too much trouble this close to 5-STABLE. If you updated your system with source from between Aug 30 06:29:26 2004 UTC and Sep 2 05:07:29 2004 UTC, you have an ifconfig that will not work with a kernel outside those dates. See the updating entry for 20040830 for more details. -- Brooks ----- Forwarded message from Brooks Davis ----- From: Brooks Davis Date: Thu, 2 Sep 2004 05:07:37 +0000 (GMT) To: brooks@FreeBSD.ORG X-Virus-Status: No Subject: [src] cvs commit: src UPDATING src/sys/net if.c if.h brooks 2004-09-02 05:07:29 UTC FreeBSD src repository Modified files: . UPDATING=20 sys/net if.c if.h=20 Log: Back out ifi_epoch. The ABI breakage is too disruptive this close to 5-STABLE. ifi_epoch will shortly be reintroduced with less precistion using the space currently allocated to ifi_unused. =20 Revision Changes Path 1.354 +8 -0 src/UPDATING 1.204 +0 -1 src/sys/net/if.c 1.91 +0 -1 src/sys/net/if.h Index: src/UPDATING diff -u src/UPDATING:1.353 src/UPDATING:1.354 --- src/UPDATING:1.353 Wed Sep 1 15:14:13 2004 +++ src/UPDATING Thu Sep 2 05:07:29 2004 @@ -23,6 +23,14 @@ developers choose to disable these features on build machines to maximize performance. =20 +20040902: + The ifi_epoch change has been reverted because the ABI breakage + was too extensive. If you are running with a kernel/userland + containing the initial change (20040830), you should heed the + warning about ifconfig incompatibility when upgrading again. + With this change, 5.3 and 6.0 ifconfigs and kernels are once + again interoperable. + 20040830: A new variable, ifi_epoch, has been added to struct if_data which is part if struct ifnet. This means all network drivers @@ -1830,4 +1838,4 @@ Contact Warner Losh if you have any questions about your use of this document. =20 -$FreeBSD: /repoman/r/ncvs/src/UPDATING,v 1.353 2004/09/01 15:14:13 brooks = Exp $ +$FreeBSD: /repoman/r/ncvs/src/UPDATING,v 1.354 2004/09/02 05:07:29 brooks = Exp $ Index: src/sys/net/if.c diff -u src/sys/net/if.c:1.203 src/sys/net/if.c:1.204 --- src/sys/net/if.c:1.203 Wed Sep 1 19:56:47 2004 +++ src/sys/net/if.c Thu Sep 2 05:07:29 2004 @@ -27,7 +27,7 @@ * SUCH DAMAGE. * * @(#)if.c 8.5 (Berkeley) 1/9/95 - * $FreeBSD: /repoman/r/ncvs/src/sys/net/if.c,v 1.203 2004/09/01 19:56:47 = mlaier Exp $ + * $FreeBSD: /repoman/r/ncvs/src/sys/net/if.c,v 1.204 2004/09/02 05:07:29 = brooks Exp $ */ =20 #include "opt_compat.h" @@ -387,7 +387,6 @@ TAILQ_INIT(&ifp->if_multiaddrs); knlist_init(&ifp->if_klist, NULL); getmicrotime(&ifp->if_lastchange); - getmicrotime(&ifp->if_data.ifi_epoch); =20 #ifdef MAC mac_init_ifnet(ifp); Index: src/sys/net/if.h diff -u src/sys/net/if.h:1.90 src/sys/net/if.h:1.91 --- src/sys/net/if.h:1.90 Wed Sep 1 18:22:14 2004 +++ src/sys/net/if.h Thu Sep 2 05:07:29 2004 @@ -27,7 +27,7 @@ * SUCH DAMAGE. * * @(#)if.h 8.1 (Berkeley) 6/10/93 - * $FreeBSD: /repoman/r/ncvs/src/sys/net/if.h,v 1.90 2004/09/01 18:22:14 b= rooks Exp $ + * $FreeBSD: /repoman/r/ncvs/src/sys/net/if.h,v 1.91 2004/09/02 05:07:29 b= rooks Exp $ */ =20 #ifndef _NET_IF_H_ @@ -104,7 +104,6 @@ u_long ifi_hwassist; /* HW offload capabilities */ u_long ifi_unused; /* XXX was ifi_xmittiming */ struct timeval ifi_lastchange; /* time of last administrative change */ - struct timeval ifi_epoch; /* time of creation or stat reset */ }; =20 #define IFF_UP 0x1 /* interface is up */ ----- End forwarded message ----- --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --hOcCNbCCxyk/YU74 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBN3riXY6L6fI4GtQRAlHrAKDLfGO7C/NuNYzc0hTDuorJ1W2GdQCfS3r+ j7ztZFY1ZkUabH1cwfmmf+k= =1YIW -----END PGP SIGNATURE----- --hOcCNbCCxyk/YU74-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 20:10:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D711816A4CE for ; Thu, 2 Sep 2004 20:10:12 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2304143D45 for ; Thu, 2 Sep 2004 20:10:12 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id C1DE41FF91D; Thu, 2 Sep 2004 22:10:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id D377F1FF9A6; Thu, 2 Sep 2004 22:10:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 5CF2C15682; Thu, 2 Sep 2004 20:09:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 51E2515329; Thu, 2 Sep 2004 20:09:59 +0000 (UTC) Date: Thu, 2 Sep 2004 20:09:57 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: Vaidas Damosevicius In-Reply-To: <20040902055633.4081A3D11C@mail.if.lt> Message-ID: References: <20040902055633.4081A3D11C@mail.if.lt> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: freebsd-current@freebsd.org Subject: Re: [BETA2] lock order reversal X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 20:10:12 -0000 On Thu, 2 Sep 2004, Vaidas Damosevicius wrote: Hi, > ..., > > lock order reversal > 1st 0xc1a756e8 re0 (network driver) @ /usr/src/sys/dev/re/if_re.c:830 > 2nd 0xc0a18060 ACPI root bus (ACPI root bus) @ /usr/src/sys/modules/acpi/acpi/../../../dev/acpica/acpi.c:841 already reported before, see http://sources.zabbadoz.net/freebsd/lor.html#026 -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 20:15:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F87716A4CE for ; Thu, 2 Sep 2004 20:15:08 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 268D343D39 for ; Thu, 2 Sep 2004 20:15:08 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 7061A1FF9A6; Thu, 2 Sep 2004 22:15:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 675E61FF92F; Thu, 2 Sep 2004 22:15:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id BC8A515682; Thu, 2 Sep 2004 20:11:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id B9B8A15329; Thu, 2 Sep 2004 20:11:13 +0000 (UTC) Date: Thu, 2 Sep 2004 20:11:13 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: =?ISO-8859-1?Q?Tommi_L=E4tti?= In-Reply-To: <4136CF5A.5010600@iki.fi> Message-ID: References: <4136CE19.5020804@iki.fi> <4136CF5A.5010600@iki.fi> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: freebsd-current@freebsd.org Subject: Re: strange crashes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 20:15:08 -0000 On Thu, 2 Sep 2004, Tommi L=E4tti wrote: > Forgot to mention that there's always a lock order reversal in an hour > after boot: > > lock order reversal > 1st 0xc488def4 vm object (vm object) @ /usr/src/sys/vm/swap_pager.c:132= 3 > 2nd 0xc06ac3e0 swap_pager swhash (swap_pager swhash) @ > /usr/src/sys/vm/swap_pager.c:1838 > 3rd 0xc0c358c4 vm object (vm object) @ /usr/src/sys/vm/uma_core.c:873 please read http://sources.zabbadoz.net/freebsd/lor.html#001 this is most likely not the cause for any crash. --=20 Bjoern A. Zeeb=09=09=09=09bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 20:20:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6126316A4CE for ; Thu, 2 Sep 2004 20:20:45 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6E3543D41 for ; Thu, 2 Sep 2004 20:20:44 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i82KI5Vm059852; Thu, 2 Sep 2004 16:18:05 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i82KI51s059849; Thu, 2 Sep 2004 16:18:05 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Thu, 2 Sep 2004 16:18:05 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Patrick Guelat In-Reply-To: <20040902211406.I19478@murphy.imp.ch> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE cc: freebsd-current@freebsd.org Subject: Re: Panic in propagate_priority() [5.3-BETA2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 20:20:45 -0000 On Thu, 2 Sep 2004, Patrick Guelat wrote: > On Thu, 2 Sep 2004, Robert Watson wrote: >=20 > >> exclusive sleep mutex rip r=3D1 (0xc079e70c) locked @ /usr/src53/sys/n= etinet6/raw_ip.c:255 > > > > Ah, indeed, there's an incorrect "lock" instead of "unlock" there. Cou= ld > > you try the attached patch: >=20 > Thanks. Your patch works like a dream. I looked a that line a dozen > times and didn't realize it was a lock instead of an unlock ;-) Great -- I've merged to HEAD and will merge to RELENG_5 in a couple of days once it has settled. > I was just wondering why you're using the same lock in IPv4 and IPv6 and > if this probably may cause problems in ipv6 over ipv4 situations. This was a design choice I inherited from those working on the network stack locking previously, but it actually makes some amount of sense: the IPv4 and IPv6 implementations share a lot of infrastructure, including protocol control blocks lists for most protocols. I.e., UDP, TCP, et al.= =20 This includes raw IP sockets. Since the same structures are use, the same locks must also be used. I agree there are potential layering issues, especially relating to IPv4/IPv6 tunneling, which may already be addressed by queued dispatch (i.e., asynchronous processing of the tunneled packet to avoid both lock orders and general recursion problems). Thanks! Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research >=20 > Tested on RELENG_5 >=20 > -Patrick >=20 > > > > Index: raw_ip6.c > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > RCS file: /data/fbsd-cvs/ncvs/src/sys/netinet6/raw_ip6.c,v > > retrieving revision 1.45 > > diff -u -r1.45 raw_ip6.c > > --- raw_ip6.c=0912 Aug 2004 18:31:36 -0000=091.45 > > +++ raw_ip6.c=092 Sep 2004 12:55:19 -0000 > > @@ -252,7 +252,7 @@ > > =09=09} > > =09=09ip6stat.ip6s_delivered--; > > =09} > > -=09INP_INFO_RLOCK(&ripcbinfo); > > +=09INP_INFO_RUNLOCK(&ripcbinfo); > > =09return IPPROTO_DONE; > > } > -- > Patrick Gu=E9lat, ImproWare AG Network Services, CH-4133 Pratteln > Mail: Patrick.Guelat@imp.ch - Phone: +41 61 826 93 00 (ext: 13) From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 20:21:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16D7F16A4CE for ; Thu, 2 Sep 2004 20:21:12 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68B5A43D2D for ; Thu, 2 Sep 2004 20:21:11 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id i82KL7R2037841; Thu, 2 Sep 2004 22:21:07 +0200 (CEST) (envelope-from sos@DeepCore.dk) Message-ID: <41378092.1090406@DeepCore.dk> Date: Thu, 02 Sep 2004 22:20:34 +0200 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nate Lawson References: <20040901202321.345035D04@ptavv.es.net> <41363364.2070103@DeepCore.dk> <4136382D.9010106@root.org> <4136CCBB.8090604@DeepCore.dk> <413766C4.6040407@root.org> In-Reply-To: <413766C4.6040407@root.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable cc: current@freebsd.org Subject: Re: ATA DVD playback hanging in physrd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 20:21:12 -0000 Nate Lawson wrote: >>>> On that note ACPI still locks hard both my laptops (ASUS/Acer) on=20 >>>> resume, with and upto date -current its back to not even switching=20 >>>> on the backlight, so I have no way to tell what happens. On the ASUS= =20 >>>> that has a serial port even that is totally dead. >>>> >>>> However, commenting out the resume code in acpi_cmbat.c make it get = >>>> so far as to give me a prompt in singleuser mode, but just a simple = >>>> ls makes in crash with a double fault in the image activation of the= =20 >>>> ls command, it looks like the vm system is way out to lunch somehow.= >>>> >>> Try taking /sys/i386/acpi_wakeup.c back to 1.36. >> >> That makes things worse actually, now I dont get back from resume, I=20 >> do get my backlight turned on though :) >=20 > Did you do this change alone or with leave cmbat resume commented out? Commented ouit or it doesn't get anywhere on resume.. >> If that doesn't work, >> >>> try reverting /sys/dev/acpica/acpi.c back to 2004/8/1 (mentioned=20 >>> previously). It is important to isolate the cause. >> >> That doesn't work, the rest of the code has changed so it wont compile= =2E. >=20 > It shouldn't require too much munging to work by itself. Hmm, didn't look too closely but it looked like defines had changed etc, = multiple pages of errors so I didn't look any further.. -S=F8ren From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 20:39:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A3A116A4CE for ; Thu, 2 Sep 2004 20:39:13 +0000 (GMT) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0114E43D45 for ; Thu, 2 Sep 2004 20:39:13 +0000 (GMT) (envelope-from ben@stuyts.com) Received: from [10.0.0.5] (stuyts.xs4all.nl [80.126.99.173]) by smtp-vbr6.xs4all.nl (8.12.11/8.12.11) with ESMTP id i82KdBoq037348 for ; Thu, 2 Sep 2004 22:39:11 +0200 (CEST) (envelope-from ben@stuyts.com) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <41365CA5.2000300@cs.unisa.edu.au> References: <41365CA5.2000300@cs.unisa.edu.au> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <239F1814-FD20-11D8-81F3-000A959CFF76@stuyts.com> Content-Transfer-Encoding: 7bit From: Ben Stuyts Date: Thu, 2 Sep 2004 22:39:08 +0200 To: current@freebsd.org X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: atacontrol rebuild, how? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 20:39:13 -0000 On 2 Sep 2004, at 01:35, Benjamin Close wrote: > Perhaps something worth trying is the following - It's what I have to > do to get the promisc card I use to rebuild: > > - Identify the channel the drive is on (ie ad6 on ata3) > > atacontrol detach ata3 > atacontrol attach ata3 > atacontrol addspare ar0 ad6 That was it, I didn't do the addspare. Also, it seems you HAVE to do the detach/attach commands, otherwise it won't work. > atacontrol rebuild > > The command exits straight away but if you run: atacontrol status ar0 > I get a 'REBUILDING 0%' message Yes, it looks ok now. Many thanks, Ben > Also checking the ps output shows a rebuild thread. > > Might work, for you. > > Cheers, > Benjamin > > Ben Stuyts wrote: > >> Hi, >> >> I have installed beta-2 (31082004) on a Supermicro 5013C-T (P4SCE >> motherboard with ICH5R, and two WD 74 GB Raptor SATA drives, which I >> want to mirror). >> >> I know the ICH5R is not a real raid controller, but I'm trying to get >> it to work using atacontrol and the built-in RAID1 support. >> >> Using the procedure described in >> http://www.techno-obscura.com/~delgado/notes/fbsd-ich5SATAraid.html >> (thanks!) I managed to get FreeBSD installed on RAID1 on ar0. >> >> Next I tried to remove a drive (atacontrol detach), and even zeroed >> the first area of the disk. After reattaching the drive, I cannot get >> atacontrol to rebuild the drive. If I do atacontrol rebuild ar0, it >> does absolutely nothing. From browsing this mailing list I see that >> this seems to be a problem with using non-raid controllers, but will >> this be improved in the future? Or am I doing something wrong? >> >> What other options do I have? Is geom-vinum ready for this? All I >> want is a fully mirrored system (incl root and swap). >> >> I could put a simple raid controller in, like the Promise S150 >> TX2Plus or TX4, but if I can get it to work with the ICH5R controller >> that would be great. >> >> Thanks, >> Ben >> >> _______________________________________________ >> 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" > > > > -- > 3D Research Associate / System Administrator +61 8 8302 3669 > School of Computer and Information Science Room D1-07, ML Campus > University of South Australia Mawson Lakes Blvd. Benjamin.Close@cs.unisa.edu.au South Australia, 5095 > F00D C83D 5F7E 5561 DF91 B74D E602 CAA3 4842 B5B4 From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 21:19:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CAFE16A4CE for ; Thu, 2 Sep 2004 21:19:29 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E14543D5C for ; Thu, 2 Sep 2004 21:19:28 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i82LJQd1061159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 Sep 2004 01:19:26 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i82LJQaN061158 for current@freebsd.org; Fri, 3 Sep 2004 01:19:26 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Fri, 3 Sep 2004 01:19:25 +0400 From: Gleb Smirnoff To: current@freebsd.org Message-ID: <20040902211925.GA61127@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: top broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 21:19:29 -0000 I've noticed today that CURRENT dated Aug 29, with ULE scheduler does not show WCPU/CPU in top at all. However, process time of CPU consumers grows. last pid: 16552; load averages: 0.59, 0.22, 0.19 up 4+07:26:38 01:17:35 17 processes: 1 running, 16 sleeping CPU states: 12.9% user, 0.0% nice, 1.2% system, 25.8% interrupt, 60.2% idle Mem: 8996K Active, 227M Inact, 88M Wired, 692K Cache, 60M Buf, 172M Free Swap: 1024M Total, 1024M Free PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 1224 glebius 76 0 1304K 820K select 3:42 0.00% 0.00% ehntserv 365 root 76 0 3464K 2808K select 0:07 0.00% 0.00% sendmail 16551 root -58 0 5160K 3964K bpf 0:03 0.00% 0.00% tcpdump 381 root 8 0 1360K 1080K nanslp 0:01 0.00% 0.00% cron 244 root 76 0 1316K 888K select 0:01 0.00% 0.00% syslogd 324 root 76 0 1240K 784K select 0:01 0.00% 0.00% usbd 369 smmsp 20 0 3344K 2712K pause 0:00 0.00% 0.00% sendmail 359 root 139 0 3364K 2536K select 0:00 0.00% 0.00% sshd 16535 glebius 76 0 6124K 3000K select 0:00 0.00% 0.00% sshd 16533 root 4 0 6124K 2948K sbwait 0:00 0.00% 0.00% sshd 16544 root 8 0 2208K 1900K wait 0:00 0.00% 0.00% bash 16552 root 76 0 2280K 1572K RUN 0:00 0.00% 0.00% top 16536 glebius 8 0 2200K 1888K wait 0:00 0.00% 0.00% bash 16540 glebius 8 0 1604K 1300K wait 0:00 0.00% 0.00% su 416 root 5 0 1284K 956K ttyin 0:00 0.00% 0.00% getty 415 root 5 0 1284K 956K ttyin 0:00 0.00% 0.00% getty 224 root 79 0 512K 376K select 0:00 0.00% 0.00% devd -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 21:21:40 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13C6516A4D1 for ; Thu, 2 Sep 2004 21:21:40 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD26F43D5C for ; Thu, 2 Sep 2004 21:21:39 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 21305 invoked from network); 2 Sep 2004 21:21:39 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 2 Sep 2004 21:21:39 -0000 Received: from [10.50.41.228] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i82LLOmb070450; Thu, 2 Sep 2004 17:21:35 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Ken Smith Date: Thu, 2 Sep 2004 17:14:42 -0400 User-Agent: KMail/1.6.2 References: <200407151424.i6FEOdoq060881@fledge.watson.org> <20040715220447.GA32888@xor.obsecurity.org> <20040902155947.GA12006@electra.cse.Buffalo.EDU> In-Reply-To: <20040902155947.GA12006@electra.cse.Buffalo.EDU> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409021714.42674.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: re@FreeBSD.org cc: current@FreeBSD.org cc: Kris Kennaway Subject: Re: 5.3-RELEASE TODO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 21:21:40 -0000 On Thursday 02 September 2004 11:59 am, Ken Smith wrote: > > * --- > > Fatal trap 12: page fault while in kernel mode > > fault virtual address = 0x104 > > fault code = supervisor read, page not present > > instruction pointer = 0x8:0xc058a8cf > > stack pointer = 0x10:0xdcb34cc4 > > frame pointer = 0x10:0xdcb34cec > > code segment = base 0x0, limit 0xfffff, type 0x1b > > = DPL 0, pres 1, def32 1, gran 1 > > processor eflags = resume, IOPL = 0 > > current process = 50 (schedcpu) > > trap number = 12 > > panic: page fault > > > > syncing disks, buffers remaining... panic: mi_switch: switch in a > > critical section > > > > addr2line says the panic was in kern/sched_4bsd.c:327 > > > > /* > > * The kse slptimes are not touched in > > wakeup * because the thread may not HAVE a KSE. */ > > if (ke->ke_state == KES_ONRUNQ) { > > awake = 1; > > ke->ke_flags &= ~KEF_DIDRUN; > > ---> } else if ((ke->ke_state == KES_THREAD) > > && (TD_IS_RUNNING(ke->ke_thread))) { awake = 1; > > > > gdb -k got confused and couldn't make anything out of the backtrace. > > The code you quote above hasn't changed recently but a few kse related > fixes have gone in recently if I recall correctly. Is this one still > biting you? This seems to be a symptom of the same bug that causes runq corruption when PREEMPTION is turned on. I think it might have triggered on SMP w/o PREEMPTION turned on however. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Sep 2 23:54:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D840E16A4CE for ; Thu, 2 Sep 2004 23:54:37 +0000 (GMT) Received: from web41413.mail.yahoo.com (web41413.mail.yahoo.com [66.218.93.79]) by mx1.FreeBSD.org (Postfix) with SMTP id AE11243D39 for ; Thu, 2 Sep 2004 23:54:37 +0000 (GMT) (envelope-from davemac11@yahoo.com) Message-ID: <20040902235437.2734.qmail@web41413.mail.yahoo.com> Received: from [168.91.4.66] by web41413.mail.yahoo.com via HTTP; Thu, 02 Sep 2004 16:54:37 PDT Date: Thu, 2 Sep 2004 16:54:37 -0700 (PDT) From: Dave McCammon To: Pawel Worach In-Reply-To: <41375DF9.2060105@telia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-current@freebsd.org Subject: Re: 5.3 Beta2 bridging (update 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 02 Sep 2004 23:54:38 -0000 --- Pawel Worach wrote: > Dave McCammon wrote: > > When the machine boots with both cables plugged > in, > > traffic passes through just fine. > > Except, machines on the em1(no ip) can't connect > to > > the bridge machine but can to machines on the > other > > To connect to the em0 address from a host behind em1 > you > need to set this sysctl, > net.inet.ip.check_interface=0 > Thanks. Takes care of that. Is that in a man page somewhere? It's not set like that(net.inet.ip.check_interface=1) in 4.10. _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 00:42:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4403A16A4CE; Fri, 3 Sep 2004 00:42:47 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id BCE6943D3F; Fri, 3 Sep 2004 00:42:46 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id i830gk41026858; Thu, 2 Sep 2004 20:42:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i830gjUU020142; Thu, 2 Sep 2004 20:42:45 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 043FD7303F; Thu, 2 Sep 2004 20:42:45 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040903004245.043FD7303F@freebsd-current.sentex.ca> Date: Thu, 2 Sep 2004 20:42:45 -0400 (EDT) Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2004 00:42:47 -0000 TB --- 2004-09-02 23:17:59 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-02 23:17:59 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-09-02 23:17:59 - checking out the source tree TB --- 2004-09-02 23:17:59 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2004-09-02 23:17:59 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-02 23:22:59 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-02 23:22:59 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2004-09-02 23:22:59 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-09-03 00:25:53 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-03 00:25:53 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2004-09-03 00:25:53 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Sep 3 00:25:53 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Sep 3 00:37:07 UTC 2004 TB --- 2004-09-03 00:37:07 - generating LINT kernel config TB --- 2004-09-03 00:37:07 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- 2004-09-03 00:37:07 - /usr/bin/make -B LINT TB --- 2004-09-03 00:37:07 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-03 00:37:07 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2004-09-03 00:37:07 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Sep 3 00:37:07 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/zs/zs_sbus.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/fs/autofs/autofs_vnops.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/fs/autofs/autofs_vnops.c: In function `autofs_remove_dupdents': /tinderbox/CURRENT/sparc64/sparc64/src/sys/fs/autofs/autofs_vnops.c:593: warning: int format, different type arg (arg 3) /tinderbox/CURRENT/sparc64/sparc64/src/sys/fs/autofs/autofs_vnops.c:593: warning: int format, different type arg (arg 4) /tinderbox/CURRENT/sparc64/sparc64/src/sys/fs/autofs/autofs_vnops.c:593: warning: int format, different type arg (arg 5) /tinderbox/CURRENT/sparc64/sparc64/src/sys/fs/autofs/autofs_vnops.c:625: warning: int format, different type arg (arg 2) /tinderbox/CURRENT/sparc64/sparc64/src/sys/fs/autofs/autofs_vnops.c:625: warning: int format, different type arg (arg 3) *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-09-03 00:42:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-03 00:42:45 - ERROR: failed to build lint kernel TB --- 2004-09-03 00:42:45 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 00:54:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94F4716A4CE for ; Fri, 3 Sep 2004 00:54:41 +0000 (GMT) Received: from smtp.tal.de (s05.tal.de [81.92.0.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id A98E543D39 for ; Fri, 3 Sep 2004 00:54:40 +0000 (GMT) (envelope-from markus@brueffer.de) Received: from ramses.kicks-ass.net (unknown [82.139.198.15]) by smtp.tal.de (SMTP.TAL.DE) with ESMTP id C79123A174; Fri, 3 Sep 2004 02:54:38 +0200 (CEST) Received: from cheops.phoenix (cheops.phoenix [192.168.1.3]) by ramses.kicks-ass.net (Postfix) with ESMTP id 0BCA8B80B; Fri, 3 Sep 2004 02:54:46 +0200 (CEST) From: Markus Brueffer To: Nate Lawson Date: Fri, 3 Sep 2004 02:54:54 +0200 User-Agent: KMail/1.6.82 References: <413768A9.4020904@root.org> In-Reply-To: <413768A9.4020904@root.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1166343.av0AS57rty"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409030255.00577.markus@brueffer.de> cc: current@freebsd.org Subject: Re: Interrupt storm on uhciX with acpi_pci_link.c 1.24.2.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 00:54:41 -0000 --nextPart1166343.av0AS57rty Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Nate, On Thursday 02 September 2004 20:38, Nate Lawson wrote: > Your ASL is at fault here. It defines a mixed set of APIC and PCI link > irq devices. (See the _PRT for PCI0, the APIC object). The MPtable is > correct. Here is the part that is wrong: > > Name (APIC, Package (0x18) > { > ... > Package (0x04) > { > 0x0004FFFF, > 0x03, > \_SB.LNKC, > 0x00 > }, > > This one should be: > > Package (0x04) > { > 0x0004FFFF, > 0x03, > 0x00, > 0x12, > } > > It should be possible to add this to /boot/loader.conf: > > hw.acpi.pci.link.0.4.3.irq=3D"18" As you already expected, this doesn't work. > But since 18 won't be in your list of valid irqs, your best bet is to > patch your ASL as above and recompile with iasl.=20 Patching the ASL did the trick. Thank you very much! While compiling tha ASL I got the following warning: markus-cuv4x-d.asl.patched 316: Method (\_WAK, 1, NotSerialized) Warning 2026 - ^ Reserved method must=20 return a value (_WAK) Maybe this information is of some use for you. > Perhaps a BIOS upgrade will have this fixed? I already have the latest BIOS installed and I doubt that there will be a n= ew=20 one in the future (the current one is from mid 2002) :( Best regards, Markus =2D-=20 Markus Brueffer | GPG-Key: http://people.FreeBSD.org/~markus/markus.asc markus@brueffer.de | FP: 3F9B EBE8 F290 E5CC 1447 8760 D48D 1072 78F8 A8D4 markus@FreeBSD.org | FreeBSD: The Power to Serve! --nextPart1166343.av0AS57rty Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBBN8Dk1I0Qcnj4qNQRAoTgAKDYIKqFh0zFK2oLJUos5RFgmqEErgCgrR5U Delv5ZtpUCmifvOQrZDpn4k= =BY2T -----END PGP SIGNATURE----- --nextPart1166343.av0AS57rty-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 01:34:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D91D416A4CE for ; Fri, 3 Sep 2004 01:34:41 +0000 (GMT) Received: from obh.snafu.de (obh.snafu.de [213.73.92.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1EFD43D41 for ; Fri, 3 Sep 2004 01:34:38 +0000 (GMT) (envelope-from ob@gruft.de) Received: from ob by obh.snafu.de with local (Exim 4.34 (FreeBSD)) id 1C32y8-0004QY-PI for current@freebsd.org; Fri, 03 Sep 2004 03:34:24 +0200 Date: Fri, 3 Sep 2004 03:34:24 +0200 From: Oliver Brandmueller To: current@freebsd.org Message-ID: <20040903013424.GA57576@e-Gitt.NET> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Sender: Oliver Brandmueller Subject: mysql on recent RELENG_5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 01:34:42 -0000 Hi, I see a little problem with either mysql-server 3.23 or 4.1.3 on a RELENG_5 as of about 12 hours ago: mysql runs fine so far, but as soon as I do not connect by socket, but by network on localhost (127.0.0.1) the mysqld dies by sig11 (and is the restarted automatically by the wrapper). I tried ULE and 4BSD, I tried a mysql 3.23 from package. I tried compiling 3.23 and 4.1.3 (did not try 4.1.4 which just arrived at the ports a few hours ago) "just plain", with BUILD_OPTIMIZED, with WITH_LINUXTHREADS defined and saw now difference. I also changed libpthread to libc_r by libmap.conf and had no difference. I'm currently a bit under pressure to get things running (I need MySQL for Nagios, this means I could live without it), so I just want to know if anyone else can reproduce this behaviour? If you have a similar setup it's enough to just telnet to port 3306 on localhost, if you see mysqld closing the connection at once and see in the mysql log that the server has been restarted because of a sig11 then you see the same thing. Well, if everything works for you I'd be interested in working out the differences of our configs. Thanx, Oliver -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 01:46:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64FD516A4CE for ; Fri, 3 Sep 2004 01:46:27 +0000 (GMT) Received: from obh.snafu.de (obh.snafu.de [213.73.92.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEC5343D1F for ; Fri, 3 Sep 2004 01:46:26 +0000 (GMT) (envelope-from ob@gruft.de) Received: from ob by obh.snafu.de with local (Exim 4.34 (FreeBSD)) id 1C339l-0004aI-OP for current@freebsd.org; Fri, 03 Sep 2004 03:46:25 +0200 Date: Fri, 3 Sep 2004 03:46:25 +0200 From: Oliver Brandmueller To: current@freebsd.org Message-ID: <20040903014625.GB57576@e-Gitt.NET> References: <20040903013424.GA57576@e-Gitt.NET> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040903013424.GA57576@e-Gitt.NET> User-Agent: Mutt/1.5.6i Sender: Oliver Brandmueller Subject: Re: mysql on recent RELENG_5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 01:46:27 -0000 Hi. I miss something like "cancel" for mailing lists :-/ I just found the CPUTYPE hint in a post not long ago. Sorry for being blind. - Oliver -- | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | | Ich bin das Internet. Sowahr ich Gott helfe. | | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 02:13:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6AFC16A4CE; Fri, 3 Sep 2004 02:13:26 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7781C43D3F; Fri, 3 Sep 2004 02:13:26 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id i832DPwM035094; Thu, 2 Sep 2004 22:13:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i832DOTk051212; Thu, 2 Sep 2004 22:13:25 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A54D17303F; Thu, 2 Sep 2004 22:13:25 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040903021325.A54D17303F@freebsd-current.sentex.ca> Date: Thu, 2 Sep 2004 22:13:25 -0400 (EDT) Subject: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2004 02:13:27 -0000 TB --- 2004-09-03 00:45:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-03 00:45:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2004-09-03 00:45:00 - checking out the source tree TB --- 2004-09-03 00:45:00 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2004-09-03 00:45:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-03 00:50:08 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-03 00:50:08 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-09-03 00:50:08 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-09-03 01:53:56 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-03 01:53:56 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-09-03 01:53:56 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Sep 3 01:53:57 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Sep 3 02:06:59 UTC 2004 TB --- 2004-09-03 02:06:59 - generating LINT kernel config TB --- 2004-09-03 02:06:59 - cd /home/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- 2004-09-03 02:06:59 - /usr/bin/make -B LINT TB --- 2004-09-03 02:06:59 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-03 02:06:59 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-09-03 02:06:59 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Sep 3 02:06:59 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/dev/xe/if_xe_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/fs/autofs/autofs_vnops.c /tinderbox/CURRENT/alpha/alpha/src/sys/fs/autofs/autofs_vnops.c: In function `autofs_remove_dupdents': /tinderbox/CURRENT/alpha/alpha/src/sys/fs/autofs/autofs_vnops.c:593: warning: int format, different type arg (arg 3) /tinderbox/CURRENT/alpha/alpha/src/sys/fs/autofs/autofs_vnops.c:593: warning: int format, different type arg (arg 4) /tinderbox/CURRENT/alpha/alpha/src/sys/fs/autofs/autofs_vnops.c:593: warning: int format, different type arg (arg 5) /tinderbox/CURRENT/alpha/alpha/src/sys/fs/autofs/autofs_vnops.c:625: warning: int format, different type arg (arg 2) /tinderbox/CURRENT/alpha/alpha/src/sys/fs/autofs/autofs_vnops.c:625: warning: int format, different type arg (arg 3) *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2004-09-03 02:13:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-03 02:13:25 - ERROR: failed to build lint kernel TB --- 2004-09-03 02:13:25 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 02:38:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F75A16A4CE for ; Fri, 3 Sep 2004 02:38:47 +0000 (GMT) Received: from mail.parodius.com (mail.parodius.com [64.62.145.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DF8843D45 for ; Fri, 3 Sep 2004 02:38:47 +0000 (GMT) (envelope-from jdc@pentarou.parodius.com) Received: from pentarou.parodius.com (jdc@localhost [127.0.0.1]) by mail.parodius.com (8.12.11/8.12.11) with ESMTP id i832ck2X095299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Sep 2004 19:38:46 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: (from jdc@localhost) by pentarou.parodius.com (8.12.11/8.12.11/Submit) id i832ckqD095298 for current@freebsd.org; Thu, 2 Sep 2004 19:38:46 -0700 (PDT) (envelope-from jdc) Date: Thu, 2 Sep 2004 19:38:46 -0700 From: Jeremy Chadwick To: current@freebsd.org Message-ID: <20040903023846.GA95115@parodius.com> Mail-Followup-To: current@freebsd.org References: <20040903013424.GA57576@e-Gitt.NET> <20040903014625.GB57576@e-Gitt.NET> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040903014625.GB57576@e-Gitt.NET> User-Agent: Mutt/1.5.6i Subject: Re: mysql on recent RELENG_5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 02:38:47 -0000 What's yet to be discussed by anyone is _why_ -march is required for this to work. Is this a gcc-related problem? It's incredibly easy to reproduce. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | On Fri, Sep 03, 2004 at 03:46:25AM +0200, Oliver Brandmueller wrote: > Hi. > > I miss something like "cancel" for mailing lists :-/ > > I just found the CPUTYPE hint in a post not long ago. > > Sorry for being blind. > > - Oliver > > -- > | Oliver Brandmueller | Offenbacher Str. 1 | Germany D-14197 Berlin | > | Fon +49-172-3130856 | Fax +49-172-3145027 | WWW: http://the.addict.de/ | > | Ich bin das Internet. Sowahr ich Gott helfe. | > | Eine gewerbliche Nutzung aller enthaltenen Adressen ist nicht gestattet! | > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 03:44:39 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8802516A4CE; Fri, 3 Sep 2004 03:44:39 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3144E43D1D; Fri, 3 Sep 2004 03:44:39 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id i833iZS5045496; Thu, 2 Sep 2004 23:44:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i833iZL5074928; Thu, 2 Sep 2004 23:44:35 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9E44C7303F; Thu, 2 Sep 2004 23:44:35 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040903034435.9E44C7303F@freebsd-current.sentex.ca> Date: Thu, 2 Sep 2004 23:44:35 -0400 (EDT) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2004 03:44:39 -0000 TB --- 2004-09-03 02:13:25 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-03 02:13:25 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-09-03 02:13:25 - checking out the source tree TB --- 2004-09-03 02:13:25 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2004-09-03 02:13:25 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-03 02:18:50 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-03 02:18:50 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-09-03 02:18:50 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-09-03 03:23:07 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-03 03:23:07 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-09-03 03:23:07 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Sep 3 03:23:08 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Sep 3 03:37:18 UTC 2004 TB --- 2004-09-03 03:37:18 - generating LINT kernel config TB --- 2004-09-03 03:37:18 - cd /home/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2004-09-03 03:37:18 - /usr/bin/make -B LINT TB --- 2004-09-03 03:37:18 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-03 03:37:18 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-09-03 03:37:18 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Sep 3 03:37:18 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/CURRENT/a md64/amd64/src/sys/dev/xe/if_xe_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/CURRENT/a md64/amd64/src/sys/fs/autofs/autofs_vnops.c /tinderbox/CURRENT/amd64/amd64/src/sys/fs/autofs/autofs_vnops.c: In function `autofs_remove_dupdents': /tinderbox/CURRENT/amd64/amd64/src/sys/fs/autofs/autofs_vnops.c:593: warning: int format, different type arg (arg 3) /tinderbox/CURRENT/amd64/amd64/src/sys/fs/autofs/autofs_vnops.c:593: warning: int format, different type arg (arg 4) /tinderbox/CURRENT/amd64/amd64/src/sys/fs/autofs/autofs_vnops.c:593: warning: int format, different type arg (arg 5) /tinderbox/CURRENT/amd64/amd64/src/sys/fs/autofs/autofs_vnops.c:625: warning: int format, different type arg (arg 2) /tinderbox/CURRENT/amd64/amd64/src/sys/fs/autofs/autofs_vnops.c:625: warning: int format, different type arg (arg 3) *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-09-03 03:44:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-03 03:44:35 - ERROR: failed to build lint kernel TB --- 2004-09-03 03:44:35 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 03:52:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21E5116A4CE for ; Fri, 3 Sep 2004 03:52:11 +0000 (GMT) Received: from cpanel.ezone.ru (cpanel.ezone.ru [213.85.31.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3EF643D62 for ; Fri, 3 Sep 2004 03:52:09 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from [81.195.2.199] (ppp2-199.pppoe.mtu-net.ru [81.195.2.199]) (authenticated bits=0) by cpanel.ezone.ru (8.13.1/8.12.11) with ESMTP id i833q1ed002570 for ; Fri, 3 Sep 2004 07:52:02 +0400 (MSD) (envelope-from mcsi@mcsi.pp.ru) Message-ID: <4137EA5C.30606@mcsi.pp.ru> Date: Fri, 03 Sep 2004 07:51:56 +0400 From: Maxim Maximov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040810 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail3.ezone.ru Subject: panic on shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 03:52:11 -0000 Hello. I just got this panic on shutdown using Power button, hand transcribed: Syncing disks: No buffers busy after final sync Uptime: 21m53s Powering system off using ACPI panic: lock (sleep mutex) Giant not locked @ /usr/src/sys/kern/kern_timeout.c:279 cpuid = 0 KDB: enter: panic ACPI power-off failed - timeout Rebooting... cpu_reset: called on cpu#1 cpu_reset: Stopping other CPUs Here it hung until I pressed Power button again. Then it shut down. -- Maxim Maximov From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 05:37:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DC9C16A4CE for ; Fri, 3 Sep 2004 05:37:19 +0000 (GMT) Received: from mail.parodius.com (mail.parodius.com [64.62.145.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8562843D3F for ; Fri, 3 Sep 2004 05:37:19 +0000 (GMT) (envelope-from jdc@pentarou.parodius.com) Received: from pentarou.parodius.com (jdc@localhost [127.0.0.1]) by mail.parodius.com (8.12.11/8.12.11) with ESMTP id i835bJeX000203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Sep 2004 22:37:19 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: (from jdc@localhost) by pentarou.parodius.com (8.12.11/8.12.11/Submit) id i835bJkE000202 for freebsd-current@freebsd.org; Thu, 2 Sep 2004 22:37:19 -0700 (PDT) (envelope-from jdc) Date: Thu, 2 Sep 2004 22:37:19 -0700 From: Jeremy Chadwick To: freebsd-current@freebsd.org Message-ID: <20040903053719.GA99932@parodius.com> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: 5.2-CURRENT (08/05): kldunload if_tap.ko panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 05:37:19 -0000 Possibly this can be ignored, since it's 5.2-CURRENT from August 5th, but still, thought it would be worth posting "just in case". Or possibly it's already been fixed somewhere else. medusa# kldload if_tap.ko {...nothing done here other than an ifconfig...} medusa# kldunload if_tap.ko medusa# {...panic occurs...} {...on serial console...} db> db> trace strcmp(c063cab4,c4c8dd76,c063cbdd,4e3,c24dc0c8) at strcmp+0x9 enroll(c063cab4,c06636fc,c063cbdd,20b,c24dc0c8) at enroll+0x8a witness_init(c24dc0c8,24,71a,c24dc000,c24dc000) at witness_init+0x17c mtx_init(c24dc0c8,c063cab4,0,0,0) at mtx_init+0xe4 soalloc(1,0,c063f851,e0,c25c0af8) at soalloc+0x56 sonewconn(c22dcc58,2,c0644f49,222,c24bd824) at sonewconn+0x89 syncache_socket(c25c0af8,c22dcc58,c3d43800,2f8,c2145024) at syncache_socket+0x9f syncache_expand(db185b9c,c24bd824,db185b98,c3d43800,ea0c) at syncache_expand+0xeb tcp_input(c3d43800,14,c1f18800,1,200000a) at tcp_input+0x6a9 ip_input(c3d43800,0,c0642d38,96,c06baa78) at ip_input+0x76b netisr_processqueue(c06baa78,0,c0642d38,fe,c1ebc080) at netisr_processqueue+0x8a swi_net(0,0,c06372ef,263,0) at swi_net+0xa1 ithread_loop(c1e60b80,db185d48,c06370da,32b,c1e60b80) at ithread_loop+0x15f fork_exit(c04a04eb,c1e60b80,db185d48) at fork_exit+0xc7 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xdb185d7c, ebp = 0 --- db> panic panic: from debugger cpuid = 0; boot() called on cpu#0 Uptime: 23d1h43m5s Other details kinda-sorta can't be provided, since I need to bring this box up ASAP, but I'll provide any other information I can. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 06:37:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0499016A4CE for ; Fri, 3 Sep 2004 06:37:06 +0000 (GMT) Received: from huva.hittite.isp.9tel.net (huva.hittite.isp.9tel.net [62.62.156.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71DBE43D45 for ; Fri, 3 Sep 2004 06:37:05 +0000 (GMT) (envelope-from clefevr-current@9online.fr) Received: from pc2k (53-244-118-80.kaptech.net [80.118.244.53]) by huva.hittite.isp.9tel.net (Postfix) with SMTP id A96AF14B6F2; Fri, 3 Sep 2004 08:51:38 +0200 (CEST) Message-ID: <023c01c49180$6cacc580$7890a8c0@gits.invalid> From: "Cyrille Lefevre" To: "Deng XueFeng" References: <002f01c49020$5e9df560$7890a8c0@gits.invalid> <20040902012216.E864.DSNOFE@msn.com> <20040902224335.8922.DSNOFE@msn.com> Date: Fri, 3 Sep 2004 08:36:49 +0200 Organization: ACME MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 cc: Sascha Wildner cc: current@freebsd.org Subject: Re: [BETA PATCH] VESA mode support for syscons X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Cyrille Lefevre List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2004 06:37:06 -0000 "Deng XueFeng" wrote: > I have test this patch. it works well with -current. > > > This is the new patch. > > but i haven't test du to the limit of opt_sche.h > > you can try this patch after current is not broken. > > I wanna go to sleep. > > so sleepy. > > Zzzzzzzz... I have tested this patch also, it seems to work well, except that mouse in graphic mode ! it doesn't appear... since I have local modifications, I'll get rid of them and restart from scratch. Cyrille Lefevre. -- mailto:clefevre-lists@9online.fr From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 07:41:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B9E516A4CE; Fri, 3 Sep 2004 07:41:20 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E3EC43D46; Fri, 3 Sep 2004 07:41:19 +0000 (GMT) (envelope-from scottl@pooker.samsco.org) Received: from pooker.samsco.org (scottl@localhost [127.0.0.1]) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i837fCo5084589; Fri, 3 Sep 2004 01:41:12 -0600 (MDT) (envelope-from scottl@pooker.samsco.org) Received: (from scottl@localhost) by pooker.samsco.org (8.12.11/8.12.10/Submit) id i837fCvb084588; Fri, 3 Sep 2004 01:41:12 -0600 (MDT) (envelope-from scottl) Date: Fri, 3 Sep 2004 01:41:12 -0600 (MDT) Message-Id: <200409030741.i837fCvb084588@pooker.samsco.org> From: Scott Long To: current@FreeBSD.org X-Spam-Status: No, hits=0.6 required=3.8 tests=SUBJ_ALL_CAPS autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org Subject: 5.3-RELEASE TODO X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: re@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: Fri, 03 Sep 2004 07:41:20 -0000 This is an automated weekly mailing of the FreeBSD 5.3 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.3R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.3 FreeBSD 5.3 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.3. If you have any updates for this list, please e-mail re@FreeBSD.org. Show stopper defects for 5.3-RELEASE +------------------------------------------------------------------------+ | Issue | Status | Responsible | Description | |--------------------+-------------+-------------+-----------------------| | | | | PREEMPTION appears to | | | | | increase the chances | | | | | of triggering a race | | | | | condition in the | | | | | thread context | | PREEMPTION-related | | Scott Long, | management and | | hangs involving | In progress | Julian | scheduling code. | | threads | | Elischer | Patches to mitigate | | | | | the problem have been | | | | | developed, with | | | | | on-going work to come | | | | | up with the correct | | | | | solution prior to | | | | | 5.3. | |--------------------+-------------+-------------+-----------------------| | | | | Jun Kuriyama has | | | | | reported problems | | | | | with NFS over IPv6 | | NFS over IPv6 | Not done | - | not functioning | | problems | | | correctly as of the | | | | | improved NFS support | | | | | for disconnection | | | | | changes. | |--------------------+-------------+-------------+-----------------------| | | | | There are reports of | | | | | applications wedging | | | | | in poll() and | | | | | select() while | | | | | running the network | | poll()/select() | | | stack without the | | application wedge | | Robert | Giant lock. A recent | | reports with | In progress | Watson | sleepq change appears | | debug.mpsafenet=1 | | | to have caused some | | | | | of the observed | | | | | problems to go away | | | | | (others are difficult | | | | | to test for due to | | | | | recent SMP | | | | | instability). | |--------------------+-------------+-------------+-----------------------| | | | | ether_input() calls | | | | | random_harvest() on | | | | | the mbuf after it has | | | | | been handed off to | | | | | ether_demux(), at | | ether_input() may | | | which point it may | | harvest entropy | In progress | Mark Murray | have been free()'d | | from free()'d mbuf | | | back to the mbuf | | | | | allocator. It also | | | | | passes in a pointer | | | | | to the mbuf itself, | | | | | rather than ethernet | | | | | frame header. | |--------------------+-------------+-------------+-----------------------| | | | | Recent changes to the | | | | | ATA driver trigger a | | | | So/ren | bug on sparc64 that | | ATA panics under | In progress | Schmidt, | causes a panic on | | sparc64 | | Scott Long | boot. A work-around | | | | | has been developed | | | | | but needs to be | | | | | committed. | |--------------------+-------------+-------------+-----------------------| | | | | Kris Kennaway has | | | | | reported problems | | | | | with boot time | | | | | panic's, mutex Giant | | boot time panic | Not done | - | not owned at | | | | | kern/vfs_subr.c:1365. | | | | | See "Re: 5.3-RELEASE | | | | | TODO" thread in | | | | | -current@. | +------------------------------------------------------------------------+ Required features for 5.3-RELEASE +------------------------------------------------------------------------+ | Issue | Status | Responsible | Description | |-----------------+-------------+--------------+-------------------------| | GDB 6.1 kernel | | | GDB 6.1.1 import does | | debugging | In progress | Marcel | not include FreeBSD | | support | | Moolenaar | kernel debugging | | | | | support. | |-----------------+-------------+--------------+-------------------------| | BIND9 import | In progress | Doug Barton | BIND9 must be imported | | into 5-CURRENT | | | for 5.3-RELEASE. | |-----------------+-------------+--------------+-------------------------| | | | | Kernel bits | | KSE support for | | | implemented, userland | | sparc64 | -- | -- | not implemented. | | | | | Required for | | | | | 5.3-RELEASE. | |-----------------+-------------+--------------+-------------------------| | | | | KLDs work when loaded | | | | | from userland, but not | | | | | from the loader. | | kld support for | | David | kldxref and loader | | amd64 | In progress | O'Brien, Ian | support has been | | | | Dowse | committed to 6-CURRENT | | | | | and will hopefully be | | | | | backported to RELENG_5 | | | | | once it is tested. | |-----------------+-------------+--------------+-------------------------| | | | | With improved support | | | | | for threading | | | | | primitives, support is | | | | David Xu, | now required to ease | | GDB thread | In progress | Marcel | debugging of threaded | | support | | Moolenaar | applications. Ideally, | | | | | this support will work | | | | | for both libthr and | | | | | libkse threading | | | | | models. | |-----------------+-------------+--------------+-------------------------| | | | | Currently, two | | | | | schedulers are present: | | | | | SCHED_ULE (default), an | | | | | SMP-optimized scheduler | | | | | created as part of | | | | | SMPng, and SCHED_4BSD, | | | | | an SMP-adapted version | | | | | of the original 4BSD | | | | | scheduler. They have | | | | | quite different | | | | | performance properties, | | | | | with ULE providing | | | | | strong interactivity | | | | | characteristics, and | | Scheduler | | | performing quite well | | cleanup and | In progress | -- | in a number of | | resolution | | | benchmarks, and 4BSD | | | | | showing greater | | | | | strength in IPC | | | | | intensive user space | | | | | benchmarks, such as | | | | | databases. One of these | | | | | schedulers must be the | | | | | default for 5.3, and | | | | | whichever one it is, it | | | | | requires careful | | | | | measurement, analysis, | | | | | and optimization before | | | | | the release in order to | | | | | address its | | | | | deficiencies. | |-----------------+-------------+--------------+-------------------------| | | | | There have been several | | | | | reports that growfs(8) | | | | | works improperly with | | Reports of UFS2 | | | large disk sizes, and | | "large disk" | In progress | Scott Long | other size-related nits | | problems | | | in the current disk and | | | | | label management tool | | | | | set. These must be | | | | | resolved for | | | | | 5.3-RELEASE. | |-----------------+-------------+--------------+-------------------------| | | | | Synaptics updates to | | Synaptics | | | the psm(4) driver have | | touchpad | In progress | Philip Paeps | resulted in poor | | problems | | | interactivity for taps | | | | | and button press events | | | | | for some users. | |-----------------+-------------+--------------+-------------------------| | | | | Entropy harvesting in | | | | | the interrupt and | | | | | incoming packet paths | | | | | currently involves a | | | | | large number of mutex | | | | | operations. In order to | | | | | improve performance, it | | Entropy | | Robert | is desirable to reduce | | harvesting | In progress | Watson, | the number of mutex | | optimizations | | Mark Murray | operations | | | | | substantially. Work is | | | | | in progress to improve | | | | | the harvesting code | | | | | along these lines, but | | | | | has not yet been | | | | | properly measured, and | | | | | therefore not yet | | | | | merged to CVS. | +------------------------------------------------------------------------+ Desired features for 5.3-RELEASE +------------------------------------------------------------------------+ | Issue | Status | Responsible | Description | |------------------+-------------+----------------+----------------------| | | | | Almost all process | | | | | debugging tools have | | | | | been updated to use | | | | | non-procfs kernel | | | | | primitives, with the | | | | | exception of | | | | | truss(1). As procfs | | | | | is considered | | | | | deprecated due to | | | | | its inherent | | | | | security risks, it | | truss support | | | is highly desirable | | for ptrace | -- | -- | to update truss to | | | | | operate in a | | | | | post-procfs world. | | | | | Dag-Erling Smorgrav | | | | | had prototype | | | | | patches; | | | | | Robert Drehmel is | | | | | developing and | | | | | testing patches now. | | | | | Support for system | | | | | call tracing has | | | | | been added to | | | | | ptrace(). | |------------------+-------------+----------------+----------------------| | | | | FAST_IPSEC currently | | | | | cannot be used | | | | | directly with the | | | | | KAME IPv6 | | | | | implementation, | | | | | requiring an | | | | | additional level of | | | | | IP tunnel | | | | | indirection to | | | | | protect IPv6 packets | | FAST_IPSEC and | | | when using hardware | | KAME | Not done | -- | crypto acceleration. | | compatibility | | | This issue must be | | | | | resolved so that the | | | | | two services may | | | | | more easily be used | | | | | together. Among | | | | | other things, this | | | | | will require a | | | | | careful review of | | | | | the handling of mbuf | | | | | header copying and | | | | | m_tag support in the | | | | | KAME IPv6 code. | |------------------+-------------+----------------+----------------------| | | | | A process cannot be | | | | | interrupted while | | | | | waiting on a lock. | | rpc.lockd(8) | | | Fixing this requires | | stability | -- | -- | that the RPC code be | | | | | taught how to deal | | | | | with lock | | | | | cancellation and | | | | | interruption events. | |------------------+-------------+----------------+----------------------| | | | | Kernel modules are | | | | | currently built | | | | | independently from a | | | | | kernel | | | | | configuration, and | | | | | independently from | | | | | one another, | | | | | resulting in | | | | | substantially | | | | | redundant | | | | | compilation of | | | | | objects, as well as | | | | | the inability to | | | | | easily manage | | | | | compile-time options | | Revised kld | | | for kernel objects | | build | Not done | Peter Wemm | (such as MAC, PAE, | | infrastructure | | | etc) that may | | | | | require conditional | | | | | compilation in the | | | | | kernel modules. In | | | | | order to improve | | | | | build performance | | | | | and better support | | | | | options of this | | | | | sort, the KLD build | | | | | infrastructure needs | | | | | to be revamped. | | | | | Peter Wemm has done | | | | | some initial | | | | | prototyping, and | | | | | should be contacted | | | | | before starting on | | | | | this work. | |------------------+-------------+----------------+----------------------| | | | | Apple's Darwin | | | | | operating system has | | | | | fairly extensive | | Merge of Darwin | | | improvements to | | msdosfs, other | Not done | -- | msdosfs and other | | fixes | | | kernel services; | | | | | these fixes must be | | | | | reviewed and merged | | | | | to the FreeBSD tree. | |------------------+-------------+----------------+----------------------| | | | | Truss appears to | | | | | contain a race | | | | | condition during the | | | | | start-up of | | | | | debugging, which can | | | | | result in truss | | | | | failing to attach to | | | | | the process before | | | | | it exits. The | | | | | symptom is that | | | | | truss reports that | | | | | it cannot open the | | | | | procfs node | | | | | supporting the | | | | | process being | | | | | debugged. A bug also | | Race conditions | Errata | Robert Drehmel | appears to exist | | in truss | candidate | | where in truss will | | | | | hang if execve() | | | | | returns ENOENT. A | | | | | further race appears | | | | | to exist in which | | | | | truss will return | | | | | "PIOCWAIT: | | | | | Input/output error" | | | | | occasionally on | | | | | startup. The fix for | | | | | this sufficiently | | | | | changes process | | | | | execution handling | | | | | that we will defer | | | | | the fix to post-5.0 | | | | | and consider this | | | | | errata. | |------------------+-------------+----------------+----------------------| | | | | Truss appears to | | | | | have another | | | | | problem. It is | | | | | repeatable by | | | | | running "truss -f | | More truss | Not done | -- | fsck -p /", | | problems | | | suspending it with | | | | | ^Z, and then killing | | | | | truss. It will leave | | | | | behind the fsck | | | | | processes which will | | | | | be unkillable. | |------------------+-------------+----------------+----------------------| | | | | Many systems | | | | | supporting POSIX.1e | | | | | ACLs permit a minor | | | | | violation to that | | | | | specification, in | | | | | which the ACL_MASK | | ACL_MASK | | | entry overrides the | | override of | Not done | Robert Watson | umask, rather than | | umask support in | | | being intersected | | UFS | | | with it. The | | | | | resulting semantics | | | | | can be useful in | | | | | group-oriented | | | | | environments, and as | | | | | such would be very | | | | | helpful on FreeBSD. | |------------------+-------------+----------------+----------------------| | | | | The LOR reported in | | | | | PR kern/55175 needs | | filedesc LOR | Not done | -- | to be fixed. | | | | | Filedesc locking | | | | | needs to be heavily | | | | | reviewed in general. | |------------------+-------------+----------------+----------------------| | | | | Currently, MAC | | | | | protections are | | | | | enforced only on | | | | | locally originated | | | | | file system | | | | | operations (VOPs), | | | | | and not on RPCs | | | | | generated via the | | | | | NFS server. | | MAC support for | | | Improvements in NFS | | NFS Server | Not done | Robert Watson | server credential | | | | | handling are | | | | | required to correct | | | | | this problem, as | | | | | well as the | | | | | introduction of new | | | | | entry points to | | | | | properly label NFS | | | | | credentials and | | | | | perform enforcement | | | | | properly. | |------------------+-------------+----------------+----------------------| | | | | All PCI drivers must | | | | | use busdma for DMA; | | | | | no use of vtophys() | | busdma in all | In progress | -- | will be permitted | | PCI drivers | | | for any recent | | | | | device driver. ISA | | | | | drivers may be | | | | | exempt. | |------------------+-------------+----------------+----------------------| | | | | Userland bits | | KSE support for | In progress | Marcel | implemented, kernel | | alpha | | Moolenaar | bits not | | | | | implemented. | |------------------+-------------+----------------+----------------------| | | | | For kernel API/ABI | | | | | compatibility | | | | | reasons, it would be | | CAM locking | In progress | Scott Long, | desirable to have | | | | Justin Gibbs | the CAM locking | | | | | strategy determined | | | | | and loosely | | | | | implemented for 5.3. | |------------------+-------------+----------------+----------------------| | | | | When running syscons | | | | | on an Ultra-30 with | | | | | Creator-3D typing | | | | | characters on the | | | | | keyboard produces | | | | | garbage. Problem | | | | | reported by Kris | | syscons not | | | Kennaway. Debugging | | working on | Not done | -- | difficult due to | | Sparc64 Ultra-30 | | | lack of this | | | | | particular | | | | | configuration among | | | | | developers and | | | | | problem isn't | | | | | present on similar | | | | | hardware (e.g. no | | | | | problem on Ultra-60 | | | | | w/Creator-3D). | +------------------------------------------------------------------------+ Documentation items that must be resolved for 5.3 +------------------------------------------------------------------------+ | Issue | Status | Responsible | Description | |-------------------+-------------+---------------+----------------------| | | | | The installation | | | | | documentation | | | | | doesn't take into | | i386 Floppy | | Gavin | account the new | | Installation Docs | Done | Atkinson, | floppy images (with | | | | Bruce A. Mah | a full kernel split | | | | | across multiple | | | | | disks). This should | | | | | be updated. | |-------------------+-------------+---------------+----------------------| | | | | Finish removing | | | | | mention of | | | | Simon L. | individual devices | | Finish hardware | | Nielsen, | in the hardware | | notes trimming | In progress | Christian | notes and use | | | | Brueffer | auto-generated | | | | | lists, based on | | | | | driver manual pages, | | | | | instead. | |-------------------+-------------+---------------+----------------------| | | | | The snd(4) and | | | | | pcm(4) drivers have | | | | | been renamed but | | | | | their manual pages | | | | | are still outdated. | | | | | sound(4) has to be | | | | | added and pcm(4), | | | | Ruslan | csa(4), gusc(4), | | sound(4) related | In progress | Ermilov, | sbc(4), and | | manual pages | | Simon L. | uaudio(4) should be | | | | Nielsen | revised. Other | | | | | manual pages which | | | | | refer to pcm(4) (if | | | | | any) should possibly | | | | | be revised, too. In | | | | | addition, supported | | | | | cards list needs to | | | | | be updated. | |-------------------+-------------+---------------+----------------------| | | | | This section is | | Sound section in | In progress | Marc | outdated, some | | the Handbook | | Fonvieille | rewrites are needed | | | | | for 5.3-RELEASE. | |-------------------+-------------+---------------+----------------------| | | | | With the snd(4) and | | | | | pcm(4) drivers | | FDP | | | changes, | | documentations | Not done | -- | documentations (FAQ) | | related pcm(4) | | | regarding the use of | | | | | these drivers need | | | | | an update. | |-------------------+-------------+---------------+----------------------| | | | | Xin LI pointed out | | | | | that FreeBSD | | | | | 5.3-RELEASE is the | | | | | first stable release | | | | | on 5.X and it is | | | | | (hopefully) not for | | | | | early adopters. | | | | | Early Adopter's | | | | | Guide is still | | Early Adopter's | In progress | Bruce A. Mah, | useful, but contains | | Guide | | Tom Rhodes | a bit old | | | | | information. Some | | | | | parts of this guide | | | | | need a rewrite, and | | | | | this document should | | | | | be published as "4.X | | | | | to 5.X Migration | | | | | Guide", which | | | | | focuses difference | | | | | between 4.X and 5.X. | |-------------------+-------------+---------------+----------------------| | | | | Some parts are | | | | | outdated. doc/70485 | | | | | has been committed, | | | | | but more work is | | | | | needed to reflect | | | | | the realities. bmah@ | | | | | pointed out that we | | Installation | Not done | Tom Rhodes | should have | | Notes | | | "quick-start" | | | | | installation guide | | | | | for each platform | | | | | instead of the | | | | | current ones because | | | | | they become too long | | | | | and difficult to be | | | | | maintained. | |-------------------+-------------+---------------+----------------------| | | | | Update the X11 | | Xorg | Done | Ken Tom, Marc | chapter of the | | | | Fonvieille | Handbook for X.Org's | | | | | X11 server. | |-------------------+-------------+---------------+----------------------| | | | | Ch.11.4 and 11.5 of | | | | | the Handbook must be | | | | | updated to mention | | rc.d scripts | In progress | Tom Rhodes | the new rc.d scripts | | | | | and some ports use | | | | | /etc/rc.conf for | | | | | their configuration. | |-------------------+-------------+---------------+----------------------| | Handbook's kernel | | | Chapter 8 must be | | configuration | In progress | Ceri Davies | updated to match | | chapter | | | 5.3-RELEASE. | |-------------------+-------------+---------------+----------------------| | | | | Some parts of | | Handbook's IPsec | | | Section 14.10 are | | section | Not done | -- | outdated and are not | | | | | correct for 5.X | | | | | systems. | |-------------------+-------------+---------------+----------------------| | Handbook's Vinum | | | Vinum chapter needs | | chapter | Not done | -- | to be revised for | | | | | 5.X systems. | +------------------------------------------------------------------------+ Testing focuses for 5.3-RELEASE +------------------------------------------------------------------------+ | Issue | Status | Responsible | Description | |-------------------+---------------+--------------+---------------------| | | | | SCHED_ULE provides | | | | | better | | | | | interactivity, | | | | | higher performance, | | SCHED_ULE as the | Needs testing | Jeff | and the ability to | | default scheduler | | Roberson | support pinning and | | | | | affinity. Basic HTT | | | | | scheduling policies | | | | | should be in place | | | | | for 5.3 also. | |-------------------+---------------+--------------+---------------------| | | | | Attempts to use | | | | | make(1) with | | | | | KQueues appears to | | | | | result in a kernel | | | | | hang under "heavy | | | | | load". It would be | | | | | desirable to fix | | | | | this both from the | | | | | perspective of | | | | | building FreeBSD | | | | | quickly as a | | make -DUSE_KQUEUE | | Brian | developer, but also | | causes lockup | Needs testing | Feldman, | because it's an | | with buildworld | | John-Mark | instability that | | -jBIGNUM | | Gurney | could show up under | | | | | other high load and | | | | | heavy use of | | | | | KQueues. See PR | | | | | kern/57945 for a | | | | | proposed patch and | | | | | details. This | | | | | appear to be the | | | | | product of a | | | | | locking problem, | | | | | and must be fixed | | | | | for 5.3. | |-------------------+---------------+--------------+---------------------| | | | | KSE has matured to | | | | | the point of being | | | | | more stable and | | | | | POSIX-compliant | | | | | than the | | | | | traditional libc_r. | | | | | All Tier-1 | | | | | platforms MUST have | | KSE as the | | David Xu, | stable KSE support | | default threads | Needs testing | Daniel | for 5.3 in order to | | library | | Eischen | support a | | | | | consistent | | | | | transition. | | | | | Additionally, all | | | | | ports that depend | | | | | on the pthreads API | | | | | must be modified to | | | | | properly detect and | | | | | support the default | | | | | threading library. | |-------------------+---------------+--------------+---------------------| | | | | Binutils needs | | | | | updating in order | | Updated binutils | | David | to support new | | for all platforms | Needs testing | O'Brien | platforms, newer | | | | | GDB versions, and | | | | | Thread Local | | | | | Storage. | |-------------------+---------------+--------------+---------------------| | | | | The previous GCC | | | | | 3.3 snapshot | | | | | included | | | | | regressions in | | | | | alignment of | | | | | floating point | | gcc 3.3 floating | | | arguments, | | point alignment | Needs testing | | resulting in a | | regression | | | substantial | | | | | performance | | | | | degradation. The | | | | | recent GCC 3.4.2 | | | | | import should fix | | | | | this, but more | | | | | testing is needed. | |-------------------+---------------+--------------+---------------------| | | | | Jun Kuriyama has | | | | | reportged a failed | | | | | locking assertion | | | | | with IPv6 TCP | | in6_pcbnotify() | Needs testing | Robert | notifications. A | | panic with TCP | | Watson | patch has been | | | | | committed to the | | | | | CVS HEAD and | | | | | RELENG_5 and needs | | | | | further testing. | |-------------------+---------------+--------------+---------------------| | | | | To complete support | | | | | for thread-local | | | | | storage on FreeBSD, | | | | | per-architecture | | Per-platform | | Doug Rabson, | changes must be | | Thread-Local | Needs testing | Marcel | made. Currently | | Storage | | Moolenaar | pending platforms | | | | | are amd64, alpha, | | | | | ia64, i386, | | | | | sparc64, and | | | | | powerpc. | |-------------------+---------------+--------------+---------------------| | | | | High load on SMP | | | | | systems appears to | | | | | result in a hard | | | | | hang related to VM | | | | | IPI. Doug White has | | SMP instability | | Doug White, | prepared a | | under load | Needs testing | Alan L. Cox | candidate patch | | | | | that appears to | | | | | resolve this | | | | | instability, which | | | | | is currently in | | | | | testing for merge | | | | | to the CVS HEAD. | |-------------------+---------------+--------------+---------------------| | | | | Significant parts | | | | | of the network | | | | | stack (especially | | | | | IPv4, UNIX domain | | | | | IPC, and sockets) | | | | | now have | | | | | fine-grained | | | | | locking of their | | | | | data structures. | | | | | It's possible to | | | | | run many common | | | | | network subsystems | | | | | and services | | | | | without the Giant | | Fine-grained | | | lock. However, a | | network stack | Needs testing | Robert | number of device | | locking without | | Watson | drivers and less | | Giant | | | mainstream network | | | | | subsystems are | | | | | currently not | | | | | MPSAFE. By | | | | | 5.3-RELEASE, it is | | | | | necessary to have | | | | | the vast majority | | | | | of network code | | | | | running without | | | | | Giant, including | | | | | sockets, permitting | | | | | complete | | | | | local<->remote | | | | | delivery without | | | | | grabbing Giant. | |-------------------+---------------+--------------+---------------------| | | | | As part of the | | | | | MPSAFE network | | | | | stack work, | | | | | delivery of routing | | | | | socket messages was | | | | | moved to queued | | | | | dispatch via netisr | | | | | rather than direct | | | | | dispatch from the | | | | | routing code. | | Increased and | | | However, the risks | | configurable | | Robert | of lost routing | | netisr queue max | Needs testing | Watson | messages for | | depth for routing | | | routing daemons are | | sockets | | | high; respond by | | | | | increasing the max | | | | | depth beyond a | | | | | default interface | | | | | max depth of 50 to | | | | | 128, and allow it | | | | | to be | | | | | user-configured. | | | | | This change is now | | | | | present in CVS HEAD | | | | | and RELENG_5. | +------------------------------------------------------------------------+ ---------------------------------------------------------------------- home | contact | legal | (c) 1995-2004 The FreeBSD Project. All rights reserved. Last modified: 2004/09/03 03:59:35 From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 09:29:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 138A016A4CE; Fri, 3 Sep 2004 09:29:35 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A329B43D31; Fri, 3 Sep 2004 09:29:34 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id i839TYM5077253; Fri, 3 Sep 2004 05:29:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i839TYGW016349; Fri, 3 Sep 2004 05:29:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EB7C07303F; Fri, 3 Sep 2004 05:29:33 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040903092933.EB7C07303F@freebsd-current.sentex.ca> Date: Fri, 3 Sep 2004 05:29:33 -0400 (EDT) Subject: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2004 09:29:35 -0000 TB --- 2004-09-03 07:29:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-03 07:29:45 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2004-09-03 07:29:45 - checking out the source tree TB --- 2004-09-03 07:29:45 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2004-09-03 07:29:45 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-03 07:34:23 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-03 07:34:23 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2004-09-03 07:34:23 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-09-03 09:00:51 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-03 09:00:51 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2004-09-03 09:00:51 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Sep 3 09:00:51 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Sep 3 09:20:24 UTC 2004 TB --- 2004-09-03 09:20:24 - generating LINT kernel config TB --- 2004-09-03 09:20:24 - cd /home/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf TB --- 2004-09-03 09:20:24 - /usr/bin/make -B LINT TB --- 2004-09-03 09:20:24 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-03 09:20:24 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2004-09-03 09:20:24 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Sep 3 09:20:24 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -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 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/dev/wi/if_wi_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -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 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/dev/wi/if_wi_pci.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -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 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/dev/xe/if_xe.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -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 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/dev/xe/if_xe_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -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 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/fs/autofs/autofs_vnops.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -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 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT/ia64/ia64/src/sys/fs/autofs/autofs_vfsops.c /tinderbox/CURRENT/ia64/ia64/src/sys/fs/autofs/autofs_vfsops.c: In function `autofs_sysctl': /tinderbox/CURRENT/ia64/ia64/src/sys/fs/autofs/autofs_vfsops.c:447: warning: int format, different type arg (arg 2) *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2004-09-03 09:29:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-03 09:29:33 - ERROR: failed to build lint kernel TB --- 2004-09-03 09:29:33 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 09:53:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99D3C16A4CE for ; Fri, 3 Sep 2004 09:53:57 +0000 (GMT) Received: from portalis.it (mail2.portalis.it [213.199.4.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD62243D2D for ; Fri, 3 Sep 2004 09:53:55 +0000 (GMT) (envelope-from esaltato@tele2.it) Received: from [62.123.62.223] ([62.123.62.223]) by portalis.it with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 3 Sep 2004 12:13:45 +0200 Message-ID: <41383F2B.5040201@tele2.it> Date: Fri, 03 Sep 2004 11:53:47 +0200 From: Esaltato User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040901) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: No keyboard with Gnome and X.org (and gnome loaded behind KDE) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 09:53:57 -0000 I got a problem with GNOME since switching to xorg. On KDE everything is fine, but on Gnome 2.6 (all my system has been portupgraded yesterday) my keystrokes are blocked; as I type the text cursor stops blinking and nothing gets written. If I press ctrl, shift and some letters a lot of times it may happen that I can write sometimes, but only as long as I hold shift down and I don't change the writing focus. It seems like if my keys command are getting intercepted. This only happens as root. I want to point out that I've been throughly searching for solutions, and that not a solution proposed on the net has solved this. It may be related to the problem of this message popping up on Gnome (which I don't have, let's clarify it now, more on this later): :::::::start message Error activating XKB configuration. Probably internal X server problem. X server version data: The X.Org Foundation 60700000 If you report this situation as a bug, please include: - The result of xprop -root | grep XKB - The result of gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb :::::::end message These are the results: localhost# xprop -root | grep XKB _XKB_RULES_NAMES(STRING) = "xorg", "logiik", "it", "basic", "" localhost# gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb layouts = [it] model = logiik overrideSettings = false options = [] No help in changing the keyboard values... People report that this error message usually comes on start after the xorg update, but I _did not_ have this problem. I only get that pop up message (twice) if I go to the gnome keyboard panel and remove my italian keymap (I tried switching to no keymap and US). I followed the UPDATING hints related to gnome and xorg, so I rebuilt the 2 needed libraries x11-toolkits/libwnck and x11/libxklavier. I _haven't_ got the line Option "XkbRules" "xfree86" in my xorg file, which I let xorg itself build, and then I modified accordingly to my needs. I tried everything, and everything seems OK: Section "InputDevice" Identifier "Keyboard1" Driver "Keyboard" Option "AutoRepeat" "500 30" Option "XkbRules" "xorg" Option "XkbModel" "logiik" Option "XkbLayout" "it" EndSection (.....) InputDevice "Keyboard1" "CoreKeyboard" Oh, and I upgraded like the HEADSUP said. I use kdm now, but I used xdm when the problem surfaced. Any idea? I seem the only one with this problem. As for now, I'm sticking with KDE, but I need/want GNOME. Oh, just another thing that may be related, but I don't think is, but anyway is annoying: when I go to the desktop properties and hide my icons from the KDE desktop my GNOME desktop comes along, with all the icons (just some of them are blank, since gnome is not completely loaded) (and yes, keyboard works). Moreover the GNOME desktop picture comes up when I turn off my PC: why? Is a part of GNOME being loaded aside with kde/kdm? From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 10:37:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41FB616A4CE for ; Fri, 3 Sep 2004 10:37:28 +0000 (GMT) Received: from 82-168-140-74-bbxl.xdsl.tiscali.nl (82-168-140-74-bbxl.xdsl.tiscali.nl [82.168.140.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5918B43D1D for ; Fri, 3 Sep 2004 10:37:27 +0000 (GMT) (envelope-from rene@82-168-140-74-bbxl.xdsl.tiscali.nl) Received: from 82-168-140-74-bbxl.xdsl.tiscali.nl (atmosphere.local [127.0.0.1])i83Ac1m1002907; Fri, 3 Sep 2004 12:38:01 +0200 (CEST) (envelope-from rene@82-168-140-74-bbxl.xdsl.tiscali.nl) Received: (from rene@localhost)i83Ac0K1002906; Fri, 3 Sep 2004 12:38:00 +0200 (CEST) (envelope-from rene) Date: Fri, 3 Sep 2004 12:38:00 +0200 From: Rene Ladan To: Israel Herraiz , freebsd-current@freebsd.org Message-ID: <20040903103800.GA2832@82-168-140-74-bbxl.xdsl.tiscali.nl> Mail-Followup-To: Israel Herraiz , freebsd-current@freebsd.org References: <20040831204011.GA705@82-168-140-74-bbxl.xdsl.tiscali.nl> <691d00b804083115447dfb5adc@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Content-Disposition: inline In-Reply-To: <691d00b804083115447dfb5adc@mail.gmail.com> User-Agent: Mutt/1.4.2.1i Subject: Re: ACPI panic on Fujitsu-Siemens C6175 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 10:37:28 -0000 --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 01, 2004 at 12:44:22AM +0200, Israel Herraiz wrote: > See this [1]. >=20 > [1]. http://lists.freebsd.org/pipermail/freebsd-current/2004-August/03598= 4.html > I think the whole commit [1] is necessary. Upgrading ata-queue.c alone to 1.34 gives this error: ata-queue.c:473: warning: no previous prototype for 'ata_catch_inflight' [1] http://lists.freebsd.org/pipermail/cvs-src/2004-August/030550.html and maybe also this one: http://lists.freebsd.org/pipermail/cvs-src/2004-August/030233.html > --=20 > Israel Herraiz=20 > israel.herraiz@gmail.com --J/dobhs11T7y2rNN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBOEmIbWa3bO9NFoMRAt6mAKCA8mMn2KcEc8PgUvLBR0CvKZhphQCfSeTf q0NlA8i4Nf88Tg1z8HOWaI0= =kS6/ -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 10:40:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB5EB16A4CE; Fri, 3 Sep 2004 10:40:26 +0000 (GMT) Received: from dd1318.kasserver.com (dd1318.kasserver.com [81.209.148.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id AFD0C43D5A; Fri, 3 Sep 2004 10:40:25 +0000 (GMT) (envelope-from gbergling@0xfce3.net) Received: from nemesis.md.0xfce3.net (port-ip-213-211-224-164.reverse.mdcc-fun.de [213.211.224.164]) by dd1318.kasserver.com (Postfix) with ESMTP id 1BF729B5C8; Fri, 3 Sep 2004 12:40:22 +0200 (CEST) Received: from nemesis.md.0xfce3.net (localhost [127.0.0.1]) by nemesis.md.0xfce3.net (8.13.1/8.13.1) with ESMTP id i83AeFp8002006; Fri, 3 Sep 2004 12:40:15 +0200 (CEST) (envelope-from gbergling@0xfce3.net) Received: (from gordon@localhost) by nemesis.md.0xfce3.net (8.13.1/8.13.1/Submit) id i83AeF3O002005; Fri, 3 Sep 2004 12:40:15 +0200 (CEST) (envelope-from gbergling@0xfce3.net) X-Authentication-Warning: nemesis.ipv6.0xfce3.net: gordon set sender to gbergling@0xfce3.net using -f Date: Fri, 3 Sep 2004 12:40:15 +0200 From: Gordon Bergling To: Robert Watson Message-ID: <20040903104015.GA1889@nemesis.md.0xfce3.net> References: <200409030309.i8339tCS012361@repoman.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9jxsPFA5p3P2qPhR" Content-Disposition: inline In-Reply-To: <200409030309.i8339tCS012361@repoman.freebsd.org> X-Url: X-Operating-System: FreeBSD 5.3-BETA2 i386 X-Host-Uptime: 12:26PM up 1:24, 1 user, load averages: 0.82, 0.37, 0.28 User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/sys/conf options src/sys/sys kernel.h src/sys/net netisr.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Gordon Bergling List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2004 10:40:27 -0000 --9jxsPFA5p3P2qPhR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri Sep 03, 2004 at 03:09AM +0000, Robert Watson wrote: > rwatson 2004-09-03 03:09:55 UTC >=20 > FreeBSD src repository >=20 > Modified files: (Branch: RELENG_5) > sys/conf options=20 > sys/sys kernel.h=20 > sys/net netisr.c=20 > Log: > Merge sys/conf/options:1.478, sys/net/netisr.c:1.12, and > sys/sys/kernel.h:1.118 to RELENG_5: > =20 > Change the default disposition of debug.mpsafenet from 0 to 1, which > will cause the network stack to operate without the Giant lock by > default. This change has the potential to improve performance by > increasing parallelism and decreasing latency in network processing. > [...] In Consideration of some recent emails on the current mailinglist I am not sure whether I should add NET_WITH_GIANT to my kernel config or not. In my LAN I take heavy usage of IPv6 and one of NICs (vr driver) is not yet marked MP_SAFE. Is it safe for now to switch over to debug.mpsafenet=3D1 or should I wait until the locking of IPv6 is done? BTW. I am very willing to help testing... ;) best regards, Gordon --=20 Gordon Bergling http://www.0xFCE3.net/ PGP Fingerprint: 7732 9BB1 5013 AE8B E42C 28E0 93B9 D32B C76F 02A0 RIPE-HDL: MDTP-RIPE "There is no place like 127.0.0.0/8" --9jxsPFA5p3P2qPhR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBOEoOk7nTK8dvAqARAsteAKCPPVqSwGsb/RfZALrwPZjaho0GMgCfQnBY pjNbgiHp1tO3bYzN6+0aVDE= =jcS3 -----END PGP SIGNATURE----- --9jxsPFA5p3P2qPhR-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 11:24:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D914616A4CE for ; Fri, 3 Sep 2004 11:24:25 +0000 (GMT) Received: from portalis.it (mail2.portalis.it [213.199.4.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63AC843D5A for ; Fri, 3 Sep 2004 11:24:24 +0000 (GMT) (envelope-from esaltato@tele2.it) Received: from [62.123.62.223] ([62.123.62.223]) by portalis.it with Microsoft SMTPSVC(5.5.1877.197.19); Fri, 3 Sep 2004 13:44:18 +0200 Message-ID: <41385463.3060805@tele2.it> Date: Fri, 03 Sep 2004 13:24:19 +0200 From: Esaltato User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040901) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jeffrey Racine , current@freebsd.org References: <1094208945.55446.1.camel@x1-6-00-b0-d0-c2-67-0e.twcny.rr.com> In-Reply-To: <1094208945.55446.1.camel@x1-6-00-b0-d0-c2-67-0e.twcny.rr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: No keyboard with Gnome and X.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 11:24:26 -0000 Jeffrey Racine wrote: >Hi. > >This is caused by the XKB config in your old XF86Config... look for a >line with something like XKB86 (I dont' recall exactly which, but it is >in the keyboard def), delete it, and restart... > >-- Jeff > > I wonder if you read messages. Not only I clearly stated that I have a xorg.conf file, but I even wrote: I followed the UPDATING hints related to gnome and xorg, so I rebuilt the 2 needed libraries x11-toolkits/libwnck and x11/libxklavier. I _haven't_ got the line Option "XkbRules" "xfree86" Please READ the message next time. And please, answer to the mailing list, so that maybe others can benefit. Thanks. From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 11:34:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6F6716A4CE for ; Fri, 3 Sep 2004 11:34:14 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6484043D48 for ; Fri, 3 Sep 2004 11:34:14 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i83BVNbi045929; Fri, 3 Sep 2004 07:31:23 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i83BVNNk045926; Fri, 3 Sep 2004 07:31:23 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Fri, 3 Sep 2004 07:31:23 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Gordon Bergling In-Reply-To: <20040903104015.GA1889@nemesis.md.0xfce3.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/sys/conf options src/sys/sys kernel.h src/sys/net netisr.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 11:34:15 -0000 On Fri, 3 Sep 2004, Gordon Bergling wrote: > > Change the default disposition of debug.mpsafenet from 0 to 1, which > > will cause the network stack to operate without the Giant lock by > > default. This change has the potential to improve performance by > > increasing parallelism and decreasing latency in network processing. > > In Consideration of some recent emails on the current mailinglist I am > not sure whether I should add NET_WITH_GIANT to my kernel config or not. > > In my LAN I take heavy usage of IPv6 and one of NICs (vr driver) is not > yet marked MP_SAFE. > > Is it safe for now to switch over to debug.mpsafenet=1 or should I wait > until the locking of IPv6 is done? > > BTW. I am very willing to help testing... ;) :-) if_vr has recently had its locking reviewed (and in many cases corrected) by Bruce Simpson, so I think it is probably reasonable to run w/o Giant even though it wasn't on my list of known good drivers. He's marked it as INTR_MPSAFE (inbound path runs w/o giant), and not marked it IFF_NEEDSGIANT (outbound path runs w/ giant). Regarding IPv6: significant parts of IPv6 are safe in an MPSAFE environment, but not very well tested -- I've had about three or four minor but significant (fail stop) bugs to correct in the last two weeks. I don't doubt more are waiting. Areas that still require substantial attention in locking include the IPv6 forwarding path, ip6fw, and multicast discovery/routing. If you're using IPv6 on a local system largely for services like TCP consumption and serving, you are probably OK, but might encounter fail stop (assertion failure) scenarios that require some debugging. So far, these problems have generally been resolved within 48 hours of the problem being reported. So if you're willing to do a bit of testing, MPSAFE operation is probably ready for you, and additional IPv6 testing is something I'd like to see more of, as I don't have easy access to a rich IPv6 environment. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 11:49:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49D2A16A4CF for ; Fri, 3 Sep 2004 11:49:26 +0000 (GMT) Received: from mail.parodius.com (mail.parodius.com [64.62.145.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1D8443D48 for ; Fri, 3 Sep 2004 11:49:25 +0000 (GMT) (envelope-from jdc@pentarou.parodius.com) Received: from pentarou.parodius.com (jdc@localhost [127.0.0.1]) by mail.parodius.com (8.12.11/8.12.11) with ESMTP id i83BnPH5008695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 3 Sep 2004 04:49:25 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: (from jdc@localhost) by pentarou.parodius.com (8.12.11/8.12.11/Submit) id i83BnPwl008694 for freebsd-current@freebsd.org; Fri, 3 Sep 2004 04:49:25 -0700 (PDT) (envelope-from jdc) Date: Fri, 3 Sep 2004 04:49:25 -0700 From: Jeremy Chadwick To: freebsd-current@freebsd.org Message-ID: <20040903114925.GA8664@parodius.com> Mail-Followup-To: freebsd-current@freebsd.org References: <20040903053719.GA99932@parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040903053719.GA99932@parodius.com> User-Agent: Mutt/1.5.6i Subject: Re: 5.2-CURRENT (08/05): kldunload if_tap.ko panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 11:49:26 -0000 As per discussion with rwatson: after upgrading the machine to 5.3-BETA2 (Fri Sep 3 00:24:35 PDT 2004 build), loading/unloading if_tap.ko works. Kernel configurations are 100% identical. I'll report back on this issue in about 20-25 days (just to see if uptime has something to do with it). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | On Thu, Sep 02, 2004 at 10:37:19PM -0700, Jeremy Chadwick wrote: > Possibly this can be ignored, since it's 5.2-CURRENT from August 5th, > but still, thought it would be worth posting "just in case". Or > possibly it's already been fixed somewhere else. > > medusa# kldload if_tap.ko > > {...nothing done here other than an ifconfig...} > > medusa# kldunload if_tap.ko > medusa# > > {...panic occurs...} > {...on serial console...} > > db> > db> trace > strcmp(c063cab4,c4c8dd76,c063cbdd,4e3,c24dc0c8) at strcmp+0x9 > enroll(c063cab4,c06636fc,c063cbdd,20b,c24dc0c8) at enroll+0x8a > witness_init(c24dc0c8,24,71a,c24dc000,c24dc000) at witness_init+0x17c > mtx_init(c24dc0c8,c063cab4,0,0,0) at mtx_init+0xe4 > soalloc(1,0,c063f851,e0,c25c0af8) at soalloc+0x56 > sonewconn(c22dcc58,2,c0644f49,222,c24bd824) at sonewconn+0x89 > syncache_socket(c25c0af8,c22dcc58,c3d43800,2f8,c2145024) at > syncache_socket+0x9f > syncache_expand(db185b9c,c24bd824,db185b98,c3d43800,ea0c) at > syncache_expand+0xeb > tcp_input(c3d43800,14,c1f18800,1,200000a) at tcp_input+0x6a9 > ip_input(c3d43800,0,c0642d38,96,c06baa78) at ip_input+0x76b > netisr_processqueue(c06baa78,0,c0642d38,fe,c1ebc080) at > netisr_processqueue+0x8a > swi_net(0,0,c06372ef,263,0) at swi_net+0xa1 > ithread_loop(c1e60b80,db185d48,c06370da,32b,c1e60b80) at > ithread_loop+0x15f > fork_exit(c04a04eb,c1e60b80,db185d48) at fork_exit+0xc7 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xdb185d7c, ebp = 0 --- > db> panic > panic: from debugger > cpuid = 0; > boot() called on cpu#0 > Uptime: 23d1h43m5s > > Other details kinda-sorta can't be provided, since I need to bring this > box up ASAP, but I'll provide any other information I can. > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. | > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 07:09:28 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED0D816A4CE for ; Fri, 3 Sep 2004 07:09:28 +0000 (GMT) Received: from dhuumrelay2.dtm.ops.eu.uu.net (dhuumrelay2.dtm.ops.eu.uu.net [194.139.33.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8969A43D2D for ; Fri, 3 Sep 2004 07:09:27 +0000 (GMT) (envelope-from swildner@erpicon.de) Received: from rosi.erpicon.de (dhuumprxy2.dtm.ops.eu.uu.net [194.139.33.82]) i8379LQX020648; Fri, 3 Sep 2004 07:09:25 GMT X-Authenticated-As: none Received: from rosi (localhost [127.0.0.1]) by rosi (Postfix) with SMTP id C835272AF; Fri, 3 Sep 2004 09:09:12 +0200 (CEST) Received: from [194.49.16.69] (AWNT69.erpicon.de [194.49.16.69]) by rosi.erpicon.de (Postfix) with ESMTP id 8887F71AB; Fri, 3 Sep 2004 09:09:12 +0200 (CEST) Message-ID: <41381898.6040706@erpicon.de> Date: Fri, 03 Sep 2004 09:09:12 +0200 From: Sascha Wildner Organization: erpicon Software Development GmbH User-Agent: Mozilla Thunderbird 0.6 (Windows/20040502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cyrille Lefevre References: <002f01c49020$5e9df560$7890a8c0@gits.invalid> <20040902012216.E864.DSNOFE@msn.com> <20040902224335.8922.DSNOFE@msn.com> <023c01c49180$6cacc580$7890a8c0@gits.invalid> In-Reply-To: <023c01c49180$6cacc580$7890a8c0@gits.invalid> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 03 Sep 2004 11:57:38 +0000 cc: Deng XueFeng cc: current@freebsd.org Subject: Re: [BETA PATCH] VESA mode support for syscons X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: saw@online.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2004 07:09:29 -0000 Cyrille Lefevre wrote: > I have tested this patch also, it seems to work well, > except that mouse in graphic mode ! it doesn't appear... > since I have local modifications, I'll get rid of them > and restart from scratch. Do you mean the mouse pointer is not visible? If so, have you tried 'vidcontrol -m on'? Is moused running? If the problem persists after removing your local modifications, I'd like to know in which mode this happens. Please also attach the output of 'vidcontrol -i mode' and the dmesg of a verbose boot (boot -v). Regards, Sascha From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 10:28:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A68016A4CE for ; Fri, 3 Sep 2004 10:28:19 +0000 (GMT) Received: from mail.efacilitas.de (efacilitas.de [213.133.110.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id E96CD43D49 for ; Fri, 3 Sep 2004 10:28:18 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from hoppel.local (port-212-202-169-9.dynamic.qsc.de [212.202.169.9]) by mail.efacilitas.de (Postfix) with ESMTP id BBD4F123D89 for ; Fri, 3 Sep 2004 12:27:20 +0200 (CEST) Received: from alpha (unknown [192.168.1.2]) by hoppel.local (Postfix) with ESMTP id F0D536233 for ; Fri, 3 Sep 2004 12:28:20 +0200 (CEST) From: "Bjoern Koenig" To: Date: Fri, 3 Sep 2004 12:29:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcSRoNd5djsrTyBxQze4iO+KGGzuyQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20040903102820.F0D536233@hoppel.local> X-Mailman-Approved-At: Fri, 03 Sep 2004 11:57:38 +0000 Subject: mount_smbfs fails once X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 10:28:19 -0000 Since 5.3-BETA1 and BETA2 there is a misbehaviour with mounting a samba share. A first try fails: # mount_smbfs //hostname/share directory/ mount_smbfs: kldload(smbfs): No such file or directory smbfs.ko was automatically loaded as expected and now a second try is successful. Bj=F6rn From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 12:07:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E7BC16A4D3; Fri, 3 Sep 2004 12:07:43 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C26343D1D; Fri, 3 Sep 2004 12:07:43 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id i83C7gGp094194; Fri, 3 Sep 2004 08:07:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i83C7gIa024359; Fri, 3 Sep 2004 08:07:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 568C77303F; Fri, 3 Sep 2004 08:07:42 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040903120742.568C77303F@freebsd-current.sentex.ca> Date: Fri, 3 Sep 2004 08:07:42 -0400 (EDT) Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2004 12:07:44 -0000 TB --- 2004-09-03 10:42:56 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-03 10:42:56 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2004-09-03 10:42:56 - checking out the source tree TB --- 2004-09-03 10:42:56 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2004-09-03 10:42:56 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-03 10:47:54 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-03 10:47:54 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2004-09-03 10:47:54 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-09-03 11:50:54 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-03 11:50:54 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2004-09-03 11:50:54 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Sep 3 11:50:54 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Sep 3 12:02:02 UTC 2004 TB --- 2004-09-03 12:02:02 - generating LINT kernel config TB --- 2004-09-03 12:02:02 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- 2004-09-03 12:02:02 - /usr/bin/make -B LINT TB --- 2004-09-03 12:02:02 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-03 12:02:02 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2004-09-03 12:02:02 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Sep 3 12:02:02 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/xe/if_xe.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/xe/if_xe_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/zs/zs.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/zs/zs_sbus.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/fs/autofs/autofs_vnops.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/fs/autofs/autofs_vfsops.c /tinderbox/CURRENT/sparc64/sparc64/src/sys/fs/autofs/autofs_vfsops.c: In function `autofs_sysctl': /tinderbox/CURRENT/sparc64/sparc64/src/sys/fs/autofs/autofs_vfsops.c:447: warning: int format, different type arg (arg 2) *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2004-09-03 12:07:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-03 12:07:42 - ERROR: failed to build lint kernel TB --- 2004-09-03 12:07:42 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 13:26:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 830EE16A4CE for ; Fri, 3 Sep 2004 13:26:29 +0000 (GMT) Received: from gravy.kishka.net (pcp04097789pcs.neave01.pa.comcast.net [68.81.192.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id D20D243D2F for ; Fri, 3 Sep 2004 13:26:28 +0000 (GMT) (envelope-from bryan@kishka.net) Received: from gravy.kishka.net (gravy.kishka.net [192.168.1.2]) by gravy.kishka.net (8.13.1/8.13.1) with ESMTP id i83DQQRZ001002; Fri, 3 Sep 2004 09:26:26 -0400 (EDT) (envelope-from bryan@kishka.net) Date: Fri, 3 Sep 2004 09:26:26 -0400 (EDT) From: Bryan Liesner To: saw@online.de In-Reply-To: <41381898.6040706@erpicon.de> Message-ID: <20040903092006.P999@gravy.kishka.net> References: <002f01c49020$5e9df560$7890a8c0@gits.invalid> <20040902012216.E864.DSNOFE@msn.com> <20040902224335.8922.DSNOFE@msn.com> <023c01c49180$6cacc580$7890a8c0@gits.invalid> <41381898.6040706@erpicon.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Cyrille Lefevre cc: Deng XueFeng cc: current@freebsd.org Subject: Re: [BETA PATCH] VESA mode support for syscons X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 13:26:29 -0000 On Fri, 3 Sep 2004, Sascha Wildner wrote: > Cyrille Lefevre wrote: > >> I have tested this patch also, it seems to work well, >> except that mouse in graphic mode ! it doesn't appear... >> since I have local modifications, I'll get rid of them >> and restart from scratch. > > Do you mean the mouse pointer is not visible? If so, have you tried > 'vidcontrol -m on'? Is moused running? > > If the problem persists after removing your local modifications, I'd like to > know in which mode this happens. Please also attach the output of 'vidcontrol > -i mode' and the dmesg of a verbose boot (boot -v). > > Regards, > Sascha > > _______________________________________________ > 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 have tried both versions of the syscons patch, and it works fine in 1024x768 (MODE_279), but blanking the screen with green_saver no longer works. The cursor disappears when the screen saver kicks in, but the screen doesn't go blank (suspend mode). When I hit a key to exit from the screen saver, the screen momentarily blanks, then comes back to life. I'm using an LCD flat panel. It still suspends (DMPS suspend) when using xscreensaver. Thanks for everyone's work on this. From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 13:40:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84F2B16A4CE for ; Fri, 3 Sep 2004 13:40:58 +0000 (GMT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 6A33443D49 for ; Fri, 3 Sep 2004 13:40:57 +0000 (GMT) (envelope-from andreas.kohn@gmx.net) Received: (qmail 20770 invoked by uid 65534); 3 Sep 2004 13:40:55 -0000 Received: from unknown (EHLO [212.204.44.203]) (212.204.44.203) by mail.gmx.net (mp015) with SMTP; 03 Sep 2004 15:40:55 +0200 X-Authenticated: #2431876 From: Andreas Kohn To: current@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-bsagMw1jIGXRZz8sI/F+" Message-Id: <1094218854.836.8.camel@klamath.ankon.de.eu.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 03 Sep 2004 15:40:55 +0200 Subject: vr0 panic on boot (6-CURRENT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 13:40:58 -0000 --=-bsagMw1jIGXRZz8sI/F+ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, since a few days I can sometimes observe the following panic on boot. Sometimes means: usually after a cold boot. After the automatic reboot, the system will boot fine into normal operation. Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0x4 fault code =3D supervisor write, page not present instruction pointer =3D 0x8:0xc04b5a37 stack pointer =3D 0x10:0xcbf16c10 frame pointer =3D 0x10:0xcbf16c40 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 22 (irq11: rl1 vr0++) trap number =3D 12 panic: page fault Uptime: 2s ---- addr2line -e /usr/obj/usr/src/sys/KLAMATH/kernel.debug 0xc04b5a37 /usr/src/sys/dev/usb/uhci.c:1867 ---- I don't use or need the vr0 device[*], so I guess I could just remove it from the kernel configuration if those panics will continue. As no harddrives are mounted at that time, I do not have any data loss or the like, so it is currently a minor inconvenience only for me. [*] Because when I use it, I get tx/rx lost messages all over, and the=20 network access is *very* slow because of that. I had some spare=20 realteks lying around, so never bothered looking deeper into it. Perhaps someone can see anything obvious. Feel free to ask for more information, and I will try to get it for you. Thanks, Regards, Andreas ---- complete dmesg --- Copyright (c) 1992-2004 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.0-CURRENT #15: Tue Aug 31 09:03:48 CEST 2004 root@klamath.ankon.de.eu.org:/usr/obj/usr/src/sys/KLAMATH WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Processor (1199.80-MHz 686-class CPU) Origin =3D "AuthenticAMD" Id =3D 0x642 Stepping =3D 2 =20 Features=3D0x183fbff AMD Features=3D0xc0440000 real memory =3D 268369920 (255 MB) avail memory =3D 248770560 (237 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe0000000-0xe3ffffff at device 0.0 o n pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 nvidia0: mem 0xd0000000-0xd7ffffff,0xde000000-0xdeffffff i rq 11 at device 0.0 on pci1 nvidia0: [GIANT-LOCKED] trm0: port 0xec00-0xecff m em 0xdffff000-0xdfffffff irq 10 at device 10.0 on pci0 trm0: [GIANT-LOCKED] rl0: port 0xe800-0xe8ff mem 0xdfffef00-0xdfffefff ir q 12 at device 11.0 on pci0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:e0:7d:96:71:ed rl0: [GIANT-LOCKED] rl1: port 0xe400-0xe4ff mem 0xdfffee00-0xdfffeeff ir q 11 at device 12.0 on pci0 miibus1: on rl1 rlphy1: on miibus1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: Ethernet address: 00:c0:26:75:80:a7 rl1: [GIANT-LOCKED] bktr0: mem 0xdddfe000-0xdddfefff irq 5 at device 13.0 on pci0 bktr0: [GIANT-LOCKED] bktr0: Hauppauge Model 61324 D129 bktr0: Detected a MSP3410D-B4 at 0x80 bktr0: Hauppauge WinCast/TV, Philips PAL I tuner, msp3400c stereo, remote contro l. pci0: at device 13.1 (no driver attached) uhci0: port 0xd800-0xd81f irq 11 at device 16.0 on p ci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered umass0: USB Flash Disk, rev 2.00/2.00, addr 2 uhci1: port 0xdc00-0xdc1f irq 5 at device 16.1 on pc i0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ums0: Logitech USB Receiver, rev 1.10/9.10, addr 2, iclass 3/1 ums0: 5 buttons and Z dir. uhci2: port 0xe000-0xe01f irq 10 at device 16.2 on p ci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xdfffed00-0xdfffedff irq 12 at devic e 16.3 on pci0 ehci0: [GIANT-LOCKED] ehci_pci_attach: companion usb0 ehci_pci_attach: companion usb1 ehci_pci_attach: companion usb2 usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered umass1: USB Flash Disk, rev 2.00/2.00, addr 2 isab0: at device 17.0 on pci0 isa0: on isab0 atapci0: port 0xfc00-0xfc0f,0x376,0x170-0x177,0x3f 6,0x1f0-0x1f7 at device 17.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 pcm0: port 0xd400-0xd4ff irq 10 at device 17.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: vr0: port 0xd000-0xd0ff mem 0xdfffec00-0xdfff ecff irq 11 at device 18.0 on pci0 miibus2: on vr0 ukphy0: on miibus2 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: Ethernet address: 00:0b:6a:05:86:1c vr0: [GIANT-LOCKED] acpi_button1: on acpi0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f irq 7 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: on ppc0 ppi0: on ppbus0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] pmtimer0 on isa0 orm0: at iomem 0xcc800-0xcdfff,0xc0000-0xcc7ff on isa0 sc0: on isa0 sc0: VGA <16 virtual consoles, flags=3D0x200> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled Timecounter "TSC" frequency 1199797633 Hz quality 800 Timecounters tick every 10.000 msec IPv6 packet filtering initialized, logging disabled IPsec: Initialized Security Association Processing. ipfw2 initialized, divert enabled, rule-based forwarding disabled, default to de ny, logging disabled acpi_cpu: throttling enabled, 16 steps (100% to 6.2%), currently 100.0% ad0: 29314MB [59560/16/63] at ata0-master UDMA100 ad1: 42934MB [87233/16/63] at ata0-slave UDMA66 ATAPI_RESET time =3D 90us acd0: CDRW at ata1-master PIO4 Waiting 2 seconds for SCSI devices to settle umass0: at uhub0 port 1 (addr 2) disconnected ums0: at uhub1 port 2 (addr 2) disconnected ums0: detached Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0x4 fault code =3D supervisor write, page not present instruction pointer =3D 0x8:0xc04b5a37 stack pointer =3D 0x10:0xcbf16c10 frame pointer =3D 0x10:0xcbf16c40 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 22 (irq11: rl1 vr0++) trap number =3D 12 panic: page fault Uptime: 2s Cannot dump. No dump device defined. Shutting down ACPI Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... --=-bsagMw1jIGXRZz8sI/F+ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBBOHRmYucd7Ow1ygwRAgY9AJ0Vd+WX0YcpRwMS5O+xmv3a5L3BtACgi+j+ N4dRVBX8wfkA8xUGyF9BosM= =X6G/ -----END PGP SIGNATURE----- --=-bsagMw1jIGXRZz8sI/F+-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 13:43:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B574016A4CE; Fri, 3 Sep 2004 13:43:49 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FAB443D2F; Fri, 3 Sep 2004 13:43:49 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id i83DhmMJ007667; Fri, 3 Sep 2004 09:43:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.12.11/8.12.11) with ESMTP id i83DhmOt062461; Fri, 3 Sep 2004 09:43:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 68AF47303F; Fri, 3 Sep 2004 09:43:48 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040903134348.68AF47303F@freebsd-current.sentex.ca> Date: Fri, 3 Sep 2004 09:43:48 -0400 (EDT) Subject: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2004 13:43:49 -0000 TB --- 2004-09-03 12:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-03 12:15:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2004-09-03 12:15:00 - checking out the source tree TB --- 2004-09-03 12:15:00 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2004-09-03 12:15:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-03 12:20:23 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-03 12:20:23 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-09-03 12:20:23 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-09-03 13:24:21 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-03 13:24:21 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-09-03 13:24:21 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Sep 3 13:24:21 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Sep 3 13:37:21 UTC 2004 TB --- 2004-09-03 13:37:21 - generating LINT kernel config TB --- 2004-09-03 13:37:21 - cd /home/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- 2004-09-03 13:37:21 - /usr/bin/make -B LINT TB --- 2004-09-03 13:37:21 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-03 13:37:21 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2004-09-03 13:37:21 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Sep 3 13:37:21 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/dev/wi/if_wi_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/dev/wi/if_wi_pci.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/dev/xe/if_xe.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/dev/xe/if_xe_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/fs/autofs/autofs_vnops.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/fs/autofs/autofs_vfsops.c /tinderbox/CURRENT/alpha/alpha/src/sys/fs/autofs/autofs_vfsops.c: In function `autofs_sysctl': /tinderbox/CURRENT/alpha/alpha/src/sys/fs/autofs/autofs_vfsops.c:447: warning: int format, different type arg (arg 2) *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2004-09-03 13:43:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-03 13:43:48 - ERROR: failed to build lint kernel TB --- 2004-09-03 13:43:48 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 13:58:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD3F716A4CE for ; Fri, 3 Sep 2004 13:58:18 +0000 (GMT) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF93443D5F for ; Fri, 3 Sep 2004 13:58:17 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 10336 invoked from network); 3 Sep 2004 13:55:41 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 3 Sep 2004 13:55:41 -0000 Message-ID: <41387876.4030401@freebsd.org> Date: Fri, 03 Sep 2004 15:58:14 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a1) Gecko/20040520 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Presentation on new things in Network Stack for 5.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 13:58:19 -0000 I've made a presentation today at SUNCON'04 in Zurich, Switzerland on the new things and changes in FreeBSD 5.3 Network Stack. You can find it here: http://people.freebsd.org/~andre/ It is fairly high-level and intended for server and system administrators as well as developers. If you write me emails please be aware that I only periodically look into my inbox till Monday. We are having fun and disucussing FreeBSD issues and new developments with a couple of guys that are here too: phk, mblapp, mlaier, pjd, and a couple more of whom I don't remember the login at the moment. PS: Linux guys where pretty much floored that FreeBSD 5.3 can route 1Mpps and they can't do much more than 100kpps. ;-) Yes, way to go! PPS: SUCON website and tracks can be found here: http://www.suug.ch/sucon/04/ -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 14:24:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BE3416A4CE for ; Fri, 3 Sep 2004 14:24:41 +0000 (GMT) Received: from sdf.lonestar.org (ol.freeshell.org [192.94.73.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 209E343D1F for ; Fri, 3 Sep 2004 14:24:41 +0000 (GMT) (envelope-from pieckiel@sdf.lonestar.org) Received: from sdf.lonestar.org (IDENT:pieckiel@sverige.freeshell.org [192.94.73.4]) by sdf.lonestar.org (8.12.10/8.12.10) with ESMTP id i83EOWtr025509 for ; Fri, 3 Sep 2004 14:24:32 GMT Received: (from pieckiel@localhost) by sdf.lonestar.org (8.12.10/8.12.8/Submit) id i83EOWX3009736 for freebsd-current@freebsd.org; Fri, 3 Sep 2004 10:24:32 -0400 (EDT) Date: Fri, 3 Sep 2004 10:24:32 -0400 From: "Kevin A. Pieckiel" To: freebsd-current@freebsd.org Message-ID: <20040903142432.GA27464@SDF.LONESTAR.ORG> Mail-Followup-To: freebsd-current@freebsd.org References: <20040829213449.GA33843@hub.freebsd.org> <20040830135311.11040.qmail@web50603.mail.yahoo.com> <20040830163106.GA19044@dragon.nuxi.com> <20040830210817.GB749@galgenberg.net> <20040831195329.GB21995@odin.ac.hmc.edu> <2F14AAB9-FB8B-11D8-B6F3-003065A20588@mac.com> <1093986646.4466.8.camel@amon.quaggaspace.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1093986646.4466.8.camel@amon.quaggaspace.org> User-Agent: Mutt/1.4.2.1i Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 14:24:41 -0000 On Tue, Aug 31, 2004 at 05:10:47PM -0400, Justin Settle wrote: > Anyway, I'd thought I'd just say your patch is working very well here > for me. I've gone with "f" and "j" as that makes far more sense to me. > Use pointer finger to point which one I want and all of that. I'm totally surprised nobody's mentioned using arrow keys instead of letters. Use the left arrow key for the left side of the screen and the right arrow key for the right side of the screen. THAT makes perfect sense IMO. From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 15:14:44 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04DE516A4CE; Fri, 3 Sep 2004 15:14:44 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D64E43D39; Fri, 3 Sep 2004 15:14:43 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id i83FEgLo032419; Fri, 3 Sep 2004 11:14:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i83FEhiq051850; Fri, 3 Sep 2004 11:14:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 16CED7303F; Fri, 3 Sep 2004 11:14:43 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040903151443.16CED7303F@freebsd-current.sentex.ca> Date: Fri, 3 Sep 2004 11:14:43 -0400 (EDT) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2004 15:14:44 -0000 TB --- 2004-09-03 13:43:48 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-03 13:43:48 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-09-03 13:43:48 - checking out the source tree TB --- 2004-09-03 13:43:48 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2004-09-03 13:43:48 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-03 13:48:58 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-03 13:48:58 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-09-03 13:48:58 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-09-03 14:53:12 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-03 14:53:12 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-09-03 14:53:12 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Sep 3 14:53:12 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Sep 3 15:07:24 UTC 2004 TB --- 2004-09-03 15:07:24 - generating LINT kernel config TB --- 2004-09-03 15:07:24 - cd /home/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2004-09-03 15:07:24 - /usr/bin/make -B LINT TB --- 2004-09-03 15:07:24 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-03 15:07:24 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-09-03 15:07:24 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Sep 3 15:07:24 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/CURRENT/a md64/amd64/src/sys/dev/wi/if_wi_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/CURRENT/a md64/amd64/src/sys/dev/wi/if_wi_pci.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/CURRENT/a md64/amd64/src/sys/dev/xe/if_xe.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/CURRENT/a md64/amd64/src/sys/dev/xe/if_xe_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/CURRENT/a md64/amd64/src/sys/fs/autofs/autofs_vnops.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/amd64/amd64/src/sys -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/altq -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/pf -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /tinderbox/CURRENT/a md64/amd64/src/sys/fs/autofs/autofs_vfsops.c /tinderbox/CURRENT/amd64/amd64/src/sys/fs/autofs/autofs_vfsops.c: In function `autofs_sysctl': /tinderbox/CURRENT/amd64/amd64/src/sys/fs/autofs/autofs_vfsops.c:447: warning: int format, different type arg (arg 2) *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-09-03 15:14:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-03 15:14:42 - ERROR: failed to build lint kernel TB --- 2004-09-03 15:14:42 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 15:40:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D10B16A4D1 for ; Fri, 3 Sep 2004 15:40:23 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA6D543D58 for ; Fri, 3 Sep 2004 15:40:11 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 32688 invoked from network); 3 Sep 2004 15:40:11 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 3 Sep 2004 15:40:10 -0000 Received: from [10.50.41.228] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i83Fe3l4076130; Fri, 3 Sep 2004 11:40:07 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Maxim Maximov Date: Fri, 3 Sep 2004 10:23:55 -0400 User-Agent: KMail/1.6.2 References: <4137EA5C.30606@mcsi.pp.ru> In-Reply-To: <4137EA5C.30606@mcsi.pp.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409031023.55561.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: current@FreeBSD.org cc: Nate Lawson Subject: Re: panic on shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 15:40:23 -0000 On Thursday 02 September 2004 11:51 pm, Maxim Maximov wrote: > Hello. > > I just got this panic on shutdown using Power button, hand transcribed: > > Syncing disks: > No buffers busy after final sync > Uptime: 21m53s > Powering system off using ACPI > > panic: lock (sleep mutex) Giant not locked @ > /usr/src/sys/kern/kern_timeout.c:279 > > cpuid = 0 > KDB: enter: panic > ACPI power-off failed - timeout > > Rebooting... > cpu_reset: called on cpu#1 > cpu_reset: Stopping other CPUs > > Here it hung until I pressed Power button again. Then it shut down. Looks like the timeout/callout routine dropped Giant more than it acquired it. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 15:49:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F3A216A510 for ; Fri, 3 Sep 2004 15:49:17 +0000 (GMT) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 522BF43D64 for ; Fri, 3 Sep 2004 15:49:16 +0000 (GMT) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.12.11/jtpda-5.4) with ESMTP id i83Fm24r065335 for ; Fri, 3 Sep 2004 17:48:02 +0200 (CEST) X-Ids: 166 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) i83FnAmp016050 for ; Fri, 3 Sep 2004 17:49:10 +0200 (MEST) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.1/8.13.1/Submit) id i83FnAB0016047; Fri, 3 Sep 2004 17:49:10 +0200 (MEST) (envelope-from arno) To: current@freebsd.org References: <20040902211925.GA61127@cell.sick.ru> From: "Arno J. Klaassen" Date: 03 Sep 2004 17:49:09 +0200 In-Reply-To: <20040902211925.GA61127@cell.sick.ru> Message-ID: Lines: 10 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at shiva.jussieu.fr with ID 41389232.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Antivirus: scanned by sophie at shiva.jussieu.fr Subject: Re: top broken? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 15:49:19 -0000 > I've noticed today that CURRENT dated Aug 29, with ULE scheduler > does not show WCPU/CPU in top at all. However, process time of > CPU consumers grows. idem here for 4BSD, however the first process shows WCPU/CPU (but surely wrong since from time to time over 100%) Arno From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 16:01:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F068C16A4CE; Fri, 3 Sep 2004 16:01:27 +0000 (GMT) Received: from shiva.jussieu.fr (shiva.jussieu.fr [134.157.0.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BCAA43D69; Fri, 3 Sep 2004 16:01:27 +0000 (GMT) (envelope-from arno@heho.snv.jussieu.fr) Received: from heho.snv.jussieu.fr (heho.snv.jussieu.fr [134.157.184.22]) by shiva.jussieu.fr (8.12.11/jtpda-5.4) with ESMTP id i83G0E6l069323 ; Fri, 3 Sep 2004 18:00:14 +0200 (CEST) X-Ids: 166 Received: from heho.snv.jussieu.fr (localhost [127.0.0.1]) i83G1NFF016160 ; Fri, 3 Sep 2004 18:01:23 +0200 (MEST) Received: (from arno@localhost) by heho.snv.jussieu.fr (8.13.1/8.13.1/Submit) id i83G1NmN016157; Fri, 3 Sep 2004 18:01:23 +0200 (MEST) (envelope-from arno) To: current@freebsd.org From: "Arno J. Klaassen" Date: 03 Sep 2004 18:01:22 +0200 Message-ID: Lines: 40 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Miltered: at shiva.jussieu.fr with ID 4138950E.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Antivirus: scanned by sophie at shiva.jussieu.fr cc: krion@freebsd.org Subject: problem with xterm and RELENG_5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 16:01:28 -0000 Hello, recently shells from xterm stopped showing up in 'w' : M ~ [12930] > w 5:57PM up 5:02, 1 user, load averages: 0.07, 0.20, 0.17 USER TTY FROM LOGIN@ IDLE WHAT arno v0 - 12:56PM 5:00 xinit M ~ [12931] > ps ux | fgrep xterm arno 10150 0.0 0.2 1608 1016 pa S+ 5:58PM 0:00.00 fgrep xterm arno 2049 0.0 0.6 5144 4084 pb S+ 3:39PM 0:01.21 xterm -geometry 80x arno 2050 0.0 0.6 5144 4084 pb S+ 3:39PM 0:01.06 xterm -geometry 80x arno 2051 0.0 0.6 5144 4084 pb S+ 3:39PM 0:01.17 xterm -geometry 80x arno 2060 0.0 0.6 5144 4084 pb S+ 3:39PM 0:01.20 xterm -geometry 80x arno 2061 0.0 0.6 5144 4084 pb S+ 3:39PM 0:01.45 xterm -geometry 80x arno 2063 0.0 0.6 5144 4084 pb S+ 3:39PM 0:01.25 xterm -geometry 80x arno 3255 0.0 0.6 5144 4084 pi S 5:02PM 0:00.50 xterm -geometry 80x arno 963 0.0 0.7 5696 4484 v0 S 12:56PM 0:03.40 xterm -geometry 80x arno 965 0.0 0.7 5692 4720 v0 S 12:57PM 0:01.86 xterm -sb -sl 2038 arno 991 0.0 0.8 5696 4724 v0 S 12:58PM 0:02.46 xterm -geometry 80x arno 993 0.0 0.8 5700 4792 v0 S 12:59PM 0:04.06 xterm -geometry 80x arno 998 0.0 0.7 5352 4380 v0 S 12:59PM 0:01.74 xterm -T handig -e arno 1001 0.0 0.8 5696 4724 v0 S 12:59PM 0:03.20 xterm -geometry 80x arno 1025 0.0 0.7 5692 4720 v0 S 1:03PM 0:01.80 xterm -sb -sl 2038 arno 1049 0.0 0.7 5696 4636 v0 S 1:14PM 0:01.91 xterm -geometry 80x arno 1080 0.0 0.7 5692 4632 v0 S 1:28PM 0:01.66 xterm -sb -sl 2038 arno 1105 0.0 0.7 5696 4636 v0 S 1:39PM 0:06.82 xterm -geometry 80x arno 1110 0.0 0.7 5696 4636 v0 S 1:40PM 0:01.90 xterm -geometry 80x arno 1346 0.0 0.7 5692 4632 v0 S 3:07PM 0:01.36 xterm -sb -sl 2038 arno 1393 0.0 0.7 5692 4632 v0 S 3:07PM 0:01.53 xterm -sb -sl 2038 arno 1527 0.0 0.7 5700 4704 v0 S 3:27PM 0:01.49 xterm -geometry 80x arno 2166 0.0 0.7 5696 4636 v0 S 3:44PM 0:01.57 xterm -geometry 80x arno 5192 0.0 0.7 5692 4632 v0 S 5:51PM 0:00.19 xterm -sb -sl 2038 M ~ [12932] > so some are assigned to a new pseudo-terminal, others stay at v0. gnome-terminal works OK; downgrading to e.g. xterm-1.94 doesnt help Regards, Arno From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 16:34:26 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 441CE16A4CF for ; Fri, 3 Sep 2004 16:34:26 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0720143D41 for ; Fri, 3 Sep 2004 16:34:26 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i83GYNDl025195; Fri, 3 Sep 2004 09:34:24 -0700 Message-ID: <41389D0F.9030204@root.org> Date: Fri, 03 Sep 2004 09:34:23 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040901) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Markus Brueffer References: <413768A9.4020904@root.org> <200409030255.00577.markus@brueffer.de> In-Reply-To: <200409030255.00577.markus@brueffer.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: Interrupt storm on uhciX with acpi_pci_link.c 1.24.2.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 16:34:26 -0000 Markus Brueffer wrote: > Hi Nate, > > On Thursday 02 September 2004 20:38, Nate Lawson wrote: > >>Your ASL is at fault here. It defines a mixed set of APIC and PCI link >>irq devices. (See the _PRT for PCI0, the APIC object). The MPtable is >>correct. Here is the part that is wrong: >> >> Name (APIC, Package (0x18) >> { >> ... >> Package (0x04) >> { >> 0x0004FFFF, >> 0x03, >> \_SB.LNKC, >> 0x00 >> }, >> >>This one should be: >> >> Package (0x04) >> { >> 0x0004FFFF, >> 0x03, >> 0x00, >> 0x12, >> } >> >>It should be possible to add this to /boot/loader.conf: >> >>hw.acpi.pci.link.0.4.3.irq="18" > > As you already expected, this doesn't work. I'll send you a patch that may fix this. >>But since 18 won't be in your list of valid irqs, your best bet is to >>patch your ASL as above and recompile with iasl. > > > Patching the ASL did the trick. Thank you very much! Thanks to jhb@ for also helping with this. > While compiling tha ASL I got the following warning: > > markus-cuv4x-d.asl.patched 316: Method (\_WAK, 1, NotSerialized) > Warning 2026 - ^ Reserved method must > return a value (_WAK) > > Maybe this information is of some use for you. Nope, the warning is harmless. If you want to feel better, you can put a Return (Package { 0, 0 }) in there (see the acpi debugging handbook page for exact syntax). >>Perhaps a BIOS upgrade will have this fixed? > > I already have the latest BIOS installed and I doubt that there will be a new > one in the future (the current one is from mid 2002) :( Ok. -Nate From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 16:41:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7DD916A4CE for ; Fri, 3 Sep 2004 16:41:38 +0000 (GMT) Received: from mail.uksolutions.net (customer-relay-1.mail.uksolutions.net [217.10.128.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5200843D1F for ; Fri, 3 Sep 2004 16:41:38 +0000 (GMT) (envelope-from bruce@cran.org.uk) Received: from 82-41-13-158.cable.ubr02.edin.blueyonder.co.uk ([82.41.13.158] helo=[10.0.0.10]) by mail.uksolutions.net with asmtp (Exim 4.34) id 1C3Ghh-0002d7-52; Fri, 03 Sep 2004 17:14:21 +0100 In-Reply-To: <200408281104.58018.doconnor@gsoft.com.au> References: <97f8dd040826235372388dea@mail.gmail.com> <200408280027.14207.doconnor@gsoft.com.au> <97f8dd0408271456a8cb2e7@mail.gmail.com> <200408281104.58018.doconnor@gsoft.com.au> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1EA329FC-FDC8-11D8-9B48-000D93ACEE20@cran.org.uk> Content-Transfer-Encoding: 7bit From: Bruce Cran Date: Fri, 3 Sep 2004 17:41:35 +0100 To: "Daniel O'Connor" X-Mailer: Apple Mail (2.619) cc: current@freebsd.org Subject: Re: System freeze when useing bfe (Broadcom BCM440x) driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 16:41:39 -0000 On 28 Aug 2004, at 02:34, Daniel O'Connor wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sat, 28 Aug 2004 07:26, Genius Freak wrote: >> The kernel is rebuilding now :) >> I was so desperate I even tried the 5.3 beta1 to see if that would >> work and it did but it was too much of a beta for me to use, it >> crashed in sysinstall twice. > > Personally I'd trust 5.3-BETA over 5.2.1... > > If it crashes in sysinstall you should report it (eg the panic > message) so > it's less of a beta when it's released :) There does seem to be a problem with the BCM driver in 5.3-BETA2, or at least some problem with the driver when combined with the ICH ATA driver. After installing lots of distributions and then configuring the network, I get a panic on my Inspiron 8500. However, if I only install a couple of distributions then there's no problem. I've also had no further problem with it once it's installed; I've been cvsup'ing and adding packages all over the place and the driver seems very stable. If there's some way to get a kernel dump when running from the CD (some kernel parameter perhaps?) I'll get an image, but otherwise all I've got is a list of symbols from the backtrace. -- Bruce Cran From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 17:08:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC78D16A4CE; Fri, 3 Sep 2004 17:08:54 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id B66A343D1F; Fri, 3 Sep 2004 17:08:54 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-127-84-57.dsl.snfc21.pacbell.net [67.127.84.57]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id i83H8qDl025613; Fri, 3 Sep 2004 10:08:52 -0700 Message-ID: <4138A524.8080107@root.org> Date: Fri, 03 Sep 2004 10:08:52 -0700 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.7.3 (X11/20040901) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <4137EA5C.30606@mcsi.pp.ru> <200409031023.55561.jhb@FreeBSD.org> In-Reply-To: <200409031023.55561.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Maxim Maximov cc: current@FreeBSD.org Subject: Re: panic on shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 17:08:55 -0000 John Baldwin wrote: > On Thursday 02 September 2004 11:51 pm, Maxim Maximov wrote: > >>Hello. >> >> I just got this panic on shutdown using Power button, hand transcribed: >> >>Syncing disks: >>No buffers busy after final sync >>Uptime: 21m53s >>Powering system off using ACPI >> >>panic: lock (sleep mutex) Giant not locked @ >>/usr/src/sys/kern/kern_timeout.c:279 >> >>cpuid = 0 >>KDB: enter: panic >>ACPI power-off failed - timeout >> >>Rebooting... >>cpu_reset: called on cpu#1 >>cpu_reset: Stopping other CPUs >> >>Here it hung until I pressed Power button again. Then it shut down. > > Looks like the timeout/callout routine dropped Giant more than it acquired it. I don't see how this could be triggered by ACPI. If you reboot the system with ACPI disabled (or enabled), do you also get this message? We don't acquire or release Giant explicitly and the device and interrupt are both marked MPSAFE. Well, we use Giant for busdma to set up the 1 MB trampoline in low memory for resume but that shouldn't affect this unless there's a bug in busdma. BTW, why doesn't "panic" from the debugger prompt actually reset the system any more? -Nate From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 17:10:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A653D16A4D5 for ; Fri, 3 Sep 2004 17:10:45 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 717FD43D45 for ; Fri, 3 Sep 2004 17:10:45 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 4CDBE72DD4; Fri, 3 Sep 2004 10:10:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 4A82972DCB; Fri, 3 Sep 2004 10:10:45 -0700 (PDT) Date: Fri, 3 Sep 2004 10:10:45 -0700 (PDT) From: Doug White To: Chris Laverdure In-Reply-To: <1093879363.74399.7.camel@elemental.DashEvil> Message-ID: <20040903100857.T27358@carver.gumbysoft.com> References: <1093879363.74399.7.camel@elemental.DashEvil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: smb mount panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 17:10:45 -0000 On Mon, 30 Aug 2004, Chris Laverdure wrote: > I'm not actually sure if this is a samba problem, but anyway: > > I have all of my mp3s stored on another box and shared with samba. Most > of the time on first boot I execute the following command: > > mount -t smbfs //incubus@sylvia/root /Network/Sylvia > > For some reason whenever I do that now I get some sort of kld related > error (even though netsmb_dev loads), and then I have to do it again for > it to actually mount the share. Are you running it as non-root? You need to preload the modules as root if you aren't. > More importantly, and this seems to be dependant on how long I have my > box up, if I do this with say.. 48 minutes of uptime, I am greated to a > beautiful kernel panic. If its related to quotas, try compiling samba without quota support. > I'm sorry for not providing any debug messages or anything of that sort > -- I'm about to hit the shower. But if anyone is interested I can > provide any information they wish. In general, its better to collect these and post them without asking -- otherwise you'll just be ignored. I just happen to know of a couple odd samba-isms that people trip over. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 17:12:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BB5E16A4CE for ; Fri, 3 Sep 2004 17:12:09 +0000 (GMT) Received: from creme-brulee.marcuscom.com (rrcs-midsouth-24-172-16-118.biz.rr.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F9F243D2F for ; Fri, 3 Sep 2004 17:12:08 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from [10.2.1.4] (vpn-client-4.marcuscom.com [10.2.1.4]) i83H9ds2053658; Fri, 3 Sep 2004 13:09:40 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: Esaltato In-Reply-To: <41383F2B.5040201@tele2.it> References: <41383F2B.5040201@tele2.it> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-z+GXOe+JEtAsOAepjE4v" Organization: MarcusCom, Inc. Message-Id: <1094231547.727.12.camel@gyros> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 03 Sep 2004 13:12:28 -0400 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on creme-brulee.marcuscom.com cc: current@freebsd.org Subject: Re: No keyboard with Gnome and X.org (and gnome loaded behind KDE) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 17:12:09 -0000 --=-z+GXOe+JEtAsOAepjE4v Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri, 2004-09-03 at 05:53, Esaltato wrote: > I got a problem with GNOME since switching to xorg. On KDE everything is=20 > fine, but on Gnome 2.6 (all my system has been portupgraded yesterday)=20 > my keystrokes are blocked; as I type the text cursor stops blinking and=20 > nothing gets written. If I press ctrl, shift and some letters a lot of=20 > times it may happen that I can write sometimes, but only as long as I=20 > hold shift down and I don't change the writing focus. It seems like if=20 > my keys command are getting intercepted. This only happens as root. > I want to point out that I've been throughly searching for solutions,=20 > and that not a solution proposed on the net has solved this. > It may be related to the problem of this message popping up on Gnome=20 > (which I don't have, let's clarify it now, more on this later): >=20 > :::::::start message > Error activating XKB configuration. > Probably internal X server problem. You need to read /usr/ports/UPDATING. [snip] > Any idea? I seem the only one with this problem. As for now, I'm=20 > sticking with KDE, but I need/want GNOME. > Oh, just another thing that may be related, but I don't think is, but=20 > anyway is annoying: when I go to the desktop properties and hide my=20 > icons from the KDE desktop my GNOME desktop comes along, with all the=20 > icons (just some of them are blank, since gnome is not completely=20 > loaded) (and yes, keyboard works). Moreover the GNOME desktop picture=20 > comes up when I turn off my PC: why? Is a part of GNOME being loaded=20 > aside with kde/kdm? No clue. Perhaps somewhere you're starting Nautilus. Joe > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= " --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-z+GXOe+JEtAsOAepjE4v Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD4DBQBBOKX7b2iPiv4Uz4cRAphKAJ9coIGE5nzh9pnIRKrhxJ1s4+nHAgCUCOAY 2QNxCoNT+OH0rJZs51Kdnw== =kd4m -----END PGP SIGNATURE----- --=-z+GXOe+JEtAsOAepjE4v-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 17:21:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51DDB16A4CE; Fri, 3 Sep 2004 17:21:29 +0000 (GMT) Received: from cpanel.ezone.ru (cpanel.ezone.ru [213.85.31.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0876343D2F; Fri, 3 Sep 2004 17:21:28 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from [81.195.2.185] (ppp2-185.pppoe.mtu-net.ru [81.195.2.185]) (authenticated bits=0) by cpanel.ezone.ru (8.13.1/8.12.11) with ESMTP id i83HLFnF088202; Fri, 3 Sep 2004 21:21:20 +0400 (MSD) (envelope-from mcsi@mcsi.pp.ru) Message-ID: <4138A806.9020105@mcsi.pp.ru> Date: Fri, 03 Sep 2004 21:21:10 +0400 From: Maxim Maximov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040810 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: Nate Lawson References: <4137EA5C.30606@mcsi.pp.ru> <200409031023.55561.jhb@FreeBSD.org> <4138A524.8080107@root.org> In-Reply-To: <4138A524.8080107@root.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail3.ezone.ru cc: current@FreeBSD.org cc: John Baldwin Subject: Re: panic on shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 17:21:29 -0000 Nate Lawson wrote: > John Baldwin wrote: > >> On Thursday 02 September 2004 11:51 pm, Maxim Maximov wrote: >> >>> Hello. >>> >>> I just got this panic on shutdown using Power button, hand >>> transcribed: >>> >>> Syncing disks: >>> No buffers busy after final sync >>> Uptime: 21m53s >>> Powering system off using ACPI >>> >>> panic: lock (sleep mutex) Giant not locked @ >>> /usr/src/sys/kern/kern_timeout.c:279 >>> >>> cpuid = 0 >>> KDB: enter: panic >>> ACPI power-off failed - timeout >>> >>> Rebooting... >>> cpu_reset: called on cpu#1 >>> cpu_reset: Stopping other CPUs >>> >>> Here it hung until I pressed Power button again. Then it shut down. >> >> >> Looks like the timeout/callout routine dropped Giant more than it >> acquired it. > > > I don't see how this could be triggered by ACPI. If you reboot the > system with ACPI disabled (or enabled), do you also get this message? My system can't boot with ACPI disabled. Also I want to mention that this panic is rare. I've seen it about 10 times in 2-3 months of everyday rebooting. And by the way, the command issued to shut the system down was 'halt -p' > We > don't acquire or release Giant explicitly and the device and interrupt > are both marked MPSAFE. Well, we use Giant for busdma to set up the 1 > MB trampoline in low memory for resume but that shouldn't affect this > unless there's a bug in busdma. > > BTW, why doesn't "panic" from the debugger prompt actually reset the > system any more? > > -Nate -- Maxim Maximov From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 18:07:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7475516A4CE for ; Fri, 3 Sep 2004 18:07:14 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 415B043D46 for ; Fri, 3 Sep 2004 18:07:14 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24024 invoked from network); 3 Sep 2004 18:07:14 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 3 Sep 2004 18:07:13 -0000 Received: from [10.50.41.228] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i83I79X4077042; Fri, 3 Sep 2004 14:07:10 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Fri, 3 Sep 2004 13:41:47 -0400 User-Agent: KMail/1.6.2 References: <4137EA5C.30606@mcsi.pp.ru> <4138A524.8080107@root.org> <4138A806.9020105@mcsi.pp.ru> In-Reply-To: <4138A806.9020105@mcsi.pp.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409031341.47074.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Maxim Maximov cc: current@FreeBSD.org cc: Nate Lawson Subject: Re: panic on shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 18:07:14 -0000 On Friday 03 September 2004 01:21 pm, Maxim Maximov wrote: > Nate Lawson wrote: > > John Baldwin wrote: > >> On Thursday 02 September 2004 11:51 pm, Maxim Maximov wrote: > >>> Hello. > >>> > >>> I just got this panic on shutdown using Power button, hand > >>> transcribed: > >>> > >>> Syncing disks: > >>> No buffers busy after final sync > >>> Uptime: 21m53s > >>> Powering system off using ACPI > >>> > >>> panic: lock (sleep mutex) Giant not locked @ > >>> /usr/src/sys/kern/kern_timeout.c:279 > >>> > >>> cpuid = 0 > >>> KDB: enter: panic > >>> ACPI power-off failed - timeout > >>> > >>> Rebooting... > >>> cpu_reset: called on cpu#1 > >>> cpu_reset: Stopping other CPUs > >>> > >>> Here it hung until I pressed Power button again. Then it shut down. > >> > >> Looks like the timeout/callout routine dropped Giant more than it > >> acquired it. > > > > I don't see how this could be triggered by ACPI. If you reboot the > > system with ACPI disabled (or enabled), do you also get this message? > > My system can't boot with ACPI disabled. > > Also I want to mention that this panic is rare. I've seen it about 10 > times in 2-3 months of everyday rebooting. > > And by the way, the command issued to shut the system down was 'halt -p' I would hack the timeout code to add some printf's before the mtx_unlock(&Giant) to dump the function pointer and argument if !tmtx_owned(&Giant) and then use gdb to figure out what the callout function was. I.e. something like: if (not mpsafe) { if (!mtx_owned(&Giant)) printf("func = %p, arg = %p\n", c_func, c_arg) mtx_unlock(&Giant); } -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 18:07:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74DEB16A4CF for ; Fri, 3 Sep 2004 18:07:14 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4174543D48 for ; Fri, 3 Sep 2004 18:07:14 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 24024 invoked from network); 3 Sep 2004 18:07:14 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 3 Sep 2004 18:07:13 -0000 Received: from [10.50.41.228] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i83I79X4077042; Fri, 3 Sep 2004 14:07:10 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Fri, 3 Sep 2004 13:41:47 -0400 User-Agent: KMail/1.6.2 References: <4137EA5C.30606@mcsi.pp.ru> <4138A524.8080107@root.org> <4138A806.9020105@mcsi.pp.ru> In-Reply-To: <4138A806.9020105@mcsi.pp.ru> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200409031341.47074.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: Maxim Maximov cc: current@FreeBSD.org cc: Nate Lawson Subject: Re: panic on shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 18:07:14 -0000 On Friday 03 September 2004 01:21 pm, Maxim Maximov wrote: > Nate Lawson wrote: > > John Baldwin wrote: > >> On Thursday 02 September 2004 11:51 pm, Maxim Maximov wrote: > >>> Hello. > >>> > >>> I just got this panic on shutdown using Power button, hand > >>> transcribed: > >>> > >>> Syncing disks: > >>> No buffers busy after final sync > >>> Uptime: 21m53s > >>> Powering system off using ACPI > >>> > >>> panic: lock (sleep mutex) Giant not locked @ > >>> /usr/src/sys/kern/kern_timeout.c:279 > >>> > >>> cpuid = 0 > >>> KDB: enter: panic > >>> ACPI power-off failed - timeout > >>> > >>> Rebooting... > >>> cpu_reset: called on cpu#1 > >>> cpu_reset: Stopping other CPUs > >>> > >>> Here it hung until I pressed Power button again. Then it shut down. > >> > >> Looks like the timeout/callout routine dropped Giant more than it > >> acquired it. > > > > I don't see how this could be triggered by ACPI. If you reboot the > > system with ACPI disabled (or enabled), do you also get this message? > > My system can't boot with ACPI disabled. > > Also I want to mention that this panic is rare. I've seen it about 10 > times in 2-3 months of everyday rebooting. > > And by the way, the command issued to shut the system down was 'halt -p' I would hack the timeout code to add some printf's before the mtx_unlock(&Giant) to dump the function pointer and argument if !tmtx_owned(&Giant) and then use gdb to figure out what the callout function was. I.e. something like: if (not mpsafe) { if (!mtx_owned(&Giant)) printf("func = %p, arg = %p\n", c_func, c_arg) mtx_unlock(&Giant); } -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 18:57:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5280D16A4CE for ; Fri, 3 Sep 2004 18:57:23 +0000 (GMT) Received: from out002.email.savvis.net (out002.apptix.savvis.net [216.91.32.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 127CC43D2D for ; Fri, 3 Sep 2004 18:57:23 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from s228130hz1ew03.apptix-01.savvis.net ([10.146.4.28]) by out002.email.savvis.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Sep 2004 13:57:25 -0500 Received: from [10.254.186.111] ([66.35.239.94]) by s228130hz1ew03.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Sep 2004 13:57:21 -0500 Message-ID: <4138BE8D.7000102@savvis.net> Date: Fri, 03 Sep 2004 11:57:17 -0700 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040822 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Sep 2004 18:57:21.0335 (UTC) FILETIME=[D791DC70:01C491E7] Subject: fine grained locking and traversing linked lists X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 18:57:23 -0000 Dear Hackers, recent Robert Watson's locking changes made me to revisit locking in the bluetooth code. bluetooth code uses linked lists for various objects. quite often it is required to locate a certain object in the list. during this operation i have to hold list mutex and individual object mutex. this is very inconvenient. so, i've written a "spherical cow" that shows fine grained locking when traversing linked lists (see below). basically, for double linked list, in order to safely manipulate by object "y" one must hold three locks: object "y" lock, object "x = y->previous" lock and object "z = y->next" lock. so, the $1 million question is: am i missing something? or this will work? note: in the "spherical cow" below linked list is replaced by array, ->next and ->previous operation are replaced with +1 and -1 respectively and -1 stands for NULL. --------------------------->8------------------------------------- #include #include #define N 21 static int locks[N] = { 0, }; static void lock(int x) { assert(0 <= x && x < sizeof(locks)/sizeof(locks[0]));\ assert(locks[x] == 0); locks[x] ++; } static void unlock(int x) { assert(0 <= x && x < sizeof(locks)/sizeof(locks[0])); assert(locks[x] == 1); locks[x] --; } static int locked(int x) { if (0 <= x && x < sizeof(locks)/sizeof(locks[0])) return (locks[x]); return (-1); } static void printlocks(void) { int i; printf("\n"); for (i = 0; i < sizeof(locks)/sizeof(locks[0]); i++) printf("%d ", locks[i]); printf("\n"); } int main(void) { int i, x, y, z; y = 0; lock(y); if ((x = (y - 1)) >= 0) lock(x); else x = -1; for (i = 1; ; i++) { if ((z = (y + 1)) < sizeof(locks)/sizeof(locks[0])) lock(z); else z = -1; printf("%-3d: (%-3d:%-3d) (%-3d:%-3d) (%-3d:%-3d)\n", i, x, locked(x), y, locked(y), z, locked(z)); if (z == -1) break; y = z; if (x != -1) unlock(x); x = y - 1; } if (x != -1) unlock(x); if (y != -1) unlock(y); printlocks(); return (0); } ------------->8------------------------------------ thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 19:10:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F0A316A4CE for ; Fri, 3 Sep 2004 19:10:43 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 451BF43D58 for ; Fri, 3 Sep 2004 19:10:43 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i83JBTX9002950; Fri, 3 Sep 2004 12:11:29 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i83JBS7K002944; Fri, 3 Sep 2004 12:11:28 -0700 Date: Fri, 3 Sep 2004 12:11:28 -0700 From: Brooks Davis To: Maksim Yevmenkin Message-ID: <20040903191128.GA649@odin.ac.hmc.edu> References: <4138BE8D.7000102@savvis.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ikeVEW9yuYc//A+q" Content-Disposition: inline In-Reply-To: <4138BE8D.7000102@savvis.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-current@freebsd.org Subject: Re: fine grained locking and traversing linked lists X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 19:10:43 -0000 --ikeVEW9yuYc//A+q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 03, 2004 at 11:57:17AM -0700, Maksim Yevmenkin wrote: > Dear Hackers, >=20 > recent Robert Watson's locking changes made me to revisit locking in > the bluetooth code. bluetooth code uses linked lists for various > objects. quite often it is required to locate a certain object in the > list. during this operation i have to hold list mutex and individual > object mutex. this is very inconvenient. Why do you have to hold the object mutex? I can think of scenerios where that is required, but usually it isn't since they key is fixed at the time the item is inserted in to the list, or is at least protected by the list mutex. For an example of a key protected by the list mutex, consider struct ifnet's if_xname member relative to ifunit() and renaming. > so, i've written a "spherical cow" that shows fine grained locking > when traversing linked lists (see below). basically, for double linked > list, in order to safely manipulate by object "y" one must hold three > locks: object "y" lock, object "x =3D y->previous" lock and object "z =3D > y->next" lock. >=20 > so, the $1 million question is: am i missing something? or this will work? How do you protect the head in this case? The list mutex would normally do so, but if the head can change, you'll need a mutex to protect it (using an array hid this issue). Also, doubly linked lists won't work without a lot of effort (read pain :-) because scanning backwards and forwards at the same time will lead to deadlock. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --ikeVEW9yuYc//A+q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBOMHgXY6L6fI4GtQRAvziAJ4yiCYMxbjgb3rKV+PaEAtjOWo40gCgu8Ee o6NZGJUda8f7hXxOr5OMgV0= =UNv4 -----END PGP SIGNATURE----- --ikeVEW9yuYc//A+q-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 19:32:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F07316A4CE for ; Fri, 3 Sep 2004 19:32:06 +0000 (GMT) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79DA243D41 for ; Fri, 3 Sep 2004 19:32:06 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (8.12.6/MantshX 2.0) with ESMTP id i83JW6Yo013478; Fri, 3 Sep 2004 12:32:06 -0700 (PDT) Received: from [10.1.1.245] (nfw2.codefab.com [199.103.21.225] (may be forged)) (authenticated bits=0)i83JW5d2025686; Fri, 3 Sep 2004 12:32:05 -0700 (PDT) In-Reply-To: <20040903142432.GA27464@SDF.LONESTAR.ORG> References: <20040829213449.GA33843@hub.freebsd.org> <20040830135311.11040.qmail@web50603.mail.yahoo.com> <20040830163106.GA19044@dragon.nuxi.com> <20040830210817.GB749@galgenberg.net> <20040831195329.GB21995@odin.ac.hmc.edu> <2F14AAB9-FB8B-11D8-B6F3-003065A20588@mac.com> <1093986646.4466.8.camel@amon.quaggaspace.org> <20040903142432.GA27464@SDF.LONESTAR.ORG> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Fri, 3 Sep 2004 15:32:03 -0400 To: "Kevin A. Pieckiel" X-Mailer: Apple Mail (2.619) cc: freebsd-current@freebsd.org Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 19:32:06 -0000 On Sep 3, 2004, at 10:24 AM, Kevin A. Pieckiel wrote: > I'm totally surprised nobody's mentioned using arrow keys instead of > letters. Use the left arrow key for the left side of the screen and > the right arrow key for the right side of the screen. THAT makes > perfect sense IMO. You're right, only most keyboards don't generate a single character for the arrow keys-- they generate something thing "^[OD", depending on your $TERM. If you can convince your keyboard to generate a single key (perhaps a high-ASCII character using keyboard mapping?), you ought be able to use the patch with them, but I'm not sure it would be worth the effort. -- -Chuck From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 19:38:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77C9516A4CE for ; Fri, 3 Sep 2004 19:38:21 +0000 (GMT) Received: from out001.email.savvis.net (out001.apptix.savvis.net [216.91.32.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2076F43D54 for ; Fri, 3 Sep 2004 19:38:21 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from s228130hz1ew03.apptix-01.savvis.net ([10.146.4.28]) by out001.email.savvis.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Sep 2004 14:38:20 -0500 Received: from [10.254.186.111] ([66.35.239.94]) by s228130hz1ew03.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Sep 2004 14:38:20 -0500 Message-ID: <4138C82A.5020304@savvis.net> Date: Fri, 03 Sep 2004 12:38:18 -0700 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040822 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <4138BE8D.7000102@savvis.net> <20040903191128.GA649@odin.ac.hmc.edu> In-Reply-To: <20040903191128.GA649@odin.ac.hmc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Sep 2004 19:38:20.0157 (UTC) FILETIME=[912452D0:01C491ED] cc: freebsd-current@freebsd.org Subject: Re: fine grained locking and traversing linked lists X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 19:38:21 -0000 Brooks Davis wrote: > On Fri, Sep 03, 2004 at 11:57:17AM -0700, Maksim Yevmenkin wrote: > >>Dear Hackers, >> >>recent Robert Watson's locking changes made me to revisit locking in >>the bluetooth code. bluetooth code uses linked lists for various >>objects. quite often it is required to locate a certain object in the >>list. during this operation i have to hold list mutex and individual >>object mutex. this is very inconvenient. > > Why do you have to hold the object mutex? I can think of scenerios > where that is required, but usually it isn't since they key is fixed at > the time the item is inserted in to the list, or is at least protected > by the list mutex. For an example of a key protected by the list > mutex, consider struct ifnet's if_xname member relative to ifunit() and > renaming. well, again i'm using bluetooth sockets code as an example. there is a linked list of all PCB. each PCB has its own lock. so, when i need to locate PCB by any field i do lock(list); list_foreach(pcb, ...) { lock(pcb); if (compare(key)) { unlock(pcb); unlock(list); return (pcb); } unlock(pcb); } unlock(list); return (NULL); in sockets layer some functions (i.e. bind, connect, control etc.) can change PCB fields without holding sockets list lock. so, in some cases i want: lock(list), lock(pcb) and in other cases i want lock(pcb), lock(list). >>so, i've written a "spherical cow" that shows fine grained locking >>when traversing linked lists (see below). basically, for double linked >>list, in order to safely manipulate by object "y" one must hold three >>locks: object "y" lock, object "x = y->previous" lock and object "z = >>y->next" lock. >> >>so, the $1 million question is: am i missing something? or this will work? > > How do you protect the head in this case? The list mutex would normally > do so, but if the head can change, you'll need a mutex to protect it > (using an array hid this issue). Also, doubly linked lists won't work > without a lot of effort (read pain :-) because scanning backwards and > forwards at the same time will lead to deadlock. yes, the head is still the issue. but i think it can be avoided. i think it only has to be protected when head changes from NULL -> non NULL and vice versa. otherwise its just lock(head). i do not think that scanning backwards and forwards at the same time is an issue. it is a (serious?) limitation i agree. but it is possible to scan list forward staring from any point. thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 19:43:34 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3222316A4CE for ; Fri, 3 Sep 2004 19:43:34 +0000 (GMT) Received: from smtp-1.isd.no (smtp-1.isd.no [195.139.232.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id D49DD43D46 for ; Fri, 3 Sep 2004 19:43:32 +0000 (GMT) (envelope-from arnvid@karstad.org) Received: (qmail 26044 invoked by uid 204); 3 Sep 2004 21:43:32 +0200 Received: from arnvid@karstad.org by smtp-1.isd.no by uid 201 with qmail-scanner-1.16 (. clamscan: 0.70. spamassassin: 2.63. Clear:. Processed in 0.349676 secs); 03 Sep 2004 19:43:32 -0000 X-Qmail-Scanner-Mail-From: arnvid@karstad.org via smtp-1.isd.no X-Qmail-Scanner: 1.16 (Clear:. Processed in 0.349676 secs) Received: from unknown (HELO ?127.0.0.1?) (195.139.232.113) by 0 with SMTP; 3 Sep 2004 21:43:32 +0200 Date: Fri, 03 Sep 2004 21:43:25 +0200 From: Arnvid Karstad To: freebsd-current@freebsd.org Organization: isd Message-Id: <20040903212703.C660.ARNVID@karstad.org> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.11.02 [en] Subject: FreeBSD 5.x under VMware ESX server. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 19:43:34 -0000 Hello, we recently someone approached us to look at the possibility to run FreeBSD 5 under VMware ESX server, since they had some machines running with 4 allready they wanted to test out the newer versions. But it seems while 4.10 and earlier boots fine 5.2.1 and 5.3-BETA-1 both crashes a terrible death. When booting with verbose logging it stops when doing something with INT9. bt0 using strict something, then it goes to alot of errors like these bt: ccb 0xd9688080 - error 4 ocured. btstat = 11, sdstat = 0 then ioapic0: routing ... down to ioapic0: routing intpin 9 (ISA IRQ 9) to cluster 0 and then crash. On a normal boot it crashes at Waiting 15 seconds for SCSI devices to Settle M Any idea how to workaround this or are they stuck on FreeBSD 4 for now? Mvh/Best regards, Arnvid L. Karstad From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 19:54:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A45E16A4CE for ; Fri, 3 Sep 2004 19:54:42 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 559B343D49 for ; Fri, 3 Sep 2004 19:54:42 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i83JtSuu010590; Fri, 3 Sep 2004 12:55:28 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i83JtST9010589; Fri, 3 Sep 2004 12:55:28 -0700 Date: Fri, 3 Sep 2004 12:55:28 -0700 From: Brooks Davis To: Maksim Yevmenkin Message-ID: <20040903195528.GA9245@odin.ac.hmc.edu> References: <4138BE8D.7000102@savvis.net> <20040903191128.GA649@odin.ac.hmc.edu> <4138C82A.5020304@savvis.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <4138C82A.5020304@savvis.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-current@freebsd.org Subject: Re: fine grained locking and traversing linked lists X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 19:54:42 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 03, 2004 at 12:38:18PM -0700, Maksim Yevmenkin wrote: > Brooks Davis wrote: > >On Fri, Sep 03, 2004 at 11:57:17AM -0700, Maksim Yevmenkin wrote: > > > >>Dear Hackers, > >> > >>recent Robert Watson's locking changes made me to revisit locking in > >>the bluetooth code. bluetooth code uses linked lists for various > >>objects. quite often it is required to locate a certain object in the > >>list. during this operation i have to hold list mutex and individual > >>object mutex. this is very inconvenient. > > > >Why do you have to hold the object mutex? I can think of scenerios > >where that is required, but usually it isn't since they key is fixed at > >the time the item is inserted in to the list, or is at least protected > >by the list mutex. For an example of a key protected by the list > >mutex, consider struct ifnet's if_xname member relative to ifunit() and > >renaming. >=20 > well, again i'm using bluetooth sockets code as an example. there is a=20 > linked list of all PCB. each PCB has its own lock. so, when i need to=20 > locate PCB by any field i do >=20 > lock(list); > list_foreach(pcb, ...) { > lock(pcb); > if (compare(key)) { > unlock(pcb); > unlock(list); > return (pcb); > } > unlock(pcb); > } > unlock(list); > return (NULL); >=20 > in sockets layer some functions (i.e. bind, connect, control etc.) can=20 > change PCB fields without holding sockets list lock. >=20 > so, in some cases i want: lock(list), lock(pcb) and in other cases i=20 > want lock(pcb), lock(list). I guess my question was, do you really need to hold the pcb lock to do the compare. It doesn't matter if other fields change if the key can not. I don't know the code in question well enough do answer that question. The key thing is that just because a object has a lock, it does not follow that the lock must be held to touch the object. You just need to be sure the object can't be deleted. If you have refcounted objects, the list holds a refrence so if you hold the list lock, you are safe. > >>so, i've written a "spherical cow" that shows fine grained locking > >>when traversing linked lists (see below). basically, for double linked > >>list, in order to safely manipulate by object "y" one must hold three > >>locks: object "y" lock, object "x =3D y->previous" lock and object "z = =3D > >>y->next" lock. > >> > >>so, the $1 million question is: am i missing something? or this will wo= rk? > > > >How do you protect the head in this case? The list mutex would normally > >do so, but if the head can change, you'll need a mutex to protect it > >(using an array hid this issue). Also, doubly linked lists won't work > >without a lot of effort (read pain :-) because scanning backwards and > >forwards at the same time will lead to deadlock. >=20 > yes, the head is still the issue. but i think it can be avoided. i think= =20 > it only has to be protected when head changes from NULL -> non NULL and= =20 > vice versa. otherwise its just lock(head). > > i do not think that scanning backwards and forwards at the same time is= =20 > an issue. it is a (serious?) limitation i agree. but it is possible to=20 > scan list forward staring from any point. If you implement this, I strongly recommend making the lists singally linked to avoid the possiablity of this deadlock. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBOMwvXY6L6fI4GtQRAknfAKCPd4r95JdWaLDUhhJaIrGCJlwDFgCgpKqS FqIp/ftDFKtTOjB4ucEd66M= =vyKW -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 20:16:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73AF716A4CE; Fri, 3 Sep 2004 20:16:29 +0000 (GMT) Received: from cpanel.ezone.ru (cpanel.ezone.ru [213.85.31.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5ABF843D58; Fri, 3 Sep 2004 20:16:28 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from [81.195.2.185] (ppp2-185.pppoe.mtu-net.ru [81.195.2.185]) (authenticated bits=0) by cpanel.ezone.ru (8.13.1/8.12.11) with ESMTP id i83KGJhB003503; Sat, 4 Sep 2004 00:16:20 +0400 (MSD) (envelope-from mcsi@mcsi.pp.ru) Message-ID: <4138D10E.4060809@mcsi.pp.ru> Date: Sat, 04 Sep 2004 00:16:14 +0400 From: Maxim Maximov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040810 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: John Baldwin References: <4137EA5C.30606@mcsi.pp.ru> <4138A524.8080107@root.org> <4138A806.9020105@mcsi.pp.ru> <200409031341.47074.jhb@FreeBSD.org> In-Reply-To: <200409031341.47074.jhb@FreeBSD.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on mail3.ezone.ru cc: current@FreeBSD.org cc: Nate Lawson Subject: Re: panic on shutdown X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 20:16:29 -0000 John Baldwin wrote: > On Friday 03 September 2004 01:21 pm, Maxim Maximov wrote: > >>Nate Lawson wrote: >> >>>John Baldwin wrote: >>> >>>>On Thursday 02 September 2004 11:51 pm, Maxim Maximov wrote: >>>> >>>>>Hello. >>>>> >>>>> I just got this panic on shutdown using Power button, hand >>>>>transcribed: >>>>> >>>>>Syncing disks: >>>>>No buffers busy after final sync >>>>>Uptime: 21m53s >>>>>Powering system off using ACPI >>>>> >>>>>panic: lock (sleep mutex) Giant not locked @ >>>>>/usr/src/sys/kern/kern_timeout.c:279 >>>>> >>>>>cpuid = 0 >>>>>KDB: enter: panic >>>>>ACPI power-off failed - timeout >>>>> >>>>>Rebooting... >>>>>cpu_reset: called on cpu#1 >>>>>cpu_reset: Stopping other CPUs >>>>> >>>>>Here it hung until I pressed Power button again. Then it shut down. >>>> >>>>Looks like the timeout/callout routine dropped Giant more than it >>>>acquired it. >>> >>>I don't see how this could be triggered by ACPI. If you reboot the >>>system with ACPI disabled (or enabled), do you also get this message? >> >>My system can't boot with ACPI disabled. >> >>Also I want to mention that this panic is rare. I've seen it about 10 >>times in 2-3 months of everyday rebooting. >> >>And by the way, the command issued to shut the system down was 'halt -p' > > > I would hack the timeout code to add some printf's before the > mtx_unlock(&Giant) to dump the function pointer and argument > if !tmtx_owned(&Giant) and then use gdb to figure out what the callout > function was. I.e. something like: > > if (not mpsafe) { > if (!mtx_owned(&Giant)) > printf("func = %p, arg = %p\n", c_func, c_arg) > mtx_unlock(&Giant); > } > Thanks, I recompiled kernel with this code. I'll let you know if this yields anything.. -- Maxim Maximov From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 20:40:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A2F316A4CE for ; Fri, 3 Sep 2004 20:40:54 +0000 (GMT) Received: from mail20.syd.optusnet.com.au (mail20.syd.optusnet.com.au [211.29.132.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id A895F43D48 for ; Fri, 3 Sep 2004 20:40:53 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) i83KepZw030068 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 4 Sep 2004 06:40:52 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])i83KepxP067196 for ; Sat, 4 Sep 2004 06:40:51 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id i83Keptl067195 for current@freebsd.org; Sat, 4 Sep 2004 06:40:51 +1000 (EST) (envelope-from pjeremy) Date: Sat, 4 Sep 2004 06:40:51 +1000 From: Peter Jeremy To: current@freebsd.org Message-ID: <20040903204051.GA67184@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2i Subject: Re: LOR re0 and acpi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 20:40:54 -0000 Marius Nünnerich wrote this message on Mon, Aug 23, 2004 at 22:30 +0200: > after enabling ACPI in my BIOS and booting with ACPI enabled i got this LOR during boot on my 6.0-CURRENT as of yesterday (this is copy'n pasted from dmesg): http://sources.zabbadoz.net/freebsd/lor.html#026 Since it doesn't seem to have been mentioned before: I get this in 5.3-BETA2 as well. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 21:01:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C73BF16A4CE for ; Fri, 3 Sep 2004 21:01:45 +0000 (GMT) Received: from ganymede.hub.org (blk-222-46-91.eastlink.ca [24.222.46.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 590A743D39 for ; Fri, 3 Sep 2004 21:01:45 +0000 (GMT) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id AC392359FE; Fri, 3 Sep 2004 18:01:43 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id AB3A33538A for ; Fri, 3 Sep 2004 18:01:43 -0300 (ADT) Date: Fri, 3 Sep 2004 18:01:43 -0300 (ADT) From: "Marc G. Fournier" To: freebsd-current@freebsd.org Message-ID: <20040903175434.A812@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 21:01:45 -0000 I'm running another fsck on a 4.x system ... I know 5.x brings in the background mode for it, which would definitely make my life easier, *but* ... when running fsck, it says its using up 99% of the CPU: # ps aux | grep fsck root 67 99.0 5.0 184252 184284 p0 R+ 12:46PM 254:16.68 fsck -y /vm now, its a dual CPU system ... on an MP system, is it not possible to have it parallelize on a file system, so that it makes use of all available CPU? For instance, right now, its in Phase 4 ... on a file system where ctl-t shows: load: 0.99 cmd: fsck 67 [running] 15192.26u 142.30s 99% 184284k /dev/da0s1h: phase 4: cyl group 408 of 866 (47%) wouldn't it be possible, on a dual CPU system, to have group 434 and above run on one process, while group 433 and below running on the second, in parallel? Its not like the drives are being beat up: # iostat 5 tty da0 pass0 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 44 0.00 0 0.00 0.00 0 0.00 40 0 0 0 60 0 11 0.00 0 0.00 0.00 0 0.00 50 0 0 0 50 0 6 0.00 0 0.00 0.00 0 0.00 50 0 0 0 50 0 6 0.00 0 0.00 0.00 0 0.00 50 0 0 0 50 0 6 0.00 0 0.00 0.00 0 0.00 50 0 0 0 50 0 6 0.00 0 0.00 0.00 0 0.00 50 0 0 0 50 0 6 16.00 0 0.00 0.00 0 0.00 50 0 0 0 50 0 6 0.00 0 0.00 0.00 0 0.00 50 0 0 0 50 0 6 0.00 0 0.00 0.00 0 0.00 50 0 0 0 50 0 45 16.00 0 0.01 0.00 0 0.00 50 0 0 0 50 0 6 0.00 0 0.00 0.00 0 0.00 50 0 0 0 50 0 6 0.00 0 0.00 0.00 0 0.00 50 0 0 0 50 0 6 16.00 0 0.00 0.00 0 0.00 50 0 0 0 50 0 4600 16.00 3 0.04 0.00 0 0.00 49 0 1 0 50 0 18 16.00 0 0.01 0.00 0 0.00 50 0 0 0 50 0 16 16.00 1 0.01 0.00 0 0.00 50 0 0 0 50 So, it looks to me like the process is CPU bound, not disk ... Or, does 5.x's fsck already make better use of available CPUs? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 21:04:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F2C816A4CE; Fri, 3 Sep 2004 21:04:42 +0000 (GMT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 362B143D1F; Fri, 3 Sep 2004 21:04:42 +0000 (GMT) (envelope-from dantavious@comcast.net) Received: from focus.dantavious.com (pcp04630633pcs.gambrl01.md.comcast.net[68.49.58.89]) by comcast.net (rwcrmhc13) with ESMTP id <2004090321044101500lrv34e> (Authid: dantavious); Fri, 3 Sep 2004 21:04:41 +0000 From: Derrick Edwards To: freebsd-current@freebsd.org Date: Fri, 3 Sep 2004 17:14:05 -0400 User-Agent: KMail/1.7 References: <200409020800.42599.dantavious@comcast.net> In-Reply-To: <200409020800.42599.dantavious@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409031714.06053.dantavious@comcast.net> cc: current@freebsd.org Subject: Re: Sound in FreeBSD 5.3 Beta2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 21:04:42 -0000 On Thursday 02 September 2004 08:00 am, Derrick Edwards wrote: Matti made the suggestion to compile snd_ich in the kernel so I did. Still, I am not able to hear any sound. Any more ideas? Am I the only once having this problem? Thanks Derrick > I am having probs with sound. I have read a bunch of postings and tried > the following things. > > 1. added device sound to the kernel > > 2. added snd_driver_load="YES" to /boot/loader.conf just to get it > working. *When I initially added snd_driver_load="YES", I got some sound > then it crashed, and never came back. > > 3. added this to /boot/device.hints because it was in the man page. > hint.pcm.0.at="isa" > hint.pcm.0.irq="5" > hint.pcm.0.drq="1" > hint.pcm.0.flags="0x0" > > 4. Even tried to add pcm to the kernel. (ofcourse it did not work) > > This is the output of pciconf > > pcm0@pci0:31:5: class=0x040100 card=0x4941434d chip=0x24c58086 rev=0x02 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio > Controller' class = multimedia > subclass = audio > I would appreciate any assistance in this manner. > Thanks > Derrick > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 21:04:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F2C816A4CE; Fri, 3 Sep 2004 21:04:42 +0000 (GMT) Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 362B143D1F; Fri, 3 Sep 2004 21:04:42 +0000 (GMT) (envelope-from dantavious@comcast.net) Received: from focus.dantavious.com (pcp04630633pcs.gambrl01.md.comcast.net[68.49.58.89]) by comcast.net (rwcrmhc13) with ESMTP id <2004090321044101500lrv34e> (Authid: dantavious); Fri, 3 Sep 2004 21:04:41 +0000 From: Derrick Edwards To: freebsd-current@freebsd.org Date: Fri, 3 Sep 2004 17:14:05 -0400 User-Agent: KMail/1.7 References: <200409020800.42599.dantavious@comcast.net> In-Reply-To: <200409020800.42599.dantavious@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200409031714.06053.dantavious@comcast.net> cc: current@freebsd.org Subject: Re: Sound in FreeBSD 5.3 Beta2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 21:04:42 -0000 On Thursday 02 September 2004 08:00 am, Derrick Edwards wrote: Matti made the suggestion to compile snd_ich in the kernel so I did. Still, I am not able to hear any sound. Any more ideas? Am I the only once having this problem? Thanks Derrick > I am having probs with sound. I have read a bunch of postings and tried > the following things. > > 1. added device sound to the kernel > > 2. added snd_driver_load="YES" to /boot/loader.conf just to get it > working. *When I initially added snd_driver_load="YES", I got some sound > then it crashed, and never came back. > > 3. added this to /boot/device.hints because it was in the man page. > hint.pcm.0.at="isa" > hint.pcm.0.irq="5" > hint.pcm.0.drq="1" > hint.pcm.0.flags="0x0" > > 4. Even tried to add pcm to the kernel. (ofcourse it did not work) > > This is the output of pciconf > > pcm0@pci0:31:5: class=0x040100 card=0x4941434d chip=0x24c58086 rev=0x02 > hdr=0x00 > vendor = 'Intel Corporation' > device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio > Controller' class = multimedia > subclass = audio > I would appreciate any assistance in this manner. > Thanks > Derrick > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 21:09:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7484316A4CE for ; Fri, 3 Sep 2004 21:09:30 +0000 (GMT) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA1D243D2F for ; Fri, 3 Sep 2004 21:09:28 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from gothmog.gr (patr530-a048.otenet.gr [212.205.215.48]) i83L9LLM002445; Sat, 4 Sep 2004 00:09:24 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.1/8.13.1) with ESMTP id i83L7RXT001335; Sat, 4 Sep 2004 00:07:27 +0300 (EEST) (envelope-from keramida@linux.gr) Received: (from giorgos@localhost) by gothmog.gr (8.13.1/8.13.1/Submit) id i83L7QGM001334; Sat, 4 Sep 2004 00:07:26 +0300 (EEST) (envelope-from keramida@linux.gr) Date: Sat, 4 Sep 2004 00:07:25 +0300 From: Giorgos Keramidas To: Maksim Yevmenkin Message-ID: <20040903210725.GA1199@gothmog.gr> References: <4138BE8D.7000102@savvis.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4138BE8D.7000102@savvis.net> Phone: +30-2610-312145 Mobile: +30-6944-116520 cc: freebsd-current@freebsd.org Subject: Re: fine grained locking and traversing linked lists X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 21:09:30 -0000 On 2004-09-03 11:57, Maksim Yevmenkin wrote: > > so, i've written a "spherical cow" that shows fine grained locking > when traversing linked lists (see below). basically, for double linked > list, in order to safely manipulate by object "y" one must hold three > locks: object "y" lock, object "x = y->previous" lock and object "z = > y->next" lock. > > so, the $1 million question is: am i missing something? or this will work? See ``the dining philosophers problem'' at Google. From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 21:16:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 03D0316A4CE for ; Fri, 3 Sep 2004 21:16:21 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44BF643D31 for ; Fri, 3 Sep 2004 21:16:20 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from gothmog.gr (patr530-a048.otenet.gr [212.205.215.48]) i83LGHCd024666; Sat, 4 Sep 2004 00:16:18 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.1/8.13.1) with ESMTP id i83LESGf014171; Sat, 4 Sep 2004 00:14:28 +0300 (EEST) (envelope-from keramida@linux.gr) Received: (from giorgos@localhost) by gothmog.gr (8.13.1/8.13.1/Submit) id i83LES6I014170; Sat, 4 Sep 2004 00:14:28 +0300 (EEST) (envelope-from keramida@linux.gr) Date: Sat, 4 Sep 2004 00:14:28 +0300 From: Giorgos Keramidas To: "Marc G. Fournier" Message-ID: <20040903211427.GB1199@gothmog.gr> References: <20040903175434.A812@ganymede.hub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040903175434.A812@ganymede.hub.org> Phone: +30-2610-312145 Mobile: +30-6944-116520 cc: freebsd-current@freebsd.org Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 21:16:21 -0000 On 2004-09-03 18:01, "Marc G. Fournier" wrote: > > load: 0.99 cmd: fsck 67 [running] 15192.26u 142.30s 99% 184284k > /dev/da0s1h: phase 4: cyl group 408 of 866 (47%) > > wouldn't it be possible, on a dual CPU system, to have group 434 and above > run on one process, while group 433 and below running on the second, in > parallel? Its not like the drives are being beat up: My intuition says that if metadata of the first part of the disk references data residing on the second part synchronization and locking would probably be a bit difficult; actually very difficult. From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 21:35:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCDC016A4CE for ; Fri, 3 Sep 2004 21:35:17 +0000 (GMT) Received: from tomts36-srv.bellnexxia.net (tomts36.bellnexxia.net [209.226.175.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFD2943D41 for ; Fri, 3 Sep 2004 21:35:16 +0000 (GMT) (envelope-from dashevil@sympatico.ca) Received: from [192.168.2.32] ([65.93.56.160]) by tomts36-srv.bellnexxia.netESMTP <20040903213515.MUKY25796.tomts36-srv.bellnexxia.net@[192.168.2.32]>; Fri, 3 Sep 2004 17:35:15 -0400 From: Chris Laverdure To: Giorgos Keramidas In-Reply-To: <20040903211427.GB1199@gothmog.gr> References: <20040903175434.A812@ganymede.hub.org> <20040903211427.GB1199@gothmog.gr> Content-Type: text/plain Message-Id: <1094232909.76688.1.camel@elemental.DashEvil> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 03 Sep 2004 17:35:10 +0000 Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 21:35:17 -0000 On Fri, 2004-09-03 at 21:14, Giorgos Keramidas wrote: > On 2004-09-03 18:01, "Marc G. Fournier" wrote: > > > > load: 0.99 cmd: fsck 67 [running] 15192.26u 142.30s 99% 184284k > > /dev/da0s1h: phase 4: cyl group 408 of 866 (47%) > > > > wouldn't it be possible, on a dual CPU system, to have group 434 and above > > run on one process, while group 433 and below running on the second, in > > parallel? Its not like the drives are being beat up: > > My intuition says that if metadata of the first part of the disk references > data residing on the second part synchronization and locking would probably > be a bit difficult; actually very difficult. My intuition tells me that it would be a much better solution to run multiple fsck's concurrently. What harm could there be in fscking (num of processors) partitions at the same time? From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 21:52:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7052016A4CE for ; Fri, 3 Sep 2004 21:52:50 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACCB343D1F for ; Fri, 3 Sep 2004 21:52:49 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from gothmog.gr (patr530-a048.otenet.gr [212.205.215.48]) i83LqkSZ027329; Sat, 4 Sep 2004 00:52:47 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.1/8.13.1) with ESMTP id i83Lou9X041279; Sat, 4 Sep 2004 00:50:56 +0300 (EEST) (envelope-from keramida@linux.gr) Received: (from giorgos@localhost) by gothmog.gr (8.13.1/8.13.1/Submit) id i83Lot6u041248; Sat, 4 Sep 2004 00:50:55 +0300 (EEST) (envelope-from keramida@linux.gr) Date: Sat, 4 Sep 2004 00:50:55 +0300 From: Giorgos Keramidas To: Chris Laverdure Message-ID: <20040903215054.GD1199@gothmog.gr> References: <20040903175434.A812@ganymede.hub.org> <20040903211427.GB1199@gothmog.gr> <1094232909.76688.1.camel@elemental.DashEvil> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1094232909.76688.1.camel@elemental.DashEvil> Phone: +30-2610-312145 Mobile: +30-6944-116520 cc: freebsd-current@freebsd.org Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 21:52:50 -0000 On 2004-09-03 17:35, Chris Laverdure wrote: > On Fri, 2004-09-03 at 21:14, Giorgos Keramidas wrote: > > (Regarding "parallelization" of fsck by spawning many instances of > > fsck for parts of the same partition...) > > > > My intuition says that if metadata of the first part of the disk references > > data residing on the second part synchronization and locking would probably > > be a bit difficult; actually very difficult. > > My intuition tells me that it would be a much better solution to run > multiple fsck's concurrently. What harm could there be in fscking (num > of processors) partitions at the same time? AFAIK, this is exactly what "background fsck" does in 5.X :-) From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 21:58:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28AD616A4CE for ; Fri, 3 Sep 2004 21:58:48 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id A071243D2F for ; Fri, 3 Sep 2004 21:58:47 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i83LwdWg030214; Fri, 3 Sep 2004 14:58:43 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409032158.i83LwdWg030214@gw.catspoiler.org> Date: Fri, 3 Sep 2004 14:58:39 -0700 (PDT) From: Don Lewis To: scrappy@hub.org In-Reply-To: <20040903175434.A812@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 21:58:48 -0000 On 3 Sep, Marc G. Fournier wrote: > > I'm running another fsck on a 4.x system ... I know 5.x brings in the > background mode for it, which would definitely make my life easier, *but* > ... when running fsck, it says its using up 99% of the CPU: > > # ps aux | grep fsck > root 67 99.0 5.0 184252 184284 p0 R+ 12:46PM 254:16.68 fsck -y /vm > > now, its a dual CPU system ... on an MP system, is it not possible to have > it parallelize on a file system, so that it makes use of all available > CPU? > > For instance, right now, its in Phase 4 ... on a file system where ctl-t > shows: > > load: 0.99 cmd: fsck 67 [running] 15192.26u 142.30s 99% 184284k > /dev/da0s1h: phase 4: cyl group 408 of 866 (47%) > > wouldn't it be possible, on a dual CPU system, to have group 434 and above > run on one process, while group 433 and below running on the second, in > parallel? Its not like the drives are being beat up: Would the file system in question happen to be full of UNREF files that fsck is deleting? I just took a look at the sparsely commented fsck code and it looks like fsck builds a list of inodes that have a zero link count during pass 1. During pass 4 fsck visits each inode that it has marked as being in either the FSTATE or DFOUND states, and either adjusts the inodes link count, or of the link count is zero, it removes the inode from the list it constructed in pass 1 and clears the inode. Because this list is just a linear linked list and inodes are prepended to the beginning in increasing inode order, and inodes are removed in increasing inode order, it looks like the entire list needs to be traversed each time an inode is removed. That would cause the run time to increase as the square of the number of UNREF'ed inodes. Using two CPUs would give you at best a 2x speedup, and in this case it would be quite a bit less since both CPUs would be trying to access and modify the same data structure. Just using a better data structure is likely to speed things up much more than 2x. Something as simple as building the list in reverse order in pass 1 is likely to make a huge difference. From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 22:04:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 842DD16A4CE for ; Fri, 3 Sep 2004 22:04:30 +0000 (GMT) Received: from out002.email.savvis.net (out002.apptix.savvis.net [216.91.32.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D88943D41 for ; Fri, 3 Sep 2004 22:04:30 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from s228130hz1ew03.apptix-01.savvis.net ([10.146.4.28]) by out002.email.savvis.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Sep 2004 17:04:29 -0500 Received: from [10.254.186.111] ([66.35.239.94]) by s228130hz1ew03.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 3 Sep 2004 17:04:28 -0500 Message-ID: <4138EA67.8090605@savvis.net> Date: Fri, 03 Sep 2004 15:04:23 -0700 From: Maksim Yevmenkin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040822 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <4138BE8D.7000102@savvis.net> <20040903191128.GA649@odin.ac.hmc.edu> <4138C82A.5020304@savvis.net> <20040903195528.GA9245@odin.ac.hmc.edu> In-Reply-To: <20040903195528.GA9245@odin.ac.hmc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Sep 2004 22:04:28.0902 (UTC) FILETIME=[FBB8A060:01C49201] cc: freebsd-current@freebsd.org Subject: Re: fine grained locking and traversing linked lists X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 22:04:30 -0000 Brooks Davis wrote: > On Fri, Sep 03, 2004 at 12:38:18PM -0700, Maksim Yevmenkin wrote: >>>>recent Robert Watson's locking changes made me to revisit locking in >>>>the bluetooth code. bluetooth code uses linked lists for various >>>>objects. quite often it is required to locate a certain object in the >>>>list. during this operation i have to hold list mutex and individual >>>>object mutex. this is very inconvenient. >>> >>>Why do you have to hold the object mutex? I can think of scenerios >>>where that is required, but usually it isn't since they key is fixed at >>>the time the item is inserted in to the list, or is at least protected >>>by the list mutex. For an example of a key protected by the list >>>mutex, consider struct ifnet's if_xname member relative to ifunit() and >>>renaming. >> >>well, again i'm using bluetooth sockets code as an example. there is a >>linked list of all PCB. each PCB has its own lock. so, when i need to >>locate PCB by any field i do >> >>lock(list); >>list_foreach(pcb, ...) { >> lock(pcb); >> if (compare(key)) { >> unlock(pcb); >> unlock(list); >> return (pcb); >> } >> unlock(pcb); >>} >>unlock(list); >>return (NULL); >> >>in sockets layer some functions (i.e. bind, connect, control etc.) can >>change PCB fields without holding sockets list lock. >> >>so, in some cases i want: lock(list), lock(pcb) and in other cases i >>want lock(pcb), lock(list). > > I guess my question was, do you really need to hold the pcb lock to > do the compare. It doesn't matter if other fields change if the key > can not. I don't know the code in question well enough do answer that > question. the key field can change :( > The key thing is that just because a object has a lock, it does not > follow that the lock must be held to touch the object. You just need to > be sure the object can't be deleted. If you have refcounted objects, > the list holds a refrence so if you hold the list lock, you are safe. yes, i understand this. >>>>so, i've written a "spherical cow" that shows fine grained locking >>>>when traversing linked lists (see below). basically, for double linked >>>>list, in order to safely manipulate by object "y" one must hold three >>>>locks: object "y" lock, object "x = y->previous" lock and object "z = >>>>y->next" lock. >>>> >>>>so, the $1 million question is: am i missing something? or this will work? >>> >>>How do you protect the head in this case? The list mutex would normally >>>do so, but if the head can change, you'll need a mutex to protect it >>>(using an array hid this issue). Also, doubly linked lists won't work >>>without a lot of effort (read pain :-) because scanning backwards and >>>forwards at the same time will lead to deadlock. >> >>yes, the head is still the issue. but i think it can be avoided. i think >>it only has to be protected when head changes from NULL -> non NULL and >>vice versa. otherwise its just lock(head). >> >>i do not think that scanning backwards and forwards at the same time is >>an issue. it is a (serious?) limitation i agree. but it is possible to >>scan list forward staring from any point. well, after thinking a bit more about the list head protection, i do not really need the list head lock. all i need is to ensure the list head never changes. this can be easily done by addind the static dummy entry and use it as the list head. this way if i want to insert element into the list all i need is lock dummy entry (head) and head->next (if any). then i can safely insert element after the head. > If you implement this, I strongly recommend making the lists singally > linked to avoid the possiablity of this deadlock. yes, i was thinking the same too. but double-linked list gives o(1) deletion (which is very nice :) so i guess the restrictions are: 1) lock order: item "x", then item "x->previous" (if any), then item "x->next" (if any) 2) always scan list forward 3) never use "x->previuos" field (except for "x" locking) it can even be done with standard sys/queue.h macros :) i just ran wintess test and it only complained about "acquiring duplicate lock of same type". thanks, max From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 22:31:17 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12FAC16A5A1; Fri, 3 Sep 2004 22:31:17 +0000 (GMT) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55CC843D46; Fri, 3 Sep 2004 22:31:15 +0000 (GMT) (envelope-from keramida@linux.gr) Received: from gothmog.gr (patr530-a148.otenet.gr [212.205.215.148]) i83MVBaF029519; Sat, 4 Sep 2004 01:31:12 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.1/8.13.1) with ESMTP id i83MGSqa070798; Sat, 4 Sep 2004 01:16:28 +0300 (EEST) (envelope-from keramida@linux.gr) Received: (from giorgos@localhost) by gothmog.gr (8.13.1/8.13.1/Submit) id i83MGSkH070797; Sat, 4 Sep 2004 01:16:28 +0300 (EEST) (envelope-from keramida@linux.gr) Date: Sat, 4 Sep 2004 01:16:28 +0300 From: Giorgos Keramidas To: Don Lewis Message-ID: <20040903221628.GA51595@gothmog.gr> References: <20040903175434.A812@ganymede.hub.org> <200409032158.i83LwdWg030214@gw.catspoiler.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409032158.i83LwdWg030214@gw.catspoiler.org> Phone: +30-2610-312145 Mobile: +30-6944-116520 cc: freebsd-current@freebsd.org Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 22:31:17 -0000 On 2004-09-03 14:58, Don Lewis wrote: > > Would the file system in question happen to be full of UNREF files that > fsck is deleting? > > I just took a look at the sparsely commented fsck code and it looks like > fsck builds a list of inodes that have a zero link count during pass 1. > During pass 4 fsck visits each inode that it has marked as being in > either the FSTATE or DFOUND states, and either adjusts the inodes link > count, or of the link count is zero, it removes the inode from the list > it constructed in pass 1 and clears the inode. > > Because this list is just a linear linked list and inodes are prepended > to the beginning in increasing inode order, and inodes are removed in > increasing inode order, it looks like the entire list needs to be > traversed each time an inode is removed. That would cause the run time > to increase as the square of the number of UNREF'ed inodes. > > Using two CPUs would give you at best a 2x speedup, and in this case it > would be quite a bit less since both CPUs would be trying to access and > modify the same data structure. Just using a better data structure is > likely to speed things up much more than 2x. Something as simple as > building the list in reverse order in pass 1 is likely to make a huge > difference. Holding both a head and tail pointer to the singly-linked list should probably make it easier to add nodes at the end of the list instead of the head. I haven't read the source of fsck_ffs at all though, so I don't know if I can come up with a working patch in a reasonable amount of time. From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 22:52:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67CE616A4CE for ; Fri, 3 Sep 2004 22:52:21 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id E210843D31 for ; Fri, 3 Sep 2004 22:52:20 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i83MqBJl030297; Fri, 3 Sep 2004 15:52:15 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409032252.i83MqBJl030297@gw.catspoiler.org> Date: Fri, 3 Sep 2004 15:52:11 -0700 (PDT) From: Don Lewis To: keramida@linux.gr In-Reply-To: <20040903221628.GA51595@gothmog.gr> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 22:52:21 -0000 On 4 Sep, Giorgos Keramidas wrote: > On 2004-09-03 14:58, Don Lewis wrote: >> Using two CPUs would give you at best a 2x speedup, and in this case it >> would be quite a bit less since both CPUs would be trying to access and >> modify the same data structure. Just using a better data structure is >> likely to speed things up much more than 2x. Something as simple as >> building the list in reverse order in pass 1 is likely to make a huge >> difference. > > Holding both a head and tail pointer to the singly-linked list should > probably make it easier to add nodes at the end of the list instead of > the head. I haven't read the source of fsck_ffs at all though, so I > don't know if I can come up with a working patch in a reasonable amount > of time. Yes, if fsck used the macros, this data structure should probably be a STAILQ. The code if fsck is all hand rolled and it would be trivially easy to add a tail pointer. The head of the list in question is struct zlncnt *zlnhead; The only modifications needed would be in the initialization code in main.c, and the code that builds the list in pass1.c. From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 23:07:45 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1E1E16A4CE for ; Fri, 3 Sep 2004 23:07:45 +0000 (GMT) Received: from jagor.srce.hr (jagor.srce.hr [161.53.2.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id D46BE43D1D for ; Fri, 3 Sep 2004 23:07:44 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from [193.198.136.221] (cmung2253.cmu.carnet.hr [193.198.136.221]) by jagor.srce.hr (8.12.10/8.12.10) with ESMTP id i83N7e9K000589 for ; Sat, 4 Sep 2004 01:07:42 +0200 (CEST) Message-ID: <4138F932.50202@fer.hr> Date: Sat, 04 Sep 2004 01:07:30 +0200 From: Ivan Voras User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040502 Thunderbird/0.6 Mnenhy/0.6.0.104 X-Accept-Language: en MIME-Version: 1.0 To: current@freebsd.org References: <4138754D.70004@nrg4u.com> In-Reply-To: <4138754D.70004@nrg4u.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.42 X-Virus-Scanned: by amavisd-new at jagor.srce.hr Subject: Re: Presentation on new things in Network Stack for 5.3 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 23:07:45 -0000 Andre Oppermann wrote: > I've made a presentation today at SUNCON'04 in Zurich, Switzerland on > the new > things and changes in FreeBSD 5.3 Network Stack. You can find it here: > > http://people.freebsd.org/~andre/ > > It is fairly high-level and intended for server and system > administrators as > well as developers. As the new -STABLE version is approaching, documentation such as this is HIGHLY desireable to "spread the word". If it's not already made, there should be a document which enumerates (on exactly the level of the above presentation) "What's new in 5-STABLE" (compared to 4-STABLE). The above presentation (probably in HTML or SGML) would be an excellent start :) Good work, Andre, and good work all who actively made it happen! :) From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 23:27:20 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BEC916A4CE for ; Fri, 3 Sep 2004 23:27:20 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE56443D53 for ; Fri, 3 Sep 2004 23:27:19 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 29410 invoked from network); 3 Sep 2004 23:27:19 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail1.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 3 Sep 2004 23:27:19 -0000 Received: from hydrogen.funkthat.com (lwxklm@localhost.funkthat.com [127.0.0.1])i83NRHuU026503; Fri, 3 Sep 2004 16:27:18 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i83NRHhD026502; Fri, 3 Sep 2004 16:27:17 -0700 (PDT) Date: Fri, 3 Sep 2004 16:27:17 -0700 From: John-Mark Gurney To: Maksim Yevmenkin Message-ID: <20040903232716.GL29902@funkthat.com> Mail-Followup-To: Maksim Yevmenkin , Brooks Davis , freebsd-current@freebsd.org References: <4138BE8D.7000102@savvis.net> <20040903191128.GA649@odin.ac.hmc.edu> <4138C82A.5020304@savvis.net> <20040903195528.GA9245@odin.ac.hmc.edu> <4138EA67.8090605@savvis.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4138EA67.8090605@savvis.net> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-current@freebsd.org Subject: Re: fine grained locking and traversing linked lists X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2004 23:27:20 -0000 Maksim Yevmenkin wrote this message on Fri, Sep 03, 2004 at 15:04 -0700: > >If you implement this, I strongly recommend making the lists singally > >linked to avoid the possiablity of this deadlock. > > yes, i was thinking the same too. but double-linked list gives o(1) > deletion (which is very nice :) > > so i guess the restrictions are: > > 1) lock order: item "x", then item "x->previous" (if any), then item > "x->next" (if any) > > 2) always scan list forward > > 3) never use "x->previuos" field (except for "x" locking) > > it can even be done with standard sys/queue.h macros :) i just ran > wintess test and it only complained about "acquiring duplicate lock of > same type". This can still lead to a dead lock: obja <-> objb <-> objc <-> objd T1: lock (objb), lock(obja) T2: lock (objc), lock(objb, but blocks for T1) T1: lock (objc, blocks for T2) So, one solution is to use a list lock, and a refcnt'd object. Then all of the next/previous pointers are protected by the list lock, and the list gets one ref... Since you're using refcnts, you can keep a ref, unlock the object lock, lock the list lock, before relocking the object lock if necessary... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 23:28:57 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1C7A16A4CE for ; Fri, 3 Sep 2004 23:28:57 +0000 (GMT) Received: from mail1.speakeasy.net (mail1.speakeasy.net [216.254.0.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5EF743D46 for ; Fri, 3 Sep 2004 23:28:57 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 31397 invoked from network); 3 Sep 2004 23:28:57 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail1.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 3 Sep 2004 23:28:57 -0000 Received: from hydrogen.funkthat.com (yvwfgj@localhost.funkthat.com [127.0.0.1])i83NSuuU026572; Fri, 3 Sep 2004 16:28:56 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i83NStI0026571; Fri, 3 Sep 2004 16:28:55 -0700 (PDT) Date: Fri, 3 Sep 2004 16:28:55 -0700 From: John-Mark Gurney To: Peter Jeremy Message-ID: <20040903232855.GM29902@funkthat.com> Mail-Followup-To: Peter Jeremy , current@freebsd.org References: <20040903204051.GA67184@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20040903204051.GA67184@cirb503493.alcatel.com.au> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: current@freebsd.org Subject: Re: LOR re0 and acpi X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2004 23:28:58 -0000 Peter Jeremy wrote this message on Sat, Sep 04, 2004 at 06:40 +1000: > Marius Nünnerich wrote this message on Mon, Aug 23, 2004 at 22:30 +0200: > > after enabling ACPI in my BIOS and booting with ACPI enabled i got this LOR during boot on my 6.0-CURRENT as of yesterday (this is copy'n pasted from dmesg): > > http://sources.zabbadoz.net/freebsd/lor.html#026 > > Since it doesn't seem to have been mentioned before: I get this in > 5.3-BETA2 as well. I've committed the fix to -current, and plan to MFC in a week... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 00:08:56 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4C7616A4CE; Sat, 4 Sep 2004 00:08:56 +0000 (GMT) Received: from angui.sh (angui.sh [216.171.167.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3E3143D55; Sat, 4 Sep 2004 00:08:56 +0000 (GMT) (envelope-from wfroning@angui.sh) Received: from angui.sh (localhost [127.0.0.1]) by angui.sh (8.12.9p2/8.12.8) with ESMTP id i8408rxd035403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 3 Sep 2004 17:08:53 -0700 (PDT) (envelope-from wfroning@angui.sh) Received: from localhost (wfroning@localhost) by angui.sh (8.12.9p2/8.12.8/Submit) with ESMTP id i8408ceg035399; Fri, 3 Sep 2004 17:08:53 -0700 (PDT) (envelope-from wfroning@angui.sh) Date: Fri, 3 Sep 2004 17:08:38 -0700 (PDT) From: Will Froning To: freebsd-current@freebsd.org Message-ID: <20040903165214.W8095@angui.sh> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.39 cc: kientzle@freebsd.org Subject: bsdtar breakage on 5.3-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 00:08:56 -0000 On a FBSD4.10 box I have created a tar file of a users home directory and then copied it over to a 5.3-BETA2 box (MD5 checksums match). I get at least this file inconsistancy: FBSD4.10 tar shows: -rw------- 14643/202 456 Aug 22 15:54 2003 tpayne/.gconf/apps/panel/profiles/default/objects/1t1061343718ut570825u15070p15903r8419k4290697116/%gconf.xml FBSD5.3-BETA2 tar shows: drw------- 0 14643 202 456 Aug 22 2003 tpayne/.gconf/apps/panel/profiles/default/objects/1t1061343718ut570825u15070p15903r8419k4290697116/%gconf.xml I have the tar available if anyone needs it (1.5MB). Thanks, Will -- Will Froning Unix Sys. Admin. wfroning@angui.sh From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 00:20:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A600F16A4CE; Sat, 4 Sep 2004 00:20:09 +0000 (GMT) Received: from out003.verizon.net (out003pub.verizon.net [206.46.170.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1948343D54; Sat, 4 Sep 2004 00:20:09 +0000 (GMT) (envelope-from andrew.lankford@verizon.net) Received: from outgoing.verizon.net ([192.168.1.1]) by out003.verizon.net ESMTP <20040904002008.CVQQ26805.out003.verizon.net@outgoing.verizon.net>; Fri, 3 Sep 2004 19:20:08 -0500 X-Mailer: Openwave WebEngine, version 2.8.12 (webedge20-101-197-20030912) From: Andrew Lankford To: , Date: Fri, 3 Sep 2004 19:20:08 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out003.verizon.net from [192.168.1.1] at Fri, 3 Sep 2004 19:20:08 -0500 Message-Id: <20040904002008.CVQQ26805.out003.verizon.net@outgoing.verizon.net> Subject: Latest MFCs break boot on amd64 notebook. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: andrew.lankford@verizon.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2004 00:20:09 -0000 The latest MFCs (the eagerly awaited boot-time module loading functionality on amd64) compiled ok, but my machine freezes and then powers down shortly after "boot" from the loader. I would try to give you all more details, but my old working kernel seems to be lost, and so I'm pretty much down for the count. Any other amd64 users out there tried rebuilding their kernels in the past few hours? Andrew Lankford From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 00:45:41 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9ACCC16A4CF for ; Sat, 4 Sep 2004 00:45:41 +0000 (GMT) Received: from mmp.dnsalias.org (YahooBB218179180003.bbtec.net [218.179.180.3]) by mx1.FreeBSD.org (Postfix) with SMTP id B14C243D39 for ; Sat, 4 Sep 2004 00:45:40 +0000 (GMT) (envelope-from thasegawa@mta.biglobe.ne.jp) Received: (qmail 93196 invoked from network); 4 Sep 2004 00:44:04 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by 0 with SMTP; 4 Sep 2004 00:44:04 -0000 Date: Sat, 04 Sep 2004 09:43:34 +0900 (JST) Message-Id: <20040904.094334.74753938.thasegawa@mta.biglobe.ne.jp> To: freebsd-current@freebsd.org From: HASEGAWA Tomoki X-Mailer: Mew version 4.0.66 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: pccard fixed disk not work on 5.3-BETA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 00:45:41 -0000 On 5.3-BETA2, my SmartMedia(with Hagiwra sys-com adapter) and ata disk card (DATAFAB PCMCIA-TO-IDE) don't work. They used to work on 4-STABLE or 5-CURRENT(at least till May,2004). The pcic of my laptop(Toshiba DynaBook SS3380) is TOPIC95B cbb0: irq 11 at device 11.0 on pci0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: irq 11 at device 11.1 on pci0 pccard1: <16-bit PCCard bus> on cbb1 dmesg for SmartMedia Status is 0x30000411 cbb1: card inserted: event=0x00000000, state=30000411 pccard1: chip_socket_enable cbb_pcic_socket_enable: cbb1: cbb_power: 5V pccard1: read_cis cis mem map 0xcac76000 (resource: 0x88010000) pccard1: CIS tuple chain: CISTPL_DEVICE type=funcspec speed=250ns 01 03 d9 01 ff unhandled CISTPL 18 18 02 df 01 CISTPL_MANFID 20 04 00 00 00 00 CISTPL_FUNCID 21 02 04 01 CISTPL_FUNCE 22 02 01 01 CISTPL_FUNCE 22 03 02 04 07 unhandled CISTPL 1c 1c 04 03 d9 01 ff CISTPL_CONFIG 1a 05 01 03 00 02 0f CISTPL_CFTABLE_ENTRY 1b 0a c0 c0 a1 07 55 4d 5d 08 00 20 CISTPL_CFTABLE_ENTRY 1b 05 00 01 01 b5 1e CISTPL_CFTABLE_ENTRY 1b 0c c1 41 99 07 55 4d 5d 64 f0 ff ff 20 CISTPL_CFTABLE_ENTRY 1b 05 01 01 01 b5 1e CISTPL_CFTABLE_ENTRY 1b 11 c2 41 99 07 55 4d 5d ea 61 f0 01 07 f6 03 01 ee 20 CISTPL_CFTABLE_ENTRY 1b 05 02 01 01 b5 1e CISTPL_CFTABLE_ENTRY 1b 11 c3 41 99 07 55 4d 5d ea 61 70 01 07 76 03 01 ee 20 CISTPL_CFTABLE_ENTRY 1b 05 03 01 01 b5 1e CISTPL_VERS_1 15 14 05 00 20 20 20 20 20 20 20 00 20 20 20 20 00 30 2e 30 00 ff CISTPL_NO_LINK 14 00 CISTPL_END ff pccard1: check_cis_quirks pccard1: CIS version PC Card Standard 5.0 pccard1: CIS info: , , 0.0 pccard1: Manufacturer code 0x0, product 0x0 pccard1: function 0: fixed disk, ccr addr 200 mask f pccard1: function 0, config table entry 0: memory card; irq mask 0; memspace 0-7ff; mwait_required rdybsy_active powerdown pccard1: function 0, config table entry 1: I/O card; irq mask ffff; iomask 4, iospace 0-f; memspace 0-7ff; rdybsy_active io8 io16 irqshare irqpulse irqlevel powerdown pccard1: function 0, config table entry 2: I/O card; irq mask 4000; iomask a, iospace 1f0-1f7 3f6-3f7; memspace 0-7ff; rdybsy_active io8 io16 irqshare irqpulse irqlevel powerdown pccard1: function 0, config table entry 3: I/O card; irq mask 4000; iomask a, iospace 170-177 376-377; memspace 0-7ff; rdybsy_active io8 io16 irqshare irqpulse irqlevel powerdown pccard1: functions scanning pccard1: Card has 1 functions. pccard_mfc is 0 pccard1: Memory space not yet implemented. pccard1: Neither memory nor I/O mampped pccard1: Allocation failed for cfe 0 pccard1: I/O rid 0 start 0 end ffffffff pccard1: Memory space not yet implemented. cbb_pcic_socket_enable: cbb1: cbb_power: 0V cbb1: cbb_power: 5V pccard1: ccr_res == 88001000-880013ff, base=200 pccard1: function 0 CCR at 0 offset 200: 41 0 e 0, 0 0 0 0, 0 pccard1: (manufacturer=0x0000, product=0x0000) at function 0 pccard1: CIS info: , , 0.0 dmesg for PCMCIA-TO-IDE Status is 0x30000411 cbb1: card inserted: event=0x00000000, state=30000411 pccard1: chip_socket_enable cbb_pcic_socket_enable: cbb1: cbb_power: 5V pccard1: read_cis cis mem map 0xcac77000 (resource: 0x88010000) pccard1: CIS tuple chain: CISTPL_DEVICE type=funcspec speed=null 01 03 d8 00 ff CISTPL_CONFIG 1a 05 01 03 00 02 0f CISTPL_CFTABLE_ENTRY 1b 0e c1 41 18 ca 61 70 01 07 76 03 01 30 00 80 CISTPL_CFTABLE_ENTRY 1b 0e 82 41 18 ca 61 60 01 07 66 03 01 30 00 10 CISTPL_CFTABLE_ENTRY 1b 0e 83 41 18 ca 61 50 01 07 56 03 01 30 00 04 CISTPL_FUNCID 21 02 04 00 CISTPL_FUNCE 22 02 01 01 CISTPL_FUNCE 22 03 02 08 7f unhandled CISTPL 18 18 02 df 01 CISTPL_VERS_1 15 19 04 01 44 41 54 41 46 41 42 00 50 43 4d 43 49 41 2d 54 4f 2d 49 44 45 00 ff CISTPL_NO_LINK 14 00 CISTPL_END ff pccard1: check_cis_quirks pccard1: CIS version PCCARD 2.0 or 2.1 pccard1: CIS info: DATAFAB, PCMCIA-TO-IDE pccard1: Manufacturer code 0xffffffff, product 0xffffffff pccard1: function 0: fixed disk, ccr addr 200 mask f pccard1: function 0, config table entry 1: I/O card; irq mask 8000; iomask a, iospace 170-177 376-377; rdybsy_active io16 irqlevel pccard1: function 0, config table entry 2: I/O card; irq mask 1000; iomask a, iospace 160-167 366-367; rdybsy_active io16 irqlevel pccard1: function 0, config table entry 3: I/O card; irq mask 400; iomask a, iospace 150-157 356-357; rdybsy_active io16 irqlevel pccard1: functions scanning pccard1: Card has 1 functions. pccard_mfc is 0 pccard1: I/O rid 0 start 170 end 177 pccard1: Allocation failed for cfe 1 pccard1: I/O rid 0 start 160 end 167 pccard1: I/O rid 1 start 366 end 367 cbb_pcic_socket_enable: cbb1: cbb_power: 0V cbb1: cbb_power: 5V pccard1: ccr_res == 88001000-880013ff, base=200 pccard1: function 0 CCR at 0 offset 200: 1 3 d8 0, 1a 5 1 3, 0 pccard1: (manufacturer=0xffffffff, product=0xffffffff) at function 0 pccard1: CIS info: DATAFAB, PCMCIA-TO-IDE, (null) From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 00:51:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2580B16A4CE; Sat, 4 Sep 2004 00:51:48 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE05743D45; Sat, 4 Sep 2004 00:51:47 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.0.200] ([192.168.0.200]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i840pjj3088387; Fri, 3 Sep 2004 18:51:45 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <413910FD.2090905@samsco.org> Date: Fri, 03 Sep 2004 18:49:01 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: andrew.lankford@verizon.net References: <20040904002008.CVQQ26805.out003.verizon.net@outgoing.verizon.net> In-Reply-To: <20040904002008.CVQQ26805.out003.verizon.net@outgoing.verizon.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: amd64@freebsd.org cc: current@freebsd.org Subject: Re: Latest MFCs break boot on amd64 notebook. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 00:51:48 -0000 Andrew Lankford wrote: > The latest MFCs (the eagerly awaited boot-time module > loading functionality on amd64) compiled ok, but my > machine freezes and then powers down shortly after > "boot" from the loader. I would try to give you all > more details, but my old working kernel seems to be > lost, and so I'm pretty much down for the count. > > Any other amd64 users out there tried rebuilding > their kernels in the past few hours? > > Andrew Lankford > Were you actually trying to load any modules from the loader, or was it just loading in the kernel? Also, have you tried running a 6-CURRENT system for comparison? Scott From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 01:36:58 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70D4316A4CE for ; Sat, 4 Sep 2004 01:36:58 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB81F43D2D for ; Sat, 4 Sep 2004 01:36:57 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i841Xxrn013904; Fri, 3 Sep 2004 19:34:00 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 03 Sep 2004 19:34:19 -0600 (MDT) Message-Id: <20040903.193419.101345623.imp@bsdimp.com> To: maksim.yevmenkin@savvis.net From: "M. Warner Losh" In-Reply-To: <4138BE8D.7000102@savvis.net> References: <4138BE8D.7000102@savvis.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: fine grained locking and traversing linked lists X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 01:36:58 -0000 In message: <4138BE8D.7000102@savvis.net> Maksim Yevmenkin writes: : recent Robert Watson's locking changes made me to revisit locking in : the bluetooth code. bluetooth code uses linked lists for various : objects. quite often it is required to locate a certain object in the : list. during this operation i have to hold list mutex and individual : object mutex. this is very inconvenient. : : so, i've written a "spherical cow" that shows fine grained locking : when traversing linked lists (see below). basically, for double linked : list, in order to safely manipulate by object "y" one must hold three : locks: object "y" lock, object "x = y->previous" lock and object "z = : y->next" lock. : : so, the $1 million question is: am i missing something? or this will work? : : note: in the "spherical cow" below linked list is replaced by array, : ->next and ->previous operation are replaced with +1 and -1 : respectively and -1 stands for NULL. I suspect that having a lock for the entire list would be more worthwhile. Especially since you'd have to acquire O(n) locks to safely traverse the list rather than O(1). Warner From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 01:51:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C844A16A4CE for ; Sat, 4 Sep 2004 01:51:15 +0000 (GMT) Received: from meitner.wh.uni-dortmund.de (meitner.wh.uni-dortmund.de [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55EC943D49 for ; Sat, 4 Sep 2004 01:51:15 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id E12201674E5 for ; Sat, 4 Sep 2004 03:51:13 +0200 (CEST) Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id i841p7kv075320 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 4 Sep 2004 03:51:12 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock To: freebsd-current@freebsd.org Date: Sat, 4 Sep 2004 03:51:02 +0200 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8549977.ArkiKayrd2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409040351.06438.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new Subject: Where did debug.acpi.disabled go? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 01:51:16 -0000 --nextPart8549977.ArkiKayrd2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I updated my 5.2-CURRENT to RELENG_5 today and the debug.acpi.disabled tuna= ble=20 seems to be gone. This is rather unfortunate for me, since I needed to set= =20 debug.acpi.disabled=3D"sysresource" so my floppy could be sucessfully probe= d. I already tried OPTIONS ACPI_debug (this breaks the acpi module and prevent= s=20 it from loading sucessfully) and compiling acpi into the kernel, no dice. =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart8549977.ArkiKayrd2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBOR+KXhc68WspdLARAjRbAJ9tAGe/gBG4fcrkx4TxyaSS09WapACbBz9y sGKQgJ0vLll1T3WYFKduKEQ= =A4RN -----END PGP SIGNATURE----- --nextPart8549977.ArkiKayrd2-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 01:54:25 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E88F316A4CE for ; Sat, 4 Sep 2004 01:54:24 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE77243D31 for ; Sat, 4 Sep 2004 01:54:24 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i841tDc8000452; Fri, 3 Sep 2004 18:55:13 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i841tDZV000451; Fri, 3 Sep 2004 18:55:13 -0700 Date: Fri, 3 Sep 2004 18:55:13 -0700 From: Brooks Davis To: Michael Nottebrock Message-ID: <20040904015513.GA32622@odin.ac.hmc.edu> References: <200409040351.06438.michaelnottebrock@gmx.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: <200409040351.06438.michaelnottebrock@gmx.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-current@freebsd.org Subject: Re: Where did debug.acpi.disabled go? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 01:54:25 -0000 --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 04, 2004 at 03:51:02AM +0200, Michael Nottebrock wrote: > I updated my 5.2-CURRENT to RELENG_5 today and the debug.acpi.disabled tu= nable=20 > seems to be gone. This is rather unfortunate for me, since I needed to se= t=20 > debug.acpi.disabled=3D"sysresource" so my floppy could be sucessfully pro= bed. >=20 > I already tried OPTIONS ACPI_debug (this breaks the acpi module and preve= nts=20 > it from loading sucessfully) and compiling acpi into the kernel, no dice. debug.acpi.disabled=3D"thermal" works with my current kernels. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBOSCBXY6L6fI4GtQRAlKMAKCa28tREvXvhtv0FfK1YTu0RxxOlACfWkCi yVOKb2FKZROIHWzjtiTsDi4= =r0l2 -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 01:55:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBBDD16A4CE for ; Sat, 4 Sep 2004 01:55:21 +0000 (GMT) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80CBE43D4C for ; Sat, 4 Sep 2004 01:55:21 +0000 (GMT) (envelope-from kientzle@freebsd.org) Received: from freebsd.org (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id i841tE90077249; Fri, 3 Sep 2004 18:55:14 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <41392082.3010204@freebsd.org> Date: Fri, 03 Sep 2004 18:55:14 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Will Froning References: <20040903165214.W8095@angui.sh> In-Reply-To: <20040903165214.W8095@angui.sh> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: bsdtar breakage on 5.3-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 01:55:21 -0000 Will Froning wrote: > On a FBSD4.10 box I have created a tar file of a users home directory > and then copied it over to a 5.3-BETA2 box (MD5 checksums match). > > I get at least this file inconsistancy: > > FBSD4.10 tar shows: > -rw------- 14643/202 456 Aug 22 15:54 2003 > tpayne/.gconf/apps/panel/profiles/default/objects/1t1061343718ut570825u15070p15903r8419k4290697116/%gconf.xml > > FBSD5.3-BETA2 tar shows: > drw------- 0 14643 202 456 Aug 22 2003 > tpayne/.gconf/apps/panel/profiles/default/objects/1t1061343718ut570825u15070p15903r8419k4290697116/%gconf.xml > > I have the tar available if anyone needs it (1.5MB). > > Thanks, > Will > Send it to me and I'll take a look. Tim From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 02:50:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3CD3816A4CF for ; Sat, 4 Sep 2004 02:50:12 +0000 (GMT) Received: from meitner.wh.uni-dortmund.de (meitner.wh.uni-dortmund.de [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id E18D943D31 for ; Sat, 4 Sep 2004 02:50:11 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id 03EDE1674E5; Sat, 4 Sep 2004 04:50:11 +0200 (CEST) Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id i842o2kv052775 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 4 Sep 2004 04:50:08 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock To: Brooks Davis Date: Sat, 4 Sep 2004 04:49:56 +0200 User-Agent: KMail/1.7 References: <200409040351.06438.michaelnottebrock@gmx.net> <20040904015513.GA32622@odin.ac.hmc.edu> In-Reply-To: <20040904015513.GA32622@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1636724.z8MgHF6AXe"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409040450.01028.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new cc: freebsd-current@freebsd.org Subject: Re: Where did debug.acpi.disabled go? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 02:50:12 -0000 --nextPart1636724.z8MgHF6AXe Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 04 September 2004 03:55, Brooks Davis wrote: > debug.acpi.disabled=3D"thermal" works with my current kernels. Where are you setting it? I don't even have the oid in sysctl -a output... =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart1636724.z8MgHF6AXe Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD0DBQBBOS1YXhc68WspdLARAqBsAIoDGsEh3X0QxFpv598EDwa7h5QAn3VTuuCZ h+2OJJp/gGQoLX46Aoxk =Ei8e -----END PGP SIGNATURE----- --nextPart1636724.z8MgHF6AXe-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 03:05:16 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBF1A16A4CE; Sat, 4 Sep 2004 03:05:16 +0000 (GMT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id CB07643D31; Sat, 4 Sep 2004 03:05:15 +0000 (GMT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 4 Sep 2004 04:05:15 +0100 (BST) To: Scott Long In-Reply-To: Your message of "Fri, 03 Sep 2004 18:49:01 MDT." <413910FD.2090905@samsco.org> Date: Sat, 04 Sep 2004 04:05:11 +0100 From: Ian Dowse Message-ID: <200409040405.aa89659@salmon.maths.tcd.ie> cc: amd64@freebsd.org cc: andrew.lankford@verizon.net cc: current@freebsd.org Subject: Re: Latest MFCs break boot on amd64 notebook. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 03:05:17 -0000 In message <413910FD.2090905@samsco.org>, Scott Long writes: >Andrew Lankford wrote: >> The latest MFCs (the eagerly awaited boot-time module >> loading functionality on amd64) compiled ok, but my >> machine freezes and then powers down shortly after >> "boot" from the loader. I would try to give you all >> more details, but my old working kernel seems to be >> lost, and so I'm pretty much down for the count. >> >> Any other amd64 users out there tried rebuilding >> their kernels in the past few hours? >> >> Andrew Lankford >> > >Were you actually trying to load any modules from the loader, >or was it just loading in the kernel? Also, have you tried >running a 6-CURRENT system for comparison? Any further information you can provide would be appreciated. For example, do any kernel messages appear before the freeze? What does "lsmod" from the loader output, and I presume you've tried booting kernel.old ("unload", "load /boot/kernel.old/kernel", "boot")? You could also try booting with the old loader by interrupting the boot process by pressing a key immediately after the first of the |/-\ sequence appears. You should get a prompt like: >> FreeBSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot: Enter 0:ad(0,a)/boot/loader.old and see if that allows you to boot. Ian From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 03:09:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7533916A4D0 for ; Sat, 4 Sep 2004 03:09:59 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0FB143D5D for ; Sat, 4 Sep 2004 03:09:58 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i8437F0B014508; Fri, 3 Sep 2004 21:07:15 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 03 Sep 2004 21:07:34 -0600 (MDT) Message-Id: <20040903.210734.89664548.imp@bsdimp.com> To: thasegawa@mta.biglobe.ne.jp From: "M. Warner Losh" In-Reply-To: <20040904.094334.74753938.thasegawa@mta.biglobe.ne.jp> References: <20040904.094334.74753938.thasegawa@mta.biglobe.ne.jp> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: pccard fixed disk not work on 5.3-BETA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 03:09:59 -0000 do other, non ata pccards work? Warner From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 03:21:33 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8610816A4CE; Sat, 4 Sep 2004 03:21:33 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E5DB43D1D; Sat, 4 Sep 2004 03:21:33 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id i843LWlu023081; Fri, 3 Sep 2004 23:21:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i843LW4G047308; Fri, 3 Sep 2004 23:21:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7AD2E7303F; Fri, 3 Sep 2004 23:21:32 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040904032132.7AD2E7303F@freebsd-current.sentex.ca> Date: Fri, 3 Sep 2004 23:21:32 -0400 (EDT) Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2004 03:21:33 -0000 TB --- 2004-09-04 01:40:28 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-04 01:40:28 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2004-09-04 01:40:28 - checking out the source tree TB --- 2004-09-04 01:40:28 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2004-09-04 01:40:28 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-04 01:45:39 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-04 01:45:39 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-09-04 01:45:39 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-09-04 02:50:34 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-04 02:50:34 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-09-04 02:50:34 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Sep 4 02:50:34 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sat Sep 4 03:04:56 UTC 2004 TB --- 2004-09-04 03:04:56 - generating LINT kernel config TB --- 2004-09-04 03:04:56 - cd /home/tinderbox/CURRENT/amd64/amd64/src/sys/amd64/conf TB --- 2004-09-04 03:04:56 - /usr/bin/make -B LINT TB --- 2004-09-04 03:04:56 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-04 03:04:56 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2004-09-04 03:04:56 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Sep 4 03:04:56 UTC 2004 >>> 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 [...] /tinderbox/CURRENT/amd64/amd64/src/sys/modules/re/../../dev/re/if_re.c:1970: warning: 're_start_locked' defined but not used /tinderbox/CURRENT/amd64/amd64/src/sys/modules/re/../../dev/re/if_re.c:2218: warning: 're_ifmedia_upd' defined but not used /tinderbox/CURRENT/amd64/amd64/src/sys/modules/re/../../dev/re/if_re.c:2236: warning: 're_ifmedia_sts' defined but not used /tinderbox/CURRENT/amd64/amd64/src/sys/modules/re/../../dev/re/if_re.c:2253: warning: 're_ioctl' defined but not used /tinderbox/CURRENT/amd64/amd64/src/sys/modules/re/../../dev/re/if_re.c:2308: warning: 're_watchdog' defined but not used /tinderbox/CURRENT/amd64/amd64/src/sys/modules/re/../../dev/re/if_re.c:2384: warning: 're_suspend' defined but not used /tinderbox/CURRENT/amd64/amd64/src/sys/modules/re/../../dev/re/if_re.c:2405: warning: 're_resume' defined but not used /tinderbox/CURRENT/amd64/amd64/src/sys/modules/re/../../dev/re/if_re.c:2432: warning: 're_shutdown' defined but not used *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/sys/modules/re. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2004-09-04 03:21:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-04 03:21:32 - ERROR: failed to build lint kernel TB --- 2004-09-04 03:21:32 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 03:32:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8468716A4CE; Sat, 4 Sep 2004 03:32:08 +0000 (GMT) Received: from ganymede.hub.org (blk-222-46-91.eastlink.ca [24.222.46.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12D5B43D41; Sat, 4 Sep 2004 03:32:08 +0000 (GMT) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id 4B1C13A673; Sat, 4 Sep 2004 00:32:07 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 4A2A93A66E; Sat, 4 Sep 2004 00:32:07 -0300 (ADT) Date: Sat, 4 Sep 2004 00:32:07 -0300 (ADT) From: "Marc G. Fournier" To: Don Lewis In-Reply-To: <200409032252.i83MqBJl030297@gw.catspoiler.org> Message-ID: <20040904003116.J812@ganymede.hub.org> References: <200409032252.i83MqBJl030297@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@freebsd.org cc: keramida@linux.gr Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 03:32:08 -0000 Long shot here, but is this a change that could be MFC'd to 4.x? Or has fsck changed so much since that it could only be done in 5.x? I just finished another 12hr fsck run *sigh* On Fri, 3 Sep 2004, Don Lewis wrote: > On 4 Sep, Giorgos Keramidas wrote: >> On 2004-09-03 14:58, Don Lewis wrote: > >>> Using two CPUs would give you at best a 2x speedup, and in this case it >>> would be quite a bit less since both CPUs would be trying to access and >>> modify the same data structure. Just using a better data structure is >>> likely to speed things up much more than 2x. Something as simple as >>> building the list in reverse order in pass 1 is likely to make a huge >>> difference. >> >> Holding both a head and tail pointer to the singly-linked list should >> probably make it easier to add nodes at the end of the list instead of >> the head. I haven't read the source of fsck_ffs at all though, so I >> don't know if I can come up with a working patch in a reasonable amount >> of time. > > Yes, if fsck used the macros, this data structure should > probably be a STAILQ. The code if fsck is all hand rolled and it would > be trivially easy to add a tail pointer. The head of the list in > question is > struct zlncnt *zlnhead; > The only modifications needed would be in the initialization code in > main.c, and the code that builds the list in pass1.c. > > > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 03:33:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2501816A4CE; Sat, 4 Sep 2004 03:33:37 +0000 (GMT) Received: from ganymede.hub.org (blk-222-46-91.eastlink.ca [24.222.46.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id B474143D49; Sat, 4 Sep 2004 03:33:27 +0000 (GMT) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id 432E9399D2; Sat, 4 Sep 2004 00:33:27 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 4254C399C4; Sat, 4 Sep 2004 00:33:27 -0300 (ADT) Date: Sat, 4 Sep 2004 00:33:27 -0300 (ADT) From: "Marc G. Fournier" To: Don Lewis In-Reply-To: <200409032158.i83LwdWg030214@gw.catspoiler.org> Message-ID: <20040904003222.J812@ganymede.hub.org> References: <200409032158.i83LwdWg030214@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@freebsd.org Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 03:33:37 -0000 On Fri, 3 Sep 2004, Don Lewis wrote: > On 3 Sep, Marc G. Fournier wrote: >> >> I'm running another fsck on a 4.x system ... I know 5.x brings in the >> background mode for it, which would definitely make my life easier, *but* >> ... when running fsck, it says its using up 99% of the CPU: >> >> # ps aux | grep fsck >> root 67 99.0 5.0 184252 184284 p0 R+ 12:46PM 254:16.68 fsck -y /vm >> >> now, its a dual CPU system ... on an MP system, is it not possible to have >> it parallelize on a file system, so that it makes use of all available >> CPU? >> >> For instance, right now, its in Phase 4 ... on a file system where ctl-t >> shows: >> >> load: 0.99 cmd: fsck 67 [running] 15192.26u 142.30s 99% 184284k >> /dev/da0s1h: phase 4: cyl group 408 of 866 (47%) >> >> wouldn't it be possible, on a dual CPU system, to have group 434 and above >> run on one process, while group 433 and below running on the second, in >> parallel? Its not like the drives are being beat up: > > Would the file system in question happen to be full of UNREF files that > fsck is deleting? mostly 'ZERO LENGTH DIRECTORY' ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 03:40:50 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D7E716A4CE for ; Sat, 4 Sep 2004 03:40:50 +0000 (GMT) Received: from ganymede.hub.org (blk-222-46-91.eastlink.ca [24.222.46.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27D9D43D31 for ; Sat, 4 Sep 2004 03:40:50 +0000 (GMT) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id AF26F3AD81; Sat, 4 Sep 2004 00:40:49 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id ADDD03AA99; Sat, 4 Sep 2004 00:40:49 -0300 (ADT) Date: Sat, 4 Sep 2004 00:40:49 -0300 (ADT) From: "Marc G. Fournier" To: Chris Laverdure In-Reply-To: <1094232909.76688.1.camel@elemental.DashEvil> Message-ID: <20040904003919.X812@ganymede.hub.org> References: <20040903175434.A812@ganymede.hub.org> <20040903211427.GB1199@gothmog.gr> <1094232909.76688.1.camel@elemental.DashEvil> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@freebsd.org cc: Giorgos Keramidas Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 03:40:50 -0000 On Fri, 3 Sep 2004, Chris Laverdure wrote: > On Fri, 2004-09-03 at 21:14, Giorgos Keramidas wrote: >> On 2004-09-03 18:01, "Marc G. Fournier" wrote: >>> >>> load: 0.99 cmd: fsck 67 [running] 15192.26u 142.30s 99% 184284k >>> /dev/da0s1h: phase 4: cyl group 408 of 866 (47%) >>> >>> wouldn't it be possible, on a dual CPU system, to have group 434 and above >>> run on one process, while group 433 and below running on the second, in >>> parallel? Its not like the drives are being beat up: >> >> My intuition says that if metadata of the first part of the disk references >> data residing on the second part synchronization and locking would probably >> be a bit difficult; actually very difficult. > > My intuition tells me that it would be a much better solution to run > multiple fsck's concurrently. What harm could there be in fscking (num > of processors) partitions at the same time? I already do that ... the problem file system is the 100+GB one that just took 12hrs to run through on a machine that was 50% idle for the whole time :( I'm looking forward to moving to 5.x because of the bkgd fsck, *but* ... if it takes 12hrs as a foreground process when it can suck all the CPU it wants, how long is it goin to take on a live server where its sharing with several hundred other processes? :( ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 03:42:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7874D16A4CE for ; Sat, 4 Sep 2004 03:42:21 +0000 (GMT) Received: from ganymede.hub.org (blk-222-46-91.eastlink.ca [24.222.46.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4492043D46 for ; Sat, 4 Sep 2004 03:42:21 +0000 (GMT) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id D72003A9BC; Sat, 4 Sep 2004 00:42:17 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id D5F3C3A9B5; Sat, 4 Sep 2004 00:42:17 -0300 (ADT) Date: Sat, 4 Sep 2004 00:42:17 -0300 (ADT) From: "Marc G. Fournier" To: Giorgos Keramidas In-Reply-To: <20040903215054.GD1199@gothmog.gr> Message-ID: <20040904004104.C812@ganymede.hub.org> References: <20040903175434.A812@ganymede.hub.org> <20040903211427.GB1199@gothmog.gr><20040903215054.GD1199@gothmog.gr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Chris Laverdure cc: freebsd-current@freebsd.org Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 03:42:21 -0000 On Sat, 4 Sep 2004, Giorgos Keramidas wrote: > On 2004-09-03 17:35, Chris Laverdure wrote: >> On Fri, 2004-09-03 at 21:14, Giorgos Keramidas wrote: >>> (Regarding "parallelization" of fsck by spawning many instances of >>> fsck for parts of the same partition...) >>> >>> My intuition says that if metadata of the first part of the disk references >>> data residing on the second part synchronization and locking would probably >>> be a bit difficult; actually very difficult. >> >> My intuition tells me that it would be a much better solution to run >> multiple fsck's concurrently. What harm could there be in fscking (num >> of processors) partitions at the same time? > > AFAIK, this is exactly what "background fsck" does in 5.X :-) fsck -p in 4.x does this also .. but, when there is only one large file system, and 4 or 5 smaller ones, those 4 or 5 smaller ones don't take long t do ... in my case, that one large one just took 12hrs to complete, on a system where that one fsck was the only thing running :( I don't believe that moving to 5.x's bkgd fsck will speed that up any, and, in fact, would probably slow it down since it will be completing with other processes ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 03:49:06 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF8AA16A4CE; Sat, 4 Sep 2004 03:49:06 +0000 (GMT) Received: from ganymede.hub.org (blk-222-46-91.eastlink.ca [24.222.46.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AA2443D2D; Sat, 4 Sep 2004 03:49:06 +0000 (GMT) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id 9F5A83AF92; Sat, 4 Sep 2004 00:49:05 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 998F93AF8C; Sat, 4 Sep 2004 00:49:05 -0300 (ADT) Date: Sat, 4 Sep 2004 00:49:05 -0300 (ADT) From: "Marc G. Fournier" To: Allan Fields In-Reply-To: <20040901224632.O72978@ganymede.hub.org> Message-ID: <20040904004706.O812@ganymede.hub.org> References: <20040901151405.G47186@ganymede.hub.org> <20040901200257.GA92717@afields.ca><41365746.2030605@samsco.org> <20040902013534.GD9327@afields.ca> <20040901224632.O72978@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@freebsd.org cc: freebsd-stable@freebsd.org Subject: Re: vnode leak in FFS code ... ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 03:49:07 -0000 Just as a followup to this ... the server crashed on Thursday night around 22:00ADT, only just came back up after a very long fsck ... with all 62 VMs started up, and 1008 processes running, vnodes currently look like: Sep 4 00:43:00 venus root: debug.numvnodes: 58370 - debug.freevnodes: 824 - debug.vnlru_nowhere: 0 - vlruwt Sep 4 00:44:00 venus root: debug.numvnodes: 58370 - debug.freevnodes: 782 - debug.vnlru_nowhere: 0 - vlruwt Sep 4 00:45:01 venus root: debug.numvnodes: 58370 - debug.freevnodes: 977 - debug.vnlru_nowhere: 0 - vlruwt Sep 4 00:46:00 venus root: debug.numvnodes: 58370 - debug.freevnodes: 582 - debug.vnlru_nowhere: 0 - vlruwt venus# ps aux | wc -l 1008 venus# about a tenth of what they were when the server crashed :( On Wed, 1 Sep 2004, Marc G. Fournier wrote: > On Wed, 1 Sep 2004, Allan Fields wrote: > >>> It's really hard to tell if there is a vnode leak here. The vnode pool >>> is fairly fluid and has nothing to do with the number of files that are >>> actually 'open'. Vnodes get created when the VFS layer wants to access >>> an object that isn't already in the cache, and only get destroyed when >>> the object is destroyed. A vnode that reprents a file that was opened >>> will stay 'active' in the system long after the file has been closed, >>> because it's cheaper to keep it active in the cache than it is to >>> discard it and then risk having to go through the pain of a namei() >>> and VOP_LOOKUP() again later. Only if the maxvnode limit is hit will >>> old vnodes start getting recycled to represent other objects. [...] >>> >>> So you've obviously bumped up kern.maxvnodes well above the limits that >>> are normally generated from the auto-tuner. Why did you do that, if not >>> because you knew that you'd have a large working set of referenced (but >>> maybe not open all at once) filesystem objects? [...] >> >> There was a pevious thread I've found which also helps explains >> this further: >> http://lists.freebsd.org/pipermail/freebsd-stable/2003-May/001266.html >> >> Really the same issue now as then? > > I'm not getting the hangs now, it is freeing up vnodes ... but its having to > work very hard to do so, or so it seems: > > venus# ps aux | grep vnlru > root 7 3.0 0.0 0 0 ?? DL 5Aug04 606:34.54 (vnlru) > > I started up the script for monitoring this on Aug 29th ... since then, there > have been 4331 entries to the log file, of which 1927 are in 'vlrup', which > I believe is vnlru running through its lists trying to find some to free up, > if I recall the code ... ? > > venus# grep vnode /var/log/syswatch | wc -l > 4331 > venus# grep vnode /var/log/syswatch | grep vlrup | wc -l > 1927 > > and this is based on a check every minute ... > > The other server, running ~19 more VMs (~100 more processes), only up 2 days > now, seems to be fairing better: > > debug.numvnodes: 344062 - debug.freevnodes: 168285 - debug.vnlru_nowhere: 0 - > vlruwt > > I've schedualed 'maintenance' on that server for Saturday ... am going to > shut down all 'non-host server' processes, and unmount the large file system > (where all the VMs run off of) ... see if that cleans up any of the vnodes > without having to do a reboot ... > > If that doesn't work, I could cause a panic and have it dump core, if that > would provide for easier/better debugging ... ? > > I have limited flexibility with the server, but it is a 'real' server without > a fake load on it, and as solid as I've always considered FreeBSD to be, I > seem to have a knack for pushing it and breaking it :( ... so whatever data I > can provide to make it that much more solid, even if it involves a little bit > of downtime to get a good core dump, I'm willing to do ... > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > _______________________________________________ > 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" > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 04:08:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D869916A4CE for ; Sat, 4 Sep 2004 04:08:38 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FB0E43D48 for ; Sat, 4 Sep 2004 04:08:38 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id i8449TSA011876; Fri, 3 Sep 2004 21:09:29 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id i8449SGF011875; Fri, 3 Sep 2004 21:09:28 -0700 Date: Fri, 3 Sep 2004 21:09:28 -0700 From: Brooks Davis To: Michael Nottebrock Message-ID: <20040904040928.GA11829@odin.ac.hmc.edu> References: <200409040351.06438.michaelnottebrock@gmx.net> <20040904015513.GA32622@odin.ac.hmc.edu> <200409040450.01028.michaelnottebrock@gmx.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <200409040450.01028.michaelnottebrock@gmx.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-current@freebsd.org Subject: Re: Where did debug.acpi.disabled go? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 04:08:39 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 04, 2004 at 04:49:56AM +0200, Michael Nottebrock wrote: > On Saturday 04 September 2004 03:55, Brooks Davis wrote: >=20 > > debug.acpi.disabled=3D"thermal" works with my current kernels. >=20 > Where are you setting it? I don't even have the oid in sysctl -a output... /boot/loader.conf. It's tunable, not a sysctl. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFBOT/4XY6L6fI4GtQRAvlfAKCIatEEv1fu4kmxzy0YYmf+haWkaQCggRmN 12VPloUPwuMYqoliytZrtEs= =wyxd -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 04:42:11 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60E7916A4CE for ; Sat, 4 Sep 2004 04:42:11 +0000 (GMT) Received: from meitner.wh.uni-dortmund.de (meitner.wh.uni-dortmund.de [129.217.129.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5603243D53 for ; Sat, 4 Sep 2004 04:42:10 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: from lofi.dyndns.org (pc2-105.intern.meitner [10.3.12.105]) by meitner.wh.uni-dortmund.de (Postfix) with ESMTP id 496BF1674E5; Sat, 4 Sep 2004 06:42:09 +0200 (CEST) Received: from kiste.my.domain (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id i844fx4Y088137 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 4 Sep 2004 06:42:03 +0200 (CEST) (envelope-from michaelnottebrock@gmx.net) From: Michael Nottebrock To: Brooks Davis Date: Sat, 4 Sep 2004 06:41:52 +0200 User-Agent: KMail/1.7 References: <200409040351.06438.michaelnottebrock@gmx.net> <200409040450.01028.michaelnottebrock@gmx.net> <20040904040928.GA11829@odin.ac.hmc.edu> In-Reply-To: <20040904040928.GA11829@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7600256.7Gu35sBZXW"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200409040641.58361.michaelnottebrock@gmx.net> X-Virus-Scanned: by amavisd-new cc: freebsd-current@freebsd.org Subject: Re: Where did debug.acpi.disabled go? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 04:42:11 -0000 --nextPart7600256.7Gu35sBZXW Content-Type: multipart/mixed; boundary="Boundary-01=_ReUOBcRcobwIoYZ" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_ReUOBcRcobwIoYZ Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 04 September 2004 06:09, Brooks Davis wrote: > On Sat, Sep 04, 2004 at 04:49:56AM +0200, Michael Nottebrock wrote: > > On Saturday 04 September 2004 03:55, Brooks Davis wrote: > > > debug.acpi.disabled=3D"thermal" works with my current kernels. > > > > Where are you setting it? I don't even have the oid in sysctl -a > > output... > > /boot/loader.conf. It's tunable, not a sysctl. Right. I keep thinking those were translated to readonly sysctls for some=20 reason (probably because it would be nice ;-)). Anyway, it turns out that debug.acpi.disabled=3D"sysresource" DOES work, it= just=20 doesn't make my floppy to probe and attach correctly anymore. I've attached devinfo -r output for acpi disabled, acpi with sysresource=20 disabled and full acpi, hopefully somebody can tell what's going wrong. The= =20 error I get from the fdc device probe (it is actually probed twice with acp= i=20 enabled, with the same error both times) is: fdc0: port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3 irq 6 dr= q 2=20 on acpi0 fdc0: cmd 3 failed at out byte 1 of 3 device_attach: fdc0 attach returned 6 =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --Boundary-01=_ReUOBcRcobwIoYZ Content-Type: text/plain; charset="iso-8859-15"; name="devinfo_r_acpi.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="devinfo_r_acpi.txt" nexus0 npx0 acpi0 Interrupt request lines: 0x9 I/O ports: 0x10-0x1f 0x22-0x3f 0x44-0x5f 0x62-0x63 0x65-0x6f 0x72-0x7f 0x80 0x84-0x86 0x88 0x8c-0x8e 0x90-0x9f 0xa2-0xbf 0xe0-0xef 0x290-0x297 0x3f0-0x3f1 0x400-0x43f 0x4d0-0x4d1 0x800-0x87f 0xc00-0xc0f I/O memory addresses: 0xfee00000-0xfee00fff 0xffb00000-0xffbfffff cpu0 I/O ports: 0x810-0x813 acpi_button0 pcib0 pci0 agp0 I/O memory addresses: 0xe0000000-0xe1ffffff pcib1 pci1 pcib2 pci3 bktr0 Interrupt request lines: 0x10 I/O memory addresses: 0xdfbfe000-0xdfbfefff rl0 Interrupt request lines: 0x11 I/O ports: 0xc800-0xc8ff I/O memory addresses: 0xdfeffe00-0xdfeffeff miibus0 rlphy0 uhci0 Interrupt request lines: 0x16 I/O ports: 0xc000-0xc01f usb0 uhub0 ums0 uhci1 Interrupt request lines: 0x17 I/O ports: 0xc400-0xc41f usb1 uhub1 ehci0 Interrupt request lines: 0x14 I/O memory addresses: 0xdfeffd00-0xdfeffdff usb2 uhub2 isab0 isa0 sc0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff orm0 I/O memory addresses: 0xc0000-0xccfff pmtimer0 atapci0 I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0xfc00-0xfc0f ata0 Interrupt request lines: 0xe ata1 Interrupt request lines: 0xf uhci2 Interrupt request lines: 0x13 I/O ports: 0xe400-0xe41f usb3 uhub3 uscanner0 pcm0 I/O ports: 0xe800-0xe83f 0xec00-0xecff acpi_sysresource0 atpic0 atdma0 attimer0 attimer1 npxisa0 psmcpnp0 Interrupt request lines: 0xc atkbdc0 I/O ports: 0x60 0x64 atkbd0 Interrupt request lines: 0x1 psm0 sio0 Interrupt request lines: 0x4 I/O ports: 0x3f8-0x3ff ppc0 Interrupt request lines: 0x7 I/O ports: 0x378-0x37f ppbus0 plip0 lpt0 ppi0 vpo0 acpi_timer0 I/O ports: 0x808-0x80b --Boundary-01=_ReUOBcRcobwIoYZ Content-Type: text/plain; charset="iso-8859-15"; name="devinfo_r_acpi-no-sysresource.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="devinfo_r_acpi-no-sysresource.txt" nexus0 npx0 acpi0 Interrupt request lines: 0x9 cpu0 I/O ports: 0x810-0x813 acpi_button0 pcib0 pci0 agp0 I/O memory addresses: 0xe0000000-0xe1ffffff pcib1 pci1 pcib2 pci3 bktr0 Interrupt request lines: 0x10 I/O memory addresses: 0xdfbfe000-0xdfbfefff rl0 Interrupt request lines: 0x11 I/O ports: 0xc800-0xc8ff I/O memory addresses: 0xdfeffe00-0xdfeffeff miibus0 rlphy0 uhci0 Interrupt request lines: 0x16 I/O ports: 0xc000-0xc01f usb0 uhub0 ums0 uhci1 Interrupt request lines: 0x17 I/O ports: 0xc400-0xc41f usb1 uhub1 ehci0 Interrupt request lines: 0x14 I/O memory addresses: 0xdfeffd00-0xdfeffdff usb2 uhub2 isab0 isa0 sc0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff orm0 I/O memory addresses: 0xc0000-0xccfff pmtimer0 atapci0 I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0xfc00-0xfc0f ata0 Interrupt request lines: 0xe ata1 Interrupt request lines: 0xf uhci2 Interrupt request lines: 0x13 I/O ports: 0xe400-0xe41f usb3 uhub3 uscanner0 pcm0 I/O ports: 0xe800-0xe83f 0xec00-0xecff atpic0 atdma0 attimer0 attimer1 npxisa0 psmcpnp0 Interrupt request lines: 0xc atkbdc0 I/O ports: 0x60 0x64 atkbd0 Interrupt request lines: 0x1 psm0 sio0 Interrupt request lines: 0x4 I/O ports: 0x3f8-0x3ff ppc0 Interrupt request lines: 0x7 I/O ports: 0x378-0x37f ppbus0 plip0 lpt0 ppi0 vpo0 acpi_timer0 I/O ports: 0x808-0x80b --Boundary-01=_ReUOBcRcobwIoYZ Content-Type: text/plain; charset="iso-8859-15"; name="devinfo_r_noacpi.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="devinfo_r_noacpi.txt" nexus0 legacy0 pcib0 pci0 agp0 I/O memory addresses: 0xe0000000-0xe1ffffff pcib1 pci1 pcib2 pci3 bktr0 Interrupt request lines: 0xb I/O memory addresses: 0xdfbfe000-0xdfbfefff rl0 Interrupt request lines: 0xa I/O ports: 0xc800-0xc8ff I/O memory addresses: 0xdfeffe00-0xdfeffeff miibus0 rlphy0 uhci0 I/O ports: 0xc000-0xc01f usb0 uhub0 uhci1 I/O ports: 0xc400-0xc41f usb1 uhub1 ehci0 Interrupt request lines: 0x5 I/O memory addresses: 0xdfeffd00-0xdfeffdff usb2 uhub2 isab0 isa0 atkbdc0 I/O ports: 0x60 0x64 atkbd0 Interrupt request lines: 0x1 psm0 Interrupt request lines: 0xc fdc0 Interrupt request lines: 0x6 DMA request lines: 2 I/O ports: 0x3f0-0x3f5 0x3f7 fd0 ppc0 Interrupt request lines: 0x7 I/O ports: 0x378-0x37f ppbus0 plip0 lpt0 ppi0 vpo0 sc0 sio0 Interrupt request lines: 0x4 I/O ports: 0x3f8-0x3ff vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff orm0 I/O memory addresses: 0xc0000-0xccfff pcibus_pnp0 I/O ports: 0x22 0x2e 0x2f 0x72-0x75 0x290-0x297 0x400-0x43f 0x4d0-0x4d1 0x800-0x87f 0xc00-0xc0f 0xcf8-0xcff sysresource0 I/O memory addresses: 0x0-0x9fbff 0x9fc00-0x9ffff 0xf0000-0xfffff 0x100000-0x3ffeffff 0x3fff0000-0x3fff7fff 0x3fff8000-0x3fffffff 0xfec00000-0xfec00fff 0xfee00000-0xfee00fff 0xffb00000-0xffbfffff 0xfff00000-0xffffffff atdma0 DMA request lines: 4 I/O ports: 0x0-0xf 0x80-0x90 0x94-0x9f 0xc0-0xde attimer0 Interrupt request lines: 0x0 I/O ports: 0x40-0x43 attimer1 Interrupt request lines: 0x8 I/O ports: 0x70-0x71 npxisa0 Interrupt request lines: 0xd I/O ports: 0xf0-0xff pmtimer0 atapci0 I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0xfc00-0xfc0f ata0 Interrupt request lines: 0xe ata1 Interrupt request lines: 0xf uhci2 I/O ports: 0xe400-0xe41f usb3 uhub3 uscanner0 pcm0 I/O ports: 0xe800-0xe83f 0xec00-0xecff pir0 cpu0 npx0 --Boundary-01=_ReUOBcRcobwIoYZ-- --nextPart7600256.7Gu35sBZXW Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQBBOUeWXhc68WspdLARAvgdAKCXs+23NHiS7Bw+tCXXwzRt3GuVYgCdHE7n EKfsmENsYbGIM4vEFLnr1VU= =tLFe -----END PGP SIGNATURE----- --nextPart7600256.7Gu35sBZXW-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 04:57:31 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D72CF16A4CE for ; Sat, 4 Sep 2004 04:57:31 +0000 (GMT) Received: from creme-brulee.marcuscom.com (rrcs-midsouth-24-172-16-118.biz.rr.com [24.172.16.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 604DC43D46 for ; Sat, 4 Sep 2004 04:57:31 +0000 (GMT) (envelope-from marcus@marcuscom.com) Received: from [192.168.1.4] (shumai.marcuscom.com [192.168.1.4]) i844svYj058789 for ; Sat, 4 Sep 2004 00:54:57 -0400 (EDT) (envelope-from marcus@marcuscom.com) From: Joe Marcus Clarke To: current@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-0FvFg+w190Eiuuw8xz09" Organization: MarcusCom, Inc. Message-Id: <1094273843.92485.11.camel@shumai.marcuscom.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sat, 04 Sep 2004 00:57:24 -0400 X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on creme-brulee.marcuscom.com Subject: Kernel panic in 6.0 revisited X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 04:57:32 -0000 --=-0FvFg+w190Eiuuw8xz09 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A few days ago, I reported a kernel panic in HEAD while building packages on my tinderbox machine. I was unable to get a core dump fro that crash, and after switching from ULE to 4BSD, I had thought it had gone away. Well, today, the machine panicked twice. It was the same panic both times, and the same panic I got a few days ago. This time, however, I was able to get a core dump. Here is the panic message: Fatal trap 12: page fault while in kernel mode cpuid =3D 0; apic id =3D 00 fault virtual address =3D 0x1c fault code =3D supervisor write, page not present instruction pointer =3D 0x8:0xc0533d07 stack pointer =3D 0x10:0xf5f30a4c frame pointer =3D 0x10:0xf5f30a58 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 27441 (cpp0) Stopped at vfs_vmio_release+0x1b: lock cmpxchgl %ecx,0x1c(%edx) Here is the full backtrace: #0 doadump () at pcpu.h:159 No locals. #1 0xc044790a in db_fncall (dummy1=3D0, dummy2=3D0, dummy3=3D-1067408529, = dummy4=3D0xf3832640 "l&\203=F3=D4\205`=C0X&\203=F3\\&\203=F3\220\a") at /us= r/src/sys/ddb/db_command.c:531 fn_addr =3D -1068568116 args =3D {0 } nargs =3D 11 retval =3D 0 func =3D (fcn_10args_t *) 0xc04ef1cc t =3D 0 #2 0xc0447718 in db_command (last_cmdp=3D0xc06aa344, cmd_table=3D0x0, aux_= cmd_tablep=3D0xc0678980, aux_cmd_tablep_end=3D0xc0678984) at /usr/src/sys/d= db/db_command.c:349 cmd =3D (struct command *) 0xc067e7c0 t =3D 0 modif =3D "l&\203=F3=D4\205`=C0X&\203=F3\\&\203=F3\220\a\000\000\22= 0\a\000\000=CF\a\000\000\000\000\000\000\000|m=C0\r\000\000\000\000|m=C0\00= 0|m=C0\r\000\000\000\001\000\000\000\230&\203=F3\a\177`=C0\230&\203=F3 \177= `=C0 Ol=C0=E0=B4k=C0x\000\000\000@=ACj=C0\f\000\000\000=B8&\203=F3|\226D=C0= _\035f=C0=EC\223D=C0\f\000\000\000@=ACj=C0\236\213D=C0" addr =3D 0 count =3D -1067408529 have_addr =3D 0 result =3D 0 #3 0xc04477e0 in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 No locals. #4 0xc0449359 in db_trap (type=3D12, code=3D0) at /usr/src/sys/ddb/db_main= .c:221 jb =3D {{_jb =3D {-209508616, -209508636, -209508564, -209508396, 1= 2, -1069247758, 12, -209508540, -1068464337, -1066976222, -1068464204, -209= 508560}}} prev_jb =3D (void *) 0x0 bkpt =3D 0 #5 0xc0506cb7 in kdb_trap (type=3D12, code=3D0, tf=3D0x1) at /usr/src/sys/= kern/subr_kdb.c:418 did_stop_cpus =3D 1 handled =3D -209508396 #6 0xc06239c1 in trap_fatal (frame=3D0xf38327d4, eva=3D28) at /usr/src/sys= /i386/i386/trap.c:804 code =3D 16 type =3D 12 ss =3D 16 esp =3D 0 softseg =3D {ssd_base =3D 0, ssd_limit =3D 1048575, ssd_type =3D 27= , ssd_dpl =3D 0, ssd_p =3D 1, ssd_xx =3D 3, ssd_xx1 =3D 3, ssd_def32 =3D 1,= ssd_gran =3D 1} #7 0xc062371f in trap_pfault (frame=3D0xf38327d4, usermode=3D0, eva=3D28) = at /usr/src/sys/i386/i386/trap.c:727 va =3D 0 vm =3D (struct vmspace *) 0x0 map =3D 0xc308a4b0 rv =3D 1 ftype =3D 1 '\001' td =3D (struct thread *) 0xc3184420 p =3D (struct proc *) 0xc35bb380 #8 0xc0623335 in trap (frame=3D{tf_fs =3D -1068629992, tf_es =3D -60162046= 4, tf_ds =3D 1048592, tf_edi =3D -601584980, tf_esi =3D -601584980, tf_ebp = =3D -209508320, tf_isp =3D -209508352, tf_ebx =3D -601584980, tf_edx =3D 0,= tf_ecx =3D -1021819872, tf_eax =3D 4, tf_trapno =3D 12, tf_err =3D 2, tf_e= ip =3D -1068290701, tf_cs =3D 8, tf_eflags =3D 66050, tf_esp =3D -601584980= , tf_ss =3D -601584980}) at /usr/src/sys/i386/i386/trap.c:417 td =3D (struct thread *) 0xc3184420 p =3D (struct proc *) 0xc35bb380 sticks =3D 3227240939 i =3D 0 ucode =3D 0 type =3D 12 code =3D 2 eva =3D 28 #9 0xc0611c2a in calltrap () at /usr/src/sys/i386/i386/exception.s:140 No locals. #10 0xc04e0018 in ktrnamei (path=3D0xdc248aac "\002") at /usr/src/sys/kern/= kern_ktrace.c:372 req =3D (struct ktr_request *) 0x0 namelen =3D -601584980 buf =3D 0xdc248aac "\002" #11 0xc05335d2 in getnewbuf (slpflag=3D0, slptimeo=3D0, size=3D2048, maxsiz= e=3D16384) at /usr/src/sys/kern/vfs_bio.c:1886 qindex =3D 1 bp =3D (struct buf *) 0xdc248aac nbp =3D (struct buf *) 0xdc248aac defrag =3D 0 nqindex =3D 524306 flushingbufs =3D 0 #12 0xc0534a59 in getblk (vp=3D0xc6f20108, blkno=3D0, size=3D2048, slpflag= =3D0, slptimeo=3D0, flags=3D0) at /usr/src/sys/kern/vfs_bio.c:2586 bsize =3D 16384 maxsize =3D 0 vmio =3D 1 offset =3D Unhandled dwarf expression opcode 0x93 And here is the output of "l *vfs_vmio_release+0x1b": 0xc0533d07 is in vfs_vmio_release (atomic.h:154). 149 static __inline int 150 atomic_cmpset_int(volatile u_int *dst, u_int exp, u_int src) 151 { 152 int res =3D exp; 153 154 __asm __volatile ( 155 " " __XSTRING(MPLOCKED) " " 156 " cmpxchgl %1,%2 ; " 157 " setz %%al ; " 158 " movzbl %%al,%0 ; " Kernel config is at http://www.marcuscom.com/downloads/FUGU.kernel and the dmesg output is at http://www.marcuscom.com/downloads/FUGU.dmesg Let me know if you need anything else. Thanks. Joe --=20 PGP Key : http://www.marcuscom.com/pgp.asc --=-0FvFg+w190Eiuuw8xz09 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBBOUszb2iPiv4Uz4cRAlR/AJ97jJx65y8iXRCFjNcS5W94V6AFFQCgpQ2X XfrUUEAbEwoaXZORKscj2VQ= =LHCN -----END PGP SIGNATURE----- --=-0FvFg+w190Eiuuw8xz09-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 05:05:19 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1638416A4CF for ; Sat, 4 Sep 2004 05:05:19 +0000 (GMT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9143943D4C for ; Sat, 4 Sep 2004 05:05:18 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-69-104-103-54.dsl.snfc21.pacbell.net [69.104.103.54])i8455FH9227500; Sat, 4 Sep 2004 01:05:16 -0400 Message-ID: <41394D0B.1050004@elischer.org> Date: Fri, 03 Sep 2004 22:05:15 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: "Marc G. Fournier" References: <20040901151405.G47186@ganymede.hub.org> <20040901200257.GA92717@afields.ca><41365746.2030605@samsco.org> <20040902013534.GD9327@afields.ca> <20040901224632.O72978@ganymede.hub.org> <20040904004706.O812@ganymede.hub.org> In-Reply-To: <20040904004706.O812@ganymede.hub.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: Allan Fields cc: freebsd-stable@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: vnode leak in FFS code ... ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 05:05:19 -0000 Marc G. Fournier wrote: > > Just as a followup to this ... the server crashed on Thursday night > around 22:00ADT, only just came back up after a very long fsck ... with > all 62 VMs started up, and 1008 processes running, vnodes currently look > like: are you using nullfs at all on your vms? > > Sep 4 00:43:00 venus root: debug.numvnodes: 58370 - debug.freevnodes: > 824 - debug.vnlru_nowhere: 0 - vlruwt > Sep 4 00:44:00 venus root: debug.numvnodes: 58370 - debug.freevnodes: > 782 - debug.vnlru_nowhere: 0 - vlruwt > Sep 4 00:45:01 venus root: debug.numvnodes: 58370 - debug.freevnodes: > 977 - debug.vnlru_nowhere: 0 - vlruwt > Sep 4 00:46:00 venus root: debug.numvnodes: 58370 - debug.freevnodes: > 582 - debug.vnlru_nowhere: 0 - vlruwt > venus# ps aux | wc -l > 1008 > venus# > > about a tenth of what they were when the server crashed :( > > From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 05:10:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8002916A4CE; Sat, 4 Sep 2004 05:10:52 +0000 (GMT) Received: from out011.verizon.net (out011pub.verizon.net [206.46.170.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id D6D4543D41; Sat, 4 Sep 2004 05:10:49 +0000 (GMT) (envelope-from andrew.lankford@verizon.net) Received: from outgoing.verizon.net ([192.168.1.1]) by out011.verizon.net ESMTP <20040904051049.DWQM14580.out011.verizon.net@outgoing.verizon.net>; Sat, 4 Sep 2004 00:10:49 -0500 X-Mailer: Openwave WebEngine, version 2.8.12 (webedge20-101-197-20030912) From: Andrew Lankford To: Ian Dowse , Scott Long Date: Sat, 4 Sep 2004 0:10:49 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=____1094274649262_6MZUzLAcuR" X-Authentication-Info: Submitted using SMTP AUTH at out011.verizon.net from [192.168.1.1] at Sat, 4 Sep 2004 00:10:49 -0500 Message-Id: <20040904051049.DWQM14580.out011.verizon.net@outgoing.verizon.net> cc: amd64@freebsd.org cc: andrew.lankford@verizon.net cc: current@freebsd.org Subject: Re: Re: Latest MFCs break boot on amd64 notebook. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: andrew.lankford@verizon.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2004 05:10:52 -0000 This is a multi-part message in MIME format. ------=____1094274649262_6MZUzLAcuR Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit > > From: Ian Dowse > Date: 2004/09/03 Fri PM 10:05:11 CDT > To: Scott Long > CC: andrew.lankford@verizon.net, amd64@freebsd.org, current@freebsd.org > Subject: Re: Latest MFCs break boot on amd64 notebook. > > Unfortunately, due to either a mistake on my part or a spiteful Makefile, /boot/kernel.old/ is totally gone. I wish it wasn't, otherwise I'd be able to look at the contents of my root partition more carefully. As you suggested, /boot/loader.old works almost as well as /boot/loader but the old version doesn't allow me to load/unload modules like I can with the new version. But it doesn't matter whether I'm using /boot/loader.old or /boot/loader. As soon as I have /boot/kernel/kernel loaded into memory and tell it to boot, the "-\|/" twirley spins for a fraction of a second, freezes, and the computer powers down a few seconds later. Unless I can figure out how to successfuly mount and run the userland on my root partition by way of the kernel from a 2 month old install CD or a cross-built kernel, there isn't much else I can do. It's worth mentioning that this notebook needs a small patch to address compatibility problem with the keyboard (it's in GNATS) so that the first probe won't cause it to reboot. I also compiled out ACPI, which has never worked right. Up until now, however, the notebook booted up ok otherwise. ------=____1094274649262_6MZUzLAcuR Content-Transfer-Encoding: base64 Content-Type: null; name="replyAll" Content-Disposition: inline; filename="replyAll" SW4gbWVzc2FnZSA8NDEzOTEwRkQuMjA5MDkwNUBzYW1zY28ub3JnPiwgU2NvdHQgTG9uZyB3 cml0ZXM6DQo+QW5kcmV3IExhbmtmb3JkIHdyb3RlOg0KPj4gVGhlIGxhdGVzdCBNRkNzICh0 aGUgZWFnZXJseSBhd2FpdGVkIGJvb3QtdGltZSBtb2R1bGUNCj4+ICBsb2FkaW5nIGZ1bmN0 aW9uYWxpdHkgb24gYW1kNjQpIGNvbXBpbGVkIG9rLCBidXQgbXkNCj4+IG1hY2hpbmUgZnJl ZXplcyBhbmQgdGhlbiBwb3dlcnMgZG93biBzaG9ydGx5IGFmdGVyDQo+PiAiYm9vdCIgZnJv bSB0aGUgbG9hZGVyLiAgSSB3b3VsZCB0cnkgdG8gZ2l2ZSB5b3UgYWxsDQo+PiBtb3JlIGRl dGFpbHMsIGJ1dCBteSBvbGQgd29ya2luZyBrZXJuZWwgc2VlbXMgdG8gYmUNCj4+IGxvc3Qs IGFuZCBzbyBJJ20gcHJldHR5IG11Y2ggZG93biBmb3IgdGhlIGNvdW50Lg0KPj4gDQo+PiBB bnkgb3RoZXIgYW1kNjQgdXNlcnMgb3V0IHRoZXJlIHRyaWVkIHJlYnVpbGRpbmcNCj4+IHRo ZWlyIGtlcm5lbHMgaW4gdGhlIHBhc3QgZmV3IGhvdXJzPw0KPj4gDQo+PiBBbmRyZXcgTGFu a2ZvcmQNCj4+IA0KPg0KPldlcmUgeW91IGFjdHVhbGx5IHRyeWluZyB0byBsb2FkIGFueSBt b2R1bGVzIGZyb20gdGhlIGxvYWRlciwNCj5vciB3YXMgaXQganVzdCBsb2FkaW5nIGluIHRo ZSBrZXJuZWw/ICBBbHNvLCBoYXZlIHlvdSB0cmllZA0KPnJ1bm5pbmcgYSA2LUNVUlJFTlQg c3lzdGVtIGZvciBjb21wYXJpc29uPw0KDQpBbnkgZnVydGhlciBpbmZvcm1hdGlvbiB5b3Ug Y2FuIHByb3ZpZGUgd291bGQgYmUgYXBwcmVjaWF0ZWQuICBGb3INCmV4YW1wbGUsIGRvIGFu eSBrZXJuZWwgbWVzc2FnZXMgYXBwZWFyIGJlZm9yZSB0aGUgZnJlZXplPyBXaGF0IGRvZXMN CiJsc21vZCIgZnJvbSB0aGUgbG9hZGVyIG91dHB1dCwgYW5kIEkgcHJlc3VtZSB5b3UndmUg dHJpZWQgYm9vdGluZw0Ka2VybmVsLm9sZCAoInVubG9hZCIsICJsb2FkIC9ib290L2tlcm5l bC5vbGQva2VybmVsIiwgImJvb3QiKT8NCg0KWW91IGNvdWxkIGFsc28gdHJ5IGJvb3Rpbmcg d2l0aCB0aGUgb2xkIGxvYWRlciBieSBpbnRlcnJ1cHRpbmcgdGhlDQpib290IHByb2Nlc3Mg YnkgcHJlc3NpbmcgYSBrZXkgaW1tZWRpYXRlbHkgYWZ0ZXIgdGhlIGZpcnN0IG9mIHRoZQ0K fC8tXCBzZXF1ZW5jZSBhcHBlYXJzLiAgWW91IHNob3VsZCBnZXQgYSBwcm9tcHQgbGlrZToN Cg0KCT4+IEZyZWVCU0QvaTM4NiBCT09UDQoJRGVmYXVsdDogMDphZCgwLGEpL2Jvb3QvbG9h ZGVyDQoJYm9vdDoNCg0KRW50ZXINCg0KCTA6YWQoMCxhKS9ib290L2xvYWRlci5vbGQNCg0K YW5kIHNlZSBpZiB0aGF0IGFsbG93cyB5b3UgdG8gYm9vdC4NCg0KSWFuDQo= ------=____1094274649262_6MZUzLAcuR-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 05:21:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 357AB16A4CE; Sat, 4 Sep 2004 05:21:52 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC5DC43D2F; Sat, 4 Sep 2004 05:21:51 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id i845Lp3G035254; Sat, 4 Sep 2004 01:21:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i845LlNp085508; Sat, 4 Sep 2004 01:21:51 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 3D1757303F; Sat, 4 Sep 2004 01:21:47 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040904052147.3D1757303F@freebsd-current.sentex.ca> Date: Sat, 4 Sep 2004 01:21:47 -0400 (EDT) Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2004 05:21:52 -0000 TB --- 2004-09-04 03:21:32 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-04 03:21:32 - starting CURRENT tinderbox run for i386/i386 TB --- 2004-09-04 03:21:32 - checking out the source tree TB --- 2004-09-04 03:21:32 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2004-09-04 03:21:32 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-04 03:26:43 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-04 03:26:43 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2004-09-04 03:26:43 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-09-04 04:33:37 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-04 04:33:37 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2004-09-04 04:33:37 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Sep 4 04:33:37 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sat Sep 4 04:55:47 UTC 2004 TB --- 2004-09-04 04:55:47 - generating LINT kernel config TB --- 2004-09-04 04:55:47 - cd /home/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- 2004-09-04 04:55:47 - /usr/bin/make -B LINT TB --- 2004-09-04 04:55:47 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-04 04:55:47 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2004-09-04 04:55:47 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Sep 4 04:55:48 UTC 2004 >>> 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 [...] /tinderbox/CURRENT/i386/i386/src/sys/modules/re/../../dev/re/if_re.c:1970: warning: 're_start_locked' defined but not used /tinderbox/CURRENT/i386/i386/src/sys/modules/re/../../dev/re/if_re.c:2218: warning: 're_ifmedia_upd' defined but not used /tinderbox/CURRENT/i386/i386/src/sys/modules/re/../../dev/re/if_re.c:2236: warning: 're_ifmedia_sts' defined but not used /tinderbox/CURRENT/i386/i386/src/sys/modules/re/../../dev/re/if_re.c:2253: warning: 're_ioctl' defined but not used /tinderbox/CURRENT/i386/i386/src/sys/modules/re/../../dev/re/if_re.c:2308: warning: 're_watchdog' defined but not used /tinderbox/CURRENT/i386/i386/src/sys/modules/re/../../dev/re/if_re.c:2384: warning: 're_suspend' defined but not used /tinderbox/CURRENT/i386/i386/src/sys/modules/re/../../dev/re/if_re.c:2405: warning: 're_resume' defined but not used /tinderbox/CURRENT/i386/i386/src/sys/modules/re/../../dev/re/if_re.c:2432: warning: 're_shutdown' defined but not used *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/sys/modules/re. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2004-09-04 05:21:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-04 05:21:46 - ERROR: failed to build lint kernel TB --- 2004-09-04 05:21:46 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 05:38:32 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A17516A4CF for ; Sat, 4 Sep 2004 05:38:32 +0000 (GMT) Received: from mmp.dnsalias.org (YahooBB218179180003.bbtec.net [218.179.180.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 41C0643D3F for ; Sat, 4 Sep 2004 05:38:31 +0000 (GMT) (envelope-from thasegawa@mta.biglobe.ne.jp) Received: (qmail 43624 invoked from network); 4 Sep 2004 05:36:58 -0000 Received: from unknown (HELO localhost) (127.0.0.1) by 0 with SMTP; 4 Sep 2004 05:36:58 -0000 Date: Sat, 04 Sep 2004 14:36:36 +0900 (JST) Message-Id: <20040904.143636.41626215.thasegawa@mta.biglobe.ne.jp> To: imp@bsdimp.com From: HASEGAWA Tomoki In-Reply-To: <20040903.210734.89664548.imp@bsdimp.com> References: <20040904.094334.74753938.thasegawa@mta.biglobe.ne.jp> <20040903.210734.89664548.imp@bsdimp.com> X-Mailer: Mew version 4.0.66 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: pccard fixed disk not work on 5.3-BETA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 05:38:32 -0000 imp> do other, non ata pccards work? NICs work well.(corega K.K. corega Ether PCC-T and NextComK.K. NC5310B Ver1.0) From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 06:45:18 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2CED16A4CE; Sat, 4 Sep 2004 06:45:18 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68B1B43D3F; Sat, 4 Sep 2004 06:45:18 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i846jHla041385; Fri, 3 Sep 2004 23:45:18 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i846jHwn041383; Fri, 3 Sep 2004 23:45:17 -0700 (PDT) (envelope-from dillon) Date: Fri, 3 Sep 2004 23:45:17 -0700 (PDT) From: Matthew Dillon Message-Id: <200409040645.i846jHwn041383@apollo.backplane.com> To: "Marc G. Fournier" References: <200409032158.i83LwdWg030214@gw.catspoiler.org> <20040904003222.J812@ganymede.hub.org> cc: Don Lewis cc: freebsd-current@freebsd.org Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 06:45:18 -0000 There may be some tricks you can use to improve your fsck times on that large partition. The first thing you can try is to compile up an fsck with a much larger in-program disk buffer cache. cd into /usr/src/sbin/fsck and edit fsck_ffs/fsck.h. Significantly increase MAXBUFSPACE and INOBUFSIZE. e.g. try increasing MAXBUFSPACE from 40MB to 200MB, and INOBUFSIZE from 56MB to 200MB. Another possibility would be to try to improve disk I/O linearity by modifying getdatablk() in fsutil.c to read-ahead several blocks rather then just one. This would require some programming. The remaining tricks involve reformatting the large partition to increase the block size and/or increase the number of bytes/inode (thus reducing the number of inodes). The larger the block size, the easier it is for fsck to track down indirect blocks. The fewer inodes the partition has, the less work fsck has to do. But, of course, to do this you have to backup all the data on the partition, newfs it with the new parameters, and restore all the data back. Maximizing the number of cylinders/group also helps a great deal but I think newfs already does that by default. -Matt Matthew Dillon From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 06:48:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8759916A4CE for ; Sat, 4 Sep 2004 06:48:49 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 406E843D41 for ; Sat, 4 Sep 2004 06:48:49 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i846meZP031009; Fri, 3 Sep 2004 23:48:44 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409040648.i846meZP031009@gw.catspoiler.org> Date: Fri, 3 Sep 2004 23:48:40 -0700 (PDT) From: Don Lewis To: scrappy@hub.org In-Reply-To: <20040904003116.J812@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org cc: keramida@linux.gr Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 06:48:49 -0000 On 4 Sep, Marc G. Fournier wrote: > > Long shot here, but is this a change that could be MFC'd to 4.x? Or has > fsck changed so much since that it could only be done in 5.x? I would certainly think so. From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 06:59:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37EDF16A4CE for ; Sat, 4 Sep 2004 06:59:12 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id E375D43D4C for ; Sat, 4 Sep 2004 06:59:11 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i846x4nM031021; Fri, 3 Sep 2004 23:59:08 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409040659.i846x4nM031021@gw.catspoiler.org> Date: Fri, 3 Sep 2004 23:59:04 -0700 (PDT) From: Don Lewis To: scrappy@hub.org In-Reply-To: <20040904003222.J812@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 06:59:12 -0000 On 4 Sep, Marc G. Fournier wrote: > On Fri, 3 Sep 2004, Don Lewis wrote: >> Would the file system in question happen to be full of UNREF files that >> fsck is deleting? > > mostly 'ZERO LENGTH DIRECTORY' ... Hmn, this may be something else then, possibly the buffer lookup in getdatablk(). It would be very interesting to compile/link a profiled version of fsck and see what shows up as the hot spot. Are you using the default value for MAXBUFSPACE (defined in fsck.h). From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 07:09:47 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A278216A4CE for ; Sat, 4 Sep 2004 07:09:47 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62B6643D49 for ; Sat, 4 Sep 2004 07:09:47 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i8479U79031043; Sat, 4 Sep 2004 00:09:34 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409040709.i8479U79031043@gw.catspoiler.org> Date: Sat, 4 Sep 2004 00:09:30 -0700 (PDT) From: Don Lewis To: dillon@apollo.backplane.com In-Reply-To: <200409040645.i846jHwn041383@apollo.backplane.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 07:09:47 -0000 On 3 Sep, Matthew Dillon wrote: > There may be some tricks you can use to improve your fsck times on that > large partition. > > The first thing you can try is to compile up an fsck with a much larger > in-program disk buffer cache. cd into /usr/src/sbin/fsck and edit > fsck_ffs/fsck.h. Significantly increase MAXBUFSPACE and INOBUFSIZE. > e.g. try increasing MAXBUFSPACE from 40MB to 200MB, and INOBUFSIZE from > 56MB to 200MB. > > Another possibility would be to try to improve disk I/O linearity by > modifying getdatablk() in fsutil.c to read-ahead several blocks rather > then just one. This would require some programming. > > The remaining tricks involve reformatting the large partition to > increase the block size and/or increase the number of bytes/inode > (thus reducing the number of inodes). The larger the block size, the > easier it is for fsck to track down indirect blocks. The fewer inodes > the partition has, the less work fsck has to do. But, of course, to do > this you have to backup all the data on the partition, newfs it with > the new parameters, and restore all the data back. Maximizing the > number of cylinders/group also helps a great deal but I think newfs > already does that by default. This sort of thing was my initial thought, but the posted CPU usage statistics show that fsck is burning up most of its CPU cycles in userland. >> load: 0.99 cmd: fsck 67 [running] 15192.26u 142.30s 99% 184284k Increasing MAXBUFSPACE looks like it would make the problem worse because getdatablk() does a linear search. From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 07:23:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 623B816A4CE; Sat, 4 Sep 2004 07:23:37 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E31843D1F; Sat, 4 Sep 2004 07:23:37 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id i847NaB3035936; Sat, 4 Sep 2004 03:23:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.12.11/8.12.11) with ESMTP id i847NZ67019429; Sat, 4 Sep 2004 03:23:36 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 13F2873042; Sat, 4 Sep 2004 03:23:36 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20040904072336.13F2873042@freebsd-current.sentex.ca> Date: Sat, 4 Sep 2004 03:23:36 -0400 (EDT) Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2004 07:23:37 -0000 TB --- 2004-09-04 05:21:47 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2004-09-04 05:21:47 - starting CURRENT tinderbox run for i386/pc98 TB --- 2004-09-04 05:21:47 - checking out the source tree TB --- 2004-09-04 05:21:47 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2004-09-04 05:21:47 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2004-09-04 05:33:00 - building world (CFLAGS=-O2 -pipe) TB --- 2004-09-04 05:33:00 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2004-09-04 05:33:00 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2004-09-04 06:48:35 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-04 06:48:35 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2004-09-04 06:48:35 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sat Sep 4 06:48:35 UTC 2004 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Sat Sep 4 07:02:06 UTC 2004 TB --- 2004-09-04 07:02:06 - generating LINT kernel config TB --- 2004-09-04 07:02:06 - cd /home/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- 2004-09-04 07:02:06 - /usr/bin/make -B LINT TB --- 2004-09-04 07:02:06 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2004-09-04 07:02:06 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2004-09-04 07:02:06 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sat Sep 4 07:02:07 UTC 2004 >>> 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 [...] /tinderbox/CURRENT/i386/pc98/src/sys/modules/re/../../dev/re/if_re.c:1970: warning: 're_start_locked' defined but not used /tinderbox/CURRENT/i386/pc98/src/sys/modules/re/../../dev/re/if_re.c:2218: warning: 're_ifmedia_upd' defined but not used /tinderbox/CURRENT/i386/pc98/src/sys/modules/re/../../dev/re/if_re.c:2236: warning: 're_ifmedia_sts' defined but not used /tinderbox/CURRENT/i386/pc98/src/sys/modules/re/../../dev/re/if_re.c:2253: warning: 're_ioctl' defined but not used /tinderbox/CURRENT/i386/pc98/src/sys/modules/re/../../dev/re/if_re.c:2308: warning: 're_watchdog' defined but not used /tinderbox/CURRENT/i386/pc98/src/sys/modules/re/../../dev/re/if_re.c:2384: warning: 're_suspend' defined but not used /tinderbox/CURRENT/i386/pc98/src/sys/modules/re/../../dev/re/if_re.c:2405: warning: 're_resume' defined but not used /tinderbox/CURRENT/i386/pc98/src/sys/modules/re/../../dev/re/if_re.c:2432: warning: 're_shutdown' defined but not used *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/sys/modules/re. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/sys/modules. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2004-09-04 07:23:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2004-09-04 07:23:35 - ERROR: failed to build lint kernel TB --- 2004-09-04 07:23:35 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 07:27:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B2F816A4CE for ; Sat, 4 Sep 2004 07:27:22 +0000 (GMT) Received: from renaissance.homeip.net (m40.net81-65-111.noos.fr [81.65.111.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 035B043D53 for ; Sat, 4 Sep 2004 07:27:21 +0000 (GMT) (envelope-from anthony.ginepro@laposte.net) Received: from renaissance.homeip.net (none@localhost.noos.fr [127.0.0.1]) i847RGdq008289; Sat, 4 Sep 2004 09:27:16 +0200 (CEST) (envelope-from anthony.ginepro@laposte.net) Received: (from rapiere@localhost) by renaissance.homeip.net (8.13.1/8.13.1/Submit) id i847RAg9008287; Sat, 4 Sep 2004 09:27:10 +0200 (CEST) (envelope-from anthony.ginepro@laposte.net) X-Authentication-Warning: renaissance.homeip.net: rapiere set sender to anthony.ginepro@laposte.net using -f Date: Sat, 4 Sep 2004 09:27:10 +0200 From: Anthony Ginepro To: Bruce Cran Message-ID: <20040904072710.GA5584@renaissance.homeip.net> References: <97f8dd040826235372388dea@mail.gmail.com> <200408280027.14207.doconnor@gsoft.com.au> <97f8dd0408271456a8cb2e7@mail.gmail.com> <200408281104.58018.doconnor@gsoft.com.au> <1EA329FC-FDC8-11D8-9B48-000D93ACEE20@cran.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1EA329FC-FDC8-11D8-9B48-000D93ACEE20@cran.org.uk> X-Operating-System: FreeBSD 5.3-BETA2 i386 User-Agent: Mutt/1.5.6i cc: current@freebsd.org Subject: Re: System freeze when useing bfe (Broadcom BCM440x) driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 07:27:22 -0000 On 09/03/04 17:41, Bruce Cran wrote: > On 28 Aug 2004, at 02:34, Daniel O'Connor wrote: > > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > >On Sat, 28 Aug 2004 07:26, Genius Freak wrote: > >>The kernel is rebuilding now :) > >>I was so desperate I even tried the 5.3 beta1 to see if that would > >>work and it did but it was too much of a beta for me to use, it > >>crashed in sysinstall twice. > > > >Personally I'd trust 5.3-BETA over 5.2.1... > > > >If it crashes in sysinstall you should report it (eg the panic > >message) so > >it's less of a beta when it's released :) > > There does seem to be a problem with the BCM driver in 5.3-BETA2, or at > least some problem with the driver when combined with the ICH ATA > driver. After installing lots of distributions and then configuring > the network, I get a panic on my Inspiron 8500. However, if I only > install a couple of distributions then there's no problem. I've also > had no further problem with it once it's installed; I've been cvsup'ing > and adding packages all over the place and the driver seems very > stable. If there's some way to get a kernel dump when running from the > CD (some kernel parameter perhaps?) I'll get an image, but otherwise > all I've got is a list of symbols from the backtrace. > Just to make you note that from time to time, network hangs completely on bfe0 and just comes back some time later. It happens when there's "a lot" of connections (some hundreds). I dunno if it's known or if there's another cause. Anthony. From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 07:35:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D16416A4CF for ; Sat, 4 Sep 2004 07:35:07 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3280943D49 for ; Sat, 4 Sep 2004 07:35:07 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1C3V4k-000Bwj-3x for freebsd-current@freebsd.org; Sat, 04 Sep 2004 10:35:06 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: freebsd-current@freebsd.org In-Reply-To: Message from Derrick Edwards <200409031714.06053.dantavious@comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 04 Sep 2004 10:35:06 +0300 From: Danny Braniss Message-Id: <20040904073507.3280943D49@mx1.FreeBSD.org> Subject: Re: Sound in FreeBSD 5.3 Beta2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 07:35:07 -0000 > On Thursday 02 September 2004 08:00 am, Derrick Edwards wrote: > > Matti made the suggestion to compile snd_ich in the kernel so I did. Still, I > am not able to hear any sound. Any more ideas? Am I the only once having this > problem? > Thanks Derrick > > > > I am having probs with sound. I have read a bunch of postings and tried > > the following things. > > > > 1. added device sound to the kernel > > > > 2. added snd_driver_load="YES" to /boot/loader.conf just to get it > > working. *When I initially added snd_driver_load="YES", I got some sound > > then it crashed, and never came back. > > > > 3. added this to /boot/device.hints because it was in the man page. > > hint.pcm.0.at="isa" > > hint.pcm.0.irq="5" > > hint.pcm.0.drq="1" > > hint.pcm.0.flags="0x0" > > > > 4. Even tried to add pcm to the kernel. (ofcourse it did not work) > > > > This is the output of pciconf > > > > pcm0@pci0:31:5: class=0x040100 card=0x4941434d chip=0x24c58086 rev=0x02 > > hdr=0x00 > > vendor = 'Intel Corporation' > > device = '82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio > > Controller' class = multimedia > > subclass = audio > > I would appreciate any assistance in this manner. > > Thanks > > Derrick look at the dmesg, and search for pcm0, and see if all is ok. in my case: pcm0: port 0xdc00-0xdc7f,0xd800-0xd8ff mem 0xdd081000-0xdd081fff irq 20 at device 6.0 on pci0 pcm0: [GIANT-LOCKED] pcm0: cannot reset channel 0 pcm0: unable to initialize the card device_attach: pcm0 attach returned 6 by chance, i disabled agp and sound is now working! ... pcm0: go figure! danny From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 07:59:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A329A16A4CE; Sat, 4 Sep 2004 07:59:48 +0000 (GMT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1582343D39; Sat, 4 Sep 2004 07:59:48 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-69-104-103-54.dsl.snfc21.pacbell.net [69.104.103.54])i847xhK6151412; Sat, 4 Sep 2004 03:59:44 -0400 Message-ID: <413975EE.4030400@elischer.org> Date: Sat, 04 Sep 2004 00:59:42 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: Don Lewis References: <200409040709.i8479U79031043@gw.catspoiler.org> In-Reply-To: <200409040709.i8479U79031043@gw.catspoiler.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 07:59:48 -0000 Don Lewis wrote: > On 3 Sep, Matthew Dillon wrote: > >> There may be some tricks you can use to improve your fsck times on that >> large partition. >> >> The first thing you can try is to compile up an fsck with a much larger >> in-program disk buffer cache. cd into /usr/src/sbin/fsck and edit >> fsck_ffs/fsck.h. Significantly increase MAXBUFSPACE and INOBUFSIZE. >> e.g. try increasing MAXBUFSPACE from 40MB to 200MB, and INOBUFSIZE from >> 56MB to 200MB. >> >> Another possibility would be to try to improve disk I/O linearity by >> modifying getdatablk() in fsutil.c to read-ahead several blocks rather >> then just one. This would require some programming. >> >> The remaining tricks involve reformatting the large partition to >> increase the block size and/or increase the number of bytes/inode >> (thus reducing the number of inodes). The larger the block size, the >> easier it is for fsck to track down indirect blocks. The fewer inodes >> the partition has, the less work fsck has to do. But, of course, to do >> this you have to backup all the data on the partition, newfs it with >> the new parameters, and restore all the data back. Maximizing the >> number of cylinders/group also helps a great deal but I think newfs >> already does that by default. > > > This sort of thing was my initial thought, but the posted CPU usage > statistics show that fsck is burning up most of its CPU cycles in > userland. > > >>>load: 0.99 cmd: fsck 67 [running] 15192.26u 142.30s 99% 184284k > > > Increasing MAXBUFSPACE looks like it would make the problem worse > because getdatablk() does a linear search. > > _______________________________________________ > 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" if you are using an alternate superblock then teh hash routines devolve into a single linked list.. make si treally sloww.. From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 08:01:14 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8442416A4CF for ; Sat, 4 Sep 2004 08:01:14 +0000 (GMT) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id B11E243D41 for ; Sat, 4 Sep 2004 08:01:13 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) i8481C9W002874 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 4 Sep 2004 18:01:12 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])i8481BxP067876 for ; Sat, 4 Sep 2004 18:01:11 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id i8481BFe067875 for current@freebsd.org; Sat, 4 Sep 2004 18:01:11 +1000 (EST) (envelope-from pjeremy) Date: Sat, 4 Sep 2004 18:01:11 +1000 From: Peter Jeremy To: current@freebsd.org Message-ID: <20040904080058.GV423@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i Subject: 5.3-BETA2 df(1) reports incorrect values for UFS1 FS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 08:01:14 -0000 On a 4.10 system, my /home reports as: Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/ad0s3g 86710002 71758104 8015098 90% 1803049 9038549 17% /home When I mount it on a 5.3-BETA2 system, I get: Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/ad0s3g 86710002 1929924 77843278 2% 70983 10770615 1% /home This is somewhat disconcerting. As far as I can tell, all the files are there but 5.3 doesn't realise it. fsck on 5.3 reports no errors and: 1803048 files, 35879051 used, 42390039 free (1903 frags, 5298517 blocks, 0.0% fragmentation) fsck on 4.10 reports no errors and: 1803048 files, 35879051 used, 7475950 free (390462 frags, 885656 blocks, 0.9% fragmentation) Any ideas what is wrong with 5.3? More critically, is it safe to write to a UFS1 filesystem with 5.3? -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 08:18:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB1F916A4CE for ; Sat, 4 Sep 2004 08:18:27 +0000 (GMT) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D1EB43D1D for ; Sat, 4 Sep 2004 08:18:27 +0000 (GMT) (envelope-from glebius@freebsd.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.12.11/8.12.8) with ESMTP id i848IOP6072234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Sep 2004 12:18:25 +0400 (MSD) (envelope-from glebius@freebsd.org) Received: (from glebius@localhost) by cell.sick.ru (8.12.11/8.12.11/Submit) id i848IObd072233; Sat, 4 Sep 2004 12:18:24 +0400 (MSD) (envelope-from glebius@freebsd.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@freebsd.org using -f Date: Sat, 4 Sep 2004 12:18:24 +0400 From: Gleb Smirnoff To: Dave McCammon Message-ID: <20040904081824.GB72131@cell.sick.ru> References: <20040901164100.47063.qmail@web41414.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20040901164100.47063.qmail@web41414.mail.yahoo.com> User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: 5.3 Beta2 bridging (update 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 08:18:28 -0000 On Wed, Sep 01, 2004 at 09:41:00AM -0700, Dave McCammon wrote: D> Got the bridging to work after cvsup yesterday(I think D> it was the rebuild but not for sure). D> D> em0 - has ip D> em1 - no ip D> D> Anyway, with both cables plugged in, traffic passes D> through the box. Weird thing is, the box can't get to D> (ssh, ping) other machines on the em1 side but can get D> to machines on the em0 side. D> Machines on the em1 side can get to machines on the D> em0 side. Machines on the em0 side can get to machines D> on the em1 side and can get to the bridging box. Do you have option BRIDGE in kernel? Or do you just load module bridge.ko? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 08:26:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DE7D16A4CE for ; Sat, 4 Sep 2004 08:26:02 +0000 (GMT) Received: from mail.digiweb.ie (mail2.digiweb.ie [217.114.163.197]) by mx1.FreeBSD.org (Postfix) with SMTP id 6B5B643D54 for ; Sat, 4 Sep 2004 08:26:01 +0000 (GMT) (envelope-from patrick@collison.ie) Received: (qmail 13326 invoked by uid 399); 4 Sep 2004 08:23:38 -0000 Received: from unknown (HELO ?192.168.1.10?) (217.159.81.198) by mail2.digiweb.ie with SMTP; 4 Sep 2004 08:23:38 -0000 Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: <395D448A-FE4C-11D8-ABA1-000A95C4B57E@collison.ie> Content-Type: text/plain; charset=US-ASCII; format=flowed To: freebsd-current@freebsd.org From: Patrick Collison Date: Sat, 4 Sep 2004 09:27:14 +0100 X-Mailer: Apple Mail (2.619) Subject: Boot hang on BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 08:26:02 -0000 I'm fairly new to FreeBSD, but I've been using 5.2.1 for a while without any major problems. When I tried 5.3-BETA2 today, the boot hung repeatedly after `acd0: DVDROM <_NEC DV-5700A/3.97> at ata1-master'. Safe mode, disabled ACPI, etc, all make no difference. From a quick browse of the archives, it seems that a few others have shared the same or similar problem. Any sign of a fix? From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 08:30:13 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15CF916A4CE for ; Sat, 4 Sep 2004 08:30:13 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id A619043D31 for ; Sat, 4 Sep 2004 08:30:12 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i848U4jN031148; Sat, 4 Sep 2004 01:30:09 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409040830.i848U4jN031148@gw.catspoiler.org> Date: Sat, 4 Sep 2004 01:30:04 -0700 (PDT) From: Don Lewis To: scrappy@hub.org In-Reply-To: <20040904003222.J812@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: freebsd-current@FreeBSD.org Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 08:30:13 -0000 On 4 Sep, Marc G. Fournier wrote: > On Fri, 3 Sep 2004, Don Lewis wrote: >> Would the file system in question happen to be full of UNREF files that >> fsck is deleting? > > mostly 'ZERO LENGTH DIRECTORY' ... I'm pretty sure that I understand the problem now. During pass 4, fsck looks at each inode. It checks each inode in the FSTATE and DFOUND states to see if their link counts need to be adjusted. If the link count does not need to be adjusted, fsck checks to see if the inode is on the list of inodes whose initial link counts were zero, and if it finds the inode on this list, it clears the inode. The problem is that the zero length directories get added to this list if their initial link count is zero, and they also don't get removed from the list because they are in the DCLEAR state, so the list doesn't shrink. This bloats the list, which greatly slows down processing of normal files and directories. Deleting unreferenced files is not the biggest bottleneck, so reversing the order of the list isn't going to help much. Probably the biggest speedup could be gained by keeping the zero length directories off the list. In -CURRENT the pass 1 code in checkinode() looks like: if (DIP(dp, di_nlink) <= 0) { zlnp = (struct zlncnt *)malloc(sizeof *zlnp); if (zlnp == NULL) { pfatal("LINK COUNT TABLE OVERFLOW"); if (reply("CONTINUE") == 0) { ckfini(0); exit(EEXIT); } } else { zlnp->zlncnt = inumber; zlnp->next = zlnhead; zlnhead = zlnp; } } if (mode == IFDIR) { if (DIP(dp, di_size) == 0) inoinfo(inumber)->ino_state = DCLEAR; else inoinfo(inumber)->ino_state = DSTATE; cacheino(dp, inumber); countdirs++; } else inoinfo(inumber)->ino_state = FSTATE; Change the first 'if' statement to: if (DIP(dp, di_nlink) <= 0 && (mode != IFDIR || DIP(dp, di_size) != 0)) { The equivalent change in 4.x would be: if (dp->di_nlink <= 0 && (mode != IFDIR || dp->di_size != 0)) { The order of the two blocks of code could also be reversed so that the inode would only be added to the list if it was not in the DCLEAR state. I think this is a cleaner change. The next step would probably be to convert the zln list to a hash table. Using the lower bits of the inode number as the key would probably be reasonable. A final step would be to build the hash chain lists in the reverse order to speed deletion, but I suspect there is lower hanging fruit elsewhere. From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 08:43:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC43416A4CE for ; Sat, 4 Sep 2004 08:43:15 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1D9EE43D39 for ; Sat, 4 Sep 2004 08:43:13 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.11/8.12.11) with ESMTP id i848fr2n048755; Sat, 4 Sep 2004 02:41:54 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 04 Sep 2004 02:42:13 -0600 (MDT) Message-Id: <20040904.024213.102230434.imp@bsdimp.com> To: thasegawa@mta.biglobe.ne.jp From: "M. Warner Losh" In-Reply-To: <20040904.143636.41626215.thasegawa@mta.biglobe.ne.jp> References: <20040904.094334.74753938.thasegawa@mta.biglobe.ne.jp> <20040903.210734.89664548.imp@bsdimp.com> <20040904.143636.41626215.thasegawa@mta.biglobe.ne.jp> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: pccard fixed disk not work on 5.3-BETA X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 08:43:16 -0000 In message: <20040904.143636.41626215.thasegawa@mta.biglobe.ne.jp> HASEGAWA Tomoki writes: : imp> do other, non ata pccards work? : : NICs work well.(corega K.K. corega Ether PCC-T and NextComK.K. NC5310B Ver1.0) Is pccard a module or compiled into the kernel? If it is a module only, then there will be no ata pccard attachment in the kernel, which could be your problem. Warner From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 09:50:01 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E562C16A4CF; Sat, 4 Sep 2004 09:50:01 +0000 (GMT) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 414CE43D53; Sat, 4 Sep 2004 09:50:01 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id 5111B50B9A; Sat, 4 Sep 2004 18:49:59 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id B772050B95; Sat, 4 Sep 2004 18:49:57 +0900 (JST) Date: Sat, 04 Sep 2004 18:49:57 +0900 Message-ID: <7mbrgmwegq.wl@black.imgsrc.co.jp> From: Jun Kuriyama To: Robert Watson In-Reply-To: References: <20040903104015.GA1889@nemesis.md.0xfce3.net> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) SEMI/1.14.6 (Maruoka) FLIM/1.14.6 (Marutamachi) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/sys/conf options src/sys/sys kernel.h src/sys/net netisr.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 09:50:02 -0000 At Fri, 3 Sep 2004 07:31:23 -0400 (EDT), Robert Watson wrote: > Regarding IPv6: significant parts of IPv6 are safe in an MPSAFE > environment, but not very well tested -- I've had about three or four > minor but significant (fail stop) bugs to correct in the last two weeks. > I don't doubt more are waiting. Areas that still require substantial > attention in locking include the IPv6 forwarding path, ip6fw, and > multicast discovery/routing. If you're using IPv6 on a local system > largely for services like TCP consumption and serving, you are probably > OK, but might encounter fail stop (assertion failure) scenarios that > require some debugging. So far, these problems have generally been > resolved within 48 hours of the problem being reported. > > So if you're willing to do a bit of testing, MPSAFE operation is probably > ready for you, and additional IPv6 testing is something I'd like to see > more of, as I don't have easy access to a rich IPv6 environment. Nice to hear. I'll start testing with mpsafenet=1 with usual workload from Monday (sitting at console). # I don't care if my box panics. :-) -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 10:36:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65F8316A4CE for ; Sat, 4 Sep 2004 10:36:00 +0000 (GMT) Received: from av1-2-sn3.vrr.skanova.net (av1-2-sn3.vrr.skanova.net [81.228.9.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F1C743D3F for ; Sat, 4 Sep 2004 10:36:00 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av1-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 77C3537EF3; Sat, 4 Sep 2004 12:35:59 +0200 (CEST) Received: from smtp1-1-sn3.vrr.skanova.net (smtp1-1-sn3.vrr.skanova.net [81.228.9.177]) by av1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 65B5637E4A; Sat, 4 Sep 2004 12:35:59 +0200 (CEST) Received: from gadget (h130n1fls11o822.telia.com [213.64.66.130]) by smtp1-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 446C33800E; Sat, 4 Sep 2004 12:35:59 +0200 (CEST) From: "Daniel Eriksson" To: "'John-Mark Gurney'" , Date: Sat, 4 Sep 2004 12:33:53 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20040825175250.GO29902@funkthat.com> Thread-Index: AcSK5KNLWPySpqwHTTuEuV7Qvx7uxQHhTM+g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: RE: if_re locking patch... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 10:36:00 -0000 John-Mark Gurney wrote: > To expand upon the patch posted previously, I have cribbed bms's rl > locking, and ported it to re. This makes the interrupt MPSAFE along > with the rest of the driver. No more GIANT LOCKED messages for re. :) I saw that this was committed to HEAD yesterday. I have a machine with a 8169-based NIC that is doing ~300GB on a daily basis that I'd love to try to run with debug.mpsafenet=1. Do you think the patch that went into HEAD has been tested enough that it is safe to try it? It's a UP machine using POLLING mode (HZ=2000), if that makes any difference. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 16:54:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61CC016A4D0; Fri, 3 Sep 2004 16:54:55 +0000 (GMT) Received: from corbulon.video-collage.com (corbulon.video-collage.com [64.35.99.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C35D43D2D; Fri, 3 Sep 2004 16:54:55 +0000 (GMT) (envelope-from mi+mxmoz@aldan.algebra.com) Received: from 250-217.customer.cloud9.net (195-11.customer.cloud9.net [168.100.195.11])i83Gsq0d037552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Sep 2004 12:54:53 -0400 (EDT) (envelope-from mi+mxmoz@aldan.algebra.com) Received: from [127.0.0.1] (mteterin@localhost [127.0.0.1]) i83GseY8019878; Fri, 3 Sep 2004 12:54:41 -0400 (EDT) (envelope-from mi+mxmoz@aldan.algebra.com) Message-ID: <4138A1D0.4050309@aldan.algebra.com> Date: Fri, 03 Sep 2004 12:54:40 -0400 From: Mikhail Teterin User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; uk-UA; rv:1.7) Gecko/20040702 X-Accept-Language: uk, en-us, en MIME-Version: 1.0 To: Ruslan Ermilov References: <413522EE.5080806@aldan.algebra.com> <20040901154335.GA15802@ip.net.ua> In-Reply-To: <20040901154335.GA15802@ip.net.ua> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamd / ClamAV version devel-20040615, clamav-milter version 0.73a on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Sat, 04 Sep 2004 12:18:44 +0000 cc: current@FreeBSD.org cc: freebsd-amd64@FreeBSD.org Subject: Re: -current buildworld fails on amd64 (5.2.1) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 16:54:55 -0000 Yes, indeed, the clock was off ( Ruslan Ermilov wrote: >On Tue, Aug 31, 2004 at 09:16:30PM -0400, Mikhail Teterin wrote: > > >>Starting with an empty /usr/obj: >> >>cc -DHAVE_CONFIG_H -DCOMPILE_ONLY -I/usr/src/lib/libmagic >>-I/usr/src/lib/libmagic/../../contrib/file -o mkmagic >>/usr/src/lib/libmagic/../../contrib/file/apprentice.c >>/usr/src/lib/libmagic/../../contrib/file/funcs.c >>/usr/src/lib/libmagic/../../contrib/file/magic.c >>/usr/src/lib/libmagic/../../contrib/file/print.c >>/usr/obj/usr/src/amd64/usr/bin/ld: cannot find -lc >>*** Error code 1 >> >>[...] >> >>Any clues? Thanks! >> >> >> >Assuming that this happened in the "building libraries" >stage of buildworld (please give more context next time!), >I'd say it's likely that your computer's date/time is set >incorrectly, or some source files have modification time >pointing to the future. > > >Cheers, > > From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 17:24:08 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DDDC16A4CE for ; Fri, 3 Sep 2004 17:24:08 +0000 (GMT) Received: from dhumketu.homeunix.net (dialpool-210-214-233-139.maa.sify.net [210.214.233.139]) by mx1.FreeBSD.org (Postfix) with ESMTP id 218C343D54 for ; Fri, 3 Sep 2004 17:24:07 +0000 (GMT) (envelope-from freebsd@dhumketu.cjb.net) Received: by dhumketu.homeunix.net (Postfix, from userid 1001) id D185620FC; Fri, 3 Sep 2004 22:53:01 +0530 (IST) Date: Fri, 3 Sep 2004 22:53:01 +0530 From: Shantanoo To: freebsd-current@freebsd.org Message-ID: <20040903172301.GA606@dhumketu.homeunix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Organization: Eh? Whats that? X-OS: FreeBSD 5.3-BETA2 i386 X-Mailman-Approved-At: Sat, 04 Sep 2004 12:18:44 +0000 Subject: Kernel Panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 17:24:08 -0000 # uname -a FreeBSD dhumketu.homeunix.net 5.3-BETA2 FreeBSD 5.3-BETA2 #1: Tue Aug 31 23:11:3 0 IST 2004 root@dhumketu.homeunix.net:/usr/obj/usr/src/sys/GENERIC i386 Received following error msgs. and I had to restart the system. ad0: warining-write_DMA intrrupt was seen but taskqueue stalled LBA=2097343 slab at 0xc19fcf70, freei 0=0 Panic: Duplicate free of item 0xc19fc000 from zone 0xc14b8000 (g_bi 0) cpuid = 0 KDB: enter: panic [thread 100036] stopped at kdb_enter+2x2bi nop db> Regards, Shantanoo From owner-freebsd-current@FreeBSD.ORG Fri Sep 3 22:05:07 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F10716A4CF for ; Fri, 3 Sep 2004 22:05:07 +0000 (GMT) Received: from web21324.mail.yahoo.com (web21324.mail.yahoo.com [216.136.175.210]) by mx1.FreeBSD.org (Postfix) with SMTP id 61BE243D49 for ; Fri, 3 Sep 2004 22:05:07 +0000 (GMT) (envelope-from brueggma@yahoo.com) Message-ID: <20040903220507.76268.qmail@web21324.mail.yahoo.com> Received: from [69.208.221.138] by web21324.mail.yahoo.com via HTTP; Fri, 03 Sep 2004 15:05:07 PDT Date: Fri, 3 Sep 2004 15:05:07 -0700 (PDT) From: asfdqwer xzcvdsf To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Sat, 04 Sep 2004 12:18:44 +0000 Subject: jails X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 03 Sep 2004 22:05:07 -0000 I'm pretty sure this used to work a few months ago, has something changed? A quick glance in UPDATING dosen't return anything interesting.. athlon1# cat make-jail.sh #!/bin/sh if [ $# -ne 2 ]; then echo "We need a jail name and an IP." exit fi # For simplicity, don't create the filesystem # mkdir -p /usr/jail/$1 # /usr/bin/nice -n 19 dd if=/dev/zero of=/usr/jail/$1.dsk bs=1k count=5000k # something=`mdconfig -a -t vnode -f /usr/jail/$1.dsk` # disklabel -r -w ${something} auto # newfs ${something}c # fsck -p -y /dev/${something}c # mount /dev/${something}c /usr/jail/$1 ### echo "/dev/${something} /usr/jail/$1 ufs rw 0 0" >> /etc/fstab ### remove disk image ### mdconfig -d -u 4 cd /usr/src /usr/bin/nice -n 19 make -j2 world DESTDIR=/usr/jail/$1 cd etc make distribution DESTDIR=/usr/jail/$1 mount_devfs devfs /usr/jail/$1/dev cd /usr/jail/$1 ln -sf dev/null kernel touch /usr/jail/$1/etc/fstab echo 'network_interfaces=""' >> /usr/jail/$1/etc/rc.conf echo 'inetd_enable="YES"' >> /usr/jail/$1/etc/rc.conf echo 'inetd_flags="-wW -C 5 -l -R 1024 -s 3"' >> /usr/jail/$1/etc/rc.conf echo 'ssh stream tcp nowait root /usr/sbin/sshd sshd -i -4' >> /usr/jail/$1/etc/inetd.conf echo 'telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a off -X sra -h' >> /usr/jail/$1/etc/inetd.conf echo 'syslogd_enable="NO"' >> /usr/jail/$1/etc/rc.conf echo 'sendmail_enable="NONE"' >> /usr/jail/$1/etc/rc.conf egrep -v "127.0.0.1" /etc/resolv.conf > /usr/jail/$1/etc/resolv.conf cp /etc/localtime /usr/jail/$1/etc cp /etc/motd /usr/jail/$1/etc touch /usr/jail/$1/etc/COPYRIGHT chroot /usr/jail/$1 /usr/bin/newaliases chroot /usr/jail/$1 /usr/sbin/pw user mod -w yes -n root chroot /usr/jail/$1 /usr/sbin/pw user add -n user -g wheel -w yes -m chroot /usr/jail/$1 /etc/rc.d/sshd forcekeygen jail /usr/jail/$1 $1 $2 /bin/sh /etc/rc # jls # jexec 1 kill -KILL -1 athlon1# athlon1# ./make-jail.sh test.org 127.0.0.2 -------------------------------------------------------------- >>> make world started on Fri Sep 3 17:01:22 CDT 2004 -------------------------------------------------------------- -------------------------------------------------------------- >>> Rebuilding the temporary build tree -------------------------------------------------------------- rm -rf /usr/obj/usr/src/i386 mkdir -p /usr/obj/usr/src/i386/legacy/usr/bin mkdir -p /usr/obj/usr/src/i386/legacy/usr/games mkdir -p /usr/obj/usr/src/i386/legacy/usr/include/c++/3.3 mkdir -p /usr/obj/usr/src/i386/legacy/usr/include/sys mkdir -p /usr/obj/usr/src/i386/legacy/usr/lib mkdir -p /usr/obj/usr/src/i386/legacy/usr/libexec mkdir -p /usr/obj/usr/src/i386/legacy/usr/sbin mkdir -p /usr/obj/usr/src/i386/legacy/usr/share/dict mkdir -p /usr/obj/usr/src/i386/legacy/usr/share/groff_font/devX100 mkdir -p /usr/obj/usr/src/i386/legacy/usr/share/groff_font/devX100-12 mkdir -p /usr/obj/usr/src/i386/legacy/usr/share/groff_font/devX75 mkdir -p /usr/obj/usr/src/i386/legacy/usr/share/groff_font/devX75-12 mkdir -p /usr/obj/usr/src/i386/legacy/usr/share/groff_font/devascii mkdir -p /usr/obj/usr/src/i386/legacy/usr/share/groff_font/devcp1047 mkdir -p /usr/obj/usr/src/i386/legacy/usr/share/groff_font/devdvi mkdir -p /usr/obj/usr/src/i386/legacy/usr/share/groff_font/devhtml mkdir -p /usr/obj/usr/src/i386/legacy/usr/share/groff_font/devkoi8-r mkdir -p /usr/obj/usr/src/i386/legacy/usr/share/groff_font/devlatin1 mkdir -p /usr/obj/usr/src/i386/legacy/usr/share/groff_font/devlbp mkdir -p /usr/obj/usr/src/i386/legacy/usr/share/groff_font/devlj4 mkdir -p /usr/obj/usr/src/i386/legacy/usr/share/groff_font/devps mkdir -p /usr/obj/usr/src/i386/legacy/usr/share/groff_font/devutf8 mkdir -p /usr/obj/usr/src/i386/legacy/usr/share/tmac/mdoc mkdir -p /usr/obj/usr/src/i386/legacy/usr/share/tmac/mm mkdir -p /usr/obj/usr/src/i386/lib mkdir -p /usr/obj/usr/src/i386/usr/bin mkdir -p /usr/obj/usr/src/i386/usr/include mkdir -p /usr/obj/usr/src/i386/usr/lib/compat/aout mkdir -p /usr/obj/usr/src/i386/usr/libdata/ldscripts mkdir -p /usr/obj/usr/src/i386/usr/libexec mkdir -p /usr/obj/usr/src/i386/usr/sbin mkdir -p /usr/obj/usr/src/i386/usr/share/misc mkdir -p /usr/obj/usr/src/i386/usr/share/snmp/defs mkdir -p /usr/obj/usr/src/i386/usr/share/snmp/mibs mtree -deU -f /usr/src/etc/mtree/BSD.include.dist -p /usr/obj/usr/src/i386/usr/include >/dev/null ln -sf /usr/src/sys /usr/obj/usr/src/i386 -------------------------------------------------------------- >>> stage 1.1: legacy release compatibility shims -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/i386 DESTDIR= INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/obj/usr/src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/src/i386 MAKEFLAGS="-m /usr/src/tools/build/mk -j 2 DESTDIR=/usr/jail/test.org -m /usr/src/share/mk" make -f Makefile.inc1 BOOTSTRAPPING=503000 -DNOHTML -DNOINFO -DNOLINT -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED -DNO_CPU_CFLAGS -DNO_WARNS legacy ===> tools/build /usr/obj/usr/src/i386/usr/src/tools/build created for /usr/src/tools/build cd /usr/src/tools/build; make buildincludes; make installincludes rm -f .depend mkdep -f .depend -a -I/usr/obj/usr/src/i386/legacy/usr/include /usr/src/tools/build/dummy.c cc -O2 -pipe -funroll-loops -ffast-math -I/usr/obj/usr/src/i386/legacy/usr/include -c /usr/src/tools/build/dummy.c building static egacy library ranlib libegacy.a sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 libegacy.a /usr/obj/usr/src/i386/legacy/usr/lib -------------------------------------------------------------- >>> stage 1.2: bootstrap tools -------------------------------------------------------------- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/i386 DESTDIR= INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386/legacy/usr/sbin:/usr/obj/usr/src/i386/legacy/usr/bin:/usr/obj/usr/src/i386/legacy/usr/games:/sbin:/bin:/usr/sbin:/usr/bin WORLDTMP=/usr/obj/usr/src/i386 MAKEFLAGS="-m /usr/src/tools/build/mk -j 2 DESTDIR=/usr/jail/test.org -m /usr/src/share/mk" make -f Makefile.inc1 BOOTSTRAPPING=503000 -DNOHTML -DNOINFO -DNOLINT -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED -DNO_CPU_CFLAGS -DNO_WARNS bootstrap-tools ===> games/fortune/strfile /usr/obj/usr/src/i386/usr/src/games/fortune/strfile created for /usr/src/games/fortune/strfile rm -f .depend mkdep -f .depend -a -I/usr/obj/usr/src/i386/legacy/usr/include /usr/src/games/fortune/strfile/strfile.c echo strfile: /usr/jail/test.org/usr/lib/libc.a /usr/obj/usr/src/i386/legacy/usr/lib/libegacy.a >> .depend make: don't know how to make /usr/jail/test.org/usr/lib/libc.a. Stop *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 12:47:52 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0E3916A4CE for ; Sat, 4 Sep 2004 12:47:52 +0000 (GMT) Received: from kraid.nerim.net (smtp-106-saturday.nerim.net [62.4.16.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A73D43D3F for ; Sat, 4 Sep 2004 12:47:52 +0000 (GMT) (envelope-from bettan@nerim.net) Received: from danielle (linux-win.com [62.212.121.38]) by kraid.nerim.net (Postfix) with SMTP id 60DD1417D1 for ; Sat, 4 Sep 2004 14:47:50 +0200 (CEST) Message-ID: <001401c4927d$666d1a50$0301a8c0@danielle> From: "bettan" To: Date: Sat, 4 Sep 2004 14:47:54 +0200 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: netgear wg311 v2 and speed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 12:47:53 -0000 hello , i have configured my ndis0 card ( netgear wg311 v2 ) in client ( = ifconfig ndis0 inet 192.168.1.2 netmask 255.255.255.0 ) and i have an = access point ( link sys wap54 g ) but i have problem with speed i have = 11 Mbps in download and 20 Mbps in upload in speed instead of 54 = mbps.How support ndis0 mode 11 g 54 Mbps ? From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 12:47:54 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4F8316A4CE; Sat, 4 Sep 2004 12:47:54 +0000 (GMT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id BBB5E43D3F; Sat, 4 Sep 2004 12:47:53 +0000 (GMT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 4 Sep 2004 13:47:53 +0100 (BST) To: andrew.lankford@verizon.net In-Reply-To: Your message of "Sat, 04 Sep 2004 00:10:49 CDT." <20040904051049.DWQM14580.out011.verizon.net@outgoing.verizon.net> Date: Sat, 04 Sep 2004 13:47:49 +0100 From: Ian Dowse Message-ID: <200409041347.aa05366@salmon.maths.tcd.ie> cc: amd64@freebsd.org cc: current@freebsd.org Subject: Re: Latest MFCs break boot on amd64 notebook. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 12:47:55 -0000 In message <20040904051049.DWQM14580.out011.verizon.net@outgoing.verizon.net>, Andrew Lankford writes: >Unfortunately, due to either a mistake on my part or a spiteful Makefile, /boo >t/kernel.old/ is totally gone. I wish it wasn't, otherwise I'd be able to loo >k at the contents of my root partition more carefully. As you suggested, /boo >t/loader.old works almost as well as /boot/loader but the old version doesn't >allow me to load/unload modules like I can with the new version. But it doesn >'t matter whether I'm using /boot/loader.old or /boot/loader. As soon as I ha >ve /boot/kernel/kernel loaded into memory and tell it to boot, the "-\|/" twir >ley spins for a fraction of a second, freezes, and the computer powers down a >few seconds later. Thanks for these details. The fact that the kernel copyright messages etc don't get displayed even with the old loader makes it seem unlikely that it is a direct problem with the module preloading. Maybe the kernel itself is corrupt - this could happen for example if the system did not shut down cleanly immediately after writing it to disk. Does the "lsmod" loader command display sensible results after "load /boot/kernel/kernel"? If ACPI causes problems, you can also check with lsmod that you haven't accidentally compiled it in. In theory it should be possible to load the kernel from the compile directory by giving the loader the full partition-relative path, e.g load disk0s1e:/obj/usr/src/sys/amd64/compile/MYCONF/kernel where "disk0s1e" is your /usr partition and the path is the compile directory relative to /usr. Unfortunately this doesn't seem to work for me, so it may not be much help. Ian From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 13:31:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 388D316A4CE for ; Sat, 4 Sep 2004 13:31:22 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD38B43D39 for ; Sat, 4 Sep 2004 13:31:21 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i84DSbUl084865; Sat, 4 Sep 2004 09:28:37 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i84DSabP084862; Sat, 4 Sep 2004 09:28:37 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 4 Sep 2004 09:28:36 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Jun Kuriyama In-Reply-To: <7mbrgmwegq.wl@black.imgsrc.co.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/sys/conf options src/sys/sys kernel.h src/sys/net netisr.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 13:31:22 -0000 On Sat, 4 Sep 2004, Jun Kuriyama wrote: > > So if you're willing to do a bit of testing, MPSAFE operation is probably > > ready for you, and additional IPv6 testing is something I'd like to see > > more of, as I don't have easy access to a rich IPv6 environment. > > Nice to hear. I'll start testing with mpsafenet=1 with usual workload > from Monday (sitting at console). > > # I don't care if my box panics. :-) That's good :-) That said, I haven't had a chance to dig into the NFS/IPv6 problem. Hopefully I can do that this weekend since it's a holiday weekend here. A starting point may be to selectively back out pieces of the NFS changes and see if we can narrow down which bit of them is the source of the problem. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 14:02:59 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD38316A4CE for ; Sat, 4 Sep 2004 14:02:59 +0000 (GMT) Received: from miranda.expro.pl (mail2.expro.pl [193.25.166.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C33143D4C for ; Sat, 4 Sep 2004 14:02:59 +0000 (GMT) (envelope-from winfried@miranda.expro.pl) Received: by miranda.expro.pl (Postfix, from userid 1001) id 21EF2153DF; Sat, 4 Sep 2004 16:02:57 +0200 (CEST) Date: Sat, 4 Sep 2004 16:02:57 +0200 From: Jan Srzednicki To: current@freebsd.org Message-ID: <20040904140257.GC51038@miranda.expro.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: 5.3-BETA3 panic, probably IPv6+SMP+mpsafenet related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 14:02:59 -0000 Hello, I'm running a fresh (cvsupped just after the BETA3 commit in newvers.sh) RELENG_5 system. It's a SMP with 2 processors, it's doing some home-routing with pf. pf and some netgraph stuff is compiled into kernel, otherwise it's mostly GENERIC. It seems to me that the panic is IPv6 and mpsafenet (and probably SMP) related. It happens about an hour after a boot (happened twice, so it's repeatable). The system was running stable on BETA2, with mpsafenet=0. I'm now checking if the panic happens again on this machine with mpsafenet=0. Here comes the system dmesg: http://wrzask.pl/stuff/smieci/vmcore.2.dmesg And here are backtraces for these 2 panics. They're similar, but I'm not sure if they're of equal importance. http://wrzask.pl/stuff/smieci/vmcore.2.backtrace http://wrzask.pl/stuff/smieci/vmcore.3.backtrace Willing to provide any aditional data on that. greetings, -- Jan 'wrzask' Srzednicki w@expro.pl From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 14:04:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 567F316A4CE; Sat, 4 Sep 2004 14:04:55 +0000 (GMT) Received: from alogis.com (firewall2.alogis.com [62.8.223.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id B030F43D2F; Sat, 4 Sep 2004 14:04:53 +0000 (GMT) (envelope-from Holger.Kipp@alogis.com) Received: (from hk@localhost) by alogis.com (8.11.1/8.9.3) id i84E4ij31847; Sat, 4 Sep 2004 16:04:44 +0200 (CEST) (envelope-from hk) Date: Sat, 4 Sep 2004 16:04:44 +0200 From: Holger Kipp To: Maxim Sobolev Message-ID: <20040904160444.A31485@intserv.int1.b.intern> References: <4133683A.3090201@portaone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <4133683A.3090201@portaone.com>; from sobomax@portaone.com on Mon, Aug 30, 2004 at 08:47:38PM +0300 cc: "current@freebsd.org" cc: sos@freebsd.org Subject: Re: burncd(8) usability: why `-s max' isn't default? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 14:04:55 -0000 On Mon, Aug 30, 2004 at 08:47:38PM +0300, Maxim Sobolev wrote: > Hi, > > I wonder if there are any compelling reasons why `-s max' is not default > behaviour of burncd(8). IMHO, there is no point to have default of 4. > Usually, today's drives are smart enough to select the maximum speed > supported both by drive and by the medium. Maybe this should be a make-option for building the port. I actually like it not being "-s max" for several reasons: - most audio-cd-player still won't play audio-cds recorded at max-speed. - many cdrs don't like the max-speed the cd-rw-drive offers. - many cd-drives don't like data-cds recorded at a higher speed. at least I don't have another medium to throw away if I forget to select a proper speed. Regards, Holger Kipp From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 14:40:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE20516A4CE for ; Sat, 4 Sep 2004 14:40:53 +0000 (GMT) Received: from hotmail.com (bay11-dav37.bay11.hotmail.com [64.4.39.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA11043D4C for ; Sat, 4 Sep 2004 14:40:53 +0000 (GMT) (envelope-from dsnofe@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 4 Sep 2004 07:40:53 -0700 Received: from 219.82.112.22 by bay11-dav37.bay11.hotmail.com with DAV; Sat, 04 Sep 2004 14:40:53 +0000 X-Originating-IP: [219.82.112.22] X-Originating-Email: [dsnofe@msn.com] X-Sender: dsnofe@msn.com Date: Sat, 04 Sep 2004 22:40:54 +0800 From: Deng XueFeng To: current@freebsd.org Message-Id: <20040904223503.E86A.DSNOFE@msn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.11.02 [CN] X-OriginalArrivalTime: 04 Sep 2004 14:40:53.0669 (UTC) FILETIME=[2E381D50:01C4928D] Subject: 6-current's BTX loader auto reboot after make world. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 14:40:53 -0000 when I rebuild world just now. then reboot. system auto reboot after screen show the first line: - it is during the BTX loader running. I can see one line of like BTX... anyway to fix it? Sincerely, Deng XueFeng MSN: dsnofe@msn.com http://www.dengh.com From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 14:51:43 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37D1416A4CF for ; Sat, 4 Sep 2004 14:51:43 +0000 (GMT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 538AB43D2D for ; Sat, 4 Sep 2004 14:51:42 +0000 (GMT) (envelope-from pldrouin@pldrouin.net) Received: from [24.200.176.90] by VL-MO-MR011.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0I3I002SGUKW3B@VL-MO-MR011.ip.videotron.ca> for current@freebsd.org; Sat, 04 Sep 2004 10:50:57 -0400 (EDT) Date: Sat, 04 Sep 2004 10:50:56 -0400 From: Pierre-Luc Drouin To: current@freebsd.org Message-id: <4139D650.9030506@pldrouin.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040902 Subject: device pcm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 14:51:43 -0000 Hi, I've read UPDATING about the changes related to the soiund devices, but I'm unable to get sound to work. I've added the line "device sound" to my kernel and have tried to use also the line "device pcm" or "device snd_pcm", but both are unknown when I try to compile. My sound card is a SB Live! What should I write in my kernel config line? Thanks! Pierre-Luc Drouin From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 15:02:53 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8494D16A4CE for ; Sat, 4 Sep 2004 15:02:53 +0000 (GMT) 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 0D18343D41 for ; Sat, 4 Sep 2004 15:02:53 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.1/8.13.1) with ESMTP id i84F2q63024534; Sat, 4 Sep 2004 08:02:52 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.1/8.13.1/Submit) id i84F2qjS024533; Sat, 4 Sep 2004 08:02:52 -0700 (PDT) (envelope-from david) Date: Sat, 4 Sep 2004 08:02:52 -0700 (PDT) From: David Wolfskill Message-Id: <200409041502.i84F2qjS024533@bunrab.catwhisker.org> To: current@freebsd.org, PeterJeremy@optushome.com.au In-Reply-To: <20040904080058.GV423@cirb503493.alcatel.com.au> Subject: Re: 5.3-BETA2 df(1) reports incorrect values for UFS1 FS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 15:02:53 -0000 >Date: Sat, 4 Sep 2004 18:01:11 +1000 >From: Peter Jeremy >To: current@freebsd.org >Subject: 5.3-BETA2 df(1) reports incorrect values for UFS1 FS >Sender: owner-freebsd-current@freebsd.org >On a 4.10 system, my /home reports as: >Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on >/dev/ad0s3g 86710002 71758104 8015098 90% 1803049 9038549 17% /home >When I mount it on a 5.3-BETA2 system, I get: >Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on >/dev/ad0s3g 86710002 1929924 77843278 2% 70983 10770615 1% /home Odd.... >This is somewhat disconcerting. As far as I can tell, all the files are >there but 5.3 doesn't realise it. >fsck on 5.3 reports no errors and: >1803048 files, 35879051 used, 42390039 free (1903 frags, 5298517 blocks, 0.0% fragmentation) >fsck on 4.10 reports no errors and: >1803048 files, 35879051 used, 7475950 free (390462 frags, 885656 blocks, 0.9% fragmentation) Hmmm... >Any ideas what is wrong with 5.3? More critically, is it safe to write >to a UFS1 filesystem with 5.3? Although it might be considered risky, each system where I run 5.x is set up so that: * Each file system backed by its own partitin (within a slice) is UFS1. This way, I can mount each of them while running 4.x and do repair work, for example. * The system multi-boots FreeBSD, and I do most of my work on 4.x (at this time). (My "production" systems run snapshots of 4.x that I build every couple of weeks.) * I track each of RELENG_4 and RELENG_5 (was HEAD before RELENG_5 was tagged) on a daily basis (unless "cvs update" shows no changes to the sources in question since last time). I am not seeing the problems you report. In particular, here's my build machine (the laptop is still doing this morning's "make buildworld" for RELENG_5, so it won't be done for a while): First, RELENG_5, freshly built: freebeast(5.3)[1] uname -a FreeBSD freebeast.catwhisker.org 5.3-BETA3 FreeBSD 5.3-BETA3 #14: Sat Sep 4 07:26:33 PDT 2004 root@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/FREEBEAST i386 freebeast(5.3)[2] df -ki Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/ad0s3a 158767 108172 37894 74% 3909 36025 10% / devfs 1 1 0 100% 0 0 100% /dev /dev/ad0s3e 1873113 913919 809345 53% 87517 383073 19% /usr /dev/ad0s4h 27728233 14294775 11215200 56% 862175 6087263 12% /common /dev/ad0s4g 2032839 425583 1444629 23% 47282 461068 9% /var procfs 4 4 0 100% 1 0 100% /proc /dev/md0 507630 8 467012 0% 5 65785 0% /tmp freebeast(5.3)[3] And here's RELENG_4: freebeast(4.10-S)[1] uname -a FreeBSD freebeast.catwhisker.org 4.10-STABLE FreeBSD 4.10-STABLE #987: Fri Sep 3 05:26:57 PDT 2004 root@freebeast.catwhisker.org:/common/S1/obj/usr/src/sys/FREEBEAST i386 freebeast(4.10-S)[2] df -ki Filesystem 1K-blocks Used Avail Capacity iused ifree %iused Mounted on /dev/ad0s1a 158767 47187 98879 32% 1902 38032 5% / mfs:25 515606 6 474352 0% 4 64506 0% /tmp /dev/ad0s1e 1873082 1009417 713819 59% 90564 380026 19% /usr /dev/ad0s2a 158767 47187 98879 32% 1902 38032 5% /S2 /dev/ad0s2e 1873113 946906 776358 55% 87586 383004 19% /S2/usr /dev/ad0s3a 158767 108172 37894 74% 3909 36025 10% /S3 /dev/ad0s3e 1873113 913919 809345 53% 87517 383073 19% /S3/usr /dev/ad0s4a 158767 108249 37817 74% 3909 36025 10% /S4 /dev/ad0s4e 1872759 910011 812928 53% 84059 386531 18% /S4/usr /dev/ad0s4h 27728233 14294777 11215198 56% 862176 6087262 12% /common /dev/ad0s4g 2032839 425642 1444570 23% 47278 461072 9% /var procfs 4 4 0 100% 50 4034 1% /proc freebeast(4.10-S)[3] (You may see that more file systems show up under RELENG_4. I do not mount the RELENG_4 file systems necessary for running the system by default when booting 5.x or higher.) As noted, I have not had the problems you are reporting. The last issue I recall was something that was committed to fsck (iirC) by Matt Dillon (to avoid a 4.x fsck seeing a superblock updated by a 5.x fsck as broken). As implied by the committer, that wa a while back. Peace, david -- David H. Wolfskill david@catwhisker.org Evidence of curmudgeonliness: becoming irritated with the usage of the word "speed" in contexts referring to quantification of network performance, as opposed to "bandwidth" or "latency." From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 15:06:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C774116A4CE for ; Sat, 4 Sep 2004 15:06:00 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1246E43D1F for ; Sat, 4 Sep 2004 15:06:00 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i84F5uqH018930 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Sep 2004 18:05:56 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i84F5ul7092352; Sat, 4 Sep 2004 18:05:56 +0300 (EEST) (envelope-from ru) Date: Sat, 4 Sep 2004 18:05:56 +0300 From: Ruslan Ermilov To: Pierre-Luc Drouin Message-ID: <20040904150556.GC92176@ip.net.ua> References: <4139D650.9030506@pldrouin.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+xNpyl7Qekk2NvDX" Content-Disposition: inline In-Reply-To: <4139D650.9030506@pldrouin.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: current@freebsd.org Subject: Re: device pcm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 15:06:00 -0000 --+xNpyl7Qekk2NvDX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 04, 2004 at 10:50:56AM -0400, Pierre-Luc Drouin wrote: > Hi, >=20 > I've read UPDATING about the changes related to the soiund devices, but= =20 > I'm unable to get sound to work. I've added the line "device sound" to=20 > my kernel and have tried to use also the line "device pcm" or "device=20 > snd_pcm", but both are unknown when I try to compile. My sound card is a= =20 > SB Live! What should I write in my kernel config line? >=20 device sound device snd_ Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --+xNpyl7Qekk2NvDX Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBOdnUqRfpzJluFF4RAke7AJ9jUxluJVWWYsrv6aDIpBFpBtgyjQCfbsSt LgyypEL3WFSNUMlzq7fIxG4= =Zv/4 -----END PGP SIGNATURE----- --+xNpyl7Qekk2NvDX-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 15:06:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7186816A4CE for ; Sat, 4 Sep 2004 15:06:37 +0000 (GMT) Received: from hotmail.com (bay11-dav1.bay11.hotmail.com [64.4.38.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D2EB43D1F for ; Sat, 4 Sep 2004 15:06:37 +0000 (GMT) (envelope-from dsnofe@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 4 Sep 2004 08:06:36 -0700 Received: from 219.82.112.22 by bay11-dav1.bay11.hotmail.com with DAV; Sat, 04 Sep 2004 15:06:36 +0000 X-Originating-IP: [219.82.112.22] X-Originating-Email: [dsnofe@msn.com] X-Sender: dsnofe@msn.com Date: Sat, 04 Sep 2004 23:06:37 +0800 From: Deng XueFeng To: Deng XueFeng In-Reply-To: <20040904223503.E86A.DSNOFE@msn.com> References: <20040904223503.E86A.DSNOFE@msn.com> Message-Id: <20040904230250.60A0.DSNOFE@msn.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.11.02 [CN] X-OriginalArrivalTime: 04 Sep 2004 15:06:36.0980 (UTC) FILETIME=[C61AAF40:01C49290] cc: current@freebsd.org Subject: Re: 6-current's BTX loader auto reboot after make world. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 15:06:37 -0000 i use: 0:ad(0,a)/boot/loader.old to enter system, then: # mv loader.old loader. reboot, all is ok. My last build world is 2004-08-02. Is there any change to loader during there days? and also, my Realtek 8139 C+ alway output: Timeout watchdog....... I can only and have to use the NDIS driver. > when I rebuild world just now. then reboot. > system auto reboot after screen show > the first line: > - > > it is during the BTX loader running. I can see one line of like BTX... > anyway to fix it? > > > Sincerely, > Deng XueFeng > MSN: dsnofe@msn.com > http://www.dengh.com > > _______________________________________________ > 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" Sincerely, Deng XueFeng MSN: dsnofe@msn.com http://www.dengh.com From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 15:08:09 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A54CD16A4CE for ; Sat, 4 Sep 2004 15:08:09 +0000 (GMT) Received: from abigail.blackend.org (blackend.org [212.11.35.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98D6743D48 for ; Sat, 4 Sep 2004 15:08:08 +0000 (GMT) (envelope-from marc@blackend.org) Received: from abigail.blackend.org (localhost [127.0.0.1]) i84F86dt005283; Sat, 4 Sep 2004 17:08:06 +0200 (CEST) (envelope-from marc@abigail.blackend.org) Received: (from marc@localhost) by abigail.blackend.org (8.12.11/8.12.11/Submit) id i84F81em005282; Sat, 4 Sep 2004 17:08:01 +0200 (CEST) (envelope-from marc) Date: Sat, 4 Sep 2004 17:08:00 +0200 From: Marc Fonvieille To: Pierre-Luc Drouin Message-ID: <20040904150800.GA2840@abigail.blackend.org> References: <4139D650.9030506@pldrouin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4139D650.9030506@pldrouin.net> User-Agent: Mutt/1.4.2.1i X-Useless-Header: blackend.org X-Operating-System: FreeBSD 4.10-PRERELEASE cc: current@freebsd.org Subject: Re: device pcm X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 15:08:09 -0000 On Sat, Sep 04, 2004 at 10:50:56AM -0400, Pierre-Luc Drouin wrote: > Hi, > > I've read UPDATING about the changes related to the soiund devices, but > I'm unable to get sound to work. I've added the line "device sound" to > my kernel and have tried to use also the line "device pcm" or "device > snd_pcm", but both are unknown when I try to compile. My sound card is a > SB Live! What should I write in my kernel config line? > Could you try to follow instructions at: http://www.blackend.org/docdev/en_US.ISO8859-1/books/handbook/sound-setup.html it's future update of Handbook section for sound setup. Any feedback is welcome :) Marc From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 15:53:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1FF616A4CE for ; Sat, 4 Sep 2004 15:53:02 +0000 (GMT) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id 0DDC243D1D for ; Sat, 4 Sep 2004 15:53:02 +0000 (GMT) (envelope-from iedowse@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 4 Sep 2004 16:53:01 +0100 (BST) To: Deng XueFeng In-Reply-To: Your message of "Sat, 04 Sep 2004 23:06:37 +0800." <20040904230250.60A0.DSNOFE@msn.com> Date: Sat, 04 Sep 2004 16:53:01 +0100 From: Ian Dowse Message-ID: <200409041653.aa45226@salmon.maths.tcd.ie> cc: current@freebsd.org Subject: Re: 6-current's BTX loader auto reboot after make world. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 15:53:02 -0000 In message <20040904230250.60A0.DSNOFE@msn.com>, Deng XueFeng writes: >i use: > >0:ad(0,a)/boot/loader.old > >to enter system, then: ># mv loader.old loader. > >reboot, all is ok. >My last build world is 2004-08-02. >Is there any change to loader during there days? The amd64 module support and a few other changes went in during that timeframe. If possible, could you try to track down which changes are to blame? This will involve using cvs or cvsup to update the boot code to a few different versions and test if you get a working loader. First make sure you have a working copy of the loader (e.g. copy to /boot/loader.good and test that it works). To test each case, you'll first need to update your boot code sources to a particular date. With CVS, you'd use cd /usr/src/sys/boot env TZ=GMT cvs update -D'2004/08/28 14:00:00' (for example) With cvsup you can add a 'date=2004.08.28.14.00.00' for example to your supfile and `cvsup ... -i src/sys/boot supfile'. To build and install the loader you'll need to do something like: cd /usr/src/sys/boot make clean make make install Some dates that are worth checking are: 2004/08/28 14:00:00 GMT (before amd64 loader work started) 2004/08/28 17:00:00 GMT (after addition of helper functions) 2004/08/29 00:00:00 GMT (after relocation changes) 2004/08/29 02:00:00 GMT (all amd64 loader changes complete) It would be great if you could narrow down when the problem was introduced this way, as it may be hard to find otherwise. Ian From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 15:55:27 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F8B816A4CE for ; Sat, 4 Sep 2004 15:55:27 +0000 (GMT) Received: from miranda.expro.pl (mail2.expro.pl [193.25.166.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51EF343D41 for ; Sat, 4 Sep 2004 15:55:27 +0000 (GMT) (envelope-from winfried@miranda.expro.pl) Received: by miranda.expro.pl (Postfix, from userid 1001) id 473E7153DE; Sat, 4 Sep 2004 17:55:26 +0200 (CEST) Date: Sat, 4 Sep 2004 17:55:26 +0200 From: Jan Srzednicki To: current@freebsd.org Message-ID: <20040904155526.GD51038@miranda.expro.pl> References: <20040904140257.GC51038@miranda.expro.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040904140257.GC51038@miranda.expro.pl> User-Agent: Mutt/1.5.6i Subject: Re: 5.3-BETA3 panic, probably IPv6+SMP+mpsafenet related X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 15:55:27 -0000 On Sat, Sep 04, 2004 at 04:02:57PM +0200, Jan Srzednicki wrote: > Hello, > > I'm running a fresh (cvsupped just after the BETA3 commit in newvers.sh) > RELENG_5 system. It's a SMP with 2 processors, it's doing some > home-routing with pf. pf and some netgraph stuff is compiled into > kernel, otherwise it's mostly GENERIC. > > It seems to me that the panic is IPv6 and mpsafenet (and probably SMP) > related. It happens about an hour after a boot (happened twice, so it's > repeatable). OK, the panic occured again with mpsafenet turned off. I also forgot to mention that this box isn't doing any IPv6 traffic, it just has INET6 enabled in kernel; no tunnels or anything. -- Jan 'Winfried' Srzednicki w@expro.pl From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 16:06:37 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 377E216A4CE for ; Sat, 4 Sep 2004 16:06:37 +0000 (GMT) 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 CF4C243D72 for ; Sat, 4 Sep 2004 16:06:36 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.1/8.13.1) with ESMTP id i84G6av3024892 for ; Sat, 4 Sep 2004 09:06:36 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.1/8.13.1/Submit) id i84G6ar3024891 for freebsd-current@freebsd.org; Sat, 4 Sep 2004 09:06:36 -0700 (PDT) (envelope-from david) Date: Sat, 4 Sep 2004 09:06:36 -0700 (PDT) From: David Wolfskill Message-Id: <200409041606.i84G6ar3024891@bunrab.catwhisker.org> To: freebsd-current@freebsd.org In-Reply-To: <20040903172301.GA606@dhumketu.homeunix.net> Subject: Panic during attempted power-off ("halt -p") X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 16:06:37 -0000 This was with RELENG_5, built today: freebeast(5.3)[1] uname -a FreeBSD freebeast.catwhisker.org 5.3-BETA3 FreeBSD 5.3-BETA3 #14: Sat Sep 4 07:26:33 PDT 2004 root@freebeast.catwhisker.org:/common/S3/obj/usr/src/sys/FREEBEAST i386 freebeast(5.3)[2] After building & booting it, then doing some reality checks, things seemed OK. So -- as is my custom -- I issued: sudo boot0cfg -s 1 ad0 && sudo halt -p || sudo reboot to shut the machine down (until late tonight). I got the following (cut/pasted from serial console; some earlier lines left in for context): Starting local daemons:. Updating motd. Starting ntpd. Configuring syscons: blanktime. Starting sshd. Initial i386 initialization:. Additional ABI support:. Starting cron. Local package initialization:Starting apache. cvsupd . Additional TCP options:. Starting inetd. Starting background file system checks in 60 seconds. Sat Sep 4 07:52:34 PDT 2004 FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0) login: [0] f:00 typ:165 s(CHS):0/1/1 e(CHS):260/254/63 s:63 l:4192902 [1] f:00 typ:165 s(CHS):261/0/1 e(CHS):521/254/63 s:4192965 l:4192965 [2] f:80 typ:165 s(CHS):522/0/1 e(CHS):782/254/63 s:8385930 l:4192965 [3] f:00 typ:165 s(CHS):783/0/1 e(CHS):1023/254/63 s:12578895 l:67697910 GEOM: Reconfigure ad0s1, start 32256 length 2146765824 end 2146798079 GEOM: Reconfigure ad0s2, start 2146798080 length 2146798080 end 4293596159 GEOM: Reconfigure ad0s3, start 4293596160 length 2146798080 end 6440394239 GEOM: Reconfigure ad0s4, start 6440394240 length 34661329920 end 41101724159 boot() called on cpu#0 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...1 1 1 0 0 0 done No buffers busy after final sync Uptime: 1m36s Shutting down ACPI panic: Unknown pri class. cpuid = 0 KDB: stack backtrace: kdb_backtrace(100,c19686e0,c06def88,0,c06de880) at kdb_backtrace+0x29 panic(c0685937,38,0,c06de890,1) at panic+0x114 sched_add_internal(c06def38,0) at sched_add_internal+0xf2 kseq_assign(c06de890) at kseq_assign+0x3d sched_runnable(d41e3d20,c04c52c5,c1967a80,c04c52ac,d41e3d34) at sched_runnable+0x82 cpu_idle(c1967a80,c04c52ac,d41e3d34,c04c5035,0) at cpu_idle+0x1b idle_proc(0,d41e3d48) at idle_proc+0x19 fork_exit(c04c52ac,0,d41e3d48) at fork_exit+0x75 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd41e3d7c, ebp = 0 --- KDB: enter: panic [end of cut/paste....] Note that the buffers had already been cleared, so no file systems needed fsck's tender mercies. And note too, that I do not recall seeing this panic previously (and I've been tracking RELENG_5 daily since it was tagged, and HEAD daily before then). My laptop is finishing up it's "make kernel" as I type, so I don't yet know if it will be similarly affected. Note that the system that got the panic is an SMP machine (while the laptop is not). Subject to other demands on my time, I'm willing and able to bring the SMP box back up and poke at it, if anyone would care to provide guidance as to what to poke. Thanks, david -- David H. Wolfskill david@catwhisker.org Evidence of curmudgeonliness: becoming irritated with the usage of the word "speed" in contexts referring to quantification of network performance, as opposed to "bandwidth" or "latency." From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 16:22:10 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4E5216A4CE; Sat, 4 Sep 2004 16:22:10 +0000 (GMT) Received: from zaphod.nitro.dk (port324.ds1-khk.adsl.cybercity.dk [212.242.113.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F73643D39; Sat, 4 Sep 2004 16:22:09 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 16F9E11AB1; Sat, 4 Sep 2004 18:22:06 +0200 (CEST) Date: Sat, 4 Sep 2004 18:22:06 +0200 From: "Simon L. Nielsen" To: freebsd-current@freebsd.org Message-ID: <20040904162206.GD759@zaphod.nitro.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PHCdUe6m4AxPMzOu" Content-Disposition: inline User-Agent: Mutt/1.5.6i cc: Pawel Jakub Dawidek Subject: Panic using geom_mirror after "WARNING: Device name truncated!..." X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 16:22:10 -0000 --PHCdUe6m4AxPMzOu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello [To Pawel: this mail contain more information than my original private mail to you] I stumbled into an slightly odd error/panic using geom_mirror(4). While I think the main problem here is somewhere in geom_mirror (and probably related to the current content on the disks I mirror) it looks like the one problem triggers other problems. I have two 10GB disks (ad0 and ad1) that I want to do a mirror on called "boot". ad0 contains a full old FreeBSD install (4.9 AFAIR). ad1 just contains a slice table with one slice, and is otherwise clean (bsdlabel for both are included). The system is running RELENG_5 and the problem happens on a August 21 and on a September 3 kernel. On the September 3 kernel I upgraded to geom_mirror from -CURRENT (from today). When I label them and load geom_mirror the systems panics very shortly after with a double fault if I don't stop the mirror first.. The console shows (from sep 4 kernel with debug set to 1): GEOM_MIRROR[1]: Creating device boot (id=3D2639492630). GEOM_MIRROR[0]: Device boot created (id=3D2639492630). GEOM_MIRROR[1]: Adding disk ad1s1 to boot. GEOM_MIRROR[1]: Invalid size of disk ad1s1 (device boot), skipping. GEOM_MIRROR[0]: Cannot add disk ad1s1 to boot (error=3D22). GEOM_MIRROR[0]: Device boot destroyed. GEOM_MIRROR[1]: Creating device boot (id=3D2639492630). GEOM_MIRROR[0]: Device boot created (id=3D2639492630). GEOM_MIRROR[1]: Adding disk ad1s1c to boot. GEOM_MIRROR[1]: Invalid size of disk ad1s1c (device boot), skipping. GEOM_MIRROR[0]: Cannot add disk ad1s1c to boot (error=3D22). GEOM_MIRROR[0]: Device boot destroyed. GEOM_MIRROR[1]: Creating device boot (id=3D2639492630). GEOM_MIRROR[0]: Device boot created (id=3D2639492630). GEOM_MIRROR[1]: Adding disk ad1 to boot. GEOM_MIRROR[1]: Disk ad1 state changed from NONE to NEW (device boot). GEOM_MIRROR[0]: Device boot: provider ad1 detected. GEOM_MIRROR[1]: Adding disk ad0 to boot. GEOM_MIRROR[1]: Disk ad0 state changed from NONE to NEW (device boot). GEOM_MIRROR[0]: Device boot: provider ad0 detected. GEOM_MIRROR[1]: Device boot state changed from STARTING to RUNNING. GEOM_MIRROR[1]: Disk ad1 state changed from NEW to ACTIVE (device boot). GEOM_MIRROR[0]: Device boot: provider ad1 activated. GEOM_MIRROR[1]: Disk ad0 state changed from NEW to ACTIVE (device boot). GEOM_MIRROR[0]: Device boot: provider ad0 activated. GEOM_MIRROR[0]: Device boot: provider mirror/boot launched. GEOM_MIRROR[1]: Adding disk ad1s1 to boot. GEOM_MIRROR[1]: Disk ad1s1 (id=3D2151593843) already exists, skipping. GEOM_MIRROR[0]: Cannot add disk ad1s1 to boot (error=3D17). GEOM_MIRROR[1]: Adding disk ad1s1c to boot. GEOM_MIRROR[1]: Disk ad1s1c (id=3D2151593843) already exists, skipping. GEOM_MIRROR[0]: Cannot add disk ad1s1c to boot (error=3D17). WARNING: Device name truncated! (mirror/boots1ccccccccccccccccccccccccccccc= ccccccccccccccccccccc)KDB: stack backtrace: kdb_backtrace(c07ed998,c1d148a4) at kdb_backtrace+0x29 make_dev(c0847e20,bc,0,5,1a0) at make_dev+0xb7 g_dev_taste(c0847e80,c1d15300,0,c1d0f980,64) at g_dev_taste+0xe2 g_new_provider_event(c1d15300,0,66666667,cbd43d04,c05cff09) at g_new_provid= er_event+0x6e one_event(cbd43d1c,c05d12e5,3c,28,c15368c0) at one_event+0x14f g_run_events(3c,28,c15368c0,c05d12a8,cbd43d34) at g_run_events+0x9 g_event_procbody(0,cbd43d48,0,c05d12a8,0) at g_event_procbody+0x3d fork_exit(c05d12a8,0,cbd43d48) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip =3D 0, esp =3D 0xcbd43d7c, ebp =3D 0 --- I added a call to kdb_backtrace after the warning in make_dev to get an idea whats going on... And it writes _a lot_ of the "WARNIG: Device name..." messages before it crashes like below. The console from August where it actually panics: GEOM_MIRROR: Device boot created (id=3D2639492630). GEOM_MIRROR: Device boot: provider ad0 detected. GEOM_MIRROR: Device boot: provider ad1 detected. GEOM_MIRROR: Device boot: provider ad1 activated. GEOM_MIRROR: Device boot: provider ad0 activated. GEOM_MIRROR: Device boot: provider mirror/boot launched. GEOM_MIRROR: Cannot add disk ad1s1 to boot (error=3D17). GEOM_MIRROR: Cannot add disk ad1s1c to boot (error=3D17). WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ")= WARNING: Device name truncated! (mirror/boots1", 'c' , ") Fatal double fault: eip =3D 0xc0795732 esp =3D 0xcbd42000 ebp =3D 0xcbd42010 cpuid =3D 0; apic id =3D 00 panic: double fault cpuid =3D 0;=20 KDB: enter: panic The backtrace of the panic : #0 doadump () at pcpu.h:159 #1 0xc0460102 in db_fncall (dummy1=3D0, dummy2=3D0, dummy3=3D-1065942185,= =20 dummy4=3D0xc09087e4 "XXX" at /FreeBSD/5-STABLE/sys/ddb/db_command.c:531 #2 0xc045ff10 in db_command (last_cmdp=3D0xc0896f44, cmd_table=3D0x0, aux_= cmd_tablep=3D0xc0817988,=20 aux_cmd_tablep_end=3D0xc08179a4) at /FreeBSD/5-STABLE/sys/ddb/db_comman= d.c:349 #3 0xc045ffd8 in db_command_loop () at /FreeBSD/5-STABLE/sys/ddb/db_comman= d.c:455 #4 0xc0461b3d in db_trap (type=3D3, code=3D0) at /FreeBSD/5-STABLE/sys/ddb= /db_main.c:221 #5 0xc0616c43 in kdb_trap (type=3D3, code=3D0, tf=3D0x1) at /FreeBSD/5-STA= BLE/sys/kern/subr_kdb.c:417 #6 0xc07893e4 in trap (frame=3D {tf_fs =3D 24, tf_es =3D 16, tf_ds =3D 16, tf_edi =3D -1065279731, tf= _esi =3D 1, tf_ebp =3D -1064269468, tf_isp =3D -1064269488, tf_ebx =3D -106= 4269424, tf_edx =3D 0, tf_ecx =3D -1056882688, tf_eax =3D 18, tf_trapno =3D= 3, tf_err =3D 0, tf_eip =3D -1067357785, tf_cs =3D 8, tf_eflags =3D 16530,= tf_esp =3D -1064269436, tf_ss =3D -1067450363}) at /FreeBSD/5-STABLE/sys/i386/i386/trap.c:576 #7 0xc0777cda in calltrap () at /FreeBSD/5-STABLE/sys/i386/i386/exception.= s:140 #8 0x00000018 in ?? () #9 0x00000010 in ?? () #10 0x00000010 in ?? () #11 0xc0811f0d in ?? () #12 0x00000001 in ?? () #13 0xc0908964 in dblfault_stack () #14 0xc0908950 in dblfault_stack () #15 0xc0908990 in dblfault_stack () #16 0x00000000 in ?? () #17 0xc1014000 in ?? () #18 0x00000012 in ?? () #19 0x00000003 in ?? () #20 0x00000000 in ?? () #21 0xc06169a7 in kdb_enter (msg=3D0x0) at cpufunc.h:56 #22 0xc0600005 in panic (fmt=3D0xc0811f0d "double fault") at /FreeBSD/5-STA= BLE/sys/kern/kern_shutdown.c:542 #23 0xc0789986 in dblfault_handler () at /FreeBSD/5-STABLE/sys/i386/i386/tr= ap.c:841 #24 0x00000000 in ?? () [simon@eddie:geom_mirror] sudo bsdlabel ad0s1 # /dev/ad0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 409600 0 4.2BSD 2048 16384 97=20 b: 524288 409600 swap =20 c: 19792017 0 unused 0 0 # "raw" part, don't= edit e: 1048576 933888 4.2BSD 2048 16384 89=20 f: 17809553 1982464 4.2BSD 2048 16384 89=20 [simon@eddie:geom_mirror] sudo bsdlabel ad1s1 # /dev/ad1s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 19807137 0 unused 0 0 # "raw" part, don't= edit Anybody get a clue about what's really going wrong here? --=20 Simon L. Nielsen FreeBSD Documentation Team --PHCdUe6m4AxPMzOu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBOeuuh9pcDSc1mlERAvZeAJ4tN2muSg2V7NAK0kPAQDMQo3S6qgCeJ3+F yUx6fBntp6gJ6MjSUqTWrvQ= =uq4Z -----END PGP SIGNATURE----- --PHCdUe6m4AxPMzOu-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 16:29:51 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12A8716A4CE for ; Sat, 4 Sep 2004 16:29:51 +0000 (GMT) Received: from smtp.eos.ocn.ne.jp (eos.ocn.ne.jp [222.146.51.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id C18F043D2D for ; Sat, 4 Sep 2004 16:29:50 +0000 (GMT) (envelope-from hrs@FreeBSD.org) Received: from delta.allbsd.org (p41145-adsao12honb4-acca.tokyo.ocn.ne.jp [219.161.230.145]) by smtp.eos.ocn.ne.jp (Postfix) with ESMTP id EB2BF29FB for ; Sun, 5 Sep 2004 01:29:49 +0900 (JST) Received: from localhost (alph.allbsd.org [192.168.0.10]) by delta.allbsd.org (8.12.9p2/8.12.9) with ESMTP id i84GSnbT011314 for ; Sun, 5 Sep 2004 01:28:49 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 05 Sep 2004 01:28:43 +0900 (JST) Message-Id: <20040905.012843.59649116.hrs@eos.ocn.ne.jp> To: current@FreeBSD.org From: Hiroki Sato X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 4.0.68 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sun_Sep__5_01_28_43_2004_636)--" Content-Transfer-Encoding: 7bit Subject: LOR X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 16:29:51 -0000 ----Security_Multipart(Sun_Sep__5_01_28_43_2004_636)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I got the following LOR just after starting /etc/rc.d/sendmail with -CURRENT as of Sep 4 on a SMP machine. No panic occurred, but this appears every time the system is booted. lock order reversal 1st 0xc08ec200 ifnet (ifnet) @ /usr/src/sys/net/if.c:1489 2nd 0xc46703c8 user map (user map) @ /usr/src/sys/vm/vm_map.c:2994 KDB: stack backtrace: kdb_backtrace(0,ffffffff,c08c7810,c08c8300,c08569ec) at kdb_backtrace+0x29 witness_checkorder(c46703c8,9,c0810c9b,bb2) at witness_checkorder+0x544 _sx_xlock(c46703c8,c0810c9b,bb2) at _sx_xlock+0x50 _vm_map_lock_read(c4670384,c0810c9b,bb2,2000004,c4b715ac) at _vm_map_lock_read+0x37 vm_map_lookup(e852ca84,813b000,2,e852ca88,e852ca78) at vm_map_lookup+0x28 vm_fault(c4670384,813b000,2,8,c4adeb00) at vm_fault+0x66 trap_pfault(e852cb4c,0,813b000) at trap_pfault+0xd2 trap(e8520018,c0610010,c08e0010,813b000,e852cbc0) at trap+0x30d calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc078d17a, esp = 0xe852cb8c, ebp = 0xe852cbec --- generic_copyout(c0086924,e852cc60,e852cc14,c061fa3a,c08c8968) at generic_copyout+0x36 ifioctl(c4c7ca20,c0086924,e852cc60,c4adeb00,0) at ifioctl+0x25 soo_ioctl(c4b4a8c4,c0086924,e852cc60,c4d5cd00,c4adeb00) at soo_ioctl+0x2b1 ioctl(c4adeb00,e852cd14,3,2,282) at ioctl+0x3e0 syscall(2f,2f,2f,0,0) at syscall+0x213 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2828c22f, esp = 0xbfbfcd7c, ebp = 0xbfbfcf28 --- -- | Hiroki SATO ----Security_Multipart(Sun_Sep__5_01_28_43_2004_636)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQBBOe07TyzT2CeTzy0RAjIBAJ9DO5f/pUOUEDcVroVgPDjvLzzAwQCfWO5S qpbrzB35RN8A0JiVhH0TBp4= =5OU3 -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Sep__5_01_28_43_2004_636)---- From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 16:56:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E433116A4CF; Sat, 4 Sep 2004 16:56:22 +0000 (GMT) Received: from ganymede.hub.org (blk-222-46-91.eastlink.ca [24.222.46.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FC6943D2F; Sat, 4 Sep 2004 16:56:22 +0000 (GMT) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id A205D3964B; Sat, 4 Sep 2004 13:32:50 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id A0EA6395FF; Sat, 4 Sep 2004 13:32:50 -0300 (ADT) Date: Sat, 4 Sep 2004 13:32:50 -0300 (ADT) From: "Marc G. Fournier" To: Don Lewis In-Reply-To: <200409040659.i846x4nM031021@gw.catspoiler.org> Message-ID: <20040904133128.I812@ganymede.hub.org> References: <200409040659.i846x4nM031021@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: freebsd-current@FreeBSD.org Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 16:56:23 -0000 On Fri, 3 Sep 2004, Don Lewis wrote: > On 4 Sep, Marc G. Fournier wrote: >> On Fri, 3 Sep 2004, Don Lewis wrote: > >>> Would the file system in question happen to be full of UNREF files that >>> fsck is deleting? >> >> mostly 'ZERO LENGTH DIRECTORY' ... > > Hmn, this may be something else then, possibly the buffer lookup in > getdatablk(). It would be very interesting to compile/link a profiled > version of fsck and see what shows up as the hot spot. Are you using > the default value for MAXBUFSPACE (defined in fsck.h). Everything *should* be default ... I've never modified fsck.h myself, but do have a -D flag set in /etc/make.conf to increase KMEM_SIZE so that we're able to increase our # of vnodes, so unless it somehow uses that to change teh default value ... ? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 16:56:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED15F16A4D1; Sat, 4 Sep 2004 16:56:22 +0000 (GMT) Received: from ganymede.hub.org (blk-222-46-91.eastlink.ca [24.222.46.91]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1E0443D31; Sat, 4 Sep 2004 16:56:22 +0000 (GMT) (envelope-from scrappy@hub.org) Received: by ganymede.hub.org (Postfix, from userid 1000) id 55A8D38608; Sat, 4 Sep 2004 13:29:50 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 51F6F33C8A; Sat, 4 Sep 2004 13:29:50 -0300 (ADT) Date: Sat, 4 Sep 2004 13:29:50 -0300 (ADT) From: "Marc G. Fournier" To: Julian Elischer In-Reply-To: <41394D0B.1050004@elischer.org> Message-ID: <20040904131131.A812@ganymede.hub.org> References: <20040901151405.G47186@ganymede.hub.org> <20040901200257.GA92717@afields.ca><41365746.2030605@samsco.org> <20040902013534.GD9327@afields.ca> <20040901224632.O72978@ganymede.hub.org> <20040904004706.O812@ganymede.hub.org> <41394D0B.1050004@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed cc: Allan Fields cc: freebsd-stable@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: vnode leak in FFS code ... ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 16:56:23 -0000 On Fri, 3 Sep 2004, Julian Elischer wrote: > Marc G. Fournier wrote: >> >> Just as a followup to this ... the server crashed on Thursday night around >> 22:00ADT, only just came back up after a very long fsck ... with all 62 VMs >> started up, and 1008 processes running, vnodes currently look like: > > are you using nullfs at all on your vms? No, I stop'd using that over a year ago, figuring that it was exasperating the problems we were having back then ... the only thing we did use nullfs at that time was so that we could 'identify' which files were specific to a VM, vs a file on the template ... we moved to using nfs to do the same thing ... The only thing we use is unionfs, and nfs ... Basically, we do a 'mount_union -b null: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface pci_open(1): mode 1 addr port (0x0cf8) is 0x80000094 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=25608086) pcibios: BIOS version 2.10 Found $PIR table, 9 entries at 0xc00f5320 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 29 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 B 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 D 0x6b 3 4 5 6 7 9 10 11 12 14 15 embedded 0 31 A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 31 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 1 8 A 0x68 3 4 5 6 7 9 10 11 12 14 15 embedded 0 1 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 1 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 2 A 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 1 1 0 A 0x69 3 4 5 6 7 9 10 11 12 14 15 slot 1 1 0 B 0x6a 3 4 5 6 7 9 10 11 12 14 15 slot 1 1 0 C 0x6b 3 4 5 6 7 9 10 11 12 14 15 slot 1 1 0 D 0x68 3 4 5 6 7 9 10 11 12 14 15 slot 2 1 1 A 0x6a 3 4 5 6 7 9 10 11 12 14 15 slot 2 1 1 B 0x69 3 4 5 6 7 9 10 11 12 14 15 slot 2 1 1 C 0x68 3 4 5 6 7 9 10 11 12 14 15 slot 2 1 1 D 0x6b 3 4 5 6 7 9 10 11 12 14 15 slot 3 1 2 A 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 3 1 2 B 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 3 1 2 C 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 3 1 2 D 0x60 3 4 5 6 7 9 10 11 12 14 15 slot 4 1 3 A 0x63 3 4 5 6 7 9 10 11 12 14 15 slot 4 1 3 B 0x62 3 4 5 6 7 9 10 11 12 14 15 slot 4 1 3 C 0x69 3 4 5 6 7 9 10 11 12 14 15 slot 4 1 3 D 0x6a 3 4 5 6 7 9 10 11 12 14 15 pcib0: pcibus 0 on motherboard pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base f8000000, size 26, enabled found-> vendor=0x8086, dev=0x2560, revid=0x01 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 3, range 32, base f0000000, size 27, enabled map[14]: type 1, range 32, base ffa80000, size 19, enabled pcib0: slot 2 INTA routed to irq 16 found-> vendor=0x8086, dev=0x2562, revid=0x01 bus=0, slot=2, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 1 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000e800, size 5, enabled pcib0: slot 29 INTA routed to irq 16 found-> vendor=0x8086, dev=0x24c2, revid=0x01 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 map[20]: type 4, range 32, base 0000e880, size 5, enabled pcib0: slot 29 INTB routed to irq 19 found-> vendor=0x8086, dev=0x24c4, revid=0x01 bus=0, slot=29, func=1 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=19 map[20]: type 4, range 32, base 0000ec00, size 5, enabled pcib0: slot 29 INTC routed to irq 18 found-> vendor=0x8086, dev=0x24c7, revid=0x01 bus=0, slot=29, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=18 map[10]: type 1, range 32, base ffa7fc00, size 10, enabled pcib0: slot 29 INTD routed to irq 23 found-> vendor=0x8086, dev=0x24cd, revid=0x01 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=23 powerspec 2 supports D0 D3 current D0 found-> vendor=0x8086, dev=0x244e, revid=0x81 bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x8080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x02 (500 ns) found-> vendor=0x8086, dev=0x24c0, revid=0x01 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x010f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000ffa0, size 4, enabled found-> vendor=0x8086, dev=0x24cb, revid=0x01 bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type 4, range 32, base 0000e000, size 5, enabled pcib0: slot 31 INTB routed to irq 17 found-> vendor=0x8086, dev=0x24c3, revid=0x01 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=17 map[10]: type 4, range 32, base 0000e400, size 8, enabled map[14]: type 4, range 32, base 0000e080, size 6, enabled map[18]: type 1, range 32, base ffa7f800, size 9, enabled map[1c]: type 1, range 32, base ffa7f400, size 8, enabled pcib0: slot 31 INTB routed to irq 17 found-> vendor=0x8086, dev=0x24c5, revid=0x01 bus=0, slot=31, func=5 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=17 powerspec 2 supports D0 D3 current D0 agp0: mem 0xffa80000-0xffafffff,0xf0000000-0xf7ffffff irq 16 at device 2.0 on pci0 agp0: Reserved 0x8000000 bytes for rid 0x10 type 3 at 0xf0000000 agp0: Reserved 0x80000 bytes for rid 0x14 type 3 at 0xffa80000 agp0: detected 892k stolen memory agp0: aperture size is 128M uhci0: port 0xe800-0xe81f irq 16 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe800 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0xe880-0xe89f irq 19 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xe880 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xec00-0xec1f irq 18 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xec00 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered pci0: at device 29.7 (no driver attached) pcib1: at device 30.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 2 pcib1: I/O decode 0xc000-0xdfff pcib1: memory decode 0xff500000-0xff8fffff pcib1: prefetched decode 0xe6900000-0xe6afffff pcib1: Subtractively decoded bridge. pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x1011, dev=0x0024, revid=0x03 bus=1, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x03 (750 ns), maxlat=0x02 (500 ns) map[10]: type 1, range 32, base ff8ff000, size 12, enabled pcib1: device (null) requested decoded memory range 0xff8ff000-0xff8fffff map[14]: type 4, range 32, base 0000dc00, size 6, enabled pcib1: device (null) requested decoded I/O range 0xdc00-0xdc3f pcib1: slot 8 INTA routed to irq 20 found-> vendor=0x8086, dev=0x1039, revid=0x81 bus=1, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=20 powerspec 2 supports D0 D1 D2 D3 current D0 pcib2: at device 1.0 on pci1 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xc000-0xcfff pcib2: memory decode 0xff500000-0xff7fffff pcib2: prefetched decode 0xe6900000-0xe69fffff pci2: on pcib2 pci2: physical bus=2 map[10]: type 4, range 32, base 0000cc00, size 7, enabled pcib2: device (null) requested decoded I/O range 0xcc00-0xcc7f pcib1: device (null) requested decoded I/O range 0xcc00-0xcc7f map[14]: type 1, range 32, base ff7ffc00, size 10, enabled pcib2: device (null) requested decoded memory range 0xff7ffc00-0xff7fffff pcib1: device (null) requested decoded memory range 0xff7ffc00-0xff7fffff pcib2: slot 4 INTA routed to irq 22 found-> vendor=0x1011, dev=0x0019, revid=0x41 bus=2, slot=4, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0280, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x14 (5000 ns), maxlat=0x28 (10000 ns) intpin=a, irq=22 map[10]: type 4, range 32, base 0000c880, size 7, enabled pcib2: device (null) requested decoded I/O range 0xc880-0xc8ff pcib1: device (null) requested decoded I/O range 0xc880-0xc8ff map[14]: type 1, range 32, base ff7ff800, size 10, enabled pcib2: device (null) requested decoded memory range 0xff7ff800-0xff7ffbff pcib1: device (null) requested decoded memory range 0xff7ff800-0xff7ffbff pcib2: slot 5 INTA routed to irq 21 found-> vendor=0x1011, dev=0x0019, revid=0x41 bus=2, slot=5, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0280, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x14 (5000 ns), maxlat=0x28 (10000 ns) intpin=a, irq=21 map[10]: type 4, range 32, base 0000c800, size 7, enabled pcib2: device (null) requested decoded I/O range 0xc800-0xc87f pcib1: device (null) requested decoded I/O range 0xc800-0xc87f map[14]: type 1, range 32, base ff7ff400, size 10, enabled pcib2: device (null) requested decoded memory range 0xff7ff400-0xff7ff7ff pcib1: device (null) requested decoded memory range 0xff7ff400-0xff7ff7ff pcib2: slot 6 INTA routed to irq 20 found-> vendor=0x1011, dev=0x0019, revid=0x41 bus=2, slot=6, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0280, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x14 (5000 ns), maxlat=0x28 (10000 ns) intpin=a, irq=20 map[10]: type 4, range 32, base 0000c480, size 7, enabled pcib2: device (null) requested decoded I/O range 0xc480-0xc4ff pcib1: device (null) requested decoded I/O range 0xc480-0xc4ff map[14]: type 1, range 32, base ff7ff000, size 10, enabled pcib2: device (null) requested decoded memory range 0xff7ff000-0xff7ff3ff pcib1: device (null) requested decoded memory range 0xff7ff000-0xff7ff3ff pcib2: slot 7 INTA routed to irq 23 found-> vendor=0x1011, dev=0x0019, revid=0x41 bus=2, slot=7, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0280, cachelnsz=16 (dwords) lattimer=0x20 (960 ns), mingnt=0x14 (5000 ns), maxlat=0x28 (10000 ns) intpin=a, irq=23 dc0: port 0xcc00-0xcc7f mem 0xff7ffc00-0xff7fffff irq 22 at device 4.0 on pci2 dc0: Reserved 0x80 bytes for rid 0x10 type 4 at 0xcc00 miibus0: on dc0 ukphy0: on miibus0 ukphy0: OUI 0x080017, model 0x0001, rev. 0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: bpf attached dc0: Ethernet address: 00:80:c8:ca:50:d1 dc0: [GIANT-LOCKED] dc1: port 0xc880-0xc8ff mem 0xff7ff800-0xff7ffbff irq 21 at device 5.0 on pci2 dc1: Reserved 0x80 bytes for rid 0x10 type 4 at 0xc880 miibus1: on dc1 ukphy1: on miibus1 ukphy1: OUI 0x080017, model 0x0001, rev. 0 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc1: bpf attached dc1: Ethernet address: 00:80:c8:ca:50:d2 dc1: [GIANT-LOCKED] dc2: port 0xc800-0xc87f mem 0xff7ff400-0xff7ff7ff irq 20 at device 6.0 on pci2 dc2: Reserved 0x80 bytes for rid 0x10 type 4 at 0xc800 miibus2: on dc2 ukphy2: on miibus2 ukphy2: OUI 0x080017, model 0x0001, rev. 0 ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc2: bpf attached dc2: Ethernet address: 00:80:c8:ca:50:d3 dc2: [GIANT-LOCKED] dc3: port 0xc480-0xc4ff mem 0xff7ff000-0xff7ff3ff irq 23 at device 7.0 on pci2 dc3: Reserved 0x80 bytes for rid 0x10 type 4 at 0xc480 miibus3: on dc3 ukphy3: on miibus3 ukphy3: OUI 0x080017, model 0x0001, rev. 0 ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc3: bpf attached dc3: Ethernet address: 00:80:c8:ca:50:d4 dc3: [GIANT-LOCKED] fxp0: port 0xdc00-0xdc3f mem 0xff8ff000-0xff8fffff irq 20 at device 8.0 on pci1 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xff8ff000 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1039 8086 3048 0081 fxp0: Dynamic Standby mode is disabled miibus4: on fxp0 inphy0: on miibus4 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:11:11:25:ee:10 fxp0: [GIANT-LOCKED] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: channel #1 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=00 ostat0=ff ostat1=ff ata1: [MPSAFE] pci0: at device 31.3 (no driver attached) pci0: at device 31.5 (no driver attached) cpu0 on motherboard pnpbios: 16 devices, largest 298 bytes PNP0c01: adding fixed memory32 range 0-0x9fbff, size=0x9fc00 PNP0c01: adding fixed memory32 range 0x9fc00-0x9ffff, size=0x400 PNP0c01: adding fixed memory32 range 0xe0000-0xfffff, size=0x20000 PNP0c01: adding fixed memory32 range 0x100000-0x7e3ffff, size=0x7d40000 PNP0c01: adding fixed memory32 range 0x7e40000-0x7e4ffff, size=0x10000 PNP0c01: adding fixed memory32 range 0x7e50000-0x7efffff, size=0xb0000 pnpbios: handle 0 device ID PNP0c01 (010cd041) PNP0200: adding dma mask 0x10 PNP0200: adding io range 0-0xf, size=0x10, align=0x1 PNP0200: adding io range 0x80-0x90, size=0x11, align=0x1 PNP0200: adding io range 0x94-0x9f, size=0xc, align=0x1 PNP0200: adding io range 0xc0-0xde, size=0x1f, align=0x1 pnpbios: handle 2 device ID PNP0200 (0002d041) PNP0100: adding irq mask 0x1 PNP0100: adding io range 0x40-0x43, size=0x4, align=0x1 pnpbios: handle 3 device ID PNP0100 (0001d041) PNP0b00: adding irq mask 0x100 PNP0b00: adding io range 0x70-0x71, size=0x2, align=0x1 pnpbios: handle 4 device ID PNP0b00 (000bd041) pnpbios: handle 5 device ID PNP0a03 (030ad041) PNP0800: adding io range 0x61-0x61, size=0x1, align=0x1 pnpbios: handle 6 device ID PNP0800 (0008d041) PNP0c04: adding irq mask 0x2000 PNP0c04: adding io range 0xf0-0xff, size=0x10, align=0x1 pnpbios: handle 7 device ID PNP0c04 (040cd041) PNP0501: adding io range 0x3f8-0x3ff, size=0x8, align=0x8 PNP0501: adding irq mask 0x10 pnpbios: handle 8 device ID PNP0501 (0105d041) pnpbios: handle 9 device ID PNP0c02 (020cd041) PNP0700: adding io range 0x3f0-0x3f5, size=0x6, align=0x1 PNP0700: adding io range 0x3f7-0x3f7, size=0x1, align=0x1 PNP0700: adding irq mask 0x40 PNP0700: adding dma mask 0x4 pnpbios: handle 10 device ID PNP0700 (0007d041) PNP0401: adding io range 0x378-0x37f, size=0x8, align=0x8 PNP0401: adding io range 0x778-0x77a, size=0x3, align=0x8 PNP0401: adding irq mask 0x80 PNP0401: adding dma mask 0x8 pnpbios: handle 11 device ID PNP0401 (0104d041) PNP0c02: adding io range 0x4d0-0x4d1, size=0x2, align=0x1 PNP0c02: adding io range 0xcf8-0xcff, size=0x8, align=0x1 PNP0c02: adding io range 0x10-0x1f, size=0x10, align=0x1 PNP0c02: adding io range 0x24-0x2d, size=0xa, align=0x1 PNP0c02: adding io range 0x30-0x3d, size=0xe, align=0x1 PNP0c02: adding io range 0x50-0x53, size=0x4, align=0x1 PNP0c02: adding io range 0x72-0x77, size=0x6, align=0x1 PNP0c02: adding io range 0x91-0x93, size=0x3, align=0x1 PNP0c02: adding io range 0xa4-0xbd, size=0x1a, align=0x1 PNP0c02: adding io range 0xdf-0xdf, size=0x1, align=0x1 PNP0c02: adding io range 0x400-0x47f, size=0x80, align=0x1 PNP0c02: adding io range 0x480-0x4bf, size=0x40, align=0x1 PNP0c02: adding io range 0x2e-0x2e, size=0x1, align=0x1 PNP0c02: adding io range 0x2f-0x2f, size=0x1, align=0x1 PNP0c02: adding io range 0x680-0x6ff, size=0x80, align=0x1 pnpbios: handle 12 device ID PNP0c02 (020cd041) INT0800: adding fixed memory32 range 0xffb80000-0xffffffff, size=0x480000 pnpbios: handle 13 device ID INT0800 (0008d425) PNP0303: adding irq mask 0x2 PNP0303: adding io range 0x60-0x60, size=0x1, align=0x1 PNP0303: adding io range 0x64-0x64, size=0x1, align=0x1 pnpbios: handle 14 device ID PNP0303 (0303d041) pnpbios: handle 15 device ID PNP0c02 (020cd041) ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0065 psm0: failed to reset the aux device. bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) ppc0: parallel port found at 0x378 ppc0: using extended I/O port range ppc0: ECP SPP SPP ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fb0: vga0, vga, type:VGA (5), flags:0x7007f fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 fb0: init mode:24, bios mode:3, current mode:24 fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k VGA parameters upon power-up 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff VGA parameters in BIOS for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff EGA/VGA parameters to be used for mode 24 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff vt0: not probed (disabled) isa_probe_children: probing PnP devices unknown: failed to probe at port 0x61 on isa0 unknown: can't assign resources (port) unknown: at port 0x3f8-0x3ff on isa0 unknown: can't assign resources (port) unknown: at port 0x3f0-0x3f5 on isa0 unknown: can't assign resources (port) unknown: at port 0x378-0x37f on isa0 unknown: failed to probe at iomem 0xffb80000-0xffffffff on isa0 unknown: can't assign resources (port) unknown: at port 0x60 on isa0 Device configuration finished. procfs registered Timecounter "TSC" frequency 1599828576 Hz quality 800 Timecounters tick every 10.000 msec ipfw2 initialized, divert enabled, rule-based forwarding disabled, default to accept, logging limited to 100 packets/entry by default lo0: bpf attached ata0-master: pio=0x0c wdma=0x22 udma=0xffffffff cable=40pin ata0-master: setting PIO4 on Intel ICH4 chip ata0-master: setting WDMA2 on Intel ICH4 chip ad0: ATA-3 disk at ata0-master ad0: 5006MB (10253928 sectors), 10850 C, 15 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, WDMA2 GEOM: new disk ad0 ar: FreeBSD check1 failed ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ioapic0: routing intpin 4 (ISA IRQ 4) to cluster 0 ioapic0: routing intpin 6 (ISA IRQ 6) to cluster 0 ioapic0: routing intpin 7 (ISA IRQ 7) to cluster 0 ioapic0: routing intpin 8 (ISA IRQ 8) to cluster 0 ioapic0: routing intpin 13 (ISA IRQ 13) to cluster 0 ioapic0: routing intpin 14 (ISA IRQ 14) to cluster 0 ioapic0: routing intpin 15 (ISA IRQ 15) to cluster 0 ioapic0: routing intpin 16 (PCI IRQ 16) to cluster 0 ioapic0: routing intpin 18 (PCI IRQ 18) to cluster 0 ioapic0: routing intpin 19 (PCI IRQ 19) to cluster 0 ioapic0: routing intpin 20 (PCI IRQ 20) to cluster 0 ioapic0: routing intpin 21 (PCI IRQ 21) to cluster 0 ioapic0: routing intpin 22 (PCI IRQ 22) to cluster 0 ioapic0: routing intpin 23 (PCI IRQ 23) to cluster 0 [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/14/63 s:63 l:10253187 [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 GEOM: Configure ad0s1, start 32256 length 5249631744 end 5249663999 GEOM: Configure ad0s1a, start 0 length 268435456 end 268435455 GEOM: Configure ad0s1b, start 268435456 length 268435456 end 536870911 GEOM: Configure ad0s1c, start 0 length 5249631744 end 5249631743 GEOM: Configure ad0s1d, start 536870912 length 471859200 end 1008730111 GEOM: Configure ad0s1e, start 1008730112 length 4240901632 end 5249631743 Mounting root from ufs:/dev/ad0s1a start_init: trying /sbin/init ----- >How-To-Repeat: The host have to upstream interfaces to ISP, three internal networks with two interfaces (two internal networks are aliased in one inteface). The default route is to the first provider. We use policy routing to route our third network to second provider. $inet1 and $inet2 are aliases on one interface. After adding ipfw rule: # ipfw add fwd $provider2 ip from $inet3 to { not $inet1 or not $inet2 } gateway paniced. I know, that in fact the rule has to be "not $inet1,$inet2". But logically the first rule has the value "all". OS must not trap. >Fix: Don't know. From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 19:36:21 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1EE516A4CE for ; Sat, 4 Sep 2004 19:36:21 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4812343D1D for ; Sat, 4 Sep 2004 19:36:21 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i84JXTti093737; Sat, 4 Sep 2004 15:33:29 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i84JXSLY093734; Sat, 4 Sep 2004 15:33:29 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 4 Sep 2004 15:33:28 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Jan Srzednicki In-Reply-To: <20040904192218.GA5879@miranda.expro.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org Subject: Re: syscons problem in ddb, if_afdata initialization (was: Re: 5.3-BETA3 , panic, probably IPv6+SMP+mpsafenet related) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 19:36:21 -0000 On Sat, 4 Sep 2004, Jan Srzednicki wrote: > OK. I'm not sure if I'm doing that the right way, but here it is: Yes, this was exactly what I was looking for. Thanks! > Hope this helps. > > It's also worth noting that on the previous kernel (that is: FreeBSD > 5.3-BETA2 (SIN) #9: Sun Aug 29 14:24:19 CEST 2004) nothing like that > happened, so it appears to be somehow related to (or uncovered by) some > very recent commit. Could you try this patch: Index: nd6.c =================================================================== RCS file: /home/ncvs/src/sys/netinet6/nd6.c,v retrieving revision 1.44 diff -u -r1.44 nd6.c --- nd6.c 23 Aug 2004 03:00:27 -0000 1.44 +++ nd6.c 4 Sep 2004 19:34:39 -0000 @@ -134,6 +134,7 @@ nd6_init_done = 1; /* start timer */ + callout_init(&nd6_slowtimo_ch, 0); callout_reset(&nd6_slowtimo_ch, ND6_SLOWTIMER_INTERVAL * hz, nd6_slowtimo, NULL); } Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 20:20:49 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98D3016A4CE; Sat, 4 Sep 2004 20:20:49 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AA1A43D3F; Sat, 4 Sep 2004 20:20:49 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.11/8.12.11) id i84KKXJw041272; Sat, 4 Sep 2004 15:20:33 -0500 (CDT) (envelope-from dan) Date: Sat, 4 Sep 2004 15:20:33 -0500 From: Dan Nelson To: Matthew Dillon Message-ID: <20040904202033.GC6279@dan.emsphone.com> References: <200409040709.i8479U79031043@gw.catspoiler.org> <200409041723.i84HNi4Q046252@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409041723.i84HNi4Q046252@apollo.backplane.com> X-OS: FreeBSD 5.3-BETA2 X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: Don Lewis cc: freebsd-current@freebsd.org Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 20:20:49 -0000 In the last episode (Sep 04), Matthew Dillon said: > :This sort of thing was my initial thought, but the posted CPU usage > :statistics show that fsck is burning up most of its CPU cycles in > :userland. > : > :>> load: 0.99 cmd: fsck 67 [running] 15192.26u 142.30s 99% 184284k > :Increasing MAXBUFSPACE looks like it would make the problem worse > :because getdatablk() does a linear search. > > Oh my. I didn't even notice. That code dates all the way back to > 1994 so I wont bash the author too badly, but it is pretty aweful > coding. > > Hashing the buffer cache is trivial. I'll do it for DragonFly and > post the patch as a template for you guys to do it in FreeBSD (or you > could just do it on your own, it really does look trivial). In my tests, the lookup time for the cache was basically zero, and prefetching disk blocks helped much more. This is on mainly-static filesystems under 80gb holding lots of small files (ports and other cvs tree, cvs repos, etc). The hardest part was dealing with the fact that the bp list doesn't cache disk blocks but arbitrary-sized objects, each any of which may be dirtied by a later write. If you prefech N bytes, you need to add N/objectsize separate entries to the cache. Simply instrumenting getdatablk to print the offest and size of each read, plus whether it was a cache hit, should generate all the data you need to determine what kind of optimizations are useful. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 20:31:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 42CE716A4CE; Sat, 4 Sep 2004 20:31:29 +0000 (GMT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2845243D39; Sat, 4 Sep 2004 20:31:29 +0000 (GMT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) i84KVQla047188; Sat, 4 Sep 2004 13:31:26 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i84KVQFc047187; Sat, 4 Sep 2004 13:31:26 -0700 (PDT) (envelope-from dillon) Date: Sat, 4 Sep 2004 13:31:26 -0700 (PDT) From: Matthew Dillon Message-Id: <200409042031.i84KVQFc047187@apollo.backplane.com> To: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) References: <200409041834.i84IYVrk032267@gw.catspoiler.org> cc: Don Lewis cc: freebsd-current@FreeBSD.org Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 20:31:29 -0000 : :Don Lewis writes: :> At least it moves the buffer to the front of the list so that repeated :> accesses of the same buffer are fast. : :Sounds like it's just waiting to be converted into a splay tree... : :DES :-- :Dag-Erling Smørgrav - des@des.no From what Don says it looks like we know what this particular cpu issue is... that it is related to how fsck keeps track of 0-length directories (in a linear list). Coupled with the fact that many 0-length directories wind up occuring (probably due to upper/lowervp refs from unionfs preventing the underlying fs's inode from being completely deleted) and you have a recipe for severe cpu usage in fsck. As far as splay trees go. Well, I am not particularly fond of splay trees because they do a *LOT* of disparate (not on the same RAS line) writes to memory, even when doing simple lookups. I feel that a read-only data access methodology is ultimately going to be the better choice on modern cpus. A binary or a radix tree with a one entry inner node cache ought to perform far better then a splay tree IMHO, which is why I haven't been backporting any of the splay code into DragonFly. Also, the splay algorithm is not very MP friendly. That said, the splay code in FreeBSD is certainly better then the code that it replaced. -Matt Matthew Dillon From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 20:34:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8865116A4CE for ; Sat, 4 Sep 2004 20:34:48 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 579CC43D4C for ; Sat, 4 Sep 2004 20:34:47 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id i84KYO1Y024424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Sep 2004 23:34:25 +0300 (EEST) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id i84KYNT8093908; Sat, 4 Sep 2004 23:34:23 +0300 (EEST) (envelope-from ru) Date: Sat, 4 Sep 2004 23:34:23 +0300 From: Ruslan Ermilov To: Barry Bouwsma Message-ID: <20040904203423.GI92176@ip.net.ua> References: <200408281700.i7SH0Q700992@Mail.NOSPAM.DynDNS.dK> <20040829143403.GE23120@ip.net.ua> <200409041752.i84HqqL01024@Mail.NOSPAM.DynDNS.dK> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="81JctsDUVPekGcy+" Content-Disposition: inline In-Reply-To: <200409041752.i84HqqL01024@Mail.NOSPAM.DynDNS.dK> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new cc: current@freebsd.org Subject: Re: M*K**BJD*RPR*F*X and make.conf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 20:34:48 -0000 --81JctsDUVPekGcy+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 04, 2004 at 07:52:53PM +0200, Barry Bouwsma wrote: [...] > Un(?)fortunately, I can't easily demonstrate the failure that I > wanted to prevent. It probably happens later after other failures > in my build. However, here are some interesting observations: >=20 > My FreeBSD-4 `make -d v buildworld' in 6-CURRENT source fails, > period. > "Makefile", line 92: MAKEOBJDIRPREFIX can only be set in environment, not= as a g > lobal (in /etc/make.conf) or command-line variable. > Drop the `-d v' and it doesn't bomb there. This is probably > not unexpected. ;-) It is better with a later `make' which > sends the debug output to stderr, not to stdout. >=20 Yes, the problem with RELENG_4 make(1) is that -dv sends its output to stdout, hence ``make -dv -V MAKEOBJDIRPREFIX'' is polluted. The make(1) in HEAD doesn't exhibit this problem. > The above test also does not fail when MAKEOBJDIRPREFIX is > given as command-line variable, using FreeBSD-4 `make'. >=20 Yes, because in 4.x, make(1) doesn't pass command-line variables as command-line variables to subprocesses, including other make's. > (I mean, I don't get the above warning, giving command-line > variable, and it continues with the build.) >=20 You won't get a warning with the 4.x version of make(1), because it's buggy. In 5.x and 6.x, you'll get it. I couldn't find a way to make it work with 4.x version of make(1), and setting MAKEOBJDIRPREFIX as a command line variable using the 4.x make(1), and running buildworld seems to work due to this bug in make(1) -- what happens is that the *actual* make(1) (the one that src/Makefile calls with the -f Makefile.inc1 argument) sees the MAKEOBJDIRPREFIX as an environment variable, which is what the make(1) expects. This explains why it happened to work for many people who passed it as a command-line variable before make(1) was fixed. > Anyway, what I try to demonstrate is setting MAKEOBJDIRPREFIX > in __MAKE_CONF. >=20 This is pointless. MAKEOBJDIRPREFIX is an environment variable, here's the code from make(1): $ grep -C3 MAKEOBJDIRPREFIX *.c main.c- * The object directory location is determined using the main.c- * following order of preference: main.c- * main.c: * 1. MAKEOBJDIRPREFIX`cwd` main.c- * 2. MAKEOBJDIR main.c- * 3. _PATH_OBJDIR.${MACHINE} main.c- * 4. _PATH_OBJDIR -- main.c- * and modify the paths for the Makefiles apropriately. The main.c- * current directory is also placed as a variable for make scripts. main.c- */ main.c: if (!(pathp =3D getenv("MAKEOBJDIRPREFIX"))) { main.c- if (!(path =3D getenv("MAKEOBJDIR"))) { main.c- path =3D _PATH_OBJDIR; main.c- pathp =3D _PATH_OBJDIRPREFIX; > This avoids the check in the -current Makefile > and in releng_5 Makefile.inc (which was the reason for my > previous patch-like thing). >=20 > [00:22:41]beer@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:~{1063}$ grep MAK= EOBJ /etc/make.conf > # MAKEOBJDIRPREFIX?=3D /usr/obj/${RELNAME} > ## Let's break the build elsewhere... MAKEOBJDIRPREFIX?=3D /usr/ob= j/${RELNAME} >=20 > [00:22:59]beer@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:~{1064}$ grep -v = ^# /dist/build/build-freebsd-current > MOUNT=3D`/sbin/mount -t union` > UNION=3D`echo $MOUNT | /usr/bin/egrep ":.*/src/FreeBSD6-src/source= -hacks on .*/src/FreeBSD6-src/src \(union,"` > if [ $? -ne 0 ] ; then > echo > echo "Must union-mount source-hacks before building..." > echo > exit 68 > fi > ( cd `dirname $0`/../src/FreeBSD6-src/src && time env TARGET_ARCH= =3Di386 __MAKE_CONF=3D`dirname $0`/../conf/current/make.conf make -DNOCL= EAN buildworld ) >=20 > [00:23:04]beer@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:~{1065}$ time nic= e -20 sh !$ > -------------------------------------------------------------- > >>> Building an up-to-date make(1) > -------------------------------------------------------------- > mkdir: /usr/obj/dist: Read-only file system > *** Error code 1 > Stop in /dist/src/FreeBSD6-src/src/usr.bin/make. >=20 > [ ... ] >=20 > [00:34:48]beer@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:~{1071}$ grep MAK= EO /dist/conf/current/make.conf > # MAKEOBJDIRPREFIX?=3D /usr/obj/${RELNAME} > MAKEOBJDIRPREFIX=3D /dist/obj/${RELNAME} >=20 This happens with 4.x make(1) because buildworld depends on a new make binary, and this new make binary cannot be built (due to MAKEOBJDIRPREFIX hardcoded by setting it as a global variable in a file pointed to by __MAKE_CONF. If you try it with 5.x make(1), it will fail as expected, later: $ grep MAKEOBJDIRPREFIX /etc/make.conf /usr/src/make.conf /usr/src/make.conf:MAKEOBJDIRPREFIX=3D/foo $ make __MAKE_CONF=3D/usr/src/make.conf buildworld "/usr/src/Makefile", line 92: MAKEOBJDIRPREFIX can only be set in environme= nt, not as a global (in /etc/make.conf) or command-line variable. > Ah, well. If I specify a MAKEOBJDIRPREFIX on the command-line, > it also passes by the test. YES I KNOW I'M NOT SUPPOSED TO DO > THIS. Just like I'm not supposed to do the above. I'm deliberately > avoiding setting the environment, for the sake of science. >=20 With 4.x make(1), yes. Like has been said already, it doesn't pass command-line variables as command-line variables to subprocesses, only passes them as environment variables -- and that's what real make(1) expects -- it find the MAKEOBJDIRPREFIX as an environment variable. Here's the picture for the old make: "make buildworld MAKEOBJDIRPREFIX=3D/foo" =2E.. src/Makefile calls "env MAKEOBJDIRPREFIX=3D/foo make -f Makefile.inc1 buildworld" =2E.. Makefile.inc1 then redefines the environment variable MAKEOBJDIRPREFIX as necessary, for difference stages of buildworld. For the current make(1), the picture is as follows: "make buildworld MAKEOBJDIRPREFIX=3D/foo" =2E.. src/Makefile calls "env MAKEOBJDIRPREFIX=3D/foo make -f Makefile.inc1 buildworld MAKEOBJDIRPRE= FIX=3D/foo" =2E.. Makefile.inc1 then redefines the environment variable MAKEOBJDIRPREFIX as necessary, but this doesn't take the desired effect because command-line variable overrides the environment variable. Is that clear enough now? > My point is that I don't have MAKEOBJDIRPREFIX in /etc/make.conf > but instead in __MAKE_CONF, yet the build goes ahead... >=20 Try with the current make(1). > the following in Makefile which helps when I've given __MAKE_CONF: >=20 > _MAKEOBJDIRPREFIX!=3D env -i PATH=3D${PATH} __MAKE_CONF=3D${__MAKE_CONF} \ > MAKEFLAGS=3D"${.MAKEFLAGS}" ${MAKE} \ > -m ${.CURDIR}/share/mk -f /dev/null -V MAKEOBJDIRPREFIX = dummy >=20 > With this, I can no longer build: > [03:54:13]beer@NOSPAM.spam.NOSPAM.spam.NOSPAM.dyndns.dk:/dist/src/FreeBSD= 6-src/ > src{1212}$ time nice env TARGET_ARCH=3Di386 __MAKE_CONF=3D/dist/conf/cur= rent/make. > conf make -DNOCLEAN buildworld > "Makefile", line 93: MAKEOBJDIRPREFIX /dist/obj/4.10-STABLE can only be= set in > environment, not as a global (in /etc/make.conf) or command-line variabl= e. >=20 > This is what you want. Believe me. Still, I'm not sure if it > is safe to use `-m' here, although it does work with my 4.x. >=20 No, it's unsafe. The old make(1) may be incompatible with the current contents of src/share/mk. > (Hm, is it safe to use ${MAKE} here, seeing that later in the > makefile one `make make's to build an up-to-date, probably for > the case where `make' doesn't set `${MAKE}'... Ignore me.) >=20 Yes, it's safe. ${MAKE} expands to argv[0]. When you later call /foo/bar/make, that make's ${MAKE} becomes /foo/bar/make. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --81JctsDUVPekGcy+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBOibPqRfpzJluFF4RAlIsAKCc/kxrHrIFpYnsf9Utw771NQV42gCfd+XC s0lK0iNepgCiq8hmuJUCrYE= =oNns -----END PGP SIGNATURE----- --81JctsDUVPekGcy+-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 21:22:29 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73F9216A4CE for ; Sat, 4 Sep 2004 21:22:29 +0000 (GMT) Received: from kientzle.com (h-66-166-149-50.snvacaid.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03DC443D39 for ; Sat, 4 Sep 2004 21:22:29 +0000 (GMT) (envelope-from kientzle@freebsd.org) Received: from freebsd.org (p54.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id i84LMP90083418; Sat, 4 Sep 2004 14:22:25 -0700 (PDT) (envelope-from kientzle@freebsd.org) Message-ID: <413A3211.7040506@freebsd.org> Date: Sat, 04 Sep 2004 14:22:25 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4) Gecko/20031006 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Will Froning References: <20040903165214.W8095@angui.sh> <41392082.3010204@freebsd.org> In-Reply-To: <41392082.3010204@freebsd.org> Content-Type: multipart/mixed; boundary="------------030102020109050001060900" cc: freebsd-current@freebsd.org Subject: Re: bsdtar breakage on 5.3-BETA2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 21:22:29 -0000 This is a multi-part message in MIME format. --------------030102020109050001060900 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Will Froning wrote: > > On a FBSD4.10 box I have created a tar file of a users home directory > and then copied it over to a 5.3-BETA2 box (MD5 checksums match). > > [ ... file with long name gets reported as a dir instead of regular file ....] > Good catch! The code for handling certain very old tar archives was getting confused by the long filename extensions. The attached patch fixes it for me. If you have a chance, apply it to src/lib/libarchive and then rebuild both libarchive and src/usr.bin/tar and let me know if this fixes it for you as well. Tim --------------030102020109050001060900 Content-Type: text/plain; name="libarchive-archive_read_support_format_tar.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="libarchive-archive_read_support_format_tar.c.diff" --- libarchive-current/archive_read_support_format_tar.c Wed Aug 25 20:25:58 2004 +++ libarchive/archive_read_support_format_tar.c Sat Sep 4 13:59:40 2004 @@ -351,12 +351,33 @@ { struct stat st; struct tar *tar; + const char *p; + int r; + size_t l; memset(&st, 0, sizeof(st)); tar = *(a->pformat_data); tar->entry_offset = 0; - return (tar_read_header(a, tar, entry, &st)); + r = tar_read_header(a, tar, entry, &st); + + if (r == ARCHIVE_OK) { + /* + * "Regular" entry with trailing '/' is really + * directory: This is needed for certain old tar + * variants and even for some broken newer ones. + */ + p = archive_entry_pathname(entry); + l = strlen(p); + if (S_ISREG(st.st_mode) && p[l-1] == '/') { + st.st_mode &= ~S_IFMT; + st.st_mode |= S_IFDIR; + } + + /* Copy the final stat data into the entry. */ + archive_entry_copy_stat(entry, &st); + } + return (r); } static int @@ -421,8 +442,6 @@ ssize_t bytes; int err; const void *h; - const char *p; - size_t l; const struct archive_entry_header_ustar *header; /* Read 512-byte header record */ @@ -513,17 +532,9 @@ a->archive_format_name = "tar (non-POSIX)"; err = header_old_tar(a, tar, entry, st, h); } - - /* "Regular" entry with trailing '/' is really directory. */ - p = archive_entry_pathname(entry); - l = strlen(p); - if (S_ISREG(st->st_mode) && p[l-1] == '/') { - st->st_mode &= ~S_IFMT; - st->st_mode |= S_IFDIR; - } } - archive_entry_copy_stat(entry, st); --tar->header_recursion_depth; + return (err); } --------------030102020109050001060900-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 22:18:23 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1990716A4CE for ; Sat, 4 Sep 2004 22:18:23 +0000 (GMT) Received: from alogis.com (firewall2.alogis.com [62.8.223.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE07443D1D for ; Sat, 4 Sep 2004 22:18:21 +0000 (GMT) (envelope-from Holger.Kipp@alogis.com) Received: (from hk@localhost) by alogis.com (8.11.1/8.9.3) id i84MIKi47349 for freebsd-current@freebsd.org; Sun, 5 Sep 2004 00:18:20 +0200 (CEST) (envelope-from hk) Date: Sun, 5 Sep 2004 00:18:20 +0200 From: Holger Kipp To: freebsd-current@freebsd.org Message-ID: <20040905001820.A47048@intserv.int1.b.intern> References: <20040829213449.GA33843@hub.freebsd.org> <20040830135311.11040.qmail@web50603.mail.yahoo.com> <20040830163106.GA19044@dragon.nuxi.com> <20040830210817.GB749@galgenberg.net> <20040831195329.GB21995@odin.ac.hmc.edu> <2F14AAB9-FB8B-11D8-B6F3-003065A20588@mac.com> <1093986646.4466.8.camel@amon.quaggaspace.org> <20040903142432.GA27464@SDF.LONESTAR.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20040903142432.GA27464@SDF.LONESTAR.ORG>; at 10:24:32AM -0400 Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 22:18:23 -0000 On Fri, Sep 03, 2004 at 10:24:32AM -0400, Kevin A. Pieckiel wrote: > On Tue, Aug 31, 2004 at 05:10:47PM -0400, Justin Settle wrote: > > Anyway, I'd thought I'd just say your patch is working very well here > > for me. I've gone with "f" and "j" as that makes far more sense to me. > > Use pointer finger to point which one I want and all of that. > > I'm totally surprised nobody's mentioned using arrow keys instead of > letters. Use the left arrow key for the left side of the screen and > the right arrow key for the right side of the screen. THAT makes > perfect sense IMO. Arrow keys are not a very good idea (tm) if you have a slow network or other network problems. You don't want to use them. Especially if you have to update a system remotely. Regards, Holger Kipp From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 23:42:38 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09E0416A4CE for ; Sat, 4 Sep 2004 23:42:38 +0000 (GMT) Received: from saltmine.radix.net (saltmine.radix.net [207.192.128.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB81643D2F for ; Sat, 4 Sep 2004 23:42:37 +0000 (GMT) (envelope-from dickey@saltmine.radix.net) Received: from saltmine.radix.net (localhost [127.0.0.1]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id i84NgabC016753 for ; Sat, 4 Sep 2004 19:42:36 -0400 (EDT) Received: (from dickey@localhost) by saltmine.radix.net (8.12.2/8.12.2/Submit) id i84NgafX016748 for freebsd-current@freebsd.org; Sat, 4 Sep 2004 19:42:36 -0400 (EDT) Date: Sat, 4 Sep 2004 19:42:36 -0400 From: Thomas Dickey To: freebsd-current@freebsd.org Message-ID: <20040904234235.GA16258@saltmine.radix.net> References: <20040830135311.11040.qmail@web50603.mail.yahoo.com> <20040830163106.GA19044@dragon.nuxi.com> <20040830210817.GB749@galgenberg.net> <20040831195329.GB21995@odin.ac.hmc.edu> <2F14AAB9-FB8B-11D8-B6F3-003065A20588@mac.com> <1093986646.4466.8.camel@amon.quaggaspace.org> <20040903142432.GA27464@SDF.LONESTAR.ORG> <20040905001820.A47048@intserv.int1.b.intern> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: <20040905001820.A47048@intserv.int1.b.intern> User-Agent: Mutt/1.3.27i Subject: Re: suggestion for /usr/src/UPDATING X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 04 Sep 2004 23:42:38 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Sep 05, 2004 at 12:18:20AM +0200, Holger Kipp wrote: =20 > Arrow keys are not a very good idea (tm) if you have a slow network or > other network problems. You don't want to use them. Especially if you > have to update a system remotely. If you're concerned about that, using printable characters as controls is not much of an improvement, since you can still get interesting problems with typeahead. Using control keys helps in that regard. --=20 Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQFBOlLdtIqByHxlDocRAjeBAJ9sMEo2H7wxtCJuZCoWdTjAchYH+gCfUvGI 5guEd60hAKDB0jzAmKmv4+I= =BttQ -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 23:57:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F26E16A507 for ; Sat, 4 Sep 2004 23:56:58 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id E761043D2D for ; Sat, 4 Sep 2004 23:56:57 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 3285 invoked from network); 4 Sep 2004 23:56:57 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail3.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 4 Sep 2004 23:56:57 -0000 Received: from hydrogen.funkthat.com (cncvkb@localhost.funkthat.com [127.0.0.1])i84NuuuU048876; Sat, 4 Sep 2004 16:56:57 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id i84Nuti5048875; Sat, 4 Sep 2004 16:56:55 -0700 (PDT) Date: Sat, 4 Sep 2004 16:56:55 -0700 From: John-Mark Gurney To: Daniel Eriksson Message-ID: <20040904235655.GO29902@funkthat.com> Mail-Followup-To: Daniel Eriksson , freebsd-current@freebsd.org References: <20040825175250.GO29902@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-current@freebsd.org Subject: Re: if_re locking patch... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2004 23:57:01 -0000 Daniel Eriksson wrote this message on Sat, Sep 04, 2004 at 12:33 +0200: > John-Mark Gurney wrote: > > > To expand upon the patch posted previously, I have cribbed bms's rl > > locking, and ported it to re. This makes the interrupt MPSAFE along > > with the rest of the driver. No more GIANT LOCKED messages for re. :) > > I saw that this was committed to HEAD yesterday. I have a machine with a > 8169-based NIC that is doing ~300GB on a daily basis that I'd love to try to > run with debug.mpsafenet=1. Do you think the patch that went into HEAD has > been tested enough that it is safe to try it? > > It's a UP machine using POLLING mode (HZ=2000), if that makes any > difference. Well, as demonstrated by ru's commit (thanks ru!).. I had not tested DEVICE_POLLING... But this afternoon I did some testing, and did not have any troubles... The only problems w/ netperf was that the *RR* tests were a bit slow, but this is to be expected due to DEVICE_POLLING.. But as I mentioned, the re driver was originally based on the rl, so I doubt there'll be much trouble since rl's locking has been in the tree for quite a while longer... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."