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