From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 01:19:26 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4BCC116A41F; Sun, 18 Dec 2005 01:19:26 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3FC3943D5D; Sun, 18 Dec 2005 01:19:25 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jBI1JMnx036781; Sat, 17 Dec 2005 18:19:23 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43A4B91D.8040304@samsco.org> Date: Sat, 17 Dec 2005 18:19:25 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Jeremy References: <43A266E5.3080103@samsco.org> <20051217215434.GB92180@svcolo.com> <20051217220807.GA28741@freebie.xs4all.nl> <43A492B6.6050305@t-hosting.hu> <20051217232856.GT77268@cirb503493.alcatel.com.au> In-Reply-To: <20051217232856.GT77268@cirb503493.alcatel.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: stable@freebsd.org, =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= , current Subject: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2005 01:19:26 -0000 Peter Jeremy wrote: > On Sat, 2005-Dec-17 23:35:34 +0100, Kövesdán Gábor wrote: > >>I agree. And after all, tracking a security branch isn't too difficult, > > ... > >># cd /usr/src >># patch < /path/to/patch >># cd /usr/src/gnu/usr.bin/cvs/cvsbug >># make obj && make depend && make && make install >># cd /usr/src/gnu/usr.bin/send-pr >># make obj && make depend && make && make install >> >>Is that difficult? > > > Speaking as a developer, I think it's trivially easy. > > As an end user, I don't think this is acceptable. Firstly, it > requires that the user has installed the src distribution - which is > optional. Secondly, the user is expected to use development tools > without understanding what they do - this is scary for them. Running > the above commands is OK as long as nothing goes wrong but the > "support" group (who inhabit -questions and answer seemingly silly > questions) are going to have to cope with people who've made a typo > somewhere in the sequence and can't explain exactly what they did - > without putting them off FreeBSD. > > I think FreeBSD Update shows the way forward but IMHO there needs to > be an "official" binary update tool accessible from www.freebsd.org. > FreeBSD Update was written by, and is continuously maintained by the actual FreeBSD Security Officer. It's as official as it gets. If the only barrier to acceptance is that it's not distributed from the FreeBSD.org domain, then a) that's a silly argument, and b) it's easily solvable so long as Colin agrees. Scott From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 01:58:40 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9B2E016A41F; Sun, 18 Dec 2005 01:58:40 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B272A43D4C; Sun, 18 Dec 2005 01:58:39 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.4/8.13.4) with ESMTP id jBI1wcab072342; Sat, 17 Dec 2005 20:58:38 -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.3/8.13.3) with ESMTP id jBI1wcYl077044; Sat, 17 Dec 2005 20:58:38 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 37E627302F; Sat, 17 Dec 2005 20:58:38 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051218015838.37E627302F@freebsd-current.sentex.ca> Date: Sat, 17 Dec 2005 20:58:38 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2005 01:58:40 -0000 TB --- 2005-12-18 01:14:03 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-12-18 01:14:03 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-12-18 01:14:03 - cleaning the object tree TB --- 2005-12-18 01:14:41 - checking out the source tree TB --- 2005-12-18 01:14:41 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2005-12-18 01:14:41 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-12-18 01:20:51 - building world (CFLAGS=-O2 -pipe) TB --- 2005-12-18 01:20:51 - cd /src TB --- 2005-12-18 01:20:51 - /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 -c /src/libexec/rshd/rshd.c cc -O2 -pipe -o rshd rshd.o -lutil -lpam gzip -cn /src/libexec/rshd/rshd.8 > rshd.8.gz ===> libexec/rtld-elf (all) cc -O2 -pipe -Wall -DFREEBSD_ELF -DIN_RTLD -I/src/libexec/rtld-elf/amd64 -I/src/libexec/rtld-elf -elf -fpic -DPIC -Wformat=2 -Wno-format-extra-args -Werror -c /src/libexec/rtld-elf/amd64/rtld_start.S cc -O2 -pipe -Wall -DFREEBSD_ELF -DIN_RTLD -I/src/libexec/rtld-elf/amd64 -I/src/libexec/rtld-elf -elf -fpic -DPIC -Wformat=2 -Wno-format-extra-args -Werror -c /src/libexec/rtld-elf/amd64/reloc.c /src/libexec/rtld-elf/amd64/reloc.c: In function `reloc_non_plt': /src/libexec/rtld-elf/amd64/reloc.c:317: warning: int format, different type arg (arg 3) *** Error code 1 Stop in /src/libexec/rtld-elf. *** Error code 1 Stop in /src/libexec. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-12-18 01:58:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-12-18 01:58:37 - ERROR: failed to build world TB --- 2005-12-18 01:58:37 - tinderbox aborted TB --- 1.38 user 6.56 system 2674.55 real From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 02:34:47 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DBF9716A41F; Sun, 18 Dec 2005 02:34:47 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail27.syd.optusnet.com.au (mail27.syd.optusnet.com.au [211.29.133.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9D4C43D8D; Sun, 18 Dec 2005 02:34:31 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail27.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id jBI2YH44002609 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 18 Dec 2005 13:34:26 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id jBI2YHHh088178; Sun, 18 Dec 2005 13:34:17 +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 jBI2YEae088177; Sun, 18 Dec 2005 13:34:14 +1100 (EST) (envelope-from pjeremy) Date: Sun, 18 Dec 2005 13:34:13 +1100 From: Peter Jeremy To: Scott Long Message-ID: <20051218023413.GU77268@cirb503493.alcatel.com.au> References: <43A266E5.3080103@samsco.org> <20051217215434.GB92180@svcolo.com> <20051217220807.GA28741@freebie.xs4all.nl> <43A492B6.6050305@t-hosting.hu> <20051217232856.GT77268@cirb503493.alcatel.com.au> <43A4B91D.8040304@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A4B91D.8040304@samsco.org> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc Cc: stable@freebsd.org, current Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2005 02:34:48 -0000 On Sat, 2005-Dec-17 18:19:25 -0700, Scott Long wrote: >Peter Jeremy wrote: >>I think FreeBSD Update shows the way forward but IMHO there needs to >>be an "official" binary update tool accessible from www.freebsd.org. > >FreeBSD Update was written by, and is continuously maintained by the >actual FreeBSD Security Officer. I realise that. But nowhere does it state that it is an "official" Project tool (though it no longer seems to include the "this is not sanctioned by the FreeBSD Project" disclaimer that I thought it used to have). > If the only barrier to acceptance is that it's not distributed from the >FreeBSD.org domain, then a) that's a silly argument, and b) it's easily >solvable so long as Colin agrees. I agree it's easily solvable. I disagree that it's a silly argument. As an end user, I would expect to find online updates to Solaris at sun.com, Microsoft at microsoft.com, etc. If I run FreeBSD, I would expect to find FreeBSD updates at freebsd.org, not daemonology.net. A quick search starting at www.freebsd.org does not throw up any references to FreeBSD Update. If I didn't know that Colin Percival was the SO, there would be nothing to suggest that FreeBSD Update had any relationship to the FreeBSD Project. Computer users are slowly cottoning on to the idea of computer security. This is good. Encouraging them to find an apparently arbitrary site that says "upgrade your operating system here" does nothing to reinforce the concept that people should be careful about downloading software from "unknown" sources. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 02:37:31 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF46016A41F; Sun, 18 Dec 2005 02:37:31 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from mail.localelinks.com (web.localelinks.com [64.39.75.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23A3A43D60; Sun, 18 Dec 2005 02:37:27 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-144-221-183.jan.bellsouth.net [70.144.221.183]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.localelinks.com (Postfix) with ESMTP id 5BE67AD; Sat, 17 Dec 2005 20:37:26 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 2E6EF61C21; Sat, 17 Dec 2005 20:37:25 -0600 (CST) Date: Sat, 17 Dec 2005 20:37:25 -0600 From: "Matthew D. Fuller" To: Joe Rhett Message-ID: <20051218023725.GM63497@over-yonder.net> References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051217220021.GB93998@svcolo.com> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.2 Cc: stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2005 02:37:32 -0000 On Sat, Dec 17, 2005 at 02:00:21PM -0800 I heard the voice of Joe Rhett, and lo! it spake thus: > > Increasing the number of deployed systems out of date [...] This doesn't make any sense. If you install a 6.0 system, in 6 months (assuming you installed it right when 6.0 was cut, for simplicity), it will be 6 months out of date. It's neither more nor less out of date if the current release is then 6.1, or 6.2, or 8.12; it's still 6 months back. A case could, in fact, be made that more common releases lead to far FEWER deployed systems out of date, since it makes it far easier for those who already use binary upgrades instead of source to get things faster. Now, this is not to say that easier incremental binary upgrades are a bad thing, but bad analogy doesn't help anybody... -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 03:07:46 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6EDA16A41F for ; Sun, 18 Dec 2005 03:07:46 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: from smtpgate2.pacific.net.sg (smtpgate2.pacific.net.sg [203.120.90.32]) by mx1.FreeBSD.org (Postfix) with SMTP id B64B643D5E for ; Sun, 18 Dec 2005 03:07:44 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: (qmail 31942 invoked from network); 18 Dec 2005 03:07:42 -0000 Received: from maxwell6.pacific.net.sg (203.120.90.212) by smtpgate2.pacific.net.sg with SMTP; 18 Dec 2005 03:07:40 -0000 Received: from [192.168.0.107] ([210.24.124.189]) by maxwell6.pacific.net.sg with ESMTP id <20051218030740.OBXU16871.maxwell6.pacific.net.sg@[192.168.0.107]>; Sun, 18 Dec 2005 11:07:40 +0800 Message-ID: <43A4D209.2000609@pacific.net.sg> Date: Sun, 18 Dec 2005 11:05:45 +0800 From: Erich Dollansky Organization: oceanare pte ltd User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <43A266E5.3080103@samsco.org> <20051217215434.GB92180@svcolo.com> <20051217220807.GA28741@freebie.xs4all.nl> <43A492B6.6050305@t-hosting.hu> <20051217232856.GT77268@cirb503493.alcatel.com.au> <43A4B91D.8040304@samsco.org> In-Reply-To: <43A4B91D.8040304@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Jeremy , stable@freebsd.org, =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= , current Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2005 03:07:47 -0000 Hi, Scott Long wrote: > Peter Jeremy wrote: > >> I think FreeBSD Update shows the way forward but IMHO there needs to >> be an "official" binary update tool accessible from www.freebsd.org. >> > > FreeBSD Update was written by, and is continuously maintained by the > actual FreeBSD Security Officer. It's as official as it gets. If > the only barrier to acceptance is that it's not distributed from the > FreeBSD.org domain, then a) that's a silly argument, and b) it's easily > solvable so long as Colin agrees. > isn't this the problem Microsoft faces all the while when users download the latest security patch from somewhere in the Internet? Teaching water and drinking wine? Erich From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 19:48:31 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 81D0B16A41F; Sat, 17 Dec 2005 19:48:31 +0000 (GMT) (envelope-from ggajic@afrodita.rcub.bg.ac.yu) Received: from afrodita.rcub.bg.ac.yu (afrodita.rcub.bg.ac.yu [147.91.1.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0923E43D81; Sat, 17 Dec 2005 19:48:16 +0000 (GMT) (envelope-from ggajic@afrodita.rcub.bg.ac.yu) Received: from afrodita.rcub.bg.ac.yu (localhost.localdomain [127.0.0.1]) by afrodita.rcub.bg.ac.yu (8.13.4/8.13.4) with ESMTP id jBHJm1Zp015427; Sat, 17 Dec 2005 20:48:01 +0100 Received: from localhost (ggajic@localhost) by afrodita.rcub.bg.ac.yu (8.13.4/8.13.4/Submit) with ESMTP id jBHJm0Ba015424; Sat, 17 Dec 2005 20:48:01 +0100 Date: Sat, 17 Dec 2005 20:48:00 +0100 (CET) From: Goran Gajic To: Antoine Brodin In-Reply-To: <20051217001507.71b04041.antoine.brodin@laposte.net> Message-ID: References: <200512151356.41550.jhb@freebsd.org> <200512161525.12656.jhb@freebsd.org> <20051217001507.71b04041.antoine.brodin@laposte.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1536391169-827033337-1134848880=:15098" X-RCUB-MailScanner-Information: Please contact the RCUB if you have problem with mail X-RCUB-MailScanner: Found to be clean X-RCUB-MailScanner-From: ggajic@afrodita.rcub.bg.ac.yu X-Mailman-Approved-At: Sun, 18 Dec 2005 03:10:38 +0000 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: skype-1.2.0.18-static for linux and FreeBSD 7.0 CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Dec 2005 19:48:31 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1536391169-827033337-1134848880=:15098 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Sat, 17 Dec 2005, Antoine Brodin wrote: >> >> Ah, I think the stack_save() stuff in 6.0 is buggy. I think there's a fix in >> HEAD. I would just turn those DEBUG options off for now. > > Hi, > > Could you try the patch at : > http://bsd.miki.eu.org/~antoine/stack/stack-12-16.diff > > Cheers, > > Antoine > I would like to, but now kernel panics on boot. dumpdev=/dev/ad0s3b is ignored at /boot/loader.conf and set dumpdev at loader prompt also seems to be ignored (is there any other way to have dumpdev set if kernel panics before init?). I did cvsup today, but now options DEBUG_LOCKS and DEBUG_VFS_LOCKS when added produce panic.. I'm attaching what I could get from ddb. Regards, gg. --1536391169-827033337-1134848880=:15098-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 21:54:40 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 874BF16A41F; Sat, 17 Dec 2005 21:54:40 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C8FC43D5F; Sat, 17 Dec 2005 21:54:40 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id jBHLsdQL021353; Sat, 17 Dec 2005 13:54:39 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id jBHLsYtK093159; Sat, 17 Dec 2005 13:54:34 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id jBHLsYas093158; Sat, 17 Dec 2005 13:54:34 -0800 (PST) (envelope-from jrhett) Date: Sat, 17 Dec 2005 13:54:34 -0800 From: Joe Rhett To: Scott Long Message-ID: <20051217215434.GB92180@svcolo.com> References: <43A266E5.3080103@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A266E5.3080103@samsco.org> Organization: svcolo.com User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Sun, 18 Dec 2005 03:11:39 +0000 Cc: stable@freebsd.org, current Subject: Re: HEADS UP: Release schedule for 2006 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Dec 2005 21:54:40 -0000 On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: > There will be three FreeBSD 6 releases in 2006. While this is nice, may I suggest that it is time to put aside/delay one release cycle and come up with a binary update mechanism supported well by the OS? Increasing the speed of releases is good. Increasing the number of deployed systems out of date because there are no easy binary upgrade mechanisms is bad. It has been bad, it's getting worse. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 22:00:27 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8638F16A41F; Sat, 17 Dec 2005 22:00:27 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CAFA43D53; Sat, 17 Dec 2005 22:00:27 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id jBHM0RQL021620; Sat, 17 Dec 2005 14:00:27 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id jBHM0LK0094649; Sat, 17 Dec 2005 14:00:21 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id jBHM0LiU094647; Sat, 17 Dec 2005 14:00:21 -0800 (PST) (envelope-from jrhett) Date: Sat, 17 Dec 2005 14:00:21 -0800 From: Joe Rhett To: Scott Long Message-ID: <20051217220021.GB93998@svcolo.com> References: <43A266E5.3080103@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A266E5.3080103@samsco.org> Organization: svcolo.com User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Sun, 18 Dec 2005 03:11:57 +0000 Cc: stable@freebsd.org, current Subject: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Dec 2005 22:00:27 -0000 On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: > There will be three FreeBSD 6 releases in 2006. While this is nice, may I suggest that it is time to put aside/delay one release cycle and come up with a binary update mechanism supported well by the OS? Increasing the speed of releases is good. Increasing the number of deployed systems out of date because there are no easy binary upgrade mechanisms is bad. It has been bad, it's getting worse. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-current@FreeBSD.ORG Sat Dec 17 22:35:45 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DB7D16A41F; Sat, 17 Dec 2005 22:35:45 +0000 (GMT) (envelope-from gabor.kovesdan@t-hosting.hu) Received: from server.t-hosting.hu (server.t-hosting.hu [217.20.133.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id E85B343D53; Sat, 17 Dec 2005 22:35:44 +0000 (GMT) (envelope-from gabor.kovesdan@t-hosting.hu) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id 01895998419; Sat, 17 Dec 2005 23:35:43 +0100 (CET) Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 44714-04; Sat, 17 Dec 2005 23:35:39 +0100 (CET) Received: from [80.98.231.227] (catv-5062e7e3.catv.broadband.hu [80.98.231.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.t-hosting.hu (Postfix) with ESMTP id 916259983EE; Sat, 17 Dec 2005 23:35:39 +0100 (CET) Message-ID: <43A492B6.6050305@t-hosting.hu> Date: Sat, 17 Dec 2005 23:35:34 +0100 From: =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wilko Bulte References: <43A266E5.3080103@samsco.org> <20051217215434.GB92180@svcolo.com> <20051217220807.GA28741@freebie.xs4all.nl> In-Reply-To: <20051217220807.GA28741@freebie.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at t-hosting.hu X-Mailman-Approved-At: Sun, 18 Dec 2005 03:12:19 +0000 Cc: Joe Rhett , stable@freebsd.org, current Subject: Re: HEADS UP: Release schedule for 2006 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Dec 2005 22:35:45 -0000 Wilko Bulte wrote: >On Sat, Dec 17, 2005 at 01:54:34PM -0800, Joe Rhett wrote.. > > >>On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: >> >> >>>There will be three FreeBSD 6 releases in 2006. >>> >>> >>While this is nice, may I suggest that it is time to put aside/delay one >>release cycle and come up with a binary update mechanism supported well by >>the OS? Increasing the speed of releases is good. Increasing the number >>of deployed systems out of date because there are no easy binary upgrade >>mechanisms is bad. >> >>It has been bad, it's getting worse. >> >> > >So, when will you fix it? Or hire someone to fix it? FreeBSD after >all is mostly a volunteer operation. > > > I agree. And after all, tracking a security branch isn't too difficult, but the most people think that they have to do a complete "make buildworld" after a security advisory, but this isn't true. For example there was that cvsbug issue in September: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-05:20.cvsbug.asc One can read here: b) Execute the following commands as root: # cd /usr/src # patch < /path/to/patch # cd /usr/src/gnu/usr.bin/cvs/cvsbug # make obj && make depend && make && make install # cd /usr/src/gnu/usr.bin/send-pr # make obj && make depend && make && make install Is that difficult? I don't think so. No reboot required and it doesn't take more than 5 minutes even on a slower machine. Only the vulnerabilities in the kernel are problematic for servers, since they require a reboot. I think I'll submit a PR with a patch to clarify this in Handbook. Do you consider this useful? Regards, Gabor Kovesdan From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 03:49:30 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28BB316A41F for ; Sun, 18 Dec 2005 03:49:30 +0000 (GMT) (envelope-from ringworm01@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id B298243D55 for ; Sun, 18 Dec 2005 03:49:29 +0000 (GMT) (envelope-from ringworm01@gmail.com) Received: by wproxy.gmail.com with SMTP id i31so910012wra for ; Sat, 17 Dec 2005 19:49:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=CpZUkCRQ5U3djXC0CgqqmmwuZbIJdG7FwCB0fn5C2xyHM27jMPKrAyIOIOWm9EQjz5/IxJ+YDPleZyHU0Ec8RuxxoNSnrQAA69Vm2y8uA0SLKbSKPpMKflzZcXehZ08AVxBzJAfWmd/xeGjXFqcPGK3oNvqpUf1BYGinQRg445k= Received: by 10.64.3.11 with SMTP id 11mr279442qbc; Sat, 17 Dec 2005 19:49:28 -0800 (PST) Received: from ringworm.mechee.com ( [71.102.14.129]) by mx.gmail.com with ESMTP id a29sm1317285qbd.2005.12.17.19.49.27; Sat, 17 Dec 2005 19:49:28 -0800 (PST) From: "Michael C. Shultz" To: current@freebsd.org Date: Sat, 17 Dec 2005 19:49:23 -0800 User-Agent: KMail/1.8.3 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512171949.25301.ringworm01@gmail.com> Cc: Subject: sysctl -n kern.osreldate inop in todays 7.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2005 03:49:30 -0000 FreeBSD FreeBSD70.mechee.com 7.0-CURRENT FreeBSD 7.0-CURRENT #2: Sat Dec 17 10:16:14 PST 2005 mike@FreeBSD70.mechee.com:/usr/obj/usr/src/sys/FREEBSD70 i386 I just cvsup'ed/buildworld/buildkernel today and sysctl -n kern.osreldate isn't working. This is causing ports that use things like .if ${OSVERSION} < 500000 BROKEN= "Does not build on 4.X" .endif to be reported as broken. I'm not sure how long this problem has existed as I very rarely use FreeBSD CURRENT. -Mike From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 07:55:45 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CAC416A420 for ; Sun, 18 Dec 2005 07:55:45 +0000 (GMT) (envelope-from caiquanqing@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B43343D53 for ; Sun, 18 Dec 2005 07:55:43 +0000 (GMT) (envelope-from caiquanqing@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so723361wxc for ; Sat, 17 Dec 2005 23:55:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XBPCBeO7Co3KxUguEbIvuWF6l1qnibSdPmyEUrpBxKr9mzRQZXqeADU45RvaEIY6GHwYYb1g1Yrw4eUQqGxno2O2nZMeKJKTX+4Dm0hcQssjuJ5VfaQMonFL3QWI/Nz8RLzcMWWiBACaL27ivyj++V8ynXBwHOwh0dYZ4NQA1XY= Received: by 10.70.99.11 with SMTP id w11mr3102142wxb; Sat, 17 Dec 2005 23:55:43 -0800 (PST) Received: by 10.70.128.11 with HTTP; Sat, 17 Dec 2005 23:55:43 -0800 (PST) Message-ID: <2b22951e0512172355k36a579f4i42dd72562a3530ed@mail.gmail.com> Date: Sat, 17 Dec 2005 23:55:43 -0800 From: "Cai, Quanqing" To: freebsd-current@freebsd.org, Matthias Andree , Craig Rodrigues In-Reply-To: <20051217141647.GC27992@merlin.emma.line.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20051213151908.GA26821@crodrigues.org> <20051216151228.GA34670@crodrigues.org> <20051217141647.GC27992@merlin.emma.line.org> Cc: freebsd-fs@freebsd.org Subject: Re: XFS (read-only) support committed to CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2005 07:55:45 -0000 On 12/17/05, Matthias Andree wrote: > On Fri, 16 Dec 2005, Craig Rodrigues wrote: > > > Your comment makes no sense. What does being GPL have to do with > > choosing ext2fs vs. XFS? We ported XFS to FreeBSD because we felt like= it, > > and it was fun. [...] > > That's a compelling reason. Seriously. No offense, you could port ext3 too if you like... My company has 20s nfs servers(6 250G RAID 1 units), currently use SuSE9 w/XFS. I used ext3 on some but got long time fsck headache(Yes, I have data=3Djournal in fstab, but journal will fail under heavy load). So personally I prefer XFS. BTW, thank Craig Rodrigues, Alexander Kabaev, Russell Cattelan and all others for porting XFS to FreeBSD, it's a good news for community. We need a journal FS on FreeBSD so badly! Cai, Quanqing From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 08:23:04 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B561016A41F for ; Sun, 18 Dec 2005 08:23:04 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B28A043D5F for ; Sun, 18 Dec 2005 08:23:03 +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 jBI8MpgF061135; Sun, 18 Dec 2005 10:22:51 +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 09462-01-7; Sun, 18 Dec 2005 10:22:50 +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 jBI8Jttd060974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Dec 2005 10:19:55 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id jBI8K3Rd098216; Sun, 18 Dec 2005 10:20:03 +0200 (EET) (envelope-from ru) Date: Sun, 18 Dec 2005 10:20:02 +0200 From: Ruslan Ermilov To: Artemiev Igor Message-ID: <20051218082002.GR41326@ip.net.ua> References: <200512141749.jBEHnjRV081112@repoman.freebsd.org> <20051214183345.GE51686@ip.net.ua> <20051215093643.694e995b.ai@bmc.brk.ru> <200512151306.57961.jhb@freebsd.org> <20051216083657.GA41326@ip.net.ua> <20051216134225.09aa93a3.ai@bmc.brk.ru> <20051216111813.GE41326@ip.net.ua> <20051217084836.71eb86e6.ai@bmc.brk.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="15k5Fuw+yLfT1d9X" Content-Disposition: inline In-Reply-To: <20051217084836.71eb86e6.ai@bmc.brk.ru> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: cvs commit: src/sys/pci amdpm.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2005 08:23:04 -0000 --15k5Fuw+yLfT1d9X Content-Type: multipart/mixed; boundary="96icqjDFsSi85SgI" Content-Disposition: inline --96icqjDFsSi85SgI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 17, 2005 at 08:48:36AM +0300, Artemiev Igor wrote: > > i2c-amd8111.c and i2c-nforce2.c are indeed very similar, because they > > both use SMBus 2.0 API. :-) > ... > > See how the offset 0x2 register means completely different things. > Yep. Sorry for this little diversion :-(( > I wrote new driver, nfpm, which completely based on linux`s i2c- > nforce2 driver. Can you review it? > http://stalker.bmc.brk.ru/~ai/patches/nfpm.c >=20 You took lm_sensors sources too literally, without accounting for FreeBSD details. In FreeBSD (dumb, but it's too late to change that now), the slave 6-bit addresses are expected by smbus(4) methods already shifted, (addr << 1). My incomplete (but enough for xmbmon to work) version is attached and appears to work, according to the debugging output from the driver, but I eihter don't have any recognizable sensors on either of SMBusses I have available for testing, or something is very odd about it. It also supports AMD-8111 SMBus 2.0 controller. Note that I don't call bus_set_resource() in my driver. In my case (nVidia nForce3 Pro150 and AMD-8111 SMBus 2.0), the I/O port resources have already been allocated, nfpm0 pnpinfo vendor=3D0x10de device=3D0x00d4 subvendor=3D0x1043 subdevice= =3D0x80c5 class=3D0x0c0500 at slot=3D1 function=3D1 handle=3D\_SB_.PCI0.SMBS I/O ports: 0x5000-0x503f 0x5040-0x507f so bus_set_resource() were effectively trying to add 0x5000-... and 0x5040-... ranges again, and that causes problems for bus_alloc_resource_any() later. There's also an accompanying one-line patch for dev/smbus/smbus.c that adds: DRIVER_MODULE(smbus, nfpm, smbus_driver, smbus_devclass, 0, 0); Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --96icqjDFsSi85SgI-- --15k5Fuw+yLfT1d9X Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDpRuxqRfpzJluFF4RAuOYAJ0XSr8rLLeNgVjdpJUpTODz2TF1ogCgnOuD GWngt1TYo3jiO1NMJo2K34w= =CA0T -----END PGP SIGNATURE----- --15k5Fuw+yLfT1d9X-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 08:45:46 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E4BB16A41F for ; Sun, 18 Dec 2005 08:45:46 +0000 (GMT) (envelope-from weirdo@tehran.lain.pl) Received: from tehran.lain.pl (tehran.lain.pl [85.221.230.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF67643D5C for ; Sun, 18 Dec 2005 08:45:45 +0000 (GMT) (envelope-from weirdo@tehran.lain.pl) Received: from weirdo by tehran.lain.pl with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EnuAo-000EME-C8 for freebsd-current@freebsd.org; Sun, 18 Dec 2005 09:45:42 +0100 Date: Sun, 18 Dec 2005 09:45:41 +0100 From: Stanislaw Halik To: freebsd-current@freebsd.org Message-ID: <20051218084541.GA54909@tehran.lain.pl> References: <20051216133448.GA10382@beastie.creo.hu> <20051216151016.GE84442@deviant.zoral.local> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nFreZHaLTZJo0R7j" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://tehran.lain.pl/public.key User-Agent: Mutt/1.5.11 Subject: Re: Easy DoS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2005 08:45:46 -0000 --nFreZHaLTZJo0R7j Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Xin LI wrote: > Patch looks good so I have committed it as sys/kern/sys_pipe.c,v > 1.185. Thanks for the submission! any chances on getting a fast backport to RELENG_6_0? regards, --=20 Stanis=B3aw Halik, http://tehran.lain.pl --nFreZHaLTZJo0R7j Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDpSG1adU+vjT62TERAuScAJ4qFMY7JVXA9EMWsapgVfJfFhO7/ACfaoau 0qwj8K+M+En3Fl7IHnfzESs= =wfKw -----END PGP SIGNATURE----- --nFreZHaLTZJo0R7j-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 09:25:31 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2207716A41F; Sun, 18 Dec 2005 09:25:31 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: from mail.dt.e-technik.uni-dortmund.de (krusty.dt.E-Technik.uni-dortmund.de [129.217.163.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15F3E43D45; Sun, 18 Dec 2005 09:25:29 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: from localhost (localhost [127.0.0.1]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 8DDDA44129; Sun, 18 Dec 2005 10:25:28 +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 ESMTP id 13716-05; Sun, 18 Dec 2005 10:25:27 +0100 (CET) Received: from m2a2.dyndns.org (p50911889.dip0.t-ipconnect.de [80.145.24.137]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id C9F2E440A8; Sun, 18 Dec 2005 10:25:26 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id EED9F200717; Sun, 18 Dec 2005 10:25:25 +0100 (CET) Received: from m2a2.dyndns.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00415-06; Sun, 18 Dec 2005 10:25:23 +0100 (CET) Received: by merlin.emma.line.org (Postfix, from userid 500) id D4FAA200A39; Sun, 18 Dec 2005 10:25:23 +0100 (CET) Date: Sun, 18 Dec 2005 10:25:23 +0100 From: Matthias Andree To: "Cai, Quanqing" Message-ID: <20051218092523.GA4694@merlin.emma.line.org> Mail-Followup-To: "Cai, Quanqing" , freebsd-current@freebsd.org, freebsd-fs@freebsd.org References: <20051213151908.GA26821@crodrigues.org> <20051216151228.GA34670@crodrigues.org> <20051217141647.GC27992@merlin.emma.line.org> <2b22951e0512172355k36a579f4i42dd72562a3530ed@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2b22951e0512172355k36a579f4i42dd72562a3530ed@mail.gmail.com> X-PGP-Key: http://home.pages.de/~mandree/keys/GPGKEY.asc User-Agent: Mutt/1.5.11 X-Virus-Scanned: amavisd-new at dt.e-technik.uni-dortmund.de Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: XFS (read-only) support committed to CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2005 09:25:31 -0000 On Sat, 17 Dec 2005, Cai, Quanqing wrote: > On 12/17/05, Matthias Andree wrote: > > On Fri, 16 Dec 2005, Craig Rodrigues wrote: > > > > > Your comment makes no sense. What does being GPL have to do with > > > choosing ext2fs vs. XFS? We ported XFS to FreeBSD because we felt like it, > > > and it was fun. [...] > > > > That's a compelling reason. Seriously. > > No offense, you could port ext3 too if you like... > > My company has 20s nfs servers(6 250G RAID 1 units), currently use > SuSE9 w/XFS. I used ext3 on some but got long time fsck headache(Yes, > I have data=journal in fstab, but journal will fail under heavy load). > So personally I prefer XFS. Failing journals are either I/O errors (dying hard disk drive) or otherwise Linux kernel bugs. I have not yet seen ext3fs + NFS (or only the journals) break under load (SUSE 9.2 and 10.0) for any other reason than a broken drive or broken cables. If you have a workload that reproduces the problem, report it to SUSE. OTOH, it's "only" one Xeon NFS server with 1 70 GB RAID5 and 1 292 GB RAID5 (MegaRAID SCSI 320-1 with BBU) with half a dozen users at any one time. > BTW, thank Craig Rodrigues, Alexander Kabaev, Russell Cattelan and all > others for porting XFS to FreeBSD, it's a good news for community. We > need a journal FS on FreeBSD so badly! :-) -- Matthias Andree From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 09:55:52 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A61A16A41F; Sun, 18 Dec 2005 09:55:52 +0000 (GMT) (envelope-from m.seaman@infracaninophile.co.uk) Received: from smtp.infracaninophile.co.uk (ns0.infracaninophile.co.uk [81.187.76.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id B397D43D46; Sun, 18 Dec 2005 09:55:49 +0000 (GMT) (envelope-from m.seaman@infracaninophile.co.uk) Received: from [IPv6:::1] (localhost [IPv6:::1]) by smtp.infracaninophile.co.uk (8.13.4/8.13.4) with ESMTP id jBI9tdEA077826; Sun, 18 Dec 2005 09:55:40 GMT (envelope-from m.seaman@infracaninophile.co.uk) Message-ID: <43A53215.8090001@infracaninophile.co.uk> Date: Sun, 18 Dec 2005 09:55:33 +0000 From: Matthew Seaman Organization: Infracaninophile User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Chuck Swiger References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> <43A4A557.3010600@mac.com> In-Reply-To: <43A4A557.3010600@mac.com> X-Enigmail-Version: 0.93.0.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig4B2841E627D47D72C34079BE" X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (smtp.infracaninophile.co.uk [IPv6:::1]); Sun, 18 Dec 2005 09:55:40 +0000 (GMT) X-Virus-Scanned: ClamAV 0.87.1/1211/Fri Dec 16 22:51:35 2005 on happy-idiot-talk.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,NO_RELAYS autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on happy-idiot-talk.infracaninophile.co.uk Cc: Joe Rhett , stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2005 09:55:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4B2841E627D47D72C34079BE Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Chuck Swiger wrote: > Upgrading the ports from there was somewhat annoying, as this guy's machine had > ~400 or so, but deleting them all, and then using "pkg_add -r " works just fine > if you want to grab the latest current binaries. From there you can portupgrade > as usual. > > Now, if you want to talk about upgrading to intermediate patch releases, you've > got a valid point there. :-) Doesn't creating a binary updates system that's going to be practical to use require implementation of that old and exceedingly bikesheddable subject: packaging up the base system? After all, you're going to need some mechanism for auditing servers down the line (yes, this machine has had the vital fix to the foo daemon applied), and while bumping the patch level on the release sorta works to do that, it implies a new kernel and a reboot for each patch applied if it's going to be visible. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW --------------enig4B2841E627D47D72C34079BE 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.4.2 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDpTIb8Mjk52CukIwRA5ghAJ93xPRSJJcFgNU429W6CRxTSiaf8gCdG93f DuzOr5UrL/5t59sS6UzD7EM= =aytM -----END PGP SIGNATURE----- --------------enig4B2841E627D47D72C34079BE-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 10:02:43 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 3FEC916A41F; Sun, 18 Dec 2005 10:02:40 +0000 (GMT) (envelope-from davidxu@freebsd.org) Message-ID: <43A533E9.8010901@freebsd.org> Date: Sun, 18 Dec 2005 18:03:21 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.10) Gecko/20050806 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Craig Rodrigues References: <20051213151908.GA26821@crodrigues.org> <20051216151228.GA34670@crodrigues.org> In-Reply-To: <20051216151228.GA34670@crodrigues.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, Matthias Andree , freebsd-current@freebsd.org Subject: Re: XFS (read-only) support committed to CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2005 10:02:43 -0000 Craig Rodrigues wrote: >On Fri, Dec 16, 2005 at 12:15:17PM +0100, Matthias Andree wrote: > > >>Hm. Does this mean that FreeBSD's XFS implementation is GPL'd like >>ext2fs is? If so, allow me a question why XFS was chosen in preference >>to ext3fs? >> >> > >Your comment makes no sense. What does being GPL have to do with >choosing ext2fs vs. XFS? We ported XFS to FreeBSD because we felt like it, >and it was fun. ext3fs is irrelevant. > > > I would like to see writable XFS, this gives us another FS option, how diffcult would it be? :-) From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 10:54:28 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 10C6C16A41F; Sun, 18 Dec 2005 10:54:28 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5501943D58; Sun, 18 Dec 2005 10:54:24 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id B151C114AF; Sun, 18 Dec 2005 11:54:22 +0100 (CET) Date: Sun, 18 Dec 2005 11:54:22 +0100 From: "Simon L. Nielsen" To: Stanislaw Halik Message-ID: <20051218105421.GB860@zaphod.nitro.dk> References: <20051216133448.GA10382@beastie.creo.hu> <20051216151016.GE84442@deviant.zoral.local> <20051218084541.GA54909@tehran.lain.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="LpQ9ahxlCli8rRTG" Content-Disposition: inline In-Reply-To: <20051218084541.GA54909@tehran.lain.pl> User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org, Xin LI Subject: Re: Easy DoS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2005 10:54:28 -0000 --LpQ9ahxlCli8rRTG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2005.12.18 09:45:41 +0100, Stanislaw Halik wrote: > Xin LI wrote: > > Patch looks good so I have committed it as sys/kern/sys_pipe.c,v > > 1.185. Thanks for the submission! >=20 > any chances on getting a fast backport to RELENG_6_0? For that to happen it need to be in RELENG_6 for a while to make sure nothing is broken by the change and then an Errata Notice has to be made for the issue. That said, it sounds like a good candidate for an Errata Notice. --=20 Simon L. Nielsen FreeBSD Deputy Security Officer --LpQ9ahxlCli8rRTG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDpT/dh9pcDSc1mlERAnFiAJ4+oCIUc7CFiWV0T/qMoSrkz8mnKACgtUv1 jcdpkA40Vs+7JAS6586aE5s= =TeyT -----END PGP SIGNATURE----- --LpQ9ahxlCli8rRTG-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 12:26:07 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAF3616A420 for ; Sun, 18 Dec 2005 12:26:07 +0000 (GMT) (envelope-from delphij@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3042743D46 for ; Sun, 18 Dec 2005 12:26:06 +0000 (GMT) (envelope-from delphij@gmail.com) Received: by wproxy.gmail.com with SMTP id i31so938652wra for ; Sun, 18 Dec 2005 04:26:06 -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:content-disposition:references; b=DMLi7r1tXp7YrUiGnKeOyS/KkeU0Ot0W5d0u/yooh4JKPWBigkTYgiwYP0fMLGhE209P3kD+VTz2s231VPKNrBuoT4oFRqNuUaQnG0ecBHa3JwAyB7ttDDk1I5CcEt6csODCkxmSN05A9Lty/ShBqcMCIUNfZ/kvM5c9FlyUoNE= Received: by 10.65.205.2 with SMTP id h2mr1726096qbq; Sun, 18 Dec 2005 04:26:06 -0800 (PST) Received: by 10.65.72.5 with HTTP; Sun, 18 Dec 2005 04:26:06 -0800 (PST) Message-ID: Date: Sun, 18 Dec 2005 20:26:06 +0800 From: Xin LI To: Stanislaw Halik In-Reply-To: <20051218084541.GA54909@tehran.lain.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20051216133448.GA10382@beastie.creo.hu> <20051216151016.GE84442@deviant.zoral.local> <20051218084541.GA54909@tehran.lain.pl> Cc: freebsd-current@freebsd.org Subject: Re: Easy DoS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: delphij@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2005 12:26:08 -0000 SGksCgpPbiAxMi8xOC8wNSwgU3RhbmlzbGF3IEhhbGlrIDx3ZWlyZG9AdGVocmFuLmxhaW4ucGw+ IHdyb3RlOgo+IFhpbiBMSSA8ZGVscGhpakBnbWFpbC5jb20+IHdyb3RlOgo+ID4gUGF0Y2ggbG9v a3MgZ29vZCBzbyBJIGhhdmUgY29tbWl0dGVkIGl0IGFzIHN5cy9rZXJuL3N5c19waXBlLmMsdgo+ ID4gMS4xODUuICBUaGFua3MgZm9yIHRoZSBzdWJtaXNzaW9uIQo+Cj4gYW55IGNoYW5jZXMgb24g Z2V0dGluZyBhIGZhc3QgYmFja3BvcnQgdG8gUkVMRU5HXzZfMD8KCkkgYW0gdmVyeSBzdXJlIHRo YXQgdGhlIHBhdGNoIGlzIHN1aXRhYmxlIGZvciBSRUxFTkdfNl8wLCB0b28uCgpDaGVlcnMsCi0t ClhpbiBMSSA8ZGVscGhpakBkZWxwaGlqLm5ldD4gaHR0cDovL3d3dy5kZWxwaGlqLm5ldAo= From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 12:30:35 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 478B816A41F for ; Sun, 18 Dec 2005 12:30:35 +0000 (GMT) (envelope-from delphij@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4520943D45 for ; Sun, 18 Dec 2005 12:30:32 +0000 (GMT) (envelope-from delphij@gmail.com) Received: by wproxy.gmail.com with SMTP id i31so938943wra for ; Sun, 18 Dec 2005 04:30:31 -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:content-disposition:references; b=s4/o3IbO4wJO09omtH06YOkIAvKt8ryHmi3WSRTVOEHJlsZSuQezN9kQfH+6T29GQm+HbSql16Omhh90Z+9Yzp/dJtZ+r1hqGKr3EinoHihZ/MBzgmC/9foNzDd3lZ6/MiGjk4e8MP/eZA7TlmJIAgeQYL/vgjd7DkOojm4x3X0= Received: by 10.64.232.6 with SMTP id e6mr1712412qbh; Sun, 18 Dec 2005 04:30:31 -0800 (PST) Received: by 10.65.72.5 with HTTP; Sun, 18 Dec 2005 04:30:31 -0800 (PST) Message-ID: Date: Sun, 18 Dec 2005 20:30:31 +0800 From: Xin LI To: "Simon L. Nielsen" In-Reply-To: <20051218105421.GB860@zaphod.nitro.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20051216133448.GA10382@beastie.creo.hu> <20051216151016.GE84442@deviant.zoral.local> <20051218084541.GA54909@tehran.lain.pl> <20051218105421.GB860@zaphod.nitro.dk> Cc: Stanislaw Halik , freebsd-current@freebsd.org, Xin LI Subject: Re: Easy DoS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: delphij@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2005 12:30:35 -0000 SGksIFNpbW9uLAoKT24gMTIvMTgvMDUsIFNpbW9uIEwuIE5pZWxzZW4gPHNpbW9uQGZyZWVic2Qu b3JnPiB3cm90ZToKPiBPbiAyMDA1LjEyLjE4IDA5OjQ1OjQxICswMTAwLCBTdGFuaXNsYXcgSGFs aWsgd3JvdGU6Cj4gPiBYaW4gTEkgPGRlbHBoaWpAZ21haWwuY29tPiB3cm90ZToKPiA+ID4gUGF0 Y2ggbG9va3MgZ29vZCBzbyBJIGhhdmUgY29tbWl0dGVkIGl0IGFzIHN5cy9rZXJuL3N5c19waXBl LmMsdgo+ID4gPiAxLjE4NS4gIFRoYW5rcyBmb3IgdGhlIHN1Ym1pc3Npb24hCj4gPgo+ID4gYW55 IGNoYW5jZXMgb24gZ2V0dGluZyBhIGZhc3QgYmFja3BvcnQgdG8gUkVMRU5HXzZfMD8KPgo+IEZv ciB0aGF0IHRvIGhhcHBlbiBpdCBuZWVkIHRvIGJlIGluIFJFTEVOR182IGZvciBhIHdoaWxlIHRv IG1ha2Ugc3VyZQo+IG5vdGhpbmcgaXMgYnJva2VuIGJ5IHRoZSBjaGFuZ2UgYW5kIHRoZW4gYW4g RXJyYXRhIE5vdGljZSBoYXMgdG8gYmUKPiBtYWRlIGZvciB0aGUgaXNzdWUuICBUaGF0IHNhaWQs IGl0IHNvdW5kcyBsaWtlIGEgZ29vZCBjYW5kaWRhdGUgZm9yIGFuCj4gRXJyYXRhIE5vdGljZS4K CkRvIHdlIHR5cGljYWxseSBpc3N1ZSBFcnJhdGEgTm90aWNlIGZvciBsb2NhbCBEb1MgaW4gdGhl IHBhc3Q/ICBJCnRoaW5rIHRoaXMgaXMgYSBzZXJpb3VzIHByb2JsZW0sIGJ1dCBub3QgdmVyeSBz dXJlIHdoZXRoZXIgaXQgc2hvdWxkCmJlIG1lcmdlZCBiYWNrIHRvIFJFTEVOR182XzAsIHRob3Vn aC4gIElmIHNvQCBhbmQgcmVAIGFncmVlcyBJIHdvdWxkCmJlIGhhcHB5IHRvIGRvIHNvbWUgZG9j dW1lbnRhcnkgd29yayBmb3IgdGhlIEVycmF0YSBOb3RpY2UgOi0pCgpDaGVlcnMsCi0tClhpbiBM SSA8ZGVscGhpakBkZWxwaGlqLm5ldD4gaHR0cDovL3d3dy5kZWxwaGlqLm5ldAo= From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 12:44:51 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38BB816A41F; Sun, 18 Dec 2005 12:44:51 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C632B43D6E; Sun, 18 Dec 2005 12:44:41 +0000 (GMT) (envelope-from dunstan@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [80.48.250.4]) by freebsd.czest.pl (8.12.10/8.12.9) with ESMTP id jBICl7Px080025; Sun, 18 Dec 2005 12:47:07 GMT (envelope-from dunstan@freebsd.czest.pl) Received: (from dunstan@localhost) by freebsd.czest.pl (8.13.4/8.12.9/Submit) id jBICl7E1080024; Sun, 18 Dec 2005 12:47:07 GMT (envelope-from dunstan) Date: Sun, 18 Dec 2005 12:47:06 +0000 From: "Wojciech A. Koszek" To: "Simon L. Nielsen" Message-ID: <20051218124706.GB79822@FreeBSD.czest.pl> References: <20051216133448.GA10382@beastie.creo.hu> <20051216151016.GE84442@deviant.zoral.local> <20051218084541.GA54909@tehran.lain.pl> <20051218105421.GB860@zaphod.nitro.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <20051218105421.GB860@zaphod.nitro.dk> User-Agent: Mutt/1.4.2.1i Cc: Stanislaw Halik , freebsd-current@freebsd.org, Xin LI Subject: Re: Easy DoS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2005 12:44:51 -0000 On Sun, Dec 18, 2005 at 11:54:22AM +0100, Simon L. Nielsen wrote: > On 2005.12.18 09:45:41 +0100, Stanislaw Halik wrote: > > Xin LI wrote: > > > Patch looks good so I have committed it as sys/kern/sys_pipe.c,v > > > 1.185. Thanks for the submission! > > > > any chances on getting a fast backport to RELENG_6_0? > > For that to happen it need to be in RELENG_6 for a while to make sure > nothing is broken by the change and then an Errata Notice has to be > made for the issue. That said, it sounds like a good candidate for an > Errata Notice. If you release a notice, large number of problems will by silently marked as "skipped", since they have neither had their entries in Release Notes, nor have been released as a separate errata. The problem with bugs like that comes over and over again. I have reported two local DoSes and none of them was a reason for releasing an errata. They were (quite) serious: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/if.c?rev=1.199.2.12&content-type=text/x-cvsweb-markup http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/net/if_clone.c?rev=1.6&content-type=text/x-cvsweb-markup Also problem with PECOFF handling resulted in local DoS, but I agree it's not worth documenting, since it's not included by default. I remember those problems were also serious and involved similar discussion: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/fs/devfs/devfs_vnops.c?rev=1.128&content-type=text/x-cvsweb-markup http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/imgact_shell.c?rev=1.31&content-type=text/x-cvsweb-markup http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/imgact_shell.c?rev=1.35&content-type=text/x-cvsweb-markup http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/opencrypto/cryptodev.c?rev=1.25.2.1&content-type=text/x-cvsweb-markup (even applicable to RELENG_4): http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/opencrypto/cryptodev.c?rev=1.4.2.5&content-type=text/x-cvsweb-markup There was a plan of updating security page to note, which type of problems needs to be coordinated with security officer (local DoSes does not) and which type of problems classifies for an errata. Is it still on someone's TODO? Regards, -- * Wojciech A. Koszek && dunstan@FreeBSD.czest.pl From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 12:51:13 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4418716A41F; Sun, 18 Dec 2005 12:51:13 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id B20D743D45; Sun, 18 Dec 2005 12:51:12 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 349EE114AF; Sun, 18 Dec 2005 13:51:11 +0100 (CET) Date: Sun, 18 Dec 2005 13:51:10 +0100 From: "Simon L. Nielsen" To: delphij@delphij.net Message-ID: <20051218125110.GC860@zaphod.nitro.dk> References: <20051216133448.GA10382@beastie.creo.hu> <20051216151016.GE84442@deviant.zoral.local> <20051218084541.GA54909@tehran.lain.pl> <20051218105421.GB860@zaphod.nitro.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DIOMP1UsTsWJauNi" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11 Cc: Stanislaw Halik , freebsd-current@freebsd.org, Xin LI Subject: Re: Easy DoS X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2005 12:51:13 -0000 --DIOMP1UsTsWJauNi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2005.12.18 20:30:31 +0800, Xin LI wrote: > Hi, Simon, >=20 > On 12/18/05, Simon L. Nielsen wrote: > > On 2005.12.18 09:45:41 +0100, Stanislaw Halik wrote: > > > Xin LI wrote: > > > > Patch looks good so I have committed it as sys/kern/sys_pipe.c,v > > > > 1.185. Thanks for the submission! > > > > > > any chances on getting a fast backport to RELENG_6_0? > > > > For that to happen it need to be in RELENG_6 for a while to make sure > > nothing is broken by the change and then an Errata Notice has to be > > made for the issue. That said, it sounds like a good candidate for an > > Errata Notice. >=20 > Do we typically issue Errata Notice for local DoS in the past? I > think this is a serious problem, but not very sure whether it should > be merged back to RELENG_6_0, though. If so@ and re@ agrees I would > be happy to do some documentary work for the Errata Notice :-) I'm can't remember if we have actually done any Errata's for local DoS issues, but it has been discussed a few times between so@ and re@ and the general agreement has been that it is a good idea. I know there was at least one other local DoS issue for 6.0 that has been proposed as an Errata, but I don't know the status of it. --=20 Simon L. Nielsen FreeBSD Deputy Security Officer --DIOMP1UsTsWJauNi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDpVs+h9pcDSc1mlERAjJJAJ9XVS1sBo4gCF6u4b27VqrM3I9RhgCfeRXx pwKbqsP+LEcjDYvVIxObjGk= =xAXE -----END PGP SIGNATURE----- --DIOMP1UsTsWJauNi-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 17:13:55 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14F6016A422; Sun, 18 Dec 2005 17:13:55 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CBEB43D5F; Sun, 18 Dec 2005 17:13:11 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id 0678D1A3C1A; Sun, 18 Dec 2005 09:13:10 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 6855351242; Sun, 18 Dec 2005 12:13:09 -0500 (EST) Date: Sun, 18 Dec 2005 12:13:09 -0500 From: Kris Kennaway To: Matthew Seaman Message-ID: <20051218171308.GA20557@xor.obsecurity.org> References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> <43A4A557.3010600@mac.com> <43A53215.8090001@infracaninophile.co.uk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2fHTh5uZTiUOsy+g" Content-Disposition: inline In-Reply-To: <43A53215.8090001@infracaninophile.co.uk> User-Agent: Mutt/1.4.2.1i Cc: Joe Rhett , stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2005 17:13:56 -0000 --2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 18, 2005 at 09:55:33AM +0000, Matthew Seaman wrote: > Chuck Swiger wrote: >=20 > >Upgrading the ports from there was somewhat annoying, as this guy's=20 > >machine had > >~400 or so, but deleting them all, and then using "pkg_add -r " works ju= st=20 > >fine > >if you want to grab the latest current binaries. From there you can=20 > >portupgrade > >as usual. > > > >Now, if you want to talk about upgrading to intermediate patch releases,= =20 > >you've > >got a valid point there. :-) >=20 > Doesn't creating a binary updates system that's going to be practical to = use > require implementation of that old and exceedingly bikesheddable subject:= =20 > packaging > up the base system? No, after all the *existing* binary update systems don't require packaging of the base system. Kris --2fHTh5uZTiUOsy+g Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDpZikWry0BWjoQKURAvTSAKDLj/qk806/kOlSpxqOuYzjOIp/3wCfRu1/ gsh6TvfeRJ40HCVp8Wg9n70= =SU7Q -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 17:33:36 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D06316A41F for ; Sun, 18 Dec 2005 17:33:36 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2A54543D5F for ; Sun, 18 Dec 2005 17:33:34 +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 jBIHXGeR073757; Sun, 18 Dec 2005 19:33:16 +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 14333-04; Sun, 18 Dec 2005 19:33:11 +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 jBIHUPCX073674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 18 Dec 2005 19:30:25 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id jBIHUXqA099886; Sun, 18 Dec 2005 19:30:33 +0200 (EET) (envelope-from ru) Date: Sun, 18 Dec 2005 19:30:28 +0200 From: Ruslan Ermilov To: Jeremy Messenger , Vladimir Timofeev Message-ID: <20051218173028.GV41326@ip.net.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cjVziHhGDpplWqiR" Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: current@FreeBSD.org Subject: New nfpm.c driver available for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2005 17:33:36 -0000 --cjVziHhGDpplWqiR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, A new nfpm(4) driver is available for testing: http://people.freebsd.org/~ru/patches/nfpm.patch http://people.freebsd.org/~ru/patches/smbtest.c This driver supports nVidia nForce2/3/4 and AMD-8111 SMBus 2.0 controllers. 1. Make sure to create an empty sys/modules/i2c/nfpm/ directory before you apply the patch. 2. Make sure sys/dev/smbus/smbus.c has patched. :-) 3. Recompile and reinstall everything in /sys/modules/i2c/: cd /sys/modules/i2c && make obj && make && make install 4. Reboot and load nfpm.ko and smb.ko from loader(8). NB: On my machine, kldload/kldunload/kldload of nfpm.ko results in non-working driver, due to some yet to be solved I/O resource problem. 5. Check if nfpm0 and nfpm1 devices have been created. 6. Make sure /dev/smb[01] nodes exist. 7. Compile and run the smbtest utility, run it twice, first with /dev/smb0 and then with /dev/smb1 as the only argument. # ./smbtest /dev/smb0 found slave device 8 found slave device 80 found slave device 81 # ./smbtest /dev/smb1 found slave device 8 8. Patch sysutils/xmbmon sources and substitute the PCI ID of your SMBus 2.0 controller (see "pciconf -lv", "nfpm0"): cd /usr/ports/sysutils/xmbmon make patch vi /pci_pm.h make install 8. Run mbmon: mbmon -S -s0 -d mbmon -S -s1 -d If any sensors are detected, e.g. on /dev/smb1 (-s1) try them: mbmon -S -s1 -c8 1 9. Send me the output of "pciconf -lv" and mbmon commands above. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --cjVziHhGDpplWqiR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDpZyzqRfpzJluFF4RAqGGAJwIuiNH0XWJVWq6D8zLwJJkfOAbdACdEqez khSlU74cqG/ZSVEHZjwubl4= =n25t -----END PGP SIGNATURE----- --cjVziHhGDpplWqiR-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 21:21:11 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3F5E16A41F for ; Sun, 18 Dec 2005 21:21:10 +0000 (GMT) (envelope-from rmgls@wanadoo.fr) Received: from smtp14.wanadoo.fr (smtp14.wanadoo.fr [193.252.23.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4045243D69 for ; Sun, 18 Dec 2005 21:21:10 +0000 (GMT) (envelope-from rmgls@wanadoo.fr) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1404.wanadoo.fr (SMTP Server) with ESMTP id BDC4270000CB for ; Sun, 18 Dec 2005 22:21:08 +0100 (CET) Received: from wanadoo.fr (ARouen-251-1-6-252.w83-115.abo.wanadoo.fr [83.115.99.252]) by mwinf1404.wanadoo.fr (SMTP Server) with ESMTP id B01A470000AF for ; Sun, 18 Dec 2005 22:21:08 +0100 (CET) X-ME-UUID: 20051218212108721.B01A470000AF@mwinf1404.wanadoo.fr Received: from rmgls by bip.private.music with local (Exim 4.52) id 1Eo5xr-0000C0-RE for freebsd-current@freebsd.org; Sun, 18 Dec 2005 22:21:07 +0100 Date: Sun, 18 Dec 2005 22:21:07 +0100 From: rmgls@wanadoo.fr To: freebsd-current@freebsd.org Message-ID: <20051218212107.GA720@wanadoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: no disk found on sony vaio s5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2005 21:21:11 -0000 hello all, i try to install FreeBSD 6.0 on a sony vaio s5. at boot, FreeBSD find the disk 0 with 3 used partitions. in the installer, fdisk does not find any disk. any idea to help? thanks in advance. raoul rmgls@wanadoo.Fr From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 21:43:13 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 22D4F16A41F for ; Sun, 18 Dec 2005 21:43:13 +0000 (GMT) (envelope-from victor@bsdes.net) Received: from alf.dyndns.ws (244.Red-217-126-240.staticIP.rima-tde.net [217.126.240.244]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E0F543D49 for ; Sun, 18 Dec 2005 21:43:11 +0000 (GMT) (envelope-from victor@bsdes.net) Received: from alf.dyndns.ws (pato.euesrg02.net [192.168.0.3]) by alf.dyndns.ws (8.13.1/8.13.1) with ESMTP id jBILh9sx027623 for ; Sun, 18 Dec 2005 22:43:09 +0100 (CET) (envelope-from victor@bsdes.net) Date: Sun, 18 Dec 2005 22:43:09 +0100 From: Victor Balada Diaz To: freebsd-current@freebsd.org Message-ID: <20051218214308.GB659@pato.euesrg02.net> References: <20051218212107.GA720@wanadoo.fr> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <20051218212107.GA720@wanadoo.fr> User-Agent: Mutt/1.4.2.1i Subject: Re: no disk found on sony vaio s5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2005 21:43:13 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Dec 18, 2005 at 10:21:07PM +0100, rmgls@wanadoo.fr wrote: > hello all, > > i try to install FreeBSD 6.0 on a sony vaio s5. > at boot, FreeBSD find the disk 0 with 3 used partitions. > in the installer, fdisk does not find any disk. > > any idea to help? FreeBSD 6.0 didn't work on my Vaio S4XP because it wasn't able find the disks, but 5.4 works. Attached is the patch that i used to get 6.0 working on my vaio. Try installing FreeBSD 5.4 and then do a source upgrade with this. I would like to hear if this solves the issue for you. To patch your system just go to /usr/src and type: # patch -p3 < /path/to/the/ata.patch -- La prueba mas fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ata.patch" --- /usr/src/sys/dev/ata/ata-chipset.c Sat Oct 29 20:01:48 2005 +++ /usr/src.new/sys/dev/ata/ata-chipset.c Sat Dec 3 02:20:15 2005 @@ -1647,6 +1647,7 @@ ctlr->r_rid2 = PCIR_BAR(5); if ((ctlr->r_res2 = bus_alloc_resource_any(dev, ctlr->r_type2, &ctlr->r_rid2, RF_ACTIVE))) { + if(0) { if (bus_teardown_intr(dev, ctlr->r_irq, ctlr->handle) || bus_setup_intr(dev, ctlr->r_irq, ATA_INTR_FLAGS, ata_ahci_intr, ctlr, &ctlr->handle)) { @@ -1671,6 +1672,7 @@ ctlr->reset = ata_ahci_reset; ctlr->dmainit = ata_ahci_dmainit; ctlr->allocate = ata_ahci_allocate; + } } else { ctlr->reset = ata_intel_reset; --yrj/dFKFPuw6o+aM-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 21:59:53 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74B9416A420; Sun, 18 Dec 2005 21:59:53 +0000 (GMT) (envelope-from pmurray@nevada.net.nz) Received: from bellagio.open2view.com (ns2.open2view.com [203.97.20.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DD6843D75; Sun, 18 Dec 2005 21:59:51 +0000 (GMT) (envelope-from pmurray@nevada.net.nz) Received: from localhost (localhost [127.0.0.1]) by bellagio.open2view.com (Postfix) with ESMTP id 160AA615BD; Mon, 19 Dec 2005 11:04:26 +1300 (NZDT) Received: from bellagio.open2view.com ([127.0.0.1]) by localhost (bellagio.open2view.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97833-04; Mon, 19 Dec 2005 11:04:23 +1300 (NZDT) Received: from [10.58.3.145] (222-153-67-4.jetstream.xtra.co.nz [222.153.67.4]) by bellagio.open2view.com (Postfix) with ESMTP id A4C5A615B4; Mon, 19 Dec 2005 11:04:22 +1300 (NZDT) In-Reply-To: <20051218173028.GV41326@ip.net.ua> References: <20051218173028.GV41326@ip.net.ua> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <69674F40-30B2-4025-B5A5-AC3DE44C00A4@nevada.net.nz> Content-Transfer-Encoding: 7bit From: Philip Murray Date: Mon, 19 Dec 2005 10:59:43 +1300 To: Ruslan Ermilov X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at open2view.com Cc: freebsd-current@freebsd.org Subject: Re: New nfpm.c driver available for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2005 21:59:53 -0000 Hi Ruslan, On 19/12/2005, at 6:30 AM, Ruslan Ermilov wrote: > > This driver supports nVidia nForce2/3/4 and AMD-8111 SMBus 2.0 > controllers. This is on a Dual Dual-Core Opteron 275 on a Tyan S2882-D motherboard w/ 4GB of RAM running -amd64 > 5. Check if nfpm0 and nfpm1 devices have been created. root@stratos# dmesg | grep nf nfpm0: port 0xcc00-0xcc1f irq 19 at device 7.2 on pci0 smbus0: on nfpm0 > 6. Make sure /dev/smb[01] nodes exist. root@stratos# ls -l /dev/smb* crw------- 1 root wheel 0, 33 Dec 19 10:44 /dev/smb0 > 7. Compile and run the smbtest utility, run it twice, first > with /dev/smb0 and then with /dev/smb1 as the only argument. root@stratos# ./smbtest /dev/smb0 found slave device 0 found slave device 1 found slave device 2 found slave device 3 ... found slave device 125 found slave device 126 found slave device 127 > > 8. Run mbmon: root@stratos# mbmon -S -s0 -d mbmon: illegal option -- s root@stratos# mbmon -S -d SMBus[AMD8111] found, but No HWM available on it!! InitMBInfo: Unknown error: 0 > > 9. Send me the output of "pciconf -lv" and mbmon commands above. root@stratos# pciconf -lv pcib1@pci0:6:0: class=0x060400 card=0x000000c0 chip=0x74601022 rev=0x07 hdr=0x01 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8111 PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:7:0: class=0x060100 card=0x74681022 chip=0x74681022 rev=0x05 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8111 LPC Bridge' class = bridge subclass = PCI-ISA atapci1@pci0:7:1: class=0x01018a card=0x74691022 chip=0x74691022 rev=0x03 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8111 UltraATA/133 Controller' class = mass storage subclass = ATA nfpm0@pci0:7:2: class=0x0c0500 card=0x746a1022 chip=0x746a1022 rev=0x02 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8111 SMBus 2.0 Controller' class = serial bus subclass = SMBus none0@pci0:7:3: class=0x068000 card=0x746b1022 chip=0x746b1022 rev=0x05 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8111 ACPI System Management Controller' class = bridge pcib2@pci0:10:0: class=0x060400 card=0x000000a0 chip=0x74501022 rev=0x12 hdr=0x01 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8131 PCI-X Bridge' class = bridge subclass = PCI-PCI none1@pci0:10:1: class=0x080010 card=0x36c01022 chip=0x74511022 rev=0x01 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8131 PCI-X IOAPIC' class = base peripheral subclass = interrupt controller pcib3@pci0:11:0: class=0x060400 card=0x000000a0 chip=0x74501022 rev=0x12 hdr=0x01 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8131 PCI-X Bridge' class = bridge subclass = PCI-PCI none2@pci0:11:1: class=0x080010 card=0x36c01022 chip=0x74511022 rev=0x01 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8131 PCI-X IOAPIC' class = base peripheral subclass = interrupt controller hostb0@pci0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb1@pci0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron Address Map' class = bridge subclass = HOST-PCI hostb2@pci0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron DRAM Controller' class = bridge subclass = HOST-PCI hostb3@pci0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron Miscellaneous Control' class = bridge subclass = HOST-PCI hostb4@pci0:25:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb5@pci0:25:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron Address Map' class = bridge subclass = HOST-PCI hostb6@pci0:25:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron DRAM Controller' class = bridge subclass = HOST-PCI hostb7@pci0:25:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron Miscellaneous Control' class = bridge subclass = HOST-PCI ohci0@pci4:0:0: class=0x0c0310 card=0x74641022 chip=0x74641022 rev=0x0b hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8111 USB OpenHCI Host Controller' class = serial bus subclass = USB ohci1@pci4:0:1: class=0x0c0310 card=0x74641022 chip=0x74641022 rev=0x0b hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'AMD-8111 USB OpenHCI Host Controller' class = serial bus subclass = USB atapci0@pci4:5:0: class=0x018000 card=0x31141095 chip=0x31141095 rev=0x02 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'Sil 3114 SATALink/SATARaid Controller' class = mass storage none3@pci4:6:0: class=0x030000 card=0x80081002 chip=0x47521002 rev=0x27 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Rage XL PCI' class = display subclass = VGA fxp0@pci4:8:0: class=0x020000 card=0x10408086 chip=0x12298086 rev=0x10 hdr=0x00 vendor = 'Intel Corporation' device = '82550/1/7/8/9 EtherExpress PRO/100(B) Ethernet Adapter' class = network subclass = ethernet bge0@pci3:9:0: class=0x020000 card=0x164414e4 chip=0x164814e4 rev=0x03 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5704 NetXtreme Dual Gigabit Adapter' class = network subclass = ethernet bge1@pci3:9:1: class=0x020000 card=0x164414e4 chip=0x164814e4 rev=0x03 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM5704 NetXtreme Dual Gigabit Adapter' class = network subclass = ethernet pcib4@pci1:1:0: class=0x060400 card=0x000000dc chip=0x03358086 rev=0x0a hdr=0x01 vendor = 'Intel Corporation' device = '80331 [Lindsay] I/O processor PCI-X bridge' class = bridge subclass = PCI-PCI arcmsr0@pci2:14:0: class=0x010400 card=0x112017d3 chip=0x112017d3 rev=0x00 hdr=0x00 vendor = 'Areca Technology Corporation' device = 'ARC-1120 8-Port PCI-X to SATA RAID Controller' class = mass storage subclass = RAID Cheers Phil From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 22:12:22 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C332216A41F; Sun, 18 Dec 2005 22:12:22 +0000 (GMT) (envelope-from mezz7@cox.net) Received: from centrmmtao02.cox.net (centrmmtao02.cox.net [70.168.83.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2106D43D46; Sun, 18 Dec 2005 22:12:18 +0000 (GMT) (envelope-from mezz7@cox.net) Received: from mezz.mezzweb.com ([68.103.32.140]) by centrmmtao02.cox.net (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id <20051218221209.ICIW8484.centrmmtao02.cox.net@mezz.mezzweb.com>; Sun, 18 Dec 2005 17:12:09 -0500 Date: Sun, 18 Dec 2005 16:13:03 -0600 To: "Ruslan Ermilov" References: <20051218173028.GV41326@ip.net.ua> From: "Jeremy Messenger" Content-Type: text/plain; format=flowed; delsp=yes; charset=us-ascii MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <20051218173028.GV41326@ip.net.ua> User-Agent: Opera M2/8.51 (Linux, build 1462) Cc: current@freebsd.org, Vladimir Timofeev Subject: Re: New nfpm.c driver available for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2005 22:12:22 -0000 On Sun, 18 Dec 2005 11:30:28 -0600, Ruslan Ermilov wrote: > Hi, > > A new nfpm(4) driver is available for testing: > > http://people.freebsd.org/~ru/patches/nfpm.patch For any 6.x users, replace above's conf/files patch to here. http://people.freebsd.org/~mezz/diff/patch-sys_conf_files The rest applied just fine beside that conf/files. > http://people.freebsd.org/~ru/patches/smbtest.c > > This driver supports nVidia nForce2/3/4 and AMD-8111 SMBus 2.0 > controllers. > > 1. Make sure to create an empty sys/modules/i2c/nfpm/ directory > before you apply the patch. I am sure you mean by sys/modules/i2c/controllers/nfpm/ . > 2. Make sure sys/dev/smbus/smbus.c has patched. :-) > > 3. Recompile and reinstall everything in /sys/modules/i2c/: > > cd /sys/modules/i2c && make obj && make && make install > > 4. Reboot and load nfpm.ko and smb.ko from loader(8). NB: > On my machine, kldload/kldunload/kldload of nfpm.ko results > in non-working driver, due to some yet to be solved I/O > resource problem. The smb_load="YES" and nfpm_load="YES" have been added in loader.conf. > 5. Check if nfpm0 and nfpm1 devices have been created. dmesg: ========================================== nfpm0: port 0xc400-0xc41f irq 23 at device 1.1 on pci0 smbus0: on nfpm0 smb0: on smbus0 nfpm1: on nfpm0 smbus1: on nfpm1 smb1: on smbus1 ========================================== > 6. Make sure /dev/smb[01] nodes exist. ========================================== # ls /dev | grep smb smb0 smb1 ========================================== > 7. Compile and run the smbtest utility, run it twice, first > with /dev/smb0 and then with /dev/smb1 as the only argument. > > # ./smbtest /dev/smb0 > found slave device 8 > found slave device 80 > found slave device 81 > # ./smbtest /dev/smb1 > found slave device 8 ========================================== # ./smbtest /dev/smb0 found slave device 8 found slave device 80 found slave device 81 # ./smbtest /dev/smb1 found slave device 8 found slave device 27 found slave device 47 ========================================== > 8. Patch sysutils/xmbmon sources and substitute the PCI ID of > your SMBus 2.0 controller (see "pciconf -lv", "nfpm0"): > > cd /usr/ports/sysutils/xmbmon > make patch > vi /pci_pm.h > > make install ========================================== # grep 0084 work/xmbmon205/* work/xmbmon205/pci_pm.h:#define ID_NFORCE2 0x008410DE ========================================== > 8. Run mbmon: > > mbmon -S -s0 -d > mbmon -S -s1 -d ========================================== # mbmon -S -s0 -d SMBus[NVidia nForce2] found, but No HWM available on it!! InitMBInfo: Device not configured # mbmon -S -s1 -d SMBus[NVidia nForce2] found, but No HWM available on it!! InitMBInfo: Device not configured ========================================== > If any sensors are detected, e.g. on /dev/smb1 (-s1) try > them: > > mbmon -S -s1 -c8 1 ========================================== # mbmon -S -s1 -c8 1 InitMBInfo: Device not configured ========================================== Umm, do I need to configure something else? > 9. Send me the output of "pciconf -lv" and mbmon commands above. pciconf: ========================================== nfpm0@pci0:1:1: class=0x0c0500 card=0x57001462 chip=0x008410de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP2S PCI System Management' class = serial bus subclass = SMBus ========================================== kldstat: ========================================== # kldstat Id Refs Address Size Name 1 14 0xc0400000 3b3960 kernel 2 2 0xc07b4000 1aeac linux.ko 3 1 0xc07cf000 3124 smb.ko 4 3 0xc07d3000 3764 smbus.ko 5 1 0xc07d7000 2f2c nfpm.ko 6 1 0xc07da000 429d40 nvidia.ko 7 1 0xc0c04000 5b734 acpi.ko ========================================== Thanks! /me goes back to watch football (NFL) game... Wow, Colt doesn't win (haha)! Cheers, Mezz > Cheers, -- mezz7@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Dec 18 22:26:36 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 147F016A420 for ; Sun, 18 Dec 2005 22:26:36 +0000 (GMT) (envelope-from vovkasm@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBFAC43D66 for ; Sun, 18 Dec 2005 22:26:33 +0000 (GMT) (envelope-from vovkasm@gmail.com) Received: by nproxy.gmail.com with SMTP id h2so344841nfe for ; Sun, 18 Dec 2005 14:26:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oVL19zXSDL0X1MJNGGl55c7TcmGxdNxE1T4C4y0UZbtv0p+k5k+JeYc5KIS/UoT6Js3iMt2+sF9NydXNZWlhIFoNzG13ppbzBgcdmp4vkpyTJ/hgQq+G29ng2FCAV2dQD90eM0H6idElp1hTHF9yyIOsYmNPLose6Ea1VN+8vew= Received: by 10.48.240.13 with SMTP id n13mr218827nfh; Sun, 18 Dec 2005 14:26:32 -0800 (PST) Received: by 10.48.144.15 with HTTP; Sun, 18 Dec 2005 14:26:32 -0800 (PST) Message-ID: Date: Mon, 19 Dec 2005 01:26:32 +0300 From: Vladimir Timofeev To: Ruslan Ermilov In-Reply-To: <20051218173028.GV41326@ip.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20051218173028.GV41326@ip.net.ua> Cc: current@freebsd.org Subject: Re: New nfpm.c driver available for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2005 22:26:36 -0000 Results for Abit NF7 on resent RELENG_6 2005/12/18, Ruslan Ermilov : > Hi, > > A new nfpm(4) driver is available for testing: > > http://people.freebsd.org/~ru/patches/nfpm.patch > http://people.freebsd.org/~ru/patches/smbtest.c > > This driver supports nVidia nForce2/3/4 and AMD-8111 SMBus 2.0 > controllers. > > 1. Make sure to create an empty sys/modules/i2c/nfpm/ directory > before you apply the patch. sys/modules/i2c/nfpm/ -> sys/modules/i2c/controllers/nfpm/ ;-) > > 2. Make sure sys/dev/smbus/smbus.c has patched. :-) on RELENG_6 for sys/conf/files: lines in patch: -pci/amdpm.c optional amdpm pci | nfpm pci +pci/amdpm.c optional amdpm pci must be simple -pci/amdpm.c optional nfpm pci > > 3. Recompile and reinstall everything in /sys/modules/i2c/: > > cd /sys/modules/i2c && make obj && make && make install > > 4. Reboot and load nfpm.ko and smb.ko from loader(8). NB: > On my machine, kldload/kldunload/kldload of nfpm.ko results > in non-working driver, due to some yet to be solved I/O > resource problem. built with kernel ;-) > > 5. Check if nfpm0 and nfpm1 devices have been created. nfpm0: port 0xe400-0xe41f irq 11 at device 1.1 on pci0 smbus0: on nfpm0 smb0: on smbus0 nfpm1: on nfpm0 smbus1: on nfpm1 smb1: on smbus1 > > 6. Make sure /dev/smb[01] nodes exist. yes > > 7. Compile and run the smbtest utility, run it twice, first > with /dev/smb0 and then with /dev/smb1 as the only argument. > root@vov# ./smbtest /dev/smb0 found slave device 8 found slave device 78 found slave device 81 found slave device 82 root@vov# ./smbtest /dev/smb1 found slave device 8 > # ./smbtest /dev/smb0 > found slave device 8 > found slave device 80 > found slave device 81 > # ./smbtest /dev/smb1 > found slave device 8 > > 8. Patch sysutils/xmbmon sources and substitute the PCI ID of > your SMBus 2.0 controller (see "pciconf -lv", "nfpm0"): > > cd /usr/ports/sysutils/xmbmon > make patch > vi /pci_pm.h > > make install > No need (see output of 'pciconf -lv') > 8. Run mbmon: > > mbmon -S -s0 -d > mbmon -S -s1 -d > root@vov# mbmon -S -s0 -d SMBus[NVidia nForce2] found, but No HWM available on it!! InitMBInfo: Device not configured root@vov# mbmon -S -s1 -d SMBus[NVidia nForce2] found, but No HWM available on it!! InitMBInfo: Device not configured > If any sensors are detected, e.g. on /dev/smb1 (-s1) try > them: > > mbmon -S -s1 -c8 1 > > 9. Send me the output of "pciconf -lv" and mbmon commands above. root@vov# pciconf -lv agp0@pci0:0:0: class=3D0x060000 card=3D0x1c02147b chip=3D0x01e010de rev=3D= 0xc1 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce2 AGP Controller' class =3D bridge subclass =3D HOST-PCI none0@pci0:0:1: class=3D0x050000 card=3D0x0c1710de chip=3D0x01eb10de rev=3D= 0xc1 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce2 Memory Controller 1' class =3D memory subclass =3D RAM none1@pci0:0:2: class=3D0x050000 card=3D0x0c1710de chip=3D0x01ee10de rev=3D= 0xc1 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce2 Memory Controller 4' class =3D memory subclass =3D RAM none2@pci0:0:3: class=3D0x050000 card=3D0x0c1710de chip=3D0x01ed10de rev=3D= 0xc1 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce2 Memory Controller 3' class =3D memory subclass =3D RAM none3@pci0:0:4: class=3D0x050000 card=3D0x0c1710de chip=3D0x01ec10de rev=3D= 0xc1 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce2 Memory Controller 2' class =3D memory subclass =3D RAM none4@pci0:0:5: class=3D0x050000 card=3D0x0c1710de chip=3D0x01ef10de rev=3D= 0xc1 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce2 Memory Controller 5' class =3D memory subclass =3D RAM isab0@pci0:1:0: class=3D0x060100 card=3D0x1c02147b chip=3D0x006010de rev=3D= 0xa4 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce MCP2 ISA Bridge' class =3D bridge subclass =3D PCI-ISA nfpm0@pci0:1:1: class=3D0x0c0500 card=3D0x1c02147b chip=3D0x006410de rev=3D= 0xa2 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce MCP-T? SMBus Controller' class =3D serial bus subclass =3D SMBus ohci0@pci0:2:0: class=3D0x0c0310 card=3D0x1c02147b chip=3D0x006710de rev=3D= 0xa4 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce MCP2 OpenHCI USB Controller' class =3D serial bus subclass =3D USB ohci1@pci0:2:1: class=3D0x0c0310 card=3D0x1c02147b chip=3D0x006710de rev=3D= 0xa4 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce MCP2 OpenHCI USB Controller' class =3D serial bus subclass =3D USB ehci0@pci0:2:2: class=3D0x0c0320 card=3D0x1c02147b chip=3D0x006810de rev=3D= 0xa4 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce MCP2 EHCI USB 2.0 Controller' class =3D serial bus subclass =3D USB nve0@pci0:4:0: class=3D0x020000 card=3D0x1c02147b chip=3D0x006610de rev=3D= 0xa1 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce MCP-T Networking Adapter' class =3D network subclass =3D ethernet pcm0@pci0:6:0: class=3D0x040100 card=3D0x1c02147b chip=3D0x006a10de rev=3D= 0xa1 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce MCP-T Audio Codec Interface' class =3D multimedia subclass =3D audio pcib1@pci0:8:0: class=3D0x060400 card=3D0x00000000 chip=3D0x006c10de rev=3D= 0xa3 hdr=3D0x01 vendor =3D 'NVIDIA Corporation' device =3D 'nForce MCP-T CPU to PCI Bridge' class =3D bridge subclass =3D PCI-PCI atapci0@pci0:9:0: class=3D0x01018a card=3D0x1c02147b chip=3D0x006510d= e rev=3D0xa2 hdr=3D0x00 vendor =3D 'NVIDIA Corporation' device =3D 'nForce MCP2 EIDE Controller' class =3D mass storage subclass =3D ATA pcib2@pci0:30:0: class=3D0x060400 card=3D0x00000000 chip=3D0x01e810d= e rev=3D0xc1 hdr=3D0x01 vendor =3D 'NVIDIA Corporation' device =3D 'nForce2 AGP Host to PCI Bridge' class =3D bridge subclass =3D PCI-PCI drm0@pci2:0:0: class=3D0x030000 card=3D0x20021787 chip=3D0x59611002 rev=3D= 0x01 hdr=3D0x00 vendor =3D 'ATI Technologies Inc' device =3D 'Radeon 9200 Series (RV280)' class =3D display subclass =3D VGA > > > Cheers, > -- > Ruslan Ermilov > ru@FreeBSD.org > FreeBSD committer > > > ;-) From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 02:02:32 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6024416A41F for ; Mon, 19 Dec 2005 02:02:31 +0000 (GMT) (envelope-from enache@rdslink.ro) Received: from smtp.rdslink.ro (smtp.rdslink.ro [193.231.236.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4F26843D67 for ; Mon, 19 Dec 2005 02:02:30 +0000 (GMT) (envelope-from enache@rdslink.ro) Received: (qmail 4914 invoked from network); 19 Dec 2005 02:02:29 -0000 X-Mail-Scanner: Scanned by qSheff 1.0 (http://www.enderunix.org/qsheff/) Received: from unknown (HELO localhost.my.domain) (86.125.101.38) by smtp.rdslink.ro with SMTP; 19 Dec 2005 02:02:29 -0000 Received: from localhost.my.domain (localhost [127.0.0.1]) by localhost.my.domain (8.13.4/8.13.4) with ESMTP id jBJ22YJ3001315 for ; Mon, 19 Dec 2005 04:02:34 +0200 (EET) (envelope-from enache@rdslink.ro) Received: (from adi@localhost) by localhost.my.domain (8.13.4/8.13.3/Submit) id jBJ22YvE001314 for freebsd-current@freebsd.org; Mon, 19 Dec 2005 04:02:34 +0200 (EET) (envelope-from enache@rdslink.ro) X-Authentication-Warning: localhost.my.domain: adi set sender to enache@rdslink.ro using -f Date: Mon, 19 Dec 2005 04:02:34 +0200 From: Enache Adrian To: freebsd-current@freebsd.org Message-ID: <20051219020234.GB1253@cubatao> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: mount_cd9660 broken with multi-session CDs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 02:02:32 -0000 mount_cd9660 doesn't pass the correct 'ssector' option to the kernel so it's unable to mount multi-session disks. this small patch fixes it for me: --- /usr/src/sbin/mount_cd9660/mount_cd9660.c Thu Dec 15 02:01:38 2005 +++ ./mount_cd9660.c Sun Dec 18 00:07:46 2005 @@ -175,7 +175,7 @@ build_iovec(&iov, &iovlen, "fstype", fstype, (size_t)-1); build_iovec(&iov, &iovlen, "fspath", mntpath, (size_t)-1); build_iovec(&iov, &iovlen, "from", dev, (size_t)-1); - build_iovec(&iov, &iovlen, "ssector", &ssector, sizeof ssector); + build_iovec_argf(&iov, &iovlen, "ssector", "%d", ssector); if (nmount(iov, iovlen, mntflags) < 0) err(1, "%s", dev); From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 05:56:44 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C860F16A41F for ; Mon, 19 Dec 2005 05:56:44 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: from www.mmlab.cse.yzu.edu.tw (www.mmlab.cse.yzu.edu.tw [140.138.150.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62C8743D58 for ; Mon, 19 Dec 2005 05:56:44 +0000 (GMT) (envelope-from avatar@mmlab.cse.yzu.edu.tw) Received: by www.mmlab.cse.yzu.edu.tw (qmail, from userid 1000) id 880268C9A76; Mon, 19 Dec 2005 13:56:43 +0800 (CST) Received: from localhost (localhost [127.0.0.1]) by www.mmlab.cse.yzu.edu.tw (qmail) with ESMTP id 5E1E78C9873; Mon, 19 Dec 2005 13:56:43 +0800 (CST) Date: Mon, 19 Dec 2005 13:56:43 +0800 (CST) From: Tai-hwa Liang To: Enache Adrian In-Reply-To: <20051219020234.GB1253@cubatao> Message-ID: <051219135457B.99603@www.mmlab.cse.yzu.edu.tw> References: <20051219020234.GB1253@cubatao> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: mount_cd9660 broken with multi-session CDs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 05:56:44 -0000 On Mon, 19 Dec 2005, Enache Adrian wrote: > mount_cd9660 doesn't pass the correct 'ssector' option to the kernel > so it's unable to mount multi-session disks. > > this small patch fixes it for me: > > --- /usr/src/sbin/mount_cd9660/mount_cd9660.c Thu Dec 15 02:01:38 2005 > +++ ./mount_cd9660.c Sun Dec 18 00:07:46 2005 > @@ -175,7 +175,7 @@ > build_iovec(&iov, &iovlen, "fstype", fstype, (size_t)-1); > build_iovec(&iov, &iovlen, "fspath", mntpath, (size_t)-1); > build_iovec(&iov, &iovlen, "from", dev, (size_t)-1); > - build_iovec(&iov, &iovlen, "ssector", &ssector, sizeof ssector); > + build_iovec_argf(&iov, &iovlen, "ssector", "%d", ssector); > > if (nmount(iov, iovlen, mntflags) < 0) > err(1, "%s", dev); Looks good to me. Fix commited to src/sbin/mount_cd9660.c:1.33. Thanks! -- Cheers, Tai-hwa Liang From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 07:19:33 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A48116A41F for ; Mon, 19 Dec 2005 07:19:33 +0000 (GMT) (envelope-from huang@gddsn.org.cn) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 076A443D45 for ; Mon, 19 Dec 2005 07:19:32 +0000 (GMT) (envelope-from huang@gddsn.org.cn) Received: from [192.168.168.131] (unknown [211.96.21.221]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gddsn.org.cn (Postfix) with ESMTP id A1BEA38CB41 for ; Mon, 19 Dec 2005 15:19:28 +0800 (CST) Message-ID: <43A65EFD.3040606@gddsn.org.cn> Date: Mon, 19 Dec 2005 15:19:25 +0800 From: Huang wen hui User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051212) X-Accept-Language: zh-cn,zh MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: Subject: em broken suspend on IBM-T42p X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 07:19:33 -0000 hi, On my T42p suspend operation can work well until Oct 20. It does not work on recent CURRENT. Remove em driver from kernel config does help that. Any ideas? #dmesg 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 7.0-CURRENT #3: Mon Dec 19 14:06:06 CST 2005 root@tp.gddsn.org.cn:/usr/obj/usr/src/sys/IBM01 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1.80GHz (1794.19-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d6 Stepping = 6 Features=0xafe9f9bf Features2=0x180 real memory = 2146828288 (2047 MB) avail memory = 2095865856 (1998 MB) ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_perf0: on cpu0 acpi_throttle0: on cpu0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xd0000000-0xdfffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) uhci0: port 0x1800-0x181f irq 11 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 11 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xc0000000-0xc00003ff irq 11 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pcib2: at device 30.0 on pci0 pci2: on pcib2 cbb0: mem 0xb0000000-0xb0000fff irq 11 at device 0.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: mem 0xb1000000-0xb1000fff irq 11 at device 0.1 on pci2 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 em0: port 0x8000-0x803f mem 0xc0240000-0xc025ffff,0xc0200000-0xc020ffff irq 11 at device 1.0 on pci2 em0: Ethernet address: 00:0d:60:75:92:ac ath0: mem 0xc0210000-0xc021ffff irq 11 at device 2.0 on pci2 ath0: Ethernet address: 00:05:4e:4d:2a:7b ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 ichsmb0: port 0x1880-0x189f irq 11 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] smbus0: on ichsmb0 smb0: on smbus0 pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff mem 0xc0000c00-0xc0000dff,0xc0000800-0xc00008ff irq 11 at device 31.5 on pci0 pcm0: pci0: at device 31.6 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 8250 or not responding ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled battery0: on acpi0 acpi_acad0: on acpi0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled pmtimer0 on isa0 orm0: at iomem 0xd0000-0xd0fff,0xd1000-0xd1fff,0xdc000-0xdffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled ugen0: vendor 0x1668 product 0x2441, rev 1.10/5.46, addr 2 Timecounter "TSC" frequency 1794190542 Hz quality 800 Timecounters tick every 1.000 msec ad0: 57231MB at ata0-master UDMA100 acd0: DVDR at ata1-master UDMA33 Trying to mount root from ufs:/dev/ad0s1a --hwh From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 11:16:57 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDEC316A41F; Mon, 19 Dec 2005 11:16:57 +0000 (GMT) (envelope-from ggajic@afrodita.rcub.bg.ac.yu) Received: from afrodita.rcub.bg.ac.yu (afrodita.rcub.bg.ac.yu [147.91.1.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id C32A843D5D; Mon, 19 Dec 2005 11:16:55 +0000 (GMT) (envelope-from ggajic@afrodita.rcub.bg.ac.yu) Received: from afrodita.rcub.bg.ac.yu (localhost.localdomain [127.0.0.1]) by afrodita.rcub.bg.ac.yu (8.13.4/8.13.4) with ESMTP id jBJBGfVj004685; Mon, 19 Dec 2005 12:16:41 +0100 Received: from localhost (ggajic@localhost) by afrodita.rcub.bg.ac.yu (8.13.4/8.13.4/Submit) with ESMTP id jBJBGeuO004682; Mon, 19 Dec 2005 12:16:40 +0100 Date: Mon, 19 Dec 2005 12:16:40 +0100 (CET) From: Goran Gajic To: Antoine Brodin In-Reply-To: <20051217001507.71b04041.antoine.brodin@laposte.net> Message-ID: References: <200512151356.41550.jhb@freebsd.org> <200512161525.12656.jhb@freebsd.org> <20051217001507.71b04041.antoine.brodin@laposte.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-RCUB-MailScanner-Information: Please contact the RCUB if you have problem with mail X-RCUB-MailScanner: Found to be clean X-RCUB-MailScanner-From: ggajic@afrodita.rcub.bg.ac.yu X-Mailman-Approved-At: Mon, 19 Dec 2005 12:37:00 +0000 Cc: freebsd-current@freebsd.org Subject: Re: skype-1.2.0.18-static for linux and FreeBSD 7.0 CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2005 11:16:57 -0000 On Sat, 17 Dec 2005, Antoine Brodin wrote: > > Hi, > > Could you try the patch at : > http://bsd.miki.eu.org/~antoine/stack/stack-12-16.diff > > Cheers, > > Antoine > Just an update. Antoine's patch solves problem. If options DEBUG_LOCKS is turned on without his patch kernel will crash when in skype username and password are supplied. However options DEBUG_VFS_LOCKS produces panic during boot (with or without patch): ad0: 78167MB at ata0-master UDMA100 Trying to mount root from ufs:/dev/ad0s3a KDB: stack backtrace: kdb_backtrace(d449c9a4,c06c459e,c08a3b16,c08c2945,c355c6a4) at kdb_backtrace+0x29 vfs_badlock(c08a3b16,c08c2945,c355c6a4) at vfs_badlock+0x11 assert_vop_locked(c355c6a4,c08c2945,c355c6a4,c08c2945) at assert_vop_locked+0x4a VOP_GETPAGES_APV(c093bb80,d449c9d8) at VOP_GETPAGES_APV+0x96 vnode_pager_getpages(c1039ba0,d449ca20,1,0) at vnode_pager_getpages+0xa5 vm_imgact_hold_page(c1039ba0,68f28,0,d449ca7c,c0641b47) at vm_imgact_hold_page+0x82 vm_imgact_map_page(c1039ba0,68f28,0,f28,0) at vm_imgact_map_page+0x11 elf32_load_section(c329c000,c32a1000,c355c6a4,c1039ba0,67000) at elf32_load_section+0x17b exec_elf32_imgact(d449cbbc,0,0,0,0) at exec_elf32_imgact+0x250 do_execve(c3298480,d449cc8c,0,0,d449cc8c) at do_execve+0x246 kern_execve(c3298480,d449cc8c,0,d35eb000,d35eb000) at kern_execve+0x74 execve(c3298480,d449ccf0,bfbfffe4,bfbffff2,bfbfffe8,bfbffffd,bfbfffec,0) at execve+0x32 start_init(0,d449cd38,0,c06436d8,0) at start_init+0x20b fork_exit(c06436d8,0,d449cd38) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd449cd6c, ebp = 0 --- VOP_GETPAGES: 0xc355c6a4 is not locked but should be KDB: enter: lock violation [thread pid 1 tid 100007 ] Stopped at kdb_enter+0x2b: nop db> show locks exclusive sleep mutex Giant r = 0 (0xc0967ecc) locked @ kern/vfs_mount.c:582 db> Can anyone tell me how to setup dumpdev from ddb or at boot time, since loader.conf dumpdev seems to be ignored, and if I'm correct this has happened when geom was introduced... Regards, gg. From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 13:11:01 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64B2916A41F; Mon, 19 Dec 2005 13:11:01 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (vds.fauxbox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B97543D55; Mon, 19 Dec 2005 13:11:00 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 0B78AEB; Mon, 19 Dec 2005 08:11:21 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 8B9CB1AE8; Mon, 19 Dec 2005 08:11:16 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EoKmz-000CPU-Jm; Mon, 19 Dec 2005 13:10:53 +0000 Date: Mon, 19 Dec 2005 13:10:53 +0000 From: Brian Candler To: Kris Kennaway Message-ID: <20051219131053.GA47692@uk.tiscali.com> References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> <43A4A557.3010600@mac.com> <43A53215.8090001@infracaninophile.co.uk> <20051218171308.GA20557@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051218171308.GA20557@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i Cc: Joe Rhett , stable@freebsd.org, Matthew Seaman , current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 13:11:01 -0000 On Sun, Dec 18, 2005 at 12:13:09PM -0500, Kris Kennaway wrote: > > Doesn't creating a binary updates system that's going to be practical to use > > require implementation of that old and exceedingly bikesheddable subject: > > packaging > > up the base system? > > No, after all the *existing* binary update systems don't require > packaging of the base system. Except that the existing binary update system is broken in several fundamental ways. I guess the reason it gets little attention is because most developers are happy to (or even prefer to) rebuild their systems from source. Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 13:20:25 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 35BA116A420 for ; Mon, 19 Dec 2005 13:20:25 +0000 (GMT) (envelope-from rmgls@wanadoo.fr) Received: from smtp10.wanadoo.fr (smtp10.wanadoo.fr [193.252.22.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B74D43D60 for ; Mon, 19 Dec 2005 13:20:24 +0000 (GMT) (envelope-from rmgls@wanadoo.fr) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1002.wanadoo.fr (SMTP Server) with ESMTP id 1CB702400053 for ; Mon, 19 Dec 2005 14:20:23 +0100 (CET) Received: from wanadoo.fr (ARouen-251-1-6-252.w83-115.abo.wanadoo.fr [83.115.99.252]) by mwinf1002.wanadoo.fr (SMTP Server) with ESMTP id 091CC240008E for ; Mon, 19 Dec 2005 14:20:23 +0100 (CET) X-ME-UUID: 20051219132023375.091CC240008E@mwinf1002.wanadoo.fr Received: from rmgls by bip.private.music with local (Exim 4.52) id 1EoKw8-0000DI-OP for freebsd-current@freebsd.org; Mon, 19 Dec 2005 14:20:20 +0100 Date: Mon, 19 Dec 2005 14:20:20 +0100 From: rmgls@wanadoo.fr To: freebsd-current@freebsd.org Message-ID: <20051219132020.GA788@wanadoo.fr> References: <20051218214308.GB659@pato.euesrg02.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051218214308.GB659@pato.euesrg02.net> User-Agent: Mutt/1.4.2.1i Subject: Re: no disk found on sony vaio s5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 13:20:25 -0000 On Sat, Nov 19, 2005 at 07:52:56AM +0000, Victor Balada Diaz wrote: > On Sun, Dec 18, 2005 at 10:21:07PM +0100, rmgls@wanadoo.fr wrote: > > hello all, > > > > i try to install FreeBSD 6.0 on a sony vaio s5. > > at boot, FreeBSD find the disk 0 with 3 used partitions. > > in the installer, fdisk does not find any disk. > > > > any idea to help? > FreeBSD 6.0 didn't work on my Vaio S4XP because it wasn't able > find the disks, but 5.4 works. > Attached is the patch that i used to get 6.0 working on my vaio. > Try installing FreeBSD 5.4 and then do a source upgrade with this. > I would like to hear if this solves the issue for you. > To patch your system just go to /usr/src and type: > > # patch -p3 < /path/to/the/ata.patch > > -- > La prueba mas fehaciente de que existe vida inteligente en otros > planetas, es que no han intentado contactar con nosotros. > --- /usr/src/sys/dev/ata/ata-chipset.c Sat Oct 29 20:01:48 2005 > +++ /usr/src.new/sys/dev/ata/ata-chipset.c Sat Dec 3 02:20:15 2005 > @@ -1647,6 +1647,7 @@ > ctlr->r_rid2 = PCIR_BAR(5); > if ((ctlr->r_res2 = bus_alloc_resource_any(dev, ctlr->r_type2, > &ctlr->r_rid2, RF_ACTIVE))) { > + if(0) { > if (bus_teardown_intr(dev, ctlr->r_irq, ctlr->handle) || > bus_setup_intr(dev, ctlr->r_irq, ATA_INTR_FLAGS, > ata_ahci_intr, ctlr, &ctlr->handle)) { > @@ -1671,6 +1672,7 @@ > ctlr->reset = ata_ahci_reset; > ctlr->dmainit = ata_ahci_dmainit; > ctlr->allocate = ata_ahci_allocate; > + } > } > else { > ctlr->reset = ata_intel_reset; Thanks for the trick, i will try it as soon as i have the 5.4 release (i run current!). best regard raoul rmgls@wanadoo.fr From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 13:43:14 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D28E16A41F for ; Mon, 19 Dec 2005 13:43:14 +0000 (GMT) (envelope-from rink@charm.il.fontys.nl) Received: from mail.unilogicnetworks.net (mail-out.unilogicnetworks.net [62.133.192.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8751D43D7C for ; Mon, 19 Dec 2005 13:43:07 +0000 (GMT) (envelope-from rink@charm.il.fontys.nl) Received: from mail.il.fontys.nl (mx0.il.fontys.nl [194.26.13.7]) by mail.unilogicnetworks.net (Postfix) with ESMTP id 70574EF131 for ; Mon, 19 Dec 2005 14:43:05 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.il.fontys.nl (Postfix/VSRI) with ESMTP id DD31E17042 for ; Mon, 19 Dec 2005 14:48:12 +0100 (CET) Received: from mail.il.fontys.nl ([127.0.0.1]) by localhost (sukke.il.fontys.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12906-02 for ; Mon, 19 Dec 2005 14:48:12 +0100 (CET) Received: from charm.il.fontys.nl (www.il.fontys.nl [IPv6:2001:4128:1000:1000::10]) by mail.il.fontys.nl (Postfix) with ESMTP for ; Mon, 19 Dec 2005 14:48:12 +0100 (CET) Received: by charm.il.fontys.nl (Postfix, from userid 1678) id 8EC3341CD; Mon, 19 Dec 2005 14:40:52 +0100 (CET) Date: Mon, 19 Dec 2005 14:40:52 +0100 From: Rink Springer To: current@freebsd.org Message-ID: <20051219134052.GB68985@il.fontys.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Editor: Vim http://www.vim.org/ X-Info: http://rink.nu/ X-Operating-System: FreeBSD 6.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Virus-Scanned: amavisd-new at il.fontys.nl Cc: Subject: [PATCH] FreeBSD/xbox nve(4) support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2005 13:43:14 -0000 Hiya, I have finally discovered why the XBOX nForce card does not attach correctly. Based on this, the patch at http://rink.nu/downloads/xbox-patches/xbox-nve.diff will fix the situation. The problem is, that the card is not fully reset. In fact, it looks as if the Linux Cromwell BIOS leaves it running, where it does not seem to accept initialization. Since probably more XBOX loaders fail to reset the chip correctly, I have chosen to create a small patch which pulls the chip out of the running state. This makes the nve(4) driver attach correctly. Could someone please commit this patch? It will be executed on XBOXes only, so it will not break anything. PS. I get 10MB/sec on my XBOX while transferring files, but the nve(4) driver will cause 7500 interrupts/sec and burn up 30% interrupt time (as well as 50% system time or so). Is this 'normal' behaviour of nve(4) ? --=20 Rink P.W. Springer - http://rink.nu "Richter: Tribute? You steal men's souls, and make them your slaves! Dracula: Perhaps the same could be said of all religions." - Castlevania: Symphony of the Night From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 15:00:57 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BFDDC16A41F; Mon, 19 Dec 2005 15:00:57 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD72643D62; Mon, 19 Dec 2005 15:00:54 +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 jBJF0iFx020790; Mon, 19 Dec 2005 16:00:44 +0100 (MET) Message-ID: <43A6CACE.30902@fer.hr> Date: Mon, 19 Dec 2005 15:59:26 +0100 From: Ivan Voras User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthias Andree References: <20051213151908.GA26821@crodrigues.org> <20051216132641.C29205@electra.nolink.net> <20051217141528.GB27992@merlin.emma.line.org> In-Reply-To: <20051217141528.GB27992@merlin.emma.line.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: XFS (read-only) support committed to CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2005 15:00:57 -0000 Matthias Andree wrote: > I was wondering if the way from ext2fs to ext3fs might have been > shorter, code-wise. For what it's worth, IIRC in Linux the code for ext3fs is separated from ext2fs - it's not handled by a bunch of #ifdefs but a separate (and much larger - IIRC at least 2x the code) codebase. From this I think that adding ext3 functionality to FreeBSD will also be similar - like a port of a completely different filesystem from scratch. From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 15:28:18 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B642216A41F for ; Mon, 19 Dec 2005 15:28:18 +0000 (GMT) (envelope-from jsmith@drexel.edu) Received: from smtp.mail.drexel.edu (pm2.irt.drexel.edu [144.118.29.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1DA143D49 for ; Mon, 19 Dec 2005 15:28:17 +0000 (GMT) (envelope-from jsmith@drexel.edu) Received: from smtp.mail.drexel.edu (localhost.localdomain [127.0.0.1]) by smtp.mail.drexel.edu (Postfix) with SMTP id DA02411667D for ; Mon, 19 Dec 2005 10:28:16 -0500 (EST) Received: from vorpal.math.drexel.edu (vorpal.math.drexel.edu [129.25.6.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mail.drexel.edu (Postfix) with ESMTP id D3E5F1165D5 for ; Mon, 19 Dec 2005 10:28:16 -0500 (EST) Received: from [IPv6:::1] (vorpal.math.drexel.edu [129.25.6.250]) by vorpal.math.drexel.edu (8.13.4/8.13.4) with ESMTP id jBJFS8P0067226 for ; Mon, 19 Dec 2005 10:28:08 -0500 (EST) (envelope-from jsmith@drexel.edu) Message-ID: <43A6D190.3020504@drexel.edu> Date: Mon, 19 Dec 2005 10:28:16 -0500 From: Justin Smith User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: "Native" journaling file systems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 15:28:18 -0000 Are there any plans to develop UFS3--- i.e., a UFS2 file system with an added journal? I've used several journaling file systems in Linux and like the Reiser FS except for one MAJOR drawback: When something goes wrong, reiser-fsck absolutely sucks at repairing things (Hans Reiser freely admits that but says it's never needed because nothing ever goes wrong). Businesses that use the reiser file system have to buy expensive commercial products for fixing it (there are at least two on the market). Ext3 works well and one always has the standard fsck to fall back on if something goes wrong. One can also easily convert an existing Ext2 file system to Ext3. After a crash, replaying the journal only takes a second or two. A UFS3 might have the same desirable features. From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 15:39:04 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1E8616A41F for ; Mon, 19 Dec 2005 15:39:04 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AEE243D53 for ; Mon, 19 Dec 2005 15:39:03 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id jBJFcscp034024; Mon, 19 Dec 2005 09:38:54 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <43A6D40A.70305@centtech.com> Date: Mon, 19 Dec 2005 09:38:50 -0600 From: Eric Anderson User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Justin Smith References: <43A6D190.3020504@drexel.edu> In-Reply-To: <43A6D190.3020504@drexel.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1213/Mon Dec 19 08:48:34 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: "Native" journaling file systems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 15:39:04 -0000 Justin Smith wrote: >Are there any plans to develop UFS3--- i.e., a UFS2 file system with an >added journal? > >I've used several journaling file systems in Linux and like the Reiser >FS except for one MAJOR drawback: When something goes wrong, reiser-fsck >absolutely sucks at repairing things (Hans Reiser freely admits that but >says it's never needed because nothing ever goes wrong). > >Businesses that use the reiser file system have to buy expensive >commercial products for fixing it (there are at least two on the market). > >Ext3 works well and one always has the standard fsck to fall back on if >something goes wrong. One can also easily convert an existing Ext2 file >system to Ext3. > >After a crash, replaying the journal only takes a second or two. > >A UFS3 might have the same desirable features. > > XFS is typically considered a better filesystem than ext*fs's, and it has recently had read-only support ported to FreeBSD. If you desire write support for it, you might offer help to the developers that worked so hard on the current state of XFS. As far as a native journaling fs for FreeBSD, Scott Long and a SoC developer started work on a jUFS, but I'm not certain as to the status. I too am very anxious for it, and would like to play with the code as it is so far, but I can't seem to easily check it out of perforce (no login, of course). Maybe Scott can give us a quick update? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 16:21:35 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6086516A41F; Mon, 19 Dec 2005 16:21:35 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A78E43D60; Mon, 19 Dec 2005 16:21:34 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 4140433 for multiple; Mon, 19 Dec 2005 11:19:39 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id jBJGLUsZ067406; Mon, 19 Dec 2005 11:21:30 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 19 Dec 2005 11:12:47 -0500 User-Agent: KMail/1.8.2 References: <200512141749.jBEHnjRV081112@repoman.freebsd.org> <20051217084836.71eb86e6.ai@bmc.brk.ru> <20051218082002.GR41326@ip.net.ua> In-Reply-To: <20051218082002.GR41326@ip.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512191112.48905.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1213/Mon Dec 19 09:48:34 2005 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Artemiev Igor Subject: Re: cvs commit: src/sys/pci amdpm.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 16:21:35 -0000 On Sunday 18 December 2005 03:20 am, Ruslan Ermilov wrote: > On Sat, Dec 17, 2005 at 08:48:36AM +0300, Artemiev Igor wrote: > > > i2c-amd8111.c and i2c-nforce2.c are indeed very similar, because they > > > both use SMBus 2.0 API. :-) > > > > ... > > > > > See how the offset 0x2 register means completely different things. > > > > Yep. Sorry for this little diversion :-(( > > I wrote new driver, nfpm, which completely based on linux`s i2c- > > nforce2 driver. Can you review it? > > http://stalker.bmc.brk.ru/~ai/patches/nfpm.c > > You took lm_sensors sources too literally, without accounting for > FreeBSD details. In FreeBSD (dumb, but it's too late to change > that now), the slave 6-bit addresses are expected by smbus(4) > methods already shifted, (addr << 1). My incomplete (but enough > for xmbmon to work) version is attached and appears to work, > according to the debugging output from the driver, but I eihter > don't have any recognizable sensors on either of SMBusses I have > available for testing, or something is very odd about it. It also > supports AMD-8111 SMBus 2.0 controller. > > Note that I don't call bus_set_resource() in my driver. In my > case (nVidia nForce3 Pro150 and AMD-8111 SMBus 2.0), the I/O port > resources have already been allocated, > > nfpm0 pnpinfo vendor=0x10de device=0x00d4 subvendor=0x1043 subdevice=0x80c5 > class=0x0c0500 at slot=1 function=1 handle=\_SB_.PCI0.SMBS I/O ports: > 0x5000-0x503f > 0x5040-0x507f > > so bus_set_resource() were effectively trying to add 0x5000-... > and 0x5040-... ranges again, and that causes problems for > bus_alloc_resource_any() later. Yes, that one part uses PCIR_BAR(1) (please use that rather than 0x14 for the rid) and that already works. The bus_set_resource() hacks need to go away I think, either that or the pci bus should implement bus-set_resourc() by treating the RID as a congig register offset of an extra BAR whcih would simplify amdpm -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 16:28:24 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC2D816A41F for ; Mon, 19 Dec 2005 16:28:24 +0000 (GMT) (envelope-from tillman@seekingfire.com) Received: from mail.seekingfire.com (caliban.seekingfire.com [24.72.123.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id F420B43D70 for ; Mon, 19 Dec 2005 16:28:12 +0000 (GMT) (envelope-from tillman@seekingfire.com) Received: by mail.seekingfire.com (Postfix, from userid 500) id A6CD6777; Mon, 19 Dec 2005 10:28:10 -0600 (CST) Date: Mon, 19 Dec 2005 10:28:10 -0600 From: Tillman Hodgson To: freebsd-current@freebsd.org Message-ID: <20051219162810.GK49244@seekingfire.com> References: <20051208181627.GM86838@seekingfire.com> <200512081946.22340.thierry@herbelot.com> <20051208190520.GA30123@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051208190520.GA30123@xor.obsecurity.org> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . X-GPG-Key-ID: 828AFC7B X-GPG-Fingerprint: 5584 14BA C9EB 1524 0E68 F543 0F0A 7FBC 828A FC7B X-GPG-Key: http://www.seekingfire.com/personal/gpg_key.asc X-Urban-Legend: There is lots of hidden information in headers X-Tillman-rules: yes he does User-Agent: Mutt/1.5.11 Subject: Re: Aftering updating from Dec 2 src, buildworld bombs with free() error on Dec 8 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 16:28:24 -0000 On Thu, Dec 08, 2005 at 02:05:20PM -0500, Kris Kennaway wrote: > Make was broken in the above way for brief window..you probably > upgraded at an unlucky time. Copy a working make from another system > to bootstrap back to a working system. It took me awhile to test this out, but a copy of make from 6.0R did indeed fix things. Thanks! -T From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 16:30:49 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 694A416A41F for ; Mon, 19 Dec 2005 16:30:49 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1632C43D53 for ; Mon, 19 Dec 2005 16:30:48 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id jBJGUf1O076430; Mon, 19 Dec 2005 08:30:41 -0800 (PST) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id jBJGUeuv076417; Mon, 19 Dec 2005 08:30:40 -0800 (PST) (envelope-from obrien) Date: Mon, 19 Dec 2005 08:30:40 -0800 From: "David O'Brien" To: Justin Smith Message-ID: <20051219163040.GA72940@dragon.NUXI.org> Mail-Followup-To: freebsd-current@freebsd.org, Justin Smith References: <43A6D190.3020504@drexel.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A6D190.3020504@drexel.edu> X-Operating-System: FreeBSD 7.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 User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: "Native" journaling file systems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2005 16:30:49 -0000 On Mon, Dec 19, 2005 at 10:28:16AM -0500, Justin Smith wrote: > Are there any plans to develop UFS3--- i.e., a UFS2 file system with an > added journal? Its been a dream of ours for a while now. Just need a dream maker to submit the patches. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 16:32:29 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D34916A41F for ; Mon, 19 Dec 2005 16:32:29 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id B666D43D6D for ; Mon, 19 Dec 2005 16:32:24 +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 jBJGWMfD020195 for ; Mon, 19 Dec 2005 18:32:22 +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 31727-01-6 for ; Mon, 19 Dec 2005 18:32:21 +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 jBJGUfCc020070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 19 Dec 2005 18:30:41 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id jBJGUoCk085114 for freebsd-current@FreeBSD.org; Mon, 19 Dec 2005 18:30:50 +0200 (EET) (envelope-from ru) Date: Mon, 19 Dec 2005 18:30:50 +0200 From: Ruslan Ermilov To: freebsd-current@FreeBSD.org Message-ID: <20051219163049.GA84996@ip.net.ua> References: <20051218173028.GV41326@ip.net.ua> <69674F40-30B2-4025-B5A5-AC3DE44C00A4@nevada.net.nz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: <69674F40-30B2-4025-B5A5-AC3DE44C00A4@nevada.net.nz> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: Subject: Re: New nfpm.c driver available for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2005 16:32:29 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 19, 2005 at 10:59:43AM +1300, Philip Murray wrote: > This is on a Dual Dual-Core Opteron 275 on a Tyan S2882-D motherboard =20 > w/ 4GB of RAM running -amd64 >=20 I have the same motherboard. > root@stratos# dmesg | grep nf > nfpm0: port 0xcc00-0xcc1f irq 19 at =20 > device 7.2 on pci0 > smbus0: on nfpm0 >=20 I figured that AMD-8111 uses an EC-based SMBus register access, so I've split the drivers into two: amdsmb(4) supports AMD-8111 SMBus 2.0 controller which uses EC to read/write SMBus registers, and nfsmb(4) supports NVIDIA nForce-2/3/4 MCP twin SMBus 2.0 controller that appears to use an I/O based access to SMBus registers. http://people.freebsd.org/~patches/amdsmb-nfsmb.patch 1. Recompile everything in /sys/modules/i2c/ (create two directories, controllers/amdsmb and controllers/nfsmb before applying a patch). 2. Check with smbtest: a) on nForce: smbtest /dev/smb0 smbtest /dev/smb1 b) on AMD-8111: smbtest All smbtest commands should include "slave 8" device which is the SMBus Host device. If it didn't find any more devices, it means that you now have a working SMBus bus, which it otherwise useless on your system. It if detects some other devices, chances are that some of them are xmbmon recognizeable sensors. 3. Make sure you compile the latest sysutils/xmbmon port which has smb(4) support ("mbmon" should have the -s option (lowercase ell)). 4. Substitute your PCI ID in xmbmon's pci_pm.h (see my original post that explains this in more detail). 5. On nForce2/3/4, run mbmon -S -s0 -d and mbmon -S -s1 -d. On AMD-8111, run mbmon -S -d. You may also want to s/-d/-D/ to verify it finds devices attached to SMBus, it's similar to smbtest. If it finds any known sensors (my systems don't have them), you can run mbmon -S -s[01] -c8 1 to display eight probes with a one second interval. P.S. I don't know how useful all of this is, since my systems don't seem to have any sensors attached to SMBus 2.0 busses. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDpuA5qRfpzJluFF4RAoBYAJ9Cm3YN+E09iRKaV7GFok6OLtCyAgCfdtKF 9NsYhLLITs9KdPJaVGF5eHY= =45W5 -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 16:34:39 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E56816A41F for ; Mon, 19 Dec 2005 16:34:39 +0000 (GMT) (envelope-from rmgls@wanadoo.fr) Received: from smtp10.wanadoo.fr (smtp10.wanadoo.fr [193.252.22.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BC1B43D70 for ; Mon, 19 Dec 2005 16:34:36 +0000 (GMT) (envelope-from rmgls@wanadoo.fr) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1002.wanadoo.fr (SMTP Server) with ESMTP id 27BD724000B6 for ; Mon, 19 Dec 2005 17:34:31 +0100 (CET) Received: from wanadoo.fr (ARouen-251-1-6-252.w83-115.abo.wanadoo.fr [83.115.99.252]) by mwinf1002.wanadoo.fr (SMTP Server) with ESMTP id 15B2024000B4 for ; Mon, 19 Dec 2005 17:34:31 +0100 (CET) X-ME-UUID: 20051219163431889.15B2024000B4@mwinf1002.wanadoo.fr Received: from rmgls by bip.private.music with local (Exim 4.52) id 1EoNy2-0000Sd-Cx for freebsd-current@freebsd.org; Mon, 19 Dec 2005 17:34:30 +0100 Date: Mon, 19 Dec 2005 17:34:30 +0100 From: rmgls@wanadoo.fr To: freebsd-current@freebsd.org Message-ID: <20051219163430.GA1748@wanadoo.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: ucomconsole X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 16:34:39 -0000 hello all, We have a comconsole which works at boot on computers which have serial ports. But new laptops only have usb ports. It would be handy to have an ucomconsole working with an usb to serial adapter. I think that this feature would be useful for many people. What do you think about this? raoul rmgls@wanadoo.fr From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 16:36:32 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA9F516A41F for ; Mon, 19 Dec 2005 16:36:32 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1794B43D8B for ; Mon, 19 Dec 2005 16:36:16 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id jBJGa5P6080730; Mon, 19 Dec 2005 08:36:05 -0800 (PST) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id jBJGa4Tv080729; Mon, 19 Dec 2005 08:36:04 -0800 (PST) (envelope-from obrien) Date: Mon, 19 Dec 2005 08:36:04 -0800 From: "David O'Brien" To: Rink Springer Message-ID: <20051219163604.GC72940@dragon.NUXI.org> Mail-Followup-To: freebsd-current@freebsd.org, Rink Springer References: <20051219134052.GB68985@il.fontys.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051219134052.GB68985@il.fontys.nl> X-Operating-System: FreeBSD 7.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 User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: [PATCH] FreeBSD/xbox nve(4) support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2005 16:36:33 -0000 On Mon, Dec 19, 2005 at 02:40:52PM +0100, Rink Springer wrote: > PS. I get 10MB/sec on my XBOX while transferring files, but the nve(4) > driver will cause 7500 interrupts/sec and burn up 30% interrupt time > (as well as 50% system time or so). Is this 'normal' behaviour of > nve(4) ? While the nForce NIC isn't a good one - it is much better than that on my normal PeeCee's. -- -- David (obrien@FreeBSD.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 15:47:58 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E937E16A41F for ; Mon, 19 Dec 2005 15:47:58 +0000 (GMT) (envelope-from sveinhal@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76B4043D4C for ; Mon, 19 Dec 2005 15:47:58 +0000 (GMT) (envelope-from sveinhal@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so900094wxc for ; Mon, 19 Dec 2005 07:47:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=q3bF6bzh1g86oKwwElE1rmY9TAHsNG0rcNG2nbmzSkNO7YDE3mBUpB3mTTurxPTocZBEbx7RvyGoemCZ2qzEQtO3XLnG06iXtfMjvDD1X6HGXy2gW62eT0Ad3aC8iYDW89qgrpSGoDo3nX+fMTLCGb+EI32jzUQL83QuvGp6Ue0= Received: by 10.70.60.13 with SMTP id i13mr4621222wxa; Mon, 19 Dec 2005 07:47:57 -0800 (PST) Received: by 10.70.105.11 with HTTP; Mon, 19 Dec 2005 07:47:57 -0800 (PST) Message-ID: Date: Mon, 19 Dec 2005 16:47:57 +0100 From: Svein Halvor Halvorsen Sender: sveinhal@gmail.com To: Justin Smith In-Reply-To: <43A6D190.3020504@drexel.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43A6D190.3020504@drexel.edu> X-Mailman-Approved-At: Mon, 19 Dec 2005 16:54:28 +0000 Cc: freebsd-current@freebsd.org Subject: Re: "Native" journaling file systems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 15:47:59 -0000 On 12/19/05, Justin Smith wrote: > Are there any plans to develop UFS3--- i.e., a UFS2 file system with an > added journal? Take a look at the gjournal system developed by Ivan Voras as a Google Summer of Code project. I don't know how stable that is, but it's probably worth a look. http://ivoras.sharanet.org/freebsd/gjournal.html Also; Read-only XFS support was commited to 7.0 last week. Write support is probably comming when the developer has time to write it. Svein Halvor From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 17:01:04 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D40116A41F for ; Mon, 19 Dec 2005 17:01:04 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CEC443D5F for ; Mon, 19 Dec 2005 17:01:02 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jBJH0xFu073844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Dec 2005 20:01:00 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jBJH0vZW073843; Mon, 19 Dec 2005 20:00:58 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 19 Dec 2005 20:00:57 +0300 From: Gleb Smirnoff To: Huang wen hui Message-ID: <20051219170057.GA41381@FreeBSD.org> References: <43A65EFD.3040606@gddsn.org.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <43A65EFD.3040606@gddsn.org.cn> User-Agent: Mutt/1.5.6i Cc: current@FreeBSD.org Subject: Re: em broken suspend on IBM-T42p X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 17:01:04 -0000 On Mon, Dec 19, 2005 at 03:19:25PM +0800, Huang wen hui wrote: H> On my T42p suspend operation can work well until Oct 20. It does not H> work on recent CURRENT. H> Remove em driver from kernel config does help that. Any ideas? This is a known problem and we are working on it. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 17:03:03 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A889816A41F for ; Mon, 19 Dec 2005 17:03:03 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9635043D68 for ; Mon, 19 Dec 2005 17:03:02 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 1919152BC5; Mon, 19 Dec 2005 18:03:01 +0100 (CET) Received: from localhost (dkf110.neoplus.adsl.tpnet.pl [83.24.9.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 1A68350F92; Mon, 19 Dec 2005 18:02:55 +0100 (CET) Date: Mon, 19 Dec 2005 18:01:50 +0100 From: Pawel Jakub Dawidek To: freebsd-current@freebsd.org, Justin Smith Message-ID: <20051219170150.GC91822@garage.freebsd.pl> References: <43A6D190.3020504@drexel.edu> <20051219163040.GA72940@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tqI+Z3u+9OQ7kwn0" Content-Disposition: inline In-Reply-To: <20051219163040.GA72940@dragon.NUXI.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r535 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: Subject: Re: "Native" journaling file systems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 17:03:03 -0000 --tqI+Z3u+9OQ7kwn0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 19, 2005 at 08:30:40AM -0800, David O'Brien wrote: +> On Mon, Dec 19, 2005 at 10:28:16AM -0500, Justin Smith wrote: +> > Are there any plans to develop UFS3--- i.e., a UFS2 file system with an +> > added journal? +>=20 +> Its been a dream of ours for a while now. +> Just need a dream maker to submit the patches. It's right around the corner:) Seriously speaking there are three projects going on: - UFS+J - journaling for UFS2 (Scott Long is responsible for it), - XFS - read-only support is in the base system and read-write support in development (AFAIK), - gjournal (not the gjournal project from SoC), developed by me. The work is finished. This is device (GEOM) level journaling, but allows for UFS journaling as well. I'm currently in the process of testing it. It allows for other cool things as well... :) --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --tqI+Z3u+9OQ7kwn0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDpud+ForvXbEpPzQRAsYDAKD5wqTXKAsImenrmN316VvTF30fFQCgoAk6 oKHqCl7qrCMMJFP4TdUVcDw= =4msD -----END PGP SIGNATURE----- --tqI+Z3u+9OQ7kwn0-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 17:11:03 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1DBA16A41F for ; Mon, 19 Dec 2005 17:11:03 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from pinus.cc.fer.hr (pinus.cc.fer.hr [161.53.73.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 430F743D46 for ; Mon, 19 Dec 2005 17:11: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 jBJHAmFx015844; Mon, 19 Dec 2005 18:10:55 +0100 (MET) Message-ID: <43A6E94A.4040701@fer.hr> Date: Mon, 19 Dec 2005 18:09:30 +0100 From: Ivan Voras User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Svein Halvor Halvorsen References: <43A6D190.3020504@drexel.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: "Native" journaling file systems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 17:11:04 -0000 Svein Halvor Halvorsen wrote: > On 12/19/05, Justin Smith wrote: > >>Are there any plans to develop UFS3--- i.e., a UFS2 file system with an >>added journal? > > Take a look at the gjournal system developed by Ivan Voras as a Google > Summer of Code project. I don't know how stable that is, but it's > probably worth a look. Sadly, this won't work instead of a journaling filesystem - fsck still needs to run on the whole filesystem after a crash. Also, last I heard is that Pawel (pjd) is working on a reimplementation of gjournal, so if anyone needs journaling-because-of-journaling you should probably use his version. From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 17:12:31 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 99E2E16A41F for ; Mon, 19 Dec 2005 17:12:31 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id BFD8D43D4C for ; Mon, 19 Dec 2005 17:12:30 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (ovsjiv@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id jBJHCSRc049138 for ; Mon, 19 Dec 2005 18:12:29 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id jBJHCS7A049137; Mon, 19 Dec 2005 18:12:28 +0100 (CET) (envelope-from olli) Date: Mon, 19 Dec 2005 18:12:28 +0100 (CET) Message-Id: <200512191712.jBJHCS7A049137@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Mailman-Approved-At: Mon, 19 Dec 2005 17:18:40 +0000 Cc: Subject: Re: "Native" journaling file systems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2005 17:12:31 -0000 Svein Halvor Halvorsen wrote: > On 12/19/05, Justin Smith wrote: > > Are there any plans to develop UFS3--- i.e., a UFS2 file system with an > > added journal? > > Take a look at the gjournal system developed by Ivan Voras as a Google > Summer of Code project. I don't know how stable that is, but it's > probably worth a look. > > http://ivoras.sharanet.org/freebsd/gjournal.html It has one problem: After a crash, you cannot simply replay the journal in order to get the file system into a consistent state. You still have to run a full-blown fsck. That problem renders gjournal rather useless. > Also; Read-only XFS support was commited to 7.0 last week. Write > support is probably comming when the developer has time to write it. I would very much hope so (even though it is GPL so it can never replace UFS in FreeBSD). But write support is probably ten times more complex than read-only support, so that's a huge amount of work. I wouldn't hold my breath. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "I started using PostgreSQL around a month ago, and the feeling is similar to the switch from Linux to FreeBSD in '96 -- 'wow!'." -- Oddbjorn Steffensen From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 17:30:59 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D79616A41F for ; Mon, 19 Dec 2005 17:30:59 +0000 (GMT) (envelope-from vovkasm@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EC7E43D5E for ; Mon, 19 Dec 2005 17:30:57 +0000 (GMT) (envelope-from vovkasm@gmail.com) Received: by nproxy.gmail.com with SMTP id p48so409333nfa for ; Mon, 19 Dec 2005 09:30:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qbsJmyTbZw44gTCuzpy1xLW5847ZmGb5PKLatpinuYM4MzDYU14sTRjATA5FoDx+NDRlqv1XBdA+2WRLNbfMIKaTWUEgei696TN/r39ukqfRLNVbPiD5yGQ2JCz+pMLlV1bDy6sCELQkg7ips0Ak/jlxhuGmFuuBEjG3slma+tM= Received: by 10.48.215.17 with SMTP id n17mr258258nfg; Mon, 19 Dec 2005 09:30:55 -0800 (PST) Received: by 10.48.144.15 with HTTP; Mon, 19 Dec 2005 09:30:55 -0800 (PST) Message-ID: Date: Mon, 19 Dec 2005 20:30:55 +0300 From: Vladimir Timofeev To: Ruslan Ermilov In-Reply-To: <20051219163049.GA84996@ip.net.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20051218173028.GV41326@ip.net.ua> <69674F40-30B2-4025-B5A5-AC3DE44C00A4@nevada.net.nz> <20051219163049.GA84996@ip.net.ua> Cc: freebsd-current@freebsd.org Subject: Re: New nfpm.c driver available for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2005 17:30:59 -0000 mb: Abit NF7 1. nfsmb0: port 0xe400-0xe41f irq 11 at device 1.1 on pci0 smbus0: on nfsmb0 smb0: on smbus0 nfsmb1: on nfsmb0 smbus1: on nfsmb1 smb1: on smbus1 2. root@vov# ./smbtest /dev/smb0 found slave device 8 found slave device 78 found slave device 81 found slave device 82 root@vov# ./smbtest /dev/smb1 found slave device 8 3. root@vov# mbmon -S -s0 -d SMBus[NVidia nForce2] found, but No HWM available on it!! InitMBInfo: Device not configured root@vov# mbmon -S -s1 -d SMBus[NVidia nForce2] found, but No HWM available on it!! InitMBInfo: Device not configured 2005/12/19, Ruslan Ermilov : > On Mon, Dec 19, 2005 at 10:59:43AM +1300, Philip Murray wrote: > > This is on a Dual Dual-Core Opteron 275 on a Tyan S2882-D motherboard > > w/ 4GB of RAM running -amd64 > > > I have the same motherboard. > > > root@stratos# dmesg | grep nf > > nfpm0: port 0xcc00-0xcc1f irq 19 at > > device 7.2 on pci0 > > smbus0: on nfpm0 > > > I figured that AMD-8111 uses an EC-based SMBus register access, so > I've split the drivers into two: amdsmb(4) supports AMD-8111 SMBus > 2.0 controller which uses EC to read/write SMBus registers, and > nfsmb(4) supports NVIDIA nForce-2/3/4 MCP twin SMBus 2.0 controller > that appears to use an I/O based access to SMBus registers. > > http://people.freebsd.org/~patches/amdsmb-nfsmb.patch > > 1. > Recompile everything in /sys/modules/i2c/ (create two directories, > controllers/amdsmb and controllers/nfsmb before applying a patch). > > 2. > Check with smbtest: > > a) on nForce: > smbtest /dev/smb0 > smbtest /dev/smb1 > b) on AMD-8111: > smbtest > > All smbtest commands should include "slave 8" device which is > the SMBus Host device. If it didn't find any more devices, it > means that you now have a working SMBus bus, which it otherwise > useless on your system. It if detects some other devices, > chances are that some of them are xmbmon recognizeable sensors. > > 3. > Make sure you compile the latest sysutils/xmbmon port which has > smb(4) support ("mbmon" should have the -s option (lowercase ell)). > > 4. > Substitute your PCI ID in xmbmon's pci_pm.h (see my original > post that explains this in more detail). > > 5. > On nForce2/3/4, run mbmon -S -s0 -d and mbmon -S -s1 -d. > On AMD-8111, run mbmon -S -d. > > You may also want to s/-d/-D/ to verify it finds devices > attached to SMBus, it's similar to smbtest. If it finds any > known sensors (my systems don't have them), you can run > mbmon -S -s[01] -c8 1 to display eight probes with a one > second interval. > > P.S. I don't know how useful all of this is, since my systems > don't seem to have any sensors attached to SMBus 2.0 busses. > > > Cheers, > -- > Ruslan Ermilov > ru@FreeBSD.org > FreeBSD committer > > > From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 18:15:04 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFFCD16A420 for ; Mon, 19 Dec 2005 18:15:04 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from smtp6-g19.free.fr (smtp6-g19.free.fr [212.27.42.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19C6043D75 for ; Mon, 19 Dec 2005 18:15:02 +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 smtp6-g19.free.fr (Postfix) with ESMTP id 53AA817F2C; Mon, 19 Dec 2005 19:15:00 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id BC27A9B6E7; Mon, 19 Dec 2005 18:14:34 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 8D346405A; Mon, 19 Dec 2005 19:14:34 +0100 (CET) Date: Mon, 19 Dec 2005 19:14:34 +0100 From: Jeremie Le Hen To: Travis Mikalson Message-ID: <20051219181434.GB3512@obiwan.tataz.chchile.org> References: <4394BECD.6090608@terranova.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4394BECD.6090608@terranova.net> User-Agent: Mutt/1.5.11 Cc: current@freebsd.org Subject: Re: -CURRENT crashdumps, mbuf corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 18:15:05 -0000 Hi, Travis, On Mon, Dec 05, 2005 at 05:27:25PM -0500, Travis Mikalson wrote: > Hi, > > This looks like an mbuf corruption problem, can you take a look at these? > http://tog.net/crashdumps/ > > I've got two different ones, one seems to involve all of my network > interfaces and another seems just to involve if_ath. I'm not an expert > at reading this, but both crashes look like they choked on corrupt mbufs. > > I have WITNESS and INVARIANT running in that kernel, I don't know if > they are of any use for figuring this problem out. > > Is there any additional information available that I can retrieve that > can help? I'm told that mbuf corruption problems are very hard to track > down, I'm wondering if there's anything I can do. > > FYI, this box's job in life at the moment while I've got it as > stripped-down as possible is to shuffle packets back and forth between > one if_ath (in hostap mode) and one if_vr using if_bridge. ipfw is in > there somewhere but net.link.bridge.pfil_bridge is off and so is > net.link.ether.ipfw and net.link.bridge.ipfw. Most of the time a stack trace suffices to a commiter to identify the problem. Having a kernel dump is good, but it requires to download a heavy file and this is certainly why you have't got an answer yet. You should use kgdb on you memory dump to obtain a stack trace and post it here in conjunction to the FreeBSD version you are using. Note that making kernel memory dumps publicly available is a security problem as the memory may contain sensitive informations. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 18:41:57 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF09716A41F for ; Mon, 19 Dec 2005 18:41:57 +0000 (GMT) (envelope-from hartzell@satchel.alerce.com) Received: from merlin.alerce.com (w094.z064001164.sjc-ca.dsl.cnc.net [64.1.164.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D78443D7E for ; Mon, 19 Dec 2005 18:41:44 +0000 (GMT) (envelope-from hartzell@satchel.alerce.com) Received: from merlin.alerce.com (localhost [127.0.0.1]) by merlin.alerce.com (Postfix) with ESMTP id 1F87521F0; Mon, 19 Dec 2005 10:41:39 -0800 (PST) Received: from satchel.alerce.com (w092.z064001164.sjc-ca.dsl.cnc.net [64.1.164.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by merlin.alerce.com (Postfix) with ESMTP id D7F0B21B9; Mon, 19 Dec 2005 10:41:38 -0800 (PST) Received: from satchel.alerce.com (localhost [127.0.0.1]) by satchel.alerce.com (8.13.4/8.13.4) with ESMTP id jBJIfefY092252; Mon, 19 Dec 2005 10:41:40 -0800 (PST) (envelope-from hartzell@satchel.alerce.com) Received: (from hartzell@localhost) by satchel.alerce.com (8.13.4/8.13.4/Submit) id jBJIfXCn092225; Mon, 19 Dec 2005 10:41:33 -0800 (PST) (envelope-from hartzell) From: George Hartzell MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17318.65245.462963.841483@satchel.alerce.com> Date: Mon, 19 Dec 2005 10:41:33 -0800 To: Huang wen hui In-Reply-To: <43A65EFD.3040606@gddsn.org.cn> References: <43A65EFD.3040606@gddsn.org.cn> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid X-Virus-Scanned: ClamAV using ClamSMTP Cc: current@freebsd.org Subject: Re: em broken suspend on IBM-T42p X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hartzell@alerce.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2005 18:41:58 -0000 Huang wen hui writes: > hi, > On my T42p suspend operation can work well until Oct 20. It does not > work on recent CURRENT. > Remove em driver from kernel config does help that. Any ideas? > [...] I'm not currently using em in my T42p on 6-STABLE. My laptop would hang at pseudo-random times after resuming, and my current theory is that em is involved. I'm still exploring the issue though. What happens to your laptop? g. From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 18:56:10 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBB2D16A41F; Mon, 19 Dec 2005 18:56:10 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7707B43D45; Mon, 19 Dec 2005 18:56:08 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 19 Dec 2005 10:56:08 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <43A70246.6040302@elischer.org> Date: Mon, 19 Dec 2005 10:56:06 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <43A6D190.3020504@drexel.edu> <20051219163040.GA72940@dragon.NUXI.org> <20051219170150.GC91822@garage.freebsd.pl> In-Reply-To: <20051219170150.GC91822@garage.freebsd.pl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Justin Smith , freebsd-current@freebsd.org Subject: Re: "Native" journaling file systems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 18:56:10 -0000 Pawel Jakub Dawidek wrote: >On Mon, Dec 19, 2005 at 08:30:40AM -0800, David O'Brien wrote: >+> On Mon, Dec 19, 2005 at 10:28:16AM -0500, Justin Smith wrote: >+> > Are there any plans to develop UFS3--- i.e., a UFS2 file system with an >+> > added journal? >+> >+> Its been a dream of ours for a while now. >+> Just need a dream maker to submit the patches. > >It's right around the corner:) > >Seriously speaking there are three projects going on: > >- UFS+J - journaling for UFS2 (Scott Long is responsible for it), >- XFS - read-only support is in the base system and read-write support > in development (AFAIK), >- gjournal (not the gjournal project from SoC), developed by me. > The work is finished. This is device (GEOM) level journaling, but > allows for UFS journaling as well. I'm currently in the process of > testing it. It allows for other cool things as well... :) > > > You forget the Reiserfs for FreeBSd project. From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 19:46:30 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B575616A420 for ; Mon, 19 Dec 2005 19:46:30 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2729643D60 for ; Mon, 19 Dec 2005 19:46:27 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 4153090 for multiple; Mon, 19 Dec 2005 14:44:27 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id jBJJkIuh068559; Mon, 19 Dec 2005 14:46:18 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Andrew Gallatin Date: Mon, 19 Dec 2005 14:26:51 -0500 User-Agent: KMail/1.8.2 References: <17314.60552.595375.783753@grasshopper.cs.duke.edu> <200512161638.03037.jhb@freebsd.org> <17315.15301.316482.649755@grasshopper.cs.duke.edu> In-Reply-To: <17315.15301.316482.649755@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512191426.52360.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1213/Mon Dec 19 09:48:34 2005 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: freebsd-current@freebsd.org Subject: Re: PREEMPTION vs ndisulator X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 19:46:30 -0000 On Friday 16 December 2005 05:12 pm, Andrew Gallatin wrote: > John Baldwin writes: > > On Friday 16 December 2005 03:52 pm, Andrew Gallatin wrote: > > > John Baldwin writes: > > > > On Friday 16 December 2005 11:34 am, Andrew Gallatin wrote: > > > > Looks like an ithread has preempted your driver's start routine. > > > > If you let it run some more and then break into ddb is the same > > > > thread (pid 11) still running? Also, which process is pid 11? > > It looks like the ithread is looping: > > db> show intrcnt > irq4: sio0 1007 > irq14: ata0 33 > irq17: fwohci0 1 > irq18: ndis0 757379 > irq21: ohci0+ 382 > cpu0: timer 1254872 > db> c > [halt - sent] > KDB: enter: Line break on console > [thread pid 76 tid 100049 ] > Stopped at kdb_enter+0x2f: nop > db> show intrcnt > irq4: sio0 1009 > irq14: ata0 33 > irq17: fwohci0 1 > irq18: ndis0 992263 > irq21: ohci0+ 382 > cpu0: timer 1259314 > > > I know the interrupt is actually disabled in the DPC, and > not in the interrupt handler. That's probably the problem. > The DPC is just never getting scheduled, so the interrupt > line is never lowered. > > Thanks! Yeah, given my recent experience with WDM that approach sounds very problematic since your DPC doesn't run at DIRQL in Windows either, and you really should be shutting your hardware up in your ISR rather than your DPC. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 19:46:31 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6482916A41F; Mon, 19 Dec 2005 19:46:31 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 273FB43D6A; Mon, 19 Dec 2005 19:46:27 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 4153092 for multiple; Mon, 19 Dec 2005 14:44:28 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id jBJJkIui068559; Mon, 19 Dec 2005 14:46:19 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Anish Mistry Date: Mon, 19 Dec 2005 14:46:47 -0500 User-Agent: KMail/1.8.2 References: <200512161237.15148.mistry.7@osu.edu> <200512161638.58917.jhb@freebsd.org> <200512161904.04913.mistry.7@osu.edu> In-Reply-To: <200512161904.04913.mistry.7@osu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512191446.50344.jhb@freebsd.org> X-Virus-Scanned: ClamAV 0.87.1/1213/Mon Dec 19 09:48:34 2005 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-0.3 required=4.2 tests=ALL_TRUSTED,BIZ_TLD autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: threads@freebsd.org, freebsd-current@freebsd.org, davidxu@freebsd.org Subject: Re: Reproducable Panic on CURRENT and 6.0-RELEASE X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 19:46:31 -0000 On Friday 16 December 2005 07:03 pm, Anish Mistry wrote: > On Friday 16 December 2005 04:38 pm, you wrote: > > On Friday 16 December 2005 03:27 pm, Anish Mistry wrote: > > > On Friday 16 December 2005 03:11 pm, you wrote: > > > > On Friday 16 December 2005 12:37 pm, Anish Mistry wrote: > > > > > Here is the offending program/code. The interesting program > > > > > is avidemux_2.1_branch_anish/avidemux/avidemux2. > > > > > (It is compiled for CURRENT, and I left all the object code > > > > > stuff in so it's a bit large 21MB) > > > > > http://am-productions.biz/docs/avidemux_2.1_branch_anish.tgz > > > > > > > > > > First you'll need to compile spidermonkey to be threadsafe so > > > > > add the following to your lang/spidermonkey/Makefile before > > > > > installing it: LIB_DEPENDS= nspr4.1:${PORTSDIR}/devel/nspr > > > > > MAKE_ARGS+= JS_THREADSAFE=YES LDFLAGS="-L${LOCALBASE}/lib > > > > > -lpthread -lm" > > > > > CFLAGS+= -I${LOCALBASE}/include/nspr > > > > > > > > > > Once a threadsafe spidermonkey is installed to kill the > > > > > machine you'll need to: > > > > > cd avidemux_2.1_branch_anish/avidemux > > > > > ./avidemux2 --run new-features-test.js > > > > > > > > > > On CURRENT: > > > > > kernel trap 12 with interrupts disabled > > > > > > > > > > Fatal trap 12: page fault while in kernel mode > > > > > fault virtual address = 0x68 > > > > > fault code = supervisor read, page not present > > > > > instruction pointer = 0x20:0xc04e6f36 > > > > > stack pointer = 0x28:0xcc9edb3c > > > > > frame pointer = 0x28:0xcc9edbb0 > > > > > code segment = base 0x0, limit 0xfffff, type 0x1b > > > > > = DPL 0, pres 1, def32 1, gran 1 > > > > > processor eflags = resume, IOPL = 0 > > > > > current process = 798 (gdb) > > > > > trap number = 12 > > > > > panic: page fault > > > > > > > > > > #0 doadump () at pcpu.h:165 > > > > > #1 0xc04bb7eb in boot (howto=260) > > > > > at /usr/src/sys/kern/kern_shutdown.c:399 > > > > > #2 0xc04bb353 in panic (fmt=0xc06069a7 "%s") > > > > > at /usr/src/sys/kern/kern_shutdown.c:555 > > > > > #3 0xc05e91ba in trap_fatal (frame=0xcc9edafc, eva=104) > > > > > at /usr/src/sys/i386/i386/trap.c:862 > > > > > #4 0xc05e96d9 in trap (frame= > > > > > {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = > > > > > -1032878460, tf_esi = 1, tf_ebp = -862004304, tf_isp = > > > > > -862004440, tf_ebx = -1033297504, tf_edx = -1033987232, > > > > > tf_ecx = 4, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = > > > > > -1068601546, tf_cs = 32, tf_eflags = 65687, tf_esp = > > > > > -1032878356, tf_ss = -1067380424}) at > > > > > /usr/src/sys/i386/i386/trap.c:273 > > > > > #5 0xc05db6fa in calltrap () > > > > > at /usr/src/sys/i386/i386/exception.s:137 > > > > > #6 0xc04e6f36 in kern_ptrace (td=0xc25e9b60, req=10, pid=1, > > > > > addr=0x0, data=17) > > > > > at /usr/src/sys/kern/sys_process.c:802 > > > > > > > > On HEAD this is: > > > > p->p_xthread->td_flags &= ~TDF_XSIG; > > > > > > > > If two threads called kern_ptrace() with the same PID and this > > > > could happen. Hmm, I have no idea how p_xthread is supposed to > > > > not be racey here in fact. It would be helpful to know what > > > > PTRACE action it it is trying to do and maybe a KTR trace of > > > > the various ptrace events leading up to this condition. I have > > > > no idea what thread you are supposed to act on if p_xthread is > > > > NULL either. > > > > > > How would I do this? My kdb/ddb skills are prettymuch limited to > > > getting a backtrace. > > > > You could add some new KTR tracepoints to log each request into > > kern_ptrace() and then do a 'show ktr' at the ddb prompt. > > I put a KTR_GEN tracepoint in kern_ptrace and only got 1 entry in the > log: > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x68 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc04ed896 > stack pointer = 0x28:0xcc9a9b3c > frame pointer = 0x28:0xcc9a9bb0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = resume, IOPL = 0 > current process = 697 (gdb) > [thread pid 697 tid 100073 ] > Stopped at kern_ptrace+0xef6: movl 0x68(%eax),%ebx > db> show ktr > 0 (0xc2354b60): kern_ptrace: td=0xc2354b60 req=0xa pid=695 addr==0x0 > data==0x0 Ok, so it's doing a PT_ATTACH on pid 695. > --- End of trace buffer --- > db> > > The full alltrace: > http://am-productions.biz/docs/ktr-trace.txt.gz > From alltrace results for pid 695 is: > db> bt > Tracing pid 697 tid 100073 td 0xc2354b60 > kern_ptrace(c2354b60,a,2b7,0,11) at kern_ptrace+0xef6 > ptrace(c2354b60,cc9a9d04,4,0,23) at ptrace+0x40 > syscall(3b,3b,3b,81e9438,2b7) at syscall+0x19a > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (26, FreeBSD ELF32, ptrace), eip = 0x282c1a6b, esp = > 0xbfbfe468, ebp = 0xbfbfe480 --- > db> alltrace > > Tracing command gdb pid 697 tid 100073 td 0xc2354b60 > kern_ptrace(c2354b60,a,2b7,0,11) at kern_ptrace+0xef6 > ptrace(c2354b60,cc9a9d04,4,0,23) at ptrace+0x40 > syscall(3b,3b,3b,81e9438,2b7) at syscall+0x19a > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (26, FreeBSD ELF32, ptrace), eip = 0x282c1a6b, esp = > 0xbfbfe468, ebp = 0xbfbfe480 --- > > Tracing command avidemux2 pid 695 tid 100080 td 0xc2635680 > sched_switch(c2635680,0,2,2ffd8312,ea5ba7fb) at sched_switch+0xb5 > mi_switch(2,0,c2635680,ac,c0619941) at mi_switch+0x259 > uio_yield(0,0,47000,0,c25f0074) at uio_yield+0x72 > vn_rdwr_inchunks(1,c2642840,89b1000,b37000,47000,0,0,101,c2640c00,0,0,c2635 >680) at vn_rdwr_inchunks+0xb4 > elf32_coredump(c2635680,c2642840,ffffffff,7fffffff) at > elf32_coredump+0x132 > sigexit(c2635680,6,c2634294,8,c0618e65) at sigexit+0x8df > kse_thr_interrupt(c2635680,cca0dd04,3,0,0) at kse_thr_interrupt+0x10c > syscall(3b,3b,3b,20,0) at syscall+0x19a > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (382, FreeBSD ELF32, kse_thr_interrupt), eip = 0x28fe5603, > esp = 0xbf8fdaec, ebp = 0xbf8fdb60 --- > > Tracing command avidemux2 pid 695 tid 100078 td 0xc26359c0 > sched_switch(c26359c0,c2635820,1,82b08812,3b03415f) at > sched_switch+0xb5 > mi_switch(1,c2635820,0,c26359c0,cca13ba0) at mi_switch+0x259 > sleepq_switch(0,cca13bd0,c04c5896,c263422c,0) at sleepq_switch+0xc2 > sleepq_wait_sig(c263422c,0,100,c0618588,31f) at sleepq_wait_sig+0xc > msleep(c263422c,c2634294,15c,c0620da6,0) at msleep+0x356 > kern_wait(c26359c0,2b8,cca13c28,0,0) at kern_wait+0x350 > wait4(c26359c0,cca13d04,4,0,0) at wait4+0x2d > syscall(3b,3b,3b,94f1000,bfbfde90) at syscall+0x19a > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (7, FreeBSD ELF32, wait4), eip = 0x2903a067, esp = > 0xbfbfdc04, ebp = 0xbfbfdc1c --- > > Tracing command avidemux2 pid 695 tid 100077 td 0xc2635b60 > sched_switch(c2635b60,0,1,cbf0f192,13141da1) at sched_switch+0xb5 > mi_switch(1,0,0,c2635b60,cca16c04) at mi_switch+0x259 > sleepq_switch(0,c2635b60,cca16c38,c04c595a,c26342b4) at > sleepq_switch+0xc2 > sleepq_timedwait_sig(c26342b4) at sleepq_timedwait_sig+0xd > msleep(c26342b4,c2634294,168,c0618e91,bb9) at msleep+0x41a > kse_release(c2635b60,cca16d04,1,0,1) at kse_release+0xb8 > syscall(3b,3b,3b,81,97c3200) at syscall+0x19a > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (383, FreeBSD ELF32, kse_release), eip = 0x28fe55c3, esp = > 0xbf9fef78, ebp = 0xbf9fefa8 --- Given that one thread is doing a coredump, I bet someone tried to enter single threading mode, and single threading mode sets P_STOPPED_SINGLE _without_ setting p_xthread, thus P_SHOULDSTOP() is true, but p_xthread is NULL. I guess thread_single() should set both p_singlethread and p_xthread? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 19:51:09 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3685F16A41F for ; Mon, 19 Dec 2005 19:51:09 +0000 (GMT) (envelope-from yb@bashibuzuk.net) Received: from a.6f2.net (a.6f2.net [213.189.5.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59DC943D64 for ; Mon, 19 Dec 2005 19:51:08 +0000 (GMT) (envelope-from yb@bashibuzuk.net) Received: by a.6f2.net (Postfix, from userid 66) id 32CA9BF8E9D; Mon, 19 Dec 2005 20:51:06 +0100 (CET) Received: by cc.bashibuzuk.net (Postfix, from userid 1001) id 8A77DC08D; Mon, 19 Dec 2005 20:50:06 +0100 (CET) Date: Mon, 19 Dec 2005 20:50:06 +0100 From: Yann Berthier To: freebsd-current@freebsd.org Message-ID: <20051219195006.GB859@bashibuzuk.net> Mail-Followup-To: freebsd-current@freebsd.org References: <43A6D190.3020504@drexel.edu> <20051219163040.GA72940@dragon.NUXI.org> <20051219170150.GC91822@garage.freebsd.pl> <43A70246.6040302@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A70246.6040302@elischer.org> X-Operating-System: FreeBSD 7.0-CURRENT User-Agent: Mutt/1.5.11 Subject: Re: "Native" journaling file systems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 19:51:09 -0000 On Mon, 19 Dec 2005, at 10:56, Julian Elischer wrote: > Pawel Jakub Dawidek wrote: > > >On Mon, Dec 19, 2005 at 08:30:40AM -0800, David O'Brien wrote: > >+> On Mon, Dec 19, 2005 at 10:28:16AM -0500, Justin Smith wrote: > >+> > Are there any plans to develop UFS3--- i.e., a UFS2 file system with > >an > >+> > added journal? > >+> > >+> Its been a dream of ours for a while now. > >+> Just need a dream maker to submit the patches. > > > >It's right around the corner:) > > > >Seriously speaking there are three projects going on: > > > >- UFS+J - journaling for UFS2 (Scott Long is responsible for it), > >- XFS - read-only support is in the base system and read-write support > > in development (AFAIK), > >- gjournal (not the gjournal project from SoC), developed by me. > > The work is finished. This is device (GEOM) level journaling, but > > allows for UFS journaling as well. I'm currently in the process of > > testing it. It allows for other cool things as well... :) > > > > > > > You forget the Reiserfs for FreeBSd project. And there is another contender: it seems that Matt Dillon plans to fully integrate ZFS in dflybsd. And no, i have not the slightest idea of the amount of work needed to benefit from his future work to bring this in freebsd :) - yann From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 20:30:55 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 095C716A42D; Mon, 19 Dec 2005 20:30:55 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF84143D60; Mon, 19 Dec 2005 20:30:46 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1EoRed-0000tk-00; Mon, 19 Dec 2005 21:30:43 +0100 Date: Mon, 19 Dec 2005 21:30:43 +0100 To: Ruslan Ermilov Message-ID: <20051219203043.GA26388@poupinou.org> References: <20051218173028.GV41326@ip.net.ua> <69674F40-30B2-4025-B5A5-AC3DE44C00A4@nevada.net.nz> <20051219163049.GA84996@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051219163049.GA84996@ip.net.ua> User-Agent: Mutt/1.5.9i From: Bruno Ducrot Cc: freebsd-current@FreeBSD.org Subject: Re: New nfpm.c driver available for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2005 20:30:56 -0000 On Mon, Dec 19, 2005 at 06:30:50PM +0200, Ruslan Ermilov wrote: > On Mon, Dec 19, 2005 at 10:59:43AM +1300, Philip Murray wrote: > > This is on a Dual Dual-Core Opteron 275 on a Tyan S2882-D motherboard > > w/ 4GB of RAM running -amd64 > > > I have the same motherboard. > > > root@stratos# dmesg | grep nf > > nfpm0: port 0xcc00-0xcc1f irq 19 at > > device 7.2 on pci0 > > smbus0: on nfpm0 > > > I figured that AMD-8111 uses an EC-based SMBus register access, so > I've split the drivers into two: amdsmb(4) supports AMD-8111 SMBus > 2.0 controller which uses EC to read/write SMBus registers, and > nfsmb(4) supports NVIDIA nForce-2/3/4 MCP twin SMBus 2.0 controller > that appears to use an I/O based access to SMBus registers. > > http://people.freebsd.org/~patches/amdsmb-nfsmb.patch > > 1. > Recompile everything in /sys/modules/i2c/ (create two directories, > controllers/amdsmb and controllers/nfsmb before applying a patch). > > 2. > Check with smbtest: > > a) on nForce: > smbtest /dev/smb0 > smbtest /dev/smb1 > b) on AMD-8111: > smbtest > > All smbtest commands should include "slave 8" device which is > the SMBus Host device. If it didn't find any more devices, it > means that you now have a working SMBus bus, which it otherwise > useless on your system. It if detects some other devices, > chances are that some of them are xmbmon recognizeable sensors. > > 3. > Make sure you compile the latest sysutils/xmbmon port which has > smb(4) support ("mbmon" should have the -s option (lowercase ell)). > > 4. > Substitute your PCI ID in xmbmon's pci_pm.h (see my original > post that explains this in more detail). > > 5. > On nForce2/3/4, run mbmon -S -s0 -d and mbmon -S -s1 -d. > On AMD-8111, run mbmon -S -d. > > You may also want to s/-d/-D/ to verify it finds devices > attached to SMBus, it's similar to smbtest. If it finds any > known sensors (my systems don't have them), you can run > mbmon -S -s[01] -c8 1 to display eight probes with a one > second interval. > > P.S. I don't know how useful all of this is, since my systems > don't seem to have any sensors attached to SMBus 2.0 busses. > I think those tyan motherboards use IPMI. Maybe sysutils/freeipmi will work? -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 20:55:50 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6390416A41F for ; Mon, 19 Dec 2005 20:55:50 +0000 (GMT) (envelope-from fcash@ocis.net) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC2CC43D4C for ; Mon, 19 Dec 2005 20:55:49 +0000 (GMT) (envelope-from fcash@ocis.net) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id C9B548A00B2 for ; Mon, 19 Dec 2005 12:55:27 -0800 (PST) Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00470-01-64 for ; Mon, 19 Dec 2005 12:55:26 -0800 (PST) Received: from s157.sbo (unknown [192.168.0.157]) by smtp.sd73.bc.ca (Postfix) with ESMTP id DD2BB8A00A6 for ; Mon, 19 Dec 2005 12:55:25 -0800 (PST) From: Freddie Cash To: freebsd-current@freebsd.org Date: Mon, 19 Dec 2005 12:55:45 -0800 User-Agent: KMail/1.8.3 References: <1132743283.1197.55.camel@leguin> In-Reply-To: <1132743283.1197.55.camel@leguin> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512191255.46304.fcash@ocis.net> X-Virus-Scanned: by amavisd-new using ClamAV at sd73.bc.ca Subject: Re: DRM update for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2005 20:55:50 -0000 On November 23, 2005 02:54 am, Eric Anholt wrote: > I've got a patch at: > http://people.freebsd.org/~anholt/dri/drm-sys-20051123.diff > for testing, which merges DRM CVS into FreeBSD. I've done basic tests > of a recent DRM CVS with WITNESS on AGP/PCI Matrox, AGP/PCI Rage 128, > AGP Radeon r100/r200/r300, AGP Savage4 (new!), SiS, and 3dfx, and this > version should be equivalent to what I tested. I'll do another pass of > testing before I commit, but I'd also like to get some wider testing so > more panics can show up if they exist. This particular diff has only > been compile-tested with LINT on amd64 so far. While I haven't tested this specific patchset, I figured I'd pipe up with a "yay, it works" regarding ATI IGP 200 (RADEON 7000) drm support on my Toshiba Satellite A60 laptop. When I was running FreeBSD 5.x and Xorg 6.x I was never able to get a working agp0, drm0, or DRM/DRI. (There was a working agp0 in the early 5.2/5.3 days, but then it disappeared. Even with that, though, DRM/DRI in X never worked.) Updating the laptop to RELENG_6 from early Dec, xorg-server-snap, and the latest dri-devel port now gives me: drm0@pci1:5:0: class=0x030000 card=0xff101179 chip=0x44371002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Radeon Mobility 7000 IGP' class = display subclass = VGA agp0@pci0:0:0 class=0x060000 card=0x00000000 chip=0xcab31002 rev=0x05 hdr=0x00 vendor = 'ATI Technologies Inc' class = bridge subclass = HOST-PCI Running glxgears at 1024x768x16 gives me a decent 35 fps, compared to the 1 fps I used to get. :) All that's left is to get the IDE controller working at better than ATA33 speeds. -- Freddie Cash fcash@ocis.net From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 21:17:20 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0493716A41F for ; Mon, 19 Dec 2005 21:17:20 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DD2E43D66 for ; Mon, 19 Dec 2005 21:17:18 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (uhktgb@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id jBJLHETM057231 for ; Mon, 19 Dec 2005 22:17:15 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id jBJLHE8C057230; Mon, 19 Dec 2005 22:17:14 +0100 (CET) (envelope-from olli) Date: Mon, 19 Dec 2005 22:17:14 +0100 (CET) Message-Id: <200512192117.jBJLHE8C057230@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG In-Reply-To: <200512191255.46304.fcash@ocis.net> X-Newsgroups: list.freebsd-current User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Mailman-Approved-At: Mon, 19 Dec 2005 21:33:13 +0000 Cc: Subject: Re: DRM update for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-current@FreeBSD.ORG List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2005 21:17:20 -0000 Freddie Cash wrote: > Running glxgears at 1024x768x16 gives me a decent 35 fps, compared to the > 1 fps I used to get. :) Uhm. Are you sure that you're running hardware-accelerated OpenGL glxgears? I get 48 fps at 1400x1050x32 -- in software, without any hardware 3D acceleration. (It's a 1.6GHz Centrino notebook with shared i915 graphics. 2D acceleration is enabled, of course.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "Clear perl code is better than unclear awk code; but NOTHING comes close to unclear perl code" (taken from comp.lang.awk FAQ) From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 21:36:20 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCBEF16A41F for ; Mon, 19 Dec 2005 21:36:20 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: from mail.dt.e-technik.uni-dortmund.de (krusty.dt.E-Technik.uni-dortmund.de [129.217.163.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id A214243D78 for ; Mon, 19 Dec 2005 21:36:18 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: from localhost (localhost [127.0.0.1]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id DBF8344129; Mon, 19 Dec 2005 22:36:16 +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 ESMTP id 01976-06; Mon, 19 Dec 2005 22:36:15 +0100 (CET) Received: from m2a2.dyndns.org (p5091366B.dip0.t-ipconnect.de [80.145.54.107]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 122B9440A8; Mon, 19 Dec 2005 22:36:14 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 4308B2018ED; Mon, 19 Dec 2005 22:36:14 +0100 (CET) Received: from m2a2.dyndns.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06378-02; Mon, 19 Dec 2005 22:36:12 +0100 (CET) Received: by merlin.emma.line.org (Postfix, from userid 500) id D2850201F1F; Mon, 19 Dec 2005 22:36:11 +0100 (CET) From: Matthias Andree To: Justin Smith In-Reply-To: <43A6D190.3020504@drexel.edu> (Justin Smith's message of "Mon, 19 Dec 2005 10:28:16 -0500") References: <43A6D190.3020504@drexel.edu> X-PGP-Key: http://home.pages.de/~mandree/keys/GPGKEY.asc Date: Mon, 19 Dec 2005 22:36:11 +0100 Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: amavisd-new at dt.e-technik.uni-dortmund.de Cc: freebsd-current@freebsd.org Subject: Re: "Native" journaling file systems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 21:36:21 -0000 Justin Smith writes: > Are there any plans to develop UFS3--- i.e., a UFS2 file system with an > added journal? > > I've used several journaling file systems in Linux and like the Reiser > FS except for one MAJOR drawback: When something goes wrong, reiser-fsck > absolutely sucks at repairing things (Hans Reiser freely admits that but > says it's never needed because nothing ever goes wrong). I have been using reiserfs for a while, but I ultimately dropped it again and reverted to ext3fs because I didn't like the sloppy spelling of the tools to begin with, and the fact that there have always been accumulated inconsistencies in the on-disk file systems on some systems. The recent in-kernel versions have been more stable, and reiserfsck has improved, too, but there are two real showstoppers: 1. the reiserfs team dropped 3.X support and went for reiser4 (I have been told this is reiser4, not reiserfs4, whatever), leaving 3.X issues unresolved 2. reiserfs 3.6 only supports a limited amount of files with the same internal hash code per given unit (I don't recall if unit was directory or file system, probably the former). Some may see this as pathological, but I see it as a problem. 3. data journalling or data ordering, which Linux ext3fs supported, has never made official reiserfs 3.X versions as far as I know, which means NUL blocks showing up in files after crashes. Chris Mason added such support to SUSE kernels. So my bottom line is: investing time into reiserfs 3.X is investing time into a dead product. I know too little about reiser4, but it has been refused entry to the baseline Linux kernel several times on technical grounds, and ultimately the opinions clashed so hard that the reviewer whose opinion was asked threw in the towel. My opinion however is that reiser4 is a new product and will not be ripe before it has been two years in the kernel baseline, and who says that the guys around Hans Reiser haven't moved on to reiser5 by that time? After all, ext3fs supports some dirhash variant ("dir_index") which seems to be pretty unobtrusive, it appears to "just work". I believe the reason why it was separated (in Linux) from the ext2 code is to not introduce instabilities or make the code harder to read. (There's actually another jbd, journalling block device, driver in Linux, that ext3fs uses.) -- Matthias Andree From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 21:37:50 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5B7816A41F for ; Mon, 19 Dec 2005 21:37:50 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: from mail.dt.e-technik.uni-dortmund.de (krusty.dt.E-Technik.uni-dortmund.de [129.217.163.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABAE443D77 for ; Mon, 19 Dec 2005 21:37:49 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: from localhost (localhost [127.0.0.1]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id E5EF844129; Mon, 19 Dec 2005 22:37:48 +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 ESMTP id 01970-07; Mon, 19 Dec 2005 22:37:47 +0100 (CET) Received: from m2a2.dyndns.org (p5091366B.dip0.t-ipconnect.de [80.145.54.107]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 349D6440A8; Mon, 19 Dec 2005 22:37:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id AA9372018ED; Mon, 19 Dec 2005 22:37:46 +0100 (CET) Received: from m2a2.dyndns.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01406-14; Mon, 19 Dec 2005 22:37:44 +0100 (CET) Received: by merlin.emma.line.org (Postfix, from userid 500) id 93FDB201F1F; Mon, 19 Dec 2005 22:37:44 +0100 (CET) From: Matthias Andree To: Eric Anderson In-Reply-To: <43A6D40A.70305@centtech.com> (Eric Anderson's message of "Mon, 19 Dec 2005 09:38:50 -0600") References: <43A6D190.3020504@drexel.edu> <43A6D40A.70305@centtech.com> X-PGP-Key: http://home.pages.de/~mandree/keys/GPGKEY.asc Date: Mon, 19 Dec 2005 22:37:44 +0100 Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: amavisd-new at dt.e-technik.uni-dortmund.de Cc: Justin Smith , freebsd-current@freebsd.org Subject: Re: "Native" journaling file systems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2005 21:37:51 -0000 Eric Anderson writes: > Justin Smith wrote: > >>Are there any plans to develop UFS3--- i.e., a UFS2 file system with an >>added journal? >> >>I've used several journaling file systems in Linux and like the Reiser >>FS except for one MAJOR drawback: When something goes wrong, reiser-fsck >>absolutely sucks at repairing things (Hans Reiser freely admits that but >>says it's never needed because nothing ever goes wrong). >> >>Businesses that use the reiser file system have to buy expensive >>commercial products for fixing it (there are at least two on the market). >> >>Ext3 works well and one always has the standard fsck to fall back on if >>something goes wrong. One can also easily convert an existing Ext2 file >>system to Ext3. >> >>After a crash, replaying the journal only takes a second or two. >> >>A UFS3 might have the same desirable features. >> >> > > XFS is typically considered a better filesystem than ext*fs's, extfs is dead, but I'd be interested to see this backed by independent sources. One thing I find lacking in XFS is the "data=ordered" mode of ext3fs. > As far as a native journaling fs for FreeBSD, Scott Long and a SoC > developer started work on a jUFS, but I'm not certain as to the status. > I too am very anxious for it, and would like to play with the code as it > is so far, but I can't seem to easily check it out of perforce (no > login, of course). > > Maybe Scott can give us a quick update? What has become of lfs by the way? -- Matthias Andree From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 21:48:28 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C06F16A420 for ; Mon, 19 Dec 2005 21:48:28 +0000 (GMT) (envelope-from caiquanqing@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C66A43D7D for ; Mon, 19 Dec 2005 21:48:25 +0000 (GMT) (envelope-from caiquanqing@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so952069wxc for ; Mon, 19 Dec 2005 13:48:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PiI/kTy2aigrp+0teHpYb6RpVzE67eadRlaZjL2pwsXNp9rSjelaBryK9c3k+LAgZk6Y8+seZNp/Hfx5eZfF2Fi6XfVbmIrcWuYeAjlh4ehUyqM21yHAniCma5LtpjBGMzRO/oGV4p0iWPqrTIQ9vqey1NiDz4Lp51ApsgH6CvI= Received: by 10.70.98.11 with SMTP id v11mr5112932wxb; Mon, 19 Dec 2005 13:48:23 -0800 (PST) Received: by 10.70.128.11 with HTTP; Mon, 19 Dec 2005 13:48:23 -0800 (PST) Message-ID: <2b22951e0512191348t227c9354i36d6a4a87e7d5698@mail.gmail.com> Date: Mon, 19 Dec 2005 13:48:23 -0800 From: "Cai, Quanqing" To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org, Matthias Andree In-Reply-To: <20051218092523.GA4694@merlin.emma.line.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20051213151908.GA26821@crodrigues.org> <20051216151228.GA34670@crodrigues.org> <20051217141647.GC27992@merlin.emma.line.org> <2b22951e0512172355k36a579f4i42dd72562a3530ed@mail.gmail.com> <20051218092523.GA4694@merlin.emma.line.org> Cc: Subject: Re: XFS (read-only) support committed to CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2005 21:48:28 -0000 On 12/18/05, Matthias Andree wrote: > On Sat, 17 Dec 2005, Cai, Quanqing wrote: > > > On 12/17/05, Matthias Andree wrote: > > > On Fri, 16 Dec 2005, Craig Rodrigues wrote: > > > > > > > Your comment makes no sense. What does being GPL have to do with > > > > choosing ext2fs vs. XFS? We ported XFS to FreeBSD because we felt = like it, > > > > and it was fun. [...] > > > > > > That's a compelling reason. Seriously. > > > > No offense, you could port ext3 too if you like... > > > > My company has 20s nfs servers(6 250G RAID 1 units), currently use > > SuSE9 w/XFS. I used ext3 on some but got long time fsck headache(Yes, > > I have data=3Djournal in fstab, but journal will fail under heavy load)= . > > So personally I prefer XFS. > > Failing journals are either I/O errors (dying hard disk drive) or > otherwise Linux kernel bugs. I have not yet seen ext3fs + NFS (or only > the journals) break under load (SUSE 9.2 and 10.0) for any other reason > than a broken drive or broken cables. If you have a workload that > reproduces the problem, report it to SUSE. No, I don't have time to deal with SuSE regarding failure, the company I am working for is growing so fast, need to add dozens of servers every month. After switch to XFS, I seldom get problems, even if I got problem, I can quickly reboot nfs server because it is using XFS. > > OTOH, it's "only" one Xeon NFS server with 1 70 GB RAID5 and 1 292 GB > RAID5 (MegaRAID SCSI 320-1 with BBU) with half a dozen users at any one > time. Oh, you don't put much load on it. I am using nfs server as storage server of internet application, so they get very high IO load. > > BTW, thank Craig Rodrigues, Alexander Kabaev, Russell Cattelan and all > > others for porting XFS to FreeBSD, it's a good news for community. We > > need a journal FS on FreeBSD so badly! > > :-) > > -- > Matthias Andree > Anyway, I am not tend to start a flame war between ext3 and XFS, I choose ext3 for our MySQL server because MySQL.com suggest me that, they said ext3 has better performance. Sorry, this is out of topic:( Cai, Quanqing From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 21:48:42 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9574416A424 for ; Mon, 19 Dec 2005 21:48:42 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0841A43D76 for ; Mon, 19 Dec 2005 21:48:40 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.4/8.13.1) with ESMTP id jBJLmcY5003162 for ; Mon, 19 Dec 2005 13:48:38 -0800 (PST) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.4/8.13.1/Submit) id jBJLmc0A003004 for freebsd-current@freebsd.org; Mon, 19 Dec 2005 13:48:38 -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: freebsd-current@freebsd.org In-Reply-To: <200512192117.jBJLHE8C057230@lurza.secnetix.de> References: <200512192117.jBJLHE8C057230@lurza.secnetix.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-JkTphaSq8/4oG5S7+GWH" Date: Mon, 19 Dec 2005 13:48:37 -0800 Message-Id: <1135028917.75547.4.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2 FreeBSD GNOME Team Port Subject: Re: DRM update for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2005 21:48:42 -0000 --=-JkTphaSq8/4oG5S7+GWH Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-12-19 at 22:17 +0100, Oliver Fromme wrote: > Freddie Cash wrote: > > Running glxgears at 1024x768x16 gives me a decent 35 fps, compared to = the=20 > > 1 fps I used to get. :) >=20 > Uhm. Are you sure that you're running hardware-accelerated > OpenGL glxgears? >=20 > I get 48 fps at 1400x1050x32 -- in software, without any > hardware 3D acceleration. (It's a 1.6GHz Centrino notebook > with shared i915 graphics. 2D acceleration is enabled, of > course.) glxgears is not a benchmark. --=20 Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org --=-JkTphaSq8/4oG5S7+GWH Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDpyq1HUdvYGzw6vcRArmNAKCWIU+TbiAaz/1r1NQkq1l6PIG4hgCcCnS+ qgEMz9rCVgZ3GlMcbmZY2zI= =2bQR -----END PGP SIGNATURE----- --=-JkTphaSq8/4oG5S7+GWH-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 21:55:58 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07BAF16A41F; Mon, 19 Dec 2005 21:55:58 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: from mail.dt.e-technik.uni-dortmund.de (krusty.dt.E-Technik.uni-dortmund.de [129.217.163.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23A5043D46; Mon, 19 Dec 2005 21:55:56 +0000 (GMT) (envelope-from matthias.andree@gmx.de) Received: from localhost (localhost [127.0.0.1]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id D122344129; Mon, 19 Dec 2005 22:55:55 +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 ESMTP id 01976-10; Mon, 19 Dec 2005 22:55:54 +0100 (CET) Received: from m2a2.dyndns.org (p5091366B.dip0.t-ipconnect.de [80.145.54.107]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 086A0440A8; Mon, 19 Dec 2005 22:55:53 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by merlin.emma.line.org (Postfix) with ESMTP id 538E7201F1F; Mon, 19 Dec 2005 22:55:53 +0100 (CET) Received: from m2a2.dyndns.org ([127.0.0.1]) by localhost (m2a2.dyndns.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06378-10; Mon, 19 Dec 2005 22:55:51 +0100 (CET) Received: by merlin.emma.line.org (Postfix, from userid 500) id 4717B201F20; Mon, 19 Dec 2005 22:55:51 +0100 (CET) Date: Mon, 19 Dec 2005 22:55:51 +0100 From: Matthias Andree To: "Cai, Quanqing" Message-ID: <20051219215551.GA7362@merlin.emma.line.org> Mail-Followup-To: "Cai, Quanqing" , freebsd-current@freebsd.org, freebsd-fs@freebsd.org References: <20051213151908.GA26821@crodrigues.org> <20051216151228.GA34670@crodrigues.org> <20051217141647.GC27992@merlin.emma.line.org> <2b22951e0512172355k36a579f4i42dd72562a3530ed@mail.gmail.com> <20051218092523.GA4694@merlin.emma.line.org> <2b22951e0512191348t227c9354i36d6a4a87e7d5698@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2b22951e0512191348t227c9354i36d6a4a87e7d5698@mail.gmail.com> X-PGP-Key: http://home.pages.de/~mandree/keys/GPGKEY.asc User-Agent: Mutt/1.5.11 X-Virus-Scanned: amavisd-new at dt.e-technik.uni-dortmund.de Cc: freebsd-fs@freebsd.org, Matthias Andree , freebsd-current@freebsd.org Subject: Re: XFS (read-only) support committed to CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2005 21:55:58 -0000 On Mon, 19 Dec 2005, Cai, Quanqing wrote: > No, I don't have time to deal with SuSE regarding failure, the company > I am working for is growing so fast, need to add dozens of servers > every month. After switch to XFS, I seldom get problems, even if I got > problem, I can quickly reboot nfs server because it is using XFS. Well, you can switch off the routine full checks of ext3fs with tune2fs, should that matter for remaining ext3 file systems.s Without that full check every few weeks, you only have journal recovery, and that is pretty fast. The journal can be offloaded on a separate drive if desired. On the downside, ext3fs and write caches don't mix well, unless you have battery backup units sitting on your RAID controllers (I do, and switching this MegaRAID - RAID5 on 2+1 - to writeback mode improved write speed by a factor of 5 - no database loads though). > > OTOH, it's "only" one Xeon NFS server with 1 70 GB RAID5 and 1 292 GB > > RAID5 (MegaRAID SCSI 320-1 with BBU) with half a dozen users at any one > > time. > > Oh, you don't put much load on it. I am using nfs server as storage > server of internet application, so they get very high IO load. Yup. And personally, if I'd have any stakes in NFS load, I'd probably consider Solaris instead. Linux and NFS is pretty flakey for some, and some people claim only 2.6.11.11 were really stable, I always see tons of fixes for NFS :-/. Myself, I have little NFS troubles with SUSE 9.2 and 10.0, but things used to be worse. > Anyway, I am not tend to start a flame war between ext3 and XFS, I > choose ext3 for our MySQL server because MySQL.com suggest me that, > they said ext3 has better performance. Sorry, this is out of topic:( I'm taking this offline. MySQL is an area I don't know well, whenever I've wanted SQL, I've used SQLite3 or PostgreSQL, so I cannot comment on that. -- Matthias Andree From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 22:19:11 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3465A16A420; Mon, 19 Dec 2005 22:19:11 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: from lira.ugcs.caltech.edu (lira.ugcs.caltech.edu [131.215.176.118]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6361C43D64; Mon, 19 Dec 2005 22:19:10 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by lira.ugcs.caltech.edu (Postfix, from userid 3640) id 203416B002; Mon, 19 Dec 2005 14:19:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by lira.ugcs.caltech.edu (Postfix) with ESMTP id C27525300A; Mon, 19 Dec 2005 14:19:08 -0800 (PST) Date: Mon, 19 Dec 2005 14:19:08 -0800 (PST) From: Jon Dama To: Matthias Andree In-Reply-To: <20051219215551.GA7362@merlin.emma.line.org> Message-ID: References: <20051213151908.GA26821@crodrigues.org> <20051216151228.GA34670@crodrigues.org> <20051217141647.GC27992@merlin.emma.line.org> <2b22951e0512172355k36a579f4i42dd72562a3530ed@mail.gmail.com> <20051218092523.GA4694@merlin.emma.line.org> <2b22951e0512191348t227c9354i36d6a4a87e7d5698@mail.gmail.com> <20051219215551.GA7362@merlin.emma.line.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-fs@freebsd.org, "Cai, Quanqing" , freebsd-current@freebsd.org Subject: Re: XFS (read-only) support committed to CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2005 22:19:11 -0000 > On the downside, ext3fs and write caches don't mix well, unless you have > battery backup units sitting on your RAID controllers (I do, and > switching this MegaRAID - RAID5 on 2+1 - to writeback mode improved > write speed by a factor of 5 - no database loads though). This an issue that Kirk has been looking into. Ideally the problem will go away completely when both request barriers and NCQ are implemented. (The latter for people with high-end SATA drives and the former for the rest of the consumers of ATA). -Jon From owner-freebsd-current@FreeBSD.ORG Mon Dec 19 23:13:54 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0029516A424 for ; Mon, 19 Dec 2005 23:13:53 +0000 (GMT) (envelope-from fcash@ocis.net) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8852D43D6A for ; Mon, 19 Dec 2005 23:13:53 +0000 (GMT) (envelope-from fcash@ocis.net) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id 2A9FE8A00AE for ; Mon, 19 Dec 2005 15:13:32 -0800 (PST) Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 03018-01-84 for ; Mon, 19 Dec 2005 15:13:30 -0800 (PST) Received: from s157.sbo (unknown [192.168.0.157]) by smtp.sd73.bc.ca (Postfix) with ESMTP id EC2A68A009C for ; Mon, 19 Dec 2005 15:13:30 -0800 (PST) From: Freddie Cash To: freebsd-current@freebsd.org Date: Mon, 19 Dec 2005 15:13:50 -0800 User-Agent: KMail/1.8.3 References: <200512192117.jBJLHE8C057230@lurza.secnetix.de> In-Reply-To: <200512192117.jBJLHE8C057230@lurza.secnetix.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512191513.51287.fcash@ocis.net> X-Virus-Scanned: by amavisd-new using ClamAV at sd73.bc.ca Subject: Re: DRM update for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2005 23:13:54 -0000 On December 19, 2005 01:17 pm, Oliver Fromme wrote: > Freddie Cash wrote: > > Running glxgears at 1024x768x16 gives me a decent 35 fps, compared > > to the 1 fps I used to get. :) > Uhm. Are you sure that you're running hardware-accelerated > OpenGL glxgears? > I get 48 fps at 1400x1050x32 -- in software, without any > hardware 3D acceleration. (It's a 1.6GHz Centrino notebook > with shared i915 graphics. 2D acceleration is enabled, of > course.) Yep. It's a bog-slow laptop (2.8 GHz Celeron CPU, 1 GB RAM, 40 GB HD running at ATA33 instead of ATA100, Radeon 7000 GPU). It may be a 2.8 GHz CPU, but it runs like a a 1 GHz, even in Debian Linux. Without DRM/DRI enabled in X, glxgears give single-digit framerates. With DRM/DRI enabled in X, glxgears gives double-digit to triple-digit framerates (depending on window size). The glxgears info also shows the hardware accel enabled and disabled correctly. Running Debian Linux unstable on the same laptop showed slightly better framerates in glxgears (~50 fps fullscreen vs. ~30 in FreeBSD), but the harddrive was also running at ATA100 (not that that should affect glxgears all that much). -- Freddie Cash fcash@ocis.net From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 00:06:06 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7480B16A420 for ; Tue, 20 Dec 2005 00:06:06 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from nic.ach.sch.gr (nic.sch.gr [194.63.238.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44F6043D68 for ; Tue, 20 Dec 2005 00:06:04 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: (qmail 14000 invoked by uid 207); 20 Dec 2005 00:06:02 -0000 Received: from keramida@ceid.upatras.gr by nic by uid 201 with qmail-scanner-1.21 (sophie: 3.04/2.30/3.97. Clear:RC:1(81.186.70.136):. Processed in 0.101074 secs); 20 Dec 2005 00:06:02 -0000 Received: from dialup136.ach.sch.gr (HELO flame.pc) ([81.186.70.136]) (envelope-sender ) by nic.sch.gr (qmail-ldap-1.03) with SMTP for ; 20 Dec 2005 00:06:01 -0000 Received: by flame.pc (Postfix, from userid 1001) id 9970711885; Tue, 20 Dec 2005 02:04:58 +0200 (EET) Date: Tue, 20 Dec 2005 02:04:58 +0200 From: Giorgos Keramidas To: Justin Smith Message-ID: <20051220000458.GA2743@flame.pc> References: <43A6D190.3020504@drexel.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A6D190.3020504@drexel.edu> Cc: freebsd-current@freebsd.org Subject: Re: "Native" journaling file systems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 00:06:06 -0000 On 2005-12-19 10:28, Justin Smith wrote: > Are there any plans to develop UFS3--- i.e., a UFS2 file system with an > added journal? Not sure. > I've used several journaling file systems in Linux and like the Reiser > FS except for one MAJOR drawback: When something goes wrong, reiser-fsck > absolutely sucks at repairing things (Hans Reiser freely admits that but > says it's never needed because nothing ever goes wrong). Which is, FYI, absolutely and plainly bullshit. I've seen Linux machines with Reiserfs die and cause major pains for dozens of people. Hans may be a smart guy and a very successful businessman, but this particular statement is utter nonsense and I have the scars to prove it. > A UFS3 might have the same desirable features. I can't help with the answer to this :) From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 00:07:02 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A5B7216A41F; Tue, 20 Dec 2005 00:07:01 +0000 (GMT) (envelope-from davidxu@freebsd.org) Message-ID: <43A74B52.1090104@freebsd.org> Date: Tue, 20 Dec 2005 08:07:46 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.10) Gecko/20050806 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthias Andree References: <43A6D190.3020504@drexel.edu> <43A6D40A.70305@centtech.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Justin Smith , freebsd-current@freebsd.org, Eric Anderson Subject: Re: "Native" journaling file systems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 00:07:02 -0000 Matthias Andree wrote: >What has become of lfs by the way? > > > I am curious why nobody picks up the BSD lfs ? the UFS background fsck sucks us too bad, sigh. David Xu From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 00:19:47 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07A4716A41F for ; Tue, 20 Dec 2005 00:19:47 +0000 (GMT) (envelope-from petre@kgb.ro) Received: from xyz.rdsbv.ro (xyz.rdsbv.ro [193.231.237.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 075FE43D78 for ; Tue, 20 Dec 2005 00:19:41 +0000 (GMT) (envelope-from petre@kgb.ro) Received: from mail.kgb.ro (localhost [127.0.0.1]) by xyz.rdsbv.ro (Postfix) with ESMTP id CD41F7D79 for ; Tue, 20 Dec 2005 02:19:38 +0200 (EET) Received: from 193.231.237.171 (SquirrelMail authenticated user petre@kgb.ro) by dummy-host.example.com with HTTP; Tue, 20 Dec 2005 02:19:38 +0200 (EET) Message-ID: <1263.193.231.237.171.1135037978.squirrel@dummy-host.example.com> Date: Tue, 20 Dec 2005 02:19:38 +0200 (EET) From: petre@kgb.ro To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.4-rc1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: Re: "Native" journaling file systems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 00:19:47 -0000 >On 2005-12-19 10:28, Justin Smith wrote: > Are there any plans to develop UFS3--- i.e., a UFS2 file system with an > added journal? >Not sure. > I've used several journaling file systems in Linux and like the Reiser > FS except for one MAJOR drawback: When something goes wrong, reiser-fsck > absolutely sucks at repairing things (Hans Reiser freely admits that but > says it's never needed because nothing ever goes wrong). hmmm, reiserfsck --rebuild-tree solved my problems twice; or was it pure luck ? ;) >Which is, FYI, absolutely and plainly bullshit. I've seen Linux machines >with Reiserfs die and cause major pains for dozens of people. Hans may be >a smart guy and a very successful businessman, but this particular >statement is utter nonsense and I have the scars to prove it. > A UFS3 might have the same desirable features. >I can't help with the answer to this :) _______________________________________________ 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 Dec 20 00:32:15 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37C2716A41F for ; Tue, 20 Dec 2005 00:32:15 +0000 (GMT) (envelope-from allbery@ece.cmu.edu) Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id D136843D5C for ; Tue, 20 Dec 2005 00:32:14 +0000 (GMT) (envelope-from allbery@ece.cmu.edu) Received: from [10.9.204.128] (dsl093-061-215.pit1.dsl.speakeasy.net [66.93.61.215]) by bache.ece.cmu.edu (Postfix) with ESMTP id D273E9A; Mon, 19 Dec 2005 19:32:13 -0500 (EST) In-Reply-To: <1263.193.231.237.171.1135037978.squirrel@dummy-host.example.com> References: <1263.193.231.237.171.1135037978.squirrel@dummy-host.example.com> Mime-Version: 1.0 (Apple Message framework v746.2) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Brandon S. Allbery KF8NH" Date: Mon, 19 Dec 2005 19:32:11 -0500 To: petre@kgb.ro X-Mailer: Apple Mail (2.746.2) Cc: freebsd-current@freebsd.org Subject: Re: "Native" journaling file systems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 00:32:15 -0000 On Dec 19, 2005, at 7:19 , petre@kgb.ro wrote: >> On 2005-12-19 10:28, Justin Smith wrote: >> I've used several journaling file systems in Linux and like the >> Reiser >> FS except for one MAJOR drawback: When something goes wrong, >> reiser-fsck >> absolutely sucks at repairing things (Hans Reiser freely admits >> that but >> says it's never needed because nothing ever goes wrong). > > hmmm, reiserfsck --rebuild-tree solved my problems twice; or was it > pure > luck ? ;) There are versions of reiserfs that are fairly stable (many of them in SuSE Linux releases, with a boatload of patches to make them stable) --- but I don't like what I've been hearing and seeing with the new version, and we've scrapped it in our production Linux environment in favor of ext3 (temporarily) and xfs (in progress). (No production FreeBSD: we absolutely *need* AFS clients, and none of us is enough of a kernel-level hacker to make OpenAFS or Arla sufficiently stable. *grumble*) -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 02:21:08 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E565216A41F for ; Tue, 20 Dec 2005 02:21:08 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 429D343D58 for ; Tue, 20 Dec 2005 02:21:08 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 58F075CA3; Mon, 19 Dec 2005 21:21:05 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35376-06; Mon, 19 Dec 2005 21:21:04 -0500 (EST) Received: from [192.168.1.3] (pool-68-161-122-227.ny325.east.verizon.net [68.161.122.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 4EA675C43; Mon, 19 Dec 2005 21:21:04 -0500 (EST) Message-ID: <43A76A95.2070402@mac.com> Date: Mon, 19 Dec 2005 21:21:09 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Brandon S. Allbery KF8NH" References: <1263.193.231.237.171.1135037978.squirrel@dummy-host.example.com> In-Reply-To: X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-current@freebsd.org, petre@kgb.ro Subject: Re: "Native" journaling file systems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 02:21:09 -0000 Brandon S. Allbery KF8NH wrote: [ ... ] > (No production FreeBSD: we absolutely *need* AFS clients, and none of > us is enough of a kernel-level hacker to make OpenAFS or Arla > sufficiently stable. *grumble*) You ought to be able to NFS-export an AFS volume mounted on a Sun box to FreeBSD clients. That worked fine at CMU, anyway, but there were plenty of people with significant AFS-mojo available there, too. -- -Chuck From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 03:14:23 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5995D16A41F for ; Tue, 20 Dec 2005 03:14:23 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E567643D68 for ; Tue, 20 Dec 2005 03:14:22 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id jBK3EEDO018765; Mon, 19 Dec 2005 22:14:15 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <43A76A95.2070402@mac.com> References: <1263.193.231.237.171.1135037978.squirrel@dummy-host.example.com> <43A76A95.2070402@mac.com> Date: Mon, 19 Dec 2005 22:14:13 -0500 To: Chuck Swiger , "Brandon S. Allbery KF8NH" From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.4 Cc: freebsd-current@freebsd.org, petre@kgb.ro Subject: Re: "Native" journaling file systems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 03:14:23 -0000 At 9:21 PM -0500 12/19/05, Chuck Swiger wrote: >Brandon S. Allbery KF8NH wrote: >[ ... ] >>(No production FreeBSD: we absolutely *need* AFS clients, and >>none of us is enough of a kernel-level hacker to make OpenAFS >>or Arla sufficiently stable. *grumble*) > >You ought to be able to NFS-export an AFS volume mounted on a Sun >box to FreeBSD clients. That worked fine at CMU, anyway, but >there were plenty of people with significant AFS-mojo available >there, too. Ugh. We did NFS-exporting of AFS volumes early on, and it caused us no end of headaches. We were very glad to abandon that setup, and stick with native AFS clients. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 03:16:52 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2F0016A41F for ; Tue, 20 Dec 2005 03:16:52 +0000 (GMT) (envelope-from allbery@ece.cmu.edu) Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 304EE43D69 for ; Tue, 20 Dec 2005 03:16:52 +0000 (GMT) (envelope-from allbery@ece.cmu.edu) Received: from [10.9.204.128] (dsl093-061-215.pit1.dsl.speakeasy.net [66.93.61.215]) by bache.ece.cmu.edu (Postfix) with ESMTP id 30ABC88; Mon, 19 Dec 2005 22:16:47 -0500 (EST) In-Reply-To: References: <1263.193.231.237.171.1135037978.squirrel@dummy-host.example.com> <43A76A95.2070402@mac.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8A3BB8D9-9270-4265-89CD-BBFB3154FA93@ece.cmu.edu> Content-Transfer-Encoding: 7bit From: "Brandon S. Allbery KF8NH" Date: Mon, 19 Dec 2005 22:16:43 -0500 To: Garance A Drosihn X-Mailer: Apple Mail (2.746.2) Cc: freebsd-current@freebsd.org Subject: Re: "Native" journaling file systems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 03:16:52 -0000 On Dec 19, 2005, at 10:14 , Garance A Drosihn wrote: > At 9:21 PM -0500 12/19/05, Chuck Swiger wrote: >> Brandon S. Allbery KF8NH wrote: >> [ ... ] >>> (No production FreeBSD: we absolutely *need* AFS clients, and >>> none of us is enough of a kernel-level hacker to make OpenAFS >>> or Arla sufficiently stable. *grumble*) >> >> You ought to be able to NFS-export an AFS volume mounted on a Sun >> box to FreeBSD clients. That worked fine at CMU, anyway, but >> there were plenty of people with significant AFS-mojo available >> there, too. > > Ugh. We did NFS-exporting of AFS volumes early on, and it caused > us no end of headaches. We were very glad to abandon that setup, > and stick with native AFS clients. Yeh, I've used tha AFS-NFS translator and knfs to bootstrap new systypes. Not about to do that for general use. -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 04:26:21 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E35816A41F for ; Tue, 20 Dec 2005 04:26:21 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86A1A43D49 for ; Tue, 20 Dec 2005 04:26:20 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 4177561 for multiple; Mon, 19 Dec 2005 23:24:26 -0500 Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id jBK4QGxU002230; Mon, 19 Dec 2005 23:26:16 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 19 Dec 2005 23:24:16 -0500 User-Agent: KMail/1.8.3 References: <200512192117.jBJLHE8C057230@lurza.secnetix.de> <200512191513.51287.fcash@ocis.net> In-Reply-To: <200512191513.51287.fcash@ocis.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200512192324.17294.jhb@freebsd.org> X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Freddie Cash Subject: Re: DRM update for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2005 04:26:21 -0000 On Monday 19 December 2005 06:13 pm, Freddie Cash wrote: > On December 19, 2005 01:17 pm, Oliver Fromme wrote: > > Freddie Cash wrote: > > > Running glxgears at 1024x768x16 gives me a decent 35 fps, compared > > > to the 1 fps I used to get. :) > > > > Uhm. Are you sure that you're running hardware-accelerated > > OpenGL glxgears? > > > > I get 48 fps at 1400x1050x32 -- in software, without any > > hardware 3D acceleration. (It's a 1.6GHz Centrino notebook > > with shared i915 graphics. 2D acceleration is enabled, of > > course.) > > Yep. It's a bog-slow laptop (2.8 GHz Celeron CPU, 1 GB RAM, 40 GB HD > running at ATA33 instead of ATA100, Radeon 7000 GPU). It may be a 2.8 > GHz CPU, but it runs like a a 1 GHz, even in Debian Linux. > > Without DRM/DRI enabled in X, glxgears give single-digit framerates. With > DRM/DRI enabled in X, glxgears gives double-digit to triple-digit > framerates (depending on window size). The glxgears info also shows the > hardware accel enabled and disabled correctly. > > Running Debian Linux unstable on the same laptop showed slightly better > framerates in glxgears (~50 fps fullscreen vs. ~30 in FreeBSD), but the > harddrive was also running at ATA100 (not that that should affect > glxgears all that much). These numbers all sound weird to me. I get 300 fps on an ancient Matrox G2= 00=20 on a system with a 700Mhz Athlon. At work we typically get around 1600 fps= =20 in glxgears with Radeon 8500's on systems with 865 chipsets and 2.4 - 2.8 g= hz=20 P4s. Sub-100 fps for glxgears seems slow even for software rendering. =2D-=20 John Baldwin =C2=A0<>< =C2=A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =C2=A0=3D =C2=A0http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 04:57:23 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07C3E16A41F; Tue, 20 Dec 2005 04:57:23 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from mail.localelinks.com (web.localelinks.com [64.39.75.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D5B743D55; Tue, 20 Dec 2005 04:57:21 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-157-22-236.jan.bellsouth.net [70.157.22.236]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.localelinks.com (Postfix) with ESMTP id 70346AD; Mon, 19 Dec 2005 22:57:21 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 7B6AE61C28; Mon, 19 Dec 2005 22:57:20 -0600 (CST) Date: Mon, 19 Dec 2005 22:57:20 -0600 From: "Matthew D. Fuller" To: John Baldwin Message-ID: <20051220045720.GT63497@over-yonder.net> References: <200512192117.jBJLHE8C057230@lurza.secnetix.de> <200512191513.51287.fcash@ocis.net> <200512192324.17294.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200512192324.17294.jhb@freebsd.org> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.2 Cc: freebsd-current@freebsd.org, Freddie Cash Subject: Re: DRM update for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2005 04:57:23 -0000 On Mon, Dec 19, 2005 at 11:24:16PM -0500 I heard the voice of John Baldwin, and lo! it spake thus: > > These numbers all sound weird to me. I get 300 fps on an ancient > Matrox G200 on a system with a 700Mhz Athlon. At work we typically > get around 1600 fps in glxgears with Radeon 8500's on systems with > 865 chipsets and 2.4 - 2.8 ghz P4s. Sub-100 fps for glxgears seems > slow even for software rendering. I get 45-50 in the default window size on my PPro (Millennium II card, so definitely software rendering). I can eek out 5 on a good day if I expand it out to the full 1280x1024. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 05:10:55 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D99DA16A41F; Tue, 20 Dec 2005 05:10:55 +0000 (GMT) (envelope-from huang@gddsn.org.cn) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68A5943D5C; Tue, 20 Dec 2005 05:10:55 +0000 (GMT) (envelope-from huang@gddsn.org.cn) Received: from [192.168.1.5] (unknown [218.19.185.114]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gddsn.org.cn (Postfix) with ESMTP id 76EBD38CB41; Tue, 20 Dec 2005 13:10:53 +0800 (CST) Message-ID: <43A7925A.4050504@gddsn.org.cn> Date: Tue, 20 Dec 2005 13:10:50 +0800 From: Huang wen hui User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051212) X-Accept-Language: zh-cn,zh MIME-Version: 1.0 To: current@freebsd.org References: <20051219173854.GC41381@FreeBSD.org> <20051220.100100.110014772.garrigue@math.nagoya-u.ac.jp> In-Reply-To: <20051220.100100.110014772.garrigue@math.nagoya-u.ac.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: glebius@freebsd.org Subject: Re: em suspend hack to test X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 05:10:56 -0000 Jacques Garrigue wrote: >From: Gleb Smirnoff > > > >> here is a hack to test whether it fixes suspend on your laptop >>or not? Please test it. Thanks in advance. >> >> > >I applied it to the vanilla if_em.c from 6.0-RELEASE, built, installed >and loaded if_em.ko, and it looks like it did the trick for me. > > works on CURRENT also. thanks! > > >Thanks! > >Jacques > > From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 06:12:36 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0349F16A41F; Tue, 20 Dec 2005 06:12:36 +0000 (GMT) (envelope-from ai@bmc.brk.ru) Received: from stalker.bmc.brk.ru (stalker.bmc.brk.ru [217.150.59.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEA5E43D49; Tue, 20 Dec 2005 06:12:34 +0000 (GMT) (envelope-from ai@bmc.brk.ru) Date: Tue, 20 Dec 2005 09:12:27 +0300 From: Artemiev Igor To: freebsd-current@freebsd.org Message-Id: <20051220091227.4ce7dfa2.ai@bmc.brk.ru> In-Reply-To: <20051218173028.GV41326@ip.net.ua> References: <20051218173028.GV41326@ip.net.ua> Organization: Bryansk Medical Center X-Mailer: Sylpheed version 2.0.0beta4 (GTK+ 2.6.8; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Re: New nfpm.c driver available for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2005 06:12:36 -0000 I've recompiled your nfm with CFLAGS+=-DDEBUG. ai@home$sudo ./smbtest /dev/smb0 found slave device 8 found slave device 80 found slave device 82 ai@home$sudo ./smbtest /dev/smb1 found slave device 8 found slave device 45 found slave device 55 found slave device 72 found slave device 73 found slave device 97 found slave device 127 smbtest gives me only a garbage. When I tried mbmon without - DSMBUS_IOCTL, it worked with SMBus through the /dev/io and "detected" slave address for the first smb controller as 0x5a Then I've run mbmon -A -d. It didn't find any sensors, but here is the driver's debug message: Dec 19 22:17:57 home kernel: nfpm: STS=0x10 Dec 19 22:17:57 home kernel: nfpm: READB from 0x10, cmd=0x40, byte=0x0, error=0x 4 Dec 19 22:17:57 home kernel: nfpm: STS=0x10 Dec 19 22:17:57 home kernel: nfpm: READB from 0x10, cmd=0x48, byte=0x0, error=0x 4 Dec 19 22:17:57 home kernel: nfpm: STS=0x10 Dec 19 22:17:57 home kernel: nfpm: READB from 0x12, cmd=0x0, byte=0x0, error=0x4 Dec 19 22:17:58 home kernel: nfpm: STS=0x10 Dec 19 22:17:58 home kernel: nfpm: READB from 0x12, cmd=0x1, byte=0x0, error=0x4 Dec 19 22:17:58 home kernel: nfpm: STS=0x10 Dec 19 22:17:58 home kernel: nfpm: READB from 0x12, cmd=0x20, byte=0x0, error=0x 4 Dec 19 22:17:58 home kernel: nfpm: STS=0x10 Dec 19 22:17:58 home kernel: nfpm: READB from 0x12, cmd=0x40, byte=0x0, error=0x 4 Dec 19 22:17:58 home kernel: nfpm: STS=0x10 Dec 19 22:17:58 home kernel: nfpm: READB from 0x12, cmd=0x48, byte=0x0, error=0x 4 Dec 19 22:17:58 home kernel: nfpm: STS=0x10 Dec 19 22:17:58 home kernel: nfpm: READB from 0x14, cmd=0x0, byte=0x0, error=0x4 Dec 19 22:17:58 home kernel: nfpm: STS=0x10 Dec 19 22:17:58 home kernel: nfpm: READB from 0x14, cmd=0x1, byte=0x0, error=0x4 Dec 19 22:17:59 home kernel: nfpm: STS=0x10 Dec 19 22:17:59 home kernel: nfpm: READB from 0x14, cmd=0x20, byte=0x0, error=0x4 Dec 19 22:17:59 home kernel: nfpm: STS=0x10 Dec 19 22:17:59 home kernel: nfpm: READB from 0x14, cmd=0x40, byte=0x0, error=0x4 Well, It's a "Device Address Not Acknowledged" error. If I shift the slave address for reading, it works, and status register contains 0x80. Yet, for writing I still have an 0x10. The documentation for AMD-8111 controller explains this by not-reset operational status before the controller checks the address. Btw, why in nfpm_wait you're polling SMB_PRTCL instead of SMB_STS? Here is pciconf -vl and devinfo -rv after kldload nfpm: agp0@pci0:0:0: class=0x060000 card=0x80ac1043 chip=0x01e010de rev=0xc1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce2 AGP Controller' class = bridge subclass = HOST-PCI none0@pci0:0:1: class=0x050000 card=0x80ac1043 chip=0x01eb10de rev=0xc1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce2 Memory Controller 1' class = memory subclass = RAM none1@pci0:0:2: class=0x050000 card=0x80ac1043 chip=0x01ee10de rev=0xc1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce2 Memory Controller 4' class = memory subclass = RAM none2@pci0:0:3: class=0x050000 card=0x80ac1043 chip=0x01ed10de rev=0xc1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce2 Memory Controller 3' class = memory subclass = RAM none3@pci0:0:4: class=0x050000 card=0x80ac1043 chip=0x01ec10de rev=0xc1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce2 Memory Controller 2' class = memory subclass = RAM none4@pci0:0:5: class=0x050000 card=0x80ac1043 chip=0x01ef10de rev=0xc1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce2 Memory Controller 5' class = memory subclass = RAM isab0@pci0:1:0: class=0x060100 card=0x80ad1043 chip=0x006010de rev=0xa4 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP2 ISA Bridge' class = bridge subclass = PCI-ISA nfpm0@pci0:1:1: class=0x0c0500 card=0x0c111043 chip=0x006410de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP-T? SMBus Controller' class = serial bus subclass = SMBus ohci0@pci0:2:0: class=0x0c0310 card=0x0c111043 chip=0x006710de rev=0xa4 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP2 OpenHCI USB Controller' class = serial bus subclass = USB ohci1@pci0:2:1: class=0x0c0310 card=0x0c111043 chip=0x006710de rev=0xa4 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP2 OpenHCI USB Controller' class = serial bus subclass = USB ehci0@pci0:2:2: class=0x0c0320 card=0x0c111043 chip=0x006810de rev=0xa4 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP2 EHCI USB 2.0 Controller' class = serial bus subclass = USB nve0@pci0:4:0: class=0x020000 card=0x80a71043 chip=0x006610de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP-T Networking Adapter' class = network subclass = ethernet none5@pci0:5:0: class=0x040100 card=0x0c111043 chip=0x006b10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP-T? Audio Processing Unit (Dolby Digital)' class = multimedia subclass = audio pcm0@pci0:6:0: class=0x040100 card=0x80951043 chip=0x006a10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP-T Audio Codec Interface' class = multimedia subclass = audio pcib1@pci0:8:0: class=0x060400 card=0x00000000 chip=0x006c10de rev=0xa3 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'nForce MCP-T CPU to PCI Bridge' class = bridge subclass = PCI-PCI atapci1@pci0:9:0: class=0x01018a card=0x0c111043 chip=0x006510de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP2 EIDE Controller' class = mass storage subclass = ATA fwohci0@pci0:13:0: class=0x0c0010 card=0x809a1043 chip=0x006e10de rev=0xa3 hdr=0x00 vendor = 'NVIDIA Corporation' device = 'nForce MCP2 OHCI Compliant IEEE 1394 Controller' class = serial bus subclass = FireWire pcib2@pci0:30:0: class=0x060400 card=0x00000000 chip=0x01e810de rev=0xc1 hdr=0x01 vendor = 'NVIDIA Corporation' device = 'nForce2 AGP Host to PCI Bridge' class = bridge subclass = PCI-PCI skc0@pci1:4:0: class=0x020000 card=0x811a1043 chip=0x432011ab rev=0x13 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '88E8001/8003/8010 Gigabit Ethernet Controller with Integrated PHY (copper)' class = network subclass = ethernet atapci0@pci1:11:0: class=0x010400 card=0x61121095 chip=0x31121095 rev=0x02 hdr=0x00 vendor = 'Silicon Image Inc (Was: CMD Technology Inc)' device = 'SiI 3112 SATALink/SATARaid Controller' class = mass storage subclass = RAID drm0@pci3:0:0: class=0x030000 card=0x7c0a174b chip=0x4e481002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Radeon 9800 Pro (R350)' class = display subclass = VGA none6@pci3:0:1: class=0x038000 card=0x7c0b174b chip=0x4e681002 rev=0x00 hdr=0x00 vendor = 'ATI Technologies Inc' device = 'Radeon 9800 Pro (R350) - Secondary' class = display nexus0 legacy0 npx0 acpi0 Interrupt request lines: 0x9 I/O ports: 0x10-0x1f 0x22-0x3f 0x44-0x5f 0x62-0x63 0x65-0x6f 0x74-0x7f 0x91-0x93 0xa2-0xbf 0xe0-0xef 0x4d0-0x4d1 0x4000-0x407f 0x4080-0x40ff 0x4200-0x427f 0x4280-0x42ff 0x4400-0x447f 0x4480-0x44ff 0x5000-0x503f 0x5500-0x553f I/O memory addresses: 0x0-0x9ffff 0xd7000-0xd7fff 0xf0000-0xf7fff 0xf8000-0xfbfff 0xfc000-0xfffff 0x100000-0x1ffeffff 0x1fff0000-0x1fffffff 0xfec00000-0xfec00fff 0xfee00000-0xfee00fff 0xffff0000-0xffffffff cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0 acpi_sysresource0 pnpinfo _HID=PNP0C02 _UID=3 at handle=\_SB_.PMIO acpi_sysresource1 pnpinfo _HID=PNP0C02 _UID=4 at handle=\_SB_.SMIO acpi_button0 pnpinfo _HID=PNP0C0C _UID=0 at handle=\_SB_.PWRB acpi_sysresource2 pnpinfo _HID=PNP0C01 _UID=0 at handle=\_SB_.MEM_ pcib0 pnpinfo _HID=PNP0A03 _UID=1 at handle=\_SB_.PCI0 pci0 agp0 pnpinfo vendor=0x10de device=0x01e0 subvendor=0x1043 subdevice=0x80ac class=0x060000 at slot=0 function=0 I/O memory addresses: 0xa0000000-0xbfffffff unknown pnpinfo vendor=0x10de device=0x01eb subvendor=0x1043 subdevice=0x80ac class=0x050000 at slot=0 function=1 unknown pnpinfo vendor=0x10de device=0x01ee subvendor=0x1043 subdevice=0x80ac class=0x050000 at slot=0 function=2 unknown pnpinfo vendor=0x10de device=0x01ed subvendor=0x1043 subdevice=0x80ac class=0x050000 at slot=0 function=3 unknown pnpinfo vendor=0x10de device=0x01ec subvendor=0x1043 subdevice=0x80ac class=0x050000 at slot=0 function=4 unknown pnpinfo vendor=0x10de device=0x01ef subvendor=0x1043 subdevice=0x80ac class=0x050000 at slot=0 function=5 isab0 pnpinfo vendor=0x10de device=0x0060 subvendor=0x1043 subdevice=0x80ad class=0x060100 at slot=1 function=0 handle=\_SB_.PCI0.VT86 isa0 adv0 aha0 aic0 bt0 cs0 ed0 fe0 ie0 lnc0 sc0 sio2 sio3 sn0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa0000-0xbffff vt0 orm0 pnpinfo pnpid=ORM0000 I/O memory addresses: 0xc0000-0xccfff 0xd0000-0xd3fff 0xd4000-0xd57ff 0xd6000-0xd6fff nfpm0 pnpinfo vendor=0x10de device=0x0064 subvendor=0x1043 subdevice=0x0c11 class=0x0c0500 at slot=1 function=1 handle= \_SB_.PCI0.SMB0 I/O ports: 0x1000-0x103f 0xdc00-0xdc1f I/O ports: 0x5000-0x503f smbus0 smb0 nfpm1 smbus1 smb1 ohci0 pnpinfo vendor=0x10de device=0x0067 subvendor=0x1043 subdevice=0x0c11 class=0x0c0310 at slot=2 function=0 handle= \_SB_.PCI0.USB0 Interrupt request lines: 0xb I/O memory addresses: 0xd5087000-0xd5087fff usb0 uhub0 ohci1 pnpinfo vendor=0x10de device=0x0067 subvendor=0x1043 subdevice=0x0c11 class=0x0c0310 at slot=2 function=1 handle= \_SB_.PCI0.USB1 I/O memory addresses: 0xd5082000-0xd5082fff usb1 uhub1 ehci0 pnpinfo vendor=0x10de device=0x0068 subvendor=0x1043 subdevice=0x0c11 class=0x0c0320 at slot=2 function=2 handle= \_SB_.PCI0.USB2 Interrupt request lines: 0x5 I/O memory addresses: 0xd5083000-0xd50830ff usb2 uhub2 nve0 pnpinfo vendor=0x10de device=0x0066 subvendor=0x1043 subdevice=0x80a7 class=0x020000 at slot=4 function=0 handle= \_SB_.PCI0.MMAC I/O ports: 0xe000-0xe007 I/O memory addresses: 0xd5086000-0xd5086fff miibus0 rlphy0 pnpinfo oui=0x20 model=0x20 rev=0x1 at phyno=1 unknown pnpinfo vendor=0x10de device=0x006b subvendor=0x1043 subdevice=0x0c11 class=0x040100 at slot=5 function=0 handle= \_SB_.PCI0.MAPU I/O memory addresses: 0xd5000000-0xd507ffff pcm0 pnpinfo vendor=0x10de device=0x006a subvendor=0x1043 subdevice=0x8095 class=0x040100 at slot=6 function=0 handle= \_SB_.PCI0.MACI I/O ports: 0xd000-0xd07f 0xe400-0xe4ff I/O memory addresses: 0xd5080000-0xd5080fff pcib1 pnpinfo vendor=0x10de device=0x006c subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=8 function=0 handle= \_SB_.PCI0.HUB0 pci1 skc0 pnpinfo vendor=0x11ab device=0x4320 subvendor=0x1043 subdevice=0x811a class=0x020000 at slot=4 function=0 I/ O ports: 0x9000-0x90ff I/O memory addresses: 0xd4000000-0xd4003fff sk0 miibus1 e1000phy0 pnpinfo oui=0x5043 model=0x2 rev=0x5 at phyno=0 atapci0 pnpinfo vendor=0x1095 device=0x3112 subvendor=0x1095 subdevice=0x6112 class=0x010400 at slot=11 function=0 I/O ports: 0x9400-0x9407 0x9800-0x9803 0x9c00-0x9c07 0xa000-0xa003 0xa400-0xa40f I/O memory addresses: 0xd4004000-0xd40041ff ata2 atapicam2 ata3 atapicam3 atapci1 pnpinfo vendor=0x10de device=0x0065 subvendor=0x1043 subdevice=0x0c11 class=0x01018a at slot=9 function=0 handle= \_SB_.PCI0.IDE0 I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0xf000-0xf00f ata0 Interrupt request lines: 0xe ad0 subdisk0 atapicam0 ata1 Interrupt request lines: 0xf acd0 atapicam1 fwohci0 pnpinfo vendor=0x10de device=0x006e subvendor=0x1043 subdevice=0x809a class=0x0c0010 at slot=13 function=0 handle= \_SB_.PCI0.F139 I/O memory addresses: 0xd5084000-0xd50847ff 0xd5085000-0xd508503f firewire0 pcib2 pnpinfo vendor=0x10de device=0x01e8 subvendor=0x0000 subdevice=0x0000 class=0x060400 at slot=30 function=0 handle= \_SB_.PCI0.AGPB pci3 drm0 pnpinfo vendor=0x1002 device=0x4e48 subvendor=0x174b subdevice=0x7c0a class=0x030000 at slot=0 function=0 handle=\_SB_.PCI0.AGPB.VGAG I/O ports: 0xc000-0xc0ff I/O memory addresses: 0xc0000000-0xc7ffffff 0xd2000000-0xd200ffff unknown pnpinfo vendor=0x1002 device=0x4e68 subvendor=0x174b subdevice=0x7c0b class=0x038000 at slot=0 function=1 I/ O memory addresses: 0xc8000000-0xcfffffff 0xd2010000-0xd201ffff unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.PRI0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.PRI0.MAST unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.PRI0.SLAV unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.SEC0 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.SEC0.MAST unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.IDE0.SEC0.SLAV unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.HUB1 unknown pnpinfo _HID=none _UID=0 at handle=\_SB_.PCI0.MMCI pci_link0 pnpinfo _HID=PNP0C0F _UID=1 at handle=\_SB_.PCI0.LNK1 pci_link1 pnpinfo _HID=PNP0C0F _UID=2 at handle=\_SB_.PCI0.LNK2 pci_link2 pnpinfo _HID=PNP0C0F _UID=3 at handle=\_SB_.PCI0.LNK3 pci_link3 pnpinfo _HID=PNP0C0F _UID=4 at handle=\_SB_.PCI0.LNK4 pci_link4 pnpinfo _HID=PNP0C0F _UID=5 at handle=\_SB_.PCI0.LNK5 pci_link5 pnpinfo _HID=PNP0C0F _UID=6 at handle=\_SB_.PCI0.LUBA pci_link6 pnpinfo _HID=PNP0C0F _UID=7 at handle=\_SB_.PCI0.LUBB pci_link7 pnpinfo _HID=PNP0C0F _UID=8 at handle=\_SB_.PCI0.LMAC pci_link8 pnpinfo _HID=PNP0C0F _UID=9 at handle=\_SB_.PCI0.LAPU pci_link9 pnpinfo _HID=PNP0C0F _UID=10 at handle=\_SB_.PCI0.LACI pci_link10 pnpinfo _HID=PNP0C0F _UID=11 at handle=\_SB_.PCI0.LMCI pci_link11 pnpinfo _HID=PNP0C0F _UID=12 at handle=\_SB_.PCI0.LSMB pci_link12 pnpinfo _HID=PNP0C0F _UID=13 at handle=\_SB_.PCI0.LUB2 pci_link13 pnpinfo _HID=PNP0C0F _UID=14 at handle=\_SB_.PCI0.LFIR pci_link14 pnpinfo _HID=PNP0C0F _UID=15 at handle=\_SB_.PCI0.L3CM pci_link15 pnpinfo _HID=PNP0C0F _UID=16 at handle=\_SB_.PCI0.LIDE pci_link16 pnpinfo _HID=PNP0C0F _UID=11 at handle=\_SB_.PCI0.APC1 pci_link17 pnpinfo _HID=PNP0C0F _UID=12 at handle=\_SB_.PCI0.APC2 pci_link18 pnpinfo _HID=PNP0C0F _UID=13 at handle=\_SB_.PCI0.APC3 pci_link19 pnpinfo _HID=PNP0C0F _UID=14 at handle=\_SB_.PCI0.APC4 pci_link20 pnpinfo _HID=PNP0C0F _UID=15 at handle=\_SB_.PCI0.APC5 pci_link21 pnpinfo _HID=PNP0C0F _UID=16 at handle=\_SB_.PCI0.APCF pci_link22 pnpinfo _HID=PNP0C0F _UID=17 at handle=\_SB_.PCI0.APCG pci_link23 pnpinfo _HID=PNP0C0F _UID=18 at handle=\_SB_.PCI0.APCH pci_link24 pnpinfo _HID=PNP0C0F _UID=26 at handle=\_SB_.PCI0.APCI pci_link25 pnpinfo _HID=PNP0C0F _UID=27 at handle=\_SB_.PCI0.APCJ pci_link26 pnpinfo _HID=PNP0C0F _UID=28 at handle=\_SB_.PCI0.APCK pci_link27 pnpinfo _HID=PNP0C0F _UID=29 at handle=\_SB_.PCI0.APCS pci_link28 pnpinfo _HID=PNP0C0F _UID=30 at handle=\_SB_.PCI0.APCL pci_link29 pnpinfo _HID=PNP0C0F _UID=31 at handle=\_SB_.PCI0.APCM pci_link30 pnpinfo _HID=PNP0C0F _UID=32 at handle=\_SB_.PCI0.AP3C pci_link31 pnpinfo _HID=PNP0C0F _UID=33 at handle=\_SB_.PCI0.APCZ acpi_sysresource3 pnpinfo _HID=PNP0C02 _UID=1 at handle= \_SB_.PCI0.SYSR atpic0 pnpinfo _HID=PNP0000 _UID=0 at handle= \_SB_.PCI0.PIC_ atdma0 pnpinfo _HID=PNP0200 _UID=0 at handle= \_SB_.PCI0.DMA1 attimer0 pnpinfo _HID=PNP0100 _UID=0 at handle= \_SB_.PCI0.TMR_ attimer1 pnpinfo _HID=PNP0B00 _UID=0 at handle= \_SB_.PCI0.RTC_ unknown pnpinfo _HID=PNP0800 _UID=0 at handle= \_SB_.PCI0.SPKR npxisa0 pnpinfo _HID=PNP0C04 _UID=0 at handle= \_SB_.PCI0.COPR fdc0 pnpinfo _HID=PNP0700 _UID=0 at handle= \_SB_.PCI0.FDC0 Interrupt request lines: 0x6 DMA request lines: 2 I/O ports: 0x3f0-0x3f5 0x3f7 fd0 fd1 sio0 pnpinfo _HID=PNP0501 _UID=1 at handle=\_SB_.PCI0.UAR1 Interrupt request lines: 0x4 I/O ports: 0x3f8-0x3ff sio1 pnpinfo _HID=PNP0501 _UID=2 at handle=\_SB_.PCI0.UAR2 Interrupt request lines: 0x3 I/O ports: 0x2f8-0x2ff unknown pnpinfo _HID=PNP0510 _UID=0 at handle=\_SB_.PCI0.IRDA unknown pnpinfo _HID=PNP0400 _UID=0 at handle=\_SB_.PCI0.LPT1 ppc0 pnpinfo _HID=PNP0401 _UID=0 at handle=\_SB_.PCI0.ECP1 I/O ports: 0x378-0x37f ppbus0 lpt0 ppi0 psmcpnp0 pnpinfo _HID=PNP0F13 _UID=0 at handle=\_SB_.PCI0.PS2M Interrupt request lines: 0xc atkbdc0 pnpinfo _HID=PNP0303 _UID=0 at handle=\_SB_.PCI0.PS2K I/O ports: 0x60 0x64 atkbd0 Interrupt request lines: 0x1 psm0 unknown pnpinfo _HID=PNPB006 _UID=0 at handle=\_SB_.PCI0.MIDI unknown pnpinfo _HID=PNPB02F _UID=0 at handle=\_SB_.PCI0.GAME acpi_timer0 pnpinfo unknown at unknown I/O ports: 0x4008-0x400b -- iprefetch ai From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 06:15:53 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0518516A41F; Tue, 20 Dec 2005 06:15:53 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45E6443D55; Tue, 20 Dec 2005 06:15:52 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.3/8.12.9) with ESMTP id jBK6FZ2q023350; Tue, 20 Dec 2005 07:15:35 +0100 (CET) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.3/8.12.9/Submit) id jBK6FUq7023349; Tue, 20 Dec 2005 01:15:30 -0500 (EST) (envelope-from cracauer) Date: Tue, 20 Dec 2005 01:15:30 -0500 From: Martin Cracauer To: David Xu Message-ID: <20051220011530.A23196@cons.org> References: <43A6D190.3020504@drexel.edu> <43A6D40A.70305@centtech.com> <43A74B52.1090104@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <43A74B52.1090104@freebsd.org>; from davidxu@freebsd.org on Tue, Dec 20, 2005 at 08:07:46AM +0800 Cc: Justin Smith , Matthias Andree , Eric Anderson , freebsd-current@freebsd.org Subject: Re: "Native" journaling file systems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 06:15:53 -0000 David Xu wrote on Tue, Dec 20, 2005 at 08:07:46AM +0800: > Matthias Andree wrote: > > >What has become of lfs by the way? > > > I am curious why nobody picks up the BSD lfs ? the UFS background fsck > sucks us too bad, sigh. If I am not mistaken, LFS was a pure log-structured filesystem, not a normal filesystem with an added log. That means it puts all the data in addition to metadata into the log, and the log is all there is. These filesystems are very difficult to make perform well if the exact usage pattern is unkown. In particular, garbage collection and the compacting of the log is a fundamental problem. Frequent deletions are an obvious example. I also think LFS did not have the capability to overwrite existing blocks in existing files with new data, so updates would lead to "shadowed" blocks at the end of the log, potentially leaving a single file spattered all over the log and making gargabe collection of deleted files in between a nightmare. These filesystem can be excellent when you know what your usage patterns are, or when you have a different API than the Unix API. Immutable files in the API come to mind, they help these filesystems a lot. Won't help us run GNOME and mysql, though :-) Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 08:07:01 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9126716A41F for ; Tue, 20 Dec 2005 08:07:01 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from smtp4-g19.free.fr (smtp4-g19.free.fr [212.27.42.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8802543D49 for ; Tue, 20 Dec 2005 08:07:00 +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 smtp4-g19.free.fr (Postfix) with ESMTP id 5B6DC4E8D9; Tue, 20 Dec 2005 09:06:59 +0100 (CET) Received: from obiwan.tataz.chchile.org (unknown [192.168.1.25]) by tatooine.tataz.chchile.org (Postfix) with ESMTP id 4A5849B6E7; Tue, 20 Dec 2005 08:06:33 +0000 (UTC) Received: by obiwan.tataz.chchile.org (Postfix, from userid 1000) id 2119B405A; Tue, 20 Dec 2005 09:06:33 +0100 (CET) Date: Tue, 20 Dec 2005 09:06:33 +0100 From: Jeremie Le Hen To: Eric Anholt Message-ID: <20051220080632.GD3512@obiwan.tataz.chchile.org> References: <200512192117.jBJLHE8C057230@lurza.secnetix.de> <1135028917.75547.4.camel@leguin> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1135028917.75547.4.camel@leguin> User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: [fbsd] Re: DRM update for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2005 08:07:01 -0000 Hi, Eric, > glxgears is not a benchmark. What benchmark do you advice ? Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 08:21:54 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1AFB16A41F for ; Tue, 20 Dec 2005 08:21:54 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4AC8543D55 for ; Tue, 20 Dec 2005 08:21:54 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id jBK8LovJ090051 for ; Tue, 20 Dec 2005 08:21:51 GMT (envelope-from davidxu@freebsd.org) Message-ID: <43A7BF25.6040901@freebsd.org> Date: Tue, 20 Dec 2005 16:21:57 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20050928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: gcc4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 08:21:54 -0000 When will gcc4 be in base tree ? David Xu From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 08:27:57 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3AA3C16A41F; Tue, 20 Dec 2005 08:27:57 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 90CE143D6B; Tue, 20 Dec 2005 08:27:53 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.4/8.13.4) with ESMTP id jBK8Ro5g047479; Tue, 20 Dec 2005 03:27:50 -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.3/8.13.3) with ESMTP id jBK8RoqZ023535; Tue, 20 Dec 2005 03:27:50 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 1D8377302F; Tue, 20 Dec 2005 03:27:50 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051220082750.1D8377302F@freebsd-current.sentex.ca> Date: Tue, 20 Dec 2005 03:27:50 -0500 (EST) X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2005 08:27:57 -0000 TB --- 2005-12-20 07:10:23 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-12-20 07:10:23 - starting HEAD tinderbox run for i386/pc98 TB --- 2005-12-20 07:10:23 - cleaning the object tree TB --- 2005-12-20 07:11:05 - checking out the source tree TB --- 2005-12-20 07:11:05 - cd /tinderbox/HEAD/i386/pc98 TB --- 2005-12-20 07:11:05 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-12-20 07:24:57 - building world (CFLAGS=-O2 -pipe) TB --- 2005-12-20 07:24:57 - cd /src TB --- 2005-12-20 07:24:57 - /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 -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/pc98/loader/../../ficl -I/src/sys/boot/pc98/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -I/src/sys/boot/pc98/loader/../../common -I/src/sys/boot/pc98/loader/../../i386 -I. -Wall -I/src/sys/boot/pc98/loader/.. -I/src/sys/boot/pc98/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/pc98/loader/../../common/load_elf32_obj.c cc -O2 -pipe -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/pc98/loader/../../ficl -I/src/sys/boot/pc98/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -I/src/sys/boot/pc98/loader/../../common -I/src/sys/boot/pc98/loader/../../i386 -I. -Wall -I/src/sys/boot/pc98/loader/.. -I/src/sys/boot/pc98/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/pc98/loader/../../common/reloc_elf32.c cc -O2 -pipe -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/pc98/loader/../../ficl -I/src/sys/boot/pc98/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -I/src/sys/boot/pc98/loader/../../common -I/src/sys/boot/pc98/loader/../../i386 -I. -Wall -I/src/sys/boot/pc98/loader/.. -I/src/sys/boot/pc98/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/pc98/loader/../../common/isapnp.c cc -O2 -pipe -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/pc98/loader/../../ficl -I/src/sys/boot/pc98/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -I/src/sys/boot/pc98/loader/../../common -I/src/sys/boot/pc98/loader/../../i386 -I. -Wall -I/src/sys/boot/pc98/loader/.. -I/src/sys/boot/pc98/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/pc98/loader/../../common/pnp.c cc -O2 -pipe -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/pc98/loader/../../ficl -I/src/sys/boot/pc98/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -I/src/sys/boot/pc98/loader/../../common -I/src/sys/boot/pc98/loader/../../i386 -I. -Wall -I/src/sys/boot/pc98/loader/.. -I/src/sys/boot/pc98/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -c /src/sys/boot/pc98/loader/../../common/interp_forth.c cc -O2 -pipe -DLOADER_NFS_SUPPORT -DBOOT_FORTH -I/src/sys/boot/pc98/loader/../../ficl -I/src/sys/boot/pc98/loader/../../ficl/i386 -DLOADER_GZIP_SUPPORT -I/src/sys/boot/pc98/loader/../../common -I/src/sys/boot/pc98/loader/../../i386 -I. -Wall -I/src/sys/boot/pc98/loader/.. -I/src/sys/boot/pc98/loader/../btx/lib -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -static -Ttext 0x0 -nostdlib -o loader.sym /obj/pc98/src/sys/boot/pc98/loader/../btx/lib/crt0.o main.o conf.o vers.o bcache.o boot.o commands.o console.o devopen.o interp.o interp_backslash.o interp_parse.o ls.o misc.o module.o panic.o load_elf32.o load_elf32_obj.o reloc_elf32.o isapnp.o pnp.o interp_forth.o /obj/pc98/src/sys/boot/pc98/loader/../../ficl/libficl.a /obj/pc98/src/sys/boot/pc98/loader/../libpc98/libpc98.a -lstand /obj/pc98/src/sys/boot/pc98/loader/../libpc98/libpc98.a(biospnp.o)(.text+0x183): In function `biospnp_enumerate': : undefined reference to `alloca' *** Error code 1 Stop in /src/sys/boot/pc98/loader. *** Error code 1 Stop in /src/sys/boot/pc98. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-12-20 08:27:49 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-12-20 08:27:49 - ERROR: failed to build world TB --- 2005-12-20 08:27:49 - tinderbox aborted TB --- 1.20 user 5.55 system 4646.12 real From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 08:43:06 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 836F616A41F for ; Tue, 20 Dec 2005 08:43:06 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 73F2F43D55 for ; Tue, 20 Dec 2005 08:43:05 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.4/8.13.1) with ESMTP id jBK8h4h7038109; Tue, 20 Dec 2005 00:43:04 -0800 (PST) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.4/8.13.1/Submit) id jBK8h3QC038108; Tue, 20 Dec 2005 00:43:03 -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: Jeremie Le Hen In-Reply-To: <20051220080632.GD3512@obiwan.tataz.chchile.org> References: <200512192117.jBJLHE8C057230@lurza.secnetix.de> <1135028917.75547.4.camel@leguin> <20051220080632.GD3512@obiwan.tataz.chchile.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-btvCxRoMZuSayIPo8vIU" Date: Tue, 20 Dec 2005 00:43:02 -0800 Message-Id: <1135068182.75547.34.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2 FreeBSD GNOME Team Port Cc: freebsd-current@freebsd.org Subject: Re: [fbsd] Re: DRM update for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2005 08:43:06 -0000 --=-btvCxRoMZuSayIPo8vIU Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-12-20 at 09:06 +0100, Jeremie Le Hen wrote: > Hi, Eric, >=20 > > glxgears is not a benchmark. >=20 > What benchmark do you advice ? Find an app whose performance you care about. Something that you would run regularly, and probably where the fps with hardware is approximately <=3D the refresh rate. For me that's been quake3, other developers ut2kX or doom3 or their own custom apps. Why is glxgears performance measurement pointless? 1) In software, many people see it going faster than the refresh rate. So why do you care if you can go 10x the refresh rate or only 1.5x? You're only displaying so much. 2) It's flat or smooth-shaded triangles. Does anybody use these? Well, some GL screensavers do, but those in particular I find work fine in software as well. 3) It's display lists of triangles. Most software where performance matters is going to be using some sort of vertex arrays of triangles (any game, basically) or lines (CAD, scientific apps). Those are going to be totally different rendering paths. 4) relative significance of swapping. In very few apps do you see swapping back to front (or perhaps waiting for pending swaps) being a major participant in the total time. Notably, 4) has led to bad optimizations like page flipping. It's a 20% or so performance improvement (over an existing 1000+ fps) in tests I've seen for glxgears, but I've only been able to measure .4% to 5% improvements for quake3 under rather ideal conditions. On the other hand, page flipping increases the complexity of your X driver code (it took a long time to get it to even render right), increases overhead of 2d operations to perform the extra accounting and copying, and is likely nonconformant for X drawing on top of GL drawing, which some apps will do as far as I've heard. That's what optimizing for bad benchmarks gets you. Oh, and for those using software, in software you're probably going to be measuring your CPU-framebuffer write speeds more than the-rest-of-GL speeds, anyway. Those rates are rather different between cards (notably, Intel stuff seems to do quite well with operations on framebuffer, perhaps due to its UMAness. I need to actually quantify it and see if I'm right), and it's unimportant for hardware acceleration. This is why I say that posting glxgears fps on mailing lists or IRC is just noise. That is, unless all you care about is the screensaver with the gears. --=20 Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org --=-btvCxRoMZuSayIPo8vIU Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDp8QWHUdvYGzw6vcRAmiZAKCNGXm4xu3cN+jKgBVI7db2dJPn6QCeJV25 PGuLMlsLaUUBXSIuxsgBzgg= =8rkB -----END PGP SIGNATURE----- --=-btvCxRoMZuSayIPo8vIU-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 08:44:09 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EC7416A41F; Tue, 20 Dec 2005 08:44:09 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail26.syd.optusnet.com.au (mail26.syd.optusnet.com.au [211.29.133.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ACA243D53; Tue, 20 Dec 2005 08:44:08 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail26.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id jBK8i6it013564 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 20 Dec 2005 19:44:06 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id jBK8i5Hh091631; Tue, 20 Dec 2005 19:44:06 +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 jBK8i5Fd091630; Tue, 20 Dec 2005 19:44:05 +1100 (EST) (envelope-from pjeremy) Date: Tue, 20 Dec 2005 19:44:05 +1100 From: Peter Jeremy To: David Xu Message-ID: <20051220084405.GA77268@cirb503493.alcatel.com.au> References: <43A6D190.3020504@drexel.edu> <43A6D40A.70305@centtech.com> <43A74B52.1090104@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A74B52.1090104@freebsd.org> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc Cc: freebsd-current@freebsd.org Subject: Re: "Native" journaling file systems? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 08:44:09 -0000 On Tue, 2005-Dec-20 08:07:46 +0800, David Xu wrote: >I am curious why nobody picks up the BSD lfs ? the UFS background fsck >sucks us too bad, sigh. As Martin pointed out, LFS sounds good in theory but turns out not to be that good in practice. That said, there's nothing stopping someone pulling sys/ufs/lfs out of the Attic. The retirement comment states that it was suffering from bitrot even before 3.0 so there's probably a non-trivial amount of work needed to get it going again. On the positive side, many of the people who worked on it are still around so anyone wanting to resurrect it could probably find reviewers who knew the code. Personally, I'd prefer to see the effort applied to getting journalling to work with UFS2. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 09:28:51 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AB4316A422 for ; Tue, 20 Dec 2005 09:28:51 +0000 (GMT) (envelope-from delphij@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id D524243D5F for ; Tue, 20 Dec 2005 09:28:49 +0000 (GMT) (envelope-from delphij@gmail.com) Received: by wproxy.gmail.com with SMTP id 57so1217934wri for ; Tue, 20 Dec 2005 01:28:49 -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:content-disposition:references; b=JcW15TxIW6Wcl72rJokZHZZV5vEQ+7hcV0ziVKRwVd0uohxDedbgxQHOl7r7V94d857JkCdkEfmK3K8+vPTsScTa3aheZuJSgNxT9cI7aas79HFivIk6EBS52tDbW1knPA1GC7JQL+yVCm0N87dymYVmOvHzytU+nTBBYbF8vxE= Received: by 10.65.153.12 with SMTP id f12mr3906283qbo; Tue, 20 Dec 2005 01:28:48 -0800 (PST) Received: by 10.65.72.5 with HTTP; Tue, 20 Dec 2005 01:28:48 -0800 (PST) Message-ID: Date: Tue, 20 Dec 2005 17:28:48 +0800 From: Xin LI To: David Xu In-Reply-To: <43A7BF25.6040901@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <43A7BF25.6040901@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: gcc4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: delphij@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2005 09:28:51 -0000 SGksIERhdmlkLAoKT24gMTIvMjAvMDUsIERhdmlkIFh1IDxkYXZpZHh1QGZyZWVic2Qub3JnPiB3 cm90ZToKPiBXaGVuIHdpbGwgZ2NjNCBiZSBpbiBiYXNlIHRyZWUgPwoKSXMgb3VyIHRyZWUgZ2Nj NC1zYWZlIGFscmVhZHk/ICBJIGhhdmUgbm90IGNoZWNrZWQgZm9yIHRoaXMgZm9yIGEgbG9uZyB0 aW1lLi4uCgpDaGVlcnMsCi0tClhpbiBMSSA8ZGVscGhpakBkZWxwaGlqLm5ldD4gaHR0cDovL3d3 dy5kZWxwaGlqLm5ldAo= From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 09:48:47 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6013916A41F; Tue, 20 Dec 2005 09:48:47 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2759243D64; Tue, 20 Dec 2005 09:48:38 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from [195.208.252.201] (celsius.cc.rsu.ru [195.208.252.201]) by mail.r61.net (8.13.4/8.13.4) with ESMTP id jBK9mXre003896; Tue, 20 Dec 2005 12:48:34 +0300 (MSK) (envelope-from bushman@rsu.ru) Message-ID: <43A7D4A6.6000607@rsu.ru> Date: Tue, 20 Dec 2005 12:53:42 +0300 From: Michael Bushkov User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051018) X-Accept-Language: en-us, en MIME-Version: 1.0 To: pjd@FreeBSD.org References: <20051102001507.GB14638@odin.ac.hmc.edu> <20051103124027.GE29387@submonkey.net> <436A0C73.3010405@rsu.ru> <20051103140221.GF29387@submonkey.net> <43A009CB.2090800@rsu.ru> <20051219130928.GE63860@submonkey.net> <20051219135019.GF63860@submonkey.net> <43A6CC9E.6040109@rsu.ru> <20051219152505.GI63860@submonkey.net> <002c01c604c4$60ebe010$0100a8c0@jersey> <20051219183137.GA1103@odin.ac.hmc.edu> In-Reply-To: <20051219183137.GA1103@odin.ac.hmc.edu> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on asterix.r61.net X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org, Ceri Davies Subject: pidfile_check() possible function X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 09:48:47 -0000 Hi! I've just had a situation, where I want to know the pid of the already running daemon, but i don't want to create the pidfile in case if there is no daemon running. Such a situation can occur if the daemon has some kind of controlling program. This program should be able to know the pid of the daemon (to send a signal, or for some logging purposes). With current pidfile API I don't see an appropriate way to do it. Pidfile_open() call can provide us with the PID. But if there is no daemon, this call will create the pidfile - and we'll have to use pidfile_remove() to do the cleanup. This behaviour doesn't seem to be appropriate. Is it possible to introduce some function to return the pid of the already running daemon or (-1), for example, if no daemon exists. Possible syntax can be: int pidfile_check(pid_t *pidptr); What do you think about that? With best regards, Michael From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 11:25:40 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9122416A41F for ; Tue, 20 Dec 2005 11:25:40 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FAC443D49 for ; Tue, 20 Dec 2005 11:25:40 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id jBKBPcUn033285; Tue, 20 Dec 2005 03:25:38 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id jBKBPcws033284; Tue, 20 Dec 2005 03:25:38 -0800 (PST) (envelope-from rizzo) Date: Tue, 20 Dec 2005 03:25:38 -0800 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20051220032538.A33093@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Cc: Subject: td->td_critnest manipulations do not use atomic_add_int ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 11:25:40 -0000 as in the subject... i see that td->td_critnest (used to determine whether a thread can be preempted or not) is manipulated using plain ++ or -- instruction instead of the atomic_add_int(). I wonder if declaring it as volatile and possibly its usage patterns are enough to make the two things equivalent on all architectures. cheers luigi From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 11:45:25 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C71BA16A41F; Tue, 20 Dec 2005 11:45:25 +0000 (GMT) (envelope-from huang@gddsn.org.cn) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19CA343D46; Tue, 20 Dec 2005 11:45:25 +0000 (GMT) (envelope-from huang@gddsn.org.cn) Received: from [192.168.1.5] (unknown [218.19.185.114]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gddsn.org.cn (Postfix) with ESMTP id 02A5F38CB41; Tue, 20 Dec 2005 19:45:22 +0800 (CST) Message-ID: <43A7EECC.7090804@gddsn.org.cn> Date: Tue, 20 Dec 2005 19:45:16 +0800 From: Huang wen hui User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051212) X-Accept-Language: zh-cn,zh MIME-Version: 1.0 To: Gleb Smirnoff , current@freebsd.org References: <20051219173854.GC41381@FreeBSD.org> <20051220.100100.110014772.garrigue@math.nagoya-u.ac.jp> <20051220092835.GL41381@cell.sick.ru> In-Reply-To: <20051220092835.GL41381@cell.sick.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: em suspend hack to test X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 11:45:25 -0000 Gleb Smirnoff wrote: >On Tue, Dec 20, 2005 at 10:01:00AM +0900, Jacques Garrigue wrote: >J> > here is a hack to test whether it fixes suspend on your laptop >J> > or not? Please test it. Thanks in advance. >J> >J> I applied it to the vanilla if_em.c from 6.0-RELEASE, built, installed >J> and loaded if_em.ko, and it looks like it did the trick for me. > >Colleagues, can you also tell me whether in your laptop em(4) NIC shares >its IRQ with something else? > > > yes. em NIC share its IRQ with a lot of other device. %dmesg 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 7.0-CURRENT #6: Tue Dec 20 08:08:54 CST 2005 hwh@tp.gddsn.org.cn:/usr/obj/usr/src/sys/IBM01 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) M processor 1.80GHz (1794.18-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x6d6 Stepping = 6 Features=0xafe9f9bf Features2=0x180 real memory = 2146828288 (2047 MB) avail memory = 2095865856 (1998 MB) ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 acpi_perf0: on cpu0 acpi_throttle0: on cpu0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xd0000000-0xdfffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) uhci0: port 0x1800-0x181f irq 11 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1820-0x183f irq 11 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xc0000000-0xc00003ff irq 11 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pcib2: at device 30.0 on pci0 pci2: on pcib2 cbb0: mem 0xb0000000-0xb0000fff irq 11 at device 0.0 on pci2cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb1: mem 0xb1000000-0xb1000fff irq 11 at device 0.1 on pci2cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 pci2: at device 1.0 (no driver attached) ath0: mem 0xc0210000-0xc021ffff irq 11 at device 2.0 on pci2 ath0: Ethernet address: 00:05:4e:4d:2a:7b ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz radio 2.3 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x1860-0x186f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 ichsmb0: port 0x1880-0x189f irq 11 at device 31.3 on pci0 ichsmb0: [GIANT-LOCKED] smbus0: on ichsmb0 smb0: on smbus0 pcm0: port 0x1c00-0x1cff,0x18c0-0x18ff mem 0xc0000c00-0xc0000dff,0xc0000800-0xc00008ff irq 11 at device 31.5 on pci0 pcm0: pci0: at device 31.6 (no driver attached) acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 8250 or not responding ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled battery0: on acpi0 acpi_acad0: on acpi0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled pmtimer0 on isa0 orm0: at iomem 0xd0000-0xd0fff,0xd1000-0xd1fff,0xdc000-0xdffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled ums0: Logitech USB Optical Mouse, rev 1.10/21.10, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. ugen0: vendor 0x1668 product 0x2441, rev 1.10/5.46, addr 2 Timecounter "TSC" frequency 1794184505 Hz quality 800 Timecounters tick every 1.000 msec ad0: 57231MB at ata0-master UDMA100 acd0: DVDR at ata1-master UDMA33 Trying to mount root from ufs:/dev/ad0s1a em0: port 0x8000-0x803f mem 0xc0240000-0xc025ffff,0xc0200000-0xc020ffff irq 11 at device 1.0 on pci2 em0: Ethernet address: 00:0d:60:75:92:ac From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 12:18:43 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D643816A420; Tue, 20 Dec 2005 12:18:43 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3997243D6D; Tue, 20 Dec 2005 12:18:40 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jBKCIbml087121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Dec 2005 15:18:38 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jBKCIbod087114; Tue, 20 Dec 2005 15:18:37 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 20 Dec 2005 15:18:37 +0300 From: Gleb Smirnoff To: current@FreeBSD.org, njl@FreeBSD.org Message-ID: <20051220121837.GQ41381@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.6i Cc: Subject: acpica memory leak? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 12:18:44 -0000 On recent current I see the "acpica" memory type allocation count slowly growing: acpica 2162 116K - 33738 16,32,64,128,256,512,1024 root@jujik:~:|>vmstat -m | grep acpica acpica 2163 116K - 33765 16,32,64,128,256,512,1024 root@jujik:~:|>vmstat -m | grep acpica acpica 2168 116K - 33900 16,32,64,128,256,512,1024 Anyone else see this? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 09:43:37 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C088B16A420 for ; Tue, 20 Dec 2005 09:43:37 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BCE243D5A for ; Tue, 20 Dec 2005 09:43:36 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (tmzebi@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id jBK9hZY6081363 for ; Tue, 20 Dec 2005 10:43:35 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id jBK9hZEK081362; Tue, 20 Dec 2005 10:43:35 +0100 (CET) (envelope-from olli) Date: Tue, 20 Dec 2005 10:43:35 +0100 (CET) Message-Id: <200512200943.jBK9hZEK081362@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG In-Reply-To: <1135028917.75547.4.camel@leguin> X-Newsgroups: list.freebsd-current User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Mailman-Approved-At: Tue, 20 Dec 2005 12:32:29 +0000 Cc: Subject: Re: DRM update for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 20 Dec 2005 09:43:37 -0000 Eric Anholt wrote: > Oliver Fromme wrote: > > Freddie Cash wrote: > > > Running glxgears at 1024x768x16 gives me a decent 35 fps, compared > > > to the 1 fps I used to get. :) > > > > Uhm. Are you sure that you're running hardware-accelerated > > OpenGL glxgears? > > > > I get 48 fps at 1400x1050x32 -- in software, without any > > hardware 3D acceleration. (It's a 1.6GHz Centrino notebook > > with shared i915 graphics. 2D acceleration is enabled, of > > course.) > > glxgears is not a benchmark. That's right. I was not suggesting to use it as a real- world benchmark, but rather as a rough indication whether hardware acceleration is enabled at all or not. If someone gets 1 fps (!) out of glxgears, something is _seriously_ wrong, even with software rendering. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. Passwords are like underwear. You don't share them, you don't hang them on your monitor or under your keyboard, you don't email them, or put them on a web site, and you must change them very often. From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 09:47:24 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D042C16A41F for ; Tue, 20 Dec 2005 09:47:24 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2AC8E43D45 for ; Tue, 20 Dec 2005 09:47:23 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (rozohw@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id jBK9lNjX081556 for ; Tue, 20 Dec 2005 10:47:23 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id jBK9lN83081555; Tue, 20 Dec 2005 10:47:23 +0100 (CET) (envelope-from olli) Date: Tue, 20 Dec 2005 10:47:23 +0100 (CET) Message-Id: <200512200947.jBK9lN83081555@lurza.secnetix.de> From: Oliver Fromme To: freebsd-current@FreeBSD.ORG In-Reply-To: X-Newsgroups: list.freebsd-current User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Mailman-Approved-At: Tue, 20 Dec 2005 12:32:39 +0000 Cc: Subject: Re: DRM update for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2005 09:47:25 -0000 othermark wrote: > Testing this and drm in X, generates a huge interrupt storm on irq 11. > Things work, but are slow as molasses with the system 75% in interrupt > servicing. Look at the output of "vmstat -i". Ist irq 11 shared with usb (*hci)? If so, try running without USB. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead." -- RFC 1925 From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 14:10:46 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0186116A422 for ; Tue, 20 Dec 2005 14:10:45 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8031A43D6B for ; Tue, 20 Dec 2005 14:10:30 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 9D4CD52B3E; Tue, 20 Dec 2005 15:10:27 +0100 (CET) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 6032A50F93; Tue, 20 Dec 2005 15:10:21 +0100 (CET) Date: Tue, 20 Dec 2005 15:09:27 +0100 From: Pawel Jakub Dawidek To: Michael Bushkov Message-ID: <20051220140927.GA1671@garage.freebsd.pl> References: <436A0C73.3010405@rsu.ru> <20051103140221.GF29387@submonkey.net> <43A009CB.2090800@rsu.ru> <20051219130928.GE63860@submonkey.net> <20051219135019.GF63860@submonkey.net> <43A6CC9E.6040109@rsu.ru> <20051219152505.GI63860@submonkey.net> <002c01c604c4$60ebe010$0100a8c0@jersey> <20051219183137.GA1103@odin.ac.hmc.edu> <43A7D4A6.6000607@rsu.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <43A7D4A6.6000607@rsu.ru> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r535 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: freebsd-current@FreeBSD.org, Ceri Davies Subject: Re: pidfile_check() possible function X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 14:10:46 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 20, 2005 at 12:53:42PM +0300, Michael Bushkov wrote: +> Hi! +> I've just had a situation, where I want to know the pid of the already r= unning daemon, but i don't want to create the pidfile in case if there is n= o daemon running. Such a=20 +> situation can occur if the daemon has some kind of controlling program. = This program should be able to know the pid of the daemon (to send a signal= , or for some logging=20 +> purposes). +> With current pidfile API I don't see an appropriate way to do it. Pidfil= e_open() call can provide us with the PID. But if there is no daemon, this = call will create the=20 +> pidfile - and we'll have to use pidfile_remove() to do the cleanup. This= behaviour doesn't seem to be appropriate. +> Is it possible to introduce some function to return the pid of the alrea= dy running daemon or (-1), for example, if no daemon exists. Possible synta= x can be: +> int pidfile_check(pid_t *pidptr); +>=20 +> What do you think about that? Maybe... This function is not enough for sure, as you need to provide file to look for pid at least. Take a look at takepid() function in usr.bin/pkill/pkill.c to see how pkill(1) is doing this. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --SUOF0GtieIMvvwua Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDqBCXForvXbEpPzQRAma3AKDwUQrq46oumKm+/haW7W7PibfhQQCghfjD NjLCrdlWLjNmrom9C2vPMb4= =t1WS -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 14:35:00 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43A1316A435 for ; Tue, 20 Dec 2005 14:35:00 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D09443D66 for ; Tue, 20 Dec 2005 14:34:55 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.0.2] (c-24-6-173-198.hsd1.ca.comcast.net [24.6.173.198]) by elvis.mu.org (Postfix) with ESMTP id 544DD1A3C27; Tue, 20 Dec 2005 06:34:54 -0800 (PST) Message-ID: <43A8166C.9060401@FreeBSD.org> Date: Tue, 20 Dec 2005 06:34:20 -0800 From: Suleiman Souhlal User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo References: <20051220032538.A33093@xorpc.icir.org> In-Reply-To: <20051220032538.A33093@xorpc.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: td->td_critnest manipulations do not use atomic_add_int ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 14:35:00 -0000 Hello Luigi, Luigi Rizzo wrote: > as in the subject... i see that td->td_critnest (used to determine > whether a thread can be preempted or not) is manipulated using > plain ++ or -- instruction instead of the atomic_add_int(). This should be fine as it only gets modified by the current thread. If an interrupt comes while we are decreasing td_critnest back to 0, then we just don't get preempted immediately, but at the end of our quantum, or when someone else tries to preempt us, whichever comes first, which should be totally harmless. --Suleiman From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 16:16:19 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AEC6816A41F; Tue, 20 Dec 2005 16:16:19 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E50E43D6D; Tue, 20 Dec 2005 16:16:13 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id jBKGGBRS037875; Tue, 20 Dec 2005 08:16:11 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id jBKGGB4l037874; Tue, 20 Dec 2005 08:16:11 -0800 (PST) (envelope-from rizzo) Date: Tue, 20 Dec 2005 08:16:11 -0800 From: Luigi Rizzo To: Suleiman Souhlal Message-ID: <20051220081611.A36159@xorpc.icir.org> References: <20051220032538.A33093@xorpc.icir.org> <43A8166C.9060401@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <43A8166C.9060401@FreeBSD.org>; from ssouhlal@FreeBSD.org on Tue, Dec 20, 2005 at 06:34:20AM -0800 Cc: current@FreeBSD.org Subject: Re: td->td_critnest manipulations do not use atomic_add_int ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 16:16:19 -0000 On Tue, Dec 20, 2005 at 06:34:20AM -0800, Suleiman Souhlal wrote: > Hello Luigi, > > Luigi Rizzo wrote: > > as in the subject... i see that td->td_critnest (used to determine > > whether a thread can be preempted or not) is manipulated using > > plain ++ or -- instruction instead of the atomic_add_int(). > > This should be fine as it only gets modified by the current thread. If > an interrupt comes while we are decreasing td_critnest back to 0, then > we just don't get preempted immediately, but at the end of our quantum, > or when someone else tries to preempt us, whichever comes first, which > should be totally harmless. i think that there are still some potential race conditions if the variable is read from another processor to make a decision based on its value. My understanding is that when critical_enter() returns, everything in the system should read td->td_critnest >= 1, which may not be guaranteed by the current implementation (which doesn't have smp locks). There might be similar issues in the 1->0 transition. cheers luigi From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 17:02:00 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FAFC16A41F for ; Tue, 20 Dec 2005 17:02:00 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3D9743D49 for ; Tue, 20 Dec 2005 17:01:59 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.4/8.13.3) with ESMTP id jBKH1tMr088431 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 20 Dec 2005 18:01:55 +0100 (CET) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.4/8.13.3/Submit) id jBKH1txC088430 for freebsd-current@freebsd.org; Tue, 20 Dec 2005 18:01:55 +0100 (CET) Date: Tue, 20 Dec 2005 18:01:55 +0100 From: Divacky Roman To: freebsd-current@freebsd.org Message-ID: <20051220170155.GA87954@stud.fit.vutbr.cz> References: <43A7BF25.6040901@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.49 on 147.229.10.14 Subject: Re: gcc4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 17:02:00 -0000 On Tue, Dec 20, 2005 at 05:28:48PM +0800, Xin LI wrote: > Hi, David, > > On 12/20/05, David Xu wrote: > > When will gcc4 be in base tree ? > > Is our tree gcc4-safe already? I have not checked for this for a long time... most of the tree is and the rest is trivial to fix.. havent tried stability thought From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 17:17:03 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2805A16A41F for ; Tue, 20 Dec 2005 17:17:03 +0000 (GMT) (envelope-from delphij@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2978743D64 for ; Tue, 20 Dec 2005 17:17:00 +0000 (GMT) (envelope-from delphij@gmail.com) Received: by zproxy.gmail.com with SMTP id q3so1508562nzb for ; Tue, 20 Dec 2005 09:16:59 -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:content-disposition:references; b=nYqwSFaIY89qHvl8GlXqKJT2urYceDD5oz3Zk3pFhyHklNFhFVxpTBpTUrWflAlur+NelQ53IGH3MKcquGqvnIN75Wv/JhaJMOw2+PmsLdxz3CixgSf6l5+Bk/9G+P93O4qlcTeoQDgoMqAuMHJMI7AZoh8EHDCFTAJr8E072Xw= Received: by 10.65.197.20 with SMTP id z20mr5734439qbp; Tue, 20 Dec 2005 09:16:59 -0800 (PST) Received: by 10.65.72.5 with HTTP; Tue, 20 Dec 2005 09:16:58 -0800 (PST) Message-ID: Date: Wed, 21 Dec 2005 01:16:58 +0800 From: Xin LI To: Divacky Roman In-Reply-To: <20051220170155.GA87954@stud.fit.vutbr.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <43A7BF25.6040901@freebsd.org> <20051220170155.GA87954@stud.fit.vutbr.cz> Cc: freebsd-current@freebsd.org Subject: Re: gcc4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: delphij@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2005 17:17:03 -0000 SGksCgpPbiAxMi8yMS8wNSwgRGl2YWNreSBSb21hbiA8eGRpdmFjMDJAc3R1ZC5maXQudnV0YnIu Y3o+IHdyb3RlOgo+IE9uIFR1ZSwgRGVjIDIwLCAyMDA1IGF0IDA1OjI4OjQ4UE0gKzA4MDAsIFhp biBMSSB3cm90ZToKWy4uLl0KPiA+IElzIG91ciB0cmVlIGdjYzQtc2FmZSBhbHJlYWR5PyAgSSBo YXZlIG5vdCBjaGVja2VkIGZvciB0aGlzIGZvciBhIGxvbmcgdGltZS4uLgo+Cj4gbW9zdCBvZiB0 aGUgdHJlZSBpcyBhbmQgdGhlIHJlc3QgaXMgdHJpdmlhbCB0byBmaXguLiBoYXZlbnQgdHJpZWQg c3RhYmlsaXR5Cj4gdGhvdWdodAoKTm90IHRoZSAid2hvbGUiIDotKQoKSSBhbSBub3QgdmVyeSBj b25maWRlbnQgdGhhdCB0aGVzZSAidHJpdmlhbCIgZml4ZXMgYXJlIGNvcnJlY3QuICBMYXN0CnRp bWUgZGVzQCBnYXZlIG1lIHNvbWUgaW5wdXQgYWJvdXQgdGhlIGNvbmNlcm5zIG9mIEFQSSBjb3Jy ZWN0bmVzcywgYXMKc29tZSAidHJpdmlhbCIgZml4ZXMgd291bGQganVzdCBoaWRlIHNlcmlvdXMg QVBJIG1pc3Rha2VzIGJlaGluZAp0aGVtLi4uCgpDaGVlcnMsCi0tClhpbiBMSSA8ZGVscGhpakBk ZWxwaGlqLm5ldD4gaHR0cDovL3d3dy5kZWxwaGlqLm5ldAo= From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 17:19:38 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 627CC16A41F for ; Tue, 20 Dec 2005 17:19:38 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD28843D81 for ; Tue, 20 Dec 2005 17:19:18 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from c-24-63-58-245.hsd1.ma.comcast.net (c-24-147-19-128.hsd1.ma.comcast.net[24.147.19.128](misconfigured sender)) by comcast.net (sccrmhc11) with ESMTP id <20051220171912011005dudde>; Tue, 20 Dec 2005 17:19:13 +0000 Received: from c-24-147-19-128.hsd1.ma.comcast.net (localhost [127.0.0.1]) by c-24-63-58-245.hsd1.ma.comcast.net (8.13.4/8.13.1) with ESMTP id jBKHJC9W045733; Tue, 20 Dec 2005 12:19:12 -0500 (EST) (envelope-from rodrigc@c-24-147-19-128.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-24-147-19-128.hsd1.ma.comcast.net (8.13.4/8.13.1/Submit) id jBKHJBva045732; Tue, 20 Dec 2005 12:19:11 -0500 (EST) (envelope-from rodrigc) Date: Tue, 20 Dec 2005 12:19:11 -0500 From: Craig Rodrigues To: delphij@delphij.net Message-ID: <20051220171911.GA32051@crodrigues.org> References: <43A7BF25.6040901@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org Subject: Re: gcc4 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 17:19:38 -0000 On Tue, Dec 20, 2005 at 05:28:48PM +0800, Xin LI wrote: > Is our tree gcc4-safe already? I have not checked for this for a long time... Not really. The kernel mostly compiles with gcc40 from ports (I used gcc 4.0.2) if you compile with these flags set: WERROR= NO_WERROR=1 CC=/usr/local/bin/gcc40 and if you apply this patch: http://people.freebsd.org/~rodrigc/gcc40_makefiles_diff.txt You get lots of compilation warnings, mostly about comparing signed/unsigned pointers, such as the ones here: http://people.freebsd.org/~rodrigc/gcc40_warnings.txt There is at least one compilation error: In file included from /usr/src/sys/kern/sched_4bsd.c:56: ./machine/smp.h:36: error: array type has incomplete element type cc1: warnings being treated as errors In file included from /usr/src/sys/kern/subr_smp.c:50: ./machine/smp.h:36: error: array type has incomplete element type In file included from /usr/src/sys/i386/i386/local_apic.c:59: ./machine/smp.h:36: error: array type has incomplete element type In file included from /usr/src/sys/i386/i386/mp_watchdog.c:46: ./machine/smp.h:36: error: array type has incomplete element type The line causing the problem I think is this one in smp.h: extern struct pcb stoppcbs[]; I think the way things are inclu I did not try a buildworld with gcc4.0. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 18:30:20 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6EF516A41F; Tue, 20 Dec 2005 18:30:20 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id A222B43D70; Tue, 20 Dec 2005 18:30:18 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 4227830 for multiple; Tue, 20 Dec 2005 13:28:27 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id jBKIUDnB007809; Tue, 20 Dec 2005 13:30:16 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 20 Dec 2005 11:39:33 -0500 User-Agent: KMail/1.8.2 References: <20051220032538.A33093@xorpc.icir.org> <43A8166C.9060401@FreeBSD.org> <20051220081611.A36159@xorpc.icir.org> In-Reply-To: <20051220081611.A36159@xorpc.icir.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512201139.35723.jhb@freebsd.org> X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Luigi Rizzo , Suleiman Souhlal Subject: Re: td->td_critnest manipulations do not use atomic_add_int ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 18:30:20 -0000 On Tuesday 20 December 2005 11:16 am, Luigi Rizzo wrote: > On Tue, Dec 20, 2005 at 06:34:20AM -0800, Suleiman Souhlal wrote: > > Hello Luigi, > > > > Luigi Rizzo wrote: > > > as in the subject... i see that td->td_critnest (used to determine > > > whether a thread can be preempted or not) is manipulated using > > > plain ++ or -- instruction instead of the atomic_add_int(). > > > > This should be fine as it only gets modified by the current thread. If > > an interrupt comes while we are decreasing td_critnest back to 0, then > > we just don't get preempted immediately, but at the end of our quantum, > > or when someone else tries to preempt us, whichever comes first, which > > should be totally harmless. > > i think that there are still some potential race conditions if > the variable is read from another processor to make a decision > based on its value. It's not, that's the key. It's only read by the current thread. Because of sched_lock being held when a thread context switches (and thus anytime it migrates) and the membars it contains, no other locking is needed for data that only curthread accesses. -- 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 Dec 20 18:50:30 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C645016A422 for ; Tue, 20 Dec 2005 18:50:30 +0000 (GMT) (envelope-from q@galgenberg.net) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5843B43D4C for ; Tue, 20 Dec 2005 18:50:26 +0000 (GMT) (envelope-from q@galgenberg.net) Received: from wrzx30.rz.uni-wuerzburg.de (wrzx30.rz.uni-wuerzburg.de [132.187.1.30]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id 33EED13F94F; Tue, 20 Dec 2005 19:50:25 +0100 (CET) Received: from virusscan (localhost [127.0.0.1]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id 17A149E10F; Tue, 20 Dec 2005 19:50:25 +0100 (CET) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id F3E549C2E1; Tue, 20 Dec 2005 19:50:24 +0100 (CET) Received: from frodo.galgenberg.net (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id E8B9313F94F; Tue, 20 Dec 2005 19:50:24 +0100 (CET) Received: from coyote.q.local (gb-21-237.galgenberg.net [172.16.21.237]) by frodo.galgenberg.net (8.13.1/8.13.1) with ESMTP id jBKIoOIe057528; Tue, 20 Dec 2005 19:50:24 +0100 (CET) (envelope-from q@galgenberg.net) Received: from roadrunner.q.local (roadrunner.q.local [192.168.0.148]) by coyote.q.local (8.13.4/8.13.4) with ESMTP id jBKIoOsw099169; Tue, 20 Dec 2005 19:50:24 +0100 (CET) (envelope-from q@galgenberg.net) Received: from roadrunner.q.local (localhost [127.0.0.1]) by roadrunner.q.local (8.13.4/8.13.4) with ESMTP id jBKIoOcq001975; Tue, 20 Dec 2005 19:50:24 +0100 (CET) (envelope-from q@galgenberg.net) Received: (from q@localhost) by roadrunner.q.local (8.13.4/8.13.4/Submit) id jBKIoNku001974; Tue, 20 Dec 2005 19:50:23 +0100 (CET) (envelope-from q@galgenberg.net) Date: Tue, 20 Dec 2005 19:50:23 +0100 From: Ulrich Spoerlein To: Freddie Cash Message-ID: <20051220185023.GB1029@galgenberg.net> Mail-Followup-To: Freddie Cash , freebsd-current@freebsd.org References: <200512192117.jBJLHE8C057230@lurza.secnetix.de> <200512191513.51287.fcash@ocis.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="96YOpH+ONegL0A3E" Content-Disposition: inline In-Reply-To: <200512191513.51287.fcash@ocis.net> X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) Cc: freebsd-current@freebsd.org Subject: Re: DRM update for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2005 18:50:30 -0000 --96YOpH+ONegL0A3E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Freddie Cash wrote: > > I get 48 fps at 1400x1050x32 -- in software, without any > > hardware 3D acceleration. (It's a 1.6GHz Centrino notebook > > with shared i915 graphics. 2D acceleration is enabled, of > > course.) >=20 > Yep. It's a bog-slow laptop (2.8 GHz Celeron CPU, 1 GB RAM, 40 GB HD=20 > running at ATA33 instead of ATA100, Radeon 7000 GPU). It may be a 2.8=20 > GHz CPU, but it runs like a a 1 GHz, even in Debian Linux. Please observe 'systat -vm' while running glxgears and being idle. How much time is spent for System/Interrupt/User? What are the Interrupt rates? Ulrich Spoerlein --=20 PGP Key ID: F0DB9F44 Encrypted mail welcome! Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 Ok, which part of "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." didn't you understand? --96YOpH+ONegL0A3E Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDqFJvmArGtfDbn0QRAi7cAJ9K1y4Hs9Ir/mYW6BnrRmmn/GuBfACgyPzb 7rUIXfuUZ1JQY53izq8nxZk= =+Hfq -----END PGP SIGNATURE----- --96YOpH+ONegL0A3E-- From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 19:04:10 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DBA216A41F for ; Tue, 20 Dec 2005 19:04:10 +0000 (GMT) (envelope-from julian@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id B31D943D64 for ; Tue, 20 Dec 2005 19:04:09 +0000 (GMT) (envelope-from julian@elischer.org) Received: from unknown (HELO [10.251.17.229]) ([10.251.17.229]) by a50.ironport.com with ESMTP; 20 Dec 2005 11:04:07 -0800 X-IronPort-Anti-Spam-Filtered: true Message-ID: <43A855A5.6070809@elischer.org> Date: Tue, 20 Dec 2005 11:04:05 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.11) Gecko/20050727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo References: <20051220032538.A33093@xorpc.icir.org> In-Reply-To: <20051220032538.A33093@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: td->td_critnest manipulations do not use atomic_add_int ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 19:04:10 -0000 Luigi Rizzo wrote: >as in the subject... i see that td->td_critnest (used to determine >whether a thread can be preempted or not) is manipulated using >plain ++ or -- instruction instead of the atomic_add_int(). > >I wonder if declaring it as volatile and possibly its >usage patterns are enough to make the two things equivalent >on all architectures. > > is td ever != curthread? >cheers >luigi >_______________________________________________ >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 Dec 20 19:22:53 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0455C16A41F; Tue, 20 Dec 2005 19:22:53 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F69843D64; Tue, 20 Dec 2005 19:22:51 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 4230763 for multiple; Tue, 20 Dec 2005 14:21:01 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id jBKJModx008107; Tue, 20 Dec 2005 14:22:50 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 20 Dec 2005 14:22:35 -0500 User-Agent: KMail/1.8.2 References: <20051220032538.A33093@xorpc.icir.org> <43A855A5.6070809@elischer.org> In-Reply-To: <43A855A5.6070809@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512201422.47323.jhb@freebsd.org> X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Luigi Rizzo , Julian Elischer , current@freebsd.org Subject: Re: td->td_critnest manipulations do not use atomic_add_int ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 19:22:53 -0000 On Tuesday 20 December 2005 02:04 pm, Julian Elischer wrote: > Luigi Rizzo wrote: > >as in the subject... i see that td->td_critnest (used to determine > >whether a thread can be preempted or not) is manipulated using > >plain ++ or -- instruction instead of the atomic_add_int(). > > > >I wonder if declaring it as volatile and possibly its > >usage patterns are enough to make the two things equivalent > >on all architectures. > > is td ever != curthread? No. -- 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 Dec 20 19:22:53 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0455C16A41F; Tue, 20 Dec 2005 19:22:53 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F69843D64; Tue, 20 Dec 2005 19:22:51 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 4230763 for multiple; Tue, 20 Dec 2005 14:21:01 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id jBKJModx008107; Tue, 20 Dec 2005 14:22:50 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 20 Dec 2005 14:22:35 -0500 User-Agent: KMail/1.8.2 References: <20051220032538.A33093@xorpc.icir.org> <43A855A5.6070809@elischer.org> In-Reply-To: <43A855A5.6070809@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512201422.47323.jhb@freebsd.org> X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Luigi Rizzo , Julian Elischer , current@freebsd.org Subject: Re: td->td_critnest manipulations do not use atomic_add_int ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 19:22:53 -0000 On Tuesday 20 December 2005 02:04 pm, Julian Elischer wrote: > Luigi Rizzo wrote: > >as in the subject... i see that td->td_critnest (used to determine > >whether a thread can be preempted or not) is manipulated using > >plain ++ or -- instruction instead of the atomic_add_int(). > > > >I wonder if declaring it as volatile and possibly its > >usage patterns are enough to make the two things equivalent > >on all architectures. > > is td ever != curthread? No. -- 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 Dec 20 21:11:05 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D91DD16A41F for ; Tue, 20 Dec 2005 21:11:05 +0000 (GMT) (envelope-from Chris@lainos.org) Received: from mail.neovanglist.net (blackacid.neovanglist.net [69.16.150.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 643C443D58 for ; Tue, 20 Dec 2005 21:11:05 +0000 (GMT) (envelope-from Chris@lainos.org) Received: from localhost (localhost.neovanglist.net [127.0.0.1]) by mail.neovanglist.net (Postfix) with ESMTP id 7D2B36D438 for ; Sat, 17 Dec 2005 17:11:13 -0700 (MST) Received: from mail.neovanglist.net ([127.0.0.1]) by localhost (blackacid.neovanglist.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37315-08 for ; Sat, 17 Dec 2005 17:11:11 -0700 (MST) Received: from melchior (0x5358bc07.bynxx15.adsl-dhcp.tele.dk [83.88.188.7]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail.neovanglist.net (Postfix) with ESMTP id F26ED6D436 for ; Sat, 17 Dec 2005 17:11:10 -0700 (MST) From: Chris Gilbert To: freebsd-current@freebsd.org Date: Sun, 18 Dec 2005 01:07:03 +0100 User-Agent: KMail/1.8.2 References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> <43A4A557.3010600@mac.com> In-Reply-To: <43A4A557.3010600@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512180107.03841.Chris@lainos.org> X-Virus-Scanned: amavisd-new at neovanglist.net Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2005 21:11:06 -0000 On Sunday 18 December 2005 00:55, Chuck Swiger wrote: > YMMV. I burned a 6.0 release from the ISO image, and did a binary upgrade > on an IBM ThinkPad (T.34? maybe), which worked perfectly. All of the 5.x > binaries, including X11, KDE, printing, Mozilla, etc worked just fine. > > Upgrading the ports from there was somewhat annoying, as this guy's machine > had ~400 or so, but deleting them all, and then using "pkg_add -r " works > just fine if you want to grab the latest current binaries. From there you > can portupgrade as usual. > > Now, if you want to talk about upgrading to intermediate patch releases, > you've got a valid point there. :-) I've had some success with this as well, but doing a pkg_add -r then mixing that with ports (if the ports are cvsuped to head and not to the release branch you installed) can cause issues. One particular issue is in regards to gnome/gtk/glib applications. They have some sort of crazy library name bumping for each version, and you will get lots of crap like "libgnomeui.so.400 not found" if you have binary libs/apps from pkg_add which are trying to link to libraries installed via an updated ports. However, this behavior seems to have gotten better recently with the latest glib, I don't see as many libfoo.so.<3 digit number> rather I see stuff like libglade-2.0.so.0. (which is much better!) Maybe this should be directed toward the FreeBSD Gnome team, but it can get really out of hand when you update ports and try to update/install some small gtk app, then it wants to get latest gnomevfs, which will want to update gtk, which will want to update glib.... and then because of the library naming you have to remove every single glib/gtk/gnome app and recompile them all from ports. (can't use packages since they will be out of sync here) I tried installing a small game called gtetrinet a couple weeks ago (with a perfectly functioning GTK/glib install) and ended up spending 4 hours tracking down tons of libs/apps which used these libraries or a library that depends on said libraries. Also, I'm aware that there is a gnome update script... however it's possible for things to go really wrong if a user inadvertently uses portupgrade or a port which gets pulled into this mess. (There was a huge warning label in the glib port at one point saying "DON'T DO THIS USE THE SCRIPT") And that still doesn't solve the problem with desktop users who just want to grab binaries and install them... my Wife was unlucky enough to have this happen to her, and even though she has been using FreeBSD successfully for a few years, it trashed her dependency tree to the point where I just had to nuke most of her applications and recompile everything for her. (Not good!) Perhaps this subject should be moved to another list and focused on what would be a good way to create a stronger package/binary management and updating system for FreeBSD? (That plays nicely with ports, and also handles kernel/world/security updates) -- Regards, Chris Gilbert From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 21:25:14 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C471116A41F for ; Tue, 20 Dec 2005 21:25:14 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71FE243D80 for ; Tue, 20 Dec 2005 21:25:05 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.4/8.13.1) with ESMTP id jBKLP2L5025372 for ; Tue, 20 Dec 2005 13:25:02 -0800 (PST) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.4/8.13.1/Submit) id jBKLP1Ub025371 for freebsd-current@freebsd.org; Tue, 20 Dec 2005 13:25:01 -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: freebsd-current@freebsd.org In-Reply-To: <200512200943.jBK9hZEK081362@lurza.secnetix.de> References: <200512200943.jBK9hZEK081362@lurza.secnetix.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-QboYOkuKNCPBydB8HPS7" Date: Tue, 20 Dec 2005 13:25:01 -0800 Message-Id: <1135113901.75547.43.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2 FreeBSD GNOME Team Port Subject: Re: DRM update for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2005 21:25:14 -0000 --=-QboYOkuKNCPBydB8HPS7 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2005-12-20 at 10:43 +0100, Oliver Fromme wrote: > Eric Anholt wrote: > > Oliver Fromme wrote: > > > Freddie Cash wrote: > > > > Running glxgears at 1024x768x16 gives me a decent 35 fps, compared > > > > to the 1 fps I used to get. :) > > > =20 > > > Uhm. Are you sure that you're running hardware-accelerated > > > OpenGL glxgears? > > > =20 > > > I get 48 fps at 1400x1050x32 -- in software, without any > > > hardware 3D acceleration. (It's a 1.6GHz Centrino notebook > > > with shared i915 graphics. 2D acceleration is enabled, of > > > course.) > >=20 > > glxgears is not a benchmark. >=20 > That's right. I was not suggesting to use it as a real- > world benchmark, but rather as a rough indication whether > hardware acceleration is enabled at all or not. >=20 > If someone gets 1 fps (!) out of glxgears, something > is _seriously_ wrong, even with software rendering. No, that's what I'm trying to say here. There's nothing seriously wrong with 1 fps software glxgears at full screen, or anything wrong at all. I get about 9 fps at 1600x1200x16 on my amd64. 1 fps is totally believable on a different graphics card and a slower cpu. --=20 Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org --=-QboYOkuKNCPBydB8HPS7 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDqHatHUdvYGzw6vcRAv/7AJ4weQyoVt0FkmNO3tlhqiqD23+ZzACcCnCR /RU9OasyQNHywKTetRV5W9w= =zB9z -----END PGP SIGNATURE----- --=-QboYOkuKNCPBydB8HPS7-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 01:57:15 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D5BB416A41F for ; Wed, 21 Dec 2005 01:57:14 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEDF343E23 for ; Wed, 21 Dec 2005 01:36:28 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.4/8.13.4) with ESMTP id jBL1aS02000714 for ; Tue, 20 Dec 2005 17:36:28 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id jBL1aSgc000713 for freebsd-current@freebsd.org; Tue, 20 Dec 2005 17:36:28 -0800 (PST) (envelope-from sgk) Date: Tue, 20 Dec 2005 17:36:28 -0800 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20051221013628.GA653@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: Extremely slow probe of fxp0? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 01:57:15 -0000 I updated an Aug 24 2005 (not-so current) -current up to HEAD, and have observed an extremely slow probe of fxp0 during boot of an SMP AMD64 kernel. The relevant lines from a verbose boot are fxp0: port 0xa000-0xa03f mem 0xfeafa000-0xfeafaff f,0xfeaa0000-0xfeabffff irq 18 at device 8.0 on pci3 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfeafa000 fxp0: using memory space register mapping (6.5 minutes or longer pause here) fxp0: PCI IDs: 8086 1229 8086 1040 0010 fxp0: Dynamic Standby mode is disabled miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:e0:81:2a:59:e7 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 51 fxp0: [MPSAFE] The full dmesg follows the sig. -- Steve 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 7.0-CURRENT #0: Tue Dec 20 16:05:59 PST 2005 root@troutmask.apl.washington.edu:/mnt1/obj/mnt1/src/sys/SPEW Preloaded elf kernel "/boot/kernel/kernel" at 0xffffffff80746000. ACPI APIC Table: Calibrating clock(s) ... i8254 clock: 1193046 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2193676782 Hz CPU: AMD Opteron(tm) Processor 248 (2193.68-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0xf58 Stepping = 8 Features=0x78bfbff AMD Features=0xe0500800 L1 2MB data TLB: 8 entries, fully associative L1 2MB instruction TLB: 8 entries, fully associative L1 4KB data TLB: 32 entries, fully associative L1 4KB instruction TLB: 32 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 2MB unified TLB: 0 entries, disabled/not present L2 4KB data TLB: 512 entries, 4-way associative L2 4KB instruction TLB: 512 entries, 4-way associative L2 unified cache: 1024 kbytes, 64 bytes/line, 1 lines/tag, 16-way associative usable memory = 12809666560 (12216 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009bfff, 634880 bytes (155 pages) 0x000000000084b000 - 0x00000000fbfeffff, 4219097088 bytes (1030053 pages) 0x0000000100000000 - 0x00000002e97bbfff, 8212168704 bytes (2004924 pages) avail memory = 12420374528 (11844 MB) 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 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: Found IO APIC ID 3, Interrupt 24 at 0xfebff000 ioapic1: intpin 0 -> PCI IRQ 24 (level, low) ioapic1: intpin 1 -> PCI IRQ 25 (level, low) ioapic1: intpin 2 -> PCI IRQ 26 (level, low) ioapic1: intpin 3 -> PCI IRQ 27 (level, low) MADT: Found IO APIC ID 4, Interrupt 28 at 0xfebfe000 ioapic2: intpin 0 -> PCI IRQ 28 (level, low) ioapic2: intpin 1 -> PCI IRQ 29 (level, low) ioapic2: intpin 2 -> PCI IRQ 30 (level, low) ioapic2: intpin 3 -> PCI IRQ 31 (level, low) MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: Forcing active-low polarity and level trigger for SCI ioapic0: intpin 9 polarity: low ioapic0: intpin 9 trigger: level ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-27 on motherboard ioapic2 irqs 28-31 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00040010 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000000 err: 0x0001000f pcm: 0x00010000 mem: null: nfslock: pseudo-device random: io: acpi0: on motherboard ioapic0: routing intpin 9 (ISA IRQ 9) to vector 48 acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80023000 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 1 2 3 4 5 6 [class=060400] [hdr=01] is there (id=74601022) AcpiOsDerivePciId: bus 0 dev 7 func 0 AcpiOsDerivePciId: bus 0 dev 7 func 1 AcpiOsDerivePciId: bus 0 dev 7 func 3 acpi0: Power Button (fixed) AcpiOsDerivePciId: bus 0 dev 10 func 0 AcpiOsDerivePciId: bus 0 dev 11 func 0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 3 4 5 6 7 9 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 9 10 11 12 14 15 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 15 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 15 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 9 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 9 10 11 12 14 15 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 9 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 9 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 ACPI timer: 1/2 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 0x5008-0x500b on acpi0 cpu0: on acpi0 acpi_throttle0: on cpu0 acpi_throttle0: P_CNT from P_BLK 0x5010 cpu1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x1022, dev=0x7460, revid=0x07 bus=0, slot=6, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0117, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x0a (2500 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x7468, revid=0x05 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x7469, revid=0x03 bus=0, slot=7, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000ffa0, size 4, port disabled found-> vendor=0x1022, dev=0x746a, revid=0x02 bus=0, slot=7, func=2 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=9 map[10]: type 4, range 32, base 0000cc00, size 5, enabled pcib0: matched entry for 0.7.INTD pcib0: slot 7 INTD hardwired to IRQ 19 found-> vendor=0x1022, dev=0x746b, revid=0x05 bus=0, slot=7, func=3 class=06-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0000, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x7450, revid=0x12 bus=0, slot=10, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0117, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x05 (1250 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x7451, revid=0x01 bus=0, slot=10, func=1 class=08-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 1, range 64, base febff000, size 12, enabled found-> vendor=0x1022, dev=0x7450, revid=0x12 bus=0, slot=11, func=0 class=06-04-00, hdrtype=0x01, mfdev=1 cmdreg=0x0116, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x05 (1250 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x7451, revid=0x01 bus=0, slot=11, func=1 class=08-00-10, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 1, range 64, base febfe000, size 12, enabled found-> vendor=0x1022, dev=0x1100, revid=0x00 bus=0, slot=24, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 bus=0, slot=24, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 bus=0, slot=24, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 bus=0, slot=24, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1100, revid=0x00 bus=0, slot=25, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1101, revid=0x00 bus=0, slot=25, func=1 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1102, revid=0x00 bus=0, slot=25, func=2 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x1022, dev=0x1103, revid=0x00 bus=0, slot=25, func=3 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib1: at device 6.0 on pci0 pcib1: secondary bus 3 pcib1: subordinate bus 3 pcib1: I/O decode 0x9000-0xbfff pcib1: memory decode 0xfc900000-0xfeafffff pcib1: prefetched decode 0xfff00000-0xfffff pci3: on pcib1 pci3: physical bus=3 found-> vendor=0x1022, dev=0x7464, revid=0x0b bus=3, slot=0, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0117, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns) intpin=d, irq=9 map[10]: type 1, range 32, base feafc000, size 12, enabled pcib1: (null) requested memory range 0xfeafc000-0xfeafcfff: good pcib1: matched entry for 3.0.INTD pcib1: slot 0 INTD hardwired to IRQ 19 found-> vendor=0x1022, dev=0x7464, revid=0x0b bus=3, slot=0, func=1 class=0c-03-10, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns) intpin=d, irq=9 map[10]: type 1, range 32, base feafd000, size 12, enabled pcib1: (null) requested memory range 0xfeafd000-0xfeafdfff: good pcib1: matched entry for 3.0.INTD pcib1: slot 0 INTD hardwired to IRQ 19 found-> vendor=0x9004, dev=0x8178, revid=0x00 bus=3, slot=4, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0280, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x08 (2000 ns) intpin=a, irq=10 map[10]: type 4, range 32, base 0000b400, size 8, enabled pcib1: (null) requested I/O range 0xb400-0xb4ff: in range map[14]: type 1, range 32, base feafe000, size 12, enabled pcib1: (null) requested memory range 0xfeafe000-0xfeafefff: good pcib1: matched entry for 3.4.INTA pcib1: slot 4 INTA hardwired to IRQ 16 found-> vendor=0x1095, dev=0x3114, revid=0x02 bus=3, slot=5, func=0 class=01-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=9 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000bc00, size 3, enabled pcib1: (null) requested I/O range 0xbc00-0xbc07: in range map[14]: type 4, range 32, base 0000b000, size 2, enabled pcib1: (null) requested I/O range 0xb000-0xb003: in range map[18]: type 4, range 32, base 0000ac00, size 3, enabled pcib1: (null) requested I/O range 0xac00-0xac07: in range map[1c]: type 4, range 32, base 0000a800, size 2, enabled pcib1: (null) requested I/O range 0xa800-0xa803: in range map[20]: type 4, range 32, base 0000a400, size 4, enabled pcib1: (null) requested I/O range 0xa400-0xa40f: in range map[24]: type 1, range 32, base feafbc00, size 10, enabled pcib1: (null) requested memory range 0xfeafbc00-0xfeafbfff: good pcib1: matched entry for 3.5.INTA pcib1: slot 5 INTA hardwired to IRQ 19 found-> vendor=0x1002, dev=0x4752, revid=0x27 bus=3, slot=6, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0087, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base fd000000, size 24, enabled pcib1: (null) requested memory range 0xfd000000-0xfdffffff: good map[14]: type 4, range 32, base 0000b800, size 8, enabled pcib1: (null) requested I/O range 0xb800-0xb8ff: in range map[18]: type 1, range 32, base feaff000, size 12, enabled pcib1: (null) requested memory range 0xfeaff000-0xfeafffff: good pcib1: matched entry for 3.6.INTA pcib1: slot 6 INTA hardwired to IRQ 18 found-> vendor=0x8086, dev=0x1229, revid=0x10 bus=3, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0290, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x08 (2000 ns), maxlat=0x38 (14000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base feafa000, size 12, enabled pcib1: (null) requested memory range 0xfeafa000-0xfeafafff: good map[14]: type 4, range 32, base 0000a000, size 6, enabled pcib1: (null) requested I/O range 0xa000-0xa03f: in range map[18]: type 1, range 32, base feaa0000, size 17, enabled pcib1: (null) requested memory range 0xfeaa0000-0xfeabffff: good pcib1: matched entry for 3.8.INTA pcib1: slot 8 INTA hardwired to IRQ 18 ohci0: mem 0xfeafc000-0xfeafcfff irq 19 at device 0.0 on pci3 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfeafc000 ioapic0: routing intpin 19 (PCI IRQ 19) to vector 49 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xfeafd000-0xfeafdfff irq 19 at device 0.1 on pci3 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfeafd000 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: AMD OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ahc0: port 0xb400-0xb4ff mem 0xfeafe000-0xfeafefff irq 16 at device 4.0 on pci3 ahc0: Defaulting to MEMIO off ahc0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xb400 ahc0: Enabling 39Bit Addressing ahc0: Reading SEEPROM...done. ahc0: internal 50 cable is present ahc0: external cable not present ahc0: BIOS eeprom is present ahc0: Low byte termination Enabled ahc0: Downloading Sequencer Program... 450 instructions downloaded ahc0: Features 0x10001, Bugs 0x25, Flags 0x21481540 ioapic0: routing intpin 16 (PCI IRQ 16) to vector 50 ahc0: [GIANT-LOCKED] aic7880: Ultra Single Channel A, SCSI Id=7, 16/253 SCBs pci3: at device 5.0 (no driver attached) vgapci0: port 0xb800-0xb8ff mem 0xfd000000-0xfdffffff,0xfeaff000-0xfeafffff irq 18 at device 6.0 on pci3 fxp0: port 0xa000-0xa03f mem 0xfeafa000-0xfeafafff,0xfeaa0000-0xfeabffff irq 18 at device 8.0 on pci3 fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfeafa000 fxp0: using memory space register mapping fxp0: PCI IDs: 8086 1229 8086 1040 0010 fxp0: Dynamic Standby mode is disabled miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: bpf attached fxp0: Ethernet address: 00:e0:81:2a:59:e7 ioapic0: routing intpin 18 (PCI IRQ 18) to vector 51 fxp0: [MPSAFE] isab0: at device 7.0 on pci0 isa0: on isab0 pci0: at device 7.1 (no driver attached) pci0: at device 7.2 (no driver attached) amdpm0: port 0x50e0-0x50ff at device 7.3 on pci0 smbus0: on amdpm0 smb0: on smbus0 pcib2: at device 10.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0x8000-0x8fff pcib2: memory decode 0xfc600000-0xfc8fffff pcib2: prefetched decode 0xff500000-0xff5fffff pci2: on pcib2 pci2: physical bus=2 found-> vendor=0x9005, dev=0x801d, revid=0x10 bus=2, slot=6, func=0 class=01-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0117, statreg=0x0430, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x28 (10000 ns), maxlat=0x19 (6250 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit map[10]: type 4, range 32, base 00008000, size 8, enabled pcib2: (null) requested I/O range 0x8000-0x80ff: in range map[14]: type 1, range 64, base fc8fc000, size 13, enabled pcib2: (null) requested memory range 0xfc8fc000-0xfc8fdfff: good map[1c]: type 4, range 32, base 00008c00, size 8, enabled pcib2: (null) requested I/O range 0x8c00-0x8cff: in range pcib2: matched entry for 2.6.INTA pcib2: slot 6 INTA hardwired to IRQ 24 found-> vendor=0x9005, dev=0x801d, revid=0x10 bus=2, slot=6, func=1 class=01-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0117, statreg=0x0430, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x28 (10000 ns), maxlat=0x19 (6250 ns) intpin=b, irq=15 powerspec 2 supports D0 D3 current D0 MSI supports 2 messages, 64 bit map[10]: type 4, range 32, base 00008800, size 8, enabled pcib2: (null) requested I/O range 0x8800-0x88ff: in range map[14]: type 1, range 64, base fc8fe000, size 13, enabled pcib2: (null) requested memory range 0xfc8fe000-0xfc8fffff: good map[1c]: type 4, range 32, base 00008400, size 8, enabled pcib2: (null) requested I/O range 0x8400-0x84ff: in range pcib2: matched entry for 2.6.INTB pcib2: slot 6 INTB hardwired to IRQ 25 ahd0: port 0x8000-0x80ff,0x8c00-0x8cff mem 0xfc8fc000-0xfc8fdfff irq 24 at device 6.0 on pci2 ahd0: Defaulting to MEMIO on ahd0: Reserved 0x2000 bytes for rid 0x14 type 3 at 0xfc8fc000 ahd0: Enabling 39Bit Addressing ahd0: Reading VPD from SEEPROM...ahd0: VPD parsing successful ahd0: Reading SEEPROM...done. ahd0: STPWLEVEL is on ahd0: Manual Primary Termination ahd0: Manual Secondary Termination ahd0: Primary High byte termination Enabled ahd0: Primary Low byte termination Enabled ahd0: Secondary High byte termination Disabled ahd0: Secondary Low byte termination Disabled ahd0: Downloading Sequencer Program... 697 instructions downloaded ahd0: Features 0x3c101, Bugs 0x740002, Flags 0x143f1 ioapic1: routing intpin 0 (PCI IRQ 24) to vector 52 ahd0: [GIANT-LOCKED] aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs ahd1: port 0x8800-0x88ff,0x8400-0x84ff mem 0xfc8fe000-0xfc8fffff irq 25 at device 6.1 on pci2 ahd1: Defaulting to MEMIO on ahd1: Reserved 0x2000 bytes for rid 0x14 type 3 at 0xfc8fe000 ahd1: Enabling 39Bit Addressing ahd1: Reading VPD from SEEPROM...ahd1: VPD parsing successful ahd1: Reading SEEPROM...done. ahd1: STPWLEVEL is on ahd1: Manual Primary Termination ahd1: Manual Secondary Termination ahd1: Primary High byte termination Enabled ahd1: Primary Low byte termination Enabled ahd1: Secondary High byte termination Disabled ahd1: Secondary Low byte termination Disabled ahd1: Downloading Sequencer Program... 697 instructions downloaded ahd1: Features 0x3c101, Bugs 0x740002, Flags 0x143f0 ioapic1: routing intpin 1 (PCI IRQ 25) to vector 53 ahd1: [GIANT-LOCKED] aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI-X 67-100Mhz, 512 SCBs pci0: at device 10.1 (no driver attached) pcib3: at device 11.0 on pci0 pcib3: secondary bus 1 pcib3: subordinate bus 1 pcib3: I/O decode 0x0-0x0 pcib3: memory decode 0xfff00000-0xfffff pcib3: prefetched decode 0xfff00000-0xfffff pci1: on pcib3 pci1: physical bus=1 pci0: at device 11.1 (no driver attached) acpi_button0: on acpi0 atkbdc0: port 0x60,0x64 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 ioapic0: routing intpin 1 (ISA IRQ 1) to vector 54 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ psmcpnp0: irq 12 on acpi0 psm0: current command byte:0065 psm0: irq 12 on atkbdc0 ioapic0: routing intpin 12 (ISA IRQ 12) to vector 55 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ioapic0: routing intpin 4 (ISA IRQ 4) to vector 56 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0 0 0 0 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ioapic0: routing intpin 3 (ISA IRQ 3) to vector 57 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 ioapic0: routing intpin 6 (ISA IRQ 6) to vector 58 fdc0: [MPSAFE] fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: using extended I/O port range ppc0: SPP ppc0: port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ioapic0: routing intpin 7 (ISA IRQ 7) to vector 59 acpi_hpet0: iomem 0xfec01000-0xfec013ff irq 0,8 on acpi0 acpi_hpet0: Vendor: 0x1022 acpi_hpet0: Leg_Route_Cap: 1 acpi_hpet0: Count_Size_Cap: 0 acpi_hpet0: Num_Tim_Cap: 8 acpi_hpet0: Rev_id: 0x3 acpi_hpet0: Period: 69841279 fs (14318180 Hz) acpi_hpet0: HPET attach Timecounter "HPET" frequency 14318180 Hz quality -200 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 sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it ahc_isa_probe 0: ioport 0xc00 alloc failed ahc_isa_probe 8: ioport 0x8c00 alloc failed ahc_isa_probe 10: ioport 0xac00 alloc failed ahc_isa_probe 11: ioport 0xbc00 alloc failed ahc_isa_probe 12: ioport 0xcc00 alloc failed isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcc7ff,0xd5800-0xd9fff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <8 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 isa_probe_children: probing PnP devices Device configuration finished. Reducing kern.maxvnodes 243854 -> 100000 procfs registered linprocfs registered lapic: Divisor 2, Frequency 99712590 hz Timecounter "TSC" frequency 2193676782 Hz quality -100 Timecounters tick every 1.000 msec Linux ELF exec handler installed lo0: bpf attached Waiting 3 seconds for SCSI devices to settle (noperiph:ahd0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. (noperiph:ahd1:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted. ahd0: Selection Timeout on A:3. 0 SCBs aborted ahd1: Selection Timeout on A:0. 0 SCBs aborted ahc0: Selection Timeout on A:3. 0 SCBs aborted ahd0: Selection Timeout on A:4. 0 SCBs aborted ahd1: Selection Timeout on A:1. 0 SCBs aborted ahc0: Selection Timeout on A:6. 0 SCBs aborted ahd0: Selection Timeout on A:5. 0 SCBs aborted ahd1: Selection Timeout on A:3. 0 SCBs aborted ahc0: Selection Timeout on A:1. 0 SCBs aborted ahd0: Selection Timeout on A:11. 0 SCBs aborted ahd1: Selection Timeout on A:4. 0 SCBs aborted ahc0: Selection Timeout on A:2. 0 SCBs aborted (probe15:ahc0:0:0:0): Retrying Command (ahc0:A:4:0): Sending SDTR period 19, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f ahc0: target 4 synchronous at 10.0MHz, offset = 0xf (ahc0:A:5:0): Sending SDTR period 19, offset f (ahc0:A:5:0): Received SDTR period 32, offset f Filtered to period 32, offset f ahc0: target 5 synchronous at 5.0MHz, offset = 0xf (ahc0:A:4:0): Sending SDTR period 19, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:5:0): Sending SDTR period 32, offset f (ahc0:A:5:0): Received SDTR period 32, offset f Filtered to period 32, offset f (ahc0:A:0:0): Sending SDTR period 19, offset f (ahc0:A:0:0): Received SDTR period 19, offset f Filtered to period 19, offset f ahc0: target 0 synchronous at 10.0MHz, offset = 0xf ahd0: Selection Timeout on A:12. 0 SCBs aborted ahd1: Selection Timeout on A:5. 0 SCBs aborted ahd0: Selection Timeout on A:13. 0 SCBs aborted ahd1: Selection Timeout on A:6. 0 SCBs aborted ahd0: Selection Timeout on A:1. 0 SCBs aborted ahd1: Selection Timeout on A:8. 0 SCBs aborted ahd0: Selection Timeout on A:2. 0 SCBs aborted ahd1: Selection Timeout on A:9. 0 SCBs aborted ahd0: Selection Timeout on A:6. 0 SCBs aborted ahd1: Selection Timeout on A:10. 0 SCBs aborted ahd0: Selection Timeout on A:8. 0 SCBs aborted ahd1: Selection Timeout on A:11. 0 SCBs aborted ahd0: Selection Timeout on A:9. 0 SCBs aborted ahd1: Selection Timeout on A:12. 0 SCBs aborted ahd0: Selection Timeout on A:10. 0 SCBs aborted ahd1: Selection Timeout on A:13. 0 SCBs aborted ahd0: Selection Timeout on A:14. 0 SCBs aborted ahd1: Selection Timeout on A:14. 0 SCBs aborted ahd0: Selection Timeout on A:15. 0 SCBs aborted (probe0:ahd0:0:0:0): Retrying Command (ahd0:A:0:0): Sending PPR bus_width 1, period 8, offset fe, ppr_options ff ahd1: Selection Timeout on A:15. 0 SCBs aborted (ahd0:A:0:0): Received PPR width 1, period 8, offset 3f,options ff Filtered to width 1, period 8, offset 3f, options ff ahd0: target 0 using 16bit transfers ahd0: target 0 synchronous with period = 0x8, offset = 0x3f(RDSTRM|DT|IU|RTI|QAS) ahd1: Selection Timeout on A:2. 0 SCBs aborted pass0 at ahd0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-3 device pass0: Serial Number 3HZ805ZE00007436F79B pass0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled pass1 at ahc0 bus 0 target 0 lun 0 pass1: Fixed Direct Access SCSI-3 device pass1: Serial Number 3BN12XT600007124NH7V pass1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled pass2 at ahc0 bus 0 target 4 lun 0 pass2: Removable CD-ROM SCSI-2 device pass2: Serial Number 3 pass2: 10.000MB/s transfers (10.000MHz, offset 15) pass3 at ahc0 bus 0 target 5 lun 0 pass3: Removable Sequential Access SCSI-2 device pass3: Serial Number CX837T0309 pass3: 5.000MB/s transfers (5.000MHz, offset 15) sa0 at ahc0 bus 0 target 5 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: Serial Number CX837T0309 sa0: 5.000MB/s transfers (5.000MHz, offset 15) da1 at ahc0 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-3 device da1: Serial Number 3BN12XT600007124NH7V da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da1: 8761MB (17942584 512 byte sectors: 255H 63S/T 1116C) da0 at ahd0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: Serial Number 3HZ805ZE00007436F79B da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 70007MB (143374744 512 byte sectors: 255H 63S/T 8924C) GEOM: new disk da0(ahc0:A:4:0): Sending SDTR period 19, offset f GEOM: n(ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f ew disk da1(cd0:ahc0:0:4:0): Retrying Command GEOM: new disk cd0 SMP: AP CPU #1 Launched! cpu1 AP: ID: 0x01000000 VER: 0x00040010 LDR: 0x02000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000200ef 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 9 (ISA IRQ 9) to cluster 0 ioapic0: routing intpin 12 (ISA IRQ 12) to cluster 0 ioapic0: routing intpin 16 (PCI IRQ 16) to cluster 0 ioapic0: routing intpin 18 (PCI IRQ 18) to cluster 0 ioapic0: routing intpin 19 (PCI IRQ 19) to cluster 0 ioapic1: routing intpin 0 (PCI IRQ 24) to cluster 0 ioapic1: routing intpin 1 (PCI IRQ 25) to cluster 0 (ahc0:A:4:0): Sending SDTR period 19, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:4:0): Sending SDTR period 19, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:4:0): Sending SDTR period 19, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:4:0): Sending SDTR period 19, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:4:0): Sending SDTR period 19, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:4:0): Sending SDTR period 19, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:4:0): Sending SDTR period 19, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:4:0): Sending SDTR period 19, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:4:0): Sending SDTR period 19, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:4:0): Sending SDTR period 19, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f (ahc0:A:4:0): Sending SDTR period 19, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: Serial Number 3 cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: cd present [190950 x 2048 byte records] (ahc0:A:4:0): Sending SDTR period 19, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): ILLEGAL REQUEST asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): ILLEGAL REQUEST asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track Unretryable error (cd0:ahc0:0:4:0): error 6 (cd0:ahc0:0:4:0): Unretryable Error (cd0:ahc0:0:4:0): cddone: got error 0x6 back (ahc0:A:4:0): Sending SDTR period 19, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): ILLEGAL REQUEST asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 1 0 0 1 0 (cd0:ahc0:0:4:0): ILLEGAL REQUEST asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track Unretryable error (cd0:ahc0:0:4:0): error 6 (cd0:ahc0:0:4:0): Unretryable Error (cd0:ahc0:0:4:0): cddone: got error 0x6 back (ahc0:A:4:0): Sending SDTR period 19, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): ILLEGAL REQUEST asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): ILLEGAL REQUEST asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track Unretryable error (cd0:ahc0:0:4:0): error 6 (cd0:ahc0:0:4:0): Unretryable Error (cd0:ahc0:0:4:0): cddone: got error 0x6 back (ahc0:A:4:0): Sending SDTR period 19, offset f (ahc0:A:4:0): Received SDTR period 19, offset f Filtered to period 19, offset f (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): CAM Status: SCSI Status Error (cd0:ahc0:0:4:0): SCSI Status: Check Condition (cd0:ahc0:0:4:0): ILLEGAL REQUEST asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track (cd0:ahc0:0:4:0): (cd0:ahc0:0:4:0): READ(10). CDB: 28 0 0 0 0 0 0 0 1 0 (cd0:ahc0:0:4:0): ILLEGAL REQUEST asc:64,0 (cd0:ahc0:0:4:0): Illegal mode for this track Unretryable error (cd0:ahc0:0:4:0): error 6 (cd0:ahc0:0:4:0): Unretryable Error (cd0:ahc0:0:4:0): cddone: got error 0x6 back Trying to mount root from ufs:/dev/da0s1a start_init: trying /sbin/init (da0:ahd0:0:0:0): Request Requeued (da0:ahd0:0:0:0): Retrying Command (da0:ahd0:0:0:0): Queue Full (da0:ahd0:0:0:0): tagged openings now 63 (da0:ahd0:0:0:0): Retrying Command From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 02:26:13 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 037BC16A423; Wed, 21 Dec 2005 02:26:12 +0000 (GMT) (envelope-from huang@gddsn.org.cn) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9817743D80; Wed, 21 Dec 2005 02:26:11 +0000 (GMT) (envelope-from huang@gddsn.org.cn) Received: from [192.168.168.129] (hwh [192.168.168.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gddsn.org.cn (Postfix) with ESMTP id D60ED38CB41; Wed, 21 Dec 2005 10:26:09 +0800 (CST) Message-ID: <43A8BD3F.2010006@gddsn.org.cn> Date: Wed, 21 Dec 2005 10:26:07 +0800 From: Huang wen hui User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051212) X-Accept-Language: zh-cn,zh MIME-Version: 1.0 To: current@freebsd.org, openoffice@FreeBSD.org Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Cc: Subject: [openoffice]no suitable windowing system found, exiting. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 02:26:14 -0000 hi, I used openoffice 2.0R from ftp://ooopackages.good-day.net/pub/OpenOffice.org/FreeBSD/. On recent CURRENT, got this problem: no suitable windowing system found, exiting. I try to back out kan's ELF symbol versioning and solve this problem. Does recompile openoffice can solve this problem? I ask becasue compile openoffice is too long. --hwh From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 03:04:11 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A211616A41F for ; Wed, 21 Dec 2005 03:04:11 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 584CA43D5F for ; Wed, 21 Dec 2005 03:04:09 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so31482wxc for ; Tue, 20 Dec 2005 19:04:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dFacGpSNPqoJsDQcWwQOzr9OKV/faShSBez6CfGW7pqoniGRTxoryKTVkZvkgI/xlMD9oVqWYkfuvNsR7YO9wdjsS3r7biyF5O60TO5yIatvn7Mo6hn2uiN7I9Td1S6sFppiu9Zd/U0eyiz1969Qx5SVBPIu2ffDh5o18tE5rhg= Received: by 10.70.28.17 with SMTP id b17mr239548wxb; Tue, 20 Dec 2005 19:04:08 -0800 (PST) Received: by 10.70.105.13 with HTTP; Tue, 20 Dec 2005 19:04:08 -0800 (PST) Message-ID: <84dead720512201904q6dbe5e6er6925282d4d320bee@mail.gmail.com> Date: Wed, 21 Dec 2005 08:34:08 +0530 From: Joseph Koshy To: John Baldwin In-Reply-To: <200512201422.47323.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20051220032538.A33093@xorpc.icir.org> <43A855A5.6070809@elischer.org> <200512201422.47323.jhb@freebsd.org> Cc: Luigi Rizzo , freebsd-current@freebsd.org Subject: Re: td->td_critnest manipulations do not use atomic_add_int ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 03:04:11 -0000 lr> is td ever !=3D curthread? jhb> No. I don't think we KASSERT() this in enough places in the code though. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 03:15:28 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C36916A41F for ; Wed, 21 Dec 2005 03:15:28 +0000 (GMT) (envelope-from rmtodd@ichotolot.servalan.com) Received: from mx2.synetsystems.com (mx2.synetsystems.com [216.226.140.79]) by mx1.FreeBSD.org (Postfix) with ESMTP id B26F143D55 for ; Wed, 21 Dec 2005 03:15:27 +0000 (GMT) (envelope-from rmtodd@ichotolot.servalan.com) Received: by mx2.synetsystems.com (Postfix, from userid 66) id 31ABC290; Tue, 20 Dec 2005 22:15:26 -0500 (EST) Received: from localhost ([127.0.0.1]:49259 helo=ichotolot.servalan.com) by servalan.servalan.com with esmtp (Exim 4.54 (FreeBSD)) id 1EotYU-0002db-1i for current@freebsd.org; Tue, 20 Dec 2005 20:18:14 -0600 To: current@freebsd.org Date: Tue, 20 Dec 2005 20:18:13 -0600 From: Richard Todd Message-Id: <20051221031526.31ABC290@mx2.synetsystems.com> Cc: Subject: Bug in latest rev kern_acct.c: panic: Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 03:15:28 -0000 I've been getting this panic a good bit recently after updating -current sources a couple days ago. The panic occurs in the acctwatch() callout routine run from the clock ithread, apparently when it tries to sleep on a lock (which is, I gather, verboten in ithreads.) The panics seemed to occur randomly but, on reflection, always occured when 1) there was a good bit of system activity and 2) I had just done something to allocate or free enough space on /usr to cause accounting to be either suspended or resumed. and thus would cause the acctwatch() routine to have to do something. "make clean; make" in a big port seemed to be fairly effective in triggering the bug. :-) My previous kernel, which dated from Oct 24, didn't have this problem, which helps point suspicion at the latest rev of kern_acct.c (rev 1.76, date: 2005/11/12 10:45:13) which involved a bunch of changes in the lock handling of kernel accounting. GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". Unread portion of the kernel message buffer: panic: Trying sleep, but thread marked as sleeping prohibited cpuid = 1 KDB: stack backtrace: kdb_backtrace(100,c3b7f900,c3b7f900,c0976100,c096f6a8) at kdb_backtrace+0x29 panic(c08a19c6,0,c096f6a8,c0970598,d85f0a14) at panic+0x114 sleepq_add(c096f6a8,c0970598,c089a4ab,1,c0970598,0,c089a875,96) at sleepq_add+0x8c cv_wait_unlock(c096f6a8,c0970598,180,d85f0a4c,c096f680) at cv_wait_unlock+0x171 cv_wait(c096f6a8,c0970598,0,c3b7c480,c3ddb1c0) at cv_wait+0x36 _sx_xlock(c096f680,c089a5a2,180) at _sx_xlock+0x68 acctwatch(0) at acctwatch+0x20 softclock(0) at softclock+0x22b ithread_execute_handlers(c3b7e8b0,c3b7c480) at ithread_execute_handlers+0xe6 ithread_loop(c3b488a0,d85f0d38,c3b488a0,c065098c,0) at ithread_loop+0x67 fork_exit(c065098c,c3b488a0,d85f0d38) at fork_exit+0xa4 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd85f0d6c, ebp = 0 --- Uptime: 49m58s Dumping 637 MB (2 chunks) chunk 0: 1MB (159 pages) ... ok chunk 1: 637MB (163072 pages) 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 #0 doadump () at pcpu.h:165 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc0663880 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399 #2 0xc0663b95 in panic ( fmt=0xc08a19c6 "Trying sleep, but thread marked as sleeping prohibited") at /usr/src/sys/kern/kern_shutdown.c:555 #3 0xc06830fc in sleepq_add (wchan=0xc096f6a8, lock=0xc0970598, wmesg=0x0, flags=1) at /usr/src/sys/kern/subr_sleepqueue.c:273 #4 0xc063dd31 in cv_wait_unlock (cvp=0xc096f6a8, mp=0xc0970598) at /usr/src/sys/kern/kern_condvar.c:152 #5 0xc063db9a in cv_wait (cvp=0xc096f6a8, mp=0xc0970598) at /usr/src/sys/kern/kern_condvar.c:112 #6 0xc06697cc in _sx_xlock (sx=0xc096f680, file=0xc089a5a2 "/usr/src/sys/kern/kern_acct.c", line=384) at /usr/src/sys/kern/kern_sx.c:188 #7 0xc063bcdc in acctwatch (a=0x0) at /usr/src/sys/kern/kern_acct.c:384 #8 0xc0670bf7 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:290 #9 0xc06508c2 in ithread_execute_handlers (p=0xc3b7e8b0, ie=0xc3b7c480) at /usr/src/sys/kern/kern_intr.c:662 #10 0xc06509f3 in ithread_loop (arg=0xc3b488a0) at /usr/src/sys/kern/kern_intr.c:745 #11 0xc064fb54 in fork_exit (callout=0xc065098c , arg=0xc3b488a0, frame=0xd85f0d38) at /usr/src/sys/kern/kern_fork.c:790 #12 0xc081ac7c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:198 (kgdb) fr 9 #9 0xc06508c2 in ithread_execute_handlers (p=0xc3b7e8b0, ie=0xc3b7c480) at /usr/src/sys/kern/kern_intr.c:662 662 ih->ih_handler(ih->ih_argument); (kgdb) p *p $1 = {p_list = {le_next = 0xc3b7eadc, le_prev = 0xc3b7e684}, p_ksegrps = { tqh_first = 0xc3b81d80, tqh_last = 0xc3b81d84}, p_threads = { tqh_first = 0xc3b7f900, tqh_last = 0xc3b7f908}, p_suspended = { tqh_first = 0x0, tqh_last = 0xc3b7e8c8}, p_ucred = 0xc3b79100, p_fd = 0xc3b85200, p_fdtol = 0x0, p_stats = 0xc3b67a00, p_limit = 0xc3b7a100, p_sigacts = 0xc3b8c000, p_flag = 524, p_sflag = 1, p_state = PRS_NORMAL, p_pid = 12, p_hash = {le_next = 0x0, le_prev = 0xc3b73030}, p_pglist = {le_next = 0xc3b7eadc, le_prev = 0xc3b7e6d4}, p_pptr = 0xc096f0c0, p_sibling = { le_next = 0xc3b7eadc, le_prev = 0xc3b7e6e0}, p_children = { lh_first = 0x0}, p_mtx = {mtx_object = {lo_class = 0xc0931b24, lo_name = 0xc089df1e "process lock", lo_type = 0xc089df1e "process lock", lo_flags = 4390912, lo_witness_data = {lod_list = {stqe_next = 0xc0981260}, lod_witness = 0xc0981260}}, mtx_lock = 4, mtx_recurse = 0}, p_ksi = 0x0, p_sigqueue = {sq_signals = {__bits = {0, 0, 0, 0}}, sq_list = { tqh_first = 0x0, tqh_last = 0xc3b7e948}, sq_proc = 0xc3b7e8b0, sq_flags = 1}, p_oppid = 0, p_vmspace = 0xc096f460, p_swtime = 2986, p_realtimer = {it_interval = {tv_sec = 0, tv_usec = 0}, it_value = { tv_sec = 0, tv_usec = 0}}, p_rux = {rux_runtime = {sec = 59, frac = 4151612463131724764}, rux_uticks = 0, rux_sticks = 0, rux_iticks = 157, rux_uu = 0, rux_su = 191765, rux_iu = 58831433}, p_crux = {rux_runtime = {sec = 0, frac = 0}, rux_uticks = 0, rux_sticks = 0, rux_iticks = 0, rux_uu = 0, rux_su = 0, rux_iu = 0}, p_profthreads = 0, p_maxthrwaits = 0, p_traceflag = 0, p_tracevp = 0x0, p_tracecred = 0x0, p_textvp = 0x0, p_lock = 1 '\001', p_sigiolst = {slh_first = 0x0}, p_sigparent = 20, p_sig = 0, p_code = 0, p_stops = 0, p_stype = 0, p_step = 0 '\0', p_pfsflags = 0 '\0', p_nlminfo = 0x0, p_aioinfo = 0x0, p_singlethread = 0x0, p_suspcount = 0, p_xthread = 0x0, p_boundary_count = 0, p_procscopegrp = 0x0, p_pendingcnt = 0, p_itimers = 0x0, p_magic = 3203398350, p_comm = "swi4: clock sio\000\000\000\000", p_pgrp = 0xc096f600, p_sysent = 0xc092cb80, p_args = 0x0, p_cpulimit = 9223372036854775807, p_nice = 0 '\0', p_xstat = 0, p_klist = {kl_list = {slh_first = 0x0}, kl_lock = 0xc064b31c , kl_unlock = 0xc064b338 , kl_locked = 0xc064b354 , kl_lockarg = 0xc3b7e918}, p_numthreads = 1, p_numksegrps = 1, p_md = {md_ldt = 0x0}, p_itcallout = { c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_mtx = 0x0, c_flags = 16}, p_acflag = 1, p_ru = 0x0, p_peers = 0x0, p_leader = 0xc3b7e8b0, p_emuldata = 0x0, p_label = 0x0, p_sched = 0xc3b7eadc, p_ktr = {stqh_first = 0x0, stqh_last = 0xc3b7ead0}, p_mqnotifier = {lh_first = 0x0}} (kgdb) fr 7 #7 0xc063bcdc in acctwatch (a=0x0) at /usr/src/sys/kern/kern_acct.c:384 384 sx_xlock(&acct_sx); (kgdb) q From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 04:10:50 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C40116A41F; Wed, 21 Dec 2005 04:10:50 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EB4543D58; Wed, 21 Dec 2005 04:10:48 +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.4/8.13.4) with ESMTP id jBL4AkCH049511; Tue, 20 Dec 2005 23:10:47 -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.3/8.13.3) with ESMTP id jBL4AlVm045380; Tue, 20 Dec 2005 23:10:47 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 918A27302F; Tue, 20 Dec 2005 23:10:46 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051221041046.918A27302F@freebsd-current.sentex.ca> Date: Tue, 20 Dec 2005 23:10:46 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2005 04:10:50 -0000 TB --- 2005-12-21 03:01:31 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-12-21 03:01:31 - starting HEAD tinderbox run for amd64/amd64 TB --- 2005-12-21 03:01:31 - cleaning the object tree TB --- 2005-12-21 03:02:07 - checking out the source tree TB --- 2005-12-21 03:02:07 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2005-12-21 03:02:07 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-12-21 03:08:04 - building world (CFLAGS=-O2 -pipe) TB --- 2005-12-21 03:08:04 - cd /src TB --- 2005-12-21 03:08:04 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -o newsyslog newsyslog.o ptimes.o gzip -cn /src/usr.sbin/newsyslog/newsyslog.8 > newsyslog.8.gz gzip -cn /src/usr.sbin/newsyslog/newsyslog.conf.5 > newsyslog.conf.5.gz ===> usr.sbin/nfsd (all) cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/usr.sbin/nfsd/nfsd.c /src/usr.sbin/nfsd/nfsd.c: In function `main': /src/usr.sbin/nfsd/nfsd.c:666: warning: passing arg 3 of `accept' from incompatible pointer type /src/usr.sbin/nfsd/nfsd.c:688: warning: passing arg 3 of `accept' from incompatible pointer type *** Error code 1 Stop in /src/usr.sbin/nfsd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-12-21 04:10:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-12-21 04:10:46 - ERROR: failed to build world TB --- 2005-12-21 04:10:46 - tinderbox aborted TB --- 1.23 user 6.71 system 4155.06 real From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 04:27:57 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3FCEB16A41F for ; Wed, 21 Dec 2005 04:27:57 +0000 (GMT) (envelope-from kabaev@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 736EB43D55 for ; Wed, 21 Dec 2005 04:27:56 +0000 (GMT) (envelope-from kabaev@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so56737nzo for ; Tue, 20 Dec 2005 20:27:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type:content-transfer-encoding; b=ISWR4xGLGzzJFb9vX9oPqSDoPhgiaSKZW5+Db/jE590+QxjKmUPNQK1NdMYYA7RWSLiFEm330AAfGPZbcV5NcJiwN55kWRMHKMbNzAjZl+jZ1P7TBOqYestH1FYzCDmlgAoCW9geacFCZAFybdmSmxP2pN7fPGVWPcmabg4vOlc= Received: by 10.37.13.62 with SMTP id q62mr320906nzi; Tue, 20 Dec 2005 20:27:55 -0800 (PST) Received: from kan.dnsalias.net ( [24.63.93.195]) by mx.gmail.com with ESMTP id r1sm283233nzd.2005.12.20.20.27.55; Tue, 20 Dec 2005 20:27:55 -0800 (PST) Date: Tue, 20 Dec 2005 23:27:54 -0500 From: Alexander Kabaev To: Huang wen hui Message-ID: <20051220232754.48631fb4@kan.dnsalias.net> In-Reply-To: <43A8BD3F.2010006@gddsn.org.cn> References: <43A8BD3F.2010006@gddsn.org.cn> X-Mailer: Sylpheed-Claws 1.9.13 (GTK+ 2.6.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 21 Dec 2005 04:58:09 +0000 Cc: current@freebsd.org, openoffice@FreeBSD.org Subject: Re: [openoffice]no suitable windowing system found, exiting. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 04:27:57 -0000 On Wed, 21 Dec 2005 10:26:07 +0800 Huang wen hui wrote: > hi, > I used openoffice 2.0R from > ftp://ooopackages.good-day.net/pub/OpenOffice.org/FreeBSD/. On recent > CURRENT, > got this problem: > > no suitable windowing system found, exiting. > > I try to back out kan's ELF symbol versioning and solve this problem. > Does recompile openoffice can solve > this problem? I ask becasue compile openoffice is too long. > > --hwh > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" I discovered the OpenOffice breakage too, only with 1.1.4. Backing out symbol versioning patch helps. I will look for an exact cause of failure when I have some free time. OpenOffice is a big dlsym() user and it is possible it has to be made aware that rtld pays attention to symbol versions now. -- Alexander Kabaev From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 07:54:47 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B8B516A41F for ; Wed, 21 Dec 2005 07:54:47 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71DED43D53 for ; Wed, 21 Dec 2005 07:54:46 +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 jBL7sLhR004255; Wed, 21 Dec 2005 09:54:21 +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 64174-03-2; Wed, 21 Dec 2005 09:54:19 +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 jBL7ndxt004138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Dec 2005 09:49:39 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id jBL7nmRM055118; Wed, 21 Dec 2005 09:49:48 +0200 (EET) (envelope-from ru) Date: Wed, 21 Dec 2005 09:49:48 +0200 From: Ruslan Ermilov To: Artemiev Igor Message-ID: <20051221074948.GI84996@ip.net.ua> References: <20051218173028.GV41326@ip.net.ua> <20051220091227.4ce7dfa2.ai@bmc.brk.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="oxV4ZoPwBLqAyY+a" Content-Disposition: inline In-Reply-To: <20051220091227.4ce7dfa2.ai@bmc.brk.ru> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: freebsd-current@freebsd.org Subject: Re: New nfpm.c driver available for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2005 07:54:47 -0000 --oxV4ZoPwBLqAyY+a Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 20, 2005 at 09:12:27AM +0300, Artemiev Igor wrote: > I've recompiled your nfm with CFLAGS+=3D-DDEBUG. >=20 You'd better try the next version, but it works the same for nForce's. > ai@home$sudo ./smbtest /dev/smb0 > found slave device 8 > found slave device 80 > found slave device 82 >=20 OK. > ai@home$sudo ./smbtest /dev/smb1 > found slave device 8 > found slave device 45 > found slave device 55 > found slave device 72 > found slave device 73 > found slave device 97 > found slave device 127 >=20 OK. > smbtest gives me only a garbage. >=20 What do you mean? It found "SMBus host" (device 8) and some others. > When I tried mbmon without - > DSMBUS_IOCTL, it worked with SMBus through the /dev/io and "detected" > slave address for the first smb controller as 0x5a >=20 This is the shifted address, try "mbmon -A -D", it will display both shifted and real slave device addresses, like this: # ./mbmon -S -D Probe Request: none >>> Testing Reg's at SMBus <<< SMBus slave 0xA0(0x50) found... SMBus slave 0xA2(0x51) found... SMBus[NVidia nForce2] found, but No HWM available on it!! InitMBInfo: Device not configured > Then I've run mbmon -A -d. > It didn't find any sensors, but here is the driver's debug message: > Dec 19 22:17:57 home kernel: nfpm: STS=3D0x10 > Dec 19 22:17:57 home kernel: nfpm: READB from 0x10, cmd=3D0x40, byte=3D0x= 0, >=20 Good. > Well, It's a "Device Address Not Acknowledged" error. >=20 Yes. > If I shift the > slave address for reading, it works, and status register contains 0x80. >=20 mbmon already shifts it, and our smb(4) is dumb in that it expects the address already shifted. (Linux does better here.) > Yet, for writing I still have an 0x10. >=20 In my case, I have (note that all addresses are even because they are already "<< 1" shifted by mbmon). nfsmb: READB from 0x9e, cmd=3D0x0, byte=3D0xff, error=3D0x4 nfsmb: STS=3D0x10 nfsmb: READB from 0xa0, cmd=3D0x0, byte=3D0x80, error=3D0x0 nfsmb: STS=3D0x0 nfsmb: READB from 0xa2, cmd=3D0x0, byte=3D0x80, error=3D0x0 nfsmb: STS=3D0x0 nfsmb: READB from 0xa4, cmd=3D0x0, byte=3D0xff, error=3D0x4 nfsmb: STS=3D0x10 (I only copied cmd=3D0x0.) This corresponds to shifted addresses 0xa0 and 0xa2 (devices 0x50 and 0x51). > The documentation for AMD-8111 > controller explains this by not-reset operational status before the > controller checks the address. >=20 Yes, AMD-8111 is another story. It uses EC-based access to SMBus registers, while nForce2/3/4 appear to provice I/O based SMBus register access, and that matches the following info from lm-sensors: http://www2.lm-sensors.nu/~lm78/cvs/lm_sensors2/doc/busses/i2c-nforce2 # Notes # ----- #=20 # The SMBus adapter in the nForce2/3/4 chipset seems to be very similar to = the # SMBus 2.0 adapter in the AMD-8111 southbridge. However, I could only get = the # driver to work with direct I/O access, which is different to the EC inter= face # of the AMD-8111. # Tested on Asus A7N8X. The ACPI DSDT table of the Asus A7N8X lists two SMB= uses, # both of which are supported by this driver. > Btw, why in nfpm_wait you're polling SMB_PRTCL instead of SMB_STS?=20 >=20 Because that's what the ACPI spec says to do, see section 12.9 of the ACPI 3.0 spec. (ACPI 2.0c spec is similar.) I've solved the problem with using non-standard BARs, and will update the patch shortly. The PEC (Parity Error Checking) is not supported; we'd need to grow the support for it in smb(4) first. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --oxV4ZoPwBLqAyY+a Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDqQkcqRfpzJluFF4RArYkAJwN4cASidJO6tIK+tlgRZA9zRhXdwCeOV2V GGuzQT/JB+Um1Xd6yE6uEbI= =lPCa -----END PGP SIGNATURE----- --oxV4ZoPwBLqAyY+a-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 10:04:06 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D6BF16A41F; Wed, 21 Dec 2005 10:04:06 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9247F43D49; Wed, 21 Dec 2005 10:04:04 +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.4/8.13.4) with ESMTP id jBLA3vBf081152; Wed, 21 Dec 2005 05:03:58 -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.3/8.13.3) with ESMTP id jBLA3v7c092846; Wed, 21 Dec 2005 05:03:57 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id B8CCD7302F; Wed, 21 Dec 2005 05:03:57 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051221100357.B8CCD7302F@freebsd-current.sentex.ca> Date: Wed, 21 Dec 2005 05:03:57 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 205.211.164.50 Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2005 10:04:06 -0000 TB --- 2005-12-21 08:52:04 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-12-21 08:52:04 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2005-12-21 08:52:04 - cleaning the object tree TB --- 2005-12-21 08:52:33 - checking out the source tree TB --- 2005-12-21 08:52:33 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2005-12-21 08:52:33 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-12-21 08:58:48 - building world (CFLAGS=-O2 -pipe) TB --- 2005-12-21 08:58:48 - cd /src TB --- 2005-12-21 08:58: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 >>> stage 4.4: building everything [...] cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -o newsyslog newsyslog.o ptimes.o gzip -cn /src/usr.sbin/newsyslog/newsyslog.8 > newsyslog.8.gz gzip -cn /src/usr.sbin/newsyslog/newsyslog.conf.5 > newsyslog.conf.5.gz ===> usr.sbin/nfsd (all) cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/usr.sbin/nfsd/nfsd.c /src/usr.sbin/nfsd/nfsd.c: In function `main': /src/usr.sbin/nfsd/nfsd.c:666: warning: passing arg 3 of `accept' from incompatible pointer type /src/usr.sbin/nfsd/nfsd.c:688: warning: passing arg 3 of `accept' from incompatible pointer type *** Error code 1 Stop in /src/usr.sbin/nfsd. *** Error code 1 Stop in /src/usr.sbin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-12-21 10:03:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-12-21 10:03:57 - ERROR: failed to build world TB --- 2005-12-21 10:03:57 - tinderbox aborted TB --- 0.93 user 4.91 system 4312.73 real From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 10:09:50 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7634716A41F for ; Wed, 21 Dec 2005 10:09:50 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50B1B43D55 for ; Wed, 21 Dec 2005 10:09:49 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id CD7A3AB; Wed, 21 Dec 2005 05:10:09 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 501562518; Wed, 21 Dec 2005 05:10:08 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ep0um-000EIs-MX; Wed, 21 Dec 2005 10:09:44 +0000 Date: Wed, 21 Dec 2005 10:09:44 +0000 From: Brian Candler To: Chris Gilbert Message-ID: <20051221100944.GA54932@uk.tiscali.com> References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> <43A4A557.3010600@mac.com> <200512180107.03841.Chris@lainos.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200512180107.03841.Chris@lainos.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 10:09:50 -0000 On Sun, Dec 18, 2005 at 01:07:03AM +0100, Chris Gilbert wrote: > And that still doesn't solve the problem with desktop users who just want to > grab binaries and install them... my Wife was unlucky enough to have this > happen to her, and even though she has been using FreeBSD successfully for a > few years, it trashed her dependency tree to the point where I just had to > nuke most of her applications and recompile everything for her. (Not good!) Here here! I recently tried to upgrade Mozilla from 1.0.7 to the current ports version (1.5.something) on a FreeBSD 5.4 box. This fell over in all sorts of ways, and I ended up having to portupgrade almost everything. That then broke me in all sorts of other ways, like finding that 'unison' was upgraded and its protocol was no longer compatible with 'unison' on other systems, so they needed upgrading too. Plus I had to remember to abort the upgrade before it started rebuilding openoffice, to avoid my system becoming polluted with java... I have no problem with libraries called libgtk.so.400 or whatever, but the whole point of this scheme is that it should be possible to have multiple versions installed at the same time. So, if the new Mozilla port really requires the newest version of gtk, then it should simply go build that version of gtk and install it alongside my existing version, so all the ports linked against the older versions continue to work. Setting FORCE_PKG_REGISTER might do this, but if that works so well, why is it not the default? And then there are various flags to portupgrade / pkg_install which explicitly tell them to leave stale versions of shared libraries around, 'just in case' they are needed. > Perhaps this subject should be moved to another list and focused on what would > be a good way to create a stronger package/binary management and updating > system for FreeBSD? (That plays nicely with ports, and also handles > kernel/world/security updates) I'd like to see that. I think Dragonfly have some good ideas, like using the filesystem to build a virtual library environment on the fly. That is, when an application runs it sees a /lib directory populated with only the libraries it needs, and the exact versions of them. Extending this so that it is possible to have multiple versions of the same application (/usr/bin/foo) installed, for instant upgrade and rollback, would be even better. (I know there are existing solutions which install lots of symlinks, and some ideas can probably be taken from those too) Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 10:09:58 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B19516A41F; Wed, 21 Dec 2005 10:09:58 +0000 (GMT) (envelope-from roth@droopy.unibe.ch) Received: from mailhub03.unibe.ch (mailhub03.unibe.ch [130.92.9.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C7A643D5E; Wed, 21 Dec 2005 10:09:57 +0000 (GMT) (envelope-from roth@droopy.unibe.ch) Received: from localhost (scanhub01-eth0.unibe.ch [130.92.254.65]) by mailhub03.unibe.ch (Postfix) with ESMTP id 8B373257A4; Wed, 21 Dec 2005 11:09:55 +0100 (CET) Received: from mailhub03.unibe.ch ([130.92.9.70]) by localhost (scanhub01.unibe.ch [130.92.254.65]) (amavisd-new, port 10024) with LMTP id 12508-07-63; Wed, 21 Dec 2005 11:09:53 +0100 (CET) Received: from asterix.unibe.ch (asterix.unibe.ch [130.92.64.4]) by mailhub03.unibe.ch (Postfix) with ESMTP id DFD3925526; Wed, 21 Dec 2005 11:09:53 +0100 (CET) Received: from droopy.unibe.ch (droopy [130.92.64.20]) by asterix.unibe.ch (8.12.10+Sun/8.12.10) with ESMTP id jBLA9s8Z027049; Wed, 21 Dec 2005 11:09:54 +0100 (MET) Received: (from roth@localhost) by droopy.unibe.ch (8.12.10+Sun/8.12.9/Submit) id jBLA9sPY024485; Wed, 21 Dec 2005 11:09:54 +0100 (MET) Date: Wed, 21 Dec 2005 11:09:54 +0100 From: Tobias Roth To: current@freebsd.org, mobile@freebsd.org Message-ID: <20051221100954.GB24363@droopy.unibe.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-message-flag: Warning! Using Outlook is insecure and promotes virus distribution. Please use a different email client. X-Virus-checked: by University of Berne Cc: Subject: IBM Thinkpad Fan Control (acpi_ibm) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 10:09:58 -0000 Hi With acpi_ibm.ko, I can monitor fan speed, thermal sensors and do many other nice things. However, my Thinkpad (a T43p) has an awfully noisy fan, that, once the notebook reaches its standard working temperature (around 45 deg C), turns on and never stops again. The generally accepted solution his to manually lower the fan speed and live with the higher temperatures, which will still be in an acceptable range even with slow running fans. The discussion and a utility for Windows can be found here [1], and a linux tool is described here [2]. Now my question. Since acpi_ibm.ko can already read temperature sensors and fan speed, would it be feasable to teach it to control fan speed as well? Is anyone working on it already? Or can someone outline the steps that have to be taken so I can take a look and see if I can do it myself? thanks, t. From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 10:13:23 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0506616A41F for ; Wed, 21 Dec 2005 10:13:23 +0000 (GMT) (envelope-from delphij@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4628C43D4C for ; Wed, 21 Dec 2005 10:13:00 +0000 (GMT) (envelope-from delphij@gmail.com) Received: by wproxy.gmail.com with SMTP id 50so97895wri for ; Wed, 21 Dec 2005 02:12: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:content-disposition:references; b=NgqXY3AtttfRH82DfEkbfNNwIiGHHB6ubpkNdp9G7xC7S6YLh9fAyGkBJOphhsunO4EgNBIRSuR5caOcKj3o+yeeS9YDuDvw4QatnbuGdy6X4wj2fgB7VLjG2CJJP84tIeodGbf3N4wvyL6WHKk9UphWZ2GpuOwHjv3VOYvwPTU= Received: by 10.65.188.4 with SMTP id q4mr350539qbp; Wed, 21 Dec 2005 02:12:57 -0800 (PST) Received: by 10.65.72.5 with HTTP; Wed, 21 Dec 2005 02:12:57 -0800 (PST) Message-ID: Date: Wed, 21 Dec 2005 18:12:57 +0800 From: Xin LI To: FreeBSD Tinderbox In-Reply-To: <20051221100357.B8CCD7302F@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20051221100357.B8CCD7302F@freebsd-current.sentex.ca> Cc: current@freebsd.org, sparc64@freebsd.org Subject: Re: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: delphij@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2005 10:13:23 -0000 T24gMTIvMjEvMDUsIEZyZWVCU0QgVGluZGVyYm94IDx0aW5kZXJib3hAZnJlZWJzZC5vcmc+IHdy b3RlOgo+IFsuLi5dCj4gPT09PiB1c3Iuc2Jpbi9uZnNkIChhbGwpCj4gY2MgLU8yIC1waXBlICAt V3N5c3RlbS1oZWFkZXJzIC1XZXJyb3IgLVdhbGwgLVduby1mb3JtYXQteTJrIC1XIC1Xbm8tdW51 c2VkLXBhcmFtZXRlciAtV3N0cmljdC1wcm90b3R5cGVzIC1XbWlzc2luZy1wcm90b3R5cGVzIC1X cG9pbnRlci1hcml0aCAtV3JldHVybi10eXBlIC1XY2FzdC1xdWFsIC1Xd3JpdGUtc3RyaW5ncyAt V3N3aXRjaCAtV3NoYWRvdyAtV2Nhc3QtYWxpZ24gLVd1bnVzZWQtcGFyYW1ldGVyIC1XY2hhci1z dWJzY3JpcHRzIC1XaW5saW5lIC1XbmVzdGVkLWV4dGVybnMgLVdyZWR1bmRhbnQtZGVjbHMgLWMg L3NyYy91c3Iuc2Jpbi9uZnNkL25mc2QuYwo+IC9zcmMvdXNyLnNiaW4vbmZzZC9uZnNkLmM6IElu IGZ1bmN0aW9uIGBtYWluJzoKPiAvc3JjL3Vzci5zYmluL25mc2QvbmZzZC5jOjY2Njogd2Fybmlu ZzogcGFzc2luZyBhcmcgMyBvZiBgYWNjZXB0JyBmcm9tIGluY29tcGF0aWJsZSBwb2ludGVyIHR5 cGUKPiAvc3JjL3Vzci5zYmluL25mc2QvbmZzZC5jOjY4ODogd2FybmluZzogcGFzc2luZyBhcmcg MyBvZiBgYWNjZXB0JyBmcm9tIGluY29tcGF0aWJsZSBwb2ludGVyIHR5cGUKPiAqKiogRXJyb3Ig Y29kZSAxCgpTb3JyeSwgc2hvdWxkIGhhdmUgYmVlbiBmaXhlZCBub3cuCgpDaGVlcnMsCi0tClhp biBMSSA8ZGVscGhpakBkZWxwaGlqLm5ldD4gaHR0cDovL3d3dy5kZWxwaGlqLm5ldAo= From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 12:24:14 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2E3116A41F; Wed, 21 Dec 2005 12:24:14 +0000 (GMT) (envelope-from roth@droopy.unibe.ch) Received: from mailhub03.unibe.ch (mailhub03.unibe.ch [130.92.9.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41F8B43D60; Wed, 21 Dec 2005 12:24:14 +0000 (GMT) (envelope-from roth@droopy.unibe.ch) Received: from localhost (scanhub02-eth0.unibe.ch [130.92.254.66]) by mailhub03.unibe.ch (Postfix) with ESMTP id F369A259FA; Wed, 21 Dec 2005 13:24:12 +0100 (CET) Received: from mailhub03.unibe.ch ([130.92.9.70]) by localhost (scanhub02.unibe.ch [130.92.254.66]) (amavisd-new, port 10024) with LMTP id 15033-01-93; Wed, 21 Dec 2005 13:24:10 +0100 (CET) Received: from asterix.unibe.ch (asterix.unibe.ch [130.92.64.4]) by mailhub03.unibe.ch (Postfix) with ESMTP id 1A9E225A02; Wed, 21 Dec 2005 13:24:11 +0100 (CET) Received: from droopy.unibe.ch (droopy [130.92.64.20]) by asterix.unibe.ch (8.12.10+Sun/8.12.10) with ESMTP id jBLCOB8Z002915; Wed, 21 Dec 2005 13:24:11 +0100 (MET) Received: (from roth@localhost) by droopy.unibe.ch (8.12.10+Sun/8.12.9/Submit) id jBLCOAYM025705; Wed, 21 Dec 2005 13:24:10 +0100 (MET) Date: Wed, 21 Dec 2005 13:24:10 +0100 From: Tobias Roth To: current@freebsd.org, mobile@freebsd.org Message-ID: <20051221122410.GA25696@droopy.unibe.ch> References: <20051221100954.GB24363@droopy.unibe.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051221100954.GB24363@droopy.unibe.ch> User-Agent: Mutt/1.4i X-message-flag: Warning! Using Outlook is insecure and promotes virus distribution. Please use a different email client. X-Virus-checked: by University of Berne Cc: Paulius Bulotas Subject: Re: IBM Thinkpad Fan Control (acpi_ibm) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 12:24:14 -0000 ...and here are the links I forgot to paste: [1] http://forum.thinkpads.com/viewtopic.php?t=17715 [2] http://www.thinkwiki.org/wiki/Ibm-acpi From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 12:36:52 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BE9416A41F for ; Wed, 21 Dec 2005 12:36:52 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 427FB43D4C for ; Wed, 21 Dec 2005 12:36:50 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp132-74.lns2.adl2.internode.on.net [59.167.132.74]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id jBLCah1g084493 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 21 Dec 2005 23:06:44 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Wed, 21 Dec 2005 23:06:35 +1030 User-Agent: KMail/1.8.3 References: <43A266E5.3080103@samsco.org> <200512180107.03841.Chris@lainos.org> <20051221100944.GA54932@uk.tiscali.com> In-Reply-To: <20051221100944.GA54932@uk.tiscali.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1524423.b3c9pLnKG7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200512212306.36473.doconnor@gsoft.com.au> X-Spam-Score: 0 () SUBJECT_EXCESS_QP X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: Chris Gilbert , Brian Candler Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 12:36:52 -0000 --nextPart1524423.b3c9pLnKG7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wed, 21 Dec 2005 20:39, Brian Candler wrote: > I recently tried to upgrade Mozilla from 1.0.7 to the current ports versi= on > (1.5.something) on a FreeBSD 5.4 box. This fell over in all sorts of ways, > and I ended up having to portupgrade almost everything. That then broke me > in all sorts of other ways, like finding that 'unison' was upgraded and i= ts > protocol was no longer compatible with 'unison' on other systems, so they > needed upgrading too. Plus I had to remember to abort the upgrade before = it > started rebuilding openoffice, to avoid my system becoming polluted with > java... > > I have no problem with libraries called libgtk.so.400 or whatever, but the > whole point of this scheme is that it should be possible to have multiple > versions installed at the same time. In an ideal world this would all Just Work (tm). Unfortunately, developers don't have infinite resources so you experience=20 problems like you are seeing. It doesn't help that there is almost no binary compatibility between variou= s=20 releases of libraries (GNOME is really good for doing this in my experience= ). > So, if the new Mozilla port really requires the newest version of gtk, th= en > it should simply go build that version of gtk and install it alongside my > existing version, so all the ports linked against the older versions > continue to work. Setting FORCE_PKG_REGISTER might do this, but if that > works so well, why is it not the default? And then there are various flags > to portupgrade / pkg_install which explicitly tell them to leave stale > versions of shared libraries around, 'just in case' they are needed. I think the reason it isn't the default is because it pollutes your disk wi= th=20 multiple copies of things that may not be necessary. In a lot of cases it=20 will cause weird errors (eg one binary ends up with more than one version o= f=20 a library linked to it at run time because its dependents weren't all=20 upgraded) > I think Dragonfly have some good ideas, like using the filesystem to build > a virtual library environment on the fly. That is, when an application ru= ns > it sees a /lib directory populated with only the libraries it needs, and > the exact versions of them. Extending this so that it is possible to have > multiple versions of the same application (/usr/bin/foo) installed, for > instant upgrade and rollback, would be even better. (I know there are > existing solutions which install lots of symlinks, and some ideas can > probably be taken from those too) I don't see how this can fix the problem where you have a program that depe= nds=20 on 2 libraries and each of those depend another library. If they are linked= =20 to 2 different versions of that 3rd library you can get very odd behaviour. This *is* an annoying problem, but the solutions are far from simple.. (Lots more man power would help) =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 --nextPart1524423.b3c9pLnKG7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDqUxU5ZPcIHs/zowRAqSHAKCH+LZXoXxRfWeqD8vBty1+Ql+3TwCghq8t dgpZKgG+Svaup9/LebISUwA= =wyNX -----END PGP SIGNATURE----- --nextPart1524423.b3c9pLnKG7-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 13:16:52 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA65816A41F for ; Wed, 21 Dec 2005 13:16:52 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (vds.fauxbox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52A1643D45 for ; Wed, 21 Dec 2005 13:16:51 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 3B38EFD; Wed, 21 Dec 2005 08:17:12 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id E594C22DE; Wed, 21 Dec 2005 08:17:09 -0500 (EST) Received: from brian by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1Ep3pm-000Pch-CV; Wed, 21 Dec 2005 13:16:46 +0000 Date: Wed, 21 Dec 2005 13:16:46 +0000 From: Brian Candler To: Daniel O'Connor Message-ID: <20051221131646.GA98466@uk.tiscali.com> References: <43A266E5.3080103@samsco.org> <200512180107.03841.Chris@lainos.org> <20051221100944.GA54932@uk.tiscali.com> <200512212306.36473.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200512212306.36473.doconnor@gsoft.com.au> User-Agent: Mutt/1.4.2.1i Cc: Chris Gilbert , freebsd-current@freebsd.org Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 13:16:52 -0000 On Wed, Dec 21, 2005 at 11:06:35PM +1030, Daniel O'Connor wrote: > This *is* an annoying problem, but the solutions are far from simple.. Agreed - and I was mainly agreeing to the suggestion to take this off-list. Perhaps each of the possible solutions could be stuck onto a wiki whiteboard so that they could be annotated with their strengths and weaknesses. Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 13:26:26 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1804816A41F for ; Wed, 21 Dec 2005 13:26:26 +0000 (GMT) (envelope-from fli+freebsd-current@shapeshifter.se) Received: from mx1.h3q.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7644943D5F for ; Wed, 21 Dec 2005 13:26:24 +0000 (GMT) (envelope-from fli+freebsd-current@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mx1.h3q.net (Postfix) with ESMTP id 9290E1A90C; Wed, 21 Dec 2005 14:26:22 +0100 (CET) Received: from mx1.h3q.net ([127.0.0.1]) by localhost (mx1.h3q.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27132-06; Wed, 21 Dec 2005 14:26:21 +0100 (CET) Received: from [192.168.0.83] (81-234-243-91-o926.tbon.telia.com [81.234.243.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.h3q.net (Postfix) with ESMTP id E37FD1A7A7; Wed, 21 Dec 2005 14:26:20 +0100 (CET) Message-ID: <43A957FA.8090005@shapeshifter.se> Date: Wed, 21 Dec 2005 14:26:18 +0100 From: Fredrik Lindberg User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050928) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tobias Roth References: <20051221100954.GB24363@droopy.unibe.ch> In-Reply-To: <20051221100954.GB24363@droopy.unibe.ch> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at h3q.net Cc: current@freebsd.org Subject: Re: IBM Thinkpad Fan Control (acpi_ibm) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 13:26:26 -0000 Tobias Roth wrote: > Hi > > With acpi_ibm.ko, I can monitor fan speed, thermal sensors and do > many other nice things. However, my Thinkpad (a T43p) has an awfully > noisy fan, that, once the notebook reaches its standard working > temperature (around 45 deg C), turns on and never stops again. > > The generally accepted solution his to manually lower the fan speed > and live with the higher temperatures, which will still be in an > acceptable range even with slow running fans. The discussion and a > utility for Windows can be found here [1], and a linux tool is > described here [2]. > > Now my question. Since acpi_ibm.ko can already read temperature > sensors and fan speed, would it be feasable to teach it to control > fan speed as well? Is anyone working on it already? Or can someone > outline the steps that have to be taken so I can take a look and > see if I can do it myself? > > thanks, t. I don't know if somebody is working on it, but it shouldn't be too hard to add it to acpi_ibm. Just parse the relevant bits from the linux patch and add a new sysctl method for fan speed in the acpi_ibm_sysctl_set() function in the file sys/dev/acpi_support/acpi_ibm.c I did this a while ago for but for fan enable/disable, but that is really useless because the only thing you can accomplish with the fan off is a fried laptop (although, it will be quiet :)). It's probably quite dangerous to mess with the fan speed too, because even if the fan is running at low speed you risk overheating your system. Fredrik Lindberg From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 15:36:34 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E877D16A420; Wed, 21 Dec 2005 15:36:34 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from mail.r61.net (mail.r61.net [195.208.245.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 77B4443D49; Wed, 21 Dec 2005 15:36:31 +0000 (GMT) (envelope-from bushman@rsu.ru) Received: from [195.208.252.201] (celsius.cc.rsu.ru [195.208.252.201]) by mail.r61.net (8.13.4/8.13.4) with ESMTP id jBLFaOdo082755; Wed, 21 Dec 2005 18:36:24 +0300 (MSK) (envelope-from bushman@rsu.ru) Message-ID: <43A977B4.6080200@rsu.ru> Date: Wed, 21 Dec 2005 18:41:40 +0300 From: Michael Bushkov User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051018) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <436A0C73.3010405@rsu.ru> <20051103140221.GF29387@submonkey.net> <43A009CB.2090800@rsu.ru> <20051219130928.GE63860@submonkey.net> <20051219135019.GF63860@submonkey.net> <43A6CC9E.6040109@rsu.ru> <20051219152505.GI63860@submonkey.net> <002c01c604c4$60ebe010$0100a8c0@jersey> <20051219183137.GA1103@odin.ac.hmc.edu> <43A7D4A6.6000607@rsu.ru> <20051220140927.GA1671@garage.freebsd.pl> In-Reply-To: <20051220140927.GA1671@garage.freebsd.pl> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.86.2, clamav-milter version 0.86 on asterix.r61.net X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org, Ceri Davies Subject: [PATCH] pidfile_check() possible function X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 15:36:35 -0000 Hi! I've made a sample implementation of pidfile_check() function based on pkill's takepid() function. It's interface is like this: int pidfile_check(const char *path, int pidfilelock, pid_t *pidptr); The patch is here: http://rsu.ru/~bushman/libpidfile.patch pidfile_check returns 0 if the pidfile owner seems to be active and (-1) otherwise (in case of failure errno would also be set). The path argument is the path of the pidfile. If pidfilelock is not 0, the function will attempt to lock the file to check if the pidfile owner is currently running. If pidptr is not NULL and pidfile owner seems to be active, it's pid will be placed in pidptr. Looking forward for your comments and suggestions! Michael Bushkov From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 16:14:50 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CD7016A429; Wed, 21 Dec 2005 16:14:50 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5992D43D72; Wed, 21 Dec 2005 16:14:34 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 47B5751B27; Wed, 21 Dec 2005 17:14:27 +0100 (CET) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id C6EA752C93; Wed, 21 Dec 2005 17:14:20 +0100 (CET) Date: Wed, 21 Dec 2005 17:13:27 +0100 From: Pawel Jakub Dawidek To: Gleb Smirnoff Message-ID: <20051221161327.GB6493@garage.freebsd.pl> References: <20051220121837.GQ41381@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NDin8bjvE/0mNLFQ" Content-Disposition: inline In-Reply-To: <20051220121837.GQ41381@FreeBSD.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r535 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: njl@FreeBSD.org, current@FreeBSD.org Subject: Re: acpica memory leak? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 16:14:50 -0000 --NDin8bjvE/0mNLFQ Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Dec 20, 2005 at 03:18:37PM +0300, Gleb Smirnoff wrote: +> On recent current I see the "acpica" memory type allocation count +> slowly growing: +>=20 +> acpica 2162 116K - 33738 16,32,64,128,256,512,1024 +> root@jujik:~:|>vmstat -m | grep acpica +> acpica 2163 116K - 33765 16,32,64,128,256,512,1024 +> root@jujik:~:|>vmstat -m | grep acpica +> acpica 2168 116K - 33900 16,32,64,128,256,512,1024 +>=20 +> Anyone else see this? I think I can confirm that. At least after every resume I get four more InUse elements. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --NDin8bjvE/0mNLFQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDqX8nForvXbEpPzQRArgTAJ0TTHWotn4L0fbHQiPj0bZuj7q4JACfXkeM qvelYwL7VB4cv7QJlJGIizM= =ujkX -----END PGP SIGNATURE----- --NDin8bjvE/0mNLFQ-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 16:19:31 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8AAD16A424; Wed, 21 Dec 2005 16:19:31 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE08643D62; Wed, 21 Dec 2005 16:19:25 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 4296152 for multiple; Wed, 21 Dec 2005 11:20:58 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id jBLGJJDO016736; Wed, 21 Dec 2005 11:19:19 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 21 Dec 2005 11:11:43 -0500 User-Agent: KMail/1.8.2 References: <20051221031526.31ABC290@mx2.synetsystems.com> In-Reply-To: <20051221031526.31ABC290@mx2.synetsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512211111.44268.jhb@freebsd.org> X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Richard Todd , rwatson@freebsd.org Subject: Re: Bug in latest rev kern_acct.c: panic: Trying sleep, but thread marked as sleeping prohibited X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 16:19:32 -0000 On Tuesday 20 December 2005 09:18 pm, Richard Todd wrote: > I've been getting this panic a good bit recently after updating -current > sources a couple days ago. The panic occurs in the acctwatch() callout > routine run from the clock ithread, apparently when it tries to sleep > on a lock (which is, I gather, verboten in ithreads.) The panics seemed > to occur randomly but, on reflection, always occured when > 1) there was a good bit of system activity and > 2) I had just done something to allocate or free enough space on /usr to > cause accounting to be either suspended or resumed. > and thus would cause the acctwatch() routine to have to do something. > "make clean; make" in a big port seemed to be fairly effective in > triggering the bug. :-) > > My previous kernel, which dated from Oct 24, didn't have this > problem, which helps point suspicion at the latest rev of kern_acct.c > (rev 1.76, date: 2005/11/12 10:45:13) which involved a bunch of changes > in the lock handling of kernel accounting. acctwatch() probably isn't a good thing to do from a callout since it wants to do VOPs and such. Probably the easiest fix is to stick acctwatch() in its own kthread. > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you > are welcome to change it and/or distribute copies of it under certain > conditions. Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd". > > Unread portion of the kernel message buffer: > panic: Trying sleep, but thread marked as sleeping prohibited > cpuid = 1 > KDB: stack backtrace: > kdb_backtrace(100,c3b7f900,c3b7f900,c0976100,c096f6a8) at > kdb_backtrace+0x29 panic(c08a19c6,0,c096f6a8,c0970598,d85f0a14) at > panic+0x114 > sleepq_add(c096f6a8,c0970598,c089a4ab,1,c0970598,0,c089a875,96) at > sleepq_add+0x8c cv_wait_unlock(c096f6a8,c0970598,180,d85f0a4c,c096f680) at > cv_wait_unlock+0x171 cv_wait(c096f6a8,c0970598,0,c3b7c480,c3ddb1c0) at > cv_wait+0x36 > _sx_xlock(c096f680,c089a5a2,180) at _sx_xlock+0x68 > acctwatch(0) at acctwatch+0x20 > softclock(0) at softclock+0x22b > ithread_execute_handlers(c3b7e8b0,c3b7c480) at > ithread_execute_handlers+0xe6 > ithread_loop(c3b488a0,d85f0d38,c3b488a0,c065098c,0) at ithread_loop+0x67 > fork_exit(c065098c,c3b488a0,d85f0d38) at fork_exit+0xa4 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xd85f0d6c, ebp = 0 --- > Uptime: 49m58s > Dumping 637 MB (2 chunks) > chunk 0: 1MB (159 pages) ... ok > chunk 1: 637MB (163072 pages) 622 606 590 574 558 542 526 510 494 478 462 > 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 > 142 126 110 94 78 62 46 30 14 > > #0 doadump () at pcpu.h:165 > 165 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) bt > #0 doadump () at pcpu.h:165 > #1 0xc0663880 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:399 > #2 0xc0663b95 in panic ( > fmt=0xc08a19c6 "Trying sleep, but thread marked as sleeping > prohibited") at /usr/src/sys/kern/kern_shutdown.c:555 > #3 0xc06830fc in sleepq_add (wchan=0xc096f6a8, lock=0xc0970598, wmesg=0x0, > flags=1) at /usr/src/sys/kern/subr_sleepqueue.c:273 > #4 0xc063dd31 in cv_wait_unlock (cvp=0xc096f6a8, mp=0xc0970598) > at /usr/src/sys/kern/kern_condvar.c:152 > #5 0xc063db9a in cv_wait (cvp=0xc096f6a8, mp=0xc0970598) > at /usr/src/sys/kern/kern_condvar.c:112 > #6 0xc06697cc in _sx_xlock (sx=0xc096f680, > file=0xc089a5a2 "/usr/src/sys/kern/kern_acct.c", line=384) > at /usr/src/sys/kern/kern_sx.c:188 > #7 0xc063bcdc in acctwatch (a=0x0) at /usr/src/sys/kern/kern_acct.c:384 > #8 0xc0670bf7 in softclock (dummy=0x0) at > /usr/src/sys/kern/kern_timeout.c:290 #9 0xc06508c2 in > ithread_execute_handlers (p=0xc3b7e8b0, ie=0xc3b7c480) at > /usr/src/sys/kern/kern_intr.c:662 > #10 0xc06509f3 in ithread_loop (arg=0xc3b488a0) > at /usr/src/sys/kern/kern_intr.c:745 > #11 0xc064fb54 in fork_exit (callout=0xc065098c , > arg=0xc3b488a0, frame=0xd85f0d38) at /usr/src/sys/kern/kern_fork.c:790 > #12 0xc081ac7c in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:198 (kgdb) fr 9 > #9 0xc06508c2 in ithread_execute_handlers (p=0xc3b7e8b0, ie=0xc3b7c480) > at /usr/src/sys/kern/kern_intr.c:662 > 662 ih->ih_handler(ih->ih_argument); > (kgdb) p *p > $1 = {p_list = {le_next = 0xc3b7eadc, le_prev = 0xc3b7e684}, p_ksegrps = { > tqh_first = 0xc3b81d80, tqh_last = 0xc3b81d84}, p_threads = { > tqh_first = 0xc3b7f900, tqh_last = 0xc3b7f908}, p_suspended = { > tqh_first = 0x0, tqh_last = 0xc3b7e8c8}, p_ucred = 0xc3b79100, > p_fd = 0xc3b85200, p_fdtol = 0x0, p_stats = 0xc3b67a00, > p_limit = 0xc3b7a100, p_sigacts = 0xc3b8c000, p_flag = 524, p_sflag = 1, > p_state = PRS_NORMAL, p_pid = 12, p_hash = {le_next = 0x0, > le_prev = 0xc3b73030}, p_pglist = {le_next = 0xc3b7eadc, > le_prev = 0xc3b7e6d4}, p_pptr = 0xc096f0c0, p_sibling = { > le_next = 0xc3b7eadc, le_prev = 0xc3b7e6e0}, p_children = { > lh_first = 0x0}, p_mtx = {mtx_object = {lo_class = 0xc0931b24, > lo_name = 0xc089df1e "process lock", > lo_type = 0xc089df1e "process lock", lo_flags = 4390912, > lo_witness_data = {lod_list = {stqe_next = 0xc0981260}, > lod_witness = 0xc0981260}}, mtx_lock = 4, mtx_recurse = 0}, > p_ksi = 0x0, p_sigqueue = {sq_signals = {__bits = {0, 0, 0, 0}}, sq_list > = { tqh_first = 0x0, tqh_last = 0xc3b7e948}, sq_proc = 0xc3b7e8b0, sq_flags > = 1}, p_oppid = 0, p_vmspace = 0xc096f460, p_swtime = 2986, p_realtimer = > {it_interval = {tv_sec = 0, tv_usec = 0}, it_value = { tv_sec = 0, tv_usec > = 0}}, p_rux = {rux_runtime = {sec = 59, frac = 4151612463131724764}, > rux_uticks = 0, rux_sticks = 0, rux_iticks = 157, rux_uu = 0, rux_su = > 191765, rux_iu = 58831433}, p_crux = {rux_runtime = {sec = 0, frac = 0}, > rux_uticks = 0, rux_sticks = 0, rux_iticks = 0, rux_uu = 0, rux_su = 0, > rux_iu = 0}, p_profthreads = 0, p_maxthrwaits = 0, p_traceflag = 0, > p_tracevp = 0x0, p_tracecred = 0x0, p_textvp = 0x0, p_lock = 1 '\001', > p_sigiolst = {slh_first = 0x0}, p_sigparent = 20, p_sig = 0, p_code = 0, > p_stops = 0, p_stype = 0, p_step = 0 '\0', p_pfsflags = 0 '\0', p_nlminfo = > 0x0, p_aioinfo = 0x0, p_singlethread = 0x0, p_suspcount = 0, p_xthread = > 0x0, > p_boundary_count = 0, p_procscopegrp = 0x0, p_pendingcnt = 0, > p_itimers = 0x0, p_magic = 3203398350, > p_comm = "swi4: clock sio\000\000\000\000", p_pgrp = 0xc096f600, > p_sysent = 0xc092cb80, p_args = 0x0, p_cpulimit = 9223372036854775807, > p_nice = 0 '\0', p_xstat = 0, p_klist = {kl_list = {slh_first = 0x0}, > kl_lock = 0xc064b31c , > kl_unlock = 0xc064b338 , > kl_locked = 0xc064b354 , kl_lockarg = 0xc3b7e918}, > p_numthreads = 1, p_numksegrps = 1, p_md = {md_ldt = 0x0}, p_itcallout = > { c_links = {sle = {sle_next = 0x0}, tqe = {tqe_next = 0x0, > tqe_prev = 0x0}}, c_time = 0, c_arg = 0x0, c_func = 0, c_mtx = 0x0, > c_flags = 16}, p_acflag = 1, p_ru = 0x0, p_peers = 0x0, > p_leader = 0xc3b7e8b0, p_emuldata = 0x0, p_label = 0x0, > p_sched = 0xc3b7eadc, p_ktr = {stqh_first = 0x0, stqh_last = 0xc3b7ead0}, > p_mqnotifier = {lh_first = 0x0}} > (kgdb) fr 7 > #7 0xc063bcdc in acctwatch (a=0x0) at /usr/src/sys/kern/kern_acct.c:384 > 384 sx_xlock(&acct_sx); > (kgdb) q > > > _______________________________________________ > 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" -- 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 Dec 21 16:19:40 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B10B216A41F for ; Wed, 21 Dec 2005 16:19:40 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9019143D64 for ; Wed, 21 Dec 2005 16:19:28 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 4296156 for multiple; Wed, 21 Dec 2005 11:21:00 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id jBLGJJDR016736; Wed, 21 Dec 2005 11:19:21 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: Joseph Koshy Date: Wed, 21 Dec 2005 11:19:53 -0500 User-Agent: KMail/1.8.2 References: <20051220032538.A33093@xorpc.icir.org> <200512201422.47323.jhb@freebsd.org> <84dead720512201904q6dbe5e6er6925282d4d320bee@mail.gmail.com> In-Reply-To: <84dead720512201904q6dbe5e6er6925282d4d320bee@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512211119.54940.jhb@freebsd.org> X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Luigi Rizzo , freebsd-current@freebsd.org Subject: Re: td->td_critnest manipulations do not use atomic_add_int ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 16:19:40 -0000 On Tuesday 20 December 2005 10:04 pm, Joseph Koshy wrote: > lr> is td ever != curthread? > > jhb> No. > > I don't think we KASSERT() this in enough places in the code > though. void critical_enter(void) { struct thread *td; td = curthread; td->td_critnest++; CTR4(KTR_CRITICAL, "critical_enter by thread %p (%ld, %s) to %d", td, (long)td->td_proc->p_pid, td->td_proc->p_comm, td->td_critnest); } void critical_exit(void) { struct thread *td; td = curthread; KASSERT(td->td_critnest != 0, .. } Need I say more? Clearly td == curthread. -- 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 Dec 21 16:20:03 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EAAD316A4E3; Wed, 21 Dec 2005 16:20:03 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA75F43D5A; Wed, 21 Dec 2005 16:20:02 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.3/8.13.3) with ESMTP id jBLGK0pn007718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Dec 2005 19:20:00 +0300 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.3/8.13.1/Submit) id jBLGJxTd007717; Wed, 21 Dec 2005 19:19:59 +0300 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 21 Dec 2005 19:19:59 +0300 From: Gleb Smirnoff To: Pawel Jakub Dawidek Message-ID: <20051221161959.GQ41381@cell.sick.ru> References: <20051220121837.GQ41381@FreeBSD.org> <20051221161327.GB6493@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20051221161327.GB6493@garage.freebsd.pl> User-Agent: Mutt/1.5.6i Cc: njl@FreeBSD.org, current@FreeBSD.org Subject: Re: acpica memory leak? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 16:20:04 -0000 On Wed, Dec 21, 2005 at 05:13:27PM +0100, Pawel Jakub Dawidek wrote: P> On Tue, Dec 20, 2005 at 03:18:37PM +0300, Gleb Smirnoff wrote: P> +> On recent current I see the "acpica" memory type allocation count P> +> slowly growing: P> +> P> +> acpica 2162 116K - 33738 16,32,64,128,256,512,1024 P> +> root@jujik:~:|>vmstat -m | grep acpica P> +> acpica 2163 116K - 33765 16,32,64,128,256,512,1024 P> +> root@jujik:~:|>vmstat -m | grep acpica P> +> acpica 2168 116K - 33900 16,32,64,128,256,512,1024 P> +> P> +> Anyone else see this? P> P> I think I can confirm that. At least after every resume I get four more P> InUse elements. I see them just during idle runtime of my testbox. The numbers above were with 1 hour uptime, and here is one day uptime: acpica 12259 747K - 306973 16,32,64,128,256,512,1024 -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 16:28:29 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3AD916A41F; Wed, 21 Dec 2005 16:28:29 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2543543DB9; Wed, 21 Dec 2005 16:28:10 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id A1BD852CA3; Wed, 21 Dec 2005 17:28:04 +0100 (CET) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id D836352C2B; Wed, 21 Dec 2005 17:27:58 +0100 (CET) Date: Wed, 21 Dec 2005 17:27:05 +0100 From: Pawel Jakub Dawidek To: Gleb Smirnoff Message-ID: <20051221162705.GC6493@garage.freebsd.pl> References: <20051220121837.GQ41381@FreeBSD.org> <20051221161327.GB6493@garage.freebsd.pl> <20051221161959.GQ41381@cell.sick.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Fig2xvG2VGoz8o/s" Content-Disposition: inline In-Reply-To: <20051221161959.GQ41381@cell.sick.ru> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r535 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: njl@FreeBSD.org, current@FreeBSD.org Subject: Re: acpica memory leak? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 16:28:30 -0000 --Fig2xvG2VGoz8o/s Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 21, 2005 at 07:19:59PM +0300, Gleb Smirnoff wrote: +> On Wed, Dec 21, 2005 at 05:13:27PM +0100, Pawel Jakub Dawidek wrote: +> P> On Tue, Dec 20, 2005 at 03:18:37PM +0300, Gleb Smirnoff wrote: +> P> +> On recent current I see the "acpica" memory type allocation count +> P> +> slowly growing: +> P> +>=20 +> P> +> acpica 2162 116K - 33738 16,32,64,128,256,512,= 1024 +> P> +> root@jujik:~:|>vmstat -m | grep acpica +> P> +> acpica 2163 116K - 33765 16,32,64,128,256,512,= 1024 +> P> +> root@jujik:~:|>vmstat -m | grep acpica +> P> +> acpica 2168 116K - 33900 16,32,64,128,256,512,= 1024 +> P> +>=20 +> P> +> Anyone else see this? +> P>=20 +> P> I think I can confirm that. At least after every resume I get four mo= re +> P> InUse elements. +>=20 +> I see them just during idle runtime of my testbox. The numbers above were +> with 1 hour uptime, and here is one day uptime: +>=20 +> acpica 12259 747K - 306973 16,32,64,128,256,512,1024 So it looks much more serious than in my case: anger:root:# vmstat -m | grep acpica acpica 4550 235K - 251941 16,32,64,128,256,512,1024,2048 anger:root:# vmstat -m | grep acpica acpica 4558 235K - 257176 16,32,64,128,256,512,1024,2048 anger:root:# vmstat -m | grep acpica acpica 4562 235K - 265940 16,32,64,128,256,512,1024,2048 anger:root:# uptime 17:26 up 5 days, 19:06, 21 users, load averages: 0,15 0,13 0,09 --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --Fig2xvG2VGoz8o/s Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDqYJZForvXbEpPzQRAh+SAKCPjxD9JRj44Axgt8E3AG25FLQwDwCfQVfM 1q8+p7l+mKUUmnah2BAoEIQ= =0Xd4 -----END PGP SIGNATURE----- --Fig2xvG2VGoz8o/s-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 19:21:29 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 480AB16A420; Wed, 21 Dec 2005 19:21:29 +0000 (GMT) (envelope-from ftigeot@aoi.wolfpond.org) Received: from aoi.wolfpond.org (gw.zefyris.com [213.41.131.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF9CA43D46; Wed, 21 Dec 2005 19:21:20 +0000 (GMT) (envelope-from ftigeot@aoi.wolfpond.org) Received: from aoi.wolfpond.org (localhost [127.0.0.1]) by aoi.wolfpond.org (8.13.4/8.13.4) with ESMTP id jBLJLL2A014336; Wed, 21 Dec 2005 20:21:21 +0100 (CET) (envelope-from ftigeot@aoi.wolfpond.org) Received: (from ftigeot@localhost) by aoi.wolfpond.org (8.13.4/8.13.1/Submit) id jBLJLIvb014335; Wed, 21 Dec 2005 20:21:18 +0100 (CET) (envelope-from ftigeot) Date: Wed, 21 Dec 2005 20:21:18 +0100 From: Francois Tigeot To: Alexander Kabaev Message-ID: <20051221192118.GA88506@aoi.wolfpond.org> References: <43A8BD3F.2010006@gddsn.org.cn> <20051220232754.48631fb4@kan.dnsalias.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051220232754.48631fb4@kan.dnsalias.net> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org, openoffice@freebsd.org Subject: Re: [openoffice]no suitable windowing system found, exiting. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 19:21:29 -0000 On Tue, Dec 20, 2005 at 11:27:54PM -0500, Alexander Kabaev wrote: > On Wed, 21 Dec 2005 10:26:07 +0800 > Huang wen hui wrote: > > > hi, > > I used openoffice 2.0R from > > ftp://ooopackages.good-day.net/pub/OpenOffice.org/FreeBSD/. On recent > > CURRENT, > > got this problem: > > > > no suitable windowing system found, exiting. > > > > I try to back out kan's ELF symbol versioning and solve this problem. > > Does recompile openoffice can solve > > this problem? I ask becasue compile openoffice is too long. > > I discovered the OpenOffice breakage too, only with 1.1.4. Backing out > symbol versioning patch helps. > > I will look for an exact cause of failure when I have some free time. > OpenOffice is a big dlsym() user and it is possible it has to be made > aware that rtld pays attention to symbol versions now. Fwiw, this is the same message given by a FreeBSD/i386 OpenOffice binary on a 6.0-RELEASE amd64 machine. I intented to find out more but real life got in the way... -- Francois Tigeot From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 19:21:47 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3F76E16A44B for ; Wed, 21 Dec 2005 19:21:47 +0000 (GMT) (envelope-from andrea@acampi.hq.inet.it) Received: from acampi.hq.inet.it (out-11.hq.inet.it [194.185.62.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E4EE43D5D for ; Wed, 21 Dec 2005 19:21:46 +0000 (GMT) (envelope-from andrea@acampi.hq.inet.it) Received: by acampi.hq.inet.it (Postfix, from userid 1000) id B51BD7C; Wed, 21 Dec 2005 20:21:45 +0100 (CET) Resent-From: andrea@webcom.it Resent-Date: Wed, 21 Dec 2005 20:21:45 +0100 Resent-Message-ID: <20051221192145.GD17950@webcom.it> Resent-To: current@freebsd.org Date: Wed, 21 Dec 2005 20:19:19 +0100 From: Andrea Campi To: current@freebsd.org Message-ID: <20051221191919.GB17950@webcom.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Cc: Subject: Panic and LOR on -CURRENT with ath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 19:21:47 -0000 Hi, I have a Soekris box working as router/firewall/access point for my LAN, and after my latest update (a few days ago) I've been having a couple of issues: a LOR at boot, and a panic after some variable amount of time. I sort of remember seeing something similar to the panic on a mailing list, but can't find the thread. Since they appear regularly, if there's anything I can do to help debug the issue I'm all ears. Bye, Andrea lock order reversal: (sleepable after non-sleepable) 1st 0xc0d68d30 ath0 (network driver) @ /usr/src/sys/dev/ath/if_ath.c:4642 2nd 0xc0cfc878 user map (user map) @ /usr/src/sys/vm/vm_map.c:2997 KDB: stack backtrace: witness_checkorder(c0cfc878,9,c05fed2f,bb5,c5b7c924) at witness_checkorder+0x383 _sx_xlock(c0cfc878,c05fed2f,bb5,2b7c928,c5b7c924) at _sx_xlock+0x3c vm_map_lookup(c5b7c924,805e000,2,c5b7c928,c5b7c918,c5b7c91c,c5b7c8ff,c5b7c900) a t vm_map_lookup+0x30 vm_fault(c0cfc834,805e000,2,8,c0d5e900) at vm_fault+0x63 trap_pfault(805e000) at trap_pfault+0x10b trap(8,c0640028,c0d50028,805e000,c0da8e00) at trap+0x34a calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc05c0316, esp = 0xc5b7ca2c, ebp = 0xc5b7ca60 --- generic_copyout(c0d65000,c0d90980,c0d68aac,c0286938,0) at generic_copyout+0x36 ieee80211_ioctl(c0d681ac,c0286938,c0d90980) at ieee80211_ioctl+0x16a ath_ioctl(c0d65000,c0286938,c0d90980) at ath_ioctl+0xb2 ifhwioctl(c0d90980,c0d5e900,c0d65000,c0fd7590,c0286938) at ifhwioctl+0x1fd ifioctl(c0fd7590,c0286938,c0d90980,c0d5e900) at ifioctl+0x5c soo_ioctl(c0de75e8,c0286938,c0d90980,c0ce6d80,c0d5e900) at soo_ioctl+0x29d ioctl(c0d5e900,c5b7cd04,3,13,206) at ioctl+0xfa syscall(3b,3b,3b,805d028,805d000) at syscall+0x110 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2813f69f, esp =fe5d8 --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdeadc0de fault code = supervisor read, page not present instruction pointer = 0x20:0xc04dccc9 stack pointer = 0x28:0xc5705c10 frame pointer = 0x28:0xc5705c18 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 = 31 (swi6: task queue) [thread pid 31 tid 100018 ] Stopped at m_tag_delete_chain+0x29: movl 0(%ebx),%eax db> bt Tracing pid 31 tid 100018 td 0xc0cf3780 m_tag_delete_chain(c103fb00,0,deadc0de,c5705c58,c057bc61) at m_tag_delete_chain+ 0x29 mb_dtor_mbuf(c103fb00,100,0) at mb_dtor_mbuf+0x38 uma_zfree_arg(c0872e80,c103fb00,0) at uma_zfree_arg+0x2f1 m_freem(c103fb00,c0d69188,0,c0fd2000,c5baa588) at m_freem+0x4e ath_tx_processq(1,c0d6940c,c5705ce8,c04c1e51,c0d68000) at ath_tx_processq+0x109 ath_tx_proc_q0123(c0d68000,1,c0ce779c,0,c05eea3e) at ath_tx_proc_q0123+0x24 taskqueue_run(c0ce7780,0,c0d0e830,0,c048ff00) at taskqueue_run+0x81 ithread_loop(c0ce7700,c5705d38,c0ce7700,c048ff00,0) at ithread_loop+0x175 fork_exit(c048ff00,c0ce7700,c5705d38) at fork_exit+0x83 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc5705d6c, ebp = 0 --- db> -- Press every key to continue. From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 19:33:45 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7AAAE16A41F; Wed, 21 Dec 2005 19:33:45 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 85D0E43D79; Wed, 21 Dec 2005 19:33:34 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id jBLJXXZP099586; Wed, 21 Dec 2005 13:33:33 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <43A9AE07.3070501@centtech.com> Date: Wed, 21 Dec 2005 13:33:27 -0600 From: Eric Anderson User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Tigeot References: <43A8BD3F.2010006@gddsn.org.cn> <20051220232754.48631fb4@kan.dnsalias.net> <20051221192118.GA88506@aoi.wolfpond.org> In-Reply-To: <20051221192118.GA88506@aoi.wolfpond.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1213/Mon Dec 19 08:48:34 2005 on mh2.centtech.com X-Virus-Status: Clean Cc: openoffice@freebsd.org, Alexander Kabaev , current@freebsd.org Subject: Re: [openoffice]no suitable windowing system found, exiting. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 19:33:45 -0000 Francois Tigeot wrote: >On Tue, Dec 20, 2005 at 11:27:54PM -0500, Alexander Kabaev wrote: > > >>On Wed, 21 Dec 2005 10:26:07 +0800 >>Huang wen hui wrote: >> >> >> >>>hi, >>>I used openoffice 2.0R from >>>ftp://ooopackages.good-day.net/pub/OpenOffice.org/FreeBSD/. On recent >>>CURRENT, >>>got this problem: >>> >>>no suitable windowing system found, exiting. >>> >>>I try to back out kan's ELF symbol versioning and solve this problem. >>>Does recompile openoffice can solve >>>this problem? I ask becasue compile openoffice is too long. >>> >>> >>I discovered the OpenOffice breakage too, only with 1.1.4. Backing out >>symbol versioning patch helps. >> >>I will look for an exact cause of failure when I have some free time. >>OpenOffice is a big dlsym() user and it is possible it has to be made >>aware that rtld pays attention to symbol versions now. >> >> > >Fwiw, this is the same message given by a FreeBSD/i386 OpenOffice binary on >a 6.0-RELEASE amd64 machine. > >I intented to find out more but real life got in the way... > > I'm seeing this too, and flash stopped working for me also. Flash7 in firefox gives me this error: LoadPlugin: failed to initialize shared library /usr/X11R6/lib/linux-flashplugin7/libflashplayer.so [/usr/X11R6/lib/linux-flashplugin7/libflashplayer.so: Undefined symbol "ah_arctan"] Is that error related I wonder? I believe it also is a dlsym user.. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 19:53:24 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF98716A41F for ; Wed, 21 Dec 2005 19:53:24 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id A604843D6B for ; Wed, 21 Dec 2005 19:53:23 +0000 (GMT) (envelope-from freebsd-current@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1Ep9zI-0005rD-By for freebsd-current@freebsd.org; Wed, 21 Dec 2005 20:51:00 +0100 Received: from r5k4.chello.upc.cz ([86.49.10.4]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Dec 2005 20:51:00 +0100 Received: from martinkov by r5k4.chello.upc.cz with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Dec 2005 20:51:00 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-current@freebsd.org From: martinko Date: Wed, 21 Dec 2005 17:26:53 +0100 Lines: 55 Message-ID: References: <1132743283.1197.55.camel@leguin> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: r5k4.chello.upc.cz User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20051205 X-Accept-Language: sk, cs, en-gb, en-us, en In-Reply-To: <1132743283.1197.55.camel@leguin> Sender: news Subject: Re: DRM update for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2005 19:53:24 -0000 Eric Anholt wrote: > I've got a patch at: > http://people.freebsd.org/~anholt/dri/drm-sys-20051123.diff > for testing, which merges DRM CVS into FreeBSD. I've done basic tests > of a recent DRM CVS with WITNESS on AGP/PCI Matrox, AGP/PCI Rage 128, > AGP Radeon r100/r200/r300, AGP Savage4 (new!), SiS, and 3dfx, and this > version should be equivalent to what I tested. I'll do another pass of > testing before I commit, but I'd also like to get some wider testing so > more panics can show up if they exist. This particular diff has only > been compile-tested with LINT on amd64 so far. > > Known issues: > - Radeon PCIGART mode hung for me. I've heard this is caused by a > change in X.Org upstream which itself worked around a different hang, so > those of you not using xorg-server-snap wouldn't hit it hopefully. > - Savage3d untested iirc > - Savage4 PCI doesn't work (needs some love in the memory mapping > department, I think). > > However, savage support has experimental and will only be on by default > with the next release of X.Org, so I feel OK with integrating it into > -current. > > So, for testing: If you get instant reboots while starting/using X, that > almost always means a kernel panic. This is new behavior in the last > year or so afaik (where a number of us have issues dumping while in X). > However, I've hooked up serial consoles and got backtraces fine, which > hopefully you can do if you hit issues, as well. > > Also, note that this brings in a new enough r300 driver for running Mesa > CVS's r300 driver, which hasn't been the case for a while. It doesn't > bring in the via driver, which jakeb ported but which got overcome by > new linux-specific code (volunteers to work on this in DRM CVS would be > excellent!) in CVS. Also, the i915 (i830 through i915 integrated > graphics) driver should be pretty quick for someone with a bit of newbus > knowledge to finish off, or it could be a chance someone who cared to > learn more about the FreeBSD kernel :) > eric, i've got only 64MB video memory, while : $ dmesg | g drm drm0: port 0xc800-0xc8ff mem 0xd0000000-0xd7ffffff,0xff8f0000-0xff8fffff irq 5 at device 0.0 on pci1 info: [drm] AGP at 0xe0000000 256MB info: [drm] Initialized radeon 1.19.0 20050911 note, that i'm running 6-stable and cvsuped recently just to discover that radeon driver is finally attaching. many thanks for your work! martin From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 20:08:17 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E45B16A41F for ; Wed, 21 Dec 2005 20:08:17 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 658DB43D90 for ; Wed, 21 Dec 2005 20:08:06 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.199] ([10.0.0.199]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id jBLK85iE024650 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Dec 2005 12:08:05 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <43A9B5EA.8030905@errno.com> Date: Wed, 21 Dec 2005 12:07:06 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Campi References: <20051221191919.GB17950@webcom.it> In-Reply-To: <20051221191919.GB17950@webcom.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Panic and LOR on -CURRENT with ath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 20:08:17 -0000 Andrea Campi wrote: > Hi, > > I have a Soekris box working as router/firewall/access point for my LAN, and > after my latest update (a few days ago) I've been having a couple of issues: > a LOR at boot, and a panic after some variable amount of time. I sort of > remember seeing something similar to the panic on a mailing list, but can't > find the thread. > > Since they appear regularly, if there's anything I can do to help debug the > issue I'm all ears. > > Bye, > Andrea > > > lock order reversal: (sleepable after non-sleepable) > 1st 0xc0d68d30 ath0 (network driver) @ /usr/src/sys/dev/ath/if_ath.c:4642 > 2nd 0xc0cfc878 user map (user map) @ /usr/src/sys/vm/vm_map.c:2997 > KDB: stack backtrace: > witness_checkorder(c0cfc878,9,c05fed2f,bb5,c5b7c924) at witness_checkorder+0x383 > _sx_xlock(c0cfc878,c05fed2f,bb5,2b7c928,c5b7c924) at _sx_xlock+0x3c > vm_map_lookup(c5b7c924,805e000,2,c5b7c928,c5b7c918,c5b7c91c,c5b7c8ff,c5b7c900) a > t vm_map_lookup+0x30 > vm_fault(c0cfc834,805e000,2,8,c0d5e900) at vm_fault+0x63 > trap_pfault(805e000) at trap_pfault+0x10b > trap(8,c0640028,c0d50028,805e000,c0da8e00) at trap+0x34a > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc05c0316, esp = 0xc5b7ca2c, ebp = 0xc5b7ca60 --- > generic_copyout(c0d65000,c0d90980,c0d68aac,c0286938,0) at generic_copyout+0x36 > ieee80211_ioctl(c0d681ac,c0286938,c0d90980) at ieee80211_ioctl+0x16a > ath_ioctl(c0d65000,c0286938,c0d90980) at ath_ioctl+0xb2 > ifhwioctl(c0d90980,c0d5e900,c0d65000,c0fd7590,c0286938) at ifhwioctl+0x1fd > ifioctl(c0fd7590,c0286938,c0d90980,c0d5e900) at ifioctl+0x5c > soo_ioctl(c0de75e8,c0286938,c0d90980,c0ce6d80,c0d5e900) at soo_ioctl+0x29d > ioctl(c0d5e900,c5b7cd04,3,13,206) at ioctl+0xfa > syscall(3b,3b,3b,805d028,805d000) at syscall+0x110 > Xint0x80_syscall() at Xint0x80_syscall+0x1f This is a driver lock held across an ioctl that does copyout and the destination faults. I've tried to get people to buy into a solution to the general problem w/o luck. > --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x2813f69f, esp =fe5d8 --- > > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0xdeadc0de > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc04dccc9 > stack pointer = 0x28:0xc5705c10 > frame pointer = 0x28:0xc5705c18 > 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 = 31 (swi6: task queue) > [thread pid 31 tid 100018 ] > Stopped at m_tag_delete_chain+0x29: movl 0(%ebx),%eax > db> bt > Tracing pid 31 tid 100018 td 0xc0cf3780 > m_tag_delete_chain(c103fb00,0,deadc0de,c5705c58,c057bc61) at m_tag_delete_chain+ > 0x29 > mb_dtor_mbuf(c103fb00,100,0) at mb_dtor_mbuf+0x38 > uma_zfree_arg(c0872e80,c103fb00,0) at uma_zfree_arg+0x2f1 > m_freem(c103fb00,c0d69188,0,c0fd2000,c5baa588) at m_freem+0x4e > ath_tx_processq(1,c0d6940c,c5705ce8,c04c1e51,c0d68000) at ath_tx_processq+0x109 > ath_tx_proc_q0123(c0d68000,1,c0ce779c,0,c05eea3e) at ath_tx_proc_q0123+0x24 > taskqueue_run(c0ce7780,0,c0d0e830,0,c048ff00) at taskqueue_run+0x81 > ithread_loop(c0ce7700,c5705d38,c0ce7700,c048ff00,0) at ithread_loop+0x175 > fork_exit(c048ff00,c0ce7700,c5705d38) at fork_exit+0x83 > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xc5705d6c, ebp = 0 --- It appears the mbuf was reclaimed while sitting on the tx queue waiting to be reaped. I've seen a few complaints of this sort but never enough info to start looking. This problem seems to be common to soekris h/w or perhaps this general config which is common on soekris h/w. Knowing the configuration might be useful; e.g. bridged config? what packet filter package? network setup? Sam From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 20:12:32 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D92316A41F for ; Wed, 21 Dec 2005 20:12:32 +0000 (GMT) (envelope-from lists@hosting50.cz) Received: from shinzon.blueboard.cz (shinzon.blueboard.cz [217.11.249.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 859D843D72 for ; Wed, 21 Dec 2005 20:12:26 +0000 (GMT) (envelope-from lists@hosting50.cz) Received: (qmail 64095 invoked by uid 89); 21 Dec 2005 20:12:21 -0000 Received: by simscan 1.1.0 ppid: 64089, pid: 64091, t: 0.2948s scanners: clamav: 0.87.1/m:34/d:1204 spam: 3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on shinzon.blueboard.cz X-Spam-Level: X-Spam-Status: No, score=-3.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.0 Received: from unknown (HELO ?10.15.141.2?) (tomas@blueboard.cz@217.11.239.237) by shinzon.blueboard.cz with (DHE-RSA-AES256-SHA encrypted) SMTP; 21 Dec 2005 20:12:21 -0000 Message-ID: <43A9B726.70207@hosting50.cz> Date: Wed, 21 Dec 2005 21:12:22 +0100 From: Tomas Randa User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: cs, en-us, en MIME-Version: 1.0 To: current@freebsd.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Dual core CPUs support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2005 20:12:32 -0000 Hello all friends of FreeBSD unix, I´d like to ask here, what is the actual situation with dual core CPUs - Athlon 64 X2 etc. and their functionality with FreeBSD 5.X / 6.X / 7.0 current. Few days ago, I bought X2 processor, but unexpectedly FreeBSD found only one CPU. I started to search google, but no exact informations is available. So I am trying this way, is anybody here who could say me status of Dual Core CPUs in FreeBSD and when (IF) they would be supported? I tried 5.4/i386 with options SMP, 6.0/i386 with the same config, in both cases system found only one CPU, but on 5.4 system wrote HTT 2 logical units. Thanks a lot for help. Tomas Randa From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 20:23:37 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3406916A425 for ; Wed, 21 Dec 2005 20:23:37 +0000 (GMT) (envelope-from tanis@gaspode.franken.de) Received: from karnickel.franken.de (karnickel.franken.de [193.141.110.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FF3B43D8A for ; Wed, 21 Dec 2005 20:23:23 +0000 (GMT) (envelope-from tanis@gaspode.franken.de) Received: from [193.141.104.200] (bertha.franken.de [193.141.104.200]) by karnickel.franken.de (8.12.10/8.12.10) with ESMTP id jBLKNH55039210; Wed, 21 Dec 2005 21:23:17 +0100 (CET) Message-ID: <43A9B9AD.50705@gaspode.franken.de> Date: Wed, 21 Dec 2005 21:23:09 +0100 From: German Tischler User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051210) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tomas Randa References: <43A9B726.70207@hosting50.cz> In-Reply-To: <43A9B726.70207@hosting50.cz> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: 8bit Cc: current@freebsd.org Subject: Re: Dual core CPUs support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2005 20:23:37 -0000 Hi, Tomas Randa wrote: > Hello all friends of FreeBSD unix, > > I´d like to ask here, what is the actual situation with dual core CPUs - > Athlon 64 X2 etc. and their functionality with FreeBSD 5.X / 6.X / 7.0 > current. > Few days ago, I bought X2 processor, but unexpectedly FreeBSD found only > one CPU. > I started to search google, but no exact informations is available. > So I am trying this way, is anybody here who could say me status of Dual > Core CPUs in FreeBSD and when (IF) they would be supported? > I tried 5.4/i386 with options SMP, 6.0/i386 with the same config, in > both cases system found only one CPU, but on 5.4 system wrote HTT 2 > logical units. my dmesg output contains ---- FreeBSD 6.0-STABLE #4: Sun Nov 20 19:54:13 CET 2005 ... ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2211.34-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20fb1 Stepping = 1 Features=0x178bfbff Features2=0x1 AMD Features=0xe2500800,LM,3DNow+,3DNow> real memory = 1073676288 (1023 MB) avail memory = 1026330624 (978 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ---- so it looks like FreeBSD 6 stable (and above) supports them. Btw: why are you trying to use FreeBSD i386 for an AMD64 cpu ? Best regards German Tischler From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 20:42:02 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D63F916A420 for ; Wed, 21 Dec 2005 20:42:02 +0000 (GMT) (envelope-from brucegb@realtime.net) Received: from ruth.realtime.net (ruth.realtime.net [205.238.132.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44B6E43D6D for ; Wed, 21 Dec 2005 20:41:54 +0000 (GMT) (envelope-from brucegb@realtime.net) Received: from tigerfish2.my.domain (cpe-70-112-148-128.austin.res.rr.com [70.112.148.128]) by realtime.net (Realtime Communications Advanced E-Mail Services V9.2) with ESMTP id 105093781 for ; Wed, 21 Dec 2005 14:41:50 -0500 Received: from tigerfish2.my.domain (localhost [127.0.0.1]) by tigerfish2.my.domain (8.13.4/8.13.4) with ESMTP id jBLKfnLX065766 for ; Wed, 21 Dec 2005 14:41:49 -0600 (CST) (envelope-from brucegb@tigerfish2.my.domain) Received: (from brucegb@localhost) by tigerfish2.my.domain (8.13.4/8.13.4/Submit) id jBLKfnBW065765 for current@freebsd.org; Wed, 21 Dec 2005 14:41:49 -0600 (CST) (envelope-from brucegb) Date: Wed, 21 Dec 2005 14:41:49 -0600 From: Bruce Burden To: current@freebsd.org Message-ID: <20051221204149.GM56798@tigerfish2.my.domain> References: <43A9B726.70207@hosting50.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A9B726.70207@hosting50.cz> User-Agent: Mutt/1.4.2.1i X-Server: High Performance Mail Server - http://surgemail.com r=-224271992 Cc: Subject: Re: Dual core CPUs support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2005 20:42:03 -0000 On Wed, Dec 21, 2005 at 09:12:22PM +0100, Tomas Randa wrote: > Hello all friends of FreeBSD unix, > > I?d like to ask here, what is the actual situation with dual core CPUs - > Athlon 64 X2 etc. and their functionality with FreeBSD 5.X / 6.X / 7.0 > current. > > I tried 5.4/i386 with options SMP, 6.0/i386 with the same config, in > both cases system found only one CPU, but on 5.4 system wrote HTT 2 > logical units. > The i386 version disables HTT by default (see the security notices for summer 2005 or thereabouts), so I am not surprised that your second core is ignored/not reported. There is a switch that will enable the HTT (second core, in your case) if you wish. As another poster mentiond, the AMD64 version of FBSD will recognise the second core as expected. Bruce -- ------------------------------------------------------------------------ "I like bad!" Bruce Burden Austin, TX. - Thuganlitha The Power and the Prophet Robert Don Hughes From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 21:37:18 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 255C916A41F for ; Wed, 21 Dec 2005 21:37:18 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.12]) by mx1.FreeBSD.org (Postfix) with SMTP id 7A1B343D60 for ; Wed, 21 Dec 2005 21:37:11 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 9554 invoked by uid 399); 21 Dec 2005 21:01:21 -0000 Received: from localhost (HELO ?192.168.1.101?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 21 Dec 2005 21:01:21 -0000 Message-ID: <43A9C296.9030403@FreeBSD.org> Date: Wed, 21 Dec 2005 13:01:10 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20051203) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: -current kernel as of this morning breaks the nvidia driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 21:37:18 -0000 I updated my -current system this morning, and the nvidia driver no longer works, even after rebuilding. Also, trying to kldunload the module causes an instant panic. Any ideas? Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 21:48:36 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 621E016A41F for ; Wed, 21 Dec 2005 21:48:36 +0000 (GMT) (envelope-from unixfreunde@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6ED443D6A for ; Wed, 21 Dec 2005 21:48:22 +0000 (GMT) (envelope-from unixfreunde@gmail.com) Received: by zproxy.gmail.com with SMTP id 8so255438nzo for ; Wed, 21 Dec 2005 13:48:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type:content-transfer-encoding; b=qonl1NwfDBaGKzZqDuX1+R0WRda2y8rZzcBujNIdslJwBEZFRMn7CCb1aXi//zt62jila9bPLCsbCKtNx5EA/vHy2MhqcwVCOdWInXp6ia/6NeH/JGR4tyWf9MlpH2sxCRKxvPoWV8IdlKd4/BFBnXf81rNIbKxXQ+w0wCMWm5c= Received: by 10.36.19.17 with SMTP id 17mr1202886nzs; Wed, 21 Dec 2005 13:48:21 -0800 (PST) Received: from splash.homeunix.org ( [84.141.36.109]) by mx.gmail.com with ESMTP id 34sm1796970nza.2005.12.21.13.48.19; Wed, 21 Dec 2005 13:48:21 -0800 (PST) Date: Wed, 21 Dec 2005 22:52:47 +0100 From: Martin Wilke To: freebsd-current@freebsd.org Message-ID: <20051221225247.3e7292e9@splash.homeunix.org> In-Reply-To: <43A9C296.9030403@FreeBSD.org> References: <43A9C296.9030403@FreeBSD.org> X-Mailer: Sylpheed-Claws 1.9.100 (GTK+ 2.8.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: base64 Subject: Re: -current kernel as of this morning breaks the nvidia driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 21:48:36 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMQ0KDQpPbiBXZWQs IDIxIERlYyAyMDA1IDEzOjAxOjEwIC0wODAwDQpEb3VnIEJhcnRvbiA8ZG91Z2JARnJlZUJTRC5v cmc+IHdyb3RlOg0KDQo+IEkgdXBkYXRlZCBteSAtY3VycmVudCBzeXN0ZW0gdGhpcyBtb3JuaW5n LCBhbmQgdGhlIG52aWRpYSBkcml2ZXIgbm8NCj4gbG9uZ2VyIHdvcmtzLCBldmVuIGFmdGVyIHJl YnVpbGRpbmcuIEFsc28sIHRyeWluZyB0byBrbGR1bmxvYWQgdGhlDQo+IG1vZHVsZSBjYXVzZXMg YW4gaW5zdGFudCBwYW5pYy4NCj4gDQo+IEFueSBpZGVhcz8NCj4gDQo+IERvdWcNCj4gDQoNClll cyB1cGdyYWRlIHlvdXIgc3JjIGFuZCBpbnN0YWxsIG52aWRpYSBuZXcuIHRoaXMgcnVubmlnLg0K DQoNCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQpWZXJzaW9uOiBHbnVQRyB2MS40LjIg KEZyZWVCU0QpDQoNCmlEOERCUUZEcWM2eUZSWi9rQlQ0dnA4UkFpL01BSjlTeDFkSE5SWCs1aytz WlNpVjhzQkxxLy82bWdDZmV2RHoNCjNZMXdlK1hudHBJTWkvRWc5ZE1ZUzVFPQ0KPWxlblMNCi0t LS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 21:58:19 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EFA016A41F for ; Wed, 21 Dec 2005 21:58:19 +0000 (GMT) (envelope-from andrea@acampi.hq.inet.it) Received: from acampi.hq.inet.it (out-11.hq.inet.it [194.185.62.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B1D643D9B for ; Wed, 21 Dec 2005 21:58:09 +0000 (GMT) (envelope-from andrea@acampi.hq.inet.it) Received: by acampi.hq.inet.it (Postfix, from userid 1000) id A84DD81; Wed, 21 Dec 2005 22:58:08 +0100 (CET) Resent-From: andrea@webcom.it Resent-Date: Wed, 21 Dec 2005 22:58:08 +0100 Resent-Message-ID: <20051221215808.GA30095@webcom.it> Resent-To: current@freebsd.org Date: Wed, 21 Dec 2005 22:54:57 +0100 From: Andrea Campi To: Sam Leffler Message-ID: <20051221215457.GE17950@webcom.it> References: <20051221191919.GB17950@webcom.it> <43A9B5EA.8030905@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A9B5EA.8030905@errno.com> User-Agent: Mutt/1.5.11 Cc: Andrea Campi , current@freebsd.org Subject: Re: Panic and LOR on -CURRENT with ath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 21:58:19 -0000 Sam, On Wed, Dec 21, 2005 at 12:07:06PM -0800, Sam Leffler wrote: > This is a driver lock held across an ioctl that does copyout and the > destination faults. I've tried to get people to buy into a solution to > the general problem w/o luck. Does this only need someone to sit down and code a solution, or is that a broader and not only technical issue? > It appears the mbuf was reclaimed while sitting on the tx queue waiting > to be reaped. I've seen a few complaints of this sort but never enough > info to start looking. This problem seems to be common to soekris h/w > or perhaps this general config which is common on soekris h/w. Knowing > the configuration might be useful; e.g. bridged config? what packet > filter package? network setup? Nope, no bridging; this is nanobsd with a GENERIC kernel minus a lot of stuff plus ipfw (which I also use for NAT). Nothing fancy really. It's not even under any high load. Is there anything I can investigate from DDB? Bye, Andrea -- Press every key to continue. From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 22:05:00 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1652116A41F for ; Wed, 21 Dec 2005 22:05:00 +0000 (GMT) (envelope-from garyj@jennejohn.org) Received: from mail08b.verio.de (mail08b.verio.de [213.198.55.74]) by mx1.FreeBSD.org (Postfix) with SMTP id ABAC543D66 for ; Wed, 21 Dec 2005 22:04:58 +0000 (GMT) (envelope-from garyj@jennejohn.org) Received: from mx08.stngva01.us.mxservers.net (204.202.242.4) by mail08b.verio.de (RS ver 1.0.95vs) with SMTP id 0-0203472695; Wed, 21 Dec 2005 23:04:57 +0100 (CET) Received: from www.jennejohn.org [213.198.5.174] (EHLO peedub.jennejohn.org) by mx08.stngva01.us.mxservers.net (mxl_mta-1.3.8-10p4) with ESMTP id 781d9a34.15641.064.mx08.stngva01.us.mxservers.net; Wed, 21 Dec 2005 17:04:55 -0500 (EST) Received: from jennejohn.org (localhost [127.0.0.1]) by peedub.jennejohn.org (8.13.4/8.11.6) with ESMTP id jBLM4rrR037479; Wed, 21 Dec 2005 23:04:54 +0100 (CET) (envelope-from garyj@jennejohn.org) Message-Id: <200512212204.jBLM4rrR037479@peedub.jennejohn.org> X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.0.4 To: Bruce Burden In-Reply-To: Message from Bruce Burden of "Wed, 21 Dec 2005 14:41:49 CST." <20051221204149.GM56798@tigerfish2.my.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Dec 2005 23:04:53 +0100 From: Gary Jennejohn X-Spam: [F=0.0100000000; heur=0.500(-19800); stat=0.010; spamtraq-heur=0.500(2005122110)] X-MAIL-FROM: X-SOURCE-IP: [213.198.5.174] X-Loop-Detect: 1 X-DistLoop-Detect: 1 Cc: current@freebsd.org Subject: Re: Dual core CPUs support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2005 22:05:00 -0000 Bruce Burden writes: > On Wed, Dec 21, 2005 at 09:12:22PM +0100, Tomas Randa wrote: > > Hello all friends of FreeBSD unix, > > > > I?d like to ask here, what is the actual situation with dual core CPUs - > > Athlon 64 X2 etc. and their functionality with FreeBSD 5.X / 6.X / 7.0 > > current. > > > > I tried 5.4/i386 with options SMP, 6.0/i386 with the same config, in > > both cases system found only one CPU, but on 5.4 system wrote HTT 2 > > logical units. > > > The i386 version disables HTT by default (see the security > notices for summer 2005 or thereabouts), so I am not surprised that > your second core is ignored/not reported. There is a switch that > will enable the HTT (second core, in your case) if you wish. > > As another poster mentiond, the AMD64 version of FBSD will > recognise the second core as expected. > HTT has nothing to do with recognizing an X2 AMD64. I've been running i386 since before 6R and FreeBSD has always seen both cores. Maybe the OP needs a new BIOS. I had to update my BIOS before the X2 was correctly recognized. --- Gary Jennejohn / garyjATjennejohnDOTorg gjATfreebsdDOTorg garyjATdenxDOTde From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 22:00:14 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71CD116A430 for ; Wed, 21 Dec 2005 22:00:14 +0000 (GMT) (envelope-from freebsd@deadcafe.de) Received: from deadcafe.de (deadcafe.de [81.169.162.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22C1B43D45 for ; Wed, 21 Dec 2005 22:00:10 +0000 (GMT) (envelope-from freebsd@deadcafe.de) Received: from dialin.t-online.de (p54A5D7EB.dip.t-dialin.net [84.165.215.235]) by deadcafe.de (8.13.4+Sun/8.13.4/Rock) with ESMTP id jBLM07WK064498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 21 Dec 2005 23:00:09 +0100 (CET) Received: from [172.23.7.254] (doom.rock.net [172.23.7.254]) by dialin.t-online.de (8.13.4+Sun/8.13.4/Rock) with ESMTP id jBLM00js076622; Wed, 21 Dec 2005 23:00:00 +0100 (CET) Message-ID: <43A9D060.6050707@deadcafe.de> Date: Wed, 21 Dec 2005 23:00:00 +0100 From: Daniel Rock User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: de-DE, de, en-us, en MIME-Version: 1.0 To: Tomas Randa References: <43A9B726.70207@hosting50.cz> In-Reply-To: <43A9B726.70207@hosting50.cz> Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.1 required=5.5 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on deadcafe.de X-Mailman-Approved-At: Wed, 21 Dec 2005 22:10:09 +0000 Cc: current@freebsd.org Subject: Re: Dual core CPUs support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2005 22:00:14 -0000 Tomas Randa schrieb: > Hello all friends of FreeBSD unix, > > I´d like to ask here, what is the actual situation with dual core CPUs - > Athlon 64 X2 etc. and their functionality with FreeBSD 5.X / 6.X / 7.0 > current. > Few days ago, I bought X2 processor, but unexpectedly FreeBSD found only > one CPU. > I started to search google, but no exact informations is available. > So I am trying this way, is anybody here who could say me status of Dual > Core CPUs in FreeBSD and when (IF) they would be supported? > I tried 5.4/i386 with options SMP, 6.0/i386 with the same config, in > both cases system found only one CPU, but on 5.4 system wrote HTT 2 > logical units. Upgrade your BIOS Daniel From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 22:08:31 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52B7816A41F; Wed, 21 Dec 2005 22:08:31 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBB3843D69; Wed, 21 Dec 2005 22:08:13 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 4315788 for multiple; Wed, 21 Dec 2005 17:09:51 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id jBLM8BbY029447; Wed, 21 Dec 2005 17:08:11 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 21 Dec 2005 17:08:44 -0500 User-Agent: KMail/1.8.2 References: <43A9C296.9030403@FreeBSD.org> In-Reply-To: <43A9C296.9030403@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512211708.45050.jhb@freebsd.org> X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Doug Barton Subject: Re: -current kernel as of this morning breaks the nvidia driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 22:08:31 -0000 On Wednesday 21 December 2005 04:01 pm, Doug Barton wrote: > I updated my -current system this morning, and the nvidia driver no longer > works, even after rebuilding. Also, trying to kldunload the module causes > an instant panic. > > Any ideas? Yeah, I said in my commit message that the vgapci and hostb changes probably break the nvidia driver, mostly the one where agp_info changes. I've talked to the folks at nvidia already and they are working on a patch. I don't have an ETA on it though. -- 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 Dec 21 23:14:28 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 212BB16A41F; Wed, 21 Dec 2005 23:14:28 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3062443D5F; Wed, 21 Dec 2005 23:14:26 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 4319221 for multiple; Wed, 21 Dec 2005 18:16:05 -0500 Received: from localhost (john@localhost [127.0.0.1]) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id jBLNEPjX029771; Wed, 21 Dec 2005 18:14:25 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 21 Dec 2005 17:16:44 -0500 User-Agent: KMail/1.8.2 References: <43A9C296.9030403@FreeBSD.org> <200512211708.45050.jhb@freebsd.org> In-Reply-To: <200512211708.45050.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512211716.46018.jhb@freebsd.org> X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Doug Barton Subject: Re: -current kernel as of this morning breaks the nvidia driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 23:14:28 -0000 On Wednesday 21 December 2005 05:08 pm, John Baldwin wrote: > On Wednesday 21 December 2005 04:01 pm, Doug Barton wrote: > > I updated my -current system this morning, and the nvidia driver no > > longer works, even after rebuilding. Also, trying to kldunload the module > > causes an instant panic. > > > > Any ideas? > > Yeah, I said in my commit message that the vgapci and hostb changes > probably break the nvidia driver, mostly the one where agp_info changes. > I've talked to the folks at nvidia already and they are working on a patch. > I don't have an ETA on it though. Hmm seems I forgot to mention that in the commit log actually. *sigh* The only thing that would actually kill it is the ABI change of agp_info (and it was also the only driver that used ai_aperture_va so it needs more than just a recompile). -- 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 Dec 21 23:16:25 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 708CD16A41F for ; Wed, 21 Dec 2005 23:16:25 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.12]) by mx1.FreeBSD.org (Postfix) with SMTP id 9F7E843D5A for ; Wed, 21 Dec 2005 23:16:24 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 92450 invoked by uid 399); 21 Dec 2005 23:00:10 -0000 Received: from localhost (HELO ?192.168.1.101?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 21 Dec 2005 23:00:08 -0000 Message-ID: <43A9DE76.8080904@FreeBSD.org> Date: Wed, 21 Dec 2005 15:00:06 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20051203) MIME-Version: 1.0 To: John Baldwin References: <43A9C296.9030403@FreeBSD.org> <200512211708.45050.jhb@freebsd.org> In-Reply-To: <200512211708.45050.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: -current kernel as of this morning breaks the nvidia driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 23:16:25 -0000 John Baldwin wrote: > On Wednesday 21 December 2005 04:01 pm, Doug Barton wrote: >> I updated my -current system this morning, and the nvidia driver no >> longer works, even after rebuilding. Also, trying to kldunload the >> module causes an instant panic. >> >> Any ideas? > > Yeah, I said in my commit message that the vgapci and hostb changes > probably break the nvidia driver, mostly the one where agp_info changes. > Sorry I missed that bit. I've been focused on the rc.d stuff lately. > I've talked to the folks at nvidia already and they are working on a > patch. I don't have an ETA on it though. Cool, I can live without it for now. Thanks, Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Wed Dec 21 23:24:39 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FC3516A41F for ; Wed, 21 Dec 2005 23:24:39 +0000 (GMT) (envelope-from rnoland@2hip.net) Received: from mailserver1.internap.com (mailserver1.internap.com [63.251.68.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE7C543D75 for ; Wed, 21 Dec 2005 23:24:38 +0000 (GMT) (envelope-from rnoland@2hip.net) Received: from [63.251.67.32] (account rnoland@mail.internap.com HELO bbeng-laptop.acs.internap.com) by mailserver1.internap.com (CommuniGate Pro SMTP 4.2.10) with ESMTP-TLS id 57309342 for freebsd-current@freebsd.org; Wed, 21 Dec 2005 18:24:37 -0500 From: "Robert C. Noland III" To: freebsd-current@freebsd.org Content-Type: text/plain Organization: 2 Hip Networks Date: Wed, 21 Dec 2005 18:24:34 -0500 Message-Id: <1135207474.963.5.camel@bbeng-laptop.acs.internap.com> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: evolution/spamassassin causing panic. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2005 23:24:39 -0000 Unfortunately I don't have serial console for now, so I can't get the backtrace. FreeBSD 7.0-CURRENT #29: Wed Dec 21 15:37:38 EST 2005 and ports updated as of last night. In evolution highlighting a message and then right clicking and selecting "mark as junk" is causing an immediate reboot. Can anyone confirm? robert. From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 00:26:23 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 758) id BBE4F16A420; Thu, 22 Dec 2005 00:26:23 +0000 (GMT) Date: Thu, 22 Dec 2005 00:26:23 +0000 From: Kris Kennaway To: Gary Jennejohn Message-ID: <20051222002623.GA63716@hub.freebsd.org> References: <20051221204149.GM56798@tigerfish2.my.domain> <200512212204.jBLM4rrR037479@peedub.jennejohn.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200512212204.jBLM4rrR037479@peedub.jennejohn.org> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org Subject: Re: Dual core CPUs support X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2005 00:26:23 -0000 On Wed, Dec 21, 2005 at 11:04:53PM +0100, Gary Jennejohn wrote: > > Bruce Burden writes: > > On Wed, Dec 21, 2005 at 09:12:22PM +0100, Tomas Randa wrote: > > > Hello all friends of FreeBSD unix, > > > > > > I?d like to ask here, what is the actual situation with dual core CPUs - > > > Athlon 64 X2 etc. and their functionality with FreeBSD 5.X / 6.X / 7.0 > > > current. > > > > > > I tried 5.4/i386 with options SMP, 6.0/i386 with the same config, in > > > both cases system found only one CPU, but on 5.4 system wrote HTT 2 > > > logical units. > > > > > The i386 version disables HTT by default (see the security > > notices for summer 2005 or thereabouts), so I am not surprised that > > your second core is ignored/not reported. There is a switch that > > will enable the HTT (second core, in your case) if you wish. > > > > As another poster mentiond, the AMD64 version of FBSD will > > recognise the second core as expected. > > > > HTT has nothing to do with recognizing an X2 AMD64. I've been running > i386 since before 6R and FreeBSD has always seen both cores. > > Maybe the OP needs a new BIOS. I had to update my BIOS before the X2 was > correctly recognized. Yes, that is almost certainly the solution. Kris From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 02:42:53 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96D0B16A41F for ; Thu, 22 Dec 2005 02:42:53 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11F9B43D4C for ; Thu, 22 Dec 2005 02:42:52 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.4/8.13.1) with ESMTP id jBM2gpAc019650; Wed, 21 Dec 2005 18:42:51 -0800 (PST) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.4/8.13.1/Submit) id jBM2golr019648; Wed, 21 Dec 2005 18:42:50 -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: martinko In-Reply-To: References: <1132743283.1197.55.camel@leguin> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Ub7xGmyyctqsnNck5hsi" Date: Wed, 21 Dec 2005 18:42:49 -0800 Message-Id: <1135219369.17506.3.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2 FreeBSD GNOME Team Port Cc: freebsd-current@freebsd.org Subject: Re: DRM update for testing X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2005 02:42:53 -0000 --=-Ub7xGmyyctqsnNck5hsi Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-12-21 at 17:26 +0100, martinko wrote: > Eric Anholt wrote: > > I've got a patch at: > > http://people.freebsd.org/~anholt/dri/drm-sys-20051123.diff > > for testing, which merges DRM CVS into FreeBSD. I've done basic tests > > of a recent DRM CVS with WITNESS on AGP/PCI Matrox, AGP/PCI Rage 128, > > AGP Radeon r100/r200/r300, AGP Savage4 (new!), SiS, and 3dfx, and this > > version should be equivalent to what I tested. I'll do another pass of > > testing before I commit, but I'd also like to get some wider testing so > > more panics can show up if they exist. This particular diff has only > > been compile-tested with LINT on amd64 so far. > >=20 > > Known issues: > > - Radeon PCIGART mode hung for me. I've heard this is caused by a > > change in X.Org upstream which itself worked around a different hang, s= o > > those of you not using xorg-server-snap wouldn't hit it hopefully. > > - Savage3d untested iirc > > - Savage4 PCI doesn't work (needs some love in the memory mapping > > department, I think). > >=20 > > However, savage support has experimental and will only be on by default > > with the next release of X.Org, so I feel OK with integrating it into > > -current. > >=20 > > So, for testing: If you get instant reboots while starting/using X, tha= t > > almost always means a kernel panic. This is new behavior in the last > > year or so afaik (where a number of us have issues dumping while in X). > > However, I've hooked up serial consoles and got backtraces fine, which > > hopefully you can do if you hit issues, as well.=20 > >=20 > > Also, note that this brings in a new enough r300 driver for running Mes= a > > CVS's r300 driver, which hasn't been the case for a while. It doesn't > > bring in the via driver, which jakeb ported but which got overcome by > > new linux-specific code (volunteers to work on this in DRM CVS would be > > excellent!) in CVS. Also, the i915 (i830 through i915 integrated > > graphics) driver should be pretty quick for someone with a bit of newbu= s > > knowledge to finish off, or it could be a chance someone who cared to > > learn more about the FreeBSD kernel :) > >=20 >=20 > eric, >=20 > i've got only 64MB video memory, while : >=20 > $ dmesg | g drm > drm0: port 0xc800-0xc8ff mem=20 > 0xd0000000-0xd7ffffff,0xff8f0000-0xff8fffff irq 5 at device 0.0 on pci1 > info: [drm] AGP at 0xe0000000 256MB > info: [drm] Initialized radeon 1.19.0 20050911 >=20 > note, that i'm running 6-stable and cvsuped recently just to discover=20 > that radeon driver is finally attaching. Yes, your AGP aperture is a limit on system memory usable by AGP. Totally unrelated to your video card's framebuffer size. --=20 Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org --=-Ub7xGmyyctqsnNck5hsi Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDqhKpHUdvYGzw6vcRAtXfAKCMWYjaDl/h6mKRdWF7PaK/ctJJxgCgm2nA KV9O7bdq3QWTLGlmtYU8A3I= =2yHW -----END PGP SIGNATURE----- --=-Ub7xGmyyctqsnNck5hsi-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 03:37:09 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C6AE16A41F for ; Thu, 22 Dec 2005 03:37:09 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: from bsd.ultra-secure.de (bsd.ultra-secure.de [62.146.20.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53FE343D62 for ; Thu, 22 Dec 2005 03:37:07 +0000 (GMT) (envelope-from rainer@ultra-secure.de) Received: (qmail 40671 invoked by uid 89); 22 Dec 2005 03:37:06 -0000 Received: by simscan 1.1.0 ppid: 40661, pid: 40665, t: 3.2403s scanners: attach: 1.1.0 clamav: 0.86.2/m:33/d:1045 spam: 3.0.4 Received: from unknown (HELO ?192.168.1.224?) (rainer@ultra-secure.de@217.71.83.52) by bsd.ultra-secure.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 22 Dec 2005 03:37:03 -0000 Message-ID: <43AA1F58.8030201@ultra-secure.de> Date: Thu, 22 Dec 2005 04:36:56 +0100 From: Rainer Duffner User-Agent: Mozilla Thunderbird 1.0.6 (X11/20051013) 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 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on bsd.ultra-secure.de X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.4 Cc: Subject: Can someone please update http://www.freebsd.org/projects/bigdisk/index.html with the values for 6.0 (and 7.0)? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2005 03:37:09 -0000 Hello, is the information on this page still "current"? http://www.freebsd.org/projects/bigdisk/index.html No quotas for filesystems > 2TB? fsck_ffs? df? NFS? Hello? cheers, Rainer From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 06:12:39 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E55C16A41F for ; Thu, 22 Dec 2005 06:12:39 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3F5343D5C for ; Thu, 22 Dec 2005 06:12:37 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.198] ([10.0.0.198]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id jBM6CZiE027707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Dec 2005 22:12:36 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <43AA4415.8070300@errno.com> Date: Wed, 21 Dec 2005 22:13:41 -0800 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Campi References: <20051221191919.GB17950@webcom.it> <43A9B5EA.8030905@errno.com> <20051221215457.GE17950@webcom.it> In-Reply-To: <20051221215457.GE17950@webcom.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Andrea Campi , current@freebsd.org Subject: Re: Panic and LOR on -CURRENT with ath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2005 06:12:39 -0000 Andrea Campi wrote: > Sam, > > On Wed, Dec 21, 2005 at 12:07:06PM -0800, Sam Leffler wrote: > >>This is a driver lock held across an ioctl that does copyout and the >>destination faults. I've tried to get people to buy into a solution to >>the general problem w/o luck. > > > Does this only need someone to sit down and code a solution, or is that > a broader and not only technical issue? It's a design issue with implications. The net80211 ioctl code is typically invoked from drivers w/ the driver lock held to guard against changes in state used by code that is invoked from an interrupt thread. But once inside net80211 there's no way to release the lock around calls like copyout. I've suggested exposing the driver lock to the net80211 layer so it can unlock+relock but gotten zero response so the problem remains. A concern is whether doing this forces driver locking into a particular model that is undesirable. This issue is really caused by the confusion in drivers over who is responsible for locking net80211 state. The net80211 layer handles the major pieces itself but some small bits are still implicitly handled by single-threading the rx path. Drivers that use the driver lock on the rx path must thus hold it over ioctl; other drivers do not except they cannot tell if an ioctl interacts with the rx path. > > >>It appears the mbuf was reclaimed while sitting on the tx queue waiting >>to be reaped. I've seen a few complaints of this sort but never enough >>info to start looking. This problem seems to be common to soekris h/w >>or perhaps this general config which is common on soekris h/w. Knowing >>the configuration might be useful; e.g. bridged config? what packet >>filter package? network setup? > > > Nope, no bridging; this is nanobsd with a GENERIC kernel minus a lot of > stuff plus ipfw (which I also use for NAT). Nothing fancy really. It's > not even under any high load. > > Is there anything I can investigate from DDB? The info you want is gone by the time the crash happens. Last time I chased a similar problem I did some private hacks to write-protect mbufs to catch unexpected modification. You might try removing ipfw or using an alternate packet filter if that's feasible. I wouldn't be surprised if this is related to ipfw and/or divert sockets. Sam From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 09:08:08 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17E9416A41F for ; Thu, 22 Dec 2005 09:08:08 +0000 (GMT) (envelope-from spil.oss@googlemail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C6B143D5E for ; Thu, 22 Dec 2005 09:08:05 +0000 (GMT) (envelope-from spil.oss@googlemail.com) Received: by nproxy.gmail.com with SMTP id l24so123399nfc for ; Thu, 22 Dec 2005 01:08:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=googlemail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=E3Ei0Q4L2/OeEHyuLIVsm3uFX6h5ybT1VYD1MX1Iqo+bXUIdWHeZw0pnmNIcs8IcDiNGdiyCrumWBPB9/wXVrwROLSN4BiEm9xLhnHYpIAw/JzcGqmN1FLGvs8RY4n9AHlAYcFoHAJc7+R9f3P9c5HCoRk/sheYEKFSpULeAAwc= Received: by 10.48.250.8 with SMTP id x8mr77928nfh; Thu, 22 Dec 2005 01:08:04 -0800 (PST) Received: by 10.48.215.13 with HTTP; Thu, 22 Dec 2005 01:08:04 -0800 (PST) Message-ID: <5fbf03c20512220108o72912108g6b7d011530bc9f88@mail.gmail.com> Date: Thu, 22 Dec 2005 10:08:04 +0100 From: Spil Oss To: =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= In-Reply-To: <43A492B6.6050305@t-hosting.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43A266E5.3080103@samsco.org> <20051217215434.GB92180@svcolo.com> <20051217220807.GA28741@freebie.xs4all.nl> <43A492B6.6050305@t-hosting.hu> Cc: Wilko Bulte , current , freebsd-stable@freebsd.org, Joe Rhett Subject: Re: HEADS UP: Release schedule for 2006 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2005 09:08:08 -0000 As a FreeBSD-n00b with some 'friends' that know FreeBSD better/well I can only say Please add this kind of information to the Handbook Any addition to the handbook on tracking down problems and smarter ways to fix things would be greatly appreciated. I found myself recompiling my kernel to test changes to a device's driver, but now you tell me I could have done that a lot smarter! Whenever I get my 'knickers-in-a-twist' when using FreeBSD my first point of reference is 'The Handbook'. Any additional information in there would greatly be appreciated. Learning-curve is very, very steep when you're used to lslpp and windowsupdate to patch your system. I _do_ appreciate that most developers and users are very experienced in using FreeBSD, but that makes it increasingly difficult for the not-so-fortunate to come up to speed with the use of FreeBSD. Spil. On 12/17/05, K=F6vesd=E1n G=E1bor wrote: > Wilko Bulte wrote: > > >On Sat, Dec 17, 2005 at 01:54:34PM -0800, Joe Rhett wrote.. > > > > > >>On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: > >> > >> > >>>There will be three FreeBSD 6 releases in 2006. > >>> > >>> > >>While this is nice, may I suggest that it is time to put aside/delay on= e > >>release cycle and come up with a binary update mechanism supported well= by > >>the OS? Increasing the speed of releases is good. Increasing the numb= er > >>of deployed systems out of date because there are no easy binary upgrad= e > >>mechanisms is bad. > >> > >>It has been bad, it's getting worse. > >> > >> > > > >So, when will you fix it? Or hire someone to fix it? FreeBSD after > >all is mostly a volunteer operation. > > > > > > > I agree. And after all, tracking a security branch isn't too difficult, > but the most people think that they have to do a complete "make > buildworld" after a security advisory, but this isn't true. For example > there was that cvsbug issue in September: > ftp://ftp.freebsd.org/pub/FreeBSD/CERT/advisories/FreeBSD-SA-05:20.cvsbug= .asc > One can read here: > > b) Execute the following commands as root: > > # cd /usr/src > # patch < /path/to/patch > # cd /usr/src/gnu/usr.bin/cvs/cvsbug > # make obj && make depend && make && make install > # cd /usr/src/gnu/usr.bin/send-pr > # make obj && make depend && make && make install > > Is that difficult? I don't think so. No reboot required and it doesn't > take more than 5 minutes even on a slower machine. Only the > vulnerabilities in the kernel are problematic for servers, since they > require a reboot. I think I'll submit a PR with a patch to clarify this > in Handbook. Do you consider this useful? > > Regards, > > Gabor Kovesdan > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 10:43:54 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9755916A41F; Thu, 22 Dec 2005 10:43:54 +0000 (GMT) (envelope-from dsh@vlink.ru) Received: from deliver.smtp.vlink.ru (vlink-1.avtlg.ru [83.239.142.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id E255443D46; Thu, 22 Dec 2005 10:43:53 +0000 (GMT) (envelope-from dsh@vlink.ru) Received: from smtp.smtp.vlink.ru (clamav.smtp.vlink.ru [192.168.4.1]) by deliver.smtp.vlink.ru (Postfix) with ESMTP id 9B8D6FED117; Thu, 22 Dec 2005 13:43:51 +0300 (MSK) Received: from neva.vlink.ru (neva.vlink.ru [217.107.252.29]) by smtp.smtp.vlink.ru (Postfix) with ESMTP id 5D03510098CF; Thu, 22 Dec 2005 13:43:51 +0300 (MSK) Received: from neva.vlink.ru (localhost [127.0.0.1]) by neva.vlink.ru (8.13.4/8.13.4) with ESMTP id jBMAhfuB031622; Thu, 22 Dec 2005 13:43:41 +0300 (MSK) (envelope-from dsh@vlink.ru) Received: (from dsh@localhost) by neva.vlink.ru (8.13.4/8.13.4/Submit) id jBMAheBG031619; Thu, 22 Dec 2005 13:43:40 +0300 (MSK) (envelope-from dsh@vlink.ru) To: freebsd-current@freebsd.org From: Denis Shaposhnikov Date: Thu, 22 Dec 2005 13:43:40 +0300 Message-ID: <87hd91fm3n.fsf@neva.vlink.ru> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: ClamAV using ClamSMTP Cc: Doug Barton Subject: troubles with /usr/local/etc/rc.d scripts in jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2005 10:43:54 -0000 Hi! Scripts with PROVIDE header don't running on jail's startup. Because early_late_divider="mountcritlocal" in /etc/defaults/rc.conf and mountcritlocal has nojail. This is one probleam. The second problem is "# REQUIRE: NETWORKING SERVERS" in a lots of scripts because they are running before ldconfig in this case. apache2.sh and mysql-server.sh for example. -- DSS5-RIPE DSS-RIPN 2:550/5068@fidonet 2:550/5069@fidonet mailto:dsh@vlink.ru http://neva.vlink.ru/~dsh/ From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 16:55:56 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD77E16A41F; Thu, 22 Dec 2005 16:55:56 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2729D43D49; Thu, 22 Dec 2005 16:55:56 +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 jBMGtr2K015360; Thu, 22 Dec 2005 08:55:53 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id jBMGtrBw015359; Thu, 22 Dec 2005 08:55:53 -0800 Date: Thu, 22 Dec 2005 08:55:53 -0800 From: Brooks Davis To: Denis Shaposhnikov Message-ID: <20051222165553.GB13683@odin.ac.hmc.edu> References: <87hd91fm3n.fsf@neva.vlink.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9zSXsLTf0vkW971A" Content-Disposition: inline In-Reply-To: <87hd91fm3n.fsf@neva.vlink.ru> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-current@freebsd.org, Doug Barton Subject: Re: troubles with /usr/local/etc/rc.d scripts in jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2005 16:55:56 -0000 --9zSXsLTf0vkW971A Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 22, 2005 at 01:43:40PM +0300, Denis Shaposhnikov wrote: > Hi! >=20 > Scripts with PROVIDE header don't running on jail's startup. Because > early_late_divider=3D"mountcritlocal" in /etc/defaults/rc.conf and > mountcritlocal has nojail. This is one probleam. I might make the early late divider NETWORKING. > The second problem is "# REQUIRE: NETWORKING SERVERS" in a lots of > scripts because they are running before ldconfig in this > case. apache2.sh and mysql-server.sh for example. Said scripts are broken in most casees. They should be "# REQUIRE: DAEMON". Very few things should start between SERVERS and DAEMON. The system isn't really bootstrapped until DAEMON. -- 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 --9zSXsLTf0vkW971A Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDqtqYXY6L6fI4GtQRAmO+AJ9dZTxS5dB+FTs5uAWUYvVESY2ufwCgzePl a3hbqlmI5hP9Cvb0rUd/ykU= =Adwy -----END PGP SIGNATURE----- --9zSXsLTf0vkW971A-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 18:17:18 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D298016A41F for ; Thu, 22 Dec 2005 18:17:18 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC28A43D5E for ; Thu, 22 Dec 2005 18:17:17 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 6500 invoked from network); 22 Dec 2005 18:23:36 -0000 Received: from c00l3r.networx.ch (HELO freebsd.org) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 22 Dec 2005 18:23:36 -0000 Message-ID: <43AAEDAC.54B51832@freebsd.org> Date: Thu, 22 Dec 2005 19:17:16 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Network performance measurements of -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2005 18:17:19 -0000 As part my funded TCP/IP optimization work I'm doing lots of measurements and profiling with an Agilent N2X network tester and calibrated traffic generator. The following data shall serve as baseline of the current performance we get out of FreeBSD 7-current. More to come tomorrow though. OS: FreeBSD 7-current as of 20051222-1600 UTC KERNEL: Generic kernel, minus WITNESS and INVARIANTS, plus HWPMC, HZ=1000 HARDWARE: Dual Opteron 852 2.6Ghz, Tyan S2882 Mobo with AMD-8131 PCI-X tunnel HARDWARE: dual Broadcom Gigabit BMC5704C PCI-X-133 ("bge") HARDWARE: dual Intel Gigabit 82546EB PCI-X-133 ("em") Uniprocessor kernel bge: normal forwarding bge0->bge1: @64/326kpps/166us/402kpps(30%Loss)/194us normal forwarding bge0->bge1: @1500/81kpps/520us normal forwarding bge0->disc0: @64/1205kpps IP fastforwarding bge0->bge1: @64/565kpps/192us/575kpps(60%Loss)/1090us IP fastforwarding bge0->bge1: @1500/81kpps/730us IP fastforwarding bge0->disc0: @64/1160kpps net.isr.direct=1 bge0->bge1: @64/476kpps/211us/487kpps(68%Loss)/1284us net.isr.direct=1 bge0->bge1: @1500/81kpps/760us net.isr.direct=1 bge0->disc0: @64/1250kpps polling (*) bge0->bge1: @64/420kpps(9%Loss)/1385us/416kpps(72%Loss)/1600us polling (*) bge0->bge1: @1500/71kpps(9%Loss)/850us polling (*) bge0->disc0: @64/697kpps Comments: Under full load the normal processing breaks completely down while with IP fastforwarding it levels off but continues to forward. Strangely with polling it has 9% loss at all loads (even at 1% wirespeed). May be related to HZ=1000. em: normal forwarding em0->em1: @64/372kpps/112us/396kpps(11%Loss)/131us normal forwarding em0->em1: @1500/81kpps/170us normal forwarding em0->disc0: @64/1130kpps IP fastforwarding em0->em1: @64/565kpps/45us/585kpps(4%Loss)/1600us IP fastforwarding em0->em1: @1500/81kpps/135us IP fastforwarding em0->disc0: @64/1116kpps net.isr.direct=1 em0->em1: later net.isr.direct=1 em0->disc0: later polling (*) em0->em1: later polling (*) em0->disc0: later (*) max_burst=1000, user_frac=0, each_burst=30 Sponsored by: TCP/IP Optimization Fundraise 2005 -- Andre From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 19:39:41 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DEFA316A41F for ; Thu, 22 Dec 2005 19:39:41 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mail2.fluidhosting.com [204.14.90.12]) by mx1.FreeBSD.org (Postfix) with SMTP id 1DA0743D5E for ; Thu, 22 Dec 2005 19:39:40 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 85713 invoked by uid 399); 22 Dec 2005 18:59:27 -0000 Received: from localhost (HELO ?192.168.1.101?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 22 Dec 2005 18:59:27 -0000 Message-ID: <43AAF78E.9030205@FreeBSD.org> Date: Thu, 22 Dec 2005 10:59:26 -0800 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Thunderbird 1.5 (X11/20051203) MIME-Version: 1.0 To: Brooks Davis References: <87hd91fm3n.fsf@neva.vlink.ru> <20051222165553.GB13683@odin.ac.hmc.edu> In-Reply-To: <20051222165553.GB13683@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Denis Shaposhnikov , freebsd-current@freebsd.org Subject: Re: troubles with /usr/local/etc/rc.d scripts in jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2005 19:39:42 -0000 Brooks Davis wrote: > On Thu, Dec 22, 2005 at 01:43:40PM +0300, Denis Shaposhnikov wrote: >> Hi! >> >> Scripts with PROVIDE header don't running on jail's startup. Because >> early_late_divider="mountcritlocal" in /etc/defaults/rc.conf and >> mountcritlocal has nojail. This is one probleam. Thanks for bringing this to our attention, and sorry for the hassle. > I might make the early late divider NETWORKING. I agree with Brooks here. If that works for you, can you please let us know? I can add another section to rc.conf(5) for jails like we did for diskless boot. >> The second problem is "# REQUIRE: NETWORKING SERVERS" in a lots of >> scripts because they are running before ldconfig in this >> case. apache2.sh and mysql-server.sh for example. > > Said scripts are broken in most casees. They should be "# REQUIRE: > DAEMON". Very few things should start between SERVERS and DAEMON. > The system isn't really bootstrapped until DAEMON. Agreed. Since for all intents and purposes the REQUIRE/BEFORE lines were being ignored in these scripts previously, we already know that there are going to have to be some adjustments. This process is a necessary step to providing the functionality of having local scripts start in the base rcorder, so we just have to buckle down and fix them. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 20:43:01 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0019016A41F for ; Thu, 22 Dec 2005 20:43:00 +0000 (GMT) (envelope-from andrea@acampi.hq.inet.it) Received: from acampi.hq.inet.it (out-11.hq.inet.it [194.185.62.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F18943D53 for ; Thu, 22 Dec 2005 20:42:59 +0000 (GMT) (envelope-from andrea@acampi.hq.inet.it) Received: by acampi.hq.inet.it (Postfix, from userid 1000) id E62057C; Thu, 22 Dec 2005 21:42:57 +0100 (CET) Date: Thu, 22 Dec 2005 21:42:57 +0100 From: Andrea Campi To: Sam Leffler Message-ID: <20051222204257.GD30118@webcom.it> References: <20051221191919.GB17950@webcom.it> <43A9B5EA.8030905@errno.com> <20051221215457.GE17950@webcom.it> <43AA4415.8070300@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43AA4415.8070300@errno.com> User-Agent: Mutt/1.5.11 Cc: Andrea Campi , current@freebsd.org Subject: Re: Panic and LOR on -CURRENT with ath X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2005 20:43:01 -0000 On Wed, Dec 21, 2005 at 10:13:41PM -0800, Sam Leffler wrote: > >Does this only need someone to sit down and code a solution, or is that > >a broader and not only technical issue? > > It's a design issue with implications. The net80211 ioctl code is > typically invoked from drivers w/ the driver lock held to guard against > changes in state used by code that is invoked from an interrupt thread. Yes, now I do remember you mentioning this before. So it looks like this isn't something I could help with, not unless a significant investment of time (which I sadly lack). But I might find it in a few months if nobody gets around to it sooner, as it would make a nice project for a networking course I have in the next semester. So basically I either have to live with it or turn off WITNESS, right? > The info you want is gone by the time the crash happens. Last time I > chased a similar problem I did some private hacks to write-protect mbufs > to catch unexpected modification. You might try removing ipfw or using > an alternate packet filter if that's feasible. I wouldn't be surprised > if this is related to ipfw and/or divert sockets. Will try switching to pf during the holidays (I've been meaning to do it but I kept procrastinating, so thanks for giving me an incentive ;-) Bye, Andrea -- Press every key to continue. From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 20:57:38 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7383D16A41F; Thu, 22 Dec 2005 20:57:38 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 040C543D5A; Thu, 22 Dec 2005 20:57:37 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id jBMKvaQL080636; Thu, 22 Dec 2005 12:57:36 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id jBMKvRTx042654; Thu, 22 Dec 2005 12:57:27 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id jBMKvPc2042652; Thu, 22 Dec 2005 12:57:25 -0800 (PST) (envelope-from jrhett) Date: Thu, 22 Dec 2005 12:57:25 -0800 From: Jo Rhett To: Chuck Swiger Message-ID: <20051222205725.GD39174@svcolo.com> References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> <43A4A557.3010600@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A4A557.3010600@mac.com> Organization: svcolo.com User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Thu, 22 Dec 2005 21:09:21 +0000 Cc: stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2005 20:57:38 -0000 On Sat, Dec 17, 2005 at 06:55:03PM -0500, Chuck Swiger wrote: > YMMV. I burned a 6.0 release from the ISO image, and did a binary upgrade on an > IBM ThinkPad (T.34? maybe), which worked perfectly. All of the 5.x binaries, > including X11, KDE, printing, Mozilla, etc worked just fine. There are no ISO for patch releases. And taking systems offline for a .1 update gets annoying fast. Dealing with all the file comparisons which are exactly the same except for the CVS tag takes hours for no good reason. Multiple many hours by hundreds of systems, and you could easily have a full time person just doing FreeBSD upgrades. > Upgrading the ports from there was somewhat annoying I don't care about ports, just the base OS. Ports we've built the infrastructure to handle properly, and very few ports are installed on production systems. > Now, if you want to talk about upgrading to intermediate patch releases, you've > got a valid point there. :-) That is exactly the point. Both .01 and .1 releases are annoying. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 20:59:53 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77C8016A41F; Thu, 22 Dec 2005 20:59:53 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6430E43D86; Thu, 22 Dec 2005 20:59:25 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id jBMKxGQp080676; Thu, 22 Dec 2005 12:59:22 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id jBMKwrD1042907; Thu, 22 Dec 2005 12:58:53 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id jBMKwrEU042905; Thu, 22 Dec 2005 12:58:53 -0800 (PST) (envelope-from jrhett) Date: Thu, 22 Dec 2005 12:58:53 -0800 From: Jo Rhett To: Kris Kennaway Message-ID: <20051222205853.GE39174@svcolo.com> References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> <20051217234627.GB68713@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051217234627.GB68713@xor.obsecurity.org> Organization: svcolo.com User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Thu, 22 Dec 2005 21:09:36 +0000 Cc: stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2005 20:59:53 -0000 > > On Fri, Dec 16, 2005 at 12:04:05AM -0700, Scott Long wrote: > > > There will be three FreeBSD 6 releases in 2006. > On Sat, Dec 17, 2005 at 02:00:21PM -0800, Joe Rhett wrote: > > While this is nice, may I suggest that it is time to put aside/delay one > > release cycle and come up with a binary update mechanism supported well by > > the OS? Increasing the speed of releases is good. Increasing the number > > of deployed systems out of date because there are no easy binary upgrade > > mechanisms is bad. > > > > It has been bad, it's getting worse. On Sat, Dec 17, 2005 at 06:46:27PM -0500, Kris Kennaway wrote: > Suggestions are nice, but who do you think will work on solving this? I and many others have proposed binary update mechanisms, and are all willing to work on them. The core freebsd team has not shown willingness to work with such an effort. Without that, we'd be patching the update mechanism with every new release, which kind of defeats the point. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 21:00:40 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 736BB16A420; Thu, 22 Dec 2005 21:00:40 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9794A43D81; Thu, 22 Dec 2005 21:00:22 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id jBML0GQX080798; Thu, 22 Dec 2005 13:00:22 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id jBML04ch043351; Thu, 22 Dec 2005 13:00:04 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id jBML03bq043346; Thu, 22 Dec 2005 13:00:03 -0800 (PST) (envelope-from jrhett) Date: Thu, 22 Dec 2005 13:00:03 -0800 From: Jo Rhett To: Matthew Seaman Message-ID: <20051222210003.GF39174@svcolo.com> References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> <43A4A557.3010600@mac.com> <43A53215.8090001@infracaninophile.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A53215.8090001@infracaninophile.co.uk> Organization: svcolo.com User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Thu, 22 Dec 2005 21:10:01 +0000 Cc: stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2005 21:00:40 -0000 On Sun, Dec 18, 2005 at 09:55:33AM +0000, Matthew Seaman wrote: > Doesn't creating a binary updates system that's going to be practical to use > require implementation of that old and exceedingly bikesheddable subject: > packaging up the base system? EXACTLY. That's why we need core team support. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 21:02:09 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2108F16A41F; Thu, 22 Dec 2005 21:02:09 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 181B543D70; Thu, 22 Dec 2005 21:01:44 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id jBML1aQb080835; Thu, 22 Dec 2005 13:01:40 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id jBML1GTJ043717; Thu, 22 Dec 2005 13:01:16 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id jBML1GWT043716; Thu, 22 Dec 2005 13:01:16 -0800 (PST) (envelope-from jrhett) Date: Thu, 22 Dec 2005 13:01:16 -0800 From: Jo Rhett To: Kris Kennaway Message-ID: <20051222210116.GG39174@svcolo.com> References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> <43A4A557.3010600@mac.com> <43A53215.8090001@infracaninophile.co.uk> <20051218171308.GA20557@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051218171308.GA20557@xor.obsecurity.org> Organization: svcolo.com User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Thu, 22 Dec 2005 21:10:56 +0000 Cc: stable@freebsd.org, Matthew Seaman , current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2005 21:02:09 -0000 > On Sun, Dec 18, 2005 at 09:55:33AM +0000, Matthew Seaman wrote: > > Doesn't creating a binary updates system that's going to be practical to use > > require implementation of that old and exceedingly bikesheddable subject: > > packaging > > up the base system? On Sun, Dec 18, 2005 at 12:13:09PM -0500, Kris Kennaway wrote: > No, after all the *existing* binary update systems don't require > packaging of the base system. None of which work properly in production environments. They work fine for home computers running GENERIC, and who can sustain some downtime for upgrade failures. And they are all completely un-auditable. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 21:09:33 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7337616A45C; Thu, 22 Dec 2005 21:09:33 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E7C843D78; Thu, 22 Dec 2005 21:09:20 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id jBML9HQX081107; Thu, 22 Dec 2005 13:09:20 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id jBML95JX045550; Thu, 22 Dec 2005 13:09:05 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id jBML94v1045547; Thu, 22 Dec 2005 13:09:04 -0800 (PST) (envelope-from jrhett) Date: Thu, 22 Dec 2005 13:09:04 -0800 From: Jo Rhett To: "Matthew D. Fuller" Message-ID: <20051222210904.GH39174@svcolo.com> References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> <20051218023725.GM63497@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051218023725.GM63497@over-yonder.net> Organization: svcolo.com User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Thu, 22 Dec 2005 21:13:49 +0000 Cc: stable@FreeBSD.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2005 21:09:33 -0000 > On Sat, Dec 17, 2005 at 02:00:21PM -0800 I heard the voice of > Joe Rhett, and lo! it spake thus: > > > > Increasing the number of deployed systems out of date [...] On Sat, Dec 17, 2005 at 08:37:25PM -0600, Matthew D. Fuller wrote: > This doesn't make any sense. If you install a 6.0 system, in 6 months > (assuming you installed it right when 6.0 was cut, for simplicity), it > will be 6 months out of date. It's neither more nor less out of date > if the current release is then 6.1, or 6.2, or 8.12; it's still 6 > months back. No, you're missing the point. More core OS upgrades means less incremental patches (which are easier to apply than a full update). That means that more systems will fall out of date because of the time-consuming nature of full operating system upgrades. > A case could, in fact, be made that more common releases lead to far > FEWER deployed systems out of date, since it makes it far easier for > those who already use binary upgrades instead of source to get things > faster. Huh? That's backwards. If we can't schedule the downtime for a full operating system upgrade (which takes far longer than it should) then the system won't get upgraded. Small incremental patches can be built on central systems and rsynced outwards fairly easily in comparison. > Now, this is not to say that easier incremental binary upgrades are a > bad thing, but bad analogy doesn't help anybody... Not to be rude, but I think your definition of analogy is wrong. There was no analogy in my comments - no parallelism at all. I was focused on the single topic, and not referring to anything else. Back to the point, the comments aren't "bad". Your idea that binary operating system upgrades from ISO are "easier" demonstrates that you're talking about home computers, not production servers. I'm talking about production environments, which I made very clear in my description. ...few have CDs ...many don't have local consoles, or local staff ...many don't have local disks at all (flash-based systems) "Install new OS from ISO" is completely impractical in all of these environments. "Install from source" is impossible in most. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 21:10:43 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69CBC16A422; Thu, 22 Dec 2005 21:10:43 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 226E643D45; Thu, 22 Dec 2005 21:10:41 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id jBMLAaQL081199; Thu, 22 Dec 2005 13:10:36 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id jBMLAKMd045889; Thu, 22 Dec 2005 13:10:20 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id jBMLAJVj045886; Thu, 22 Dec 2005 13:10:19 -0800 (PST) (envelope-from jrhett) Date: Thu, 22 Dec 2005 13:10:19 -0800 From: Jo Rhett To: Wilko Bulte Message-ID: <20051222211019.GI39174@svcolo.com> References: <43A266E5.3080103@samsco.org> <20051217215434.GB92180@svcolo.com> <20051217220807.GA28741@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051217220807.GA28741@freebie.xs4all.nl> Organization: svcolo.com User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Thu, 22 Dec 2005 21:13:58 +0000 Cc: stable@freebsd.org, current Subject: Re: HEADS UP: Release schedule for 2006 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2005 21:10:43 -0000 On Sat, Dec 17, 2005 at 11:08:07PM +0100, Wilko Bulte wrote: > So, when will you fix it? Or hire someone to fix it? FreeBSD after > all is mostly a volunteer operation. I and many others have offered to work on this. The core team has repeatedly stated that they won't integrate the efforts, which makes os-upgrade capability minimal and easily broken. (see current efforts) -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 21:14:34 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED38416A420; Thu, 22 Dec 2005 21:14:34 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from outbound0.sv.meer.net (outbound0.sv.meer.net [205.217.152.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7588E43D5E; Thu, 22 Dec 2005 21:14:34 +0000 (GMT) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (mail.meer.net [209.157.152.14]) by outbound0.sv.meer.net (8.12.10/8.12.6) with ESMTP id jBMLERQV081351; Thu, 22 Dec 2005 13:14:30 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: from mail.meer.net (localhost [127.0.0.1]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id jBMLE3UW046805; Thu, 22 Dec 2005 13:14:03 -0800 (PST) (envelope-from jrhett@mail.meer.net) Received: (from jrhett@localhost) by mail.meer.net (8.13.3/8.13.3) id jBMLE2hP046803; Thu, 22 Dec 2005 13:14:02 -0800 (PST) (envelope-from jrhett) Date: Thu, 22 Dec 2005 13:14:02 -0800 From: Jo Rhett To: K?vesd?n G?bor Message-ID: <20051222211402.GJ39174@svcolo.com> References: <43A266E5.3080103@samsco.org> <20051217215434.GB92180@svcolo.com> <20051217220807.GA28741@freebie.xs4all.nl> <43A492B6.6050305@t-hosting.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43A492B6.6050305@t-hosting.hu> Organization: svcolo.com User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Thu, 22 Dec 2005 21:15:32 +0000 Cc: Wilko Bulte , stable@freebsd.org, current Subject: Re: HEADS UP: Release schedule for 2006 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2005 21:14:35 -0000 On Sat, Dec 17, 2005 at 11:35:34PM +0100, K?vesd?n G?bor wrote: > I agree. And after all, tracking a security branch isn't too difficult, > but the most people think that they have to do a complete "make > buildworld" after a security advisory, but this isn't true. For example > there was that cvsbug issue in September: .. > # make obj && make depend && make && make install > > Is that difficult? I don't think so. No reboot required and it doesn't > take more than 5 minutes even on a slower machine. This comment demonstrates that you are again talking about home computers, while all of my comments indicated that I was talking about production systems. Ones that may not have sufficient memory to compile code, or local disks, or... In any case, you are right. This kind of patch is easy to apply. You can build it on a central server and synchronize it outwards to the others. The existing binary update mechanisms can handle this situation fairly well. But more "core OS" upgrades means less of these patches and more requirement for a full binary upgrade. Which is NOT easy like this. -- Jo Rhett senior geek SVcolo : Silicon Valley Colocation From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 21:30:57 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95B2A16A41F; Thu, 22 Dec 2005 21:30:57 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CACA43D45; Thu, 22 Dec 2005 21:30:54 +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 jBMLUfA1006361; Thu, 22 Dec 2005 13:30:41 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id jBMLUfPX006360; Thu, 22 Dec 2005 13:30:41 -0800 Date: Thu, 22 Dec 2005 13:30:41 -0800 From: Brooks Davis To: Jo Rhett Message-ID: <20051222213041.GA5746@odin.ac.hmc.edu> References: <43A266E5.3080103@samsco.org> <20051217215434.GB92180@svcolo.com> <20051217220807.GA28741@freebie.xs4all.nl> <20051222211019.GI39174@svcolo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pWyiEgJYm5f9v55/" Content-Disposition: inline In-Reply-To: <20051222211019.GI39174@svcolo.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: Wilko Bulte , stable@freebsd.org, current Subject: Re: HEADS UP: Release schedule for 2006 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2005 21:30:57 -0000 --pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 22, 2005 at 01:10:19PM -0800, Jo Rhett wrote: > On Sat, Dec 17, 2005 at 11:08:07PM +0100, Wilko Bulte wrote: > > So, when will you fix it? Or hire someone to fix it? FreeBSD after > > all is mostly a volunteer operation. > =20 > I and many others have offered to work on this. The core team has > repeatedly stated that they won't integrate the efforts, which makes > os-upgrade capability minimal and easily broken. (see current efforts) This statement makes no sense. The core team wouldn't have much to do with this other than possibly being involved in making any service official. Also, approval is never given to include a non-existent feature. Easy, binary updates sound like a great idea, but without seeing actual code thats all anyone can say other than offering advice. If volunteering is conditional on acceptance of the work, that's a chicken-egg problem and is not resolvable. We simply can't maintain quality if we accept non-existent code just because the idea sounds good. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDqxsAXY6L6fI4GtQRAqM4AJ9PNtHWGQ7GkdqoUuaR/WpI0LSnUwCdHQje gx1cWPr0p5dYmc8ImDs6Yt4= =9bQQ -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 21:46:55 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3095316A428; Thu, 22 Dec 2005 21:46:55 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F25343D46; Thu, 22 Dec 2005 21:45:16 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 4934C5D8C; Thu, 22 Dec 2005 16:45:05 -0500 (EST) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28305-05; Thu, 22 Dec 2005 16:45:04 -0500 (EST) Received: from [192.168.1.3] (pool-68-161-122-227.ny325.east.verizon.net [68.161.122.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pi.codefab.com (Postfix) with ESMTP id 14DA05C51; Thu, 22 Dec 2005 16:45:03 -0500 (EST) Message-ID: <43AB1E65.2030501@mac.com> Date: Thu, 22 Dec 2005 16:45:09 -0500 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jo Rhett References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> <43A4A557.3010600@mac.com> <20051222205725.GD39174@svcolo.com> In-Reply-To: <20051222205725.GD39174@svcolo.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2005 21:46:56 -0000 Jo Rhett wrote: > On Sat, Dec 17, 2005 at 06:55:03PM -0500, Chuck Swiger wrote: >>YMMV. I burned a 6.0 release from the ISO image, and did a binary upgrade on an >>IBM ThinkPad (T.34? maybe), which worked perfectly. All of the 5.x binaries, >>including X11, KDE, printing, Mozilla, etc worked just fine. > > There are no ISO for patch releases. FreeBSD releases new .ISO images several times a year, but you've got the tools to make .ISO images of patch releases yourself, if you want to. I don't think that the FreeBSD project can shorten the release cycle below a month or so, which means that patch releases are always going to be on the (b)leading edge... > And taking systems offline for a .1 > update gets annoying fast. Dealing with all the file comparisons which are > exactly the same except for the CVS tag takes hours for no good reason. > Multiple many hours by hundreds of systems, and you could easily have a > full time person just doing FreeBSD upgrades. Using a build server as a testbed and to generate new packages or even a new kernel + world will reduce the amount of work required, but FreeBSD does require some level of administration and maintenance. >> Upgrading the ports from there was somewhat annoying > > I don't care about ports, just the base OS. Ports we've built the > infrastructure to handle properly, and very few ports are installed on > production systems. I've got firewalls with a single-digit number of ports installed, but anything else seems to acquire 100-200 or so. >> Now, if you want to talk about upgrading to intermediate patch releases, you've >> got a valid point there. :-) > > That is exactly the point. Both .01 and .1 releases are annoying. I'm with you on this, but suggesting solutions is more useful than just noting the existence of problems. -- -Chuck From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 21:59:50 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E1A4016A41F; Thu, 22 Dec 2005 21:59:50 +0000 (GMT) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id B348943D58; Thu, 22 Dec 2005 21:59:48 +0000 (GMT) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn [127.0.0.1]) by gwyn.kn-bremen.de (8.13.4/8.13.4/Debian-3) with ESMTP id jBMLxlSR012745; Thu, 22 Dec 2005 22:59:47 +0100 Received: from saturn.kn-bremen.de (uucp@localhost) by gwyn.kn-bremen.de (8.13.4/8.13.4/Submit) with UUCP id jBMLxlwB012743; Thu, 22 Dec 2005 22:59:47 +0100 Received: from saturn.kn-bremen.de (localhost [127.0.0.1]) by saturn.kn-bremen.de (8.13.1/8.13.1) with ESMTP id jBMLtxVo001586; Thu, 22 Dec 2005 22:55:59 +0100 (CET) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.13.1/8.13.1/Submit) id jBMLtwuP001585; Thu, 22 Dec 2005 22:55:59 +0100 (CET) (envelope-from nox) From: Juergen Lock Date: Thu, 22 Dec 2005 22:55:58 +0100 To: freebsd-stable@freebsd.org Message-ID: <20051222215558.GA1240@saturn.kn-bremen.de> Mail-Followup-To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org References: <20051221221530.GA2390@saturn.kn-bremen.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051221221530.GA2390@saturn.kn-bremen.de> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Thu, 22 Dec 2005 22:10:08 +0000 Cc: freebsd-current@freebsd.org Subject: Re: cdboot troubles; 6.0 kernel hanging X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2005 21:59:51 -0000 On Wed, Dec 21, 2005 at 11:15:30PM +0100, Juergen Lock wrote: > I have this box that apparently no longer likes FreeBSD's cdboot, > it prints something about BOOT/LOADER and then just reboots. > Any ideas how to debug something like that? The box already has > FreeBSD installed (5.3 with some patches), and i tried copying the > 6.0 kernel from disc1 and loading it manually at the loader prompt. > It hangs after printing (boot -v): > GEOM: new disk ad0 > GEOM: new disk ad4 > > ad0 is on oboard pata (the board is a via kt400), ad4 is a single disk > on a Promise Fasttrack tx2200 sata controller. I guess i could try > to build a 6.0 kernel with ddb, but what would i be looking for then > to find out why its hanging? [...] I have now done that, here is a boot -v and ddb `ps' and `show thread' log of the hanging RELENG_6_0 GENERIC with ddb, does that tell anyone anything? (i dunno if the `call boot' crash at the end is important, probably not.) I need help... Oh, would it help if i retried this with a -current kernel? (I don't want to actually put -current on this box because it is my router and i want it to be stable, i just wanted to upgrade it to 6.0...) ----snip----- OK boot -v -s /boot/kernel/acpi.ko text=0x3fbfc data=0x1c04+0x112c syms=[0x4+0x72f0+0x4+0x97c7] KDB: debugger backends: ddb KDB: current backend: ddb SMAP type=01 base=0000000000000000 len=000000000009a000 SMAP type=02 base=00000000000f0000 len=0000000000010000 SMAP type=02 base=00000000fec00000 len=0000000000001000 SMAP type=02 base=00000000fee00000 len=0000000000001000 SMAP type=02 base=00000000ffff0000 len=0000000000010000 SMAP type=02 base=000000000009a000 len=0000000000006000 SMAP type=01 base=0000000000100000 len=000000001fef0000 SMAP type=03 base=000000001fff3000 len=000000000000d000 SMAP type=04 base=000000001fff0000 len=0000000000003000 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-RELEASE-p1 #1: Thu Dec 22 21:47:15 CET 2005 nox@saturn:/usr/obj/usr/home/nox/src6/src/sys/GENERICDB Preloaded elf kernel "/boot/kernel/kernel.60db" at 0xc0a98000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0a9825c. link_elf: symbol ioapic_enable_mixed_mode undefined KLD file acpi.ko - could not finalize loading MP Configuration Table version 1.1 found at 0xc00f1400 APIC: Using the MPTable enumerator. MPTable: Calibrating clock(s) ... i8254 clock: 1193267 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 2075028490 Hz CPU: AMD Athlon(tm) XP 2600+ (2075.03-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x681 Stepping = 1 Features=0x383fbff AMD Features=0xc0400800 Data TLB: 32 entries, fully associative Instruction TLB: 16 entries, fully associative L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative L2 internal cache: 256 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative real memory = 536805376 (511 MB) Physical memory chunk(s): 0x0000000000001000 - 0x0000000000099fff, 626688 bytes (153 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c25000 - 0x000000001f6b7fff, 514404352 bytes (125587 pages) avail memory = 516055040 (492 MB) bios32: Found BIOS32 Service Directory header at 0xc00faf00 bios32: Entry = 0xfb370 (c00fb370) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xb3a0 pnpbios: Bad PnP BIOS data checksum Other BIOS signatures found: ioapic0: Assuming intbase of 0 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) ioapic0: intpin 16 bus ISA ioapic0: Routing IRQ 10 -> intpin 16 ioapic0: intpin 10 disabled ioapic0: intpin 16 trigger: level ioapic0: intpin 16 polarity: low ioapic0: intpin 17 bus ISA ioapic0: Routing IRQ 11 -> intpin 17 ioapic0: intpin 11 disabled ioapic0: intpin 17 trigger: level ioapic0: intpin 17 polarity: low ioapic0: intpin 18 bus ISA ioapic0: Routing IRQ 10 -> intpin 18 ioapic0: intpin 18 trigger: level ioapic0: intpin 18 polarity: low ioapic0: intpin 19 bus ISA ioapic0: Routing IRQ 11 -> intpin 19 ioapic0: intpin 19 trigger: level ioapic0: intpin 19 polarity: low ioapic0: intpin 21 bus PCI ioapic0: intpin 21 trigger: level ioapic0: intpin 21 polarity: low ioapic0: intpin 21 bus PCI ioapic0: intpin 21 trigger: level ioapic0: intpin 21 polarity: low ioapic0: intpin 21 bus PCI ioapic0: intpin 21 trigger: level ioapic0: intpin 21 polarity: low ioapic0: intpin 19 bus PCI ioapic0: intpin 19 trigger: level ioapic0: intpin 19 polarity: low ioapic0: intpin 16 bus PCI ioapic0: intpin 16 trigger: level ioapic0: intpin 16 polarity: low ioapic0: intpin 22 bus PCI ioapic0: intpin 22 trigger: level ioapic0: intpin 22 polarity: low ioapic0: intpin 16 bus PCI ioapic0: intpin 16 trigger: level ioapic0: intpin 16 polarity: low ioapic0: intpin 18 bus PCI ioapic0: intpin 18 trigger: level ioapic0: intpin 18 polarity: low ioapic0: intpin 16 bus PCI ioapic0: intpin 16 trigger: level ioapic0: intpin 16 polarity: low ioapic0: intpin 17 bus PCI ioapic0: intpin 17 trigger: level ioapic0: intpin 17 polarity: low ioapic0: intpin 19 bus PCI ioapic0: intpin 19 trigger: level ioapic0: intpin 19 polarity: low ioapic0: intpin 1 bus ISA ioapic0: intpin 1 trigger: edge ioapic0: intpin 1 polarity: high ioapic0: intpin 2 bus ISA ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high ioapic0: intpin 3 bus ISA ioapic0: intpin 3 trigger: edge ioapic0: intpin 3 polarity: high ioapic0: intpin 4 bus ISA ioapic0: intpin 4 trigger: edge ioapic0: intpin 4 polarity: high ioapic0: intpin 5 bus ISA ioapic0: intpin 5 trigger: edge ioapic0: intpin 5 polarity: high ioapic0: intpin 6 bus ISA ioapic0: intpin 6 trigger: edge ioapic0: intpin 6 polarity: high ioapic0: intpin 7 bus ISA ioapic0: intpin 7 trigger: edge ioapic0: intpin 7 polarity: high ioapic0: intpin 8 bus ISA ioapic0: intpin 8 trigger: edge ioapic0: intpin 8 polarity: high ioapic0: intpin 9 bus ISA ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: high ioapic0: intpin 12 bus ISA ioapic0: intpin 12 trigger: edge ioapic0: intpin 12 polarity: high ioapic0: intpin 13 bus ISA ioapic0: intpin 13 trigger: edge ioapic0: intpin 13 polarity: high ioapic0: intpin 14 bus ISA ioapic0: intpin 14 trigger: edge ioapic0: intpin 14 polarity: high ioapic0: intpin 15 bus ISA ioapic0: intpin 15 trigger: edge ioapic0: intpin 15 polarity: high lapic: Routing ExtINT -> LINT0 lapic: Routing NMI -> LINT1 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00040010 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00000000 err: 0x00010000 pcm: 0x00010000 wlan: <802.11 Link Layer> null: random: nfslock: pseudo-device io: mem: Pentium Pro MTRR support enabled npx0: [FAST] npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard 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=31891106) pcibios: BIOS version 2.10 Found $PIR table, 12 entries at 0xc00fde90 PCI-Only Interrupts: 10 11 Location Bus Device Pin Link IRQs slot 1 0 8 A 0x01 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 B 0x02 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 C 0x03 3 4 5 7 9 10 11 12 14 15 slot 1 0 8 D 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 C 0x05 3 4 5 7 9 10 11 12 14 15 slot 2 0 9 D 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 A 0x03 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 B 0x05 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 C 0x01 3 4 5 7 9 10 11 12 14 15 slot 3 0 10 D 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 A 0x05 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 B 0x01 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 C 0x02 3 4 5 7 9 10 11 12 14 15 slot 4 0 11 D 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 12 A 0x01 3 4 5 7 9 10 11 12 14 15 slot 5 0 12 B 0x02 3 4 5 7 9 10 11 12 14 15 slot 5 0 12 C 0x03 3 4 5 7 9 10 11 12 14 15 slot 5 0 12 D 0x05 3 4 5 7 9 10 11 12 14 15 slot 6 0 14 A 0x03 3 4 5 7 9 10 11 12 14 15 slot 6 0 14 B 0x05 3 4 5 7 9 10 11 12 14 15 slot 6 0 14 C 0x01 3 4 5 7 9 10 11 12 14 15 slot 6 0 14 D 0x02 3 4 5 7 9 10 11 12 14 15 slot 7 0 15 A 0x05 3 4 5 7 9 10 11 12 14 15 slot 7 0 15 B 0x01 3 4 5 7 9 10 11 12 14 15 slot 7 0 15 C 0x02 3 4 5 7 9 10 11 12 14 15 slot 7 0 15 D 0x03 3 4 5 7 9 10 11 12 14 15 slot 8 0 13 A 0x02 3 4 5 7 9 10 11 12 14 15 slot 8 0 13 B 0x03 3 4 5 7 9 10 11 12 14 15 slot 8 0 13 C 0x05 3 4 5 7 9 10 11 12 14 15 slot 8 0 13 D 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 17 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 17 D 0x05 3 4 5 7 9 10 11 12 14 15 embedded 0 1 A 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 1 B 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 1 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 1 D 0x05 3 4 5 7 9 10 11 12 14 15 embedded 0 16 A 0x01 3 4 5 7 9 10 11 12 14 15 embedded 0 16 B 0x02 3 4 5 7 9 10 11 12 14 15 embedded 0 16 C 0x03 3 4 5 7 9 10 11 12 14 15 embedded 0 16 D 0x05 3 4 5 7 9 10 11 12 14 15 embedded 0 18 A 0x01 3 4 5 7 9 10 11 12 14 15 pcib0: pcibus 0 on motherboard pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x1106, dev=0x3189, revid=0x00 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x08 (240 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 map[10]: type 3, range 32, base d0000000, size 27, enabled found-> vendor=0x1106, dev=0xb168, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x2230, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x105a, dev=0x3571, revid=0x02 bus=0, slot=9, func=0 class=01-04-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=1 (dwords) lattimer=0x40 (1920 ns), mingnt=0x04 (1000 ns), maxlat=0x12 (4500 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D3 current D0 map[10]: type 4, range 32, base 0000a000, size 7, enabled map[18]: type 4, range 32, base 0000a400, size 8, enabled map[1c]: type 1, range 32, base e8180000, size 12, enabled map[20]: type 1, range 32, base e8100000, size 17, enabled pcib0: slot 9 INTA routed to irq 11 found-> vendor=0x8086, dev=0x1076, revid=0x00 bus=0, slot=10, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0230, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0xff (63750 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D3 current D0 MSI supports 1 message, 64 bit map[10]: type 1, range 32, base e8120000, size 17, enabled map[14]: type 1, range 32, base e8140000, size 17, enabled map[18]: type 4, range 32, base 0000a800, size 6, enabled pcib0: slot 10 INTA routed to irq 10 found-> vendor=0x1000, dev=0x000f, revid=0x26 bus=0, slot=11, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x11 (4250 ns), maxlat=0x40 (16000 ns) intpin=a, irq=11 powerspec 1 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000ac00, size 8, enabled map[14]: type 1, range 32, base e8181000, size 8, enabled map[18]: type 1, range 32, base e8182000, size 12, enabled pcib0: slot 11 INTA routed to irq 11 found-> vendor=0x1274, dev=0x1371, revid=0x08 bus=0, slot=12, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0105, statreg=0x0410, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x0c (3000 ns), maxlat=0x80 (32000 ns) intpin=a, irq=10 powerspec 1 supports D0 D2 D3 current D0 map[10]: type 4, range 32, base 0000b000, size 6, enabled pcib0: slot 12 INTA routed to irq 10 found-> vendor=0x1106, dev=0x3038, revid=0x80 bus=0, slot=16, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 0000b400, size 5, enabled pcib0: slot 16 INTA routed to irq 21 found-> vendor=0x1106, dev=0x3038, revid=0x80 bus=0, slot=16, func=1 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 0000b800, size 5, enabled pcib0: slot 16 INTB routed to irq 21 found-> vendor=0x1106, dev=0x3038, revid=0x80 bus=0, slot=16, func=2 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[20]: type 4, range 32, base 0000bc00, size 5, enabled pcib0: slot 16 INTC routed to irq 21 found-> vendor=0x1106, dev=0x3104, revid=0x82 bus=0, slot=16, func=3 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base e8183000, size 8, enabled pcib0: slot 16 INTD routed to irq 11 found-> vendor=0x1106, dev=0x3177, revid=0x00 bus=0, slot=17, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x0087, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D3 current D0 found-> vendor=0x1106, dev=0x0571, revid=0x06 bus=0, slot=17, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000c000, size 4, enabled found-> vendor=0x1106, dev=0x3059, revid=0x50 bus=0, slot=17, func=5 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000c400, size 8, enabled pcib0: slot 17 INTC routed to irq 22 found-> vendor=0x1106, dev=0x3065, revid=0x74 bus=0, slot=18, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x03 (750 ns), maxlat=0x08 (2000 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000c800, size 8, enabled map[14]: type 1, range 32, base e8184000, size 8, enabled pcib0: slot 18 INTA routed to irq 10 agp0: mem 0xd0000000-0xd7ffffff at device 0.0 on pci0 agp0: Reserved 0x8000000 bytes for rid 0x10 type 3 at 0xd0000000 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 0x9000-0x9fff pcib1: memory decode 0xe8000000-0xe80fffff pcib1: prefetched decode 0xd8000000-0xe7ffffff pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x1002, dev=0x4144, revid=0x00 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0087, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base d8000000, size 27, enabled pcib1: (null) requested memory range 0xd8000000-0xdfffffff: good map[14]: type 4, range 32, base 00009000, size 8, enabled pcib1: (null) requested I/O range 0x9000-0x90ff: in range map[18]: type 1, range 32, base e8020000, size 16, enabled pcib1: (null) requested memory range 0xe8020000-0xe802ffff: good pcib1: slot 0 INTA routed to irq 10 found-> vendor=0x1002, dev=0x4164, revid=0x00 bus=1, slot=0, func=1 class=03-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0080, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base e0000000, size 27, memory disabled pcib1: (null) requested memory range 0xe0000000-0xe7ffffff: good map[14]: type 1, range 32, base e8030000, size 16, enabled pcib1: (null) requested memory range 0xe8030000-0xe803ffff: good pci1: at device 0.0 (no driver attached) pci1: at device 0.1 (no driver attached) atapci0: port 0xa000-0xa07f,0xa400-0xa4ff mem 0xe8180000-0xe8180fff,0xe8100000-0xe811ffff irq 11 at device 9.0 on pci0 atapci0: rid 0x20 is memory, requested 4 atapci0: Reserved 0x20000 bytes for rid 0x20 type 3 at 0xe8100000 atapci0: Reserved 0x1000 bytes for rid 0x1c type 3 at 0xe8180000 atapci0: [MPSAFE] ata2: on atapci0 ata2: SATA connect ready time=0ms ata2: sata_connect devices=0x1 ata2: [MPSAFE] ata3: on atapci0 ata3: SATA connect status=00000000 ata3: [MPSAFE] ata4: on atapci0 ata4: reset tp1 mask=03 ostat0=e0 ostat1=f0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat0=0xa0 err=0xa0 lsb=0xa0 msb=0xa0 ata4: stat1=0xb0 err=0xb0 lsb=0xb0 msb=0xb0 ata4: reset tp2 stat0=a0 stat1=b0 devices=0x0 ata4: [MPSAFE] em0: port 0xa800-0xa83f mem 0xe8120000-0xe813ffff,0xe8140000-0xe815ffff irq 10 at device 10.0 on pci0 em0: Reserved 0x20000 bytes for rid 0x10 type 3 at 0xe8120000 em0: Reserved 0x40 bytes for rid 0x18 type 4 at 0xa800 em0: [MPSAFE] em0: bpf attached em0: Ethernet address: 00:0e:0c:6d:38:a9 em0: Speed:N/A Duplex:N/A sym0: <875> port 0xac00-0xacff mem 0xe8181000-0xe81810ff,0xe8182000-0xe8182fff irq 11 at device 11.0 on pci0 sym0: Reserved 0x100 bytes for rid 0x14 type 3 at 0xe8181000 sym0: Reserved 0x1000 bytes for rid 0x18 type 3 at 0xe8182000 sym0: chip clock is 40401KHz sym0: No NVRAM, ID 7, Fast-20, SE, parity checking sym0: open drain IRQ line driver, using on-chip SRAM sym0: using LOAD/STORE-based firmware. sym0: [GIANT-LOCKED] pci0: at device 12.0 (no driver attached) uhci0: port 0xb400-0xb41f irq 21 at device 16.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb400 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 uhci1: port 0xb800-0xb81f irq 21 at device 16.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xb800 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0xbc00-0xbc1f irq 21 at device 16.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xbc00 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xe8183000-0xe81830ff irq 11 at device 16.3 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xe8183000 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered isab0: at device 17.0 on pci0 isa0: on isab0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xc000-0xc00f at device 17.1 on pci0 atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0xc000 ata0: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci1: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 ata0: [MPSAFE] ata1: on atapci1 atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci1: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=50 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0xc ata1: [MPSAFE] pci0: at device 17.5 (no driver attached) vr0: port 0xc800-0xc8ff mem 0xe8184000-0xe81840ff irq 10 at device 18.0 on pci0 vr0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xc800 miibus0: on vr0 ukphy0: on miibus0 ukphy0: OUI 0x004063, model 0x0032, rev. 5 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: bpf attached vr0: Ethernet address: 00:0a:e6:55:d5:db vr0: [MPSAFE] ahc_isa_probe 10: ioport 0xac00 alloc failed ahc_isa_probe 11: ioport 0xbc00 alloc failed ex_isa_identify() ata: ata0 already exists; skipping it ata: ata1 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 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 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 0xc0000-0xccfff,0xd0000-0xd7fff,0xe2000-0xe2fff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0047 atkbd: keyboard ID 0x41ab (2) kbdc: RESET_KBD return code:00fa kbdc: RESET_KBD status:00aa kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x1d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0047 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 kbdc: RESET_AUX return code:00fa kbdc: RESET_AUX status:00aa kbdc: RESET_AUX ID:0000 psm: status 00 03 64 psm: status 00 00 64 psm: status 00 03 64 psm: status 00 03 64 psm: data 08 00 00 psm: status 00 03 64 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3-00, 3 buttons psm0: config:00000000, flags:00000008, packet size:4 psm0: syncmask:08, syncbits:00 bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fdc0: ic_type 90 part_id 80 fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: ic_type 90 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 pcic1: not probed (disabled) ppc0: parallel port found at 0x378 ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x100> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio0: irq maps: 0xc0c1 0xc0d1 0xc0c1 0xc0c1 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A, console sio1: irq maps: 0xc0c1 0xc0c9 0xc0c1 0xc0c1 sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A 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 lapic: Divisor 2, Frequency 166001945 hz Timecounter "TSC" frequency 2075028490 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=80 wire ad0: setting PIO4 on VIA 8235 chip ad0: setting UDMA133 on VIA 8235 chip ad0: 78167MB at ata0-master UDMA133 ad0: 160086528 sectors [158816C/16H/63S] 16 sectors/interrupt 1 depth queue ad0: VIA check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed ata1-slave: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=80 wire ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting PIO4 on VIA 8235 chip acd0: setting UDMA33 on VIA 8235 chip acd0: DVDROM drive at ata1 as master acd0: read 8268KB/s (8268KB/s), 512KB buffer, UDMA33 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 acd1: setting PIO4 on VIA 8235 chip acd1: setting UDMA33 on VIA 8235 chip acd1: DVDR drive at ata1 as slave acd1: read 6890KB/s (6890KB/s) write 6890KB/s (6890KB/s), 2048KB buffer, UDMA33 acd1: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd1: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof acd1: Audio: play, 256 volume levels acd1: Mechanism: ejectable tray, unlocked acd1: Medium: no/blank disc ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA133 cable=40 wire ad4: 152627MB at ata2-master SATA150 ad4: 312581808 sectors [310101C/16H/63S] 16 sectors/interrupt 1 depth queue ad4: Promise check1 failed ad4: Adaptec check1 failed ad4: LSI (v3) check1 failed ad4: LSI (v2) check1 failed ad4: FreeBSD 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 ad4 KDB: enter: Line break on console [thread pid 11 tid 100005 ] Stopped at kdb_enter+0x2b: nop db> tr Tracing pid 11 tid 100005 td 0xc1970780 kdb_enter(c088cf57) at kdb_enter+0x2b siointr1(c1af4400) at siointr1+0xce siointr(c1af4400) at siointr+0x38 intr_execute_handlers(c19a1090,d4480cb8,4,d4480cfc,c07ff6d3) at intr_execute_handlers+0x85 lapic_handle_intr(34) at lapic_handle_intr+0x2e Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc0806ba9, esp = 0xd4480cfc, ebp = 0xd4480cfc --- cpu_idle_default(d4480d10,c0628949,c196fa3c,d4480d24,c06286f8) at cpu_idle_default+0x5 cpu_idle(c196fa3c,d4480d24,c06286f8,0,d4480d38) at cpu_idle+0x1f idle_proc(0,d4480d38) at idle_proc+0x11 fork_exit(c0628938,0,d4480d38) at fork_exit+0x70 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd4480d6c, ebp = 0 --- db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd 44 c1a9f830 0 0 0 0000204 [IWAIT] swi0: sio 7 c1a9fa3c 0 0 0 0000204 [SLPQ - 0xc1a8de3c][SLP] fdc0 43 c1a9fc48 0 0 0 0000204 [SLPQ usbevt 0xc1a57210][SLP] usb3 42 c1aa0000 0 0 0 0000204 [SLPQ usbevt 0xc1a95210][SLP] usb2 41 c19b3c48 0 0 0 0000204 [SLPQ usbevt 0xc1a81210][SLP] usb1 40 c19c7000 0 0 0 0000204 [SLPQ usbtsk 0xc092e924][SLP] usbtask 39 c19c720c 0 0 0 0000204 [SLPQ usbevt 0xc1a78210][SLP] usb0 38 c19c7418 0 0 0 0000204 [IWAIT] swi2: cambio 6 c19c7624 0 0 0 0000204 [SLPQ - 0xc1a66400][SLP] kqueue taskq 37 c19c7830 0 0 0 0000204 [IWAIT] swi5:+ 5 c19c7a3c 0 0 0 0000204 [SLPQ - 0xc196e380][SLP] thread taskq 36 c19c7c48 0 0 0 0000204 [IWAIT] swi6:+ 35 c19c9000 0 0 0 0000204 [IWAIT] swi6: task queue 34 c19c920c 0 0 0 0000204 [SLPQ - 0xc092c640][SLP] yarrow 4 c19c9418 0 0 0 0000204 [SLPQ - 0xc092ee08][SLP] g_down 3 c19ab624 0 0 0 0000204 [SLPQ - 0xc092ee04][SLP] g_up 2 c19ab830 0 0 0 0000204 [SLPQ - 0xc092edfc][SLP] g_event 33 c19aba3c 0 0 0 0000204 [IWAIT] swi3: vm 32 c19abc48 0 0 0 000020c [IWAIT] swi4: clock sio 31 c19b3000 0 0 0 0000204 [IWAIT] swi1: net 30 c19b320c 0 0 0 0000204 [IWAIT] irq23: 29 c19b3418 0 0 0 0000204 [IWAIT] irq22: 28 c19b3624 0 0 0 0000204 [IWAIT] irq21: uhci0 uhci1+ 27 c19b3830 0 0 0 0000204 [IWAIT] irq20: 26 c19b3a3c 0 0 0 0000204 [IWAIT] irq11: atapci0 sym+ 25 c197520c 0 0 0 0000204 [IWAIT] irq10: em0 vr0 24 c1975418 0 0 0 0000204 [IWAIT] irq15: ata1 23 c1975624 0 0 0 0000204 [IWAIT] irq14: ata0 22 c1975830 0 0 0 0000204 [IWAIT] irq13: 21 c1975a3c 0 0 0 0000204 [IWAIT] irq12: psm0 20 c1975c48 0 0 0 0000204 [IWAIT] irq9: 19 c19ab000 0 0 0 0000204 [IWAIT] irq8: 18 c19ab20c 0 0 0 0000204 [IWAIT] irq7: ppc0 17 c19ab418 0 0 0 0000204 [IWAIT] irq6: fdc0 16 c196f000 0 0 0 0000204 [IWAIT] irq5: 15 c196f20c 0 0 0 0000204 [IWAIT] irq4: sio0 14 c196f418 0 0 0 0000204 [IWAIT] irq3: sio1 13 c196f624 0 0 0 0000204 [IWAIT] irq0: 12 c196f830 0 0 0 0000204 [IWAIT] irq1: atkbd0 11 c196fa3c 0 0 0 000020c [CPU 0] idle 1 c196fc48 0 0 0 0000200 [INACTIVE] swapper 10 c1975000 0 0 0 0000204 [SLPQ ktrace 0xc092f858][SLP] ktrace 0 c092ef00 0 0 0 0000200 [SLPQ conifhk 0xc08d1fac][SLP] swapper db> show thr 100046 (0xc19b4d80) sched_switch(c19b4d80,0,1) at sched_switch+0x14b 100047 (0xc19b4c00) sched_switch(c19b4c00,0,1) at sched_switch+0x14b 100048 (0xc19b4a80) sched_switch(c19b4a80,0,1) at sched_switch+0x14b 100049 (0xc19b4900) sched_switch(c19b4900,0,1) at sched_switch+0x14b 100027 (0xc19b4180) sched_switch(c19b4180,0,1) at sched_switch+0x14b 100028 (0xc19b4000) sched_switch(c19b4000,0,1) at sched_switch+0x14b 100029 (0xc1976d80) sched_switch(c1976d80,0,1) at sched_switch+0x14b 100030 (0xc1976c00) fork_trampoline() at fork_trampoline 100031 (0xc1976a80) sched_switch(c1976a80,0,1) at sched_switch+0x14b 100032 (0xc1976900) fork_trampoline() at fork_trampoline 100033 (0xc1976780) sched_switch(c1976780,0,1) at sched_switch+0x14b 100034 (0xc1976600) fork_trampoline() at fork_trampoline 100035 (0xc1976480) sched_switch(c1976480,0,1) at sched_switch+0x14b 100036 (0xc19cad80) sched_switch(c19cad80,0,1) at sched_switch+0x14b 100037 (0xc19cac00) sched_switch(c19cac00,0,1) at sched_switch+0x14b 100017 (0xc1972900) sched_switch(c1972900,0,1) at sched_switch+0x14b 100018 (0xc1972780) sched_switch(c1972780,0,1) at sched_switch+0x14b 100019 (0xc1972600) fork_trampoline() at fork_trampoline 100020 (0xc1972480) sched_switch(c1972480,0,1) at sched_switch+0x14b 100021 (0xc1972300) fork_trampoline() at fork_trampoline 100022 (0xc1972180) fork_trampoline() at fork_trampoline 100023 (0xc19b4780) fork_trampoline() at fork_trampoline 100024 (0xc19b4600) fork_trampoline() at fork_trampoline 100025 (0xc19b4480) fork_trampoline() at fork_trampoline 100026 (0xc19b4300) sched_switch(c19b4300,0,1) at sched_switch+0x14b 100008 (0xc1970300) fork_trampoline() at fork_trampoline 100009 (0xc1970180) sched_switch(c1970180,0,1) at sched_switch+0x14b 100010 (0xc1970000) sched_switch(c1970000,0,1) at sched_switch+0x14b 100011 (0xc1976300) fork_trampoline() at fork_trampoline 100012 (0xc1976180) fork_trampoline() at fork_trampoline 100013 (0xc1976000) fork_trampoline() at fork_trampoline 100014 (0xc1972d80) fork_trampoline() at fork_trampoline 100015 (0xc1972c00) fork_trampoline() at fork_trampoline 100016 (0xc1972a80) fork_trampoline() at fork_trampoline 100000 (0xc1972000) fork_trampoline() at fork_trampoline 100001 (0xc1970d80) fork_trampoline() at fork_trampoline 100002 (0xc1970c00) fork_trampoline() at fork_trampoline 100003 (0xc1970a80) fork_trampoline() at fork_trampoline 100004 (0xc1970900) sched_switch(c1970900,0,1) at sched_switch+0x14b 100005 (0xc1970780) kdb_enter(c088cf57) at kdb_enter+0x2b 100006 (0xc1970600) fork_trampoline() at fork_trampoline 100007 (0xc1970480) sched_switch(c1970480,0,1) at sched_switch+0x14b 0 (0xc092f120) sched_switch(c092f120,0,1) at sched_switch+0x14b db> call boot All buffers synced. Uptime: 1m0s kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8 fault code = supervisor write, page not present instruction pointer = 0x20:0xc065bb96 stack pointer = 0x28:0xd448083c frame pointer = 0x28:0xd4480848 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 11 (idle) trap number = 12 panic: page fault KDB: stack backtrace: kdb_backtrace(100,c1970780,28,d44807fc,c) at kdb_backtrace+0x29 panic(c0842351,c08902f9,0,fffff,c09b) at panic+0xa8 trap_fatal(d44807fc,8) at trap_fatal+0x2a2 trap(8,28,28,3e8,c1970780) at trap+0xf6 calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc065bb96, esp = 0xd448083c, ebp = 0xd4480848 --- sleepq_add(c1b999cc,c1b999a8,c084c5b7,1,0) at sleepq_add+0x66 cv_timedwait(c1b999cc,c1b999a8,fa0,c196ac00,c1b99960) at cv_timedwait+0x108 _sema_timedwait(c1b999a8,fa0,0,0) at _sema_timedwait+0x52 ata_queue_request(c1b99960,0,e7,c1b7e480,c1958280) at ata_queue_request+0x2a2 ata_controlcmd(c1b7e480,e7,0,0,0,0) at ata_controlcmd+0x78 ad_shutdown(c1b7e480) at ad_shutdown+0x2c device_shutdown(c1b7e480) at device_shutdown+0x42 bus_generic_shutdown(c1a66b00) at bus_generic_shutdown+0x16 device_shutdown(c1a66b00) at device_shutdown+0x42 bus_generic_shutdown(c19bec80) at bus_generic_shutdown+0x16 device_shutdown(c19bec80) at device_shutdown+0x42 bus_generic_shutdown(c1a66080) at bus_generic_shutdown+0x16 device_shutdown(c1a66080) at device_shutdown+0x42 bus_generic_shutdown(c1a66100) at bus_generic_shutdown+0x16 device_shutdown(c1a66100) at device_shutdown+0x42 bus_generic_shutdown(c1a66280) at bus_generic_shutdown+0x16 device_shutdown(c1a66280) at device_shutdown+0x42 bus_generic_shutdown(c196e680) at bus_generic_shutdown+0x16 device_shutdown(c196e680) at device_shutdown+0x42 bus_generic_shutdown(c19be000) at bus_generic_shutdown+0x16 device_shutdown(c19be000,d4480a08,c0634ced,c1966500,2) at device_shutdown+0x42 root_bus_module_handler(c1966500,2,0) at root_bus_module_handler+0xa7 module_shutdown(0,1) at module_shutdown+0x31 boot(1,0,2000003e,c0841ffb,d4480b4c,c06584a9,20,0,2,c089e860) at boot+0x4b2 db_fncall(3f8,0,ffffffff,d4480acc,0) at db_fncall+0xff db_command(c09181c4,c089e860,c08958e4,c0895900,c0841ff7) at db_command+0x264 db_command_loop(0,0,d4480b84,d4480b70,d4480bb8) at db_command_loop+0x5c db_trap(3,0,c1970780,3,d4480c04) at db_trap+0xdd kdb_trap(3,0,d4480c0c) at kdb_trap+0x6b trap(8,28,28,79,c1af4400) at trap+0x498 calltrap() at calltrap+0x5 --- trap 0x3, eip = 0xc06563ef, esp = 0xd4480c4c, ebp = 0xd4480c4c --- kdb_enter(c088cf57) at kdb_enter+0x2b siointr1(c1af4400) at siointr1+0xce siointr(c1af4400) at siointr+0x38 intr_execute_handlers(c19a1090,d4480cb8,4,d4480cfc,c07ff6d3) at intr_execute_handlers+0x85 lapic_handle_intr(34) at lapic_handle_intr+0x2e Xapic_isr1() at Xapic_isr1+0x33 --- interrupt, eip = 0xc0806ba9, esp = 0xd4480cfc, ebp = 0xd4480cfc --- cpu_idle_default(d4480d10,c0628949,c196fa3c,d4480d24,c06286f8) at cpu_idle_default+0x5 cpu_idle(c196fa3c,d4480d24,c06286f8,0,d4480d38) at cpu_idle+0x1f idle_proc(0,d4480d38) at idle_proc+0x11 fork_exit(c0628938,0,d4480d38) at fork_exit+0x70 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd4480d6c, ebp = 0 --- Uptime: 1m0s Cannot dump. No dump device defined. Automatic reboot in 15 seconds - press a key on the console to abort --> Press a key on the console to reboot, --> or switch off the system now. Rebooting... From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 22:16:56 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02FD216A41F for ; Thu, 22 Dec 2005 22:16:56 +0000 (GMT) (envelope-from jdelano@nspiral.com) Received: from smtpout03-03.mesa1.secureserver.net (smtpout03-03.mesa1.secureserver.net [64.202.165.73]) by mx1.FreeBSD.org (Postfix) with SMTP id 71C8543D4C for ; Thu, 22 Dec 2005 22:16:55 +0000 (GMT) (envelope-from jdelano@nspiral.com) Received: (qmail 14956 invoked from network); 22 Dec 2005 22:16:54 -0000 Received: from unknown (HELO gem-wbe02.mesa1.secureserver.net) (64.202.189.27) by smtpout03-03.mesa1.secureserver.net with SMTP; 22 Dec 2005 22:16:54 -0000 Received: (qmail 25461 invoked by uid 99); 22 Dec 2005 22:16:54 -0000 Date: Thu, 22 Dec 2005 15:16:54 -0700 From: jdelano@nspiral.com To: freebsd-current@freebsd.org Message-ID: <20051222151654.487394aa30c155c9a20129fbf28b1b35.82098b0558.wbe@email.email.secureserver.net> MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII X-Originating-IP: 216.75.24.38 Subject: ieee80211_input.c - typo? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2005 22:16:56 -0000 Hi Sam, Build with new patch for ath failed because of line 713 below *** src/sys/net80211/ieee80211_input.c Sun Dec 18 10:24:27 2005 --- /usr/src/sys/net80211/ieee80211_input.c Thu Dec 22 05:41:23 2005 *************** *** 710,716 **** if (m != NULL) { if (ni->ni_vlan != 0) { /* attach vlan tag */ ! VLAN_INPUT_TAG(ifp, m, ni->ni_vlan); /* <<<<< missing comma ? */ if (m == NULL) goto out; /* XXX goto err? */ } --- 710,716 ---- if (m != NULL) { if (ni->ni_vlan != 0) { /* attach vlan tag */ ! VLAN_INPUT_TAG(ifp, m, ni->ni_vlan,); if (m == NULL) goto out; /* XXX goto err? */ } Regards, JD From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 22:22:17 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A10E16A41F for ; Thu, 22 Dec 2005 22:22:17 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr10.xs4all.nl (smtp-vbr10.xs4all.nl [194.109.24.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CBB943D45 for ; Thu, 22 Dec 2005 22:22:05 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr10.xs4all.nl (8.13.3/8.13.3) with ESMTP id jBMMM2Xd033886; Thu, 22 Dec 2005 23:22:03 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.4/8.13.3) with ESMTP id jBMMLwaU000775; Thu, 22 Dec 2005 23:21:58 +0100 (CET) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.4/8.13.1/Submit) id jBMMLwvP000774; Thu, 22 Dec 2005 23:21:58 +0100 (CET) (envelope-from wb) Date: Thu, 22 Dec 2005 23:21:58 +0100 From: Wilko Bulte To: =?iso-8859-1?Q?S=F8ren?= Schmidt Message-ID: <20051222222158.GA726@freebie.xs4all.nl> References: <20051215194325.49909.qmail@web35908.mail.mud.yahoo.com> <43A1CCFE.10705@FreeBSD.org> <20051215201737.GA10846@freebie.xs4all.nl> <43A1D51D.7070804@deepcore.dk> <20051215211842.GA11418@freebie.xs4all.nl> <43A1DF77.4040307@deepcore.dk> <20051215214129.GA11777@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051215214129.GA11777@freebie.xs4all.nl> X-OS: FreeBSD 6.0-STABLE User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@FreeBSD.ORG Subject: Promise TX2300 results X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2005 22:22:17 -0000 On Thu, Dec 15, 2005 at 10:41:29PM +0100, Wilko Bulte wrote.. > On Thu, Dec 15, 2005 at 10:26:15PM +0100, Sren Schmidt wrote.. > > Wilko Bulte wrote: > > > > >>All RAID1's that ATA supports are sofware based, any controller can do > > >>here, unless you want to boot from it, you'd go for one that has BIOS > > >>support for RAID like the Promise TX2200.. > > > > > >Well, yes, booting is the issue yes. Seems in .NL TX2200 has become a rare > > >breed. Would a TX2300 also do? > > > > It should, I might not have all the PCI ID's in there yet (new ones keep > > popping up), but the support code is there, just needs the PCI ID in > > case its not found. > > OK. I ordered a 2300 and will let you know what develops :) Promise made, promise kept, the Promise TX2300 card was delivered today. RELENG_6 tapci0@pci2:13:0: class=0x010400 card=0x3570105a chip=0x3570105a rev=0x02 hdr=0x00 vendor = 'Promise Technology Inc' class = mass storage subclass = RAID atapci0: port 0xd480-0xd4ff,0xd000-0xd0ff mem 0xf7ff6000-0xf7ff6fff,0xf7fc0000-0xf7fdffff irq 21 at device 13.0 on pci2 ata2: on atapci0 ata3: on atapci0 ata4: on atapci0 The chip is marked: PDC20771 (not 20580). With ataraid in the kernel: ar0: 238418MB status: READY ar0: disk0 READY (master) using ad4 at ata2-master ar0: disk1 READY (mirror) using ad6 at ata3-master So first impression is that it 'Just Works'. Anything specific I should try? -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 22:51:59 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1807316A420 for ; Thu, 22 Dec 2005 22:51:59 +0000 (GMT) (envelope-from kabaev@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07F1643D49 for ; Thu, 22 Dec 2005 22:51:57 +0000 (GMT) (envelope-from kabaev@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so521225nzo for ; Thu, 22 Dec 2005 14:51:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=CUXyhs+cXbiiHgZJkNDRfyPfacxHgwQzOy8DvEF4+AT+llXLvLi+1bcDEsgGwE1cMzawPNhyHO81s8HiImldjR9jzY628k0+RSfovTYUyCO7L+6Q6Jy4mpHqyJDE8X2ddPJNhGPsOOIkIzcIVXcOsMrty5WmagKj+TuAn28H6vA= Received: by 10.36.109.2 with SMTP id h2mr745537nzc; Thu, 22 Dec 2005 14:51:57 -0800 (PST) Received: from kan.dnsalias.net ( [24.63.93.195]) by mx.gmail.com with ESMTP id r1sm1316164nzd.2005.12.22.14.51.56; Thu, 22 Dec 2005 14:51:56 -0800 (PST) Date: Thu, 22 Dec 2005 17:51:52 -0500 From: Alexander Kabaev To: Eric Anderson Message-ID: <20051222175152.292f510b@kan.dnsalias.net> In-Reply-To: <43A9AE07.3070501@centtech.com> References: <43A8BD3F.2010006@gddsn.org.cn> <20051220232754.48631fb4@kan.dnsalias.net> <20051221192118.GA88506@aoi.wolfpond.org> <43A9AE07.3070501@centtech.com> X-Mailer: Sylpheed-Claws 1.9.13 (GTK+ 2.6.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Signature_Thu__22_Dec_2005_17_51_52_-0500_Q/gyEzWX=haK7874"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Mailman-Approved-At: Thu, 22 Dec 2005 22:55:11 +0000 Cc: current@freebsd.org, openoffice@freebsd.org Subject: Re: [openoffice]no suitable windowing system found, exiting. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2005 22:51:59 -0000 --Signature_Thu__22_Dec_2005_17_51_52_-0500_Q/gyEzWX=haK7874 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable The commit below fixes OpenOffice 1.1.5 for me. kan 2005-12-22 16:42:38 UTC FreeBSD src repository Modified files: libexec/rtld-elf rtld.c=20 Log: Initialize object dagmembers list before checking version dependencies.=20 Revision Changes Path 1.110 +2 -4 src/libexec/rtld-elf/rtld.c http://cvsweb.FreeBSD.org/src/libexec/rtld-elf/rtld.c.diff?r1=3D1.109&r2=3D= 1.110 --=20 Alexander Kabaev --Signature_Thu__22_Dec_2005_17_51_52_-0500_Q/gyEzWX=haK7874 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDqy4LQ6z1jMm+XZYRAr0pAJ9IFvesc80ABZA5k5cUGPv3pgf5QgCfWvqq AGJSgz6gAmQb/KVql/LGxDw= =F57m -----END PGP SIGNATURE----- --Signature_Thu__22_Dec_2005_17_51_52_-0500_Q/gyEzWX=haK7874-- From owner-freebsd-current@FreeBSD.ORG Thu Dec 22 23:13:52 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C985716A41F for ; Thu, 22 Dec 2005 23:13:52 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6153C43D55 for ; Thu, 22 Dec 2005 23:13:52 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: by lh.synack.net (Postfix, from userid 100) id 3F6B55E48DC; Thu, 22 Dec 2005 15:13:52 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 608D85E47EF for ; Thu, 22 Dec 2005 15:13:50 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <36D83F22-D5E0-4525-841D-4A03C64C0A19@freebsd.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-current@freebsd.org From: Jason Evans Date: Thu, 22 Dec 2005 15:13:47 -0800 X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Subject: Adding RB_NFIND() to sys/tree.h X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2005 23:13:53 -0000 I'd like to add RB_NFIND() to sys/tree.h, since I need it for the malloc implementation I've been working on. Mark Murray suggested that I ask for comments here before committing. sys/tree.h comes from NetBSD, and up to now, the only changes we've made have been for the purpose of avoiding compiler warnings. RB_NFIND() is like RB_FIND(), but if an exact match isn't found, RB_NFIND() returns the next object in the tree (if there is one). Emulating RB_NFIND() with the existing RB_*() API is possible, but certainly not ideal. I would claim that RB_PFIND() isn't necessary, since it could be easily (if not quite as efficiently) emulated with RB_NFIND(), followed by RB_PREV(). However, there is no RB_PREV(), even though there is RB_NEXT(). This seems to me like an API design oversight (as is the omission of RB_FOREACH_REVERSE()), but it doesn't cause me issues, so I haven't tackled it. A patch follows (manpage changes omitted). Are there any objections to committing this? Thanks, Jason Index: sys/sys/tree.h =================================================================== RCS file: /home/ncvs/src/sys/sys/tree.h,v retrieving revision 1.3 diff -u -r1.3 tree.h --- sys/sys/tree.h 10 Jun 2005 11:44:57 -0000 1.3 +++ sys/sys/tree.h 17 Dec 2005 03:00:01 -0000 @@ -382,6 +382,7 @@ struct type *name##_RB_REMOVE(struct name *, struct type *); \ struct type *name##_RB_INSERT(struct name *, struct type *); \ struct type *name##_RB_FIND(struct name *, struct type *); \ +struct type *name##_RB_NFIND(struct name *, struct type *); \ struct type *name##_RB_NEXT(struct type *); \ struct type *name##_RB_MINMAX(struct name *, int); \ \ @@ -628,6 +629,35 @@ return (NULL); \ } \ \ +/* Finds the first node greater than or equal to the search key */ \ +struct type * \ +name##_RB_NFIND(struct name *head, struct type *elm) \ +{ \ + struct type *ret = RB_ROOT(head); \ + struct type *tmp; \ + int comp; \ + while (ret && (comp = cmp(elm, ret)) != 0) { \ + if (comp < 0) { \ + if ((tmp = RB_LEFT(ret, field)) == NULL) \ + break; \ + ret = tmp; \ + } else { \ + if ((tmp = RB_RIGHT(ret, field)) == NULL) { \ + tmp = ret; \ + ret = RB_PARENT(ret, field); \ + while (ret && tmp == RB_RIGHT(ret, \ + field)) { \ + tmp = ret; \ + ret = RB_PARENT(ret, field); \ + } \ + break; \ + } \ + ret = tmp; \ + } \ + } \ + return (ret); \ +} \ + \ /* ARGSUSED */ \ struct type * \ name##_RB_NEXT(struct type *elm) \ @@ -671,6 +701,7 @@ #define RB_INSERT(name, x, y) name##_RB_INSERT(x, y) #define RB_REMOVE(name, x, y) name##_RB_REMOVE(x, y) #define RB_FIND(name, x, y) name##_RB_FIND(x, y) +#define RB_NFIND(name, x, y) name##_RB_NFIND(x, y) #define RB_NEXT(name, x, y) name##_RB_NEXT(y) #define RB_MIN(name, x) name##_RB_MINMAX(x, RB_NEGINF) #define RB_MAX(name, x) name##_RB_MINMAX(x, RB_INF) From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 00:12:37 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78B9016A41F for ; Fri, 23 Dec 2005 00:12:37 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3366143D5D for ; Fri, 23 Dec 2005 00:12:22 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.198] ([10.0.0.198]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id jBN0CKiE032825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Dec 2005 16:12:21 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <43AB4126.8020004@errno.com> Date: Thu, 22 Dec 2005 16:13:26 -0800 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jdelano@nspiral.com References: <20051222151654.487394aa30c155c9a20129fbf28b1b35.82098b0558.wbe@email.email.secureserver.net> In-Reply-To: <20051222151654.487394aa30c155c9a20129fbf28b1b35.82098b0558.wbe@email.email.secureserver.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ieee80211_input.c - typo? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 00:12:37 -0000 jdelano@nspiral.com wrote: > Hi Sam, > > Build with new patch for ath failed because of line 713 below > > > *** src/sys/net80211/ieee80211_input.c Sun Dec 18 10:24:27 2005 > --- /usr/src/sys/net80211/ieee80211_input.c Thu Dec 22 05:41:23 2005 > *************** > *** 710,716 **** > if (m != NULL) { > if (ni->ni_vlan != 0) { > /* attach vlan tag */ > ! VLAN_INPUT_TAG(ifp, m, ni->ni_vlan); /* <<<<< missing comma ? */ > if (m == NULL) > goto out; /* XXX goto err? */ > } > --- 710,716 ---- > if (m != NULL) { > if (ni->ni_vlan != 0) { > /* attach vlan tag */ > ! VLAN_INPUT_TAG(ifp, m, ni->ni_vlan,); > if (m == NULL) > goto out; /* XXX goto err? */ > } > The vlan code changed; you'll need to fix the output of the patch. Not sure when I'll have time to update it. Sam From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 00:58:23 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCFF416A41F; Fri, 23 Dec 2005 00:58:23 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6BB443D45; Fri, 23 Dec 2005 00:58:22 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.21]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id jBN0uuWR033158 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 23 Dec 2005 11:26:56 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Fri, 23 Dec 2005 11:26:44 +1030 User-Agent: KMail/1.8.3 References: <43A266E5.3080103@samsco.org> <43A4B91D.8040304@samsco.org> <20051222211730.GK39174@svcolo.com> In-Reply-To: <20051222211730.GK39174@svcolo.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2057809.76DZ9OFnvS"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200512231126.51500.doconnor@gsoft.com.au> X-Spam-Score: -1.36 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: current , Jo Rhett , stable@freebsd.org, K?vesd?n G?bor , Peter Jeremy Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 00:58:24 -0000 --nextPart2057809.76DZ9OFnvS Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 23 Dec 2005 07:47, Jo Rhett wrote: > On Sat, Dec 17, 2005 at 06:19:25PM -0700, Scott Long wrote: > > FreeBSD Update was written by, and is continuously maintained by the > > actual FreeBSD Security Officer. It's as official as it gets. If > > the only barrier to acceptance is that it's not distributed from the > > FreeBSD.org domain, then a) that's a silly argument, and b) it's easily > > solvable so long as Colin agrees. > > But FreeBSD Update suffers from all of the same limitations that I've been > describing because of lack of integration with the Core OS. > > 1. modified kernels are foobar > ..yet are practically mandatory on production systems > > 2. modified sources are foobar > ..yet many common production situations require source compilation > options How do you expect these two to be handled in a binary upgrade? I can't see how it's possible.. I don't think integrating it with the core OS (whatever that means) will=20 magically fix this. > 3. FreeBSD Update can't handle updates of jails and other situations that > package systems deal with just fine. Not having run jails I am not very qualified to comment, however, I don't s= ee=20 why you can't just run freebsd update inside your jail(s). If you mean that= =20 it would be good if you could automatically upgrade a large number of jails= =20 and rebuild link farms etc etc.. well sure that isn't supported, but it is = a=20 very difficult problem to solve (I believe). =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 --nextPart2057809.76DZ9OFnvS Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDq0tT5ZPcIHs/zowRArtPAJ4vH5OgQm59MXIs+PEl1PbQpQ2vxACfcmV0 /fp/zYIGzpSSJvIhsIdHhns= =mKZ7 -----END PGP SIGNATURE----- --nextPart2057809.76DZ9OFnvS-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 01:06:20 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89EB816A420; Fri, 23 Dec 2005 01:06:20 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78A2A43D68; Fri, 23 Dec 2005 01:06:16 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.21]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id jBN16ERM037992 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 23 Dec 2005 11:36:15 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Fri, 23 Dec 2005 11:36:11 +1030 User-Agent: KMail/1.8.3 References: <43A266E5.3080103@samsco.org> <43AB1E65.2030501@mac.com> <20051222221202.GM39174@svcolo.com> In-Reply-To: <20051222221202.GM39174@svcolo.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart162186818.BU15SNjyMy"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200512231136.12471.doconnor@gsoft.com.au> X-Spam-Score: -1.36 () ALL_TRUSTED,SUBJECT_EXCESS_QP X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: Jo Rhett , stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 01:06:20 -0000 --nextPart162186818.BU15SNjyMy Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 23 Dec 2005 08:42, Jo Rhett wrote: > > Using a build server as a testbed and to generate new packages or even a > > new kernel + world will reduce the amount of work required, but FreeBSD > > does require some level of administration and maintenance. > > We already have that. But again, I'm not sure what you are trying to say > here. The centralized server makes patching and port upgrades easier. It > does _NOTHING_ for core OS upgrades because there is no supported mechani= sm > for doing binary upgrades except from the ISO. Thus, we are finally back > on topic. Uhh.. On your central PC.. buildworld once. builkernel once for each of the different kernels you are using. On each 'client' PC.. NFS mount /usr/src and /usr/obj installkernel reboot installworld Sure there are no tools to automagically do this, but I don't believe core= =20 would say "no, we will never support this". > I have made suggestions. Everyone has made suggestions. Most of us have > produced code to work around the problem, but the core OS team has always > refused to support or acknowledge these efforts. You are putting words in the mouth of core@ - I find it very hard to believ= e=20 that core would suggest someone NOT implement a good framework for doing fu= ll=20 binary upgrades via the network. Unless you mean "core@ said they would not support packaging the base" whic= h=20 is different. > For binary upgrades without booting from CD-ROM to be possible, we need > versioning of some sort at the OS level. Core OS packages are the most This is not true - I don't see it as being mandatory to be able to apply=20 binary updates. (Case in point - freebsd-update works fine without it) > popular suggestion, but not the only path. Every year this topic comes up > and gets struck down again. Yes, because a) it isn't necessary, b) it may not solve the problem, c) the= re=20 are no patches to evaluate. I think the people suggesting it see it as a panacea to fix their problems = but=20 haven't fully evaluated it. =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 --nextPart162186818.BU15SNjyMy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDq02E5ZPcIHs/zowRAn5GAJ97pxuA0nXeDa5va0P84gbIcOf/hQCdEdG6 s5bEFdO5ykUVmWsYsPRT0yo= =DCOf -----END PGP SIGNATURE----- --nextPart162186818.BU15SNjyMy-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 03:08:16 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB9D816A41F; Fri, 23 Dec 2005 03:08:16 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from mail.localelinks.com (web.localelinks.com [64.39.75.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id D709F43D5C; Fri, 23 Dec 2005 03:08:15 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-222-80-189.jan.bellsouth.net [68.222.80.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.localelinks.com (Postfix) with ESMTP id 637B5DE; Thu, 22 Dec 2005 21:08:14 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id 473AF61C21; Thu, 22 Dec 2005 21:08:13 -0600 (CST) Date: Thu, 22 Dec 2005 21:08:13 -0600 From: "Matthew D. Fuller" To: Jo Rhett Message-ID: <20051223030813.GD63497@over-yonder.net> References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> <20051218023725.GM63497@over-yonder.net> <20051222210904.GH39174@svcolo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051222210904.GH39174@svcolo.com> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.2 Cc: stable@FreeBSD.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 03:08:16 -0000 On Thu, Dec 22, 2005 at 01:09:04PM -0800 I heard the voice of Jo Rhett, and lo! it spake thus: > > No, you're missing the point. More core OS upgrades means less > incremental patches (which are easier to apply than a full update). Right. I don't understand how B follows A here. These patches come from where? Security advisories, mailing list discussions, and eating too much beef right before bed and waking up at 2am with brilliant ideas? Why would there be less of them, just because RELENG_X_Y_RELEASE tags are laid down more often? > Huh? That's backwards. If we can't schedule the downtime for a > full operating system upgrade (which takes far longer than it > should) then the system won't get upgraded. Having done full OS upgrades a number of times, I can't remember the last time it took more than 5 or 10 minutes (during most of which the system can keep running its normal services, just a little more crunched on CPU or I/O). Well, OK, I can; it was when I moved servers from 2.2.x to 4.x. But that's a rather exceptional case, and next time THAT happens, I'm darn well using it as an excuse to strongarm new hardware out of somebody and replace the server at the same time... > Not to be rude, but I think your definition of analogy is wrong. No, you're right. "Hyperbole" was probably a better word, but even that doesn't quite fit. My ability to find the right word is flaky at times. I don't understand the basis of your assertion that more common tagging means suddenly you can't apply individual patches. > Back to the point, the comments aren't "bad". Your idea that binary > operating system upgrades from ISO are "easier" demonstrates that > you're talking about home computers, not production servers. Oh, no. Heck, I find that upgrades from SOURCE are "easier". In fact, just last month I bought my first CD burner, so it wasn't until a few weeks ago that I even burned my first ISO (and that, just to test the burner and figure out how to do it), and I've never booted or installed off one. For small groups of servers, I NFS mount installworlds, and for larger groups, I rdist out binaries. But it always comes from source. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 04:38:26 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D6B316A41F; Fri, 23 Dec 2005 04:38:26 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail20.syd.optusnet.com.au (mail20.syd.optusnet.com.au [211.29.132.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id C34F943D5E; Fri, 23 Dec 2005 04:38:24 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail20.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id jBN4cLB6029540 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 23 Dec 2005 15:38:22 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id jBN4cLHh023618; Fri, 23 Dec 2005 15:38:21 +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 jBN4cKOe023617; Fri, 23 Dec 2005 15:38:20 +1100 (EST) (envelope-from pjeremy) Date: Fri, 23 Dec 2005 15:38:20 +1100 From: Peter Jeremy To: Jo Rhett Message-ID: <20051223043820.GG77268@cirb503493.alcatel.com.au> References: <43A266E5.3080103@samsco.org> <20051217215434.GB92180@svcolo.com> <20051217220807.GA28741@freebie.xs4all.nl> <20051222211019.GI39174@svcolo.com> <20051222213041.GA5746@odin.ac.hmc.edu> <20051222220532.GL39174@svcolo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051222220532.GL39174@svcolo.com> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc Cc: stable@freebsd.org, current Subject: Re: HEADS UP: Release schedule for 2006 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 04:38:26 -0000 On Thu, 2005-Dec-22 13:10:19 -0800, Jo Rhett wrote: >I and many others have offered to work on this. The core team has >repeatedly stated that they won't integrate the efforts, which makes >os-upgrade capability minimal and easily broken. (see current efforts) On Thu, 2005-Dec-22 14:05:32 -0800, Jo Rhett wrote: >On Thu, Dec 22, 2005 at 01:30:41PM -0800, Brooks Davis wrote: >> This statement makes no sense. The core team wouldn't have much to >> do with this other than possibly being involved in making any service >> official. Also, approval is never given to include a non-existent >> feature. Easy, binary updates sound like a great idea, but without >> seeing actual code thats all anyone can say other than offering advice. >> If volunteering is conditional on acceptance of the work, that's a >> chicken-egg problem and is not resolvable. We simply can't maintain >> quality if we accept non-existent code just because the idea sounds >> good. > >What are you talking about? These issues have been repeatedly brought up >in the mailing lists, and what it would require to make it possible to >handle appropriately (namely, core os packages or a similar versioning >mechanism) and the arguements have often been given. I agree with Brooks. I don't recall ever seeing a message from -core (or anyone else talking on behalf of the Project) stating that code to make binary updates possible would not be integrated. For that matter, I don't recall ever seeing code offered to implement such a feature. Core OS packages have been discussed but I don't recall the idea ever being vetoed. Some work have been done in breaking bits of the base OS out into packages (perl, games and UUCP come to mind) but packaging the entire system is a major undertaking. In any case, I don't see how packaging the system would help you. Taking Solaris as an example of an OS which is broken up into lots of packages, patches don't replace whole packages, they replace individual files. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 04:56:52 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 823A416A41F; Fri, 23 Dec 2005 04:56:52 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA52943D49; Fri, 23 Dec 2005 04:56:51 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail05.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id jBN4unwV017955 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 23 Dec 2005 15:56:49 +1100 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id jBN4umHh023651; Fri, 23 Dec 2005 15:56:48 +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 jBN4um3q023650; Fri, 23 Dec 2005 15:56:48 +1100 (EST) (envelope-from pjeremy) Date: Fri, 23 Dec 2005 15:56:48 +1100 From: Peter Jeremy To: Jo Rhett Message-ID: <20051223045648.GH77268@cirb503493.alcatel.com.au> References: <43A266E5.3080103@samsco.org> <20051217215434.GB92180@svcolo.com> <20051217220807.GA28741@freebie.xs4all.nl> <43A492B6.6050305@t-hosting.hu> <20051217232856.GT77268@cirb503493.alcatel.com.au> <43A4B91D.8040304@samsco.org> <20051222211730.GK39174@svcolo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051222211730.GK39174@svcolo.com> User-Agent: Mutt/1.4.2.1i X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc Cc: stable@freebsd.org, current Subject: Re: FreeBSD Update is the binary update solution [Re: HEADS UP: Release schedule for 2006] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 04:56:52 -0000 On Thu, 2005-Dec-22 13:17:30 -0800, Jo Rhett wrote: >But FreeBSD Update suffers from all of the same limitations that I've been >describing because of lack of integration with the Core OS. > >1. modified kernels are foobar > ..yet are practically mandatory on production systems > >2. modified sources are foobar > ..yet many common production situations require source compilation options So you want to be able to make arbitrary changes you your source code and compilation options and then expect the FreeBSD project to provide a tool that will apply binary fixes to the resultant executables? I don't know that modified kernels are mandatory. A lot of work has been going on to reduce the need to re-compile the kernel for common situations. Likewise, I don't know that "many common" and "require" go together - IMHO, 'desire' or 'would be nice' are more appropriate descriptions. Would you care to provide some details of what you believe can be done to reduce your need to re-compile the OS. I'm not sure that FreeBSD Update is totally unusable for you. If you have the situation where you have a modified FreeBSD that you need to roll out to a large number of hosts, you just need to have your own FreeBSD Update server - you test the changes in your environment and then roll them out as you require. AFAIK, Colin hasn't fully productised FreeBSD Update to date but has not rejected the idea of doing so. >3. FreeBSD Update can't handle updates of jails and other situations that >package systems deal with just fine. I don't run jails so I'm not familiar with the problems here. Maybe you'd like to explain the problems you run into. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 07:42:09 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 808A516A41F; Fri, 23 Dec 2005 07:42:09 +0000 (GMT) (envelope-from huang@gddsn.org.cn) Received: from gddsn.org.cn (gddsn.org.cn [218.19.164.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7905243D60; Fri, 23 Dec 2005 07:42:08 +0000 (GMT) (envelope-from huang@gddsn.org.cn) Received: from [192.168.4.81] (unknown [210.72.96.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gddsn.org.cn (Postfix) with ESMTP id 0FAD838CB41; Fri, 23 Dec 2005 15:42:02 +0800 (CST) Message-ID: <43ABAA43.2050306@gddsn.org.cn> Date: Fri, 23 Dec 2005 15:41:55 +0800 From: Huang wen hui User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051212) X-Accept-Language: zh-cn,zh MIME-Version: 1.0 References: <43A8BD3F.2010006@gddsn.org.cn> <20051220232754.48631fb4@kan.dnsalias.net> <20051221192118.GA88506@aoi.wolfpond.org> <43A9AE07.3070501@centtech.com> <20051222175152.292f510b@kan.dnsalias.net> In-Reply-To: <20051222175152.292f510b@kan.dnsalias.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org, openoffice@freebsd.org Subject: Re: [openoffice]no suitable windowing system found, exiting. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 07:42:09 -0000 Alexander Kabaev wrote: >The commit below fixes OpenOffice 1.1.5 for me. > >kan 2005-12-22 16:42:38 UTC > > FreeBSD src repository > > Modified files: > libexec/rtld-elf rtld.c > Log: > Initialize object dagmembers list before checking version >dependencies. > Revision Changes Path > 1.110 +2 -4 src/libexec/rtld-elf/rtld.c > >http://cvsweb.FreeBSD.org/src/libexec/rtld-elf/rtld.c.diff?r1=1.109&r2=1.110 > > > > also fixed OpenOffice 2.0 for me, thank you! --hwh From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 08:57:07 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B91FE16A41F; Fri, 23 Dec 2005 08:57:07 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from mail.localelinks.com (web.localelinks.com [64.39.75.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 17A3D43D45; Fri, 23 Dec 2005 08:57:01 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-222-80-189.jan.bellsouth.net [68.222.80.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.localelinks.com (Postfix) with ESMTP id B4E71DE; Fri, 23 Dec 2005 02:56:58 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id D545561C21; Fri, 23 Dec 2005 02:56:57 -0600 (CST) Date: Fri, 23 Dec 2005 02:56:57 -0600 From: "Matthew D. Fuller" To: "Patrick M. Hausen" Message-ID: <20051223085657.GF63497@over-yonder.net> References: <200512231136.12471.doconnor@gsoft.com.au> <200512230851.jBN8pFVv060458@hugo10.ka.punkt.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200512230851.jBN8pFVv060458@hugo10.ka.punkt.de> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.2 Cc: freebsd-stable@freebsd.org, current , Jo Rhett Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 08:57:07 -0000 On Fri, Dec 23, 2005 at 09:51:15AM +0100 I heard the voice of Patrick M. Hausen, and lo! it spake thus: > > Any suggestions for an alternative to NFS if your 'client' servers > are located "all over the world" and you want to installworld across > the Internet? I was planning to use NFS/TCP secured by IPSec > transport mode, but anything less complicated would be greatly > appreciated ;-) This is one of the situations where r{dist,sync}'ing out the binaries makes more sense than NFS mounting and running installworld (which would be awful awful slow, above and beyond security and convenience issues). -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 09:14:16 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A749216A41F for ; Fri, 23 Dec 2005 09:14:16 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF74243D5F for ; Fri, 23 Dec 2005 09:14:15 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: by lh.synack.net (Postfix, from userid 100) id 4C8E85E48ED; Fri, 23 Dec 2005 01:14:15 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 0FF735E48A2 for ; Fri, 23 Dec 2005 01:14:11 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-current@freebsd.org From: Jason Evans Date: Fri, 23 Dec 2005 01:14:08 -0800 X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Subject: New malloc ready, take 42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 09:14:16 -0000 On 28 November, I announced a new malloc implementation that I've been working on as a replacement for the current libc malloc. The main goal for this rewrite of malloc is to provide better scalability for multi-threaded programs on SMP systems, without degrading performance in general. The benchmarks I've run indicate that the code now meets this goal. === === Resolved issues === === Several people provided valuable feedback regarding architecture, (in) correct function, and performance. At this point, I think I have addressed all outstanding issues. Here's a recap: * Hiten Pandya and others requested that I used the sys/tree.h implementation of red-black trees rather than my own. This is done. * Jon Dama objected to leaving sbrk() support out of the malloc implementation for 32-bit architectures. I've added support for sbrk () on i386 and arm. * David Xu pointed out that the hand-rolled spinlocks did not do priority inheritance, which could lead to priority inversion deadlocks. This has been fixed by using the libc spinlocks. * Kris Kennaway discovered that sparc64 doesn't have TLS, and Olivier Houchard contacted me about the same issue for arm. I removed the use of TLS on those architectures. * Claus Guttesen and Devon O'Dell reported issues in kldxref and X on amd64. The kldxref problem has been fixed. The X problem is a bit trickier. I borrowed a Turion-based laptop from Rob Braun and indeed found that X wouldn't start. Eric Anholt suggested trying the xorg- server-snap port rather than xorg-server, and the problem went away. Eric explained that xorg-server uses custom ELF *.a module loading (the idea being that the same exact module could be used on different operating systems), whereas xorg-server-snap uses dlopen(3) and friends. Apparently, we are on the cusp of the transition to using the latter, so for now the workaround on amd64 is to use xorg-server- snap, with the expectation that soon the standard xorg-server port will be upgraded. === === Benchmarking ad nauseam === === ==> Lever & Boreham benchmarks (multi-threaded) Chuck Lever and David Boreham published "malloc() Performance in a Multithreaded Linux Environment" in the proceedings of the FREENIX track of the 2000 USENIX Annual Technical Conference. By some incredible stroke of luck, I found the source code for their benchmarks, and Kris Kennaway ran the first of them on a 14-CPU sparc64 system as well as a dual-dual opteron system. (The other two benchmarks aren't very enlightening.) It's important to keep in mind that this is a micro-benchmark that demonstrates a worst case scenario for non-SMP-scalable malloc implementations. That said, with 5 threads, jemalloc outperformed phkmalloc by 15X on sparc64 and 80X on amd64. ==> super-smack (multi-threaded) The SMP scalability tests were very encouraging, but Kris also ran some super-smack benchmarks on a dual-dual opteron system, and jemalloc was actually a bit slower than phkmalloc in that case (~2.7-3.7% slower, depending on jemalloc configuration). I've been obsessing over that for over a week now, and one of the results is that jemalloc is now more tunable -- delayed coalescence cache size, number of allocation arenas, and allocation quantum size are all tunable via MALLOC_OPTIONS now. However, changing the tuning parameters wasn't enough to make up the performance difference for the super-smack benchmarks. So, I spent some time looking at memory fragmentation. Taking a cue from Poul- Henning Kamp's malloc work, I finally wrote a program that converts ktrace output to memory usage graphs. Here's a series of of graphs from various stages of the fragmentation avoidance changes I made. The test program was 'kldxref /boot/kernel' on amd64. http://people.freebsd.org/~jasone/jemalloc/plots/kldxref.png http://people.freebsd.org/~jasone/jemalloc/plots/kldxref13.gif http://people.freebsd.org/~jasone/jemalloc/plots/kldxref15.gif The interesting thing to note is that in the first two plots, the highly fragmented portion of the graph continuously grows, wheareas in the last plot, the fragmented portion stops growing about 1/3 of the way through the program run. (The first plot only shows the bottom half of what the other two plots show.) This is all really cool, but alas, it didn't help the super-smack results. I was able to use the graphing program to determine that cache line sharing was potentially causing even more issues than suspected, but we already knew that cache line sharing was an issue as a result of some of the runs that Kris did. Finally, last night I discovered that overzealous use of __inline is likely to have been the culprit. I removed the __inline keyword from all of the functions that aren't part of the critical path for small memory allocation/deallocation, and measured a substantial performance improvement. I don't have access to the machine that Kris ran the super-smack benchmarks on, so I set up a couple of VMware guest systems using VMware 5.5 on a 3.2 GHz P4 system (HTT enabled for the host, but not the guests). The two guests were configured very similarly, so that the only pertinent difference was that one was using phkmalloc, and the other was using jemalloc. Before the __inline changes, jemalloc was ~2.5% slower than phkmalloc. Here are the final results, which show jemalloc to be ~4.1% faster than phkmalloc for the benchmark: x ss_phk + ss_je +----------------------------------------------------------------------- ---+ |xxx x x x x x x + x + ++ ++ + + + +| | |_____________A__M__________| | ___________A___M______| | +----------------------------------------------------------------------- ---+ N Min Max Median Avg Stddev x 10 1594.94 1658.64 1623.73 1619.431 21.833342 + 10 1649.06 1706.75 1693.23 1686.275 17.410025 Difference at 95.0% confidence 66.844 +/- 18.5532 4.12762% +/- 1.14566% (Student's t, pooled s = 19.7459) The numbers reported are queries/second, so bigger is better. I used mysql 5.0.16, super-smack 1.3, libthr, and MALLOC_OPTIONS='aj', with 10 replicates of the following command for each VMware guest: super-smack -d mysql select-key.smack 4 10000 It's worth noting that, as near as I can tell, almost all memory allocation happens in a single mysqld thread. Presumably, a master thread is handing buffers to slaves, which process the buffers, then free them. As such, this test doesn't benefit from jemalloc's multiple arenas, so it is not a very good test of SMP scalability, at least with regard to malloc. ==> cfrac (single-threaded) cfrac is one of many benchmark programs that is included in the Hoard memory allocator source distribution (see http://www.cs.umass.edu/ ~emery/hoard/). I ran cfrac as follows: cfrac 47582602774358115722167492755475367767 (Same VMware setup as for super-smack benchmarks.) Wall time (seconds) phkmalloc 'aj': 18.75, 18.68, 18.69 jemalloc 'aj': 17.57, 17.65, 17.56 I haven't looked at allocation traces of cfrac in quite a while, but IIRC, it does a lot of small allocations of various sizes. ==> sh6bench (single-threaded) sh6bench (see http://www.microquill.com/smartheap/shbench/bench.zip) is a quirky malloc benchmark that has been used in some of the published malloc literature, so I include it here. sh6bench does cycles of allocating groups of objects, where the size of objects in each group is random. Sometimes the objects are held for a while before being freed. I ran sh6bench with the following interactive runtime parameters: call count: 50000 min block size: 1 max block size: 1000 phkmalloc doesn't fare very well with its default settings since the benchmark's memory usage fluctuates enough to cause phkmalloc to repeatedly allocate and free pages. Therefore I report numbers for multiple MALLOC_OPTIONS settings. Since the program prompts for interactive input, I report the sum of user and sys time, rather than wall time. (Same VMware setup as for super-smack benchmarks.) user+sys time (seconds) phkmalloc 'aj': 25.66, 25.78, 22.50 phkmalloc 'aj>>>>': 13.72, 13.77, 13.69 jemalloc 'aj': 17.88, 17.05, 17.10 If phkmalloc's cache size is increased adequately, it beats jemalloc. jemalloc simply has to do more work when splitting and coalescing regions than phkmalloc does, and this benchmark severely stresses that aspect of jemalloc. It's perhaps worth noting that jemalloc's peak memory usage is ~22% lower than phkmalloc's, which means that it's doing a better job of avoiding fragmentation. At least the extra algorithmic overhead gains us something. ==> gs (single-threaded) Ghostscript is the well known PostScript interpreter. I took the biggest PDF I have (the PostScript Lanuguage Reference, 3rd Ed.) and converted it to PostScript, then ran AFPL Ghostscript 8.53 as follows: gs -dBATCH -dNODISPLAY PS3.ps As with sh6bench, memory usage fluctuated enough to cause excessive allocation/deallocation of pages with phkmalloc, so I report times for multiple MALLOC_OPTIONS settings. (Same VMware setup as for super-smack benchmarks.) Wall time (seconds) phkmalloc 'aj': 92.12, 92.03, 92.90 phkmalloc 'aj>>>>': 61.11, 61.29, 61.73 jemalloc 'aj': 62.34, 62.43, 62.20 jemalloc 'ajQQQc': 60.85, 60.48, 60.81 Okay, the 'ajQQQc' parameterization for jemalloc is a bit silly, but if phkmalloc gets help, then so should jemalloc. =) === === Proposed approach for inclusion in CURRENT === === Here's a current version of all the changes that are necessary for jemalloc to go in to the tree: http://people.freebsd.org/~jasone/jemalloc/patches/ jemalloc_20051222c.diff This patch includes (roughly): 1) Fix gensnmptree bug (missing variable initialization). I emailed the maintainer, Hartmut Brandt, about this today, and am awaiting a reply. 2) Fix kldxref bug (assumes allocation is adequately aligned). This needs to be committed along with (5), since the fix uses posix_memalign(). 3) Move calloc() from calloc.c to malloc.c (enables better statistics gathering). 4) Add _malloc_{pre,post}fork(), for use by threading libraries. 5) Replace malloc(), calloc(), realloc(), and free(). Add posix_memalign(). I'd like to commit (3) and (4) first, so that we have a version of phkmalloc in the cvs repository that is API-compatible with libc as it will be after jemalloc is committed. This will make it easier to swap the phkmalloc code in, should we wish to do further benchmarking or regression testing at some point in the future. Poul-Henning has agreed with this in principle, though I haven't yet supplied him with diffs for only (3) and (4). So, how about it? Is jemalloc ready to go in now? Thanks, Jason From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 09:27:43 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3D3A16A422 for ; Fri, 23 Dec 2005 09:27:43 +0000 (GMT) (envelope-from devon.odell@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D5A443D58 for ; Fri, 23 Dec 2005 09:27:42 +0000 (GMT) (envelope-from devon.odell@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so412528wxc for ; Fri, 23 Dec 2005 01:27:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=elboDQMeHWXX/Eubdgv/oo8TPNsus7eVHSI///QE+Hu9UOHHuz/hP7K5gnqCc3+q4M5KZyxqgj4rjpeTZ+V5g1Fh1jzz2RoDZ6rtHjKlYRnejMM6K0pAWp/BZCPaHd73nq+6USkRBw2XshK8SYG0XKLasSKn9Bx766m/wU/kVIs= Received: by 10.70.99.13 with SMTP id w13mr2812061wxb; Fri, 23 Dec 2005 01:27:41 -0800 (PST) Received: by 10.70.65.4 with HTTP; Fri, 23 Dec 2005 01:27:41 -0800 (PST) Message-ID: <9ab217670512230127p3acb85e7q@mail.gmail.com> Date: Fri, 23 Dec 2005 01:27:41 -0800 From: "Devon H. O'Dell" To: Jason Evans In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: Cc: freebsd-current@freebsd.org Subject: Re: New malloc ready, take 42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 09:27:43 -0000 > * Claus Guttesen and Devon O'Dell reported issues in kldxref and X on Hey, that's me. :) > So, how about it? Is jemalloc ready to go in now? I wasn't going to say yes if the X thing wasn't fixed for AMD64, just because I run -CURRENT on it on my primary workstation, but I can be happy with xorg-server-snap if that works. Especially considering that we will be upgrading soon. > Thanks, > Jason Great work. The benchmarks are impressive. --Devon From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 09:31:21 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A854816A41F; Fri, 23 Dec 2005 09:31:21 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BAB843D46; Fri, 23 Dec 2005 09:31:17 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jBN9VEtD073761; Fri, 23 Dec 2005 02:31:15 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43ABC3E2.1030108@samsco.org> Date: Fri, 23 Dec 2005 02:31:14 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Evans References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: New malloc ready, take 42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 09:31:21 -0000 Jason Evans wrote: > On 28 November, I announced a new malloc implementation that I've been > working on as a replacement for the current libc malloc. The main goal > for this rewrite of malloc is to provide better scalability for > multi-threaded programs on SMP systems, without degrading performance > in general. The benchmarks I've run indicate that the code now meets > this goal. > > === > === Resolved issues === > === > > Several people provided valuable feedback regarding architecture, (in) > correct function, and performance. At this point, I think I have > addressed all outstanding issues. Here's a recap: > > * Hiten Pandya and others requested that I used the sys/tree.h > implementation of red-black trees rather than my own. This is done. > > * Jon Dama objected to leaving sbrk() support out of the malloc > implementation for 32-bit architectures. I've added support for sbrk () > on i386 and arm. > > * David Xu pointed out that the hand-rolled spinlocks did not do > priority inheritance, which could lead to priority inversion > deadlocks. This has been fixed by using the libc spinlocks. > > * Kris Kennaway discovered that sparc64 doesn't have TLS, and Olivier > Houchard contacted me about the same issue for arm. I removed the use > of TLS on those architectures. > > * Claus Guttesen and Devon O'Dell reported issues in kldxref and X on > amd64. The kldxref problem has been fixed. The X problem is a bit > trickier. I borrowed a Turion-based laptop from Rob Braun and indeed > found that X wouldn't start. Eric Anholt suggested trying the xorg- > server-snap port rather than xorg-server, and the problem went away. > Eric explained that xorg-server uses custom ELF *.a module loading (the > idea being that the same exact module could be used on different > operating systems), whereas xorg-server-snap uses dlopen(3) and > friends. Apparently, we are on the cusp of the transition to using the > latter, so for now the workaround on amd64 is to use xorg-server- snap, > with the expectation that soon the standard xorg-server port will be > upgraded. > > === > === Benchmarking ad nauseam === > === > > ==> Lever & Boreham benchmarks (multi-threaded) > > Chuck Lever and David Boreham published "malloc() Performance in a > Multithreaded Linux Environment" in the proceedings of the FREENIX > track of the 2000 USENIX Annual Technical Conference. By some > incredible stroke of luck, I found the source code for their > benchmarks, and Kris Kennaway ran the first of them on a 14-CPU sparc64 > system as well as a dual-dual opteron system. (The other two > benchmarks aren't very enlightening.) It's important to keep in mind > that this is a micro-benchmark that demonstrates a worst case scenario > for non-SMP-scalable malloc implementations. That said, with 5 > threads, jemalloc outperformed phkmalloc by 15X on sparc64 and 80X on > amd64. > > ==> super-smack (multi-threaded) > > The SMP scalability tests were very encouraging, but Kris also ran some > super-smack benchmarks on a dual-dual opteron system, and jemalloc was > actually a bit slower than phkmalloc in that case (~2.7-3.7% slower, > depending on jemalloc configuration). I've been obsessing over that > for over a week now, and one of the results is that jemalloc is now > more tunable -- delayed coalescence cache size, number of allocation > arenas, and allocation quantum size are all tunable via MALLOC_OPTIONS > now. > > However, changing the tuning parameters wasn't enough to make up the > performance difference for the super-smack benchmarks. So, I spent > some time looking at memory fragmentation. Taking a cue from Poul- > Henning Kamp's malloc work, I finally wrote a program that converts > ktrace output to memory usage graphs. Here's a series of of graphs > from various stages of the fragmentation avoidance changes I made. The > test program was 'kldxref /boot/kernel' on amd64. > > http://people.freebsd.org/~jasone/jemalloc/plots/kldxref.png > http://people.freebsd.org/~jasone/jemalloc/plots/kldxref13.gif > http://people.freebsd.org/~jasone/jemalloc/plots/kldxref15.gif > > The interesting thing to note is that in the first two plots, the > highly fragmented portion of the graph continuously grows, wheareas in > the last plot, the fragmented portion stops growing about 1/3 of the > way through the program run. (The first plot only shows the bottom > half of what the other two plots show.) This is all really cool, but > alas, it didn't help the super-smack results. I was able to use the > graphing program to determine that cache line sharing was potentially > causing even more issues than suspected, but we already knew that cache > line sharing was an issue as a result of some of the runs that Kris did. > > Finally, last night I discovered that overzealous use of __inline is > likely to have been the culprit. I removed the __inline keyword from > all of the functions that aren't part of the critical path for small > memory allocation/deallocation, and measured a substantial performance > improvement. > > I don't have access to the machine that Kris ran the super-smack > benchmarks on, so I set up a couple of VMware guest systems using > VMware 5.5 on a 3.2 GHz P4 system (HTT enabled for the host, but not > the guests). The two guests were configured very similarly, so that > the only pertinent difference was that one was using phkmalloc, and the > other was using jemalloc. Before the __inline changes, jemalloc was > ~2.5% slower than phkmalloc. Here are the final results, which show > jemalloc to be ~4.1% faster than phkmalloc for the benchmark: > > x ss_phk > + ss_je > +----------------------------------------------------------------------- > ---+ > |xxx x x x x x x + x + ++ ++ + + > + +| > | |_____________A__M__________| | > ___________A___M______| | > +----------------------------------------------------------------------- > ---+ > N Min Max Median Avg > Stddev > x 10 1594.94 1658.64 1623.73 1619.431 > 21.833342 > + 10 1649.06 1706.75 1693.23 1686.275 > 17.410025 > Difference at 95.0% confidence > 66.844 +/- 18.5532 > 4.12762% +/- 1.14566% > (Student's t, pooled s = 19.7459) > > The numbers reported are queries/second, so bigger is better. > > I used mysql 5.0.16, super-smack 1.3, libthr, and MALLOC_OPTIONS='aj', > with 10 replicates of the following command for each VMware guest: > > super-smack -d mysql select-key.smack 4 10000 > > It's worth noting that, as near as I can tell, almost all memory > allocation happens in a single mysqld thread. Presumably, a master > thread is handing buffers to slaves, which process the buffers, then > free them. As such, this test doesn't benefit from jemalloc's multiple > arenas, so it is not a very good test of SMP scalability, at least with > regard to malloc. > > ==> cfrac (single-threaded) > > cfrac is one of many benchmark programs that is included in the Hoard > memory allocator source distribution (see http://www.cs.umass.edu/ > ~emery/hoard/). I ran cfrac as follows: > > cfrac 47582602774358115722167492755475367767 > > (Same VMware setup as for super-smack benchmarks.) > > Wall time (seconds) > phkmalloc 'aj': 18.75, 18.68, 18.69 > jemalloc 'aj': 17.57, 17.65, 17.56 > > I haven't looked at allocation traces of cfrac in quite a while, but > IIRC, it does a lot of small allocations of various sizes. > > ==> sh6bench (single-threaded) > > sh6bench (see http://www.microquill.com/smartheap/shbench/bench.zip) is > a quirky malloc benchmark that has been used in some of the published > malloc literature, so I include it here. sh6bench does cycles of > allocating groups of objects, where the size of objects in each group > is random. Sometimes the objects are held for a while before being > freed. I ran sh6bench with the following interactive runtime parameters: > > call count: 50000 > min block size: 1 > max block size: 1000 > > phkmalloc doesn't fare very well with its default settings since the > benchmark's memory usage fluctuates enough to cause phkmalloc to > repeatedly allocate and free pages. Therefore I report numbers for > multiple MALLOC_OPTIONS settings. Since the program prompts for > interactive input, I report the sum of user and sys time, rather than > wall time. (Same VMware setup as for super-smack benchmarks.) > > user+sys time (seconds) > phkmalloc 'aj': 25.66, 25.78, 22.50 > phkmalloc 'aj>>>>': 13.72, 13.77, 13.69 > jemalloc 'aj': 17.88, 17.05, 17.10 > > If phkmalloc's cache size is increased adequately, it beats jemalloc. > jemalloc simply has to do more work when splitting and coalescing > regions than phkmalloc does, and this benchmark severely stresses that > aspect of jemalloc. It's perhaps worth noting that jemalloc's peak > memory usage is ~22% lower than phkmalloc's, which means that it's > doing a better job of avoiding fragmentation. At least the extra > algorithmic overhead gains us something. > > ==> gs (single-threaded) > > Ghostscript is the well known PostScript interpreter. I took the > biggest PDF I have (the PostScript Lanuguage Reference, 3rd Ed.) and > converted it to PostScript, then ran AFPL Ghostscript 8.53 as follows: > > gs -dBATCH -dNODISPLAY PS3.ps > > As with sh6bench, memory usage fluctuated enough to cause excessive > allocation/deallocation of pages with phkmalloc, so I report times for > multiple MALLOC_OPTIONS settings. (Same VMware setup as for > super-smack benchmarks.) > > Wall time (seconds) > phkmalloc 'aj': 92.12, 92.03, 92.90 > phkmalloc 'aj>>>>': 61.11, 61.29, 61.73 > jemalloc 'aj': 62.34, 62.43, 62.20 > jemalloc 'ajQQQc': 60.85, 60.48, 60.81 > > Okay, the 'ajQQQc' parameterization for jemalloc is a bit silly, but if > phkmalloc gets help, then so should jemalloc. =) > > === > === Proposed approach for inclusion in CURRENT === > === > > Here's a current version of all the changes that are necessary for > jemalloc to go in to the tree: > > http://people.freebsd.org/~jasone/jemalloc/patches/ > jemalloc_20051222c.diff > > This patch includes (roughly): > > 1) Fix gensnmptree bug (missing variable initialization). I emailed > the maintainer, Hartmut Brandt, about this today, and am awaiting a reply. > > 2) Fix kldxref bug (assumes allocation is adequately aligned). This > needs to be committed along with (5), since the fix uses posix_memalign(). > > 3) Move calloc() from calloc.c to malloc.c (enables better statistics > gathering). > > 4) Add _malloc_{pre,post}fork(), for use by threading libraries. > > 5) Replace malloc(), calloc(), realloc(), and free(). Add > posix_memalign(). > > I'd like to commit (3) and (4) first, so that we have a version of > phkmalloc in the cvs repository that is API-compatible with libc as it > will be after jemalloc is committed. This will make it easier to swap > the phkmalloc code in, should we wish to do further benchmarking or > regression testing at some point in the future. Poul-Henning has > agreed with this in principle, though I haven't yet supplied him with > diffs for only (3) and (4). > > So, how about it? Is jemalloc ready to go in now? > > Thanks, > Jason I think that this is overall a good plan. Two things need to be stressed, since they will quickly become FAQs. First is that phkmalloc and jemalloc won't be interchangable at runtime, like the threading libraries are. Second is that amd64 will be stuck without working X until the 6.9/7.0 stuff gets in the tree, and people should be well aware of this. Another thing that I worry about is complex library scenarios where you might have different versions of libc getting pulled into the same process by different library dependencies. This could turn into a big headache that is only solvable by telling people to wipe out their entire ports collection and rebuild from scratch. Does this warrant a library version bump now (as much as I really don't want to advocate this)? Scott From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 09:32:18 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3ECB016A41F for ; Fri, 23 Dec 2005 09:32:18 +0000 (GMT) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BF5743D80 for ; Fri, 23 Dec 2005 09:32:15 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 12640 invoked from network); 23 Dec 2005 09:38:26 -0000 Received: from c00l3r.networx.ch (HELO freebsd.org) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 23 Dec 2005 09:38:26 -0000 Message-ID: <43ABC41F.15C083AE@freebsd.org> Date: Fri, 23 Dec 2005 10:32:15 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.8 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: ShouYan Mao References: <6834BE1811D97C4B8581CE6BD14506800545C5@lepton.jnpr.net> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Network performance measurements of -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2005 09:32:18 -0000 ShouYan Mao wrote: > > So, would you try it with PCI-E Gigabit card? I would if I had a PCI-E system and suitable PCI-E Gigabit cards. Feel free to send me a test system. -- Andre > Best Regards. > Shouyan > > ------------------------------------------------------- > I'm not the best, but I try to do better. > ------------------------------------------------------- > > -----Original Message----- > From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Andre Oppermann > Sent: 2005Äę12ÔÂ23ČŐ 2:17 > To: freebsd-current@freebsd.org > Cc: freebsd-net@freebsd.org > Subject: Network performance measurements of -current > > As part my funded TCP/IP optimization work I'm doing lots of measurements > and profiling with an Agilent N2X network tester and calibrated traffic > generator. > > The following data shall serve as baseline of the current performance we > get out of FreeBSD 7-current. More to come tomorrow though. > > OS: FreeBSD 7-current as of 20051222-1600 UTC > KERNEL: Generic kernel, minus WITNESS and INVARIANTS, plus HWPMC, HZ=1000 > HARDWARE: Dual Opteron 852 2.6Ghz, Tyan S2882 Mobo with AMD-8131 PCI-X tunnel > HARDWARE: dual Broadcom Gigabit BMC5704C PCI-X-133 ("bge") > HARDWARE: dual Intel Gigabit 82546EB PCI-X-133 ("em") > > Uniprocessor kernel > > bge: > normal forwarding bge0->bge1: @64/326kpps/166us/402kpps(30%Loss)/194us > normal forwarding bge0->bge1: @1500/81kpps/520us > normal forwarding bge0->disc0: @64/1205kpps > IP fastforwarding bge0->bge1: @64/565kpps/192us/575kpps(60%Loss)/1090us > IP fastforwarding bge0->bge1: @1500/81kpps/730us > IP fastforwarding bge0->disc0: @64/1160kpps > net.isr.direct=1 bge0->bge1: @64/476kpps/211us/487kpps(68%Loss)/1284us > net.isr.direct=1 bge0->bge1: @1500/81kpps/760us > net.isr.direct=1 bge0->disc0: @64/1250kpps > polling (*) bge0->bge1: > @64/420kpps(9%Loss)/1385us/416kpps(72%Loss)/1600us > polling (*) bge0->bge1: @1500/71kpps(9%Loss)/850us > polling (*) bge0->disc0: @64/697kpps > > Comments: Under full load the normal processing breaks completely down > while with IP fastforwarding it levels off but continues to forward. > Strangely with polling it has 9% loss at all loads (even at 1% wirespeed). > May be related to HZ=1000. > > em: > normal forwarding em0->em1: @64/372kpps/112us/396kpps(11%Loss)/131us > normal forwarding em0->em1: @1500/81kpps/170us > normal forwarding em0->disc0: @64/1130kpps > IP fastforwarding em0->em1: @64/565kpps/45us/585kpps(4%Loss)/1600us > IP fastforwarding em0->em1: @1500/81kpps/135us > IP fastforwarding em0->disc0: @64/1116kpps > net.isr.direct=1 em0->em1: later > net.isr.direct=1 em0->disc0: later > polling (*) em0->em1: later > polling (*) em0->disc0: later > > (*) max_burst=1000, user_frac=0, each_burst=30 > > Sponsored by: TCP/IP Optimization Fundraise 2005 > > -- > Andre > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 09:42:16 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9D4A16A41F; Fri, 23 Dec 2005 09:42:16 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8795543D64; Fri, 23 Dec 2005 09:42:16 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 85F23BC66; Fri, 23 Dec 2005 09:42:14 +0000 (UTC) To: Jason Evans From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 23 Dec 2005 01:14:08 PST." Date: Fri, 23 Dec 2005 10:42:13 +0100 Message-ID: <26783.1135330933@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: New malloc ready, take 42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 09:42:17 -0000 In message , Jason Evans writes: >So, how about it? Is jemalloc ready to go in now? Sounds like it to me :-) Various fatherly advice: During the first part of the integration period performance is not important, correctness is. Enable all reasonable checks. If you have something like phkmallocs EXTRA_SANITY, turn it on. There will be whineage about performance and how FreeBSD is dying etc, just ignore it, those people havn't got a clue and you'll get to show them later when the checks are turned off. I also advice that you to keep both mallocs in the tree for a transition period and define an environment variable that causes fallback to phkmalloc. That way you don't risk stopping people dead in their tracks if some unforseen sideeffect shows up. Regarding unforseen sideeffects, the thing I would worry most about is alignment, where phkmalloc is very generous. And once again: Thankyou! 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 Fri Dec 23 10:02:58 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5969716A41F; Fri, 23 Dec 2005 10:02:58 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id C971C43D46; Fri, 23 Dec 2005 10:02:57 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id D21D1CE; Fri, 23 Dec 2005 05:03:18 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 5E78C2515; Fri, 23 Dec 2005 05:03:15 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EpjlD-0001bX-WB; Fri, 23 Dec 2005 10:02:52 +0000 Date: Fri, 23 Dec 2005 10:02:51 +0000 From: Brian Candler To: "Matthew D. Fuller" Message-ID: <20051223100251.GB6049@uk.tiscali.com> References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> <20051218023725.GM63497@over-yonder.net> <20051222210904.GH39174@svcolo.com> <20051223030813.GD63497@over-yonder.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051223030813.GD63497@over-yonder.net> User-Agent: Mutt/1.4.2.1i Cc: Jo Rhett , stable@FreeBSD.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 10:02:58 -0000 On Thu, Dec 22, 2005 at 09:08:13PM -0600, Matthew D. Fuller wrote: > > No, you're missing the point. More core OS upgrades means less > > incremental patches (which are easier to apply than a full update). > > Right. I don't understand how B follows A here. > > These patches come from where? Security advisories, mailing list > discussions, and eating too much beef right before bed and waking up > at 2am with brilliant ideas? Why would there be less of them, just > because RELENG_X_Y_RELEASE tags are laid down more often? I think the real concern here is: for how long after RELEASE_X_Y are binary patches for it made available? If the policy is "every RELEASE_X_Y has binary patches available for Z months after its release", then clearly it doesn't matter how many RELEASE_X_Y's are made in this period. If the policy is "binary patches are made available for the last N releases", then the availability lifetime of binary patches is (N * release interval). As long as N is made sufficiently large, then it's not a problem. There is a risk that reducing the interval between releases does not cause a corresponding increase in N, thus forcing people to perform full updates to a new release more often. > > Huh? That's backwards. If we can't schedule the downtime for a > > full operating system upgrade (which takes far longer than it > > should) then the system won't get upgraded. > > Having done full OS upgrades a number of times, I can't remember the > last time it took more than 5 or 10 minutes ... > For small groups of servers, I NFS mount > installworlds, and for larger groups, I rdist out binaries. But it > always comes from source. That's good for you and a certain clan of highly experienced FreeBSD system administrators. However I believe that there's a far larger pool of people for whom binary installs and upgrades makes much more sense. At one end of the spectrum are those bailing out from Linux, and the other end are people who want an audit trail for every binary back to a 3rd-party release medium. (I started off in the first group, but now fall into the second) Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 10:05:01 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1FF016A41F; Fri, 23 Dec 2005 10:05:00 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 57FFF43D45; Fri, 23 Dec 2005 10:05:00 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id jBNA4u2b056287; Fri, 23 Dec 2005 10:04:58 GMT (envelope-from davidxu@freebsd.org) Message-ID: <43ABCBCF.8060500@freebsd.org> Date: Fri, 23 Dec 2005 18:05:03 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20050928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Evans References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: New malloc ready, take 42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 10:05:01 -0000 Jason Evans wrote: > On 28 November, I announced a new malloc implementation that I've been > working on as a replacement for the current libc malloc. The main goal > for this rewrite of malloc is to provide better scalability for > multi-threaded programs on SMP systems, without degrading performance > in general. The benchmarks I've run indicate that the code now meets > this goal. > ... Great! > === > === Benchmarking ad nauseam === > === > ==> sh6bench (single-threaded) >... > phkmalloc doesn't fare very well with its default settings since the > benchmark's memory usage fluctuates enough to cause phkmalloc to > repeatedly allocate and free pages. Therefore I report numbers for > multiple MALLOC_OPTIONS settings. Since the program prompts for > interactive input, I report the sum of user and sys time, rather than > wall time. (Same VMware setup as for super-smack benchmarks.) > > user+sys time (seconds) > phkmalloc 'aj': 25.66, 25.78, 22.50 > phkmalloc 'aj>>>>': 13.72, 13.77, 13.69 > jemalloc 'aj': 17.88, 17.05, 17.10 > > If phkmalloc's cache size is increased adequately, it beats jemalloc. > jemalloc simply has to do more work when splitting and coalescing > regions than phkmalloc does, and this benchmark severely stresses that > aspect of jemalloc. It's perhaps worth noting that jemalloc's peak > memory usage is ~22% lower than phkmalloc's, which means that it's > doing a better job of avoiding fragmentation. At least the extra > algorithmic overhead gains us something. > If I have linked " aj>>>>>>>" to /etc/malloc.conf for phkmalloc, the super-smack get better result, on my Pentium-D 2.8Ghz machine, before this set, the select-key.smack can only reach 19500 q_per_s, after the set, it can reach 20791.33 q_per_s ! The '>' option should be supported in jemalloc because mysql relies on it. > So, how about it? Is jemalloc ready to go in now? > > Thanks, > Jason In general, it is fine to me, I don't have other use-cases to test, others may try apache web benchmark etcs? David Xu From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 10:12:11 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4D5716A41F; Fri, 23 Dec 2005 10:12:11 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66DC643D7E; Fri, 23 Dec 2005 10:12:10 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 4BCAEBC66; Fri, 23 Dec 2005 10:12:08 +0000 (UTC) To: David Xu From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 23 Dec 2005 18:05:03 +0800." <43ABCBCF.8060500@freebsd.org> Date: Fri, 23 Dec 2005 11:12:07 +0100 Message-ID: <26940.1135332727@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org, Jason Evans Subject: Re: New malloc ready, take 42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 10:12:12 -0000 In message <43ABCBCF.8060500@freebsd.org>, David Xu writes: >If I have linked " aj>>>>>>>" to /etc/malloc.conf for phkmalloc, the >super-smack get better result, on my Pentium-D 2.8Ghz machine, >before this set, the select-key.smack can only reach 19500 q_per_s, >after the set, it can reach 20791.33 q_per_s ! yes, this is not suprising. >The '>' option should be supported in jemalloc because mysql relies >on it. That is indeed a strange usage of the word "relies" and it sort of indicates that you don't even have the foggiest notion about what the '>' option does in phkmalloc. Maybe a reading of the relevant manual page might be in order ? 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 Fri Dec 23 10:14:57 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A5FE16A41F for ; Fri, 23 Dec 2005 10:14:57 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from mail.localelinks.com (web.localelinks.com [64.39.75.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B80443D49 for ; Fri, 23 Dec 2005 10:14:56 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from draco.over-yonder.net (adsl-222-80-189.jan.bellsouth.net [68.222.80.189]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.localelinks.com (Postfix) with ESMTP id 9EDE6DE; Fri, 23 Dec 2005 04:14:55 -0600 (CST) Received: by draco.over-yonder.net (Postfix, from userid 100) id DFF1161C21; Fri, 23 Dec 2005 04:14:54 -0600 (CST) Date: Fri, 23 Dec 2005 04:14:54 -0600 From: "Matthew D. Fuller" To: Brian Candler Message-ID: <20051223101454.GG63497@over-yonder.net> References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> <20051218023725.GM63497@over-yonder.net> <20051222210904.GH39174@svcolo.com> <20051223030813.GD63497@over-yonder.net> <20051223100251.GB6049@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051223100251.GB6049@uk.tiscali.com> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.11-fullermd.2 Cc: Jo Rhett , current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 10:14:57 -0000 [ -stable yanked from CC by a flip of a coin ] On Fri, Dec 23, 2005 at 10:02:51AM +0000 I heard the voice of Brian Candler, and lo! it spake thus: > > That's good for you and a certain clan of highly experienced FreeBSD > system administrators. However I believe that there's a far larger > pool of people for whom binary installs and upgrades makes much more > sense. Oh, yes. I've almost precisely zero interest in such things myself, but I'm quite aware that other people want them for both irrational and thoroughly sensible reasons. Me, I don't remember the last time ANY system I ran was on a -RELEASE longer than it took to install and pull up to the latest along whatever branch I thought appropriate for it, but that's me. With any luck, none of the people gasping in horror and calling for smelling salts at the thought will ever know what services they use end up coming from boxes I control 8-} I'm just in this fray for kicks, because I think the "BSD will implode if we start releasing more often without this" perspective is a little nutty. I don't see how it really makes anything materially worse than it currently is for that group of people (sure, it may be pretty bad now, but I don't really buy that releasing more often makes it all that much worse). -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 10:18:21 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E60C16A420 for ; Fri, 23 Dec 2005 10:18:21 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BE1443D53 for ; Fri, 23 Dec 2005 10:18:20 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 570D4BC66 for ; Fri, 23 Dec 2005 10:18:19 +0000 (UTC) To: current@freebsd.org From: Poul-Henning Kamp Date: Fri, 23 Dec 2005 11:18:18 +0100 Message-ID: <26957.1135333098@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Subject: diskless VFS lock issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2005 10:18:21 -0000 fxp0: link state changed to UP KDB: stack backtrace: kdb_backtrace(d448a9b4,c06c18b6,c088e359,c08a84c5,c45fca50) at 0xc067f70d = kdb_backtrace+0x29 vfs_badlock(c088e359,c08a84c5,c45fca50) at 0xc06c17bd = vfs_badlock+0x11 assert_vop_locked(c45fca50,c08a84c5,c45fca50,c08a84c5) at 0xc06c18b6 = assert_vop_locked+0x4a VOP_GETPAGES_APV(c091c9e0,d448a9e8) at 0xc0830e9e = VOP_GETPAGES_APV+0x52 vnode_pager_getpages(c1054c1c,d448aa34,1,0) at 0xc07c3917 = vnode_pager_getpages+0xd3 vm_imgact_hold_page(c1054c1c,6d104,0,d448aa8c,c0634851) at 0xc07b3051 = vm_imgact_hold_page+0x81 vm_imgact_map_page(c1054c1c,6d104,0,d448aaa4,c0649c03) at 0xc07b31cd = vm_imgact_map_page+0x11 elf32_load_section(c4365000,c1054c1c,6a580,80b3580,225a8) at 0xc0634851 = elf32_load_section+0x169 exec_elf32_imgact(d448abc4,c45fd000,0,1,0) at 0xc0634e1f = exec_elf32_imgact+0x24b do_execve(c435e480,d448ac90,0,0,d448ac90) at 0xc0648cbe = do_execve+0x262 kern_execve(c435e480,d448ac90,0,d35d8000,d35d8000) at 0xc06489d0 = kern_execve+0xc8 execve(c435e480,d448acf4,bfbfffe4,bfbffff2,bfbfffe8,bfbffffd,bfbfffec,0) at 0xc06488e2 = execve+0x32 start_init(0,d448ad38) at 0xc063653f = start_init+0x20f fork_exit(c0636330,0,d448ad38) at 0xc064d81d = fork_exit+0x75 fork_trampoline() at 0xc0809d6c = fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd448ad6c, ebp = 0 --- VOP_GETPAGES: 0xc45fca50 is not locked but should be KDB: enter: lock violation [thread pid 1 tid 100007 ] Stopped at 0xc067f78f = kdb_enter+0x2b: nop db> -- 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 Fri Dec 23 10:26:16 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8ABEB16A41F; Fri, 23 Dec 2005 10:26:16 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6EF8643D5A; Fri, 23 Dec 2005 10:26:11 +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.4/8.13.4) with ESMTP id jBNAQ5sc021216; Fri, 23 Dec 2005 05:26:05 -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.3/8.13.3) with ESMTP id jBNAQ5aU056549; Fri, 23 Dec 2005 05:26:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 4BCF47302F; Fri, 23 Dec 2005 05:26:05 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20051223102605.4BCF47302F@freebsd-current.sentex.ca> Date: Fri, 23 Dec 2005 05:26:05 -0500 (EST) X-Virus-Scanned: ClamAV version 0.85.1, clamav-milter version 0.85 on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2005 10:26:16 -0000 TB --- 2005-12-23 09:02:31 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-12-23 09:02:31 - starting HEAD tinderbox run for i386/pc98 TB --- 2005-12-23 09:02:31 - cleaning the object tree TB --- 2005-12-23 09:03:04 - checking out the source tree TB --- 2005-12-23 09:03:04 - cd /tinderbox/HEAD/i386/pc98 TB --- 2005-12-23 09:03:04 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-12-23 09:08:52 - building world (CFLAGS=-O2 -pipe) TB --- 2005-12-23 09:08:52 - cd /src TB --- 2005-12-23 09:08:52 - /usr/bin/make -B buildworld >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-12-23 10:13:15 - generating LINT kernel config TB --- 2005-12-23 10:13:15 - cd /src/sys/pc98/conf TB --- 2005-12-23 10:13:15 - /usr/bin/make -B LINT TB --- 2005-12-23 10:13:16 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-12-23 10:13:16 - cd /src TB --- 2005-12-23 10:13:16 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Dec 23 10:13:16 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 [...] cc -c -x assembler-with-cpp -DLOCORE -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/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror /src/sys/pc98/apm/apm_bioscall.S cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/pc98/cbus/cbus_dma.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -Werror -finstrument-functions -Wno-inline /src/sys/pc98/cbus/clock.c /src/sys/pc98/cbus/clock.c: In function `clkintr': /src/sys/pc98/cbus/clock.c:167: warning: implicit declaration of function `TRAPF_USERMODE' /src/sys/pc98/cbus/clock.c:167: warning: nested extern declaration of `TRAPF_USERMODE' /src/sys/pc98/cbus/clock.c:167: warning: implicit declaration of function `TRAPF_PC' /src/sys/pc98/cbus/clock.c:167: warning: nested extern declaration of `TRAPF_PC' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2005-12-23 10:26:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-12-23 10:26:05 - ERROR: failed to build lint kernel TB --- 2005-12-23 10:26:05 - tinderbox aborted TB --- 1.10 user 5.39 system 5013.64 real From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 10:28:53 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DAB1C16A420; Fri, 23 Dec 2005 10:28:53 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD7FC43D7E; Fri, 23 Dec 2005 10:28:23 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp132-74.lns2.adl2.internode.on.net [59.167.132.74]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id jBNASKQU047315 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 23 Dec 2005 20:58:21 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: "Matthew D. Fuller" Date: Fri, 23 Dec 2005 20:57:48 +1030 User-Agent: KMail/1.8.3 References: <200512231136.12471.doconnor@gsoft.com.au> <200512230851.jBN8pFVv060458@hugo10.ka.punkt.de> <20051223085657.GF63497@over-yonder.net> In-Reply-To: <20051223085657.GF63497@over-yonder.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1382220.lQOUgZ8vqd"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200512232058.14651.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: "Patrick M. Hausen" , Jo Rhett , freebsd-stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 10:28:54 -0000 --nextPart1382220.lQOUgZ8vqd Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 23 Dec 2005 19:26, Matthew D. Fuller wrote: > > the Internet? I was planning to use NFS/TCP secured by IPSec > > transport mode, but anything less complicated would be greatly > > appreciated ;-) > > This is one of the situations where r{dist,sync}'ing out the binaries > makes more sense than NFS mounting and running installworld (which > would be awful awful slow, above and beyond security and convenience > issues). I guess one problem is that is replicating installworld's behaviour can be= =20 difficult as it does more than just install files sometimes. =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 --nextPart1382220.lQOUgZ8vqd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDq9E+5ZPcIHs/zowRAiFTAJ9w4aS/G191UDi+FtlRRXDMX2agsQCfSseM BC83jyyWZ3VHN6skrcHGsvM= =Y0pV -----END PGP SIGNATURE----- --nextPart1382220.lQOUgZ8vqd-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 10:29:06 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 709E716A423; Fri, 23 Dec 2005 10:29:06 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 314B043D77; Fri, 23 Dec 2005 10:28:52 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id jBNASXKp057148; Fri, 23 Dec 2005 10:28:34 GMT (envelope-from davidxu@freebsd.org) Message-ID: <43ABD158.8080802@freebsd.org> Date: Fri, 23 Dec 2005 18:28:40 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20050928 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Poul-Henning Kamp References: <26940.1135332727@critter.freebsd.dk> In-Reply-To: <26940.1135332727@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Jason Evans Subject: Re: New malloc ready, take 42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 10:29:06 -0000 Poul-Henning Kamp wrote: > >>The '>' option should be supported in jemalloc because mysql relies >>on it. > > > That is indeed a strange usage of the word "relies" and it sort of > indicates that you don't even have the foggiest notion about what > the '>' option does in phkmalloc. > > Maybe a reading of the relevant manual page might be in order ? > > Poul-Henning > I know what '>' does in phkmalloc. I found 'Q', he replaced '>' with 'Q', this is really strange to me. ;-) From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 10:34:56 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43E9F16A41F; Fri, 23 Dec 2005 10:34:56 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd3mo3so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E54D843D69; Fri, 23 Dec 2005 10:34:52 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd2mr4so.prod.shaw.ca (pd2mr4so-qfe3.prod.shaw.ca [10.0.141.107]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IRY00MGD5E3ZK80@l-daemon>; Fri, 23 Dec 2005 03:34:51 -0700 (MST) Received: from pn2ml9so.prod.shaw.ca ([10.0.121.7]) by pd2mr4so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IRY00ICZ5E3U8F0@pd2mr4so.prod.shaw.ca>; Fri, 23 Dec 2005 03:34:51 -0700 (MST) Received: from [192.168.0.60] ([24.87.209.6]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IRY00FCZ5E21D10@l-daemon>; Fri, 23 Dec 2005 03:34:51 -0700 (MST) Date: Fri, 23 Dec 2005 02:34:43 -0800 From: Colin Percival In-reply-to: <20051223100251.GB6049@uk.tiscali.com> To: Brian Candler Message-id: <43ABD2C3.9020301@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.93.0.0 References: <43A266E5.3080103@samsco.org> <20051217220021.GB93998@svcolo.com> <20051218023725.GM63497@over-yonder.net> <20051222210904.GH39174@svcolo.com> <20051223030813.GD63497@over-yonder.net> <20051223100251.GB6049@uk.tiscali.com> User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051001) Cc: Jo Rhett , stable@freebsd.org, current , "Matthew D. Fuller" Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 10:34:56 -0000 Brian Candler wrote: > I think the real concern here is: for how long after RELEASE_X_Y are binary > patches for it made available? I build FreeBSD Update patches for all the branches supported by the FreeBSD Security Team. To answer a couple of other questions: FreeBSD Update is something which I _personally_ support; it isn't supported by the _project_, because at the moment there isn't anyone else who could take over running it if I get hit by a bus. Re the long list of requests people have made (starting with "amd64 support" and "make this officially supported by the project"), I'll get to those as soon as I have time. Sadly, I have a pesky thing called "a full time job" and my FreeBSD time has been occupied with portsnap lately. Colin Percival From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 10:39:15 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D2D2F16A420; Fri, 23 Dec 2005 10:39:15 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.FreeBSD.org (Postfix) with ESMTP id 71F0443D6B; Fri, 23 Dec 2005 10:39:15 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id E5964BC66; Fri, 23 Dec 2005 10:39:12 +0000 (UTC) To: freebsd-stable@freebsd.org, current From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 23 Dec 2005 20:57:48 +1030." <200512232058.14651.doconnor@gsoft.com.au> Date: Fri, 23 Dec 2005 11:39:12 +0100 Message-ID: <27065.1135334352@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 10:39:16 -0000 I have consistently ignored all emails in this thread because the use of the word "demand" in the Subject. Whenever people use words like "demand" or "somebody should" in FreeBSD contexts, it indicates cluelessness to me. Cluelessness about how the project works and cluenessness about how things happen in the project and a touch of insensibility to the developers how seldom are paid to listen to such drivel. The precense if "binary updates" in the subject also indicated to me that we had to do with people who didn't really know what they were talking about nor indeed the implications of attempting to do what they demanded. Now that I've read the tread anyway I can to my chagrin see that I was right. In my opinion, and I readily admit that since I only have 20+ years of experience managing UNIX computers I may be totally wrong, binary updates is not what we really want. It's what people are used to, but it is not what they want. It would be much better to invest time in developing a configuration management system that allows the system administrators of FreeBSD installations to do their job more effectively than to spend time giving them the tool they know inwards and outwards is not an effective way to do their job. The assignment is simple, and with creative thinking maybe the solution is also: Bring to system administration what source code version control brought to programming. Merry Xmas, 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 Fri Dec 23 11:34:36 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2792216A41F; Fri, 23 Dec 2005 11:34:36 +0000 (GMT) (envelope-from dsh@vlink.ru) Received: from deliver.smtp.vlink.ru (vlink-1.avtlg.ru [83.239.142.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8837843D55; Fri, 23 Dec 2005 11:34:30 +0000 (GMT) (envelope-from dsh@vlink.ru) Received: from smtp.smtp.vlink.ru (clamav.smtp.vlink.ru [192.168.4.1]) by deliver.smtp.vlink.ru (Postfix) with ESMTP id 443ACFED8C0; Fri, 23 Dec 2005 14:34:29 +0300 (MSK) Received: from neva.vlink.ru (neva.vlink.ru [217.107.252.29]) by smtp.smtp.vlink.ru (Postfix) with ESMTP id 211E910098BA; Fri, 23 Dec 2005 14:34:26 +0300 (MSK) Received: from neva.vlink.ru (localhost [127.0.0.1]) by neva.vlink.ru (8.13.4/8.13.4) with ESMTP id jBNBYDAY054155; Fri, 23 Dec 2005 14:34:13 +0300 (MSK) (envelope-from dsh@vlink.ru) Received: (from dsh@localhost) by neva.vlink.ru (8.13.4/8.13.4/Submit) id jBNBXnQV054148; Fri, 23 Dec 2005 14:33:49 +0300 (MSK) (envelope-from dsh@vlink.ru) X-Comment-To: Doug Barton To: Doug Barton References: <87hd91fm3n.fsf@neva.vlink.ru> <20051222165553.GB13683@odin.ac.hmc.edu> <43AAF78E.9030205@FreeBSD.org> From: Denis Shaposhnikov Date: Fri, 23 Dec 2005 14:33:49 +0300 In-Reply-To: <43AAF78E.9030205@FreeBSD.org> (Doug Barton's message of "Thu, 22 Dec 2005 10:59:26 -0800") Message-ID: <87acesjbdu.fsf@neva.vlink.ru> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-current@freebsd.org Subject: Re: troubles with /usr/local/etc/rc.d scripts in jail X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 11:34:36 -0000 >>>>> "Doug" == Doug Barton writes: >> I might make the early late divider NETWORKING. Doug> I agree with Brooks here. If that works for you, can you please Doug> let us know? I can add another section to rc.conf(5) for jails Doug> like we did for diskless boot. Yes, it works fine. -- DSS5-RIPE DSS-RIPN 2:550/5068@fidonet 2:550/5069@fidonet mailto:dsh@vlink.ru http://neva.vlink.ru/~dsh/ From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 11:44:32 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CD9F16A41F for ; Fri, 23 Dec 2005 11:44:32 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF05343D58 for ; Fri, 23 Dec 2005 11:44:29 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp132-74.lns2.adl2.internode.on.net [59.167.132.74]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id jBNBiRZd048100 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 23 Dec 2005 22:14:27 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Fri, 23 Dec 2005 22:14:13 +1030 User-Agent: KMail/1.8.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4190476.Dv6TNIgTFJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200512232214.21552.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Subject: if_ed on !i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 11:44:32 -0000 --nextPart4190476.Dv6TNIgTFJ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Is there any reason it is not built? It works on in amd64 under qemu (about the only time you're likely to find= =20 NE2000 hardware on amd64 I'd hope :) If there is no reason it isn't built by default can someone commit this pat= ch? Index: modules/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=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/local/ncvs/src/sys/modules/Makefile,v retrieving revision 1.450.2.8 diff -u -r1.450.2.8 Makefile =2D-- modules/Makefile 1 Dec 2005 02:43:13 -0000 1.450.2.8 +++ modules/Makefile 23 Dec 2005 11:43:51 -0000 @@ -68,7 +68,7 @@ ${_dpt} \ ${_drm} \ dummynet \ =2D ${_ed} \ + ed \ ${_el} \ ${_elink} \ ${_em} \ @@ -328,7 +328,6 @@ _cpufreq=3D cpufreq _digi=3D digi _drm=3D drm =2D_ed=3D ed _elink=3D elink _em=3D em _ep=3D ep Thanks. =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 --nextPart4190476.Dv6TNIgTFJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDq+MV5ZPcIHs/zowRAu1UAJ4khE9Vpuz8ybmKvVtqnARXCQrrjgCePC/I /qqSwtJll1St3GCuqpSEByc= =pCX/ -----END PGP SIGNATURE----- --nextPart4190476.Dv6TNIgTFJ-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 12:26:45 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F07616A41F for ; Fri, 23 Dec 2005 12:26:45 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBB2343D4C for ; Fri, 23 Dec 2005 12:26:43 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 3052C52BC5; Fri, 23 Dec 2005 13:26:41 +0100 (CET) Received: from localhost (dlp165.neoplus.adsl.tpnet.pl [83.24.45.165]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 81E1D50F92; Fri, 23 Dec 2005 13:26:34 +0100 (CET) Date: Fri, 23 Dec 2005 13:25:37 +0100 From: Pawel Jakub Dawidek To: Poul-Henning Kamp Message-ID: <20051223122537.GA43276@garage.freebsd.pl> References: <26957.1135333098@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline In-Reply-To: <26957.1135333098@critter.freebsd.dk> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r535 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: ** X-Spam-Status: No, score=2.6 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL,RCVD_IN_XBL autolearn=no version=3.0.4 Cc: current@freebsd.org Subject: Re: diskless VFS lock issue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2005 12:26:45 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 23, 2005 at 11:18:18AM +0100, Poul-Henning Kamp wrote: +>=20 +> fxp0: link state changed to UP +> KDB: stack backtrace: +> kdb_backtrace(d448a9b4,c06c18b6,c088e359,c08a84c5,c45fca50) at 0xc067f70= d =3D kdb_backtrace+0x29 +> vfs_badlock(c088e359,c08a84c5,c45fca50) at 0xc06c17bd =3D vfs_badlock+0x= 11 +> assert_vop_locked(c45fca50,c08a84c5,c45fca50,c08a84c5) at 0xc06c18b6 =3D= assert_vop_locked+0x4a +> VOP_GETPAGES_APV(c091c9e0,d448a9e8) at 0xc0830e9e =3D VOP_GETPAGES_APV+0= x52 +> vnode_pager_getpages(c1054c1c,d448aa34,1,0) at 0xc07c3917 =3D vnode_page= r_getpages+0xd3 +> vm_imgact_hold_page(c1054c1c,6d104,0,d448aa8c,c0634851) at 0xc07b3051 = =3D vm_imgact_hold_page+0x81 +> vm_imgact_map_page(c1054c1c,6d104,0,d448aaa4,c0649c03) at 0xc07b31cd =3D= vm_imgact_map_page+0x11 +> elf32_load_section(c4365000,c1054c1c,6a580,80b3580,225a8) at 0xc0634851 = =3D elf32_load_section+0x169 +> exec_elf32_imgact(d448abc4,c45fd000,0,1,0) at 0xc0634e1f =3D exec_elf32_= imgact+0x24b +> do_execve(c435e480,d448ac90,0,0,d448ac90) at 0xc0648cbe =3D do_execve+0x= 262 +> kern_execve(c435e480,d448ac90,0,d35d8000,d35d8000) at 0xc06489d0 =3D ker= n_execve+0xc8 +> execve(c435e480,d448acf4,bfbfffe4,bfbffff2,bfbfffe8,bfbffffd,bfbfffec,0)= at 0xc06488e2 =3D execve+0x32 +> start_init(0,d448ad38) at 0xc063653f =3D start_init+0x20f +> fork_exit(c0636330,0,d448ad38) at 0xc064d81d =3D fork_exit+0x75 +> fork_trampoline() at 0xc0809d6c =3D fork_trampoline+0x8 +> --- trap 0x1, eip =3D 0, esp =3D 0xd448ad6c, ebp =3D 0 --- +> VOP_GETPAGES: 0xc45fca50 is not locked but should be +> KDB: enter: lock violation +> [thread pid 1 tid 100007 ] +> Stopped at 0xc067f78f =3D kdb_enter+0x2b: nop =20 +> db>=20 It was broken by alc@'s commit. He knows about it already. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDq+zBForvXbEpPzQRAhC1AJ9XawsuA3OFGV5HyzwvLqQ9KV27RQCfTbGq DYgBkVoW0wIdZxeC0+7SlVs= =wlyO -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 08:51:24 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E58716A420; Fri, 23 Dec 2005 08:51:24 +0000 (GMT) (envelope-from hausen@punkt.de) Received: from gate.ka.punkt.de (kagate.punkt.de [217.29.33.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59B4943D5E; Fri, 23 Dec 2005 08:51:22 +0000 (GMT) (envelope-from hausen@punkt.de) Received: from hugo10.ka.punkt.de (hugo10.ka.punkt.de [10.0.0.110]) by gate.ka.punkt.de with ESMTP id jBN8pLba024492; Fri, 23 Dec 2005 09:51:21 +0100 (CET) Received: from hugo10.ka.punkt.de (localhost [127.0.0.1]) by hugo10.ka.punkt.de (8.12.10/8.12.10) with ESMTP id jBN8pIuL060459; Fri, 23 Dec 2005 09:51:18 +0100 (CET) (envelope-from ry93@hugo10.ka.punkt.de) Received: (from ry93@localhost) by hugo10.ka.punkt.de (8.12.10/8.12.10/Submit) id jBN8pFVv060458; Fri, 23 Dec 2005 09:51:15 +0100 (CET) (envelope-from ry93) From: "Patrick M. Hausen" Message-Id: <200512230851.jBN8pFVv060458@hugo10.ka.punkt.de> In-Reply-To: <200512231136.12471.doconnor@gsoft.com.au> To: "Daniel O'Connor" Date: Fri, 23 Dec 2005 09:51:15 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL99f (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Fri, 23 Dec 2005 12:45:56 +0000 Cc: Jo Rhett , stable@freebsd.org, freebsd-stable@freebsd.org, current Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 08:51:24 -0000 Hi, Folks! > On your central PC.. > buildworld once. > builkernel once for each of the different kernels you are using. > > On each 'client' PC.. > NFS mount /usr/src and /usr/obj > installkernel > reboot > installworld Any suggestions for an alternative to NFS if your 'client' servers are located "all over the world" and you want to installworld across the Internet? I was planning to use NFS/TCP secured by IPSec transport mode, but anything less complicated would be greatly appreciated ;-) Anyone using ggated/ggatec for that purpose? Thanks, Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH Internet - Dienstleistungen - Beratung Vorholzstr. 25 Tel. 0721 9109 -0 Fax: -100 76137 Karlsruhe http://punkt.de From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 09:15:56 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 477B616A41F; Fri, 23 Dec 2005 09:15:56 +0000 (GMT) (envelope-from symao@juniper.net) Received: from kremlin.juniper.net (kremlin.juniper.net [207.17.137.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 595BE43D73; Fri, 23 Dec 2005 09:15:52 +0000 (GMT) (envelope-from symao@juniper.net) Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by kremlin.juniper.net with ESMTP; 23 Dec 2005 01:15:52 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.99,286,1131350400"; d="scan'208"; a="517501284:sNHT34775548" Received: from lepton.jnpr.net ([10.208.0.16]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Dec 2005 01:15:51 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Dec 2005 17:11:04 +0800 Message-ID: <6834BE1811D97C4B8581CE6BD14506800545C5@lepton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Network performance measurements of -current Thread-Index: AcYHJCQJfBMPIyNMT32OGEjPw40miAAfG7cQ From: "ShouYan Mao" To: "Andre Oppermann" , X-OriginalArrivalTime: 23 Dec 2005 09:15:51.0624 (UTC) FILETIME=[784F7480:01C607A1] X-Mailman-Approved-At: Fri, 23 Dec 2005 12:50:36 +0000 Cc: freebsd-net@freebsd.org Subject: RE: Network performance measurements of -current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2005 09:15:56 -0000 So, would you try it with PCI-E Gigabit card? Best Regards. Shouyan ------------------------------------------------------- I'm not the best, but I try to do better. ------------------------------------------------------- -----Original Message----- From: owner-freebsd-net@freebsd.org = [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Andre Oppermann Sent: 2005=C4=EA12=D4=C223=C8=D5 2:17 To: freebsd-current@freebsd.org Cc: freebsd-net@freebsd.org Subject: Network performance measurements of -current As part my funded TCP/IP optimization work I'm doing lots of = measurements and profiling with an Agilent N2X network tester and calibrated traffic generator. The following data shall serve as baseline of the current performance we get out of FreeBSD 7-current. More to come tomorrow though. OS: FreeBSD 7-current as of 20051222-1600 UTC KERNEL: Generic kernel, minus WITNESS and INVARIANTS, plus HWPMC, = HZ=3D1000 HARDWARE: Dual Opteron 852 2.6Ghz, Tyan S2882 Mobo with AMD-8131 PCI-X = tunnel HARDWARE: dual Broadcom Gigabit BMC5704C PCI-X-133 ("bge") HARDWARE: dual Intel Gigabit 82546EB PCI-X-133 ("em") Uniprocessor kernel bge: normal forwarding bge0->bge1: = @64/326kpps/166us/402kpps(30%Loss)/194us normal forwarding bge0->bge1: @1500/81kpps/520us normal forwarding bge0->disc0: @64/1205kpps IP fastforwarding bge0->bge1: = @64/565kpps/192us/575kpps(60%Loss)/1090us IP fastforwarding bge0->bge1: @1500/81kpps/730us IP fastforwarding bge0->disc0: @64/1160kpps net.isr.direct=3D1 bge0->bge1: = @64/476kpps/211us/487kpps(68%Loss)/1284us net.isr.direct=3D1 bge0->bge1: @1500/81kpps/760us net.isr.direct=3D1 bge0->disc0: @64/1250kpps polling (*) bge0->bge1: =20 @64/420kpps(9%Loss)/1385us/416kpps(72%Loss)/1600us polling (*) bge0->bge1: @1500/71kpps(9%Loss)/850us polling (*) bge0->disc0: @64/697kpps Comments: Under full load the normal processing breaks completely down while with IP fastforwarding it levels off but continues to forward. Strangely with polling it has 9% loss at all loads (even at 1% = wirespeed). May be related to HZ=3D1000. em: normal forwarding em0->em1: = @64/372kpps/112us/396kpps(11%Loss)/131us normal forwarding em0->em1: @1500/81kpps/170us normal forwarding em0->disc0: @64/1130kpps IP fastforwarding em0->em1: = @64/565kpps/45us/585kpps(4%Loss)/1600us IP fastforwarding em0->em1: @1500/81kpps/135us IP fastforwarding em0->disc0: @64/1116kpps net.isr.direct=3D1 em0->em1: later net.isr.direct=3D1 em0->disc0: later polling (*) em0->em1: later polling (*) em0->disc0: later (*) max_burst=3D1000, user_frac=3D0, each_burst=3D30 Sponsored by: TCP/IP Optimization Fundraise 2005 --=20 Andre _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 09:40:20 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4FAC16A41F; Fri, 23 Dec 2005 09:40:20 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07CA643D5E; Fri, 23 Dec 2005 09:40:19 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id CE0B23EAA; Fri, 23 Dec 2005 03:40:18 -0600 (CST) Date: Fri, 23 Dec 2005 03:40:18 -0600 To: Jason Evans Message-ID: <20051223094018.GA25562@soaustin.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Fri, 23 Dec 2005 12:52:10 +0000 Cc: freebsd-current@freebsd.org Subject: Re: New malloc ready, take 42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 09:40:20 -0000 On Fri, Dec 23, 2005 at 01:14:08AM -0800, Jason Evans wrote: > * Claus Guttesen and Devon O'Dell reported issues in kldxref and X on > amd64 [ ... ] Apparently, we are on the cusp of the transition to using > [latest xorg], so for now the workaround on amd64 is to use xorg-server- > snap, with the expectation that soon the standard xorg-server port > will be upgraded. I think it's fair to ask if anyone has attempted to find out if there are similar problems with XFree86 on either i386 or amd64. I don't know if there is any appreciable install base for the latter but AFAICT there still is for the former. At least we ought to know yea or nay before making the switch, IMHO. mcl From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 13:09:05 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95CBD16A41F; Fri, 23 Dec 2005 13:09:05 +0000 (GMT) (envelope-from mak@ll.mit.edu) Received: from ll.mit.edu (LLMAIL.LL.MIT.EDU [129.55.12.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3539A43D49; Fri, 23 Dec 2005 13:09:04 +0000 (GMT) (envelope-from mak@ll.mit.edu) Received: (from smtp@localhost) by ll.mit.edu (8.12.10/8.8.8) id jBND93Ra016150; Fri, 23 Dec 2005 08:09:03 -0500 (EST) Received: from UNKNOWN( ), claiming to be "[155.34.104.109]" via SMTP by llmail, id smtpdAAAS1aajF; Fri Dec 23 08:08:56 2005 Message-ID: <43ABF6E4.2090908@ll.mit.edu> Date: Fri, 23 Dec 2005 08:08:52 -0500 From: "Michael A. Koerber" User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051220) X-Accept-Language: en-us, en MIME-Version: 1.0 To: stable@freebsd.org, current@freebsd.org X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 23 Dec 2005 13:18:16 +0000 Cc: Subject: SSH login takes very long time...sometimes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 13:09:05 -0000 All, I have three machines that have had 5.4 and 6.0 installed. Two of the three machines have very well behaved "ssh". However, the machine (laptop) named OBOE does not. Specifically "ssh oboe" will (most of the time) hang for around one minute before asking for a prompt. However, if I'm logged into OBOE and "ssh BSD" (one of the other machines) a password is requested within a couple seconds. (I said most of the time, since on occasion I can reboot OBOE and ssh will work just fine...hmmm.) I have looked through the /var/log files for clues and skimmed "man ssh" for time out related stuff, but no luck. Where should I start looking for clues? All machines have had clean installs from "newfs'd" drive under both 5.4 and 6.0 so I'm sure no left over configs are getting propagated. -- --------------------- Dr Michael A. Koerber x3250 From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 13:24:49 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 919DA16A41F; Fri, 23 Dec 2005 13:24:49 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1534043D45; Fri, 23 Dec 2005 13:24:48 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id jBNDOjVF008268; Fri, 23 Dec 2005 08:24:47 -0500 (EST) Date: Fri, 23 Dec 2005 08:24:45 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Scott Long In-Reply-To: <43ABC3E2.1030108@samsco.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, Jason Evans Subject: Re: New malloc ready, take 42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Dec 2005 13:24:49 -0000 On Fri, 23 Dec 2005, Scott Long wrote: > Jason Evans wrote: > > > Here's a current version of all the changes that are necessary for > > jemalloc to go in to the tree: > > > > http://people.freebsd.org/~jasone/jemalloc/patches/ > > jemalloc_20051222c.diff > > > > This patch includes (roughly): > > > > 1) Fix gensnmptree bug (missing variable initialization). I emailed > > the maintainer, Hartmut Brandt, about this today, and am awaiting a reply. > > > > 2) Fix kldxref bug (assumes allocation is adequately aligned). This > > needs to be committed along with (5), since the fix uses posix_memalign(). > > > > 3) Move calloc() from calloc.c to malloc.c (enables better statistics > > gathering). > > > > 4) Add _malloc_{pre,post}fork(), for use by threading libraries. > > > > 5) Replace malloc(), calloc(), realloc(), and free(). Add > > posix_memalign(). > > > > I'd like to commit (3) and (4) first, so that we have a version of > > phkmalloc in the cvs repository that is API-compatible with libc as it > > will be after jemalloc is committed. This will make it easier to swap > > the phkmalloc code in, should we wish to do further benchmarking or > > regression testing at some point in the future. Poul-Henning has > > agreed with this in principle, though I haven't yet supplied him with > > diffs for only (3) and (4). > > > > So, how about it? Is jemalloc ready to go in now? > > > > Thanks, > > Jason > > I think that this is overall a good plan. Two things need to be > stressed, since they will quickly become FAQs. First is that phkmalloc > and jemalloc won't be interchangable at runtime, like the threading > libraries are. Second is that amd64 will be stuck without working X > until the 6.9/7.0 stuff gets in the tree, and people should be well > aware of this. > > Another thing that I worry about is complex library scenarios where you > might have different versions of libc getting pulled into the same > process by different library dependencies. This could turn into a big > headache that is only solvable by telling people to wipe out their > entire ports collection and rebuild from scratch. Does this warrant a > library version bump now (as much as I really don't want to advocate > this)? Please, no more library version bumps (ever, hopefully). That's what we have library versioning for. Also, I don't see how this changes external APIs (ABI) any more than we've done in the past when adding interfaces. We're adding posix_memalign() and the __malloc_foofork() interfaces for our thread libraries. -- DE From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 13:26:44 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 498E816A41F; Fri, 23 Dec 2005 13:26:44 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81F3E43D5D; Fri, 23 Dec 2005 13:26:30 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id jBNDQUmU012490; Fri, 23 Dec 2005 07:26:30 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <43ABFAFF.9000306@centtech.com> Date: Fri, 23 Dec 2005 07:26:23 -0600 From: Eric Anderson User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Michael A. Koerber" References: <43ABF6E4.2090908@ll.mit.edu> In-Reply-To: <43ABF6E4.2090908@ll.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1213/Mon Dec 19 08:48:34 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: stable@freebsd.org, current@freebsd.org Subject: Re: SSH login takes very long time...sometimes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 13:26:44 -0000 Michael A. Koerber wrote: >All, > > I have three machines that have had 5.4 and 6.0 installed. Two of the three machines have very >well behaved "ssh". However, the machine (laptop) named OBOE does not. > > Specifically "ssh oboe" will (most of the time) hang for around one minute before asking for a >prompt. However, if I'm logged into OBOE and "ssh BSD" (one of the other machines) a password is >requested within a couple seconds. (I said most of the time, since on occasion I can reboot OBOE >and ssh will work just fine...hmmm.) > > I have looked through the /var/log files for clues and skimmed "man ssh" for time out related >stuff, but no luck. > > Where should I start looking for clues? > > All machines have had clean installs from "newfs'd" drive under both 5.4 and 6.0 so I'm sure no >left over configs are getting propagated. > > Check your DNS (or reverse DNS really) on the laptop (OBOE). Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 13:32:26 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0E5216A41F for ; Fri, 23 Dec 2005 13:32:26 +0000 (GMT) (envelope-from dsh@vlink.ru) Received: from deliver.smtp.vlink.ru (vlink-1.avtlg.ru [83.239.142.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00F7943D53 for ; Fri, 23 Dec 2005 13:32:25 +0000 (GMT) (envelope-from dsh@vlink.ru) Received: from smtp.smtp.vlink.ru (clamav.smtp.vlink.ru [192.168.4.1]) by deliver.smtp.vlink.ru (Postfix) with ESMTP id 12211FED4D4 for ; Fri, 23 Dec 2005 16:32:24 +0300 (MSK) Received: from neva.vlink.ru (neva.vlink.ru [217.107.252.29]) by smtp.smtp.vlink.ru (Postfix) with ESMTP id A8CCD1009806 for ; Fri, 23 Dec 2005 16:32:23 +0300 (MSK) Received: from neva.vlink.ru (localhost [127.0.0.1]) by neva.vlink.ru (8.13.4/8.13.4) with ESMTP id jBNDWDOw060566 for ; Fri, 23 Dec 2005 16:32:13 +0300 (MSK) (envelope-from dsh@vlink.ru) Received: (from dsh@localhost) by neva.vlink.ru (8.13.4/8.13.4/Submit) id jBNDWDQ9060563; Fri, 23 Dec 2005 16:32:13 +0300 (MSK) (envelope-from dsh@vlink.ru) To: freebsd-current@freebsd.org From: Denis Shaposhnikov Date: Fri, 23 Dec 2005 16:32:13 +0300 Message-ID: <87bqz8hrc2.fsf@neva.vlink.ru> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.18 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Virus-Scanned: ClamAV using ClamSMTP Subject: current freeze from time to time X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 13:32:27 -0000 Hi! I have a problem with CURRENT. It freezes from time to time on SMP dual Xeon system. For some processes I see MWCHAN = ufs and "D" in the STAT. And I can't kill such processes even with -9. And system can't kill them too on shutdown. So, system can't do shutdown and wait forever after "All buffers synced" message. At this moment I've entered to KDB do "show lockedvnods": Locked vnodes 0xc687cb58: tag ufs, type VDIR usecount 1, writecount 0, refcount 2 mountedhere 0 flags () v_object 0xcb5b1934 ref 0 pages 0 lock type ufs: EXCL (count 1) by thread 0xc795d600 (pid 74686) with 1 pending ino 2072602, on dev ad4s1g 0xc687ca50: tag ufs, type VDIR usecount 31, writecount 0, refcount 32 mountedhere 0 flags () v_object 0xc85d2744 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc7683d80 (pid 74178) with 6 pending ino 2072603, on dev ad4s1g 0xc687c948: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc875d000 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc91f3300 (pid 65610) with 1 pending ino 2072615, on dev ad4s1g 0xc691f420: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc8a773e0 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc68e5780 (pid 519) with 1 pending ino 2072680, on dev ad4s1g 0xc691f318: tag ufs, type VDIR usecount 3, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xc8a7b2e8 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc7019780 (pid 74103) with 2 pending ino 2072795, on dev ad4s1g 0xc69bb528: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc7890744 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc91f4600 (pid 74129) with 1 pending ino 2072767, on dev ad4s1g Locked vnodes 0xc687cb58: tag ufs, type VDIR usecount 1, writecount 0, refcount 2 mountedhere 0 flags () v_object 0xcb5b1934 ref 0 pages 0 lock type ufs: EXCL (count 1) by thread 0xc795d600 (pid 74686) with 1 pending ino 2072602, on dev ad4s1g 0xc687ca50: tag ufs, type VDIR usecount 31, writecount 0, refcount 32 mountedhere 0 flags () v_object 0xc85d2744 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc7683d80 (pid 74178) with 6 pending ino 2072603, on dev ad4s1g 0xc687c948: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc875d000 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc91f3300 (pid 65610) with 1 pending ino 2072615, on dev ad4s1g 0xc691f420: tag ufs, type VDIR usecount 2, writecount 0, refcount 3 mountedhere 0 flags () v_object 0xc8a773e0 ref 0 pages 1 lock type ufs: EXCL (count 1) by thread 0xc68e5780 (pid 519) with 1 pending ino 2072680, on dev ad4s1g 0xc691f318: tag ufs, type VDIR usecount 3, writecount 0, refcount 4 mountedhere 0 flags () v_object 0xc8a7b2e8 ref 0 pages 1 lock type ufs: EXCL (count 1) by t(kgdb) After that I've done "call doadump" and got vmcore. ps show me: (kgdb) ps During symbol reading, Incomplete CFI data; unspecified registers at 0xc04d97eb. pid proc uid ppid pgrp flag stat comm wchan 74686 c9464000 0 1 1 000000 1 sh ufs c687caa8 74195 c970d000 0 3074 74195 4000100 1 sshd ufs c687caa8 74178 c7682adc 0 3074 74178 004000 1 sshd ufs c687c9a0 74129 c9b82adc 1008 1 5504 004000 1 parser3.cgi ufs c691f370 74103 c70b5458 1008 1 5504 000000 1 httpd ufs c69bb580 65610 c92c0458 1005 1 65610 004000 1 sftp-server ufs c691f478 5518 c6247458 1008 1 5516 004002 1 perl5.8.7 ufs c687caa8 3081 c7523d08 0 1 3081 000000 1 cron ufs c687caa8 3074 c7682d08 0 1 3074 000100 1 sshd ufs c687caa8 3016 c7523adc 0 1 3016 000000 1 syslogd ufs c687caa8 519 c68e4d08 80 1 518 000100 1 nginx ufs c691f370 34 c6260000 0 0 0 000204 1 schedcpu - e88b3cf0 33 c62438b0 0 0 0 000204 1 syncer ktsusp c6243938 32 c6243adc 0 0 0 000204 1 vnlru ktsusp c6243b64 31 c6243d08 0 0 0 000204 1 bufdaemon ktsusp c6243d90 30 c6244000 0 0 0 00020c 1 pagezero pgzero c06c21a0 29 c624422c 0 0 0 000204 1 vmdaemon psleep c06c1d08 28 c6244458 0 0 0 000204 1 pagedaemon psleep c06c1cc8 27 c602e684 0 0 0 000204 1 irq1: atkbd0 26 c602e8b0 0 0 0 000204 1 swi0: sio 25 c602eadc 0 0 0 000204 1 irq18: atapci1 24 c602ed08 0 0 0 000204 1 irq15: ata1 23 c6074000 0 0 0 000204 1 irq14: ata0 22 c607422c 0 0 0 000204 1 irq27: em1 21 c6074458 0 0 0 000204 1 irq26: em0 20 c6074684 0 0 0 000204 1 irq9: acpi0 19 c60748b0 0 0 0 000204 1 swi2: cambio 18 c6074adc 0 0 0 000204 1 swi6: task queue 9 c5fd822c 0 0 0 000204 1 acpi_task2 - c6061e40 8 c5fd8458 0 0 0 000204 1 acpi_task1 - c6061e40 7 c5fd8684 0 0 0 000204 1 acpi_task0 - c6061e40 17 c5fd88b0 0 0 0 000204 1 swi6: Giant taskq 6 c5fd8adc 0 0 0 000204 1 thread taskq - c6062040 16 c5fd8d08 0 0 0 000204 1 swi5: Fast taskq 5 c602e000 0 0 0 000204 1 kqueue taskq - c6062100 15 c602e22c 0 0 0 000204 1 yarrow - c06b1720 4 c602e458 0 0 0 000204 1 g_down - c06b1fc0 3 c5fd3000 0 0 0 000204 1 g_up - c06b1fbc 2 c5fd322c 0 0 0 000204 1 g_event - c06b1fb4 14 c5fd3458 0 0 0 000204 1 swi3: vm 13 c5fd3684 0 0 0 00020c 1 swi4: clock sio 12 c5fd38b0 0 0 0 000204 1 swi1: net 11 c5fd3adc 0 0 0 00020c 1 idle: cpu0 10 c5fd3d08 0 0 0 00020c 1 idle: cpu1 1 c5fd8000 0 0 1 004200 1 init ufs c687cbb0 0 c06b20c0 0 0 0 000200 1 swapper There is no member named p_pptr. Note, I've tried to check v_object addresses from "show lockedvnodes": (kgdb) p/x *0xcb5b1934 $1 = 0xc068f280 (kgdb) p/x *0xc85d2744 $2 = 0xc068f280 (kgdb) p/x *0xc875d000 $3 = 0xc068f280 (kgdb) p/x *0xc8a773e0 $4 = 0xc068f280 ... and so on. May be that's important? Could anybody help me to fix this problem? PS. The system works fine with debug.mpsafevfs=0. -- DSS5-RIPE DSS-RIPN 2:550/5068@fidonet 2:550/5069@fidonet mailto:dsh@vlink.ru http://neva.vlink.ru/~dsh/ From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 13:30:00 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F55116A423; Fri, 23 Dec 2005 13:30:00 +0000 (GMT) (envelope-from kobi@macron.co.il) Received: from mxout1.netvision.net.il (mxout1.netvision.net.il [194.90.9.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CF4843D53; Fri, 23 Dec 2005 13:29:44 +0000 (GMT) (envelope-from kobi@macron.co.il) Received: from alpha.nonstop.co.il ([217.132.8.83]) by mxout1.netvision.net.il (Sun Java System Messaging Server 6.1 HotFix 0.11 (built Jan 28 2005)) with ESMTP id <0IRY00FKLDHD6X00@mxout1.netvision.net.il>; Fri, 23 Dec 2005 15:29:39 +0200 (IST) Received: from localhost ([127.0.0.1] helo=home1) by alpha.nonstop.co.il with smtp (Exim 4.44) id 1EpmzA-0000ja-I0; Fri, 23 Dec 2005 15:29:28 +0200 Date: Fri, 23 Dec 2005 15:29:17 +0200 From: Kobi Shmueli To: "Michael A. Koerber" Message-id: <001301c607c4$e04e2540$80cea8c0@home1> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Outlook Express 6.00.2800.1506 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <43ABF6E4.2090908@ll.mit.edu> X-Mailman-Approved-At: Fri, 23 Dec 2005 13:34:44 +0000 Cc: stable@freebsd.org, current@freebsd.org Subject: Re: SSH login takes very long time...sometimes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 13:30:00 -0000 Michael A. Koerber wrote: > I have three machines that have had 5.4 and 6.0 installed. Two of the three machines have very > well behaved "ssh". However, the machine (laptop) named OBOE does not. > > Specifically "ssh oboe" will (most of the time) hang for around one minute before asking for a > prompt. However, if I'm logged into OBOE and "ssh BSD" (one of the other machines) a password is > requested within a couple seconds. (I said most of the time, since on occasion I can reboot OBOE > and ssh will work just fine...hmmm.) > > I have looked through the /var/log files for clues and skimmed "man ssh" for time out related > stuff, but no luck. > > Where should I start looking for clues? Try checking /etc/resolv.conf on oboe first, adding a static entry to /etc/hosts of the remote ip/host should speed dns checks as well. You can also run ssh in verbose mode (ssh -v oboe) or/and run sshd in debug mode (sshd -d). -Kobi. From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 13:35:04 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 92C3A16A420; Fri, 23 Dec 2005 13:35:04 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E07343D5F; Fri, 23 Dec 2005 13:35:03 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.5/8.13.5/NETPLEX) with ESMTP id jBNDZ2Th022130; Fri, 23 Dec 2005 08:35:02 -0500 (EST) Date: Fri, 23 Dec 2005 08:35:01 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Scott Long In-Reply-To: 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, Jason Evans Subject: Re: New malloc ready, take 42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Dec 2005 13:35:04 -0000 On Fri, 23 Dec 2005, Daniel Eischen wrote: > On Fri, 23 Dec 2005, Scott Long wrote: > > > > Another thing that I worry about is complex library scenarios where you > > might have different versions of libc getting pulled into the same > > process by different library dependencies. This could turn into a big > > headache that is only solvable by telling people to wipe out their > > entire ports collection and rebuild from scratch. Does this warrant a > > library version bump now (as much as I really don't want to advocate > > this)? > > Please, no more library version bumps (ever, hopefully). That's > what we have library versioning for. Also, I don't see how I meant symbol versioning... > this changes external APIs (ABI) any more than we've done in > the past when adding interfaces. We're adding posix_memalign() > and the __malloc_foofork() interfaces for our thread libraries. I think if you have more than one version of libc linked into your program, you might be hosed regardless of the malloc changes. There's other global data in libc that may confuse the implementation when there is more than one instance of it. Have we ever guaranteed that you could do that? -- DE From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 13:54:08 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7759A16A41F; Fri, 23 Dec 2005 13:54:08 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from crivens.unixoid.de (crivens.unixoid.de [81.169.171.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE77643D72; Fri, 23 Dec 2005 13:54:07 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from localhost (localhost [127.0.0.1]) by crivens.unixoid.de (Postfix) with ESMTP id 61DD641C4; Fri, 23 Dec 2005 14:54:05 +0100 (CET) Received: from crivens.unixoid.de ([127.0.0.1]) by localhost (crivens.unixoid.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63658-12; Fri, 23 Dec 2005 14:54:01 +0100 (CET) Received: from [192.168.100.104] (p54BDDC0C.dip.t-dialin.net [84.189.220.12]) by crivens.unixoid.de (Postfix) with ESMTP id 9EAE941C3; Fri, 23 Dec 2005 14:53:46 +0100 (CET) Message-ID: <43AC0160.4070108@kernel32.de> Date: Fri, 23 Dec 2005 14:53:36 +0100 From: Marian Hettwer User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kobi Shmueli References: <43ABF6E4.2090908@ll.mit.edu> <001301c607c4$e04e2540$80cea8c0@home1> In-Reply-To: <001301c607c4$e04e2540$80cea8c0@home1> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at unixoid.de Cc: stable@freebsd.org, "Michael A. Koerber" , current@freebsd.org Subject: Re: SSH login takes very long time...sometimes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 13:54:08 -0000 Hej there, Kobi Shmueli wrote: > > > Try checking /etc/resolv.conf on oboe first, adding a static entry to > /etc/hosts of the remote ip/host should speed dns checks as well. > You can also run ssh in verbose mode (ssh -v oboe) or/and run sshd in debug > mode (sshd -d). > alternativly to check out wether it's dns related, you use set the Option "UseDNS no" in your sshd_config, so sshd won't try a reverse dns lookup. Give it a shoot. Usually ssh timeouts are related to DNS... HTH, Marian From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 14:24:07 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B762516A420; Fri, 23 Dec 2005 14:24:07 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from speedfactory.net (mail6.speedfactory.net [66.23.216.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3053143D62; Fri, 23 Dec 2005 14:24:01 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (unverified [66.23.211.162]) by speedfactory.net (SurgeMail 3.5b3) with ESMTP id 4425589 for multiple; Fri, 23 Dec 2005 09:25:18 -0500 Received: from zion.baldwin.cx (zion.baldwin.cx [192.168.0.7]) (authenticated bits=0) by server.baldwin.cx (8.13.4/8.13.4) with ESMTP id jBNENZ70043122; Fri, 23 Dec 2005 09:23:35 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org, Daniel Eischen Date: Fri, 23 Dec 2005 09:21:18 -0500 User-Agent: KMail/1.8.3 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200512230921.20887.jhb@freebsd.org> X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.4 required=4.2 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on server.baldwin.cx X-Server: High Performance Mail Server - http://surgemail.com r=1653887525 Cc: Jason Evans Subject: Re: New malloc ready, take 42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 14:24:07 -0000 On Friday 23 December 2005 08:35 am, Daniel Eischen wrote: > On Fri, 23 Dec 2005, Daniel Eischen wrote: > > On Fri, 23 Dec 2005, Scott Long wrote: > > > Another thing that I worry about is complex library scenarios where y= ou > > > might have different versions of libc getting pulled into the same > > > process by different library dependencies. This could turn into a big > > > headache that is only solvable by telling people to wipe out their > > > entire ports collection and rebuild from scratch. Does this warrant a > > > library version bump now (as much as I really don't want to advocate > > > this)? > > > > Please, no more library version bumps (ever, hopefully). That's > > what we have library versioning for. Also, I don't see how > > I meant symbol versioning... > > > this changes external APIs (ABI) any more than we've done in > > the past when adding interfaces. We're adding posix_memalign() > > and the __malloc_foofork() interfaces for our thread libraries. > > I think if you have more than one version of libc linked > into your program, you might be hosed regardless of the > malloc changes. There's other global data in libc that > may confuse the implementation when there is more than > one instance of it. Have we ever guaranteed that you could > do that? No, you're already screwed in that case. This will only be potentially=20 painful for folks using -current (since 7.0's libc will either be libc.so.7= =20 or have symbol versioning in use) and it's ok to create temporary pain for= =20 folks running -current. =2D-=20 John Baldwin =A0<>< =A0http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =A0=3D =A0http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 15:09:36 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7AD516A41F; Fri, 23 Dec 2005 15:09:36 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B56E543D66; Fri, 23 Dec 2005 15:09:34 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id jBNF9VJN013817; Fri, 23 Dec 2005 09:09:31 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <43AC1325.2080700@centtech.com> Date: Fri, 23 Dec 2005 09:09:25 -0600 From: Eric Anderson User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexander Kabaev References: <43A8BD3F.2010006@gddsn.org.cn> <20051220232754.48631fb4@kan.dnsalias.net> <20051221192118.GA88506@aoi.wolfpond.org> <43A9AE07.3070501@centtech.com> <20051222175152.292f510b@kan.dnsalias.net> In-Reply-To: <20051222175152.292f510b@kan.dnsalias.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1213/Mon Dec 19 08:48:34 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: current@freebsd.org, openoffice@freebsd.org Subject: Re: [openoffice]no suitable windowing system found, exiting. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 15:09:37 -0000 Alexander Kabaev wrote: >The commit below fixes OpenOffice 1.1.5 for me. > >kan 2005-12-22 16:42:38 UTC > > FreeBSD src repository > > Modified files: > libexec/rtld-elf rtld.c > Log: > Initialize object dagmembers list before checking version >dependencies. > Revision Changes Path > 1.110 +2 -4 src/libexec/rtld-elf/rtld.c > >http://cvsweb.FreeBSD.org/src/libexec/rtld-elf/rtld.c.diff?r1=1.109&r2=1.110 > > > > Yep, that did it (for 2.0). Thanks! Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 15:20:45 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1888916A41F for ; Fri, 23 Dec 2005 15:20:45 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CE4443D55 for ; Fri, 23 Dec 2005 15:20:44 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id jBNFKhNJ033832; Fri, 23 Dec 2005 09:20:43 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <43AC15C5.1040306@centtech.com> Date: Fri, 23 Dec 2005 09:20:37 -0600 From: Eric Anderson User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@freebsd.org References: <43A8BD3F.2010006@gddsn.org.cn> <20051220232754.48631fb4@kan.dnsalias.net> <20051221192118.GA88506@aoi.wolfpond.org> <43A9AE07.3070501@centtech.com> <20051222175152.292f510b@kan.dnsalias.net> <43AC1325.2080700@centtech.com> In-Reply-To: <43AC1325.2080700@centtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1213/Mon Dec 19 08:48:34 2005 on mh2.centtech.com X-Virus-Status: Clean Cc: Alexander Kabaev Subject: Re: [openoffice]no suitable windowing system found, exiting. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 15:20:45 -0000 Eric Anderson wrote: > Alexander Kabaev wrote: > >> The commit below fixes OpenOffice 1.1.5 for me. >> >> kan 2005-12-22 16:42:38 UTC >> >> FreeBSD src repository >> >> Modified files: >> libexec/rtld-elf rtld.c Log: >> Initialize object dagmembers list before checking version >> dependencies. Revision Changes Path >> 1.110 +2 -4 src/libexec/rtld-elf/rtld.c >> >> http://cvsweb.FreeBSD.org/src/libexec/rtld-elf/rtld.c.diff?r1=1.109&r2=1.110 >> >> >> >> >> > > Yep, that did it (for 2.0). Thanks! Although now firefox segfaults. I'm recompiling it now, but this is all I could scavange from the core file: in _rtld_free_tls () from /libexec/ld-elf.so.1 Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 15:40:27 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B06F16A41F for ; Fri, 23 Dec 2005 15:40:27 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3364D43D69 for ; Fri, 23 Dec 2005 15:40:20 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so458569wxc for ; Fri, 23 Dec 2005 07:40:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=p56AuC6NA1I1ucg3w8/lZPWRC8Rn5w31s4OnksYPGZAAeqAlZAMRgCYdAQmpTrwV7PMjxcNlSSCYChX7CsUH0qxINyL38trgBGKgOuhKWe/gDWbs4Op7ROABaiA1P8H0cBJvymiNuXanNH28zV01AA9CfKr3bwMNjmHeJ/bF/x0= Received: by 10.70.97.9 with SMTP id u9mr3426686wxb; Fri, 23 Dec 2005 07:40:19 -0800 (PST) Received: by 10.70.105.13 with HTTP; Fri, 23 Dec 2005 07:40:19 -0800 (PST) Message-ID: <84dead720512230740m732add82i95416281be335a80@mail.gmail.com> Date: Fri, 23 Dec 2005 21:10:19 +0530 From: Joseph Koshy To: Poul-Henning Kamp In-Reply-To: <27065.1135334352@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200512232058.14651.doconnor@gsoft.com.au> <27065.1135334352@critter.freebsd.dk> Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 15:40:27 -0000 phk> Bring to system administration what source code phk> version control brought to programming. www.infrastructures.org www.isconf.org -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 15:34:58 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0725016A41F for ; Fri, 23 Dec 2005 15:34:58 +0000 (GMT) (envelope-from kabaev@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FA9A43D4C for ; Fri, 23 Dec 2005 15:34:57 +0000 (GMT) (envelope-from kabaev@gmail.com) Received: by xproxy.gmail.com with SMTP id t12so469252wxc for ; Fri, 23 Dec 2005 07:34:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type; b=H0ypVkrIvJUx2j2naEGZe5Byb4XJ6XIUkpeBxI1KZB2q62+f8f0vdY9Wf/gFVwObGA0t8kqXMBsK9AEZSF4ik5SIcfcENGHNPQAbYTbwE2l2WSyLf8KYeIkSuVoNaICoF11nqZspXgUAaHEe8PSCRkMNkA6vk4nNoHsB/Uus4ts= Received: by 10.70.26.8 with SMTP id 8mr3375321wxz; Fri, 23 Dec 2005 07:34:56 -0800 (PST) Received: from kan.dnsalias.net ( [24.63.93.195]) by mx.gmail.com with ESMTP id i12sm5051442wxd.2005.12.23.07.34.56; Fri, 23 Dec 2005 07:34:56 -0800 (PST) Date: Fri, 23 Dec 2005 10:34:48 -0500 From: Alexander Kabaev To: Eric Anderson Message-ID: <20051223103448.3d7eb8d4@kan.dnsalias.net> In-Reply-To: <43AC15C5.1040306@centtech.com> References: <43A8BD3F.2010006@gddsn.org.cn> <20051220232754.48631fb4@kan.dnsalias.net> <20051221192118.GA88506@aoi.wolfpond.org> <43A9AE07.3070501@centtech.com> <20051222175152.292f510b@kan.dnsalias.net> <43AC1325.2080700@centtech.com> <43AC15C5.1040306@centtech.com> X-Mailer: Sylpheed-Claws 1.9.13 (GTK+ 2.6.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Signature_Fri__23_Dec_2005_10_34_48_-0500_O/SIeXUx+dLNmY+u"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Mailman-Approved-At: Fri, 23 Dec 2005 15:45:19 +0000 Cc: current@freebsd.org Subject: Re: [openoffice]no suitable windowing system found, exiting. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 15:34:58 -0000 --Signature_Fri__23_Dec_2005_10_34_48_-0500_O/SIeXUx+dLNmY+u Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 23 Dec 2005 09:20:37 -0600 Eric Anderson wrote: > Eric Anderson wrote: >=20 > > Alexander Kabaev wrote: > > > >> The commit below fixes OpenOffice 1.1.5 for me. > >> > >> kan 2005-12-22 16:42:38 UTC > >> > >> FreeBSD src repository > >> > >> Modified files: > >> libexec/rtld-elf rtld.c Log: > >> Initialize object dagmembers list before checking version > >> dependencies. Revision Changes Path > >> 1.110 +2 -4 src/libexec/rtld-elf/rtld.c > >> > >> http://cvsweb.FreeBSD.org/src/libexec/rtld-elf/rtld.c.diff?r1=3D1.109&= r2=3D1.110=20 > >> > >> > >> > >> =20 > >> > > > > Yep, that did it (for 2.0). Thanks! >=20 >=20 > Although now firefox segfaults. I'm recompiling it now, but this is > all I could scavange from the core file: > in _rtld_free_tls () from /libexec/ld-elf.so.1 >=20 > Eric >=20 >=20 >=20 >=20 > --=20 > ------------------------------------------------------------------------ > Eric Anderson Sr. Systems Administrator Centaur > Technology Anything that works is better than anything that doesn't. > ------------------------------------------------------------------------ The segfault was caused by *((char *)0) =3D 0; statement that I forgot to remove from the source before committing. Now firefox does not segfault but properly fails to load plugin due to inadequate versioning emulation by flash[67].so wrappers. --=20 Alexander Kabaev --Signature_Fri__23_Dec_2005_10_34_48_-0500_O/SIeXUx+dLNmY+u Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDrBkeQ6z1jMm+XZYRAmHbAJ4jeYU0f+scUUt7FwCE3xAx8PN8QQCgiwzg lQtmT8Rerlv2ozftcowup8k= =dytL -----END PGP SIGNATURE----- --Signature_Fri__23_Dec_2005_10_34_48_-0500_O/SIeXUx+dLNmY+u-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 16:42:51 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDEF416A41F for ; Fri, 23 Dec 2005 16:42:51 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31DD443D55 for ; Fri, 23 Dec 2005 16:42:50 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id jBNGgn28015111; Fri, 23 Dec 2005 10:42:50 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <43AC2903.3040208@centtech.com> Date: Fri, 23 Dec 2005 10:42:43 -0600 From: Eric Anderson User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051204) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexander Kabaev References: <43A8BD3F.2010006@gddsn.org.cn> <20051220232754.48631fb4@kan.dnsalias.net> <20051221192118.GA88506@aoi.wolfpond.org> <43A9AE07.3070501@centtech.com> <20051222175152.292f510b@kan.dnsalias.net> <43AC1325.2080700@centtech.com> <43AC15C5.1040306@centtech.com> <20051223103448.3d7eb8d4@kan.dnsalias.net> In-Reply-To: <20051223103448.3d7eb8d4@kan.dnsalias.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1213/Mon Dec 19 08:48:34 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: current@freebsd.org Subject: Re: [openoffice]no suitable windowing system found, exiting. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 16:42:52 -0000 Alexander Kabaev wrote: >On Fri, 23 Dec 2005 09:20:37 -0600 >Eric Anderson wrote: > > > >>Eric Anderson wrote: >> >> >> >>>Alexander Kabaev wrote: >>> >>> >>> >>>>The commit below fixes OpenOffice 1.1.5 for me. >>>> >>>>kan 2005-12-22 16:42:38 UTC >>>> >>>> FreeBSD src repository >>>> >>>> Modified files: >>>> libexec/rtld-elf rtld.c Log: >>>> Initialize object dagmembers list before checking version >>>>dependencies. Revision Changes Path >>>> 1.110 +2 -4 src/libexec/rtld-elf/rtld.c >>>> >>>>http://cvsweb.FreeBSD.org/src/libexec/rtld-elf/rtld.c.diff?r1=1.109&r2=1.110 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>Yep, that did it (for 2.0). Thanks! >>> >>> >>Although now firefox segfaults. I'm recompiling it now, but this is >>all I could scavange from the core file: >>in _rtld_free_tls () from /libexec/ld-elf.so.1 >> >>Eric >> >> >> >> >>-- >>------------------------------------------------------------------------ >>Eric Anderson Sr. Systems Administrator Centaur >>Technology Anything that works is better than anything that doesn't. >>------------------------------------------------------------------------ >> >> >The segfault was caused by *((char *)0) = 0; statement that I forgot to >remove from the source before committing. Now firefox does not segfault >but properly fails to load plugin due to inadequate versioning >emulation by flash[67].so wrappers. > That does stop the seg faults, but now flash doesn't work: LoadPlugin: failed to initialize shared library /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so [/usr/local/lib/pluginwrapper/flash6.so does not have version information, but /usr/X11R6/lib/linux-flashplugin6/libflashplayer.so requires it] LoadPlugin: failed to initialize shared library /usr/X11R6/lib/linux-flashplugin7/libflashplayer.so [/usr/local/lib/pluginwrapper/flash7.so does not have version information, but /usr/X11R6/lib/linux-flashplugin7/libflashplayer.so requires it] How do I fix the versioning emulation on the flash wrapper? Thanks! Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 17:25:06 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8365016A41F for ; Fri, 23 Dec 2005 17:25:06 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DF5E43D49 for ; Fri, 23 Dec 2005 17:25:03 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jBNHP1Bg076442; Fri, 23 Dec 2005 10:25:01 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <43AC32EC.7010609@samsco.org> Date: Fri, 23 Dec 2005 10:25:00 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel O'Connor" References: <200512232214.21552.doconnor@gsoft.com.au> In-Reply-To: <200512232214.21552.doconnor@gsoft.com.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: if_ed on !i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 17:25:06 -0000 Daniel O'Connor wrote: > Is there any reason it is not built? > > It works on in amd64 under qemu (about the only time you're likely to find > NE2000 hardware on amd64 I'd hope :) > > If there is no reason it isn't built by default can someone commit this patch? > > Index: modules/Makefile > =================================================================== > RCS file: /usr/local/ncvs/src/sys/modules/Makefile,v > retrieving revision 1.450.2.8 > diff -u -r1.450.2.8 Makefile > --- modules/Makefile 1 Dec 2005 02:43:13 -0000 1.450.2.8 > +++ modules/Makefile 23 Dec 2005 11:43:51 -0000 > @@ -68,7 +68,7 @@ > ${_dpt} \ > ${_drm} \ > dummynet \ > - ${_ed} \ > + ed \ > ${_el} \ > ${_elink} \ > ${_em} \ > @@ -328,7 +328,6 @@ > _cpufreq= cpufreq > _digi= digi > _drm= drm > -_ed= ed > _elink= elink > _em= em > _ep= ep > > Thanks. > Does it work on big-endian machines? Scott From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 17:46:00 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1D8716A420 for ; Fri, 23 Dec 2005 17:46:00 +0000 (GMT) (envelope-from jrtanis@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF58E43D68 for ; Fri, 23 Dec 2005 17:45:59 +0000 (GMT) (envelope-from jrtanis@gmail.com) Received: by nproxy.gmail.com with SMTP id l37so243660nfc for ; Fri, 23 Dec 2005 09:45:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LQelLmRSjgm25W4K9c6e2q2MioLywLVoMJN7dNcYJcpccKWFU49ZRSzEAsQuQrL0FHUnVbs209Xhp+HjmdO59YWvRsiVQ9VHK4Dh9vydJS/MIXw5o1t8jLRG3Q8GL1NV+8El71OSARZhVwiYQQwshQReE6oqeylaZd5ulW33/60= Received: by 10.49.2.9 with SMTP id e9mr149764nfi; Fri, 23 Dec 2005 09:45:58 -0800 (PST) Received: by 10.48.216.10 with HTTP; Fri, 23 Dec 2005 09:45:58 -0800 (PST) Message-ID: <65dcde740512230945j11b1e3f9ied13a8129f568091@mail.gmail.com> Date: Fri, 23 Dec 2005 12:45:58 -0500 From: James Tanis Sender: jrtanis@gmail.com To: "Michael A. Koerber" In-Reply-To: <43ABF6E4.2090908@ll.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <43ABF6E4.2090908@ll.mit.edu> Cc: stable@freebsd.org, current@freebsd.org Subject: Re: SSH login takes very long time...sometimes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 17:46:00 -0000 For whatever reason, I have had a similar problem which was solved by entering the machines that you are logging in from into the hosts file. I'm guessing it attempts a reverse lookup and your (as well as my) dns/hostname does not match its reverse lookup entry. On 12/23/05, Michael A. Koerber wrote: > All, > > I have three machines that have had 5.4 and 6.0 installed. Two of the = three machines have very > well behaved "ssh". However, the machine (laptop) named OBOE does not. > > Specifically "ssh oboe" will (most of the time) hang for around one min= ute before asking for a > prompt. However, if I'm logged into OBOE and "ssh BSD" (one of the other= machines) a password is > requested within a couple seconds. (I said most of the time, since on oc= casion I can reboot OBOE > and ssh will work just fine...hmmm.) > > I have looked through the /var/log files for clues and skimmed "man ssh= " for time out related > stuff, but no luck. > > Where should I start looking for clues? > > All machines have had clean installs from "newfs'd" drive under both 5.= 4 and 6.0 so I'm sure no > left over configs are getting propagated. > -- > --------------------- > Dr Michael A. Koerber > x3250 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- James Tanis jtanis@pycoder.org http://pycoder.org From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 19:22:50 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8968216A41F; Fri, 23 Dec 2005 19:22:50 +0000 (GMT) (envelope-from sean@cyberwang.net) Received: from imf25aec.mail.bellsouth.net (imf25aec.mail.bellsouth.net [205.152.59.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3588543D5F; Fri, 23 Dec 2005 19:22:46 +0000 (GMT) (envelope-from sean@cyberwang.net) Received: from ibm69aec.bellsouth.net ([68.19.113.81]) by imf25aec.mail.bellsouth.net with ESMTP id <20051223192234.BHNI4211.imf25aec.mail.bellsouth.net@ibm69aec.bellsouth.net>; Fri, 23 Dec 2005 14:22:34 -0500 Received: from [192.168.10.100] (really [68.19.113.81]) by ibm69aec.bellsouth.net with ESMTP id <20051223192234.PQUJ10934.ibm69aec.bellsouth.net@[192.168.10.100]>; Fri, 23 Dec 2005 14:22:34 -0500 Message-ID: <43AC4E6D.4060107@cyberwang.net> Date: Fri, 23 Dec 2005 14:22:21 -0500 From: Sean Bryant User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Tanis References: <43ABF6E4.2090908@ll.mit.edu> <65dcde740512230945j11b1e3f9ied13a8129f568091@mail.gmail.com> In-Reply-To: <65dcde740512230945j11b1e3f9ied13a8129f568091@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: stable@freebsd.org, "Michael A. Koerber" , current@freebsd.org Subject: Re: SSH login takes very long time...sometimes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 19:22:50 -0000 James Tanis wrote: >For whatever reason, I have had a similar problem which was solved by >entering the machines that you are logging in from into the hosts >file. I'm guessing it attempts a reverse lookup and your (as well as >my) dns/hostname does not match its reverse lookup entry. > >On 12/23/05, Michael A. Koerber wrote: > > >>All, >> >> I have three machines that have had 5.4 and 6.0 installed. Two of the three machines have very >>well behaved "ssh". However, the machine (laptop) named OBOE does not. >> >> Specifically "ssh oboe" will (most of the time) hang for around one minute before asking for a >>prompt. However, if I'm logged into OBOE and "ssh BSD" (one of the other machines) a password is >>requested within a couple seconds. (I said most of the time, since on occasion I can reboot OBOE >>and ssh will work just fine...hmmm.) >> >> I have looked through the /var/log files for clues and skimmed "man ssh" for time out related >>stuff, but no luck. >> >> Where should I start looking for clues? >> >> All machines have had clean installs from "newfs'd" drive under both 5.4 and 6.0 so I'm sure no >>left over configs are getting propagated. >>-- >>--------------------- >>Dr Michael A. Koerber >>x3250 >>_______________________________________________ >>freebsd-stable@freebsd.org mailing list >>http://lists.freebsd.org/mailman/listinfo/freebsd-stable >>To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> >> >> > > >-- >James Tanis >jtanis@pycoder.org >http://pycoder.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" > > Try disabling sendmail. I don't remember exactly how I came up with this solution but I remember sendmail was the problem. This might work for you as well. From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 19:48:52 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CAE9216A420; Fri, 23 Dec 2005 19:48:52 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1FD3543D5E; Fri, 23 Dec 2005 19:48:52 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: by lh.synack.net (Postfix, from userid 100) id E83CA5E48ED; Fri, 23 Dec 2005 11:48:51 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 577A85E48B4; Fri, 23 Dec 2005 11:48:50 -0800 (PST) In-Reply-To: <43ABCBCF.8060500@freebsd.org> References: <43ABCBCF.8060500@freebsd.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Evans Date: Fri, 23 Dec 2005 11:48:47 -0800 To: David Xu X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: New malloc ready, take 42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 19:48:52 -0000 On Dec 23, 2005, at 2:05 AM, David Xu wrote: > > If I have linked " aj>>>>>>>" to /etc/malloc.conf for phkmalloc, the > super-smack get better result, on my Pentium-D 2.8Ghz machine, > before this set, the select-key.smack can only reach 19500 q_per_s, > after the set, it can reach 20791.33 q_per_s ! Was this a CURRENT system? If so, did you use the 'aj' flags when running the first test? By default, CURRENT has 'AJ' set, which means that junk filling is on unless you turn it off. Junk filling would cause approximately the performance difference you measured. Thanks, Jason From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 20:07:39 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28B9016A41F; Fri, 23 Dec 2005 20:07:39 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8251743D6A; Fri, 23 Dec 2005 20:07:36 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: by lh.synack.net (Postfix, from userid 100) id 5B8755E48B4; Fri, 23 Dec 2005 12:07:36 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 53BB55E48B4; Fri, 23 Dec 2005 12:07:35 -0800 (PST) In-Reply-To: <43ABD158.8080802@freebsd.org> References: <26940.1135332727@critter.freebsd.dk> <43ABD158.8080802@freebsd.org> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8326DD7F-9576-4D1F-8B3B-5FCD1BE135CC@freebsd.org> Content-Transfer-Encoding: quoted-printable From: Jason Evans Date: Fri, 23 Dec 2005 12:07:32 -0800 To: David Xu X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: Poul-Henning Kamp , freebsd-current@freebsd.org Subject: Re: New malloc ready, take 42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 20:07:39 -0000 On Dec 23, 2005, at 2:28 AM, David Xu wrote: > I know what '>' does in phkmalloc. I found 'Q', he replaced '>' with > 'Q', this is really strange to me. ;-) Actually, the closest analog to phkmalloc's '>' and '<' are 'C' and =20 'c'. However, they don't have quite the same meaning, so I thought =20 that changing the designators was appropriate. Here's a snippet from =20= the man page about some of the performance tuning flags supported by =20 jemalloc: C Increase/decrease the size of the cache by a factor of two. The default cache size is 256 objects for each arena. This option can be specified multiple times. N Increase/decrease the number of arenas by a factor of two. The default number of arenas is twice the number of CPUs, or one if there is a single CPU. This option can be specified multiple times. Q Increase/decrease the size of the allocation quantum by a factor of two. The default quantum is the minimum allowed by the archi- tecture (typically 8 or 16 bytes). This option can be specified multiple times. The implications of each of these flags is described in some detail =20 later in the man page: This allocator uses multiple arenas in order to reduce lock contention for threaded programs on multi-processor systems. This works well =20 with regard to threading scalability, but incurs some costs. There is a =20= small fixed per-arena overhead, and additionally, arenas manage memory com- pletely independently of each other, which means a small fixed =20 increase in overall memory fragmentation. These overheads aren't generally an issue, given the number of arenas normally used. Note that using sub- stantially more arenas than the default is not likely to improve =20 perfor- mance, mainly due to reduced cache performance. However, it may make sense to reduce the number of arenas if an application does not =20 make much use of the allocation functions. This allocator uses a novel approach to object caching. For objects below a size threshold (use the ``P'' option to discover the =20 threshold), full deallocation and attempted coalescence with adjacent memory =20 regions are delayed. This is so that if the application requests an =20 allocation of that size soon thereafter, the request can be met much more =20 quickly. Most applications heavily use a small number of object sizes, so this caching has the potential to have a large positive performance impact. However, the effectiveness of the cache depends on the cache being =20 large enough to absorb typical fluctuations in the number of allocated =20 objects. If an application routinely fluctuates by thousands of objects, =20 then it may make sense to increase the size of the cache. Conversely, if an application's memory usage fluctuates very little, it may make =20 sense to reduce the size of the cache, so that unused regions can be coalesced sooner. This allocator is very aggressive about tightly packing objects in =20 mem- ory, even for objects much larger than the system page size. For pro- grams that allocate objects larger than half the system page size, =20 this has the potential to reduce memory footprint in comparison to other =20= allo- cators. However, it has some side effects that are important to =20 keep in mind. First, even multi-page objects can start at non-page-aligned addresses, since the implementation only guarantees quantum alignment. Second, this tight packing of objects can cause objects to share L1 =20= cache lines, which can be a performance issue for multi-threaded =20 applications. There are two ways to approach these issues. First, p=08osix_memalign()= provides the ability to align allocations as needed. By aligning an allocation to at least the L1 cache line size, and padding the =20 allocation request by one L1 cache line unit, the programmer can rest assured =20 that no cache line sharing will occur for the object. Second, the ``Q'' =20 option can be used to force all allocations to be aligned with the L1 cache lines. This approach should be used with care though, because =20 although easy to implement, it means that all allocations must be at least as large as the quantum, which can cause severe internal fragmentation if the application allocates many small objects. Jason= From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 21:49:36 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1ACEF16A41F for ; Fri, 23 Dec 2005 21:49:36 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id A1F4543D5A for ; Fri, 23 Dec 2005 21:49:35 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jBNLmnB7070235; Fri, 23 Dec 2005 14:48:51 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 23 Dec 2005 14:48:51 -0700 (MST) Message-Id: <20051223.144851.74146497.imp@bsdimp.com> To: scottl@samsco.org From: "M. Warner Losh" In-Reply-To: <43AC32EC.7010609@samsco.org> References: <200512232214.21552.doconnor@gsoft.com.au> <43AC32EC.7010609@samsco.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 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 23 Dec 2005 14:48:55 -0700 (MST) Cc: freebsd-current@freebsd.org Subject: Re: if_ed on !i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 21:49:36 -0000 In message: <43AC32EC.7010609@samsco.org> Scott Long writes: : Daniel O'Connor wrote: : : > Is there any reason it is not built? : > : > It works on in amd64 under qemu (about the only time you're likely to find : > NE2000 hardware on amd64 I'd hope :) : > : > If there is no reason it isn't built by default can someone commit this patch? : > : > Index: modules/Makefile : > =================================================================== : > RCS file: /usr/local/ncvs/src/sys/modules/Makefile,v : > retrieving revision 1.450.2.8 : > diff -u -r1.450.2.8 Makefile : > --- modules/Makefile 1 Dec 2005 02:43:13 -0000 1.450.2.8 : > +++ modules/Makefile 23 Dec 2005 11:43:51 -0000 : > @@ -68,7 +68,7 @@ : > ${_dpt} \ : > ${_drm} \ : > dummynet \ : > - ${_ed} \ : > + ed \ : > ${_el} \ : > ${_elink} \ : > ${_em} \ : > @@ -328,7 +328,6 @@ : > _cpufreq= cpufreq : > _digi= digi : > _drm= drm : > -_ed= ed : > _elink= elink : > _em= em : > _ep= ep : > : > Thanks. : > : : Does it work on big-endian machines? I don't think anybody has tested a NE-2000 PCI card on sparc64 to know for sure. Warner From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 22:41:13 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F6AA16A41F for ; Fri, 23 Dec 2005 22:41:13 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81BD643D4C for ; Fri, 23 Dec 2005 22:41:12 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp132-74.lns2.adl2.internode.on.net [59.167.132.74]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id jBNMfARK056318 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sat, 24 Dec 2005 09:11:11 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: Scott Long Date: Sat, 24 Dec 2005 09:10:57 +1030 User-Agent: KMail/1.8.3 References: <200512232214.21552.doconnor@gsoft.com.au> <43AC32EC.7010609@samsco.org> In-Reply-To: <43AC32EC.7010609@samsco.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1228471.0yqHHFZ3B4"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200512240911.05850.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: freebsd-current@freebsd.org Subject: Re: if_ed on !i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 22:41:13 -0000 --nextPart1228471.0yqHHFZ3B4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sat, 24 Dec 2005 03:55, Scott Long wrote: > Does it work on big-endian machines? Aye, that's the rub :) I guess just adding it to the amd64 section is safer since I know that work= s. (Tested with qemu) =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 --nextPart1228471.0yqHHFZ3B4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDrH0B5ZPcIHs/zowRAmLoAJ9oiqputG5KurX+qkzh4Hgv0GQ7WACeNmb6 BMN/AbG2KbxhqYp5jA20rdU= =DgYf -----END PGP SIGNATURE----- --nextPart1228471.0yqHHFZ3B4-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 23 23:49:15 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9E0A16A41F for ; Fri, 23 Dec 2005 23:49:15 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id B248643D72 for ; Fri, 23 Dec 2005 23:49:07 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: by lh.synack.net (Postfix, from userid 100) id 8EFEA5E48D8; Fri, 23 Dec 2005 15:49:07 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id A053C5E48B4; Fri, 23 Dec 2005 15:49:04 -0800 (PST) In-Reply-To: <20051223094018.GA25562@soaustin.net> References: <20051223094018.GA25562@soaustin.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <69D03F43-D467-4AD2-92AB-378F5CF4C00F@freebsd.org> Content-Transfer-Encoding: 7bit From: Jason Evans Date: Fri, 23 Dec 2005 15:49:01 -0800 To: Mark Linimon X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: New malloc ready, take 42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2005 23:49:16 -0000 On Dec 23, 2005, at 1:40 AM, Mark Linimon wrote: > On Fri, Dec 23, 2005 at 01:14:08AM -0800, Jason Evans wrote: >> * Claus Guttesen and Devon O'Dell reported issues in kldxref and X on >> amd64 [ ... ] Apparently, we are on the cusp of the transition to >> using >> [latest xorg], so for now the workaround on amd64 is to use xorg- >> server- >> snap, with the expectation that soon the standard xorg-server port >> will be upgraded. > > I think it's fair to ask if anyone has attempted to find out if > there are > similar problems with XFree86 on either i386 or amd64. I don't > know if > there is any appreciable install base for the latter but AFAICT > there still > is for the former. > > At least we ought to know yea or nay before making the switch, IMHO. I just checked XFree86-4 on i386, and it works fine. I already returned the amd64 machine I was borrowing, so I can't check that. My expectation is that XFree86 has the same issue as xorg on amd64. Thanks, Jason From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 00:03:51 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D0BC16A41F; Sat, 24 Dec 2005 00:03:51 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0231A43D5D; Sat, 24 Dec 2005 00:03:50 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 427B83EAE; Fri, 23 Dec 2005 18:03:50 -0600 (CST) Date: Fri, 23 Dec 2005 18:03:50 -0600 To: Jason Evans Message-ID: <20051224000350.GA19888@soaustin.net> References: <20051223094018.GA25562@soaustin.net> <69D03F43-D467-4AD2-92AB-378F5CF4C00F@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69D03F43-D467-4AD2-92AB-378F5CF4C00F@freebsd.org> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Sat, 24 Dec 2005 00:09:41 +0000 Cc: Mark Linimon , freebsd-current@freebsd.org Subject: Re: New malloc ready, take 42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Dec 2005 00:03:51 -0000 On Fri, Dec 23, 2005 at 03:49:01PM -0800, Jason Evans wrote: > I just checked XFree86-4 on i386, and it works fine. I already > returned the amd64 machine I was borrowing, so I can't check that. > My expectation is that XFree86 has the same issue as xorg on amd64. Cool, thanks for checking. Any volunteers to try it on amd64? (No, sorry, I don't have one but I would take one :-) ) mcl From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 00:24:38 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 21A3616A41F; Sat, 24 Dec 2005 00:24:37 +0000 (GMT) (envelope-from davidxu@freebsd.org) Message-ID: <43AC957A.3010909@freebsd.org> Date: Sat, 24 Dec 2005 08:25:30 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.10) Gecko/20050806 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jason Evans References: <43ABCBCF.8060500@freebsd.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: New malloc ready, take 42 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Dec 2005 00:24:38 -0000 Jason Evans wrote: > > On Dec 23, 2005, at 2:05 AM, David Xu wrote: > >> >> If I have linked " aj>>>>>>>" to /etc/malloc.conf for phkmalloc, the >> super-smack get better result, on my Pentium-D 2.8Ghz machine, >> before this set, the select-key.smack can only reach 19500 q_per_s, >> after the set, it can reach 20791.33 q_per_s ! > > > Was this a CURRENT system? If so, did you use the 'aj' flags when > running the first test? By default, CURRENT has 'AJ' set, which > means that junk filling is on unless you turn it off. Junk filling > would cause approximately the performance difference you measured. > > Thanks, > Jason > > > Yes, with CURRENT, I think I didn't use 'aj' for first test. I will test it again when I am back to office, sorry. David Xu From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 00:40:01 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3D5916A41F for ; Sat, 24 Dec 2005 00:40:01 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id 887D043D55 for ; Sat, 24 Dec 2005 00:40:00 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: by lh.synack.net (Postfix, from userid 100) id 6BB8A5E48ED; Fri, 23 Dec 2005 16:40:00 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id E7A285E488C for ; Fri, 23 Dec 2005 16:39:58 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: <497D3FE0-BF69-4BFF-8C25-54C29F93D86D@freebsd.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: freebsd-current@freebsd.org From: Jason Evans Date: Fri, 23 Dec 2005 16:39:56 -0800 X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Subject: Malloc delay X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Dec 2005 00:40:02 -0000 I'm sorry to say that I just had a catastrophic hardware failure (electrostatic shock, followed by a short that blew the breaker switch), and all I have left running is a couple of Macs. I don't know how long this is going to set me back, but chances are that I won't have any usable hardware for at least a couple of weeks. The malloc code, which I was literally within minutes of starting to commit, is going to sit for a while. Sorry. Jason From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 05:00:21 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5811816A422; Sat, 24 Dec 2005 05:00:21 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA25643D5D; Sat, 24 Dec 2005 05:00:20 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.13.3/8.13.3/NinthNine) with ESMTP id jBO50Jmb008905; Sat, 24 Dec 2005 14:00:19 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sat, 24 Dec 2005 14:00:19 +0900 From: Norikatsu Shigemura To: kan@FreeBSD.org, freebsd-current@FreeBSD.org Message-Id: <20051224140019.d2311673.nork@FreeBSD.org> X-Mailer: Sylpheed version 2.2.0beta1 (GTK+ 2.8.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sakura.ninth-nine.com [219.127.74.121]); Sat, 24 Dec 2005 14:00:19 +0900 (JST) Cc: takawata@FreeBSD.org, nork@FreeBSD.org, ume@FreeBSD.org Subject: Can't resolve defined(?) symbol after ELF symbol versioning X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Dec 2005 05:00:21 -0000 Hi rtld masters! I'm restructuring linuxpluginwraapper by supporting ELF symbol versioning. I noticed that there are some problems. 1. I'll never try to support Flash6, and I'll support Flash7. Because Flash6 required some old(2.0.x) freetype2 functions. I tried to make a compat functions, and noticed that I cannot care these functions:-(. *NOTE* This isn't a issue caused by ELF symbol versioning. *NOTE* 2. "T" (the symbol is in the text (code) section) symbol cannot be resolved like following behavior. $ firefox /home/nork/Flash/AYB2.swf LoadPlugin: failed to initialize shared library /usr/X11R6/lib/linux-flashplugin7/libflashplayer.so [/usr/X11R6/lib/linux-flashplugin7/libflashplayer.so: Undefined symbol "_ZN12NetworkASyncD1Ev"] (NOTE)_ZN12NetworkASyncD1Ev = NetworkASync::~NetworkASync() $ nm -DC /usr/X11R6/lib/linux-flashplugin7/libflashplayer.so (snip) 000677e0 T NetworkASync::~NetworkASync() (snip) $ elfdump /usr/X11R6/lib/linux-flashplugin7/libflashplayer.so (snip) entry: 757 st_name: _ZN12NetworkASyncD1Ev st_value: 0x677e0 st_size: 33 st_info: STT_FUNC STB_GLOBAL st_shndx: 10 (snip) # I trying to test with $FreeBSD: src/libexec/rtld-elf/rtld.c,v 1.109 2005/12/18 19:43:32 kan Exp $ linux-flashplugin-7.0r61 FreeBSD nadesico.ninth-nine.com 7.0-CURRENT FreeBSD 7.0-CURRENT #68: Wed Dec 21 20:56:36 JST 2005 nork@nadesico.ninth-nine.com:/usr/obj/usr/src/sys/NADESICO i386 # New codes are in following place: http://people.freebsd.org/~nork/LinuxPluginWrapper.tar.bz2 (NOTE) Alpha-- quality codes, please cd LinuxPluginWrapper/wrappers/browser, and make all install. How about should I fix? From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 06:16:52 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3BBE16A41F for ; Sat, 24 Dec 2005 06:16:51 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20B1343D5A for ; Sat, 24 Dec 2005 06:16:51 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id jBO6FaCP073107; Fri, 23 Dec 2005 23:15:41 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Fri, 23 Dec 2005 23:15:39 -0700 (MST) Message-Id: <20051223.231539.93383283.imp@bsdimp.com> To: doconnor@gsoft.com.au From: "M. Warner Losh" In-Reply-To: <200512240911.05850.doconnor@gsoft.com.au> References: <200512232214.21552.doconnor@gsoft.com.au> <43AC32EC.7010609@samsco.org> <200512240911.05850.doconnor@gsoft.com.au> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 23 Dec 2005 23:15:46 -0700 (MST) Cc: freebsd-current@FreeBSD.org Subject: Re: if_ed on !i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Dec 2005 06:16:52 -0000 In message: <200512240911.05850.doconnor@gsoft.com.au> "Daniel O'Connor" writes: : On Sat, 24 Dec 2005 03:55, Scott Long wrote: : > Does it work on big-endian machines? : : Aye, that's the rub :) : : I guess just adding it to the amd64 section is safer since I know that works. : (Tested with qemu) Done! Warner From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 10:18:20 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1011F16A41F for ; Sat, 24 Dec 2005 10:18:20 +0000 (GMT) (envelope-from psionic@csh.rit.edu) Received: from blacksheep.csh.rit.edu (blacksheep.csh.rit.edu [129.21.60.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9DB9B43D60 for ; Sat, 24 Dec 2005 10:18:19 +0000 (GMT) (envelope-from psionic@csh.rit.edu) Received: from localhost (localhost [127.0.0.1]) by blacksheep.csh.rit.edu (Postfix) with ESMTP id 7AB6A260F for ; Sat, 24 Dec 2005 05:18:18 -0500 (EST) Received: from blacksheep.csh.rit.edu ([127.0.0.1]) by localhost (blacksheep.csh.rit.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 166020-06 for ; Sat, 24 Dec 2005 05:18:18 -0500 (EST) Received: from fury.csh.rit.edu (fury.csh.rit.edu [IPv6:2001:470:1f00:135:a00:20ff:fe8d:5399]) by blacksheep.csh.rit.edu (Postfix) with ESMTP id 423512434 for ; Sat, 24 Dec 2005 05:18:18 -0500 (EST) Received: from fury.csh.rit.edu (localhost [127.0.0.1]) by fury.csh.rit.edu (Postfix) with ESMTP id EA28A157E for ; Sat, 24 Dec 2005 05:18:17 -0500 (EST) From: Jordan Sissel To: freebsd-current@freebsd.org Date: Sat, 24 Dec 2005 05:18:17 -0500 Sender: psionic@csh.rit.edu Message-Id: <20051224101817.EA28A157E@fury.csh.rit.edu> X-Virus-Scanned: amavisd-new at csh.rit.edu Subject: Call for testers: New moused(8) and psm(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2005 10:18:20 -0000 Howdy, I've been working on a userland-ification of psm(4) and a complete rewrite of moused(8). The new psm(4) driver lacks protocol understanding and expects to be controlled through ioctls only. The new moused(8) is designed such that mouse drivers are in the userland. I have implemented 3 driver modules thus far: - Synaptics Touchpad (ps/2 only, not usb) - Generic PS/2 - sysmouse (for ums(4) and mse(4)) Development has been done in 6.x (I don't have a -current machine handy) but this will probably work fine in -current. Directions on what to do can be found on the project's site: http://www.csh.rit.edu/~psionic/projects/newpsm/ Comments/suggestions welcome :) -Jordan PS: I know most (all?) of the code doesn't conform to style(9). I'll fix that eventually. From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 12:43:08 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CBA6C16A41F; Sat, 24 Dec 2005 12:43:08 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from sakura.ninth-nine.com (sakura.ninth-nine.com [219.127.74.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0AE8C43D5D; Sat, 24 Dec 2005 12:43:07 +0000 (GMT) (envelope-from nork@FreeBSD.org) Received: from nadesico.ninth-nine.com (nadesico.ninth-nine.com [219.127.74.122]) by sakura.ninth-nine.com (8.13.3/8.13.3/NinthNine) with ESMTP id jBOCh6OC019973; Sat, 24 Dec 2005 21:43:06 +0900 (JST) (envelope-from nork@FreeBSD.org) Date: Sat, 24 Dec 2005 21:43:08 +0900 From: Norikatsu Shigemura To: kan@FreeBSD.org, freebsd-current@FreeBSD.org Message-Id: <20051224214308.fb94df1f.nork@FreeBSD.org> In-Reply-To: <20051224140019.d2311673.nork@FreeBSD.org> References: <20051224140019.d2311673.nork@FreeBSD.org> X-Mailer: Sylpheed version 2.2.0beta1 (GTK+ 2.8.9; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (sakura.ninth-nine.com [219.127.74.121]); Sat, 24 Dec 2005 21:43:06 +0900 (JST) Cc: takawata@FreeBSD.org, nork@FreeBSD.org, ume@FreeBSD.org Subject: Re: Can't resolve defined(?) symbol after ELF symbol versioning X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Dec 2005 12:43:08 -0000 On Sat, 24 Dec 2005 14:00:19 +0900 Norikatsu Shigemura wrote: > 2. "T" (the symbol is in the text (code) section) symbol > cannot be resolved like following behavior. > $ firefox /home/nork/Flash/AYB2.swf > LoadPlugin: failed to initialize shared library /usr/X11R6/lib/linux-flashplugin7/libflashplayer.so [/usr/X11R6/lib/linux-flashplugin7/libflashplayer.so: Undefined symbol "_ZN12NetworkASyncD1Ev"] Oops, case: new rtld.c $FreeBSD: src/libexec/rtld-elf/rtld.c,v 1.111 2005/12/23 15:30:53 kan Exp $ $ firefox /home/nork/Flash/maiyahi.swf LoadPlugin: failed to initialize shared library /usr/X11R6/lib/linux-flashplugin7/libflashplayer.so [/usr/local/lib/pluginwrapper/browser.so does not have version information, but /usr/X11R6/lib/linux-flashplugin7/libflashplayer.so requires it] I should study about ELF symbol versioning. From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 13:49:30 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C38A16A41F for ; Sat, 24 Dec 2005 13:49:30 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6031443D5F for ; Sat, 24 Dec 2005 13:49:25 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp132-74.lns2.adl2.internode.on.net [59.167.132.74]) (authenticated bits=0) by cain.gsoft.com.au (8.13.5/8.13.4) with ESMTP id jBODmbSi066554 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Sun, 25 Dec 2005 00:18:38 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: "M. Warner Losh" Date: Sun, 25 Dec 2005 00:18:21 +1030 User-Agent: KMail/1.8.3 References: <200512232214.21552.doconnor@gsoft.com.au> <200512240911.05850.doconnor@gsoft.com.au> <20051223.231539.93383283.imp@bsdimp.com> In-Reply-To: <20051223.231539.93383283.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart32441953.1jKKnu2cIO"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200512250018.35814.doconnor@gsoft.com.au> X-Spam-Score: 0 () X-Scanned-By: MIMEDefang 2.54 on 203.31.81.10 Cc: freebsd-current@freebsd.org Subject: Re: if_ed on !i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Dec 2005 13:49:30 -0000 --nextPart32441953.1jKKnu2cIO Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sat, 24 Dec 2005 16:45, M. Warner Losh wrote: > : I guess just adding it to the amd64 section is safer since I know that > : works. (Tested with qemu) > > Done! Thanks! =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 --nextPart32441953.1jKKnu2cIO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDrVGz5ZPcIHs/zowRAm5iAKCemOjCNFVoqZZvCm6IVHBRb4t/EgCfQYCm hdxQ8/ZYGq16oUBWgatxaZs= =8mHZ -----END PGP SIGNATURE----- --nextPart32441953.1jKKnu2cIO-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 15:32:27 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A494716A41F; Sat, 24 Dec 2005 15:32:27 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38F9143D45; Sat, 24 Dec 2005 15:32:27 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id C1C10E5; Sat, 24 Dec 2005 10:32:47 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 40B902DA2; Sat, 24 Dec 2005 10:32:42 -0500 (EST) Received: from lists by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EqBNa-00019v-Hz; Sat, 24 Dec 2005 15:32:18 +0000 Date: Sat, 24 Dec 2005 15:32:18 +0000 From: Brian Candler To: "Patrick M. Hausen" Message-ID: <20051224153218.GA4424@uk.tiscali.com> References: <200512231136.12471.doconnor@gsoft.com.au> <200512230851.jBN8pFVv060458@hugo10.ka.punkt.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200512230851.jBN8pFVv060458@hugo10.ka.punkt.de> User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org, freebsd-stable@freebsd.org, current , Jo Rhett Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Dec 2005 15:32:27 -0000 On Fri, Dec 23, 2005 at 09:51:15AM +0100, Patrick M. Hausen wrote: > Any suggestions for an alternative to NFS if your 'client' servers > are located "all over the world" and you want to installworld across > the Internet? I was planning to use NFS/TCP secured by IPSec transport > mode, but anything less complicated would be greatly appreciated ;-) > > Anyone using ggated/ggatec for that purpose? I think that would not work unless you had a second FreeBSD installation on the remote machine and rebooted into that while you were upgrading the first. That's because you can't safely modify a block filesystem while it's mounted by someone else (even read-only). You could try tunneling NFS/TCP through ssh port forwarding. Never tried it myself, and there may be some gotchas. Linux has an extremely neat solution for this (sshfs) but I don't know of anything comparable in the BSD world. sshfs uses 'Fuse', a plug-in architecture which allows filesystems to run in userland. I believe it makes an sftp connection to the remote host, and then exposes it as if it were a real filesystem. Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 16:00:49 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C476416A41F for ; Sat, 24 Dec 2005 16:00:49 +0000 (GMT) (envelope-from mph@echobase.hoth.dk) Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EAD643D7E for ; Sat, 24 Dec 2005 16:00:49 +0000 (GMT) (envelope-from mph@echobase.hoth.dk) Received: from echobase.hoth.dk (echobase.hoth.dk [80.62.210.27]) by pfepb.post.tele.dk (Postfix) with ESMTP id D755C5EE0A4 for ; Sat, 24 Dec 2005 17:00:47 +0100 (CET) Received: by echobase.hoth.dk (Postfix, from userid 1001) id 9BA9C19B3D; Sat, 24 Dec 2005 17:00:47 +0100 (CET) Date: Sat, 24 Dec 2005 17:00:47 +0100 From: "Martin P. Hansen" To: freebsd-current@freebsd.org Message-ID: <20051224160047.GA40553@echobase.hoth.dk> Mail-Followup-To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: if_dc.c causes page fault while in kernel mode; coredump; reproducible X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Dec 2005 16:00:50 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm currently experiencing periodic page faults with my FreeBSD when shutting down (power-down). I've experienced this behavior in 6.0-RELEASE (GENERIC) and in 6.0-STABLE (GENERIC) cvsup'ed 2005-12-22 14:19. Not beeing a kernelhacker myself I've come to the conclusion that something in the dc driver is freed to soon or perhaps a lock isn't held. It might have something to do with ACPI as the powerdown is close. I've got two crashdumps for 6.0-RELEASE and three for 6.0-STABLE and it seems to be reproducible. To reproduce I set up a machine to ping my FreeBSD box and tell the FreeBSD box ``shutdown -p now''. All suggestions are welcome. uname -a: FreeBSD mph 6.0-STABLE FreeBSD 6.0-STABLE #0: Thu Dec 22 13:38:15 CET 2005 mph@mph:/usr/obj/usr/src/sys/GENERIC i386 The crashdump header looks like this: Fatal trap 12: page fault while in kernel mode fault virtual address =3D 0x18 fault code =3D supervisor write, page not present instruction pointer =3D 0x20:0xc073d480 stack pointer =3D 0x28:0xd5865cb4 frame pointer =3D 0x28:0xd5865ccc 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 28 (irq17: pcm0 dc0) trap number =3D 12 panic: page fault The crash happens at 0xc073d480 is in dc_rxeof (/usr/src/sys/pci/if_dc.c:2779) 2774 * If we are on an architecture with alignment prob= lems, or 2775 * if the allocation fails, then use m_devget and l= eave the 2776 * existing buffer in the receive ring. 2777 */ 2778 if (dc_quick && dc_newbuf(sc, i, 1) =3D=3D 0) { 2779 m->m_pkthdr.rcvif =3D ifp; 2780 m->m_pkthdr.len =3D m->m_len =3D total_len; 2781 DC_INC(i, DC_RX_LIST_CNT); 2782 } else 2783 #endif (kgdb) print m $1 =3D (struct mbuf *) 0x0 (kgdb) print sc->dc_cdata.dc_rx_prod $2 =3D 43 Unread portion of the kernel message buffer: <118>Shutting down daemon processes: <118>. <118>Shutting down local daemons: <118>. <118>Writing entropy file: <118>. <118>Terminated <118>. <118>Dec 22 17:55:14 mph syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 1 1 0 0 0 done All buffers synced. Uptime: 3h34m52s --=20 Martin P. Hansen --SUOF0GtieIMvvwua Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDrXCvOxWv3QTcu8YRAsvmAJ9W1I03L/GNpWBFJizdpg1siEUr+ACeK+YO 6Yfsj8ecwWbezJoyLRYVMb4= =4Q09 -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 18:23:34 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1206816A41F for ; Sat, 24 Dec 2005 18:23:34 +0000 (GMT) (envelope-from delphij@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A53E43D58 for ; Sat, 24 Dec 2005 18:23:32 +0000 (GMT) (envelope-from delphij@gmail.com) Received: by zproxy.gmail.com with SMTP id 18so323470nzp for ; Sat, 24 Dec 2005 10:23:32 -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:content-disposition:references; b=kK58yZ74fCbl9qzbrb8meIpxsypk1qi3CqmB9W/Gtp7Nt/BAAuZp7TgRDtuypBaFZHyYFfZhPVL3QqLd+TIyK140Bg4/wbfbei8kxbd7szJtzzNWQ1sGZmlLVJpLC0DizUaPWdHE0musjXXqTmpc51IE1mYtlvy8r2OgyLdee7k= Received: by 10.64.199.7 with SMTP id w7mr2031255qbf; Sat, 24 Dec 2005 10:23:31 -0800 (PST) Received: by 10.65.72.5 with HTTP; Sat, 24 Dec 2005 10:23:31 -0800 (PST) Message-ID: Date: Sun, 25 Dec 2005 02:23:31 +0800 From: Xin LI To: freebsd-current@freebsd.org In-Reply-To: <20051224160047.GA40553@echobase.hoth.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline References: <20051224160047.GA40553@echobase.hoth.dk> Subject: Re: if_dc.c causes page fault while in kernel mode; coredump; reproducible X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: delphij@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Dec 2005 18:23:34 -0000 SGksIE1hcnRpbiwKCldvdWxkIHlvdSBwbGVhc2UgcHJvdmlkZSBvdXRwdXQgZnJvbSBHREIncyAi YnQgZnVsbCI/ICBUaGF0IHdvdWxkIGhlbHAKdXMgdG8gdHJhY2sgZG93biB0aGUgaXNzdWUuCgpD aGVlcnMsCi0tClhpbiBMSSA8ZGVscGhpakBkZWxwaGlqLm5ldD4gaHR0cDovL3d3dy5kZWxwaGlq Lm5ldAo= From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 21:02:41 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 004D816A41F for ; Sat, 24 Dec 2005 21:02:40 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from mailserver.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BE6F43D5C for ; Sat, 24 Dec 2005 21:02:40 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mailserver.sandvine.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 24 Dec 2005 16:01:36 -0500 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id 20CBC13660; Sat, 24 Dec 2005 16:02:39 -0500 (EST) Date: Sat, 24 Dec 2005 16:02:38 -0500 From: Ed Maste To: Brian Candler Message-ID: <20051224210238.GA72070@sandvine.com> References: <200512231136.12471.doconnor@gsoft.com.au> <200512230851.jBN8pFVv060458@hugo10.ka.punkt.de> <20051224153218.GA4424@uk.tiscali.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051224153218.GA4424@uk.tiscali.com> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 24 Dec 2005 21:01:36.0656 (UTC) FILETIME=[3A545100:01C608CD] Cc: "Patrick M. Hausen" , Jo Rhett , freebsd-current@freebsd.org Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Dec 2005 21:02:41 -0000 On Sat, Dec 24, 2005 at 03:32:18PM +0000, Brian Candler wrote: > Linux has an extremely neat solution for this (sshfs) but I don't know of > anything comparable in the BSD world. sshfs uses 'Fuse', a plug-in > architecture which allows filesystems to run in userland. I believe it makes > an sftp connection to the remote host, and then exposes it as if it were a > real filesystem. In fact, FreeBSD's got Fuse & sshfs as well. Csaba Henk did the port as a Google SoC project. See and /usr/ports/sysutils/fusefs* . -- Ed Maste Sandvine Incorporated From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 21:47:59 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 990B716A41F for ; Sat, 24 Dec 2005 21:47:59 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn.pobox.com (thorn.pobox.com [208.210.124.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 29E4543D4C for ; Sat, 24 Dec 2005 21:47:59 +0000 (GMT) (envelope-from b.candler@pobox.com) Received: from thorn (localhost [127.0.0.1]) by thorn.pobox.com (Postfix) with ESMTP id 79B35ED; Sat, 24 Dec 2005 16:48:20 -0500 (EST) Received: from mappit.local.linnet.org (212-74-113-67.static.dsl.as9105.com [212.74.113.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by thorn.sasl.smtp.pobox.com (Postfix) with ESMTP id 2193128FB; Sat, 24 Dec 2005 16:48:17 -0500 (EST) Received: from brian by mappit.local.linnet.org with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EqHF3-0001NO-R0; Sat, 24 Dec 2005 21:47:53 +0000 Date: Sat, 24 Dec 2005 21:47:53 +0000 From: Brian Candler To: Ed Maste Message-ID: <20051224214753.GA5253@uk.tiscali.com> References: <200512231136.12471.doconnor@gsoft.com.au> <200512230851.jBN8pFVv060458@hugo10.ka.punkt.de> <20051224153218.GA4424@uk.tiscali.com> <20051224210238.GA72070@sandvine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051224210238.GA72070@sandvine.com> User-Agent: Mutt/1.4.2.1i Cc: "Patrick M. Hausen" , Jo Rhett , freebsd-current@freebsd.org Subject: Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 ) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Dec 2005 21:47:59 -0000 On Sat, Dec 24, 2005 at 04:02:38PM -0500, Ed Maste wrote: > On Sat, Dec 24, 2005 at 03:32:18PM +0000, Brian Candler wrote: > > > Linux has an extremely neat solution for this (sshfs) but I don't know of > > anything comparable in the BSD world. sshfs uses 'Fuse', a plug-in > > architecture which allows filesystems to run in userland. I believe it makes > > an sftp connection to the remote host, and then exposes it as if it were a > > real filesystem. > > In fact, FreeBSD's got Fuse & sshfs as well. Csaba Henk did the port > as a Google SoC project. See and > /usr/ports/sysutils/fusefs* . Looks like very recent work. Thanks for the pointer - although it seems it's not available for FreeBSD <6.0 unfortunately. From owner-freebsd-current@FreeBSD.ORG Sat Dec 24 23:52:05 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 633AF16A41F for ; Sat, 24 Dec 2005 23:52:05 +0000 (GMT) (envelope-from mph@echobase.hoth.dk) Received: from pfepb.post.tele.dk (pfepb.post.tele.dk [195.41.46.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C95D43D58 for ; Sat, 24 Dec 2005 23:51:57 +0000 (GMT) (envelope-from mph@echobase.hoth.dk) Received: from echobase.hoth.dk (echobase.hoth.dk [80.62.210.27]) by pfepb.post.tele.dk (Postfix) with ESMTP id 4B61A5EE01D for ; Sun, 25 Dec 2005 00:51:54 +0100 (CET) Received: by echobase.hoth.dk (Postfix, from userid 1001) id 0E8EF19B3D; Sun, 25 Dec 2005 00:51:54 +0100 (CET) Date: Sun, 25 Dec 2005 00:51:53 +0100 From: "Martin P. Hansen" To: freebsd-current@freebsd.org Message-ID: <20051224235153.GA46187@echobase.hoth.dk> Mail-Followup-To: freebsd-current@freebsd.org References: <20051224160047.GA40553@echobase.hoth.dk> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7JfCtLOvnd9MIVvH" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Subject: Re: if_dc.c causes page fault while in kernel mode; coredump; reproducible X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Dec 2005 23:52:05 -0000 --7JfCtLOvnd9MIVvH Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, 25 Dec 2005, Xin LI wrote: > Would you please provide output from GDB's "bt full"? That would help > us to track down the issue. Sure, it got trimmed away in my attempt to balance the information. (kgdb) bt full #0 doadump () at pcpu.h:165 No locals. #1 0xc063a55e in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:3= 99 first_buf_printf =3D 1 #2 0xc063a7f4 in panic (fmt=3D0xc08539cc "%s") at /usr/src/sys/kern/kern_shutdown.c:555 td =3D (struct thread *) 0xc36db600 bootopt =3D 260 newpanic =3D 0 ap =3D 0xc36db600 "$\226m=C3" buf =3D "page fault", '\0' #3 0xc080b484 in trap_fatal (frame=3D0xd5865c74, eva=3D24) at /usr/src/sys/i386/i386/trap.c:836 code =3D 40 type =3D 12 ss =3D 40 esp =3D 0 softseg =3D {ssd_base =3D 0, ssd_limit =3D 1048575, ssd_type =3D 27= ,=20 ssd_dpl =3D 0, ssd_p =3D 1, ssd_xx =3D 6, ssd_xx1 =3D 1, ssd_def32 =3D 1,= ssd_gran =3D 1} msg =3D 0x0 #4 0xc080b1eb in trap_pfault (frame=3D0xd5865c74, usermode=3D0, eva=3D24) at /usr/src/sys/i386/i386/trap.c:744 va =3D 0 vm =3D (struct vmspace *) 0x0 map =3D 0xc0925ec0 rv =3D 1 ftype =3D 1 '\001' td =3D (struct thread *) 0xc36db600 p =3D (struct proc *) 0xc36d9624 #5 0xc080ae29 in trap (frame=3D {tf_fs =3D 8, tf_es =3D -1012793304, tf_ds =3D -1066205144, tf_edi = =3D -4, tf_esi =3D 16, tf_ebp =3D -712614708, tf_isp =3D -712614752, tf_ebx= =3D 0, tf_edx =3D -712183808, tf_ecx =3D 0, tf_eax =3D -1015383040, tf_tra= pno =3D 12, tf_err =3D 2, tf_eip =3D -1066150784, tf_cs =3D 32, tf_eflags = =3D 590406, tf_esp =3D -712183552, tf_ss =3D -1015383040}) at /usr/src/sys/i386/i386/trap.c:434 td =3D (struct thread *) 0xc36db600 p =3D (struct proc *) 0xc36d9624 sticks =3D 406607872 i =3D 0 ucode =3D 0 type =3D 12 code =3D 2 eva =3D 24 #6 0xc07fa5da in calltrap () at /usr/src/sys/i386/i386/exception.s:139 No locals. #7 0xc073d480 in dc_rxeof (sc=3D0xc379c000) at /usr/src/sys/pci/if_dc.c:27= 79 m =3D (struct mbuf *) 0x0 ifp =3D (struct ifnet *) 0xc37a7c00 cur_rx =3D (struct dc_desc *) 0xd58cf100 i =3D 16 total_len =3D -4 rxstat =3D 0 #8 0xc073dbbe in dc_intr (arg=3D0xc379c000) at /usr/src/sys/pci/if_dc.c:31= 42 curpkts =3D 11281 sc =3D (struct dc_softc *) 0xc379c000 ifp =3D (struct ifnet *) 0xc37a7c00 status =3D 4026532162 #9 0xc06260f5 in ithread_loop (arg=3D0xc367f480) at /usr/src/sys/kern/kern_intr.c:547 ithd =3D (struct ithd *) 0xc367f480 ih =3D (struct intrhand *) 0xc3809400 td =3D (struct thread *) 0xc36db600 p =3D (struct proc *) 0xc36d9624 count =3D 0 warned =3D 0 #10 0xc062537c in fork_exit (callout=3D0xc0625f9c ,=20 arg=3D0xc367f480, frame=3D0xd5865d38) at /usr/src/sys/kern/kern_fork.c:= 789 p =3D (struct proc *) 0xc36d9624 td =3D (struct thread *) 0xd58cf000 #11 0xc07fa63c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:= 208 No locals. (kgdb) --=20 Martin P. Hansen --7JfCtLOvnd9MIVvH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFDrd8ZOxWv3QTcu8YRAnI4AJ4sTwgikC5UL1WG8dNLcIg+0Vxo8wCeKfhX QRLk4G8NcEnUttY0xx1zBnk= =I2H0 -----END PGP SIGNATURE----- --7JfCtLOvnd9MIVvH--