From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 00:43:32 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7E6116A4CE; Sun, 9 Jan 2005 00:43:32 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75EB943D2D; Sun, 9 Jan 2005 00:43:32 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id j090hVIC088810; Sat, 8 Jan 2005 19:43:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id j090hVei062463; Sat, 8 Jan 2005 19:43:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 914C37306E; Sat, 8 Jan 2005 19:43:31 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050109004331.914C37306E@freebsd-current.sentex.ca> Date: Sat, 8 Jan 2005 19:43:31 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/640/Thu Dec 23 13:48:27 2004 clamav-milter version 0.80j on avscan2 X-Virus-Status: Clean 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, 09 Jan 2005 00:43:33 -0000 TB --- 2005-01-08 23:44:33 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-08 23:44:33 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-01-08 23:44:33 - checking out the source tree TB --- 2005-01-08 23:44:33 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-01-08 23:44:33 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-01-08 23:50:22 - building world (CFLAGS=-O2 -pipe) TB --- 2005-01-08 23:50:22 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-01-08 23:50: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 [...] cc -O2 -pipe -I/tinderbox/CURRENT/amd64/amd64/src/sbin/atm/ilmid/../../../sys -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /tinderbox/CURRENT/amd64/amd64/src/sbin/atm/ilmid/ilmid.c (cd /tinderbox/CURRENT/amd64/amd64/src/rescue/rescue/../../sbin/ping6 && /home/tinderbox/CURRENT/amd64/amd64/obj/tinderbox/CURRENT/amd64/amd64/src/make.i386/make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/ping6/ depend && /home/tinderbox/CURRENT/amd64/amd64/obj/tinderbox/CURRENT/amd64/amd64/src/make.i386/make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/ping6/ ping6.o) rm -f .depend mkdep -f .depend -a -DINET6 -DIPSEC -DKAME_SCOPEID -DUSE_RFC2292BIS -DHAVE_POLL_H -DHAVE_ARC4RANDOM -DRESCUE /tinderbox/CURRENT/amd64/amd64/src/sbin/ping6/ping6.c echo ping6: /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libc.a /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libipsec.a /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libm.a /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libmd.a >> .depend cc -O2 -pipe -DINET6 -DIPSEC -DKAME_SCOPEID -DUSE_RFC2292BIS -DHAVE_POLL_H -DHAVE_ARC4RANDOM -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /tinderbox/CURRENT/amd64/amd64/src/sbin/ping6/ping6.c /tinderbox/CURRENT/amd64/amd64/src/sbin/ping6/ping6.c: In function `pr_ip6opt': /tinderbox/CURRENT/amd64/amd64/src/sbin/ping6/ping6.c:1786: warning: passing arg 5 of `inet6_opt_next' from incompatible pointer type *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/sbin/ping6. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2005-01-09 00:43:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-01-09 00:43:31 - ERROR: failed to build world TB --- 2005-01-09 00:43:31 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 01:11:36 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1103C16A4CE for ; Sun, 9 Jan 2005 01:11:36 +0000 (GMT) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73A8543D46 for ; Sun, 9 Jan 2005 01:11:35 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j091BXFp014536 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 9 Jan 2005 12:11:34 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j091BXxP047116 for ; Sun, 9 Jan 2005 12:11:33 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j091BWuG047115 for freebsd-current@freebsd.org; Sun, 9 Jan 2005 12:11:33 +1100 (EST) (envelope-from pjeremy) Date: Sun, 9 Jan 2005 12:11:32 +1100 From: Peter Jeremy To: freebsd-current@freebsd.org Message-ID: <20050109011132.GJ39552@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i Subject: bus_dmamem_alloc() can't handle large NOWAIT requests X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Jan 2005 01:11:36 -0000 I've just been tracking down a panic in 4.x and found that the problem is still present in 6.x. According to bus_dma(9), bus_dmamem_alloc() can be invoked with a flag BUS_DMA_NOWAIT to indicate that sleep()ing is not allowed. At least on the i386, if the requested size exceeds 1 page (or some other cases), the requested memory will be allocated via contigmalloc(). bus_dmamem_alloc() maps BUS_DMA_NOWAIT to M_NOWAIT but contigmalloc() does not support M_NOWAIT and will tsleep() under some conditions. Unfortunately, I don't know enough about the VM code to be able to suggest a fix. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 05:25:22 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDFCE16A4D3 for ; Sun, 9 Jan 2005 05:25:22 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A153E43D2F for ; Sun, 9 Jan 2005 05:25:21 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.12] (g4.samsco.home [192.168.254.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id j095SMaB033730; Sat, 8 Jan 2005 22:28:22 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <41E0C02F.60100@freebsd.org> Date: Sat, 08 Jan 2005 22:25:03 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Jeremy References: <20050109011132.GJ39552@cirb503493.alcatel.com.au> In-Reply-To: <20050109011132.GJ39552@cirb503493.alcatel.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-current@freebsd.org Subject: Re: bus_dmamem_alloc() can't handle large NOWAIT requests X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Jan 2005 05:25:23 -0000 Peter Jeremy wrote: > I've just been tracking down a panic in 4.x and found that the problem > is still present in 6.x. > > According to bus_dma(9), bus_dmamem_alloc() can be invoked with a > flag BUS_DMA_NOWAIT to indicate that sleep()ing is not allowed. > > At least on the i386, if the requested size exceeds 1 page (or some > other cases), the requested memory will be allocated via contigmalloc(). > > bus_dmamem_alloc() maps BUS_DMA_NOWAIT to M_NOWAIT but contigmalloc() > does not support M_NOWAIT and will tsleep() under some conditions. > > Unfortunately, I don't know enough about the VM code to be able to > suggest a fix. > Will contigmalloc() actually sleep? If so, then this is something that needs to be addressed in contigmalloc. Scott From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 05:41:01 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F0AB16A4CE; Sun, 9 Jan 2005 05:41:01 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 359AA43D31; Sun, 9 Jan 2005 05:40:58 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j095ess3096552; Sun, 9 Jan 2005 16:10:55 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Sun, 9 Jan 2005 16:10:44 +1030 User-Agent: KMail/1.7.1 References: <20050109011132.GJ39552@cirb503493.alcatel.com.au> <41E0C02F.60100@freebsd.org> In-Reply-To: <41E0C02F.60100@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6024751.l3Fc9boJEZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501091610.51185.doconnor@gsoft.com.au> X-Spam-Score: -5.4 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Peter Jeremy cc: Scott Long Subject: Re: bus_dmamem_alloc() can't handle large NOWAIT requests X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Jan 2005 05:41:01 -0000 --nextPart6024751.l3Fc9boJEZ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sun, 9 Jan 2005 15:55, Scott Long wrote: > > bus_dmamem_alloc() maps BUS_DMA_NOWAIT to M_NOWAIT but contigmalloc() > > does not support M_NOWAIT and will tsleep() under some conditions. > > > > Unfortunately, I don't know enough about the VM code to be able to > > suggest a fix. > > Will contigmalloc() actually sleep? If so, then this is something that > needs to be addressed in contigmalloc. Couldn't contigmalloc() just return NULL if it was going to sleep? (hehe.. "just" ;) =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 --nextPart6024751.l3Fc9boJEZ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBB4MPj5ZPcIHs/zowRArkAAJ0WjM7ycTtZ41lnzIdr8e0xVDmiQQCfcvB9 BpHsDxxEYyd3hK8rt0CCSME= =OSdh -----END PGP SIGNATURE----- --nextPart6024751.l3Fc9boJEZ-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 05:42:18 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBBEF16A4CE for ; Sun, 9 Jan 2005 05:42:18 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 211A043D49 for ; Sun, 9 Jan 2005 05:42:18 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id j095cQYi055320 for ; Sun, 9 Jan 2005 00:38:26 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)j095cQm5055317 for ; Sun, 9 Jan 2005 05:38:26 GMT (envelope-from robert@fledge.watson.org) Date: Sun, 9 Jan 2005 05:38:26 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: HEADS UP: IPX/SPX now marked MPSAFE in 6.x-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, 09 Jan 2005 05:42:18 -0000 Over the last hour or so, I've merged a set of changes I've been working on for a couple of weeks that introduce locking to the IPX/SPX implementation covering several critical global variables, the raw and regular IPX/SPX PCB lists, and the PCB data structures for IPX and IPX/SPX. This involved some additional cleanup of the SPX code. The result is that the IPX/SPX code is *largely* MPSAFE -- certainly enough so to run without the Giant lock except under fairly unusual circumstances (see below). As such, I've removed the flag causing inclusion of IPX/SPX in the kernel to force the Giant lock over the entire network stack. It can be restored, if problems are experienced, by setting debug.mpsafenet=0 in /boot/loader.conf. There are a number of issues that remain necessary to address in the IPX/SPX code, including: (1) The protocol address lists (ifaddrs) are not locked down, so rapid changes in addresses during high volume input might result in a read of inconsistent address data from kernel memory. This also needs to be addressed with several other protocols, but in practice is a very difficult race to exercise. (2) IPX raw sockets permit outbound packets to be "sniffed" as well as inbound packets, resulting in reentrance of the IPX stack in the output path. This can result in some lock order problems as higher level locks are often held over the output path in a downward direction. I will likely introduce redelivery of "sniffed" sent packets using a netisr, similar to the way we handle routing socket messages. This is an edge case in how the stack is used -- neither the default behavior, nor used in current applications that I know of. I hope to get the chance to dig into both of these issues in the next couple of weeks. I've set of an MFC after of 2-4 weeks for various elements of the above changes. Since IPX/SPX is not widely used in the FreeBSD world, I suspect we won't get much testing of these changes, so if you are a user of IPX/SPX, your testing would be much appreciated! There are likely nits and bugs in this code -- if you experience crashes, please make sure your kernel is built with INVARIANTS and WITNESS, as that will make it much easier to debug locking problems. When reporting bugs, please include all relevant console and debugging output relating to failed assertions, traps, etc. I've attempted to test several forms of normal socket I/O, but I'm not set up to exercise netncp/nwfs or IPX routing. Thanks, Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 05:42:41 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FA4E16A4CF; Sun, 9 Jan 2005 05:42:41 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3DB143D2F; Sun, 9 Jan 2005 05:42:40 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id j095geYW000373; Sun, 9 Jan 2005 00:42:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id j095ge5B057990; Sun, 9 Jan 2005 00:42:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4FEDC7306E; Sun, 9 Jan 2005 00:42:40 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050109054240.4FEDC7306E@freebsd-current.sentex.ca> Date: Sun, 9 Jan 2005 00:42:40 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/640/Thu Dec 23 13:48:27 2004 clamav-milter version 0.80j on clamscanner3 X-Virus-Status: Clean 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, 09 Jan 2005 05:42:41 -0000 TB --- 2005-01-09 04:19:35 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-09 04:19:35 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2005-01-09 04:19:35 - checking out the source tree TB --- 2005-01-09 04:19:35 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2005-01-09 04:19:35 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-01-09 04:25:17 - building world (CFLAGS=-O2 -pipe) TB --- 2005-01-09 04:25:17 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-01-09 04:25:17 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/tinderbox/CURRENT/ia64/ia64/src/sbin/atm/ilmid/../../../sys -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /tinderbox/CURRENT/ia64/ia64/src/sbin/atm/ilmid/ilmid.c (cd /tinderbox/CURRENT/ia64/ia64/src/rescue/rescue/../../sbin/ping6 && /home/tinderbox/CURRENT/ia64/ia64/obj/tinderbox/CURRENT/ia64/ia64/src/make.i386/make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/ping6/ depend && /home/tinderbox/CURRENT/ia64/ia64/obj/tinderbox/CURRENT/ia64/ia64/src/make.i386/make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/ping6/ ping6.o) rm -f .depend mkdep -f .depend -a -DINET6 -DIPSEC -DKAME_SCOPEID -DUSE_RFC2292BIS -DHAVE_POLL_H -DHAVE_ARC4RANDOM -DRESCUE /tinderbox/CURRENT/ia64/ia64/src/sbin/ping6/ping6.c echo ping6: /home/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/i386/usr/lib/libc.a /home/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/i386/usr/lib/libipsec.a /home/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/i386/usr/lib/libm.a /home/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/i386/usr/lib/libmd.a >> .depend cc -O2 -pipe -DINET6 -DIPSEC -DKAME_SCOPEID -DUSE_RFC2292BIS -DHAVE_POLL_H -DHAVE_ARC4RANDOM -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /tinderbox/CURRENT/ia64/ia64/src/sbin/ping6/ping6.c /tinderbox/CURRENT/ia64/ia64/src/sbin/ping6/ping6.c: In function `pr_ip6opt': /tinderbox/CURRENT/ia64/ia64/src/sbin/ping6/ping6.c:1786: warning: passing arg 5 of `inet6_opt_next' from incompatible pointer type *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/sbin/ping6. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2005-01-09 05:42:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-01-09 05:42:39 - ERROR: failed to build world TB --- 2005-01-09 05:42:39 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 06:55:15 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF07F16A4CE for ; Sun, 9 Jan 2005 06:55:15 +0000 (GMT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E3B943D49 for ; Sun, 9 Jan 2005 06:55:15 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-216-100-134-143.dsl.snfc21.pacbell.net [216.100.134.143])j096tDHg337176 for ; Sun, 9 Jan 2005 01:55:14 -0500 Message-ID: <41E0D550.1050608@elischer.org> Date: Sat, 08 Jan 2005 22:55:12 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8a3) Gecko/20041017 X-Accept-Language: en, hu MIME-Version: 1.0 To: Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: do YOU have one of these USB devices? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Jan 2005 06:55:16 -0000 If so, let me know if it crashes the system, or works (or just does nothing :-) ) Julian (working through the USB PRs) From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 06:57:06 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B24216A4CE for ; Sun, 9 Jan 2005 06:57:06 +0000 (GMT) Received: from makeworld.com (makeworld.com [198.92.228.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 330FB43D1F for ; Sun, 9 Jan 2005 06:57:06 +0000 (GMT) (envelope-from racerx@makeworld.com) Received: from localhost (localhost.com [127.0.0.1]) by makeworld.com (Postfix) with ESMTP id 71CA76121; Sun, 9 Jan 2005 00:57:05 -0600 (CST) Received: from makeworld.com ([127.0.0.1]) by localhost (makeworld.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32329-10; Sun, 9 Jan 2005 00:57:03 -0600 (CST) Received: from [198.92.228.34] (racerx.makeworld.com [198.92.228.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by makeworld.com (Postfix) with ESMTP id 9EE9860EA; Sun, 9 Jan 2005 00:57:03 -0600 (CST) Message-ID: <41E0D5BF.70406@makeworld.com> Date: Sun, 09 Jan 2005 00:57:03 -0600 From: Chris User-Agent: Mozilla Thunderbird 1.0 (X11/20050101) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <41E0D550.1050608@elischer.org> In-Reply-To: <41E0D550.1050608@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by ClamAV 0.75.1/amavisd-new-2.2.0 (20041102) at makeworld.com - Isn't it ironic cc: Current Subject: Re: do YOU have one of these USB devices? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Jan 2005 06:57:06 -0000 Julian Elischer wrote: > If so, let me know if it crashes the system, or works > (or just does nothing :-) ) > > Julian > (working through the USB PRs) It *might* help if we know what USB devices you mean... -- Best regards, Chris Entropy has us outnumbered. From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 06:58:44 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9828B16A4CE for ; Sun, 9 Jan 2005 06:58:44 +0000 (GMT) Received: from pimout1-ext.prodigy.net (pimout1-ext.prodigy.net [207.115.63.77]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4791443D2F for ; Sun, 9 Jan 2005 06:58:44 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-216-100-134-143.dsl.snfc21.pacbell.net [216.100.134.143])j096wSjb021470; Sun, 9 Jan 2005 01:58:29 -0500 Message-ID: <41E0D614.4000305@elischer.org> Date: Sat, 08 Jan 2005 22:58:28 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8a3) Gecko/20041017 X-Accept-Language: en, hu MIME-Version: 1.0 To: Julian Elischer References: <41E0D550.1050608@elischer.org> In-Reply-To: <41E0D550.1050608@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Current Subject: Re: do YOU have one of these USB devices? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Jan 2005 06:58:44 -0000 Julian Elischer wrote: > If so, let me know if it crashes the system, or works > (or just does nothing :-) ) > > Julian > (working through the USB PRs) of course forgot to include the devices.. kensington mouse-in-a-box optical pro, as seen in: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/32713 or "Logitech Wingman Digital 3D" (product 0xc207 vendor 0x046d release 0x0104) as seen in: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/30502 From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 07:10:03 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F2A916A4CE for ; Sun, 9 Jan 2005 07:10:03 +0000 (GMT) Received: from mail.iinet.net.au (mail-08.iinet.net.au [203.59.3.40]) by mx1.FreeBSD.org (Postfix) with SMTP id F2DB143D3F for ; Sun, 9 Jan 2005 07:10:01 +0000 (GMT) (envelope-from shinjii@virusinfo.rdksupportinc.com) Received: (qmail 12018 invoked from network); 9 Jan 2005 07:10:00 -0000 Received: from unknown (HELO ?10.100.6.10?) (203.206.229.203) by mail.iinet.net.au with SMTP; 9 Jan 2005 07:10:00 -0000 From: Warren To: Peter Jeremy Date: Sun, 9 Jan 2005 17:09:48 +1000 User-Agent: KMail/1.7.2 References: <200501081518.33396.shinjii@virusinfo.rdksupportinc.com> <200501091318.38409.shinjii@virusinfo.rdksupportinc.com> <20050109065525.GL39552@cirb503493.alcatel.com.au> In-Reply-To: <20050109065525.GL39552@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501091709.48526.shinjii@virusinfo.rdksupportinc.com> cc: freebsd-current@freebsd.org Subject: Re: 5.3-STABLE failing to read 4.x-Stable hdd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Jan 2005 07:10:03 -0000 > Sorry. I didn't keep the original mail but I thought you'd posted your > results from running disklabel: > > disklabel ad0s1 > disklabel ad1s1 > > Hopefully, this will reveal the partitions as you expect. In ads1 i have: ads1 ad1s1c ad1s1e .... how do i rename those partitions to what ever it is there supposed to be.... Soz im totally new to this sort of thing in freebsd and clueless. =================== # /dev/ad0s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 993280 0 4.2BSD 2048 16384 62088 b: 1024000 2938880 swap c: 234436482 0 unused 0 0 # "raw" part, don't edit d: 1945600 993280 4.2BSD 2048 16384 28552 e: 33554432 3962880 4.2BSD 2048 16384 28552 f: 196919170 37517312 4.2BSD 2048 16384 28552 ================== # /dev/ad1s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 234436482 0 unused 0 0 # "raw" part, don't edit e: 234436482 0 4.2BSD 2048 16384 89 ================= Yours Sincerely Shinjii http://www.shinji.nq.nu From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 07:16:21 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F2B216A4CE; Sun, 9 Jan 2005 07:16:21 +0000 (GMT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0D9843D39; Sun, 9 Jan 2005 07:16:20 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-216-100-134-143.dsl.snfc21.pacbell.net [216.100.134.143])j097GIHg199638; Sun, 9 Jan 2005 02:16:18 -0500 Message-ID: <41E0DA41.60008@elischer.org> Date: Sat, 08 Jan 2005 23:16:17 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8a3) Gecko/20041017 X-Accept-Language: en, hu MIME-Version: 1.0 To: Current , stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: anyone using the umodem(4) module/driver? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2005 07:16:21 -0000 If so I'd like to hear success/failure reports.. looking at closing or otherwise acting on: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/39341 however the original submitter has dissappeared. From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 07:41:56 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 215DE16A4CE for ; Sun, 9 Jan 2005 07:41:56 +0000 (GMT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A1BD43D1F for ; Sun, 9 Jan 2005 07:41:55 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0)j097fhHo005073 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sun, 9 Jan 2005 08:41:46 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j097fLRd011003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Jan 2005 08:41:22 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j097fLMg003023; Sun, 9 Jan 2005 08:41:21 +0100 (CET) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j097fL0G003022; Sun, 9 Jan 2005 08:41:21 +0100 (CET) (envelope-from ticso) Date: Sun, 9 Jan 2005 08:41:20 +0100 From: Bernd Walter To: Julian Elischer Message-ID: <20050109074119.GD628@cicely12.cicely.de> References: <41E0D550.1050608@elischer.org> <41E0D614.4000305@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41E0D614.4000305@elischer.org> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=ham version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de cc: Current Subject: Re: do YOU have one of these USB devices? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.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, 09 Jan 2005 07:41:56 -0000 On Sat, Jan 08, 2005 at 10:58:28PM -0800, Julian Elischer wrote: > Julian Elischer wrote: > >If so, let me know if it crashes the system, or works > >(or just does nothing :-) ) > > > >Julian > >(working through the USB PRs) > > > of course forgot to include the devices.. > > kensington mouse-in-a-box optical pro, > as seen in: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/32713 Sounds very much like a power problem. I've seen lots of USB devices to be oversensitive. Using a different port or a hub between could help to work around. FreeBSD can't do anything to disconnect a device other then triggering a firmware bug, but in case of a firmware bug the device would either stop responding or just restart. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 07:50:33 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D075316A4CF for ; Sun, 9 Jan 2005 07:50:33 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95BBB43D54 for ; Sun, 9 Jan 2005 07:50:33 +0000 (GMT) (envelope-from julian@FreeBSD.org) Received: from freefall.freebsd.org (julian@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j097oXIF020918 for ; Sun, 9 Jan 2005 07:50:33 GMT (envelope-from julian@freefall.freebsd.org) Received: (from julian@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j097oXj0020917 for current; Sun, 9 Jan 2005 07:50:33 GMT (envelope-from julian) Date: Sun, 9 Jan 2005 07:50:33 GMT From: Julian Elischer Message-Id: <200501090750.j097oXj0020917@freefall.freebsd.org> To: current@FreeBSD.org Subject: got a "ucom" or "usio" device? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Jan 2005 07:50:33 -0000 http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/73799 can you test the patch supplied above for your device? From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 08:02:25 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB1EB16A4CE for ; Sun, 9 Jan 2005 08:02:25 +0000 (GMT) Received: from error404.nls.net (error404.nls.net [216.144.36.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5422E43D46 for ; Sun, 9 Jan 2005 08:02:25 +0000 (GMT) (envelope-from ketrien@error404.nls.net) Received: from error404.nls.net (ketrien@error404.nls.net [216.144.36.24]) by error404.nls.net (8.13.1/8.13.1) with ESMTP id j0985JMB099844; Sun, 9 Jan 2005 03:05:19 -0500 (EST) (envelope-from ketrien@error404.nls.net) Date: Sun, 9 Jan 2005 03:05:19 -0500 (EST) From: "Ketrien I. Saihr-Kenchedra" X-X-Sender: ketrien@bahre.achedra.org To: Julian Elischer In-Reply-To: <41E0D614.4000305@elischer.org> Message-ID: <20050109030232.P779@bahre.achedra.org> References: <41E0D550.1050608@elischer.org> <41E0D614.4000305@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.80/631/Wed Dec 15 09:01:14 2004 clamav-milter version 0.80j on bahre.achedra.org X-Virus-Status: Clean cc: Current Subject: Re: do YOU have one of these USB devices? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Jan 2005 08:02:25 -0000 On Sat, 8 Jan 2005, Julian Elischer wrote: > Julian Elischer wrote: >> If so, let me know if it crashes the system, or works >> (or just does nothing :-) ) >> >> Julian >> (working through the USB PRs) > > of course forgot to include the devices.. > > kensington mouse-in-a-box optical pro, > as seen in: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/32713 Yes, though not currently connected to a box. I'll do so tomorrow. They mislabeled; it's actually just the Kensington Optical Pro, AKA whatever Logitech model it is; they're actually made by Micro Innovations. (http://www.mic-innovations.com/) I've noticed that this mouse does _not_ like sitting idle. If I don't move it for several minutes, it takes a second to respond again, though if it's reattaching in Windows I've never seen it. -Ketrien I. Saihr-Kenchedra From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 08:34:41 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 347B516A4CE; Sun, 9 Jan 2005 08:34:41 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2C4D43D46; Sun, 9 Jan 2005 08:34:40 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j098YdmX083356; Sun, 9 Jan 2005 03:34:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id j098YduJ003795; Sun, 9 Jan 2005 03:34:39 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4A4F07306E; Sun, 9 Jan 2005 03:34:39 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050109083439.4A4F07306E@freebsd-current.sentex.ca> Date: Sun, 9 Jan 2005 03:34:39 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/625/Fri Dec 10 12:41:57 2004 clamav-milter version 0.80j on clamscanner1 X-Virus-Scanned: ClamAV 0.80/640/Thu Dec 23 13:48:27 2004 clamav-milter version 0.80j on clamscanner2 X-Virus-Status: Clean X-Virus-Status: Clean 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, 09 Jan 2005 08:34:41 -0000 TB --- 2005-01-09 07:28:43 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-09 07:28:43 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-01-09 07:28:43 - checking out the source tree TB --- 2005-01-09 07:28:43 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-01-09 07:28:43 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-01-09 07:34:41 - building world (CFLAGS=-O2 -pipe) TB --- 2005-01-09 07:34:41 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-01-09 07:34:41 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -I/tinderbox/CURRENT/sparc64/sparc64/src/sbin/atm/ilmid/../../../sys -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/atm/ilmid/ilmid.c (cd /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue/../../sbin/ping6 && /home/tinderbox/CURRENT/sparc64/sparc64/obj/tinderbox/CURRENT/sparc64/sparc64/src/make.i386/make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/ping6/ depend && /home/tinderbox/CURRENT/sparc64/sparc64/obj/tinderbox/CURRENT/sparc64/sparc64/src/make.i386/make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/ping6/ ping6.o) rm -f .depend mkdep -f .depend -a -DINET6 -DIPSEC -DKAME_SCOPEID -DUSE_RFC2292BIS -DHAVE_POLL_H -DHAVE_ARC4RANDOM -DRESCUE /tinderbox/CURRENT/sparc64/sparc64/src/sbin/ping6/ping6.c echo ping6: /home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libc.a /home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libipsec.a /home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libm.a /home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/lib/libmd.a >> .depend cc -O2 -pipe -DINET6 -DIPSEC -DKAME_SCOPEID -DUSE_RFC2292BIS -DHAVE_POLL_H -DHAVE_ARC4RANDOM -DRESCUE -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/ping6/ping6.c /tinderbox/CURRENT/sparc64/sparc64/src/sbin/ping6/ping6.c: In function `pr_ip6opt': /tinderbox/CURRENT/sparc64/sparc64/src/sbin/ping6/ping6.c:1786: warning: passing arg 5 of `inet6_opt_next' from incompatible pointer type *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/sbin/ping6. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/rescue/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/rescue. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-01-09 08:34:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-01-09 08:34:39 - ERROR: failed to build world TB --- 2005-01-09 08:34:39 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 10:15:32 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 773AD16A4CE; Sun, 9 Jan 2005 10:15:32 +0000 (GMT) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id D477443D2D; Sun, 9 Jan 2005 10:15:31 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j09AFU0B010280 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 9 Jan 2005 21:15:30 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j09AFUxP047582; Sun, 9 Jan 2005 21:15:30 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j09AFTSw047581; Sun, 9 Jan 2005 21:15:29 +1100 (EST) (envelope-from pjeremy) Date: Sun, 9 Jan 2005 21:15:29 +1100 From: Peter Jeremy To: Scott Long Message-ID: <20050109101529.GM39552@cirb503493.alcatel.com.au> References: <20050109011132.GJ39552@cirb503493.alcatel.com.au> <41E0C02F.60100@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41E0C02F.60100@freebsd.org> User-Agent: Mutt/1.4.2i cc: freebsd-current@freebsd.org Subject: Re: bus_dmamem_alloc() can't handle large NOWAIT requests X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Jan 2005 10:15:32 -0000 On Sat, 2005-Jan-08 22:25:03 -0700, Scott Long wrote: >>According to bus_dma(9), bus_dmamem_alloc() can be invoked with a >>flag BUS_DMA_NOWAIT to indicate that sleep()ing is not allowed. >> >>At least on the i386, if the requested size exceeds 1 page (or some >>other cases), the requested memory will be allocated via contigmalloc(). ... >Will contigmalloc() actually sleep? If so, then this is something that >needs to be addressed in contigmalloc. I have not actually seen this occur. If I get some time, I might see if I can force the issue. Reading the code, I believe it can. Firstly: 1) if (vm_old_contigmalloc), contigmalloc1() locks vm_page_queue_mtx via vm_page_lock_queues(). 2) Otherwise, contigmalloc2() calls vm_map_lock() which locks kernel_map->system_mtx Both these mutexes are MTX_DEF (sleepable) and there doesn't appear to be anything preventing them from sleeping. There are other theoretical code paths that end in sleeps (eg the following), though I suspect this path can never occur: contigmalloc() => vm_contig.c:552: contigmalloc1() => vm_contig.c:222,227: vm_contig_launder() => vm_contig.c:141: vm_contig_launder_page() => vm_contig.c:98: vm_page_sleep_if_busy() => vm_page.c:440: msleep() -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 10:31:21 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5F9ED16A4CE for ; Sun, 9 Jan 2005 10:31:21 +0000 (GMT) Received: from portpc-design.spb.ru (ns2.portpc-design.spb.ru [195.161.118.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00DED43D1D for ; Sun, 9 Jan 2005 10:31:20 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from [83.237.208.199] (ppp83-237-208-199.pppoe.mtu-net.ru [83.237.208.199]) (authenticated bits=0) by portpc-design.spb.ru (8.13.2/8.13.2) with ESMTP id j09AVEHQ044341 for ; Sun, 9 Jan 2005 13:31:14 +0300 (MSK) (envelope-from mcsi@mcsi.pp.ru) Message-ID: <41E107ED.8010409@mcsi.pp.ru> Date: Sun, 09 Jan 2005 13:31:09 +0300 From: Maxim Maximov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20041224 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: LOR in ndis driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2005 10:31:21 -0000 Hello, all. I've just got this LOR on FreeBSD ultra.domain 6.0-CURRENT FreeBSD 6.0-CURRENT #2: Fri Jan 7 22:42:15 MSK 2005 mcsi@ultra.domain:/usr/obj/usr/src/sys/ULTRA i386 ndis0: link down acquiring duplicate lock of same type: "network driver" 1st ndis irq lock @ /usr/src/sys/dev/if_ndis/if_ndis.c:1044 2nd ndis softc lock @ /usr/src/sys/compat/ndis/kern_ndis.c:1467 KDB: stack backtrace: witness_checkorder(c1d0fcc4,9,c089d4b7,5bb) at witness_checkorder+0x500 _mtx_lock_flags(c1d0fcc4,0,c089d4b7,5bb,c1d0f000) at _mtx_lock_flags+0x40 ndis_disable_intr(c1d0f000,0,0,c1d12780,c1ae8580) at ndis_disable_intr+0x21 ndis_intr(c1d0f000,0,0,c1af99d8,0) at ndis_intr+0x59 ithread_loop(c1ae8580,d426ad48,c1ae8580,c064451c,0) at ithread_loop+0x19e fork_exit(c064451c,c1ae8580,d426ad48) at fork_exit+0x7e fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd426ad7c, ebp = 0 --- ndis0: link up -- Maxim Maximov From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 11:58:44 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 975E716A4CE for ; Sun, 9 Jan 2005 11:58:44 +0000 (GMT) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A9B443D39 for ; Sun, 9 Jan 2005 11:58:43 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received-SPF: pass (eva.fit.vutbr.cz: domain of xdivac02@eva.fit.vutbr.cz designates 127.0.0.1 as permitted sender) receiver=eva.fit.vutbr.cz; client_ip=127.0.0.1; envelope-from=xdivac02@eva.fit.vutbr.cz; Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (8.12.11/8.12.11) with ESMTP id j09BwdEP025051 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sun, 9 Jan 2005 12:58:39 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.12.11/8.12.5/Submit) id j09Bwd5F025049 for current@freebsd.org; Sun, 9 Jan 2005 12:58:39 +0100 (CET) Date: Sun, 9 Jan 2005 12:58:39 +0100 From: Divacky Roman To: current@freebsd.org Message-ID: <20050109115839.GA24538@stud.fit.vutbr.cz> References: <41DF253C.5040705@fer.hr> <20050108005540.GB93568@troutmask.apl.washington.edu> <20050108030707.GA3656@frontfree.net> <20050108034424.GA94365@troutmask.apl.washington.edu> <41DF999E.7060403@comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41DF999E.7060403@comcast.net> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) Subject: Re: MFC wishlist X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Jan 2005 11:58:44 -0000 I experience hardlocks on UP with both 4BSD and/or ULE. its somewhat related (I think) to some multimedia since it demonstrates itself when running mplayer/xmms. But I've seen this even withuot running those programs. But it might be a coincidence. On Sat, Jan 08, 2005 at 03:28:14AM -0500, Sean wrote: > Steve Kargl wrote: > >On Sat, Jan 08, 2005 at 11:07:07AM +0800, Xin LI wrote: > > > >>On Fri, Jan 07, 2005 at 04:55:40PM -0800, Steve Kargl wrote: > >> > >>>On Sat, Jan 08, 2005 at 01:11:40AM +0100, Ivan Voras wrote: > >>> > >>>>It's been a while now and (judging from this list at least), people are > >>>>not complaining about ULE, so maybe (with re@ approval) the fix & > >>>>supporting infrastructure could be brought to RELENG_5? > >>>> > >>> > >>>That's not a good idea. I can lock up ULE+PREEMPTION on > >>>a dual amd64 system within 30 minutes. The system is > >>>runnnig X11 and normally firefox (or other threaded > >>>app) and it simply freezes. No panic. No keyboard > >>>response. Nothing. > >> > >>This is observed in pre-5.3RELEASE CURRENT, but I thought Jeff has > >>already fixed it in -CURRENT. I don't have dual amd64 system to do > >>such experiments, are you sure you are talking about the latest > >>6-CURRENT, or just 5.3? > >> > > > > > >Yes, I'm talking about 6-CURRENT. My last kernel/world build is > >04 Jan 05. I can only invoke the problem with X11 running, and > >I currently don't have a serial console on this system. I'm > >guessing that I hit a deadlock (or livelock). > > > I also have a dual amd64 and 6-CURRENT and had all sort of problems when > I tried ULE. > > Sean > _______________________________________________ > 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 Jan 9 13:05:58 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70C7D16A4CE; Sun, 9 Jan 2005 13:05:58 +0000 (GMT) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A5A8C43D1F; Sun, 9 Jan 2005 13:05:57 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id j09D5u0S025249; Sun, 9 Jan 2005 15:05:56 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 13139-12; Sun, 9 Jan 2005 15:05:56 +0200 (EET) 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 j09D5tji025246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 9 Jan 2005 15:05:56 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.1/8.13.1) id j09D5gC6096629; Sun, 9 Jan 2005 15:05:42 +0200 (EET) (envelope-from ru) Date: Sun, 9 Jan 2005 15:05:41 +0200 From: Ruslan Ermilov To: Kris Kennaway Message-ID: <20050109130541.GC96289@ip.net.ua> References: <200501022117.48924.michaelnottebrock@gmx.net> <20050102212335.GA58562@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1SQmhf2mF2YjsYvc" Content-Disposition: inline In-Reply-To: <20050102212335.GA58562@xor.obsecurity.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at ip.net.ua cc: harti@FreeBSD.org cc: current@FreeBSD.org Subject: Re: Ports failing with bsd make X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Jan 2005 13:05:58 -0000 --1SQmhf2mF2YjsYvc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 02, 2005 at 01:23:35PM -0800, Kris Kennaway wrote: > On Sun, Jan 02, 2005 at 09:17:44PM +0100, Michael Nottebrock wrote: > > On recent -current, several ports are failing to build. Common quality:= They=20 > > all use the system make rather than gmake. > >=20 > > Examples: science/hdf, textproc/Wordnet, devel/qmake. > >=20 > > The errors all look pretty similar: > >=20 > > =3D=3D=3D> mfhdf/nctest (all) > > make: don't know how to make nctest.1. Stop > > ... > >=20 > > make: don't know how to make wn.1. Stop > > ... > >=20 > > make: don't know how to make qmake.1. Stop > >=20 > > Looks like they're all failing while trying to generate manpages. Has m= ake=20 > > become allergic to targets with a dot in them perhaps? >=20 > Ruslan's NO_* change broke a lot of ports. He's currently on vacation > for a few days, but I expect he'll fix these when he gets back. If > you want to do it in the meantime (although we're in ports freeze > anyway so this won't be committed until after), the port needs to set > *both* NOMAN and NO_MAN (similarly for any other options like NOSHARED > and NOPROFILE), for compatibility with both 6.x and older. >=20 I'm back, and this should all be fixed now. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --1SQmhf2mF2YjsYvc Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFB4SwlqRfpzJluFF4RAryCAJ4sUVjU8AuW3iy5bXzjggvqNJiIGQCghpjK 9AEcJ7SdfKLC1rfQQfjsi1o= =6+7r -----END PGP SIGNATURE----- --1SQmhf2mF2YjsYvc-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 00:28:08 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 68BE016A4CE for ; Sun, 9 Jan 2005 00:28:08 +0000 (GMT) Received: from mail.iinet.net.au (mail-03.iinet.net.au [203.59.3.35]) by mx1.FreeBSD.org (Postfix) with SMTP id 160E643D2F for ; Sun, 9 Jan 2005 00:28:07 +0000 (GMT) (envelope-from shinjii@virusinfo.rdksupportinc.com) Received: (qmail 7346 invoked from network); 9 Jan 2005 00:28:05 -0000 Received: from unknown (HELO ?10.100.6.10?) (203.206.229.203) by mail.iinet.net.au with SMTP; 9 Jan 2005 00:28:05 -0000 From: Warren To: Peter Jeremy Date: Sun, 9 Jan 2005 10:27:02 +1000 User-Agent: KMail/1.7.2 References: <200501081518.33396.shinjii@virusinfo.rdksupportinc.com> <200501081658.10291.shinjii@virusinfo.rdksupportinc.com> <20050108191849.GG39552@cirb503493.alcatel.com.au> In-Reply-To: <20050108191849.GG39552@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501091027.02967.shinjii@virusinfo.rdksupportinc.com> X-Mailman-Approved-At: Sun, 09 Jan 2005 13:17:18 +0000 Subject: Re: 5.3-STABLE failing to read 4.x-Stable hdd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Jan 2005 00:28:08 -0000 > Try running disklabel on ad0s1 and ad1s1. Slice numbers should now be > treated as mandatory on sliced disks. im still relatively new to freebsd .. but if it only detects 1 partition on the 2nd hdd .. how will disklabel allow me to retrieve the data that is on there if it shows 1 partition using the entire hdd ? -- Yours Sincerely Shinjii http://www.shinji.nq.nu From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 03:20:11 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F20B16A4CE for ; Sun, 9 Jan 2005 03:20:11 +0000 (GMT) Received: from mail.iinet.net.au (mail-09.iinet.net.au [203.59.3.41]) by mx1.FreeBSD.org (Postfix) with SMTP id B4B3043D4C for ; Sun, 9 Jan 2005 03:20:09 +0000 (GMT) (envelope-from shinjii@virusinfo.rdksupportinc.com) Received: (qmail 2642 invoked from network); 9 Jan 2005 03:20:08 -0000 Received: from unknown (HELO ?10.100.6.10?) (203.206.229.203) by mail.iinet.net.au with SMTP; 9 Jan 2005 03:20:08 -0000 From: Warren To: Peter Jeremy Date: Sun, 9 Jan 2005 13:18:38 +1000 User-Agent: KMail/1.7.2 References: <200501081518.33396.shinjii@virusinfo.rdksupportinc.com> <200501091027.02967.shinjii@virusinfo.rdksupportinc.com> <20050109013023.GK39552@cirb503493.alcatel.com.au> In-Reply-To: <20050109013023.GK39552@cirb503493.alcatel.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200501091318.38409.shinjii@virusinfo.rdksupportinc.com> X-Mailman-Approved-At: Sun, 09 Jan 2005 13:17:18 +0000 Subject: Re: 5.3-STABLE failing to read 4.x-Stable hdd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Jan 2005 03:20:11 -0000 > ad1 and ad1s1 are not the same, even if ad1 only has one partition > defined. Older versions of FreeBSD had code that would map adX to the > first FreeBSD slice in adX but this is deprecated in FreeBSD 4.x and > I think it has been removed in 5.x. > > I suspect that if you run disklabel on ad1s1, you will find the partitions > as you expect and can mount them as ad1s1a etc. What is the command to use for this exactly ? As i have no idea on this sort of thing. -- Yours Sincerely Shinjii http://www.shinji.nq.nu From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 17:35:01 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07E7116A4CE; Sun, 9 Jan 2005 17:35:01 +0000 (GMT) Received: from 212.106.238.57.adsl.jazztel.es (212.106.238.57.adsl.jazztel.es [212.106.238.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9143B43D48; Sun, 9 Jan 2005 17:34:59 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from [192.168.254.16] (orion.redesjm.local [192.168.254.16]) j09HYqtq000750; Sun, 9 Jan 2005 18:34:55 +0100 (CET) (envelope-from freebsd@redesjm.local) Message-ID: <41E16B3C.30302@redesjm.local> Date: Sun, 09 Jan 2005 18:34:52 +0100 From: Jose M Rodriguez User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: es-es, es MIME-Version: 1.0 To: Brooks Davis References: <41DDC4F2.5090709@yahoo.com> <20050107003806.GA14003@odin.ac.hmc.edu> <41DE5242.4030606@redesjm.local> <20050107182024.GB30931@odin.ac.hmc.edu> In-Reply-To: <20050107182024.GB30931@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.29.0.5; VDF: 6.29.0.31; host: antares.redesjm.local) cc: Rob cc: freebsd-current cc: x11@freebsd.org cc: Jose M Rodriguez Subject: Re: Xorg ICE vs. Xfce4 (4.2-RC3) needs fixing /etc/rc.d/cleartmp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Jan 2005 17:35:01 -0000 Brooks Davis escribió: >On Fri, Jan 07, 2005 at 10:11:30AM +0100, Jose M Rodriguez wrote: > > >>Brooks Davis escribió: >> >> >> >>>Could you please try the following patch? It does the same thing, but >>>gives the inode paranoid a way to disable the creation of these >>>directories or only create the ones they need. >>> >>>-- Brooks >>> >>>Index: rc.d/cleartmp >>>=================================================================== >>>RCS file: /usr/cvs/src/etc/rc.d/cleartmp,v >>>retrieving revision 1.11 >>>diff -u -p -r1.11 cleartmp >>>--- rc.d/cleartmp 7 Oct 2004 13:55:25 -0000 1.11 >>>+++ rc.d/cleartmp 7 Jan 2005 00:31:51 -0000 >>>@@ -35,5 +35,7 @@ run_rc_command "$1" >>># restarting X >>># >>>rm -f /tmp/.X[0-9]-lock >>>-rm -fr /tmp/.X11-unix >>>-mkdir -m 1777 /tmp/.X11-unix >>>+if [ -n ${clear_tmp_xdirs} ]; then >>>+ rm -fr ${clear_tmp_xdirs} >>>+ mkdir -m 1777 ${clear_tmp_xdirs} >>>+fi >>>Index: defaults/rc.conf >>>=================================================================== >>>RCS file: /usr/cvs/src/etc/defaults/rc.conf,v >>>retrieving revision 1.235 >>>diff -u -p -r1.235 rc.conf >>>--- defaults/rc.conf 15 Dec 2004 12:39:28 -0000 1.235 >>>+++ defaults/rc.conf 7 Jan 2005 00:30:49 -0000 >>>@@ -443,6 +443,8 @@ linux_enable="NO" # Linux binary compati >>>svr4_enable="NO" # SysVR4 emulation loaded at startup (or NO). >>>osf1_enable="NO" # Alpha OSF/1 emulation loaded at startup (or NO). >>>clear_tmp_enable="NO" # Clear /tmp at startup. >>>+clear_tmp_xdirs="/tmp/.X11-unix /tmp/.font-unix /tmp/.ICE-unix" >>>+ # Directories needed by X11 >>>ldconfig_insecure="NO" # Set to YES to disable ldconfig security >>>checks >>>ldconfig_paths="/usr/lib/compat /usr/X11R6/lib /usr/local/lib >>>/usr/local/lib/compat/pkg" >>> # shared library search paths >>> >>> >>> >>> >>> >>I recall putting this in a conf PR, try a follow-up. >> >>But I think your patch is a little bit wrong >> >>I never like the way X11 is taken by /etc/rc.d/cleartmp. none must be >>do after the run_rc_command. >> >> > >That's easy enough to fix. > > > >>If we need do this from the base system (Thing that I doubt more and >>more), this must be implementing a new /etc/rc.d/clearx11tmp (this may >>be do in the main /etc/rc.d/cleartmp, like in sendmail), with all the bits: >>clear_x11tmp_enable, clear_x11tmp_dirs, ... >> >>But I must point that: >> >>X11 is now mostly a ports thing, not a base system component. If this >>can be take from ports (I send-pr this also), this must be the path to >>the solution. I put a simple script from libs, but I can work and rcNG >>enabled thing if prefered. >> >>This is not what x11 really needs. x11 only needs some like this: mkdir >>-p ... && chown root:wheel ... && chmod 01777 ... . this may be >>prefered by the x11 team. >> >>This can be taken both from base and ports without too much problem. >>The only secondary effect of this I know is that you may polite /tmp >>entries twice, with is not a real pain to the whole boot process. >> >> > >My worry with using your patch is that localpkg is run quite late in the >startup process, well after X may have tried to start if xdm is run from >/etc/ttys. If package startup scripts could run anywhere in the order, >a script in the port would be obvious solution, but that's not the case. > >-- Brooks > > > You're molsty wrong. init launch gettys after rc has finished (and also localpkg). -- josemi From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 17:45:06 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 795B516A4CE; Sun, 9 Jan 2005 17:45:06 +0000 (GMT) Received: from 212.106.238.57.adsl.jazztel.es (212.106.238.57.adsl.jazztel.es [212.106.238.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83F1D43D2F; Sun, 9 Jan 2005 17:45:05 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from [192.168.254.16] (orion.redesjm.local [192.168.254.16]) j09Hj1H1000777; Sun, 9 Jan 2005 18:45:03 +0100 (CET) (envelope-from freebsd@redesjm.local) Message-ID: <41E16D9C.3010100@redesjm.local> Date: Sun, 09 Jan 2005 18:45:00 +0100 From: Jose M Rodriguez User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: es-es, es MIME-Version: 1.0 To: Pawel Worach References: <41DDC4F2.5090709@yahoo.com> <20050107003806.GA14003@odin.ac.hmc.edu> <41DE5242.4030606@redesjm.local> <20050107182024.GB30931@odin.ac.hmc.edu> <41DED3DA.1040506@telia.com> In-Reply-To: <41DED3DA.1040506@telia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.29.0.5; VDF: 6.29.0.31; host: antares.redesjm.local) cc: Rob cc: freebsd-current cc: x11@freebsd.org cc: Jose M Rodriguez Subject: Re: Xorg ICE vs. Xfce4 (4.2-RC3) needs fixing /etc/rc.d/cleartmp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Jan 2005 17:45:06 -0000 Pawel Worach escribió: > Brooks Davis wrote: > >> My worry with using your patch is that localpkg is run quite late in the >> startup process, well after X may have tried to start if xdm is run from >> /etc/ttys. If package startup scripts could run anywhere in the order, >> a script in the port would be obvious solution, but that's not the case. > > > Another issue I see with doing this in localpkg is that on a diskless > client > that shares /usr with the server it's common to set local_startup="" for > the client so that it doesn't start all the stuff you have installed > on the > server. This issue is smaller today now that more ports use rcNG. > >> >> -- Brooks >> > Not here, working great. But your proposition main problem is the time to go HEAD -> RELENG_5 -> RELENG_4. This can take months to go RELENG_5 and never to RELENG_4. Also, as I said, you may polite This. What cleartmp do now is a pure hack. What you propose is twice. If this must to HEAD, it must be adapted to rcNG rules. -- josemi From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 20:26:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9A9E16A4CE for ; Sun, 9 Jan 2005 20:26:40 +0000 (GMT) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D92543D1F for ; Sun, 9 Jan 2005 20:26:40 +0000 (GMT) (envelope-from rionda@gufi.org) Received: from localhost.localdomain (unknown [82.52.112.71]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP id A82125788 for ; Sun, 9 Jan 2005 21:29:30 +0100 (CET) From: Matteo Riondato To: freebsd-current@freebsd.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-XgMtRc/omB0bxtzafmKW" Date: Sun, 09 Jan 2005 21:24:57 +0100 Message-Id: <1105302297.9705.23.camel@kaiser.sig11.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port Subject: firefox coredumping in recent 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, 09 Jan 2005 20:26:41 -0000 --=-XgMtRc/omB0bxtzafmKW Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi folks I'm experimenting some core dumps with firefox on a recent current (Jan 2 2005). Firefox crashes during surfing, but there's no way to say "in this page it will crash" because crashes seem to happen randomly. The only message that appears on the command line is: Fatal error 'Recurse on a private mutex.' at line 988 in file /usr/src/lib/libpthread/thread/thr_mutex.c (errno =3D 0) Abort trap (core dumped) Hope this will help and that this is the right list where to post this message... Best Regards --=20 Rionda aka Matteo Riondato GUFI Staff Member (http://www.gufi.org) FreeSBIE Developer (http://www.freesbie.org) BSD-FAQ-it Main Developer (http://utenti.gufi.org/~rionda) Sent from: kaiser.sig11.org running FreeBSD-6.0-CURRENT --=-XgMtRc/omB0bxtzafmKW Content-Type: application/pgp-signature; name=signature.asc Content-Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBB4ZMZ2Mp4pR7Fa+wRAnJ/AJ43mFG0+pzsmw+DC5tsaNyunAohpgCcDFjo P5UiOKQP3NtFuBOCAAv7d88= =mKAi -----END PGP SIGNATURE----- --=-XgMtRc/omB0bxtzafmKW-- From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 21:17:37 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 480E716A4CE for ; Sun, 9 Jan 2005 21:17:37 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE12943D49 for ; Sun, 9 Jan 2005 21:17:36 +0000 (GMT) (envelope-from arr@watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id j09LDhjT069108; Sun, 9 Jan 2005 16:13:43 -0500 (EST) (envelope-from arr@watson.org) Received: from localhost (arr@localhost)j09LDh61069105; Sun, 9 Jan 2005 16:13:43 -0500 (EST) (envelope-from arr@watson.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Sun, 9 Jan 2005 16:13:43 -0500 (EST) From: "Andrew R. Reiter" To: Matteo Riondato In-Reply-To: <1105302297.9705.23.camel@kaiser.sig11.org> Message-ID: <20050109161216.T65259@fledge.watson.org> References: <1105302297.9705.23.camel@kaiser.sig11.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: firefox coredumping in recent 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, 09 Jan 2005 21:17:37 -0000 On Sun, 9 Jan 2005, Matteo Riondato wrote: :Hi folks :I'm experimenting some core dumps with firefox on a recent current (Jan :2 2005). Firefox crashes during surfing, but there's no way to say "in :this page it will crash" because crashes seem to happen randomly. :The only message that appears on the command line is: : I've had similar issues, so I wanted to figure out what the deal was. I deinstalled firefox and rebuilt with debugging symbols... I've yet to have it crash since... :-/ :Fatal error 'Recurse on a private mutex.' at line 988 in :file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 0) :Abort trap (core dumped) : :Hope this will help and that this is the right list where to post this :message... : :Best Regards :-- :Rionda aka Matteo Riondato :GUFI Staff Member (http://www.gufi.org) :FreeSBIE Developer (http://www.freesbie.org) :BSD-FAQ-it Main Developer (http://utenti.gufi.org/~rionda) :Sent from: kaiser.sig11.org running FreeBSD-6.0-CURRENT : -- Andrew R. Reiter arr@watson.org arr@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 21:44:59 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D892C16A4CE for ; Sun, 9 Jan 2005 21:44:59 +0000 (GMT) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id 480A443D3F for ; Sun, 9 Jan 2005 21:44:59 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 3530 invoked from network); 9 Jan 2005 21:44:55 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 9 Jan 2005 21:44:55 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id j09Lis08060041 for ; Sun, 9 Jan 2005 22:44:54 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id j09Lis18060040 for current@freebsd.org; Sun, 9 Jan 2005 22:44:54 +0100 (CET) (envelope-from pho) Date: Sun, 9 Jan 2005 22:44:54 +0100 From: Peter Holm To: current@freebsd.org Message-ID: <20050109214454.GA60018@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: panic: proc not held @ fs/procfs/procfs_regs.c:60 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Jan 2005 21:45:00 -0000 With GENERIC HEAD from Jan 8 08:45 UTC I got: panic(c0826351,c0826973,c082fcfc,3,c175a2e0) at panic+0xd8 procfs_doprocregs(c175a2e0,c1b1b5e8,c1665d80,0,ce778c90) at procfs_doprocregs+0x10a pfs_read(ce778c1c,20000,c1f19e04,c08294ba,845) at pfs_read+0x20f vn_read(c1b17ae4,ce778c90,c1a9c080,0,c175a2e0) at vn_read+0x1b9 dofileread(8,bfbfea50,4c,ffffffff,ffffffff) at dofileread+0x82 read(c175a2e0,ce778d14,3,1,282) at read+0x44 syscall(2f,2f,2f,8059f48,a7c) at syscall+0x128 Details at http://www.holm.cc/stress/log/cons105.html -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 22:59:23 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C698216A4CF; Sun, 9 Jan 2005 22:59:23 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id E865B43D45; Sun, 9 Jan 2005 22:59:22 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j09MvuXV025567; Sun, 9 Jan 2005 15:57:56 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 09 Jan 2005 15:58:34 -0700 (MST) Message-Id: <20050109.155834.04734584.imp@bsdimp.com> To: julian@freebsd.org From: "M. Warner Losh" In-Reply-To: <200501090750.j097oXj0020917@freefall.freebsd.org> References: <200501090750.j097oXj0020917@freefall.freebsd.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: got a "ucom" or "usio" device? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Jan 2005 22:59:23 -0000 In message: <200501090750.j097oXj0020917@freefall.freebsd.org> Julian Elischer writes: : : http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/73799 : : can you test the patch supplied above for your device? Specifically Entrega Serial DB25 adapter or + match "vendor" "0x082d"; + match "product" "0x0100"; + match "release" "0x0100"; (which I think is some sort of palm device). Warner From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 23:02:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A590E16A4E8; Sun, 9 Jan 2005 23:02:31 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27F9D43D49; Sun, 9 Jan 2005 23:02:29 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j09N0UqA025597; Sun, 9 Jan 2005 16:00:30 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 09 Jan 2005 16:01:07 -0700 (MST) Message-Id: <20050109.160107.01029278.imp@bsdimp.com> To: julian@elischer.org From: "M. Warner Losh" In-Reply-To: <41E0DA41.60008@elischer.org> References: <41E0DA41.60008@elischer.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: stable@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: anyone using the umodem(4) module/driver? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jan 2005 23:02:31 -0000 In message: <41E0DA41.60008@elischer.org> Julian Elischer writes: : If so I'd like to hear success/failure reports.. : looking at closing or otherwise acting on: : http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/39341 : however the original submitter has dissappeared. I use umodem as a driver all the time to dial into the net, and have since before 5.2 without flaw using the module. It works greak, so this can be closed, I believe. Warner From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 23:14:23 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCA1716A4CE for ; Sun, 9 Jan 2005 23:14:23 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37CE143D48 for ; Sun, 9 Jan 2005 23:14:23 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j09NCTOR025677; Sun, 9 Jan 2005 16:12:30 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 09 Jan 2005 16:13:07 -0700 (MST) Message-Id: <20050109.161307.16265866.imp@bsdimp.com> To: kwm@rainbow-runner.nl From: "M. Warner Losh" In-Reply-To: <1105227700.25419.14.camel@heater.rainbow-runner.nl> References: <1105227700.25419.14.camel@heater.rainbow-runner.nl> 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: cbb0: CardBus card activation failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Jan 2005 23:14:23 -0000 Can you set hw.cbb.debug=1, hw.pccard.debug=1, and hw.cardbus.debug=1 and boot -v and try to insert the card to see what's going on? Please include a complete dmesg. Thanks. Warner From owner-freebsd-current@FreeBSD.ORG Sun Jan 9 23:30:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25F0216A4CE for ; Sun, 9 Jan 2005 23:30:10 +0000 (GMT) Received: from error404.nls.net (error404.nls.net [216.144.36.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B57843D5E for ; Sun, 9 Jan 2005 23:30:07 +0000 (GMT) (envelope-from ketrien@error404.nls.net) Received: from error404.nls.net (ketrien@error404.nls.net [216.144.36.24]) by error404.nls.net (8.13.1/8.13.1) with ESMTP id j09NX3xN003019; Sun, 9 Jan 2005 18:33:03 -0500 (EST) (envelope-from ketrien@error404.nls.net) Date: Sun, 9 Jan 2005 18:33:03 -0500 (EST) From: "Ketrien I. Saihr-Kenchedra" X-X-Sender: ketrien@bahre.achedra.org To: Julian Elischer In-Reply-To: <41E0D614.4000305@elischer.org> Message-ID: <20050109182454.O779@bahre.achedra.org> References: <41E0D550.1050608@elischer.org> <41E0D614.4000305@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.80/631/Wed Dec 15 09:01:14 2004 clamav-milter version 0.80j on bahre.achedra.org X-Virus-Status: Clean cc: Current Subject: Re: do YOU have one of these USB devices? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 09 Jan 2005 23:30:10 -0000 On Sat, 8 Jan 2005, Julian Elischer wrote: > Julian Elischer wrote: >> If so, let me know if it crashes the system, or works >> (or just does nothing :-) ) Already ran into something interesting; this is a Netfinity 4500R. Jan 9 18:13:18 terya kernel: uhub0: device problem (SET_ADDR_FAILED), disabling port 1 Jan 9 18:13:52 terya last message repeated 6 times ohci0: mem 0xff700000-0xff700fff irq 11 at device 15.2 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 4 ports with 4 removable, self powered ohci0@pci0:15:2: class=0x0c0310 card=0x02201166 chip=0x02201166 rev=0x04 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'OSB4 OpenHCI Compliant USB Controller' class = serial bus subclass = USB Move it to the bottom USB port... Jan 9 18:13:56 terya kernel: ums0: Kensington USB/PS2 Wheel Mouse, rev 1.10/1.00, addr 2, iclass 3/1 Jan 9 18:13:56 terya kernel: ums0: 5 buttons and Z dir. Jan 9 18:13:56 terya kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 9 18:13:56 terya kernel: ums0: detached Jan 9 18:13:57 terya kernel: ums0: Kensington USB/PS2 Wheel Mouse, rev 1.10/1.00, addr 2, iclass 3/1 Jan 9 18:13:57 terya kernel: ums0: 5 buttons and Z dir. So as one can see, it's immediately detaching and reattaching, yep. It doesn't seem to detach when I just let it sit though. As far as working, yes, it works, with the exception of the thumb buttons. (Only tested console.) Detach is also OK. Jan 9 18:21:07 terya kernel: ums0: at uhub0 port 2 (addr 2) disconnected Jan 9 18:21:07 terya kernel: ums0: detached Jan 9 18:21:07 terya moused: unable to open /dev/ums0: No such file or directory -Ketrien I. Saihr-Kenchedra From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 02:04:32 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62E2C16A4CE for ; Mon, 10 Jan 2005 02:04:31 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02F8443D2F for ; Mon, 10 Jan 2005 02:04:29 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw503.dsto.defence.gov.au (ednmsw503.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id j0A23KF3013304 for ; Mon, 10 Jan 2005 12:33:20 +1030 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw503.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Mon, 10 Jan 2005 12:34:21 +1030 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id j0A1xoQ11608 for ; Mon, 10 Jan 2005 12:29:50 +1030 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YK376Z5B; Mon, 10 Jan 2005 12:29:36 +1030 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id j0A20F5n024288 for ; Mon, 10 Jan 2005 12:30:15 +1030 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id j0A20FpR024287 for freebsd-current@freebsd.org; Mon, 10 Jan 2005 12:30:15 +1030 (CST) (envelope-from wilkinsa) Date: Mon, 10 Jan 2005 12:30:15 +1030 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20050110015842.GA24213@squash.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: <20041223123621.GB17515@eddie.nitro.dk> <41CADACC.9050607@freebsd.org> <20050106131327.GE801@zaphod.nitro.dk> <20050106.134852.41638084.imp@harmony.village.org> <41DDC29F.9000002@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <41DDC29F.9000002@freebsd.org> User-Agent: Mutt/1.5.6i Subject: Re: pci powerstate related: aac(4) broken on Perc 3/Di on -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, 10 Jan 2005 02:04:32 -0000 0n Thu, Jan 06, 2005 at 03:58:39PM -0700, Scott Long wrote: >It should be noted that WinXP tried to get fancy in a similar way with >automatic powerdown of devices, and broke these PERC devices in a >similar way. Due to restrictions of the MS driver framework, the only >solution that Adaptec could use was to modify the firmware to make the >bridge be opaque. This solved the issue of the OS seeing devices that >belong to the firmware, but made it impossible to run the controller in >split-channel mode, where one channel is for RAID and the other channel >is pure SCSI. Scott, what is meant by "...to make the bridge be opaque." ? - aW From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 03:31:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E66016A4CE for ; Mon, 10 Jan 2005 03:31:31 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B527943D3F for ; Mon, 10 Jan 2005 03:31:30 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id j0A3Yo65037406; Sun, 9 Jan 2005 20:34:50 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <41E1F6AD.9040704@freebsd.org> Date: Sun, 09 Jan 2005 20:29:49 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Wilkinson, Alex" References: <20041223123621.GB17515@eddie.nitro.dk> <41CADACC.9050607@freebsd.org> <20050106131327.GE801@zaphod.nitro.dk> <20050106.134852.41638084.imp@harmony.village.org> <41DDC29F.9000002@freebsd.org> <20050110015842.GA24213@squash.dsto.defence.gov.au> In-Reply-To: <20050110015842.GA24213@squash.dsto.defence.gov.au> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-current@freebsd.org Subject: Re: pci powerstate related: aac(4) broken on Perc 3/Di on -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, 10 Jan 2005 03:31:31 -0000 Wilkinson, Alex wrote: > 0n Thu, Jan 06, 2005 at 03:58:39PM -0700, Scott Long wrote: > > > >It should be noted that WinXP tried to get fancy in a similar way with > >automatic powerdown of devices, and broke these PERC devices in a > >similar way. Due to restrictions of the MS driver framework, the only > >solution that Adaptec could use was to modify the firmware to make the > >bridge be opaque. This solved the issue of the OS seeing devices that > >belong to the firmware, but made it impossible to run the controller in > >split-channel mode, where one channel is for RAID and the other channel > >is pure SCSI. > > > Scott, what is meant by "...to make the bridge be opaque." ? > > - aW > A PCI-PCI bridge is opaque when it is set to not forward PCI config cycles across the bridge. In other words, the host CPU cannot see any devices past the first side of the bridge. However, normal data cycles work, so things like DMA work. This is incredibly useful for segregating the PCI hierarchy into sub-domains that are only visible within a specific scope, but allow data to travel across the domain boundaries. Many RAID cards are set up this way. Scott From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 04:01:24 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D155A16A4CE for ; Mon, 10 Jan 2005 04:01:24 +0000 (GMT) Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 528F243D1F for ; Mon, 10 Jan 2005 04:01:24 +0000 (GMT) (envelope-from jason@ec.rr.com) Received: from BARTON (cpe-065-184-201-054.ec.rr.com [65.184.201.54]) j0A41LCh020349 for ; Sun, 9 Jan 2005 23:01:21 -0500 (EST) Date: Mon, 10 Jan 2005 04:07:08 +0000 From: Jason Henson To: freebsd-current@freebsd.org References: <1105302297.9705.23.camel@kaiser.sig11.org> In-Reply-To: <1105302297.9705.23.camel@kaiser.sig11.org> (from rionda@gufi.org on Sun Jan 9 15:24:57 2005) X-Mailer: Balsa 2.2.6 Message-Id: <1105330028l.5495l.2l@BARTON> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: Re: firefox coredumping in recent 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, 10 Jan 2005 04:01:24 -0000 On 01/09/05 15:24:57, Matteo Riondato wrote: > Hi folks > I'm experimenting some core dumps with firefox on a recent current > (Jan > 2 2005). Firefox crashes during surfing, but there's no way to say =20 > "in > this page it will crash" because crashes seem to happen randomly. > The only message that appears on the command line is: >=20 > Fatal error 'Recurse on a private mutex.' at line 988 in > file /usr/src/lib/libpthread/thread/thr_mutex.c (errno =3D 0) > Abort trap (core dumped) >=20 > Hope this will help and that this is the right list where to post =20 > this > message... >=20 > Best Regards What options, if any, did you build with? -f options kill all the =20 chrome stuff from mozilla on my machince. From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 05:53:04 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D2B016A4CE; Mon, 10 Jan 2005 05:53:04 +0000 (GMT) Received: from arginine.spc.org (arginine.spc.org [195.206.69.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F45A43D1F; Mon, 10 Jan 2005 05:53:04 +0000 (GMT) (envelope-from bms@spc.org) Received: from localhost (localhost [127.0.0.1]) by arginine.spc.org (Postfix) with ESMTP id 412B2651EE; Mon, 10 Jan 2005 05:53:03 +0000 (GMT) Received: from arginine.spc.org ([127.0.0.1]) by localhost (arginine.spc.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 58351-03; Mon, 10 Jan 2005 05:53:02 +0000 (GMT) Received: from empiric.dek.spc.org (unknown [213.210.24.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by arginine.spc.org (Postfix) with ESMTP id 7F3C4651EB; Mon, 10 Jan 2005 05:53:02 +0000 (GMT) Received: by empiric.dek.spc.org (Postfix, from userid 1001) id A0E746530; Mon, 10 Jan 2005 05:53:09 +0000 (GMT) Date: Mon, 10 Jan 2005 05:53:09 +0000 From: Bruce M Simpson To: Julian Elischer Message-ID: <20050110055309.GG709@empiric.icir.org> References: <200501090750.j097oXj0020917@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501090750.j097oXj0020917@freefall.freebsd.org> cc: current@FreeBSD.org Subject: Re: got a "ucom" or "usio" device? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Jan 2005 05:53:04 -0000 On Sun, Jan 09, 2005 at 07:50:33AM +0000, Julian Elischer wrote: > http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/73799 > can you test the patch supplied above for your device? Apologies as this isn't directly related to this specific change, but the nature of the change. I think moving things out of usbd.conf is a good thing (as devd is a more general way of doing many of the things which usbd does). However, I should like to know how to go about converting the following usbd.conf entries to devd.conf and perhaps committing it, together with a port, for the convenience of those of us who use Bluetooth together with the rather common Broadcom chips which need firmware: %%% # Firmware download for Broadcom BCM2033 Bluetooth dongle. # # Requires that the ubtbcmfw.ko module is pre-loaded in order for the # pre-firmware device to be recognised. ng_ubt.ko should be pre-loaded # also, in order for the device to be connected to the Bluetooth stack. # # The firmware image files are not installed by default and should be # extracted from the Linux BlueZ firmware collection at: # http://www.bluez.org/download.html # device "Broadcom BCM2033 Bluetooth dongle" devname "ubtbcmfw[0-9]+" attach "/usr/sbin/bcmfw -n ${DEVNAME} -m /usr/local/share/usb/firmware/B CM2033-MD.hex -f /usr/local/share/usb/firmware/BCM2033-FW.bin" %%% I imagine something like the following would be required, but would appreciate a quick glance at it:- %%% attach 10 { device-name "ubtbcmfw[0-9]+"; action "/usr/sbin/bcmfw -n $device-name -m /usr/local/share/usb/firmware/BCM2033-MD.hex -f /usr/local/share/usb/firmware/BCM2033-FW.bin"; }; %%% Regards, BMS From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 07:27:54 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C62E16A4CE; Mon, 10 Jan 2005 07:27:54 +0000 (GMT) Received: from publicd.ub.mng.net (publicd.ub.mng.net [202.179.0.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7143243D49; Mon, 10 Jan 2005 07:27:52 +0000 (GMT) (envelope-from ganbold@micom.mng.net) Received: from [202.179.0.164] (helo=ganbold.micom.mng.net) by publicd.ub.mng.net with esmtpa (Exim 4.43 (FreeBSD)) id 1Cnu1t-0005rC-OP; Mon, 10 Jan 2005 15:31:58 +0800 Message-Id: <6.2.0.14.2.20050110151705.03f2f470@202.179.0.80> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 10 Jan 2005 15:27:33 +0800 To: freebsd-current@freebsd.org From: Ganbold Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed cc: rwatson@freebsd.org Subject: fxp0: device timed out problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 07:27:54 -0000 Hi, I'm having trouble on FreeBSD 5.3 with squid-2.5.7. Squid installed from ports collection. cache4# uname -an FreeBSD cache4.micom.mng.net 5.3-STABLE FreeBSD 5.3-STABLE #2: Wed Dec 15 18:26:14 ULAT 2004 tsgan@cache4.micom.mng.net:/usr/obj/usr/src/sys/CACHEK i386 After few hours machine hangs and stops responding saying following error: fxp0: device timed out. I turned off debug.mpsafenet to 0 and it seems like problem goes away. kernel compiled with following options: options MSGMNB=8192 # max # of bytes in a queue options MSGMNI=40 # number of message queue identifiers options MSGSEG=512 # number of message segments per queue options MSGSSZ=64 # size of a message segment options MSGTQL=2048 # max messages in system options IPFIREWALL options IPFIREWALL_DEFAULT_TO_ACCEPT options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPDIVERT #divert sockets options IPFIREWALL_FORWARD #packet destination changes device gre # GRE tunneling Is this problem related to network stack? Or is it related to fxp driver? thanks, Ganbold From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 12:09:43 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A28C116A4CE; Mon, 10 Jan 2005 12:09:43 +0000 (GMT) Received: from www.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEF8643D31; Mon, 10 Jan 2005 12:09:42 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.128] (sobohome.portaone.com [193.28.87.24]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j0AC9YGq058850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jan 2005 13:09:39 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <41E27076.8080904@portaone.com> Date: Mon, 10 Jan 2005 14:09:26 +0200 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org, current@freebsd.org Content-Type: multipart/mixed; boundary="------------040104060604090102080808" X-Virus-Scanned: ClamAV 0.80/589/Wed Nov 17 13:38:41 2004 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean Subject: Attempt to invoke connect(2) on already connected unix domaindatagram socket fails with ECONNRESET X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Jan 2005 12:09:43 -0000 This is a multi-part message in MIME format. --------------040104060604090102080808 Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Folks, I've discovered very strange behaviour of the connect(2) system call when it's called on already connected unix domain datagram socket. In this case connect(2) fails with ECONNRESET, which is weird. ECONNRESET is not even listed among possible return values of connect(2). I've confirmed this behaviour at 4.10 and 5.3 systems. Linux doesn't exhibit this (mis?)behaviour. As long as I can tell, this behaviour contradicts documentation, connect(2) manpage says: Generally, stream sockets may successfully connect() only once; datagram sockets may use connect() multiple times to change their association. Attached please find small test program which illustrates the problem. It forks itsels at the start, child becomes a server, while parent a client. After each transaction server closes unix domain socket and opens its again, while the client attempts to re-connect() to that unix domain socket using already created socket object. This mimics real-world scenario in which I've encountered the problem. In this scenarion, there are two distinct processes communicating using unix domain socket. Client uses connect() on already connected socket object for performance reasons to avoid calling socket(2) for each transaction. Everything works just fine until server is restarted. After that any attempts to send command from the client to the server fails with ECONNRESET until the client is restarted as well. -Maxim --------------040104060604090102080808 Content-Type: text/plain; name="socket_test.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="socket_test.c" #include #include #include #include #include #include #include #include #include #include #include #define UDS_NAME "/tmp/uds_test.sock" #define sstosa(ss) ((struct sockaddr *)(ss)) static pid_t pid_kill; void prepare_ifsun(struct sockaddr_un *ifsun) { static char ch = '1' * 2; memset(ifsun, '\0', sizeof(*ifsun)); #if !defined(__linux__) && !defined(__solaris__) ifsun->sun_len = strlen(UDS_NAME); #endif ifsun->sun_family = AF_LOCAL; strcpy(ifsun->sun_path, UDS_NAME); //ifsun->sun_path[ifsun->sun_len - 1] = ch / 2; ch++; } int create_uds_server(void) { struct sockaddr_un ifsun; int sock; prepare_ifsun(&ifsun); unlink(ifsun.sun_path); sock = socket(PF_LOCAL, SOCK_DGRAM, 0); if (sock == -1) err(1, "server: can't create socket"); setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &sock, sizeof(sock)); if (bind(sock, sstosa(&ifsun), sizeof(ifsun)) < 0) err(1, "server: can't bind to a socket"); return sock; } void connect_uds_server(int sock) { struct sockaddr_un ifsun; prepare_ifsun(&ifsun); if (connect(sock, sstosa(&ifsun), sizeof(ifsun)) < 0) err(1, "client: can't connect to a socket"); } static void cleanup(void) { kill(pid_kill, SIGKILL); } int main() { int sock, len; pid_t pid; pid = fork(); if (pid < 0) err(1, "can't fork"); pid_kill = getpid(); if (pid != 0) { /* Parent */ pid_kill = pid; atexit(cleanup); sock = socket(PF_LOCAL, SOCK_DGRAM, 0); if (sock < 0) err(1, "client: can't create socket"); for (;;) { sleep(1); connect_uds_server(sock); len = write(sock, &pid, sizeof(pid)); if (len < 0) err(1, "client: can't write to a socket"); printf("client: wrote %d bytes to the socket\n", len); } } else { /* Child */ atexit(cleanup); for (;;) { sock = create_uds_server(); len = recvfrom(sock, &pid, sizeof(pid), 0, NULL, NULL); if (len < 0) err(1, "server: can't read from a socket"); printf("server: read %d bytes from the socket\n", len); close(sock); } } exit (1); } --------------040104060604090102080808-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 13:15:33 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8911416A4CE for ; Mon, 10 Jan 2005 13:15:33 +0000 (GMT) Received: from gateway.nixsys.be (gateway.nixsys.be [195.144.77.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id E594343D48 for ; Mon, 10 Jan 2005 13:15:32 +0000 (GMT) (envelope-from philip@nixsys.be) Received: from loge.nixsys.be (loge.nixsys.be [IPv6:2001:838:37f:0:20c:6eff:fe4b:23f]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "loge.home.paeps.cx", Issuer "NixSys CA" (verified OK)) by gateway.nixsys.be (Postfix) with ESMTP id 0F718C196 for ; Mon, 10 Jan 2005 14:15:30 +0100 (CET) Received: from loge.nixsys.be (philip@localhost [127.0.0.1]) by loge.nixsys.be (8.13.1/8.13.1) with ESMTP id j0ADFTWO000782 for ; Mon, 10 Jan 2005 14:15:29 +0100 (CET) (envelope-from philip@loge.nixsys.be) Received: (from philip@localhost) by loge.nixsys.be (8.13.1/8.13.1/Submit) id j0ADFTGE000781 for current@freebsd.org; Mon, 10 Jan 2005 14:15:29 +0100 (CET) (envelope-from philip) Date: Mon, 10 Jan 2005 14:15:29 +0100 From: Philip Paeps To: current@freebsd.org Message-ID: <20050110131529.GA716@loge.nixsys.be> Mail-Followup-To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Date-in-Rome: ante diem IV Idius Ianuarias MMDCCLVIII ab Urbe Condida X-PGP-Fingerprint: FA74 3C27 91A6 79D5 F6D3 FC53 BF4B D0E6 049D B879 X-Message-Flag: Get a proper mailclient! Organization: Happily Disorganized User-Agent: Mutt/1.5.6i Subject: [PLEASE TEST] Many improvements to Synaptics support in psm(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Jan 2005 13:15:33 -0000 I just committed a patch to -current which greatly improves support in psm(4) for Synaptics touchpads. Owners of these gadgets are encouraged to test this. If it turns out to work well, I'll enable support by default. For now, to get the new behaviour, you need to set hw.psm.synaptics_support=1 in /boot/loader.conf. Please also fiddle with the stickiness sysctls. The quest for finding perfect values is still on... Thanks! - Philip ----- Forwarded message from Philip Paeps ----- philip 2005-01-10 13:05:58 UTC FreeBSD src repository Modified files: sys/isa psm.c Log: Make life for owners of Synaptics Touchpads more pleasant :-) o Implement a shiny new algorithm to keep track of finger movement at slow speeds. This dramatically reduces the level of questionable language from users trying to resize windows. o Properly catch the many extra buttons and dials which manufacturers are known to screw onto Synaptics touchpad controllers. Currently, up to seven buttons are known to work, more should work too. o Add a number of sysctls allowing one to tune the driver to taste in a simple way: # Should the extra buttons act as axes or as middle button hw.psm.synaptics.directional_scrolls # These control the 'stickiness' at low speeds hw.psm.synaptics.low_speed_threshold hw.psm.synaptics.min_movement hw.psm.synaptics.squelch_level PR: kern/75725 Submitted by: Jason Kuri MFC after: 1 month Revision Changes Path 1.84 +207 -11 src/sys/isa/psm.c ----- End forwarded message ----- -- Philip Paeps Please don't Cc me, I am philip@freebsd.org subscribed to the list. BOFH Excuse #438: sticky bit has come loose From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 14:59:12 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C7EC16A4CE; Mon, 10 Jan 2005 14:59:12 +0000 (GMT) Received: from www.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC94143D2F; Mon, 10 Jan 2005 14:59:11 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.1.26] (SIRIUS-ats227-UTC.ukrtel.net [195.5.25.154]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j0AEx7VT079060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jan 2005 15:59:09 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <41E29838.9020805@portaone.com> Date: Mon, 10 Jan 2005 16:59:04 +0200 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org References: <41E27076.8080904@portaone.com> In-Reply-To: <41E27076.8080904@portaone.com> Content-Type: multipart/mixed; boundary="------------040309000406060207060002" X-Virus-Scanned: ClamAV 0.80/589/Wed Nov 17 13:38:41 2004 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean cc: current@freebsd.org Subject: Re: Attempt to invoke connect(2) on already connected unix domain datagram socket fails with ECONNRESET X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Jan 2005 14:59:12 -0000 This is a multi-part message in MIME format. --------------040309000406060207060002 Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Further investigation revealed that the said problem only happens when the program is trying to re-connect() socket object which previously has been connected to the unix domain socket closed on the server side at the time when the second connect() is called. Attached please find more simple testcase. -Maxim Maxim Sobolev wrote: > Folks, > > I've discovered very strange behaviour of the connect(2) system call > when it's called on already connected unix domain datagram socket. In > this case connect(2) fails with ECONNRESET, which is weird. ECONNRESET > is not even listed among possible return values of connect(2). I've > confirmed this behaviour at 4.10 and 5.3 systems. Linux doesn't exhibit > this (mis?)behaviour. > > As long as I can tell, this behaviour contradicts documentation, > connect(2) manpage says: > > Generally, stream sockets may successfully connect() only > once; datagram sockets may use connect() multiple times to change > their association. > > Attached please find small test program which illustrates the problem. > It forks itsels at the start, child becomes a server, while parent a > client. After each transaction server closes unix domain socket and > opens its again, while the client attempts to re-connect() to that unix > domain socket using already created socket object. > > This mimics real-world scenario in which I've encountered the problem. > In this scenarion, there are two distinct processes communicating using > unix domain socket. Client uses connect() on already connected socket > object for performance reasons to avoid calling socket(2) for each > transaction. Everything works just fine until server is restarted. After > that any attempts to send command from the client to the server fails > with ECONNRESET until the client is restarted as well. > > -Maxim --------------040309000406060207060002 Content-Type: text/plain; name="socket_test1.c" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="socket_test1.c" #include #include #include #include #include #include #include #include #include #include #include #include #define UDS_NAME1 "/tmp/uds_test.sock1" #define UDS_NAME2 "/tmp/uds_test.sock2" #define sstosa(ss) ((struct sockaddr *)(ss)) void prepare_ifsun(struct sockaddr_un *ifsun, const char *path) { memset(ifsun, '\0', sizeof(*ifsun)); #if !defined(__linux__) && !defined(__solaris__) ifsun->sun_len = strlen(path); #endif ifsun->sun_family = AF_LOCAL; strcpy(ifsun->sun_path, path); } int create_uds_server(const char *path) { struct sockaddr_un ifsun; int sock; prepare_ifsun(&ifsun, path); unlink(ifsun.sun_path); sock = socket(PF_LOCAL, SOCK_DGRAM, 0); if (sock == -1) err(1, "server: can't create socket"); setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, &sock, sizeof(sock)); if (bind(sock, sstosa(&ifsun), sizeof(ifsun)) < 0) err(1, "server: can't bind to a socket"); return sock; } void connect_uds_server(int sock, const char *path) { struct sockaddr_un ifsun; int e; prepare_ifsun(&ifsun, path); e = connect(sock, sstosa(&ifsun), sizeof(ifsun)); if (e < 0) err(1, "client: can't connect to a socket"); } int main() { int s_sock1, s_sock2, c_sock; s_sock1 = create_uds_server(UDS_NAME1); s_sock2 = create_uds_server(UDS_NAME2); c_sock = socket(PF_LOCAL, SOCK_DGRAM, 0); if (c_sock < 0) err(1, "client: can't create socket"); connect_uds_server(c_sock, UDS_NAME1); close(s_sock1); connect_uds_server(c_sock, UDS_NAME2); exit (0); } --------------040309000406060207060002-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 16:21:00 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3CE616A4CE for ; Mon, 10 Jan 2005 16:20:59 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75FDA43D4C for ; Mon, 10 Jan 2005 16:20:59 +0000 (GMT) (envelope-from geekout@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so195522wri for ; Mon, 10 Jan 2005 08:20:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=aKVITFglIhvrtBEJWuh0gZRUwR54VHFD5MH5Yp8Ew9mkPw1RvTnulwDnY1i+MAoxd33O03drH6zyLpUko6Y2Td7Vw3PYR/dbv2upnCas+xtSRvK4+IG35aMLYSH6/Gz2C6ZbOZpY/bo9fSJM0aKoinFhnfUAdnp+KzStU7bgdEw= Received: by 10.54.29.76 with SMTP id c76mr315003wrc; Mon, 10 Jan 2005 08:20:58 -0800 (PST) Received: by 10.54.46.25 with HTTP; Mon, 10 Jan 2005 08:20:58 -0800 (PST) Message-ID: <6e01203b05011008207cfee1bc@mail.gmail.com> Date: Mon, 10 Jan 2005 09:20:58 -0700 From: Tyler Gee To: Jason Henson In-Reply-To: <1105330028l.5495l.2l@BARTON> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1105302297.9705.23.camel@kaiser.sig11.org> <1105330028l.5495l.2l@BARTON> cc: freebsd-current@freebsd.org Subject: Re: firefox coredumping in recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Tyler Gee List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 16:21:00 -0000 I have been experiencing the same problems so I tried a build without optimization and without debugging and still had problems. I tried one with just debugging and still had problems. More to come... -wtgee On Mon, 10 Jan 2005 04:07:08 +0000, Jason Henson wrote: > On 01/09/05 15:24:57, Matteo Riondato wrote: > > Hi folks > > I'm experimenting some core dumps with firefox on a recent current > > (Jan > > 2 2005). Firefox crashes during surfing, but there's no way to say > > "in > > this page it will crash" because crashes seem to happen randomly. > > The only message that appears on the command line is: > > > > Fatal error 'Recurse on a private mutex.' at line 988 in > > file /usr/src/lib/libpthread/thread/thr_mutex.c (errno = 0) > > Abort trap (core dumped) > > > > Hope this will help and that this is the right list where to post > > this > > message... > > > > Best Regards > > What options, if any, did you build with? -f options kill all the > chrome stuff from mozilla on my machince. > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 16:40:02 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A62116A4CE for ; Mon, 10 Jan 2005 16:40:02 +0000 (GMT) Received: from amber.aeternal.net (amber.in.markiza.sk [62.168.76.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 558D143D48 for ; Mon, 10 Jan 2005 16:40:01 +0000 (GMT) (envelope-from corwin@pleiades.aeternal.net) Received: from localhost (localhost.aeternal.net [127.0.0.1]) by amber.aeternal.net (Postfix) with ESMTP id 32867B853 for ; Mon, 10 Jan 2005 17:43:42 +0100 (CET) Received: from amber.aeternal.net ([127.0.0.1]) by localhost (amber.aeternal.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09095-08 for ; Mon, 10 Jan 2005 17:43:41 +0100 (CET) Received: from pleiades.aeternal.net (pleiades.markiza.sk [192.168.0.7]) by amber.aeternal.net (Postfix) with ESMTP id 34C1FB84E for ; Mon, 10 Jan 2005 17:43:41 +0100 (CET) Received: from pleiades.aeternal.net (localhost.aeternal.net [127.0.0.1]) by pleiades.aeternal.net (Postfix) with ESMTP id 2CC577E80B for ; Mon, 10 Jan 2005 17:39:56 +0100 (CET) Received: (from corwin@localhost) by pleiades.aeternal.net (8.13.1/8.13.1/Submit) id j0AGdsKn075550 for freebsd-current@freebsd.org; Mon, 10 Jan 2005 17:39:54 +0100 (CET) (envelope-from corwin) Date: Mon, 10 Jan 2005 17:39:54 +0100 From: martin hudec To: freebsd-current@freebsd.org Message-ID: <20050110163954.GB738@pleiades.aeternal.net> References: <1105302297.9705.23.camel@kaiser.sig11.org> <1105330028l.5495l.2l@BARTON> <6e01203b05011008207cfee1bc@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SkvwRMAIpAhPCcCJ" Content-Disposition: inline In-Reply-To: <6e01203b05011008207cfee1bc@mail.gmail.com> X-Copyright: (C) 2004 Martin Hudec X-Operating-System: FreeBSD pleiades.aeternal.net 6.0-CURRENT i386 X-PGP-Key: http://www.aeternal.net/corwin_aeternal.asc User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at aeternal.net Subject: Re: firefox coredumping in recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: martin hudec List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 16:40:02 -0000 --SkvwRMAIpAhPCcCJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, On Mon, Jan 10, 2005 at 09:20:58AM -0700 or thereabouts, Tyler Gee wrote: > I have been experiencing the same problems so I tried a build without > optimization and without debugging and still had problems. I tried > one with just debugging and still had problems. I am using Firefox (firefox-1.0_7,1 built on Jan 03, 2005 with WITH_SMB=3Dyes) on CURRENT built on Jan 03, 2005 without any problems. Firefox was built after CURRENT installworld. My flags from make.conf are as: CPUTYPE?=3Dathlon-xp and CFLAGS=3D-O -pipe. Just reporting. Cheers, Martin --=20 martin hudec * 421 907 303 393 * corwin@aeternal.net * http://www.aeternal.net "Nothing travels faster than the speed of light with the possible=20 exception of bad news, which obeys its own special laws." Douglas Adams, "The Hitchhiker's Guide to the Galaxy" --SkvwRMAIpAhPCcCJ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB4q/aZYEZIv+rgggRAtKAAJ0cHZF4oUgh69cpgc0TqJZGvccTGQCfZxGM IKTviPxHZizdFYKqqiHFxrk= =tolt -----END PGP SIGNATURE----- --SkvwRMAIpAhPCcCJ-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 16:45:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 040CB16A4CE for ; Mon, 10 Jan 2005 16:45:57 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8441443D39 for ; Mon, 10 Jan 2005 16:45:56 +0000 (GMT) (envelope-from geekout@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so104720wri for ; Mon, 10 Jan 2005 08:45:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=prgOx7kwsscALFgNUov10Xxlu8x2DtniH61aVQn+CkYG1D0JgPtK88rgFW9Q7YwsORKlawRendbGaF2phBf3//Wv36fHeFRxTuNIFtU95geQwVZjAG4hnYzal/v1bzAqfbJQw65UZw1SnJasvsC/ghU0kOOraM30uLpVGxf+ovw= Received: by 10.54.27.49 with SMTP id a49mr481936wra; Mon, 10 Jan 2005 08:45:55 -0800 (PST) Received: by 10.54.46.25 with HTTP; Mon, 10 Jan 2005 08:45:55 -0800 (PST) Message-ID: <6e01203b05011008457519f49d@mail.gmail.com> Date: Mon, 10 Jan 2005 09:45:55 -0700 From: Tyler Gee To: martin hudec In-Reply-To: <20050110163954.GB738@pleiades.aeternal.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1105302297.9705.23.camel@kaiser.sig11.org> <1105330028l.5495l.2l@BARTON> <6e01203b05011008207cfee1bc@mail.gmail.com> <20050110163954.GB738@pleiades.aeternal.net> cc: freebsd-current@freebsd.org Subject: Re: firefox coredumping in recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Tyler Gee List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 16:45:57 -0000 Thanks for the report Martin, I will try it with those settings next (well, except for the cpu). I was trying to figure out if it had something to do with xorg 6.8 as I was on a patched version from before the official port. Anyone else having problems with firefox have anything special with xorg? -wtgee On Mon, 10 Jan 2005 17:39:54 +0100, martin hudec wrote: > Hello, > > On Mon, Jan 10, 2005 at 09:20:58AM -0700 or thereabouts, Tyler Gee wrote: > > I have been experiencing the same problems so I tried a build without > > optimization and without debugging and still had problems. I tried > > one with just debugging and still had problems. > > I am using Firefox (firefox-1.0_7,1 built on Jan 03, 2005 with > WITH_SMB=yes) on CURRENT built on Jan 03, 2005 without any problems. > Firefox was built after CURRENT installworld. My flags from make.conf > are as: CPUTYPE?=athlon-xp and CFLAGS=-O -pipe. Just reporting. > > Cheers, > > Martin > > -- > martin hudec > > * 421 907 303 393 > * corwin@aeternal.net > * http://www.aeternal.net > > "Nothing travels faster than the speed of light with the possible > exception of bad news, which obeys its own special laws." > > Douglas Adams, "The Hitchhiker's Guide to the Galaxy" > > > From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 16:46:24 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C8DD16A4CE; Mon, 10 Jan 2005 16:46:24 +0000 (GMT) Received: from www.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5F0A43D45; Mon, 10 Jan 2005 16:46:22 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.1.26] (SIRIUS-ats227-UTC.ukrtel.net [195.5.25.154]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j0AGkJ03093388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jan 2005 17:46:20 +0100 (CET) (envelope-from sobomax@portaone.com) Message-ID: <41E2B157.3080306@portaone.com> Date: Mon, 10 Jan 2005 18:46:15 +0200 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@FreeBSD.ORG References: <41E27076.8080904@portaone.com> <41E29838.9020805@portaone.com> In-Reply-To: <41E29838.9020805@portaone.com> Content-Type: multipart/mixed; boundary="------------070202070809080104090402" X-Virus-Scanned: ClamAV 0.80/589/Wed Nov 17 13:38:41 2004 clamav-milter version 0.80j on www.portaone.com X-Virus-Status: Clean cc: current@FreeBSD.ORG Subject: Re: Attempt to invoke connect(2) on already connected unix domain datagram socket fails with ECONNRESET X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Jan 2005 16:46:24 -0000 This is a multi-part message in MIME format. --------------070202070809080104090402 Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit Maxim Sobolev wrote: > Further investigation revealed that the said problem only happens when > the program is trying to re-connect() socket object which previously has > been connected to the unix domain socket closed on the server side at > the time when the second connect() is called. Attached please find more > simple testcase. It seems that I've found source of the problem. It is caused by the fact that when server closes its side of unix domain socket it causes unp_drop(ref, ECONNRESET) to be called on client side of the connection, which in turn results in so_error member of client's struct socket to be set to ECONNRESET. Since we don't do any more reads on the client side of the connection, this error is never cleared up and then being picked up as a connection error by kern_connect() routine, which is obviously incorrect. The funny thing is that despite that error (ECONNRESET) one can still use resulting socket like if no error has happened. Attached please find which I believe should fix the problem in question. I would appreciate if somebody can review it. Thanks in advance! Regards, Maxim --------------070202070809080104090402 Content-Type: text/plain; name="diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="diff" Index: uipc_socket.c =================================================================== RCS file: /home/ncvs/src/sys/kern/uipc_socket.c,v retrieving revision 1.208.2.6 diff -d -u -r1.208.2.6 uipc_socket.c --- uipc_socket.c 16 Nov 2004 08:15:07 -0000 1.208.2.6 +++ uipc_socket.c 10 Jan 2005 16:23:07 -0000 @@ -530,10 +530,19 @@ */ if (so->so_state & (SS_ISCONNECTED|SS_ISCONNECTING) && ((so->so_proto->pr_flags & PR_CONNREQUIRED) || - (error = sodisconnect(so)))) + (error = sodisconnect(so)))) { error = EISCONN; - else + } else { + SOCK_LOCK(so); + /* + * Prevent accumulated error from previous connection + * from biting us. + */ + so->so_error = 0; + SOCK_UNLOCK(so); error = (*so->so_proto->pr_usrreqs->pru_connect)(so, nam, td); + } + return (error); } --------------070202070809080104090402-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 16:53:58 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8A4616A4CE for ; Mon, 10 Jan 2005 16:53:58 +0000 (GMT) Received: from amber.aeternal.net (amber.in.markiza.sk [62.168.76.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 396E943D3F for ; Mon, 10 Jan 2005 16:53:58 +0000 (GMT) (envelope-from corwin@pleiades.aeternal.net) Received: from localhost (localhost.aeternal.net [127.0.0.1]) by amber.aeternal.net (Postfix) with ESMTP id DAF46B853 for ; Mon, 10 Jan 2005 17:57:41 +0100 (CET) Received: from amber.aeternal.net ([127.0.0.1]) by localhost (amber.aeternal.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09379-04 for ; Mon, 10 Jan 2005 17:57:39 +0100 (CET) Received: from pleiades.aeternal.net (pleiades.markiza.sk [192.168.0.7]) by amber.aeternal.net (Postfix) with ESMTP id 4DCA5B84E for ; Mon, 10 Jan 2005 17:57:39 +0100 (CET) Received: from pleiades.aeternal.net (localhost.aeternal.net [127.0.0.1]) by pleiades.aeternal.net (Postfix) with ESMTP id 8467E7E80B for ; Mon, 10 Jan 2005 17:53:54 +0100 (CET) Received: (from corwin@localhost) by pleiades.aeternal.net (8.13.1/8.13.1/Submit) id j0AGrsH3092416 for freebsd-current@freebsd.org; Mon, 10 Jan 2005 17:53:54 +0100 (CET) (envelope-from corwin) Date: Mon, 10 Jan 2005 17:53:54 +0100 From: martin hudec To: freebsd-current@freebsd.org Message-ID: <20050110165354.GC738@pleiades.aeternal.net> References: <1105302297.9705.23.camel@kaiser.sig11.org> <1105330028l.5495l.2l@BARTON> <6e01203b05011008207cfee1bc@mail.gmail.com> <20050110163954.GB738@pleiades.aeternal.net> <6e01203b05011008457519f49d@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KDt/GgjP6HVcx58l" Content-Disposition: inline In-Reply-To: <6e01203b05011008457519f49d@mail.gmail.com> X-Copyright: (C) 2004 Martin Hudec X-Operating-System: FreeBSD pleiades.aeternal.net 6.0-CURRENT i386 X-PGP-Key: http://www.aeternal.net/corwin_aeternal.asc User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at aeternal.net Subject: Re: firefox coredumping in recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: martin hudec List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 16:53:58 -0000 --KDt/GgjP6HVcx58l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, On Mon, Jan 10, 2005 at 09:45:55AM -0700 or thereabouts, Tyler Gee wrote: > Thanks for the report Martin, I will try it with those settings next > (well, except for the cpu). :), mine are pretty conservative ones :), I was never really excited about setting various flags (like my friend is with gentoo linux) and running for few more percents to overall performance of my box. > I was trying to figure out if it had something to do with xorg 6.8 as > I was on a patched version from before the official port. Anyone else > having problems with firefox have anything special with xorg? Forgot to mention that after installworld and following firefox upgrade I was using old xorg 6.7, later last week (around friday) I have upgraded to xorg 6.8.1. Cheers, Martin --=20 martin hudec * 421 907 303 393 * corwin@aeternal.net * http://www.aeternal.net "Nothing travels faster than the speed of light with the possible=20 exception of bad news, which obeys its own special laws." Douglas Adams, "The Hitchhiker's Guide to the Galaxy" --KDt/GgjP6HVcx58l Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB4rMiZYEZIv+rgggRAqOHAJ9Oqv5BfQEYyX87cD819ChIkKYPbwCePDfG 6T0x7okPh7vtE38gzHg6Oiw= =1xh4 -----END PGP SIGNATURE----- --KDt/GgjP6HVcx58l-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 17:47:53 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4C0116A4CE; Mon, 10 Jan 2005 17:47:53 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57F5143D54; Mon, 10 Jan 2005 17:47:53 +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 j0AHoLor017867; Mon, 10 Jan 2005 09:50:22 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j0AHoJ05017864; Mon, 10 Jan 2005 09:50:19 -0800 Date: Mon, 10 Jan 2005 09:50:19 -0800 From: Brooks Davis To: Jose M Rodriguez Message-ID: <20050110175019.GA15907@odin.ac.hmc.edu> References: <41DDC4F2.5090709@yahoo.com> <20050107003806.GA14003@odin.ac.hmc.edu> <41DE5242.4030606@redesjm.local> <20050107182024.GB30931@odin.ac.hmc.edu> <41E16B3C.30302@redesjm.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oyUTqETQ0mS9luUI" Content-Disposition: inline In-Reply-To: <41E16B3C.30302@redesjm.local> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: Rob cc: freebsd-current cc: x11@freebsd.org Subject: Re: Xorg ICE vs. Xfce4 (4.2-RC3) needs fixing /etc/rc.d/cleartmp X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Jan 2005 17:47:53 -0000 --oyUTqETQ0mS9luUI Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jan 09, 2005 at 06:34:52PM +0100, Jose M Rodriguez wrote: > Brooks Davis escribi=F3: >=20 > >On Fri, Jan 07, 2005 at 10:11:30AM +0100, Jose M Rodriguez wrote: > >=20 > > > >>Brooks Davis escribi=F3: > >> > >> =20 > >> > >>>Could you please try the following patch? It does the same thing, but > >>>gives the inode paranoid a way to disable the creation of these > >>>directories or only create the ones they need. > >>> > >>>-- Brooks > >>> > >>>Index: rc.d/cleartmp > >>>=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: /usr/cvs/src/etc/rc.d/cleartmp,v > >>>retrieving revision 1.11 > >>>diff -u -p -r1.11 cleartmp > >>>--- rc.d/cleartmp 7 Oct 2004 13:55:25 -0000 1.11 > >>>+++ rc.d/cleartmp 7 Jan 2005 00:31:51 -0000 > >>>@@ -35,5 +35,7 @@ run_rc_command "$1" > >>># restarting X > >>># > >>>rm -f /tmp/.X[0-9]-lock > >>>-rm -fr /tmp/.X11-unix > >>>-mkdir -m 1777 /tmp/.X11-unix > >>>+if [ -n ${clear_tmp_xdirs} ]; then > >>>+ rm -fr ${clear_tmp_xdirs} > >>>+ mkdir -m 1777 ${clear_tmp_xdirs} > >>>+fi > >>>Index: defaults/rc.conf > >>>=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: /usr/cvs/src/etc/defaults/rc.conf,v > >>>retrieving revision 1.235 > >>>diff -u -p -r1.235 rc.conf > >>>--- defaults/rc.conf 15 Dec 2004 12:39:28 -0000 1.235 > >>>+++ defaults/rc.conf 7 Jan 2005 00:30:49 -0000 > >>>@@ -443,6 +443,8 @@ linux_enable=3D"NO" # Linux binary compati > >>>svr4_enable=3D"NO" # SysVR4 emulation loaded at startup (or NO). > >>>osf1_enable=3D"NO" # Alpha OSF/1 emulation loaded at startup (or NO). > >>>clear_tmp_enable=3D"NO" # Clear /tmp at startup. > >>>+clear_tmp_xdirs=3D"/tmp/.X11-unix /tmp/.font-unix /tmp/.ICE-unix" > >>>+ # Directories needed by X11 > >>>ldconfig_insecure=3D"NO" # Set to YES to disable ldconfig security=20 > >>>checks > >>>ldconfig_paths=3D"/usr/lib/compat /usr/X11R6/lib /usr/local/lib=20 > >>>/usr/local/lib/compat/pkg" > >>> # shared library search paths > >>> > >>> > >>> > >>> =20 > >>> > >>I recall putting this in a conf PR, try a follow-up. > >> > >>But I think your patch is a little bit wrong > >> > >>I never like the way X11 is taken by /etc/rc.d/cleartmp. none must b= e=20 > >>do after the run_rc_command. > >> =20 > >> > > > >That's easy enough to fix. > > > >=20 > > > >>If we need do this from the base system (Thing that I doubt more and=20 > >>more), this must be implementing a new /etc/rc.d/clearx11tmp (this may= =20 > >>be do in the main /etc/rc.d/cleartmp, like in sendmail), with all the= =20 > >>bits: > >>clear_x11tmp_enable, clear_x11tmp_dirs, ... > >> > >>But I must point that: > >> > >>X11 is now mostly a ports thing, not a base system component. If this= =20 > >>can be take from ports (I send-pr this also), this must be the path to= =20 > >>the solution. I put a simple script from libs, but I can work and rcNG= =20 > >>enabled thing if prefered. > >> > >>This is not what x11 really needs. x11 only needs some like this: mkdi= r=20 > >>-p ... && chown root:wheel ... && chmod 01777 ... . this may be=20 > >>prefered by the x11 team. > >> > >>This can be taken both from base and ports without too much problem. = =20 > >>The only secondary effect of this I know is that you may polite /tmp=20 > >>entries twice, with is not a real pain to the whole boot process. > >> =20 > >> > > > >My worry with using your patch is that localpkg is run quite late in the > >startup process, well after X may have tried to start if xdm is run from > >/etc/ttys. If package startup scripts could run anywhere in the order, > >a script in the port would be obvious solution, but that's not the case. > > > You're molsty wrong. init launch gettys after rc has finished (and also= =20 > localpkg). You are correct. According to "The Design and Implementation of the FreeBSD Operating System" init does not spawn processes ttys until after /etc/rc exits sucessfully. Good luck getting your port commited, I'm done with this issue. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --oyUTqETQ0mS9luUI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFB4sBaXY6L6fI4GtQRAopRAKCv9tX9Dc2Qa6R/ztD+roK+OjJMdACePg87 8UfuVHbxkY6/+k7mNyJTMnU= =ZdJP -----END PGP SIGNATURE----- --oyUTqETQ0mS9luUI-- From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 18:51:07 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D881816A4CE for ; Mon, 10 Jan 2005 18:51:07 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30CFF43D55 for ; Mon, 10 Jan 2005 18:51:07 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])j0AIp4s1022157; Mon, 10 Jan 2005 13:51:04 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.2/8.12.1/Submit) id j0AIp4iN022156; Mon, 10 Jan 2005 13:51:04 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Mon, 10 Jan 2005 13:51:04 -0500 From: Bosko Milekic To: Peter Holm Message-ID: <20050110185104.GA22091@technokratis.com> References: <20041220234103.GA59225@technokratis.com> <20041222210553.GA28108@peter.osted.lan> <20041222221540.GA70052@technokratis.com> <20041226161153.GA74592@peter.osted.lan> <20041226181738.GA21533@technokratis.com> <20041226225651.GA87178@peter.osted.lan> <20041227013745.GA5267@technokratis.com> <20041227040216.GA44588@technokratis.com> <20041228084731.GA766@peter.osted.lan> <20041228135339.GA80377@technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041228135339.GA80377@technokratis.com> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: panic: uma_zone_slab is looping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Jan 2005 18:51:08 -0000 Peter, Any updates? should I commit the fix I sent you? -Bosko On Tue, Dec 28, 2004 at 08:53:39AM -0500, Bosko Milekic wrote: > > On Tue, Dec 28, 2004 at 09:47:31AM +0100, Peter Holm wrote: > > On Sun, Dec 26, 2004 at 11:02:16PM -0500, Bosko Milekic wrote: > > > > I'll have to reserve some more time to think about this. One way I > > > > think it might be solvable would be to change that check that > > > > triggers the NULL return explicitly check for the bucketzone, and not > > > > for all UMA_ZONE_INTERNAL zones; I need to think this through a little > > > > more. > > > > > > Please try the attached patch and let me know if with it you can or > > > cannot trigger the original (seemingly infinite) looping. Although I > > > still haven't quite figured out how the described scenario could lead > > > to infinite looping exactly (I did conclude that it could lead to some > > > looping, though), the patch is worth trying as I believe the scenario > > > *could* occur. > > > > > > > After more than 18 hours of testing with your patch I ran into a > > (unrelated ?) "panic: mutex vm object not owned": > > http://www.holm.cc/stress/log/freeze06.html > > Your other (private) Email to me mentions that another developer has > claimed this one. If/when he fixes it, it would be worthwhile to give > it another consecutive 18 hours before we decide that "yes, it's good > and it works." I am optimistic, but we have to be thorough. > > Good work, so far! > > Cheers, > -- > Bosko Milekic > bmilekic@technokratis.com > bmilekic@FreeBSD.org > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 19:03:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F341C16A4CE for ; Mon, 10 Jan 2005 19:03:09 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79E9D43D45 for ; Mon, 10 Jan 2005 19:03:09 +0000 (GMT) (envelope-from dettloff@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so125120wri for ; Mon, 10 Jan 2005 11:03:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=OSAPrOp/+6Qe3eTXqoEQKLfhz7sBLddfPY8CLP5PI4DVkmk4VIzRc7OLYhQbzg6rcSaelNUwYIsvZbJvnsiyFWPglFXTQEMWvsI6nE1hhmq3oNzPN/5mMET0ljnsSHserkfh8kgm58ipIFDBGBC3hsZ9GR8ltlyWs8LXWlskCgQ= Received: by 10.54.27.49 with SMTP id a49mr558784wra; Mon, 10 Jan 2005 11:03:07 -0800 (PST) Received: by 10.54.8.66 with HTTP; Mon, 10 Jan 2005 11:03:07 -0800 (PST) Message-ID: <5b0444b5050110110339c7b3e8@mail.gmail.com> Date: Mon, 10 Jan 2005 20:03:07 +0100 From: Tim Dettloff To: Richard Cadwalader In-Reply-To: <200501061255.47218.richard@howitsdone.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200501050830.36906.richard@howitsdone.net> <200501050943.11320.richard@howitsdone.net> <84dead72050106094231b43492@mail.gmail.com> <200501061255.47218.richard@howitsdone.net> cc: freebsd-current@freebsd.org Subject: Re: pkg_add looking in the wrong place X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Tim Dettloff List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 19:03:10 -0000 Try printenv See the printenv and your shells man page. The default shell for FreeBSD is tcsh. >Tim. On Thu, 6 Jan 2005 12:55:43 -0600, Richard Cadwalader wrote: > I don't mean to sound like a moron, I know that certainly most of you folks on > this mailing list have enough to do without holding my hand, but where does > one set the environment variables? > > I cvsup'd ports and the src tree, and I've installed stuff, it's just now that > I am having trouble...I install things by going to the ftp site and getting > the packages I need, but isn't there some config file somewhere that tells > pkg_add where to go? > > the output: > # sysctl kern.osreldate > kern.osreldate: 503101 > > On Thursday 06 January 2005 11:42, Joseph Koshy wrote: > > > gigaping# uname -a > > > FreeBSD gigaping.gigaping 5.3-STABLE FreeBSD 5.3-STABLE #1: Mon Jan 3 > > > 11:25:50CST 2005 > > > gigaping@gigaping.gigaping:/usr/src/sys/i386/compile/GIGAPING i386 > > > gigaping# > > > > Please check that you don't have environment > > variables PACKAGESITE or PACKAGEROOT set. > > > > If these are not set, please check the output of 'sysctl > > kern.osreldate'. This should be a number between > > 503000 and 599000 if you are running 5.3-STABLE. > > > > If not, it is likely that your system may not have been > > updated using the recommended upgrade procedure in the > > Handbook. > > > > [snip] > > > > > what does all that mean up there? > > > > There is an explanation of uname's output in its manual > > page (man uname). > > _______________________________________________ > > 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" > > -- > Richard Cadwalader > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 19:42:23 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1864616A4CE for ; Mon, 10 Jan 2005 19:42:23 +0000 (GMT) Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 797E643D39 for ; Mon, 10 Jan 2005 19:42:22 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 43373 invoked from network); 10 Jan 2005 19:42:21 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 10 Jan 2005 19:42:21 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id j0AJgKiI064234; Mon, 10 Jan 2005 20:42:20 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id j0AJgKTq064233; Mon, 10 Jan 2005 20:42:20 +0100 (CET) (envelope-from pho) Date: Mon, 10 Jan 2005 20:42:20 +0100 From: Peter Holm To: Bosko Milekic Message-ID: <20050110194220.GA64197@peter.osted.lan> References: <20041222210553.GA28108@peter.osted.lan> <20041222221540.GA70052@technokratis.com> <20041226161153.GA74592@peter.osted.lan> <20041226181738.GA21533@technokratis.com> <20041226225651.GA87178@peter.osted.lan> <20041227013745.GA5267@technokratis.com> <20041227040216.GA44588@technokratis.com> <20041228084731.GA766@peter.osted.lan> <20041228135339.GA80377@technokratis.com> <20050110185104.GA22091@technokratis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050110185104.GA22091@technokratis.com> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: panic: uma_zone_slab is looping X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Jan 2005 19:42:23 -0000 On Mon, Jan 10, 2005 at 01:51:04PM -0500, Bosko Milekic wrote: > > Peter, > > Any updates? should I commit the fix I sent you? > Your patch seems to work for me. I have been testing non stop for weeks and not seen any uma problems. - Peter > -Bosko > > On Tue, Dec 28, 2004 at 08:53:39AM -0500, Bosko Milekic wrote: > > > > On Tue, Dec 28, 2004 at 09:47:31AM +0100, Peter Holm wrote: > > > On Sun, Dec 26, 2004 at 11:02:16PM -0500, Bosko Milekic wrote: > > > > > I'll have to reserve some more time to think about this. One way I > > > > > think it might be solvable would be to change that check that > > > > > triggers the NULL return explicitly check for the bucketzone, and not > > > > > for all UMA_ZONE_INTERNAL zones; I need to think this through a little > > > > > more. > > > > > > > > Please try the attached patch and let me know if with it you can or > > > > cannot trigger the original (seemingly infinite) looping. Although I > > > > still haven't quite figured out how the described scenario could lead > > > > to infinite looping exactly (I did conclude that it could lead to some > > > > looping, though), the patch is worth trying as I believe the scenario > > > > *could* occur. > > > > > > > > > > After more than 18 hours of testing with your patch I ran into a > > > (unrelated ?) "panic: mutex vm object not owned": > > > http://www.holm.cc/stress/log/freeze06.html > > > > Your other (private) Email to me mentions that another developer has > > claimed this one. If/when he fixes it, it would be worthwhile to give > > it another consecutive 18 hours before we decide that "yes, it's good > > and it works." I am optimistic, but we have to be thorough. > > > > Good work, so far! > > > > Cheers, > > -- > > Bosko Milekic > > bmilekic@technokratis.com > > bmilekic@FreeBSD.org > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > -- > Bosko Milekic > bmilekic@technokratis.com > bmilekic@FreeBSD.org -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 20:35:00 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2107D16A4CE for ; Mon, 10 Jan 2005 20:35:00 +0000 (GMT) Received: from portpc-design.spb.ru (ns2.portpc-design.spb.ru [195.161.118.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3A2843D31 for ; Mon, 10 Jan 2005 20:34:58 +0000 (GMT) (envelope-from mcsi@mcsi.pp.ru) Received: from [83.237.61.163] (ppp83-237-61-163.pppoe.mtu-net.ru [83.237.61.163]) (authenticated bits=0) by portpc-design.spb.ru (8.13.2/8.13.2) with ESMTP id j0AKYta2091881 for ; Mon, 10 Jan 2005 23:34:56 +0300 (MSK) (envelope-from mcsi@mcsi.pp.ru) Message-ID: <41E2E6EA.5050501@mcsi.pp.ru> Date: Mon, 10 Jan 2005 23:34:50 +0300 From: Maxim Maximov User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20041224 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 References: <20050110131529.GA716@loge.nixsys.be> In-Reply-To: <20050110131529.GA716@loge.nixsys.be> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: [PLEASE TEST] Many improvements to Synaptics support in psm(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Jan 2005 20:35:00 -0000 Philip Paeps wrote: > I just committed a patch to -current which greatly improves support in psm(4) > for Synaptics touchpads. Owners of these gadgets are encouraged to test this. > If it turns out to work well, I'll enable support by default. Is it possible to remain tap-and-drag functionality? This was the only regression found by now. UP and DOWN keys work again, thanks! > > For now, to get the new behaviour, you need to set hw.psm.synaptics_support=1 > in /boot/loader.conf. > > Please also fiddle with the stickiness sysctls. The quest for finding perfect > values is still on... Only min_movement=4 (or greater) makes the mouse cursor to remain still when I place a finger on the touchpad and don't move it at all. Otherwise, the cursor starts floating around the initial point. > > Thanks! > Thanks to you! -- Maxim Maximov From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 20:43:04 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 611F516A4CE for ; Mon, 10 Jan 2005 20:43:04 +0000 (GMT) Received: from sax.sax.de (sax.sax.de [193.175.26.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D52443D5A for ; Mon, 10 Jan 2005 20:43:03 +0000 (GMT) (envelope-from j@uriah.heep.sax.de) Received: from sax.sax.de (localhost [127.0.0.1]) by sax.sax.de (8.12.10/8.12.10) with ESMTP id j0AKh21A001166 for ; Mon, 10 Jan 2005 21:43:02 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: (from uucp@localhost) by sax.sax.de (8.12.10/8.12.10/Submit) with UUCP id j0AKh2sv001164 for freebsd-current@freebsd.org; Mon, 10 Jan 2005 21:43:02 +0100 (CET) (envelope-from j@uriah.heep.sax.de) Received: from uriah.heep.sax.de (localhost [127.0.0.1]) by uriah.heep.sax.de (8.13.1/8.13.1) with ESMTP id j0AKge4t082626 for ; Mon, 10 Jan 2005 21:42:40 +0100 (MET) (envelope-from j@uriah.heep.sax.de) Received: (from j@localhost) by uriah.heep.sax.de (8.13.1/8.13.1/Submit) id j0AKgep7082625 for freebsd-current@freebsd.org; Mon, 10 Jan 2005 21:42:40 +0100 (MET) (envelope-from j) Date: Mon, 10 Jan 2005 21:42:40 +0100 From: Joerg Wunsch To: freebsd-current@freebsd.org Message-ID: <20050110204240.GA82582@uriah.heep.sax.de> Mail-Followup-To: Joerg Wunsch , freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E X-GPG-Fingerprint: 5E84 F980 C3CA FD4B B584 1070 F48C A81B 69A8 5873 X-Spam-Status: No, score=-2.6 required=7.5 tests=BAYES_00 autolearn=ham version=3.0.1 X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on uriah.heep.sax.de Subject: umass: differences between RELENG_5 and -current? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joerg Wunsch List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 20:43:04 -0000 I've got the following device which basically works under -current: umass0: SigmaTel, Inc. USBMSC Audio Player, rev 1.10/0.01, addr 2 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0: Get Max Lun not supported (STALLED) umass0:2:0:-1: Attached to scbus2 da1 at umass-sim0 bus 0 target 0 lun 0 da1: Removable Direct Access SCSI-4 device da1: 1.000MB/s transfers da1: 123MB (251904 512 byte sectors: 64H 32S/T 123C) (It panics the system when I unmount a msdosfs on it, but accessing it through mtools works well.) Under RELENG_5, all I get is: umass0: SigmaTel, Inc. USBMSC Audio Player, rev 1.10/0.01, addr 5 usbd_setup_pipe: failed to start endpoint, IOERROR device_attach: umass0 attach returned 6 The differences between the umass.c files between both systems aren't exciting, so I guess it's something else. Does anyone have a hint for me where to look? I'd like to get it supported under -stable as well if possible. If anyone is interested in seeing the msdosfs unmount panic, I can send a trace as well (but I'd rather update to a recent -current before then to make sure the problem still persists). -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 21:21:59 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C40816A4CE for ; Mon, 10 Jan 2005 21:21:59 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFBE243D2D for ; Mon, 10 Jan 2005 21:21:58 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) j0ALLwQn070201 for ; Mon, 10 Jan 2005 13:21:58 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)j0ALLwpN070200 for freebsd-current@freebsd.org; Mon, 10 Jan 2005 13:21:58 -0800 (PST) (envelope-from sgk) Date: Mon, 10 Jan 2005 13:21:58 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20050110212158.GA70082@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: ATA panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2005 21:21:59 -0000 Hand transcribed Fatal trap 12: page fault while in kernel mode fault virtual address = 0xff70ff90 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0641091 stack pointer = 0x10:0xc0c20c58 frame pointer = 0x10:0xc0c20c78 code segement = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflages = interrupt enabled, resume, IOPL = 0 current process = 0 (swapper) [thread pid 52 tid 100040] Stopped at mtrash_ctor+0x63: movl 0x20(%eax),%edx db> trace mtrash_ctor(c1bc9600,200,0,1,c0c20b8) at mtrash_ctor+0x63 uma_zalloc_arg(c10456c0,0,1,c1046be0,c1979ac) at uma_zalloc_arg+0x46c malloc(200,c06f5760,1,950a,c0c20d40) at malloc+0x87 ata_getparam(10,3f,200,c1bc9800,c1979a00) at ata_getparam+0x38 ata_identify_device(c1a7f080,1,c19fc990,c197296c,c0c20d78) at ata_identify_device+0xfc ata_boot_attach(0,c0545d5f,c072c9e0,0,c06d15d7) at ata_boot_attach+0x40 run_interrupt_driven_config_hooks(0,0,c197299c,c1ec00,c1e000) at run_interrupt_driven_config_hooks+0x22 mi_startup() at mi_startup()+0xb1 Verbose dmesg from last working kernel follows .sig. -- Steve 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 #5: Sun Nov 14 13:24:03 PST 2004 root@kargl.stms.org:/usr/obj/usr/src/sys/MOBILE WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/sgk/kernel" at 0xc086f000. Preloaded elf module "/boot/sgk/vesa.ko" at 0xc086f14c. Preloaded elf module "/boot/sgk/snd_ich.ko" at 0xc086f1f4. Preloaded elf module "/boot/sgk/sound.ko" at 0xc086f2a0. Preloaded elf module "/boot/sgk/umodem.ko" at 0xc086f348. Preloaded elf module "/boot/sgk/ucom.ko" at 0xc086f3f0. Preloaded elf module "/boot/sgk/agp.ko" at 0xc086f498. Preloaded elf module "/boot/sgk/radeon.ko" at 0xc086f540. Preloaded elf module "/boot/sgk/uplcom.ko" at 0xc086f5e8. Calibrating clock(s) ... i8254 clock: 1193139 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1994126872 Hz CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz (1994.13-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebf9ff real memory = 536748032 (511 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c26000 - 0x000000001f6b1fff, 514375680 bytes (125580 pages) avail memory = 516014080 (492 MB) bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xbfee pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f0000:e2f4 Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: wlan: <802.11 Link Layer> random: mem: Pentium Pro MTRR support enabled io: VESA: information block 56 45 53 41 00 02 00 01 00 01 01 00 00 00 22 00 00 01 00 01 00 01 19 01 00 01 2f 01 00 01 34 01 00 01 82 01 0d 01 0e 01 0f 01 20 01 92 01 93 01 94 01 95 01 96 01 a2 01 a3 01 a4 01 a5 01 a6 01 VESA: 60 mode(s) found VESA: v2.0, 16384k memory, flags:0x1, mode table:0xc0807c42 (1000022) VESA: ATI MOBILITY RADEON 7500 VESA: ATI Technologies Inc. P7 01.00 null: acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80010014 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=1a308086) pcibios: BIOS version 2.10 Found $PIR table, 11 entries at 0xc00fbb90 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 29 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 B 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 31 A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 31 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 1 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 2 0 A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 2 1 A 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 2 3 A 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 2 3 B 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 2 8 A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 2 12 A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 2 12 B 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 2 12 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 2 12 D 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 8 0 A 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 8 1 A 0x61 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 31 func 0 atpic: Programming IRQ9 as level/low acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 29 func 1 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 29 func 2 ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_tz0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 ACPI link \\_SB_.PCI0.LNKB has invalid initial irq 11, ignoring ACPI PCI link initial configuration: \\_SB_.PCI0.LNKA irq 0: [ 9 10 11] 11+ low,level,sharable 0.31.0 \\_SB_.PCI0.LNKB irq 0: [ 5 7] 0+ low,level,sharable 0.31.1 \\_SB_.PCI0.LNKC irq 0: [ 9 10 11] 11+ low,level,sharable 0.31.2 \\_SB_.PCI0.LNKD irq 0: [ 5 7 9 10 11] 11+ low,level,sharable 0.31.3 \\_SB_.PCI0.LNKA irq 0: [ 9 10 11] 11+ low,level,sharable 0.29.0 \\_SB_.PCI0.LNKD irq 0: [ 5 7 9 10 11] 11+ low,level,sharable 0.29.1 \\_SB_.PCI0.LNKC irq 0: [ 9 10 11] 11+ low,level,sharable 0.29.2 \\_SB_.PCI0.LNKA irq 0: [ 9 10 11] 11+ low,level,sharable 0.2.0 \\_SB_.PCI0.LNKA irq 0: [ 9 10 11] 11+ low,level,sharable 0.1.0 \\_SB_.PCI0.LNKB irq 0: [ 5 7] 0+ low,level,sharable 0.1.1 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base e8000000, size 26, enabled found-> vendor=0x8086, dev=0x1a30, revid=0x04 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x1a31, revid=0x04 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x0e (3500 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000bf80, size 5, enabled pcib0: matched entry for 0.29.INTA (src \\_SB_.PCI0.LNKA) pcib0: possible interrupts: 9 10 11 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LNKB (references 2, priority 5130): interrupts: 5 7 penalty: 90 5040 \\_SB_.PCI0.LNKD (references 2, priority 2180): interrupts: 11 10 5 9 7 penalty: 80 80 90 160 5040 \\_SB_.PCI0.LNKA (references 4, priority 426): interrupts: 11 10 9 penalty: 80 80 160 \\_SB_.PCI0.LNKC (references 2, priority 213): interrupts: 11 10 9 penalty: 80 80 160 pcib0: slot 29 INTA routed to irq 11 via \\_SB_.PCI0.LNKA found-> vendor=0x8086, dev=0x2482, revid=0x02 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 found-> vendor=0x8086, dev=0x2448, revid=0x42 bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x06 (1500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x248c, revid=0x02 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x010f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000bfa0, size 4, enabled found-> vendor=0x8086, dev=0x248a, revid=0x02 bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[10]: type 4, range 32, base 0000d800, size 8, enabled map[14]: type 4, range 32, base 0000dc80, size 6, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.PCI0.LNKB) pcib0: possible interrupts: 5 7 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LNKB (references 2, priority 5210): interrupts: 5 7 penalty: 130 5080 \\_SB_.PCI0.LNKD (references 2, priority 2356): interrupts: 5 10 11 9 7 penalty: 130 160 200 320 5080 \\_SB_.PCI0.LNKC (references 2, priority 453): interrupts: 10 11 9 penalty: 160 200 320 atpic: Programming IRQ5 as level/low pcib0: slot 31 INTB routed to irq 5 via \\_SB_.PCI0.LNKB found-> vendor=0x8086, dev=0x2485, revid=0x02 bus=0, slot=31, func=5 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 map[10]: type 4, range 32, base 0000d400, size 8, enabled map[14]: type 4, range 32, base 0000dc00, size 7, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.PCI0.LNKB) pcib0: slot 31 INTB is already routed to irq 5 found-> vendor=0x8086, dev=0x2486, revid=0x02 bus=0, slot=31, func=6 class=07-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=5 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 64M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xc000-0xcfff pcib1: memory decode 0xfc000000-0xfdffffff pcib1: prefetched decode 0xe0000000-0xe7ffffff ACPI PCI link initial configuration: \\_SB_.PCI0.LNKA irq*11: [ 9 10 11] 11+ low,level,sharable 1.0.0 pci1: on pcib1 pci1: physical bus=1 map[10]: type 3, range 32, base e0000000, size 27, enabled pcib1: device (null) requested decoded memory range 0xe0000000-0xe7ffffff map[14]: type 4, range 32, base 0000c000, size 8, enabled pcib1: device (null) requested decoded I/O range 0xc000-0xc0ff map[18]: type 1, range 32, base fcff0000, size 16, enabled pcib1: device (null) requested decoded memory range 0xfcff0000-0xfcffffff pcib1: matched entry for 1.0.INTA (src \\_SB_.PCI0.LNKA) pcib1: slot 0 INTA is already routed to irq 11 found-> vendor=0x1002, dev=0x4c57, revid=0x00 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x01a7, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 drm0: port 0xc000-0xc0ff mem 0xfcff0000-0xfcffffff,0xe0000000-0xe7ffffff irq 11 at device 0.0 on pci1 info: [drm] AGP at 0xe8000000 64MB info: [drm] Initialized radeon 1.11.0 20020828 on minor 0 uhci0: port 0xbf80-0xbf9f irq 11 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xbf80 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 pcib2: at device 30.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 16 pcib2: I/O decode 0xe000-0xffff pcib2: memory decode 0xf4000000-0xfbffffff pcib2: prefetched decode 0xfff00000-0xfffff pcib2: Subtractively decoded bridge. ACPI PCI link initial configuration: \\_SB_.PCI0.LNKD irq 0: [ 5 7 9 10 11] 11+ low,level,sharable 2.1.0 \\_SB_.PCI0.LNKD irq 0: [ 5 7 9 10 11] 11+ low,level,sharable 2.1.1 \\_SB_.PCI0.LNKD irq 0: [ 5 7 9 10 11] 11+ low,level,sharable 2.1.2 \\_SB_.PCI0.LNKB irq* 5: [ 5 7] 0+ low,level,sharable 2.3.0 \\_SB_.PCI0.LNKD irq 0: [ 5 7 9 10 11] 11+ low,level,sharable 2.3.1 \\_SB_.PCI0.LNKC irq 0: [ 9 10 11] 11+ low,level,sharable 2.0.0 \\_SB_.PCI0.LNKC irq 0: [ 9 10 11] 11+ low,level,sharable 2.8.0 pci2: on pcib2 pci2: physical bus=2 map[10]: type 4, range 32, base 0000ec80, size 7, enabled pcib2: device (null) requested decoded I/O range 0xec80-0xecff map[14]: type 1, range 32, base f8fffc00, size 7, enabled pcib2: device (null) requested decoded memory range 0xf8fffc00-0xf8fffc7f pcib2: matched entry for 2.0.INTA (src \\_SB_.PCI0.LNKC) pcib2: possible interrupts: 9 10 11 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LNKD (references 6, priority 7764): interrupts: 5 10 11 9 7 penalty: 250 280 320 440 5180 \\_SB_.PCI0.LNKC (references 4, priority 1386): interrupts: 10 11 9 penalty: 280 320 440 pcib2: slot 0 INTA routed to irq 11 via \\_SB_.PCI0.LNKC found-> vendor=0x10b7, dev=0x9200, revid=0x78 bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x0a (2500 ns), maxlat=0x0a (2500 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 00000000, size 12, memory disabled found-> vendor=0x104c, dev=0xac51, revid=0x00 bus=2, slot=1, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x40 (16000 ns), maxlat=0x07 (1750 ns) intpin=a, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 00000000, size 12, memory disabled found-> vendor=0x104c, dev=0xac51, revid=0x00 bus=2, slot=1, func=1 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x40 (16000 ns), maxlat=0x07 (1750 ns) intpin=a, irq=255 powerspec 1 supports D0 D1 D2 D3 current D0 xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0xec80-0xecff mem 0xf8fffc00-0xf8fffc7f irq 11 at device 0.0 on pci2 xl0: Reserved 0x80 bytes for rid 0x14 type 3 at 0xf8fffc00 xl0: using memory mapped I/O xl0: media options word: a xl0: found MII/AUTO miibus0: on xl0 ukphy0: on miibus0 ukphy0: OUI 0x00105a, model 0x0000, rev. 0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: bpf attached xl0: Ethernet address: 00:08:74:99:7c:c5 xl0: [MPSAFE] cbb0: at device 1.0 on pci2 pcib2: device cbb0 requested decoded memory range 0xf4000000-0xfbffffff cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xf4000000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib2: matched entry for 2.1.INTA (src \\_SB_.PCI0.LNKD) pcib2: possible interrupts: 5 7 9 10 11 ACPI PCI link arbitrated settings: \\_SB_.PCI0.LNKD (references 6, priority 8484): interrupts: 5 10 11 9 7 penalty: 350 400 480 560 5280 pcib2: slot 1 INTA routed to irq 11 via \\_SB_.PCI0.LNKD cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0xac51104c 0x02100007 0x06070000 0x00822008 0x10: 0xf4000000 0x020000a0 0x20040400 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010b 0x40: 0x012b1028 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x2024d025 0x00000000 0x00000000 0x01261222 0x90: 0x6064a6c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe110001 0x00c00000 0x00000000 0x00000017 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 cbb1: at device 1.1 on pci2 pcib2: device cbb1 requested decoded memory range 0xf4000000-0xfbffffff cbb1: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xf4001000 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pcib2: matched entry for 2.1.INTA (src \\_SB_.PCI0.LNKD) pcib2: slot 1 INTA is already routed to irq 11 cbb1: [MPSAFE] cbb1: PCI Configuration space: 0x00: 0xac51104c 0x02100007 0x06070000 0x00822008 0x10: 0xf4001000 0x020000a0 0x20050500 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x0740010b 0x40: 0x012b1028 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x2024d025 0x00000000 0x00000000 0x01261222 0x90: 0x6064a6c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe110001 0x00c00000 0x00000000 0x00000017 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xbfa0-0xbfaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xbfa0 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=00 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] pcm0: port 0xdc80-0xdcbf,0xd800-0xd8ff irq 5 at device 31.5 on pci0 pcm0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xd800 pcm0: Reserved 0x40 bytes for rid 0x14 type 4 at 0xdc80 pcm0: [GIANT-LOCKED] pcm0: pcm0: Codec features mic channel, tone, simulated stereo, bass boost, 20 bit DAC, 18 bit ADC, 5 bit master volume, SRS 3D Stereo Enhancement pcm0: Primary codec extended features variable rate PCM, variable rate mic, AMAP pcm0: sndbuf_setmap 1f423000, 4000; 0xd9489000 -> 1f423000 pcm0: sndbuf_setmap 1f41f000, 4000; 0xd948d000 -> 1f41f000 pcm0: sndbuf_setmap 1f41b000, 4000; 0xd9491000 -> 1f41b000 pci0: at device 31.6 (no driver attached) pci0:31:6: Transition from D0 to D3 psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x1, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0065 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 fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] sio0: irq maps: 0x1 0x11 0x1 0x1 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A 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/8 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 npx0: [FAST] npx0: on motherboard npx0: INT 16 interface 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 Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xcf800-0xcffff,0xcf000-0xcf7ff,0xc0000-0xcefff on isa0 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 <8 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x1 0x1 0x1 0x1 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 1994126872 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached cpu0: set speed to 100.0% acpi_cpu: throttling enabled, 8 steps (100% to 12.5%), currently 100.0% acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times acpi_cmbat0: battery initialization start acpi_cmbat0: battery initialization done, tried 1 times acpi_cmbat1: battery initialization start 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=0x0c wdma=0x22 udma=0x45 cable=80pin ata0-master: setting PIO4 on Intel ICH3 chip ata0-master: setting UDMA100 on Intel ICH3 chip ad0: ATA-5 disk at ata0-master ad0: 38154MB (78140160 sectors), 77520 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA100 GEOM: new disk ad0 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 ata1: reiniting channel .. ata1: reset tp1 mask=03 ostat0=00 ostat1=00 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: resetting done .. ata1: reiniting channel .. ata1-slave: FAILURE - ATAPI_IDENTIFY timed out ata1: reiniting channel .. ata1-slave: FAILURE - ATAPI_IDENTIFY timed out ata1-master: pio=0x0c wdma=0x22 udma=0xffffffff cable=40pin ata1-master: setting PIO4 on Intel ICH3 chip ata1: device config done .. ata1-slave: FAILURE - ATAPI_IDENTIFY timed out ata1-master: pio=0x0c wdma=0x22 udma=0xffffffff cable=40pin ata1-master: setting PIO4 on Intel ICH3 chip acd0: DVDROM drive at ata1 as master acd0: read 1722KB/s (4134KB/s), 512KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd0: Writes: acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc pcm0: measured ac97 link rate at 48007 Hz, will use 48000 Hz Mounting root from ufs:/dev/ad0s3a start_init: trying /sbin/init splash: image decoder found: blank_saver Linux ELF exec handler installed acpi_cmbat1: battery initialization failed, giving up From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 23:11:52 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA53616A4CE; Mon, 10 Jan 2005 23:11:52 +0000 (GMT) Received: from vidle.i.cz (vidle.i.cz [193.179.36.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A38843D46; Mon, 10 Jan 2005 23:11:52 +0000 (GMT) (envelope-from mime@traveller.cz) Received: from ns.i.cz (brana.i.cz [193.179.36.134]) by vidle.i.cz (Postfix) with ESMTP id 971A11527B; Tue, 11 Jan 2005 00:11:50 +0100 (CET) Received: from localhost (localhost.i.cz [127.0.0.1]) by ns.i.cz (Postfix) with SMTP id 75D79F4B03; Tue, 11 Jan 2005 00:11:50 +0100 (CET) X-AV-Checked: Tue Jan 11 00:11:50 2005 ns.i.cz Received: from localhost.localdomain (brana.i.cz [192.168.1.10]) by ns.i.cz (Postfix) with ESMTP id E5C7BF4B01; Tue, 11 Jan 2005 00:11:49 +0100 (CET) From: Michal Mertl To: freebsd-current@freebsd.org Content-Type: text/plain Date: Tue, 11 Jan 2005 00:11:47 +0100 Message-Id: <1105398707.726.23.camel@genius2.i.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: usb problems - ehci and umass and possible fix X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 10 Jan 2005 23:11:53 -0000 Hello, I've just found one problem with my hardware and I did some analysis of the problem. Even when it's, as I suppose, a known issue, the fix mentioned below might help someone. I've got Pentium-M based notebook and an USB2 memory stick. When I try to use it with EHCI it fails yet it works with UHCI. I found out that it works with EHCI when I enable high debugging in EHCI driver (hw.usb.ehci.debug). ISTR I read somewhere some USB problems might be related to timing issues and that seems to confirm it - with high debug lots of messages are generated which probably slow down the operation a lot. I need to enable the debug only for attaching the device. After it succesfully attaches I can disable the debug and use the device without problems. Lately I've also seen improper initialisation with UHCI, so the problem isn't EHCI specific at the end. With UHCI I get 2 of 3 good initilizations and none whatsoever with EHCI. Error messages with debug disabled seem to come from the cam layer. umass0: M-SysT5 Dell Memory Key, rev 2.00/2.00, addr 2 umass0: SCSI over Bulk-Only; quirks = 0x0000 umass0:0:0:-1: Attached to scbus0 pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Removable Direct Access SCSI-0 device pass0: Serial Number u pass0: 1.000MB/s transfers GEOM: new disk da0 (da0:umass-sim0:0:0:0): Retrying Command (da0:umass-sim0:0:0:0): Retrying Command (da0:umass-sim0:0:0:0): Retrying Command (da0:umass-sim0:0:0:0): Retrying Command (da0:umass-sim0:0:0:0): error 6 (da0:umass-sim0:0:0:0): Unretryable Error da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: Serial Number u da0: 1.000MB/s transfers da0: Attempt to query device size failed: UNIT ATTENTION, Medium not present (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error (da0:umass-sim0:0:0:0): SCSI Status: Check Condition (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present (da0:umass-sim0:0:0:0): (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da0:umass-sim0:0:0:0): UNIT ATTENTION asc:3a,0 (da0:umass-sim0:0:0:0): Medium not present Retrying Command (per Sense Data) (da0:umass-sim0:0:0:0): Retrying Command I thought the problem might be in the device doesn't get normally enough time to initialize. The debug output/failure happens immediately when the device is plugged in. I think most devices powered from USB might actually need a bit of time before they are ready to process commands. It seems FreeBSD gives them in general 300ms which is far too little. For example in Linux sources I found out a delay (or timeout) of 20 seconds for umass devices. I tried to look for information on allowed delays in usb specs but wasn't successful. One solution might be to increase the default delay #define'd in src/sys/dev/usb.h USB_PORT_POWERUP_DELAY. According to mentioned Linux source it seems no delay might be long enough :-(. Increasing it to say 2000 from the current 300ms might still be good enough for most devices. Other solution might be to add some delay before initialization of some classes of devices (like umass) or adding quirks. P.S. The increase of USB_PORT_POWERUP_DELAY really works for me. Regards Michal Mertl From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 02:34:58 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2256416A4CE; Tue, 11 Jan 2005 02:34:58 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B049A43D39; Tue, 11 Jan 2005 02:34:52 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw503.dsto.defence.gov.au (ednmsw503.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id j0B2Xgfn013887; Tue, 11 Jan 2005 13:03:42 +1030 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw503.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.10) with ESMTP id ; Tue, 11 Jan 2005 13:04:41 +1030 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id j0B2TMQ00973; Tue, 11 Jan 2005 12:59:22 +1030 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YK378TK4; Tue, 11 Jan 2005 12:59:07 +1030 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id j0B2TpIf033365 ; Tue, 11 Jan 2005 12:59:51 +1030 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id j0B2To6Q033364; Tue, 11 Jan 2005 12:59:50 +1030 (CST) (envelope-from wilkinsa) Date: Tue, 11 Jan 2005 12:59:50 +1030 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org, usb@freebsd.org Message-ID: <20050111022946.GA33309@squash.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org, usb@freebsd.org References: <20050107064748.GE18554@squash.dsto.defence.gov.au> <41DE4E52.2040301@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <41DE4E52.2040301@elischer.org> User-Agent: Mutt/1.5.6i Subject: Re: [USB] JetFlash TS1GJF2B 2.00 Attempt to query device sizefailed: UNIT ATTENTION X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 02:34:58 -0000 0n Fri, Jan 07, 2005 at 12:54:42AM -0800, Julian Elischer wrote: >Wilkinson, Alex wrote: >>No response from usb@ so hopefully someone (julian) will respond here >>;) > >well you posted there at 8:49 and here at 10:47 > >I guess I didn't happen to read the usb list in that 1 hour and 58 minutes. > >we may need to make it use a quirk to use a different read capacity command >or skip it.. > >I'll have to look to remember what collection of 'quirks' we have in our >collection. Interestingly, if the thumb drive is plugged in whilst boot strapping a get a panic: umass0: BBB reset failed, STALLED umass0: BBB bulk-in clear stall failed, STALLED umass0: at uhub1 port 1 (addr 2) disconnected Fatal trap 12: page fault while in kernel mode fault virtual address = 0x1c fault code = supervisor read, page not present instruction pointer = 0x8:0xc04a5907 stack pointer = 0x10:0xe36f7ca4 frame pointer = 0x10:0xe36f7cb8 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 = 29 (irq19: uhci1) [thread pid 29 tid 100000 ] Stopped at uhci_softintr+0x23: movl 0x1c(%eax),%eax db> db> tr Tracing pid 29 tid 100000 td 0xc2664000 uhci_softintr(c275e000,0,c2766d00,4,c2661400) at uhci_softintr+0x23 uhci_intr1(c275e000,c2664000,0,0,0) at uhci_intr1+0xcd ithread_loop(c2661400,e36f7d48,0,0,0) at ithread_loop+0xb7 fork_exit(c04e4c20,c2661400,e36f7d48) at fork_exit+0x64 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe36f7d7c, ebp = 0 --- db> From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 02:36:21 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5585E16A4CE for ; Tue, 11 Jan 2005 02:36:21 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3974743D1F for ; Tue, 11 Jan 2005 02:36:21 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id E0B5D72DF4; Mon, 10 Jan 2005 18:36:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id DE07072DD4; Mon, 10 Jan 2005 18:36:20 -0800 (PST) Date: Mon, 10 Jan 2005 18:36:20 -0800 (PST) From: Doug White To: Randy Bush In-Reply-To: <16860.4383.281114.747270@roam.psg.com> Message-ID: <20050110183217.M84532@carver.gumbysoft.com> References: <16860.4383.281114.747270@roam.psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD Current Subject: Re: fsck issue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 02:36:21 -0000 On Wed, 5 Jan 2005, Randy Bush wrote: > a box running happily over a month > > FreeBSD foo.psg.com 6.0-CURRENT FreeBSD 6.0-CURRENT #13: Tue Nov 30 20:38:02 GMT 2004 root@foo.psg.com:/usr/obj/usr/src/sys/FOO i386 > > locked up sufficiently to require the reset button. as it is remote, and > i was not logged into the console, i do not know why. > > on restart, it seems to work, but i get > > KDB: stack backtrace: > kdb_backtrace(c0680fb8,2,cbbea330,0,22) at kdb_backtrace+0x2e > getdirtybuf(d6654bc0,0,1,cbbea330,1) at getdirtybuf+0x2b > flush_deplist(c26ead4c,1,d6654be4,d6654be8,0) at flush_deplist+0x47 > flush_inodedep_deps(c1634800,1562b,3,d6654c34,c054b6fa) at flush_inodedep_deps+0x9e > softdep_sync_metadata(d6654ca4,3,0,d6654c5c,c155f2d0) at softdep_sync_metadata+0x54 > ffs_fsync(d6654ca4,0,0,0,0) at ffs_fsync+0x47c > fsync(c1937900,d6654d14,4,d6654d3c,c0516c66) at fsync+0x1a1 > syscall(2f,2f,bfbf002f,0,8125c90) at syscall+0x300 > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (95, FreeBSD ELF32, fsync), eip = 0x283c59af, esp = 0xbfbfdaac, ebp = 0xbfbfe898 --- These backtraces are generated by this code in getdirtybuf(): 5847 if (bp->b_vp == NULL) 5848 kdb_backtrace(); Somehow there's a buf floating around without a vnode attached. I'd suggest booting single user and fsck -y'ing all your filesystems to verify there is no residual damage, and remove any snapshots from your ufs2 filesystems. This isn't the first time I've seen this, so I'd check the archive too. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 04:41:20 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86DEF16A4CE; Tue, 11 Jan 2005 04:41:20 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0228C43D55; Tue, 11 Jan 2005 04:41:20 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id j0B4imcU042717; Mon, 10 Jan 2005 21:44:48 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <41E3588B.2060309@freebsd.org> Date: Mon, 10 Jan 2005 21:39:39 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org References: <41DA5C4D.1060606@freebsd.org> In-Reply-To: <41DA5C4D.1060606@freebsd.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: current@freebsd.org Subject: Reminder: Call for FreeBSD status reports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: monthly@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: Tue, 11 Jan 2005 04:41:20 -0000 All, This is a reminder that FreeBSD status report submissions are due by Jan 15. So far there have been a lot of good submissions, so keep them coming! Scott Scott Long wrote: > All, > > It's time again for the bi-monthly status reports. The July-Oct 2004 > status reports were preempted by the 5.3 release, so this one is open > for anything that has happened since June. As always, submissions > having to do with FreeBSD development, documentation, organized events, > etc, are welcome and highly encouraged. Submissions are due by Jan 15 > to monthly@freebsd.org > > There are also a couple of changes to announce. First is that Tom > Rhodes and Max Laier have volunteered to help run the status reports and > keep them more timely. Many thanks to Tom and Max for offering to > help. Second is that a couple of new attributes have been added to the > XML thanks to Max. The first is a project category attribute that will > enable us to group the submissions into categories and render the full > report with these categories for easier viewing. You can choose to use > whatever category tag fits your report best, or omit it entirely and let > us take care of it. The category mapping is listed below. Feel free to > suggest additional categories. > > proj - Projects (non-specific) > docs - Documentation > kern - Kernel > arch - Architectures > ports - Ports > vendor - Vendor / 3rd party software > misc - Miscellaneous > > The second new attribute lets you lists tasks for your project that > others can help with. An example is provided in the template under the > and tags. > > The template is available at > http://www.freebsd.org/news/status/report-sample.xml. I've just > committed the updated version with the new tags, so it might take a few > hours for it to reach the website for downloading. > > Submissions are due on Jan 15. Thanks a lot, and we are looking for a > big turn-out. > > Scott From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 06:54:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31E2216A4CE for ; Tue, 11 Jan 2005 06:54:57 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55B6843D5C for ; Tue, 11 Jan 2005 06:54:56 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j0B6slIv017557; Mon, 10 Jan 2005 23:54:48 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 10 Jan 2005 23:55:28 -0700 (MST) Message-Id: <20050110.235528.25732845.imp@bsdimp.com> To: kwm@rainbow-runner.nl From: "M. Warner Losh" In-Reply-To: <1105227700.25419.14.camel@heater.rainbow-runner.nl> References: <1105227700.25419.14.camel@heater.rainbow-runner.nl> 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: cbb0: CardBus card activation failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 06:54:57 -0000 In message: <1105227700.25419.14.camel@heater.rainbow-runner.nl> Koop Mast writes: : I got myself an 3Com wireless card based on the Atheros 5212 chip. : After inserting it in the first pcmcia slot the kernel tells me this: : : cbb0: CardBus card activation failed This line has zero content. It just means that the driver didn't attach, but doesn't tell me why... What are the lines before it. : But after some fiddling around I stuck the card in the second pcmcia : slot, I was rewarded with the following: Did you load if_ath in between? Warner From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 07:54:33 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1536516A4CE for ; Tue, 11 Jan 2005 07:54:33 +0000 (GMT) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C0FA43D45 for ; Tue, 11 Jan 2005 07:54:32 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j0B7sUPN016105 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 11 Jan 2005 18:54:30 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j0B7sUxP050523; Tue, 11 Jan 2005 18:54:30 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j0B7sTsf050522; Tue, 11 Jan 2005 18:54:29 +1100 (EST) (envelope-from pjeremy) Date: Tue, 11 Jan 2005 18:54:29 +1100 From: Peter Jeremy To: Warren Message-ID: <20050111075429.GZ79646@cirb503493.alcatel.com.au> References: <200501081518.33396.shinjii@virusinfo.rdksupportinc.com> <200501091318.38409.shinjii@virusinfo.rdksupportinc.com> <20050109065525.GL39552@cirb503493.alcatel.com.au> <200501091709.48526.shinjii@virusinfo.rdksupportinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501091709.48526.shinjii@virusinfo.rdksupportinc.com> User-Agent: Mutt/1.4.2i cc: freebsd-current@freebsd.org Subject: Re: 5.3-STABLE failing to read 4.x-Stable hdd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 07:54:33 -0000 On Sun, 2005-Jan-09 17:09:48 +1000, Warren wrote: >In ads1 i have: > >ads1 ad1s1c ad1s1e .... > >how do i rename those partitions to what ever it is there supposed to be.... You don't need to rename them. Based on the dmesg, you should be able to fsck and mount /dev/ad1s1e You will probably need to update your /etc/fstab. >Soz im totally new to this sort of thing in freebsd and clueless. I suggest you read http://www.freebsd.org/projects/newbies.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/basics.html and followup with any questions to freebsd-questions@freebsd.org -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 11:57:46 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 590E216A4CE for ; Tue, 11 Jan 2005 11:57:46 +0000 (GMT) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09F6B43D4C for ; Tue, 11 Jan 2005 11:57:46 +0000 (GMT) (envelope-from rionda@gufi.org) Received: from localhost.localdomain (unknown [82.52.112.71]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP id 90F34576C for ; Tue, 11 Jan 2005 13:00:40 +0100 (CET) From: Matteo Riondato To: freebsd-current@freebsd.org In-Reply-To: <1105330028l.5495l.2l@BARTON> References: <1105302297.9705.23.camel@kaiser.sig11.org> <1105330028l.5495l.2l@BARTON> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-habzfkAWbxAlaBBc2x82" Date: Tue, 11 Jan 2005 12:57:43 +0100 Message-Id: <1105444663.21117.13.camel@kaiser.sig11.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port Subject: Re: firefox coredumping in recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 11:57:46 -0000 --=-habzfkAWbxAlaBBc2x82 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 10-01-2005 at 04:07 +0000, Jason Henson wrote: > On 01/09/05 15:24:57, Matteo Riondato wrote: > > Hi folks > > I'm experimenting some core dumps with firefox on a recent current > > (Jan > > 2 2005). Firefox crashes during surfing, > What options, if any, did you build with? -f options kill all the =20 > chrome stuff from mozilla on my machince. Sorry for having caused such a noise. I noticed that I built firefox with -O2, which isn't supported. Probably, building it with -O will result in a working firefox.=20 Anyway, if that matters: I rebuild it (again, with -O2 and debug) and here is a backtrace: (gdb) bt #0 0x28ab00ab in pthread_testcancel () from /usr/lib/libpthread.so.1 #1 0x28aa8510 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 #2 0x00000000 in ?? () Perhaps it can be useful to something else, such as tracking bugs down in libpthread. Best Regards --=20 Rionda aka Matteo Riondato GUFI Staff Member (http://www.gufi.org) FreeSBIE Developer (http://www.freesbie.org) BSD-FAQ-it Main Developer (http://utenti.gufi.org/~rionda) Sent from: kaiser.sig11.org running FreeBSD-6.0-CURRENT --=-habzfkAWbxAlaBBc2x82 Content-Type: application/pgp-signature; name=signature.asc Content-Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBB47832Mp4pR7Fa+wRAss7AKCGF7GxXwfmJzwkWSNXoMOkTa2UeQCdEwG8 RAqAp1H2q6R+oUAzAdckov4= =BiSF -----END PGP SIGNATURE----- --=-habzfkAWbxAlaBBc2x82-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 12:10:21 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 824FD16A4D0 for ; Tue, 11 Jan 2005 12:10:21 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F0F843D1D for ; Tue, 11 Jan 2005 12:10:21 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j0BCAIkH020193 for ; Tue, 11 Jan 2005 12:10:20 GMT (envelope-from davidxu@freebsd.org) Message-ID: <41E3C2CF.3080601@freebsd.org> Date: Tue, 11 Jan 2005 20:13:03 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.2) Gecko/20041004 X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Kernel thread hash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 12:10:21 -0000 I am trying to make umtx robustness like Soloris does, when a lock holder dies, other waiters will be noticed, I need a fast way to find a thread by thread id, but current there isn't, who is working on it ? David Xu From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 12:26:54 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE4BF16A4CE for ; Tue, 11 Jan 2005 12:26:54 +0000 (GMT) Received: from 212.106.238.57.adsl.jazztel.es (212.106.238.57.adsl.jazztel.es [212.106.238.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64FE443D2D for ; Tue, 11 Jan 2005 12:26:53 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from [192.168.254.16] (orion.redesjm.local [192.168.254.16]) j0BCQkSH086773; Tue, 11 Jan 2005 13:26:46 +0100 (CET) (envelope-from freebsd@redesjm.local) Message-ID: <41E3C608.6070003@redesjm.local> Date: Tue, 11 Jan 2005 13:26:48 +0100 From: Jose M Rodriguez User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: es-es, es MIME-Version: 1.0 To: Matteo Riondato References: <1105302297.9705.23.camel@kaiser.sig11.org> <1105330028l.5495l.2l@BARTON> <1105444663.21117.13.camel@kaiser.sig11.org> In-Reply-To: <1105444663.21117.13.camel@kaiser.sig11.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-3; AVE: 6.29.0.5; VDF: 6.29.0.31; host: antares.redesjm.local) cc: freebsd-current@freebsd.org Subject: Re: firefox coredumping in recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 12:26:55 -0000 Matteo Riondato escribió: >On 10-01-2005 at 04:07 +0000, Jason Henson wrote: > > >>On 01/09/05 15:24:57, Matteo Riondato wrote: >> >> >>>Hi folks >>>I'm experimenting some core dumps with firefox on a recent current >>>(Jan >>>2 2005). Firefox crashes during surfing, >>> >>> > > > >>What options, if any, did you build with? -f options kill all the >>chrome stuff from mozilla on my machince. >> >> > >Sorry for having caused such a noise. I noticed that I built firefox >with -O2, which isn't supported. Probably, building it with -O will >result in a working firefox. >Anyway, if that matters: I rebuild it (again, with -O2 and debug) and >here is a backtrace: >(gdb) bt >#0 0x28ab00ab in pthread_testcancel () from /usr/lib/libpthread.so.1 >#1 0x28aa8510 in pthread_mutexattr_init () >from /usr/lib/libpthread.so.1 >#2 0x00000000 in ?? () > > >Perhaps it can be useful to something else, such as tracking bugs down >in libpthread. > >Best Regards > > Try using CFLAGS+= -O2 -fno-strict-aliasing and/or WITH_OPTIMIZED_CFLAGS="YES" Also, check your CPU options. I use CPUTYPE=athlon-xp NO_CPU_CFLAGS= true NO_CPU_COPTFLAGS=true CFLAGS= -O2 -march=pentium-mmx -mtune=athlon-xp -fno-strict-aliasing -pipe -- josemi From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 12:40:19 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 371A216A4CF; Tue, 11 Jan 2005 12:40:19 +0000 (GMT) Received: from mail-gw1.york.ac.uk (mail-gw1.york.ac.uk [144.32.128.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B9CC43D1F; Tue, 11 Jan 2005 12:40:18 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from buffy.york.ac.uk (buffy.york.ac.uk [144.32.226.160]) by mail-gw1.york.ac.uk (8.12.10/8.12.10) with ESMTP id j0BCeExN002930; Tue, 11 Jan 2005 12:40:15 GMT Received: from buffy.york.ac.uk (localhost [127.0.0.1]) by buffy.york.ac.uk (8.13.1/8.13.1) with ESMTP id j0BCeESV005759; Tue, 11 Jan 2005 12:40:14 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: (from ga9@localhost) by buffy.york.ac.uk (8.13.1/8.13.1/Submit) id j0BCeEu8005758; Tue, 11 Jan 2005 12:40:14 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: buffy.york.ac.uk: ga9 set sender to gavin.atkinson@ury.york.ac.uk using -f From: Gavin Atkinson To: Vince Hoffman In-Reply-To: <20040815113727.S33525@unsane.co.uk> References: <20040815113727.S33525@unsane.co.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Tue, 11 Jan 2005 12:40:13 +0000 Message-Id: <1105447213.5153.3.camel@buffy.york.ac.uk> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk cc: freebsd-current@freebsd.org cc: freebsd-mobile@freebsd.org Subject: Re: 5.x on a portege A100 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 12:40:19 -0000 On Sun, 2004-08-15 at 13:09 +0100, Vince Hoffman wrote: > Hi all, > Firstly sorry for the cross post but it seemed equaly appropriate > for both lists. > I'm rather idley trying to get 5.2.1+ to work on my toshiba > portege A100. So far no joy, 5.x will not boot. I have tried the > various boot menu options (with and without ACPI), but 5.2.1 > and the latest -CURRENT snapshot I could could find on the snapshot server > both freeze at pci0, ACPI enabled says, pci0: on pcib0 > non ACPI says pci0: . I'll write down and retype the > entire output if it'll help. Yes - and I suspect Google could have answered your question too. All recent Toshiba laptops that I have been able to get my hands on have this same problem. Apparently all Acer Centrino laptops need this too, but I can't confirm that. set hw.pci.enable_io_modes=0 at the loader prompt, then boot. If that doesn't work, try also setting the PnP OS option in the bios to "no". This _shouldn't_ be necessary, but was on at least one Toshiba laptop I played with recently. Gavin From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 12:43:17 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAC3216A4CE; Tue, 11 Jan 2005 12:43:17 +0000 (GMT) Received: from mail-gw0.york.ac.uk (mail-gw0.york.ac.uk [144.32.128.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id 631C143D1F; Tue, 11 Jan 2005 12:43:17 +0000 (GMT) (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from ury.york.ac.uk (ury.york.ac.uk [144.32.108.81]) by mail-gw0.york.ac.uk (8.12.10/8.12.10) with ESMTP id j0BChBc5001945; Tue, 11 Jan 2005 12:43:11 GMT Received: from ury.york.ac.uk (localhost.york.ac.uk [127.0.0.1]) by ury.york.ac.uk (8.12.9p2/8.12.9) with ESMTP id j0BChBp8041312; Tue, 11 Jan 2005 12:43:11 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) Received: from localhost (gavin@localhost)j0BChBZo041309; Tue, 11 Jan 2005 12:43:11 GMT (envelope-from gavin.atkinson@ury.york.ac.uk) X-Authentication-Warning: ury.york.ac.uk: gavin owned process doing -bs Date: Tue, 11 Jan 2005 12:43:11 +0000 (GMT) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Vince Hoffman In-Reply-To: <1105447213.5153.3.camel@buffy.york.ac.uk> Message-ID: <20050111124136.D41222@ury.york.ac.uk> References: <20040815113727.S33525@unsane.co.uk> <1105447213.5153.3.camel@buffy.york.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-York-MailScanner: Found to be clean X-York-MailScanner-From: gavin.atkinson@ury.york.ac.uk cc: freebsd-current@freebsd.org cc: freebsd-mobile@freebsd.org Subject: Re: 5.x on a portege A100 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 12:43:18 -0000 On Tue, 11 Jan 2005, Gavin Atkinson wrote: > On Sun, 2004-08-15 at 13:09 +0100, Vince Hoffman wrote: > > Hi all, Oops, I have no idea how I failed to notice that the email I replied to was nearly 6 months ago. Apologies all. Gavin From owner-freebsd-current@FreeBSD.ORG Mon Jan 10 23:47:34 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BEB916A4D0 for ; Mon, 10 Jan 2005 23:47:34 +0000 (GMT) Received: from ring.vpop.net (ring.vpop.net [207.178.248.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id A401E43D2D for ; Mon, 10 Jan 2005 23:47:33 +0000 (GMT) (envelope-from mreimer@vpop.net) Received: from bilbo.vpop.net (bilbo.vpop.net [70.56.77.194]) by ring.vpop.net (Postfix) with ESMTP id E5E0EAFA8ED for ; Mon, 10 Jan 2005 15:47:24 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) Message-Id: <200501101547.18892.mreimer@vpop.net> From: Matt Reimer Date: Mon, 10 Jan 2005 15:47:18 -0800 To: current@freebsd.org X-UID: 11 X-Length: 7579 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 11 Jan 2005 13:20:59 +0000 Subject: Reproducible filesystem deadlock on 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, 10 Jan 2005 23:47:34 -0000 On a UP machine (P4, 128M RAM) running RELENG_5 (as of Friday), I am seeing what looks like a hang or deadlock on a filesystem with 10 snapshots. Our problems began when we ran out of disk space, resulting in a series of these log messages: kernel: pid 39 (bufdaemon), uid 0 inumber 7277783 on /backup: filesystem full kernel: initiate_write_filepage: already started So I tried to delete a snapshot to free up some space, but then the kernel began panicking. In my effort to workaround the panic, I disabled softupdates. Then I came across the identical panic in a post by Kris Kennaway (http://lists.freebsd.org/pipermail/freebsd-current/2004-September/036946.html), which he fixed by increasing KSTACK_PAGES. After increasing it to 31, the kernel no longer panics, but instead filesystem access seems to deadlock: if I try to even touch a file into existence on that partition, the touch command hangs in state 'wdrain', and other attempts to access that filesystem hang as well. This problem is 100% reproducible. How to proceed? Serial console access is available if someone wants to tackle it. Matt # sysctl vfs vfs.nfs4.access_cache_timeout: 60 vfs.nfs4.nfsv3_commit_on_close: 0 vfs.ufs.dirhash_minsize: 2560 vfs.ufs.dirhash_maxmem: 2097152 vfs.ufs.dirhash_mem: 20750 vfs.ufs.dirhash_docheck: 0 vfs.devfs.noverflow: 32768 vfs.devfs.generation: 72 vfs.devfs.inodes: 72 vfs.devfs.topinode: 75 vfs.nfs.downdelayinitial: 12 vfs.nfs.downdelayinterval: 30 vfs.nfs.realign_test: 0 vfs.nfs.realign_count: 0 vfs.nfs.bufpackets: 4 vfs.nfs.reconnects: 0 vfs.nfs.iodmaxidle: 120 vfs.nfs.iodmin: 4 vfs.nfs.iodmax: 20 vfs.nfs.defect: 0 vfs.nfs.nfs_ip_paranoia: 1 vfs.nfs.diskless_valid: 0 vfs.nfs.diskless_rootpath: vfs.nfs.access_cache_timeout: 60 vfs.nfs.nfsv3_commit_on_close: 0 vfs.pfs.vncache.entries: 0 vfs.pfs.vncache.maxentries: 0 vfs.pfs.vncache.hits: 0 vfs.pfs.vncache.misses: 0 vfs.vmiodirenable: 1 vfs.runningbufspace: 5294080 vfs.bufspace: 18628608 vfs.maxbufspace: 23756800 vfs.bufmallocspace: 57344 vfs.maxmallocbufspace: 1155072 vfs.lobufspace: 23035904 vfs.hibufspace: 23101440 vfs.bufreusecnt: 1137 vfs.buffreekvacnt: 0 vfs.bufdefragcnt: 0 vfs.lorunningspace: 524288 vfs.hirunningspace: 1048576 vfs.dirtybufferflushes: 0 vfs.altbufferflushes: 0 vfs.recursiveflushes: 1310 vfs.numdirtybuffers: 67 vfs.lodirtybuffers: 191 vfs.hidirtybuffers: 382 vfs.dirtybufthresh: 343 vfs.numfreebuffers: 764 vfs.lofreebuffers: 85 vfs.hifreebuffers: 170 vfs.getnewbufcalls: 1544 vfs.getnewbufrestarts: 0 vfs.flushwithdeps: 0 vfs.cache.numneg: 10 vfs.cache.numcache: 167 vfs.cache.numcalls: 5481 vfs.cache.dothits: 9 vfs.cache.dotdothits: 4 vfs.cache.numchecks: 4748 vfs.cache.nummiss: 786 vfs.cache.nummisszap: 0 vfs.cache.numposzaps: 0 vfs.cache.numposhits: 4330 vfs.cache.numnegzaps: 1 vfs.cache.numneghits: 351 vfs.cache.nchstats: 4330 351 1 0 786 0 8 90 vfs.cache.numcwdcalls: 3 vfs.cache.numcwdfail1: 0 vfs.cache.numcwdfail2: 0 vfs.cache.numcwdfail3: 0 vfs.cache.numcwdfail4: 0 vfs.cache.numcwdfound: 3 vfs.cache.numfullpathcalls: 0 vfs.cache.numfullpathfail1: 0 vfs.cache.numfullpathfail2: 0 vfs.cache.numfullpathfail3: 0 vfs.cache.numfullpathfail4: 0 vfs.cache.numfullpathfound: 0 vfs.write_behind: 1 vfs.read_max: 8 vfs.opv_numops: 64 vfs.usermount: 0 vfs.numvnodes: 352 vfs.wantfreevnodes: 25 vfs.freevnodes: 189 vfs.reassignbufcalls: 343 vfs.nameileafonly: 0 vfs.timestamp_precision: 0 vfs.worklist_len: 10 vfs.nfsrv.nfs_privport: 0 vfs.nfsrv.async: 0 vfs.nfsrv.commit_blks: 0 vfs.nfsrv.commit_miss: 0 vfs.nfsrv.realign_test: 0 vfs.nfsrv.realign_count: 0 vfs.nfsrv.gatherdelay: 10000 vfs.nfsrv.gatherdelay_v3: 0 vfs.ffs.doasyncfree: 1 vfs.ffs.doreallocblks: 1 db> ps pid proc uarea uid ppid pgrp flag stat wmesg wchan cmd 140 c0f57388 c84c4000 0 138 140 0004002 [SLPQ wdrain 0xc0661324] [SLP] touch 138 c0f5754c c84c5000 0 137 138 0004002 [SLPQ wait 0xc0f5754c][SLP] bash 137 c0f57e20 c874a000 1001 135 137 0004102 [SLPQ wait 0xc0f57e20][SLP] su 135 c0f57710 c84c6000 1001 134 135 0004002 [SLPQ wait 0xc0f57710][SLP] bash 134 c1010000 c8b98000 1001 131 131 0000100 [SLPQ select 0xc0660d24][SLP] sshd 131 c0f571c4 c84c3000 0 128 131 0000100 [SLPQ sbwait 0xc10acd40][SLP] sshd 128 c0f57a98 c8748000 0 1 128 0000100 [SLPQ select 0xc0660d24][SLP] sshd 106 c10101c4 c8b9a000 0 1 106 0004002 [SLPQ ttyin 0xc0fe9610][SLP] sh 46 c0ecda98 c8326000 0 0 0 0000204 [SLPQ - 0xc7b66d18][SLP] schedcpu 45 c0ecdc5c c8327000 0 0 0 0000204 [SLPQ - 0xc0663dcc][SLP] nfsiod 3 44 c0ecde20 c8328000 0 0 0 0000204 [SLPQ - 0xc0663dc8][SLP] nfsiod 2 43 c0f54000 c8379000 0 0 0 0000204 [SLPQ - 0xc0663dc4][SLP] nfsiod 1 42 c0f541c4 c84ba000 0 0 0 0000204 [SLPQ - 0xc0663dc0][SLP] nfsiod 0 41 c0f54388 c84bb000 0 0 0 0000204 [SLPQ syncer 0xc065d4cc][SLP] syncer 40 c0f5454c c84bc000 0 0 0 0000204 [SLPQ vlruwt 0xc0f5454c][SLP] vnlru 39 c0f54710 c84bd000 0 0 0 0000204 [SLPQ psleep 0xc06612ec][SLP] bufdaemon 38 c0f548d4 c84be000 0 0 0 000020c [SLPQ pgzero 0xc066a634][SLP] pagezero 37 c0f54a98 c84bf000 0 0 0 0000204 [SLPQ psleep 0xc066a688][SLP] vmdaemon 36 c0f54c5c c84c0000 0 0 0 0000204 [SLPQ psleep 0xc066a644][SLP] pagedaemon 35 c0f54e20 c84c1000 0 0 0 0000204 [IWAIT] swi0: sio 34 c0f57000 c84c2000 0 0 0 0000204 [SLPQ - 0xc0f4603c][SLP] fdc0 9 c0ebd54c c81da000 0 0 0 0000204 [SLPQ actask 0xc06550ac][SLP] acpi_task2 8 c0ebd710 c81db000 0 0 0 0000204 [SLPQ actask 0xc06550ac][SLP] acpi_task1 7 c0ebd8d4 c81dc000 0 0 0 0000204 [SLPQ actask 0xc06550ac][SLP] acpi_task0 33 c0ebda98 c831d000 0 0 0 0000204 [IWAIT] swi6: acpitaskq 6 c0ebdc5c c831e000 0 0 0 0000204 [SLPQ - 0xc0ee3ac0][SLP] kqueue taskq 32 c0ebde20 c831f000 0 0 0 0000204 [IWAIT] swi6:+ 5 c0ecd000 c8320000 0 0 0 0000204 [SLPQ - 0xc0ee3b80][SLP] thread taskq 31 c0ecd1c4 c8321000 0 0 0 0000204 [IWAIT] swi6:+ 30 c0ecd388 c8322000 0 0 0 0000204 [IWAIT] swi6: task queue 29 c0ecd54c c8323000 0 0 0 0000204 [SLPQ - 0xc0655320][SLP] yarrow 4 c0ecd710 c8324000 0 0 0 0000204 [SLPQ - 0xc0657da8][SLP] g_down 3 c0ecd8d4 c8325000 0 0 0 0000204 [SLPQ - 0xc0657da4][SLP] g_up 2 c0ea21c4 c7aa5000 0 0 0 0000204 [SLPQ - 0xc0657d9c][SLP] g_event 28 c0ea2388 c7aa6000 0 0 0 0000204 [IWAIT] swi1: net 27 c0ea254c c7be7000 0 0 0 0000204 [IWAIT] swi4: vm 26 c0ea2710 c7be8000 0 0 0 000020c [IWAIT] swi5: clock sio 25 c0ea28d4 c7be9000 0 0 0 0000204 [IWAIT] irq15: ata1 24 c0ea2a98 c7bea000 0 0 0 0000204 [IWAIT] irq14: ata0 23 c0ea2c5c c7beb000 0 0 0 0000204 [IWAIT] irq13: 22 c0ea2e20 c7bec000 0 0 0 0000204 [IWAIT] irq12: 21 c0ebd000 c81d7000 0 0 0 0000204 [IWAIT] irq11: 20 c0ebd1c4 c81d8000 0 0 0 0000204 [IWAIT] irq10: 19 c0ebd388 c81d9000 0 0 0 0000204 [IWAIT] irq9: em0 atapci1+ 18 c0e9a000 c781b000 0 0 0 0000204 [IWAIT] irq8: rtc 17 c0e9a1c4 c7a9c000 0 0 0 0000204 [IWAIT] irq7: 16 c0e9a388 c7a9d000 0 0 0 0000204 [IWAIT] irq6: fdc0 15 c0e9a54c c7a9e000 0 0 0 0000204 [IWAIT] irq5: 14 c0e9a710 c7a9f000 0 0 0 0000204 [IWAIT] irq4: sio0 13 c0e9a8d4 c7aa0000 0 0 0 0000204 [IWAIT] irq3: sio1 12 c0e9aa98 c7aa1000 0 0 0 0000204 [IWAIT] irq1: atkbd0 11 c0e9ac5c c7aa2000 0 0 0 0000204 [IWAIT] irq0: clk 10 c0e9ae20 c7aa3000 0 0 0 000020c [CPU 0] idle 1 c0ea2000 c7aa4000 0 0 1 0004200 [SLPQ wait 0xc0ea2000][SLP] init 0 c0657e40 c081f000 0 0 0 0000200 [SLPQ sched 0xc0657e40][SLP] swapper From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 13:53:11 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72F9016A4CE; Tue, 11 Jan 2005 13:53:11 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id E85FA43D1D; Tue, 11 Jan 2005 13:53:10 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j0BDr9Qg058857; Tue, 11 Jan 2005 08:53:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id j0BDr9aO088461; Tue, 11 Jan 2005 08:53:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7EE357306E; Tue, 11 Jan 2005 08:53:09 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050111135309.7EE357306E@freebsd-current.sentex.ca> Date: Tue, 11 Jan 2005 08:53:09 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/625/Fri Dec 10 12:41:57 2004 clamav-milter version 0.80j on clamscanner2 X-Virus-Scanned: ClamAV 0.80/640/Thu Dec 23 13:48:27 2004 clamav-milter version 0.80j on clamscanner2 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 13:53:11 -0000 TB --- 2005-01-11 13:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-11 13:15:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-01-11 13:15:00 - checking out the source tree TB --- 2005-01-11 13:15:00 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-01-11 13:15:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-01-11 13:20:48 - building world (CFLAGS=-O2 -pipe) TB --- 2005-01-11 13:20:48 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-01-11 13:20:48 - /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 [...] mkdep -f .depend -a /tinderbox/CURRENT/alpha/alpha/src/sbin/kldstat/kldstat.c echo kldstat: /home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libc.a >> .depend ===> sbin/kldunload (depend) rm -f .depend mkdep -f .depend -a /tinderbox/CURRENT/alpha/alpha/src/sbin/kldunload/kldunload.c echo kldunload: /home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/lib/libc.a >> .depend ===> sbin/ldconfig (depend) make: don't know how to make shlib.c. Stop *** Error code 2 Stop in /tinderbox/CURRENT/alpha/alpha/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-01-11 13:53:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-01-11 13:53:09 - ERROR: failed to build world TB --- 2005-01-11 13:53:09 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 14:23:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3225316A4CF for ; Tue, 11 Jan 2005 14:23:40 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B565243D45 for ; Tue, 11 Jan 2005 14:23:39 +0000 (GMT) (envelope-from eischen@vigrid.com) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j0BENabI028748; Tue, 11 Jan 2005 09:23:36 -0500 (EST) Date: Tue, 11 Jan 2005 09:23:36 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Matteo Riondato In-Reply-To: <1105444663.21117.13.camel@kaiser.sig11.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: freebsd-current@freebsd.org Subject: Re: firefox coredumping in recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@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: Tue, 11 Jan 2005 14:23:40 -0000 On Tue, 11 Jan 2005, Matteo Riondato wrote: > On 10-01-2005 at 04:07 +0000, Jason Henson wrote: > > On 01/09/05 15:24:57, Matteo Riondato wrote: > > > Hi folks > > > I'm experimenting some core dumps with firefox on a recent current > > > (Jan > > > 2 2005). Firefox crashes during surfing, > > > What options, if any, did you build with? -f options kill all the > > chrome stuff from mozilla on my machince. > > Sorry for having caused such a noise. I noticed that I built firefox > with -O2, which isn't supported. Probably, building it with -O will > result in a working firefox. > Anyway, if that matters: I rebuild it (again, with -O2 and debug) and > here is a backtrace: > (gdb) bt > #0 0x28ab00ab in pthread_testcancel () from /usr/lib/libpthread.so.1 > #1 0x28aa8510 in pthread_mutexattr_init () > from /usr/lib/libpthread.so.1 > #2 0x00000000 in ?? () > > Perhaps it can be useful to something else, such as tracking bugs down > in libpthread. Please see @ports. You need an updated linuxpluginwrapper. -- DE From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 14:30:25 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 029AA16A4CE; Tue, 11 Jan 2005 14:30:25 +0000 (GMT) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0F6243D3F; Tue, 11 Jan 2005 14:30:24 +0000 (GMT) (envelope-from rionda@gufi.org) Received: from localhost.localdomain (unknown [82.52.112.71]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP id C6ACC576C; Tue, 11 Jan 2005 15:33:19 +0100 (CET) From: Matteo Riondato To: deischen@freebsd.org In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-C+ucKfzGKwNuBezIAPmn" Date: Tue, 11 Jan 2005 15:30:22 +0100 Message-Id: <1105453822.21117.17.camel@kaiser.sig11.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port cc: freebsd-current@freebsd.org Subject: Re: firefox coredumping in recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 14:30:25 -0000 --=-C+ucKfzGKwNuBezIAPmn Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 11-01-2005, Daniel Eischen wrote: > On Tue, 11 Jan 2005, Matteo Riondato wrote: >=20 > > On 10-01-2005 at 04:07 +0000, Jason Henson wrote: > > > On 01/09/05 15:24:57, Matteo Riondato wrote: > > > > Hi folks > > > > I'm experimenting some core dumps with firefox on a recent curren >=20 > Please see @ports. You need an updated linuxpluginwrapper. Ok, thanks. Best Regards --=20 Rionda aka Matteo Riondato GUFI Staff Member (http://www.gufi.org) FreeSBIE Developer (http://www.freesbie.org) BSD-FAQ-it Main Developer (http://utenti.gufi.org/~rionda) Sent from: kaiser.sig11.org running FreeBSD-6.0-CURRENT --=-C+ucKfzGKwNuBezIAPmn Content-Type: application/pgp-signature; name=signature.asc Content-Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBB4+L+2Mp4pR7Fa+wRAm32AKCdPM7LncjrtbBItnSR/p84637mXwCgj6ig GOYEaO1irfJ10W0HmvTWFj8= =E3lT -----END PGP SIGNATURE----- --=-C+ucKfzGKwNuBezIAPmn-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 14:31:51 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 123E016A4D1; Tue, 11 Jan 2005 14:31:51 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F13B43D31; Tue, 11 Jan 2005 14:31:50 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j0BEVoiH062421; Tue, 11 Jan 2005 09:31:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id j0BEVo8n063278; Tue, 11 Jan 2005 09:31:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C22E57306E; Tue, 11 Jan 2005 09:31:49 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050111143149.C22E57306E@freebsd-current.sentex.ca> Date: Tue, 11 Jan 2005 09:31:49 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/625/Fri Dec 10 12:41:57 2004 clamav-milter version 0.80j on clamscanner2 X-Virus-Scanned: ClamAV 0.80/640/Thu Dec 23 13:48:27 2004 clamav-milter version 0.80j on clamscanner3 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 14:31:51 -0000 TB --- 2005-01-11 13:53:09 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-11 13:53:09 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-01-11 13:53:09 - checking out the source tree TB --- 2005-01-11 13:53:09 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-01-11 13:53:09 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-01-11 13:58:58 - building world (CFLAGS=-O2 -pipe) TB --- 2005-01-11 13:58:58 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-01-11 13:58:58 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies [...] mkdep -f .depend -a /tinderbox/CURRENT/amd64/amd64/src/sbin/kldstat/kldstat.c echo kldstat: /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libc.a >> .depend ===> sbin/kldunload (depend) rm -f .depend mkdep -f .depend -a /tinderbox/CURRENT/amd64/amd64/src/sbin/kldunload/kldunload.c echo kldunload: /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/lib/libc.a >> .depend ===> sbin/ldconfig (depend) make: don't know how to make shlib.c. Stop *** Error code 2 Stop in /tinderbox/CURRENT/amd64/amd64/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2005-01-11 14:31:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-01-11 14:31:49 - ERROR: failed to build world TB --- 2005-01-11 14:31:49 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 14:56:26 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DD4F116A4CE for ; Tue, 11 Jan 2005 14:56:26 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABDAD43D1F for ; Tue, 11 Jan 2005 14:56:26 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 13130 invoked from network); 11 Jan 2005 14:56:26 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 11 Jan 2005 14:56:21 -0000 Received: from [192.168.0.15] (osx.baldwin.cx [192.168.0.15]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id j0BEtiAI018252; Tue, 11 Jan 2005 09:55:45 -0500 (EST) (envelope-from jhb@FreeBSD.org) In-Reply-To: <86775.1105138701@critter.freebsd.dk> References: <86775.1105138701@critter.freebsd.dk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Baldwin Date: Tue, 11 Jan 2005 09:55:44 -0500 To: "Poul-Henning Kamp" X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: current@FreeBSD.org Subject: Re: kernel compilation in if_sis.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: Tue, 11 Jan 2005 14:56:27 -0000 On Jan 7, 2005, at 5:58 PM, Poul-Henning Kamp wrote: > > Are you sure your sources are consistent/up-to-date ? I got the same error trying to build LINT yesterday. > In message <1105136996.9713.1.camel@server.mcneil.com>, Sean McNeil > writes: >> >> --=-VGjSHlp1t1Sr22dGI19B >> Content-Type: text/plain >> Content-Transfer-Encoding: quoted-printable >> >> Can someone please fix this? >> >> =3D=3D=3D> sis (all) >> /usr/src/sys/modules/sis/../../pci/if_sis.c: In function `sis_intr': >> /usr/src/sys/modules/sis/../../pci/if_sis.c:1645: error: label `done' >> used but not defined >> *** Error code 1 >> >> Stop in /usr/src/sys/modules/sis. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 15:03:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1D8F16A4CE for ; Tue, 11 Jan 2005 15:03:31 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BA1F43D5A for ; Tue, 11 Jan 2005 15:03:31 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 21433 invoked from network); 11 Jan 2005 15:03:31 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 11 Jan 2005 15:03:27 -0000 Received: from [192.168.0.15] (osx.baldwin.cx [192.168.0.15]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id j0BF2krb018296; Tue, 11 Jan 2005 10:02:46 -0500 (EST) (envelope-from jhb@FreeBSD.org) In-Reply-To: <41E02AD7.5000005@root.org> References: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <41DEED05.4040000@root.org> <41DF0839.6040700@telia.com> <200501071728.16828.jhb@FreeBSD.org> <41DF2BB3.60800@root.org> <41DF347E.6010305@telia.com> <41DF5159.1090106@root.org> <41DF5DEA.3030904@telia.com> <41DF9481.5030305@root.org> <41DFA2FF.0@telia.com> <41E02AD7.5000005@root.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: John Baldwin Date: Tue, 11 Jan 2005 10:02:45 -0500 To: Nate Lawson X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: freebsd-current@FreeBSD.org Subject: Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 15:03:31 -0000 On Jan 8, 2005, at 1:47 PM, Nate Lawson wrote: > Pawel Worach wrote: >> Nate Lawson wrote: >> --- sys/dev/acpica/acpi_pcib.c 27 Dec 2004 05:36:47 -0000 1.53 >> +++ sys/dev/acpica/acpi_pcib.c 8 Jan 2005 09:05:57 -0000 >> @@ -249,11 +249,18 @@ >> /* >> * We have to find the source device (PCI interrupt link device). >> */ >> - if (ACPI_FAILURE(AcpiGetHandle(ACPI_ROOT_OBJECT, prt->Source, >> &lnkdev))) { >> + if (ACPI_FAILURE(AcpiGetHandle(acpi_get_handle(pcib), >> prt->Source, >> + &lnkdev))) { >> device_printf(pcib, "couldn't find PCI interrupt link device >> %s\n", >> prt->Source); >> goto out; >> } > > This change should not be committed. I think it's correct to use \ to > start the search since your _PRT contains relative references but the > links are under \. So, should I change the code to force-attach the devices to also use ACPI_ROOT_OBJECT for its lookup as well in prt_attach_devices()? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 15:10:22 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9BF9416A4CE; Tue, 11 Jan 2005 15:10:22 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3BE543D49; Tue, 11 Jan 2005 15:10:21 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id j0BFAL2x084146; Tue, 11 Jan 2005 10:10:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id j0BFALIi038731; Tue, 11 Jan 2005 10:10:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D04A57306E; Tue, 11 Jan 2005 10:10:20 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050111151020.D04A57306E@freebsd-current.sentex.ca> Date: Tue, 11 Jan 2005 10:10:20 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/640/Thu Dec 23 13:48:27 2004 clamav-milter version 0.80j on clamscanner3 X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 15:10:22 -0000 TB --- 2005-01-11 14:31:50 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-11 14:31:50 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-01-11 14:31:50 - checking out the source tree TB --- 2005-01-11 14:31:50 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-01-11 14:31:50 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-01-11 14:37:37 - building world (CFLAGS=-O2 -pipe) TB --- 2005-01-11 14:37:37 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-01-11 14:37: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 [...] mkdep -f .depend -a /tinderbox/CURRENT/i386/i386/src/sbin/kldstat/kldstat.c echo kldstat: /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/usr/lib/libc.a >> .depend ===> sbin/kldunload (depend) rm -f .depend mkdep -f .depend -a /tinderbox/CURRENT/i386/i386/src/sbin/kldunload/kldunload.c echo kldunload: /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/usr/lib/libc.a >> .depend ===> sbin/ldconfig (depend) make: don't know how to make shlib.c. Stop *** Error code 2 Stop in /tinderbox/CURRENT/i386/i386/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2005-01-11 15:10:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-01-11 15:10:20 - ERROR: failed to build world TB --- 2005-01-11 15:10:20 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 15:49:01 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DA9216A4CE; Tue, 11 Jan 2005 15:49:01 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15F9643D46; Tue, 11 Jan 2005 15:49:01 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j0BFn0A4069307; Tue, 11 Jan 2005 10:49:00 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id j0BFn0Qf010625; Tue, 11 Jan 2005 10:49:00 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D9CA87306E; Tue, 11 Jan 2005 10:48:59 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050111154859.D9CA87306E@freebsd-current.sentex.ca> Date: Tue, 11 Jan 2005 10:48:59 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/625/Fri Dec 10 12:41:57 2004 clamav-milter version 0.80j on clamscanner3 X-Virus-Scanned: ClamAV 0.80/640/Thu Dec 23 13:48:27 2004 clamav-milter version 0.80j on avscan2 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 15:49:01 -0000 TB --- 2005-01-11 15:10:20 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-11 15:10:20 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-01-11 15:10:20 - checking out the source tree TB --- 2005-01-11 15:10:20 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-01-11 15:10:20 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-01-11 15:16:10 - building world (CFLAGS=-O2 -pipe) TB --- 2005-01-11 15:16:10 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-01-11 15:16:10 - /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 [...] mkdep -f .depend -a /tinderbox/CURRENT/i386/pc98/src/sbin/kldstat/kldstat.c echo kldstat: /home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/i386/usr/lib/libc.a >> .depend ===> sbin/kldunload (depend) rm -f .depend mkdep -f .depend -a /tinderbox/CURRENT/i386/pc98/src/sbin/kldunload/kldunload.c echo kldunload: /home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/i386/usr/lib/libc.a >> .depend ===> sbin/ldconfig (depend) make: don't know how to make shlib.c. Stop *** Error code 2 Stop in /tinderbox/CURRENT/i386/pc98/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2005-01-11 15:48:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-01-11 15:48:59 - ERROR: failed to build world TB --- 2005-01-11 15:48:59 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 16:35:30 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16F2D16A4CE; Tue, 11 Jan 2005 16:35:30 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9404843D4C; Tue, 11 Jan 2005 16:35:29 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id j0BGZSeF091944; Tue, 11 Jan 2005 11:35:28 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id j0BGZIpK026659; Tue, 11 Jan 2005 11:35:18 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8FA947306E; Tue, 11 Jan 2005 11:35:18 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050111163518.8FA947306E@freebsd-current.sentex.ca> Date: Tue, 11 Jan 2005 11:35:18 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/640/Thu Dec 23 13:48:27 2004 clamav-milter version 0.80j on clamscanner3 X-Virus-Status: Clean Subject: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 16:35:30 -0000 TB --- 2005-01-11 15:49:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-11 15:49:00 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2005-01-11 15:49:00 - checking out the source tree TB --- 2005-01-11 15:49:00 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2005-01-11 15:49:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-01-11 15:54:41 - building world (CFLAGS=-O2 -pipe) TB --- 2005-01-11 15:54:41 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-01-11 15:54:41 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies [...] mkdep -f .depend -a /tinderbox/CURRENT/ia64/ia64/src/sbin/kldstat/kldstat.c echo kldstat: /home/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/i386/usr/lib/libc.a >> .depend ===> sbin/kldunload (depend) rm -f .depend mkdep -f .depend -a /tinderbox/CURRENT/ia64/ia64/src/sbin/kldunload/kldunload.c echo kldunload: /home/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/i386/usr/lib/libc.a >> .depend ===> sbin/ldconfig (depend) make: don't know how to make shlib.c. Stop *** Error code 2 Stop in /tinderbox/CURRENT/ia64/ia64/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2005-01-11 16:35:18 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-01-11 16:35:18 - ERROR: failed to build world TB --- 2005-01-11 16:35:18 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 17:14:43 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C3D316A4CE; Tue, 11 Jan 2005 17:14:43 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAF6C43D46; Tue, 11 Jan 2005 17:14:42 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j0BHEgKO078125; Tue, 11 Jan 2005 12:14:42 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.1/8.13.1) with ESMTP id j0BHEfxk029881; Tue, 11 Jan 2005 12:14:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9E7407306E; Tue, 11 Jan 2005 12:14:41 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050111171441.9E7407306E@freebsd-current.sentex.ca> Date: Tue, 11 Jan 2005 12:14:41 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/625/Fri Dec 10 12:41:57 2004 clamav-milter version 0.80j on clamscanner3 X-Virus-Scanned: ClamAV 0.80/649/Sun Jan 2 18:02:22 2005 clamav-milter version 0.80j on avscan2 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 17:14:43 -0000 TB --- 2005-01-11 16:35:18 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-11 16:35:18 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2005-01-11 16:35:18 - checking out the source tree TB --- 2005-01-11 16:35:18 - cd /home/tinderbox/CURRENT/powerpc/powerpc TB --- 2005-01-11 16:35:18 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-01-11 16:41:09 - building world (CFLAGS=-O2 -pipe) TB --- 2005-01-11 16:41:09 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2005-01-11 16:41:09 - /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 [...] mkdep -f .depend -a /tinderbox/CURRENT/powerpc/powerpc/src/sbin/kldstat/kldstat.c echo kldstat: /home/tinderbox/CURRENT/powerpc/powerpc/obj/powerpc/tinderbox/CURRENT/powerpc/powerpc/src/i386/usr/lib/libc.a >> .depend ===> sbin/kldunload (depend) rm -f .depend mkdep -f .depend -a /tinderbox/CURRENT/powerpc/powerpc/src/sbin/kldunload/kldunload.c echo kldunload: /home/tinderbox/CURRENT/powerpc/powerpc/obj/powerpc/tinderbox/CURRENT/powerpc/powerpc/src/i386/usr/lib/libc.a >> .depend ===> sbin/ldconfig (depend) make: don't know how to make shlib.c. Stop *** Error code 2 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/sbin. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2005-01-11 17:14:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-01-11 17:14:41 - ERROR: failed to build world TB --- 2005-01-11 17:14:41 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 17:23:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B4A016A4CE for ; Tue, 11 Jan 2005 17:23:10 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9843943D1D for ; Tue, 11 Jan 2005 17:23:09 +0000 (GMT) (envelope-from benjamin.becker@gmail.com) Received: by rproxy.gmail.com with SMTP id g11so17471rne for ; Tue, 11 Jan 2005 09:23:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=OySLTgZxNTr+0dIdQOz7D+c5riDS9aP3ejP6IZaBwuXvADCNILUrRrb4HZEo0UednJZTXQZvL/iQ8CahPGT5Ksglnm+OXws0G2jgogzQLgcQbVYHe7qmSMEjlEhuSKbuC0rnB1V2MCdcnuuE6UkYW+vVHjSeZliQXq9EElvi7oI= Received: by 10.38.13.79 with SMTP id 79mr212871rnm; Tue, 11 Jan 2005 09:23:09 -0800 (PST) Received: by 10.38.73.18 with HTTP; Tue, 11 Jan 2005 09:23:08 -0800 (PST) Message-ID: <38d37be7050111092379f2a898@mail.gmail.com> Date: Tue, 11 Jan 2005 09:23:08 -0800 From: Ben Becker To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Atheros and SIS bridging problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Ben Becker List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 17:23:10 -0000 Hello, I'm working on a FreeBSD-based bridge with one Atheros 5004X (5212) wireless interface and one SIS Ethernet interface. The Atheros interface is associated to an access point running hostap (another FreeBSD box) while the Ethernet port is connected to my laptop. Here's a quick outline: [Laptop]--------(sis0)-[FreeBSD Bridge]-(ath0)--------[FreeBSD AP] There seems to be a problem with bridging ath0 and sis0. I have 1 IP assigned to ath0 which is 192.168.1.3, and I've sysctl'd 'net.link.ether.bridge.enable=1' and 'net.link.ether.bridge.config=ath0,sis0'. From the bridge, I can ping the AP (192.168.1.1) and the laptop (192.168.1.5). However I can't ping from the laptop to the AP or from the AP to the laptop. When I sysctl net.link.ether.bridge.debug on, I notice something strange. Packets to and from the AP have a destination of BDG_UNKNOWN until the bridge shows 'bridge_in: new addr xx.xx.xx.xx.xx.xx at 3121 for ath0'. At that point, I'm able to send and receive a few packets through the link, but it's very inconsistent. However, the bridge debug info now shows the proper interfaces as the destination. This only lasts about 20 seconds until I get a 'bdg_timeout: flushing stale entry 3121' at which point everything gets forwarded to BDG_UNKNOWN again and no traffic gets passed. Wtihin a few minutes I get the 'bridge_in: new addr' message again and the cycle repeats. The amount of time seems to vary, though. I've tried this on current, 5.3 and 5.2.1. The wireless interface is configured without WEP and I've tried 11b and 11g mode. The AP is a 5.2.1 system with the same type of Atheros card in non-bridged 11b hostap mode. I can't think of any additional debug info other than the bridge debug output, so please let me know if there is anything else I can supply to help troubleshoot this issue. Also, has anybody successfully set up a bridge like this in the past? Best Regards, Ben Becker From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 18:34:28 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 469DB16A4CE; Tue, 11 Jan 2005 18:34:28 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id EFC1E43D48; Tue, 11 Jan 2005 18:34:27 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 26BA37A403; Tue, 11 Jan 2005 10:34:27 -0800 (PST) Message-ID: <41E41C32.3060904@elischer.org> Date: Tue, 11 Jan 2005 10:34:26 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: David Xu References: <41E3C2CF.3080601@freebsd.org> In-Reply-To: <41E3C2CF.3080601@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org Subject: Re: Kernel thread hash X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 18:34:28 -0000 David Xu wrote: > I am trying to make umtx robustness like Soloris does, when > a lock holder dies, other waiters will be noticed, I need > a fast way to find a thread by thread id, but current there > isn't, who is working on it ? No-one at the moment, though you might check with Marcell as he did the thread-ID stuff. > > > David Xu > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 19:13:55 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CC9416A4CE; Tue, 11 Jan 2005 19:13:55 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A2CB43D58; Tue, 11 Jan 2005 19:13:55 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j0BJDrGV009633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Jan 2005 11:13:54 -0800 Message-ID: <41E42570.8040503@root.org> Date: Tue, 11 Jan 2005 11:13:52 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <20587818.1102626838092.JavaMail.tomcat@pne-ps4-sn1> <41DEED05.4040000@root.org> <41DF0839.6040700@telia.com> <200501071728.16828.jhb@FreeBSD.org> <41DF2BB3.60800@root.org> <41DF347E.6010305@telia.com> <41DF5159.1090106@root.org> <41DF5DEA.3030904@telia.com> <41DF9481.5030305@root.org> <41DFA2FF.0@telia.com> <41E02AD7.5000005@root.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@FreeBSD.org Subject: Re: page fault panic in device_get_softc/acpi_pcib_route_interrupt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 19:13:55 -0000 John Baldwin wrote: > > On Jan 8, 2005, at 1:47 PM, Nate Lawson wrote: > >> Pawel Worach wrote: >> >>> Nate Lawson wrote: >>> --- sys/dev/acpica/acpi_pcib.c 27 Dec 2004 05:36:47 -0000 1.53 >>> +++ sys/dev/acpica/acpi_pcib.c 8 Jan 2005 09:05:57 -0000 >>> @@ -249,11 +249,18 @@ >>> /* >>> * We have to find the source device (PCI interrupt link device). >>> */ >>> - if (ACPI_FAILURE(AcpiGetHandle(ACPI_ROOT_OBJECT, prt->Source, >>> &lnkdev))) { >>> + if (ACPI_FAILURE(AcpiGetHandle(acpi_get_handle(pcib), prt->Source, >>> + &lnkdev))) { >>> device_printf(pcib, "couldn't find PCI interrupt link device %s\n", >>> prt->Source); >>> goto out; >>> } >> >> >> This change should not be committed. I think it's correct to use \ to >> start the search since your _PRT contains relative references but the >> links are under \. > > > So, should I change the code to force-attach the devices to also use > ACPI_ROOT_OBJECT for its lookup as well in prt_attach_devices()? > Sure, I think that's a good idea. -- Nate From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 20:25:02 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DE0816A4CE; Tue, 11 Jan 2005 20:25:02 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC3BA43D48; Tue, 11 Jan 2005 20:25:01 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id C5C1FACB34; Tue, 11 Jan 2005 21:24:52 +0100 (CET) Date: Tue, 11 Jan 2005 21:24:52 +0100 From: Pawel Jakub Dawidek To: freebsd-current@freebsd.org Message-ID: <20050111202452.GK795@darkness.comp.waw.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="p1Od3smaOkJqivj4" Content-Disposition: inline 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: njl@freebsd.org Subject: Intel SHG2 and ACPI problems. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 20:25:02 -0000 --p1Od3smaOkJqivj4 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi. I had problems with ACPI on Intel SHG2 motherboard. I made a patch with works for me just fine. Could you, Nate, verify it and commit if it is ok. If you need some more info, just ask. http://people.freebsd.org/~pjd/patches/acpi_pci_link.c.patch --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --p1Od3smaOkJqivj4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFB5DYUForvXbEpPzQRAkhKAKDKcHbka5VNhTkQl12by5s0rC2DWACg81sa 85UPnQ5wGxTpojSwIQD+Hw0= =KoLT -----END PGP SIGNATURE----- --p1Od3smaOkJqivj4-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 21:36:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id 8678B16A4CF; Tue, 11 Jan 2005 21:36:40 +0000 (GMT) Date: Tue, 11 Jan 2005 21:36:40 +0000 From: David O'Brien To: Jeff Roberson Message-ID: <20050111213640.GA88223@hub.freebsd.org> References: <20041213054007.Y9536@mail.chesapeake.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041213054007.Y9536@mail.chesapeake.net> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 4.11-RC2 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: SMP VFS Last call 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: Tue, 11 Jan 2005 21:36:40 -0000 On Mon, Dec 13, 2004 at 05:46:32AM -0500, Jeff Roberson wrote: > The SMP FFS/VFS patch has undergone several iterations and lots of serious > testing over the past few weeks. Many people, especially Peter Holm, have > sent me good bug reports. It's currently running on the port build > cluster and I have done extended load testing in small memory > configurations. What this means is, after I get back from vacation, it's > going to go into the tree. If you don't test it now, you will be in a few > weeks. :-) > > http://www.chesapeake.net/~jroberson/smpffs.diff Hi Jeff, Can you please commit this ASAP? It seems to be working very well. There are now conflicts between your patch and PHK's 2005 work. It has gotten to the point that testing this patch set is going to become too hard and the testers will have to revert to stock sources. Thanks! -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 21:55:27 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC33716A4CE; Tue, 11 Jan 2005 21:55:27 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 841C743D1D; Tue, 11 Jan 2005 21:55:27 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id BC08C51456; Tue, 11 Jan 2005 13:55:26 -0800 (PST) Date: Tue, 11 Jan 2005 13:55:26 -0800 From: Kris Kennaway To: David O'Brien Message-ID: <20050111215526.GA64909@xor.obsecurity.org> References: <20041213054007.Y9536@mail.chesapeake.net> <20050111213640.GA88223@hub.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: <20050111213640.GA88223@hub.freebsd.org> User-Agent: Mutt/1.4.2.1i cc: Jeff Roberson cc: current@freebsd.org Subject: Re: SMP VFS Last call X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 21:55:28 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 11, 2005 at 09:36:40PM +0000, David O'Brien wrote: > On Mon, Dec 13, 2004 at 05:46:32AM -0500, Jeff Roberson wrote: > > The SMP FFS/VFS patch has undergone several iterations and lots of seri= ous > > testing over the past few weeks. Many people, especially Peter Holm, h= ave > > sent me good bug reports. It's currently running on the port build > > cluster and I have done extended load testing in small memory > > configurations. What this means is, after I get back from vacation, it= 's > > going to go into the tree. If you don't test it now, you will be in a = few > > weeks. :-) > >=20 > > http://www.chesapeake.net/~jroberson/smpffs.diff > =20 > Hi Jeff, >=20 > Can you please commit this ASAP? It seems to be working very well. I've reported two repeatable panics in the most recent version. There's clearly some more work that needs to be done first. Kris --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB5EtOWry0BWjoQKURAq2yAJ0bDEjCv1IeaLVGfhKSNM8Ux+dEZQCggfJl 1XykjNVFipxnAlx0UAagzzY= =o88P -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 22:02:39 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEF5316A4CE for ; Tue, 11 Jan 2005 22:02:39 +0000 (GMT) Received: from stealth.sorbs.net (stealth.sorbs.net [203.15.51.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id EED4043D31 for ; Tue, 11 Jan 2005 22:02:38 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from goliath.sorbs.net (goliath.sorbs.net [203.15.51.42]) by stealth.sorbs.net (Postfix) with ESMTP id AD55CDF98F for ; Wed, 12 Jan 2005 08:02:36 +1000 (EST) Received: from twister.isux.com (unknown [192.168.1.5]) by goliath.sorbs.net (Postfix) with ESMTP id 262592C5C9 for ; Wed, 12 Jan 2005 08:02:37 +1000 (EST) Received: from [10.200.254.98] (stealthd.wireless.isux.com [10.200.254.98]) by twister.isux.com (iPlanet Messaging Server 5.2 HotFix 1.07 (built Nov 25 2002)) with ESMTPA id <0IA6006W1ACUB5@twister.isux.com> for freebsd-current@freebsd.org; Wed, 12 Jan 2005 07:58:09 +1000 (EST) Date: Wed, 12 Jan 2005 08:01:52 +1000 From: Matthew Sullivan To: freebsd-current@freebsd.org Message-id: <41E44CD0.1000008@uq.edu.au> MIME-version: 1.0 Content-type: multipart/signed; boundary=------------ms000303080006040701010801; micalg=sha1; protocol="application/x-pkcs7-signature" X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040618 Subject: Fatal Trap 12: Page fault while in kernel mode (racoon/amd64/5.3-RELEASE-p4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 22:02:39 -0000 This is a cryptographically signed message in MIME format. --------------ms000303080006040701010801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi All, Sorry, this is going to be a short introductory message rather than a full report initially due to lack of information. I seem to be having problems with a new AMD64 'Firewall' I am building - the last part of the puzzle being configuring at least 1 VPN tunnel. From what I can gather racoon is the defacto for setting up IPSec tunnels on FreeBSD. (I am still a relative newcomer to BSD being a Linux/Solaris fan to date - must say I am impressed) ...anyhow to the problem... Installation of the OS was from 5.3/amd64 CD's Kernel has been recompiled: FreeBSD desperado.sorbs.net 5.3-RELEASE-p4 FreeBSD 5.3-RELEASE-p4 #0: Tue Jan 11 17:08:16 EST 2005 root@desperado.sorbs.net:/usr/obj/usr/src/sys/DESPERADO amd64 (everything pretty much standard, will make config available if requested - IPFIREWALL is enabled) racoon compiled and installed from source (via Ports) Upon running of the binary the kernel will instantly trap a page fault which begins: Fatal Trap 12: Page fault while in kernel mode fault virtual address = 0xffffffffc93009fc fault code = supervisor read, page not present I have recompiled the kernel with KDB and KDB_UNATTENDED however it appears the machine is totally locked in this state - it will not automatically reboot, it will not respond to [CTRL-ALT-ESC] it will not even respond to [CTRL-ALT-DEL] - the only thing it will respond to is "the big red button" ;-) I have told it to save cores, however so far no cores. The crash is reproducible everytime. The fault process is recorded as racoon. Any suggestions on solving or debugging this further would be greatly appreciated. The machine is rack mounted and without remote management card so getting the rest of the trace information is not going to be easy. Regards, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms000303080006040701010801 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDExMTIyMDE1MlowIwYJKoZIhvcNAQkEMRYEFF6w3WRlBWLQCluZ WSkPOjffCqSiMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQCay+KA5CdkLPNBDXj6ScOjX9ftT8mzD+3t7n0LZvc4MGc1kEJMX52ZYfs2z2l0cvDz7 DutMnIIl29YHXFsq6tEAAAAAAAA= --------------ms000303080006040701010801-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 22:16:09 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 128BF16A4CE; Tue, 11 Jan 2005 22:16:09 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id B33B143D1F; Tue, 11 Jan 2005 22:16:08 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j0BMG7GV016434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Jan 2005 14:16:08 -0800 Message-ID: <41E45026.20208@root.org> Date: Tue, 11 Jan 2005 14:16:06 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20050111202452.GK795@darkness.comp.waw.pl> In-Reply-To: <20050111202452.GK795@darkness.comp.waw.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@FreeBSD.org cc: John Baldwin Subject: Re: Intel SHG2 and ACPI problems. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 22:16:09 -0000 Pawel Jakub Dawidek wrote: > I had problems with ACPI on Intel SHG2 motherboard. > I made a patch with works for me just fine. Could you, Nate, verify it > and commit if it is ok. > If you need some more info, just ask. > > http://people.freebsd.org/~pjd/patches/acpi_pci_link.c.patch John mentioned that it appears the root problem is that _CRS is failing for you. Can you send a dmesg from a broken boot (without your patch)? -- Nate From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 22:40:09 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF29216A4CE; Tue, 11 Jan 2005 22:40:09 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B49843D2D; Tue, 11 Jan 2005 22:40:09 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id A2A6CACBD2; Tue, 11 Jan 2005 23:40:07 +0100 (CET) Date: Tue, 11 Jan 2005 23:40:07 +0100 From: Pawel Jakub Dawidek To: Nate Lawson Message-ID: <20050111224007.GL795@darkness.comp.waw.pl> References: <20050111202452.GK795@darkness.comp.waw.pl> <41E45026.20208@root.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RHdRtM27np9fZUoh" Content-Disposition: inline In-Reply-To: <41E45026.20208@root.org> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-current@FreeBSD.org cc: John Baldwin Subject: Re: Intel SHG2 and ACPI problems. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 22:40:10 -0000 --RHdRtM27np9fZUoh Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 11, 2005 at 02:16:06PM -0800, Nate Lawson wrote: +> Pawel Jakub Dawidek wrote: +> >I had problems with ACPI on Intel SHG2 motherboard. +> >I made a patch with works for me just fine. Could you, Nate, verify it +> >and commit if it is ok. +> >If you need some more info, just ask. +> > +> > http://people.freebsd.org/~pjd/patches/acpi_pci_link.c.patch +>=20 +> John mentioned that it appears the root problem is that _CRS is failing= =20 +> for you. Can you send a dmesg from a broken boot (without your patch)? Here you go: http://people.freebsd.org/~pjd/misc/boot-v1.txt --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --RHdRtM27np9fZUoh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFB5FXHForvXbEpPzQRAjU6AJwO11OzN7mLqTMvmJxHl9JMifBLTACgnuOA ZLhmY2XMRBH8jYuSK+RCclI= =xt39 -----END PGP SIGNATURE----- --RHdRtM27np9fZUoh-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 22:45:52 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0762A16A4CE for ; Tue, 11 Jan 2005 22:45:52 +0000 (GMT) Received: from dragon.nuxi.com (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAD1943D1F for ; Tue, 11 Jan 2005 22:45:51 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.13.1/8.13.1) with ESMTP id j0BMjhoT004401; Tue, 11 Jan 2005 14:45:43 -0800 (PST) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.13.1/8.13.1/Submit) id j0BMjgUF004400; Tue, 11 Jan 2005 14:45:42 -0800 (PST) (envelope-from obrien) Date: Tue, 11 Jan 2005 14:45:42 -0800 From: "David O'Brien" To: Kris Kennaway Message-ID: <20050111224542.GA4269@dragon.nuxi.com> Mail-Followup-To: David O'Brien , Kris Kennaway , Jeff Roberson , current@freebsd.org References: <20041213054007.Y9536@mail.chesapeake.net> <20050111213640.GA88223@hub.freebsd.org> <20050111215526.GA64909@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050111215526.GA64909@xor.obsecurity.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: Jeff Roberson cc: current@freebsd.org Subject: Re: SMP VFS Last call 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: Tue, 11 Jan 2005 22:45:52 -0000 On Tue, Jan 11, 2005 at 01:55:26PM -0800, Kris Kennaway wrote: > On Tue, Jan 11, 2005 at 09:36:40PM +0000, David O'Brien wrote: > > On Mon, Dec 13, 2004 at 05:46:32AM -0500, Jeff Roberson wrote: > > > The SMP FFS/VFS patch has undergone several iterations and lots of serious > > > testing over the past few weeks. Many people, especially Peter Holm, have > > > sent me good bug reports. It's currently running on the port build > > > cluster and I have done extended load testing in small memory > > > configurations. What this means is, after I get back from vacation, it's > > > going to go into the tree. If you don't test it now, you will be in a few > > > weeks. :-) > > > > > > http://www.chesapeake.net/~jroberson/smpffs.diff > > > > Hi Jeff, > > > > Can you please commit this ASAP? It seems to be working very well. > > I've reported two repeatable panics in the most recent version. > There's clearly some more work that needs to be done first. Jeff, Mentioned there was one outstanding bug that was reported to him. BUT that he could commit his patchset but still always depend on GIANT. That way we would get fixes to the bugs he found, and Jeff could still work on the remaining ?locking? issue. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 23:05:20 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 67D6D16A4CE for ; Tue, 11 Jan 2005 23:05:20 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCE8443D3F for ; Tue, 11 Jan 2005 23:05:11 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.12] (g4.samsco.home [192.168.254.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id j0BN8gMZ093361; Tue, 11 Jan 2005 16:08:44 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <41E45BA3.3040606@freebsd.org> Date: Tue, 11 Jan 2005 16:05:07 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20041213054007.Y9536@mail.chesapeake.net> <20050111213640.GA88223@hub.freebsd.org> <20050111215526.GA64909@xor.obsecurity.org> <20050111224542.GA4269@dragon.nuxi.com> In-Reply-To: <20050111224542.GA4269@dragon.nuxi.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: Kris Kennaway Subject: Re: SMP VFS Last call X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 23:05:20 -0000 David O'Brien wrote: > On Tue, Jan 11, 2005 at 01:55:26PM -0800, Kris Kennaway wrote: > >>On Tue, Jan 11, 2005 at 09:36:40PM +0000, David O'Brien wrote: >> >>>On Mon, Dec 13, 2004 at 05:46:32AM -0500, Jeff Roberson wrote: >>> >>>>The SMP FFS/VFS patch has undergone several iterations and lots of serious >>>>testing over the past few weeks. Many people, especially Peter Holm, have >>>>sent me good bug reports. It's currently running on the port build >>>>cluster and I have done extended load testing in small memory >>>>configurations. What this means is, after I get back from vacation, it's >>>>going to go into the tree. If you don't test it now, you will be in a few >>>>weeks. :-) >>>> >>>>http://www.chesapeake.net/~jroberson/smpffs.diff >>> >>> >>>Hi Jeff, >>> >>>Can you please commit this ASAP? It seems to be working very well. >> >>I've reported two repeatable panics in the most recent version. >>There's clearly some more work that needs to be done first. > > > Jeff, > > Mentioned there was one outstanding bug that was reported to him. BUT > that he could commit his patchset but still always depend on GIANT. That > way we would get fixes to the bugs he found, and Jeff could still work on > the remaining ?locking? issue. > The biggest thing that concerns me about his work in not the Giant switch on VFS, it's the 'fixes' that he's made to UFS and SoftUpdates that cannot be turned off via a sysctl. Again, his lack of responsivness here means that it's hard to judge the safety of this work. Scott From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 00:41:12 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EFF516A4CE for ; Wed, 12 Jan 2005 00:41:12 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 523E143D2F for ; Wed, 12 Jan 2005 00:41:11 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 342A27A403 for ; Tue, 11 Jan 2005 16:41:11 -0800 (PST) Message-ID: <41E47226.8050001@elischer.org> Date: Tue, 11 Jan 2005 16:41:10 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: test(1) unexpected result (to me) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 00:41:12 -0000 # ls -l /sys lrwxrwxrwx 1 root wheel 11 Sep 4 22:03 /sys -> usr/src/sys # if [ /sys -ef /usr/src/sys ] > then > echo same > else > echo no > fi no I would have expected the result "same" comments? From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 00:54:36 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52C1D16A4CE for ; Wed, 12 Jan 2005 00:54:36 +0000 (GMT) Received: from mail.mcneil.com (mcneil.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08B9043D31 for ; Wed, 12 Jan 2005 00:54:36 +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 63EE6F27A6; Tue, 11 Jan 2005 16:54:35 -0800 (PST) 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 64556-10; Tue, 11 Jan 2005 16:54:34 -0800 (PST) Received: from mcneil.com (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id 6FB00F27A1; Tue, 11 Jan 2005 16:54:34 -0800 (PST) From: Sean McNeil To: Julian Elischer In-Reply-To: <41E47226.8050001@elischer.org> References: <41E47226.8050001@elischer.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-tv0lCrwrHrdz8oe0cldC" Date: Tue, 11 Jan 2005 16:54:34 -0800 Message-Id: <1105491274.67086.2.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port X-Virus-Scanned: by amavisd-new at mcneil.com cc: FreeBSD Current Subject: Re: test(1) unexpected result (to me) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 00:54:36 -0000 --=-tv0lCrwrHrdz8oe0cldC Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-01-11 at 16:41 -0800, Julian Elischer wrote: > # ls -l /sys > lrwxrwxrwx 1 root wheel 11 Sep 4 22:03 /sys -> usr/src/sys > # if [ /sys -ef /usr/src/sys ] > > then > > echo same > > else > > echo no > > fi > no >=20 >=20 > I would have expected the result "same" >=20 > comments? By "same file" they mean each references the same inode. Since this is a symlink, the files do not refer to the same file. You can see that if it were a hard link the result would be "same" echoed. Cheers, Sean --=-tv0lCrwrHrdz8oe0cldC Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBB5HVKyQsGN30uGE4RArsUAJ9GGwiJyAVy1Nm8ol1fSzL31L2ShwCeOXVD aYRNG1m0RUS1kH3LqgE6RIE= =eJlX -----END PGP SIGNATURE----- --=-tv0lCrwrHrdz8oe0cldC-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 00:56:39 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16D2716A4CE; Wed, 12 Jan 2005 00:56:39 +0000 (GMT) Received: from www.cryptography.com (li-22.members.linode.com [64.5.53.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA3EE43D1D; Wed, 12 Jan 2005 00:56:38 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222]) by www.cryptography.com (8.12.8/8.12.8) with ESMTP id j0C0ubGV021956 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Jan 2005 16:56:38 -0800 Message-ID: <41E475C5.8000800@root.org> Date: Tue, 11 Jan 2005 16:56:37 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: acpi@freebsd.org Subject: [Fwd: cvs commit: src/sys/contrib/dev/acpica dsutils.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: Wed, 12 Jan 2005 00:56:39 -0000 This fix should be tested by anyone with _STA errors ("no return object"). I'll MFC in a day or two given no major issues. -------- Original Message -------- Subject: cvs commit: src/sys/contrib/dev/acpica dsutils.c Date: Wed, 12 Jan 2005 00:52:49 +0000 (GMT) From: Nate Lawson To: njl@FreeBSD.ORG njl 2005-01-12 00:52:40 UTC FreeBSD src repository Modified files: (Branch: INTEL) sys/contrib/dev/acpica dsutils.c Log: Fix handling of the implicit return case for methods called from an external source (i.e., _STA). The previous case only handled calls occurring within AML. This should fix Toshibas, among others. Thanks to Robert Moore of Intel for the fix. MFC after: 2 days Revision Changes Path 1.1.1.23 +2 -1 src/sys/contrib/dev/acpica/dsutils.c Index: src/sys/contrib/dev/acpica/dsutils.c diff -u src/sys/contrib/dev/acpica/dsutils.c:1.1.1.22 src/sys/contrib/dev/acpica/dsutils.c:1.1.1.23 --- src/sys/contrib/dev/acpica/dsutils.c:1.1.1.22 Wed Dec 1 23:13:41 2004 +++ src/sys/contrib/dev/acpica/dsutils.c Wed Jan 12 00:52:40 2005 @@ -167,7 +167,8 @@ * An executing method typically has no parent, since each method * is parsed separately. */ - if (!Op->Common.Parent) + if (!Op->Common.Parent || + Op->Common.Parent->Common.AmlOpcode == AML_SCOPE_OP) { /* * If this is the last statement in the method, we know it is not a -- Nate From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 01:05:34 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A084116A4CE for ; Wed, 12 Jan 2005 01:05:34 +0000 (GMT) Received: from bloodwood.hunterlink.net.au (smtp-local.hunterlink.net.au [203.12.144.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C37743D2D for ; Wed, 12 Jan 2005 01:05:33 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from [61.8.40.78] (ppp284E.dyn.pacific.net.au [61.8.40.78]) j0C153h1019866; Wed, 12 Jan 2005 12:05:11 +1100 Message-ID: <41E47797.3010409@brooknet.com.au> Date: Wed, 12 Jan 2005 12:04:23 +1100 From: Sam Lawrance User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Elischer References: <41E47226.8050001@elischer.org> In-Reply-To: <41E47226.8050001@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: FreeBSD Current Subject: Re: test(1) unexpected result (to me) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 01:05:34 -0000 Julian Elischer wrote: > # ls -l /sys > lrwxrwxrwx 1 root wheel 11 Sep 4 22:03 /sys -> usr/src/sys > # if [ /sys -ef /usr/src/sys ] > > then > > echo same > > else > > echo no > > fi > no > > > I would have expected the result "same" > > comments? I see the opposite of this. Just to make sure... does your /usr/src/sys actually exist? -- Sam Lawrance ph +61 0425 228 579 freenode: deft From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 01:10:07 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5591116A4CE for ; Wed, 12 Jan 2005 01:10:07 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 383A143D1D for ; Wed, 12 Jan 2005 01:10:07 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 160F27A403; Tue, 11 Jan 2005 17:10:07 -0800 (PST) Message-ID: <41E478EF.9040508@elischer.org> Date: Tue, 11 Jan 2005 17:10:07 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Sean McNeil References: <41E47226.8050001@elischer.org> <1105491274.67086.2.camel@server.mcneil.com> In-Reply-To: <1105491274.67086.2.camel@server.mcneil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: FreeBSD Current Subject: Re: test(1) unexpected result (to me) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 01:10:07 -0000 Sean McNeil wrote: >On Tue, 2005-01-11 at 16:41 -0800, Julian Elischer wrote: > > >># ls -l /sys >>lrwxrwxrwx 1 root wheel 11 Sep 4 22:03 /sys -> usr/src/sys >># if [ /sys -ef /usr/src/sys ] >> > then >> > echo same >> > else >> > echo no >> > fi >>no >> >> >>I would have expected the result "same" >> >>comments? >> >> > >By "same file" they mean each references the same inode. Since this is >a symlink, the files do not refer to the same file. > >You can see that if it were a hard link the result would be "same" >echoed. > > yes, but this leaves us with no way to check that a file and a symlink are the same. >Cheers, >Sean > > > From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 01:11:09 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 681B116A4CE for ; Wed, 12 Jan 2005 01:11:09 +0000 (GMT) Received: from bloodwood.hunterlink.net.au (smtp-local.hunterlink.net.au [203.12.144.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id B700C43D41 for ; Wed, 12 Jan 2005 01:11:08 +0000 (GMT) (envelope-from boris@brooknet.com.au) Received: from [61.8.40.78] (ppp284E.dyn.pacific.net.au [61.8.40.78]) j0C1AJh1023500; Wed, 12 Jan 2005 12:10:37 +1100 Message-ID: <41E478FB.1060608@brooknet.com.au> Date: Wed, 12 Jan 2005 12:10:19 +1100 From: Sam Lawrance User-Agent: Mozilla Thunderbird 1.0 (X11/20050106) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sean McNeil References: <41E47226.8050001@elischer.org> <1105491274.67086.2.camel@server.mcneil.com> In-Reply-To: <1105491274.67086.2.camel@server.mcneil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: FreeBSD Current cc: Julian Elischer Subject: Re: test(1) unexpected result (to me) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 01:11:09 -0000 Sean McNeil wrote: >On Tue, 2005-01-11 at 16:41 -0800, Julian Elischer wrote: > > >># ls -l /sys >>lrwxrwxrwx 1 root wheel 11 Sep 4 22:03 /sys -> usr/src/sys >># if [ /sys -ef /usr/src/sys ] >> > then >> > echo same >> > else >> > echo no >> > fi >>no >> >> >>I would have expected the result "same" >> >>comments? >> >> > >By "same file" they mean each references the same inode. Since this is >a symlink, the files do not refer to the same file. > >You can see that if it were a hard link the result would be "same" >echoed. > test -ef uses stat() to compare the inodes. stat returns the inode of the pointed-to file, not the link. From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 01:13:59 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FE0316A4CE for ; Wed, 12 Jan 2005 01:13:59 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7AC143D3F for ; Wed, 12 Jan 2005 01:13:58 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id B90A17A403; Tue, 11 Jan 2005 17:13:58 -0800 (PST) Message-ID: <41E479D6.4090409@elischer.org> Date: Tue, 11 Jan 2005 17:13:58 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Sean McNeil References: <41E47226.8050001@elischer.org> <1105491274.67086.2.camel@server.mcneil.com> In-Reply-To: <1105491274.67086.2.camel@server.mcneil.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: FreeBSD Current Subject: Re: test(1) unexpected result (to me) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 01:13:59 -0000 never mind.. pilot error.. # ls -lL /sys lrwxrwxrwx 1 root wheel 11 Sep 4 22:03 /sys -> usr/src/sys # ls -l /usr/src/sys ls: /usr/src/sys: No such file or directory # mkdir /usr/src/sys # # if [ /sys -ef /usr/src/sys ] > then > echo same > else > echo no > fi same Sean McNeil wrote: >On Tue, 2005-01-11 at 16:41 -0800, Julian Elischer wrote: > > >># ls -l /sys >>lrwxrwxrwx 1 root wheel 11 Sep 4 22:03 /sys -> usr/src/sys >># if [ /sys -ef /usr/src/sys ] >> > then >> > echo same >> > else >> > echo no >> > fi >>no >> >> >>I would have expected the result "same" >> >>comments? >> >> > >By "same file" they mean each references the same inode. Since this is >a symlink, the files do not refer to the same file. > >You can see that if it were a hard link the result would be "same" >echoed. > >Cheers, >Sean > > > From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 02:51:51 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF8E316A4CE for ; Wed, 12 Jan 2005 02:51:51 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62D8D43D58 for ; Wed, 12 Jan 2005 02:51:51 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.92] ([66.127.85.92]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j0C2poWi024526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Jan 2005 18:51:50 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <41E490D4.70504@errno.com> Date: Tue, 11 Jan 2005 18:52:04 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Becker References: <38d37be7050111092379f2a898@mail.gmail.com> In-Reply-To: <38d37be7050111092379f2a898@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: Atheros and SIS bridging problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 02:51:51 -0000 Ben Becker wrote: > Hello, > > I'm working on a FreeBSD-based bridge with one Atheros 5004X (5212) > wireless interface and one SIS Ethernet interface. The Atheros > interface is associated to an access point running hostap (another > FreeBSD box) while the Ethernet port is connected to my laptop. > Here's a quick outline: > > [Laptop]--------(sis0)-[FreeBSD Bridge]-(ath0)--------[FreeBSD AP] > > There seems to be a problem with bridging ath0 and sis0. I have 1 IP > assigned to ath0 which is 192.168.1.3, and I've sysctl'd > 'net.link.ether.bridge.enable=1' and > 'net.link.ether.bridge.config=ath0,sis0'. From the bridge, I can ping > the AP (192.168.1.1) and the laptop (192.168.1.5). However I can't > ping from the laptop to the AP or from the AP to the laptop. > > When I sysctl net.link.ether.bridge.debug on, I notice something > strange. Packets to and from the AP have a destination of BDG_UNKNOWN > until the bridge shows 'bridge_in: new addr xx.xx.xx.xx.xx.xx at 3121 > for ath0'. At that point, I'm able to send and receive a few packets > through the link, but it's very inconsistent. However, the bridge > debug info now shows the proper interfaces as the destination. This > only lasts about 20 seconds until I get a 'bdg_timeout: flushing stale > entry 3121' at which point everything gets forwarded to BDG_UNKNOWN > again and no traffic gets passed. Wtihin a few minutes I get the > 'bridge_in: new addr' message again and the cycle repeats. The amount > of time seems to vary, though. > > I've tried this on current, 5.3 and 5.2.1. The wireless interface is > configured without WEP and I've tried 11b and 11g mode. The AP is a > 5.2.1 system with the same type of Atheros card in non-bridged 11b > hostap mode. I can't think of any additional debug info other than > the bridge debug output, so please let me know if there is anything > else I can supply to help troubleshoot this issue. Also, has anybody > successfully set up a bridge like this in the past? This doesn't work because the wireless interface will not receive frames from the ap destined for the laptop. You basically need/want to tunnel the laptop frames which requires support that's not currently in the system. Sam From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 08:33:03 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B73416A4CE for ; Wed, 12 Jan 2005 08:33:03 +0000 (GMT) Received: from heechee.tobez.org (heechee.tobez.org [217.157.39.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AB0F43D39 for ; Wed, 12 Jan 2005 08:33:02 +0000 (GMT) (envelope-from tobez@tobez.org) Received: by heechee.tobez.org (Postfix, from userid 1001) id E4A18125465; Wed, 12 Jan 2005 09:33:00 +0100 (CET) Date: Wed, 12 Jan 2005 09:33:00 +0100 From: Anton Berezin To: Max Khon Message-ID: <20050112083300.GB66718@heechee.tobez.org> Mail-Followup-To: Anton Berezin , Max Khon , Jamie Bowden , Randy Bush , FreeBSD Current References: <16749.21420.643438.983797@ran.psg.com> <20041013101825.B19494-100000@moo.sysabend.org> <20041014121852.GB28875@samodelkin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041014121852.GB28875@samodelkin.net> User-Agent: Mutt/1.4.2.1i cc: Randy Bush cc: Jamie Bowden cc: FreeBSD Current Subject: Re: beating mergemaster to /etc/rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 08:33:03 -0000 On Thu, Oct 14, 2004 at 07:18:52PM +0700, Max Khon wrote: > Personally, I do not understand why requests for the feature > "list of files to install automatically" are still rejected. A colleague of mine came up with an idea which I did not see before: Optionally, if CVS revisions are different, and CVS repository is available, fetch the file with the same revision as the installed one from CVS, and compare it with the installed one. If they are identical, mergemaster can safely assume that the file was not modified by hand and can therefore overwrite it without doing a diff loop hoop-la. I gave it a shot yesterday, and would appreciate any testing and feedback, especially because my shell skills suck. --- /usr/sbin/mergemaster Wed Dec 22 11:31:30 2004 +++ mergemaster Tue Jan 11 23:27:20 2005 @@ -30,6 +30,7 @@ display_usage () { echo ' -P Preserve files that are overwritten' echo " -m /path/directory Specify location of source to do the make in" echo " -t /path/directory Specify temp root directory" + echo " -R cvsroot Specify cvs repository and instruct to use it" echo " -d Add date and time to directory name (e.g., /var/tmp/temproot.`date +%m%d.%H.%M`)" echo " -u N Specify a numeric umask" echo " -w N Specify a screen width in columns to sdiff" @@ -238,7 +239,7 @@ fi # Check the command line options # -while getopts ":ascrvhipCPm:t:du:w:D:" COMMAND_LINE_ARGUMENT ; do +while getopts ":ascrvhipCPm:t:R:du:w:D:" COMMAND_LINE_ARGUMENT ; do case "${COMMAND_LINE_ARGUMENT}" in s) STRICT=yes @@ -284,6 +285,9 @@ while getopts ":ascrvhipCPm:t:du:w:D:" C t) TEMPROOT=${OPTARG} ;; + R) + CVSROOT=${OPTARG} + ;; d) TEMPROOT=${TEMPROOT}.`date +%m%d.%H.%M` ;; @@ -896,21 +900,69 @@ for COMPFILE in `find . -type f -size +0 echo " *** Temp ${COMPFILE} and installed are the same, deleting" rm "${COMPFILE}" else - # Ok, the files are different, so show the user where they differ. - # Use user's choice of diff methods; and user's pager if they have one. - # Use more if not. - # Use unified diffs by default. Context diffs give me a headache. :) - # - case "${AUTO_RUN}" in + DO_DIFF_LOOP=yes + + case "${CVSROOT}" in '') - # prompt user to install/delete/merge changes - diff_loop ;; *) - # If this is an auto run, make it official - echo " *** ${COMPFILE} will remain for your consideration" + CVSFILE=`grep "[$]${CVS_ID_TAG}:" ${DESTDIR}${COMPFILE#.} 2>/dev/null | + sed -e "s#.*[$]${CVS_ID_TAG}: \(src/.*\),v .*#\1#" 2>/dev/null` + CVSREV=`grep "[$]${CVS_ID_TAG}:" ${DESTDIR}${COMPFILE#.} 2>/dev/null | + sed -e "s#.*[$]${CVS_ID_TAG}: src/.*,v \([0-9.]*\) .*#\1#" 2>/dev/null` + case "${CVSFILE}" in + '') + ;; + *) + case "${CVSREV}" in + '') + ;; + *) + CVSFILE_N=`echo "${CVSFILE}"|wc -l` + CVSREV_N=`echo "${CVSREV}"|wc -l` + if [ ${CVSFILE_N} -eq 1 -a ${CVSREV_N} -eq 1 ]; then + CVSTEMP=`mktemp -t mmcvs` + cvs -d ${CVSROOT} co -r${CVSREV} -p ${CVSFILE} >${CVSTEMP} 2>/dev/null + if diff -q ${DIFF_OPTIONS} "${DESTDIR}${COMPFILE#.}" "${CVSTEMP}" > \ + /dev/null 2>&1; then + rm -f ${CVSTEMP} + echo '' + echo " *** The installed version of ${COMPFILE} is the same as" + echo " its CVS revision ${CVSREV}, overwriting it" + echo '' + if mm_install "${COMPFILE}"; then + echo " *** ${COMPFILE} installed successfully" + else + echo " *** Problem installing ${COMPFILE}, it will remain to merge by hand" + fi + unset DO_DIFF_LOOP + fi # same file in CVS and in DESTDIR, can overwrite it + rm -f ${CVSTEMP} + fi # CVSFILE and CVSREV can be used + ;; + esac # CVSREV non-empty + ;; + esac # CVSFILE non-empty ;; - esac # Auto run test + esac # cvs root test + + if [ -n "${DO_DIFF_LOOP}" ]; then + # Ok, the files are different, so show the user where they differ. + # Use user's choice of diff methods; and user's pager if they have one. + # Use more if not. + # Use unified diffs by default. Context diffs give me a headache. :) + # + case "${AUTO_RUN}" in + '') + # prompt user to install/delete/merge changes + diff_loop + ;; + *) + # If this is an auto run, make it official + echo " *** ${COMPFILE} will remain for your consideration" + ;; + esac # Auto run test + fi # Yes, do a diff loop fi # Yes, the files are different fi # Yes, the file still remains to be checked done # This is for the do way up there at the beginning of the comparison Cheers, \Anton. -- The moronity of the universe is a monotonically increasing function. -- Jarkko Hietaniemi From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 09:26:46 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DE0616A4CE for ; Wed, 12 Jan 2005 09:26:46 +0000 (GMT) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5763E43D5D for ; Wed, 12 Jan 2005 09:26:45 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received-SPF: pass (eva.fit.vutbr.cz: domain of xdivac02@eva.fit.vutbr.cz designates 127.0.0.1 as permitted sender) receiver=eva.fit.vutbr.cz; client_ip=127.0.0.1; envelope-from=xdivac02@eva.fit.vutbr.cz; Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (8.12.11/8.12.11) with ESMTP id j0C9QfhU061747 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 12 Jan 2005 10:26:41 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.12.11/8.12.5/Submit) id j0C9QfYT061746 for current@freebsd.org; Wed, 12 Jan 2005 10:26:41 +0100 (CET) Date: Wed, 12 Jan 2005 10:26:41 +0100 From: Divacky Roman To: current@freebsd.org Message-ID: <20050112092641.GA61635@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) Subject: non-killable process X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 09:26:46 -0000 hi, I have CFLAGS=-Os (dunno if it matters) compiled ports/net/iftop. and whenever I run it on recent 6-current it "hangs": 880 v4 R+ 0:00.05 iftop (ps ax output) and it cannot be killed - I can repeat it, so this might reveal some bug. I use sched_ule. roman From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 10:27:51 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37C9916A4CE for ; Wed, 12 Jan 2005 10:27:51 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 310DF43D5C for ; Wed, 12 Jan 2005 10:27:50 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j0CARns0035192 for ; Wed, 12 Jan 2005 11:27:49 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org From: Poul-Henning Kamp Date: Wed, 12 Jan 2005 11:27:48 +0100 Message-ID: <35191.1105525668@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: [TEST/REVIEW] vnode_if* 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: Wed, 12 Jan 2005 10:27:51 -0000 This patch (from perforce, use "cd /sys ; patch -p3 < foo") changes the generated vnode interface to improve test-coverage and type checking. Please review and test. Changes: Generate non-inlined VOP_FOO_AP() functions which take an argument structure pointer. Put all KASSERTS and checks into VOP_FOO_AP(). Add check for correct argument type. VOP_FOO() is still inline, but now only packs up the arguments and calls the corresponding VOP_FOO_AP() function. Put a pointer to the VOP_FOO_AP() function in the vnode description structure for VCALL() to use. In deadfs and unionfs use VOP_FOO_AP() instead of VCALL(). Remove now unused vdesc_offset and VOFFSET(). diff -ur -x compile -x _* freebsd/src/sys/fs/deadfs/dead_vnops.c phk/phk_dev/sys/fs/deadfs/dead_vnops.c --- freebsd/src/sys/fs/deadfs/dead_vnops.c Thu Jan 6 21:43:36 2005 +++ phk/phk_dev/sys/fs/deadfs/dead_vnops.c Wed Jan 12 10:57:13 2005 @@ -176,7 +176,7 @@ if (!chkvnlock(ap->a_vp)) return (ENOTTY); /* XXX: Doesn't this just recurse back here ? */ - return (VCALL(ap->a_vp, VOFFSET(vop_ioctl), ap)); + return (VOP_IOCTL_AP(ap)); } @@ -203,7 +203,7 @@ } if (!chkvnlock(vp)) return (0); - return (VCALL(vp, VOFFSET(vop_lock), ap)); + return (VOP_LOCK_AP(ap)); } /* diff -ur -x compile -x _* freebsd/src/sys/fs/nullfs/null_vnops.c phk/phk_dev/sys/fs/nullfs/null_vnops.c --- freebsd/src/sys/fs/nullfs/null_vnops.c Mon Jan 10 16:42:38 2005 +++ phk/phk_dev/sys/fs/nullfs/null_vnops.c Wed Jan 12 10:57:13 2005 @@ -296,7 +296,7 @@ * with the modified argument structure. */ if (vps_p[0] && *vps_p[0]) - error = VCALL(*(vps_p[0]), descp->vdesc_offset, ap); + error = VCALL(ap); else { printf("null_bypass: no map for %s\n", descp->vdesc_name); error = EINVAL; diff -ur -x compile -x _* freebsd/src/sys/fs/umapfs/umap_vnops.c phk/phk_dev/sys/fs/umapfs/umap_vnops.c --- freebsd/src/sys/fs/umapfs/umap_vnops.c Thu Jan 6 21:43:38 2005 +++ phk/phk_dev/sys/fs/umapfs/umap_vnops.c Wed Jan 12 10:57:13 2005 @@ -197,7 +197,7 @@ * Call the operation on the lower layer * with the modified argument structure. */ - error = VCALL(*(vps_p[0]), descp->vdesc_offset, ap); + error = VCALL(ap); /* * Maintain the illusion of call-by-value diff -ur -x compile -x _* freebsd/src/sys/fs/unionfs/union_vnops.c phk/phk_dev/sys/fs/unionfs/union_vnops.c --- freebsd/src/sys/fs/unionfs/union_vnops.c Tue Jan 11 09:53:01 2005 +++ phk/phk_dev/sys/fs/unionfs/union_vnops.c Wed Jan 12 11:12:21 2005 @@ -829,7 +829,7 @@ vp = un->un_lowervp; } ap->a_vp = vp; - return (VCALL(vp, VOFFSET(vop_close), ap)); + return (VOP_CLOSE_AP(ap)); } /* @@ -872,7 +872,7 @@ if ((vp = union_lock_upper(un, td)) != NULLVP) { ap->a_vp = vp; - error = VCALL(vp, VOFFSET(vop_access), ap); + error = VOP_ACCESS_AP(ap); union_unlock_upper(vp, td); return(error); } @@ -888,7 +888,7 @@ if ((un->un_vnode->v_mount->mnt_flag & MNT_RDONLY) == 0) ap->a_mode &= ~VWRITE; - error = VCALL(vp, VOFFSET(vop_access), ap); + error = VOP_ACCESS_AP(ap); if (error == 0) { struct union_mount *um; @@ -896,7 +896,7 @@ if (um->um_op == UNMNT_BELOW) { ap->a_cred = um->um_cred; - error = VCALL(vp, VOFFSET(vop_access), ap); + error = VOP_ACCESS_AP(ap); } } VOP_UNLOCK(vp, 0, td); @@ -1119,7 +1119,7 @@ struct vnode *ovp = OTHERVP(ap->a_vp); ap->a_vp = ovp; - return (VCALL(ovp, VOFFSET(vop_lease), ap)); + return (VOP_LEASE_AP(ap)); } static int @@ -1136,7 +1136,7 @@ struct vnode *ovp = OTHERVP(ap->a_vp); ap->a_vp = ovp; - return (VCALL(ovp, VOFFSET(vop_ioctl), ap)); + return (VOP_IOCTL_AP(ap)); } static int @@ -1151,7 +1151,7 @@ struct vnode *ovp = OTHERVP(ap->a_vp); ap->a_vp = ovp; - return (VCALL(ovp, VOFFSET(vop_poll), ap)); + return (VOP_POLL_AP(ap)); } static int @@ -1594,7 +1594,7 @@ if ((uvp = union_lock_upper(un, td)) != NULLVP) { ap->a_vp = uvp; - error = VCALL(uvp, VOFFSET(vop_readdir), ap); + error = VOP_READDIR_AP(ap); union_unlock_upper(uvp, td); } return(error); @@ -1618,7 +1618,7 @@ KASSERT(vp != NULL, ("union_readlink: backing vnode missing!")); ap->a_vp = vp; - error = VCALL(vp, VOFFSET(vop_readlink), ap); + error = VOP_READLINK_AP(ap); union_unlock_other(vp, td); return (error); @@ -1785,7 +1785,7 @@ KASSERT(vp != NULL, ("union_pathconf: backing vnode missing!")); ap->a_vp = vp; - error = VCALL(vp, VOFFSET(vop_pathconf), ap); + error = VOP_PATHCONF_AP(ap); union_unlock_other(vp, td); return (error); @@ -1804,7 +1804,7 @@ register struct vnode *ovp = OTHERVP(ap->a_vp); ap->a_vp = ovp; - return (VCALL(ovp, VOFFSET(vop_advlock), ap)); + return (VOP_ADVLOCK_AP(ap)); } @@ -1851,7 +1851,7 @@ vp = union_lock_other(un, ap->a_td); ap->a_vp = vp; - error = VCALL(vp, VOFFSET(vop_getacl), ap); + error = VOP_GETACL_AP(ap); union_unlock_other(vp, ap->a_td); return (error); @@ -1873,7 +1873,7 @@ vp = union_lock_other(un, ap->a_td); ap->a_vp = vp; - error = VCALL(vp, VOFFSET(vop_setacl), ap); + error = VOP_SETACL_AP(ap); union_unlock_other(vp, ap->a_td); return (error); @@ -1892,7 +1892,7 @@ struct vnode *ovp = OTHERVP(ap->a_vp); ap->a_vp = ovp; - return (VCALL(ovp, VOFFSET(vop_aclcheck), ap)); + return (VOP_ACLCHECK_AP(ap)); } static int @@ -1910,7 +1910,7 @@ vp = union_lock_other(un, ap->a_td); ap->a_vp = vp; - error = VCALL(vp, VOFFSET(vop_closeextattr), ap); + error = VOP_CLOSEEXTATTR_AP(ap); union_unlock_other(vp, ap->a_td); return (error); @@ -1934,7 +1934,7 @@ vp = union_lock_other(un, ap->a_td); ap->a_vp = vp; - error = VCALL(vp, VOFFSET(vop_getextattr), ap); + error = VOP_GETEXTATTR_AP(ap); union_unlock_other(vp, ap->a_td); return (error); @@ -1957,7 +1957,7 @@ vp = union_lock_other(un, ap->a_td); ap->a_vp = vp; - error = VCALL(vp, VOFFSET(vop_listextattr), ap); + error = VOP_LISTEXTATTR_AP(ap); union_unlock_other(vp, ap->a_td); return (error); @@ -1977,7 +1977,7 @@ vp = union_lock_other(un, ap->a_td); ap->a_vp = vp; - error = VCALL(vp, VOFFSET(vop_openextattr), ap); + error = VOP_OPENEXTATTR_AP(ap); union_unlock_other(vp, ap->a_td); return (error); @@ -1999,7 +1999,7 @@ vp = union_lock_other(un, ap->a_td); ap->a_vp = vp; - error = VCALL(vp, VOFFSET(vop_deleteextattr), ap); + error = VOP_DELETEEXTATTR_AP(ap); union_unlock_other(vp, ap->a_td); return (error); @@ -2022,7 +2022,7 @@ vp = union_lock_other(un, ap->a_td); ap->a_vp = vp; - error = VCALL(vp, VOFFSET(vop_setextattr), ap); + error = VOP_SETEXTATTR_AP(ap); union_unlock_other(vp, ap->a_td); return (error); @@ -2043,7 +2043,7 @@ vp = union_lock_other(un, ap->a_td); ap->a_vp = vp; - error = VCALL(vp, VOFFSET(vop_setlabel), ap); + error = VOP_SETLABEL_AP(ap); union_unlock_other(vp, ap->a_td); return (error); diff -ur -x compile -x _* freebsd/src/sys/kern/vfs_init.c phk/phk_dev/sys/kern/vfs_init.c --- freebsd/src/sys/kern/vfs_init.c Fri Jan 7 09:23:49 2005 +++ phk/phk_dev/sys/kern/vfs_init.c Wed Jan 12 00:04:51 2005 @@ -89,32 +89,6 @@ * Routines having to do with the management of the vnode table. */ -/* - * XXX: hack alert - */ -int -vcall(struct vnode *vp, u_int off, void *ap) -{ - struct vop_vector *vop = vp->v_op; - vop_bypass_t **bpt; - int rc; - - for(;;) { - bpt = (void *)((u_char *)vop + off); - if (vop != NULL && *bpt == NULL && vop->vop_bypass == NULL) { - vop = vop->vop_default; - continue; - } - break; - } - KASSERT(vop != NULL, ("No VCALL(%p...)", vp)); - if (*bpt != NULL) - rc = (*bpt)(ap); - else - rc = vop->vop_bypass(ap); - return (rc); -} - struct vfsconf * vfs_byname(const char *name) { diff -ur -x compile -x _* freebsd/src/sys/sys/vnode.h phk/phk_dev/sys/sys/vnode.h --- freebsd/src/sys/sys/vnode.h Fri Jan 7 09:24:14 2005 +++ phk/phk_dev/sys/sys/vnode.h Wed Jan 12 11:12:21 2005 @@ -409,6 +409,17 @@ #define VDESC_VPP_WILLRELE 0x0200 /* + * A generic structure. + * This can be used by bypass routines to identify generic arguments. + */ +struct vop_generic_args { + struct vnodeop_desc *a_desc; + /* other random data follows, presumably */ +}; + +typedef int vop_bypass_t(struct vop_generic_args *); + +/* * VDESC_NO_OFFSET is used to identify the end of the offset list * and in places where no such field exists. */ @@ -418,9 +429,9 @@ * This structure describes the vnode operation taking place. */ struct vnodeop_desc { - int vdesc_offset; /* offset in vector,first for speed */ char *vdesc_name; /* a readable name for debugging */ int vdesc_flags; /* VDESC_* flags */ + vop_bypass_t *vdesc_call; /* Function to call */ /* * These ops are used by bypass routines to map and locate arguments. @@ -451,14 +462,6 @@ #define VOPARG_OFFSETTO(s_type, s_offset, struct_p) \ ((s_type)(((char*)(struct_p)) + (s_offset))) -/* - * A generic structure. - * This can be used by bypass routines to identify generic arguments. - */ -struct vop_generic_args { - struct vnodeop_desc *a_desc; - /* other random data follows, presumably */ -}; #ifdef DEBUG_VFS_LOCKS /* @@ -521,9 +524,8 @@ /* * This call works for vnodes in the kernel. */ -#define VCALL(a, b, c) vcall((a), (b), (c)) +#define VCALL(c) ((c)->a_desc->vdesc_call(c)) #define VDESC(OP) (& __CONCAT(OP,_desc)) -#define VOFFSET(OP) (VDESC(OP)->vdesc_offset) /* * VMIO support inline @@ -674,7 +676,6 @@ int vop_stdcreatevobject(struct vop_createvobject_args *ap); int vop_stddestroyvobject(struct vop_destroyvobject_args *ap); int vop_stdgetvobject(struct vop_getvobject_args *ap); -int vcall(struct vnode *vp, u_int off, void *ap); void vfree(struct vnode *); void vput(struct vnode *vp); diff -ur -x compile -x _* freebsd/src/sys/tools/vnode_if.awk phk/phk_dev/sys/tools/vnode_if.awk --- freebsd/src/sys/tools/vnode_if.awk Fri Jan 7 09:24:14 2005 +++ phk/phk_dev/sys/tools/vnode_if.awk Wed Jan 12 10:57:13 2005 @@ -62,25 +62,27 @@ function printp(s) {print s > pfile;} function printq(s) {print s > qfile;} -function add_debug_code(name, arg, pos) +function add_debug_code(name, arg, pos, ind) { if (arg == "vpp") - arg = "*vpp"; + star = "*"; + else + star = ""; if (lockdata[name, arg, pos] && (lockdata[name, arg, pos] != "-")) { if (arg ~ /^\*/) { - printh("\tif ("substr(arg, 2)" != NULL) {"); + printc(ind"if ("substr(arg, 2)" != NULL) {"); } - printh("\tASSERT_VI_UNLOCKED("arg", \""uname"\");"); + printc(ind"ASSERT_VI_UNLOCKED("star"a->a_"arg", \""uname"\");"); # Add assertions for locking if (lockdata[name, arg, pos] == "L") - printh("\tASSERT_VOP_LOCKED("arg", \""uname"\");"); + printc(ind"ASSERT_VOP_LOCKED(" star "a->a_"arg", \""uname"\");"); else if (lockdata[name, arg, pos] == "U") - printh("\tASSERT_VOP_UNLOCKED("arg", \""uname"\");"); + printc(ind"ASSERT_VOP_UNLOCKED(" star "a->a_"arg", \""uname"\");"); else if (0) { # XXX More checks! } if (arg ~ /^\*/) { - printh("\t}"); + printc("ind}"); } } } @@ -88,18 +90,18 @@ function add_debug_pre(name) { if (lockdata[name, "pre"]) { - printh("#ifdef DEBUG_VFS_LOCKS"); - printh("\t"lockdata[name, "pre"]"(&a);"); - printh("#endif"); + printc("#ifdef DEBUG_VFS_LOCKS"); + printc("\t"lockdata[name, "pre"]"(a);"); + printc("#endif"); } } function add_debug_post(name) { if (lockdata[name, "post"]) { - printh("#ifdef DEBUG_VFS_LOCKS"); - printh("\t"lockdata[name, "post"]"(&a, rc);"); - printh("#endif"); + printc("#ifdef DEBUG_VFS_LOCKS"); + printc("\t"lockdata[name, "post"]"(a, rc);"); + printc("#endif"); } } @@ -159,8 +161,6 @@ if (qfile) { printq(common_head) - printq("struct vop_generic_args;") - printq("typedef int vop_bypass_t(struct vop_generic_args *);\n") } if (hfile) { @@ -176,9 +176,9 @@ "#include \n" \ "\n" \ "struct vnodeop_desc vop_default_desc = {\n" \ - " 1,\t\t\t/* special case, vop_default => 1 */\n" \ " \"default\",\n" \ " 0,\n" \ + " (void *)(uintptr_t)vop_panic,\n" \ " NULL,\n" \ " VDESC_NO_OFFSET,\n" \ " VDESC_NO_OFFSET,\n" \ @@ -196,8 +196,6 @@ $2 !~ /^[a-z]+$/ || $3 !~ /^[a-z]+$/ || \ $4 !~ /^.$/ || $5 !~ /^.$/ || $6 !~ /^.$/) continue; - if ($3 == "vpp") - $3 = "*vpp"; lockdata["vop_" $2, $3, "Entry"] = $4; lockdata["vop_" $2, $3, "OK"] = $5; lockdata["vop_" $2, $3, "Error"] = $6; @@ -280,9 +278,10 @@ ctrargs = 6; else ctrargs = numargs; - ctrstr = "\tCTR" ctrargs "(KTR_VOP, " ctrstr ")\""; - for (i = 0; i < ctrargs; ++i) - ctrstr = ctrstr ", " args[i]; + ctrstr = "\tCTR" ctrargs "(KTR_VOP,\n\t " ctrstr ")\",\n\t "; + ctrstr = ctrstr "a->a_" args[0]; + for (i = 1; i < ctrargs; ++i) + ctrstr = ctrstr ", a->a_" args[i]; ctrstr = ctrstr ");"; if (pfile) { @@ -299,44 +298,30 @@ for (i = 0; i < numargs; ++i) printh("\t" t_spc(types[i]) "a_" args[i] ";"); printh("};"); + printh(""); # Print out extern declaration. printh("extern struct vnodeop_desc " name "_desc;"); + printh(""); - # Print out function. + # Print out function prototypes. + printh("int " uname "_AP(struct " name "_args *);"); + printh(""); printh("static __inline int " uname "("); for (i = 0; i < numargs; ++i) { printh("\t" t_spc(types[i]) args[i] \ (i < numargs - 1 ? "," : ")")); } - printh("{\n\tstruct " name "_args a;"); - printh("\tint rc;"); + printh("{"); + printh("\tstruct " name "_args a;"); + printh(""); printh("\ta.a_gen.a_desc = VDESC(" name ");"); for (i = 0; i < numargs; ++i) printh("\ta.a_" args[i] " = " args[i] ";"); - for (i = 0; i < numargs; ++i) - add_debug_code(name, args[i], "Entry"); - add_debug_pre(name); - printh("\t{") - printh("\t\tstruct vop_vector *vop = "args[0]"->v_op;") - printh("\t\twhile(vop != NULL && vop->"name" == NULL && vop->vop_bypass == NULL)") - printh("\t\t\tvop = vop->vop_default;") - printh("\t\tKASSERT(vop != NULL, (\"No "name"(%p...)\", "args[0]"));") - printh("\t\tif (vop->"name" != NULL)") - printh("\t\t\trc = vop->"name"(&a);") - printh("\t\telse") - printh("\t\t\trc = vop->vop_bypass(&a.a_gen);") - printh("\t}") - printh(ctrstr); - printh("if (rc == 0) {"); - for (i = 0; i < numargs; ++i) - add_debug_code(name, args[i], "OK"); - printh("} else {"); - for (i = 0; i < numargs; ++i) - add_debug_code(name, args[i], "Error"); + printh("\treturn (" uname "_AP(&a));"); printh("}"); - add_debug_post(name); - printh("\treturn (rc);\n}"); + + printh(""); } if (cfile) { @@ -362,10 +347,40 @@ printc("\tVDESC_NO_OFFSET"); printc("};"); + # Print out function. + printc("\nint\n" uname "_AP(struct " name "_args *a)"); + printc("{"); + printc("\tint rc;"); + printc("\tstruct vnode *vp = a->a_" args[0]";"); + printc("\tstruct vop_vector *vop = vp->v_op;"); + printc(""); + printc("\tKASSERT(a->a_gen.a_desc == VDESC(" name "),"); + printc("\t (\"Wrong a_desc in " name "(%p, %p)\", vp, a));"); + printc("\twhile(vop != NULL && \\"); + printc("\t vop->"name" == NULL && vop->vop_bypass == NULL)") + printc("\t\tvop = vop->vop_default;") + printc("\tKASSERT(vop != NULL, (\"No "name"(%p, %p)\", vp, a));") + for (i = 0; i < numargs; ++i) + add_debug_code(name, args[i], "Entry", "\t"); + add_debug_pre(name); + printc("\tif (vop->"name" != NULL)") + printc("\t\trc = vop->"name"(a);") + printc("\telse") + printc("\t\trc = vop->vop_bypass(&a->a_gen);") + printc(ctrstr); + printc("\tif (rc == 0) {"); + for (i = 0; i < numargs; ++i) + add_debug_code(name, args[i], "OK", "\t\t"); + printc("\t} else {"); + for (i = 0; i < numargs; ++i) + add_debug_code(name, args[i], "Error", "\t\t"); + printc("\t}"); + add_debug_post(name); + printc("\treturn (rc);"); + printc("}\n"); + # Print out the vnodeop_desc structure. printc("struct vnodeop_desc " name "_desc = {"); - # offset - printc("\toffsetof(struct vop_vector, "name"),"); # printable name printc("\t\"" name "\","); # flags @@ -381,6 +396,8 @@ releflags = "0"; printc("\t" releflags vppwillrele ","); + # function to call + printc("\t(void*)(uintptr_t)" uname "_AP,"); # vp offsets printc("\t" name "_vp_offsets,"); # vpp (if any) @@ -393,6 +410,7 @@ printc("\t" find_arg_with_type("struct componentname *") ","); # transport layer information printc("\tNULL,\n};\n"); + } } -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 10:50:37 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9451B16A4CE; Wed, 12 Jan 2005 10:50:37 +0000 (GMT) Received: from mail07.syd.optusnet.com.au (mail07.syd.optusnet.com.au [211.29.132.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDAC343D4C; Wed, 12 Jan 2005 10:50:36 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j0CAoYsc020904 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 12 Jan 2005 21:50:35 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j0CAoYxP052233; Wed, 12 Jan 2005 21:50:34 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j0CAoYuE052232; Wed, 12 Jan 2005 21:50:34 +1100 (EST) (envelope-from pjeremy) Date: Wed, 12 Jan 2005 21:50:34 +1100 From: Peter Jeremy To: Anton Berezin Message-ID: <20050112105034.GA51959@cirb503493.alcatel.com.au> References: <16749.21420.643438.983797@ran.psg.com> <20041013101825.B19494-100000@moo.sysabend.org> <20041014121852.GB28875@samodelkin.net> <20050112083300.GB66718@heechee.tobez.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050112083300.GB66718@heechee.tobez.org> User-Agent: Mutt/1.4.2i cc: FreeBSD Current Subject: Re: beating mergemaster to /etc/rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 10:50:37 -0000 On Wed, 2005-Jan-12 09:33:00 +0100, Anton Berezin wrote: >A colleague of mine came up with an idea which I did not see before: > >Optionally, if CVS revisions are different, and CVS repository is >available, fetch the file with the same revision as the installed one >from CVS, and compare it with the installed one. If they are identical, >mergemaster can safely assume that the file was not modified by hand and >can therefore overwrite it without doing a diff loop hoop-la. I think this has been suggested before but you are the first person to actually code it. Thank you. Note that there are still risks in blindly applying CVS changes. There have been a couple of cases where defaults have changed meaning that corresponding changes to local system configuration is required to retain previous behaviour. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 11:59:56 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5DD316A4CE for ; Wed, 12 Jan 2005 11:59:56 +0000 (GMT) Received: from heechee.tobez.org (heechee.tobez.org [217.157.39.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id D252443D48 for ; Wed, 12 Jan 2005 11:59:55 +0000 (GMT) (envelope-from tobez@tobez.org) Received: by heechee.tobez.org (Postfix, from userid 1001) id 3CA0F125465; Wed, 12 Jan 2005 12:59:54 +0100 (CET) Date: Wed, 12 Jan 2005 12:59:54 +0100 From: Anton Berezin To: Peter Jeremy Message-ID: <20050112115954.GB68344@heechee.tobez.org> Mail-Followup-To: Anton Berezin , Peter Jeremy , FreeBSD Current References: <16749.21420.643438.983797@ran.psg.com> <20041013101825.B19494-100000@moo.sysabend.org> <20041014121852.GB28875@samodelkin.net> <20050112083300.GB66718@heechee.tobez.org> <20050112105034.GA51959@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050112105034.GA51959@cirb503493.alcatel.com.au> User-Agent: Mutt/1.4.2.1i cc: FreeBSD Current Subject: Re: beating mergemaster to /etc/rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 11:59:56 -0000 On Wed, Jan 12, 2005 at 09:50:34PM +1100, Peter Jeremy wrote: > On Wed, 2005-Jan-12 09:33:00 +0100, Anton Berezin wrote: > >A colleague of mine came up with an idea which I did not see before: > > > >Optionally, if CVS revisions are different, and CVS repository is > >available, fetch the file with the same revision as the installed one > >from CVS, and compare it with the installed one. If they are identical, > >mergemaster can safely assume that the file was not modified by hand and > >can therefore overwrite it without doing a diff loop hoop-la. > Note that there are still risks in blindly applying CVS changes. There > have been a couple of cases where defaults have changed meaning that > corresponding changes to local system configuration is required to > retain previous behaviour. Yeah, the possibility to shoot yourself if the foot is always there. On the other hand, I would expect that 1) changes in defaults should be in UPDATING, and 2) most people qi such files (say, for /etc/defaults/rc.conf) without looking too closely into the actual diffs. \Anton. -- The moronity of the universe is a monotonically increasing function. -- Jarkko Hietaniemi From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 12:47:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25EF116A4CE; Wed, 12 Jan 2005 12:47:57 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 191F843D48; Wed, 12 Jan 2005 12:47:54 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j0CCln8L098110; Wed, 12 Jan 2005 23:17:50 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Wed, 12 Jan 2005 23:17:37 +1030 User-Agent: KMail/1.7.1 References: <16749.21420.643438.983797@ran.psg.com> <20050112105034.GA51959@cirb503493.alcatel.com.au> <20050112115954.GB68344@heechee.tobez.org> In-Reply-To: <20050112115954.GB68344@heechee.tobez.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1519589.c9QQFITtb6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501122317.44517.doconnor@gsoft.com.au> X-Spam-Score: -5.4 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Peter Jeremy cc: Anton Berezin Subject: Re: beating mergemaster to /etc/rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 12:47:57 -0000 --nextPart1519589.c9QQFITtb6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 12 Jan 2005 22:29, Anton Berezin wrote: > > Note that there are still risks in blindly applying CVS changes. There > > have been a couple of cases where defaults have changed meaning that > > corresponding changes to local system configuration is required to > > retain previous behaviour. > > Yeah, the possibility to shoot yourself if the foot is always there. On > the other hand, I would expect that 1) changes in defaults should be in > UPDATING, and 2) most people qi such files (say, for > /etc/defaults/rc.conf) without looking too closely into the actual > diffs. Those default changes are always (or should always be :) UPDATING fodder.. *cough*etcmerge*cough* :) =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 --nextPart1519589.c9QQFITtb6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBB5Rxw5ZPcIHs/zowRAnQrAKCfDWY+zVG1QPvmGrjRH93WM2RmSACgiwQx Zf9XcHGcFeFdSODFJEbO53s= =j5uW -----END PGP SIGNATURE----- --nextPart1519589.c9QQFITtb6-- From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 15:10:44 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7B5516A4CE for ; Tue, 11 Jan 2005 15:10:44 +0000 (GMT) Received: from mail2.speakeasy.net (mail2.speakeasy.net [216.254.0.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6E0B43D5E for ; Tue, 11 Jan 2005 15:10:41 +0000 (GMT) (envelope-from john@baldwin.cx) Received: (qmail 16883 invoked from network); 11 Jan 2005 15:10:41 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 11 Jan 2005 15:08:21 -0000 Received: from [192.168.0.15] (osx.baldwin.cx [192.168.0.15]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id j0BF8D43018321; Tue, 11 Jan 2005 10:08:13 -0500 (EST) (envelope-from john@baldwin.cx) In-Reply-To: <20050109101529.GM39552@cirb503493.alcatel.com.au> References: <20050109011132.GJ39552@cirb503493.alcatel.com.au> <41E0C02F.60100@freebsd.org> <20050109101529.GM39552@cirb503493.alcatel.com.au> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9D0B94DA-63E2-11D9-A25E-000393921CC4@baldwin.cx> Content-Transfer-Encoding: 7bit From: John Baldwin Date: Tue, 11 Jan 2005 10:08:13 -0500 To: Peter Jeremy X-Mailer: Apple Mail (2.619) X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx X-Mailman-Approved-At: Wed, 12 Jan 2005 14:26:47 +0000 cc: freebsd-current@freebsd.org cc: Scott Long Subject: Re: bus_dmamem_alloc() can't handle large NOWAIT requests X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 15:10:45 -0000 On Jan 9, 2005, at 5:15 AM, Peter Jeremy wrote: > On Sat, 2005-Jan-08 22:25:03 -0700, Scott Long wrote: >>> According to bus_dma(9), bus_dmamem_alloc() can be invoked with a >>> flag BUS_DMA_NOWAIT to indicate that sleep()ing is not allowed. >>> >>> At least on the i386, if the requested size exceeds 1 page (or some >>> other cases), the requested memory will be allocated via >>> contigmalloc(). > ... >> Will contigmalloc() actually sleep? If so, then this is something >> that >> needs to be addressed in contigmalloc. > > I have not actually seen this occur. If I get some time, I might see > if I can force the issue. Reading the code, I believe it can. > > Firstly: > 1) if (vm_old_contigmalloc), contigmalloc1() locks vm_page_queue_mtx > via vm_page_lock_queues(). > 2) Otherwise, contigmalloc2() calls vm_map_lock() which locks > kernel_map->system_mtx > > Both these mutexes are MTX_DEF (sleepable) and there doesn't appear > to be anything preventing them from sleeping. Unforunately, "sleep" is a bit of an overloaded term in the kernel. Blocking on a mutex is not considered a "sleep" quite like msleep() or cv_wait() in that a mutex will eventually be released (barring an infinite loop bug) and thus a thread blocked on a lock won't sleep forever. msleep() and cv_wait() on the other hand do not have the same guarantee. M_NOWAIT means that msleep() and cv_wait() won't be called; it is ok to block on a mutex with M_NOWAIT however. I tried to explain this difference in semantics some in the glossary of the SMP chapter in the kernel devbook. > -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 18:57:49 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B35E716A4CE for ; Tue, 11 Jan 2005 18:57:49 +0000 (GMT) Received: from forrie.com (forrie.ne.client2.attbi.com [24.147.45.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 408DA43D1F for ; Tue, 11 Jan 2005 18:57:49 +0000 (GMT) (envelope-from forrie@forrie.com) Received: from [192.168.1.99] (i-99.forrie.net. [192.168.1.99]) (authenticated bits=0) by forrie.com with ESMTP id j0BIvfvB009985verify=NO) for ; Tue, 11 Jan 2005 13:57:42 -0500 (EST) (envelope-from forrie@forrie.com) Message-ID: <41E42221.8090208@forrie.com> Date: Tue, 11 Jan 2005 13:59:45 -0500 From: Forrest Aldrich User-Agent: Mozilla Thunderbird 1.0 (Windows/20041226) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RAVMilter-Version: 8.3.0(snapshot 20010925) (forrie.ne.client2.attbi.com) X-MailScanner-LocalNet: Found to be clean X-Mailman-Approved-At: Wed, 12 Jan 2005 14:26:47 +0000 Subject: PF timestamp stats on rule hits? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 18:57:49 -0000 After reading through the manpage for pfctl, I wonder if there's a mechanism/equivalent for PF that shows the timestamp of the last "hit" on a rule... similar to "ipfw -t"...? Might be useful to include a function to output stats in XML for further parsing. Thanks. From owner-freebsd-current@FreeBSD.ORG Tue Jan 11 21:38:53 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B695E16A4CE for ; Tue, 11 Jan 2005 21:38:53 +0000 (GMT) Received: from just.puresimplicity.net (just.puresimplicity.net [140.177.207.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E3DD43D3F for ; Tue, 11 Jan 2005 21:38:53 +0000 (GMT) (envelope-from craig@puresimplicity.net) Received: from localhost (CPE0050bf78b8c6-CM023459906096.cpe.net.cable.rogers.com [24.157.84.118]) (authenticated bits=0)j0BLckfq090568 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 11 Jan 2005 15:38:48 -0600 (CST) (envelope-from craig@backfire.ca) Date: Tue, 11 Jan 2005 16:38:41 -0500 From: Craig Reyenga To: Matt Reimer Message-ID: <20050111213841.GA6373@burnout.lan.bluemidnight.ca> References: <200501101547.18892.mreimer@vpop.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501101547.18892.mreimer@vpop.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV 0.80/610/Sun Nov 28 15:32:08 2004 clamav-milter version 0.80j on just.puresimplicity.net X-Virus-Status: Clean X-Spam-Status: No, score=1.8 required=8.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=disabled version=3.0.1 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on just.puresimplicity.net X-Mailman-Approved-At: Wed, 12 Jan 2005 14:26:47 +0000 cc: freebsd-current@freebsd.org Subject: Re: Reproducible filesystem deadlock on RELENG_5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Craig Reyenga List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2005 21:38:53 -0000 On Mon, Jan 10, 2005 at 03:47:18PM -0800, Matt Reimer wrote: > On a UP machine (P4, 128M RAM) running RELENG_5 (as of Friday), I am seeing > what looks like a hang or deadlock on a filesystem with 10 snapshots. Our > problems began when we ran out of disk space, resulting in a series of > these log messages: > > kernel: pid 39 (bufdaemon), uid 0 inumber 7277783 on /backup: filesystem > full > kernel: initiate_write_filepage: already started > > So I tried to delete a snapshot to free up some space, but then the kernel > began panicking. In my effort to workaround the panic, I disabled > softupdates. Then I came across the identical panic in a post by Kris > Kennaway > (http://lists.freebsd.org/pipermail/freebsd-current/2004-September/036946.html), > which he fixed by increasing KSTACK_PAGES. After increasing it to 31, the > kernel no longer panics, but instead filesystem access seems to deadlock: > if I try to even touch a file into existence on that partition, the touch > command hangs in state 'wdrain', and other attempts to access that > filesystem hang as well. This problem is 100% reproducible. > > How to proceed? Serial console access is available if someone wants to > tackle it. > > Matt > [sniiip] Hi, I am seeing this too, and it would appear that I've been beaten to sending a message about it. :) This is what my /var/log/kernel had to say, after rebooting from a (live|dead)lock. Jan 11 00:23:08 burnout kernel: >pid 44 (pagedaemon), uid 0 inumber 8298 on /var: filesystem full Jan 11 00:23:08 burnout kernel: vnode_pager_putpages: I/O error 28 Jan 11 00:23:08 burnout kernel: vnode_pager_putpages: residual I/O 65536 at 21872 Jan 11 00:23:08 burnout kernel: pid 44 (pagedaemon), uid 0 inumber 8298 on /var: filesystem full Jan 11 00:23:08 burnout kernel: vnode_pager_putpages: I/O error 28 Jan 11 00:23:08 burnout kernel: vnode_pager_putpages: residual I/O 65536 at 21872 Over and over and over. Of course, this log is On the /var FS itself. FreeBSD burnout 5.3-RELEASE-p2 FreeBSD 5.3-RELEASE-p2 #1: Wed Jan 5 18:44:27 EST 2005 craig@burnout:/usr/obj/usr/src/sys/BURNOUT5 i386 I'm not sure what other info to paste, my vfs.* sysctls are all defaults, except for vfs.usermount=1. -Craig From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 16:12:06 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EE5316A4CE for ; Wed, 12 Jan 2005 16:12:06 +0000 (GMT) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8E4043D2D for ; Wed, 12 Jan 2005 16:12:03 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from [161.53.72.113] (lara.cc.fer.hr [161.53.72.113]) by pinus.cc.fer.hr (8.12.2/8.12.2) with ESMTP id j0CGOJ5B013611 for ; Wed, 12 Jan 2005 17:24:20 +0100 (MET) Message-ID: <41E54C51.4000300@fer.hr> Date: Wed, 12 Jan 2005 17:12:01 +0100 From: Ivan Voras User-Agent: Mozilla Thunderbird 1.0 (X11/20041213) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org References: <41DF253C.5040705@fer.hr> <20050108005540.GB93568@troutmask.apl.washington.edu> <20050108030707.GA3656@frontfree.net> <20050108034424.GA94365@troutmask.apl.washington.edu> In-Reply-To: <20050108034424.GA94365@troutmask.apl.washington.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: MFC wishlist X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 16:12:06 -0000 Steve Kargl wrote: > On Sat, Jan 08, 2005 at 11:07:07AM +0800, Xin LI wrote: > >>On Fri, Jan 07, 2005 at 04:55:40PM -0800, Steve Kargl wrote: >> >>>On Sat, Jan 08, 2005 at 01:11:40AM +0100, Ivan Voras wrote: >>> >>>>It's been a while now and (judging from this list at least), people are >>>>not complaining about ULE, so maybe (with re@ approval) the fix & >>>>supporting infrastructure could be brought to RELENG_5? >>>> >>> >>>That's not a good idea. I can lock up ULE+PREEMPTION on >>This is observed in pre-5.3RELEASE CURRENT, but I thought Jeff has > I'm talking about 6-CURRENT. My last kernel/world build is Are there plans for assigning more priority/resources on solving this? Maybe mark it as show-stopper for 5.4? (it's currently not even on the http://www.freebsd.org/releases/5.4R/todo.html list) From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 16:37:37 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 495C116A4CE for ; Wed, 12 Jan 2005 16:37:37 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CEAB43D31 for ; Wed, 12 Jan 2005 16:37:37 +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 j0CGeMEW031048; Wed, 12 Jan 2005 08:40:22 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j0CGeMJ2031047; Wed, 12 Jan 2005 08:40:22 -0800 Date: Wed, 12 Jan 2005 08:40:22 -0800 From: Brooks Davis To: Ivan Voras Message-ID: <20050112164022.GD28786@odin.ac.hmc.edu> References: <41DF253C.5040705@fer.hr> <20050108005540.GB93568@troutmask.apl.washington.edu> <20050108030707.GA3656@frontfree.net> <20050108034424.GA94365@troutmask.apl.washington.edu> <41E54C51.4000300@fer.hr> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d01dLTUuW90fS44H" Content-Disposition: inline In-Reply-To: <41E54C51.4000300@fer.hr> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: current@freebsd.org Subject: Re: MFC wishlist X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 16:37:37 -0000 --d01dLTUuW90fS44H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 12, 2005 at 05:12:01PM +0100, Ivan Voras wrote: > Steve Kargl wrote: > >On Sat, Jan 08, 2005 at 11:07:07AM +0800, Xin LI wrote: > > > >>On Fri, Jan 07, 2005 at 04:55:40PM -0800, Steve Kargl wrote: > >> > >>>On Sat, Jan 08, 2005 at 01:11:40AM +0100, Ivan Voras wrote: > >>> > >>>>It's been a while now and (judging from this list at least), people a= re=20 > >>>>not complaining about ULE, so maybe (with re@ approval) the fix &=20 > >>>>supporting infrastructure could be brought to RELENG_5? > >>>> > >>> > >>>That's not a good idea. I can lock up ULE+PREEMPTION on >=20 > >>This is observed in pre-5.3RELEASE CURRENT, but I thought Jeff has >=20 > >I'm talking about 6-CURRENT. My last kernel/world build is >=20 > Are there plans for assigning more priority/resources on solving this?=20 > Maybe mark it as show-stopper for 5.4? (it's currently not even on the=20 > http://www.freebsd.org/releases/5.4R/todo.html list) No, because the project has no ability to "assign priority/resources". If someone who has is intrested and capable time to work on it, does so in time, then it may be done, if not, it won't. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --d01dLTUuW90fS44H Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFB5VL0XY6L6fI4GtQRAp7vAJ9sRoMmxVJoM4pH9I8EUEWhSqwqSgCg5xPN cNheJG2BpD0uutzdZgYgpLY= =7gNf -----END PGP SIGNATURE----- --d01dLTUuW90fS44H-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 16:42:09 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B96D16A4CE for ; Wed, 12 Jan 2005 16:42:09 +0000 (GMT) Received: from av7-1-sn4.m-sp.skanova.net (av7-1-sn4.m-sp.skanova.net [81.228.10.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1552543D45 for ; Wed, 12 Jan 2005 16:42:09 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av7-1-sn4.m-sp.skanova.net (Postfix, from userid 502) id 0AF9B37E5D; Wed, 12 Jan 2005 17:42:08 +0100 (CET) Received: from smtp2-2-sn4.m-sp.skanova.net (smtp2-2-sn4.m-sp.skanova.net [81.228.10.182]) by av7-1-sn4.m-sp.skanova.net (Postfix) with ESMTP id F097337E55 for ; Wed, 12 Jan 2005 17:42:07 +0100 (CET) Received: from sentinel (h217n1fls11o822.telia.com [213.64.66.217]) by smtp2-2-sn4.m-sp.skanova.net (Postfix) with ESMTP id D79D837E57 for ; Wed, 12 Jan 2005 17:42:07 +0100 (CET) From: "Daniel Eriksson" To: Date: Wed, 12 Jan 2005 17:42:03 +0100 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcT4xaT+KdsIl87ERUe0M0DBbnIDtQ== Subject: NFS problems, locking up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 16:42:09 -0000 I'm still having problems with NFS locking up when moving large amounts of data over it on 6-CURRENT from 2005.01.11.05.00.00. This problem has persisted for a long time now, and the only thing that seems to cure it is running the network stack with giant enabled (debug.mpsafenet=0). When it happens, the process doing the copying ends up in "nfsaio" state according to ps. Any accesses to the locked mount by other processes ends up waiting forever in state "nfs". I have multiple file systems mounted from the same server, and only the mount where the data is being moved locks up. The others continue to work as expected. Server: UP, 6-CURRENT from 2005.01.11.05.00.00, if_vr (POLLING) Client: SMP (dual AMD MP), 6-CURRENT from 2005.01.11.05.00.00, if_em The machines are connected with a crossover cable. I've tried both schedulers (4BSD and ULE) on the client, but it doesn't make any difference (server is running 4BSD). PREEMPTION is enabled on both server and client. ADAPTIVE_GIANT is enabled on the client. /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 16:44:02 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A849316A4CE for ; Wed, 12 Jan 2005 16:44:02 +0000 (GMT) Received: from saturn.criticalmagic.com (saturn.criticalmagic.com [64.74.124.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5999743D49 for ; Wed, 12 Jan 2005 16:44:02 +0000 (GMT) (envelope-from rcoleman@criticalmagic.com) Received: from [10.40.30.75] (delta.ciphertrust.com [216.235.158.34]) by saturn.criticalmagic.com (Postfix) with ESMTP id 709B83BD21; Wed, 12 Jan 2005 11:44:01 -0500 (EST) Message-ID: <41E553EB.10809@criticalmagic.com> Date: Wed, 12 Jan 2005 11:44:27 -0500 From: Richard Coleman Organization: Critical Magic User-Agent: Mozilla Thunderbird 1.0 (X11/20041230) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <41DF253C.5040705@fer.hr> <20050108005540.GB93568@troutmask.apl.washington.edu> <20050108030707.GA3656@frontfree.net> <20050108034424.GA94365@troutmask.apl.washington.edu> <41E54C51.4000300@fer.hr> <20050112164022.GD28786@odin.ac.hmc.edu> In-Reply-To: <20050112164022.GD28786@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: current@freebsd.org cc: Ivan Voras Subject: Re: MFC wishlist X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 16:44:02 -0000 Brooks Davis wrote: >>>>>> It's been a while now and (judging from this list at >>>>>> least), people are not complaining about ULE, so maybe >>>>>> (with re@ approval) the fix & supporting infrastructure >>>>>> could be brought to RELENG_5? >>>>>> >>>>> >>>>> That's not a good idea. I can lock up ULE+PREEMPTION on >> >>>> This is observed in pre-5.3RELEASE CURRENT, but I thought Jeff >>>> has >> >>> I'm talking about 6-CURRENT. My last kernel/world build is >> >> Are there plans for assigning more priority/resources on solving >> this? Maybe mark it as show-stopper for 5.4? (it's currently not >> even on the http://www.freebsd.org/releases/5.4R/todo.html list) > > > No, because the project has no ability to "assign > priority/resources". If someone who has is intrested and capable time > to work on it, does so in time, then it may be done, if not, it > won't. > > -- Brooks Should we take this to mean that none of the developers are interested in ULE any more? That's the general feeling I get these days. Just curious. Richard Coleman rcoleman@criticalmagic.com From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 16:50:39 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D11C116A4CE for ; Wed, 12 Jan 2005 16:50:39 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CD8B43D1D for ; Wed, 12 Jan 2005 16:50:39 +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 j0CGrRBd031858; Wed, 12 Jan 2005 08:53:27 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j0CGrPd7031857; Wed, 12 Jan 2005 08:53:25 -0800 Date: Wed, 12 Jan 2005 08:53:25 -0800 From: Brooks Davis To: Richard Coleman Message-ID: <20050112165325.GF28786@odin.ac.hmc.edu> References: <41DF253C.5040705@fer.hr> <20050108005540.GB93568@troutmask.apl.washington.edu> <20050108030707.GA3656@frontfree.net> <20050108034424.GA94365@troutmask.apl.washington.edu> <41E54C51.4000300@fer.hr> <20050112164022.GD28786@odin.ac.hmc.edu> <41E553EB.10809@criticalmagic.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QXO0/MSS4VvK6f+D" Content-Disposition: inline In-Reply-To: <41E553EB.10809@criticalmagic.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: current@freebsd.org cc: Ivan Voras Subject: Re: MFC wishlist X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 16:50:40 -0000 --QXO0/MSS4VvK6f+D Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 12, 2005 at 11:44:27AM -0500, Richard Coleman wrote: > Brooks Davis wrote: > >>>>>>It's been a while now and (judging from this list at > >>>>>>least), people are not complaining about ULE, so maybe > >>>>>>(with re@ approval) the fix & supporting infrastructure > >>>>>>could be brought to RELENG_5? > >>>>>> > >>>>> > >>>>>That's not a good idea. I can lock up ULE+PREEMPTION on > >> > >>>>This is observed in pre-5.3RELEASE CURRENT, but I thought Jeff > >>>>has > >> > >>>I'm talking about 6-CURRENT. My last kernel/world build is > >> > >>Are there plans for assigning more priority/resources on solving > >>this? Maybe mark it as show-stopper for 5.4? (it's currently not > >>even on the http://www.freebsd.org/releases/5.4R/todo.html list) > > > > > >No, because the project has no ability to "assign > >priority/resources". If someone who has is intrested and capable time > >to work on it, does so in time, then it may be done, if not, it > >won't. >=20 > Should we take this to mean that none of the developers are interested=20 > in ULE any more? That's the general feeling I get these days. Just=20 > curious. Schedulers are non-trivial and the bugs in ULE are also extremely non-trivial. Since Jeff is very busy, the amount of time to be spent on this is very limited. It's not so much that no one is interested as that no one who is interested and capable has time. If someone who has time and interest wants to be come capable or someone with time could be convinced become interested, that problem could be alleviated. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --QXO0/MSS4VvK6f+D Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFB5VYEXY6L6fI4GtQRAmBxAJ4hzMyBxH58kXksK3CpSUvS7UicCQCg2HKQ 3kwKTFntTPXQ5ps4cXGSeaM= =Nw3b -----END PGP SIGNATURE----- --QXO0/MSS4VvK6f+D-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 16:54:08 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9629D16A4CE for ; Wed, 12 Jan 2005 16:54:08 +0000 (GMT) Received: from web80602.mail.yahoo.com (web80602.mail.yahoo.com [66.218.79.91]) by mx1.FreeBSD.org (Postfix) with SMTP id 50AB043D41 for ; Wed, 12 Jan 2005 16:54:08 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Message-ID: <20050112165408.95051.qmail@web80602.mail.yahoo.com> Received: from [209.79.46.235] by web80602.mail.yahoo.com via HTTP; Wed, 12 Jan 2005 08:54:08 PST Date: Wed, 12 Jan 2005 08:54:08 -0800 (PST) From: Mohan Srinivasan To: Daniel Eriksson , freebsd-current@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: NFS problems, locking up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 16:54:08 -0000 Daniel, Can you force a core and point me at the core ? mohan --- Daniel Eriksson wrote: > > I'm still having problems with NFS locking up when moving large amounts of > data over it on 6-CURRENT from 2005.01.11.05.00.00. This problem has > persisted for a long time now, and the only thing that seems to cure it is > running the network stack with giant enabled (debug.mpsafenet=0). > > When it happens, the process doing the copying ends up in "nfsaio" state > according to ps. Any accesses to the locked mount by other processes ends up > waiting forever in state "nfs". I have multiple file systems mounted from > the same server, and only the mount where the data is being moved locks up. > The others continue to work as expected. > > Server: UP, 6-CURRENT from 2005.01.11.05.00.00, if_vr (POLLING) > Client: SMP (dual AMD MP), 6-CURRENT from 2005.01.11.05.00.00, if_em > > The machines are connected with a crossover cable. I've tried both > schedulers (4BSD and ULE) on the client, but it doesn't make any difference > (server is running 4BSD). PREEMPTION is enabled on both server and client. > ADAPTIVE_GIANT is enabled on the client. > > /Daniel Eriksson > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 17:15:26 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAB2F16A4CE for ; Wed, 12 Jan 2005 17:15:26 +0000 (GMT) Received: from av4-2-sn3.vrr.skanova.net (av4-2-sn3.vrr.skanova.net [81.228.9.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D2B143D49 for ; Wed, 12 Jan 2005 17:15:26 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: by av4-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 87CF437E6E; Wed, 12 Jan 2005 18:15:25 +0100 (CET) Received: from smtp1-2-sn3.vrr.skanova.net (smtp1-2-sn3.vrr.skanova.net [81.228.9.178]) by av4-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 7861437E42; Wed, 12 Jan 2005 18:15:25 +0100 (CET) Received: from sentinel (h217n1fls11o822.telia.com [213.64.66.217]) by smtp1-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 4382638010; Wed, 12 Jan 2005 18:15:25 +0100 (CET) From: "Daniel Eriksson" To: "'Mohan Srinivasan'" , Date: Wed, 12 Jan 2005 18:15:21 +0100 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050112165408.95051.qmail@web80602.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcT4x+i7gP8opfUuTMyeNytWWh7fcgAAikEA Subject: RE: NFS problems, locking up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 17:15:26 -0000 Mohan Srinivasan wrote: > Can you force a core and point me at the core ? Next time it happens I'll be sure to do that. What do I need to do? Just enter the debugger and call doadump? /Daniel From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 17:26:18 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1E6016A4CE for ; Wed, 12 Jan 2005 17:26:18 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 773B243D1D for ; Wed, 12 Jan 2005 17:26:18 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) j0CHQANJ016301; Wed, 12 Jan 2005 09:26:10 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)j0CHQ8DF016300; Wed, 12 Jan 2005 09:26:08 -0800 (PST) (envelope-from sgk) Date: Wed, 12 Jan 2005 09:26:08 -0800 From: Steve Kargl To: Richard Coleman Message-ID: <20050112172608.GB16201@troutmask.apl.washington.edu> References: <41DF253C.5040705@fer.hr> <20050108005540.GB93568@troutmask.apl.washington.edu> <20050108030707.GA3656@frontfree.net> <20050108034424.GA94365@troutmask.apl.washington.edu> <41E54C51.4000300@fer.hr> <20050112164022.GD28786@odin.ac.hmc.edu> <41E553EB.10809@criticalmagic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41E553EB.10809@criticalmagic.com> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org cc: Ivan Voras Subject: Re: MFC wishlist X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 17:26:18 -0000 On Wed, Jan 12, 2005 at 11:44:27AM -0500, Richard Coleman wrote: > Brooks Davis wrote: > > > >No, because the project has no ability to "assign > >priority/resources". If someone who has is intrested and capable time > >to work on it, does so in time, then it may be done, if not, it > >won't. > > > > Should we take this to mean that none of the developers are interested > in ULE any more? That's the general feeling I get these days. Just > curious. > As Brooks stated, Jeff is busy. He works on it when he can. My problem is that system simply freezes. I can't get a kernel dump, so its hard to provide more info. I'll also note that I believe that there are recent KSE/pthread changes in -current that may be exposing a latent bug in ULE. Jeff's recent ULE changes may actual work on 5.3. No one is stopping you from backport the changes. -- Steve From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 17:33:54 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 826E616A4CE for ; Wed, 12 Jan 2005 17:33:54 +0000 (GMT) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40AE643D4C for ; Wed, 12 Jan 2005 17:33:54 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-1.free.fr (Postfix) with ESMTP id 5A49C2641C0 for ; Wed, 12 Jan 2005 18:33:53 +0100 (CET) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 49F3340B9; Wed, 12 Jan 2005 18:33:50 +0100 (CET) Date: Wed, 12 Jan 2005 18:33:50 +0100 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Message-ID: <20050112173350.GA46508@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: LOR in IPFilter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 17:33:54 -0000 Hi, I recompiled my kernel with source tree upgraded around 2005.01.12.00.00.00 and I get the following LOR (pasted by hand) : %%% lock order reversal 1st 0x... dont_sleep_in_callout (dont_sleep_in_callout) @ kern/kern_timeout.c:257 2nd 0x... ipf fragment rwlock (ipf fragment rwlock) @ contrib/ipfilter/netinet/ip_frag.c:529 KDB: stack backtrace: kdb_backtrace() witness_checkorder() _sx_xlock() ipfr_fragexpire() ipfr_slowtimer() ithread_loop() fork_exit() fork_trampoline() %%% I looked a bit at the source and I understood that when DIAGNOSTIC is defined, then the softclock() function from kern_timeout.c use a kind a dummy mutex to prevent the callout function from sleeping. Unfortunately the ipfr_fragexpire() from ip_frag.c use a sx_lock... (voir en quoi consitent les sx_lock) On the other hand, I have serious feeling that I'm somewhat the culprit since: o I know that the use of sx(9) locks have already been discussed [1] with Darren Reed but I can't find it on bz@'s page referencing all known LORs [2]. o No such report appeared on current@. o I don't remember any significant commit in either ip_frag.c or kern_timeout.c since my last kernel update on 2004/12/28. o Looking at the code path [3] shows off that the ipfr_fragexpire() function must be automatically called when the module loader function is called, thus this LOR should already have been triggered IMHO. Regards, [1] http://lists.freebsd.org/pipermail/cvs-src/2004-December/thread.html#37421 [2] http://sources.zabbadoz.net/freebsd/lor.html [3] ipfilter_modevent() -> iplattach() -> timeout(&ipfr_slowtimer) ; ipfr_slowtimer() -> ipfr_fragexpire() -- Jeremie Le Hen jeremie@le-hen.org From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 17:37:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0540716A4CE for ; Wed, 12 Jan 2005 17:37:10 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83AFF43D45 for ; Wed, 12 Jan 2005 17:37:09 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.12] (g4.samsco.home [192.168.254.12]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id j0CHehV6096854; Wed, 12 Jan 2005 10:40:43 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <41E5603E.4020203@freebsd.org> Date: Wed, 12 Jan 2005 10:37:02 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ivan Voras References: <41DF253C.5040705@fer.hr> <20050108005540.GB93568@troutmask.apl.washington.edu> <20050108030707.GA3656@frontfree.net> <20050108034424.GA94365@troutmask.apl.washington.edu> <41E54C51.4000300@fer.hr> In-Reply-To: <41E54C51.4000300@fer.hr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: current@freebsd.org Subject: Re: MFC wishlist X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 17:37:10 -0000 Ivan Voras wrote: > Steve Kargl wrote: > >> On Sat, Jan 08, 2005 at 11:07:07AM +0800, Xin LI wrote: >> >>> On Fri, Jan 07, 2005 at 04:55:40PM -0800, Steve Kargl wrote: >>> >>>> On Sat, Jan 08, 2005 at 01:11:40AM +0100, Ivan Voras wrote: >>>> >>>>> It's been a while now and (judging from this list at least), people >>>>> are not complaining about ULE, so maybe (with re@ approval) the fix >>>>> & supporting infrastructure could be brought to RELENG_5? >>>>> >>>> >>>> That's not a good idea. I can lock up ULE+PREEMPTION on > > >>> This is observed in pre-5.3RELEASE CURRENT, but I thought Jeff has > > >> I'm talking about 6-CURRENT. My last kernel/world build is > > > Are there plans for assigning more priority/resources on solving this? > Maybe mark it as show-stopper for 5.4? (it's currently not even on the > http://www.freebsd.org/releases/5.4R/todo.html list) Assigning priorities and resources really is at the will of the developers. Very few are paid to do this work, and none are paid by the release engineering or core groups. The release engineers can put items on the todo list in hopes that it will inspire others to help. Specifically for ULE, since it is not the default scheduler, it will not be making the showstopper list for 5.4. If someone would like to step forward and work on ULE full time, that would be wonderful and I'd highly encourage it. Scott From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 19:44:14 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A32F16A4CF for ; Wed, 12 Jan 2005 19:44:14 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF80E43D49 for ; Wed, 12 Jan 2005 19:44:13 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 19284 invoked from network); 12 Jan 2005 19:44:13 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 12 Jan 2005 19:44:13 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id j0CJi4VX027337; Wed, 12 Jan 2005 14:44:09 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Pawel Jakub Dawidek Date: Wed, 12 Jan 2005 14:42:02 -0500 User-Agent: KMail/1.6.2 References: <20050111202452.GK795@darkness.comp.waw.pl> <41E45026.20208@root.org> <20050111224007.GL795@darkness.comp.waw.pl> In-Reply-To: <20050111224007.GL795@darkness.comp.waw.pl> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200501121442.02702.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: acpi@FreeBSD.org cc: freebsd-current@FreeBSD.org cc: Nate Lawson Subject: Re: Intel SHG2 and ACPI 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: Wed, 12 Jan 2005 19:44:14 -0000 On Tuesday 11 January 2005 05:40 pm, Pawel Jakub Dawidek wrote: > On Tue, Jan 11, 2005 at 02:16:06PM -0800, Nate Lawson wrote: > +> Pawel Jakub Dawidek wrote: > +> >I had problems with ACPI on Intel SHG2 motherboard. > +> >I made a patch with works for me just fine. Could you, Nate, verify it > +> >and commit if it is ok. > +> >If you need some more info, just ask. > +> > > +> > http://people.freebsd.org/~pjd/patches/acpi_pci_link.c.patch > +> > +> John mentioned that it appears the root problem is that _CRS is failing > +> for you. Can you send a dmesg from a broken boot (without your patch)? > > Here you go: > > http://people.freebsd.org/~pjd/misc/boot-v1.txt Ok, this is a rather large patch as allowing for a b0rked _CRS required a good bit of work. I've only compile tested it and haven't run tested it so far, so beware. Note that it does include fixes for some bugs related to ExtIRQ routing (I wrote the irq to the wrong resource structure :( ) and to parsing the buffer we handed to _SRS (end pointer was wrong so I probably only ever parsed the first resource, which is the common case, so this probably didn't affect anyone). -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 19:52:21 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3523316A4CE; Wed, 12 Jan 2005 19:52:21 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 14DC343D5A; Wed, 12 Jan 2005 19:52:21 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id D9BD17A403; Wed, 12 Jan 2005 11:52:20 -0800 (PST) Message-ID: <41E57FF4.90403@elischer.org> Date: Wed, 12 Jan 2005 11:52:20 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: John Baldwin References: <20050109011132.GJ39552@cirb503493.alcatel.com.au> <41E0C02F.60100@freebsd.org> <20050109101529.GM39552@cirb503493.alcatel.com.au> <9D0B94DA-63E2-11D9-A25E-000393921CC4@baldwin.cx> In-Reply-To: <9D0B94DA-63E2-11D9-A25E-000393921CC4@baldwin.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: Peter Jeremy cc: freebsd-current@freebsd.org cc: Scott Long Subject: Re: bus_dmamem_alloc() can't handle large NOWAIT requests X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 19:52:21 -0000 John Baldwin wrote: > Unforunately, "sleep" is a bit of an overloaded term in the kernel. > Blocking on a mutex is not considered a "sleep" quite like msleep() or > cv_wait() in that a mutex will eventually be released (barring an > infinite loop bug) and thus a thread blocked on a lock won't sleep > forever. msleep() and cv_wait() on the other hand do not have the > same guarantee. M_NOWAIT means that msleep() and cv_wait() won't be > called; it is ok to block on a mutex with M_NOWAIT however. I tried > to explain this difference in semantics some in the glossary of the > SMP chapter in the kernel devbook. The problem is that people may think about a call with M_NOWAIT for different reasons. Sometimes it is to ensure that the response time is limitted, even if that means that an error may be returned, while others may call it because they feel it stops the possibility of recursion or some other interference.. The 2nd will not work in the current scheme where a mutex may block the thread. The distinction needs to be drawn between "don't go away for a long time" and "don't switch to any other thread". From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 20:07:09 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D630216A4D3 for ; Wed, 12 Jan 2005 20:07:09 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CFB443D55 for ; Wed, 12 Jan 2005 20:07:09 +0000 (GMT) (envelope-from benjamin.becker@gmail.com) Received: by rproxy.gmail.com with SMTP id g11so71021rne for ; Wed, 12 Jan 2005 12:07:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=rEtK/OC7xlA456JwfIPCD7v0qd9YWslRD+e4G4a8gg3nUGZick69cnnbxOLr5MgXoAsIlrmFV7yOQCk9T9sJQlXk1yEjkVWg0C2T5vxQy2lQ9zeYOMs/DndjWz4+f5N+qkt5twktsbES79YB/2lnGIPctCSAvXeaz5gNz4C5tP4= Received: by 10.39.1.5 with SMTP id d5mr1841rni; Wed, 12 Jan 2005 12:07:08 -0800 (PST) Received: by 10.38.73.18 with HTTP; Wed, 12 Jan 2005 12:07:08 -0800 (PST) Message-ID: <38d37be7050112120767d4ca5f@mail.gmail.com> Date: Wed, 12 Jan 2005 12:07:08 -0800 From: Ben Becker To: freebsd-current@freebsd.org In-Reply-To: <41E490D4.70504@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <38d37be7050111092379f2a898@mail.gmail.com> <41E490D4.70504@errno.com> Subject: Re: Atheros and SIS bridging problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Ben Becker List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 20:07:09 -0000 On Tue, 11 Jan 2005 18:52:04 -0800, Sam Leffler wrote: > This doesn't work because the wireless interface will not receive > frames from the ap destined for the laptop. You basically need/want to > tunnel the laptop frames which requires support that's not currently in > the system. I just tested a few things: First, I was able to ping the AP from the laptop by adding static ARP entries on both devices and pointing the opposite device's IP to the mac address of Ath0 on the bridge. It seems to have worked as I can ping back and forth, but the response time is usually greater than 200ms. Just thought this was interesting. Is the issue here just that the bridge needs to learn all the MAC addresses and which side of the bridge they're on? Or does this have more to do with the Atheros driver? I want to add this functionality and I'm willing to take the time to write a patch, but I want to make sure I'm on the right track. Any pointers would be greatly appreciated. Regards, Ben From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 20:11:28 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 895CA16A4CE for ; Wed, 12 Jan 2005 20:11:28 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 372D243D45 for ; Wed, 12 Jan 2005 20:11:28 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 18664 invoked from network); 12 Jan 2005 20:11:28 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 12 Jan 2005 20:11:27 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id j0CKBIGF027541; Wed, 12 Jan 2005 15:11:18 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Wed, 12 Jan 2005 15:03:29 -0500 User-Agent: KMail/1.6.2 References: <20050109214454.GA60018@peter.osted.lan> In-Reply-To: <20050109214454.GA60018@peter.osted.lan> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200501121503.29257.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: current@FreeBSD.org Subject: Re: panic: proc not held @ fs/procfs/procfs_regs.c:60 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 20:11:28 -0000 On Sunday 09 January 2005 04:44 pm, Peter Holm wrote: > With GENERIC HEAD from Jan 8 08:45 UTC I got: > > panic(c0826351,c0826973,c082fcfc,3,c175a2e0) at panic+0xd8 > procfs_doprocregs(c175a2e0,c1b1b5e8,c1665d80,0,ce778c90) at > procfs_doprocregs+0x10a pfs_read(ce778c1c,20000,c1f19e04,c08294ba,845) at > pfs_read+0x20f > vn_read(c1b17ae4,ce778c90,c1a9c080,0,c175a2e0) at vn_read+0x1b9 > dofileread(8,bfbfea50,4c,ffffffff,ffffffff) at dofileread+0x82 > read(c175a2e0,ce778d14,3,1,282) at read+0x44 > syscall(2f,2f,2f,8059f48,a7c) at syscall+0x128 > > Details at http://www.holm.cc/stress/log/cons105.html Hmm, looking at procfs_doprocregs() I'm not sure how it could lose the proc lock. The assertion must be in one of the PROC_UNLOCK(). Can you do a listing of the procfs_doprocregs() frame to see where it died? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 20:11:28 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EA0B16A4CF for ; Wed, 12 Jan 2005 20:11:28 +0000 (GMT) Received: from mail5.speakeasy.net (mail5.speakeasy.net [216.254.0.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3928A43D49 for ; Wed, 12 Jan 2005 20:11:28 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 18664 invoked from network); 12 Jan 2005 20:11:28 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 12 Jan 2005 20:11:27 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id j0CKBIGF027541; Wed, 12 Jan 2005 15:11:18 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Wed, 12 Jan 2005 15:03:29 -0500 User-Agent: KMail/1.6.2 References: <20050109214454.GA60018@peter.osted.lan> In-Reply-To: <20050109214454.GA60018@peter.osted.lan> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200501121503.29257.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: current@FreeBSD.org Subject: Re: panic: proc not held @ fs/procfs/procfs_regs.c:60 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 20:11:28 -0000 On Sunday 09 January 2005 04:44 pm, Peter Holm wrote: > With GENERIC HEAD from Jan 8 08:45 UTC I got: > > panic(c0826351,c0826973,c082fcfc,3,c175a2e0) at panic+0xd8 > procfs_doprocregs(c175a2e0,c1b1b5e8,c1665d80,0,ce778c90) at > procfs_doprocregs+0x10a pfs_read(ce778c1c,20000,c1f19e04,c08294ba,845) at > pfs_read+0x20f > vn_read(c1b17ae4,ce778c90,c1a9c080,0,c175a2e0) at vn_read+0x1b9 > dofileread(8,bfbfea50,4c,ffffffff,ffffffff) at dofileread+0x82 > read(c175a2e0,ce778d14,3,1,282) at read+0x44 > syscall(2f,2f,2f,8059f48,a7c) at syscall+0x128 > > Details at http://www.holm.cc/stress/log/cons105.html Hmm, looking at procfs_doprocregs() I'm not sure how it could lose the proc lock. The assertion must be in one of the PROC_UNLOCK(). Can you do a listing of the procfs_doprocregs() frame to see where it died? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 20:11:36 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B88316A511 for ; Wed, 12 Jan 2005 20:11:36 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EA9143D49 for ; Wed, 12 Jan 2005 20:11:35 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 846 invoked from network); 12 Jan 2005 20:11:35 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 12 Jan 2005 20:11:32 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id j0CKBIGG027541; Wed, 12 Jan 2005 15:11:27 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-current@FreeBSD.org Date: Wed, 12 Jan 2005 15:06:50 -0500 User-Agent: KMail/1.6.2 References: <20050111202452.GK795@darkness.comp.waw.pl> <20050111224007.GL795@darkness.comp.waw.pl> <200501121442.02702.jhb@FreeBSD.org> In-Reply-To: <200501121442.02702.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200501121506.50867.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: acpi@FreeBSD.org cc: Pawel Jakub Dawidek cc: Nate Lawson Subject: Re: Intel SHG2 and ACPI 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: Wed, 12 Jan 2005 20:11:36 -0000 On Wednesday 12 January 2005 02:42 pm, John Baldwin wrote: > On Tuesday 11 January 2005 05:40 pm, Pawel Jakub Dawidek wrote: > > On Tue, Jan 11, 2005 at 02:16:06PM -0800, Nate Lawson wrote: > > +> Pawel Jakub Dawidek wrote: > > +> >I had problems with ACPI on Intel SHG2 motherboard. > > +> >I made a patch with works for me just fine. Could you, Nate, verify > > it +> >and commit if it is ok. > > +> >If you need some more info, just ask. > > +> > > > +> > http://people.freebsd.org/~pjd/patches/acpi_pci_link.c.patch > > +> > > +> John mentioned that it appears the root problem is that _CRS is > > failing +> for you. Can you send a dmesg from a broken boot (without > > your patch)? > > > > Here you go: > > > > http://people.freebsd.org/~pjd/misc/boot-v1.txt > > Ok, this is a rather large patch as allowing for a b0rked _CRS required a > good bit of work. I've only compile tested it and haven't run tested it so > far, so beware. Note that it does include fixes for some bugs related to > ExtIRQ routing (I wrote the irq to the wrong resource structure :( ) and to > parsing the buffer we handed to _SRS (end pointer was wrong so I probably > only ever parsed the first resource, which is the common case, so this > probably didn't affect anyone). Gee, patch would help: --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_pci_link.c 2004/12/27 05:45:32 +++ //depot/user/jhb/acpipci/dev/acpica/acpi_pci_link.c 2005/01/12 19:31:01 @@ -77,6 +77,7 @@ * DMA Channel 3 * * The XXX is because I'm not sure if this is a valid assumption to make. + * Further reading of the spec is advised before this hits CVS. */ /* States during DPF processing. */ @@ -88,7 +89,9 @@ struct acpi_pci_link_softc { int pl_num_links; + int pl_crs_bad; struct link *pl_links; + device_t pl_dev; }; struct link { @@ -302,7 +305,13 @@ KASSERT(req->link_index < req->sc->pl_num_links, ("%s: array boundary violation", __func__)); link = &req->sc->pl_links[req->link_index]; + if (link->l_res_index == -1) { + KASSERT(req->sc->pl_crs_bad, + ("res_index should be set")); + link->l_res_index = req->res_index; + } req->link_index++; + req->res_index++; /* * Stash a copy of the resource for later use when doing @@ -334,6 +343,14 @@ link->l_isa_irq = FALSE; } break; + default: + if (req->in_dpf == DPF_IGNORE) + break; + if (req->sc->pl_crs_bad) + device_printf(req->sc->pl_dev, + "Warning: possible resource %d will be lost during _SRS\n", + req->res_index); + req->res_index++; } return (AE_OK); } @@ -396,21 +413,35 @@ int i; sc = device_get_softc(dev); + sc->pl_dev = dev; ACPI_SERIAL_BEGIN(pci_link); /* * Count the number of current resources so we know how big of - * a link array to allocate. + * a link array to allocate. On some systems, _CRS is broken, + * so for those systems try to derive the count from _PRS instead. */ creq.in_dpf = DPF_OUTSIDE; creq.count = 0; status = AcpiWalkResources(acpi_get_handle(dev), "_CRS", acpi_count_irq_resources, &creq); - if (ACPI_FAILURE(status)) - return (ENXIO); + sc->pl_crs_bad = ACPI_FAILURE(status); + if (sc->pl_crs_bad) { + creq.in_dpf = DPF_OUTSIDE; + creq.count = 0; + status = AcpiWalkResources(acpi_get_handle(dev), "_PRS", + acpi_count_irq_resources, &creq); + if (ACPI_FAILURE(status)) { + device_printf(dev, + "Unable to parse _CRS or _PRS: %s\n", + AcpiFormatException(status)); + ACPI_SERIAL_END(pci_link); + return (ENXIO); + } + } + sc->pl_num_links = creq.count; if (creq.count == 0) return (0); - sc->pl_num_links = creq.count; sc->pl_links = malloc(sizeof(struct link) * sc->pl_num_links, M_PCI_LINK, M_WAITOK | M_ZERO); @@ -420,22 +451,41 @@ sc->pl_links[i].l_bios_irq = PCI_INVALID_IRQ; sc->pl_links[i].l_sc = sc; sc->pl_links[i].l_isa_irq = FALSE; + sc->pl_links[i].l_res_index = -1; + } + + /* Try to read the current settings from _CRS if it is valid. */ + if (!sc->pl_crs_bad) { + rreq.in_dpf = DPF_OUTSIDE; + rreq.link_index = 0; + rreq.res_index = 0; + rreq.sc = sc; + status = AcpiWalkResources(acpi_get_handle(dev), "_CRS", + link_add_crs, &rreq); + if (ACPI_FAILURE(status)) { + device_printf(dev, "Unable to parse _CRS: %s\n", + AcpiFormatException(status)); + goto fail; + } } + + /* + * Try to read the possible settings from _PRS. Note that if the + * _CRS is toast, we depend on having a working _PRS. However, if + * _CRS works, then it is ok for _PRS to be missing. + */ rreq.in_dpf = DPF_OUTSIDE; rreq.link_index = 0; rreq.res_index = 0; rreq.sc = sc; - status = AcpiWalkResources(acpi_get_handle(dev), "_CRS", - link_add_crs, &rreq); - if (ACPI_FAILURE(status)) - goto fail; - rreq.in_dpf = DPF_OUTSIDE; - rreq.link_index = 0; - rreq.res_index = 0; status = AcpiWalkResources(acpi_get_handle(dev), "_PRS", link_add_prs, &rreq); - if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) + if (ACPI_FAILURE(status) && + (status != AE_NOT_FOUND || sc->pl_crs_bad)) { + device_printf(dev, "Unable to parse _PRS: %s\n", + AcpiFormatException(status)); goto fail; + } if (bootverbose) { device_printf(dev, "Links after initial probe:\n"); acpi_pci_link_dump(sc); @@ -589,33 +639,31 @@ } static ACPI_STATUS -acpi_pci_link_route_irqs(device_t dev) +acpi_pci_link_srs_from_crs(struct acpi_pci_link_softc *sc, ACPI_BUFFER *srsbuf) { - struct acpi_pci_link_softc *sc; ACPI_RESOURCE *resource, *end, newres, *resptr; - ACPI_BUFFER crsbuf, srsbuf; + ACPI_BUFFER crsbuf; ACPI_STATUS status; struct link *link; int i, in_dpf; /* Fetch the _CRS. */ ACPI_SERIAL_ASSERT(pci_link); - sc = device_get_softc(dev); crsbuf.Pointer = NULL; crsbuf.Length = ACPI_ALLOCATE_BUFFER; - status = AcpiGetCurrentResources(acpi_get_handle(dev), &crsbuf); + status = AcpiGetCurrentResources(acpi_get_handle(sc->pl_dev), &crsbuf); if (ACPI_SUCCESS(status) && crsbuf.Pointer == NULL) status = AE_NO_MEMORY; if (ACPI_FAILURE(status)) { if (bootverbose) - device_printf(dev, + device_printf(sc->pl_dev, "Unable to fetch current resources: %s\n", AcpiFormatException(status)); return (status); } /* Fill in IRQ resources via link structures. */ - srsbuf.Pointer = NULL; + srsbuf->Pointer = NULL; link = sc->pl_links; i = 0; in_dpf = DPF_OUTSIDE; @@ -668,10 +716,10 @@ resptr = &newres; resptr->Data.ExtendedIrq.NumberOfInterrupts = 1; if (PCI_INTERRUPT_VALID(link->l_irq)) - resource->Data.ExtendedIrq.Interrupts[0] = + resptr->Data.ExtendedIrq.Interrupts[0] = link->l_irq; else - resource->Data.ExtendedIrq.Interrupts[0] = 0; + resptr->Data.ExtendedIrq.Interrupts[0] = 0; link++; i++; break; @@ -679,13 +727,13 @@ resptr = resource; } if (resptr != NULL) { - status = acpi_AppendBufferResource(&srsbuf, resptr); + status = acpi_AppendBufferResource(srsbuf, resptr); if (ACPI_FAILURE(status)) { - device_printf(dev, - "Unable to build reousrces: %s\n", + device_printf(sc->pl_dev, + "Unable to build resources: %s\n", AcpiFormatException(status)); - if (srsbuf.Pointer != NULL) - AcpiOsFree(srsbuf.Pointer); + if (srsbuf->Pointer != NULL) + AcpiOsFree(srsbuf->Pointer); AcpiOsFree(crsbuf.Pointer); return (status); } @@ -696,17 +744,88 @@ if (resource >= end) break; } + AcpiOsFree(crsbuf.Pointer); + return (AE_OK); +} + +static ACPI_STATUS +acpi_pci_link_srs_from_links(struct acpi_pci_link_softc *sc, + ACPI_BUFFER *srsbuf) +{ + ACPI_RESOURCE newres; + ACPI_STATUS status; + struct link *link; + int i; + + /* Start off with an empty buffer. */ + srsbuf->Pointer = NULL; + link = sc->pl_links; + for (i = 0; i < sc->pl_num_links; i++) { + + /* Add a new IRQ resource from each link. */ + link = &sc->pl_links[i]; + newres = link->l_prs_template; + if (newres.Id == ACPI_RSTYPE_IRQ) { + + /* Build an IRQ resource. */ + newres.Data.Irq.NumberOfInterrupts = 1; + if (PCI_INTERRUPT_VALID(link->l_irq)) { + KASSERT(link->l_irq < NUM_ISA_INTERRUPTS, + ("%s: can't put non-ISA IRQ %d in legacy IRQ resource type", + __func__, link->l_irq)); + newres.Data.Irq.Interrupts[0] = link->l_irq; + } else + newres.Data.Irq.Interrupts[0] = 0; + } else { + + /* Build an ExtIRQ resuorce. */ + newres.Data.ExtendedIrq.NumberOfInterrupts = 1; + if (PCI_INTERRUPT_VALID(link->l_irq)) + newres.Data.ExtendedIrq.Interrupts[0] = + link->l_irq; + else + newres.Data.ExtendedIrq.Interrupts[0] = 0; + } + + /* Add the new resource to the end of the _SRS buffer. */ + status = acpi_AppendBufferResource(srsbuf, &newres); + if (ACPI_FAILURE(status)) { + device_printf(sc->pl_dev, + "Unable to build resources: %s\n", + AcpiFormatException(status)); + if (srsbuf->Pointer != NULL) + AcpiOsFree(srsbuf->Pointer); + return (status); + } + } + return (AE_OK); +} + +static ACPI_STATUS +acpi_pci_link_route_irqs(device_t dev) +{ + struct acpi_pci_link_softc *sc; + ACPI_RESOURCE *resource, *end; + ACPI_BUFFER srsbuf; + ACPI_STATUS status; + struct link *link; + int i; + ACPI_SERIAL_ASSERT(pci_link); + sc = device_get_softc(dev); + if (sc->pl_crs_bad) + status = acpi_pci_link_srs_from_links(sc, &srsbuf); + else + status = acpi_pci_link_srs_from_crs(sc, &srsbuf); + /* Write out new resources via _SRS. */ status = AcpiSetCurrentResources(acpi_get_handle(dev), &srsbuf); if (ACPI_FAILURE(status)) { device_printf(dev, "Unable to route IRQs: %s\n", AcpiFormatException(status)); - AcpiOsFree(crsbuf.Pointer); AcpiOsFree(srsbuf.Pointer); return (status); } - AcpiOsFree(crsbuf.Pointer); /* * Perform acpi_config_intr() on each IRQ resource if it was just @@ -715,6 +834,7 @@ link = sc->pl_links; i = 0; resource = (ACPI_RESOURCE *)srsbuf.Pointer; + end = (ACPI_RESOURCE *)((char *)srsbuf.Pointer + srsbuf.Length); for (;;) { if (resource->Id == ACPI_RSTYPE_END_TAG) break; --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_pcib.c 2004/12/27 05:40:30 +++ //depot/user/jhb/acpipci/dev/acpica/acpi_pcib.c 2005/01/11 21:44:38 @@ -98,8 +98,7 @@ /* Lookup the associated handle and device. */ pcib = (device_t)arg; - if (ACPI_FAILURE(AcpiGetHandle(acpi_get_handle(pcib), entry->Source, - &handle))) + if (ACPI_FAILURE(AcpiGetHandle(ACPI_ROOT_OBJECT, entry->Source, &handle))) return; child = acpi_get_device(handle); if (child == NULL) --- //depot/vendor/freebsd/src/sys/dev/acpica/acpi_resource.c 2004/12/27 05:40:30 +++ //depot/user/jhb/acpipci/dev/acpica/acpi_resource.c 2004/12/31 18:57:45 @@ -439,7 +439,11 @@ "unimplemented Address64 resource\n")); break; case ACPI_RSTYPE_EXT_IRQ: - /* XXX special handling? */ + if (res->Data.ExtendedIrq.ProducerConsumer != ACPI_CONSUMER) { + ACPI_DEBUG_PRINT((ACPI_DB_RESOURCES, + "ignored ExtIRQ producer\n")); + break; + } set->set_irq(dev, context,res->Data.ExtendedIrq.Interrupts, res->Data.ExtendedIrq.NumberOfInterrupts, res->Data.ExtendedIrq.EdgeLevel, --- //depot/vendor/freebsd/src/sys/i386/i386/mptable.c 2005/01/07 18:45:35 +++ //depot/user/jhb/acpipci/i386/i386/mptable.c 2005/01/12 18:06:08 @@ -635,23 +635,38 @@ mptable_parse_io_int(int_entry_ptr intr) { void *ioapic; - u_int pin; + u_int pin, apic_id; + apic_id = intr->dst_apic_id; if (intr->dst_apic_id == 0xff) { - printf("MPTable: Ignoring global interrupt entry for pin %d\n", - intr->dst_apic_int); - return; + /* + * An APIC ID of 0xff means that the interrupt is connected + * to the specified pin on all I/O APICs in the system. If + * there is only one I/O APIC, then use that APIC to route + * the interrupts. If there is more than one I/O APIC, then + * punt. + */ + if (mptable_nioapics == 1) { + apic_id = 0; + while (ioapics[apic_id] == NULL) + apic_id++; + } else { + printf( + "MPTable: Ignoring global interrupt entry for pin %d\n", + intr->dst_apic_int); + return; + } } - if (intr->dst_apic_id >= NAPICID) { + if (apic_id >= NAPICID) { printf("MPTable: Ignoring interrupt entry for ioapic%d\n", intr->dst_apic_id); return; } - ioapic = ioapics[intr->dst_apic_id]; + ioapic = ioapics[apic_id]; if (ioapic == NULL) { printf( "MPTable: Ignoring interrupt entry for missing ioapic%d\n", - intr->dst_apic_id); + apic_id); return; } pin = intr->dst_apic_int; --- //depot/vendor/freebsd/src/sys/i386/pci/pci_pir.c 2005/01/06 22:21:32 +++ //depot/user/jhb/acpipci/i386/pci/pci_pir.c 2005/01/07 20:04:48 @@ -324,22 +324,50 @@ pin = intpin - entry->pe_intpin; pci_link = pci_pir_find_link(intpin->link); irq = pci_pir_search_irq(entry->pe_bus, entry->pe_device, pin); - if (irq == PCI_INVALID_IRQ) + if (irq == PCI_INVALID_IRQ || irq == pci_link->pl_irq) return; - if (pci_pir_valid_irq(pci_link, irq)) { - if (pci_link->pl_irq == PCI_INVALID_IRQ) { - pci_link->pl_irq = irq; - pci_link->pl_routed = 1; - } else if (pci_link->pl_irq != irq) + + /* + * If we don't have an IRQ for this link yet, then we trust the + * BIOS, even if it seems invalid from the $PIR entries. + */ + if (pci_link->pl_irq == PCI_INVALID_IRQ) { + if (!pci_pir_valid_irq(pci_link, irq)) printf( - "$PIR: BIOS IRQ %d for %d.%d.INT%c does not match link %#x irq %d\n", + "$PIR: Using invalid BIOS IRQ %d from %d.%d.INT%c is for link %#x\n", irq, entry->pe_bus, entry->pe_device, pin + 'A', - pci_link->pl_id, pci_link->pl_irq); - } else + pci_link->pl_id); + pci_link->pl_irq = irq; + pci_link->pl_routed = 1; + return; + } + + /* + * We have an IRQ and it doesn't match the current IRQ for this + * link. If the new IRQ is invalid, then warn about it and ignore + * it. If the old IRQ is invalid and the new IRQ is valid, then + * prefer the new IRQ instead. If both IRQs are valid, then just + * use the first one. Note that if we ever get into this situation + * we are having to guess which setting the BIOS actually routed. + * Perhaps we should just give up instead. + */ + if (!pci_pir_valid_irq(pci_link, irq)) { printf( "$PIR: BIOS IRQ %d for %d.%d.INT%c is not valid for link %#x\n", irq, entry->pe_bus, entry->pe_device, pin + 'A', pci_link->pl_id); + } else if (!pci_pir_valid_irq(pci_link, pci_link->pl_irq)) { + printf( +"$PIR: Preferring valid BIOS IRQ %d from %d.%d.INT%c for link %#x to IRQ %d\n", + irq, entry->pe_bus, entry->pe_device, pin + 'A', + pci_link->pl_id, pci_link->pl_irq); + pci_link->pl_irq = irq; + pci_link->pl_routed = 1; + } else + printf( + "$PIR: BIOS IRQ %d for %d.%d.INT%c does not match link %#x irq %d\n", + irq, entry->pe_bus, entry->pe_device, pin + 'A', + pci_link->pl_id, pci_link->pl_irq); } /* @@ -386,9 +414,9 @@ } /* - * Allow the user to override the IRQ for a given link device as - * long as the override is valid or is 255 or 0 to clear a preset - * IRQ. + * Allow the user to override the IRQ for a given link device. We + * allow invalid IRQs to be specified but warn about them. An IRQ + * of 255 or 0 clears any preset IRQ. */ i = 0; TAILQ_FOREACH(pci_link, &pci_links, pl_links) { @@ -398,12 +426,14 @@ continue; if (irq == 0) irq = PCI_INVALID_IRQ; - if (irq == PCI_INVALID_IRQ || - pci_pir_valid_irq(pci_link, irq)) { - pci_link->pl_routed = 0; - pci_link->pl_irq = irq; - i = 1; - } + if (irq != PCI_INVALID_IRQ && + !pci_pir_valid_irq(pci_link, irq) && bootverbose) + printf( + "$PIR: Warning, IRQ %d for link %#x is not listed as valid\n", + irq, pci_link->pl_id); + pci_link->pl_routed = 0; + pci_link->pl_irq = irq; + i = 1; } if (bootverbose && i) { printf("$PIR: Links after tunable overrides:\n"); -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 20:57:14 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 61BEC16A4CE for ; Wed, 12 Jan 2005 20:57:14 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0433243D49 for ; Wed, 12 Jan 2005 20:57:14 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id j0CKrC5D053299; Wed, 12 Jan 2005 15:53:12 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)j0CKrCkH053296; Wed, 12 Jan 2005 20:53:12 GMT (envelope-from robert@fledge.watson.org) Date: Wed, 12 Jan 2005 20:53:11 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Daniel Eriksson In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: NFS problems, locking up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 20:57:14 -0000 On Wed, 12 Jan 2005, Daniel Eriksson wrote: > I'm still having problems with NFS locking up when moving large amounts > of data over it on 6-CURRENT from 2005.01.11.05.00.00. This problem has > persisted for a long time now, and the only thing that seems to cure it > is running the network stack with giant enabled (debug.mpsafenet=0). > > When it happens, the process doing the copying ends up in "nfsaio" state > according to ps. Any accesses to the locked mount by other processes > ends up waiting forever in state "nfs". I have multiple file systems > mounted from the same server, and only the mount where the data is being > moved locks up. The others continue to work as expected. > > Server: UP, 6-CURRENT from 2005.01.11.05.00.00, if_vr (POLLING) Client: > SMP (dual AMD MP), 6-CURRENT from 2005.01.11.05.00.00, if_em > > The machines are connected with a crossover cable. I've tried both > schedulers (4BSD and ULE) on the client, but it doesn't make any > difference (server is running 4BSD). PREEMPTION is enabled on both > server and client. ADAPTIVE_GIANT is enabled on the client. If you run with INVARIANTS and WITNESS, does anything useful get printed out? Does it make a difference if you run the client with a UP kernel? If you break to the debugger on the client and server once wedging has occurred, what does "show lockedvnods" and "show alllocks" show? Is there any chance you could attach a second NFS client to the configuration, wedge the file system from the first client, and then try the second client and see if it experiences immediate problems? Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 20:58:57 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 370C616A4CF for ; Wed, 12 Jan 2005 20:58:57 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C01C843D48 for ; Wed, 12 Jan 2005 20:58:56 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id j0CKsgpx053367; Wed, 12 Jan 2005 15:54:42 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)j0CKsfqw053364; Wed, 12 Jan 2005 20:54:41 GMT (envelope-from robert@fledge.watson.org) Date: Wed, 12 Jan 2005 20:54:41 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Richard Coleman In-Reply-To: <41E553EB.10809@criticalmagic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: current@freebsd.org cc: Ivan Voras Subject: Re: MFC wishlist X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 20:58:57 -0000 On Wed, 12 Jan 2005, Richard Coleman wrote: > > No, because the project has no ability to "assign > > priority/resources". If someone who has is intrested and capable time > > to work on it, does so in time, then it may be done, if not, it > > won't. > > Should we take this to mean that none of the developers are interested > in ULE any more? That's the general feeling I get these days. Just > curious. Well, Jeff had a spurt of activity just before Christmas in which he corrected some issues relating to scheduling, and also committed a visual scheduling analysis tool that is both (a) quite neat, and (b) intended to help him measure and optimize scheduling. However, he's not been seen since then, so perhaps he went on vacation for a few weeks. From conversations with him, it sounded like he would be investing a substantial mount of time on the SMP VFS locking work, and also on SCHED_ULE. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 21:14:46 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8195B16A4D0 for ; Wed, 12 Jan 2005 21:14:46 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD58143D39 for ; Wed, 12 Jan 2005 21:14:45 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 1923 invoked from network); 12 Jan 2005 21:14:45 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 12 Jan 2005 21:14:45 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id j0CLEcLn027907; Wed, 12 Jan 2005 16:14:41 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-acpi@FreeBSD.org Date: Wed, 12 Jan 2005 16:15:23 -0500 User-Agent: KMail/1.6.2 References: <20050111202452.GK795@darkness.comp.waw.pl> <200501121442.02702.jhb@FreeBSD.org> <200501121506.50867.jhb@FreeBSD.org> In-Reply-To: <200501121506.50867.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200501121615.23209.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: acpi@FreeBSD.org cc: freebsd-current@FreeBSD.org cc: Pawel Jakub Dawidek Subject: Re: Intel SHG2 and ACPI 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: Wed, 12 Jan 2005 21:14:46 -0000 On Wednesday 12 January 2005 03:06 pm, John Baldwin wrote: > On Wednesday 12 January 2005 02:42 pm, John Baldwin wrote: > > On Tuesday 11 January 2005 05:40 pm, Pawel Jakub Dawidek wrote: > > > On Tue, Jan 11, 2005 at 02:16:06PM -0800, Nate Lawson wrote: > > > +> Pawel Jakub Dawidek wrote: > > > +> >I had problems with ACPI on Intel SHG2 motherboard. > > > +> >I made a patch with works for me just fine. Could you, Nate, verify > > > it +> >and commit if it is ok. > > > +> >If you need some more info, just ask. > > > +> > > > > +> > http://people.freebsd.org/~pjd/patches/acpi_pci_link.c.patch > > > +> > > > +> John mentioned that it appears the root problem is that _CRS is > > > failing +> for you. Can you send a dmesg from a broken boot (without > > > your patch)? > > > > > > Here you go: > > > > > > http://people.freebsd.org/~pjd/misc/boot-v1.txt > > > > Ok, this is a rather large patch as allowing for a b0rked _CRS required a > > good bit of work. I've only compile tested it and haven't run tested it > > so far, so beware. Note that it does include fixes for some bugs related > > to ExtIRQ routing (I wrote the irq to the wrong resource structure :( ) > > and to parsing the buffer we handed to _SRS (end pointer was wrong so I > > probably only ever parsed the first resource, which is the common case, > > so this probably didn't affect anyone). > > Gee, patch would help: > > [snip] Please ignore changes in this patch to files other than acpi_pci_link.c, sorry. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 21:17:54 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73C3316A4D5 for ; Wed, 12 Jan 2005 21:17:54 +0000 (GMT) Received: from ran.psg.com (ip192.186.dsl-acs2.seawa0.iinet.com [209.20.186.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4089B43D49 for ; Wed, 12 Jan 2005 21:17:54 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ran.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CopsF-000Eke-Cm; Wed, 12 Jan 2005 13:17:51 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16869.37886.885177.826496@ran.psg.com> Date: Wed, 12 Jan 2005 13:17:50 -0800 To: Doug White References: <16860.4383.281114.747270@roam.psg.com> <20050110183217.M84532@carver.gumbysoft.com> cc: FreeBSD Current Subject: Re: fsck issue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 21:17:54 -0000 > These backtraces are generated by this code in getdirtybuf(): > 5847 if (bp->b_vp == NULL) > 5848 kdb_backtrace(); > > Somehow there's a buf floating around without a vnode attached. I'd > suggest booting single user and fsck -y'ing all your filesystems to verify > there is no residual damage, and remove any snapshots from your ufs2 > filesystems. been doing that, except for snap removal. do you mean rm -rf /foo/.snap/* ? randy From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 21:34:38 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38AAB16A4CE; Wed, 12 Jan 2005 21:34:38 +0000 (GMT) Received: from darkness.comp.waw.pl (darkness.comp.waw.pl [195.117.238.136]) by mx1.FreeBSD.org (Postfix) with ESMTP id 829E543D1F; Wed, 12 Jan 2005 21:34:37 +0000 (GMT) (envelope-from pjd@darkness.comp.waw.pl) Received: by darkness.comp.waw.pl (Postfix, from userid 1009) id DC344ACBF9; Wed, 12 Jan 2005 22:34:33 +0100 (CET) Date: Wed, 12 Jan 2005 22:34:33 +0100 From: Pawel Jakub Dawidek To: John Baldwin Message-ID: <20050112213433.GP795@darkness.comp.waw.pl> References: <20050111202452.GK795@darkness.comp.waw.pl> <200501121442.02702.jhb@FreeBSD.org> <200501121506.50867.jhb@FreeBSD.org> <200501121615.23209.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xe2geHXJg22At20M" Content-Disposition: inline In-Reply-To: <200501121615.23209.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 5.2.1-RC2 i386 cc: freebsd-acpi@FreeBSD.org cc: freebsd-current@FreeBSD.org Subject: Re: Intel SHG2 and ACPI 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: Wed, 12 Jan 2005 21:34:38 -0000 --xe2geHXJg22At20M Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 12, 2005 at 04:15:23PM -0500, John Baldwin wrote: +> > > Ok, this is a rather large patch as allowing for a b0rked _CRS requi= red a +> > > good bit of work. I've only compile tested it and haven't run teste= d it +> > > so far, so beware. Note that it does include fixes for some bugs re= lated +> > > to ExtIRQ routing (I wrote the irq to the wrong resource structure := ( ) +> > > and to parsing the buffer we handed to _SRS (end pointer was wrong s= o I +> > > probably only ever parsed the first resource, which is the common ca= se, +> > > so this probably didn't affect anyone). +> > +> > Gee, patch would help: +> > +> > [snip] +>=20 +> Please ignore changes in this patch to files other than acpi_pci_link.c,= =20 +> sorry. Works for me. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --xe2geHXJg22At20M Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFB5ZfpForvXbEpPzQRApV4AJ49dkixHEwp8oFHcs2qhZ3tdBTuZgCg4sOv DxushVzCxapw5ihdYvRfZHs= =P08n -----END PGP SIGNATURE----- --xe2geHXJg22At20M-- From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 21:36:06 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA98816A4CE for ; Wed, 12 Jan 2005 21:36:06 +0000 (GMT) Received: from avscan1.sentex.ca (avscan1.sentex.ca [199.212.134.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7853B43D3F for ; Wed, 12 Jan 2005 21:36:06 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id j0CLa5rW089655; Wed, 12 Jan 2005 16:36:05 -0500 (EST) (envelope-from mike@sentex.net) Received: from avscan1.sentex.ca ([127.0.0.1]) by localhost (avscan1.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 89148-07; Wed, 12 Jan 2005 16:36:05 -0500 (EST) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan1.sentex.ca (8.12.11/8.12.11) with ESMTP id j0CLa56l089598; Wed, 12 Jan 2005 16:36:05 -0500 (EST) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id j0CLZvIh017089; Wed, 12 Jan 2005 16:35:58 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <6.2.0.14.0.20050112155023.06444c18@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 12 Jan 2005 16:36:44 -0500 To: freebsd-current@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan1b Subject: em0 link transitions when aliasing an interface X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 21:36:06 -0000 Does anyone know of a way to avoid bouncing the em NIC when adding or removing aliases ? In cases where the switch's port blocking kicks in, this can take the box off line for a problematic amount of time. e.g. ifconfig em0 19.168.13.9 netmask 255.255.255.252 alias will down and up the interface. I dont know of any other drivers that work this way. On RELENG_4, it used to only have this problem behavior when the NIC was in autoneg. But this is no longer the case in RELENG_5 as all media-opts (full / half / autoneg) work this way now. Are there any tunables that would govern this behavior ? Thanks for any insight, ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 03:14:50 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E544616A4CE for ; Thu, 13 Jan 2005 03:14:50 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A892E43D39 for ; Thu, 13 Jan 2005 03:14:50 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 9949472DD4; Wed, 12 Jan 2005 19:14:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 947AE72DCB; Wed, 12 Jan 2005 19:14:50 -0800 (PST) Date: Wed, 12 Jan 2005 19:14:50 -0800 (PST) From: Doug White To: Randy Bush In-Reply-To: <16869.37886.885177.826496@ran.psg.com> Message-ID: <20050112191405.J6322@carver.gumbysoft.com> References: <16860.4383.281114.747270@roam.psg.com> <20050110183217.M84532@carver.gumbysoft.com> <16869.37886.885177.826496@ran.psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: FreeBSD Current Subject: Re: fsck issue? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 03:14:51 -0000 On Wed, 12 Jan 2005, Randy Bush wrote: > > These backtraces are generated by this code in getdirtybuf(): > > 5847 if (bp->b_vp == NULL) > > 5848 kdb_backtrace(); > > > > Somehow there's a buf floating around without a vnode attached. I'd > > suggest booting single user and fsck -y'ing all your filesystems to verify > > there is no residual damage, and remove any snapshots from your ufs2 > > filesystems. > > been doing that, except for snap removal. do you mean > rm -rf /foo/.snap/* Yes. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 04:00:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C37C16A4CE for ; Thu, 13 Jan 2005 04:00:10 +0000 (GMT) Received: from mailhub2.uq.edu.au (mailhub2.uq.edu.au [130.102.149.128]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71E1B43D48 for ; Thu, 13 Jan 2005 04:00:09 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from smtp2.uq.edu.au (smtp2.uq.edu.au [130.102.5.53]) by mailhub2.uq.edu.au (8.12.11/8.12.11) with ESMTP id j0D408MF054853 for ; Thu, 13 Jan 2005 14:00:08 +1000 (EST) Received: from [130.102.152.118] (stealthd.its.uq.edu.au [130.102.152.118]) by smtp2.uq.edu.au (8.12.10/8.12.10) with ESMTP id j0D407Jh026490 for ; Thu, 13 Jan 2005 14:00:07 +1000 (EST) Message-ID: <41E5F22A.6010607@uq.edu.au> Date: Thu, 13 Jan 2005 13:59:38 +1000 From: Matthew Sullivan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040618 X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <41E44CD0.1000008@uq.edu.au> In-Reply-To: <41E44CD0.1000008@uq.edu.au> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080802070900010705070000" X-Scanned-By: MIMEDefang 2.43 on UQ Mailhub Subject: Re: Fatal Trap 12: Page fault while in kernel mode (racoon/amd64/5.3-RELEASE-p4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 04:00:10 -0000 This is a cryptographically signed message in MIME format. --------------ms080802070900010705070000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit First if this is the incorrect mailing list for these type of posts please let me know or I'll never be able to post to the correct location... Matthew Sullivan wrote: > I have recompiled the kernel with KDB and KDB_UNATTENDED however it > appears the machine is totally locked in this state - it will not > automatically reboot, it will not respond to [CTRL-ALT-ESC] it will > not even respond to [CTRL-ALT-DEL] - the only thing it will respond to > is "the big red button" ;-) > > I have told it to save cores, however so far no cores. The crash is > reproducible everytime. The fault process is recorded as racoon. > > Any suggestions on solving or debugging this further would be greatly > appreciated. > > The machine is rack mounted and without remote management card so > getting the rest of the trace information is not going to be easy. > Further to my last I have finally located a null modem cable and got it installed... A little fiddling later and we have DDB taking over... root@desperado:~# racoon Fatal trap 12: page fault while in kernel mode fault virtual address = 0x39 fault code = supervisor write, page not present instruction pointer = 0x8:0xffffffff80307a70 stack pointer = 0x10:0xffffffff94eb4860 frame pointer = 0x10:0xffffffff94eb4960 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 454 (racoon) [thread 100081] Stopped at keydb_newsecasvar+0x100: decl %ecx db> where keydb_newsecasvar() at keydb_newsecasvar+0x100 raw_usend() at raw_usend+0x60 key_send() at key_send+0xa sosend() at sosend+0x626 kern_sendit() at kern_sendit+0x113 sendit() at sendit+0x5f sendto() at sendto+0x4d syscall() at syscall+0x50c Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (133, FreeBSD ELF64, sendto), rip = 0x800a63da8, rsp = 0x7fffffffec38, rbp = 0x2 --- db> show reg cs 0x8 ss 0x10 rax 0xffffffff94eb4890 rcx 0xffffffff94eb493f rdx 0xffffffff94eb4970 rbx 0xffffffff80307a6d keydb_newsecasvar+0xfd rsp 0xffffffff94eb4860 rbp 0xffffffff94eb4960 rsi 0x280 rdi 0xffffff001cce7c00 r8 0xa0 r9 0xffffff00151807b0 r10 0xffffffff80513980 key_usrreqs r11 0xffffffff94eb4a10 r12 0x39 r13 0 r14 0 r15 0xffffff00164aa678 rip 0xffffffff80307a70 keydb_newsecasvar+0x100 rflags 0x10202 dr0 0 dr1 0 dr2 0 dr3 0 dr4 0xffff0ff0 dr5 0x400 dr6 0xffff0ff0 dr7 0x400 keydb_newsecasvar+0x100: decl %ecx db> show all procs/m pid proc uarea uid ppid pgrp flag stat wmesg wchan cmd 454 ffffff001555e5d0 ffffffff94ec0000 0 453 454 0004002 [CPU 0] racoon 453 ffffff001555e2e8 ffffffff94ebf000 0 443 453 0004002 [SLPQ wait 0xffffff001555e2e8][SLP] bash 452 ffffff001ccc62e8 ffffffff93cd3000 0 1 1 0004000 [SLPQ siodcd 0xffffff000096dc00][SLP] getty 451 ffffff001555e8b8 ffffffff94ec1000 0 1 451 0004002 [SLPQ ttyin 0xffffff0000956010][SLP] getty 450 ffffff001ccc6000 ffffffff93cd2000 0 1 450 0004002 [SLPQ ttyin 0xffffff0000956410][SLP] getty 449 ffffff001cce32e8 ffffffff93c92000 0 1 449 0004002 [SLPQ ttyin 0xffffff000096c010][SLP] getty 448 ffffff00152f98b8 ffffffff94e80000 0 1 448 0004002 [SLPQ ttyin 0xffffff0000954410][SLP] getty 447 ffffff001555eba0 ffffffff94ec2000 0 1 447 0004002 [SLPQ ttyin 0xffffff0000954810][SLP] getty 446 ffffff00152f92e8 ffffffff94e7e000 0 1 446 0004002 [SLPQ ttyin 0xffffff000096d410][SLP] getty 445 ffffff00152f95d0 ffffffff94e7f000 0 1 445 0004002 [SLPQ ttyin 0xffffff0000971c10][SLP] getty 444 ffffff00152f9000 ffffffff94e7d000 0 1 444 0004002 [SLPQ ttyin 0xffffff000096c810][SLP] getty 443 ffffff001ccc68b8 ffffffff93cd5000 0 1 443 0004102 [SLPQ wait 0xffffff001ccc68b8][SLP] login 442 ffffff00152f9ba0 ffffffff94e81000 0 441 53 0004002 [SLPQ nanslp 0xffffffff8053ba40][SLP] sleep 441 ffffff001cce35d0 ffffffff93c93000 0 438 53 0000002 [SLPQ wait 0xffffff001cce35d0][SLP] sh 439 ffffff001555e000 ffffffff94e82000 0 1 53 0004002 [SLPQ piperd 0xffffff001722ab40][SLP] logger 438 ffffff001ccc6ba0 ffffffff93cd6000 0 1 53 0000002 [SLPQ wait 0xffffff001ccc6ba0][SLP] sh 403 ffffff00154a1000 ffffffff94ec3000 0 1 403 0000000 [SLPQ nanslp 0xffffffff8053ba40][SLP] cron 390 ffffff001cda75d0 ffffffff93c00000 25 1 390 0000100 [SLPQ pause 0xffffff001cda7640][SLP] sendmail 386 ffffff001cda7ba0 ffffffff93c02000 0 1 386 0000100 [SLPQ select 0xffffffff80542030][SLP] sendmail 380 ffffff001cce38b8 ffffffff93cd0000 0 1 380 0000100 [SLPQ select 0xffffffff80542030][SLP] sshd 273 ffffff001cce3ba0 ffffffff93cd1000 0 1 273 0000000 [SLPQ select 0xffffffff80542030][SLP] syslogd 253 ffffff001cce3000 ffffffff93c91000 0 1 253 0000000 [SLPQ select 0xffffffff80542030][SLP] devd 181 ffffff001cda78b8 ffffffff93c01000 0 1 181 0000000 [SLPQ pause 0xffffff001cda7928][SLP] adjkerntz 52 ffffff001ccc65d0 ffffffff93cd4000 0 0 0 0000204 [SLPQ - 0xffffffff93cacbe4][SLP] schedcpu 51 ffffff001cda2000 ffffffff93bb8000 0 0 0 0000204 [SLPQ syncer 0xffffffff8053b720][SLP] syncer 50 ffffff001cda22e8 ffffffff93bb9000 0 0 0 0000204 [SLPQ vlruwt 0xffffff001cda22e8][SLP] vnlru 49 ffffff001cda25d0 ffffffff93bba000 0 0 0 0000204 [SLPQ psleep 0xffffffff8054295c][SLP] bufdaemon 48 ffffff001cda28b8 ffffffff93bbb000 0 0 0 000020c [SLPQ pgzero 0xffffffff80556dd4][SLP] pagezero 47 ffffff001cda2ba0 ffffffff93bbc000 0 0 0 0000204 [SLPQ psleep 0xffffffff80556e3c][SLP] vmdaemon 46 ffffff001cd83000 ffffffff93bbd000 0 0 0 0000204 [SLPQ psleep 0xffffffff80556dec][SLP] pagedaemon 45 ffffff001cd832e8 ffffffff93bfa000 0 0 0 0000204 [IWAIT] swi0: sio 44 ffffff001cd835d0 ffffffff93bfb000 0 0 0 0000204 [SLPQ - 0xffffff0000811848][SLP] fdc0 43 ffffff001cd838b8 ffffffff93bfc000 0 0 0 0000204 [SLPQ tzpoll 0xffffffff8052e568][SLP] acpi_thermal 9 ffffff001cd83ba0 ffffffff93bfd000 0 0 0 0000204 [SLPQ actask 0xffffffff8052e620][SLP] acpi_task2 8 ffffff001cda7000 ffffffff93bfe000 0 0 0 0000204 [SLPQ actask 0xffffffff8052e620][SLP] acpi_task1 7 ffffff001cd92000 ffffffff93b72000 0 0 0 0000204 [SLPQ actask 0xffffffff8052e620][SLP] acpi_task0 42 ffffff001cd922e8 ffffffff93b73000 0 0 0 0000204 [IWAIT] swi6: task queue 41 ffffff001cd925d0 ffffffff93b74000 0 0 0 0000204 [IWAIT] swi6:+ 6 ffffff001cd928b8 ffffffff93b75000 0 0 0 0000204 [SLPQ - 0xffffff0000835b80][SLP] thread taskq 40 ffffff001cd92ba0 ffffffff93b76000 0 0 0 0000204 [IWAIT] swi6:+ 5 ffffff001cdb7000 ffffffff93bb3000 0 0 0 0000204 [SLPQ - 0xffffff0000835d00][SLP] kqueue taskq 39 ffffff001cdb72e8 ffffffff93bb4000 0 0 0 0000204 [IWAIT] swi6: acpitaskq 38 ffffff001cdb75d0 ffffffff93bb5000 0 0 0 0000204 [SLPQ - 0xffffffff8052eb00][SLP] yarrow 4 ffffff001cdb78b8 ffffffff93bb6000 0 0 0 0000204 [SLPQ - 0xffffffff80532988][SLP] g_down 3 ffffff001cdb7ba0 ffffffff93bb7000 0 0 0 0000204 [SLPQ - 0xffffffff80532980][SLP] g_up 2 ffffff001cd8e2e8 ffffffff93b2d000 0 0 0 0000204 [SLPQ - 0xffffffff80532970][SLP] g_event 37 ffffff001cd8e5d0 ffffffff93b2e000 0 0 0 0000204 [IWAIT] swi4: vm 36 ffffff001cd8e8b8 ffffffff93b2f000 0 0 0 000020c [RUNQ] swi5: clock sio 35 ffffff001cd8eba0 ffffffff93b30000 0 0 0 0000204 [IWAIT] swi1: net 34 ffffff001cda5000 ffffffff93b6d000 0 0 0 0000204 [IWAIT] irq23: 33 ffffff001cda52e8 ffffffff93b6e000 0 0 0 0000204 [IWAIT] irq22: 32 ffffff001cda55d0 ffffffff93b6f000 0 0 0 0000204 [IWAIT] irq21: 31 ffffff001cda58b8 ffffffff93b70000 0 0 0 0000204 [IWAIT] irq20: 30 ffffff001cda5ba0 ffffffff93b71000 0 0 0 0000204 [RUNQ] irq19: sis0 sis1 29 ffffff001cda38b8 ffffffff93b07000 0 0 0 0000204 [IWAIT] irq18: 28 ffffff001cda3ba0 ffffffff93b08000 0 0 0 0000204 [IWAIT] irq17: atapci1 27 ffffff001cd8c000 ffffffff93b09000 0 0 0 0000204 [IWAIT] irq16: 26 ffffff001cd8c2e8 ffffffff93b28000 0 0 0 0000204 [IWAIT] irq15: ata1 25 ffffff001cd8c5d0 ffffffff93b29000 0 0 0 0000204 [IWAIT] irq14: ata0 24 ffffff001cd8c8b8 ffffffff93b2a000 0 0 0 0000204 [IWAIT] irq13: 23 ffffff001cd8cba0 ffffffff93b2b000 0 0 0 0000204 [IWAIT] irq12: 22 ffffff001cd8e000 ffffffff93b2c000 0 0 0 0000204 [IWAIT] irq11: 21 ffffff001cddd2e8 ffffffff93ae2000 0 0 0 0000204 [IWAIT] irq10: 20 ffffff001cddd5d0 ffffffff93ae3000 0 0 0 0000204 [IWAIT] irq9: acpi0 19 ffffff001cddd8b8 ffffffff93b02000 0 0 0 0000204 [IWAIT] irq8: rtc 18 ffffff001cdddba0 ffffffff93b03000 0 0 0 0000204 [IWAIT] irq7: ppc0 17 ffffff001cda3000 ffffffff93b04000 0 0 0 0000204 [IWAIT] irq6: fdc0 16 ffffff001cda32e8 ffffffff93b05000 0 0 0 0000204 [IWAIT] irq5: 15 ffffff001cda35d0 ffffffff93b06000 0 0 0 0000204 [IWAIT] irq4: sio0 14 ffffff001cdd6000 ffffffff93aa0000 0 0 0 0000204 [IWAIT] irq3: sio1 13 ffffff001cdd62e8 ffffffff93add000 0 0 0 0000204 [IWAIT] irq0: clk 12 ffffff001cdd65d0 ffffffff93ade000 0 0 0 0000204 [IWAIT] irq1: atkbd0 11 ffffff001cdd68b8 ffffffff93adf000 0 0 0 000020c [Can run] idle 1 ffffff001cdd6ba0 ffffffff93ae0000 0 0 1 0004200 [SLPQ wait 0xffffff001cdd6ba0][SLP] init 10 ffffff001cddd000 ffffffff93ae1000 0 0 0 0000204 [SLPQ ktrace 0xffffffff80538370][SLP] ktrace 0 ffffffff80532b00 ffffffff80679000 0 0 0 0000200 [SLPQ sched 0xffffffff80532b00][SLP] swapper I'm going to have to put this machine into production within the next 7 days so any help would be really great, also any extra info anyone requires is available. As I said in my last this is 100% reproducable. Dumps are not available - calling panic will lock the system solid. Calling boot(0) seems to work fine though... Regards, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms080802070900010705070000 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDExMzAzNTkzOFowIwYJKoZIhvcNAQkEMRYEFAvBOHL3pvrLKWKp VT/JC2bbCtOCMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQHr9wSisw2m3T02gcf+p6Tq5g34XmKZDseKmfVBCdlMPfAhF5gPb45hBF3qkfiIJJciN TTO1XAaCXYMbrVo4w3oAAAAAAAA= --------------ms080802070900010705070000-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 06:07:25 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A85EE16A4CE for ; Thu, 13 Jan 2005 06:07:25 +0000 (GMT) Received: from smtp1.fuse.net (mail-out1.fuse.net [216.68.8.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED65E43D31 for ; Thu, 13 Jan 2005 06:07:24 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from gx5.fuse.net ([216.196.230.139]) by smtp1.fuse.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050113060547.XSBQ18019.smtp1.fuse.net@gx5.fuse.net> for ; Thu, 13 Jan 2005 01:05:47 -0500 Received: from www.united-ware.com ([216.196.230.139]) by gx5.fuse.net (InterMail vG.1.02.00.02 201-2136-104-102-20041210) with ESMTP id <20050113060423.HXKV4914.gx5.fuse.net@www.united-ware.com> for ; Thu, 13 Jan 2005 01:04:23 -0500 Received: from [192.168.0.5] (adsl-69-208-54-135.dsl.wotnoh.ameritech.net [69.208.54.135]) (authenticated bits=0) by www.united-ware.com (8.12.9p2/8.12.9) with ESMTP id j0D5qpKp079067 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 13 Jan 2005 00:52:52 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-current@freebsd.org Date: Thu, 13 Jan 2005 01:10:58 -0500 User-Agent: KMail/1.7 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1195697.l2nzahnLhT"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501130111.04893.mistry.7@osu.edu> Subject: propagate_priority panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 06:07:25 -0000 --nextPart1195697.l2nzahnLhT Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Not sure if anyone else is seeing this, but I'm pretty sure the following= =20 commit broke my system. When mysql tries to shutdown I get a panic in=20 propagate_priority. As well as X freezing when I go to start it. Actually= =20 one of the applictions or the WM causes it to freeze, but same problem I=20 think but I can't see the console. Before this everything worked fine. I= =20 can post the hand transcribed panic backtrace message tomorrow if anyone=20 is interested since I don't have a serial port on the machine. I'm using the 4BSD scheduler with the latest -CURRENT. jhb 2004-12-30 20:52:44 UTC FreeBSD src repository Modified files: sys/kern sched_4bsd.c sched_ule.c subr_turnstile.c=20 sys/sys proc.h sched.h turnstile.h=20 =20 Revision Changes Path 1.71 +102 -14 src/sys/kern/sched_4bsd.c 1.144 +77 -20 src/sys/kern/sched_ule.c 1.151 +120 -71 src/sys/kern/subr_turnstile.c 1.415 +1 -0 src/sys/sys/proc.h 1.23 +2 -0 src/sys/sys/sched.h 1.6 +1 -0 src/sys/sys/turnstile.h =2D-=20 Anish Mistry --nextPart1195697.l2nzahnLhT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBB5hD4xqA5ziudZT0RAtoNAKCeAE9Bzbgu28BBpfvkM9iVL5J+nACbBQVc iwCn1gzaurCAYvH3yC8wrIk= =JaHu -----END PGP SIGNATURE----- --nextPart1195697.l2nzahnLhT-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 06:50:12 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3986D16A4CE for ; Thu, 13 Jan 2005 06:50:12 +0000 (GMT) Received: from drop.bsdchat.com (drop.bsdchat.com [209.237.225.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0929743D5A for ; Thu, 13 Jan 2005 06:50:12 +0000 (GMT) (envelope-from clive@tongi.org) Received: from CARTIER (drag.bsdchat.com [209.237.225.37]) by drop.bsdchat.com (8.13.1/8.13.1) with SMTP id j0D6lnw0052730; Thu, 13 Jan 2005 06:47:51 GMT (envelope-from clive@tongi.org) Received: (nullmailer pid 9816 invoked by uid 1000); Thu, 13 Jan 2005 06:50:03 -0000 Date: Thu, 13 Jan 2005 14:50:03 +0800 From: Clive Lin To: Ben Becker Message-ID: <20050113065003.GA2336@tongi.org> References: <38d37be7050111092379f2a898@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38d37be7050111092379f2a898@mail.gmail.com> X-PGP-key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA008C03E User-Agent: Mutt/1.5.6i cc: freebsd-current@freebsd.org Subject: Re: Atheros and SIS bridging problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 06:50:12 -0000 On Tue, Jan 11, 2005 at 09:23:08AM -0800, Ben Becker wrote: > [Laptop]--------(sis0)-[FreeBSD Bridge]-(ath0)--------[FreeBSD AP] > > There seems to be a problem with bridging ath0 and sis0. I have 1 IP > assigned to ath0 which is 192.168.1.3, and I've sysctl'd > 'net.link.ether.bridge.enable=1' and > 'net.link.ether.bridge.config=ath0,sis0'. From the bridge, I can ping > the AP (192.168.1.1) and the laptop (192.168.1.5). However I can't > ping from the laptop to the AP or from the AP to the laptop. Hi, Have you tried ng_bridge(4)? My own experience is similar with yours, and the problem like yours is sovled via ng_bridge(4). Example scripts to setup ng_bridge(4) is at /usr/share/examples/netgraph/ether.bridge. My setup is: [Desktop]------(ed0)-[freebsd bridge]-(fxp0)----[LAN] With bridge(4), the Desktop is able to access the LAN, but not the bridge. No response at all. With ng_bridge(4), both LAN and the freebsd bridge are accessible. The freebsd bridge is -current, and NICs above are: fxp0: port 0x8000-0x803f mem 0xc0201000-0xc0201fff irq 11 at device 8.0 on pci2 ed0: at port 0x4000-0x401f irq 11 function 0 config 16 on pccard0 BTW, bridge(4) performance is better than ng_bridge(4). Cheers, -- Clive Tong-I Lin | http://tongi.org | PGP KeyID: A008C03E From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 10:07:15 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FA0E16A4CE for ; Thu, 13 Jan 2005 10:07:15 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA6CB43D49 for ; Thu, 13 Jan 2005 10:07:14 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1Cp1sl-000Ewk-QG; Thu, 13 Jan 2005 12:07:11 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Anish Mistry In-reply-to: Your message of Thu, 13 Jan 2005 01:10:58 -0500 . Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Jan 2005 12:07:11 +0200 From: Danny Braniss Message-Id: <20050113100714.EA6CB43D49@mx1.FreeBSD.org> cc: freebsd-current@freebsd.org Subject: Re: propagate_priority panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 10:07:15 -0000 > Not sure if anyone else is seeing this, but I'm pretty sure the following= > =20 > commit broke my system. When mysql tries to shutdown I get a panic in=20 > propagate_priority. As well as X freezing when I go to start it. Actually= > =20 > one of the applictions or the WM causes it to freeze, but same problem I=20 > think but I can't see the console. Before this everything worked fine. I= > =20 > can post the hand transcribed panic backtrace message tomorrow if anyone=20 > is interested since I don't have a serial port on the machine. > I'm using the 4BSD scheduler with the latest -CURRENT. > > jhb 2004-12-30 20:52:44 UTC > > FreeBSD src repository > > Modified files: > sys/kern sched_4bsd.c sched_ule.c subr_turnstile.c=20 > sys/sys proc.h sched.h turnstile.h=20 > =20 > Revision Changes Path > 1.71 +102 -14 src/sys/kern/sched_4bsd.c > 1.144 +77 -20 src/sys/kern/sched_ule.c > 1.151 +120 -71 src/sys/kern/subr_turnstile.c > 1.415 +1 -0 src/sys/sys/proc.h > 1.23 +2 -0 src/sys/sys/sched.h > 1.6 +1 -0 src/sys/sys/turnstile.h > =2D-=20 > Anish Mistry in my case it's probably more my fault, since it happens in a driver-module that im writing - though i'm begining to think otherwise. Adding debug printfs fixes the panics, which most probably means some timing problem. The code is experimental, but if someone would like to take a look, i've placed it, together with the panic in: ftp://ftp.cs.huji.ac.il/users/danny/freebsd/panic/ danny From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 10:07:43 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3361016A4CE for ; Thu, 13 Jan 2005 10:07:43 +0000 (GMT) Received: from ms-dienst.rz.rwth-aachen.de (ms-2.rz.RWTH-Aachen.DE [134.130.3.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F2B243D1D for ; Thu, 13 Jan 2005 10:07:42 +0000 (GMT) (envelope-from chris@unixpages.org) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0IA900FXX2SSUW@ms-dienst.rz.rwth-aachen.de> for current@freebsd.org; Thu, 13 Jan 2005 11:07:41 +0100 (MET) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Thu, 13 Jan 2005 11:07:39 +0100 (MET) Received: from haakonia.hitnet.rwth-aachen.de (mulzirak.hitnet.RWTH-Aachen.DE [137.226.181.149])j0DA7dF5006897 for ; Thu, 13 Jan 2005 11:07:39 +0100 (MET) Received: from gondor.middleearth (gondor.middleearth [192.168.1.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))(Postfix) with ESMTP id DB9582844E for ; Thu, 13 Jan 2005 11:07:33 +0100 (CET) Received: by gondor.middleearth (Postfix, from userid 1001) id 3376822824; Thu, 13 Jan 2005 11:07:33 +0100 (CET) Date: Thu, 13 Jan 2005 11:07:32 +0100 From: Christian Brueffer To: current@freebsd.org Message-id: <20050113100732.GA65407@unixpages.org> MIME-version: 1.0 Content-type: multipart/signed; boundary=wac7ysb48OaltWcw; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 6.0-CURRENT X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D Subject: panic: softdep_deallocate_dependencies: dangling deps X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 10:07:43 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, got this panic on a SMP machine tonight. This is about the 10th time I've gotten this specific panic during the last 2 years. Unfortunately I haven't found a way to trigger this yet. Coredump is available for further investigation. panic: softdep_deallocate_dependencies: dangling deps panic messages: --- panic: softdep_deallocate_dependencies: dangling deps cpuid =3D 1 KDB: enter: panic Dumping 511 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 --- #0 doadump () at pcpu.h:159 159 pcpu.h: No such file or directory. in pcpu.h doadump () at pcpu.h:159 159 in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:159 #1 0xc0475620 in db_fncall (dummy1=3D0, dummy2=3D0, dummy3=3D-1066882173,= =20 dummy4=3D0xd544a9ec "\030=AAD=D5\207\223h=C0\004=AAD=D5\b=AAD=D5\220\a") at /usr/home/build/src/sys/ddb/db_command.c:531 #2 0xc0475422 in db_command (last_cmdp=3D0xc0742124, cmd_table=3D0x0, aux_= cmd_tablep=3D0xc070a468,=20 aux_cmd_tablep_end=3D0xc070a46c) at /usr/home/build/src/sys/ddb/db_comm= and.c:349 #3 0xc04754ee in db_command_loop () at /usr/home/build/src/sys/ddb/db_comm= and.c:455 #4 0xc047722c in db_trap (type=3D3, code=3D0) at /usr/home/build/src/sys/d= db/db_main.c:221 #5 0xc0556209 in kdb_trap (type=3D3, code=3D0, tf=3D0x1) at /usr/home/buil= d/src/sys/kern/subr_kdb.c:418 #6 0xc06a55d0 in trap (frame=3D {tf_fs =3D 24, tf_es =3D 16, tf_ds =3D 16, tf_edi =3D -1066419633, tf= _esi =3D 1, tf_ebp =3D -716919956, tf_isp =3D -716919976, tf_ebx =3D -716919912, tf_edx =3D 0, tf_ecx =3D -1056755712, tf_eax =3D 18, tf_trapno =3D 3, tf_er= r =3D 0, tf_eip =3D -1068146901, tf_cs =3D 8, tf_eflags =3D 646, tf_esp =3D -716919924, tf_ss =3D -1068243131}) at /usr/home/build/src/sys/i386/i386/trap.c:576 #7 0xc069384a in calltrap () at /usr/home/build/src/sys/i386/i386/exceptio= n.s:140 #8 0x00000018 in ?? () #9 0x00000010 in ?? () #10 0x00000010 in ?? () #11 0xc06fba4f in ?? () #12 0x00000001 in ?? () #13 0xd544ab6c in ?? () #14 0xd544ab58 in ?? () #15 0xd544ab98 in ?? () #16 0x00000000 in ?? () #17 0xc1033000 in ?? () #18 0x00000012 in ?? () #19 0x00000003 in ?? () #20 0x00000000 in ?? () #21 0xc0555f2b in kdb_enter (msg=3D0x0) at cpufunc.h:56 #22 0xc053e745 in panic (fmt=3D0xc06fba4f "softdep_deallocate_dependencies:= dangling deps") at /usr/home/build/src/sys/kern/kern_shutdown.c:550 #23 0xc0646256 in softdep_deallocate_dependencies (bp=3D0x0) at /usr/home/build/src/sys/ufs/ffs/ffs_softdep.c:5949 #24 0xc058280f in brelse (bp=3D0xcbff6f9c) at buf.h:431 #25 0xc0590430 in flushbuflist (blist=3D0xcbff6f9c, flags=3D0, vp=3D0xc1fac= 630, slpflag=3D0, slptimeo=3D0,=20 errorp=3D0x0) at /usr/home/build/src/sys/kern/vfs_subr.c:1101 #26 0xc0590109 in vinvalbuf (vp=3D0xc1fac630, flags=3D0, cred=3D0x0, td=3D0= x0, slpflag=3D0, slptimeo=3D0) at /usr/home/build/src/sys/kern/vfs_subr.c:987 #27 0xc0592999 in vclean (vp=3D0xc1fac630, flags=3D8, td=3D0xc19e6c80) at /usr/home/build/src/sys/kern/vfs_subr.c:2479 #28 0xc0592f11 in vgonel (vp=3D0xc1fac630, td=3D0xc19e6c80) at /usr/home/bu= ild/src/sys/kern/vfs_subr.c:2701 #29 0xc058f3f2 in vlrureclaim (mp=3D0xc2395800) at pcpu.h:156 #30 0xc058f5a6 in vnlru_proc () at /usr/home/build/src/sys/kern/vfs_subr.c:= 598 #31 0xc0529848 in fork_exit (callout=3D0xc058f460 , arg=3D0x0, = frame=3D0xd544ad48) at /usr/home/build/src/sys/kern/kern_fork.c:807 #32 0xc06938ac in fork_trampoline () at /usr/home/build/src/sys/i386/i386/e= xception.s:209 - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --wac7ysb48OaltWcw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB5khkbHYXjKDtmC0RAlEzAKCRATT45bLRt8bZvvYoAm0EwZevCACgg0t4 GhdrRmfAcfgz2W/4x2SHEEI= =hJ2B -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 11:49:44 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CACAF16A4CE for ; Thu, 13 Jan 2005 11:49:44 +0000 (GMT) Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id E570D43D53 for ; Thu, 13 Jan 2005 11:49:41 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 78358 invoked from network); 13 Jan 2005 11:49:40 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 13 Jan 2005 11:49:40 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id j0DBndN6079081; Thu, 13 Jan 2005 12:49:39 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id j0DBndtS079080; Thu, 13 Jan 2005 12:49:39 +0100 (CET) (envelope-from pho) Date: Thu, 13 Jan 2005 12:49:39 +0100 From: Peter Holm To: John Baldwin Message-ID: <20050113114939.GA79046@peter.osted.lan> References: <20050109214454.GA60018@peter.osted.lan> <200501121503.29257.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501121503.29257.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@FreeBSD.org cc: current@FreeBSD.org Subject: Re: panic: proc not held @ fs/procfs/procfs_regs.c:60 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 11:49:44 -0000 On Wed, Jan 12, 2005 at 03:03:29PM -0500, John Baldwin wrote: > On Sunday 09 January 2005 04:44 pm, Peter Holm wrote: > > With GENERIC HEAD from Jan 8 08:45 UTC I got: > > > > panic(c0826351,c0826973,c082fcfc,3,c175a2e0) at panic+0xd8 > > procfs_doprocregs(c175a2e0,c1b1b5e8,c1665d80,0,ce778c90) at > > procfs_doprocregs+0x10a pfs_read(ce778c1c,20000,c1f19e04,c08294ba,845) at > > pfs_read+0x20f > > vn_read(c1b17ae4,ce778c90,c1a9c080,0,c175a2e0) at vn_read+0x1b9 > > dofileread(8,bfbfea50,4c,ffffffff,ffffffff) at dofileread+0x82 > > read(c175a2e0,ce778d14,3,1,282) at read+0x44 > > syscall(2f,2f,2f,8059f48,a7c) at syscall+0x128 > > > > Details at http://www.holm.cc/stress/log/cons105.html > > Hmm, looking at procfs_doprocregs() I'm not sure how it could lose the proc > lock. The assertion must be in one of the PROC_UNLOCK(). Can you do a > listing of the procfs_doprocregs() frame to see where it died? > No, sorry. I seem to have fumbled the backup of the tree before I did an update :-( But isn't the panic in this code: procfs_regs.c, Revision 1.29.2.1 1.24 jhb 59: PROC_LOCK(p); 1.29.2.1! das 60: KASSERT(p->p_lock > 0, ("proc not held")); > -- > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 11:49:44 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CF97116A4CF for ; Thu, 13 Jan 2005 11:49:44 +0000 (GMT) Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id E59E743D55 for ; Thu, 13 Jan 2005 11:49:41 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 78358 invoked from network); 13 Jan 2005 11:49:40 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 13 Jan 2005 11:49:40 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id j0DBndN6079081; Thu, 13 Jan 2005 12:49:39 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id j0DBndtS079080; Thu, 13 Jan 2005 12:49:39 +0100 (CET) (envelope-from pho) Date: Thu, 13 Jan 2005 12:49:39 +0100 From: Peter Holm To: John Baldwin Message-ID: <20050113114939.GA79046@peter.osted.lan> References: <20050109214454.GA60018@peter.osted.lan> <200501121503.29257.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501121503.29257.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@FreeBSD.org cc: current@FreeBSD.org Subject: Re: panic: proc not held @ fs/procfs/procfs_regs.c:60 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 11:49:44 -0000 On Wed, Jan 12, 2005 at 03:03:29PM -0500, John Baldwin wrote: > On Sunday 09 January 2005 04:44 pm, Peter Holm wrote: > > With GENERIC HEAD from Jan 8 08:45 UTC I got: > > > > panic(c0826351,c0826973,c082fcfc,3,c175a2e0) at panic+0xd8 > > procfs_doprocregs(c175a2e0,c1b1b5e8,c1665d80,0,ce778c90) at > > procfs_doprocregs+0x10a pfs_read(ce778c1c,20000,c1f19e04,c08294ba,845) at > > pfs_read+0x20f > > vn_read(c1b17ae4,ce778c90,c1a9c080,0,c175a2e0) at vn_read+0x1b9 > > dofileread(8,bfbfea50,4c,ffffffff,ffffffff) at dofileread+0x82 > > read(c175a2e0,ce778d14,3,1,282) at read+0x44 > > syscall(2f,2f,2f,8059f48,a7c) at syscall+0x128 > > > > Details at http://www.holm.cc/stress/log/cons105.html > > Hmm, looking at procfs_doprocregs() I'm not sure how it could lose the proc > lock. The assertion must be in one of the PROC_UNLOCK(). Can you do a > listing of the procfs_doprocregs() frame to see where it died? > No, sorry. I seem to have fumbled the backup of the tree before I did an update :-( But isn't the panic in this code: procfs_regs.c, Revision 1.29.2.1 1.24 jhb 59: PROC_LOCK(p); 1.29.2.1! das 60: KASSERT(p->p_lock > 0, ("proc not held")); > -- > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve" = http://www.FreeBSD.org -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 11:56:07 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54A0416A4D5 for ; Thu, 13 Jan 2005 11:56:07 +0000 (GMT) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id CD41243D41 for ; Thu, 13 Jan 2005 11:56:06 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 85316 invoked from network); 13 Jan 2005 11:56:05 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 13 Jan 2005 11:56:05 -0000 X-pair-Authenticated: 80.164.63.199 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.1/8.13.1) with ESMTP id j0DBu4qB079148 for ; Thu, 13 Jan 2005 12:56:04 +0100 (CET) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.1/8.13.1/Submit) id j0DBu49o079147 for current@freebsd.org; Thu, 13 Jan 2005 12:56:04 +0100 (CET) (envelope-from pho) Date: Thu, 13 Jan 2005 12:56:04 +0100 From: Peter Holm To: current@freebsd.org Message-ID: <20050113115604.GA79120@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Page fault in kern/kern_sig.c:1582 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 11:56:07 -0000 With GENERIC HEAD from Jan 11 09:07 UTC and syscall() stress testing I got this page fault: Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0xcf75bc78 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0614dbb stack pointer = 0x10:0xcf301cbc frame pointer = 0x10:0xcf301cd0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 35328 (syscall) [thread pid 35328 tid 100197 ] Stopped at psignal+0x97: testl %eax,0(%esi,%edx,4) db> where Tracing pid 35328 tid 100197 td 0xc1c87a10 psignal(c1e283f0,1,0,c1c87a10,c1ece9d8) at psignal+0x97 kill(c1c87a10,cf301d14,2,0,292) at kill+0xd8 syscall(2f,2f,2f,2804f6c0,bfbfeaa4) at syscall+0x128 (kgdb) l *0xc0614dbb 0xc0614dbb is in psignal (../../../kern/kern_sig.c:1582). 1577 * way to deliver signal. 1578 */ 1579 signal_td = NULL; 1580 mtx_lock_spin(&sched_lock); 1581 FOREACH_THREAD_IN_PROC(p, td) { 1582 if (td->td_waitset != NULL && 1583 SIGISMEMBER(*(td->td_waitset), sig)) { 1584 mtx_unlock_spin(&sched_lock); 1585 return (td); 1586 } More info at http://www.holm.cc/stress/log/cons106.html -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 12:15:07 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16DA716A4CE for ; Thu, 13 Jan 2005 12:15:07 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DE3C43D2D for ; Thu, 13 Jan 2005 12:15:04 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j0DCF3RC059187 for ; Thu, 13 Jan 2005 13:15:03 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org From: Poul-Henning Kamp Date: Thu, 13 Jan 2005 13:15:03 +0100 Message-ID: <59186.1105618503@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: Top 50 kernel files with 'issues' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 12:15:07 -0000 I mused for a second about the number of ecks-ecks-ecks (thankyou spamfilters!) comments in kern/vfs_subr.c and on a whim I did a script to find the to 50 kernel files with 'issues'. In total we have 7107 such comments in the kernel... Happy hacking :-) 77 ./netipsec/key.c 73 ./netkey/key.c 54 ./net80211/ieee80211_ioctl.c 54 ./dev/ath/if_ath.c 48 ./netinet6/ip6_output.c 46 ./net80211/ieee80211_input.c 45 ./netinet6/icmp6.c 45 ./dev/ray/if_ray.c 42 ./compat/linprocfs/linprocfs.c 41 ./netinet6/nd6.c 40 ./netgraph/bluetooth/socket/ng_btsocket_rfcomm.c 37 ./netinet6/ipsec.c 37 ./kern/tty.c 34 ./net80211/ieee80211_node.c 32 ./dev/syscons/syscons.c 31 ./netinet6/nd6_rtr.c 31 ./netinet6/in6.c 31 ./dev/wi/if_wi.c 31 ./dev/firewire/sbp_targ.c 30 ./dev/fb/vga.c 29 ./pc98/pc98/sio.c 27 ./netgraph/ng_sample.c 27 ./dev/firewire/sbp.c 25 ./netinet/ip_mroute.c 25 ./net/if_spppsubr.c 25 ./i386/i386/machdep.c 25 ./dev/usb/ehci.c 25 ./dev/sio/sio.c 24 ./pc98/i386/machdep.c 24 ./dev/usb/ohci.c 23 ./netinet6/ip6_input.c 23 ./isa/psm.c 23 ./dev/ciss/ciss.c 23 ./alpha/alpha/machdep.c 23 ./alpha/alpha/clock.c 22 ./dev/sound/usb/uaudio.c 22 ./dev/musycc/musycc.c 22 ./contrib/pf/net/pf_ioctl.c 21 ./nfs4client/nfs4_vnops.c 21 ./netgraph/ng_base.c 21 ./net80211/ieee80211_output.c 21 ./kern/vfs_subr.c 21 ./dev/mly/mly.c 21 ./dev/ar/if_ar.c 20 ./netinet6/in6_src.c 20 ./netgraph/bluetooth/drivers/h4/ng_h4.c 20 ./compat/svr4/svr4_misc.c 20 ./alpha/osf1/osf1_ioctl.c 19 ./netinet/ip_input.c 19 ./i386/i386/support.s -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 14:00:16 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 787DC16A4CE for ; Thu, 13 Jan 2005 14:00:16 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E05E943D48 for ; Thu, 13 Jan 2005 14:00:15 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1Cp5WG-000NzE-Rg; Thu, 13 Jan 2005 16:00:12 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: freebsd-current@freebsd.org In-Reply-To: Message from Danny Braniss <20050113100714.EA6CB43D49@mx1.FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 13 Jan 2005 16:00:12 +0200 From: Danny Braniss Message-Id: <20050113140015.E05E943D48@mx1.FreeBSD.org> Subject: Re: propagate_priority panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 14:00:16 -0000 > > Not sure if anyone else is seeing this, but I'm pretty sure the following= > > =20 > > commit broke my system. When mysql tries to shutdown I get a panic in=20 > > propagate_priority. As well as X freezing when I go to start it. Actually= > > =20 > > one of the applictions or the WM causes it to freeze, but same problem I=20 > > think but I can't see the console. Before this everything worked fine. I= > > =20 > > can post the hand transcribed panic backtrace message tomorrow if anyone=20 > > is interested since I don't have a serial port on the machine. > > I'm using the 4BSD scheduler with the latest -CURRENT. > > > > jhb 2004-12-30 20:52:44 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/kern sched_4bsd.c sched_ule.c subr_turnstile.c=20 > > sys/sys proc.h sched.h turnstile.h=20 > > =20 > > Revision Changes Path > > 1.71 +102 -14 src/sys/kern/sched_4bsd.c > > 1.144 +77 -20 src/sys/kern/sched_ule.c > > 1.151 +120 -71 src/sys/kern/subr_turnstile.c > > 1.415 +1 -0 src/sys/sys/proc.h > > 1.23 +2 -0 src/sys/sys/sched.h > > 1.6 +1 -0 src/sys/sys/turnstile.h > > =2D-=20 > > Anish Mistry > > in my case it's probably more my fault, since it happens in a driver-module > that im writing - though i'm begining to think otherwise. Adding > debug printfs fixes the panics, which most probably means some > timing problem. The code is experimental, but if someone would like to > take a look, i've placed it, together with the panic in: > ftp://ftp.cs.huji.ac.il/users/danny/freebsd/panic/ > ok, problem solved. I had a kernel thread that exited, while a socket was being closed. before: while(sp->flags & ISC_RUN) sbwait(&so->so_rcv); kthread_exit(0); now: while(so->so_state & SS_ISCONNECTED) sbwait(&so->so_rcv); kthread_exit(0); From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 14:12:43 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3FA116A4CE for ; Thu, 13 Jan 2005 14:12:43 +0000 (GMT) Received: from vbook.fbsd.ru (asplinux.ru [195.133.213.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 577FE43D4C for ; Thu, 13 Jan 2005 14:12:43 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.43 (FreeBSD)) id 1Cp5iA-0007sN-B1; Thu, 13 Jan 2005 17:12:30 +0300 From: Vladimir Grebenschikov To: Daniel O'Connor In-Reply-To: <200412241756.56900.doconnor@gsoft.com.au> References: <20041224010759.N1763@april.chuckr.org> <200412241756.56900.doconnor@gsoft.com.au> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Thu, 13 Jan 2005 17:12:29 +0300 Message-Id: <1105625549.942.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: Chuck Robey cc: freebsd-current@freebsd.org Subject: Re: fingerprints 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: Thu, 13 Jan 2005 14:12:44 -0000 =F7 =D0=D4, 24/12/2004 =D7 17:56 +1030, Daniel O'Connor =D0=C9=DB=C5=D4: > On Fri, 24 Dec 2004 16:41, Chuck Robey wrote: > > Has there been any work on getting fingerprint readers working on FreeB= SD? > > I *really* disilked the fact that (apparently) the only fingerprint > > reader is supplied via Microsoft, but beyond that, it's a USB device, > > which ought to mean, a simple implementation. I guess I have to read h= ow >=20 > Ahaha.. > Ahem, sorry.. USB !=3D simple. >=20 > > USB works, but before I give too much time to it, I wanted to ask if > > anyone has done anything yet. >=20 > Ask the maker for specs on how to talk to it.. http://biomark.org.ru/en/software/pam_bfp.html (there was message about it in freebsd-security@ list ) --=20 Vladimir B. Grebenchikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Wed Jan 12 18:13:54 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C471816A4CE for ; Wed, 12 Jan 2005 18:13:54 +0000 (GMT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 11EF143D3F for ; Wed, 12 Jan 2005 18:13:51 +0000 (GMT) (envelope-from michael.class@gmx.de) Received: (qmail invoked by alias); 12 Jan 2005 18:13:46 -0000 Received: from p54A0F1F9.dip.t-dialin.net (EHLO sv-micha.mc.hp.com) (84.160.241.249) by mail.gmx.net (mp009) with SMTP; 12 Jan 2005 19:13:46 +0100 X-Authenticated: #442072 Received: from [172.16.81.200] (michaelc@pc-micha.mc.hp.com [172.16.81.200]) (authenticated bits=0) by sv-micha.mc.hp.com (8.13.1/8.13.1) with ESMTP id j0CIDeMj000970 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 12 Jan 2005 18:13:45 GMT (envelope-from michael.class@gmx.de) Message-ID: <41E568CE.9030905@gmx.de> Date: Wed, 12 Jan 2005 19:13:34 +0100 From: Michael Class User-Agent: Mozilla Thunderbird 1.0 (X11/20041229) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: multipart/mixed; boundary="------------030705060303020702090105" X-Y-GMX-Trusted: 0 X-Mailman-Approved-At: Thu, 13 Jan 2005 14:22:38 +0000 Subject: SIL3112 and Maxtor 6Y160M0 SATA Disk: DMA Failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2005 18:13:54 -0000 This is a multi-part message in MIME format. --------------030705060303020702090105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello, recently I have added a cheap SIL3112 SATA controller in my system. Unfortunately when I do attach my Maxtor SATA disk to this controller I do only get DMA errors. This is all on a recent 6.0-CURRENT system and can be reproduced with a GENERIC kernel. I have tried with and without ACPI while still getting the same results. Attached to this mail is the output of a "boot -v" of this system. Anything I could do to track this further down? Thank you for your help Michael ------------------------------------------------------------------------- michael class E-Mail: michael.class@gmx.de ------------------------------------------------------------------------- --------------030705060303020702090105 Content-Type: text/plain; name="GENERIC.out" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="GENERIC.out" Copyright (c) 1992-2005 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 #0: Sat Jan 8 22:23:09 MET 2005 root@sv-micha.mc.hp.com:/usr/src/sys/i386/compile/GENERIC WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "/boot/kernel.GENERIC/kernel" at 0xc0a88000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a881a0. Calibrating clock(s) ... i8254 clock: 1193228 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 996551298 Hz CPU: Intel Pentium III (996.55-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x383fbff real memory = 1073676288 (1023 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c28000 - 0x000000003edbffff, 1041858560 bytes (254360 pages) avail memory = 1041924096 (993 MB) MP Configuration Table version 1.1 found at 0xc00f59a0 Table 'FACP' at 0x3fff0030 Table 'APIC' at 0x3fff00b0 MADT: Found table at 0x3fff00b0 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 1: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 2: enabled SMP: Added CPU 1 (AP) ACPI APIC Table: APIC ID: physical 0, logical 0:0 APIC ID: physical 1, logical 0:1 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 bios32: Found BIOS32 Service Directory header at 0xc00fdad0 bios32: Entry = 0xfdae0 (c00fdae0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xdb01 pnpbios: Found PnP BIOS data at 0xc00f6e40 pnpbios: Entry = f0000:5c04 Rev = 1.0 Other BIOS signatures found: APIC: CPU 0 has ACPI ID 1 APIC: CPU 1 has ACPI ID 2 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: 0x00040011 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x00010000 therm: 0x00000000 err: 0x0001000f pcm: 0x00010000 wlan: <802.11 Link Layer> random: nfslock: pseudo-device 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 0x80010014 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=06911106) pcibios: BIOS version 2.10 Found $PIR table, 8 entries at 0xc00f7530 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs 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 7 A 0xfe 14 embedded 0 7 B 0xff 15 embedded 0 7 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 7 D 0x05 3 4 5 7 9 10 11 12 14 15 slot 1 0 9 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 1 0 9 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 1 0 9 C 0x05 3 4 5 7 9 10 11 12 14 15 slot 1 0 9 D 0x01 3 4 5 7 9 10 11 12 14 15 slot 2 0 10 A 0x03 3 4 5 7 9 10 11 12 14 15 slot 2 0 10 B 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 10 C 0x01 3 4 5 7 9 10 11 12 14 15 slot 2 0 10 D 0x02 3 4 5 7 9 10 11 12 14 15 slot 3 0 11 A 0x05 3 4 5 7 9 10 11 12 14 15 slot 3 0 11 B 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 11 C 0x02 3 4 5 7 9 10 11 12 14 15 slot 3 0 11 D 0x03 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 A 0x01 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 B 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 C 0x03 3 4 5 7 9 10 11 12 14 15 slot 4 0 12 D 0x05 3 4 5 7 9 10 11 12 14 15 slot 5 0 13 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 5 0 13 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 13 C 0x05 3 4 5 7 9 10 11 12 14 15 slot 5 0 13 D 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 14 A 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 14 B 0x05 3 4 5 7 9 10 11 12 14 15 embedded 0 14 C 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 14 D 0x02 3 4 5 7 9 10 11 12 14 15 AcpiOsDerivePciId: bus 0 dev 7 func 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi0: Power Button (fixed) AcpiOsDerivePciId: bus 0 dev 0 func 0 AcpiOsDerivePciId: bus 0 dev 7 func 0 ACPI timer: 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci_link0: irq 10 on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 3 4 5 6 7 10 11 12 14 15 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 3 4 5 6 7 10 11 12 14 15 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: irq 9 on acpi0 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 9 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 9 N 0 3 4 5 6 7 10 11 12 14 15 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci0: on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base e0000000, size 26, enabled found-> vendor=0x1106, dev=0x0691, revid=0xc4 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2210, cachelnsz=0 (dwords) lattimer=0x10 (480 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0x8598, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0007, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) found-> vendor=0x1106, dev=0x0686, revid=0x40 bus=0, slot=7, 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 0000ffa0, size 4, enabled found-> vendor=0x1106, dev=0x0571, revid=0x06 bus=0, slot=7, 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) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000c400, size 5, enabled pcib0: matched entry for 0.7.INTD (src \\_SB_.LNKD:0) pcib0: slot 7 INTD routed to irq 9 via \\_SB_.LNKD found-> vendor=0x1106, dev=0x3038, revid=0x1a bus=0, slot=7, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=9 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000c800, size 5, enabled pcib0: matched entry for 0.7.INTD (src \\_SB_.LNKD:0) pcib0: slot 7 INTD routed to irq 9 via \\_SB_.LNKD found-> vendor=0x1106, dev=0x3038, revid=0x1a bus=0, slot=7, func=3 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=9 powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0x3057, revid=0x40 bus=0, slot=7, func=4 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000d400, size 8, enabled map[14]: type 4, range 32, base 0000d000, size 2, enabled map[18]: type 4, range 32, base 0000cc00, size 2, enabled pcib0: matched entry for 0.7.INTC (src \\_SB_.LNKC:0) ioapic0: Changing trigger for pin 10 to level ioapic0: Changing polarity for pin 10 to low pcib0: slot 7 INTC routed to irq 10 via \\_SB_.LNKC found-> vendor=0x1106, dev=0x3058, revid=0x50 bus=0, slot=7, 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 D3 current D0 map[10]: type 1, range 32, base dffc0000, size 17, enabled map[14]: type 1, range 32, base dffa0000, size 17, enabled map[18]: type 4, range 32, base 0000c000, size 6, enabled pcib0: matched entry for 0.9.INTA pcib0: slot 9 INTA hardwired to IRQ 17 found-> vendor=0x8086, dev=0x1076, revid=0x00 bus=0, slot=9, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0230, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=17 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 4, range 32, base 0000d800, size 8, enabled map[14]: type 1, range 32, base dfffff00, size 8, enabled pcib0: matched entry for 0.10.INTA pcib0: slot 10 INTA hardwired to IRQ 18 found-> vendor=0x1000, dev=0x0001, revid=0x01 bus=0, slot=10, func=0 class=00-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=18 map[10]: type 3, range 32, base d8000000, size 26, enabled pcib0: matched entry for 0.11.INTA pcib0: slot 11 INTA hardwired to IRQ 19 found-> vendor=0x4444, dev=0x0803, revid=0x01 bus=0, slot=11, func=0 class=04-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0116, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x80 (32000 ns), maxlat=0x08 (2000 ns) intpin=a, irq=19 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base dfffd000, size 12, enabled pcib0: matched entry for 0.12.INTA pcib0: slot 12 INTA hardwired to IRQ 16 found-> vendor=0x1033, dev=0x0035, revid=0x41 bus=0, slot=12, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0116, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base dfffe000, size 12, enabled pcib0: matched entry for 0.12.INTB pcib0: slot 12 INTB hardwired to IRQ 17 found-> vendor=0x1033, dev=0x0035, revid=0x41 bus=0, slot=12, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0116, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=17 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base dffffe00, size 8, enabled pcib0: matched entry for 0.12.INTC pcib0: slot 12 INTC hardwired to IRQ 18 found-> vendor=0x1033, dev=0x00e0, revid=0x02 bus=0, slot=12, func=2 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0116, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=18 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000bc00, size 3, enabled map[14]: type 4, range 32, base 0000b800, size 2, enabled map[18]: type 4, range 32, base 0000b400, size 3, enabled map[1c]: type 4, range 32, base 0000b000, size 2, enabled map[20]: type 4, range 32, base 0000ac00, size 4, enabled map[24]: type 1, range 32, base dffffc00, size 9, enabled pcib0: matched entry for 0.13.INTA pcib0: slot 13 INTA hardwired to IRQ 17 found-> vendor=0x1095, dev=0x3112, revid=0x02 bus=0, slot=13, func=0 class=01-04-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=17 powerspec 2 supports D0 D1 D2 D3 current D0 agp0: mem 0xe0000000-0xe3ffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xe0000000 agp0: allocating GATT for aperture of size 256M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x5000-0x6fff pcib1: memory decode 0xdfd00000-0xdfdfffff pcib1: prefetched decode 0xb7b00000-0xd7bfffff pci1: on pcib1 pci1: physical bus=1 map[10]: type 3, range 32, base c8000000, size 27, enabled pcib1: device (null) requested decoded memory range 0xc8000000-0xcfffffff map[14]: type 4, range 32, base 00006800, size 8, enabled pcib1: device (null) requested decoded I/O range 0x6800-0x68ff map[18]: type 1, range 32, base dfdf0000, size 16, enabled pcib1: device (null) requested decoded memory range 0xdfdf0000-0xdfdfffff 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=0x1002, dev=0x5961, revid=0x01 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0107, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=16 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base c0000000, size 27, enabled pcib1: device (null) requested decoded memory range 0xc0000000-0xc7ffffff map[14]: type 1, range 32, base dfde0000, size 16, enabled pcib1: device (null) requested decoded memory range 0xdfde0000-0xdfdeffff found-> vendor=0x1002, dev=0x5941, revid=0x01 bus=1, slot=0, func=1 class=03-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D1 D2 D3 current D0 pci1: at device 0.0 (no driver attached) pci1: at device 0.1 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 ata0: channel #0 on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=50 ata0-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0-slave: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=50 devices=0x3 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=00 ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb ata1-slave: stat=0x00 err=0x00 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ata1: [MPSAFE] uhci0: port 0xc400-0xc41f irq 9 at device 7.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc400 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 ulpt0: Hewlett-Packard DeskJet 990C, rev 1.10/1.00, addr 2, iclass 7/1 ulpt0: using bi-directional mode uhci1: port 0xc800-0xc81f irq 9 at device 7.3 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xc800 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 pci0: at device 7.4 (no driver attached) pci0:7:4: Transition from D0 to D3 pci0: at device 7.5 (no driver attached) pci0:7:5: Transition from D0 to D3 em0: port 0xc000-0xc03f mem 0xdffa0000-0xdffbffff,0xdffc0000-0xdffdffff irq 17 at device 9.0 on pci0 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xdffc0000 em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0xc000 em0: [MPSAFE] em0: bpf attached em0: Ethernet address: 00:0e:0c:2e:81:1c em0: Speed:N/A Duplex:N/A sym0: <810> port 0xd800-0xd8ff mem 0xdfffff00-0xdfffffff irq 18 at device 10.0 on pci0 sym0: Reserved 0x100 bytes for rid 0x14 type 3 at 0xdfffff00 sym0: No NVRAM, ID 7, Fast-10, SE, parity checking sym0: open drain IRQ line driver sym0: using NCR-generic firmware. sym0: [GIANT-LOCKED] pci0: at device 11.0 (no driver attached) pci0:11:0: Transition from D0 to D3 ohci0: mem 0xdfffd000-0xdfffdfff irq 16 at device 12.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xdfffd000 ohci0: [GIANT-LOCKED] usb2: OHCI version 1.0 usb2: on ohci0 usb2: USB revision 1.0 uhub2: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 1 port with 1 removable, self powered ohci1: mem 0xdfffe000-0xdfffefff irq 17 at device 12.1 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xdfffe000 ohci1: [GIANT-LOCKED] usb3: OHCI version 1.0 usb3: on ohci1 usb3: USB revision 1.0 uhub3: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 1 port with 1 removable, self powered pci0: at device 12.2 (no driver attached) pci0:12:2: Transition from D0 to D3 atapci1: port 0xac00-0xac0f,0xb000-0xb003,0xb400-0xb407,0xb800-0xb803,0xbc00-0xbc07 mem 0xdffffc00-0xdffffdff irq 17 at device 13.0 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xac00 atapci1: [MPSAFE] atapci1: Reserved 0x200 bytes for rid 0x24 type 3 at 0xdffffc00 ata2: channel #0 on atapci1 ata2: reset tp1 mask=01 ostat0=50 ostat1=00 ata2-master: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: [MPSAFE] ata3: channel #1 on atapci1 ata3: reset tp1 mask=01 ostat0=7f ostat1=00 ata3-master: stat=0xff err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0xff err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0xff err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0xff err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0xff err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0xff err=0x00 lsb=0x00 msb=0x00 ata3-master: stat=0xff err=0x00 lsb=0x00 msb=0x00 ata3: reset tp2 stat0=ff stat1=00 devices=0x0 ata3: [MPSAFE] pci_link2: irq 11 on acpi0 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 14 15 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 14 15 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: irq 5 on acpi0 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 5 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 5 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 acpi_button1: on acpi0 acpi_tz0: on acpi0 psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0065 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model MouseMan+, device ID 0-38, 3 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:08, syncbits:00 fdc0: port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: irq maps: 0xc001 0xc011 0xc001 0xc001 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: irq maps: 0xc001 0xc009 0xc001 0xc001 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A 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/8 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 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 pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete 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 10: ioport 0xac00 alloc failed ahc_isa_probe 11: ioport 0xbc00 alloc failed ahc_isa_probe 12: ioport 0xcc00 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 orm0: at iomem 0xd0800-0xd4fff,0xcd000-0xd07ff,0xc0000-0xccfff 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 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered Timecounter "TSC" frequency 996551298 Hz quality -100 Timecounters tick every 1.000 msec lo0: bpf attached ata0-slave: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata0-master: pio=0x0c wdma=0x22 udma=0x45 cable=80pin ata0-master: setting PIO4 on VIA 82C686B chip ata0-master: setting UDMA100 on VIA 82C686B chip ata0-slave: setting PIO4 on VIA 82C686B chip ata0-slave: setting UDMA100 on VIA 82C686B chip ad0: ATA-6 disk at ata0-master ad0: 176700MB (361882080 sectors), 359010 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA100 ar: FreeBSD check1 failed ad1: ATA-5 disk at ata0-slave ad1: 43979MB (90069840 sectors), 89355 C, 16 H, 63 S, 512 B ad1: 16 secs/int, 1 depth queue, UDMA100 ar: FreeBSD check1 failed ata1-master: pio=0x0c wdma=0x22 udma=0x42 cable=80pin ata1-master: setting PIO4 on VIA 82C686B chip ata1-master: setting UDMA33 on VIA 82C686B chip acd0: DVDR drive at ata1 as master acd0: read 5512KB/s (5512KB/s) write 4134KB/s (4134KB/s), 8192KB 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 em0: Link is up 1000 Mbps Full Duplex ata2-master: pio=0x0c wdma=0x22 udma=0x46 cable=40pin ad4: ATA-7 disk at ata2-master ad4: 156334MB (320173056 sectors), 317632 C, 16 H, 63 S, 512 B ad4: 16 secs/int, 1 depth queue, SATA150 ar: LSI check1 failed Waiting 5 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. GEOM: new disk ad0 GEOM: new disk ad1 GEOM: new disk ad4 ad4: TIMEOUT - READ_DMA retrying (2 retries left) LBA=0 ata2: reiniting channel .. (probe3:sym0:0:3:0): error 22 (probe3:sym0:0:3:0): Unretryable Error pass0 at sym0 bus 0 target 3 lun 0 pass0: Removable CD-ROM SCSI-2 device pass0: 10.000MB/s transfers (10.000MHz, offset 8) SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00040011 LDR: 0x02000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x00010000 therm: 0x00000000 err: 0x00010000 pcm: 0x00010000 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 12 (ISA IRQ 12) to cluster 0 ioapic0: routing intpin 13 (ISA IRQ 13) to cluster 0 ioapic0: routing intpin 14 (ISA IRQ 14) to cluster 0 ioapic0: routing intpin 15 (ISA IRQ 15) to cluster 0 ioapic0: routing intpin 16 (PCI IRQ 16) to cluster 0 ioapic0: routing intpin 17 (PCI IRQ 17) to cluster 0 ioapic0: routing intpin 18 (PCI IRQ 18) to cluster 0 (cd0:sym0:0:3:0): error 6 (cd0:sym0:0:3:0): Unretryable Error cd0 at sym0 bus 0 target 3 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 8) cd0: Attempt to query device size failed: NOT READY, Medium not present ata2: reset tp1 mask=01 ostat0=50 ostat1=00 ad4: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: resetting done .. ad4: pio=0x0c wdma=0x22 udma=0x46 cable=40pin ata2: device config done .. ad4: TIMEOUT - READ_DMA retrying (1 retry left) LBA=0 ata2: reiniting channel .. ata2: reset tp1 mask=01 ostat0=50 ostat1=00 ad4: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: resetting done .. ad4: pio=0x0c wdma=0x22 udma=0x46 cable=40pin ata2: device config done .. ata2: reiniting channel .. ata2: reset tp1 mask=01 ostat0=50 ostat1=00 ad4: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: resetting done .. ad4: pio=0x0c wdma=0x22 udma=0x46 cable=40pin ata2: device config done .. ad4: FAILURE - READ_DMA timed out ad4: FAILURE - READ_DMA status=51 error=4 LBA=0 GEOM: new disk cd0 (cd0:sym0:0:3:0): error 6 (cd0:sym0:0:3:0): Unretryable Error (cd0:sym0:0:3:0): error 6 (cd0:sym0:0:3:0): Unretryable Error (cd0:sym0:0:3:0): error 6 (cd0:sym0:0:3:0): Unretryable Error Trying to mount root from ufs:/dev/ad1s1a start_init: trying /sbin/init (cd0:sym0:0:3:0): error 6 (cd0:sym0:0:3:0): Unretryable Error GEOM_VINUM: subdisk space.p0.s1 is up GEOM_VINUM: subdisk space.p0.s0 is up (cd0:sym0:0:3:0): error 6 (cd0:sym0:0:3:0): Unretryable Error --------------030705060303020702090105-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 16:23:32 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BE9716A4CE; Thu, 13 Jan 2005 16:23:32 +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 5BC0943D60; Thu, 13 Jan 2005 16:23:31 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.0.5] (adsl-69-208-54-135.dsl.wotnoh.ameritech.net [69.208.54.135]) (authenticated bits=0)j0DFxFWp058677 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 13 Jan 2005 10:59:16 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-current@freebsd.org Date: Thu, 13 Jan 2005 11:27:03 -0500 User-Agent: KMail/1.7 References: <200501130111.04893.mistry.7@osu.edu> In-Reply-To: <200501130111.04893.mistry.7@osu.edu> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2171260.UK9NqQR2DK"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501131127.10811.mistry.7@osu.edu> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on crumpet.united-ware.com Subject: Re: propagate_priority panic [backtrace] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 16:23:32 -0000 --nextPart2171260.UK9NqQR2DK Content-Type: multipart/mixed; boundary="Boundary-01=_XFq5ByzsIMXoSvA" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_XFq5ByzsIMXoSvA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 13 January 2005 01:10 am, Anish Mistry wrote: > Not sure if anyone else is seeing this, but I'm pretty sure the following > commit broke my system. When mysql tries to shutdown I get a panic in > propagate_priority. As well as X freezing when I go to start it. Actually > one of the applictions or the WM causes it to freeze, but same problem I > think but I can't see the console. Before this everything worked fine. I > can post the hand transcribed panic backtrace message tomorrow if anyone > is interested since I don't have a serial port on the machine. > I'm using the 4BSD scheduler with the latest -CURRENT. > > jhb 2004-12-30 20:52:44 UTC > > FreeBSD src repository > > Modified files: > sys/kern sched_4bsd.c sched_ule.c subr_turnstile.c > sys/sys proc.h sched.h turnstile.h > > Revision Changes Path > 1.71 +102 -14 src/sys/kern/sched_4bsd.c > 1.144 +77 -20 src/sys/kern/sched_ule.c > 1.151 +120 -71 src/sys/kern/subr_turnstile.c > 1.415 +1 -0 src/sys/sys/proc.h > 1.23 +2 -0 src/sys/sys/sched.h > 1.6 +1 -0 src/sys/sys/turnstile.h Dmesg and kernel config attached. Ok, here is the panic and backtrace: kernel trap 12 with interrupts disabled =46atal trap 12: page fault while in kernel mode fault virtual address =3D 0x4 fault code =3D supervisor read, page not present instruction pointer =3D 0x8:0xc04d5a4f stack pointer =3D 0x10:0xcc53bbdc frame pointer =3D 0x10:0xcc53bbec code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, def32 1, gran 1 processor eflags =3D resume, IOPL =3D 0 current process =3D 628 (mysqld) [thread pid 628 tid 100085 ] Stopped at propagate_priority+0x153: pushl 0x4(%eax) db> tr Tracing pid 628 tid 100085 td 0xc14e4730 propagate_priority(c0645cb4,c0645cb0,c15ac650,c14e4730,c14e4730) at=20 propagate_priority+0x153 turnstile_wait(c15as650,c15ac650,2,c05f401e,21e) at turnstile_wait+0x1ae _mtx_lock_sleep(c15ac650,c14e4730,0,c05f8604,206) at _mtx_lock_sleep+0x85 _mtx_lock_flags(c15ac650,0,c05f8604,206,c15ac650) at _mtx_lock_flags+0x50 sleepq_calc_signal_retval(0,0,100,ci4e4730,8476f4c) at=20 sleep_calc_signal_retval+0x2b msleep(c10bb334,c15ac650,168,c05f399a,402) at msleep+0x3eb kse_release(c14e4730,cc53bd14,1,12,296) at kse_release+0x186 syscall(2f,2f,2f,8472000,0) at syscall+0x128 Xint-x80_syscall() at Xint0x80_syscall+0x1f =2D-- syscall (383, FreeBSD ELF32, kse_release), eip =3D 0x285851eb, esp = =3D=20 0x8476f28, ebp =3D 0x8476f64 =2D-=20 Anish Mistry --Boundary-01=_XFq5ByzsIMXoSvA Content-Type: text/plain; charset="iso-8859-1"; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg.txt" 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 #22: Wed Jan 12 19:52:52 EST 2005 amistry@littleguy.am-productions.biz:/usr/obj/usr/src/sys/LITTLEGUY Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Transmeta(tm) Crusoe(tm) Processor TM5800 (859.34-MHz 586-class CPU) Origin = "GenuineTMx86" Id = 0x543 Stepping = 3 Features=0x84893f real memory = 251527168 (239 MB) avail memory = 240914432 (229 MB) Crusoe LongRun support enabled, current mode: 2 <867MHz 1300mV 100%> npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) acpi_ec0: port 0x66,0x62 on acpi0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xff08-0xff0b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci_link0: irq 11 on acpi0 pci_link1: irq 9 on acpi0 pci_link2: irq 9 on acpi0 pci_link3: irq 9 on acpi0 pci_link4: irq 9 on acpi0 pci_link5: irq 9 on acpi0 pci_link6: on acpi0 pci_link7: on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) ohci0: mem 0xfc004000-0xfc004fff irq 11 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pcm0: port 0x1000-0x10ff mem 0xfc005000-0xfc005fff irq 9 at device 4.0 on pci0 pcm0: pcm0: [GIANT-LOCKED] pci0: at device 6.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at device 12.0 (no driver attached) atapci0: port 0x1800-0x180f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.0 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 rl0: port 0x8000-0x80ff mem 0xfc007800-0xfc0078ff irq 9 at device 16.0 on pci0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:e0:00:ae:45:08 fwohci0: mem 0xfc000000-0xfc003fff,0xfc007000-0xfc0077ff irq 9 at device 19.0 on pci0 fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:0e:10:00:b0:29:d0 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci0: at device 20.0 (no driver attached) acpi_button0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 acpi_lid0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: flags 0x3000 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 pci_link8: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xd0000-0xd0fff,0xc0000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 859335275 Hz quality 800 Timecounters tick every 0.976 msec cpu0: set speed to 100.0% acpi_cpu: throttling enabled, acpi_acad0: acline initialization startacpi_cmbat0: battery ini8 steps (100% to 12.5%), currently 100.0% acpi_cmbat1: battery initialization start tialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times ad0: 19077MB [38760/16/63] at ata0-master UDMA66 acpi_cmbat0: battery initialization done, tried 1 times acd0: CDRW at ata1-master PIO4 Trying to mount root from ufs:/dev/ad0s2a WARNING: / was not properly dismounted WARNING: /tmp was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted acpi_cmbat1: battery initialization failed, giving up kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x8:0xc04d5a4f stack pointer = 0x10:0xcc53bbdc frame pointer = 0x10:0xcc53bbec code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 628 (mysqld) 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 #22: Wed Jan 12 19:52:52 EST 2005 amistry@littleguy.am-productions.biz:/usr/obj/usr/src/sys/LITTLEGUY Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Transmeta(tm) Crusoe(tm) Processor TM5800 (859.34-MHz 586-class CPU) Origin = "GenuineTMx86" Id = 0x543 Stepping = 3 Features=0x84893f real memory = 251527168 (239 MB) avail memory = 240914432 (229 MB) Crusoe LongRun support enabled, current mode: 2 <867MHz 1300mV 100%> npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) acpi_ec0: port 0x66,0x62 on acpi0 Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0xff08-0xff0b on acpi0 cpu0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci_link0: irq 11 on acpi0 pci_link1: irq 9 on acpi0 pci_link2: irq 9 on acpi0 pci_link3: irq 9 on acpi0 pci_link4: irq 9 on acpi0 pci_link5: irq 9 on acpi0 pci_link6: on acpi0 pci_link7: on acpi0 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) ohci0: mem 0xfc004000-0xfc004fff irq 11 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: AcerLabs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pcm0: port 0x1000-0x10ff mem 0xfc005000-0xfc005fff irq 9 at device 4.0 on pci0 pcm0: pcm0: [GIANT-LOCKED] pci0: at device 6.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at device 12.0 (no driver attached) atapci0: port 0x1800-0x180f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.0 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 rl0: port 0x8000-0x80ff mem 0xfc007800-0xfc0078ff irq 9 at device 16.0 on pci0 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:e0:00:ae:45:08 fwohci0: mem 0xfc000000-0xfc003fff,0xfc007000-0xfc0077ff irq 9 at device 19.0 on pci0 fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:0e:10:00:b0:29:d0 fwohci0: Phy 1394a available S400, 1 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci0: at device 20.0 (no driver attached) acpi_button0: on acpi0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_cmbat1: on acpi0 acpi_lid0: on acpi0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: flags 0x3000 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 pci_link8: on acpi0 pmtimer0 on isa0 orm0: at iomem 0xd0000-0xd0fff,0xc0000-0xcffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounter "TSC" frequency 859338652 Hz quality 800 Timecounters tick every 0.976 msec 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_cmbat1: battery initialization start acpi_acad0: acline initialization start acpi_cmbat0: battery initialization done, tried 1 times acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times ad0: 19077MB [38760/16/63] at ata0-master UDMA66 acd0: CDRW at ata1-master PIO4 Trying to mount root from ufs:/dev/ad0s2a WARNING: / was not properly dismounted acpi_cmbat1: battery initialization failed, giving up --Boundary-01=_XFq5ByzsIMXoSvA Content-Type: text/plain; charset="iso-8859-1"; name="LITTLEGUY" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="LITTLEGUY" # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig= =2Dconfig.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files.=20 # If you are in doubt as to the purpose or necessity of a line, check first= =20 # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.369.2.1 2002/12/18 08:11:24 scott= l Exp $ machine i386 cpu I586_CPU ident LITTLEGUY maxusers 0 #To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" #Default places to look for devices. makeoptions DEBUG=3D-g #Build kernel with gdb(1) debug symbols options DDB, KDB, KDB_UNATTENDED options PREEMPTION options FULL_PREEMPTION options INET #InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_ACL #Support for access control lists options UFS_DIRHASH #Improve performance on big directories options MD_ROOT #MD is a potential root device #options NFSCLIENT #Network Filesystem Client #options NFSSERVER #Network Filesystem Server #options NFS_ROOT #NFS usable as root device, requires NFSCLIENT options MSDOSFS #MSDOS Filesystem options NTFS # NT Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem (requires PSEUDOFS) options PSEUDOFS #Pseudo-filesystem framework options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 #Compatible with FreeBSD4 #options SCSI_DELAY=3D15000 #Delay (in ms) before probing SCSI options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING #Posix P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options AHC_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~128k to driver. options AHD_REG_PRETTY_PRINT # Print register bitfields in debug # output. Adds ~215k to driver. options CPU_ENABLE_LONGRUN # Debugging for use in -current options INVARIANTS #Enable calls of extra sanity checking options INVARIANT_SUPPORT #Extra sanity checks of internal structures, req= uired by INVARIANTS #options WITNESS_KDB #options WITNESS_SKIPSPIN #options WITNESS #Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN #Don't run witness on spinlocks for speed #options PCI_ENABLE_IO_MODES #options CPU_SUSP_HLT #options CPU_ENABLE_SSE # To make an SMP kernel, the next two are needed #options SMP # Symmetric MultiProcessor Kernel #options APIC_IO # Symmetric (APIC) I/O device isa device pci # Floppy drives #device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives #options ATA_STATIC_ID #Static device numbering # SCSI peripherals device scbus # SCSI bus (required) device da # Direct Access (disks) #device atapicam device cd device pass # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device vga # VGA video card driver options VESA #device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc options SC_PIXEL_MODE # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor #device agp # support several AGP chipsets # Floating point support - do not disable. device npx # add new scheduler options SCHED_4BSD #options SCHED_ULE # Add suspend/resume support for the i8254. device pmtimer # PCCARD (PCMCIA) support # Pcmcia and cardbus bridge support #device cbb # cardbus (yenta) bridge #device pcic # ExCA ISA and PCI bridges #device pccard # PC Card (16-bit) bus #device cardbus # CardBus (32-bit) bus # Serial (COM) ports #device sio # 8250, 16[45]50 based serial ports # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device rl # RealTek 8129/8139 # Wireless NIC cards #device an # Aironet 4500/4800 802.11 wireless NICs.=20 #device awi # BayStack 660 and others #device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. #device wl # Older non 802.11 Wavelan wireless NIC. # Pseudo devices - the number indicates how many units to allocate. device random # Entropy device device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device #device null # Null and zero devices device ether # Ethernet support #device sl # Kernel SLIP #device ppp # Kernel PPP device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # sound #device pcm # firewire (IEEE 1394) #device firewire # system management bus #device iicbus #device iicbb #device ic #device iic #device iicsmb #device smbus #device smb #device alpm # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter # USB support options USB_DEBUG # USB debugging #device uhci # UHCI PCI->USB interface #device ohci # OHCI PCI->USB interface #device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices #device ugen # Generic #device uhid # "Human Interface Devices" #device ukbd # Keyboard #device ulpt # Printer #device umass # Disks/Mass storage - Requires scbus and da #device ums # Mouse #device urio # Diamond Rio 500 MP3 player #device uscanner # Scanners --Boundary-01=_XFq5ByzsIMXoSvA-- --nextPart2171260.UK9NqQR2DK Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBB5qFexqA5ziudZT0RAkD6AJ9reQdaDOERP/bCd+HFmJKqZ7cgqQCfWxj4 6Vz7HmNtqfCa/EiDqoxW0AU= =MbAK -----END PGP SIGNATURE----- --nextPart2171260.UK9NqQR2DK-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 16:27:55 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 013D016A4CE for ; Thu, 13 Jan 2005 16:27:55 +0000 (GMT) Received: from blake.polstra.com (blake.polstra.com [64.81.189.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7F43F43D46 for ; Thu, 13 Jan 2005 16:27:54 +0000 (GMT) (envelope-from jdp@polstra.com) Received: from strings.polstra.com (dsl081-189-067.sea1.dsl.speakeasy.net [64.81.189.67]) by blake.polstra.com (8.13.1/8.13.1) with ESMTP id j0DGRrto063238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 13 Jan 2005 08:27:54 -0800 (PST) (envelope-from jdp@strings.polstra.com) Received: (from jdp@localhost) by strings.polstra.com (8.13.1/8.13.1/Submit) id j0DGRr27040048 for current@freebsd.org; Thu, 13 Jan 2005 08:27:53 -0800 (PST) (envelope-from jdp) Message-ID: X-Mailer: XFMail 1.5.5 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <59186.1105618503@critter.freebsd.dk> Date: Thu, 13 Jan 2005 08:27:53 -0800 (PST) From: John Polstra To: current@freebsd.org X-Bogosity: No, tests=bogofilter, spamicity=0.102572, version=0.14.5 Subject: RE: Top 50 kernel files with 'issues' X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 16:27:55 -0000 On 13-Jan-2005 Poul-Henning Kamp wrote: > I mused for a second about the number of ecks-ecks-ecks (thankyou > spamfilters!) comments in kern/vfs_subr.c and on a whim I did a > script to find the to 50 kernel files with 'issues'. It's amusing that kern_xxx.c isn't one of them. :-) John From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 17:17:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6AB1716A4D0 for ; Thu, 13 Jan 2005 17:17:10 +0000 (GMT) Received: from omoikane.mb.skyweb.ca (64-42-246-34.mb.skyweb.ca [64.42.246.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBDB443D45 for ; Thu, 13 Jan 2005 17:17:09 +0000 (GMT) (envelope-from mark@skyweb.ca) Received: by omoikane.mb.skyweb.ca (Postfix, from userid 1001) id 8DCB661D98; Thu, 13 Jan 2005 11:17:11 -0600 (CST) From: Mark Johnston To: current@freebsd.org, freebsd-cvs-summary@lists.enderunix.org Date: Thu, 13 Jan 2005 11:17:10 -0600 User-Agent: KMail/1.6.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200501131117.10864.mjohnston@skyweb.ca> Subject: cvs-src summary for January 4-10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 17:17:10 -0000 Sorry for the delay, here it is. FreeBSD cvs-src summary for 2005-01-04 to 2005-01-10 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a regular weekly summary of FreeBSD's cutting-edge development. It is intended to help the FreeBSD community keep up with the fast-paced work going on in FreeBSD-CURRENT by distilling the deluge of data from the CVS mailing list into a (hopefully) easy-to-read newsletter. You can get old summaries, and an HTML version of this one, at http://www.xl0.org/FreeBSD/. An RSS feed is available from http://excel.xl0.org/cgi-bin/rss.py. If you would like to receive the summary without subscribing to current@, send a blank message to freebsd-cvs-summary-subscribe@lists.enderunix.org; thanks to Omer Faruk Sen and EnderUNIX for hosting this list. Please send any comments to Mark Johnston (mark at xl0.org). ============ New Features ============ Improvements to Synaptics touchpad support ------------------------------------------ Philip Paeps (philip) committed patches from Jason Kuri to the psm[1] driver, for PS/2 mice. The patches significantly improve tracking movement at slow speeds and add support for extra buttons and widgets that are often added to touchpads. There are also some new sysctls, under hw.psm.synaptics, that control the specifics of the slow-speed algorithm and the effects of the extra buttons. [1] http://www.freebsd.org/cgi/man.cgi?query=psm&apropos=0&sektion=4&manpath=FreeBSD+6.0-current&format=html Submitted by: Jason Kuri PR: 75725 (http://www.freebsd.org/cgi/query-pr.cgi?pr=75725) http://www.freebsd.org/cgi/mid.cgi?200501101305.j0AD5w3L073495 IPX/SPX runs without Giant lock ------------------------------- Robert Watson (rwatson) made numerous commits to the code supporting IPX/SPX (The low-level protocols used by Novell systems), finishing by removing the requirement for the Giant system lock to be used. He notes that IPX/SPX is not fully safe for Giant-free SMP use, and more work is still required, but in general it can be used without Giant. http://www.freebsd.org/cgi/mid.cgi?200501090534.j095Ybo1042972 =============== Notable Changes =============== wd driver removed ----------------- Warner Losh (imp) removed the wd driver, which was the IDE disk driver before ata[1]. wd was being kept around for compatibility with PC98 (An alternate PC standard designed by NEC and used in Japan). PC98 is now working properly with the ata driver, so wd is no longer needed. [1] http://www.freebsd.org/cgi/man.cgi?query=ata&apropos=0&sektion=4&manpath=FreeBSD+6.0-current&format=html http://www.freebsd.org/cgi/mid.cgi?200501040624.j046OXQp086082 matcd driver removed -------------------- Warner Losh (imp) removed the matcd driver, which supported some old proprietary CD-ROM drives. It was not used in the default build and not working properly. Submitted by: throdes http://www.freebsd.org/cgi/mid.cgi?200501100800.j0A80EXs047489 ================= Discussion Topics ================= Marking unused arguments to main() ---------------------------------- Xin Li (delphij) changed a line of code to use the __unused macro instead of "void" in the arguments to main(), noting that the change had been suggested by Jacques Vidrine (nectar). Maxime Henrion (mux) wondered why that was, and a few other people commented on their preferences. After some discussion and speculation, Jacques explained that he had made the suggestion since __unused is the canonical FreeBSD way to mark unused arguments. http://www.freebsd.org/cgi/mid.cgi?200501042007.j04K7Ch1043130 Tagging licenses contained in source code files ----------------------------------------------- Warner Losh (imp) updated the style[1] manual page to specify that license and copyright statements contained within C source code should be tagged with /*- at the beginning. Some discussion followed about other uses of /*-, like controlling automatic formatting of the comment block. Several people suggested other ways of identifying copyright statements, but they were judged either overly elaborate or unreliable. [1] http://www.freebsd.org/cgi/man.cgi?query=style&apropos=0&sektion=9&manpath=FreeBSD+6.0-current&format=html http://www.freebsd.org/cgi/mid.cgi?200501051916.j05JG1iH029185 ================= Committer Changes ================= Ceri Davies (ceri) is now a src committer, in addition to his existing documentation commit privileges. Murray Stokely (murray) will be his mentor. http://www.freebsd.org/cgi/mid.cgi?200501060745.j067jtDm082624 Stephan Uphoff (ups) is no longer being mentored. http://www.freebsd.org/cgi/mid.cgi?200501071946.j07JkbhR059610 =================== Important Bug Fixes =================== Chance of damage to HD boot sector when booting from media fixed ---------------------------------------------------------------- Peter Edwards (peadar) committed a modified patch from Hans Petter Selasky for the boot manager. This patch fixes a bug where, if the bootloader was run from USB or floppy media, it could overwrite and break the bootloader on the hard drive. Submitted by: Hans Petter Selasky PR: 66248 (http://www.freebsd.org/cgi/query-pr.cgi?pr=66248) http://www.freebsd.org/cgi/mid.cgi?200501092330.j09NUZUs013213 =============== Other Bug Fixes =============== Ralf S. Engelschall (rse) fixed the bsdlabel[1] tool so that it can work with disk devices in subdirectories of /dev. [1] http://www.freebsd.org/cgi/man.cgi?query=bsdlabel&apropos=0&sektion=8&manpath=FreeBSD+6.0-current&format=html http://www.freebsd.org/cgi/mid.cgi?200501071219.j07CJwrM025235 Poul-Henning Kamp (phk) fixed numerous minor bugs in the sis[1] driver, for Ethernet cards based on SiS and National Semiconductor DP83815 chips. These chips are commonly found on motherboards and on some Netgear Ethernet cards. [1] http://www.freebsd.org/cgi/man.cgi?query=sis&apropos=0&sektion=4&manpath=FreeBSD+6.0-current&format=html Julian Elischer (julian) committed a fix from Naoyuki Tai for a bug in usbd[1], which monitors USB devices attaching and detaching. The bug caused usbd to send out only one notification when a hub with multiple devices connected was plugged in. [1] http://www.freebsd.org/cgi/man.cgi?query=usbd&apropos=0&sektion=8&manpath=FreeBSD+6.0-current&format=html Submitted by: Naoyuki Tai PR: 43993 (http://www.freebsd.org/cgi/query-pr.cgi?pr=43993) http://www.freebsd.org/cgi/mid.cgi?200501040645.j046jfSe087032 From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 17:41:59 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3001B16A4CE for ; Thu, 13 Jan 2005 17:41:59 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id EEAC043D45 for ; Thu, 13 Jan 2005 17:41:58 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id E01A872DD4; Thu, 13 Jan 2005 09:41:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id DB5B872DCB; Thu, 13 Jan 2005 09:41:58 -0800 (PST) Date: Thu, 13 Jan 2005 09:41:58 -0800 (PST) From: Doug White To: Matthew Sullivan In-Reply-To: <41E5F22A.6010607@uq.edu.au> Message-ID: <20050113093955.P12838@carver.gumbysoft.com> References: <41E44CD0.1000008@uq.edu.au> <41E5F22A.6010607@uq.edu.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: Fatal Trap 12: Page fault while in kernel mode (racoon/amd64/5.3-RELEASE-p4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 17:41:59 -0000 On Thu, 13 Jan 2005, Matthew Sullivan wrote: > First if this is the incorrect mailing list for these type of posts > please let me know or I'll never be able to post to the correct location... You're in the right spot. > Further to my last I have finally located a null modem cable and got it > installed... A little fiddling later and we have DDB taking over... > > root@desperado:~# racoon Hm, null pointer+offset dereference. Are you using IPSEC or FAST_IPSEC in your kernel? When did you grab the sources last? > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x39 > fault code = supervisor write, page not present > instruction pointer = 0x8:0xffffffff80307a70 > stack pointer = 0x10:0xffffffff94eb4860 > frame pointer = 0x10:0xffffffff94eb4960 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 454 (racoon) > [thread 100081] > Stopped at keydb_newsecasvar+0x100: decl %ecx > > db> where > keydb_newsecasvar() at keydb_newsecasvar+0x100 > raw_usend() at raw_usend+0x60 > key_send() at key_send+0xa > sosend() at sosend+0x626 > kern_sendit() at kern_sendit+0x113 > sendit() at sendit+0x5f > sendto() at sendto+0x4d > syscall() at syscall+0x50c > Xfast_syscall() at Xfast_syscall+0xa8 > --- syscall (133, FreeBSD ELF64, sendto), rip = 0x800a63da8, rsp = > 0x7fffffffec38, rbp = 0x2 --- > db> show reg > cs 0x8 > ss 0x10 > rax 0xffffffff94eb4890 > rcx 0xffffffff94eb493f > rdx 0xffffffff94eb4970 > rbx 0xffffffff80307a6d keydb_newsecasvar+0xfd > rsp 0xffffffff94eb4860 > rbp 0xffffffff94eb4960 > rsi 0x280 > rdi 0xffffff001cce7c00 > r8 0xa0 > r9 0xffffff00151807b0 > r10 0xffffffff80513980 key_usrreqs > r11 0xffffffff94eb4a10 > r12 0x39 > r13 0 > r14 0 > r15 0xffffff00164aa678 > rip 0xffffffff80307a70 keydb_newsecasvar+0x100 > rflags 0x10202 > dr0 0 > dr1 0 > dr2 0 > dr3 0 > dr4 0xffff0ff0 > dr5 0x400 > dr6 0xffff0ff0 > dr7 0x400 > keydb_newsecasvar+0x100: decl %ecx > db> show all procs/m > pid proc uarea uid ppid pgrp flag stat wmesg wchan cmd > 454 ffffff001555e5d0 ffffffff94ec0000 0 453 454 0004002 [CPU 0] > racoon > 453 ffffff001555e2e8 ffffffff94ebf000 0 443 453 0004002 [SLPQ > wait 0xffffff001555e2e8][SLP] bash > 452 ffffff001ccc62e8 ffffffff93cd3000 0 1 1 0004000 [SLPQ > siodcd 0xffffff000096dc00][SLP] getty > 451 ffffff001555e8b8 ffffffff94ec1000 0 1 451 0004002 [SLPQ > ttyin 0xffffff0000956010][SLP] getty > 450 ffffff001ccc6000 ffffffff93cd2000 0 1 450 0004002 [SLPQ > ttyin 0xffffff0000956410][SLP] getty > 449 ffffff001cce32e8 ffffffff93c92000 0 1 449 0004002 [SLPQ > ttyin 0xffffff000096c010][SLP] getty > 448 ffffff00152f98b8 ffffffff94e80000 0 1 448 0004002 [SLPQ > ttyin 0xffffff0000954410][SLP] getty > 447 ffffff001555eba0 ffffffff94ec2000 0 1 447 0004002 [SLPQ > ttyin 0xffffff0000954810][SLP] getty > 446 ffffff00152f92e8 ffffffff94e7e000 0 1 446 0004002 [SLPQ > ttyin 0xffffff000096d410][SLP] getty > 445 ffffff00152f95d0 ffffffff94e7f000 0 1 445 0004002 [SLPQ > ttyin 0xffffff0000971c10][SLP] getty > 444 ffffff00152f9000 ffffffff94e7d000 0 1 444 0004002 [SLPQ > ttyin 0xffffff000096c810][SLP] getty > 443 ffffff001ccc68b8 ffffffff93cd5000 0 1 443 0004102 [SLPQ > wait 0xffffff001ccc68b8][SLP] login > 442 ffffff00152f9ba0 ffffffff94e81000 0 441 53 0004002 [SLPQ > nanslp 0xffffffff8053ba40][SLP] sleep > 441 ffffff001cce35d0 ffffffff93c93000 0 438 53 0000002 [SLPQ > wait 0xffffff001cce35d0][SLP] sh > 439 ffffff001555e000 ffffffff94e82000 0 1 53 0004002 [SLPQ > piperd 0xffffff001722ab40][SLP] logger > 438 ffffff001ccc6ba0 ffffffff93cd6000 0 1 53 0000002 [SLPQ > wait 0xffffff001ccc6ba0][SLP] sh > 403 ffffff00154a1000 ffffffff94ec3000 0 1 403 0000000 [SLPQ > nanslp 0xffffffff8053ba40][SLP] cron > 390 ffffff001cda75d0 ffffffff93c00000 25 1 390 0000100 [SLPQ > pause 0xffffff001cda7640][SLP] sendmail > 386 ffffff001cda7ba0 ffffffff93c02000 0 1 386 0000100 [SLPQ > select 0xffffffff80542030][SLP] sendmail > 380 ffffff001cce38b8 ffffffff93cd0000 0 1 380 0000100 [SLPQ > select 0xffffffff80542030][SLP] sshd > 273 ffffff001cce3ba0 ffffffff93cd1000 0 1 273 0000000 [SLPQ > select 0xffffffff80542030][SLP] syslogd > 253 ffffff001cce3000 ffffffff93c91000 0 1 253 0000000 [SLPQ > select 0xffffffff80542030][SLP] devd > 181 ffffff001cda78b8 ffffffff93c01000 0 1 181 0000000 [SLPQ > pause 0xffffff001cda7928][SLP] adjkerntz > 52 ffffff001ccc65d0 ffffffff93cd4000 0 0 0 0000204 [SLPQ - > 0xffffffff93cacbe4][SLP] schedcpu > 51 ffffff001cda2000 ffffffff93bb8000 0 0 0 0000204 [SLPQ > syncer 0xffffffff8053b720][SLP] syncer > 50 ffffff001cda22e8 ffffffff93bb9000 0 0 0 0000204 [SLPQ > vlruwt 0xffffff001cda22e8][SLP] vnlru > 49 ffffff001cda25d0 ffffffff93bba000 0 0 0 0000204 [SLPQ > psleep 0xffffffff8054295c][SLP] bufdaemon > 48 ffffff001cda28b8 ffffffff93bbb000 0 0 0 000020c [SLPQ > pgzero 0xffffffff80556dd4][SLP] pagezero > 47 ffffff001cda2ba0 ffffffff93bbc000 0 0 0 0000204 [SLPQ > psleep 0xffffffff80556e3c][SLP] vmdaemon > 46 ffffff001cd83000 ffffffff93bbd000 0 0 0 0000204 [SLPQ > psleep 0xffffffff80556dec][SLP] pagedaemon > 45 ffffff001cd832e8 ffffffff93bfa000 0 0 0 0000204 [IWAIT] > swi0: sio > 44 ffffff001cd835d0 ffffffff93bfb000 0 0 0 0000204 [SLPQ - > 0xffffff0000811848][SLP] fdc0 > 43 ffffff001cd838b8 ffffffff93bfc000 0 0 0 0000204 [SLPQ > tzpoll 0xffffffff8052e568][SLP] acpi_thermal > 9 ffffff001cd83ba0 ffffffff93bfd000 0 0 0 0000204 [SLPQ > actask 0xffffffff8052e620][SLP] acpi_task2 > 8 ffffff001cda7000 ffffffff93bfe000 0 0 0 0000204 [SLPQ > actask 0xffffffff8052e620][SLP] acpi_task1 > 7 ffffff001cd92000 ffffffff93b72000 0 0 0 0000204 [SLPQ > actask 0xffffffff8052e620][SLP] acpi_task0 > 42 ffffff001cd922e8 ffffffff93b73000 0 0 0 0000204 [IWAIT] > swi6: task queue > 41 ffffff001cd925d0 ffffffff93b74000 0 0 0 0000204 [IWAIT] > swi6:+ > 6 ffffff001cd928b8 ffffffff93b75000 0 0 0 0000204 [SLPQ - > 0xffffff0000835b80][SLP] thread taskq > 40 ffffff001cd92ba0 ffffffff93b76000 0 0 0 0000204 [IWAIT] > swi6:+ > 5 ffffff001cdb7000 ffffffff93bb3000 0 0 0 0000204 [SLPQ - > 0xffffff0000835d00][SLP] kqueue taskq > 39 ffffff001cdb72e8 ffffffff93bb4000 0 0 0 0000204 [IWAIT] > swi6: acpitaskq > 38 ffffff001cdb75d0 ffffffff93bb5000 0 0 0 0000204 [SLPQ - > 0xffffffff8052eb00][SLP] yarrow > 4 ffffff001cdb78b8 ffffffff93bb6000 0 0 0 0000204 [SLPQ - > 0xffffffff80532988][SLP] g_down > 3 ffffff001cdb7ba0 ffffffff93bb7000 0 0 0 0000204 [SLPQ - > 0xffffffff80532980][SLP] g_up > 2 ffffff001cd8e2e8 ffffffff93b2d000 0 0 0 0000204 [SLPQ - > 0xffffffff80532970][SLP] g_event > 37 ffffff001cd8e5d0 ffffffff93b2e000 0 0 0 0000204 [IWAIT] > swi4: vm > 36 ffffff001cd8e8b8 ffffffff93b2f000 0 0 0 000020c [RUNQ] > swi5: clock sio > 35 ffffff001cd8eba0 ffffffff93b30000 0 0 0 0000204 [IWAIT] > swi1: net > 34 ffffff001cda5000 ffffffff93b6d000 0 0 0 0000204 [IWAIT] > irq23: > 33 ffffff001cda52e8 ffffffff93b6e000 0 0 0 0000204 [IWAIT] > irq22: > 32 ffffff001cda55d0 ffffffff93b6f000 0 0 0 0000204 [IWAIT] > irq21: > 31 ffffff001cda58b8 ffffffff93b70000 0 0 0 0000204 [IWAIT] > irq20: > 30 ffffff001cda5ba0 ffffffff93b71000 0 0 0 0000204 [RUNQ] > irq19: sis0 sis1 > 29 ffffff001cda38b8 ffffffff93b07000 0 0 0 0000204 [IWAIT] > irq18: > 28 ffffff001cda3ba0 ffffffff93b08000 0 0 0 0000204 [IWAIT] > irq17: atapci1 > 27 ffffff001cd8c000 ffffffff93b09000 0 0 0 0000204 [IWAIT] > irq16: > 26 ffffff001cd8c2e8 ffffffff93b28000 0 0 0 0000204 [IWAIT] > irq15: ata1 > 25 ffffff001cd8c5d0 ffffffff93b29000 0 0 0 0000204 [IWAIT] > irq14: ata0 > 24 ffffff001cd8c8b8 ffffffff93b2a000 0 0 0 0000204 [IWAIT] > irq13: > 23 ffffff001cd8cba0 ffffffff93b2b000 0 0 0 0000204 [IWAIT] > irq12: > 22 ffffff001cd8e000 ffffffff93b2c000 0 0 0 0000204 [IWAIT] > irq11: > 21 ffffff001cddd2e8 ffffffff93ae2000 0 0 0 0000204 [IWAIT] > irq10: > 20 ffffff001cddd5d0 ffffffff93ae3000 0 0 0 0000204 [IWAIT] > irq9: acpi0 > 19 ffffff001cddd8b8 ffffffff93b02000 0 0 0 0000204 [IWAIT] > irq8: rtc > 18 ffffff001cdddba0 ffffffff93b03000 0 0 0 0000204 [IWAIT] > irq7: ppc0 > 17 ffffff001cda3000 ffffffff93b04000 0 0 0 0000204 [IWAIT] > irq6: fdc0 > 16 ffffff001cda32e8 ffffffff93b05000 0 0 0 0000204 [IWAIT] > irq5: > 15 ffffff001cda35d0 ffffffff93b06000 0 0 0 0000204 [IWAIT] > irq4: sio0 > 14 ffffff001cdd6000 ffffffff93aa0000 0 0 0 0000204 [IWAIT] > irq3: sio1 > 13 ffffff001cdd62e8 ffffffff93add000 0 0 0 0000204 [IWAIT] > irq0: clk > 12 ffffff001cdd65d0 ffffffff93ade000 0 0 0 0000204 [IWAIT] > irq1: atkbd0 > 11 ffffff001cdd68b8 ffffffff93adf000 0 0 0 000020c [Can > run] idle > 1 ffffff001cdd6ba0 ffffffff93ae0000 0 0 1 0004200 [SLPQ > wait 0xffffff001cdd6ba0][SLP] init > 10 ffffff001cddd000 ffffffff93ae1000 0 0 0 0000204 [SLPQ > ktrace 0xffffffff80538370][SLP] ktrace > 0 ffffffff80532b00 ffffffff80679000 0 0 0 0000200 [SLPQ > sched 0xffffffff80532b00][SLP] swapper > > > I'm going to have to put this machine into production within the next 7 > days so any help would be really great, also any extra info anyone > requires is available. As I said in my last this is 100% reproducable. > Dumps are not available - calling panic will lock the system solid. > Calling boot(0) seems to work fine though... > > Regards, > > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 17:52:22 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3368616A4CE for ; Thu, 13 Jan 2005 17:52:22 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id AABAC43D46 for ; Thu, 13 Jan 2005 17:52:20 +0000 (GMT) (envelope-from ph.schulz@gmx.de) Received: (qmail invoked by alias); 13 Jan 2005 17:52:19 -0000 Received: from dsl-082-083-167-119.arcor-ip.net (EHLO [192.168.1.4]) (82.83.167.119) by mail.gmx.net (mp023) with SMTP; 13 Jan 2005 18:52:19 +0100 X-Authenticated: #1954550 Message-ID: <41E6B56B.6020207@gmx.de> Date: Thu, 13 Jan 2005 18:52:43 +0100 From: Phil Schulz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041217 X-Accept-Language: de, en-us, en MIME-Version: 1.0 To: Matthew Sullivan , freebsd-current@freebsd.org References: <41E44CD0.1000008@uq.edu.au> <41E5F22A.6010607@uq.edu.au> <20050113093955.P12838@carver.gumbysoft.com> In-Reply-To: <20050113093955.P12838@carver.gumbysoft.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: Fatal Trap 12: Page fault while in kernel mode (racoon/amd64/5.3-RELEASE-p4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 17:52:22 -0000 [lost the original mail...] On 01/13/05 18:41, Doug White wrote: > On Thu, 13 Jan 2005, Matthew Sullivan wrote: >>I'm going to have to put this machine into production within the next 7 >>days so any help would be really great, also any extra info anyone >>requires is available. As I said in my last this is 100% reproducable. >>Dumps are not available - calling panic will lock the system solid. >>Calling boot(0) seems to work fine though... When you are in the debugger, can you type "call doadump"? Last time I tried to debug a panic, I've had problems with panics not generating a core dump as well. Calling the doadump() function manually worked, though. I don't know if a dump will get you any further, though. Kind regards, Phil. From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 18:19:03 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D7F816A4CE for ; Thu, 13 Jan 2005 18:19:03 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FCEC43D1F for ; Thu, 13 Jan 2005 18:19:03 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 3343272DD4; Thu, 13 Jan 2005 10:19:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 2E22972DCB; Thu, 13 Jan 2005 10:19:03 -0800 (PST) Date: Thu, 13 Jan 2005 10:19:03 -0800 (PST) From: Doug White To: Anish Mistry In-Reply-To: <200501130111.04893.mistry.7@osu.edu> Message-ID: <20050113101102.P13218@carver.gumbysoft.com> References: <200501130111.04893.mistry.7@osu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: propagate_priority panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 18:19:03 -0000 On Thu, 13 Jan 2005, Anish Mistry wrote: > Not sure if anyone else is seeing this, but I'm pretty sure the following > commit broke my system. When mysql tries to shutdown I get a panic in > propagate_priority. As well as X freezing when I go to start it. Actually > one of the applictions or the WM causes it to freeze, but same problem I > think but I can't see the console. Before this everything worked fine. I > can post the hand transcribed panic backtrace message tomorrow if anyone > is interested since I don't have a serial port on the machine. > I'm using the 4BSD scheduler with the latest -CURRENT. We really do need: . the panic message . backtrace . cvsup time . scheduler (ULE or BSD) . if PREEMPTION is enabled in the kernel config . mysql version . thread package mysql was compiled with propagate_priority() is a canary for other problems so the backtrace is especially important. > jhb 2004-12-30 20:52:44 UTC > > FreeBSD src repository > > Modified files: > sys/kern sched_4bsd.c sched_ule.c subr_turnstile.c > sys/sys proc.h sched.h turnstile.h > > Revision Changes Path > 1.71 +102 -14 src/sys/kern/sched_4bsd.c > 1.144 +77 -20 src/sys/kern/sched_ule.c > 1.151 +120 -71 src/sys/kern/subr_turnstile.c > 1.415 +1 -0 src/sys/sys/proc.h > 1.23 +2 -0 src/sys/sys/sched.h > 1.6 +1 -0 src/sys/sys/turnstile.h How did you determine it was this commit that is causing your problem? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 18:29:07 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C61B16A4CE for ; Thu, 13 Jan 2005 18:29:07 +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 650F843D2F for ; Thu, 13 Jan 2005 18:29:06 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.0.5] (adsl-69-208-54-135.dsl.wotnoh.ameritech.net [69.208.54.135]) (authenticated bits=0)j0DI4sWp058853 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 13 Jan 2005 13:04:55 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: Doug White Date: Thu, 13 Jan 2005 13:32:42 -0500 User-Agent: KMail/1.7 References: <200501130111.04893.mistry.7@osu.edu> <20050113101102.P13218@carver.gumbysoft.com> In-Reply-To: <20050113101102.P13218@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1177232.tVA5AhGD8g"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501131332.50598.mistry.7@osu.edu> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on crumpet.united-ware.com cc: freebsd-current@freebsd.org Subject: Re: propagate_priority panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 18:29:07 -0000 --nextPart1177232.tVA5AhGD8g Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 13 January 2005 01:19 pm, you wrote: > On Thu, 13 Jan 2005, Anish Mistry wrote: > > Not sure if anyone else is seeing this, but I'm pretty sure the > > following commit broke my system. When mysql tries to shutdown I get a > > panic in propagate_priority. As well as X freezing when I go to start i= t. > > Actually one of the applictions or the WM causes it to freeze, but same > > problem I think but I can't see the console. Before this everything > > worked fine. I can post the hand transcribed panic backtrace message > > tomorrow if anyone is interested since I don't have a serial port on the > > machine. > > I'm using the 4BSD scheduler with the latest -CURRENT. > > We really do need: > . the panic message > . backtrace > . cvsup time > . scheduler (ULE or BSD) > . if PREEMPTION is enabled in the kernel config > . mysql version > . thread package mysql was compiled with > > propagate_priority() is a canary for other problems so the backtrace is > especially important. > > > jhb 2004-12-30 20:52:44 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/kern sched_4bsd.c sched_ule.c subr_turnstile.c > > sys/sys proc.h sched.h turnstile.h > > > > Revision Changes Path > > 1.71 +102 -14 src/sys/kern/sched_4bsd.c > > 1.144 +77 -20 src/sys/kern/sched_ule.c > > 1.151 +120 -71 src/sys/kern/subr_turnstile.c > > 1.415 +1 -0 src/sys/sys/proc.h > > 1.23 +2 -0 src/sys/sys/sched.h > > 1.6 +1 -0 src/sys/sys/turnstile.h > > How did you determine it was this commit that is causing your problem? See my followup post to the thread it has most of this information. The my= sql=20 version is 4.1.7 and I did a binary search through a series of cvsups to=20 narrow it down to about a 3 hour window and this seemed like the only commi= t=20 that wasn't whitespace fixes or ports. =2D-=20 Anish Mistry --nextPart1177232.tVA5AhGD8g Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBB5r7SxqA5ziudZT0RAiBWAJ4pJV2t+CHKeDx1blE6oR23PGm2LQCgr2Iu WhTrAzoS2/RGlUN795rNMaE= =PUUy -----END PGP SIGNATURE----- --nextPart1177232.tVA5AhGD8g-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 18:52:34 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BB0416A4CE for ; Thu, 13 Jan 2005 18:52:34 +0000 (GMT) Received: from mail14.speakeasy.net (mail22.sea5.speakeasy.net [69.17.117.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2390843D46 for ; Thu, 13 Jan 2005 18:52:34 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 14694 invoked from network); 13 Jan 2005 18:52:33 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 13 Jan 2005 18:52:33 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id j0DIqGuw035159; Thu, 13 Jan 2005 13:52:27 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Peter Holm Date: Thu, 13 Jan 2005 13:43:26 -0500 User-Agent: KMail/1.6.2 References: <20050109214454.GA60018@peter.osted.lan> <200501121503.29257.jhb@FreeBSD.org> <20050113114939.GA79046@peter.osted.lan> In-Reply-To: <20050113114939.GA79046@peter.osted.lan> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200501131343.26286.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: freebsd-current@FreeBSD.org cc: current@FreeBSD.org Subject: Re: panic: proc not held @ fs/procfs/procfs_regs.c:60 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 18:52:34 -0000 On Thursday 13 January 2005 06:49 am, Peter Holm wrote: > On Wed, Jan 12, 2005 at 03:03:29PM -0500, John Baldwin wrote: > > On Sunday 09 January 2005 04:44 pm, Peter Holm wrote: > > > With GENERIC HEAD from Jan 8 08:45 UTC I got: > > > > > > panic(c0826351,c0826973,c082fcfc,3,c175a2e0) at panic+0xd8 > > > procfs_doprocregs(c175a2e0,c1b1b5e8,c1665d80,0,ce778c90) at > > > procfs_doprocregs+0x10a pfs_read(ce778c1c,20000,c1f19e04,c08294ba,845) > > > at pfs_read+0x20f > > > vn_read(c1b17ae4,ce778c90,c1a9c080,0,c175a2e0) at vn_read+0x1b9 > > > dofileread(8,bfbfea50,4c,ffffffff,ffffffff) at dofileread+0x82 > > > read(c175a2e0,ce778d14,3,1,282) at read+0x44 > > > syscall(2f,2f,2f,8059f48,a7c) at syscall+0x128 > > > > > > Details at http://www.holm.cc/stress/log/cons105.html > > > > Hmm, looking at procfs_doprocregs() I'm not sure how it could lose the > > proc lock. The assertion must be in one of the PROC_UNLOCK(). Can you > > do a listing of the procfs_doprocregs() frame to see where it died? > > No, sorry. I seem to have fumbled the backup of the tree before I > did an update :-( > > But isn't the panic in this code: > > procfs_regs.c, Revision 1.29.2.1 > 1.24 jhb 59: PROC_LOCK(p); > 1.29.2.1! das 60: KASSERT(p->p_lock > 0, ("proc not held")); Ah, doh. Too many different locks around. :( Weird, pfs_read() does a _PHOLD and PRELE around calling procfs_doprocregs(), so I'm not sure how this happened. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 18:52:34 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C30516A4CF for ; Thu, 13 Jan 2005 18:52:34 +0000 (GMT) Received: from mail14.speakeasy.net (mail22.sea5.speakeasy.net [69.17.117.24]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2608643D58 for ; Thu, 13 Jan 2005 18:52:34 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 14694 invoked from network); 13 Jan 2005 18:52:33 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 13 Jan 2005 18:52:33 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id j0DIqGuw035159; Thu, 13 Jan 2005 13:52:27 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Peter Holm Date: Thu, 13 Jan 2005 13:43:26 -0500 User-Agent: KMail/1.6.2 References: <20050109214454.GA60018@peter.osted.lan> <200501121503.29257.jhb@FreeBSD.org> <20050113114939.GA79046@peter.osted.lan> In-Reply-To: <20050113114939.GA79046@peter.osted.lan> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200501131343.26286.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: freebsd-current@FreeBSD.org cc: current@FreeBSD.org Subject: Re: panic: proc not held @ fs/procfs/procfs_regs.c:60 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 18:52:34 -0000 On Thursday 13 January 2005 06:49 am, Peter Holm wrote: > On Wed, Jan 12, 2005 at 03:03:29PM -0500, John Baldwin wrote: > > On Sunday 09 January 2005 04:44 pm, Peter Holm wrote: > > > With GENERIC HEAD from Jan 8 08:45 UTC I got: > > > > > > panic(c0826351,c0826973,c082fcfc,3,c175a2e0) at panic+0xd8 > > > procfs_doprocregs(c175a2e0,c1b1b5e8,c1665d80,0,ce778c90) at > > > procfs_doprocregs+0x10a pfs_read(ce778c1c,20000,c1f19e04,c08294ba,845) > > > at pfs_read+0x20f > > > vn_read(c1b17ae4,ce778c90,c1a9c080,0,c175a2e0) at vn_read+0x1b9 > > > dofileread(8,bfbfea50,4c,ffffffff,ffffffff) at dofileread+0x82 > > > read(c175a2e0,ce778d14,3,1,282) at read+0x44 > > > syscall(2f,2f,2f,8059f48,a7c) at syscall+0x128 > > > > > > Details at http://www.holm.cc/stress/log/cons105.html > > > > Hmm, looking at procfs_doprocregs() I'm not sure how it could lose the > > proc lock. The assertion must be in one of the PROC_UNLOCK(). Can you > > do a listing of the procfs_doprocregs() frame to see where it died? > > No, sorry. I seem to have fumbled the backup of the tree before I > did an update :-( > > But isn't the panic in this code: > > procfs_regs.c, Revision 1.29.2.1 > 1.24 jhb 59: PROC_LOCK(p); > 1.29.2.1! das 60: KASSERT(p->p_lock > 0, ("proc not held")); Ah, doh. Too many different locks around. :( Weird, pfs_read() does a _PHOLD and PRELE around calling procfs_doprocregs(), so I'm not sure how this happened. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 18:52:37 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF1C516A4CE for ; Thu, 13 Jan 2005 18:52:36 +0000 (GMT) Received: from mail16.speakeasy.net (mail24.sea5.speakeasy.net [69.17.117.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB37643D53 for ; Thu, 13 Jan 2005 18:52:36 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 11593 invoked from network); 13 Jan 2005 18:52:36 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 13 Jan 2005 18:52:35 -0000 Received: from [10.50.41.243] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id j0DIqGux035159; Thu, 13 Jan 2005 13:52:31 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: Anish Mistry Date: Thu, 13 Jan 2005 13:48:37 -0500 User-Agent: KMail/1.6.2 References: <200501130111.04893.mistry.7@osu.edu> <200501131127.10811.mistry.7@osu.edu> In-Reply-To: <200501131127.10811.mistry.7@osu.edu> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200501131348.37699.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: freebsd-current@FreeBSD.org Subject: Re: propagate_priority panic [backtrace] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 18:52:37 -0000 On Thursday 13 January 2005 11:27 am, Anish Mistry wrote: > On Thursday 13 January 2005 01:10 am, Anish Mistry wrote: > > Not sure if anyone else is seeing this, but I'm pretty sure the > > following commit broke my system. When mysql tries to shutdown I get a > > panic in propagate_priority. As well as X freezing when I go to start it. > > Actually one of the applictions or the WM causes it to freeze, but same > > problem I think but I can't see the console. Before this everything > > worked fine. I can post the hand transcribed panic backtrace message > > tomorrow if anyone is interested since I don't have a serial port on the > > machine. > > I'm using the 4BSD scheduler with the latest -CURRENT. > > > > jhb 2004-12-30 20:52:44 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/kern sched_4bsd.c sched_ule.c subr_turnstile.c > > sys/sys proc.h sched.h turnstile.h > > > > Revision Changes Path > > 1.71 +102 -14 src/sys/kern/sched_4bsd.c > > 1.144 +77 -20 src/sys/kern/sched_ule.c > > 1.151 +120 -71 src/sys/kern/subr_turnstile.c > > 1.415 +1 -0 src/sys/sys/proc.h > > 1.23 +2 -0 src/sys/sys/sched.h > > 1.6 +1 -0 src/sys/sys/turnstile.h > > Dmesg and kernel config attached. > Ok, here is the panic and backtrace: > kernel trap 12 with interrupts disabled > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x4 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc04d5a4f > stack pointer = 0x10:0xcc53bbdc > frame pointer = 0x10:0xcc53bbec > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 628 (mysqld) > [thread pid 628 tid 100085 ] > Stopped at propagate_priority+0x153: pushl 0x4(%eax) > db> tr > Tracing pid 628 tid 100085 td 0xc14e4730 > propagate_priority(c0645cb4,c0645cb0,c15ac650,c14e4730,c14e4730) at > propagate_priority+0x153 > turnstile_wait(c15as650,c15ac650,2,c05f401e,21e) at turnstile_wait+0x1ae > _mtx_lock_sleep(c15ac650,c14e4730,0,c05f8604,206) at _mtx_lock_sleep+0x85 > _mtx_lock_flags(c15ac650,0,c05f8604,206,c15ac650) at _mtx_lock_flags+0x50 > sleepq_calc_signal_retval(0,0,100,ci4e4730,8476f4c) at > sleep_calc_signal_retval+0x2b > msleep(c10bb334,c15ac650,168,c05f399a,402) at msleep+0x3eb > kse_release(c14e4730,cc53bd14,1,12,296) at kse_release+0x186 > syscall(2f,2f,2f,8472000,0) at syscall+0x128 > Xint-x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (383, FreeBSD ELF32, kse_release), eip = 0x285851eb, esp = > 0x8476f28, ebp = 0x8476f64 Does this still happen if you turn FULL_PREEMPTION off? Note from NOTES: # FULL_PREEMPTION instructs the kernel to preempt non-realtime kernel # threads. Its sole use is to expose race conditions and other # bugs during development. Enabling this option will reduce # performance and increase the frequency of kernel panics by # design. If you aren't sure that you need it then you don't. # Relies on the PREEMPTION option. DON'T TURN THIS ON. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 18:58:17 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8F8016A4CE for ; Thu, 13 Jan 2005 18:58:17 +0000 (GMT) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40D4D43D46 for ; Thu, 13 Jan 2005 18:58:17 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 316FA72DD4; Thu, 13 Jan 2005 10:58:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 2F1B272DCB; Thu, 13 Jan 2005 10:58:17 -0800 (PST) Date: Thu, 13 Jan 2005 10:58:17 -0800 (PST) From: Doug White To: Christian Brueffer In-Reply-To: <20050113100732.GA65407@unixpages.org> Message-ID: <20050113105643.L13218@carver.gumbysoft.com> References: <20050113100732.GA65407@unixpages.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE cc: current@freebsd.org Subject: Re: panic: softdep_deallocate_dependencies: dangling deps X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 18:58:17 -0000 On Thu, 13 Jan 2005, Christian Brueffer wrote: > Hi, > > got this panic on a SMP machine tonight. This is about the 10th time > I've gotten this specific panic during the last 2 years. Unfortunately > I haven't found a way to trigger this yet. Coredump is available for > further investigation. Version? It doesn't appear to be HEAD, the line numbers are all offset by too much. System configuration? Kernel compile options? There's one hop in here where a bufpointer gets converted to a NULL, which I don't think would happen in an inline macro. Unless ddb is misinterpreting something. > panic: softdep_deallocate_dependencies: dangling deps > panic messages: > --- > panic: softdep_deallocate_dependencies: dangling deps > cpuid =3D 1 > KDB: enter: panic > Dumping 511 MB > 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 > 320 336 352 368 384 400 416 432 448 464 480 496 > --- > #0 doadump () at pcpu.h:159 > 159 pcpu.h: No such file or directory. > in pcpu.h > doadump () at pcpu.h:159 > 159 in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:159 > #1 0xc0475620 in db_fncall (dummy1=3D0, dummy2=3D0, dummy3=3D-1066882173= , > dummy4=3D0xd544a9ec "\030=AAD=D5\207\223h=C0\004=AAD=D5\b=AAD=D5\220\= a") > at /usr/home/build/src/sys/ddb/db_command.c:531 > #2 0xc0475422 in db_command (last_cmdp=3D0xc0742124, cmd_table=3D0x0, au= x_cmd_tablep=3D0xc070a468, > aux_cmd_tablep_end=3D0xc070a46c) at /usr/home/build/src/sys/ddb/db_co= mmand.c:349 > #3 0xc04754ee in db_command_loop () at /usr/home/build/src/sys/ddb/db_co= mmand.c:455 > #4 0xc047722c in db_trap (type=3D3, code=3D0) at /usr/home/build/src/sys= /ddb/db_main.c:221 > #5 0xc0556209 in kdb_trap (type=3D3, code=3D0, tf=3D0x1) at /usr/home/bu= ild/src/sys/kern/subr_kdb.c:418 > #6 0xc06a55d0 in trap (frame=3D > {tf_fs =3D 24, tf_es =3D 16, tf_ds =3D 16, tf_edi =3D -1066419633, = tf_esi > =3D 1, tf_ebp =3D -716919956, tf_isp =3D -716919976, tf_ebx =3D -71691991= 2, > tf_edx =3D 0, tf_ecx =3D -1056755712, tf_eax =3D 18, tf_trapno =3D 3, tf_= err =3D > 0, tf_eip =3D -1068146901, tf_cs =3D 8, tf_eflags =3D 646, tf_esp =3D > -716919924, tf_ss =3D -1068243131}) > at /usr/home/build/src/sys/i386/i386/trap.c:576 > #7 0xc069384a in calltrap () at /usr/home/build/src/sys/i386/i386/except= ion.s:140 > #8 0x00000018 in ?? () > #9 0x00000010 in ?? () > #10 0x00000010 in ?? () > #11 0xc06fba4f in ?? () > #12 0x00000001 in ?? () > #13 0xd544ab6c in ?? () > #14 0xd544ab58 in ?? () > #15 0xd544ab98 in ?? () > #16 0x00000000 in ?? () > #17 0xc1033000 in ?? () > #18 0x00000012 in ?? () > #19 0x00000003 in ?? () > #20 0x00000000 in ?? () > #21 0xc0555f2b in kdb_enter (msg=3D0x0) at cpufunc.h:56 > #22 0xc053e745 in panic (fmt=3D0xc06fba4f "softdep_deallocate_dependencie= s: dangling deps") > at /usr/home/build/src/sys/kern/kern_shutdown.c:550 > #23 0xc0646256 in softdep_deallocate_dependencies (bp=3D0x0) > at /usr/home/build/src/sys/ufs/ffs/ffs_softdep.c:5949 > #24 0xc058280f in brelse (bp=3D0xcbff6f9c) at buf.h:431 > #25 0xc0590430 in flushbuflist (blist=3D0xcbff6f9c, flags=3D0, vp=3D0xc1f= ac630, slpflag=3D0, slptimeo=3D0, > errorp=3D0x0) at /usr/home/build/src/sys/kern/vfs_subr.c:1101 > #26 0xc0590109 in vinvalbuf (vp=3D0xc1fac630, flags=3D0, cred=3D0x0, td= =3D0x0, slpflag=3D0, slptimeo=3D0) > at /usr/home/build/src/sys/kern/vfs_subr.c:987 > #27 0xc0592999 in vclean (vp=3D0xc1fac630, flags=3D8, td=3D0xc19e6c80) > at /usr/home/build/src/sys/kern/vfs_subr.c:2479 > #28 0xc0592f11 in vgonel (vp=3D0xc1fac630, td=3D0xc19e6c80) at /usr/home/= build/src/sys/kern/vfs_subr.c:2701 > #29 0xc058f3f2 in vlrureclaim (mp=3D0xc2395800) at pcpu.h:156 > #30 0xc058f5a6 in vnlru_proc () at /usr/home/build/src/sys/kern/vfs_subr.= c:598 > #31 0xc0529848 in fork_exit (callout=3D0xc058f460 , arg=3D0x0= , frame=3D0xd544ad48) > at /usr/home/build/src/sys/kern/kern_fork.c:807 > #32 0xc06938ac in fork_trampoline () at /usr/home/build/src/sys/i386/i386= /exception.s:209 > > > - Christian > > --=20 Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 19:23:04 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEB7A16A4CE for ; Thu, 13 Jan 2005 19:23:04 +0000 (GMT) Received: from ms-dienst.rz.rwth-aachen.de (ms-2.rz.RWTH-Aachen.DE [134.130.3.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17AA243D45 for ; Thu, 13 Jan 2005 19:23:04 +0000 (GMT) (envelope-from chris@unixpages.org) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 HotFix 1.12 (built Feb 13 2003)) with ESMTP id <0IA9000ICSIEIU@ms-dienst.rz.rwth-aachen.de> for current@freebsd.org; Thu, 13 Jan 2005 20:23:03 +0100 (MET) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Thu, 13 Jan 2005 20:23:01 +0100 (MET) Received: from haakonia.hitnet.rwth-aachen.de (mulzirak.hitnet.RWTH-Aachen.DE [137.226.181.149]) j0DJN0Aj028880; Thu, 13 Jan 2005 20:23:00 +0100 (MET) Received: from gondor.middleearth (gondor.middleearth [192.168.1.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))(Postfix) with ESMTP id C3B0A2844E; Thu, 13 Jan 2005 20:22:54 +0100 (CET) Received: by gondor.middleearth (Postfix, from userid 1001) id 3081B22824; Thu, 13 Jan 2005 20:22:54 +0100 (CET) Date: Thu, 13 Jan 2005 20:22:53 +0100 From: Christian Brueffer In-reply-to: <20050113105643.L13218@carver.gumbysoft.com> To: Doug White Message-id: <20050113192253.GB65407@unixpages.org> MIME-version: 1.0 Content-type: multipart/signed; boundary="Fba/0zbH8Xs+Fj9o"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 6.0-CURRENT X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <20050113100732.GA65407@unixpages.org> <20050113105643.L13218@carver.gumbysoft.com> cc: current@freebsd.org Subject: Re: panic: softdep_deallocate_dependencies: dangling deps X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 19:23:04 -0000 --Fba/0zbH8Xs+Fj9o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 13, 2005 at 10:58:17AM -0800, Doug White wrote: > On Thu, 13 Jan 2005, Christian Brueffer wrote: >=20 > > Hi, > > > > got this panic on a SMP machine tonight. This is about the 10th time > > I've gotten this specific panic during the last 2 years. Unfortunately > > I haven't found a way to trigger this yet. Coredump is available for > > further investigation. >=20 > Version? It doesn't appear to be HEAD, the line numbers are all offset by > too much. >=20 > System configuration? Kernel compile options? >=20 > There's one hop in here where a bufpointer gets converted to a NULL, which > I don't think would happen in an inline macro. Unless ddb is > misinterpreting something. >=20 Oops, sorry. 5.3-STABLE as of 5th January. CPUTYPE?=3Di686 CFLAGS=3D -O -pipe Kernel config is at http://people.freebsd.org/~brueffer/LORIEN I can give interested parties access to the dump and a matching debug kernel. - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --Fba/0zbH8Xs+Fj9o Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB5sqNbHYXjKDtmC0RAgAdAJ4p4iXjXRRgd777IG7mBczkKxDayACfQDj7 2Mb2RgE9574/+McWJRSw4/Y= =i3j1 -----END PGP SIGNATURE----- --Fba/0zbH8Xs+Fj9o-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 20:19:28 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B761716A4CE for ; Thu, 13 Jan 2005 20:19:28 +0000 (GMT) Received: from post-22.mail.nl.demon.net (post-22.mail.nl.demon.net [194.159.73.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7664443D1D for ; Thu, 13 Jan 2005 20:19:28 +0000 (GMT) (envelope-from kwm@rainbow-runner.nl) Received: from kazerne.demon.nl ([212.238.222.22]:60284 helo=heater.rainbow-runner.nl) by post-22.mail.nl.demon.net with esmtp (Exim 4.34) id 1CpBRG-000KRz-Me; Thu, 13 Jan 2005 20:19:26 +0000 From: Koop Mast To: "M. Warner Losh" In-Reply-To: <20050110.235528.25732845.imp@bsdimp.com> References: <1105227700.25419.14.camel@heater.rainbow-runner.nl> <20050110.235528.25732845.imp@bsdimp.com> Content-Type: text/plain Date: Thu, 13 Jan 2005 20:46:00 +0100 Message-Id: <1105645560.8933.4.camel@heater.rainbow-runner.nl> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: cbb0: CardBus card activation failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 20:19:28 -0000 Op ma, 10-01-2005 te 23:55 -0700, schreef M. Warner Losh: > In message: <1105227700.25419.14.camel@heater.rainbow-runner.nl> > Koop Mast writes: > : I got myself an 3Com wireless card based on the Atheros 5212 chip. > : After inserting it in the first pcmcia slot the kernel tells me this: > : > : cbb0: CardBus card activation failed > > This line has zero content. It just means that the driver didn't > attach, but doesn't tell me why... What are the lines before it. Sorry for the wait, I wrecked my imap when I upgraded it. Here its is with hw.cbb.debug=1, hw.pccard.debug=1, hw.cardbus.debug=1 and boot -v. The complete dmesg is here: http://prisma.rainbow-runner.nl/kwm/dmesg-ath . > : But after some fiddling around I stuck the card in the second pcmcia > : slot, I was rewarded with the following: > > Did you load if_ath in between? No, I load my modules at boot. > Warner Koop From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 20:45:27 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 776A516A4CE; Thu, 13 Jan 2005 20:45:27 +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 D6F8E43D31; Thu, 13 Jan 2005 20:45:26 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.0.5] (adsl-69-208-54-135.dsl.wotnoh.ameritech.net [69.208.54.135]) (authenticated bits=0)j0DKLDWp059164 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 13 Jan 2005 15:21:15 -0500 (EST) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: John Baldwin Date: Thu, 13 Jan 2005 15:48:56 -0500 User-Agent: KMail/1.7 References: <200501130111.04893.mistry.7@osu.edu> <200501131127.10811.mistry.7@osu.edu> <200501131348.37699.jhb@FreeBSD.org> In-Reply-To: <200501131348.37699.jhb@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1896723.jU0RUahIWr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501131549.08903.mistry.7@osu.edu> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on crumpet.united-ware.com cc: freebsd-current@freebsd.org Subject: Re: propagate_priority panic [backtrace] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 20:45:27 -0000 --nextPart1896723.jU0RUahIWr Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 13 January 2005 01:48 pm, John Baldwin wrote: > On Thursday 13 January 2005 11:27 am, Anish Mistry wrote: > > On Thursday 13 January 2005 01:10 am, Anish Mistry wrote: > > > Not sure if anyone else is seeing this, but I'm pretty sure the > > > following commit broke my system. When mysql tries to shutdown I get= a > > > panic in propagate_priority. As well as X freezing when I go to start > > > it. Actually one of the applictions or the WM causes it to freeze, but > > > same problem I think but I can't see the console. Before this > > > everything worked fine. I can post the hand transcribed panic > > > backtrace message tomorrow if anyone is interested since I don't have= a > > > serial port on the machine. > > > I'm using the 4BSD scheduler with the latest -CURRENT. > > > > > > jhb 2004-12-30 20:52:44 UTC > > > > > > FreeBSD src repository > > > > > > Modified files: > > > sys/kern sched_4bsd.c sched_ule.c subr_turnstile.c > > > sys/sys proc.h sched.h turnstile.h > > > > > > Revision Changes Path > > > 1.71 +102 -14 src/sys/kern/sched_4bsd.c > > > 1.144 +77 -20 src/sys/kern/sched_ule.c > > > 1.151 +120 -71 src/sys/kern/subr_turnstile.c > > > 1.415 +1 -0 src/sys/sys/proc.h > > > 1.23 +2 -0 src/sys/sys/sched.h > > > 1.6 +1 -0 src/sys/sys/turnstile.h > > > > Dmesg and kernel config attached. > > Ok, here is the panic and backtrace: > > kernel trap 12 with interrupts disabled > > > > > > Fatal trap 12: page fault while in kernel mode > > fault virtual address =3D 0x4 > > fault code =3D supervisor read, page not present > > instruction pointer =3D 0x8:0xc04d5a4f > > stack pointer =3D 0x10:0xcc53bbdc > > frame pointer =3D 0x10:0xcc53bbec > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, def32 1, gran 1 > > processor eflags =3D resume, IOPL =3D 0 > > current process =3D 628 (mysqld) > > [thread pid 628 tid 100085 ] > > Stopped at propagate_priority+0x153: pushl 0x4(%eax) > > db> tr > > Tracing pid 628 tid 100085 td 0xc14e4730 > > propagate_priority(c0645cb4,c0645cb0,c15ac650,c14e4730,c14e4730) at > > propagate_priority+0x153 > > turnstile_wait(c15as650,c15ac650,2,c05f401e,21e) at turnstile_wait+0x1ae > > _mtx_lock_sleep(c15ac650,c14e4730,0,c05f8604,206) at _mtx_lock_sleep+0x= 85 > > _mtx_lock_flags(c15ac650,0,c05f8604,206,c15ac650) at _mtx_lock_flags+0x= 50 > > sleepq_calc_signal_retval(0,0,100,ci4e4730,8476f4c) at > > sleep_calc_signal_retval+0x2b > > msleep(c10bb334,c15ac650,168,c05f399a,402) at msleep+0x3eb > > kse_release(c14e4730,cc53bd14,1,12,296) at kse_release+0x186 > > syscall(2f,2f,2f,8472000,0) at syscall+0x128 > > Xint-x80_syscall() at Xint0x80_syscall+0x1f > > --- syscall (383, FreeBSD ELF32, kse_release), eip =3D 0x285851eb, esp = =3D > > 0x8476f28, ebp =3D 0x8476f64 > > Does this still happen if you turn FULL_PREEMPTION off? Note from NOTES: > > # FULL_PREEMPTION instructs the kernel to preempt non-realtime kernel > # threads. Its sole use is to expose race conditions and other > # bugs during development. Enabling this option will reduce > # performance and increase the frequency of kernel panics by > # design. If you aren't sure that you need it then you don't. > # Relies on the PREEMPTION option. DON'T TURN THIS ON. Yeah, that was it. =2D-=20 Anish Mistry --nextPart1896723.jU0RUahIWr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBB5t7ExqA5ziudZT0RAgHUAJ9toIUhMI4q3GzePmvwQlv4opDXdACgp1ds eKQg87YgEBYDnQwmf6hYDkQ= =eubF -----END PGP SIGNATURE----- --nextPart1896723.jU0RUahIWr-- From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 22:31:00 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4B3716A503 for ; Thu, 13 Jan 2005 22:30:59 +0000 (GMT) Received: from post-22.mail.nl.demon.net (post-22.mail.nl.demon.net [194.159.73.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAE2043D1D for ; Thu, 13 Jan 2005 22:30:50 +0000 (GMT) (envelope-from kwm@rainbow-runner.nl) Received: from kazerne.demon.nl ([212.238.222.22]:65292 helo=heater.rainbow-runner.nl) by post-22.mail.nl.demon.net with esmtp (Exim 4.34) id 1CpDUP-000EzE-L4; Thu, 13 Jan 2005 22:30:49 +0000 From: Koop Mast To: Warner Losh In-Reply-To: <20050113.145906.74740364.imp@harmony.village.org> References: <1105227700.25419.14.camel@heater.rainbow-runner.nl> <20050110.235528.25732845.imp@bsdimp.com> <1105645560.8933.4.camel@heater.rainbow-runner.nl> <20050113.145906.74740364.imp@harmony.village.org> Content-Type: text/plain Date: Thu, 13 Jan 2005 23:30:55 +0100 Message-Id: <1105655455.97999.8.camel@heater.rainbow-runner.nl> Mime-Version: 1.0 X-Mailer: Evolution 2.1.3.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org cc: imp@bsdimp.com Subject: Re: cbb0: CardBus card activation failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 22:31:00 -0000 Op do, 13-01-2005 te 14:59 -0700, schreef Warner Losh: > From: Koop Mast > Subject: Re: cbb0: CardBus card activation failed > Date: Thu, 13 Jan 2005 20:46:00 +0100 > > > Op ma, 10-01-2005 te 23:55 -0700, schreef M. Warner Losh: > > > In message: <1105227700.25419.14.camel@heater.rainbow-runner.nl> > > > Koop Mast writes: > > > : I got myself an 3Com wireless card based on the Atheros 5212 chip. > > > : After inserting it in the first pcmcia slot the kernel tells me this: > > > : > > > : cbb0: CardBus card activation failed > > > > > > This line has zero content. It just means that the driver didn't > > > attach, but doesn't tell me why... What are the lines before it. > > > > Sorry for the wait, I wrecked my imap when I upgraded it. > > Here its is with hw.cbb.debug=1, hw.pccard.debug=1, hw.cardbus.debug=1 > > and boot -v. The complete dmesg is here: > > http://prisma.rainbow-runner.nl/kwm/dmesg-ath . > > Thanks for the info. Sadly, I wasn't able to get anything useful out > of it :-(. I'll look into adding some better debugging to try to sort > out what's going on. It is safe to assume that if you insert/remove > the card N times into slot 1, it will fail every time, right? Sadly true. I tried it with 8 times just after I send the mail and just now 10 times > Warner Koop From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 22:38:48 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B406716A4CE for ; Thu, 13 Jan 2005 22:38:48 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23CAD43D41 for ; Thu, 13 Jan 2005 22:38:48 +0000 (GMT) (envelope-from benjamin.becker@gmail.com) Received: by rproxy.gmail.com with SMTP id r35so268239rna for ; Thu, 13 Jan 2005 14:38:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=gjBsWGIefdzpARdkv+Ag0IK7q5fDwNPzZ6s1wjV5GWi05ezDpzYT7ZTxhBTtYeBsG5nYmSoicqYk/T1RgbX5CAuxFApp1bhC3L0B8mYHAsjFgxlQbaJxyOBH6FsQPPhgfjHgf823wELsMfzEXYJaSpkDyfUOHvA+nNxSGlmAcpo= Received: by 10.38.86.60 with SMTP id j60mr117574rnb; Thu, 13 Jan 2005 14:38:47 -0800 (PST) Received: by 10.38.73.18 with HTTP; Thu, 13 Jan 2005 14:38:47 -0800 (PST) Message-ID: <38d37be7050113143868516018@mail.gmail.com> Date: Thu, 13 Jan 2005 14:38:47 -0800 From: Ben Becker To: freebsd-current@freebsd.org In-Reply-To: <20050113065003.GA2336@tongi.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <38d37be7050111092379f2a898@mail.gmail.com> <20050113065003.GA2336@tongi.org> Subject: Re: Atheros and SIS bridging problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Ben Becker List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 22:38:48 -0000 On Thu, 13 Jan 2005 14:50:03 +0800, Clive Lin wrote: > On Tue, Jan 11, 2005 at 09:23:08AM -0800, Ben Becker wrote: > > [Laptop]--------(sis0)-[FreeBSD Bridge]-(ath0)--------[FreeBSD AP] > > > > There seems to be a problem with bridging ath0 and sis0. I have 1 IP > > assigned to ath0 which is 192.168.1.3, and I've sysctl'd > > 'net.link.ether.bridge.enable=1' and > > 'net.link.ether.bridge.config=ath0,sis0'. From the bridge, I can ping > > the AP (192.168.1.1) and the laptop (192.168.1.5). However I can't > > ping from the laptop to the AP or from the AP to the laptop. > > Hi, > > Have you tried ng_bridge(4)? My own experience is similar with > yours, and the problem like yours is sovled via ng_bridge(4). Example > scripts to setup ng_bridge(4) is at > /usr/share/examples/netgraph/ether.bridge. > Thank you for the idea, but there are still problems that appear to be related to net80211 or the ath driver. I did get a little further in debugging this with ng_bridge, though. Packets from the remote computer actually go through the bridge and get to the AP. I enabled debug mode for ath0 on the AP(ifconfig ath0 debug), and here's what I get when I try to send a packet from a remote computer that goes through the bridge (hand transcribed): ath0: station 00:0c:6e:a7:47:3b deauthenticate (reason 6) ath0: sending deauth to 00:0c:6e:a7:47:3b on channel 11 ath0: station 00:0c:6e:a7:47:3b disassociate (reason 7) ath0: sending disassoc to 00:0c:6e:a7:47:3b on channel 11 ath0: received auth from 00:0b:6b:33:08:1a rssi 22 ath0: sending auth to 00:0b:6b:33:08:1a on channel 11 ath0: station already 00:0b:6b:33:08:1a authenticated ath0: received assoc_req from 00:0b:6b:33:08:1a rssi 24 ath0: sending assoc_resp to 00:0b:6b:33:08:1a on channel 11 ath0: station already 00:0b:6b:33:08:1a associated 00:0c:6e:a7:47:3b is the MAC address of the remote computer's rl0 interface. 00:0b:6b:33:08:1a is the MAC address of the bridge's ath0 interface. It appears as though ath0 on the AP sees the packet, but thinks the remote computer is actually a station that isn't associated. Am I correct here? I'm not very familiar with the net80211 code, but would it be possible to simply allow the AP to receive and transmit packets to/from layer 2 address that aren't necessarily associated? I know Sam recommended tunneling, but I'd like to essentially have a system that works like those Ethernet-to-Wireless bridge devices (i.e. D-Link DWL-810, newer Linksys WAP11). Am I dreaming -- is this even possible? The more I look into it there doesn't seem to be any standard way of creating an 'Ethernet-to-Wireless' bridge. I'd like to hear from the net80211 pros what the best (if any) solution would be for 'Ethernet-to-Wireless' bridging. Thanks for taking the time to hash through all of this! From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 22:47:15 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C310716A4CE for ; Thu, 13 Jan 2005 22:47:15 +0000 (GMT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74D9743D2F for ; Thu, 13 Jan 2005 22:47:15 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.92] ([66.127.85.92]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j0DMlCWi036381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Jan 2005 14:47:13 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <41E6FA7F.2070406@errno.com> Date: Thu, 13 Jan 2005 14:47:27 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Becker References: <38d37be7050111092379f2a898@mail.gmail.com> <20050113065003.GA2336@tongi.org> <38d37be7050113143868516018@mail.gmail.com> In-Reply-To: <38d37be7050113143868516018@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: Atheros and SIS bridging problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 22:47:16 -0000 Ben Becker wrote: > On Thu, 13 Jan 2005 14:50:03 +0800, Clive Lin wrote: > >>On Tue, Jan 11, 2005 at 09:23:08AM -0800, Ben Becker wrote: >> >>>[Laptop]--------(sis0)-[FreeBSD Bridge]-(ath0)--------[FreeBSD AP] >>> >>>There seems to be a problem with bridging ath0 and sis0. I have 1 IP >>>assigned to ath0 which is 192.168.1.3, and I've sysctl'd >>>'net.link.ether.bridge.enable=1' and >>>'net.link.ether.bridge.config=ath0,sis0'. From the bridge, I can ping >>>the AP (192.168.1.1) and the laptop (192.168.1.5). However I can't >>>ping from the laptop to the AP or from the AP to the laptop. >> >>Hi, >> >> Have you tried ng_bridge(4)? My own experience is similar with >>yours, and the problem like yours is sovled via ng_bridge(4). Example >>scripts to setup ng_bridge(4) is at >>/usr/share/examples/netgraph/ether.bridge. >> > > > Thank you for the idea, but there are still problems that appear to be > related to net80211 or the ath driver. I did get a little further in > debugging this with ng_bridge, though. Packets from the remote > computer actually go through the bridge and get to the AP. I enabled > debug mode for ath0 on the AP(ifconfig ath0 debug), and here's what I > get when I try to send a packet from a remote computer that goes > through the bridge (hand transcribed): > > ath0: station 00:0c:6e:a7:47:3b deauthenticate (reason 6) > ath0: sending deauth to 00:0c:6e:a7:47:3b on channel 11 > ath0: station 00:0c:6e:a7:47:3b disassociate (reason 7) > ath0: sending disassoc to 00:0c:6e:a7:47:3b on channel 11 > ath0: received auth from 00:0b:6b:33:08:1a rssi 22 > ath0: sending auth to 00:0b:6b:33:08:1a on channel 11 > ath0: station already 00:0b:6b:33:08:1a authenticated > ath0: received assoc_req from 00:0b:6b:33:08:1a rssi 24 > ath0: sending assoc_resp to 00:0b:6b:33:08:1a on channel 11 > ath0: station already 00:0b:6b:33:08:1a associated > > 00:0c:6e:a7:47:3b is the MAC address of the remote computer's rl0 interface. > 00:0b:6b:33:08:1a is the MAC address of the bridge's ath0 interface. > > It appears as though ath0 on the AP sees the packet, but thinks the > remote computer is actually a station that isn't associated. Am I > correct here? I'm not very familiar with the net80211 code, but would > it be possible to simply allow the AP to receive and transmit packets > to/from layer 2 address that aren't necessarily associated? > > I know Sam recommended tunneling, but I'd like to essentially have a > system that works like those Ethernet-to-Wireless bridge devices (i.e. > D-Link DWL-810, newer Linksys WAP11). Am I dreaming -- is this even > possible? The more I look into it there doesn't seem to be any > standard way of creating an 'Ethernet-to-Wireless' bridge. I'd like > to hear from the net80211 pros what the best (if any) solution would > be for 'Ethernet-to-Wireless' bridging. Those devices tunnel using a 4-address 802.11 format specifically designed for this. Like I said, what you need is not currently supported. The encapsulation work is actually very simple; the hard bit is how everything ties into the system. I happen to be working on this but results will not be available for a while. Sam From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 00:42:06 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8401116A4CE; Fri, 14 Jan 2005 00:42:06 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85DD943D39; Fri, 14 Jan 2005 00:42:05 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j0E0g1Y5043485; Fri, 14 Jan 2005 11:12:01 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Fri, 14 Jan 2005 11:11:43 +1030 User-Agent: KMail/1.7.1 References: <41E568CE.9030905@gmx.de> In-Reply-To: <41E568CE.9030905@gmx.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart13821811.uDLRfvkhHr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501141112.00237.doconnor@gsoft.com.au> X-Spam-Score: -5.4 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Michael Class cc: current@freebsd.org Subject: Re: SIL3112 and Maxtor 6Y160M0 SATA Disk: DMA Failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 00:42:06 -0000 --nextPart13821811.uDLRfvkhHr Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 13 Jan 2005 04:43, Michael Class wrote: > Unfortunately when I do attach my Maxtor SATA disk to this controller > I do only get DMA errors. This is all on a recent 6.0-CURRENT system > and can be reproduced with a GENERIC kernel. > Anything I could do to track this further down? I good start would be to post the stack trace of the crash.. =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 --nextPart13821811.uDLRfvkhHr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBB5xVX5ZPcIHs/zowRArJ6AKCR8CpeUoeITFzS5adeACF9cBjX+gCfYqwm 5+BonGN91RgYnwP1wH6pW7I= =544n -----END PGP SIGNATURE----- --nextPart13821811.uDLRfvkhHr-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 00:42:06 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8401116A4CE; Fri, 14 Jan 2005 00:42:06 +0000 (GMT) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85DD943D39; Fri, 14 Jan 2005 00:42:05 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j0E0g1Y5043485; Fri, 14 Jan 2005 11:12:01 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Fri, 14 Jan 2005 11:11:43 +1030 User-Agent: KMail/1.7.1 References: <41E568CE.9030905@gmx.de> In-Reply-To: <41E568CE.9030905@gmx.de> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart13821811.uDLRfvkhHr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501141112.00237.doconnor@gsoft.com.au> X-Spam-Score: -5.4 () IN_REP_TO,PGP_SIGNATURE_2,QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01,USER_AGENT,USER_AGENT_KMAIL X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) cc: Michael Class cc: current@freebsd.org Subject: Re: SIL3112 and Maxtor 6Y160M0 SATA Disk: DMA Failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 00:42:06 -0000 --nextPart13821811.uDLRfvkhHr Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 13 Jan 2005 04:43, Michael Class wrote: > Unfortunately when I do attach my Maxtor SATA disk to this controller > I do only get DMA errors. This is all on a recent 6.0-CURRENT system > and can be reproduced with a GENERIC kernel. > Anything I could do to track this further down? I good start would be to post the stack trace of the crash.. =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 --nextPart13821811.uDLRfvkhHr Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBB5xVX5ZPcIHs/zowRArJ6AKCR8CpeUoeITFzS5adeACF9cBjX+gCfYqwm 5+BonGN91RgYnwP1wH6pW7I= =544n -----END PGP SIGNATURE----- --nextPart13821811.uDLRfvkhHr-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 00:48:52 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8564016A4CE; Fri, 14 Jan 2005 00:48:52 +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 16F6C43D49; Fri, 14 Jan 2005 00:48:52 +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 j0E0mpOZ026648; Thu, 13 Jan 2005 16:48:51 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <41E716F3.20504@freebsd.org> Date: Thu, 13 Jan 2005 16:48:51 -0800 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: David Schultz References: <200501120735.j0C7ZABq048856@repoman.freebsd.org> <41E5ED66.4070902@freebsd.org> <20050113072153.GA28485@VARK.MIT.EDU> In-Reply-To: <20050113072153.GA28485@VARK.MIT.EDU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: "'freebsd-current@freebsd.org'" cc: Pawel Jakub Dawidek Subject: Re: fts improvements, alternatives X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 00:48:52 -0000 [Moved to -current for further discussion.] David Schultz wrote: >Tim Kientzle wrote: >>Pawel Jakub Dawidek wrote: >> >>> Introduce new field 'fts_bignum' ... >>> This work is part of the BigDisk project: >>> http://www.FreeBSD.org/projects/bigdisk/ >> >>Any plans to deal with other fts limits ... ? > > Removing FTS_LOGICAL's path length limitation is nontrivial, but > given your experience with bsdtar, I'd say you're an ideal person > to do it. ;-) As it happens, I started tinkering with these ideas a while ago but haven't found time to finish it all. Here's a snapshot of the current WIP: http://people.freebsd.org/~kientzle/libarchive/src/tree.tgz This includes a simple main() test function that just does the rough equivalent of "find .". > .. fts() effectively uses chdir("..") to > climb up one level in the tree in chdir mode. If it chdir'd > across a symlink earlier, this would put it in the wrong place. > Perhaps you have a better solution, but my best idea is to keep > the parent directory open when chdiring ... The tree package does exactly this. It just keeps a flag with each ancestor node indicating the type of traversal that's needed. > A more uniform approach would be to ... always keep the > parent open when descending a level. Unfortunately, this limits > the traversal depth to the number of available file descriptors. The tree package does not do this for exactly this reason. I have some ideas for handling the case where the number of symlinks exceeds the available file descriptors, but that doesn't seem particularly pressing at the moment. > (On the other hand, I would argue that anyone with a directory > tree a few thousand levels deep is asking for trouble.) I thought you *wanted* to support big disks! ;-) I started this work partly because I wanted to really stress the long pathname support in bsdtar. I've archived directory trees with megabyte pathnames (several thousand directory levels crossing several hundred symlinks) in testing. Of course, I can't yet *dearchive* such deep trees. That seems to be a harder problem. The tree package also keeps a *lot* less data in memory than fts. It has no trouble with million-entry directories, for example. In comparison, the current ls crashes on such large directories in part because of the memory required for fts. The tree package is quite a bit different in many respects: * The traversal is in a very different order, for instance. * It has a completely different API than fts. It's fully opaque (so should be easier to change in the future, unlike fts). * It takes a very different approach to determine when to visit a child. In particular, instead of the client specifying a mode and optionally inhibiting the descent through a "prune" request, the tree package has the client specifically request descent. If you request descent for *every* item, you'll end up with a logical traversal; if you request descent for every dir, you'll end up with a physical traversal. (The tree package is smart enough to ignore any descent request that isn't for a dir or a link to a dir.) Feedback, suggestions, etc. appreciated. Tim From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 00:57:43 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB07216A4CE for ; Fri, 14 Jan 2005 00:57:43 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23F6F43D49 for ; Fri, 14 Jan 2005 00:57:43 +0000 (GMT) (envelope-from benjamin.becker@gmail.com) Received: by rproxy.gmail.com with SMTP id r35so280824rna for ; Thu, 13 Jan 2005 16:57:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=aMfTqHDe0JomBbn/Sq/xaxehhoNJ5D86oFnxNO4ETWXVNaOFoeIbFzSq2MWxo9JqMCEXrjYkvZB5ouxKELRBPhWHSo5P6PhECj/oMuM9xMRUjfn2VSjtVyLPeHQdgsVEu23lGG/Kh9v46mkOUL6VlbjSKwken5jMdboWvc/pKbY= Received: by 10.38.90.35 with SMTP id n35mr139248rnb; Thu, 13 Jan 2005 16:57:42 -0800 (PST) Received: by 10.38.73.18 with HTTP; Thu, 13 Jan 2005 16:57:42 -0800 (PST) Message-ID: <38d37be7050113165733434463@mail.gmail.com> Date: Thu, 13 Jan 2005 16:57:42 -0800 From: Ben Becker To: freebsd-current@freebsd.org In-Reply-To: <41E6FA7F.2070406@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <38d37be7050111092379f2a898@mail.gmail.com> <20050113065003.GA2336@tongi.org> <38d37be7050113143868516018@mail.gmail.com> <41E6FA7F.2070406@errno.com> Subject: Re: Atheros and SIS bridging problem X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Ben Becker List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 00:57:43 -0000 On Thu, 13 Jan 2005 14:47:27 -0800, Sam Leffler wrote: > Those devices tunnel using a 4-address 802.11 format specifically > designed for this. Like I said, what you need is not currently > supported. The encapsulation work is actually very simple; the hard bit > is how everything ties into the system. I happen to be working on this > but results will not be available for a while. > > Sam Would this be as simple as using the struct ieee80211_frame_add4 instead of ieee80211_frame and setting the proper ToDS and FromDS values in the control settings? It looks like you've done most of the work already. Is there anything else that needs to be done aside from updating all of the net80211 and device driver functions that reference ieee80211_frame? I'm going to start working on a hack for this since I need the feature for a project I'm working on. I don't want to keep pestering you with this since you're already working on it, but I'm more than happy to help incorporate this feature in any way I can. Obviously, any tips and pointers would be greatly appreciated. -Ben From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 01:06:42 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D61D416A4CE for ; Fri, 14 Jan 2005 01:06:42 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92A1643D1F for ; Fri, 14 Jan 2005 01:06:42 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j0E16atP030900 for ; Thu, 13 Jan 2005 17:06:40 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200501140106.j0E16atP030900@gw.catspoiler.org> Date: Thu, 13 Jan 2005 17:06:36 -0800 (PST) From: Don Lewis To: current@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Subject: repeatable panic - ffs_blkfree: freeing free block X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 01:06:42 -0000 I'm getting a repeatable panic when trying to build openoffice with a 2005-01-12 kernel and world. I manually fsck'ed the file system immediately before the build. The first panic happened during the patching phase of the build. I tried again and this time the panic happened during configuration. dev = da0s2a, block = 5090392, fs = /mnt panic: ffs_blkfree: freeing free block cpuid = 0 KDB: enter: panic [thread pid 55 tid 100043 ] Stopped at kdb_enter+0x2c: leave db> tr Tracing pid 55 tid 100043 td 0xc22fa450 kdb_enter(c0848a40,100,c22fa450,1361b80,4b5) at kdb_enter+0x2c panic(c085f39d,c085f37d,c26cc280,4dac58,0) at panic+0x17f ffs_blkfree(c2863800,c2987114,4dac58,0,4000) at ffs_blkfree+0x3a0 indir_trunc(136b060,0,0,c,0,e4d5bc4c) at indir_trunc+0x1bf handle_workitem_freeblocks(0,0,0,1,0) at handle_workitem_freeblocks+0x2e6 process_worklist_item(41e7112d,0,0,c247d2bc,23) at process_worklist_item+0x1c0 softdep_process_worklist(0,29,41e7112d,1,0) at softdep_process_worklist+0x66 sched_sync(0,e4d5bd48,0,c0677b60,0) at sched_sync+0x3b2 fork_exit(c0677b60,0,e4d5bd48) at fork_exit+0x7e fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4d5bd7c, ebp = 0 --- The kernel was built with INVARIANTS, WITNESS, and DEBUG_VFS_LOCKS. I was able to get a crash dump from the first panic, so at least doadump works for me. After the crash, fsck reports some unexpected damage: PARTIALLY TRUNCATED INODE I=127552 but this inode doesn't seem to be associated with the block number in the panic message. % fsdb /dev/da0s2a ** /dev/da0s2a (NO WRITE) Editing file system `/dev/da0s2a' Last Mounted on /mnt current inode: directory I=2 MODE=40755 SIZE=512 MTIME=Feb 14 11:55:43 2004 [0 nsec] CTIME=Feb 14 11:55:43 2004 [0 nsec] ATIME=Jan 13 16:15:58 2005 [0 nsec] OWNER=root GRP=wheel LINKCNT=7 FLAGS=0 BLKCNT=4 GEN=53557245 fsdb (inum: 2)> inode 127552 current inode: regular file I=127552 MODE=100644 SIZE=1932 MTIME=Dec 22 07:47:38 2003 [0 nsec] CTIME=Dec 22 07:47:38 2003 [0 nsec] ATIME=Dec 22 07:57:30 2003 [0 nsec] OWNER=root GRP=wheel LINKCNT=1 FLAGS=0 BLKCNT=4 GEN=1442a6af fsdb (inum: 127552)> blocks Blocks for inode 127552: Direct blocks: 533086 (1 frag) There are no snapshots present. From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 01:15:06 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F9A616A4CE for ; Fri, 14 Jan 2005 01:15:06 +0000 (GMT) Received: from digger1.defence.gov.au (digger1.defence.gov.au [203.5.217.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B74C643D31 for ; Fri, 14 Jan 2005 01:15:04 +0000 (GMT) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: from ednmsw503.dsto.defence.gov.au (ednmsw503.dsto.defence.gov.au [131.185.2.150]) by digger1.defence.gov.au with ESMTP id j0E1DtTe010031 for ; Fri, 14 Jan 2005 11:43:55 +1030 (CST) Received: from muttley.dsto.defence.gov.au (unverified) by ednmsw503.dsto.defence.gov.au (Content Technologies SMTPRS 4.3.10) with ESMTP id for ; Fri, 14 Jan 2005 11:44:55 +1030 Received: from ednex501.dsto.defence.gov.au (ednex501.dsto.defence.gov.au [131.185.2.81]) by muttley.dsto.defence.gov.au (8.11.3/8.11.3) with ESMTP id j0E15xQ31995 for ; Fri, 14 Jan 2005 11:35:59 +1030 (CST) Received: from squash.dsto.defence.gov.au ([131.185.40.212]) by ednex501.dsto.defence.gov.au with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id YK38C6CM; Fri, 14 Jan 2005 11:35:40 +1030 Received: from squash.dsto.defence.gov.au (localhost [127.0.0.1]) by squash.dsto.defence.gov.au (8.12.11/8.12.11) with ESMTP id j0E16c2D050362 for ; Fri, 14 Jan 2005 11:36:38 +1030 (CST) (envelope-from wilkinsa@squash.dsto.defence.gov.au) Received: (from wilkinsa@localhost) by squash.dsto.defence.gov.au (8.12.11/8.12.11/Submit) id j0E16ckA050361 for freebsd-current@freebsd.org; Fri, 14 Jan 2005 11:36:38 +1030 (CST) (envelope-from wilkinsa) Date: Fri, 14 Jan 2005 11:36:38 +1030 From: "Wilkinson, Alex" To: freebsd-current@freebsd.org Message-ID: <20050114010638.GT49309@squash.dsto.defence.gov.au> Mail-Followup-To: freebsd-current@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Subject: Re: NFS problems, locking up X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 01:15:06 -0000 0n Wed, Jan 12, 2005 at 08:53:11PM +0000, Robert Watson wrote: > >On Wed, 12 Jan 2005, Daniel Eriksson wrote: > >> I'm still having problems with NFS locking up when moving large amounts >> of data over it on 6-CURRENT from 2005.01.11.05.00.00. This problem has >> persisted for a long time now, and the only thing that seems to cure it >> is running the network stack with giant enabled (debug.mpsafenet=0). >> >> When it happens, the process doing the copying ends up in "nfsaio" state >> according to ps. Any accesses to the locked mount by other processes >> ends up waiting forever in state "nfs". I have multiple file systems >> mounted from the same server, and only the mount where the data is being >> moved locks up. The others continue to work as expected. >> >> Server: UP, 6-CURRENT from 2005.01.11.05.00.00, if_vr (POLLING) Client: >> SMP (dual AMD MP), 6-CURRENT from 2005.01.11.05.00.00, if_em >> >> The machines are connected with a crossover cable. I've tried both >> schedulers (4BSD and ULE) on the client, but it doesn't make any >> difference (server is running 4BSD). PREEMPTION is enabled on both >> server and client. ADAPTIVE_GIANT is enabled on the client. > >If you run with INVARIANTS and WITNESS, does anything useful get printed >out? Does it make a difference if you run the client with a UP kernel? > >If you break to the debugger on the client and server once wedging has >occurred, what does "show lockedvnods" and "show alllocks" show? > >Is there any chance you could attach a second NFS client to the >configuration, wedge the file system from the first client, and then try >the second client and see if it experiences immediate problems? What is meant by 'wedge the file system' ? - aW From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 01:35:03 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 956CC16A4CE for ; Fri, 14 Jan 2005 01:35:03 +0000 (GMT) Received: from mailhub2.uq.edu.au (mailhub2.uq.edu.au [130.102.149.128]) by mx1.FreeBSD.org (Postfix) with ESMTP id 98A5D43D2F for ; Fri, 14 Jan 2005 01:35:02 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from smtp2.uq.edu.au (smtp2.uq.edu.au [130.102.5.53]) by mailhub2.uq.edu.au (8.12.11/8.12.11) with ESMTP id j0E1Z1rV029967 for ; Fri, 14 Jan 2005 11:35:01 +1000 (EST) Received: from [130.102.152.118] (stealthd.its.uq.edu.au [130.102.152.118]) by smtp2.uq.edu.au (8.12.10/8.12.10) with ESMTP id j0E1Z1Jh009492 for ; Fri, 14 Jan 2005 11:35:01 +1000 (EST) Message-ID: <41E721A7.3010302@uq.edu.au> Date: Fri, 14 Jan 2005 11:34:31 +1000 From: Matthew Sullivan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040618 X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <41E44CD0.1000008@uq.edu.au> <41E5F22A.6010607@uq.edu.au> <20050113093955.P12838@carver.gumbysoft.com> In-Reply-To: <20050113093955.P12838@carver.gumbysoft.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000706040904000201030804" X-Scanned-By: MIMEDefang 2.43 on UQ Mailhub Subject: Re: Fatal Trap 12: Page fault while in kernel mode (racoon/amd64/5.3-RELEASE-p4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 01:35:03 -0000 This is a cryptographically signed message in MIME format. --------------ms000706040904000201030804 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Doug White wrote: >You're in the right spot. > > That's a start then, thanks ;-) >>Further to my last I have finally located a null modem cable and got it >>installed... A little fiddling later and we have DDB taking over... >> >>root@desperado:~# racoon >> >> > >Hm, null pointer+offset dereference. Are you using IPSEC or FAST_IPSEC in >your kernel? When did you grab the sources last? > > IPSEC (see: http://www.au.sorbs.net/~matthew/freebsd/ for all kernel, config, cores and info I can give) Source was updated after finding this issue (within the last 10 days) and it made no difference. >>Fatal trap 12: page fault while in kernel mode >>fault virtual address = 0x39 >>fault code = supervisor write, page not present >>instruction pointer = 0x8:0xffffffff80307a70 >>stack pointer = 0x10:0xffffffff94eb4860 >>frame pointer = 0x10:0xffffffff94eb4960 >>code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, long 1, def32 0, gran 1 >>processor eflags = interrupt enabled, resume, IOPL = 0 >>current process = 454 (racoon) >>[thread 100081] >>Stopped at keydb_newsecasvar+0x100: decl %ecx >> >> Thanks, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms000706040904000201030804 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDExNDAxMzQzMVowIwYJKoZIhvcNAQkEMRYEFCD8B6Sg9wU8RMzi xHCfTReXdwacMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQIo97p6giIm3NcZoqlkyajTWPXzRPCj4CJAnVwXiZGZuRJ5HfeoyGWVR7ULC9GdsYI/o yivMzP+hR+Ljg6fSKpQAAAAAAAA= --------------ms000706040904000201030804-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 01:47:54 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FB8916A4CF for ; Fri, 14 Jan 2005 01:47:54 +0000 (GMT) Received: from mailhub1.uq.edu.au (mailhub1.uq.edu.au [130.102.148.128]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BF8743D1D for ; Fri, 14 Jan 2005 01:47:53 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from smtp2.uq.edu.au (smtp2.uq.edu.au [130.102.5.53]) by mailhub1.uq.edu.au (8.12.11/8.12.11) with ESMTP id j0E1lqPc008572 for ; Fri, 14 Jan 2005 11:47:52 +1000 (EST) Received: from [130.102.152.118] (stealthd.its.uq.edu.au [130.102.152.118]) by smtp2.uq.edu.au (8.12.10/8.12.10) with ESMTP id j0E1lpJh016620 for ; Fri, 14 Jan 2005 11:47:51 +1000 (EST) Message-ID: <41E724AE.3040809@uq.edu.au> Date: Fri, 14 Jan 2005 11:47:26 +1000 From: Matthew Sullivan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040618 X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <41E44CD0.1000008@uq.edu.au> <41E5F22A.6010607@uq.edu.au> <20050113093955.P12838@carver.gumbysoft.com> <41E6B56B.6020207@gmx.de> In-Reply-To: <41E6B56B.6020207@gmx.de> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080104050604090205060905" X-Scanned-By: MIMEDefang 2.43 on UQ Mailhub Subject: Re: Fatal Trap 12: Page fault while in kernel mode (racoon/amd64/5.3-RELEASE-p4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 01:47:54 -0000 This is a cryptographically signed message in MIME format. --------------ms080104050604090205060905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Phil Schulz wrote: > [lost the original mail...] > > On 01/13/05 18:41, Doug White wrote: > >> On Thu, 13 Jan 2005, Matthew Sullivan wrote: >> >>> I'm going to have to put this machine into production within the next 7 >>> days so any help would be really great, also any extra info anyone >>> requires is available. As I said in my last this is 100% reproducable. >>> Dumps are not available - calling panic will lock the system solid. >>> Calling boot(0) seems to work fine though... >> > > When you are in the debugger, can you type "call doadump"? Yes thanks, between you mailing and my last post I spotted this call in someone elses woes an took immediate advantage ;-) Results are at: http://www.au.sorbs.net/~matthew/freebsd/ along with the core, the kernel, the symbols etc etc etc.. ;-) > Last time I tried to debug a panic, I've had problems with panics not > generating a core dump as well. Calling the doadump() function > manually worked, though. Gets me here: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x39 fault code = supervisor write, page not present instruction pointer = 0x8:0xffffffff80307a70 stack pointer = 0x10:0xffffffff93cc0860 frame pointer = 0x10:0xffffffff93cc0960 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 480 (racoon) [thread 100068] Stopped at keydb_newsecasvar+0x100: decl %ecx db> w Nothing written. db> where keydb_newsecasvar() at keydb_newsecasvar+0x100 raw_usend() at raw_usend+0x60 key_send() at key_send+0xa sosend() at sosend+0x626 kern_sendit() at kern_sendit+0x113 sendit() at sendit+0x5f sendto() at sendto+0x4d syscall() at syscall+0x50c Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (133, FreeBSD ELF64, sendto), rip = 0x800a63da8, rsp = 0x7fffffffec38, rbp = 0x2 --- db> call doadump Dumping 479 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 Dump complete 0xf Then we can proceed ;-) (kgdb) file /usr/obj/usr/src/sys/DESPERADO/kernel.debug Reading symbols from /usr/obj/usr/src/sys/DESPERADO/kernel.debug...done. (kgdb) where #0 doadump () at pcpu.h:167 #1 0xffffffff80172736 in db_fncall (dummy1=0, dummy2=0, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:531 #2 0xffffffff80172bc5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:349 #3 0xffffffff80174a53 in db_trap (type=-1815345680, code=0) at /usr/src/sys/ddb/db_main.c:221 #4 0xffffffff8023070b in kdb_trap (type=12, code=0, tf=0xffffffff93cc07b0) at /usr/src/sys/kern/subr_kdb.c:418 #5 0xffffffff80371dae in trap_fatal (frame=0xffffffff93cc07b0, eva=18446742974681318688) at /usr/src/sys/amd64/amd64/trap.c:626 #6 0xffffffff80372143 in trap_pfault (frame=0xffffffff93cc07b0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:554 #7 0xffffffff803723a4 in trap (frame= {tf_rdi = -1099028463104, tf_rsi = 640, tf_rdx = -1815344784, tf_rcx = -1815344833, tf_r8 = 160, tf_r9 = -1099028232928 , tf_rax = -1815345008, tf_rbx = -2144306579, tf_rbp = -1815344800, tf_r10 = -2142160512, tf_r11 = -1815344624, tf_r12 = 57, tf_r13 = 0, tf_r14 = 0, tf_r15 = -1099140303240, tf_trapno = 12, tf_addr = 57, tf_flags = -1099132378656, tf_err = 2, tf_rip = -2144306576, tf_cs = 8, tf_rflags = 66054, tf_rsp = -1815345040, tf_ss = 16}) at /usr/src/sys/amd64/amd64/trap.c:333 #8 0xffffffff80361bab in calltrap () at /usr/src/sys/amd64/amd64/exception.S:171 #9 0xffffff001ccc8200 in ?? () #10 0x0000000000000280 in ?? () #11 0xffffffff93cc0970 in ?? () #12 0xffffffff93cc093f in ?? () #13 0x00000000000000a0 in ?? () #14 0xffffff001cd00520 in ?? () #15 0xffffffff93cc0890 in ?? () #16 0xffffffff80307a6d in keydb_newsecasvar () at /usr/src/sys/netkey/keydb.c:187 #17 0xffffffff8029cfc0 in raw_usend (so=0x0, flags=0, m=0x0, nam=0x0, control=0x0, td=0x0) at /usr/src/sys/net/raw_usrreq.c:263 #18 0xffffffff8030845a in key_send (so=0x0, flags=0, m=0x0, nam=0x0, control=0x0, td=0x0) at /usr/src/sys/netkey/keysock.c:442 #19 0xffffffff80253bc6 in sosend (so=0xffffff001621f678, addr=0x0, uio=0xffffffff93cc0a80, top=0xffffff001ccc8200, control=0x0, flags=0, td=0xffffff001cd00520) at /usr/src/sys/kern/uipc_socket.c:815 #20 0xffffffff8025ba73 in kern_sendit (td=0xffffff001cd00520, s=4, mp=0xffffffff93cc0b50, flags=0, control=0x0) at /usr/src/sys/kern/uipc_syscalls.c:738 #21 0xffffffff8025ca5f in sendit (td=0xffffff001cd00520, s=4, mp=0xffffffff93cc0b50, flags=0) at /usr/src/sys/kern/uipc_syscalls.c:682 #22 0xffffffff8025cbed in sendto (td=0x0, uap=0x0) at /usr/src/sys/kern/uipc_syscalls.c:795 #23 0xffffffff80372b6c in syscall (frame= {tf_rdi = 4, tf_rsi = 5660864, tf_rdx = 16, tf_rcx = 0, tf_r8 = 0, tf_r9 = 0, tf_rax = 133, tf_rbx = 5660880, tf_rbp = 2, tf_r10 = -2141993928, tf_r11 = 514, tf_r12 = 5660864, tf_r13 = 16, tf_r14 = 7, tf_r15 = 4, tf_trapno = 12, tf_addr = 42840 00, tf_flags = 0, tf_err = 2, tf_rip = 34370633128, tf_cs = 43, tf_rflags = 514, tf_rsp = 140737488350264, tf_ss = 35}) at /usr/src/sys/amd64/amd64/trap.c:763 #24 0xffffffff80361ce8 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:248 . . . (kgdb) frame 16 #16 0xffffffff80307a6d in keydb_newsecasvar () at /usr/src/sys/netkey/keydb.c:187 187 p->id = said; (kgdb) info loc p = (struct secasvar *) 0x39 q = (struct secasvar *) 0xffffffff80307a6d said = 0 (kgdb) l *0xffffffff80307a70 0xffffffff80307a70 is in keydb_newsecasvar (/usr/src/sys/netkey/keydb.c:191). 186 bzero(p, sizeof(*p)); 187 p->id = said; 188 if (q) 189 TAILQ_INSERT_AFTER(&satailq, q, p, tailq); 190 else 191 TAILQ_INSERT_TAIL(&satailq, p, tailq); 192 return p; 193 } 194 195 void (kgdb) l 156,193 156 /* 157 * secasvar management (reference counted) 158 */ 159 struct secasvar * 160 keydb_newsecasvar() 161 { 162 struct secasvar *p, *q; 163 static u_int32_t said = 0; 164 165 p = (struct secasvar *)malloc(sizeof(*p), M_SECA, M_NOWAIT); 166 if (!p) 167 return p; 168 169 again: 170 said++; 171 if (said == 0) 172 said++; 173 TAILQ_FOREACH(q, &satailq, tailq) { 174 if (q->id == said) 175 goto again; 176 if (TAILQ_NEXT(q, tailq)) { 177 if (q->id < said && said < TAILQ_NEXT(q, tailq)->id) 178 break; 179 if (q->id + 1 < TAILQ_NEXT(q, tailq)->id) { 180 said = q->id + 1; 181 break; 182 } 183 } 184 } 185 186 bzero(p, sizeof(*p)); 187 p->id = said; 188 if (q) 189 TAILQ_INSERT_AFTER(&satailq, q, p, tailq); 190 else 191 TAILQ_INSERT_TAIL(&satailq, p, tailq); 192 return p; 193 } Without a clue on the FreeBSD kernel and not enough time to get stuck in (atm) I'm not geing to be able to get further without help. Regards, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms080104050604090205060905 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDExNDAxNDcyNlowIwYJKoZIhvcNAQkEMRYEFHw1D9hCgiQVJpeY tVYR7YG48m0OMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQBgM4n0c4dLW7KaHLpmLubtt7i79lsSOjHzLLO/O/zEbl0VkxCTmmZNg8WGdzbRTgrh6 sq8dxxNh3k5ncR1+gYUAAAAAAAA= --------------ms080104050604090205060905-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 02:30:41 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 778AC16A4CE for ; Fri, 14 Jan 2005 02:30:41 +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 D8A9343D41 for ; Fri, 14 Jan 2005 02:30:40 +0000 (GMT) (envelope-from marcel@xcllnt.net) Received: from [192.168.4.250] (dhcp50.pn.xcllnt.net [192.168.4.250]) by ns1.xcllnt.net (8.13.1/8.13.1) with ESMTP id j0E2Ue4b003435; Thu, 13 Jan 2005 18:30:40 -0800 (PST) (envelope-from marcel@xcllnt.net) In-Reply-To: <41E721A7.3010302@uq.edu.au> References: <41E44CD0.1000008@uq.edu.au> <41E5F22A.6010607@uq.edu.au> <20050113093955.P12838@carver.gumbysoft.com> <41E721A7.3010302@uq.edu.au> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4781326B-65D4-11D9-A004-000D93C47836@xcllnt.net> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Thu, 13 Jan 2005 18:30:39 -0800 To: Matthew Sullivan X-Mailer: Apple Mail (2.619) cc: freebsd-current@freebsd.org Subject: Re: Fatal Trap 12: Page fault while in kernel mode (racoon/amd64/5.3-RELEASE-p4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 02:30:41 -0000 On Jan 13, 2005, at 5:34 PM, Matthew Sullivan wrote: >> >> Hm, null pointer+offset dereference. Are you using IPSEC or >> FAST_IPSEC in >> your kernel? When did you grab the sources last? >> > IPSEC (see: http://www.au.sorbs.net/~matthew/freebsd/ for all kernel, > config, cores and info I can give) > > Source was updated after finding this issue (within the last 10 days) > and it made no difference. Note that "setkey -D" should be enough to trigger the page fault on amd64. Note also that i386 and ia64 don't have this problem. I don't know about alpha or sparc64, but it looks amd64 specific. FYI, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 03:02:36 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 658CE16A4CE for ; Fri, 14 Jan 2005 03:02:36 +0000 (GMT) Received: from mailhub2.uq.edu.au (mailhub2.uq.edu.au [130.102.149.128]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A1A943D31 for ; Fri, 14 Jan 2005 03:02:35 +0000 (GMT) (envelope-from matthew@uq.edu.au) Received: from smtp2.uq.edu.au (smtp2.uq.edu.au [130.102.5.53]) by mailhub2.uq.edu.au (8.12.11/8.12.11) with ESMTP id j0E32XVF004995 for ; Fri, 14 Jan 2005 13:02:33 +1000 (EST) Received: from [130.102.152.118] (stealthd.its.uq.edu.au [130.102.152.118]) by smtp2.uq.edu.au (8.12.10/8.12.10) with ESMTP id j0E32XJh028560 for ; Fri, 14 Jan 2005 13:02:33 +1000 (EST) Message-ID: <41E73630.7050301@uq.edu.au> Date: Fri, 14 Jan 2005 13:02:08 +1000 From: Matthew Sullivan User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040618 X-Accept-Language: en MIME-Version: 1.0 Cc: freebsd-current@freebsd.org References: <41E44CD0.1000008@uq.edu.au> <41E5F22A.6010607@uq.edu.au> <20050113093955.P12838@carver.gumbysoft.com> <41E721A7.3010302@uq.edu.au> <4781326B-65D4-11D9-A004-000D93C47836@xcllnt.net> In-Reply-To: <4781326B-65D4-11D9-A004-000D93C47836@xcllnt.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms040203020202010905010202" X-Scanned-By: MIMEDefang 2.43 on UQ Mailhub Subject: Re: Fatal Trap 12: Page fault while in kernel mode (racoon/amd64/5.3-RELEASE-p4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 03:02:36 -0000 This is a cryptographically signed message in MIME format. --------------ms040203020202010905010202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Marcel Moolenaar wrote: > On Jan 13, 2005, at 5:34 PM, Matthew Sullivan wrote: > >>> >>> Hm, null pointer+offset dereference. Are you using IPSEC or >>> FAST_IPSEC in >>> your kernel? When did you grab the sources last? >>> >> IPSEC (see: http://www.au.sorbs.net/~matthew/freebsd/ for all kernel, >> config, cores and info I can give) >> >> Source was updated after finding this issue (within the last 10 days) >> and it made no difference. > > > Note that "setkey -D" should be enough to trigger the page fault on > amd64. > Note also that i386 and ia64 don't have this problem. I don't know about > alpha or sparc64, but it looks amd64 specific. Yup, with the same config there was no issue on my PII 450 so I guessed it was either AMD64 or a general 64-Bit issue and the setkey -D ... you're not wrong ;-) Fatal trap 12: page fault while in kernel mode fault virtual address = 0x39 fault code = supervisor write, page not present instruction pointer = 0x8:0xffffffff80307a70 stack pointer = 0x10:0xffffffff94f08860 frame pointer = 0x10:0xffffffff94f08960 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 2736 (setkey) [thread 100095] Stopped at keydb_newsecasvar+0x100: decl %ecx db> where keydb_newsecasvar() at keydb_newsecasvar+0x100 raw_usend() at raw_usend+0x60 key_send() at key_send+0xa sosend() at sosend+0x626 kern_sendit() at kern_sendit+0x113 sendit() at sendit+0x5f sendto() at sendto+0x4d syscall() at syscall+0x50c Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (133, FreeBSD ELF64, sendto), rip = 0x80079cda8, rsp = 0x7fffffff6c58, rbp = 0x7fffffffed20 --- Regards, -- Matthew Sullivan Specialist Systems Programmer Information Technology Services The University of Queensland --------------ms040203020202010905010202 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIG7DCC A3IwggJaoAMCAQICASowDQYJKoZIhvcNAQEEBQAwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQI EwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNp dHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2 aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUgU2VydmVyMB4XDTA0MDEyMTIzMzYyMVoXDTA2 MDEyMTIzMzYyMVowgbIxCzAJBgNVBAYTAkFVMSUwIwYDVQQKExxUaGUgVW5pdmVyc2l0eSBv ZiBRdWVlbnNsYW5kMScwJQYDVQQLEx5JbmZvcm1hdGlvbiBUZWNub2xvZ3kgU2VydmljZXMx FjAUBgoJkiaJk/IsZAEBEwZjY21hdHQxGTAXBgNVBAMTEE1hdHRoZXcgU3VsbGl2YW4xIDAe BgkqhkiG9w0BCQEWEW1hdHRoZXdAdXEuZWR1LmF1MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJB AJsUfrw/QUqKIzDverWc2F4GFFRZmIeO+bAl+7BM6x/9frMzOtygx4QGb4oQwtOE8Sda1aIs v+yJF3Di9EuUyvMCAwEAAaNoMGYwDgYDVR0PAQH/BAQDAgXgMBEGCWCGSAGG+EIBAQQEAwIF oDAfBgNVHSMEGDAWgBQmqtoyueiWTYZBinvsnzeOWLtUuzAgBgNVHREEGTAXgRVtYXR0aGV3 QGl0cy51cS5lZHUuYXUwDQYJKoZIhvcNAQEEBQADggEBAF2gZrkqZsZlHd4K/+yBN6qrpD61 hctDf7/Eg4jk6DMknEs6nvHMFUMZ4SXvkqPLnHBygTARKAs7qBSLd7mUUBOOQEgk6ovQVY6S 1CDSt3P9O6wjG0K1igtk8v6u7lkQ8p2STXqrOePVINdaucUgBO/IpeUtt9ATl1qvPTWyM/fz oUZsIKeYjNQVEQsuimrZjdbIAFxdl1fggSngUv64wBn8wCssGrPZIZA2lpBBEW1wejoWrDOH IIr+SspGd0i8MovDTMRSvgTERLki17FU/ANilcrSXiODKeIvpXhnQqVScnsoMSZmBmN2QIoG SnBjNK5mYxx5E3v20VOwtP1hVdEwggNyMIICWqADAgECAgEqMA0GCSqGSIb3DQEBBAUAMIGj MQswCQYDVQQGEwJBVTETMBEGA1UECBMKUXVlZW5zbGFuZDERMA8GA1UEBxMIQnJpc2JhbmUx JTAjBgNVBAoTHFRoZSBVbml2ZXJzaXR5IG9mIFF1ZWVuc2xhbmQxKDAmBgNVBAsTH0luZm9y bWF0aW9uIFRlY2hub2xvZ3kgU2VydmljZXMxGzAZBgNVBAMTEkNlcnRpZmljYXRlIFNlcnZl cjAeFw0wNDAxMjEyMzM2MjFaFw0wNjAxMjEyMzM2MjFaMIGyMQswCQYDVQQGEwJBVTElMCMG A1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEnMCUGA1UECxMeSW5mb3JtYXRp b24gVGVjbm9sb2d5IFNlcnZpY2VzMRYwFAYKCZImiZPyLGQBARMGY2NtYXR0MRkwFwYDVQQD ExBNYXR0aGV3IFN1bGxpdmFuMSAwHgYJKoZIhvcNAQkBFhFtYXR0aGV3QHVxLmVkdS5hdTBc MA0GCSqGSIb3DQEBAQUAA0sAMEgCQQCbFH68P0FKiiMw73q1nNheBhRUWZiHjvmwJfuwTOsf /X6zMzrcoMeEBm+KEMLThPEnWtWiLL/siRdw4vRLlMrzAgMBAAGjaDBmMA4GA1UdDwEB/wQE AwIF4DARBglghkgBhvhCAQEEBAMCBaAwHwYDVR0jBBgwFoAUJqraMrnolk2GQYp77J83jli7 VLswIAYDVR0RBBkwF4EVbWF0dGhld0BpdHMudXEuZWR1LmF1MA0GCSqGSIb3DQEBBAUAA4IB AQBdoGa5KmbGZR3eCv/sgTeqq6Q+tYXLQ3+/xIOI5OgzJJxLOp7xzBVDGeEl75Kjy5xwcoEw ESgLO6gUi3e5lFATjkBIJOqL0FWOktQg0rdz/TusIxtCtYoLZPL+ru5ZEPKdkk16qznj1SDX WrnFIATvyKXlLbfQE5darz01sjP386FGbCCnmIzUFRELLopq2Y3WyABcXZdX4IEp4FL+uMAZ /MArLBqz2SGQNpaQQRFtcHo6FqwzhyCK/krKRndIvDKLw0zEUr4ExES5ItexVPwDYpXK0l4j gyniL6V4Z0KlUnJ7KDEmZgZjdkCKBkpwYzSuZmMceRN79tFTsLT9YVXRMYIDQDCCAzwCAQEw gakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhCcmlz YmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UECxMf SW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNhdGUg U2VydmVyAgEqMAkGBSsOAwIaBQCgggItMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTA1MDExNDAzMDIwOFowIwYJKoZIhvcNAQkEMRYEFETEMZTMkGPndJ/p /PNHGKJ9SxnQMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIG6BgkrBgEEAYI3EAQx gawwgakwgaMxCzAJBgNVBAYTAkFVMRMwEQYDVQQIEwpRdWVlbnNsYW5kMREwDwYDVQQHEwhC cmlzYmFuZTElMCMGA1UEChMcVGhlIFVuaXZlcnNpdHkgb2YgUXVlZW5zbGFuZDEoMCYGA1UE CxMfSW5mb3JtYXRpb24gVGVjaG5vbG9neSBTZXJ2aWNlczEbMBkGA1UEAxMSQ2VydGlmaWNh dGUgU2VydmVyAgEqMIG8BgsqhkiG9w0BCRACCzGBrKCBqTCBozELMAkGA1UEBhMCQVUxEzAR BgNVBAgTClF1ZWVuc2xhbmQxETAPBgNVBAcTCEJyaXNiYW5lMSUwIwYDVQQKExxUaGUgVW5p dmVyc2l0eSBvZiBRdWVlbnNsYW5kMSgwJgYDVQQLEx9JbmZvcm1hdGlvbiBUZWNobm9sb2d5 IFNlcnZpY2VzMRswGQYDVQQDExJDZXJ0aWZpY2F0ZSBTZXJ2ZXICASowDQYJKoZIhvcNAQEB BQAEQGJyA77roiE96CLRRGcsvoBW5XAGiyd5ucbMu38uxrU/rNb7GJzcaAZf9qrXpd2hbZl6 iKn+VQFGzRxDu81TE04AAAAAAAA= --------------ms040203020202010905010202-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 03:26:06 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9084A16A4CE for ; Fri, 14 Jan 2005 03:26:06 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30B2E43D1D for ; Fri, 14 Jan 2005 03:26:06 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j0E3PxDf031145 for ; Thu, 13 Jan 2005 19:26:03 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200501140326.j0E3PxDf031145@gw.catspoiler.org> Date: Thu, 13 Jan 2005 19:25:59 -0800 (PST) From: Don Lewis To: current@FreeBSD.org In-Reply-To: <200501140106.j0E16atP030900@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Subject: Re: repeatable panic - ffs_blkfree: freeing free block X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 03:26:06 -0000 On 13 Jan, Don Lewis wrote: > I'm getting a repeatable panic when trying to build openoffice with a > 2005-01-12 kernel and world. I manually fsck'ed the file system > immediately before the build. The first panic happened during the > patching phase of the build. I tried again and this time the panic > happened during configuration. > > dev = da0s2a, block = 5090392, fs = /mnt > panic: ffs_blkfree: freeing free block > cpuid = 0 > KDB: enter: panic > [thread pid 55 tid 100043 ] > Stopped at kdb_enter+0x2c: leave > db> tr > Tracing pid 55 tid 100043 td 0xc22fa450 > kdb_enter(c0848a40,100,c22fa450,1361b80,4b5) at kdb_enter+0x2c > panic(c085f39d,c085f37d,c26cc280,4dac58,0) at panic+0x17f > ffs_blkfree(c2863800,c2987114,4dac58,0,4000) at ffs_blkfree+0x3a0 > indir_trunc(136b060,0,0,c,0,e4d5bc4c) at indir_trunc+0x1bf > handle_workitem_freeblocks(0,0,0,1,0) at handle_workitem_freeblocks+0x2e6 > process_worklist_item(41e7112d,0,0,c247d2bc,23) at process_worklist_item+0x1c0 > softdep_process_worklist(0,29,41e7112d,1,0) at softdep_process_worklist+0x66 > sched_sync(0,e4d5bd48,0,c0677b60,0) at sched_sync+0x3b2 > fork_exit(c0677b60,0,e4d5bd48) at fork_exit+0x7e > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xe4d5bd7c, ebp = 0 --- > > The kernel was built with INVARIANTS, WITNESS, and DEBUG_VFS_LOCKS. > > I was able to get a crash dump from the first panic, so at least doadump > works for me. > > After the crash, fsck reports some unexpected damage: > PARTIALLY TRUNCATED INODE I=127552 > but this inode doesn't seem to be associated with the block number in > the panic message. > % fsdb /dev/da0s2a > ** /dev/da0s2a (NO WRITE) > Editing file system `/dev/da0s2a' > Last Mounted on /mnt > current inode: directory > I=2 MODE=40755 SIZE=512 > MTIME=Feb 14 11:55:43 2004 [0 nsec] > CTIME=Feb 14 11:55:43 2004 [0 nsec] > ATIME=Jan 13 16:15:58 2005 [0 nsec] > OWNER=root GRP=wheel LINKCNT=7 FLAGS=0 BLKCNT=4 GEN=53557245 > fsdb (inum: 2)> inode 127552 > current inode: regular file > I=127552 MODE=100644 SIZE=1932 > MTIME=Dec 22 07:47:38 2003 [0 nsec] > CTIME=Dec 22 07:47:38 2003 [0 nsec] > ATIME=Dec 22 07:57:30 2003 [0 nsec] > OWNER=root GRP=wheel LINKCNT=1 FLAGS=0 BLKCNT=4 GEN=1442a6af > fsdb (inum: 127552)> blocks > Blocks for inode 127552: > Direct blocks: > 533086 (1 frag) Some other interesting bits of data: The file in question is /mnt/usr/ports/editors/openoffice-1.1/work/config_office/configure The inode number of this file is same as the inum parameter to ffs_blkfree(). The panic occurs while this script is being executed. Some more of the fsck output: ** /dev/da0s2a (NO WRITE) ** Last Mounted on /mnt ** Phase 1 - Check Blocks and Sizes PARTIALLY TRUNCATED INODE I=1275522 SALVAGE? no INCORRECT BLOCK COUNT I=1275522 (416 should be 704) CORRECT? no INCORRECT BLOCK COUNT I=1282133 (704 should be 384) CORRECT? no It looks like inode 1282133 has been deleted because I can't find it in the file system tree. If I use fsdb to find the first few block numbers and dump them out, I see the following: # Generated by GNU Autoconf 2.59. # # Copyright (C) 2003 Free Software Foundation, Inc. # This configure script is free software; the Free Software Foundation # gives unlimited permission to copy, distribute and modify it. ## --------------------- ## ## M4sh Initialization. ## ## --------------------- ## # Be Bourne compatible if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then emulate sh NULLCMD=: # Zsh 3.x and 4.x performs word splitting on ${1+"$@"}, which # is contrary to our usage. Disable this feature. alias -g '${1+"$@"}'='"$@"' elif test -n "${BASH_VERSION+set}" && (set -o posix) >/dev/null 2>&1; then set -o posix fi DUALCASE=1; export DUALCASE # for MKS sh # Support unset when possible. if ( (MAIL=60; unset MAIL) || exit) >/dev/null 2>&1; then as_unset=unset else as_unset=false fi # Work around bugs in pre-3.0 UWIN ksh. $as_unset ENV MAIL MAILPATH PS1='$ ' PS2='> ' PS4='+ ' # NLS nuisances. for as_var in \ LANG LANGUAGE LC_ADDRESS LC_ALL LC_COLLATE LC_CTYPE LC_IDENTIFICATION \ LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER \ LC_TELEPHONE LC_TIME do if (set +x; test -z "`(eval $as_var=C; export $as_var) 2>&1`"); then eval $as_var=C; export $as_var else $as_unset $as_var fi done [snip] whereas .../work/config_office/configure starts out: #! /bin/sh # From configure.in Revision: 1.55.6.10 . # Guess values for system-dependent variables and create Makefiles. # Generated by GNU Autoconf 2.59. # # Copyright (C) 2003 Free Software Foundation, Inc. # This configure script is free software; the Free Software Foundation # gives unlimited permission to copy, distribute and modify it. ## --------------------- ## ## M4sh Initialization. ## ## --------------------- ## # Be Bourne compatible if test -n "${ZSH_VERSION+set}" && (emulate sh) >/dev/null 2>&1; then emulate sh NULLCMD=: # Zsh 3.x and 4.x performs word splitting on ${1+"$@"}, which # is contrary to our usage. Disable this feature. alias -g '${1+"$@"}'='"$@"' elif test -n "${BASH_VERSION+set}" && (set -o posix) >/dev/null 2>&1; then set -o posix fi DUALCASE=1; export DUALCASE # for MKS sh # Support unset when possible. if ( (MAIL=60; unset MAIL) || exit) >/dev/null 2>&1; then as_unset=unset else as_unset=false fi # Work around bugs in pre-3.0 UWIN ksh. $as_unset ENV MAIL MAILPATH PS1='$ ' PS2='> ' PS4='+ ' # NLS nuisances. for as_var in \ LANG LANGUAGE LC_ADDRESS LC_ALL LC_COLLATE LC_CTYPE LC_IDENTIFICATION \ LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER \ LC_TELEPHONE LC_TIME do if (set +x; test -z "`(eval $as_var=C; export $as_var) 2>&1`"); then eval $as_var=C; export $as_var else $as_unset $as_var fi done It looks like the configure script has just been regenerated and a bug is being triggered by executing the script shortly after the script file was regenerated and before softupdates has flushed the changes to disk. I cleaned things up and ran "make extract". I don't see anything that has the contents seen in inode 1282133, so I suspect it is a temporary file. The configure script starts off: #! /bin/sh # From configure.in Revision: 1.55.6.9.4.2 . [snip] so the configure script is definitely being regenerated (and the configure.in script is $Revision: 1.55.6.10). The file system in question is UFS2 with the default 16K/2K block/fragment sizes. From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 06:48:03 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E22AC16A4CE; Fri, 14 Jan 2005 06:48:03 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8CC5843D55; Fri, 14 Jan 2005 06:48:03 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.13.1) with ESMTP id j0E6m6xW010894; Fri, 14 Jan 2005 01:48:06 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.13.1/Submit) id j0E6m6hA010893; Fri, 14 Jan 2005 01:48:06 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Fri, 14 Jan 2005 01:48:06 -0500 From: David Schultz To: Tim Kientzle Message-ID: <20050114064806.GA10856@VARK.MIT.EDU> Mail-Followup-To: Tim Kientzle , Pawel Jakub Dawidek , "'freebsd-current@freebsd.org'" References: <200501120735.j0C7ZABq048856@repoman.freebsd.org> <41E5ED66.4070902@freebsd.org> <20050113072153.GA28485@VARK.MIT.EDU> <41E716F3.20504@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41E716F3.20504@freebsd.org> cc: "'freebsd-current@freebsd.org'" cc: Pawel Jakub Dawidek Subject: Re: fts improvements, alternatives X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 06:48:04 -0000 On Thu, Jan 13, 2005, Tim Kientzle wrote: > [Moved to -current for further discussion.] > > David Schultz wrote: > >Tim Kientzle wrote: > >>Pawel Jakub Dawidek wrote: > >> > >>>Introduce new field 'fts_bignum' ... > >>>This work is part of the BigDisk project: > >>> http://www.FreeBSD.org/projects/bigdisk/ > >> > >>Any plans to deal with other fts limits ... ? > > > >Removing FTS_LOGICAL's path length limitation is nontrivial, but > >given your experience with bsdtar, I'd say you're an ideal person > >to do it. ;-) > > As it happens, I started tinkering with these ideas a > while ago but haven't found time to finish it all. > > Here's a snapshot of the current WIP: > > http://people.freebsd.org/~kientzle/libarchive/src/tree.tgz Nice. That's much cleaner than the fts implementation (although it doesn't do all that fts does.) So tell me again: when did you say were you planning on rewriting/fixing fts? ;-) From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 07:38:05 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22B5D16A4CE; Fri, 14 Jan 2005 07:38:05 +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 2D4E943D54; Fri, 14 Jan 2005 07:38:04 +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 j0E7c3OZ028482; Thu, 13 Jan 2005 23:38:03 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <41E776DA.6080809@freebsd.org> Date: Thu, 13 Jan 2005 23:38:02 -0800 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: David Schultz References: <200501120735.j0C7ZABq048856@repoman.freebsd.org> <41E5ED66.4070902@freebsd.org> <20050113072153.GA28485@VARK.MIT.EDU> <41E716F3.20504@freebsd.org> <20050114064806.GA10856@VARK.MIT.EDU> In-Reply-To: <20050114064806.GA10856@VARK.MIT.EDU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: "'freebsd-current@freebsd.org'" cc: Pawel Jakub Dawidek Subject: Re: fts improvements, alternatives X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 07:38:05 -0000 David Schultz wrote: > On Thu, Jan 13, 2005, Tim Kientzle wrote: >> >>As it happens, I started tinkering with these ideas >>[about a better way to traverse directory trees] a >>while ago but haven't found time to finish it all. >> >>Here's a snapshot of the current WIP: >> >>http://people.freebsd.org/~kientzle/libarchive/src/tree.tgz > > Nice. That's much cleaner than the fts implementation (although > it doesn't do all that fts does.) So tell me again: when did you > say were you planning on rewriting/fixing fts? ;-) The basic problems with fts are hard to fix without breaking the API badly. On the other hand, augmenting "tree" to the point that it can replace fts in many (but not all) applications would interest me. Since you've done more work with fts-using applications than I have recently, you tell me: What does "tree" absolutely require to be usable in a broad cross-section of applications? It already does what bsdtar needs, of course. Accepting a sort parameter is probably not in the making, of course. Part of the whole point to "tree" is that it doesn't store a lot of data at one time. fts has to be better at something, right? ;-) Tim From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 11:06:48 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DA6716A4CE for ; Fri, 14 Jan 2005 11:06:48 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27EE143D41 for ; Fri, 14 Jan 2005 11:06:48 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j0EB6eFa032116; Fri, 14 Jan 2005 03:06:44 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200501141106.j0EB6eFa032116@gw.catspoiler.org> Date: Fri, 14 Jan 2005 03:06:40 -0800 (PST) From: Don Lewis To: current@FreeBSD.org In-Reply-To: <200501140326.j0E3PxDf031145@gw.catspoiler.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: mckusick@mckusick.com Subject: Re: repeatable panic - ffs_blkfree: freeing free block X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 11:06:48 -0000 On 13 Jan, Don Lewis wrote: > On 13 Jan, Don Lewis wrote: >> I'm getting a repeatable panic when trying to build openoffice with a >> 2005-01-12 kernel and world. I manually fsck'ed the file system >> immediately before the build. The first panic happened during the >> patching phase of the build. I tried again and this time the panic >> happened during configuration. >> >> dev = da0s2a, block = 5090392, fs = /mnt >> panic: ffs_blkfree: freeing free block >> cpuid = 0 >> KDB: enter: panic >> [thread pid 55 tid 100043 ] >> Stopped at kdb_enter+0x2c: leave >> db> tr >> Tracing pid 55 tid 100043 td 0xc22fa450 >> kdb_enter(c0848a40,100,c22fa450,1361b80,4b5) at kdb_enter+0x2c >> panic(c085f39d,c085f37d,c26cc280,4dac58,0) at panic+0x17f >> ffs_blkfree(c2863800,c2987114,4dac58,0,4000) at ffs_blkfree+0x3a0 >> indir_trunc(136b060,0,0,c,0,e4d5bc4c) at indir_trunc+0x1bf >> handle_workitem_freeblocks(0,0,0,1,0) at handle_workitem_freeblocks+0x2e6 >> process_worklist_item(41e7112d,0,0,c247d2bc,23) at process_worklist_item+0x1c0 >> softdep_process_worklist(0,29,41e7112d,1,0) at softdep_process_worklist+0x66 >> sched_sync(0,e4d5bd48,0,c0677b60,0) at sched_sync+0x3b2 >> fork_exit(c0677b60,0,e4d5bd48) at fork_exit+0x7e >> fork_trampoline() at fork_trampoline+0x8 >> --- trap 0x1, eip = 0, esp = 0xe4d5bd7c, ebp = 0 --- > It looks like the configure script has just been regenerated and a bug > is being triggered by executing the script shortly after the script file > was regenerated and before softupdates has flushed the changes to disk. It appears that executing the configure script isn't necessary. I can execute this: # make extract patch build-depends lib-depends misc-depends \ configure-message pre-configure pre-configure-script patch-autotools and things are fine, but I get the panic shortly after I run this: # make run-autotools Another interesting bit of information is that the problem goes away if I unmount and remount the file system between the patch-autotools and run-autotools steps. I was able to loop over the whole sequence from "make clean" to "make run-autotools" ten times without failure. On the other hand, doing "sync; sleep 60" instead of unmounting and remounting the file system does not seem to help and the system still panics. Doing fsync /mnt/usr/ports/editors/openoffice-1.1/work/config_office/configure doesn't solve the problem, either. From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 11:55:45 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6451116A4CE; Fri, 14 Jan 2005 11:55:45 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1C4F43D2D; Fri, 14 Jan 2005 11:55:44 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id j0EBtiZl023667; Fri, 14 Jan 2005 06:55:44 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.1/8.13.1) with ESMTP id j0EBthcD083816; Fri, 14 Jan 2005 06:55:43 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 01B777306E; Fri, 14 Jan 2005 06:55:43 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050114115543.01B777306E@freebsd-current.sentex.ca> Date: Fri, 14 Jan 2005 06:55:43 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/649/Sun Jan 2 18:02:22 2005 clamav-milter version 0.80j on clamscanner3 X-Virus-Status: Clean Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 11:55:45 -0000 TB --- 2005-01-14 10:30:06 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-14 10:30:06 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-01-14 10:30:06 - checking out the source tree TB --- 2005-01-14 10:30:06 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-01-14 10:30:06 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-01-14 10:35:56 - building world (CFLAGS=-O2 -pipe) TB --- 2005-01-14 10:35:56 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-01-14 10:35:56 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-01-14 11:42:25 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-01-14 11:42:25 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-01-14 11:42:25 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Fri Jan 14 11:42:25 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Fri Jan 14 11:54:25 UTC 2005 TB --- 2005-01-14 11:54:25 - generating LINT kernel config TB --- 2005-01-14 11:54:25 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- 2005-01-14 11:54:25 - /usr/bin/make -B LINT TB --- 2005-01-14 11:54:26 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-01-14 11:54:26 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-01-14 11:54:26 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Jan 14 11:54:26 UTC 2005 >>> 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 [...] awk -f /tinderbox/CURRENT/sparc64/sparc64/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/sparc64/sparc64/src/sys/libkern/iconv_converter_if.m -h awk -f /tinderbox/CURRENT/sparc64/sparc64/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/ofw/ofw_bus_if.m -h awk -f /tinderbox/CURRENT/sparc64/sparc64/src/sys/tools/makeobjops.awk /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/pci/ofw_pci_if.m -h if [ -f .olddep ]; then mv .olddep .depend; fi rm -f .newdep /home/tinderbox/CURRENT/sparc64/sparc64/obj/tinderbox/CURRENT/sparc64/sparc64/src/make.i386/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP="cc -E" CC="cc" xargs mkdep -a -f .newdep -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-gr owth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding /tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/syscons/snake/snake_saver.c:40:32: machine/pc/display.h: No such file or directory mkdep: compile failed *** 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/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 --- 2005-01-14 11:55:43 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-01-14 11:55:43 - ERROR: failed to build lint kernel TB --- 2005-01-14 11:55:43 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 16:00:09 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C67416A4CE for ; Thu, 13 Jan 2005 16:00:09 +0000 (GMT) Received: from mail.dt.e-technik.uni-dortmund.de (mail.dt.e-technik.Uni-Dortmund.DE [129.217.163.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E56A43D46 for ; Thu, 13 Jan 2005 16:00:08 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: from localhost (localhost [127.0.0.1])6939E4CB2F; Thu, 13 Jan 2005 17:00:07 +0100 (CET) Received: from mail.dt.e-technik.uni-dortmund.de ([127.0.0.1]) by localhost (krusty [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 06658-01-16; Thu, 13 Jan 2005 17:00:06 +0100 (CET) Received: from m2a2.dyndns.org (p548548EF.dip.t-dialin.net [84.133.72.239]) 7ED4E4CB27; Thu, 13 Jan 2005 17:00:06 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 5C4CC87683; Thu, 13 Jan 2005 17:00:06 +0100 (CET) Received: from merlin.emma.line.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 22636-02; Thu, 13 Jan 2005 17:00:04 +0100 (CET) Received: by merlin.emma.line.org (Postfix, from userid 500) id D403D87684; Thu, 13 Jan 2005 17:00:04 +0100 (CET) From: Matthias Andree To: Michael Class In-Reply-To: <41E568CE.9030905@gmx.de> (Michael Class's message of "Wed, 12 Jan 2005 19:13:34 +0100") References: <41E568CE.9030905@gmx.de> Date: Thu, 13 Jan 2005 17:00:04 +0100 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new at dt.e-technik.uni-dortmund.de X-Mailman-Approved-At: Fri, 14 Jan 2005 13:02:12 +0000 cc: current@freebsd.org Subject: Re: SIL3112 and Maxtor 6Y160M0 SATA Disk: DMA Failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 16:00:09 -0000 Michael Class writes: > recently I have added a cheap SIL3112 SATA controller in my system. --------- The chip is buggy. Does the seller offer you to return that product and buy something else in exchange? If recently is within a week or two, some offer such "Umtausch" options. -- Matthias Andree From owner-freebsd-current@FreeBSD.ORG Thu Jan 13 22:01:06 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BE6516A4CE for ; Thu, 13 Jan 2005 22:01:06 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE8CD43D1F for ; Thu, 13 Jan 2005 22:01:05 +0000 (GMT) (envelope-from imp@harmony.village.org) Received: from localhost (localhost [IPv6:::1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j0DLxF9v010116; Thu, 13 Jan 2005 14:59:15 -0700 (MST) (envelope-from imp@harmony.village.org) Date: Thu, 13 Jan 2005 14:59:06 -0700 (MST) Message-Id: <20050113.145906.74740364.imp@harmony.village.org> To: kwm@rainbow-runner.nl From: Warner Losh In-Reply-To: <1105645560.8933.4.camel@heater.rainbow-runner.nl> References: <1105227700.25419.14.camel@heater.rainbow-runner.nl> <20050110.235528.25732845.imp@bsdimp.com> <1105645560.8933.4.camel@heater.rainbow-runner.nl> 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 X-Mailman-Approved-At: Fri, 14 Jan 2005 13:02:12 +0000 cc: freebsd-current@freebsd.org cc: imp@bsdimp.com Subject: Re: cbb0: CardBus card activation failed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2005 22:01:06 -0000 From: Koop Mast Subject: Re: cbb0: CardBus card activation failed Date: Thu, 13 Jan 2005 20:46:00 +0100 > Op ma, 10-01-2005 te 23:55 -0700, schreef M. Warner Losh: > > In message: <1105227700.25419.14.camel@heater.rainbow-runner.nl> > > Koop Mast writes: > > : I got myself an 3Com wireless card based on the Atheros 5212 chip. > > : After inserting it in the first pcmcia slot the kernel tells me this: > > : > > : cbb0: CardBus card activation failed > > > > This line has zero content. It just means that the driver didn't > > attach, but doesn't tell me why... What are the lines before it. > > Sorry for the wait, I wrecked my imap when I upgraded it. > Here its is with hw.cbb.debug=1, hw.pccard.debug=1, hw.cardbus.debug=1 > and boot -v. The complete dmesg is here: > http://prisma.rainbow-runner.nl/kwm/dmesg-ath . Thanks for the info. Sadly, I wasn't able to get anything useful out of it :-(. I'll look into adding some better debugging to try to sort out what's going on. It is safe to assume that if you insert/remove the card N times into slot 1, it will fail every time, right? Warner From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 07:38:11 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2931E16A4CF for ; Fri, 14 Jan 2005 07:38:11 +0000 (GMT) Received: from grerelbul01.net.external.hp.com (grerelbul01.net.external.hp.com [155.208.255.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45AD643D53 for ; Fri, 14 Jan 2005 07:38:10 +0000 (GMT) (envelope-from michaelc@tmbbobmc.bbn.hp.com) Received: from ebsc01.bbn.hp.com (ebsc01.bbn.hp.com [15.136.121.146]) by grerelbul01.net.external.hp.com (Postfix) with ESMTP id 20AD337F6D; Fri, 14 Jan 2005 08:38:35 +0100 (CET) Received: from tmbbobmc.bbn.hp.com (tmbbobmc.bbn.hp.com [15.136.123.54]) ESMTP id IAA10679; Fri, 14 Jan 2005 08:41:55 +0100 (MET) Received: from tmbbobmc.bbn.hp.com (localhost.localdomain [127.0.0.1]) by tmbbobmc.bbn.hp.com (8.12.11/8.12.11) with ESMTP id j0E7cvhl005217; Fri, 14 Jan 2005 08:38:57 +0100 Received: from localhost (michaelc@localhost)j0E7cvbS005214; Fri, 14 Jan 2005 08:38:57 +0100 Date: Fri, 14 Jan 2005 08:38:56 +0100 (CET) From: Michael Class To: "Daniel O'Connor" In-Reply-To: <200501141112.00237.doconnor@gsoft.com.au> Message-ID: References: <41E568CE.9030905@gmx.de> <200501141112.00237.doconnor@gsoft.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 14 Jan 2005 13:02:12 +0000 cc: current@freebsd.org Subject: Re: SIL3112 and Maxtor 6Y160M0 SATA Disk: DMA Failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: michael.class@gmx.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 07:38:11 -0000 On Fri, 14 Jan 2005, Daniel O'Connor wrote: > On Thu, 13 Jan 2005 04:43, Michael Class wrote: >> Unfortunately when I do attach my Maxtor SATA disk to this controller >> I do only get DMA errors. This is all on a recent 6.0-CURRENT system >> and can be reproduced with a GENERIC kernel. >> Anything I could do to track this further down? > > I good start would be to post the stack trace of the crash.. Thank you for your answer! Sorry for not making myself clear enough. The system does not crash! So there are obviously no stack traces of crashes ... The attached disk (ad4) simply does not work, generating DMA errors that can be seen in the verbose bootlog that was attached to my first mail. The disk by itself seems to be o.k. as it is working on an other system running FBSD 6.0-current attached to a Promise SATA controller. The lines that are relevant to this in the bootlog seem to be: (but I attached the whole log to the original mail, so that someone who might be interessted can read more about the exact specification of the system used) ... atapci1: port 0xac00-0xac0f,0xb000-0xb003,0xb400-0xb407,0xb800-0xb803,0xbc00-0xbc07 mem 0xdffffc00-0xdffffdff irq 17 at device 13.0 on pci0 ... ad4: ATA-7 disk at ata2-master ad4: 156334MB (320173056 sectors), 317632 C, 16 H, 63 S, 512 B ad4: 16 secs/int, 1 depth queue, SATA150 ... GEOM: new disk ad4 ad4: TIMEOUT - READ_DMA retrying (2 retries left) LBA=0 ata2: reiniting channel .. .... ata2: reset tp1 mask=01 ostat0=50 ostat1=00 ad4: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: resetting done .. ad4: pio=0x0c wdma=0x22 udma=0x46 cable=40pin ata2: device config done .. ad4: TIMEOUT - READ_DMA retrying (1 retry left) LBA=0 ata2: reiniting channel .. ata2: reset tp1 mask=01 ostat0=50 ostat1=00 ad4: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: resetting done .. ad4: pio=0x0c wdma=0x22 udma=0x46 cable=40pin ata2: device config done .. ata2: reiniting channel .. ata2: reset tp1 mask=01 ostat0=50 ostat1=00 ad4: stat=0x50 err=0x01 lsb=0x00 msb=0x00 ata2: reset tp2 stat0=50 stat1=00 devices=0x1 ata2: resetting done .. ad4: pio=0x0c wdma=0x22 udma=0x46 cable=40pin ata2: device config done .. ad4: FAILURE - READ_DMA timed out ad4: FAILURE - READ_DMA status=51 error=4 LBA=0 Thank you Michael From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 13:30:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40B2C16A4D9; Fri, 14 Jan 2005 13:30:35 +0000 (GMT) Received: from alpha.siliconlandmark.com (alpha.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3185843D45; Fri, 14 Jan 2005 13:30:31 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from alpha.siliconlandmark.com (andy@localhost [127.0.0.1]) j0EDUTsN049557; Fri, 14 Jan 2005 08:30:29 -0500 (EST) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost)j0EDUQSo049554; Fri, 14 Jan 2005 08:30:29 -0500 (EST) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: alpha.siliconlandmark.com: andy owned process doing -bs Date: Fri, 14 Jan 2005 08:30:26 -0500 (EST) From: Andre Guibert de Bruet To: Peter Jeremy In-Reply-To: <20050112105034.GA51959@cirb503493.alcatel.com.au> Message-ID: <20050114082713.S49498@alpha.siliconlandmark.com> References: <16749.21420.643438.983797@ran.psg.com> <20041014121852.GB28875@samodelkin.net> <20050112105034.GA51959@cirb503493.alcatel.com.au> 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: FreeBSD Current cc: Anton Berezin Subject: Re: beating mergemaster to /etc/rc.d X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 13:30:35 -0000 On Wed, 12 Jan 2005, Peter Jeremy wrote: > On Wed, 2005-Jan-12 09:33:00 +0100, Anton Berezin wrote: >> A colleague of mine came up with an idea which I did not see before: >> >> Optionally, if CVS revisions are different, and CVS repository is >> available, fetch the file with the same revision as the installed one >> from CVS, and compare it with the installed one. If they are identical, >> mergemaster can safely assume that the file was not modified by hand and >> can therefore overwrite it without doing a diff loop hoop-la. > > I think this has been suggested before but you are the first person to > actually code it. Thank you. > > Note that there are still risks in blindly applying CVS changes. There > have been a couple of cases where defaults have changed meaning that > corresponding changes to local system configuration is required to > retain previous behaviour. One would have to use the -R flag to obtain this behavior. Blindly running mergemaster -i isn't going to be affected by this. If you follow the recommended system upgrade path, you would have read UPDATING before the installkernel and reboot anyway... ;) Cheers, Andy | Andre Guibert de Bruet | Enterprise Software Consultant > | Silicon Landmark, LLC. | http://siliconlandmark.com/ > From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 16:44:40 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E7DC016A4CE for ; Fri, 14 Jan 2005 16:44:40 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F1B643D1D for ; Fri, 14 Jan 2005 16:44:40 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id j0EGiamU094207; Fri, 14 Jan 2005 17:44:38 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <41E7F6BE.9070308@DeepCore.dk> Date: Fri, 14 Jan 2005 17:43:42 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Class References: <41E568CE.9030905@gmx.de> In-Reply-To: <41E568CE.9030905@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.6 cc: current@freebsd.org Subject: Re: SIL3112 and Maxtor 6Y160M0 SATA Disk: DMA Failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 16:44:41 -0000 Michael Class wrote: > recently I have added a cheap SIL3112 SATA controller in my system. My condolences.. > Unfortunately when I do attach my Maxtor SATA disk to this controller > I do only get DMA errors. This is all on a recent 6.0-CURRENT system > and can be reproduced with a GENERIC kernel. The SiI3112 silicon is so bug ridden its not even funny. I suggest you return that piece of crap to the vendor that sold it to=20 you and get somthing that works. If thats not an option and you have plenty of time, you can try to=20 experiment with all PCI and memory options in your BIOS, maybe you can=20 find a combination that make it work. Beware of silent datacorruption and that sort of thing though... Good luck! -S=F8ren From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 17:29:28 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79BFE16A4CE for ; Fri, 14 Jan 2005 17:29:28 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0126A43D5E for ; Fri, 14 Jan 2005 17:29:28 +0000 (GMT) (envelope-from geekout@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so770627wri for ; Fri, 14 Jan 2005 09:29:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=hkSQ/tuqKmns43lb2dsYkKNHmEqibRfns/ZGghnK8MClCoZrdp2idd4pAtd8lFe/tYkp3P2WdUZTAobB4vz+nLF0OzvvS6evlAA9J+LkWTrkxQKUNeXxgVmQxJX/O5EGVqmALzl+2Y8PrLT22Xswa/HGeWBSbXnY8NVZdgqTDRU= Received: by 10.54.2.54 with SMTP id 54mr148766wrb; Fri, 14 Jan 2005 09:29:27 -0800 (PST) Received: by 10.54.46.25 with HTTP; Fri, 14 Jan 2005 09:29:27 -0800 (PST) Message-ID: <6e01203b0501140929dd69bc7@mail.gmail.com> Date: Fri, 14 Jan 2005 10:29:27 -0700 From: Tyler Gee To: Matteo Riondato In-Reply-To: <1105453822.21117.17.camel@kaiser.sig11.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1105453822.21117.17.camel@kaiser.sig11.org> cc: deischen@freebsd.org cc: freebsd-current@freebsd.org Subject: Re: firefox coredumping in recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Tyler Gee List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 17:29:28 -0000 I haven't been able to figure anything out and I am still dumping. If others want to check out the page I am using go to http://www.ucreditu.com and hit the "Log In" graphic in the top right. You don't actually need to log in as my firefox will crash either immediately after clicking the link or about five seconds into the page load after clicking the link. This is the one site where it crashes for me every single time. On Tue, 11 Jan 2005 15:30:22 +0100, Matteo Riondato wrote: > On 11-01-2005, Daniel Eischen wrote: > > On Tue, 11 Jan 2005, Matteo Riondato wrote: > > > > > On 10-01-2005 at 04:07 +0000, Jason Henson wrote: > > > > On 01/09/05 15:24:57, Matteo Riondato wrote: > > > > > Hi folks > > > > > I'm experimenting some core dumps with firefox on a recent curren > > > > Please see @ports. You need an updated linuxpluginwrapper. > > Ok, thanks. > > Best Regards > -- > Rionda aka Matteo Riondato > GUFI Staff Member (http://www.gufi.org) > FreeSBIE Developer (http://www.freesbie.org) > BSD-FAQ-it Main Developer (http://utenti.gufi.org/~rionda) > Sent from: kaiser.sig11.org running FreeBSD-6.0-CURRENT > > > From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 18:46:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDABA16A4CE; Fri, 14 Jan 2005 18:46:31 +0000 (GMT) Received: from ylpvm01.prodigy.net (ylpvm01-ext.prodigy.net [207.115.57.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D2D443D2D; Fri, 14 Jan 2005 18:46:31 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.0.34] (adsl-67-119-74-222.dsl.sntc01.pacbell.net [67.119.74.222])j0EIkUvE018736; Fri, 14 Jan 2005 13:46:30 -0500 Message-ID: <41E8137A.1050603@root.org> Date: Fri, 14 Jan 2005 10:46:18 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: xorg-server doesn't build? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 18:46:32 -0000 I'm not sure if ports@ is the right list for this, but I have this build problem for xorg-server on -current: making all in programs/Xserver/hw/xfree86/xf86cfg... rm -f interface.o cc -c -O2 -fno-strict-aliasing -pipe -ansi -pedantic -Wno-system-headers -Dasm=__asm -Wall -Wpointer-arith -Wundef -fno-merge-constants -I../common -I../scanpci -I../loader -I/usr/ports/x11-servers/xorg-server/work/xc/programs/Xserver/hw/xfree86/os-support -I/usr/ports/x11-servers/xorg-server/work/xc/programs/Xserver/include -I/usr/ports/x11-servers/xorg-server/work/xc/exports/include/X11 -I/usr/ports/x11-servers/xorg-server/work/xc/lib/font/include -I/usr/ports/x11-servers/xorg-server/work/xc -I/usr/ports/x11-servers/xorg-server/work/xc/exports/include -I/usr/X11R6/include -I/usr/X11R6/include -DCSRG_BASED -DSHAPE -DXINPUT -DXKB -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT -DDPMSExtension -DPANORAMIX -DRENDER -DRANDR -DXFIXES -DDAMAGE -DCOMPOSITE -DXEVIE -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV -DSINGLEDEPTH -DXFreeXDGA -DXvExtension -DXFree86LOADER -DXFree86Server -DXF86VIDMODE -DXvMCExtension -DSMART_SCHEDULE -DBUILDDEBUG -DXResExtension -DX_BYTE_ORDER=X_LITTLE_ENDIAN -DXORG_VERSION_CURRENT="(((6) * 10000000) + ((8) * 100000) + ((1) * 1000) + 0)" -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO -DXF86CONFIG=\"xorg.conf\" -DUSE_MODULES -DHAS_NCURSES -DPROJECT_ROOT=\"/usr/X11R6\" -DXF86CONFIGDIR=\"/usr/X11R6/lib/X11\" -DPCCONS_SUPPORT -DSYSCONS_SUPPORT -DPCVT_SUPPORT -D__XCONFIGFILE__='"xorg.conf"' -D__XCONFIGDIR__='"/usr/X11R6/lib/X11"' -D__XLOGFILE__='"Xorg"' -D__XSERVERNAME__='"Xorg"' -D__XKBDEFRULES__='"xorg"' interface.c interface.c: In function `Usage': interface.c:224: warning: string length `630' is greater than the length `509' ISO C89 compilers are required to support interface.c: In function `main': interface.c:411: error: `compositeWidgetClass' undeclared (first use in this function) interface.c:411: error: (Each undeclared identifier is reported only once interface.c:411: error: for each function it appears in.) *** Error code 1 Stop in /usr/ports/x11-servers/xorg-server/work/xc/programs/Xserver/hw/xfree86/xf86cfg. *** Error code 1 Stop in /usr/ports/x11-servers/xorg-server/work/xc/programs/Xserver/hw/xfree86. *** Error code 1 Stop in /usr/ports/x11-servers/xorg-server/work/xc/programs/Xserver. *** Error code 1 -- Nate From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 19:08:37 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8B1016A4CE for ; Fri, 14 Jan 2005 19:08:37 +0000 (GMT) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FC9943D31 for ; Fri, 14 Jan 2005 19:08:37 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) j0EJ8Z8s006696; Fri, 14 Jan 2005 14:08:35 -0500 (EST) Date: Fri, 14 Jan 2005 14:08:35 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Tyler Gee In-Reply-To: <6e01203b0501140929dd69bc7@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) cc: Matteo Riondato cc: freebsd-current@freebsd.org Subject: Re: firefox coredumping in recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 19:08:37 -0000 On Fri, 14 Jan 2005, Tyler Gee wrote: > I haven't been able to figure anything out and I am still dumping. > > If others want to check out the page I am using go to > http://www.ucreditu.com and hit the "Log In" graphic in the top right. > You don't actually need to log in as my firefox will crash either > immediately after clicking the link or about five seconds into the > page load after clicking the link. This is the one site where it > crashes for me every single time. Works for me. There is a flash advertisement on that page and it doesn't cause any problems for me with updated linuxpluginwrapper. Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20041122 Firefox/1.0 firefox-1.0_3,1 from ports. -- Dan Eischen From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 19:55:12 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 286CD16A4CE; Fri, 14 Jan 2005 19:55:12 +0000 (GMT) Received: from jail1-fbsd4.consiagnet.it (jail1-fbsd4.consiagnet.it [83.149.128.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9D2F743D53; Fri, 14 Jan 2005 19:55:11 +0000 (GMT) (envelope-from rionda@gufi.org) Received: from localhost.localdomain (unknown [82.52.112.71]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by jail1-fbsd4.consiagnet.it (Postfix) with ESMTP id 6937557F1; Fri, 14 Jan 2005 20:58:14 +0100 (CET) From: Matteo Riondato To: Daniel Eischen In-Reply-To: References: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Gtok8Ka1Hbn3Wvy51D6y" Date: Fri, 14 Jan 2005 20:55:08 +0100 Message-Id: <1105732508.25379.4.camel@kaiser.sig11.org> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port cc: freebsd-current@freebsd.org cc: Tyler Gee Subject: Re: firefox coredumping in recent current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 19:55:12 -0000 --=-Gtok8Ka1Hbn3Wvy51D6y Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 14-01-2005 at 14:08 -0500, Daniel Eischen wrote: >=20 >=20 > Works for me. =20 Just a me too, with up-to-date linuxpluginwrapper Best Regards --=20 Rionda aka Matteo Riondato GUFI Staff Member (http://www.gufi.org) FreeSBIE Developer (http://www.freesbie.org) BSD-FAQ-it Main Developer (http://utenti.gufi.org/~rionda) Sent from: kaiser.sig11.org running FreeBSD-6.0-CURRENT --=-Gtok8Ka1Hbn3Wvy51D6y Content-Type: application/pgp-signature; name=signature.asc Content-Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQBB6COc2Mp4pR7Fa+wRAu5jAJwMviJBaRlJTxRQc4bMFApLh1ayQgCePsNJ 7BWZGFrF32HAzvigSigatfA= =kpSD -----END PGP SIGNATURE----- --=-Gtok8Ka1Hbn3Wvy51D6y-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 20:52:49 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 604E716A4CE for ; Fri, 14 Jan 2005 20:52:49 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 4165943D46 for ; Fri, 14 Jan 2005 20:52:48 +0000 (GMT) (envelope-from emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 14 Jan 2005 20:52:47 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) (62.245.232.135) by mail.gmx.net (mp001) with SMTP; 14 Jan 2005 21:52:47 +0100 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-current@freebsd.org Date: Fri, 14 Jan 2005 21:52:35 +0100 User-Agent: KMail/1.7.2 References: <41E568CE.9030905@gmx.de> <41E7F6BE.9070308@DeepCore.dk> In-Reply-To: <41E7F6BE.9070308@DeepCore.dk> X-Birthday: 10/06/72 X-CelPhone: +49 173 9967781 X-Tel: +49 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart18747388.UNAQSZZG8b"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501142152.43282.emanuel.strobl@gmx.net> X-Y-GMX-Trusted: 0 cc: Michael Class cc: current@freebsd.org cc: =?iso-8859-1?q?S=F8ren_Schmidt?= Subject: Re: SIL3112 and Maxtor 6Y160M0 SATA Disk: DMA Failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 20:52:49 -0000 --nextPart18747388.UNAQSZZG8b Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Freitag, 14. Januar 2005 17:43 schrieb S=F8ren Schmidt: > Michael Class wrote: > > recently I have added a cheap SIL3112 SATA controller in my system. > > My condolences.. > > > Unfortunately when I do attach my Maxtor SATA disk to this controller > > I do only get DMA errors. This is all on a recent 6.0-CURRENT system > > and can be reproduced with a GENERIC kernel. > > The SiI3112 silicon is so bug ridden its not even funny. > > I suggest you return that piece of crap to the vendor that sold it to > you and get somthing that works. I can understand your comment but please extend it with some recommendation= s.=20 If anybody, you should know which controllers are reliable, os hw and sq=20 sight! =2DMano > > If thats not an option and you have plenty of time, you can try to > experiment with all PCI and memory options in your BIOS, maybe you can > find a combination that make it work. > > Beware of silent datacorruption and that sort of thing though... > > Good luck! > > -S=F8ren > > _______________________________________________ > 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" --nextPart18747388.UNAQSZZG8b Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBB6DEbBylq0S4AzzwRAo3KAKCNY3hysGTSLP5wPJIx9qRRwZXOtwCeMkNz axrbEPDNJ77a0TbkFimh7ew= =ZY+1 -----END PGP SIGNATURE----- --nextPart18747388.UNAQSZZG8b-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 20:52:49 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A45D16A4CF for ; Fri, 14 Jan 2005 20:52:49 +0000 (GMT) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 708C843D49 for ; Fri, 14 Jan 2005 20:52:48 +0000 (GMT) (envelope-from emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 14 Jan 2005 20:52:47 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) (62.245.232.135) by mail.gmx.net (mp001) with SMTP; 14 Jan 2005 21:52:47 +0100 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-current@freebsd.org Date: Fri, 14 Jan 2005 21:52:35 +0100 User-Agent: KMail/1.7.2 References: <41E568CE.9030905@gmx.de> <41E7F6BE.9070308@DeepCore.dk> In-Reply-To: <41E7F6BE.9070308@DeepCore.dk> X-Birthday: 10/06/72 X-CelPhone: +49 173 9967781 X-Tel: +49 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart18747388.UNAQSZZG8b"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200501142152.43282.emanuel.strobl@gmx.net> X-Y-GMX-Trusted: 0 cc: Michael Class cc: current@freebsd.org cc: =?iso-8859-1?q?S=F8ren_Schmidt?= Subject: Re: SIL3112 and Maxtor 6Y160M0 SATA Disk: DMA Failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 20:52:49 -0000 --nextPart18747388.UNAQSZZG8b Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Freitag, 14. Januar 2005 17:43 schrieb S=F8ren Schmidt: > Michael Class wrote: > > recently I have added a cheap SIL3112 SATA controller in my system. > > My condolences.. > > > Unfortunately when I do attach my Maxtor SATA disk to this controller > > I do only get DMA errors. This is all on a recent 6.0-CURRENT system > > and can be reproduced with a GENERIC kernel. > > The SiI3112 silicon is so bug ridden its not even funny. > > I suggest you return that piece of crap to the vendor that sold it to > you and get somthing that works. I can understand your comment but please extend it with some recommendation= s.=20 If anybody, you should know which controllers are reliable, os hw and sq=20 sight! =2DMano > > If thats not an option and you have plenty of time, you can try to > experiment with all PCI and memory options in your BIOS, maybe you can > find a combination that make it work. > > Beware of silent datacorruption and that sort of thing though... > > Good luck! > > -S=F8ren > > _______________________________________________ > 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" --nextPart18747388.UNAQSZZG8b Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBB6DEbBylq0S4AzzwRAo3KAKCNY3hysGTSLP5wPJIx9qRRwZXOtwCeMkNz axrbEPDNJ77a0TbkFimh7ew= =ZY+1 -----END PGP SIGNATURE----- --nextPart18747388.UNAQSZZG8b-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 21:04:00 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36E3416A4CE for ; Fri, 14 Jan 2005 21:04:00 +0000 (GMT) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7ED0C43D41 for ; Fri, 14 Jan 2005 21:03:59 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.143] (laptop.deepcore.dk [194.192.25.143]) by spider.deepcore.dk (8.12.11/8.12.10) with ESMTP id j0EL3tqI096455; Fri, 14 Jan 2005 22:03:57 +0100 (CET) (envelope-from sos@DeepCore.dk) Message-ID: <41E83386.1030206@DeepCore.dk> Date: Fri, 14 Jan 2005 22:03:02 +0100 From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= User-Agent: Mozilla Thunderbird 0.7.2 (X11/20040802) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Emanuel Strobl References: <41E568CE.9030905@gmx.de> <41E7F6BE.9070308@DeepCore.dk> <200501142152.43282.emanuel.strobl@gmx.net> In-Reply-To: <200501142152.43282.emanuel.strobl@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-mail-scanned: by DeepCore Virus & Spam killer v1.6 cc: Michael Class cc: freebsd-current@freebsd.org Subject: Re: SIL3112 and Maxtor 6Y160M0 SATA Disk: DMA Failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 21:04:00 -0000 Emanuel Strobl wrote: >>>Unfortunately when I do attach my Maxtor SATA disk to this controller >>>I do only get DMA errors. This is all on a recent 6.0-CURRENT system >>>and can be reproduced with a GENERIC kernel. >> >>The SiI3112 silicon is so bug ridden its not even funny. >> >>I suggest you return that piece of crap to the vendor that sold it to >>you and get somthing that works. >=20 > I can understand your comment but please extend it with some recommenda= tions.=20 > If anybody, you should know which controllers are reliable, os hw and s= q=20 > sight! Well I'll just start to sound like the PR department of Promise, but=20 their controllers work perfectly and they support FreeBSD by giving me=20 access to documentation. --=20 -S=F8ren From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 21:04:27 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B40BC16A4CE; Fri, 14 Jan 2005 21:04:27 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B6E843D1F; Fri, 14 Jan 2005 21:04:27 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id j0EL4QFi065947; Fri, 14 Jan 2005 16:04:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.1/8.13.1) with ESMTP id j0EL4QP3039836; Fri, 14 Jan 2005 16:04:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 6DA1E7306E; Fri, 14 Jan 2005 16:04:26 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050114210426.6DA1E7306E@freebsd-current.sentex.ca> Date: Fri, 14 Jan 2005 16:04:26 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/649/Sun Jan 2 18:02:22 2005 clamav-milter version 0.80j on clamscanner1 X-Virus-Status: Clean Subject: [current tinderbox] failure on alpha/alpha X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 21:04:27 -0000 TB --- 2005-01-14 20:30:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-14 20:30:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-01-14 20:30:00 - checking out the source tree TB --- 2005-01-14 20:30:00 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-01-14 20:30:00 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-01-14 20:35:39 - building world (CFLAGS=-O2 -pipe) TB --- 2005-01-14 20:35:39 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-01-14 20:35:39 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] building static telnet library ranlib libtelnet.a ===> lib/libthr (all) cc -O2 -pipe -mcpu=ev4 -mtune=ev5 -mieee -DPTHREAD_KERNEL -D_THREAD_SAFE -I/tinderbox/CURRENT/alpha/alpha/src/lib/libthr/../libc/include -I/tinderbox/CURRENT/alpha/alpha/src/lib/libthr/thread -I/tinderbox/CURRENT/alpha/alpha/src/lib/libthr/../../include -I/tinderbox/CURRENT/alpha/alpha/src/lib/libthr/../../libexec/rtld-elf -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /tinderbox/CURRENT/alpha/alpha/src/lib/libthr/thread/thr_atfork.c In file included from /tinderbox/CURRENT/alpha/alpha/src/lib/libthr/thread/thr_private.h:72, from /tinderbox/CURRENT/alpha/alpha/src/lib/libthr/thread/thr_atfork.c:36: /home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include/sys/umtx.h: In function `umtx_wait': /home/tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include/sys/umtx.h:118: warning: passing arg 5 of `_umtx_op' discards qualifiers from pointer target type *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/lib/libthr. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src/lib. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-01-14 21:04:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-01-14 21:04:26 - ERROR: failed to build world TB --- 2005-01-14 21:04:26 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 21:24:08 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 25AEC16A4D0 for ; Fri, 14 Jan 2005 21:24:08 +0000 (GMT) Received: from mail27.sea5.speakeasy.net (mail27.sea5.speakeasy.net [69.17.117.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53CDC43D49 for ; Fri, 14 Jan 2005 21:24:07 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 15837 invoked from network); 14 Jan 2005 21:24:07 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) AES256-SHA encrypted SMTP for ; 14 Jan 2005 21:24:06 -0000 Received: from [10.50.40.231] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id j0ELNxcJ043527; Fri, 14 Jan 2005 16:24:02 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: current@FreeBSD.org Date: Fri, 14 Jan 2005 15:46:31 -0500 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200501141546.31386.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: bde@FreeBSD.org cc: phk@FreeBSD.org Subject: [PATCH] Use local APIC timer to drive kernel clocks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 21:24:08 -0000 I have a patch that uses the local APIC timer to drive the kernel clocks (hardclock, statclock, and profclock) instead of the ISA timer and RTC. The advantage of this change is that SMP machines can stop using IPIs to bounce clock interrupts around all the time. Currently the code will always use the local APIC timer if an APIC is being used, but it might be desirable to only use the timer if we have more than one CPU. Some caveats and details: - statclock and profclock are not evenly distributed as they are when driven by the RTC. Specifically, since there is only one timer in the APIC, I had to drive all 3 clocks from the same timer. The current code uses two different timers with profclock and statclock being driven by the same timer. Emulating this behavior completely requires that I run the APIC timer at the least common multiple of the 3 clocks and drive each clock via a software divisor. With the default hz's of 1000, 128, and 1024 (hz, stathz, and profhz), I ended up having to run the timer at 128000 interrupts per second. That didn't seem to be a good tradeoff for hz + profhz (2024) IPIs per second. Instead, I went with a simpler algorithm suggested by phk that lets me run the timer at hz and guarantees that statclock() will be called stathz times per second, just not evenly spaced. The same is true for profhz and profclock() with the exception that since the timer only runs at hz, if hz is less than profhz (which it is by default), profhz runs at hz instead of 1024. - Right now I have intrcnt entries for each CPUs timer as well as virtual counters representing how often the different clocks run on the BSP. This is so you can verify that the clocks are running at the correct rates in systat -vmstat. I might remove these counters or I might leave them in if this is eventually committed. - The IPI_BITMAP handler has now degenerated back into just IPI_AST, but I've still left all the bitmap stuff in for now. - The clock interrupt doesn't share a vector with the IPI priority group, but instead steals the highest vector from the previous group. This does mean there's one less interrupt available for devices and MSI, but we have plenty to spare at the moment anyway, and will soon have oodles to spare when we start allocating the APIC vectors on demand rather than statically. Please test and let me know if there are any regressions. Thanks. Patch is at http://www.FreeBSD.org/~jhb/patches/lapic_timer.patch -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 21:24:09 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAE8816A4D1 for ; Fri, 14 Jan 2005 21:24:09 +0000 (GMT) Received: from mail15.speakeasy.net (mail23.sea5.speakeasy.net [69.17.117.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C03F43D31 for ; Fri, 14 Jan 2005 21:24:09 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 28658 invoked from network); 14 Jan 2005 21:24:09 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 14 Jan 2005 21:24:09 -0000 Received: from [10.50.40.231] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id j0ELNxcK043527 for ; Fri, 14 Jan 2005 16:24:05 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: current@FreeBSD.org Date: Fri, 14 Jan 2005 16:24:34 -0500 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200501141624.34752.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx Subject: [PATCH] Divorce critical sections from spin mutexes (round 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 21:24:10 -0000 Ok, in the process of updating my tree that held the earlier version of the critical section vs. spin mutexes patch I think I have found and fixed the bug that may have caused the lockups a few people reported. As such, I'd like folks to test the updated patch. Details and such of what the patch does: - spin locks and critical sections are divorced. Specifically, the sole purpose of a critical section is to keep the current thread from being preempted until it exits the section. Nothing requires that the critical section actually disable interrupts during the section as any interrupt threads scheduled would simply not preempt either because they would be picked up by another CPU or preempt the current thread when it exited the critical section. However, spin locks do need to prevent themselves from being interrupted by any code that can try to acquire a spin lock. Strictly speaking, only spin mutexes used in interrupt context (sched_lock, icu_lock, locks in INTR_FAST handlers, sleepq locks, etc.) need to block interrupts, but if you have a mutex that is only used in top half code, you should probably be using a normal mutex anyway, so the set of spin mutexes not used in interrupt context tends to be small to empty. So far in SMPng, almost all critical sections have been inside of spin mutexes (since spin mutexes also need to block preemptions in addition to interrupts). Thus, for the sake of simplicity, critical sections also included the interrupt blocking behavior. (Keep in mind that this was an evolutionary process. :) However, as SMPng progresses, it has now become useful to divorce the two concepts, especially as some folks are working on locking schemes which just use critical sections to protect per-CPU resources that are not accessed from interrupt context. What this change does is to move the interrupt blocking/deferment/whatever bits that spin mutexes need into a separate spinlock_enter()/spinlock_exit() API completely implemented in MD code. critical sections, on the other hand, are now reduced to a simple per-thread nesting count and are now completely MI. - The MI code that creates idle threads for each of the CPUs no longer tries to set curthread up for the APs and no longer messes with the critnest count for the idlethreads. Instead, the MD code now explicitly borrows the idlethread context for the APs when it needs it and is responsible for adjusting the critical section and spinlock nesting counts to account for the weirdness of borrowing the context for the first context switch. I've tested this on SMP i386, SMP sparc64, and UP alpha. Testing on other archs and on SMP would be greatly appreciated. Patch is at http://www.FreeBSD.org/~jhb/patches/spinlock.patch -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 21:29:07 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2342816A4CE for ; Fri, 14 Jan 2005 21:29:07 +0000 (GMT) Received: from vbook.fbsd.ru (user164.hovrino.net [82.179.232.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7C9D43D46 for ; Fri, 14 Jan 2005 21:29:04 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.43 (FreeBSD)) id 1CpZ04-0000LU-7L; Sat, 15 Jan 2005 00:28:56 +0300 From: Vladimir Grebenschikov To: current@freebsd.org In-Reply-To: <1105138987.1401.5.camel@localhost> References: <20041228010938.GA39686@freebsd3.cimlogic.com.au> <20041230.111631.13597845.imp@bsdimp.com> <1104542138.3084.9.camel@localhost> <41D67753.60202@elischer.org> <1105138987.1401.5.camel@localhost> Content-Type: multipart/mixed; boundary="=-/aV4VwvMH0ZArwudcSpB" Organization: SWsoft Date: Sat, 15 Jan 2005 00:28:55 +0300 Message-Id: <1105738135.1124.9.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov cc: =?ISO-8859-1?Q?S=F8ren?= Schmidt cc: "M. Warner Losh" cc: Julian Elischer Subject: Re: USB problems 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: Fri, 14 Jan 2005 21:29:07 -0000 --=-/aV4VwvMH0ZArwudcSpB Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable =F7 =D3=C2, 08/01/2005 =D7 02:03 +0300, Vladimir Grebenschikov =D0=C9=DB=C5= =D4: > =F7 =D3=C2, 01/01/2005 =D7 02:11 -0800, Julian Elischer =D0=C9=DB=C5=D4: > > Vladimir Grebenschikov wrote: > > > =F7 =D0=D4, 31/12/2004 =D7 05:05 -1000, Randy Bush =D0=C9=DB=C5=D4: > > >=20 > > >>possibly related? > > >> > > >>just so you know, on a thinkpad t41 with any current in the last > > >>few weeks, i kernel panic on boot if a usb device is not plugged > > >>in. turning off acpi also allows boot. see > > >> > > >> > > >> > > >>i can help debug if anyone is on the trail > > >=20 > > >=20 > > > I have also problems with USB on recent current (previous was few wee= ks > > > old). > > >=20 > >=20 > > the most salient thiing you could do is find the date of the problem by= checking=20 > > out sys/dev/usb on dec 9 and seeing if that fixes it (you said dec 9 w= as ok) > > and if so, gradually moving it forward using a binary search and narrow= ing in on=20 > > the commit that broke it. I have found the exact reason - it stats fail after following patch: sos 2004-12-08 11:16:33 UTC FreeBSD src repository Modified files: sys/dev/ata ata-queue.c=20 Log: Reset timeout when we are back from interrupt. =20 Revision Changes Path 1.41 +3 -0 src/sys/dev/ata/ata-queue.c @@ -216,6 +216,9 @@ ata_completed(request, 0); } else { + if (!dumping) + callout_reset(&request->callout, request->timeout * hz, + (timeout_t*)ata_timeout, request); if (request->bio && !(request->flags & ATA_R_TIMEOUT)) { ATA_DEBUG_RQ(request, "finish bio_taskqueue"); bio_taskqueue(request->bio, (bio_task_t *)ata_completed, reques= t); Looks like something bad happens with locking while this timeout. With this patch reverse applied - all is ok. Can anybody advise, what wrong happens there with locking ? (original panic description in attachment) This panic happens after ATA initialization. But If I boot with plugged USB= hub (it has keyboard and mouse) I've get panic on ATAPICAM init. Should I fill PR ? (last try with very last current) --=20 Vladimir B. Grebenchikov vova@fbsd.ru --=-/aV4VwvMH0ZArwudcSpB Content-Disposition: inline Content-Description: =?koi8-r?Q?=F7=CC=CF=D6=C5=CE=CE=CF=C5?= =?koi8-r?Q?_=D3=CF=CF=C2=DD=C5=CE=C9=C5?= - Re: USB problems Content-Type: message/rfc822 Return-path: Envelope-to: vova@fbsd.ru Delivery-date: Sat, 01 Jan 2005 04:16:33 +0300 Received: from mx2.freebsd.org ([216.136.204.119]) by fbsd.ru with esmtp (Exim 3.36 #1) id 1CkXse-00062r-00 for vova@fbsd.ru; Sat, 01 Jan 2005 04:16:33 +0300 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 2637E579E0; Sat, 1 Jan 2005 01:16:00 +0000 (GMT) (envelope-from owner-freebsd-current@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id EE66F16A4FC; Sat, 1 Jan 2005 01:15:56 +0000 (GMT) Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C9B516A4CE; Sat, 1 Jan 2005 01:15:49 +0000 (GMT) Received: from vbook.fbsd.ru (user181.hovrino.net [82.179.232.181]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FAC443D4C; Sat, 1 Jan 2005 01:15:48 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.43 (FreeBSD)) id 1CkXrn-0000p2-Ca; Sat, 01 Jan 2005 04:15:39 +0300 From: Vladimir Grebenschikov To: Randy Bush In-Reply-To: <16853.27324.504672.6086@roam.psg.com> References: <20041228010938.GA39686@freebsd3.cimlogic.com.au> <20041230.111631.13597845.imp@bsdimp.com> <16853.27324.504672.6086@roam.psg.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Sat, 01 Jan 2005 04:15:38 +0300 Message-Id: <1104542138.3084.9.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.0.0FreeBSD GNOME Team Port Cc: "M. Warner Losh" Subject: Re: USB problems 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: , Sender: owner-freebsd-current@freebsd.org Errors-To: owner-freebsd-current@freebsd.org X-Evolution-Source: mbox:/var/mail/vova =F7 =D0=D4, 31/12/2004 =D7 05:05 -1000, Randy Bush =D0=C9=DB=C5=D4: > possibly related? >=20 > just so you know, on a thinkpad t41 with any current in the last > few weeks, i kernel panic on boot if a usb device is not plugged > in. turning off acpi also allows boot. see >=20 > >=20 > i can help debug if anyone is on the trail I have also problems with USB on recent current (previous was few weeks old). It panics on each boot: Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0x1ff0383 fault code =3D supervisor write, page not present instruction pointer =3D 0x8:0xc07bc886 stack pointer =3D 0x10:0xe6923a8c frame pointer =3D 0x10:0xe6923a90 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 477 (usbd) [thread pid 477 tid 100078 ] Stopped at usb_get_next_event+0x6e: movl %eax,0x184(%edx) db> trace Tracing pid 477 tid 100078 td 0xc212bb80 usb_get_next_event(1ff01ff,1ff01ff,1ff01ff,1ff01ff,1ff01ff) at usb_get_next_event+0x6e usbread(c1a60200,e6923c7c,10,7000000,0) at usbread+0x43 devfs_read_f(c1d3f264,e6923c7c,c1977c80,0,c212bb80) at devfs_read_f+0xd4 dofileread(c212bb80,c1d3f264,7,bfbfeb50,180) at dofileread+0x7e read(c212bb80,e6923d14,c,c212bb80,7) at read+0x6b syscall(2f,2f,2f,7,7) at syscall+0x300 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (3, FreeBSD ELF32, read), eip =3D 0x280cbc17, esp =3D 0xbfbfeb2c, ebp =3D 0xbfbfecd8 --- db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd 514 c212a3f0 0 1 48 0000002 [LOCK Giant c2019040] hcsecd 512 c212a000 65534 1 512 0000100 [SLPQ select 0xc06b8d04][SLP] sdpd 477 c212a5e8 0 472 48 0004002 [CPU 0] usbd 472 c1a475e8 0 48 48 0000002 [SLPQ wait 0xc1a475e8][SLP] sh ...=20 db> trace 514 Tracing pid 514 tid 100079 td 0xc212bcf0 sched_switch(c212bcf0,0,1,7066308c,418ddef8) at sched_switch+0x170 mi_switch(1,0,c05238cd,c19939a4,c1d65484) at mi_switch+0x1d9 turnstile_wait(c06b2ae0,c212bb80,0,bfbfe000,e69b9cbc) at turnstile_wait +0x350 _mtx_lock_sleep(c06b2ae0,c212bcf0,0,0,0) at _mtx_lock_sleep+0xb4 vm_fault(c1993960,bfbfe000,2,8,e69b9cfc) at vm_fault+0x211 trap_pfault(e69b9d48,1,bfbfeb4c,e69b9d34,bfbfeb4c) at trap_pfault+0x13b trap(2f,2f,2f,0,bfbfeb60) at trap+0x21a calltrap() at calltrap+0x5 --- trap 0xc, eip =3D 0x280cc601, esp =3D 0xbfbfeb50, ebp =3D 0xbfbfebb8 --= - db> =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 I have found way how to workaround panic. If I turn on USB dongle while boot (after usb bus detected) it boots ok. But If I boot with turned off USB dongle - it panics, same If I boot with turned on USB dongle. (also it is same with usb mice or keyboard). I have allways turned on umass on-board card reader. There is my usual list of USB devides: # usbdevs -v Controller /dev/usb0: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x= 0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb1: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x= 0000), rev 1.00 port 1 powered port 2 powered Controller /dev/usb2: addr 1: full speed, self powered, config 1, UHCI root hub(0x0000), Intel(0x= 0000), rev 1.00 port 1 powered port 2 addr 2: full speed, power 100 mA, config 1, UGX(0x3003), ALPS(0x044= e), rev 7.81 Controller /dev/usb3: addr 1: high speed, self powered, config 1, EHCI root hub(0x0000), Intel(0x= 0000), rev 1.00 port 1 powered port 2 powered port 3 powered port 4 powered port 5 addr 2: high speed, self powered, config 1, USB Memory Stick Slot(0= x014d), Sony(0x054c), rev 1.10 port 6 powered # Last "good" kernel dated Dec 9 2004. (or near this date). As I notice it allways panics when some process gets Giant, (usually it is bluetooth process) Looks like it is USB problem, but probably it is bluetooth related. I am not sure. I can provide more details. > randy --=20 Vladimir B. Grebenchikov vova@fbsd.ru _______________________________________________ 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" --=-/aV4VwvMH0ZArwudcSpB-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 21:39:08 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 845EA16A4CE; Fri, 14 Jan 2005 21:39:08 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 072A943D46; Fri, 14 Jan 2005 21:39:08 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id j0ELd7Jp069178; Fri, 14 Jan 2005 16:39:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.1/8.13.1) with ESMTP id j0ELd6UG059936; Fri, 14 Jan 2005 16:39:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 5602C7306E; Fri, 14 Jan 2005 16:39:07 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050114213907.5602C7306E@freebsd-current.sentex.ca> Date: Fri, 14 Jan 2005 16:39:07 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/649/Sun Jan 2 18:02:22 2005 clamav-milter version 0.80j on clamscanner3 X-Virus-Status: Clean Subject: [current tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 21:39:08 -0000 TB --- 2005-01-14 21:04:26 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-14 21:04:26 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2005-01-14 21:04:26 - checking out the source tree TB --- 2005-01-14 21:04:26 - cd /home/tinderbox/CURRENT/amd64/amd64 TB --- 2005-01-14 21:04:26 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-01-14 21:10:03 - building world (CFLAGS=-O2 -pipe) TB --- 2005-01-14 21:10:03 - cd /home/tinderbox/CURRENT/amd64/amd64/src TB --- 2005-01-14 21:10:03 - /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 [...] building static telnet library ranlib libtelnet.a ===> lib/libthr (all) cc -O2 -pipe -DPTHREAD_KERNEL -D_THREAD_SAFE -I/tinderbox/CURRENT/amd64/amd64/src/lib/libthr/../libc/include -I/tinderbox/CURRENT/amd64/amd64/src/lib/libthr/thread -I/tinderbox/CURRENT/amd64/amd64/src/lib/libthr/../../include -I/tinderbox/CURRENT/amd64/amd64/src/lib/libthr/../../libexec/rtld-elf -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /tinderbox/CURRENT/amd64/amd64/src/lib/libthr/thread/thr_atfork.c In file included from /tinderbox/CURRENT/amd64/amd64/src/lib/libthr/thread/thr_private.h:72, from /tinderbox/CURRENT/amd64/amd64/src/lib/libthr/thread/thr_atfork.c:36: /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include/sys/umtx.h: In function `umtx_wait': /home/tinderbox/CURRENT/amd64/amd64/obj/amd64/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include/sys/umtx.h:118: warning: passing arg 5 of `_umtx_op' discards qualifiers from pointer target type *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/lib/libthr. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src/lib. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. *** Error code 1 Stop in /tinderbox/CURRENT/amd64/amd64/src. TB --- 2005-01-14 21:39:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-01-14 21:39:07 - ERROR: failed to build world TB --- 2005-01-14 21:39:07 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 21:45:46 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E64516A4CE; Fri, 14 Jan 2005 21:45:46 +0000 (GMT) Received: from stephanie.unixdaemons.com (stephanie.unixdaemons.com [67.18.111.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id F300C43D1D; Fri, 14 Jan 2005 21:45:45 +0000 (GMT) (envelope-from bmilekic@technokratis.com) Received: from stephanie.unixdaemons.com (bmilekic@localhost.unixdaemons.com [127.0.0.1])j0ELjhkg096154; Fri, 14 Jan 2005 16:45:43 -0500 (EST) Received: (from bmilekic@localhost) by stephanie.unixdaemons.com (8.13.2/8.12.1/Submit) id j0ELjhL9096153; Fri, 14 Jan 2005 16:45:43 -0500 (EST) (envelope-from bmilekic@technokratis.com) X-Authentication-Warning: stephanie.unixdaemons.com: bmilekic set sender to bmilekic@technokratis.com using -f Date: Fri, 14 Jan 2005 16:45:43 -0500 From: Bosko Milekic To: John Baldwin Message-ID: <20050114214543.GA92921@technokratis.com> References: <200501141624.34752.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501141624.34752.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2.1i cc: current@freebsd.org Subject: Re: [PATCH] Divorce critical sections from spin mutexes (round 2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 21:45:46 -0000 On Fri, Jan 14, 2005 at 04:24:34PM -0500, John Baldwin wrote: > Ok, in the process of updating my tree that held the earlier version of the > critical section vs. spin mutexes patch I think I have found and fixed the > bug that may have caused the lockups a few people reported. As such, I'd > like folks to test the updated patch. Details and such of what the patch > does: > > - spin locks and critical sections are divorced. Specifically, the sole > purpose of a critical section is to keep the current thread from being > preempted until it exits the section. Nothing requires that the critical > section actually disable interrupts during the section as any interrupt > threads scheduled would simply not preempt either because they would be > picked up by another CPU or preempt the current thread when it exited the > critical section. However, spin locks do need to prevent themselves from > being interrupted by any code that can try to acquire a spin lock. Strictly > speaking, only spin mutexes used in interrupt context (sched_lock, icu_lock, > locks in INTR_FAST handlers, sleepq locks, etc.) need to block interrupts, > but if you have a mutex that is only used in top half code, you should > probably be using a normal mutex anyway, so the set of spin mutexes not used > in interrupt context tends to be small to empty. So far in SMPng, almost > all critical sections have been inside of spin mutexes (since spin mutexes > also need to block preemptions in addition to interrupts). Thus, for the > sake of simplicity, critical sections also included the interrupt blocking > behavior. (Keep in mind that this was an evolutionary process. :) However, > as SMPng progresses, it has now become useful to divorce the two concepts, > especially as some folks are working on locking schemes which just use > critical sections to protect per-CPU resources that are not accessed from > interrupt context. What this change does is to move the interrupt > blocking/deferment/whatever bits that spin mutexes need into a separate > spinlock_enter()/spinlock_exit() API completely implemented in MD code. > critical sections, on the other hand, are now reduced to a simple per-thread > nesting count and are now completely MI. > - The MI code that creates idle threads for each of the CPUs no longer tries > to set curthread up for the APs and no longer messes with the critnest count > for the idlethreads. Instead, the MD code now explicitly borrows the > idlethread context for the APs when it needs it and is responsible for > adjusting the critical section and spinlock nesting counts to account for > the weirdness of borrowing the context for the first context switch. > > I've tested this on SMP i386, SMP sparc64, and UP alpha. Testing on other > archs and on SMP would be greatly appreciated. Patch is at > http://www.FreeBSD.org/~jhb/patches/spinlock.patch After a non-contextual review and reading the patch description, I am very pleased that the evolutionary process has led us this way. This makes me much more confident that different synchronization paradigms will now be usable (and therefore considered) in FreeBSD. For those unaware of the impact of this work: it's big. FreeBSD tends more and more to a flexible middle-ground/compromise now when it comes to synchronization. We can now build much faster per-CPU structures without completely succumbing to the latency associated with global locking schemes (such as mutexes). But, in addition to that, we can still continue to use mutexes where appropriate. Yay! Thank you. -- Bosko Milekic bmilekic@technokratis.com bmilekic@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 22:06:28 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5C2D716A4CE for ; Fri, 14 Jan 2005 22:06:28 +0000 (GMT) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D88A143D1F for ; Fri, 14 Jan 2005 22:06:27 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.1/8.13.1) with ESMTP id j0EM6QEr001485; Fri, 14 Jan 2005 14:06:26 -0800 (PST) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.1/8.13.1/Submit) id j0EM6QV1001484; Fri, 14 Jan 2005 14:06:26 -0800 (PST) (envelope-from eta@lclark.edu) X-Authentication-Warning: leguin.anholt.net: anholt set sender to eta@lclark.edu using -f From: Eric Anholt To: Nate Lawson In-Reply-To: <41E8137A.1050603@root.org> References: <41E8137A.1050603@root.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 14 Jan 2005 14:06:25 -0800 Message-Id: <1105740385.846.10.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 FreeBSD GNOME Team Port cc: FreeBSD Current Subject: Re: xorg-server doesn't build? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 22:06:28 -0000 On Fri, 2005-01-14 at 10:46 -0800, Nate Lawson wrote: > I'm not sure if ports@ is the right list for this, but I have this build > problem for xorg-server on -current: > > making all in programs/Xserver/hw/xfree86/xf86cfg... > rm -f interface.o > cc -c -O2 -fno-strict-aliasing -pipe -ansi -pedantic -Wno-system-headers > -Dasm=__asm -Wall -Wpointer-arith -Wundef -fno-merge-constants > -I../common -I../scanpci -I../loader > -I/usr/ports/x11-servers/xorg-server/work/xc/programs/Xserver/hw/xfree86/os-support > > -I/usr/ports/x11-servers/xorg-server/work/xc/programs/Xserver/include > -I/usr/ports/x11-servers/xorg-server/work/xc/exports/include/X11 > -I/usr/ports/x11-servers/xorg-server/work/xc/lib/font/include > -I/usr/ports/x11-servers/xorg-server/work/xc > -I/usr/ports/x11-servers/xorg-server/work/xc/exports/include > -I/usr/X11R6/include -I/usr/X11R6/include -DCSRG_BASED -DSHAPE -DXINPUT > -DXKB -DXAPPGROUP -DXCSECURITY -DTOGCUP -DXF86BIGFONT > -DDPMSExtension -DPANORAMIX -DRENDER -DRANDR -DXFIXES > -DDAMAGE -DCOMPOSITE -DXEVIE -DGCCUSESGAS -DAVOID_GLYPHBLT -DPIXPRIV > -DSINGLEDEPTH -DXFreeXDGA -DXvExtension > -DXFree86LOADER -DXFree86Server > -DXF86VIDMODE -DXvMCExtension > -DSMART_SCHEDULE -DBUILDDEBUG > -DXResExtension > -DX_BYTE_ORDER=X_LITTLE_ENDIAN > -DXORG_VERSION_CURRENT="(((6) * 10000000) + ((8) * 100000) + ((1) * > 1000) + 0)" -DNDEBUG -DFUNCPROTO=15 -DNARROWPROTO > -DXF86CONFIG=\"xorg.conf\" -DUSE_MODULES -DHAS_NCURSES > -DPROJECT_ROOT=\"/usr/X11R6\" > -DXF86CONFIGDIR=\"/usr/X11R6/lib/X11\" -DPCCONS_SUPPORT > -DSYSCONS_SUPPORT -DPCVT_SUPPORT > -D__XCONFIGFILE__='"xorg.conf"' > -D__XCONFIGDIR__='"/usr/X11R6/lib/X11"' -D__XLOGFILE__='"Xorg"' > -D__XSERVERNAME__='"Xorg"' -D__XKBDEFRULES__='"xorg"' interface.c > interface.c: In function `Usage': > interface.c:224: warning: string length `630' is greater than the length > `509' ISO C89 compilers are required to support > interface.c: In function `main': > interface.c:411: error: `compositeWidgetClass' undeclared (first use in > this function) > interface.c:411: error: (Each undeclared identifier is reported only once > interface.c:411: error: for each function it appears in.) > *** Error code 1 I haven't heard back from the last person I responded to with this issue, but could you reinstall xorg-libraries and try again? -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 22:13:36 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A4AB16A4CE; Fri, 14 Jan 2005 22:13:35 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7023543D2D; Fri, 14 Jan 2005 22:13:35 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id j0EMDYfC071399; Fri, 14 Jan 2005 17:13:34 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.1/8.13.1) with ESMTP id j0EMDYQ8075265; Fri, 14 Jan 2005 17:13:34 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 749A37306E; Fri, 14 Jan 2005 17:13:34 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050114221334.749A37306E@freebsd-current.sentex.ca> Date: Fri, 14 Jan 2005 17:13:34 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/649/Sun Jan 2 18:02:22 2005 clamav-milter version 0.80j on clamscanner3 X-Virus-Status: Clean 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: Fri, 14 Jan 2005 22:13:36 -0000 TB --- 2005-01-14 21:39:07 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-14 21:39:07 - starting CURRENT tinderbox run for i386/i386 TB --- 2005-01-14 21:39:07 - checking out the source tree TB --- 2005-01-14 21:39:07 - cd /home/tinderbox/CURRENT/i386/i386 TB --- 2005-01-14 21:39:07 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-01-14 21:44:53 - building world (CFLAGS=-O2 -pipe) TB --- 2005-01-14 21:44:53 - cd /home/tinderbox/CURRENT/i386/i386/src TB --- 2005-01-14 21:44: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 [...] building static telnet library ranlib libtelnet.a ===> lib/libthr (all) cc -O2 -pipe -DPTHREAD_KERNEL -D_THREAD_SAFE -I/tinderbox/CURRENT/i386/i386/src/lib/libthr/../libc/include -I/tinderbox/CURRENT/i386/i386/src/lib/libthr/thread -I/tinderbox/CURRENT/i386/i386/src/lib/libthr/../../include -I/tinderbox/CURRENT/i386/i386/src/lib/libthr/../../libexec/rtld-elf -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /tinderbox/CURRENT/i386/i386/src/lib/libthr/thread/thr_atfork.c In file included from /tinderbox/CURRENT/i386/i386/src/lib/libthr/thread/thr_private.h:72, from /tinderbox/CURRENT/i386/i386/src/lib/libthr/thread/thr_atfork.c:36: /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/usr/include/sys/umtx.h: In function `umtx_wait': /home/tinderbox/CURRENT/i386/i386/obj/tinderbox/CURRENT/i386/i386/src/i386/usr/include/sys/umtx.h:118: warning: passing arg 5 of `_umtx_op' discards qualifiers from pointer target type *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/lib/libthr. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src/lib. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/i386/src. TB --- 2005-01-14 22:13:34 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-01-14 22:13:34 - ERROR: failed to build world TB --- 2005-01-14 22:13:34 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 22:48:17 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4832316A4CE; Fri, 14 Jan 2005 22:48:17 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1E0843D1D; Fri, 14 Jan 2005 22:48:16 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j0EMmFs1070600; Fri, 14 Jan 2005 17:48:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.1/8.13.1) with ESMTP id j0EMmFRv017379; Fri, 14 Jan 2005 17:48:15 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A361B7306E; Fri, 14 Jan 2005 17:48:15 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050114224815.A361B7306E@freebsd-current.sentex.ca> Date: Fri, 14 Jan 2005 17:48:15 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/625/Fri Dec 10 12:41:57 2004 clamav-milter version 0.80j on clamscanner3 X-Virus-Scanned: ClamAV 0.80/663/Tue Jan 11 17:44:48 2005 clamav-milter version 0.80j on clamscanner3 X-Virus-Status: Clean X-Virus-Status: Clean 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: Fri, 14 Jan 2005 22:48:17 -0000 TB --- 2005-01-14 22:13:34 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-14 22:13:34 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-01-14 22:13:34 - checking out the source tree TB --- 2005-01-14 22:13:34 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-01-14 22:13:34 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-01-14 22:19:29 - building world (CFLAGS=-O2 -pipe) TB --- 2005-01-14 22:19:29 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-01-14 22:19:29 - /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 [...] building static telnet library ranlib libtelnet.a ===> lib/libthr (all) cc -O2 -pipe -DPTHREAD_KERNEL -D_THREAD_SAFE -I/tinderbox/CURRENT/i386/pc98/src/lib/libthr/../libc/include -I/tinderbox/CURRENT/i386/pc98/src/lib/libthr/thread -I/tinderbox/CURRENT/i386/pc98/src/lib/libthr/../../include -I/tinderbox/CURRENT/i386/pc98/src/lib/libthr/../../libexec/rtld-elf -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /tinderbox/CURRENT/i386/pc98/src/lib/libthr/thread/thr_atfork.c In file included from /tinderbox/CURRENT/i386/pc98/src/lib/libthr/thread/thr_private.h:72, from /tinderbox/CURRENT/i386/pc98/src/lib/libthr/thread/thr_atfork.c:36: /home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/i386/usr/include/sys/umtx.h: In function `umtx_wait': /home/tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/i386/usr/include/sys/umtx.h:118: warning: passing arg 5 of `_umtx_op' discards qualifiers from pointer target type *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/lib/libthr. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src/lib. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2005-01-14 22:48:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-01-14 22:48:15 - ERROR: failed to build world TB --- 2005-01-14 22:48:15 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 23:13:56 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CEBD16A4CE; Fri, 14 Jan 2005 23:13:56 +0000 (GMT) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id A508843D55; Fri, 14 Jan 2005 23:13:55 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost1.sentex.ca (8.13.1/8.13.1) with ESMTP id j0ENDtHB076616; Fri, 14 Jan 2005 18:13:55 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.1/8.13.1) with ESMTP id j0ENDsWP099663; Fri, 14 Jan 2005 18:13:54 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C7F4C7306E; Fri, 14 Jan 2005 18:13:54 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050114231354.C7F4C7306E@freebsd-current.sentex.ca> Date: Fri, 14 Jan 2005 18:13:54 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/649/Sun Jan 2 18:02:22 2005 clamav-milter version 0.80j on clamscanner1 X-Virus-Status: Clean Subject: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 23:13:56 -0000 TB --- 2005-01-14 22:48:15 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-14 22:48:15 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2005-01-14 22:48:15 - checking out the source tree TB --- 2005-01-14 22:48:15 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2005-01-14 22:48:15 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-01-14 22:53:49 - building world (CFLAGS=-O2 -pipe) TB --- 2005-01-14 22:53:49 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-01-14 22:53:49 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -D_IEEE_LIBM -I/tinderbox/CURRENT/ia64/ia64/src/lib/msun/../libc/include -I/tinderbox/CURRENT/ia64/ia64/src/lib/msun/../libc/ia64 -c /tinderbox/CURRENT/ia64/ia64/src/lib/msun/src/k_rem_pio2f.c cc -O2 -pipe -D_IEEE_LIBM -I/tinderbox/CURRENT/ia64/ia64/src/lib/msun/../libc/include -I/tinderbox/CURRENT/ia64/ia64/src/lib/msun/../libc/ia64 -c /tinderbox/CURRENT/ia64/ia64/src/lib/msun/src/k_sin.c cc -O2 -pipe -D_IEEE_LIBM -I/tinderbox/CURRENT/ia64/ia64/src/lib/msun/../libc/include -I/tinderbox/CURRENT/ia64/ia64/src/lib/msun/../libc/ia64 -c /tinderbox/CURRENT/ia64/ia64/src/lib/msun/src/k_sinf.c cc -O2 -pipe -D_IEEE_LIBM -I/tinderbox/CURRENT/ia64/ia64/src/lib/msun/../libc/include -I/tinderbox/CURRENT/ia64/ia64/src/lib/msun/../libc/ia64 -c /tinderbox/CURRENT/ia64/ia64/src/lib/msun/src/k_standard.c /tinderbox/CURRENT/ia64/ia64/src/lib/msun/src/k_standard.c: In function `__kernel_standard': /tinderbox/CURRENT/ia64/ia64/src/lib/msun/src/k_standard.c:150: error: `HUGE' undeclared (first use in this function) /tinderbox/CURRENT/ia64/ia64/src/lib/msun/src/k_standard.c:150: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/ia64/ia64/src/lib/msun/src/k_standard.c:150: error: for each function it appears in.) *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src/lib/msun. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2005-01-14 23:13:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-01-14 23:13:54 - ERROR: failed to build world TB --- 2005-01-14 23:13:54 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 23:37:25 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6389C16A4CF; Fri, 14 Jan 2005 23:37:25 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA14D43D1F; Fri, 14 Jan 2005 23:37:24 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j0ENbOMK073004; Fri, 14 Jan 2005 18:37:24 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.1/8.13.1) with ESMTP id j0ENbNX1009433; Fri, 14 Jan 2005 18:37:23 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C2E2F7306E; Fri, 14 Jan 2005 18:37:23 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050114233723.C2E2F7306E@freebsd-current.sentex.ca> Date: Fri, 14 Jan 2005 18:37:23 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/625/Fri Dec 10 12:41:57 2004 clamav-milter version 0.80j on clamscanner1 X-Virus-Scanned: ClamAV 0.80/649/Sun Jan 2 18:02:22 2005 clamav-milter version 0.80j on avscan2 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 23:37:25 -0000 TB --- 2005-01-14 23:13:54 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-14 23:13:54 - starting CURRENT tinderbox run for powerpc/powerpc TB --- 2005-01-14 23:13:54 - checking out the source tree TB --- 2005-01-14 23:13:54 - cd /home/tinderbox/CURRENT/powerpc/powerpc TB --- 2005-01-14 23:13:54 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-01-14 23:19:34 - building world (CFLAGS=-O2 -pipe) TB --- 2005-01-14 23:19:34 - cd /home/tinderbox/CURRENT/powerpc/powerpc/src TB --- 2005-01-14 23:19:34 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -D_IEEE_LIBM -I/tinderbox/CURRENT/powerpc/powerpc/src/lib/msun/../libc/include -I/tinderbox/CURRENT/powerpc/powerpc/src/lib/msun/../libc/powerpc -c /tinderbox/CURRENT/powerpc/powerpc/src/lib/msun/src/k_rem_pio2f.c cc -O2 -pipe -D_IEEE_LIBM -I/tinderbox/CURRENT/powerpc/powerpc/src/lib/msun/../libc/include -I/tinderbox/CURRENT/powerpc/powerpc/src/lib/msun/../libc/powerpc -c /tinderbox/CURRENT/powerpc/powerpc/src/lib/msun/src/k_sin.c cc -O2 -pipe -D_IEEE_LIBM -I/tinderbox/CURRENT/powerpc/powerpc/src/lib/msun/../libc/include -I/tinderbox/CURRENT/powerpc/powerpc/src/lib/msun/../libc/powerpc -c /tinderbox/CURRENT/powerpc/powerpc/src/lib/msun/src/k_sinf.c cc -O2 -pipe -D_IEEE_LIBM -I/tinderbox/CURRENT/powerpc/powerpc/src/lib/msun/../libc/include -I/tinderbox/CURRENT/powerpc/powerpc/src/lib/msun/../libc/powerpc -c /tinderbox/CURRENT/powerpc/powerpc/src/lib/msun/src/k_standard.c /tinderbox/CURRENT/powerpc/powerpc/src/lib/msun/src/k_standard.c: In function `__kernel_standard': /tinderbox/CURRENT/powerpc/powerpc/src/lib/msun/src/k_standard.c:150: error: `HUGE' undeclared (first use in this function) /tinderbox/CURRENT/powerpc/powerpc/src/lib/msun/src/k_standard.c:150: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/powerpc/powerpc/src/lib/msun/src/k_standard.c:150: error: for each function it appears in.) *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src/lib/msun. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. *** Error code 1 Stop in /tinderbox/CURRENT/powerpc/powerpc/src. TB --- 2005-01-14 23:37:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-01-14 23:37:23 - ERROR: failed to build world TB --- 2005-01-14 23:37:23 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 23:59:27 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E47516A4CE; Fri, 14 Jan 2005 23:59:27 +0000 (GMT) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B56E243D1F; Fri, 14 Jan 2005 23:59:26 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.1/8.13.1) with ESMTP id j0ENxQdu074009; Fri, 14 Jan 2005 18:59:26 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.1/8.13.1) with ESMTP id j0ENxPtN017589; Fri, 14 Jan 2005 18:59:25 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C55AD7306E; Fri, 14 Jan 2005 18:59:25 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050114235925.C55AD7306E@freebsd-current.sentex.ca> Date: Fri, 14 Jan 2005 18:59:25 -0500 (EST) X-Virus-Scanned: ClamAV 0.80/625/Fri Dec 10 12:41:57 2004 clamav-milter version 0.80j on clamscanner1 X-Virus-Scanned: ClamAV 0.80/649/Sun Jan 2 18:02:22 2005 clamav-milter version 0.80j on clamscanner1 X-Virus-Status: Clean X-Virus-Status: Clean Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 23:59:27 -0000 TB --- 2005-01-14 23:37:23 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-01-14 23:37:23 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-01-14 23:37:23 - checking out the source tree TB --- 2005-01-14 23:37:23 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-01-14 23:37:23 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-01-14 23:42:59 - building world (CFLAGS=-O2 -pipe) TB --- 2005-01-14 23:42:59 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-01-14 23:42:59 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] cc -O2 -pipe -D_IEEE_LIBM -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/msun/../libc/include -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/msun/../libc/sparc64 -c /tinderbox/CURRENT/sparc64/sparc64/src/lib/msun/src/k_rem_pio2f.c cc -O2 -pipe -D_IEEE_LIBM -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/msun/../libc/include -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/msun/../libc/sparc64 -c /tinderbox/CURRENT/sparc64/sparc64/src/lib/msun/src/k_sin.c cc -O2 -pipe -D_IEEE_LIBM -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/msun/../libc/include -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/msun/../libc/sparc64 -c /tinderbox/CURRENT/sparc64/sparc64/src/lib/msun/src/k_sinf.c cc -O2 -pipe -D_IEEE_LIBM -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/msun/../libc/include -I/tinderbox/CURRENT/sparc64/sparc64/src/lib/msun/../libc/sparc64 -c /tinderbox/CURRENT/sparc64/sparc64/src/lib/msun/src/k_standard.c /tinderbox/CURRENT/sparc64/sparc64/src/lib/msun/src/k_standard.c: In function `__kernel_standard': /tinderbox/CURRENT/sparc64/sparc64/src/lib/msun/src/k_standard.c:150: error: `HUGE' undeclared (first use in this function) /tinderbox/CURRENT/sparc64/sparc64/src/lib/msun/src/k_standard.c:150: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/sparc64/sparc64/src/lib/msun/src/k_standard.c:150: error: for each function it appears in.) *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src/lib/msun. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-01-14 23:59:25 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-01-14 23:59:25 - ERROR: failed to build world TB --- 2005-01-14 23:59:25 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 01:18:37 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78C6D16A4CE for ; Sat, 15 Jan 2005 01:18:37 +0000 (GMT) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 7641943D41 for ; Sat, 15 Jan 2005 01:18:36 +0000 (GMT) (envelope-from michaelnottebrock@gmx.net) Received: (qmail invoked by alias); 15 Jan 2005 01:18:35 -0000 Received: from pD95D86FA.dip.t-dialin.net (EHLO lofi.dyndns.org) (217.93.134.250) by mail.gmx.net (mp017) with SMTP; 15 Jan 2005 02:18:35 +0100 X-Authenticated: #443188 Received: from [192.168.8.4] (lofi@kiste.my.domain [192.168.8.4]) (authenticated bits=0) by lofi.dyndns.org (8.12.10/8.12.10) with ESMTP id j0F1ID0Z059447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 15 Jan 2005 02:18:17 +0100 (CET) (envelope-from michaelnottebrock@gmx.net) Message-ID: <41E86F55.4030906@gmx.net> Date: Sat, 15 Jan 2005 02:18:13 +0100 From: Michael Nottebrock User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en, de-de MIME-Version: 1.0 To: Steve Kargl References: <41DF253C.5040705@fer.hr> <20050108005540.GB93568@troutmask.apl.washington.edu> <20050108030707.GA3656@frontfree.net> <20050108034424.GA94365@troutmask.apl.washington.edu> <41E54C51.4000300@fer.hr> <20050112164022.GD28786@odin.ac.hmc.edu> <41E553EB.10809@criticalmagic.com> <20050112172608.GB16201@troutmask.apl.washington.edu> In-Reply-To: <20050112172608.GB16201@troutmask.apl.washington.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Y-GMX-Trusted: 0 cc: Richard Coleman cc: current@freebsd.org cc: Ivan Voras Subject: Re: MFC wishlist X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 15 Jan 2005 01:18:37 -0000 Steve Kargl wrote: > On Wed, Jan 12, 2005 at 11:44:27AM -0500, Richard Coleman wrote: > >>Brooks Davis wrote: >> >>>No, because the project has no ability to "assign >>>priority/resources". If someone who has is intrested and capable time >>>to work on it, does so in time, then it may be done, if not, it >>>won't. >>> >> >>Should we take this to mean that none of the developers are interested >>in ULE any more? That's the general feeling I get these days. Just >>curious. >> > > > As Brooks stated, Jeff is busy. He works on it when he > can. My problem is that system simply freezes. I can't > get a kernel dump, so its hard to provide more info. The broken crashdumps are really annoying. I've been harassing people on freebsd-stable about it before christmas (rwatson IIRC)... -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 01:24:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9046916A4CE for ; Sat, 15 Jan 2005 01:24:31 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 631F543D58 for ; Sat, 15 Jan 2005 01:24:31 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) j0F1ORsF051598; Fri, 14 Jan 2005 17:24:27 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)j0F1ORtI051597; Fri, 14 Jan 2005 17:24:27 -0800 (PST) (envelope-from sgk) Date: Fri, 14 Jan 2005 17:24:27 -0800 From: Steve Kargl To: Michael Nottebrock Message-ID: <20050115012427.GA51585@troutmask.apl.washington.edu> References: <41DF253C.5040705@fer.hr> <20050108005540.GB93568@troutmask.apl.washington.edu> <20050108030707.GA3656@frontfree.net> <20050108034424.GA94365@troutmask.apl.washington.edu> <41E54C51.4000300@fer.hr> <20050112164022.GD28786@odin.ac.hmc.edu> <41E553EB.10809@criticalmagic.com> <20050112172608.GB16201@troutmask.apl.washington.edu> <41E86F55.4030906@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41E86F55.4030906@gmx.net> User-Agent: Mutt/1.4.2.1i cc: Richard Coleman cc: current@freebsd.org cc: Ivan Voras Subject: Re: MFC wishlist X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 15 Jan 2005 01:24:31 -0000 On Sat, Jan 15, 2005 at 02:18:13AM +0100, Michael Nottebrock wrote: > Steve Kargl wrote: > >On Wed, Jan 12, 2005 at 11:44:27AM -0500, Richard Coleman wrote: > > > >>Brooks Davis wrote: > >> > >>>No, because the project has no ability to "assign > >>>priority/resources". If someone who has is intrested and capable time > >>>to work on it, does so in time, then it may be done, if not, it > >>>won't. > >>> > >> > >>Should we take this to mean that none of the developers are interested > >>in ULE any more? That's the general feeling I get these days. Just > >>curious. > >> > > > > > >As Brooks stated, Jeff is busy. He works on it when he > >can. My problem is that system simply freezes. I can't > >get a kernel dump, so its hard to provide more info. > > The broken crashdumps are really annoying. I've been harassing people on > freebsd-stable about it before christmas (rwatson IIRC)... > This isn't a broken crash dump problem. This is either a deadlock or livelock type problem. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 02:07:28 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA07616A4CE for ; Sat, 15 Jan 2005 02:07:28 +0000 (GMT) Received: from ran.psg.com (ip192.186.dsl-acs2.seawa0.iinet.com [209.20.186.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7327443D1F for ; Sat, 15 Jan 2005 02:07:28 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ran.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.43 (FreeBSD)) id 1CpdLb-000Meo-Us for freebsd-current@freebsd.org; Fri, 14 Jan 2005 18:07:28 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16872.31455.543832.92692@ran.psg.com> Date: Fri, 14 Jan 2005 18:07:27 -0800 To: FreeBSD Current Subject: breakage in current as of 01:25 gmt X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 15 Jan 2005 02:07:29 -0000 cc -O -pipe -march=pentiumpro -I/usr/src/lib/libtelnet/../../contrib/telnet -DENCRYPTION -DAUTHENTICATION -DSRA -c /usr/src/lib/libtelnet/../../contrib/telnet/libtelnet/enc_des.c cc -O -pipe -march=pentiumpro -I/usr/src/lib/libtelnet/../../contrib/telnet -DENCRYPTION -DAUTHENTICATION -DSRA -c /usr/src/lib/libtelnet/../../contrib/telnet/libtelnet/sra.c cc -O -pipe -march=pentiumpro -I/usr/src/lib/libtelnet/../../contrib/telnet -DENCRYPTION -DAUTHENTICATION -DSRA -c /usr/src/lib/libtelnet/../../contrib/telnet/libtelnet/pk.c building static telnet library ranlib libtelnet.a ===> lib/libthr (all) cc -O -pipe -march=pentiumpro -DPTHREAD_KERNEL -D_THREAD_SAFE -I/usr/src/lib/libthr/../libc/include -I/usr/src/lib/libthr/thread -I/usr/src/lib/libthr/../../include -I/usr/src/lib/libthr/../../libexec/rtld-elf -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/lib/libthr/thread/thr_atfork.c In file included from /usr/src/lib/libthr/thread/thr_private.h:72, from /usr/src/lib/libthr/thread/thr_atfork.c:36: /usr/obj/usr/src/i386/usr/include/sys/umtx.h: In function `umtx_wait': /usr/obj/usr/src/i386/usr/include/sys/umtx.h:118: warning: passing arg 5 of `_umtx_op' discards qualifiers from pointer target type *** Error code 1 Stop in /usr/src/lib/libthr. *** Error code 1 From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 03:58:45 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F93D16A4CE for ; Sat, 15 Jan 2005 03:58:45 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A97B43D39 for ; Sat, 15 Jan 2005 03:58:45 +0000 (GMT) (envelope-from nate@root.org) Received: from [10.0.5.51] (adsl-64-171-185-2.dsl.snfc21.pacbell.net [64.171.185.2])j0F3sIbs007937; Fri, 14 Jan 2005 22:54:19 -0500 Message-ID: <41E894E6.1080301@root.org> Date: Fri, 14 Jan 2005 19:58:30 -0800 From: Nate Lawson User-Agent: Mozilla Thunderbird 1.0RC1 (X11/20041205) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anholt References: <41E8137A.1050603@root.org> <1105740385.846.10.camel@leguin> In-Reply-To: <1105740385.846.10.camel@leguin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: FreeBSD Current Subject: Re: xorg-server doesn't build? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 15 Jan 2005 03:58:45 -0000 Eric Anholt wrote: > On Fri, 2005-01-14 at 10:46 -0800, Nate Lawson wrote: > >>I'm not sure if ports@ is the right list for this, but I have this build >>problem for xorg-server on -current: >> >>-D__XCONFIGDIR__='"/usr/X11R6/lib/X11"' -D__XLOGFILE__='"Xorg"' >>-D__XSERVERNAME__='"Xorg"' -D__XKBDEFRULES__='"xorg"' interface.c >>interface.c: In function `Usage': >>interface.c:224: warning: string length `630' is greater than the length >>`509' ISO C89 compilers are required to support >>interface.c: In function `main': >>interface.c:411: error: `compositeWidgetClass' undeclared (first use in >>this function) >>interface.c:411: error: (Each undeclared identifier is reported only once >>interface.c:411: error: for each function it appears in.) >>*** Error code 1 > > > I haven't heard back from the last person I responded to with this > issue, but could you reinstall xorg-libraries and try again? Yep, that was it. Thanks for the help. -- Nate From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 07:16:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAC9316A4CE; Sat, 15 Jan 2005 07:16:10 +0000 (GMT) Received: from mail19.syd.optusnet.com.au (mail19.syd.optusnet.com.au [211.29.132.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4C6A43D31; Sat, 15 Jan 2005 07:16:09 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) j0F7G7KJ010481 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 15 Jan 2005 18:16:08 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1])j0F7G7xP059532; Sat, 15 Jan 2005 18:16:07 +1100 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost)j0F7G6nX059531; Sat, 15 Jan 2005 18:16:06 +1100 (EST) (envelope-from pjeremy) Date: Sat, 15 Jan 2005 18:16:06 +1100 From: Peter Jeremy To: John Baldwin Message-ID: <20050115071606.GB53545@cirb503493.alcatel.com.au> References: <200501141546.31386.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501141546.31386.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2i cc: current@freebsd.org Subject: Re: [PATCH] Use local APIC timer to drive kernel clocks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 15 Jan 2005 07:16:10 -0000 On Fri, 2005-Jan-14 15:46:31 -0500, John Baldwin wrote: >I have a patch that uses the local APIC timer to drive the kernel clocks >(hardclock, statclock, and profclock) instead of the ISA timer and RTC. The >advantage of this change is that SMP machines can stop using IPIs to bounce >clock interrupts around all the time. What is the cost of an IPI compared to a hardware interrupt? > IPIs per second. Instead, I went with a simpler algorithm suggested by phk > that lets me run the timer at hz and guarantees that statclock() will be > called stathz times per second, just not evenly spaced. This would seem to negate the benefit of statclock. If a process synchronises to hardclock, and statclock is derived from hardclock then the process will also be synchronised to statclock - and can therefore (at least partially) circumvent the scheduler's attempts to stop processes hogging the CPI. AFAIK, the numbers 128 and 1024 are not magical to the scheduler, they are just convenient values that can be generated by the RTC. Rather than running the APIC timer at hz, you might get better detection of "rogue" processes by running the APIC timer at (say) 3000Hz with hz=apichz/3, profhz = apichz/2 (1500Hz) and stathz=apichz/23 (~130Hz) or 20 (120Hz). If it's acceptable hardclock to have significant jitter, you could further reduce synchronisation by using a fractional divisor for hz (eg hz=apichz/2.5). -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 08:38:48 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA6AB16A4CE for ; Sat, 15 Jan 2005 08:38:48 +0000 (GMT) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.199.47.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8254443D41 for ; Sat, 15 Jan 2005 08:38:48 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 74BBC5145A; Sat, 15 Jan 2005 00:38:47 -0800 (PST) Date: Sat, 15 Jan 2005 00:38:47 -0800 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20050115083847.GA47466@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: fstat triggered INVARIANTS panic in memrw() X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 15 Jan 2005 08:38:49 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The full panic string is panic: vm_fault: fault on nofault entry, addr: deae2000 ----- Forwarded message from Kris Kennaway ----- Date: Fri, 24 Dec 2004 17:42:08 -0800 From: Kris Kennaway To: current@FreeBSD.org Cc: phk@FreeBSD.org Subject: fstat triggered INVARIANTS panic User-Agent: Mutt/1.4.2.1i I ran fstat | more on a SMP 6.0 machine with kernel from about a month ago, which had a lot of files open. It panicked with: panic: vm_fault: fau and got no further on the console, but I was able to break to DBB and obtain the following traceback from fstat: db> tr 94874 Tracing pid 94874 tid 100815 td 0xc9ec1780 sched_switch(c9ec1780,c34dc480,1,11a,88a1da96) at sched_switch+0x105 mi_switch(6,c34dc480,c06d4ca0,271,c34dc5d0) at mi_switch+0x1d3 maybe_preempt(c34dc480,1,c06d4c85,3d6,46) at maybe_preempt+0x11d sched_add(c34dc480,4,c06d4ca0,1ce,c9ec1780,0,c06d11f3,197,197,c06d11f3) at = sched_add+0x299 setrunqueue(c34dc480,4,c06d11f3,197,c077a900) at setrunqueue+0x109 ithread_schedule(c34d4380,0,eed96788,a0f1b,c9ec1780) at ithread_schedule+0x= af intr_execute_handlers(c34d2ea8,eed967b8,eed96810,c0686583,45) at intr_execu= te_handlers+0x74 lapic_handle_intr(45) at lapic_handle_intr+0x2d Xapic_isr2() at Xapic_isr2+0x33 --- interrupt, eip =3D 0xc0519495, esp =3D 0xeed967fc, ebp =3D 0xeed96810 -= -- critical_exit(c0768120,0,c06ea261,a23,1) at critical_exit+0x75 siocnputc(c071b960,75,5,75,eed9696c) at siocnputc+0x9b cnputc(75,10,1,0,c06d396c) at cnputc+0x65 putchar(75,eed9696c,c0524e6c,30,13) at putchar+0xa8 kvprintf(c06d3963,c0524780,eed9696c,a,eed96990) at kvprintf+0x87d printf(c06d3963,c072c680,c06e688a,eed969bc,c9ec1780) at printf+0x54 panic(c06e688a,deae6000,1,eed96aa8,eed96a98) at panic+0xe1 vm_fault(c1059000,deae6000,1,0,c9ec1780) at vm_fault+0x1327 trap_pfault(deae6000,c9ec1780,eed96ba8,c050e2c3,deae6000) at trap_pfault+0x= 82 trap(c06e0018,10,c1050010,8058f20,deae5ffe) at trap+0x363 calltrap() at calltrap+0x5 --- trap 0xc, eip =3D 0xc0697f2a, esp =3D 0xeed96bcc, ebp =3D 0xeed96c04 --- generic_copyout(deadc0de,7ab7037c,eed96c84,54,5964d000) at generic_copyout+= 0x36 memrw(c34fad00,eed96c84,0,398,7ab7037c) at memrw+0x18a devfs_read_f(c51773b8,eed96c84,ca75c800,0,c9ec1780) at devfs_read_f+0x142 dofileread(4,804f000,7ab7037c,ffffffff,ffffffff) at dofileread+0x92 read(c9ec1780,eed96d14,c,3ff,3) at read+0x75 syscall(2f,2f,2f,7ab7037c,80b1078) at syscall+0x137 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (3, FreeBSD ELF32, read), eip =3D 0x280d347f, esp =3D 0xbfbfe34= c, ebp =3D 0xbfbfe378 --- Note the deadc0de in generic_copyout(). There seem to be several other bugs here that show off the well-known brokenness of panic() and related code on SMP machines. Kris ----- End forwarded message ----- --HlL+5n6rz5pIUxbD Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB6NaXWry0BWjoQKURAkyXAKD2EMTQkTQ8xF1SwHsNG3iKy+ViJgCfWi6a PkVx0rku0UlbyeUjU9zi2pM= =j9bA -----END PGP SIGNATURE----- --HlL+5n6rz5pIUxbD-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 09:32:42 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 977B616A4CE; Sat, 15 Jan 2005 09:32:42 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id B2B5543D1D; Sat, 15 Jan 2005 09:32:41 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j0F9Wduq000826; Sat, 15 Jan 2005 10:32:39 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Peter Jeremy From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 15 Jan 2005 18:16:06 +1100." <20050115071606.GB53545@cirb503493.alcatel.com.au> Date: Sat, 15 Jan 2005 10:32:39 +0100 Message-ID: <825.1105781559@critter.freebsd.dk> Sender: phk@critter.freebsd.dk cc: current@freebsd.org Subject: Re: [PATCH] Use local APIC timer to drive kernel clocks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 15 Jan 2005 09:32:42 -0000 In message <20050115071606.GB53545@cirb503493.alcatel.com.au>, Peter Jeremy wri tes: >This would seem to negate the benefit of statclock. If a process >synchronises to hardclock, and statclock is derived from hardclock >then the process will also be synchronised to statclock - and can >therefore (at least partially) circumvent the scheduler's attempts >to stop processes hogging the CPI. It is actually far worse than this. Back when hardclock() was new, the cpu would execute around 10000 instructions per tick, these days it will execute around 1000000 instructions per tick. Realistically we should have a Hz of 1MHz to maintain decent probabilities for scheduler and in particular profiling. Unfortunately, the time to service an interrupt has stayed close to constant while cpus got three orders of magnitude faster (mostly because the speed was gained by adding pipelines, caches etc) so this is utterly impossible. Results from statistical profiling is so close to meaningless these days that we might as well just remove it. statclock is a hard one, I think it is still cheaper than doing comprehensive accounting (ie: actually timing when you move between the three states) but I think the margins are getting smaller. Real computer architectures have hardware counters for that sort of stuff. Poul-Henning -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 12:20:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 111CB16A4CE; Sat, 15 Jan 2005 12:20:10 +0000 (GMT) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99F3943D41; Sat, 15 Jan 2005 12:20:07 +0000 (GMT) (envelope-from andrea@acampi.inet.it) Received: by acampi.inet.it (Postfix, from userid 1000) id 43C481A; Sat, 15 Jan 2005 13:20:06 +0100 (CET) Date: Sat, 15 Jan 2005 13:20:06 +0100 From: Andrea Campi To: John Baldwin Message-ID: <20050115122005.GA70274@webcom.it> References: <200501141546.31386.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200501141546.31386.jhb@FreeBSD.org> User-Agent: Mutt/1.5.6i cc: phk@FreeBSD.org cc: current@FreeBSD.org cc: bde@FreeBSD.org Subject: Re: [PATCH] Use local APIC timer to drive kernel clocks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 15 Jan 2005 12:20:10 -0000 On Fri, Jan 14, 2005 at 03:46:31PM -0500, John Baldwin wrote: > IPIs per second. Instead, I went with a simpler algorithm suggested by phk > that lets me run the timer at hz and guarantees that statclock() will be > called stathz times per second, just not evenly spaced. The same is true I guess this assumes hz > stathz? If that's true and this is committed, you should send a big headsup, as people may still have HZ=100 (I know that's not default, but habits are hard to change). Bye, Andrea -- Intel: where Quality is job number 0.9998782345! From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 13:47:18 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DB6116A4CE for ; Sat, 15 Jan 2005 13:47:18 +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 0717943D5A for ; Sat, 15 Jan 2005 13:47:18 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 59BE71201E; Sat, 15 Jan 2005 14:47:16 +0100 (CET) Date: Sat, 15 Jan 2005 14:47:15 +0100 From: "Simon L. Nielsen" To: Divacky Roman Message-ID: <20050115134715.GA769@zaphod.nitro.dk> References: <20050112092641.GA61635@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <20050112092641.GA61635@stud.fit.vutbr.cz> User-Agent: Mutt/1.5.6i cc: current@freebsd.org Subject: Re: non-killable process X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 15 Jan 2005 13:47:18 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2005.01.12 10:26:41 +0100, Divacky Roman wrote: > hi, >=20 > I have CFLAGS=3D-Os (dunno if it matters) compiled ports/net/iftop. and w= henever > I run it on recent 6-current it "hangs": > 880 v4 R+ 0:00.05 iftop > (ps ax output) >=20 > and it cannot be killed - I can repeat it, so this might reveal some bug.= I use > sched_ule. I'm seeing a similar problem on a 5.3-RELEASE SMP system using the 4BSD scheduler. I have two processes which just won't die. At first (before I knew there was a problem) I simply tried to kill the program with CTRL-C, but I don't know if that is related. I use -O optimizations. 34916 p0 RN+ 150:04,80 webazolver (webalizer) 34940 p0 RNE+ 31:17,24 webazolver (webalizer) I didn't "nice" the processes until after I had found out I couldn't kill them. Since this is my main mail/web/etc server I'm haven't tried to trace the proccesses in ddb yet. --=20 Simon L. Nielsen --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFB6R7jh9pcDSc1mlERAgPJAKDH63WIq2w3niItcS964nYD+sTNPACfTIOi 7rygRC60X0lhIbIZhLra7QE= =73gR -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From owner-freebsd-current@FreeBSD.ORG Fri Jan 14 14:36:37 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B72FD16A4CE for ; Fri, 14 Jan 2005 14:36:37 +0000 (GMT) Received: from bbnrelbul01.net.external.hp.com (bbnrelbul01.net.external.hp.com [155.208.255.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id C645E43D1D for ; Fri, 14 Jan 2005 14:36:36 +0000 (GMT) (envelope-from michaelc@tmbbobmc.bbn.hp.com) Received: from ebsc01.bbn.hp.com (ebsc01.bbn.hp.com [15.136.121.146]) by bbnrelbul01.net.external.hp.com (Postfix) with ESMTP id D7BC9380A0; Fri, 14 Jan 2005 15:36:25 +0100 (CET) Received: from tmbbobmc.bbn.hp.com (tmbbobmc.bbn.hp.com [15.136.123.54]) ESMTP id PAA14638; Fri, 14 Jan 2005 15:40:18 +0100 (MET) Received: from tmbbobmc.bbn.hp.com (localhost.localdomain [127.0.0.1]) by tmbbobmc.bbn.hp.com (8.12.11/8.12.11) with ESMTP id j0EEbJhG010933; Fri, 14 Jan 2005 15:37:19 +0100 Received: from localhost (michaelc@localhost)j0EEbEdi010930; Fri, 14 Jan 2005 15:37:18 +0100 Date: Fri, 14 Jan 2005 15:37:14 +0100 (CET) From: Michael Class To: Matthias Andree In-Reply-To: Message-ID: References: <41E568CE.9030905@gmx.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sat, 15 Jan 2005 14:19:46 +0000 cc: Michael Class cc: current@freebsd.org Subject: Re: SIL3112 and Maxtor 6Y160M0 SATA Disk: DMA Failure X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: michael.class@gmx.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jan 2005 14:36:37 -0000 On Thu, 13 Jan 2005, Matthias Andree wrote: > Michael Class writes: > >> recently I have added a cheap SIL3112 SATA controller in my system. > > The chip is buggy. > > Does the seller offer you to return that product and buy something else > in exchange? If recently is within a week or two, some offer such > "Umtausch" options. Well, I have read the sourcecode of the ata driver and found that there are two revisions of that chip. For the older one there is some special workaround. And if I remember well, that was about having two disks on one controller causing problems. I do have the newer revision of the chip. Up so far I have not read that these controllers do not work at all on FreeBSD. Yes, for sure I could exchange this controller, but unless we do a formal announcement that this controller will not be supported in FreeBSD, I do think that we will cause problems for FreeBSD reputation as these contollers are fairly widespread. I am not in an urgent need to have this working, so I am open to help with testing. Michael From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 04:13:11 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED7EC16A4CE for ; Sat, 15 Jan 2005 04:13:11 +0000 (GMT) Received: from mail26.sea5.speakeasy.net (mail26.sea5.speakeasy.net [69.17.117.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F93543D46 for ; Sat, 15 Jan 2005 04:13:11 +0000 (GMT) (envelope-from jordan@bxds.com) Received: (qmail 13939 invoked from network); 15 Jan 2005 04:13:11 -0000 Received: from dsl081-065-187.sfo1.dsl.speakeasy.net (HELO boxlightblack) ([64.81.65.187]) (envelope-sender ) by mail26.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 15 Jan 2005 04:13:10 -0000 From: "Jordan" To: Date: Fri, 14 Jan 2005 20:13:18 -0800 Message-ID: <004901c4fab8$8b62c910$0200a8c0@boxlightblack> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Importance: Normal X-Mailman-Approved-At: Sat, 15 Jan 2005 14:19:46 +0000 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.1 Subject: HighPoint RocketRAID 1820 Driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: jordan@bxds.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2005 04:13:12 -0000 Hi Scott,=20 =20 Hate to bother you, but I don't quite know where else to turn. We are = having trouble getting a HighPoint RocketRaid 182x to initialize during a = FBSD5.3 install. Do you have any ideas on how best to force an initialization = for this SATA controller? =20 Jordan Hilsenbeck =20 >>> Owner B O X L I G H T D E S I G N, I N C. =20 PC Tech Support | IT Consultation Toll Free: (866) 293-5330 Bay Area: (415) 462-5850 FAX: (415) 276-2342 =20 =20 =20 From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 15:55:46 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3861116A4CE for ; Sat, 15 Jan 2005 15:55:46 +0000 (GMT) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5A9143D48 for ; Sat, 15 Jan 2005 15:55:45 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id DB117C050 for ; Sat, 15 Jan 2005 16:55:44 +0100 (CET) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 6ACD3407C; Sat, 15 Jan 2005 16:55:38 +0100 (CET) Date: Sat, 15 Jan 2005 16:55:38 +0100 From: Jeremie Le Hen To: freebsd-current@freebsd.org Message-ID: <20050115155538.GA36629@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i Subject: no /dev/ums0 when module loaded X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 15 Jan 2005 15:55:46 -0000 Hi, I was playing a bit with devd(8) to have ums.ko automatically loaded when I plug my USB mouse. This works quite well except that it seems that ums0 is NOT detected when the module is loaded when the mouse is already plugged. Thus, when I match against the uhid(4) device to get the ums(4) module loaded, it cannot work since the module is inevitably loaded after the moused is plugged. Is this a bug or a feature ? I've been told that whenever an USB device is not grabbed by any driver on attach, it uses ugen(4) and it won't be possible to ``move'' it from ugen(4) to ums(4) later. FYI, I'm running -CURRENT from 2004/12/28. -- Jeremie Le Hen jeremie@le-hen.org From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 16:30:09 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AD2716A4CE for ; Sat, 15 Jan 2005 16:30:09 +0000 (GMT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA7BF43D48 for ; Sat, 15 Jan 2005 16:30:08 +0000 (GMT) (envelope-from bsdaemon@comcast.net) Received: from fw.home (pcp05404374pcs.norstn01.pa.comcast.net[68.80.144.252]) by comcast.net (sccrmhc12) with SMTP id <20050115163008012000u5ibe>; Sat, 15 Jan 2005 16:30:08 +0000 Received: (qmail 87773 invoked from network); 15 Jan 2005 16:30:06 -0000 Received: from kris.home (HELO ?192.168.0.251?) (192.168.0.251) by fw.home with SMTP; 15 Jan 2005 16:30:06 -0000 Message-ID: <41E94650.2060609@comcast.net> Date: Sat, 15 Jan 2005 11:35:28 -0500 From: Kris Maglione User-Agent: Mozilla Thunderbird 1.0 (X11/20041212) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20050112092641.GA61635@stud.fit.vutbr.cz> <20050115134715.GA769@zaphod.nitro.dk> In-Reply-To: <20050115134715.GA769@zaphod.nitro.dk> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: non-killable process X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 15 Jan 2005 16:30:09 -0000 Simon L. Nielsen wrote: >On 2005.01.12 10:26:41 +0100, Divacky Roman wrote: > > >>hi, >> >>I have CFLAGS=-Os (dunno if it matters) compiled ports/net/iftop. and whenever >>I run it on recent 6-current it "hangs": >> 880 v4 R+ 0:00.05 iftop >>(ps ax output) >> >>and it cannot be killed - I can repeat it, so this might reveal some bug. I use >>sched_ule. >> >From http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/basics-daemons.htm SIGKILL can not be ignored by a process. This is the ``I do not care what you are doing, stop right now'' signal. If you send SIGKILL to a process then FreeBSD will stop that process there and then[1]. [1] Not quite true--there are a few things that can not be interrupted. For example, if the process is trying to read from a file that is on another computer on the network, and the other computer has gone away for some reason (been turned off, or the network has a fault), then the process is said to be ``uninterruptible''. Eventually the process will time out, typically after two minutes. As soon as this time out occurs the process will be killed. From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 18:44:31 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C676716A4CE; Sat, 15 Jan 2005 18:44:31 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2BD2D43D1D; Sat, 15 Jan 2005 18:44:31 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id j0FImSNU011575; Sat, 15 Jan 2005 11:48:28 -0700 (MST) (envelope-from scottl@freebsd.org) Message-ID: <41E96426.5020508@freebsd.org> Date: Sat, 15 Jan 2005 11:42:46 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040929 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hackers@freebsd.org References: <41DA5C4D.1060606@freebsd.org> In-Reply-To: <41DA5C4D.1060606@freebsd.org> X-Enigmail-Version: 0.86.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: "current@freebsd.org" Subject: Last call! [Re: Call for FreeBSD status reports] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: monthly@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2005 18:44:31 -0000 All, This is a last call for status report submissions. If you intend to submit one, please do it in the next 12 hours. Thanks, Scott Scott Long wrote: > All, > > It's time again for the bi-monthly status reports. The July-Oct 2004 > status reports were preempted by the 5.3 release, so this one is open > for anything that has happened since June. As always, submissions > having to do with FreeBSD development, documentation, organized events, > etc, are welcome and highly encouraged. Submissions are due by Jan 15 > to monthly@freebsd.org > > There are also a couple of changes to announce. First is that Tom > Rhodes and Max Laier have volunteered to help run the status reports and > keep them more timely. Many thanks to Tom and Max for offering to > help. Second is that a couple of new attributes have been added to the > XML thanks to Max. The first is a project category attribute that will > enable us to group the submissions into categories and render the full > report with these categories for easier viewing. You can choose to use > whatever category tag fits your report best, or omit it entirely and let > us take care of it. The category mapping is listed below. Feel free to > suggest additional categories. > > proj - Projects (non-specific) > docs - Documentation > kern - Kernel > arch - Architectures > ports - Ports > vendor - Vendor / 3rd party software > misc - Miscellaneous > > The second new attribute lets you lists tasks for your project that > others can help with. An example is provided in the template under the > and tags. > > The template is available at > http://www.freebsd.org/news/status/report-sample.xml. I've just > committed the updated version with the new tags, so it might take a few > hours for it to reach the website for downloading. > > Submissions are due on Jan 15. Thanks a lot, and we are looking for a > big turn-out. > > Scott From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 19:06:53 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C95316A4CE for ; Sat, 15 Jan 2005 19:06:53 +0000 (GMT) Received: from critter.freebsd.dk (f170.freebsd.dk [212.242.86.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 513D343D3F for ; Sat, 15 Jan 2005 19:06:52 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.1/8.13.1) with ESMTP id j0FJ6ppS009552 for ; Sat, 15 Jan 2005 20:06:51 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: current@freebsd.org From: Poul-Henning Kamp Date: Sat, 15 Jan 2005 20:06:51 +0100 Message-ID: <9551.1105816011@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Subject: reproduced: ffs_blkfree: freeing free block X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 15 Jan 2005 19:06:53 -0000 Quite by accident my test-machine here can now reliably reproduce the dreaded "panic: ffs_blkfree: freeing free block" in a few minutes of time. It is very interesting that the location of the actual error is a very narrow stripe of the filesystem: dev = ad8, block = 13456368, fs = /hex dev = ad8, block = 13455888, fs = /hex dev = ad8, block = 13454688, fs = /hex dev = ad8, block = 13455040, fs = /hex dev = ad8, block = 13455200, fs = /hex dev = ad8, block = 13455880, fs = /hex The application I'm running at the time adds/modifies records in a db(3) hash file and nothing much besides. Before I start implementing complete I/O traces and spend days groveling over UFS/FFS on-disk bits, are there anybody who has suggestions for things I should try to enable/disable to narrow this down ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 19:09:49 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CD1816A4CE; Sat, 15 Jan 2005 19:09:49 +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 6D94943D49; Sat, 15 Jan 2005 19:09:48 +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 j0FJ9lOZ037612; Sat, 15 Jan 2005 11:09:48 -0800 (PST) (envelope-from kientzle@freebsd.org) Message-ID: <41E96A7B.3010400@freebsd.org> Date: Sat, 15 Jan 2005 11:09:47 -0800 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: David Schultz References: <200501120735.j0C7ZABq048856@repoman.freebsd.org> <41E5ED66.4070902@freebsd.org> <20050113072153.GA28485@VARK.MIT.EDU> <41E716F3.20504@freebsd.org> <20050114064806.GA10856@VARK.MIT.EDU> In-Reply-To: <20050114064806.GA10856@VARK.MIT.EDU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: "'freebsd-current@freebsd.org'" cc: Pawel Jakub Dawidek Subject: Re: fts improvements, alternatives X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 15 Jan 2005 19:09:49 -0000 David Schultz wrote: > On Thu, Jan 13, 2005, Tim Kientzle wrote: >> >>Here's a snapshot of the current WIP: >> >>http://people.freebsd.org/~kientzle/libarchive/src/tree.tgz > > Nice. That's much cleaner than the fts implementation (although > it doesn't do all that fts does.) So tell me again: when did you > say were you planning on rewriting/fixing fts? ;-) I updated the tree.tgz above with a quick sketch of a "du" based on tree. A few interesting things I found out: * du really requires "pre-descent" and "post-descent" hooks for each directory, so I added them to tree. * You can actually separate du's size storage from the traversal data pretty easily. I've never been entirely comfortable with the fts_number and fts_pointer fields on principle; this code shows a fairly simple way to avoid them. * I just used intmax_t for the size accumulators in du. That seemed the simplest (and most future-proof) datatype for the purpose. Cheers, Tim From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 20:56:10 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 85B3016A4CE for ; Sat, 15 Jan 2005 20:56:10 +0000 (GMT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18A4A43D5C for ; Sat, 15 Jan 2005 20:56:10 +0000 (GMT) (envelope-from bsdaemon@comcast.net) Received: from fw.home (pcp05404374pcs.norstn01.pa.comcast.net[68.80.144.252]) by comcast.net (sccrmhc11) with SMTP id <20050115205609011000ks90e>; Sat, 15 Jan 2005 20:56:09 +0000 Received: (qmail 19778 invoked from network); 15 Jan 2005 20:56:08 -0000 Received: from kris.home (HELO ?192.168.0.251?) (192.168.0.251) by fw.home with SMTP; 15 Jan 2005 20:56:08 -0000 Message-ID: <41E984AB.7060205@comcast.net> Date: Sat, 15 Jan 2005 16:01:31 -0500 From: Kris Maglione User-Agent: Mozilla Thunderbird 1.0 (X11/20041212) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Laptop won't boot -CURRENT after 8/04 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 15 Jan 2005 20:56:10 -0000 I am in the process of narrowing down the exact date that it stops booting, but my laptop won't boot any stable past an early BETA of 5.3 and it won't boot with -CURRENT from sometime in late 8/04. The latest date I tried was 1/14/05, I believe. The boot stops after detecting acd0 (cdrw/dvd-rom). In verbose mode, it stops at: GEOM: Configure ad0s1 start ... length ... end ... GEOM: Configure ad0s2[a-f] start ... length ... end ... The laptop doesn't have a serial port, and I've been testing with a FreesBIE CD, since the laptop has a slow HD, so I can't post the entire dmesg, though I can type out anything important. Can someone post an easy way to find all CVS changes between two dates? That would be extremely helpful in narrowing the source of the problem. Thanks From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 21:09:12 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63B9B16A4CE for ; Sat, 15 Jan 2005 21:09:12 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3B76043D1D for ; Sat, 15 Jan 2005 21:09:12 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) j0FL9B2A057591; Sat, 15 Jan 2005 13:09:11 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)j0FL9BU8057590; Sat, 15 Jan 2005 13:09:11 -0800 (PST) (envelope-from sgk) Date: Sat, 15 Jan 2005 13:09:11 -0800 From: Steve Kargl To: Kris Maglione Message-ID: <20050115210911.GB57529@troutmask.apl.washington.edu> References: <41E984AB.7060205@comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41E984AB.7060205@comcast.net> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: Laptop won't boot -CURRENT after 8/04 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 15 Jan 2005 21:09:12 -0000 On Sat, Jan 15, 2005 at 04:01:31PM -0500, Kris Maglione wrote: > I am in the process of narrowing down the exact date that it stops > booting, but my laptop won't boot any stable past an early BETA of 5.3 > and it won't boot with -CURRENT from sometime in late 8/04. The latest > date I tried was 1/14/05, I believe. The boot stops after detecting acd0 > (cdrw/dvd-rom). In verbose mode, it stops at: > GEOM: Configure ad0s1 start ... length ... end ... > GEOM: Configure ad0s2[a-f] start ... length ... end ... > This is a well known problem. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 21:25:51 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 324D816A4CE; Sat, 15 Jan 2005 21:25:51 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6AEF643D2F; Sat, 15 Jan 2005 21:25:50 +0000 (GMT) (envelope-from das@FreeBSD.ORG) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.13.1) with ESMTP id j0FLPjnG013743; Sat, 15 Jan 2005 16:25:45 -0500 (EST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.13.1/Submit) id j0FLPiFl013742; Sat, 15 Jan 2005 16:25:44 -0500 (EST) (envelope-from das@FreeBSD.ORG) Date: Sat, 15 Jan 2005 16:25:44 -0500 From: David Schultz To: Tim Kientzle Message-ID: <20050115212544.GA13274@VARK.MIT.EDU> Mail-Followup-To: Tim Kientzle , Pawel Jakub Dawidek , "'freebsd-current@freebsd.org'" References: <200501120735.j0C7ZABq048856@repoman.freebsd.org> <41E5ED66.4070902@freebsd.org> <20050113072153.GA28485@VARK.MIT.EDU> <41E716F3.20504@freebsd.org> <20050114064806.GA10856@VARK.MIT.EDU> <41E776DA.6080809@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41E776DA.6080809@freebsd.org> cc: "'freebsd-current@freebsd.org'" cc: Pawel Jakub Dawidek Subject: Re: fts improvements, alternatives X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 15 Jan 2005 21:25:51 -0000 On Thu, Jan 13, 2005, Tim Kientzle wrote: > David Schultz wrote: > >On Thu, Jan 13, 2005, Tim Kientzle wrote: > >> > >>As it happens, I started tinkering with these ideas > >>[about a better way to traverse directory trees] a > >>while ago but haven't found time to finish it all. > >> > >>Here's a snapshot of the current WIP: > >> > >>http://people.freebsd.org/~kientzle/libarchive/src/tree.tgz > > > >Nice. That's much cleaner than the fts implementation (although > >it doesn't do all that fts does.) So tell me again: when did you > >say were you planning on rewriting/fixing fts? ;-) > > The basic problems with fts are hard to fix > without breaking the API badly. On the other > hand, augmenting "tree" to the point that it can > replace fts in many (but not all) applications > would interest me. > > Since you've done more work with fts-using applications > than I have recently, you tell me: What does > "tree" absolutely require to be usable in a broad > cross-section of applications? It already does > what bsdtar needs, of course. I don't have experience with a ``broad cross-section'' of fts-using applications, but support for physical and logical traversals, not crossing a mount point, and the ability to choose whether to stat files or not, seem frequently used. Your library seems to have no problem with these, except that it calls stat(2) on every entry. For UFS, not calling stat(2) is an important optimization because it means only reading the (usually contiguous) contents of the directory rather than seeking to all the inodes for the files. I believe getdirentries(2) makes it possible to identify the type of a file without reading its inode, although the readdir(3) interface hides that information, forcing fts(3) to perform some acrobatics to infer that information. Given that your tree library doesn't suffer some of the limitations of fts, I think it would be a great addition to FreeBSD. Even better would be to reimplement fts and ftw as wrappers for it, if you think it would be reasonable to do so. ;-) From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 21:33:33 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E43BD16A4CE for ; Sat, 15 Jan 2005 21:33:33 +0000 (GMT) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F6BF43D53 for ; Sat, 15 Jan 2005 21:33:33 +0000 (GMT) (envelope-from bsdaemon@comcast.net) Received: from fw.home (pcp05404374pcs.norstn01.pa.comcast.net[68.80.144.252]) by comcast.net (sccrmhc12) with SMTP id <20050115213332012000qhave>; Sat, 15 Jan 2005 21:33:32 +0000 Received: (qmail 24258 invoked from network); 15 Jan 2005 21:33:31 -0000 Received: from kris.home (HELO ?192.168.0.251?) (192.168.0.251) by fw.home with SMTP; 15 Jan 2005 21:33:31 -0000 Message-ID: <41E98D6E.7080604@comcast.net> Date: Sat, 15 Jan 2005 16:38:54 -0500 From: Kris Maglione User-Agent: Mozilla Thunderbird 1.0 (X11/20041212) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <41E984AB.7060205@comcast.net> In-Reply-To: <41E984AB.7060205@comcast.net> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF419251FE23609C4A1C5FAC8" Subject: Re: Laptop won't boot -CURRENT after 8/04 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 15 Jan 2005 21:33:34 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF419251FE23609C4A1C5FAC8 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit For some reason, I'm not getting most mail from this list. I have to keep looking in the archives. Please bear with me. > This is a well known problem. I wouldn't expect a well known problem to go unfixed for over three months, although I have found references to similar problems. Nevertheless, I would like to find the commit that caused the breakage and, if possible, find a way to patch future releases so I can boot them. I have been stuck with 5.2.1 on this laptop for several months and would prefer not to have to switch to 4.x for lack of ACPI support or to DragonFly, for lack of a mature STABLE release. --------------enigF419251FE23609C4A1C5FAC8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB6Y1umcXjc1XBrAQRAiB1AKCwy1z3+fFeA1EHp9IlKWK80NjCDACeLUgo tzVcFwIpmE47Qhz5DHTlsqU= =O5gB -----END PGP SIGNATURE----- --------------enigF419251FE23609C4A1C5FAC8-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 22:06:21 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16CB816A4CE for ; Sat, 15 Jan 2005 22:06:21 +0000 (GMT) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id D303543D53 for ; Sat, 15 Jan 2005 22:06:20 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) j0FM6JNn058015; Sat, 15 Jan 2005 14:06:19 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost)j0FM6Jcg058014; Sat, 15 Jan 2005 14:06:19 -0800 (PST) (envelope-from sgk) Date: Sat, 15 Jan 2005 14:06:19 -0800 From: Steve Kargl To: Kris Maglione Message-ID: <20050115220619.GA57935@troutmask.apl.washington.edu> References: <41E984AB.7060205@comcast.net> <41E98D6E.7080604@comcast.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41E98D6E.7080604@comcast.net> User-Agent: Mutt/1.4.2.1i cc: freebsd-current@freebsd.org Subject: Re: Laptop won't boot -CURRENT after 8/04 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 15 Jan 2005 22:06:21 -0000 On Sat, Jan 15, 2005 at 04:38:54PM -0500, Kris Maglione wrote: > For some reason, I'm not getting most mail from this list. I have to > keep looking in the archives. Please bear with me. > > > This is a well known problem. > > I wouldn't expect a well known problem to go unfixed for over three > months, although I have found references to similar problems. One would certainly think bug reports of this nature would be addressed, but it is volunteer project. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 22:13:59 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3639D16A4CE for ; Sat, 15 Jan 2005 22:13:59 +0000 (GMT) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id C036143D2F for ; Sat, 15 Jan 2005 22:13:58 +0000 (GMT) (envelope-from bsdaemon@comcast.net) Received: from fw.home (pcp05404374pcs.norstn01.pa.comcast.net[68.80.144.252]) by comcast.net (sccrmhc11) with SMTP id <20050115221358011000mci5e>; Sat, 15 Jan 2005 22:13:58 +0000 Received: (qmail 29180 invoked from network); 15 Jan 2005 22:13:56 -0000 Received: from kris.home (HELO ?192.168.0.251?) (192.168.0.251) by fw.home with SMTP; 15 Jan 2005 22:13:56 -0000 Message-ID: <41E996E3.9010505@comcast.net> Date: Sat, 15 Jan 2005 17:19:15 -0500 From: Kris Maglione User-Agent: Mozilla Thunderbird 1.0 (X11/20041212) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <41E984AB.7060205@comcast.net> <41E98D6E.7080604@comcast.net> <20050115220619.GA57935@troutmask.apl.washington.edu> In-Reply-To: <20050115220619.GA57935@troutmask.apl.washington.edu> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2AE8A9323BC9B1FCDC5DE2D9" Subject: Re: Laptop won't boot -CURRENT after 8/04 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 15 Jan 2005 22:13:59 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2AE8A9323BC9B1FCDC5DE2D9 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Steve Kargl wrote: >On Sat, Jan 15, 2005 at 04:38:54PM -0500, Kris Maglione wrote: > > >>For some reason, I'm not getting most mail from this list. I have to >>keep looking in the archives. Please bear with me. >> >> > This is a well known problem. >> >>I wouldn't expect a well known problem to go unfixed for over three >>months, although I have found references to similar problems. >> >> > >One would certainly think bug reports of this nature would >be addressed, but it is volunteer project. > > Well, unfortunately, I don't have the expertise to address the problem for anyone other than myself. All I need is a way to find the commits between two dates to any file in the MAIN branch, although, I would obviously be willing to help with a more permanent solution in any way that I can. --------------enig2AE8A9323BC9B1FCDC5DE2D9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB6ZbnmcXjc1XBrAQRAqSpAJ4wU92yOSSJZVCmii9c4r63+j7s+QCgsXoq rN5dMC+FLudAcTpH42r/paQ= =rJZs -----END PGP SIGNATURE----- --------------enig2AE8A9323BC9B1FCDC5DE2D9-- From owner-freebsd-current@FreeBSD.ORG Sat Jan 15 23:30:00 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53BC416A4CE for ; Sat, 15 Jan 2005 23:30:00 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 018DF43D41 for ; Sat, 15 Jan 2005 23:30:00 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.1/8.13.1) with ESMTP id j0FNTqrf035987; Sat, 15 Jan 2005 15:29:56 -0800 (PST) (envelope-from truckman@FreeBSD.org) Message-Id: <200501152329.j0FNTqrf035987@gw.catspoiler.org> Date: Sat, 15 Jan 2005 15:29:52 -0800 (PST) From: Don Lewis To: phk@phk.freebsd.dk In-Reply-To: <9551.1105816011@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii cc: current@FreeBSD.org Subject: Re: reproduced: ffs_blkfree: freeing free block X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: 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, 15 Jan 2005 23:30:00 -0000 On 15 Jan, Poul-Henning Kamp wrote: > > Quite by accident my test-machine here can now reliably reproduce > the dreaded "panic: ffs_blkfree: freeing free block" in a few minutes > of time. > > It is very interesting that the location of the actual error is a > very narrow stripe of the filesystem: > > dev = ad8, block = 13456368, fs = /hex > dev = ad8, block = 13455888, fs = /hex > dev = ad8, block = 13454688, fs = /hex > dev = ad8, block = 13455040, fs = /hex > dev = ad8, block = 13455200, fs = /hex > dev = ad8, block = 13455880, fs = /hex > > The application I'm running at the time adds/modifies records in a > db(3) hash file and nothing much besides. > > Before I start implementing complete I/O traces and spend days > groveling over UFS/FFS on-disk bits, are there anybody who has > suggestions for things I should try to enable/disable to narrow > this down ? I'm reasonably certain that the on-disk bits are ok. I'm seeing it in the case where a freshly written file is being re-written. If I unmount the file system after the file is initially created, the file system fsck's clean, and if I then remount the file system, I am unable to reproduce the problem. Fsdb lists the block causing the panic as one that was initially allocated to the file. It looks like the in-core block bitmap is getting corrupted. In my openoffice build example, the following final step is sufficient to trigger the panic: jot -b x 174113 > \ /mnt/usr/ports/editors/openoffice-1.1/work/config_office/configure Merely truncating the file with "cat /dev/null" does not appear to be sufficient to trigger the panic.