From owner-freebsd-current@FreeBSD.ORG Sun Dec 17 10:36:47 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D32E316A504 for ; Sun, 17 Dec 2006 10:36:47 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id 1445543C9D for ; Sun, 17 Dec 2006 10:36:46 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 11535 invoked by uid 399); 17 Dec 2006 10:36:48 -0000 Received: from localhost (HELO ?192.168.0.5?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 17 Dec 2006 10:36:48 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <45851DBC.9010604@FreeBSD.org> Date: Sun, 17 Dec 2006 02:36:44 -0800 From: Doug Barton Organization: http://www.freebsd.org/ User-Agent: Thunderbird 1.5.0.8 (X11/20061215) MIME-Version: 1.0 To: Per olof Ljungmark References: <4579EB08.8080704@intersonic.se> <20061210.230622.-1844001233.imp@bsdimp.com> <45845F8B.3060304@intersonic.se> In-Reply-To: <45845F8B.3060304@intersonic.se> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG, "M. Warner Losh" Subject: Re: Am I an Idiot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Dec 2006 10:36:47 -0000 Per olof Ljungmark wrote: > Thank you all for the input. After some consideration I've decided to go > ahead so I'm currently preparing and testing a -CURRENT system for > production use, after all, there is nothing like real life :-) Thank you for taking this on! This is exactly the kind of testing today's -current needs to be the best possible -stable for tomorrow. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sun Dec 17 10:52:00 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1194B16A403; Sun, 17 Dec 2006 10:52:00 +0000 (UTC) (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 ACCF743C9D; Sun, 17 Dec 2006 10:51:59 +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.6/8.13.6) with ESMTP id kBHApw4c098262; Sun, 17 Dec 2006 05:51:58 -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.8/8.13.8) with ESMTP id kBHApw8v089369; Sun, 17 Dec 2006 05:51:58 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 9019273034; Sun, 17 Dec 2006 05:51:58 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061217105158.9019273034@freebsd-current.sentex.ca> Date: Sun, 17 Dec 2006 05:51:58 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner3 X-Virus-Status: Clean 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, 17 Dec 2006 10:52:00 -0000 TB --- 2006-12-17 09:15:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-17 09:15:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-12-17 09:15:00 - cleaning the object tree TB --- 2006-12-17 09:15:47 - checking out the source tree TB --- 2006-12-17 09:15:47 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-12-17 09:15:47 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-17 09:25:02 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-17 09:25:02 - cd /src TB --- 2006-12-17 09:25:02 - /usr/bin/make -B buildworld >>> World build started on Sun Dec 17 09:25:04 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun Dec 17 10:40:00 UTC 2006 TB --- 2006-12-17 10:40:00 - generating LINT kernel config TB --- 2006-12-17 10:40:00 - cd /src/sys/amd64/conf TB --- 2006-12-17 10:40:00 - /usr/bin/make -B LINT TB --- 2006-12-17 10:40:00 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-17 10:40:00 - cd /src TB --- 2006-12-17 10:40:00 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Dec 17 10:40:01 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/amd64/amd64/uio_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/amd64/amd64/uma_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/amd64/amd64/vm_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/amd64/isa/atpic.c /src/sys/amd64/isa/atpic.c:498: error: conflicting types for 'atpic_handle_intr' /src/sys/amd64/isa/icu.h:46: error: previous declaration of 'atpic_handle_intr' was here /src/sys/amd64/isa/atpic.c:498: error: conflicting types for 'atpic_handle_intr' /src/sys/amd64/isa/icu.h:46: error: previous declaration of 'atpic_handle_intr' was here *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-17 10:51:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-17 10:51:58 - ERROR: failed to build lint kernel TB --- 2006-12-17 10:51:58 - tinderbox aborted TB --- 0.82 user 3.50 system 5818.10 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Dec 17 14:50:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BEF5316A40F for ; Sun, 17 Dec 2006 14:50:27 +0000 (UTC) (envelope-from uspoerlein@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8563343CA3 for ; Sun, 17 Dec 2006 14:50:26 +0000 (GMT) (envelope-from uspoerlein@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so1117347uge for ; Sun, 17 Dec 2006 06:50:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:mail-followup-to:references:mime-version:content-type:content-disposition:in-reply-to; b=cSRZDIEpJef7dDWVDgN7Y5oh6GSw/aIwj1674R6l8n7lsuF0F9HUUvrzOSctfQHQ+PVbRy+ow4Rm8uuTTH3C9Th0kYJQzJrXk070t2aYOkZ7U13FPFFIeopNFm7j2L5c/hHSz+zTdN3sp5wX36UiMc/8XYT6zxaesvfrwKSJB+I= Received: by 10.67.19.13 with SMTP id w13mr3475366ugi.1166367025174; Sun, 17 Dec 2006 06:50:25 -0800 (PST) Received: from roadrunner.aventurien.local ( [84.149.91.73]) by mx.google.com with ESMTP id b23sm7648028ugd.2006.12.17.06.50.23; Sun, 17 Dec 2006 06:50:24 -0800 (PST) Received: from roadrunner.aventurien.local (localhost [127.0.0.1]) by roadrunner (8.13.8/8.13.8) with ESMTP id kBHEoFv1002215; Sun, 17 Dec 2006 15:50:15 +0100 (CET) (envelope-from uspoerlein@gmail.com) Received: (from q@localhost) by roadrunner (8.13.8/8.13.8/Submit) id kBHEjPgP002026; Sun, 17 Dec 2006 15:45:25 +0100 (CET) (envelope-from uspoerlein@gmail.com) Date: Sun, 17 Dec 2006 15:44:25 +0100 From: Ulrich Spoerlein To: obrien@freebsd.org, Stefan Ehmann , freebsd-current@freebsd.org, Peter Jeremy , Steve Kargl Message-ID: <20061217144425.GA1463@roadrunner.aventurien.local> Mail-Followup-To: obrien@freebsd.org, Stefan Ehmann , freebsd-current@freebsd.org, Peter Jeremy , Steve Kargl References: <20061213192150.CF83D16A417@hub.freebsd.org> <458235EC.80300@samsco.org> <200612151250.10033.shoesoft@gmx.net> <200612151914.53705.shoesoft@gmx.net> <20061215205138.GB55276@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061215205138.GB55276@dragon.NUXI.org> Cc: Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Dec 2006 14:50:27 -0000 David O'Brien wrote: > On Fri, Dec 15, 2006 at 07:14:53PM +0100, Stefan Ehmann wrote: > > > CPU: AMD Athlon(TM) XP 2700+ (2166.44-MHz 686-class CPU) > .. > > Settings/Compiler | gcc-3.4 | gcc-4.1 | gcc-4.2 > > ----------------------------+---------+---------+--------- > > -O2 | 6.46s | 6.67s | 6.38s > > -O2 -funroll-loops | 4.44s | 4.16s | 4.02s > > -O2 -march=athlon-xp -fun.. | 4.39s | 4.38s | 4.26s > > -O3 | 6.14s | 5.23s | 5.16s > > -O3 -funroll-loops | 4.24s | 4.87s | 4.95s > > -O3 -march=athlon-xp -fun.. | 4.19s | 4.90s | 5.07s > > A fine example that -O3 isn't always better than -O2. > I wonder if you're blowing the L2 cache. IIRC, all Athlon XP 2700+ > are the Thoughbread core, which has only 256KB L2. I'd be very much interested in -Os numbers. It should help with the cache ... Ulrich Spoerlein -- A: Yes. >Q: Are you sure? > >A: Because it reverses the logical flow of conversation. > >>Q: Why is top posting frowned upon? From owner-freebsd-current@FreeBSD.ORG Sun Dec 17 15:39:42 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 11D7916A407; Sun, 17 Dec 2006 15:39:42 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00CFC43D45; Sun, 17 Dec 2006 15:39:15 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id kBHFdE5f030121; Sun, 17 Dec 2006 18:39:14 +0300 (MSK) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id kBHFdEgn030120; Sun, 17 Dec 2006 18:39:14 +0300 (MSK) (envelope-from ache) Date: Sun, 17 Dec 2006 18:39:14 +0300 From: Andrey Chernov To: Robert Watson Message-ID: <20061217153914.GA30048@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Robert Watson , current@FreeBSD.org References: <20061216055903.GA2712@nagual.pp.ru> <20061216111656.GA7501@nagual.pp.ru> <20061216112117.P72986@fledge.watson.org> <20061216114426.GA7735@nagual.pp.ru> <20061216120746.E72986@fledge.watson.org> <20061216125136.GA1094@nagual.pp.ru> <20061216125419.J72986@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061216125419.J72986@fledge.watson.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@FreeBSD.org Subject: Re: sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in -current) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Dec 2006 15:39:42 -0000 On Sat, Dec 16, 2006 at 01:00:56PM +0000, Robert Watson wrote: > As I said, this is something that I hope to revisit in the next few days. > However, it would be helpful if you could tell me the arguments and call > path to the ipcperm() function instance that's generating the improper > failure. It could be that both a bug in ipcperm() and a big in shmget() This is kernel debug running test from t-shm.c which fails (from root). Is it what you need? acc_mode 0x1b0 owner obj_mode 0x9b0 dac_granted 0x1180 priv_granted 0x0 EACCES -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Sun Dec 17 16:07:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7567F16A416 for ; Sun, 17 Dec 2006 16:07:26 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5921843CA5 for ; Sun, 17 Dec 2006 16:07:25 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so1126749uge for ; Sun, 17 Dec 2006 08:07: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:references; b=RpDkaq9TnzcHz6Kdo84A2cl8ffND9HH9a6hUabBmL/UA/7ZdpkgmKN7fqBeEM6dPM6MWoJuyH4p8oEXglWJdAAsL2lZbe36NRspCAHP++PxFQW1+r4Thq8C4F+WXSRKoWgARsKVevSGLFGANd2C2H2p9XzrkcjcJW5p/wzAM+1w= Received: by 10.78.149.15 with SMTP id w15mr2169601hud.1166371643677; Sun, 17 Dec 2006 08:07:23 -0800 (PST) Received: by 10.78.31.7 with HTTP; Sun, 17 Dec 2006 08:07:23 -0800 (PST) Message-ID: <2fd864e0612170807x20ff699x42538cfa497c1398@mail.gmail.com> Date: Sun, 17 Dec 2006 10:07:23 -0600 From: Astrodog To: freebsd-current@freebsd.org In-Reply-To: <45851DBC.9010604@FreeBSD.org> MIME-Version: 1.0 References: <4579EB08.8080704@intersonic.se> <20061210.230622.-1844001233.imp@bsdimp.com> <45845F8B.3060304@intersonic.se> <45851DBC.9010604@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Am I an Idiot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Dec 2006 16:07:26 -0000 Something that, in my opinion, may have been missed in all of this, Why, exactly, do you want to run -CURRENT in production? As others have said above, its certainly possible to do. I've done it before myself, but always because of a specific feature, or bit of supported hardware, that didn't exist in -STABLE. Running -CURRENT is quite a bit more work than running -STABLE. The fact that a -CURRENT kernel and world can build and run on a test system, does little to indicate what type of performance, and stability you will see in a production environment. Many of the problems that may exist in -CURRENT will be induced by specific types of load. Race conditions, Lock Order Reversal, and certain driver issues in many cases, only appear under particularly heavy loads, or particular types of load. What this means, simply, is that when you test the next version of -CURRENT you'd like to run, there's quite a bit of testing you'll have to do. Along side this type of problem, is the issue of security. If you are running -CURRENT as of 2 weeks ago, and a security vulnerability is discovered, in some cases, you will be compelled to upgrade to the latest -CURRENT, even if it has known stability problems, or performance/functionality regression. None of this should be construed to imply that -CURRENT cannot be run in production, only that you really should have a compelling reason to do so... or at the very least, quite a bit of free time. --- Harrison Grundy From owner-freebsd-current@FreeBSD.ORG Sun Dec 17 16:11:05 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1062A16A403 for ; Sun, 17 Dec 2006 16:11:05 +0000 (UTC) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 7E38143CB2 for ; Sun, 17 Dec 2006 16:10:57 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 17 Dec 2006 16:10:55 -0000 Received: from h081217095052.dyn.cm.kabsi.at (EHLO taxman.pepperland) [81.217.95.52] by mail.gmx.net (mp010) with SMTP; 17 Dec 2006 17:10:55 +0100 X-Authenticated: #16703784 From: Stefan Ehmann To: freebsd-current@freebsd.org Date: Sun, 17 Dec 2006 17:10:53 +0100 User-Agent: KMail/1.9.4 References: <20061213192150.CF83D16A417@hub.freebsd.org> <20061215205138.GB55276@dragon.NUXI.org> <20061217144425.GA1463@roadrunner.aventurien.local> In-Reply-To: <20061217144425.GA1463@roadrunner.aventurien.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612171710.55134.shoesoft@gmx.net> X-Y-GMX-Trusted: 0 Cc: Peter Jeremy , Steve Kargl Subject: Re: Let's use gcc-4.2, not 4.1 -- OpenMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Dec 2006 16:11:05 -0000 On Sunday 17 December 2006 15:44, Ulrich Spoerlein wrote: > David O'Brien wrote: > > On Fri, Dec 15, 2006 at 07:14:53PM +0100, Stefan Ehmann wrote: > > > > CPU: AMD Athlon(TM) XP 2700+ (2166.44-MHz 686-class CPU) > > > > .. > > > > > Settings/Compiler | gcc-3.4 | gcc-4.1 | gcc-4.2 > > > ----------------------------+---------+---------+--------- > > > -O2 | 6.46s | 6.67s | 6.38s > > > -O2 -funroll-loops | 4.44s | 4.16s | 4.02s > > > -O2 -march=athlon-xp -fun.. | 4.39s | 4.38s | 4.26s > > > -O3 | 6.14s | 5.23s | 5.16s > > > -O3 -funroll-loops | 4.24s | 4.87s | 4.95s > > > -O3 -march=athlon-xp -fun.. | 4.19s | 4.90s | 5.07s > > > > A fine example that -O3 isn't always better than -O2. > > I wonder if you're blowing the L2 cache. IIRC, all Athlon XP 2700+ > > are the Thoughbread core, which has only 256KB L2. > > I'd be very much interested in -Os numbers. It should help with the > cache ... While -Os -funroll-loops seems a weird combination: Settings/Compiler | gcc-3.4 | gcc-4.1 | gcc-4.2 ----------------------------+---------+---------+--------- -Os | 6.96s | 6.48s | 6.69s -Os -funroll-loops | 5.01s | 4.63s | 4.58s -Os -march=athlon-xp -fun | 4.93s | 4.69s | 4.64s We probably should stop exploiting my simple test or perform it properly if there's really any interest (e.g. larger number of programs, different CPUs, something better than time(1); also my computer was up to 0.05s slower than on Friday :-)) Also, for most "normal" programs, there won't be that much difference between compilers and/or settings. From owner-freebsd-current@FreeBSD.ORG Sun Dec 17 17:12:16 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40AEA16A403; Sun, 17 Dec 2006 17:12:16 +0000 (UTC) (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 8777F43CAC; Sun, 17 Dec 2006 17:12:15 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBHHCEkN025730; Sun, 17 Dec 2006 12:12:14 -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.8/8.13.8) with ESMTP id kBHHCEBm010043; Sun, 17 Dec 2006 12:12:14 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8013C73034; Sun, 17 Dec 2006 12:12:14 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061217171214.8013C73034@freebsd-current.sentex.ca> Date: Sun, 17 Dec 2006 12:12:14 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner2 X-Virus-Status: Clean 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, 17 Dec 2006 17:12:16 -0000 TB --- 2006-12-17 15:35:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-17 15:35:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-12-17 15:35:00 - cleaning the object tree TB --- 2006-12-17 15:35:39 - checking out the source tree TB --- 2006-12-17 15:35:39 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-12-17 15:35:39 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-17 15:44:57 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-17 15:44:57 - cd /src TB --- 2006-12-17 15:44:57 - /usr/bin/make -B buildworld >>> World build started on Sun Dec 17 15:44:59 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun Dec 17 17:00:36 UTC 2006 TB --- 2006-12-17 17:00:36 - generating LINT kernel config TB --- 2006-12-17 17:00:36 - cd /src/sys/amd64/conf TB --- 2006-12-17 17:00:36 - /usr/bin/make -B LINT TB --- 2006-12-17 17:00:36 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-17 17:00:36 - cd /src TB --- 2006-12-17 17:00:36 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Dec 17 17:00:36 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/amd64/amd64/uio_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/amd64/amd64/uma_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/amd64/amd64/vm_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/amd64/isa/atpic.c /src/sys/amd64/isa/atpic.c:498: error: conflicting types for 'atpic_handle_intr' /src/sys/amd64/isa/icu.h:46: error: previous declaration of 'atpic_handle_intr' was here /src/sys/amd64/isa/atpic.c:498: error: conflicting types for 'atpic_handle_intr' /src/sys/amd64/isa/icu.h:46: error: previous declaration of 'atpic_handle_intr' was here *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-17 17:12:14 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-17 17:12:14 - ERROR: failed to build lint kernel TB --- 2006-12-17 17:12:14 - tinderbox aborted TB --- 0.80 user 2.77 system 5833.38 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Dec 17 17:39:56 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E366E16A4D2 for ; Sun, 17 Dec 2006 17:39:55 +0000 (UTC) (envelope-from freebsd@alaskaparadise.com) Received: from stargate.alaskaparadise.com (114-103-74-65.gci.net [65.74.103.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0DBA43CC0 for ; Sun, 17 Dec 2006 17:39:54 +0000 (GMT) (envelope-from freebsd@alaskaparadise.com) Received: from localhost (localhost [127.0.0.1]) by stargate.alaskaparadise.com (Postfix) with ESMTP id 2A8044214; Sun, 17 Dec 2006 08:39:54 -0900 (AKST) From: Beech Rintoul Organization: Alaska Paradise Travel To: freebsd-current@freebsd.org Date: Sun, 17 Dec 2006 08:39:32 -0900 User-Agent: KMail/1.9.4 References: <4579EB08.8080704@intersonic.se> <45851DBC.9010604@FreeBSD.org> <2fd864e0612170807x20ff699x42538cfa497c1398@mail.gmail.com> In-Reply-To: <2fd864e0612170807x20ff699x42538cfa497c1398@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart15981463.5oATKVL1Lg"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612170839.50597.freebsd@alaskaparadise.com> Cc: Astrodog Subject: Re: Am I an Idiot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Dec 2006 17:39:56 -0000 --nextPart15981463.5oATKVL1Lg Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 17 December 2006 07:07, Astrodog wrote: > Something that, in my opinion, may have been missed in all of this, > > Why, exactly, do you want to run -CURRENT in production? As others have > said above, its certainly possible to do. I've done it before myself, but > always because of a specific feature, or bit of supported hardware, that > didn't exist in -STABLE. > > Running -CURRENT is quite a bit more work than running -STABLE. The fact > that a -CURRENT kernel and world can build and run on a test system, does > little to indicate what type of performance, and stability you will see in > a production environment. Many of the problems that may exist in -CURRENT > will be induced by specific types of load. Race conditions, Lock Order > Reversal, and certain driver issues in many cases, only appear under > particularly heavy loads, or particular types of load. > What this means, simply, is that when you test the next version of -CURRE= NT > you'd like to run, there's quite a bit of testing you'll have to do. Along > side this type of problem, is the issue of security. If you are running > -CURRENT as of 2 weeks ago, and a security vulnerability is discovered, in > some cases, you will be compelled to upgrade to the latest -CURRENT, even > if it has known stability problems, or performance/functionality > regression. > > None of this should be construed to imply that -CURRENT cannot be run in > production, only that you really should have a compelling reason to do > so... or at the very least, quite a bit of free time. I agree with astrodog. I've been running FreeBSD since the first versions. = I=20 do run -CURRENT on my home machine, but I run 6-STABLE on my office servers= =2E=20 When you run -CURRENT you become a beta or worse an alpha tester. While I'm= =20 sure the development team would welcome your input, -CURRENT is NOT intende= d=20 for production environments. I have dealt with many serious bugs in -CURREN= T=20 over the years up to the point where it sometimes wouldn't boot at all. Whi= le=20 this is rare, it can jump up and bite you. Sometimes downloading sources an= =20 hour later makes the difference between boot/no-boot. If you do decide to=20 run -CURRENT you should be prepared to do a lot of your own troubleshooting= =20 before posting to the list. Also, you should not blindly upgrade your serve= r.=20 You should try new versions on a test machine with similar hardware before= =20 updating your production server. While -CURRENT seems to be relatively stab= le=20 right now, It's no guarantee it will remain that way. Astrodog was right in= =20 saying be prepared to spend a LOT of time, you most certainly will. Beech =2D-=20 =2D------------------------------------------------------------------------= =2D------------- Beech Rintoul - Sys. Administrator - beech@alaskaparadise.com /"\ ASCII Ribbon Campaign | Alaska Paradise Travel \ / - NO HTML/RTF in e-mail | 201 East 9Th Avenue Ste.310 X - NO Word docs in e-mail | Anchorage, AK 99501 / \ - Please visit Alaska Paradise - http://www.alaskaparadise.com =2D------------------------------------------------------------------------= =2D------------- --nextPart15981463.5oATKVL1Lg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFhYDmR5sEeCt9j00RAvFQAJ9xt7Stu1HWcP5wAg+wansFK207ywCgoWoo bErgtHmgjH/pdRZhzojyTMY= =UiaF -----END PGP SIGNATURE----- --nextPart15981463.5oATKVL1Lg-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 17 20:46:36 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE6B816A415 for ; Sun, 17 Dec 2006 20:46:36 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id B530143CB8 for ; Sun, 17 Dec 2006 20:46:30 +0000 (GMT) (envelope-from infofarmer@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so1162315uge for ; Sun, 17 Dec 2006 12:46:25 -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:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=iRmjW//JjssuSacfAVJ24WqSnHAYcsYh0yPnag/9cji91Fi+Ls+NBKJ8NV/4qECvXucQqy8h9ARSp4bmf49KkrCofzJaC/x21bYocYrGcs40zdqU6kD4bBzvcEc3T48fOjHMc4LSLpxZ75HgUQL3dXaeBPt8R6loQ9KLhowqD0Q= Received: by 10.78.203.13 with SMTP id a13mr1577138hug.1166388384293; Sun, 17 Dec 2006 12:46:24 -0800 (PST) Received: by 10.78.167.16 with HTTP; Sun, 17 Dec 2006 12:46:24 -0800 (PST) Message-ID: Date: Sun, 17 Dec 2006 23:46:24 +0300 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: 6b01e422fffd46e1 Cc: David Xu Subject: vge(4) bad checksum X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Dec 2006 20:46:36 -0000 I'm not sure what it's all about, but with today's current whatever goes out my vge interface (icmp/ tcp/udp) has bad checksum: 23:35:59.786960 IP (tos 0x0, ttl 64, id 2287, offset 0, flags [none], proto: UDP (17), length: 66, bad cksum 0 (->ce25)!) 192.168.17.69.55929 > 192.168.17.1.161: [bad udp cksum 944b!] { SNMPv2c C=asdf { GetNextRequest(25) R=431960954 .1.3.6.1.2.1 } } 23:36:11.866766 IP (tos 0x0, ttl 64, id 2300, offset 0, flags [none], proto: ICMP (1), length: 84, bad cksum 0 (->ce16)!) 192.168.17.69 > 192.168.17.1: ICMP echo request, id 39684, seq 1, length 64 23:36:58.918191 IP (tos 0x10, ttl 64, id 2327, offset 0, flags [DF], proto: TCP (6), length: 52, bad cksum 0 (->8e06)!) 192.168.17.69.53243 > 192.168.17.1.41319: ., cksum 0xa3bd (incorrect (-> 0x6f3b), 512:512(0) ack 513 win 33304 I switched from ipsec(4) to fast_ipsec(4). My last kernel is from December 10 and everything seems to be ok. More testing pending... From owner-freebsd-current@FreeBSD.ORG Sun Dec 17 20:52:58 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BDA5316A407; Sun, 17 Dec 2006 20:52:58 +0000 (UTC) (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 78BBC43CBD; Sun, 17 Dec 2006 20:52:53 +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 A71861A3C1C; Sun, 17 Dec 2006 12:52:52 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 9DAEA512EA; Sun, 17 Dec 2006 15:52:49 -0500 (EST) Date: Sun, 17 Dec 2006 15:52:49 -0500 From: Kris Kennaway To: Andrew Pantyukhin Message-ID: <20061217205249.GA73132@xor.obsecurity.org> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Ckj6UjgE2iN1+kY" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Cc: current@freebsd.org, David Xu Subject: Re: vge(4) bad checksum X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Dec 2006 20:52:58 -0000 --4Ckj6UjgE2iN1+kY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Sun, Dec 17, 2006 at 11:46:24PM +0300, Andrew Pantyukhin wrote: > I'm not sure what it's all about, but with today's > current whatever goes out my vge interface (icmp/ > tcp/udp) has bad checksum: This is a FAQ; it's probably using hardware checksum offloading. Since the packet passed down to the NIC does not yet have the checksum computed, it looks to tcpdump like the checksum is incorrect. However if you look at the packet actually transmitted by the NIC (e.g. tcpdump on another host), you'll see that it has the correct checksum. Kris --4Ckj6UjgE2iN1+kY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFha4hWry0BWjoQKURAkPDAKDv6DDEkCGdSi+Hq/RVdTedthSfjACgvVQW Yd27Rb3UV1qeJtEtnwk3Z/g= =OnaB -----END PGP SIGNATURE----- --4Ckj6UjgE2iN1+kY-- From owner-freebsd-current@FreeBSD.ORG Sun Dec 17 21:08:59 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 363D316A412 for ; Sun, 17 Dec 2006 21:08:59 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id 541DB43C9F for ; Sun, 17 Dec 2006 21:08:58 +0000 (GMT) (envelope-from infofarmer@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so1165416uge for ; Sun, 17 Dec 2006 13:08: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:x-google-sender-auth; b=koJbayokd4ShX4GecFq5MEnXeB4C1i055PYuQozxj07hLMJYW3CC89E4L/MA9p8WmHjsfCQoEuvvrRw03wovCU9LouMyhLINPZy1br0XgqgN2v9gMx2t2OWJGaL3cfI/MIg/zXlVnIRKJoW6lqQyzxwHlRGP4qxjzoMjwwkC43I= Received: by 10.78.57.11 with SMTP id f11mr1700266hua.1166389736926; Sun, 17 Dec 2006 13:08:56 -0800 (PST) Received: by 10.78.167.16 with HTTP; Sun, 17 Dec 2006 13:08:56 -0800 (PST) Message-ID: Date: Mon, 18 Dec 2006 00:08:56 +0300 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: "Kris Kennaway" In-Reply-To: <20061217205249.GA73132@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061217205249.GA73132@xor.obsecurity.org> X-Google-Sender-Auth: d25e7543e78450d0 Cc: current@freebsd.org, David Xu Subject: Re: vge(4) bad checksum X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Dec 2006 21:08:59 -0000 On 12/17/06, Kris Kennaway wrote: > On Sun, Dec 17, 2006 at 11:46:24PM +0300, Andrew Pantyukhin wrote: > > I'm not sure what it's all about, but with today's > > current whatever goes out my vge interface (icmp/ > > tcp/udp) has bad checksum: > > This is a FAQ; it's probably using hardware checksum offloading. > > Since the packet passed down to the NIC does not yet have the checksum > computed, it looks to tcpdump like the checksum is incorrect. However > if you look at the packet actually transmitted by the NIC > (e.g. tcpdump on another host), you'll see that it has the correct > checksum. I wouldn't even notice the checksum issue if my ipsec connection to another host hadn't stop working. The host has ipsec(4) and a re(4) interface. dmesg on the box showed issues with AH checksums. The problem is whenever I run tcpdump (promiscuous or not) on re(4), the box (amd64 current) drops to kernel debugger with messages like: panic: mutex Giant not owned at /usr/src/sys/net/bpf.c:1399 But that's another story. So I guess my fast_ipsec/vge/checksum problem is either fast_ipsec or fast_ipsec+vge bound. Again, there was no problem with 20061210-current+ipsec+vge (not fast_ipsec). From owner-freebsd-current@FreeBSD.ORG Sun Dec 17 21:21:51 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ADFF016A40F for ; Sun, 17 Dec 2006 21:21:51 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id D32FF43CB1 for ; Sun, 17 Dec 2006 21:21:50 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 22388 invoked by uid 399); 17 Dec 2006 21:21:58 -0000 Received: from localhost (HELO ?192.168.0.5?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 17 Dec 2006 21:21:58 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <4585B4EC.1070906@FreeBSD.org> Date: Sun, 17 Dec 2006 13:21:48 -0800 From: Doug Barton Organization: http://www.freebsd.org/ User-Agent: Thunderbird 1.5.0.8 (X11/20061215) MIME-Version: 1.0 To: Astrodog References: <4579EB08.8080704@intersonic.se> <20061210.230622.-1844001233.imp@bsdimp.com> <45845F8B.3060304@intersonic.se> <45851DBC.9010604@FreeBSD.org> <2fd864e0612170807x20ff699x42538cfa497c1398@mail.gmail.com> In-Reply-To: <2fd864e0612170807x20ff699x42538cfa497c1398@mail.gmail.com> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Am I an Idiot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Dec 2006 21:21:51 -0000 Astrodog wrote: > Something that, in my opinion, may have been missed in all of this, > It hasn't been missed. It's been said over and over again. > Why, exactly, do you want to run -CURRENT in production? If you had actually read this thread, you'd know the answer to that. > Running -CURRENT is quite a bit more work than running -STABLE. The OP has stated repeatedly that he knows this, and is willing to do the work as long as time is available. > Many of the > problems that may exist in -CURRENT will be induced by specific > types of load. Race conditions, Lock Order Reversal, and certain > driver issues in many cases, only appear under particularly heavy > loads, or particular types of load. What this means, simply, is > that when you test the next version of -CURRENT you'd like to run, > there's quite a bit of testing you'll have to do. And this exact testing is what we need from the user base if we're going to make this thing work. It's ok if _you_ don't want to do it (really, it is), but please stop trying to discourage someone who has said repeatedly that he knows what he is signing up for. > Along side this > type of problem, is the issue of security. If you are running > -CURRENT as of 2 weeks ago, and a security vulnerability is > discovered, in some cases, you will be compelled to upgrade to the > latest -CURRENT, even if it has known stability problems, or > performance/functionality regression. Um, that's just bollocks. If the only way you know how to update a system is buildworld, you really should not be giving someone advice on system administration. Enough is enough already. This thread pole-vaulted past its useful lifetime ages ago, let's let it die. Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sun Dec 17 21:58:17 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1079E16A4C8 for ; Sun, 17 Dec 2006 21:58:17 +0000 (UTC) (envelope-from nate@root.org) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4BD2743F28 for ; Sun, 17 Dec 2006 21:47:42 +0000 (GMT) (envelope-from nate@root.org) Received: (qmail 71931 invoked from network); 17 Dec 2006 21:47:43 -0000 Received: from ppp-71-139-31-204.dsl.snfc21.pacbell.net (HELO ?10.0.5.59?) (nate-mail@71.139.31.204) by root.org with ESMTPA; 17 Dec 2006 21:47:43 -0000 Message-ID: <4585BAF3.1010504@root.org> Date: Sun, 17 Dec 2006 13:47:31 -0800 From: Nate Lawson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Stepan Zastupov References: <20061214234849.GA1062@stepan.ispsystem.net> <4584708B.3020902@root.org> <20061217214408.GA902@stepan.ispsystem.net> In-Reply-To: <20061217214408.GA902@stepan.ispsystem.net> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: cbb hangs during suspend if ath card active X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Dec 2006 21:58:18 -0000 Stepan Zastupov wrote: > On Sat, Dec 16, 2006 at 02:17:47PM -0800, Nate Lawson wrote: >> Stepan Zastupov wrote: >>> Does anyone still work on this problem? >>> (http://lists.freebsd.org/pipermail/freebsd-current/2006-July/064550.html) >>> I incure the same problems. If need testing I can help with it. >> Just comment out this line in ath_stop() in if_ath.c: >> // ath_hal_setpower(sc->sc_ah, HAL_PM_FULL_SLEEP); > It is already commented out in current and doesn't help. Card wont work > even if it inserted after suspend and resume. > That's something different then. I was talking about the suspend process hanging if the card is inserted and active. But ejecting it would allow the process to continue and after resume, re-inserting it worked fine. -- Nate From owner-freebsd-current@FreeBSD.ORG Sun Dec 17 21:59:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F89C16A513 for ; Sun, 17 Dec 2006 21:59:31 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC4E3442BF for ; Sun, 17 Dec 2006 21:55:36 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so1171180uge for ; Sun, 17 Dec 2006 13:55:28 -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:references; b=S3bP73yrXNQTadL1Oh+5YNvHSIpiAjOS6s6VVAfoK2o/s4fkvg+X6Vw8g1gn6iBqO/uOZABDBSsdl6U5EGtfqoAzf0ksiy/i2mQoLpQT+hPOTdl1N9E/7d3WBNBGC3GbSfjZo9Tipy4E4Z+CSSf+VxKaoyPPPVHOZ3FLUufV8K8= Received: by 10.78.170.17 with SMTP id s17mr2443301hue.1166392528117; Sun, 17 Dec 2006 13:55:28 -0800 (PST) Received: by 10.78.31.7 with HTTP; Sun, 17 Dec 2006 13:55:28 -0800 (PST) Message-ID: <2fd864e0612171355u1183779ds2eb2086442e13da6@mail.gmail.com> Date: Sun, 17 Dec 2006 15:55:28 -0600 From: Astrodog To: "Doug Barton" In-Reply-To: <4585B4EC.1070906@FreeBSD.org> MIME-Version: 1.0 References: <4579EB08.8080704@intersonic.se> <20061210.230622.-1844001233.imp@bsdimp.com> <45845F8B.3060304@intersonic.se> <45851DBC.9010604@FreeBSD.org> <2fd864e0612170807x20ff699x42538cfa497c1398@mail.gmail.com> <4585B4EC.1070906@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Am I an Idiot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Dec 2006 21:59:31 -0000 On 12/17/06, Doug Barton wrote: > > Astrodog wrote: > > Something that, in my opinion, may have been missed in all of this, > > > It hasn't been missed. It's been said over and over again. > > > Why, exactly, do you want to run -CURRENT in production? > > If you had actually read this thread, you'd know the answer to that. "It just works better on our fileserver than 6.x does on our production systems" is not a reason. Its an anecdote, that because of the vast differences in load between a fileserver, and a database, webserver, or mailserver, is not particularily valuable. > Running -CURRENT is quite a bit more work than running -STABLE. > > The OP has stated repeatedly that he knows this, and is willing to do > the work as long as time is available. > > > Many of the > > problems that may exist in -CURRENT will be induced by specific > > types of load. Race conditions, Lock Order Reversal, and certain > > driver issues in many cases, only appear under particularly heavy > > loads, or particular types of load. What this means, simply, is > > that when you test the next version of -CURRENT you'd like to run, > > there's quite a bit of testing you'll have to do. > > And this exact testing is what we need from the user base if we're > going to make this thing work. It's ok if _you_ don't want to do it > (really, it is), but please stop trying to discourage someone who has > said repeatedly that he knows what he is signing up for. This isn't testing, though. Since he's removing all of the debugging options, he can only help with 2 things. Either it works, or it doesn't, and he can point out significant performance problems. The kind of testing needed in -CURRENT is controlled, in my opinion. Just look at the PR database, and mailing lists for "Cannot Reproduce". A production system will rarely have an environment that is easily recreated, when someone goes to fix the problem. Understand, that I'm not trying to discourage him, just make sure he's clearly aware of what he's getting into. Everyone seems to be glossing over some important details. > Along side this > > type of problem, is the issue of security. If you are running > > -CURRENT as of 2 weeks ago, and a security vulnerability is > > discovered, in some cases, you will be compelled to upgrade to the > > latest -CURRENT, even if it has known stability problems, or > > performance/functionality regression. > > Um, that's just bollocks. If the only way you know how to update a > system is buildworld, you really should not be giving someone advice > on system administration. There is no other *acceptable* way to upgrade a -CURRENT system every time, as any other method will have undefined results. It might work, but no testing whatsoever is performed on it with any regularity. While its possible to do this with other methods, it will be specific to what needs to be updated. At which point, his system no longer runs -CURRENT, and may run into a crop of bugs that no one will be able to recreate, or even patch for. Enough is enough already. This thread pole-vaulted past its useful > lifetime ages ago, let's let it die. I'm wondering if it might be benificial to put something together for people who are considering -CURRENT on production. I'll send it off list if I come up with something. --- Harrison Grundy From owner-freebsd-current@FreeBSD.ORG Sun Dec 17 22:28:16 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88DA516A47B for ; Sun, 17 Dec 2006 22:28:16 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from mail2.fluidhosting.com (mx21.fluidhosting.com [204.14.89.4]) by mx1.FreeBSD.org (Postfix) with SMTP id D9B9343D7F for ; Sun, 17 Dec 2006 22:22:25 +0000 (GMT) (envelope-from dougb@FreeBSD.org) Received: (qmail 18115 invoked by uid 399); 17 Dec 2006 22:22:34 -0000 Received: from localhost (HELO ?192.168.0.5?) (dougb@dougbarton.us@127.0.0.1) by localhost with SMTP; 17 Dec 2006 22:22:34 -0000 X-Originating-IP: 127.0.0.1 Message-ID: <4585C31F.5040804@FreeBSD.org> Date: Sun, 17 Dec 2006 14:22:23 -0800 From: Doug Barton Organization: http://www.freebsd.org/ User-Agent: Thunderbird 1.5.0.8 (X11/20061215) MIME-Version: 1.0 To: Astrodog References: <4579EB08.8080704@intersonic.se> <20061210.230622.-1844001233.imp@bsdimp.com> <45845F8B.3060304@intersonic.se> <45851DBC.9010604@FreeBSD.org> <2fd864e0612170807x20ff699x42538cfa497c1398@mail.gmail.com> <4585B4EC.1070906@FreeBSD.org> <2fd864e0612171355u1183779ds2eb2086442e13da6@mail.gmail.com> In-Reply-To: <2fd864e0612171355u1183779ds2eb2086442e13da6@mail.gmail.com> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Am I an Idiot? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 17 Dec 2006 22:28:16 -0000 Astrodog wrote: > The kind of testing needed in -CURRENT is controlled, in my opinion. You are, of course, welcome to your opinions. You will, of course, please make allowances for the facts that, A) You might be wrong, and B) Even if you are right within some limited sphere, your knowledge and experience only extend so far, and others who have different knowledge and/or experience may not find them useful. For example, as a FreeBSD developer I am always quite gratified when people run my -current code in a real world environment, since I find anecdotes useful. Of course I'd always rather hear, "It works!" but even if the answer is that it doesn't work, it gives me a direction to look in that I didn't have before. So let me summarize. Yes, there are potential problems with running -current in production. As I said very early in this thread, the safest way of doing so is to run -current on a limited number of systems, and have -stable hardware ready to swap in if needed. The OP says he understands the issues at hand, and is willing to jump into the deep end of the pool. He seems like a grown-up to me, let's leave him alone and move on to other things, shall we? Doug -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sun Dec 17 23:26:32 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 450A116A403; Sun, 17 Dec 2006 23:26:32 +0000 (UTC) (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 E622C43CB9; Sun, 17 Dec 2006 23:26:31 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBHNQVQn052700; Sun, 17 Dec 2006 18:26:31 -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.8/8.13.8) with ESMTP id kBHNQVU5009047; Sun, 17 Dec 2006 18:26:31 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2523773034; Sun, 17 Dec 2006 18:26:31 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061217232631.2523773034@freebsd-current.sentex.ca> Date: Sun, 17 Dec 2006 18:26:31 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner4 X-Virus-Status: Clean 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, 17 Dec 2006 23:26:32 -0000 TB --- 2006-12-17 21:50:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-17 21:50:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-12-17 21:50:00 - cleaning the object tree TB --- 2006-12-17 21:50:41 - checking out the source tree TB --- 2006-12-17 21:50:41 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-12-17 21:50:41 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-17 21:59:45 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-17 21:59:45 - cd /src TB --- 2006-12-17 21:59:45 - /usr/bin/make -B buildworld >>> World build started on Sun Dec 17 21:59:46 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Sun Dec 17 23:14:48 UTC 2006 TB --- 2006-12-17 23:14:48 - generating LINT kernel config TB --- 2006-12-17 23:14:48 - cd /src/sys/amd64/conf TB --- 2006-12-17 23:14:48 - /usr/bin/make -B LINT TB --- 2006-12-17 23:14:48 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-17 23:14:48 - cd /src TB --- 2006-12-17 23:14:48 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Dec 17 23:14:48 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/amd64/amd64/uio_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/amd64/amd64/uma_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/amd64/amd64/vm_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/amd64/isa/atpic.c /src/sys/amd64/isa/atpic.c:498: error: conflicting types for 'atpic_handle_intr' /src/sys/amd64/isa/icu.h:46: error: previous declaration of 'atpic_handle_intr' was here /src/sys/amd64/isa/atpic.c:498: error: conflicting types for 'atpic_handle_intr' /src/sys/amd64/isa/icu.h:46: error: previous declaration of 'atpic_handle_intr' was here *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-17 23:26:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-17 23:26:30 - ERROR: failed to build lint kernel TB --- 2006-12-17 23:26:30 - tinderbox aborted TB --- 0.70 user 2.90 system 5790.15 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Sun Dec 17 21:50:07 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7F3816A407 for ; Sun, 17 Dec 2006 21:50:07 +0000 (UTC) (envelope-from redchrom@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AD61442DA for ; Sun, 17 Dec 2006 21:43:55 +0000 (GMT) (envelope-from redchrom@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so1659556nfc for ; Sun, 17 Dec 2006 13:43:42 -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:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:x-useless-header; b=fQjtkNrB6+vY221+GLiEszzhINREGiyZ3tE7Fg8hlwVuXdlJCw6q8IExmo4xxsUADQCis85zoBiGZbMXJkxJvS3hd9WnzLliyL/qIkj3ffEL3zYUlf6POqmSJrmZk9oiA3Q9mERqCTULR8xAf0fTDPG/fKGbgWEYz/y0w3x89J0= Received: by 10.48.210.20 with SMTP id i20mr6477086nfg.1166391822401; Sun, 17 Dec 2006 13:43:42 -0800 (PST) Received: from localhost ( [82.146.37.133]) by mx.google.com with ESMTP id b1sm24731521nfe.2006.12.17.13.43.40; Sun, 17 Dec 2006 13:43:42 -0800 (PST) Date: Mon, 18 Dec 2006 05:44:08 +0800 From: Stepan Zastupov To: Nate Lawson Message-ID: <20061217214408.GA902@stepan.ispsystem.net> References: <20061214234849.GA1062@stepan.ispsystem.net> <4584708B.3020902@root.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4584708B.3020902@root.org> User-Agent: Mutt/1.4.2.2i X-Useless-Header: They killed Kenny! THOSE BASTARDS! X-Mailman-Approved-At: Mon, 18 Dec 2006 01:15:59 +0000 Cc: Stepan Zastupov , freebsd-current@freebsd.org Subject: Re: cbb hangs during suspend if ath card active X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stepan Zastupov List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Dec 2006 21:50:07 -0000 On Sat, Dec 16, 2006 at 02:17:47PM -0800, Nate Lawson wrote: > Stepan Zastupov wrote: > >Does anyone still work on this problem? > >(http://lists.freebsd.org/pipermail/freebsd-current/2006-July/064550.html) > >I incure the same problems. If need testing I can help with it. > > Just comment out this line in ath_stop() in if_ath.c: > // ath_hal_setpower(sc->sc_ah, HAL_PM_FULL_SLEEP); > > -- > Nate It is already commented out in current and doesn't help. Card wont work even if it inserted after suspend and resume. -- Best regards, Stepan Zastupov aka RedChrom ISPSystem From owner-freebsd-current@FreeBSD.ORG Mon Dec 18 02:41:48 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 78CE416A40F for ; Mon, 18 Dec 2006 02:41:48 +0000 (UTC) (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 8AD0243CA2 for ; Mon, 18 Dec 2006 02:41:47 +0000 (GMT) (envelope-from sam@errno.com) Received: from [10.0.0.200] ([10.0.0.200]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id kBI26rd0075480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Dec 2006 18:06:54 -0800 (PST) (envelope-from sam@errno.com) Message-ID: <4585F7BB.9010704@errno.com> Date: Sun, 17 Dec 2006 18:06:51 -0800 From: Sam Leffler Organization: Errno Consulting User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Nate Lawson References: <20061214234849.GA1062@stepan.ispsystem.net> <4584708B.3020902@root.org> <20061217214408.GA902@stepan.ispsystem.net> <4585BAF3.1010504@root.org> In-Reply-To: <4585BAF3.1010504@root.org> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stepan Zastupov , freebsd-current@freebsd.org Subject: Re: cbb hangs during suspend if ath card active X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2006 02:41:48 -0000 Nate Lawson wrote: > Stepan Zastupov wrote: >> On Sat, Dec 16, 2006 at 02:17:47PM -0800, Nate Lawson wrote: >>> Stepan Zastupov wrote: >>>> Does anyone still work on this problem? >>>> (http://lists.freebsd.org/pipermail/freebsd-current/2006-July/064550.html) >>>> >>>> I incure the same problems. If need testing I can help with it. >>> Just comment out this line in ath_stop() in if_ath.c: >>> // ath_hal_setpower(sc->sc_ah, HAL_PM_FULL_SLEEP); > >> It is already commented out in current and doesn't help. Card wont work >> even if it inserted after suspend and resume. >> > > That's something different then. I was talking about the suspend > process hanging if the card is inserted and active. But ejecting it > would allow the process to continue and after resume, re-inserting it > worked fine. > What Nate is referring to is that on many ath parts if you "power down" the MAC then any pci references to registers outside the PCI clock domain will hang the bus. Not putting the chip in "full sleep" is a hack as it means it'll continue to draw full power after the interface is marked down. Something is causing the driver to be entered and registers accessed when not intended/expected. I haven't been able to make this happen on any of my laptops (most have ACPI problems s.t. suspend/resume doesn't work right) so haven't had a test case to debug--and noone with the problem has been able to provide the needed info. Sam From owner-freebsd-current@FreeBSD.ORG Mon Dec 18 07:42:40 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 738BA16A412; Mon, 18 Dec 2006 07:42:40 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mrout1.yahoo.com (mrout1.yahoo.com [216.145.54.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id D084743CCC; Mon, 18 Dec 2006 07:42:32 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout1.yahoo.com (8.13.6/8.13.6/y.out) with ESMTP id kBI7W2qU052085; Sun, 17 Dec 2006 23:32:02 -0800 (PST) Date: Mon, 18 Dec 2006 11:51:22 +0900 Message-ID: From: gnn@freebsd.org To: "Andrew Pantyukhin" In-Reply-To: References: <20061217205249.GA73132@xor.obsecurity.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/22.0.90 (i386-apple-darwin8.8.1) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: David Xu , current@freebsd.org, Kris Kennaway Subject: Re: vge(4) bad checksum X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2006 07:42:40 -0000 At Mon, 18 Dec 2006 00:08:56 +0300, Andrew Pantyukhin wrote: > I wouldn't even notice the checksum issue if my ipsec > connection to another host hadn't stop working. The > host has ipsec(4) and a re(4) interface. dmesg on the > box showed issues with AH checksums. The problem is > whenever I run tcpdump (promiscuous or not) on re(4), > the box (amd64 current) drops to kernel debugger with > messages like: > panic: mutex Giant not owned at /usr/src/sys/net/bpf.c:1399 > But that's another story. > > So I guess my fast_ipsec/vge/checksum problem is either > fast_ipsec or fast_ipsec+vge bound. Again, there was no > problem with 20061210-current+ipsec+vge (not fast_ipsec). Hi, If you can get tcpdump output on both side of the connection I would appreciate a PR being filed on this and asssigned to me (gnn) since I'm currently in the guts of FAST_IPSEC. Thanks, George From owner-freebsd-current@FreeBSD.ORG Mon Dec 18 14:56:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2682B16A40F for ; Mon, 18 Dec 2006 14:56:23 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 84D2E43CA2 for ; Mon, 18 Dec 2006 14:56:22 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from localhost (tarsier.geekcn.org [210.51.165.229]) by tarsier.geekcn.org (Postfix) with ESMTP id 948C4EB1660 for ; Mon, 18 Dec 2006 22:27:21 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([210.51.165.229]) by localhost (mail.geekcn.org [210.51.165.229]) (amavisd-new, port 10024) with ESMTP id 0PlXgFm19SR1 for ; Mon, 18 Dec 2006 22:27:14 +0800 (CST) Received: from [192.168.1.32] (unknown [221.222.206.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 81D6CEB107E for ; Mon, 18 Dec 2006 22:27:14 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:organization:user-agent:mime-version:to: subject:x-enigmail-version:content-type; b=r/wUK+J5P4Bwo9oWGyrAUpNvO7AxrRJVV1cp+pvJAO+LJb5Wii20E4mEZbwFUzeqT NdhXZ8pBpYHdjcGVtLcHQ== Message-ID: <4586A50C.7000900@delphij.net> Date: Mon, 18 Dec 2006 22:26:20 +0800 From: LI Xin Organization: The FreeBSD Project User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: freebsd-current@freebsd.org X-Enigmail-Version: 0.94.1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="------------enig26AC5EE4E37A0973D6A3A04B" Subject: Call for testers: aac(4) driver update from vendor X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2006 14:56:23 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig26AC5EE4E37A0973D6A3A04B Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I would like to hear feedbacks about a potential merge from vendor update for our aac(4) driver. This update adds the following hardware support to aac(4): Adaptec RAID ASR5800 Adaptec RAID ASR5805 Adaptec RAID ASR5808 Adaptec SAS RAID 1800SAS Adaptec SAS RAID 2400SAS Adaptec SAS RAID 3400SAS Adaptec SAS RAID 3800SAS Adaptec SAS RAID 3805SAS IBM ServeRAID 8s ICP ICP5045AL SAS RAID ICP ICP5045AU SAS RAID ICP ICP5085AU SAS RAID ICP ICP5445AU SAS RAID ICP ICP9067MA SATA RAID If you have to use the vendor supplied driver in the past, please test this one to make sure whether your hardware is get properly probed. Note: In this version, "Adaptec SATA RAID 2610SA" which has same ID of a HP branded one, was removed by the vendor. Because I do not have one at hand I am not sure whether this makes some difference (according to the code I think the HP branded one would have higher priority, though, therefore the driver does not really support it in the previous versions I think). Please let me know if the patch has caused any breakages. The patch is located at: http://people.freebsd.org/~delphij/for_review/patch-aac-vendor-b11518 Thanks in advance! Cheers, --=20 Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! --------------enig26AC5EE4E37A0973D6A3A04B 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.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFhqUMOfuToMruuMARA0HPAJ9YCB/ED1GjtM6x2qF4+rFzs/8yJQCeNX+G 7Kmosu8smn3v7QBCk8s55rI= =daHk -----END PGP SIGNATURE----- --------------enig26AC5EE4E37A0973D6A3A04B-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 18 16:25:24 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E815A16A407 for ; Mon, 18 Dec 2006 16:25:24 +0000 (UTC) (envelope-from cokane@mail.cokane.org) Received: from ms-smtp-05.texas.rr.com (ms-smtp-05.texas.rr.com [24.93.47.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3774B43CA4 for ; Mon, 18 Dec 2006 16:25:24 +0000 (GMT) (envelope-from cokane@mail.cokane.org) Received: from ramen.cokane.org (rrcs-24-153-184-158.sw.biz.rr.com [24.153.184.158]) by ms-smtp-05.texas.rr.com (8.13.6/8.13.6) with SMTP id kBIFdDu8023390 for ; Mon, 18 Dec 2006 09:39:14 -0600 (CST) Received: (qmail 6918 invoked by uid 1001); 18 Dec 2006 15:39:06 -0000 Date: Mon, 18 Dec 2006 15:39:06 +0000 From: Coleman Kane To: freebsd-current@freebsd.org Message-ID: <20061218153906.GA6910@ramen.coleyandcheryl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: UFS_GJOURNAL and ufs.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2006 16:25:25 -0000 Hello, I have noticed (since adding UFS journal support) that the UFS_GJOURNAL option hasn't been added to the ufs.ko kernel module. I've been using this (out of an effort to test as much as possible as KLDs) and every time I upgrade my kernel I must manually add -DUFS_GJOURNAL to the CFLAGS line in its Makefile. Is there any specific reason why this can't be committed? So far, my experience with GJOURNAL has been great testing it both with journal+fs on the same device as well as on two seperate devices. It looks like an oversight to me, but I don't want to jump the gun on it if there is some reasonable argument to keep it out "by default". -- Coleman Kane From owner-freebsd-current@FreeBSD.ORG Mon Dec 18 17:11:14 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 42BC716A403; Mon, 18 Dec 2006 17:11:14 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (grnl-static-02-0046.dsl.iowatelecom.net [69.66.56.110]) by mx1.FreeBSD.org (Postfix) with ESMTP id D29B943CA3; Mon, 18 Dec 2006 17:11:06 +0000 (GMT) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.13.8/8.13.8) with ESMTP id kBIGaDqb086360; Mon, 18 Dec 2006 10:36:13 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.13.8/8.13.8/Submit) id kBIGaDij086359; Mon, 18 Dec 2006 10:36:13 -0600 (CST) (envelope-from brooks) Date: Mon, 18 Dec 2006 10:36:13 -0600 From: Brooks Davis To: Coleman Kane Message-ID: <20061218163613.GA86127@lor.one-eyed-alien.net> References: <20061218153906.GA6910@ramen.coleyandcheryl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <20061218153906.GA6910@ramen.coleyandcheryl> User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: UFS_GJOURNAL and ufs.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2006 17:11:14 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 18, 2006 at 03:39:06PM +0000, Coleman Kane wrote: > Hello, >=20 > I have noticed (since adding UFS journal support) that the > UFS_GJOURNAL option hasn't been added to the ufs.ko kernel > module. I've been using this (out of an effort to test as > much as possible as KLDs) and every time I upgrade my kernel > I must manually add -DUFS_GJOURNAL to the CFLAGS line in > its Makefile. >=20 > Is there any specific reason why this can't be committed? > So far, my experience with GJOURNAL has been great testing > it both with journal+fs on the same device as well as on > two seperate devices. >=20 > It looks like an oversight to me, but I don't want to jump > the gun on it if there is some reasonable argument to keep > it out "by default". UFS_GJOURNAL is not enabled in GENERIC yet so it should not be enabled in the module. At this time more review is needed before it can be enabled by default (believe Kirk has been convinced to perform some review). While Pawel's work looks good we need to be very, very careful with UFS. We can't afford to have anything go wrong with our main (essentially only) file system. -- Brooks --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFhsN8XY6L6fI4GtQRAn0QAJ9dGBgDs6l5QwfYmUlsh5b8PlV6CQCgkPHT i9DsIaS47+eNbJZIP14C7b4= =HZEX -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 18 18:26:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BB93A16A415; Mon, 18 Dec 2006 18:26:29 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0052643CAE; Mon, 18 Dec 2006 18:24:39 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.66.42.124] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1GwMvg26XQ-0007Ti; Mon, 18 Dec 2006 19:09:36 +0100 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Mon, 18 Dec 2006 19:09:28 +0100 User-Agent: KMail/1.9.4 References: <20061218153906.GA6910@ramen.coleyandcheryl> In-Reply-To: <20061218153906.GA6910@ramen.coleyandcheryl> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart77835921.2Weo3IfLAM"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612181909.35355.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Coleman Kane Subject: Re: UFS_GJOURNAL and ufs.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2006 18:26:29 -0000 --nextPart77835921.2Weo3IfLAM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 18 December 2006 16:39, Coleman Kane wrote: > I have noticed (since adding UFS journal support) that the > UFS_GJOURNAL option hasn't been added to the ufs.ko kernel > module. I've been using this (out of an effort to test as > much as possible as KLDs) and every time I upgrade my kernel > I must manually add -DUFS_GJOURNAL to the CFLAGS line in > its Makefile. There is always make.conf > Is there any specific reason why this can't be committed? > So far, my experience with GJOURNAL has been great testing > it both with journal+fs on the same device as well as on > two seperate devices. > > It looks like an oversight to me, but I don't want to jump > the gun on it if there is some reasonable argument to keep > it out "by default". =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart77835921.2Weo3IfLAM Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFhtlfXyyEoT62BG0RAjc+AJ48RjIyZdQRRRsQoO5YMGts7Dte7QCdGHgS kpchrbDGUxSNwQKtK/z2s9o= =3qu7 -----END PGP SIGNATURE----- --nextPart77835921.2Weo3IfLAM-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 18 20:30:35 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DE63F16A494 for ; Mon, 18 Dec 2006 20:30:35 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6924443CA6 for ; Mon, 18 Dec 2006 20:30:35 +0000 (GMT) (envelope-from bms@incunabulum.net) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id A07FB53B70 for ; Mon, 18 Dec 2006 14:59:26 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Mon, 18 Dec 2006 14:59:26 -0500 X-Sasl-enc: nJ77/43Ft4kPhLTtM9wjHVvktGYQoFFqyKf8SLpfW8uX 1166471966 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id EEB0DEC22 for ; Mon, 18 Dec 2006 14:59:25 -0500 (EST) Message-ID: <4586F31F.4040001@incunabulum.net> Date: Mon, 18 Dec 2006 19:59:27 +0000 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------010702020305080100040201" Subject: [PATCH] Remove watchdog warnings from ral(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: Mon, 18 Dec 2006 20:30:36 -0000 This is a multi-part message in MIME format. --------------010702020305080100040201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, Here is a patch to update ral(4) for the removal of the if_watchdog ABI. I have tested this with an RT2661 part and looks OK. If others could test then I shall commit. Regards, BMS --------------010702020305080100040201 Content-Type: text/x-patch; name="ral-watchdog.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ral-watchdog.diff" ? .swp Index: rt2560.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ral/rt2560.c,v retrieving revision 1.8 diff -u -p -r1.8 rt2560.c --- rt2560.c 7 Dec 2006 15:24:38 -0000 1.8 +++ rt2560.c 18 Dec 2006 19:55:05 -0000 @@ -119,7 +119,7 @@ static struct mbuf *rt2560_get_rts(stru static int rt2560_tx_data(struct rt2560_softc *, struct mbuf *, struct ieee80211_node *); static void rt2560_start(struct ifnet *); -static void rt2560_watchdog(struct ifnet *); +static void rt2560_watchdog(void *); static int rt2560_reset(struct ifnet *); static int rt2560_ioctl(struct ifnet *, u_long, caddr_t); static void rt2560_bbp_write(struct rt2560_softc *, uint8_t, @@ -206,6 +206,7 @@ rt2560_attach(device_t dev, int id) mtx_init(&sc->sc_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK, MTX_DEF | MTX_RECURSE); + callout_init_mtx(&sc->watchdog_ch, &sc->sc_mtx, 0); callout_init(&sc->scan_ch, debug_mpsafenet ? CALLOUT_MPSAFE : 0); callout_init(&sc->rssadapt_ch, CALLOUT_MPSAFE); @@ -266,7 +267,6 @@ rt2560_attach(device_t dev, int id) ifp->if_init = rt2560_init; ifp->if_ioctl = rt2560_ioctl; ifp->if_start = rt2560_start; - ifp->if_watchdog = rt2560_watchdog; IFQ_SET_MAXLEN(&ifp->if_snd, IFQ_MAXLEN); ifp->if_snd.ifq_drv_maxlen = IFQ_MAXLEN; IFQ_SET_READY(&ifp->if_snd); @@ -386,6 +386,7 @@ rt2560_detach(void *xsc) struct ifnet *ifp = ic->ic_ifp; rt2560_stop(sc); + callout_stop(&sc->watchdog_ch); callout_stop(&sc->scan_ch); callout_stop(&sc->rssadapt_ch); @@ -2080,36 +2081,29 @@ rt2560_start(struct ifnet *ifp) } sc->sc_tx_timer = 5; - ifp->if_timer = 1; + callout_reset(&sc->watchdog_ch, hz, rt2560_watchdog, sc); } RAL_UNLOCK(sc); } static void -rt2560_watchdog(struct ifnet *ifp) +rt2560_watchdog(void *arg) { - struct rt2560_softc *sc = ifp->if_softc; + struct rt2560_softc *sc = (struct rt2560_softc *)arg; struct ieee80211com *ic = &sc->sc_ic; - RAL_LOCK(sc); - - ifp->if_timer = 0; - if (sc->sc_tx_timer > 0) { if (--sc->sc_tx_timer == 0) { device_printf(sc->sc_dev, "device timeout\n"); rt2560_init(sc); - ifp->if_oerrors++; - RAL_UNLOCK(sc); + sc->sc_ifp->if_oerrors++; return; } - ifp->if_timer = 1; + callout_reset(&sc->watchdog_ch, hz, rt2560_watchdog, sc); } ieee80211_watchdog(ic); - - RAL_UNLOCK(sc); } /* @@ -2769,7 +2763,6 @@ rt2560_stop(void *priv) struct ifnet *ifp = ic->ic_ifp; sc->sc_tx_timer = 0; - ifp->if_timer = 0; ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); ieee80211_new_state(ic, IEEE80211_S_INIT, -1); @@ -2837,7 +2830,7 @@ rt2560_raw_xmit(struct ieee80211_node *n goto bad; } sc->sc_tx_timer = 5; - ifp->if_timer = 1; + callout_reset(&sc->watchdog_ch, hz, rt2560_watchdog, sc); RAL_UNLOCK(sc); Index: rt2560var.h =================================================================== RCS file: /home/ncvs/src/sys/dev/ral/rt2560var.h,v retrieving revision 1.1 diff -u -p -r1.1 rt2560var.h --- rt2560var.h 5 Mar 2006 20:36:56 -0000 1.1 +++ rt2560var.h 18 Dec 2006 19:55:05 -0000 @@ -108,6 +108,7 @@ struct rt2560_softc { struct mtx sc_mtx; + struct callout watchdog_ch; struct callout scan_ch; struct callout rssadapt_ch; Index: rt2661.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ral/rt2661.c,v retrieving revision 1.9 diff -u -p -r1.9 rt2661.c --- rt2661.c 7 Dec 2006 15:24:38 -0000 1.9 +++ rt2661.c 18 Dec 2006 19:55:10 -0000 @@ -117,7 +117,7 @@ static int rt2661_tx_data(struct rt2661 static int rt2661_tx_mgt(struct rt2661_softc *, struct mbuf *, struct ieee80211_node *); static void rt2661_start(struct ifnet *); -static void rt2661_watchdog(struct ifnet *); +static void rt2661_watchdog(void *); static int rt2661_reset(struct ifnet *); static int rt2661_ioctl(struct ifnet *, u_long, caddr_t); static void rt2661_bbp_write(struct rt2661_softc *, uint8_t, @@ -209,6 +209,7 @@ rt2661_attach(device_t dev, int id) mtx_init(&sc->sc_mtx, device_get_nameunit(dev), MTX_NETWORK_LOCK, MTX_DEF | MTX_RECURSE); + callout_init_mtx(&sc->watchdog_ch, &sc->sc_mtx, 0); callout_init(&sc->scan_ch, debug_mpsafenet ? CALLOUT_MPSAFE : 0); callout_init(&sc->rssadapt_ch, CALLOUT_MPSAFE); @@ -293,7 +294,6 @@ rt2661_attach(device_t dev, int id) ifp->if_init = rt2661_init; ifp->if_ioctl = rt2661_ioctl; ifp->if_start = rt2661_start; - ifp->if_watchdog = rt2661_watchdog; IFQ_SET_MAXLEN(&ifp->if_snd, IFQ_MAXLEN); ifp->if_snd.ifq_drv_maxlen = IFQ_MAXLEN; IFQ_SET_READY(&ifp->if_snd); @@ -407,6 +407,7 @@ rt2661_detach(void *xsc) struct ifnet *ifp = ic->ic_ifp; rt2661_stop(sc); + callout_stop(&sc->watchdog_ch); callout_stop(&sc->scan_ch); callout_stop(&sc->rssadapt_ch); @@ -1853,36 +1854,29 @@ rt2661_start(struct ifnet *ifp) } sc->sc_tx_timer = 5; - ifp->if_timer = 1; + callout_reset(&sc->watchdog_ch, hz, rt2661_watchdog, sc); } RAL_UNLOCK(sc); } static void -rt2661_watchdog(struct ifnet *ifp) +rt2661_watchdog(void *arg) { - struct rt2661_softc *sc = ifp->if_softc; + struct rt2661_softc *sc = (struct rt2661_softc *)arg; struct ieee80211com *ic = &sc->sc_ic; - RAL_LOCK(sc); - - ifp->if_timer = 0; - if (sc->sc_tx_timer > 0) { if (--sc->sc_tx_timer == 0) { device_printf(sc->sc_dev, "device timeout\n"); rt2661_init(sc); - ifp->if_oerrors++; - RAL_UNLOCK(sc); + sc->sc_ifp->if_oerrors++; return; } - ifp->if_timer = 1; + callout_reset(&sc->watchdog_ch, hz, rt2661_watchdog, sc); } ieee80211_watchdog(ic); - - RAL_UNLOCK(sc); } /* @@ -2619,7 +2613,6 @@ rt2661_stop(void *priv) uint32_t tmp; sc->sc_tx_timer = 0; - ifp->if_timer = 0; ifp->if_drv_flags &= ~(IFF_DRV_RUNNING | IFF_DRV_OACTIVE); ieee80211_new_state(ic, IEEE80211_S_INIT, -1); Index: rt2661var.h =================================================================== RCS file: /home/ncvs/src/sys/dev/ral/rt2661var.h,v retrieving revision 1.1 diff -u -p -r1.1 rt2661var.h --- rt2661var.h 5 Mar 2006 20:36:56 -0000 1.1 +++ rt2661var.h 18 Dec 2006 19:55:10 -0000 @@ -101,6 +101,7 @@ struct rt2661_softc { struct mtx sc_mtx; + struct callout watchdog_ch; struct callout scan_ch; struct callout rssadapt_ch; --------------010702020305080100040201-- From owner-freebsd-current@FreeBSD.ORG Mon Dec 18 20:39:03 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7721816A47B for ; Mon, 18 Dec 2006 20:39:03 +0000 (UTC) (envelope-from vincent@xtra-net.org) Received: from ns1.xtra-net.be (ns1.xtra-net.be [195.162.200.90]) by mx1.FreeBSD.org (Postfix) with SMTP id 4177143CA2 for ; Mon, 18 Dec 2006 20:39:00 +0000 (GMT) (envelope-from vincent@xtra-net.org) Received: (qmail 4578 invoked from network); 18 Dec 2006 20:12:11 -0000 Received: from unknown (HELO sbepfkaa.srv.xtra-net.be) (172.16.66.66) by 0 with SMTP; 18 Dec 2006 20:12:11 -0000 Received: (qmail 44357 invoked from network); 18 Dec 2006 20:09:17 -0000 Received: from wbedllfs.intranet.xtra-net.be (HELO wbemfkaa.net.xtra-net.be) (172.16.66.1) by 0 with SMTP; 18 Dec 2006 20:09:17 -0000 From: Vincent Blondel To: freebsd-current@freebsd.org Content-Type: text/plain Date: Mon, 18 Dec 2006 21:11:06 +0100 Message-Id: <1166472667.903.23.camel@wbemfkaa.net.xtra-net.be> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: vincent@xtra-net.org Subject: /etc/rc.d/mdconfig2 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2006 20:39:03 -0000 Hello all, I discovered yesterday the existence of /etc/rc.d/mdconfig2. I am trying to use this script to automate the creation of a vnode disk at system boot but I encounter some problems. First of all I created a simple test vnode disk like this ... dd if=/dev/zero of=/var/squid/cache0 bs=1k count=512k mdconfig -a -t vnode -f /var/squid/cache0 -u 0 bsdlabel -w md0 auto newfs md0c mount /dev/md0c /mnt This is working perfectly. I can attach/detach the memory disk, mount/unmount this vnode device with no problem. But when I try to automate this procedure, I get some problems. So I first added these two lines in /etc/rc.conf. mdconfig_md0="-t vnode -f /var/squid/cache0" mdconfig_md0_cmd="mount \${_dev} /mnt" First part happens correctly and I get my device mounted as /dev/md0 but due the fact the device is labeled, I also get /dev/md0a and /dev/md0c and this occurs a problem. When debugging the script you can see the script is trying to make an fsck on /dev/md0 and not /dev/md0c. + mdconfig -l -u md0 + echo Creating md0 device (vnode). Creating md0 device (vnode). + mdconfig -a -t vnode -f /var/squid/cache0 -u md0 + [ /var/squid/cache0 != /var/squid/cache0 ] + checkyesno background_fsck + eval _value=$background_fsck + _value=YES + debug checkyesno: background_fsck is set to YES. + return 0 + _fsck_cmd=fsck -F + eval fsck -F -p /dev/md0 + fsck -F -p /dev/md0 fsck: Could not determine filesystem type + echo Fsck failed on /dev/md0, not mounting the filesystem. Fsck failed on /dev/md0, not mounting the filesystem. + continue + _return=0 + [ 0 -ne 0 ] + [ -n ] + return 0 So, is really mdconfig_mdX_cmd the right way to mount this vnode device or is there another way to do it ? Vincent. From owner-freebsd-current@FreeBSD.ORG Mon Dec 18 22:44:11 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C421416A639; Mon, 18 Dec 2006 22:44:06 +0000 (UTC) (envelope-from piso@newluxor.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FD0243CA3; Mon, 18 Dec 2006 22:43:52 +0000 (GMT) (envelope-from piso@newluxor.wired.org) Received: from newluxor.wired.org (ip-64-88.sn2.eutelia.it [83.211.64.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oltrelinux.com (Postfix) with ESMTP id DA64911AE43; Mon, 18 Dec 2006 23:22:52 +0100 (CET) Received: (from piso@localhost) by newluxor.wired.org (8.13.8/8.13.8/Submit) id kBIMMfdb001354; Mon, 18 Dec 2006 23:22:41 +0100 (CET) (envelope-from piso) Date: Mon, 18 Dec 2006 23:22:40 +0100 From: Paolo Pisati To: FreeBSD_Current , FreeBSD_Amd64 Message-ID: <20061218222240.GA1255@tin.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: Subject: FreeBSD/amd64 CURRENT@12/18/06: reproducible hang/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: Mon, 18 Dec 2006 22:44:11 -0000 Hi, since 17/12/06 i decided to switch my main development box from FreeBSD/i386 to FreeBSD/amd64. My box is composed of: PentiumD 920 (2x2.8Ghz no overclock) 2GB ram Interl 945g make.conf: CPUTYPE?= nocona CFLAGS= -O -pipe KERNCONF= GENERIC With FreeBSD/i386 the box worked fine for months, but with FreeBSD/amd64 i encountered these problems: 1) i'm able to solid hang the box (no panic, no crash, just a "picture" of my desktop) putting a bit of load on it (make -j6 buidworld). 2) sometimes when i rebooted the box, i got a panic/double fault after buffers where synced to disk: unfortunately the double fault msg scrolled up the real panic, so i was unable to see it. While investigating the above problems, i decided to add: options DEBUG_MEMGUARD options DEBUG_REDZONE to my kernel config. Made a buildworld, installed and rebooted. With these 2 options activated, the system panics at boot: MEMGUARD DEBUGGING ALLOCATOR INITIALIZED: MEMGUARD MAP BASE: 0xffffffff80e22000 MEMGUARD MAP LIMIT: 0xffffffff83623000 MEMGUARD MAP SIZE: 41947136 (BYTES) MEMORY MODIFIED AFTER FREE 0xffffff0000039d00 (248) val = 5 @ 0xffffff0000039dd0 kernel trap 9 with interrupts disabled fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 inst ptr = ... stack ptr = ... frame ptr = ... code segment = ... proc eflags = resume, iopl = 0 current process = 0 () [thread pid 0 tid 0] stopped at strlen+0x4: cmpb $0, (%rdi) db> bt tracing pid 0 tid 0 td 0xffffffff80940080 strlen() at strlen+0x4 vnsprintf() vnsprintf+0x2e panic() at panic+0x148 mtrash_dtor() at mtrash_dtor uma_zalloc_arg() at uma_zalloc_arg+0x2fc malloc() at malloc+0xe4 init_dynamic_kenv() a init_dynamic_kenv+0x5e mi_startup() at mi_startup+0xc0 btext() at btext+0x2c Now, i dunno if this panic is related to the previous described problems, but i would like to know if i'm the only one to experience such problems. bye, P. From owner-freebsd-current@FreeBSD.ORG Mon Dec 18 19:06:35 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DFFBC16A407 for ; Mon, 18 Dec 2006 19:06:35 +0000 (UTC) (envelope-from cokane@mail.cokane.org) Received: from ms-smtp-02.texas.rr.com (ms-smtp-02.texas.rr.com [24.93.47.41]) by mx1.FreeBSD.org (Postfix) with ESMTP id BADC743C9F for ; Mon, 18 Dec 2006 19:06:34 +0000 (GMT) (envelope-from cokane@mail.cokane.org) Received: from ramen.cokane.org (rrcs-24-153-184-158.sw.biz.rr.com [24.153.184.158]) by ms-smtp-02.texas.rr.com (8.13.6/8.13.6) with SMTP id kBIIJWDk023217 for ; Mon, 18 Dec 2006 12:19:32 -0600 (CST) Received: (qmail 7895 invoked by uid 1001); 18 Dec 2006 18:19:25 -0000 Date: Mon, 18 Dec 2006 18:19:25 +0000 From: Coleman Kane To: Brooks Davis Message-ID: <20061218181925.GA7885@ramen.coleyandcheryl> References: <20061218153906.GA6910@ramen.coleyandcheryl> <20061218163613.GA86127@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061218163613.GA86127@lor.one-eyed-alien.net> User-Agent: Mutt/1.4.1i X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Mailman-Approved-At: Mon, 18 Dec 2006 23:03:28 +0000 Cc: freebsd-current@freebsd.org, Coleman Kane Subject: Re: UFS_GJOURNAL and ufs.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 18 Dec 2006 19:06:36 -0000 On Mon, Dec 18, 2006 at 10:36:13AM -0600, Brooks Davis wrote, and it was proclaimed: > On Mon, Dec 18, 2006 at 03:39:06PM +0000, Coleman Kane wrote: > > Hello, > > > > I have noticed (since adding UFS journal support) that the > > UFS_GJOURNAL option hasn't been added to the ufs.ko kernel > > module. I've been using this (out of an effort to test as > > much as possible as KLDs) and every time I upgrade my kernel > > I must manually add -DUFS_GJOURNAL to the CFLAGS line in > > its Makefile. > > > > Is there any specific reason why this can't be committed? > > So far, my experience with GJOURNAL has been great testing > > it both with journal+fs on the same device as well as on > > two seperate devices. > > > > It looks like an oversight to me, but I don't want to jump > > the gun on it if there is some reasonable argument to keep > > it out "by default". > > UFS_GJOURNAL is not enabled in GENERIC yet so it should not be enabled > in the module. At this time more review is needed before it can be > enabled by default (believe Kirk has been convinced to perform some > review). While Pawel's work looks good we need to be very, very careful > with UFS. We can't afford to have anything go wrong with our main > (essentially only) file system. > > -- Brooks I understand, thanks for the explanation. I'll just maintain it with my patchset for now. -- Coleman From owner-freebsd-current@FreeBSD.ORG Mon Dec 18 19:11:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B125516A416 for ; Mon, 18 Dec 2006 19:11:33 +0000 (UTC) (envelope-from redchrom@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B10843CB3 for ; Mon, 18 Dec 2006 19:11:28 +0000 (GMT) (envelope-from redchrom@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so1911448nfc for ; Mon, 18 Dec 2006 11:11:20 -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:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:x-useless-header; b=OSLH+kjCmPUYIIzPo0IbKimp9fW77GrCZIs2pytCgRliXKa5uZds5+aJvc2PxHFT98uUZ6qJWKMyuyNACm54FkgSbnf5X65jwSh7yky3axxqoQr+qdai9O2dMln4sxQLDwHC5hY3fKulOdOXjMADJ/2azlPox2XkEBb/Tpf66y8= Received: by 10.49.20.5 with SMTP id x5mr5451810nfi.1166467579355; Mon, 18 Dec 2006 10:46:19 -0800 (PST) Received: from localhost ( [82.146.37.133]) by mx.google.com with ESMTP id v20sm28365512nfc.2006.12.18.10.46.16; Mon, 18 Dec 2006 10:46:18 -0800 (PST) Date: Tue, 19 Dec 2006 02:46:46 +0800 From: Stepan Zastupov To: Sam Leffler Message-ID: <20061218184646.GA7183@stepan.ispsystem.net> References: <20061214234849.GA1062@stepan.ispsystem.net> <4584708B.3020902@root.org> <20061217214408.GA902@stepan.ispsystem.net> <4585BAF3.1010504@root.org> <4585F7BB.9010704@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <4585F7BB.9010704@errno.com> User-Agent: Mutt/1.4.2.2i X-Useless-Header: They killed Kenny! THOSE BASTARDS! X-Mailman-Approved-At: Mon, 18 Dec 2006 23:03:44 +0000 Cc: Stepan Zastupov , freebsd-current@freebsd.org, Nate Lawson Subject: Re: cbb hangs during suspend if ath card active X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stepan Zastupov List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2006 19:11:33 -0000 On Sun, Dec 17, 2006 at 06:06:51PM -0800, Sam Leffler wrote: > Nate Lawson wrote: > > Stepan Zastupov wrote: > >> On Sat, Dec 16, 2006 at 02:17:47PM -0800, Nate Lawson wrote: > >>> Stepan Zastupov wrote: > >>>> Does anyone still work on this problem? > >>>> (http://lists.freebsd.org/pipermail/freebsd-current/2006-July/064550.html) > >>>> > >>>> I incure the same problems. If need testing I can help with it. > >>> Just comment out this line in ath_stop() in if_ath.c: > >>> // ath_hal_setpower(sc->sc_ah, HAL_PM_FULL_SLEEP); > > > >> It is already commented out in current and doesn't help. Card wont work > >> even if it inserted after suspend and resume. > >> > > > > That's something different then. I was talking about the suspend > > process hanging if the card is inserted and active. But ejecting it > > would allow the process to continue and after resume, re-inserting it > > worked fine. > > > > What Nate is referring to is that on many ath parts if you "power down" > the MAC then any pci references to registers outside the PCI clock > domain will hang the bus. Not putting the chip in "full sleep" is a > hack as it means it'll continue to draw full power after the interface > is marked down. Something is causing the driver to be entered and > registers accessed when not intended/expected. I haven't been able to > make this happen on any of my laptops (most have ACPI problems s.t. > suspend/resume doesn't work right) so haven't had a test case to > debug--and noone with the problem has been able to provide the needed info. Ok what info you need exactly? I can provide only the messages after some systls verbose tuned. -- Best regards, Stepan Zastupov aka RedChrom ISPSystem From owner-freebsd-current@FreeBSD.ORG Tue Dec 19 02:00:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 49F1816A4B3 for ; Tue, 19 Dec 2006 02:00:32 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43B0343CC3 for ; Tue, 19 Dec 2006 01:59:44 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so471390ana for ; Mon, 18 Dec 2006 17:59:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=THm66Zr6OuVdRvE9yo+ruu0JWLYPcQCO+DkeKHfge4qCblladp72MMzOzWYW4TLJfYzBliK/1YT4Qs00u0MfUWuX76iSL4gw6Lve0q7v29FN0JWACuXHIJMi3nQywxjO4+ogkK+qwQipsP2ouxXHipW/DrybstJluUh0nNbkZvE= Received: by 10.100.139.9 with SMTP id m9mr3805942and.1166492075820; Mon, 18 Dec 2006 17:34:35 -0800 (PST) Received: by 10.100.136.16 with HTTP; Mon, 18 Dec 2006 17:34:35 -0800 (PST) Message-ID: <6eb82e0612181734n92e4a95l9d54aeb1edae87d1@mail.gmail.com> Date: Tue, 19 Dec 2006 09:34:35 +0800 From: "Rong-en Fan" To: "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: bigdisk and scsi_da X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2006 02:00:32 -0000 It seems to me that scsi_da.c reports the wrong size: da1 at mpt0 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled da1: 0MB (1 0 byte sectors: 0H 0S/T 0C) While geom shows the right one: Geom name: da1 Providers: 1. Name: da1 Mediasize: 4991221760000 (4.5T) Sectorsize: 512 Mode: r0w0e0 fwsectors: 63 fwheads: 255 Speaking of bigdisk, can gpt modify on-disk table on-fly? Regards, Rong-En Fan From owner-freebsd-current@FreeBSD.ORG Tue Dec 19 07:19:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7696016A416 for ; Tue, 19 Dec 2006 07:19:44 +0000 (UTC) (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 D750A43CA0 for ; Tue, 19 Dec 2006 07:19:43 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kBJ6qc4k070981; Mon, 18 Dec 2006 23:52:48 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <45878C35.3030404@samsco.org> Date: Tue, 19 Dec 2006 01:52:37 -0500 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Rong-en Fan References: <6eb82e0612181734n92e4a95l9d54aeb1edae87d1@mail.gmail.com> In-Reply-To: <6eb82e0612181734n92e4a95l9d54aeb1edae87d1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: FreeBSD Current Subject: Re: bigdisk and scsi_da X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2006 07:19:44 -0000 Rong-en Fan wrote: > It seems to me that scsi_da.c reports the wrong size: > > da1 at mpt0 bus 0 target 0 lun 0 > da1: Fixed Direct Access SCSI-5 device > da1: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged > Queueing Enabled > da1: 0MB (1 0 byte sectors: 0H 0S/T 0C) > > While geom shows the right one: > > Geom name: da1 > Providers: > 1. Name: da1 > Mediasize: 4991221760000 (4.5T) > Sectorsize: 512 > Mode: r0w0e0 > fwsectors: 63 > fwheads: 255 > XPT_CALC_GEOMETRY is failing when the disk is being probed. This is likely a problem with the MPT driver. However, I'd need some time to think through all of the code in order to be sure. Scott From owner-freebsd-current@FreeBSD.ORG Tue Dec 19 17:06:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E80DE16A403 for ; Tue, 19 Dec 2006 17:06:44 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 175A743CB7 for ; Tue, 19 Dec 2006 17:06:37 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so537028ana for ; Tue, 19 Dec 2006 09:06:37 -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=N71WeB6bBCNyIr1cJmq9p+/zh2VYZVIJYgYdNDM6x5eCv5EoQBvB1xVj19gnUnFGhAoyTx75J4rYaQQqcLIfuW93KjdtjDYQDHfg2MEswPzGmpHMeBSLijggJcxdQWZSsbSxj/xSItG//62VnssOPS+J78KjmeNGvf+j88IEyDw= Received: by 10.78.164.13 with SMTP id m13mr4047844hue.1166546250935; Tue, 19 Dec 2006 08:37:30 -0800 (PST) Received: by 10.78.198.13 with HTTP; Tue, 19 Dec 2006 08:37:30 -0800 (PST) Message-ID: <7579f7fb0612190837s7c3a876er8722a97d758c3474@mail.gmail.com> Date: Tue, 19 Dec 2006 08:37:30 -0800 From: "Matthew Jacob" To: "Scott Long" In-Reply-To: <45878C35.3030404@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6eb82e0612181734n92e4a95l9d54aeb1edae87d1@mail.gmail.com> <45878C35.3030404@samsco.org> Cc: FreeBSD Current , Rong-en Fan Subject: Re: bigdisk and scsi_da X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2006 17:06:45 -0000 > XPT_CALC_GEOMETRY is failing when the disk is being probed. This > is likely a problem with the MPT driver. static void mpt_calc_geometry(struct ccb_calc_geometry *ccg, int extended) { #if __FreeBSD_version >= 500000 cam_calc_geometry(ccg, extended); #else From owner-freebsd-current@FreeBSD.ORG Tue Dec 19 17:43:04 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B9B9016A415 for ; Tue, 19 Dec 2006 17:43:04 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.238]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C6B843C9F for ; Tue, 19 Dec 2006 17:42:59 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so755255nzh for ; Tue, 19 Dec 2006 09:42:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=cITzYFfs+H32TXW35PLcvKR05bMNVJbDD/IJTXZqdS2MwrynOxqjsLwaBUUGLDnr+fnOWxTlfbW0WIx0Itpsev8cSSNpRXZIgo1SymtxCoTjyllhpZgXlOyAPiCOUdRLBXCcJpWQEJgRid0obQ8PYtfGNqWYWVxNf3TtwdLO/vQ= Received: by 10.65.122.20 with SMTP id z20mr7333404qbm.1166548505727; Tue, 19 Dec 2006 09:15:05 -0800 (PST) Received: by 10.65.61.1 with HTTP; Tue, 19 Dec 2006 09:15:05 -0800 (PST) Message-ID: <790a9fff0612190915va75678at895efa0bc93ac3a1@mail.gmail.com> Date: Tue, 19 Dec 2006 11:15:05 -0600 From: "Scot Hetzel" To: "FreeBSD Current" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: settimeofday function taking 24 - 30 minutes to complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2006 17:43:04 -0000 While working on implementing the settimeofday function in the linuxolator, I was using the LTP testcase settimeofday01 to test it. Running this test caused the system to hang for 24-30 minutes. I then decided to rewrite the testcase so that it would run on FreeBSD, and it also hung the system for 24-30 minutes. What the settimeofday01 test was doing is to set the time to a known value (100 sec, 100 usec) and then use gettimeofday to retrieve the current time. It then compared the returned value to check if it was within +/- 500 msec. I have since reduced the testcode down to the following testcase that is causing the hang. Any ideals as to what could be causing this hang? Scot #include #include #include #define VAL_SEC 100 #define VAL_MSEC 100 int main(int argc, char **argv) { struct timeval tp, tp1, save_tv; long return_test, errno_test; suseconds_t delta; #define TEST(SCALL) \ do { \ errno = 0; \ return_test = SCALL; \ errno_test = errno; \ } while (0) /* Save the current time values */ if ((gettimeofday(&save_tv, (struct timezone *)&tp1)) == -1) { printf("BROK: gettimeofday failed. errno=%d\n", errno); exit(1); } else { printf("INFO: Saved current time\n"); } tp.tv_sec = VAL_SEC; tp.tv_usec = VAL_MSEC; /* Hang occurs here */ TEST(settimeofday(&tp, NULL)); if (return_test == -1) { printf("FAIL: Error Setting Time, errno=%d\n", errno_test); } else { printf("INFO: settimeofday completed sucessfully\n"); } /* restore the original time values. */ if ((settimeofday(&save_tv, NULL)) == -1) { printf("WARN: FATAL COULD NOT RESET THE CLOCK\n"); printf("FAIL: Error Setting Time, errno=%d (%d, %d)\n", errno, tp.tv_sec, tp.tv_usec); } else { printf("INFO: Reset time to original value\n"); } return(0); } -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Tue Dec 19 17:52:37 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8EAD16A47B for ; Tue, 19 Dec 2006 17:52:36 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5BF9B43CBA for ; Tue, 19 Dec 2006 17:52:32 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id kBJHbHZo059464 for ; Tue, 19 Dec 2006 19:37:18 +0200 (EET) (envelope-from dmitry@atlantis.dp.ua) Date: Tue, 19 Dec 2006 19:37:17 +0200 (EET) From: Dmitry Pryanishnikov To: freebsd-current@freebsd.org Message-ID: <20061219175917.L84683@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: ddb(4) spoils kernel stack in CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2006 17:52:37 -0000 Hello! I'm facing with a strange debugging problem under the fresh (19-Dec-2006) CURRENT on the uniprocessor i386 machine. My kernel config is: ident LYNX machine i386 makeoptions DEBUG=-g options INCLUDE_CONFIG_FILE cpu I686_CPU options SCHED_4BSD options ADAPTIVE_GIANT options PREEMPTION device apic options COMPAT_43 options COMPAT_43TTY options COMPAT_FREEBSD4 options COMPAT_FREEBSD5 options COMPAT_FREEBSD6 options SYSVSHM options SYSVSEM options SYSVMSG options KDB options KDB_TRACE options DDB options DDB_NUMSYM options SYSCTL_DEBUG options KTRACE options KTRACE_REQUEST_POOL=101 options INVARIANTS options INVARIANT_SUPPORT options INET options FAST_IPSEC options IPSEC_FILTERGIF device ether device loop device bpf device ppp options PPP_BSDCOMP options PPP_DEFLATE options PPP_FILTER options IPFIREWALL options IPFIREWALL_VERBOSE options IPFIREWALL_VERBOSE_LIMIT=100 options IPFIREWALL_FORWARD options IPSTEALTH options FFS options SOFTUPDATES options UFS_EXTATTR options UFS_ACL options UFS_DIRHASH options QUOTA options _KPOSIX_PRIORITY_SCHEDULING device pty device crypto device pci device atkbdc device atkbd device psm options KBD_INSTALL_CDEV device vga device splash device sc options SC_HISTORY_SIZE=5000 options SC_TWOBUTTON_MOUSE device ata device atadisk options ATA_STATIC_ID device scbus device da device cd device pass To demonstrate the problem, I've forced an artificial panic from the singleuser mode using the 'sysctl debug.kdb.panic=1' command, and then typing 'panic' from ddb. kgdb against the resulting kernel dump fails to print complete backtrace: (kgdb) where #0 doadump () at pcpu.h:166 #1 0xc04aad4c in boot (howto=260) at /mnt3/usr/CURRENT/src/sys/kern/kern_shutdown.c:411 #2 0xc04aaff7 in panic (fmt=0xc05ffbbf "from debugger") at /mnt3/usr/CURRENT/src/sys/kern/kern_shutdown.c:567 #3 0xc044238e in db_panic (addr=-1068723113, have_addr=0, count=-1, modif=0xe4b4795c "") at /mnt3/usr/CURRENT/src/sys/ddb/db_command.c:433 #4 0xc0442327 in db_command (last_cmdp=0xc0660a04, cmd_table=0x0) at /mnt3/usr/CURRENT/src/sys/ddb/db_command.c:401 #5 0xc04423e2 in db_command_loop () at /mnt3/usr/CURRENT/src/sys/ddb/db_command.c:453 #6 0xc044402d in db_trap (type=3, code=0) at /mnt3/usr/CURRENT/src/sys/ddb/db_main.c:222 #7 0xc04c96d1 in kdb_trap (type=3, code=0, tf=0x0) at /mnt3/usr/CURRENT/src/sys/kern/subr_kdb.c:502 #8 0xc05ddfc1 in trap (frame=0xe4b47aec) at /mnt3/usr/CURRENT/src/sys/i386/i386/trap.c:621 #9 0xc05ca84b in calltrap () at /mnt3/usr/CURRENT/src/sys/i386/i386/exception.s:139 #10 0x00000000 in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) However, if I turn ddb off with the 'sysctl debug.debugger_on_panic=0' and then obtain a kernel dump via 'sysctl debug.kdb.panic=1', kgdb completely unwinds the stack from the resulting dump: (kgdb) where #0 doadump () at pcpu.h:166 #1 0xc04aad4c in boot (howto=260) at /mnt3/usr/CURRENT/src/sys/kern/kern_shutdown.c:411 #2 0xc04aaff7 in panic (fmt=0xc060d1bd "kdb_sysctl_panic") at /mnt3/usr/CURRENT/src/sys/kern/kern_shutdown.c:567 #3 0xc04c929e in kdb_sysctl_panic (oidp=0xc06435c0, arg1=0x0, arg2=0, req=0xe4b78ba4) at /mnt3/usr/CURRENT/src/sys/kern/subr_kdb.c:182 #4 0xc04b3073 in sysctl_root (oidp=0x0, arg1=0x0, arg2=0, req=0xe4b78ba4) at /mnt3/usr/CURRENT/src/sys/kern/kern_sysctl.c:1282 #5 0xc04b3244 in userland_sysctl (td=0x0, name=0xe4b78c24, namelen=3, old=0xe4b78ba4, oldlenp=0x0, inkernel=0, new=0xbfbfe4bc, newlen=0, retval=0xe4b78c20, flags=0) at /mnt3/usr/CURRENT/src/sys/kern/kern_sysctl.c:1381 #6 0xc04b30fb in __sysctl (td=0xc3cf91b0, uap=0xe4b78d00) at /mnt3/usr/CURRENT/src/sys/kern/kern_sysctl.c:1316 #7 0xc05de786 in syscall (frame=0xe4b78d38) at /mnt3/usr/CURRENT/src/sys/i386/i386/trap.c:1008 #8 0xc05ca8b0 in Xint0x80_syscall () at /mnt3/usr/CURRENT/src/sys/i386/i386/exception.s:196 #9 0x48133747 in ?? () Previous frame inner to this frame (corrupt stack?) I've tried to repeat this under the RELENG_6 as of 30-Oct (just removing kernel options COMPAT_43TTY, COMPAT_FREEBSD6, INVARIANTS, INVARIANT_SUPPORT, and using 'debug.kdb.enter' instead of 'debug.kdb.panic') - and kgdb unwinds the stack even if the dump got via typing 'panic' from ddb: (kgdb) where #0 doadump () at pcpu.h:165 #1 0xc049eb46 in boot (howto=260) at /usr/RELENG_6/src/sys/kern/kern_shutdown.c:409 #2 0xc049ee0c in panic (fmt=0xc05fabc0 "from debugger") at /usr/RELENG_6/src/sys/kern/kern_shutdown.c:565 #3 0xc043fcd5 in db_panic (addr=-1068795853, have_addr=0, count=-1, modif=0xe526ba2c "") at /usr/RELENG_6/src/sys/ddb/db_command.c:438 #4 0xc043fc6c in db_command (last_cmdp=0xc06483a4, cmd_table=0x0, aux_cmd_tablep=0xc061ac3c, aux_cmd_tablep_end=0xc061ac40) at /usr/RELENG_6/src/sys/ddb/db_command.c:350 #5 0xc043fd34 in db_command_loop () at /usr/RELENG_6/src/sys/ddb/db_command.c:458 #6 0xc0441949 in db_trap (type=3, code=0) at /usr/RELENG_6/src/sys/ddb/db_main.c:222 #7 0xc04b7aaf in kdb_trap (type=3, code=0, tf=0xe526bb6c) at /usr/RELENG_6/src/sys/kern/subr_kdb.c:473 #8 0xc05da99c in trap (frame= {tf_fs = -450494456, tf_es = -1068826584, tf_ds = -1067450328, tf_edi = -450446332, tf_esi = 0, tf_ebp = -450446420, tf_isp = -450446440, tf_ebx = -450446332, tf_edx = 0, tf_ecx = -1056878592, tf_eax = 35, tf_trapno = 3, tf_err = 0, tf_eip = -1068795853, tf_cs = 32, tf_eflags = 646, tf_esp = -450446400, tf_ss = -1068796128}) at /usr/RELENG_6/src/sys/i386/i386/trap.c:594 #9 0xc05c915a in calltrap () at /usr/RELENG_6/src/sys/i386/i386/exception.s:139 #10 0xc04b7833 in kdb_enter (msg=0x23
) at cpufunc.h:60 #11 0xc04b7720 in kdb_sysctl_enter (oidp=0xc062cf60, arg1=0x0, arg2=0, req=0xe526bc04) at /usr/RELENG_6/src/sys/kern/subr_kdb.c:175 #12 0xc04a6bb3 in sysctl_root (oidp=0x0, arg1=0x0, arg2=0, req=0xe526bc04) at /usr/RELENG_6/src/sys/kern/kern_sysctl.c:1281 #13 0xc04a6db0 in userland_sysctl (td=0x23, name=0xe526bc74, namelen=3, old=0xe526bc04, oldlenp=0x0, inkernel=0, new=0xbfbfe4ac, newlen=35, retval=0xe526bc70, flags=35) at /usr/RELENG_6/src/sys/kern/kern_sysctl.c:1380 #14 0xc04a6c53 in __sysctl (td=0xc4d0ea80, uap=0xe526bd04) at /usr/RELENG_6/src/sys/kern/kern_sysctl.c:1315 #15 0xc05db1f3 in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 3, tf_esi = 0, tf_ebp = -1077943272, tf_isp = -450445980, tf_ebx = 1209310688, tf_edx = 0, tf_ecx = -1077941056, tf_eax = 202, tf_trapno = 12, tf_err = 2, tf_eip = 1209155743, tf_cs = 51, tf_eflags = 658, tf_esp = -1077943332, tf_ss = 59}) at /usr/RELENG_6/src/sys/i386/i386/trap.c:983 #16 0xc05c91af in Xint0x80_syscall () at /usr/RELENG_6/src/sys/i386/i386/exception.s:200 #17 0x00000033 in ?? () So it looks like a regression in CURRENT vs RELENG_6 (either ddb 'spoils' the stack somehow, or kgdb fails to unwind it). Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-current@FreeBSD.ORG Tue Dec 19 19:56:20 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 72BC216A706 for ; Tue, 19 Dec 2006 19:56:20 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3BF643CC0 for ; Tue, 19 Dec 2006 19:55:40 +0000 (GMT) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kBJJtdmk007676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 19 Dec 2006 11:55:39 -0800 X-Auth-Received: from [128.208.5.99] (nilakantha.cs.washington.edu [128.208.5.99]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kBJJtdUP017204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 19 Dec 2006 11:55:39 -0800 Message-ID: <458843B8.1060704@u.washington.edu> Date: Tue, 19 Dec 2006 11:55:36 -0800 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <790a9fff0612190915va75678at895efa0bc93ac3a1@mail.gmail.com> In-Reply-To: <790a9fff0612190915va75678at895efa0bc93ac3a1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.19.113932 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Re: settimeofday function taking 24 - 30 minutes to complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2006 19:56:20 -0000 Scot Hetzel wrote: > While working on implementing the settimeofday function in the > linuxolator, I was using the LTP testcase settimeofday01 to test it. > Running this test caused the system to hang for 24-30 minutes. > > I then decided to rewrite the testcase so that it would run on > FreeBSD, and it also hung the system for 24-30 minutes. What the > settimeofday01 test was doing is to set the time to a known value (100 > sec, 100 usec) and then use gettimeofday to retrieve the current time. > It then compared the returned value to check if it was within +/- 500 > msec. > > I have since reduced the testcode down to the following testcase that > is causing the hang. > > Any ideals as to what could be causing this hang? > > Scot > > #include > #include > #include > > #define VAL_SEC 100 > #define VAL_MSEC 100 > > int main(int argc, char **argv) > { > struct timeval tp, tp1, save_tv; > long return_test, errno_test; > suseconds_t delta; > > #define TEST(SCALL) \ > do { \ > errno = 0; \ > return_test = SCALL; \ > errno_test = errno; \ > } while (0) > > /* Save the current time values */ > if ((gettimeofday(&save_tv, (struct timezone *)&tp1)) == -1) { > printf("BROK: gettimeofday failed. errno=%d\n", errno); > exit(1); > } else { > printf("INFO: Saved current time\n"); > } > > tp.tv_sec = VAL_SEC; > tp.tv_usec = VAL_MSEC; > > /* Hang occurs here */ > TEST(settimeofday(&tp, NULL)); > if (return_test == -1) { > printf("FAIL: Error Setting Time, errno=%d\n", > errno_test); > } else { > printf("INFO: settimeofday completed sucessfully\n"); > } > > /* restore the original time values. */ > if ((settimeofday(&save_tv, NULL)) == -1) { > printf("WARN: FATAL COULD NOT RESET THE CLOCK\n"); > printf("FAIL: Error Setting Time, errno=%d (%d, %d)\n", > errno, tp.tv_sec, tp.tv_usec); > } else { > printf("INFO: Reset time to original value\n"); > } > > return(0); > } > Not sure about why it takes so long to complete, but it seems as if the system is 'hanging' because it probably is using up all of your CPU resources in the while loop under your TEST macro. Maybe the near 100% CPU usage is effecting kernel operations as well, i.e. slowing it down to stone age speeds? sleep(3)/nanosleep(2) to the rescue? -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Dec 19 20:20:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B995516A416 for ; Tue, 19 Dec 2006 20:20:15 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31BB943CA3 for ; Tue, 19 Dec 2006 20:20:15 +0000 (GMT) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.141]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kBJKKErU007293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 19 Dec 2006 12:20:14 -0800 X-Auth-Received: from [128.208.5.22] (shiina.dyn.cs.washington.edu [128.208.5.22]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kBJKKEFd020768 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 19 Dec 2006 12:20:14 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <9ab217670612191201y47b7bb3codf979f88f56e81cc@mail.gmail.com> References: <790a9fff0612190915va75678at895efa0bc93ac3a1@mail.gmail.com> <458843B8.1060704@u.washington.edu> <9ab217670612191201y47b7bb3codf979f88f56e81cc@mail.gmail.com> X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <034496F2-6A3F-4721-8370-7ED79C6E1D6C@u.washington.edu> Content-Transfer-Encoding: 7bit From: Garrett Cooper Date: Tue, 19 Dec 2006 12:20:18 -0800 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.752.2) X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.19.115932 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Subject: Re: settimeofday function taking 24 - 30 minutes to complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2006 20:20:15 -0000 On Dec 19, 2006, at 12:01 PM, Devon H. O'Dell wrote: > 2006/12/19, Garrett Cooper : >> Scot Hetzel wrote: >> > While working on implementing the settimeofday function in the >> > linuxolator, I was using the LTP testcase settimeofday01 to test >> it. >> > Running this test caused the system to hang for 24-30 minutes. >> > >> > I then decided to rewrite the testcase so that it would run on >> > FreeBSD, and it also hung the system for 24-30 minutes. What the >> > settimeofday01 test was doing is to set the time to a known >> value (100 >> > sec, 100 usec) and then use gettimeofday to retrieve the current >> time. >> > It then compared the returned value to check if it was within >> +/- 500 >> > msec. >> > >> > I have since reduced the testcode down to the following testcase >> that >> > is causing the hang. >> > >> > Any ideals as to what could be causing this hang? >> > >> > Scot >> > >> > #include >> > #include >> > #include >> > >> > #define VAL_SEC 100 >> > #define VAL_MSEC 100 >> > >> > int main(int argc, char **argv) >> > { >> > struct timeval tp, tp1, save_tv; >> > long return_test, errno_test; >> > suseconds_t delta; >> > >> > #define TEST(SCALL) \ >> > do { \ >> > errno = 0; \ >> > return_test = SCALL; \ >> > errno_test = errno; \ >> > } while (0) >> > >> > /* Save the current time values */ >> > if ((gettimeofday(&save_tv, (struct timezone *)&tp1)) == >> -1) { >> > printf("BROK: gettimeofday failed. errno=%d\n", >> errno); >> > exit(1); >> > } else { >> > printf("INFO: Saved current time\n"); >> > } >> > >> > tp.tv_sec = VAL_SEC; >> > tp.tv_usec = VAL_MSEC; >> > >> > /* Hang occurs here */ >> > TEST(settimeofday(&tp, NULL)); >> > if (return_test == -1) { >> > printf("FAIL: Error Setting Time, errno=%d\n", >> > errno_test); >> > } else { >> > printf("INFO: settimeofday completed sucessfully >> \n"); >> > } >> > >> > /* restore the original time values. */ >> > if ((settimeofday(&save_tv, NULL)) == -1) { >> > printf("WARN: FATAL COULD NOT RESET THE CLOCK\n"); >> > printf("FAIL: Error Setting Time, errno=%d (%d, % >> d)\n", >> > errno, tp.tv_sec, tp.tv_usec); >> > } else { >> > printf("INFO: Reset time to original value\n"); >> > } >> > >> > return(0); >> > } >> > >> Not sure about why it takes so long to complete, but it seems >> as if >> the system is 'hanging' because it probably is using up all of >> your CPU >> resources in the while loop under your TEST macro. Maybe the near >> 100% >> CPU usage is effecting kernel operations as well, i.e. slowing it >> down >> to stone age speeds? sleep(3)/nanosleep(2) to the rescue? > > The while loop in the TEST macro is a do { /* ... */ } while (0); so > it should only execute once. > > --Devon Duh, of course. Sorry, must be hungry ><. One thing though, why don't you define your macro outside main()? Could it (TEST) be invoking itself instead many times through implicit recursion? I wouldn't think so because you used '\' to carry on the line, but meh.. you never know. I'll try compiling and running your code on a FC5 box since I don't have my FreeBSD box in front of me to test it on. -Garrett From owner-freebsd-current@FreeBSD.ORG Tue Dec 19 20:28:53 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6089B16A407 for ; Tue, 19 Dec 2006 20:28:53 +0000 (UTC) (envelope-from knightmare.freebsd@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E7B943C9F for ; Tue, 19 Dec 2006 20:28:51 +0000 (GMT) (envelope-from knightmare.freebsd@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so1683893uge for ; Tue, 19 Dec 2006 12:28:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=tD3AG+fokUMjcWckPgBRH9HGUNBWtBoILTE1qt6xNp7PiVdyQNbbd4GY43i36Jojnt5Ozy/lNnfcdEcoPG+pPtrQqipixjyeppcB8PX68aVRzYoyGWI2KnnZP4IfQTh+kTTYrBBe+6/zQpVxBy9Fbu7JdU+DM0FGLttHNKlueKM= Received: by 10.67.99.1 with SMTP id b1mr8954986ugm.1166558412318; Tue, 19 Dec 2006 12:00:12 -0800 (PST) Received: by 10.66.250.4 with HTTP; Tue, 19 Dec 2006 12:00:11 -0800 (PST) Message-ID: Date: Wed, 20 Dec 2006 04:00:11 +0800 From: "shava knightmare" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: how to invoke a network configure dialog in install.cfg X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2006 20:28:53 -0000 i'm building a automatic install cdrom with install.cfg for sysinstall. and i cannot find a way to invoke network configure dialog in install.cfg. the tcpMenuSelect command popup the configure dialog and throw a error message when selected the device.So what shall i do so that i can get a user inputted ipaddress in system install progress? From owner-freebsd-current@FreeBSD.ORG Tue Dec 19 20:29:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6587B16A40F for ; Tue, 19 Dec 2006 20:29:40 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32E4743CA7 for ; Tue, 19 Dec 2006 20:29:31 +0000 (GMT) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kBJKTUjx010338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 19 Dec 2006 12:29:30 -0800 X-Auth-Received: from [128.208.5.22] (shiina.dyn.cs.washington.edu [128.208.5.22]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kBJKTU9H030899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 19 Dec 2006 12:29:30 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <9ab217670612191201y47b7bb3codf979f88f56e81cc@mail.gmail.com> References: <790a9fff0612190915va75678at895efa0bc93ac3a1@mail.gmail.com> <458843B8.1060704@u.washington.edu> <9ab217670612191201y47b7bb3codf979f88f56e81cc@mail.gmail.com> X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6EBDAA3A-A78C-4AA2-B9B7-E94C5C7DB186@u.washington.edu> Content-Transfer-Encoding: 7bit From: Garrett Cooper Date: Tue, 19 Dec 2006 12:29:35 -0800 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.752.2) X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.19.121432 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Subject: Re: settimeofday function taking 24 - 30 minutes to complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2006 20:29:40 -0000 On Dec 19, 2006, at 12:01 PM, Devon H. O'Dell wrote: > 2006/12/19, Garrett Cooper : >> Scot Hetzel wrote: >> > While working on implementing the settimeofday function in the >> > linuxolator, I was using the LTP testcase settimeofday01 to test >> it. >> > Running this test caused the system to hang for 24-30 minutes. >> > >> > I then decided to rewrite the testcase so that it would run on >> > FreeBSD, and it also hung the system for 24-30 minutes. What the >> > settimeofday01 test was doing is to set the time to a known >> value (100 >> > sec, 100 usec) and then use gettimeofday to retrieve the current >> time. >> > It then compared the returned value to check if it was within >> +/- 500 >> > msec. >> > >> > I have since reduced the testcode down to the following testcase >> that >> > is causing the hang. >> > >> > Any ideals as to what could be causing this hang? >> > >> > Scot >> > >> > #include >> > #include >> > #include >> > >> > #define VAL_SEC 100 >> > #define VAL_MSEC 100 >> > >> > int main(int argc, char **argv) >> > { >> > struct timeval tp, tp1, save_tv; >> > long return_test, errno_test; >> > suseconds_t delta; >> > >> > #define TEST(SCALL) \ >> > do { \ >> > errno = 0; \ >> > return_test = SCALL; \ >> > errno_test = errno; \ >> > } while (0) >> > >> > /* Save the current time values */ >> > if ((gettimeofday(&save_tv, (struct timezone *)&tp1)) == >> -1) { >> > printf("BROK: gettimeofday failed. errno=%d\n", >> errno); >> > exit(1); >> > } else { >> > printf("INFO: Saved current time\n"); >> > } >> > >> > tp.tv_sec = VAL_SEC; >> > tp.tv_usec = VAL_MSEC; >> > >> > /* Hang occurs here */ >> > TEST(settimeofday(&tp, NULL)); >> > if (return_test == -1) { >> > printf("FAIL: Error Setting Time, errno=%d\n", >> > errno_test); >> > } else { >> > printf("INFO: settimeofday completed sucessfully >> \n"); >> > } >> > >> > /* restore the original time values. */ >> > if ((settimeofday(&save_tv, NULL)) == -1) { >> > printf("WARN: FATAL COULD NOT RESET THE CLOCK\n"); >> > printf("FAIL: Error Setting Time, errno=%d (%d, % >> d)\n", >> > errno, tp.tv_sec, tp.tv_usec); >> > } else { >> > printf("INFO: Reset time to original value\n"); >> > } >> > >> > return(0); >> > } >> > >> Not sure about why it takes so long to complete, but it seems >> as if >> the system is 'hanging' because it probably is using up all of >> your CPU >> resources in the while loop under your TEST macro. Maybe the near >> 100% >> CPU usage is effecting kernel operations as well, i.e. slowing it >> down >> to stone age speeds? sleep(3)/nanosleep(2) to the rescue? > > The while loop in the TEST macro is a do { /* ... */ } while (0); so > it should only execute once. > > --Devon Comes back near instantly, unsuccessful as a regular user and successful as superuser under OS X. Trying linux now.. -Garrett PS You didn't include stdio.h or stdlib.h and the compiler (gcc) complained quite a bit. From owner-freebsd-current@FreeBSD.ORG Tue Dec 19 20:30:20 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DD09916A415 for ; Tue, 19 Dec 2006 20:30:19 +0000 (UTC) (envelope-from devon.odell@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A75A43CA4 for ; Tue, 19 Dec 2006 20:30:11 +0000 (GMT) (envelope-from devon.odell@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so1045963pyh for ; Tue, 19 Dec 2006 12:30:10 -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=Xk8UNwZsG/OCUdZKRUoa9OSfwg1X65ae/TqE3fgpjsVeho11khglwL5PdYYAGi/c2Bpqd9yPjRF7iS/7rIGt4x7gJciaFsZ1Gpt8tG8t/t1WbhmaAengBYboW0Ld8D0EN1G5GWHD0E0QB+ph3/WaSpieWG+hAvA0TlJhNXdQvBs= Received: by 10.35.9.15 with SMTP id m15mr10935235pyi.1166558497166; Tue, 19 Dec 2006 12:01:37 -0800 (PST) Received: by 10.108.12.19 with HTTP; Tue, 19 Dec 2006 12:01:37 -0800 (PST) Message-ID: <9ab217670612191201y47b7bb3codf979f88f56e81cc@mail.gmail.com> Date: Tue, 19 Dec 2006 15:01:37 -0500 From: "Devon H. O'Dell" To: "Garrett Cooper" In-Reply-To: <458843B8.1060704@u.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <790a9fff0612190915va75678at895efa0bc93ac3a1@mail.gmail.com> <458843B8.1060704@u.washington.edu> Cc: freebsd-current@freebsd.org Subject: Re: settimeofday function taking 24 - 30 minutes to complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2006 20:30:20 -0000 2006/12/19, Garrett Cooper : > Scot Hetzel wrote: > > While working on implementing the settimeofday function in the > > linuxolator, I was using the LTP testcase settimeofday01 to test it. > > Running this test caused the system to hang for 24-30 minutes. > > > > I then decided to rewrite the testcase so that it would run on > > FreeBSD, and it also hung the system for 24-30 minutes. What the > > settimeofday01 test was doing is to set the time to a known value (100 > > sec, 100 usec) and then use gettimeofday to retrieve the current time. > > It then compared the returned value to check if it was within +/- 500 > > msec. > > > > I have since reduced the testcode down to the following testcase that > > is causing the hang. > > > > Any ideals as to what could be causing this hang? > > > > Scot > > > > #include > > #include > > #include > > > > #define VAL_SEC 100 > > #define VAL_MSEC 100 > > > > int main(int argc, char **argv) > > { > > struct timeval tp, tp1, save_tv; > > long return_test, errno_test; > > suseconds_t delta; > > > > #define TEST(SCALL) \ > > do { \ > > errno = 0; \ > > return_test = SCALL; \ > > errno_test = errno; \ > > } while (0) > > > > /* Save the current time values */ > > if ((gettimeofday(&save_tv, (struct timezone *)&tp1)) == -1) { > > printf("BROK: gettimeofday failed. errno=%d\n", errno); > > exit(1); > > } else { > > printf("INFO: Saved current time\n"); > > } > > > > tp.tv_sec = VAL_SEC; > > tp.tv_usec = VAL_MSEC; > > > > /* Hang occurs here */ > > TEST(settimeofday(&tp, NULL)); > > if (return_test == -1) { > > printf("FAIL: Error Setting Time, errno=%d\n", > > errno_test); > > } else { > > printf("INFO: settimeofday completed sucessfully\n"); > > } > > > > /* restore the original time values. */ > > if ((settimeofday(&save_tv, NULL)) == -1) { > > printf("WARN: FATAL COULD NOT RESET THE CLOCK\n"); > > printf("FAIL: Error Setting Time, errno=%d (%d, %d)\n", > > errno, tp.tv_sec, tp.tv_usec); > > } else { > > printf("INFO: Reset time to original value\n"); > > } > > > > return(0); > > } > > > Not sure about why it takes so long to complete, but it seems as if > the system is 'hanging' because it probably is using up all of your CPU > resources in the while loop under your TEST macro. Maybe the near 100% > CPU usage is effecting kernel operations as well, i.e. slowing it down > to stone age speeds? sleep(3)/nanosleep(2) to the rescue? The while loop in the TEST macro is a do { /* ... */ } while (0); so it should only execute once. --Devon > -Garrett > _______________________________________________ > 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 19 20:42:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40BD816A415 for ; Tue, 19 Dec 2006 20:42:42 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62F7443CA2 for ; Tue, 19 Dec 2006 20:42:37 +0000 (GMT) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kBJKgIiZ023974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 19 Dec 2006 12:42:18 -0800 X-Auth-Received: from [128.208.5.22] (shiina.dyn.cs.washington.edu [128.208.5.22]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kBJKgHTW032733 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 19 Dec 2006 12:42:17 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <6EBDAA3A-A78C-4AA2-B9B7-E94C5C7DB186@u.washington.edu> References: <790a9fff0612190915va75678at895efa0bc93ac3a1@mail.gmail.com> <458843B8.1060704@u.washington.edu> <9ab217670612191201y47b7bb3codf979f88f56e81cc@mail.gmail.com> <6EBDAA3A-A78C-4AA2-B9B7-E94C5C7DB186@u.washington.edu> X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1A4AF851-63A3-48CA-93D4-04117C6752EB@u.washington.edu> Content-Transfer-Encoding: 7bit From: Garrett Cooper Date: Tue, 19 Dec 2006 12:42:22 -0800 To: freebsd-current@freebsd.org X-Mailer: Apple Mail (2.752.2) X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.19.122432 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Subject: Re: settimeofday function taking 24 - 30 minutes to complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2006 20:42:42 -0000 On Dec 19, 2006, at 12:29 PM, Garrett Cooper wrote: > On Dec 19, 2006, at 12:01 PM, Devon H. O'Dell wrote: > >> 2006/12/19, Garrett Cooper : >>> Scot Hetzel wrote: >>> > While working on implementing the settimeofday function in the >>> > linuxolator, I was using the LTP testcase settimeofday01 to >>> test it. >>> > Running this test caused the system to hang for 24-30 minutes. >>> > >>> > I then decided to rewrite the testcase so that it would run on >>> > FreeBSD, and it also hung the system for 24-30 minutes. What the >>> > settimeofday01 test was doing is to set the time to a known >>> value (100 >>> > sec, 100 usec) and then use gettimeofday to retrieve the >>> current time. >>> > It then compared the returned value to check if it was within >>> +/- 500 >>> > msec. >>> > >>> > I have since reduced the testcode down to the following >>> testcase that >>> > is causing the hang. >>> > >>> > Any ideals as to what could be causing this hang? >>> > >>> > Scot >>> > >>> > #include >>> > #include >>> > #include >>> > >>> > #define VAL_SEC 100 >>> > #define VAL_MSEC 100 >>> > >>> > int main(int argc, char **argv) >>> > { >>> > struct timeval tp, tp1, save_tv; >>> > long return_test, errno_test; >>> > suseconds_t delta; >>> > >>> > #define TEST(SCALL) \ >>> > do { \ >>> > errno = 0; \ >>> > return_test = SCALL; \ >>> > errno_test = errno; \ >>> > } while (0) >>> > >>> > /* Save the current time values */ >>> > if ((gettimeofday(&save_tv, (struct timezone *)&tp1)) == >>> -1) { >>> > printf("BROK: gettimeofday failed. errno=%d\n", >>> errno); >>> > exit(1); >>> > } else { >>> > printf("INFO: Saved current time\n"); >>> > } >>> > >>> > tp.tv_sec = VAL_SEC; >>> > tp.tv_usec = VAL_MSEC; >>> > >>> > /* Hang occurs here */ >>> > TEST(settimeofday(&tp, NULL)); >>> > if (return_test == -1) { >>> > printf("FAIL: Error Setting Time, errno=%d\n", >>> > errno_test); >>> > } else { >>> > printf("INFO: settimeofday completed sucessfully >>> \n"); >>> > } >>> > >>> > /* restore the original time values. */ >>> > if ((settimeofday(&save_tv, NULL)) == -1) { >>> > printf("WARN: FATAL COULD NOT RESET THE CLOCK\n"); >>> > printf("FAIL: Error Setting Time, errno=%d (%d, % >>> d)\n", >>> > errno, tp.tv_sec, tp.tv_usec); >>> > } else { >>> > printf("INFO: Reset time to original value\n"); >>> > } >>> > >>> > return(0); >>> > } >>> > >>> Not sure about why it takes so long to complete, but it seems >>> as if >>> the system is 'hanging' because it probably is using up all of >>> your CPU >>> resources in the while loop under your TEST macro. Maybe the near >>> 100% >>> CPU usage is effecting kernel operations as well, i.e. slowing it >>> down >>> to stone age speeds? sleep(3)/nanosleep(2) to the rescue? >> >> The while loop in the TEST macro is a do { /* ... */ } while (0); so >> it should only execute once. >> >> --Devon > > Comes back near instantly, unsuccessful as a regular user and > successful as superuser under OS X. Trying linux now.. > -Garrett > > PS You didn't include stdio.h or stdlib.h and the compiler (gcc) > complained quite a bit. This (slightly) modified version of the code works perfectly fine under OSX 10.4.8 and FC5: -Garrett #include #include #include #include #include #define VAL_SEC 100 #define VAL_MSEC 100 int main(int argc, char **argv) { struct timeval tp, tp1, save_tv; long return_test, errno_test; // suseconds_t delta; #define TEST(SCALL) \ do { \ errno = 0; \ return_test = SCALL; \ errno_test = errno; \ } while (0) /* Save the current time values */ if ((gettimeofday(&save_tv, (struct timezone *)&tp1)) == -1) { printf("BROK: gettimeofday failed. errno=%d\n", errno); exit(1); } else { printf("INFO: Saved current time\n"); } tp.tv_sec = VAL_SEC; tp.tv_usec = VAL_MSEC; /* Hang occurs here */ TEST(settimeofday(&tp, NULL)); if (return_test == -1) { printf("FAIL: Error Setting Time, errno=%ld\n", errno_test); } else { printf("INFO: settimeofday completed sucessfully\n"); } /* restore the original time values. */ if ((settimeofday(&save_tv, NULL)) == -1) { printf("WARN: FATAL COULD NOT RESET THE CLOCK\n"); printf("FAIL: Error Setting Time, errno=%d (%d, %d) \n", errno, tp.tv_sec, tp.tv_usec); } else { printf("INFO: Reset time to original value\n"); } return(0); } From owner-freebsd-current@FreeBSD.ORG Tue Dec 19 23:35:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C827416A417 for ; Tue, 19 Dec 2006 23:35:42 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 941D143CB3 for ; Tue, 19 Dec 2006 23:35:30 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so787494nzh for ; Tue, 19 Dec 2006 15:35:29 -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=Ipbq9eVsoXDiOW1gicFFPvayyHN2/+8zKumtHfVbiAs8zMBYMQtwuMGVJKG9Uo4mVhVdI+lxzrJtRGzZJMvPVFiyukZL17KvyS9Z5bBRUIYLBbeEq5ei41xkIu+wA33vQ2wBvGSE5d7Y4WLcBAiJxCkvA5zcckrz5C/TLzCR4O8= Received: by 10.65.219.1 with SMTP id w1mr8146424qbq.1166571329688; Tue, 19 Dec 2006 15:35:29 -0800 (PST) Received: by 10.65.61.1 with HTTP; Tue, 19 Dec 2006 15:35:29 -0800 (PST) Message-ID: <790a9fff0612191535w471f6b5eoce02d53c7aeeb976@mail.gmail.com> Date: Tue, 19 Dec 2006 17:35:29 -0600 From: "Scot Hetzel" To: "Garrett Cooper" In-Reply-To: <1A4AF851-63A3-48CA-93D4-04117C6752EB@u.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <790a9fff0612190915va75678at895efa0bc93ac3a1@mail.gmail.com> <458843B8.1060704@u.washington.edu> <9ab217670612191201y47b7bb3codf979f88f56e81cc@mail.gmail.com> <6EBDAA3A-A78C-4AA2-B9B7-E94C5C7DB186@u.washington.edu> <1A4AF851-63A3-48CA-93D4-04117C6752EB@u.washington.edu> Cc: freebsd-current@freebsd.org Subject: Re: settimeofday function taking 24 - 30 minutes to complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2006 23:35:42 -0000 On 12/19/06, Garrett Cooper wrote: > One thing though, why don't you define your macro outside main()? Didn't think about that at the time, just coppied the TEST define from one of the LTP headers, and it into the code so I wouldn't have to rewrite the entire test. On 12/19/06, Garrett Cooper wrote: > > Comes back near instantly, unsuccessful as a regular user and > > successful as superuser under OS X. Trying linux now.. > > -Garrett > > > > PS You didn't include stdio.h or stdlib.h and the compiler (gcc) > > complained quite a bit. It didn't complain when I compiled it under FreeBSD. > > This (slightly) modified version of the code works perfectly fine > under OSX 10.4.8 and FC5: Even with the addition of these headers, it still hangs the system under FreeBSD/amd64 -CURRENT. If someone could run the test program under FreeBSD/i386 and see if they get the same problem. Thanks for looking into the problem. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Tue Dec 19 23:55:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B4B0316A417 for ; Tue, 19 Dec 2006 23:55:15 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from smtp5.clear.net.nz (smtp5.clear.net.nz [203.97.33.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35CE243C9F for ; Tue, 19 Dec 2006 23:55:14 +0000 (GMT) (envelope-from markir@paradise.net.nz) Received: from [192.168.1.11] (121-72-71-65.dsl.telstraclear.net [121.72.71.65]) by smtp5.clear.net.nz (CLEAR Net Mail) with ESMTP id <0JAJ009VSOEY4720@smtp5.clear.net.nz> for freebsd-current@freebsd.org; Wed, 20 Dec 2006 12:40:11 +1300 (NZDT) Date: Wed, 20 Dec 2006 12:40:07 +1300 From: Mark Kirkwood In-reply-to: <458843B8.1060704@u.washington.edu> To: Garrett Cooper Message-id: <45887857.903@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <790a9fff0612190915va75678at895efa0bc93ac3a1@mail.gmail.com> <458843B8.1060704@u.washington.edu> User-Agent: Thunderbird 1.5.0.8 (X11/20061129) Cc: freebsd-current@freebsd.org Subject: Re: settimeofday function taking 24 - 30 minutes to complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 19 Dec 2006 23:55:15 -0000 Garrett Cooper wrote: > Scot Hetzel wrote: >> While working on implementing the settimeofday function in the >> linuxolator, I was using the LTP testcase settimeofday01 to test it. >> Running this test caused the system to hang for 24-30 minutes. >> >> I then decided to rewrite the testcase so that it would run on >> FreeBSD, and it also hung the system for 24-30 minutes. What the >> settimeofday01 test was doing is to set the time to a known value (100 >> sec, 100 usec) and then use gettimeofday to retrieve the current time. >> It then compared the returned value to check if it was within +/- 500 >> msec. >> >> I have since reduced the testcode down to the following testcase that >> is causing the hang. >> >> Any ideals as to what could be causing this hang? Just tried out this on 6-STABLE (FreeBSD 6.2-PRERELEASE #7: Mon Nov 27 19:32:33 NZDT 2006). I added #include #include to get rid of the obvious warnings (and called the beast settimetest.c). However I still get warnings you might want to look at: # gcc -Wall -O2 -o settimetest settimetest.c settimetest.c: In function `main': settimetest.c:24: warning: dereferencing type-punned pointer will break strict-aliasing rules settimetest.c:37: warning: int format, long int arg (arg 2) settimetest.c:46: warning: int format, long int arg (arg 3) settimetest.c:46: warning: int format, suseconds_t arg (arg 4) settimetest.c:14: warning: unused variable `delta' I can't get the hang at all (with or without thee extra includes): # time ./settimetest INFO: Saved current time INFO: settimeofday completed sucessfully INFO: Reset time to original value 0.000u 0.002s 0:00.00 0.0% 0+0k 0+0io 0pf+0w Cheers Mark From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 00:03:08 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A0A616A403 for ; Wed, 20 Dec 2006 00:03:08 +0000 (UTC) (envelope-from markir@paradise.net.nz) Received: from smtp5.clear.net.nz (smtp5.clear.net.nz [203.97.33.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8CB743C9F for ; Wed, 20 Dec 2006 00:03:07 +0000 (GMT) (envelope-from markir@paradise.net.nz) Received: from [192.168.1.11] (121-72-71-65.dsl.telstraclear.net [121.72.71.65]) by smtp5.clear.net.nz (CLEAR Net Mail) with ESMTP id <0JAJ009WPOS44620@smtp5.clear.net.nz> for freebsd-current@freebsd.org; Wed, 20 Dec 2006 12:48:05 +1300 (NZDT) Date: Wed, 20 Dec 2006 12:48:01 +1300 From: Mark Kirkwood In-reply-to: <45887857.903@paradise.net.nz> To: Garrett Cooper Message-id: <45887A31.4050801@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <790a9fff0612190915va75678at895efa0bc93ac3a1@mail.gmail.com> <458843B8.1060704@u.washington.edu> <45887857.903@paradise.net.nz> User-Agent: Thunderbird 1.5.0.8 (X11/20061129) Cc: freebsd-current@freebsd.org Subject: Re: settimeofday function taking 24 - 30 minutes to complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2006 00:03:08 -0000 Mark Kirkwood wrote: > Just tried out this on 6-STABLE > I can't get the hang at all (with or without thee extra includes): > > # time ./settimetest > INFO: Saved current time > INFO: settimeofday completed sucessfully > INFO: Reset time to original value > 0.000u 0.002s 0:00.00 0.0% 0+0k 0+0io 0pf+0w > Oops - thought I was reading -stable instead of -current list (doh).. sorry! Well at least you know it can work on *some* version of FreeBSD!....(I don't have any machines running -current at the moment to test). Cheers Mark From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 01:41:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4731F16A407 for ; Wed, 20 Dec 2006 01:41:10 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80AB443CB5 for ; Wed, 20 Dec 2006 01:41:07 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so798011nzh for ; Tue, 19 Dec 2006 17:41:06 -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=He65ZHPGehJ5AAJA2oIq9QLBSxBE22msn8MSZ0Bd1mHdSHkqH80U3Rys2s8aCtpvcJ5Zc+6haMH/w/S1jrvyp5Yzl/PkSFj9xV0E9u73UxT3H88eikq3R9BBIP3VKVVuAO9XWjUOcGte8cKonXZt+CzRHq0DnSVK6fOjZESFdY8= Received: by 10.65.176.3 with SMTP id d3mr8128333qbp.1166578866880; Tue, 19 Dec 2006 17:41:06 -0800 (PST) Received: by 10.65.61.1 with HTTP; Tue, 19 Dec 2006 17:41:06 -0800 (PST) Message-ID: <790a9fff0612191741r656fbbe0ic8660a9c59ba632b@mail.gmail.com> Date: Tue, 19 Dec 2006 19:41:06 -0600 From: "Scot Hetzel" To: "Mark Kirkwood" In-Reply-To: <45887A31.4050801@paradise.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <790a9fff0612190915va75678at895efa0bc93ac3a1@mail.gmail.com> <458843B8.1060704@u.washington.edu> <45887857.903@paradise.net.nz> <45887A31.4050801@paradise.net.nz> Cc: Garrett Cooper , freebsd-current@freebsd.org Subject: Re: settimeofday function taking 24 - 30 minutes to complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2006 01:41:10 -0000 On 12/19/06, Mark Kirkwood wrote: > Mark Kirkwood wrote: > > > Just tried out this on 6-STABLE > > > I can't get the hang at all (with or without thee extra includes): > > > > # time ./settimetest > > INFO: Saved current time > > INFO: settimeofday completed sucessfully > > INFO: Reset time to original value > > 0.000u 0.002s 0:00.00 0.0% 0+0k 0+0io 0pf+0w > > > > Oops - thought I was reading -stable instead of -current list > (doh).. sorry! Well at least you know it can work on *some* version of > FreeBSD!....(I don't have any machines running -current at the moment to > test). > Here's the time for the test on FreeBSD/amd64 -CURRENT, update yesterday. hp010# date ; time ./t1 ; date Tue Dec 19 19:07:33 CST 2006 INFO: Saved current time INFO: settimeofday completed sucessfully INFO: Reset time to original value 0.000u 1469.241s 0:00.00 0.0% 5+175k 0+0io 0pf+0w Tue Dec 19 19:07:33 CST 2006 hp010# date 200612191933 Tue Dec 19 19:33:00 CST 2006 Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 01:45:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A505216A407 for ; Wed, 20 Dec 2006 01:45:34 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout7.cac.washington.edu (mxout7.cac.washington.edu [140.142.32.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id F04A843CCD for ; Wed, 20 Dec 2006 01:44:57 +0000 (GMT) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139] (may be forged)) by mxout7.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kBK1ivEr026648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 19 Dec 2006 17:44:57 -0800 X-Auth-Received: from [128.208.4.96] (dzihan.cs.washington.edu [128.208.4.96]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kBK1iuKL011401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 19 Dec 2006 17:44:57 -0800 Message-ID: <45889598.3030408@u.washington.edu> Date: Tue, 19 Dec 2006 17:44:56 -0800 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.8 (X11/20061108) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <790a9fff0612190915va75678at895efa0bc93ac3a1@mail.gmail.com> <458843B8.1060704@u.washington.edu> <45887857.903@paradise.net.nz> <45887A31.4050801@paradise.net.nz> <790a9fff0612191741r656fbbe0ic8660a9c59ba632b@mail.gmail.com> In-Reply-To: <790a9fff0612191741r656fbbe0ic8660a9c59ba632b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.19.172932 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Re: settimeofday function taking 24 - 30 minutes to complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2006 01:45:34 -0000 Scot Hetzel wrote: > On 12/19/06, Mark Kirkwood wrote: >> Mark Kirkwood wrote: >> >> > Just tried out this on 6-STABLE >> >> > I can't get the hang at all (with or without thee extra includes): >> > >> > # time ./settimetest >> > INFO: Saved current time >> > INFO: settimeofday completed sucessfully >> > INFO: Reset time to original value >> > 0.000u 0.002s 0:00.00 0.0% 0+0k 0+0io 0pf+0w >> > >> >> Oops - thought I was reading -stable instead of -current list >> (doh).. sorry! Well at least you know it can work on *some* version of >> FreeBSD!....(I don't have any machines running -current at the moment to >> test). >> > > Here's the time for the test on FreeBSD/amd64 -CURRENT, update yesterday. > > hp010# date ; time ./t1 ; date > Tue Dec 19 19:07:33 CST 2006 > INFO: Saved current time > INFO: settimeofday completed sucessfully > INFO: Reset time to original value > 0.000u 1469.241s 0:00.00 0.0% 5+175k 0+0io 0pf+0w > Tue Dec 19 19:07:33 CST 2006 > hp010# date 200612191933 > Tue Dec 19 19:33:00 CST 2006 > > Scot Well, I'll find a random unused machine, setup FreeBSD on it with vmware and then try that out. Seems interesting that it takes 30 minutes to run instead of being done almost instantaneously. -Garrett From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 09:04:13 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9277716A4A0; Wed, 20 Dec 2006 09:04:13 +0000 (UTC) (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 8C46D43CA6; Wed, 20 Dec 2006 09:03:52 +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.8/8.13.8) with ESMTP id kBK8LHB5005698; Wed, 20 Dec 2006 03:21:17 -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.8/8.13.8) with ESMTP id kBK8LHw7055792; Wed, 20 Dec 2006 03:21:17 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E61F473034; Wed, 20 Dec 2006 03:21:16 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061220082116.E61F473034@freebsd-current.sentex.ca> Date: Wed, 20 Dec 2006 03:21:16 -0500 (EST) Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2006 09:04:13 -0000 TB --- 2006-12-20 07:04:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-20 07:04:45 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2006-12-20 07:04:45 - cleaning the object tree TB --- 2006-12-20 07:05:13 - checking out the source tree TB --- 2006-12-20 07:05:13 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2006-12-20 07:05:13 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-20 07:10:38 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-20 07:10:38 - cd /src TB --- 2006-12-20 07:10:38 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 20 07:10:40 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Dec 20 08:06:53 UTC 2006 TB --- 2006-12-20 08:06:53 - generating LINT kernel config TB --- 2006-12-20 08:06:53 - cd /src/sys/sun4v/conf TB --- 2006-12-20 08:06:53 - /usr/bin/make -B LINT TB --- 2006-12-20 08:06:53 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-20 08:06:53 - cd /src TB --- 2006-12-20 08:06:53 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Dec 20 08:06:54 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/hvcons.c cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/hcall.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/hviommu.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/identcpu.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/in_cksum.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/intr_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/machdep.c /src/sys/sun4v/sun4v/machdep.c:187: error: size of array `__assert187' is negative *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-20 08:21:16 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-20 08:21:16 - ERROR: failed to build lint kernel TB --- 2006-12-20 08:21:16 - tinderbox aborted TB --- 0.56 user 2.00 system 4591.32 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 09:52:00 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DAF8916A403 for ; Wed, 20 Dec 2006 09:52:00 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.239]) by mx1.FreeBSD.org (Postfix) with ESMTP id 211D443CB6 for ; Wed, 20 Dec 2006 09:51:59 +0000 (GMT) (envelope-from infofarmer@gmail.com) Received: by wr-out-0506.google.com with SMTP id i28so989488wra for ; Wed, 20 Dec 2006 01:51: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:mime-version:content-type:content-transfer-encoding:content-disposition:x-google-sender-auth; b=Jj5YZpo2MhnOw3IlHPysW0JcCBRCeoc458mlGAevJb334MKwtgkb8X+TLPW34UKkAkz8Ab1SS5CvBbe4tGLok4BJDkGz2LP8fIy77kQjJRsaKnAbBptlFpQrrV5nFbDeFYUeZlvx2gngUPCkgmefvjpelN9Pp8Iici9NNPXXzdQ= Received: by 10.78.183.15 with SMTP id g15mr4058286huf.1166606875814; Wed, 20 Dec 2006 01:27:55 -0800 (PST) Received: by 10.78.167.16 with HTTP; Wed, 20 Dec 2006 01:27:55 -0800 (PST) Message-ID: Date: Wed, 20 Dec 2006 12:27:55 +0300 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Google-Sender-Auth: b8649363b914d7a3 Cc: Subject: Laptop display stays on with lid closed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2006 09:52:00 -0000 I only noticed this now, thought it is a hardware glitch. My laptop display - and its backlight - stay on when I close the lid. Shouldn't it be turned off like in an OS-independent way?.. Anyway, mailing lists say that at least some lap- tops keep their display on with closed lid, I'm not sure about backlight though. I don't need the lid to trigger any Sx state, can I just get the display to turn off? BTW, acpi notices the lid closed event, so the trigger must be working. If not, I would appreciate a way to turn it off with some script, so that I can run it manually. My laptop is the now infamous Fujitsu-Siemens Amilo Pa 1510 [1]. [1] http://www.fujitsu-siemens.com/home/products/notebooks/amilo_pa_1510.html Thanks! From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 10:46:15 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 247FB16A416 for ; Wed, 20 Dec 2006 10:46:15 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from mail1a.your-server.co.za (mail1a.your-server.co.za [196.7.18.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92B2643CB7 for ; Wed, 20 Dec 2006 10:46:13 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from [192.168.2.25] (helo=hetzner.co.za) by mail1a.your-server.co.za with esmtpa (Exim 4.63) (envelope-from ) id 1GwybC-0001oh-7d for current@freebsd.org; Wed, 20 Dec 2006 12:22:58 +0200 Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1Gwyb8-0000ud-VO for current@freebsd.org; Wed, 20 Dec 2006 12:22:55 +0200 To: current@freebsd.org From: Ian FREISLICH X-Attribution: BOFH Date: Wed, 20 Dec 2006 12:22:54 +0200 Message-Id: X-Authenticated-Sender: if@hetzner.co.za X-Virus-Scanned: Clear (ClamAV 0.88.4/2360/Wed Dec 20 08:24:09 2006) Cc: Subject: packets duplicated *massively* on transmit. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2006 10:46:15 -0000 Hi I have two FreeBSD routers: FreeBSD firewall1 7.0-CURRENT FreeBSD 7.0-CURRENT #7: Wed May 17 14:27:51 SAST 2006 ianf:/usr/obj/usr/src/sys/FIREWALL i386 FreeBSD firewall2 7.0-CURRENT FreeBSD 7.0-CURRENT #8: Fri Sep 1 08:32:04 SAST 2006 ianf:/usr/obj/usr/src/sys/FIREWALL i386 In two reasonably busy datacenters. We're seeing packet loss that we traced to a packet ariving on the world-facing interface being retransmitted approximately every 10 microseconds or so for 1 to 5 seconds out of the interface the client is on. Example trace: Incoming packet on re0 1166597152.957627 00:02:85:07:32:40 > 00:30:4f:40:d9:cf, ethertype IPv4 (0x0800) , length 62: 196.40.89.191.4655 > 196.40.102.12.445: S 1714709786:1714709786(0) win 8760 Outbound packet(s) on vlan17 - parent re1 1166597153.000003 00:30:4f:40:d9:ee > 00:02:b3:d8:e7:4d, ethertype IPv4 (0x0800) , length 62: 196.40.89.191.4655 > 196.40.102.12.445: S 1714709786:1714709786(0) win 8760 1166597153.000013 00:30:4f:40:d9:ee > 00:02:b3:d8:e7:4d, ethertype IPv4 (0x0800) , length 62: 196.40.89.191.4655 > 196.40.102.12.445: S 1714709786:1714709786(0) win 8760 1166597153.000022 00:30:4f:40:d9:ee > 00:02:b3:d8:e7:4d, ethertype IPv4 (0x0800) , length 62: 196.40.89.191.4655 > 196.40.102.12.445: S 1714709786:1714709786(0) win 8760 We're seeing this on re(4) and rl(4) interfaces on firewall1 (uname above) and on em(4) interfaces on firewall2. It just transmits faster on the em(4) interfaces. Until recently, all instances I've seen so far had been SYN packets, but I've just seen the same deal with an icmp echo request. Sadly, I don't have a copy of the original packet. 1166608024.000164 00:04:23:d4:7f:b3 > 00:01:29:19:06:c2, ethertype IPv4 (0x0800) , length 98: (tos 0x0, ttl 28, id 16462, offset 0, flags [none], proto: ICMP (1 ), length: 84) 196.22.132.223 > 196.22.138.62: ICMP echo request, id 34631, seq 0, length 64 1166608024.000166 00:04:23:d4:7f:b3 > 00:01:29:19:06:c2, ethertype IPv4 (0x0800) , length 98: (tos 0x0, ttl 28, id 16462, offset 0, flags [none], proto: ICMP (1 ), length: 84) 196.22.132.223 > 196.22.138.62: ICMP echo request, id 34631, seq 0, length 64 1166608024.000167 00:04:23:d4:7f:b3 > 00:01:29:19:06:c2, ethertype IPv4 (0x0800) , length 98: (tos 0x0, ttl 28, id 16462, offset 0, flags [none], proto: ICMP (1 ), length: 84) 196.22.132.223 > 196.22.138.62: ICMP echo request, id 34631, seq 0, length 64 1166608024.000169 00:04:23:d4:7f:b3 > 00:01:29:19:06:c2, ethertype IPv4 (0x0800) , length 98: (tos 0x0, ttl 28, id 16462, offset 0, flags [none], proto: ICMP (1 ), length: 84) 196.22.132.223 > 196.22.138.62: ICMP echo request, id 34631, seq 0, length 64 Any ideas? Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 11:18:50 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA96916A40F for ; Wed, 20 Dec 2006 11:18:50 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5B1543CB4 for ; Wed, 20 Dec 2006 11:18:43 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id kBKBIdSc085239 for ; Wed, 20 Dec 2006 13:18:40 +0200 (EET) (envelope-from dmitry@atlantis.dp.ua) Date: Wed, 20 Dec 2006 13:18:39 +0200 (EET) From: Dmitry Pryanishnikov To: freebsd-current@freebsd.org In-Reply-To: <20061219175917.L84683@atlantis.atlantis.dp.ua> Message-ID: <20061220130559.P54963@atlantis.atlantis.dp.ua> References: <20061219175917.L84683@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: ddb(4) spoils kernel stack in CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2006 11:18:50 -0000 Hello! On Tue, 19 Dec 2006, Dmitry Pryanishnikov wrote: > I've tried to repeat this under the RELENG_6 as of 30-Oct (just removing > kernel options COMPAT_43TTY, COMPAT_FREEBSD6, INVARIANTS, INVARIANT_SUPPORT, > and using 'debug.kdb.enter' instead of 'debug.kdb.panic') - and kgdb unwinds > the stack even if the dump got via typing 'panic' from ddb: Today I've tried this with the fresh (20-Dec) RELENG_6 and with INVARIANTS* (so the only difference between kernel configs are CURRENT-only options COMPAT_43TTY and COMPAT_FREEBSD6). No differences - kgdb successfully unwinds the stack under RELENG_6. It seems that the following stands: > So it looks like a regression in CURRENT vs RELENG_6 (either ddb 'spoils' the > stack somehow, or kgdb fails to unwind it). Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 11:54:02 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 338ED16A407 for ; Wed, 20 Dec 2006 11:54:02 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id D8F1A43CC9 for ; Wed, 20 Dec 2006 11:53:38 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 20 Dec 2006 03:36:26 -0800 X-IronPort-AV: i="4.12,192,1165219200"; d="scan'208"; a="756954187:sNHT107764914" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kBKBaPZW026277 for ; Wed, 20 Dec 2006 03:36:25 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id kBKBaPjU005513 for ; Wed, 20 Dec 2006 03:36:25 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 03:35:54 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 03:35:54 -0800 Message-ID: <45891FE9.4020700@cisco.com> Date: Wed, 20 Dec 2006 06:35:05 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Dec 2006 11:35:54.0199 (UTC) FILETIME=[022C2670:01C7242B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1013; t=1166614585; x=1167478585; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20A=20stuck=20system |Sender:=20; bh=73ekeTDEJAaFjxwON/ga1n0NNXBhYAhlfD5b7bXGC4Y=; b=WMALDA+U+FfkMDyGXbP+aB+oFopbSxY0uskVBoTyI78nj3n9gFePseF0eq2nVcQYPbAtk9sw jkCH5vofQSI7my8LIJZUzRZenQXrrrHLkz0mqJKTyBU68S8geu9Fo7A5; Authentication-Results: sj-dkim-1; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim1002 verified; ); Subject: A stuck system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2006 11:54:02 -0000 All: Ok my P4D machine is sitting hung... its in that state I mentioned previously. It will not respond to network input on the em0 card... i.e. it won't answer pings.. I have not tried the new msk0 device... its not configured up :-( Now, I know from past experience if I hit any key... it will start up again.. give out various warnings and timeouts.. sometimes a "clock ran backwards".. possibly.. and then start working fine again.. Is there anything I can try to get some information so we can figure whats going on... It could be a hardware problem... don't know... but it might not be.. it does look like a lost interupt... but thats just a stab in the dark guess.. Suggestions on anything I can try to get info would be welcome. I can do a kernel dump of course but by the time I get ctl-alt-esc in.. the machine will be running not in the hung state :-( thoughts anyone ?? R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 12:14:38 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8213F16A4A0 for ; Wed, 20 Dec 2006 12:14:38 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2B4343CAD for ; Wed, 20 Dec 2006 12:13:01 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 20 Dec 2006 04:12:50 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kBKCCoCI016727; Wed, 20 Dec 2006 04:12:50 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kBKCCmZg000178; Wed, 20 Dec 2006 04:12:48 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 04:12:48 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 04:12:47 -0800 Message-ID: <4589288E.2070509@cisco.com> Date: Wed, 20 Dec 2006 07:11:58 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo References: <45891FE9.4020700@cisco.com> <20061220040151.B88849@xorpc.icir.org> In-Reply-To: <20061220040151.B88849@xorpc.icir.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Dec 2006 12:12:47.0665 (UTC) FILETIME=[29804210:01C72430] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1991; t=1166616770; x=1167480770; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20A=20stuck=20system |Sender:=20; bh=qF4Dr/NS8mxzKhwEqR7p3ODZ37UZUB4rlHiBMXEe7/s=; b=xF3HTUj3DssHBba+X4VoXxm6UIgrf4SWwHSy+QuLbMXDFTQeoTe6Imi6A37+8doMkidPZ4nH 4c5Tlswd/yBQM6IpprUNWoZ0PN+IdxUGmy9Uc5ubI5W7mGk4ICxFfiOD; Authentication-Results: sj-dkim-2; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); Cc: freebsd-current@freebsd.org Subject: Re: A stuck system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2006 12:14:38 -0000 Luigi Rizzo wrote: > On Wed, Dec 20, 2006 at 06:35:05AM -0500, Randall Stewart wrote: > >>All: >> >>Ok my P4D machine is sitting hung... its in that >>state I mentioned previously. >> >>It will not respond to network input on the em0 card... i.e. >>it won't answer pings.. >> >>I have not tried the new msk0 device... its not configured up :-( >> >>Now, I know from past experience if I hit any key... it will >>start up again.. give out various warnings and timeouts.. sometimes >>a "clock ran backwards".. possibly.. and then >>start working fine again.. >> >>Is there anything I can try to get some information so we can >>figure whats going on... >> >>It could be a hardware problem... don't know... but >>it might not be.. it does look like a lost interupt... but >>thats just a stab in the dark guess.. > > > could you try putting a second network card in the box ? > > if you suspect it is only the 'em' card that is stuck > a second one might give you some hints on what is going on. > > or plug in some usb device and see if there is any daemon > responding to the event, etc. > > cheers > luigi > Ahh.. great Idea.. I do have a second motherboard e-net card (msk0).. that I have the driver loaded.. but just have not gotten around to enabling.. But of course thats hind site.. Let me try my USB device.. I have one of those USB-Keys that I use in meetings that work with FreeBSD.. let me see if that "revives" the system.. if so then I can get in and configure up the second network :-) drat.. idiot that I am... I moved the chasy and knocked the power cable out.. Ok I will reboot and this time before running the test that will lock it up.. I will enable the network too.. so I will have two things to try.. It will take me a few hours to hit the condition again... I will get back to you with results...sigh.. R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 12:16:30 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 17FD516A494 for ; Wed, 20 Dec 2006 12:16:30 +0000 (UTC) (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 4704443CA2 for ; Wed, 20 Dec 2006 12:16:03 +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.13.6) with ESMTP id kBKC1pDB089023; Wed, 20 Dec 2006 04:01:51 -0800 (PST) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id kBKC1pqi089022; Wed, 20 Dec 2006 04:01:51 -0800 (PST) (envelope-from rizzo) Date: Wed, 20 Dec 2006 04:01:51 -0800 From: Luigi Rizzo To: Randall Stewart Message-ID: <20061220040151.B88849@xorpc.icir.org> References: <45891FE9.4020700@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <45891FE9.4020700@cisco.com>; from rrs@cisco.com on Wed, Dec 20, 2006 at 06:35:05AM -0500 Cc: freebsd-current@freebsd.org Subject: Re: A stuck system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2006 12:16:30 -0000 On Wed, Dec 20, 2006 at 06:35:05AM -0500, Randall Stewart wrote: > All: > > Ok my P4D machine is sitting hung... its in that > state I mentioned previously. > > It will not respond to network input on the em0 card... i.e. > it won't answer pings.. > > I have not tried the new msk0 device... its not configured up :-( > > Now, I know from past experience if I hit any key... it will > start up again.. give out various warnings and timeouts.. sometimes > a "clock ran backwards".. possibly.. and then > start working fine again.. > > Is there anything I can try to get some information so we can > figure whats going on... > > It could be a hardware problem... don't know... but > it might not be.. it does look like a lost interupt... but > thats just a stab in the dark guess.. could you try putting a second network card in the box ? if you suspect it is only the 'em' card that is stuck a second one might give you some hints on what is going on. or plug in some usb device and see if there is any daemon responding to the event, etc. cheers luigi From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 12:34:03 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 329D916A40F for ; Wed, 20 Dec 2006 12:34:03 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.241]) by mx1.FreeBSD.org (Postfix) with ESMTP id C8D5C43CA7 for ; Wed, 20 Dec 2006 12:33:45 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so619557ana for ; Wed, 20 Dec 2006 04:33:44 -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=DfxxsR/E/TVJJ+ZtpxDjdLmFs2fVtl/ZpEOmoMMen/RwlJvVgiXEwdm8cJA9SneqCOpsXvxDTh2GouL1AydwuSVKBZ8VGscLD32wn755ZqmnHVjzlPpCuujisL1gD9l+UNHLKfluxu/m3iG996pqzfOl0ifPCIGYfJmHc+SoYeg= Received: by 10.100.164.14 with SMTP id m14mr5562517ane.1166618024707; Wed, 20 Dec 2006 04:33:44 -0800 (PST) Received: by 10.100.136.16 with HTTP; Wed, 20 Dec 2006 04:33:44 -0800 (PST) Message-ID: <6eb82e0612200433j6a127094v11ddebddb4455800@mail.gmail.com> Date: Wed, 20 Dec 2006 20:33:44 +0800 From: "Rong-en Fan" To: "Matthew Jacob" In-Reply-To: <7579f7fb0612190837s7c3a876er8722a97d758c3474@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6eb82e0612181734n92e4a95l9d54aeb1edae87d1@mail.gmail.com> <45878C35.3030404@samsco.org> <7579f7fb0612190837s7c3a876er8722a97d758c3474@mail.gmail.com> Cc: FreeBSD Current Subject: Re: bigdisk and scsi_da X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2006 12:34:03 -0000 On 12/20/06, Matthew Jacob wrote: > > XPT_CALC_GEOMETRY is failing when the disk is being probed. This > > is likely a problem with the MPT driver. > > static void > mpt_calc_geometry(struct ccb_calc_geometry *ccg, int extended) > { > #if __FreeBSD_version >= 500000 > cam_calc_geometry(ccg, extended); > #else > For other purpose, I compiled ddb. I got: da1 at mpt0 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-5 device da1: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enab led da1: 0MB (9261518235570798593 0 byte sectors: 0H 0S/T 0C) SMP: AP CPU #1 Launched! Fatal trap 18: integer divide fault while in kernel mode cpuid = 0; apic id = 03 instruction pointer = 0x20:0xc06a8d7b stack pointer = 0x28:0xe32498a4 frame pointer = 0x28:0xe3249928 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 = 2 (g_event) [thread pid 2 tid 100001 ] Stopped at __qdivrem+0x3b: divl %ecx,%eax db> bt Tracing pid 2 tid 100001 td 0xc46f2d80 __qdivrem(201,ffffffff,0,0,0,...) at __qdivrem+0x3b __udivdi3(201,ffffffff,0,0,c483f000,...) at __udivdi3+0x2e cam_calc_geometry(e3249a00,1,e32499b8,c04d2561,e3249a00,...) at cam_calc_geometry+0x35 mpt_calc_geometry(e3249a00,1,47258f,c46f12c0,c46f1218,...) at mpt_calc_geometry+0x18 mpt_action(c482c1c0,e3249a00,69aceab3,7c791ba0,1,...) at mpt_action+0x551 xpt_action(e3249a00,c48578b0,1,1,1d,...) at xpt_action+0x2db dasetgeom(c49ab000,10000000,200,ffffffff,c49b80f0,...) at dasetgeom+0x80 dagetcapacity(c49ab000,14c,0,e3249ab0,e3249b08,...) at dagetcapacity+0x342 daopen(c49ab180,c06cf87d,c49ab0d8,1,0,...) at daopen+0x7e g_disk_access(c49ab080,1,0,0,0,...) at g_disk_access+0x11d g_access(c4851a80,1,0,0,e3249c48,...) at g_access+0x16b g_slice_new(c06f9bc0,80,c49ab080,e3249c44,e3249c48,...) at g_slice_new+0xc0 g_gpt_taste(c06f9bc0,c49ab080,0,c49ab280,4,...) at g_gpt_taste+0x64 g_new_provider_event(c49ab080,0,0,4c,c06c5175,...) at g_new_provider_event+0x7a one_event(66666667,c46f2d80,0,e3249d00,c04f8f15,...) at one_event+0x23c g_run_events(c071f65c,0,4c,c06c5175,64,...) at g_run_events+0x15 g_event_procbody(0,e3249d38,0,0,0,...) at g_event_procbody+0xb5 fork_exit(c04f8e60,0,e3249d38) at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe3249d6c, ebp = 0 --- This is the best I can got. Since no dumpdev is defined at this point. Rong-En Fan From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 13:50:08 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 883A216A416 for ; Wed, 20 Dec 2006 13:50:08 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA0F943CB3 for ; Wed, 20 Dec 2006 13:49:55 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 20 Dec 2006 05:49:54 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id kBKDnsAB021843; Wed, 20 Dec 2006 05:49:54 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kBKDnsA4025972; Wed, 20 Dec 2006 05:49:54 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 05:49:52 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 05:49:52 -0800 Message-ID: <45893F4D.9060104@cisco.com> Date: Wed, 20 Dec 2006 08:49:01 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randall Stewart References: <45891FE9.4020700@cisco.com> <20061220040151.B88849@xorpc.icir.org> <4589288E.2070509@cisco.com> In-Reply-To: <4589288E.2070509@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Dec 2006 13:49:52.0743 (UTC) FILETIME=[B9849F70:01C7243D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2866; t=1166622594; x=1167486594; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20A=20stuck=20system |Sender:=20; bh=wRBpYnyz870n7DdFKbAVjrPw3kj+qMLN8V2M1dwHRPo=; b=H+1Cgwnh6JRefZq3CxMxPjWw2XEAuNy7nfuHIkrq39ttGVSCO1PRcG+ryCFe5Y9QSRQZbii4 4JzdOCYjM74uAVpThTNMQ4lURVn3jHgszb54Zj6rELzHaVmuDkvASq5M; Authentication-Results: sj-dkim-8; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim8002 verified; ); Cc: Luigi Rizzo , freebsd-current@freebsd.org Subject: Re: A stuck system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2006 13:50:08 -0000 Luigi: Ok, I was wrong on this... I recreated it.. hooked up my em0 card to my laptop (right now its isolated running the mpi tests and uses the loopback only). I do a ping And ta-da the system comes back to life after being hung for 15 minutes. This time I did not see any of the usual syslog messages either... of course it was only "stuck" for 15 minutes or so... I will leave the thing running and get it stuck again and validate that the msk and usb will also cause the machine to come back to life.. Is there any way this could be a lost interupt type problem (remember the scheduler is appearing to "stop" scheduling things). OR is this a problem with my hardware... somehow failing to deliver interupts maybe??? R Randall Stewart wrote: > Luigi Rizzo wrote: > >> On Wed, Dec 20, 2006 at 06:35:05AM -0500, Randall Stewart wrote: >> >>> All: >>> >>> Ok my P4D machine is sitting hung... its in that >>> state I mentioned previously. >>> >>> It will not respond to network input on the em0 card... i.e. >>> it won't answer pings.. >>> >>> I have not tried the new msk0 device... its not configured up :-( >>> >>> Now, I know from past experience if I hit any key... it will >>> start up again.. give out various warnings and timeouts.. sometimes >>> a "clock ran backwards".. possibly.. and then >>> start working fine again.. >>> >>> Is there anything I can try to get some information so we can >>> figure whats going on... >>> >>> It could be a hardware problem... don't know... but >>> it might not be.. it does look like a lost interupt... but >>> thats just a stab in the dark guess.. >> >> >> >> could you try putting a second network card in the box ? >> >> if you suspect it is only the 'em' card that is stuck >> a second one might give you some hints on what is going on. >> >> or plug in some usb device and see if there is any daemon >> responding to the event, etc. >> >> cheers >> luigi >> > Ahh.. great Idea.. I do have a second motherboard e-net card > (msk0).. that I have the driver loaded.. but just have > not gotten around to enabling.. > > But of course thats hind site.. > > Let me try my USB device.. I have one of those USB-Keys that > I use in meetings that work with FreeBSD.. let me see if that > "revives" the system.. if so then I can get in and configure up > the second network :-) > > drat.. idiot that I am... I moved the chasy and knocked the > power cable out.. > > Ok I will reboot and this time before running the test that > will lock it up.. I will enable the network too.. so I will > have two things to try.. > > It will take me a few hours to hit the condition again... > > I will get back to you with results...sigh.. > > R > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 14:03:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 792D816A403 for ; Wed, 20 Dec 2006 14:03:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC67743CA9 for ; Wed, 20 Dec 2006 14:01:52 +0000 (GMT) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.227] (helo=fw.zoral.com.ua) by relay01.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1Gx0lq-000Bl6-3V for freebsd-current@freebsd.org; Wed, 20 Dec 2006 14:42:14 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id kBKCeXMB050346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Dec 2006 14:40:33 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id kBKCeXsn067522; Wed, 20 Dec 2006 14:40:33 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id kBKCeWge067521; Wed, 20 Dec 2006 14:40:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Dec 2006 14:40:32 +0200 From: Kostik Belousov To: Dmitry Pryanishnikov Message-ID: <20061220124032.GC23698@deviant.kiev.zoral.com.ua> References: <20061219175917.L84683@atlantis.atlantis.dp.ua> <20061220130559.P54963@atlantis.atlantis.dp.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9aHjqRFB8NC1b71K" Content-Disposition: inline In-Reply-To: <20061220130559.P54963@atlantis.atlantis.dp.ua> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=ALL_TRUSTED,SPF_NEUTRAL autolearn=failed version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on fw.zoral.com.ua X-Scanner-Signature: f216f799903dddc2f9accd11d8a1fded X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 631 [Dec 20 2006] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: freebsd-current@freebsd.org Subject: Re: ddb(4) spoils kernel stack in CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2006 14:03:34 -0000 --9aHjqRFB8NC1b71K Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 20, 2006 at 01:18:39PM +0200, Dmitry Pryanishnikov wrote: >=20 > Hello! >=20 > On Tue, 19 Dec 2006, Dmitry Pryanishnikov wrote: > >I've tried to repeat this under the RELENG_6 as of 30-Oct (just removing > >kernel options COMPAT_43TTY, COMPAT_FREEBSD6, INVARIANTS,=20 > >INVARIANT_SUPPORT, > >and using 'debug.kdb.enter' instead of 'debug.kdb.panic') - and kgdb=20 > >unwinds > >the stack even if the dump got via typing 'panic' from ddb: >=20 > Today I've tried this with the fresh (20-Dec) RELENG_6 and with=20 > INVARIANTS* > (so the only difference between kernel configs are CURRENT-only options > COMPAT_43TTY and COMPAT_FREEBSD6). No differences - kgdb successfully > unwinds the stack under RELENG_6. It seems that the following stands: >=20 > >So it looks like a regression in CURRENT vs RELENG_6 (either ddb 'spoils= '=20 > >the stack somehow, or kgdb fails to unwind it). Could you further localize the problem, i.e. try to backtrace CURRENT dump by RELENG_6 kgdb and vice versa. --9aHjqRFB8NC1b71K Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFFiS9AC3+MBN1Mb4gRAvlSAKDtjEQn4EDw8vr9gg8fZ/BGw0fdHgCffsBI WN9b9WVTAijUEYiVRO+Elas= =LMby -----END PGP SIGNATURE----- --9aHjqRFB8NC1b71K-- From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 14:08:33 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A15616A610 for ; Wed, 20 Dec 2006 14:08:33 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 458A943CA2 for ; Wed, 20 Dec 2006 14:08:32 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id kBKE8Mv0082149; Wed, 20 Dec 2006 16:08:22 +0200 (EET) (envelope-from dmitry@atlantis.dp.ua) Date: Wed, 20 Dec 2006 16:08:22 +0200 (EET) From: Dmitry Pryanishnikov To: Kostik Belousov In-Reply-To: <20061220124032.GC23698@deviant.kiev.zoral.com.ua> Message-ID: <20061220151813.R91910@atlantis.atlantis.dp.ua> References: <20061219175917.L84683@atlantis.atlantis.dp.ua> <20061220130559.P54963@atlantis.atlantis.dp.ua> <20061220124032.GC23698@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: ddb(4) spoils kernel stack in CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2006 14:08:33 -0000 Hello! On Wed, 20 Dec 2006, Kostik Belousov wrote: >>> So it looks like a regression in CURRENT vs RELENG_6 (either ddb 'spoils' >>> the stack somehow, or kgdb fails to unwind it). > > Could you further localize the problem, i.e. try to backtrace CURRENT dump > by RELENG_6 kgdb and vice versa. 1. Trying to analyze CURRENT's kernel dump under RELENG_6 fails miserably. Here are the relevant pieces of 'diff -u' ('-' = output of kgdb run from CURRENT, '+' = the same kernel image and coredump, but kgdb run from RELENG_6): This GDB was configured as "i386-marcel-freebsd". +kgdb: kvm_read: invalid address (0x0) -#0 doadump () at pcpu.h:166 -166 pcpu.h: No such file or directory. - in pcpu.h +#0 0x00000000 in ?? () (kgdb) bt -#0 doadump () at pcpu.h:166 -#1 0xc04aad4c in boot (howto=260) - at /mnt3/usr/CURRENT/src/sys/kern/kern_shutdown.c:411 -#2 0xc04aaff7 in panic (fmt=0xc05ffbbf "from debugger") - at /mnt3/usr/CURRENT/src/sys/kern/kern_shutdown.c:567 -#3 0xc044238e in db_panic (addr=-1068723113, have_addr=0, count=-1, - modif=0xe4b4795c "") at /mnt3/usr/CURRENT/src/sys/ddb/db_command.c:433 -#4 0xc0442327 in db_command (last_cmdp=0xc0660a04, cmd_table=0x0) - at /mnt3/usr/CURRENT/src/sys/ddb/db_command.c:401 -#5 0xc04423e2 in db_command_loop () - at /mnt3/usr/CURRENT/src/sys/ddb/db_command.c:453 -#6 0xc044402d in db_trap (type=3, code=0) - at /mnt3/usr/CURRENT/src/sys/ddb/db_main.c:222 -#7 0xc04c96d1 in kdb_trap (type=3, code=0, tf=0x0) - at /mnt3/usr/CURRENT/src/sys/kern/subr_kdb.c:502 -#8 0xc05ddfc1 in trap (frame=0xe4b47aec) - at /mnt3/usr/CURRENT/src/sys/i386/i386/trap.c:621 -#9 0xc05ca84b in calltrap () - at /mnt3/usr/CURRENT/src/sys/i386/i386/exception.s:139 -#10 0x00000000 in ?? () -Previous frame inner to this frame (corrupt stack?) +#0 0x00000000 in ?? () 2. Alas, trying to analyze RELENG_6's kernel dump under the CURRENT gives the same behaviour: kgdb issues 'kgdb: kvm_read: invalid address (0x0)' and shows just '#0 0x00000000 in ?? ()' instead of backtrace. So, cross kernel dump analysis between RELENG_6 and CURRENT seems to be impossible now ;( Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 14:58:41 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B27FD16A412; Wed, 20 Dec 2006 14:58:41 +0000 (UTC) (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 4CD5043C9F; Wed, 20 Dec 2006 14:58:38 +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.6/8.13.6) with ESMTP id kBKEwbgu063072; Wed, 20 Dec 2006 09: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.8/8.13.8) with ESMTP id kBKEwb9E076821; Wed, 20 Dec 2006 09:58:37 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 941B173034; Wed, 20 Dec 2006 09:58:37 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061220145837.941B173034@freebsd-current.sentex.ca> Date: Wed, 20 Dec 2006 09:58:37 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2006 14:58:41 -0000 TB --- 2006-12-20 13:45:26 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-20 13:45:26 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2006-12-20 13:45:26 - cleaning the object tree TB --- 2006-12-20 13:45:56 - checking out the source tree TB --- 2006-12-20 13:45:56 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2006-12-20 13:45:56 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-20 13:54:52 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-20 13:54:52 - cd /src TB --- 2006-12-20 13:54:52 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 20 13:54:53 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Dec 20 14:47:37 UTC 2006 TB --- 2006-12-20 14:47:37 - generating LINT kernel config TB --- 2006-12-20 14:47:37 - cd /src/sys/sun4v/conf TB --- 2006-12-20 14:47:37 - /usr/bin/make -B LINT TB --- 2006-12-20 14:47:37 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-20 14:47:37 - cd /src TB --- 2006-12-20 14:47:37 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Dec 20 14:47:37 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/hvcons.c cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/hcall.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/hviommu.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/identcpu.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/in_cksum.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/intr_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/machdep.c /src/sys/sun4v/sun4v/machdep.c:187: error: size of array `__assert187' is negative *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-20 14:58:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-20 14:58:37 - ERROR: failed to build lint kernel TB --- 2006-12-20 14:58:37 - tinderbox aborted TB --- 0.44 user 1.94 system 4390.57 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 15:07:04 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C586916A407 for ; Wed, 20 Dec 2006 15:07:04 +0000 (UTC) (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 2FA0543CA2 for ; Wed, 20 Dec 2006 15:07:01 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kBKF6qlZ089516; Wed, 20 Dec 2006 08:06:58 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4589518C.3070507@samsco.org> Date: Wed, 20 Dec 2006 10:06:52 -0500 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Rong-en Fan References: <6eb82e0612181734n92e4a95l9d54aeb1edae87d1@mail.gmail.com> In-Reply-To: <6eb82e0612181734n92e4a95l9d54aeb1edae87d1@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: FreeBSD Current Subject: Re: bigdisk and scsi_da X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2006 15:07:04 -0000 Rong-en Fan wrote: > It seems to me that scsi_da.c reports the wrong size: > > da1 at mpt0 bus 0 target 0 lun 0 > da1: Fixed Direct Access SCSI-5 device > da1: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged > Queueing Enabled > da1: 0MB (1 0 byte sectors: 0H 0S/T 0C) > > While geom shows the right one: > > Geom name: da1 > Providers: > 1. Name: da1 > Mediasize: 4991221760000 (4.5T) > Sectorsize: 512 > Mode: r0w0e0 > fwsectors: 63 > fwheads: 255 > > Speaking of bigdisk, can gpt modify on-disk table on-fly? > > Regards, > Rong-En Fan Just for reference, what version of FreeBSD is this? Scott From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 15:16:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B0E8C16A415 for ; Wed, 20 Dec 2006 15:16:44 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.247]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF15243CA8 for ; Wed, 20 Dec 2006 15:16:26 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so632906ana for ; Wed, 20 Dec 2006 07:16:26 -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=MIBy/l0Ad4D28FqIs5Dl6DUsutHrGUWXZNwZSM5tkFvIwOUiwCsaq9hYnxBnK6Kj8EZyysZqlmywfit8nbKJl48VFjTwGGULIS7mfhWcQD42zYnO5WtCx63xF9uhJfO3NsCgBFKkw1R/jfRzOqw5I8ggiQ7Zx9BURC11ZTr3sCY= Received: by 10.100.7.18 with SMTP id 18mr5785075ang.1166627786165; Wed, 20 Dec 2006 07:16:26 -0800 (PST) Received: by 10.100.136.16 with HTTP; Wed, 20 Dec 2006 07:16:26 -0800 (PST) Message-ID: <6eb82e0612200716x4fcf6960t3c5fe5cab5fd0bcf@mail.gmail.com> Date: Wed, 20 Dec 2006 23:16:26 +0800 From: "Rong-en Fan" To: "Scott Long" In-Reply-To: <4589518C.3070507@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6eb82e0612181734n92e4a95l9d54aeb1edae87d1@mail.gmail.com> <4589518C.3070507@samsco.org> Cc: FreeBSD Current Subject: Re: bigdisk and scsi_da X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2006 15:16:44 -0000 On 12/20/06, Scott Long wrote: > Rong-en Fan wrote: > > It seems to me that scsi_da.c reports the wrong size: > > > > da1 at mpt0 bus 0 target 0 lun 0 > > da1: Fixed Direct Access SCSI-5 device > > da1: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged > > Queueing Enabled > > da1: 0MB (1 0 byte sectors: 0H 0S/T 0C) > > > > While geom shows the right one: > > > > Geom name: da1 > > Providers: > > 1. Name: da1 > > Mediasize: 4991221760000 (4.5T) > > Sectorsize: 512 > > Mode: r0w0e0 > > fwsectors: 63 > > fwheads: 255 > > > > Speaking of bigdisk, can gpt modify on-disk table on-fly? > > > > Regards, > > Rong-En Fan > > Just for reference, what version of FreeBSD is this? Ah, it's a 6.2-RC1. I thought I posted to stable@... > > Scott > > From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 15:25:47 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E8A216A403 for ; Wed, 20 Dec 2006 15:25:47 +0000 (UTC) (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 1225643CA2 for ; Wed, 20 Dec 2006 15:25:46 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kBKFPagP089690; Wed, 20 Dec 2006 08:25:42 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <458955F0.4020102@samsco.org> Date: Wed, 20 Dec 2006 10:25:36 -0500 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Rong-en Fan References: <6eb82e0612181734n92e4a95l9d54aeb1edae87d1@mail.gmail.com> <4589518C.3070507@samsco.org> <6eb82e0612200716x4fcf6960t3c5fe5cab5fd0bcf@mail.gmail.com> In-Reply-To: <6eb82e0612200716x4fcf6960t3c5fe5cab5fd0bcf@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: FreeBSD Current Subject: Re: bigdisk and scsi_da X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2006 15:25:47 -0000 Rong-en Fan wrote: > On 12/20/06, Scott Long wrote: >> Rong-en Fan wrote: >> > It seems to me that scsi_da.c reports the wrong size: >> > >> > da1 at mpt0 bus 0 target 0 lun 0 >> > da1: Fixed Direct Access SCSI-5 device >> > da1: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged >> > Queueing Enabled >> > da1: 0MB (1 0 byte sectors: 0H 0S/T 0C) >> > >> > While geom shows the right one: >> > >> > Geom name: da1 >> > Providers: >> > 1. Name: da1 >> > Mediasize: 4991221760000 (4.5T) >> > Sectorsize: 512 >> > Mode: r0w0e0 >> > fwsectors: 63 >> > fwheads: 255 >> > >> > Speaking of bigdisk, can gpt modify on-disk table on-fly? >> > >> > Regards, >> > Rong-En Fan >> >> Just for reference, what version of FreeBSD is this? > > Ah, it's a 6.2-RC1. I thought I posted to stable@... > Ok, it makes a whole lot more sense now. 7-CURRENT has checks to prevent the divide-by-zero. I'm still looking into the actual bug, though. Scott From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 15:43:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8AEC16A4D4 for ; Wed, 20 Dec 2006 15:43:22 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id E066043CAA for ; Wed, 20 Dec 2006 15:43:03 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from [10.7.6.254] ([63.76.235.163]) by lexi.siliconlandmark.com (8.13.3/8.13.3) with ESMTP id kBKFUMkS056639; Wed, 20 Dec 2006 10:30:22 -0500 (EST) (envelope-from andy@siliconlandmark.com) In-Reply-To: <45893F4D.9060104@cisco.com> References: <45891FE9.4020700@cisco.com> <20061220040151.B88849@xorpc.icir.org> <4589288E.2070509@cisco.com> <45893F4D.9060104@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <58281AA0-3738-490C-9EA8-7766033713A2@siliconlandmark.com> Content-Transfer-Encoding: 7bit From: Andre Guibert de Bruet Date: Wed, 20 Dec 2006 10:30:16 -0500 To: Randall Stewart X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: ClamAV 0.88.6/2360/Wed Dec 20 01:24:09 2006 on lexi.siliconlandmark.com X-Virus-Status: Clean X-Information: Please contact the ISP for more information X-SL-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-SL-SpamCheck: not spam, SpamAssassin (not cached, score=-1.458, required 6, AWL -0.00, BAYES_00 -2.60, SPF_FAIL 1.14) X-MailScanner-From: andy@siliconlandmark.com Cc: freebsd-current@freebsd.org Subject: Re: A stuck system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2006 15:43:23 -0000 On Dec 20, 2006, at 8:49 AM, Randall Stewart wrote: > Ok, I was wrong on this... I recreated it.. hooked up > my em0 card to my laptop (right now its isolated > running the mpi tests and uses the loopback only). > > I do a ping > > And ta-da the system comes back to life after > being hung for 15 minutes. > > This time I did not see any of the usual syslog messages > either... of course it was only "stuck" for 15 minutes or > so... > > I will leave the thing running and get it stuck again and > validate that the msk and usb will also cause the machine > to come back to life.. > > Is there any way this could be a lost interupt type problem (remember > the scheduler is appearing to "stop" scheduling things). OR > is this a problem with my hardware... somehow failing to > deliver interupts maybe??? I am seeing something similar on my dual Xeon system. It appears that a kernel from December 13th did not exhibit this behavior whereas one from the 16th does. I am able to "revive" the machine by pushing traf on the msk0 interface. Kernel config: http://bling.properkernel.com/freebsd/BLING Andy /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 16:10:09 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C708716A407 for ; Wed, 20 Dec 2006 16:10:09 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from farris.bafirst.com (adsl-065-081-102-002.sip.jan.bellsouth.net [65.81.102.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9574F43CBA for ; Wed, 20 Dec 2006 16:10:07 +0000 (GMT) (envelope-from eculp@encontacto.net) Received: from HOME.encontacto.net ([189.129.17.4]) by farris.bafirst.com with esmtp; Wed, 20 Dec 2006 09:57:26 -0600 id 0006D418.45895D66.0000AEA8 Received: from localhost (localhost [127.0.0.1]) (uid 80) by HOME.encontacto.net with local; Wed, 20 Dec 2006 09:57:25 -0600 id 0004AC36.45895D65.00015BD1 Received: from dsl-189-129-17-4.prod-infinitum.com.mx (dsl-189-129-17-4.prod-infinitum.com.mx [189.129.17.4]) by correo.encontacto.net (Horde MIME library) with HTTP; Wed, 20 Dec 2006 09:57:25 -0600 Message-ID: <20061220095725.sna02itekgkk4kkw@correo.encontacto.net> X-Priority: 3 (Normal) Date: Wed, 20 Dec 2006 09:57:25 -0600 From: "eculp@encontacto.net" To: freebsd-current@freebsd.org References: <6eb82e0612181734n92e4a95l9d54aeb1edae87d1@mail.gmail.com> <4589518C.3070507@samsco.org> <6eb82e0612200716x4fcf6960t3c5fe5cab5fd0bcf@mail.gmail.com> <458955F0.4020102@samsco.org> In-Reply-To: <458955F0.4020102@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.2-cvs) Subject: Can the mpt0: be rebooted on 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: Wed, 20 Dec 2006 16:10:09 -0000 The "bigdisk and scsi_da" thread reminded me of a problem that I have had since July. I have a dell server with the LSILogic 1030 Ultra4 Adapter that I haven't been able to reboot in current. I am holding on to a Jun 16 06:09:11 CDT 2006 kernel and feel that I should either install 6.2 over the old current installation or build a new current kernel and reboot assuming that the driver is working. The major problem is the some 4,000 km and a border between the the machine and I. Any update on the status of the driver or a cool solution would be appreciated. Thanks, ed From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 16:15:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F99D16A49E for ; Wed, 20 Dec 2006 16:15:15 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4780643D6A for ; Wed, 20 Dec 2006 16:14:05 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 20 Dec 2006 08:13:43 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id kBKGDhOU006272; Wed, 20 Dec 2006 08:13:43 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id kBKGDgA4008295; Wed, 20 Dec 2006 08:13:42 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 08:13:25 -0800 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Dec 2006 08:13:24 -0800 Message-ID: <458960F2.9090703@cisco.com> Date: Wed, 20 Dec 2006 11:12:34 -0500 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Guibert de Bruet References: <45891FE9.4020700@cisco.com> <20061220040151.B88849@xorpc.icir.org> <4589288E.2070509@cisco.com> <45893F4D.9060104@cisco.com> <58281AA0-3738-490C-9EA8-7766033713A2@siliconlandmark.com> In-Reply-To: <58281AA0-3738-490C-9EA8-7766033713A2@siliconlandmark.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Dec 2006 16:13:24.0958 (UTC) FILETIME=[C6CC57E0:01C72451] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2191; t=1166631223; x=1167495223; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:=20Randall=20Stewart=20 |Subject:=20Re=3A=20A=20stuck=20system |Sender:=20; bh=bysCgrvlfAmObttNFoLeOyexR58ftRduwsVJ8lUPLHI=; b=qITe0l3Y35uPoc9w2jIcZYyOmFMk13wze6+UUoVaK/QnD5ulpFlXJ1xjfPEA8WYk6Qdtl/r4 U5yR71Xd46GxfGPZj/QkmpcImaFlroMre1d/ZXhH8joaJlKFi4Q8me6L; Authentication-Results: sj-dkim-5; header.From=rrs@cisco.com; dkim=pass (sig from cisco.com/sjdkim5002 verified; ); Cc: freebsd-current@freebsd.org Subject: Re: A stuck system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2006 16:15:15 -0000 Interesting.. I have actually been having this problem for a while... can't remember when I last updated.. its related to pounding the network.. at least mine seems to be... (I am pounding the loopback).. and it appears that everything just "freezes". Is your machine a Gig-a-Byte motherboard? R Andre Guibert de Bruet wrote: > > > On Dec 20, 2006, at 8:49 AM, Randall Stewart wrote: > >> Ok, I was wrong on this... I recreated it.. hooked up >> my em0 card to my laptop (right now its isolated >> running the mpi tests and uses the loopback only). >> >> I do a ping >> >> And ta-da the system comes back to life after >> being hung for 15 minutes. >> >> This time I did not see any of the usual syslog messages >> either... of course it was only "stuck" for 15 minutes or >> so... >> >> I will leave the thing running and get it stuck again and >> validate that the msk and usb will also cause the machine >> to come back to life.. >> >> Is there any way this could be a lost interupt type problem (remember >> the scheduler is appearing to "stop" scheduling things). OR >> is this a problem with my hardware... somehow failing to >> deliver interupts maybe??? > > > I am seeing something similar on my dual Xeon system. It appears that a > kernel from December 13th did not exhibit this behavior whereas one > from the 16th does. I am able to "revive" the machine by pushing traf > on the msk0 interface. > > Kernel config: http://bling.properkernel.com/freebsd/BLING > > Andy > > /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ > /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ > /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ > /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 803-317-4952 (cell) From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 16:19:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D73716A541 for ; Wed, 20 Dec 2006 16:19:01 +0000 (UTC) (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 E627443CA6 for ; Wed, 20 Dec 2006 16:17:52 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kBKGHN1f090150; Wed, 20 Dec 2006 09:17:29 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <45896213.2020600@samsco.org> Date: Wed, 20 Dec 2006 11:17:23 -0500 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: "eculp@encontacto.net" References: <6eb82e0612181734n92e4a95l9d54aeb1edae87d1@mail.gmail.com> <4589518C.3070507@samsco.org> <6eb82e0612200716x4fcf6960t3c5fe5cab5fd0bcf@mail.gmail.com> <458955F0.4020102@samsco.org> <20061220095725.sna02itekgkk4kkw@correo.encontacto.net> In-Reply-To: <20061220095725.sna02itekgkk4kkw@correo.encontacto.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: Can the mpt0: be rebooted on 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: Wed, 20 Dec 2006 16:19:01 -0000 eculp@encontacto.net wrote: > The "bigdisk and scsi_da" thread reminded me of a problem that I have > had since July. I have a dell server with the LSILogic 1030 Ultra4 > Adapter that I haven't been able to reboot in current. I am holding on > to a Jun 16 06:09:11 CDT 2006 kernel and feel that I should either > install 6.2 over the old current installation or build a new current > kernel and reboot assuming that the driver is working. > > The major problem is the some 4,000 km and a border between the the > machine and I. Any update on the status of the driver or a cool > solution would be appreciated. > > Thanks, > > ed > Um, you forgot to say what the problem is that you're concerned about. Scott From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 16:42:59 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8320716A407 for ; Wed, 20 Dec 2006 16:42:59 +0000 (UTC) (envelope-from toxahost@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFC1B43CB6 for ; Wed, 20 Dec 2006 16:42:49 +0000 (GMT) (envelope-from toxahost@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so641969ana for ; Wed, 20 Dec 2006 08:42:49 -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:references; b=mw8WZozcd+NzR7xjO+Rzozx6G+KsYvquEpkhJ5Hd5amluk0tp+sRMDlj+34dJQI2yW1QJ/th7RWGXM3hRxDOEEHZkWvY4rL3S41EGAStPTF7KuFW50SBDUSSEFpw59tbhuhFxfCBLlj36z5Pbi1hkeaMtRt6DdSxBO+vPfZL1DQ= Received: by 10.100.125.5 with SMTP id x5mr5923002anc.1166631212862; Wed, 20 Dec 2006 08:13:32 -0800 (PST) Received: by 10.100.138.7 with HTTP; Wed, 20 Dec 2006 08:13:32 -0800 (PST) Message-ID: Date: Wed, 20 Dec 2006 19:13:32 +0300 From: "Anton Karpov" To: "Andrew Pantyukhin" In-Reply-To: MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: Laptop display stays on with lid closed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2006 16:42:59 -0000 2006/12/20, Andrew Pantyukhin : > > I only noticed this now, thought it is a hardware > glitch. My laptop display - and its backlight - > stay on when I close the lid. Shouldn't it be > turned off like in an OS-independent way?.. > > Anyway, mailing lists say that at least some lap- > tops keep their display on with closed lid, I'm > not sure about backlight though. I don't need the > lid to trigger any Sx state, can I just get the > display to turn off? BTW, acpi notices the lid > closed event, so the trigger must be working. > > If not, I would appreciate a way to turn it off > with some script, so that I can run it manually. # sysctl -w hw.acpi.lid_switch_state= for ex, hw.acpi.lid_switch_state=S5 powering down my VAIO. From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 17:04:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E22D16A47B for ; Wed, 20 Dec 2006 17:04:12 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C32443CA0 for ; Wed, 20 Dec 2006 17:01:05 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so643375ana for ; Wed, 20 Dec 2006 09:01:05 -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=Sc5D+4Y1khH+yw1dp5Ud8U7hy/D3pQ47IL+WZSzG4llar2TAxlL8xQUEjPbkvU2MjycAnH7Xf4Gh/ylc42TpYCewcwqGowHCA9mt2bCqF+9HhUiutSKGRBW5dGXhkXZwrwr9n/0UbRdwmVgSCZu30Ar0kPRn0g5GmamFKHbC/kE= Received: by 10.100.94.3 with SMTP id r3mr6011609anb.1166634065303; Wed, 20 Dec 2006 09:01:05 -0800 (PST) Received: by 10.100.136.16 with HTTP; Wed, 20 Dec 2006 09:01:05 -0800 (PST) Message-ID: <6eb82e0612200901i7a95ad49sd5b0ea66db72939b@mail.gmail.com> Date: Thu, 21 Dec 2006 01:01:05 +0800 From: "Rong-en Fan" To: "Scott Long" In-Reply-To: <458955F0.4020102@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6eb82e0612181734n92e4a95l9d54aeb1edae87d1@mail.gmail.com> <4589518C.3070507@samsco.org> <6eb82e0612200716x4fcf6960t3c5fe5cab5fd0bcf@mail.gmail.com> <458955F0.4020102@samsco.org> Cc: FreeBSD Current , mjacob@freebsd.org Subject: Re: bigdisk and scsi_da X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2006 17:04:12 -0000 On 12/20/06, Scott Long wrote: > Rong-en Fan wrote: > > On 12/20/06, Scott Long wrote: > >> Rong-en Fan wrote: > >> > It seems to me that scsi_da.c reports the wrong size: > >> > > >> > da1 at mpt0 bus 0 target 0 lun 0 > >> > da1: Fixed Direct Access SCSI-5 device > >> > da1: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged > >> > Queueing Enabled > >> > da1: 0MB (1 0 byte sectors: 0H 0S/T 0C) > >> > > >> > While geom shows the right one: > >> > > >> > Geom name: da1 > >> > Providers: > >> > 1. Name: da1 > >> > Mediasize: 4991221760000 (4.5T) > >> > Sectorsize: 512 > >> > Mode: r0w0e0 > >> > fwsectors: 63 > >> > fwheads: 255 > >> > > >> > Speaking of bigdisk, can gpt modify on-disk table on-fly? > >> > > >> > Regards, > >> > Rong-En Fan > >> > >> Just for reference, what version of FreeBSD is this? > > > > Ah, it's a 6.2-RC1. I thought I posted to stable@... > > > > Ok, it makes a whole lot more sense now. 7-CURRENT has checks to > prevent the divide-by-zero. I'm still looking into the actual > bug, though. OK. Manually backports rev 1.10 of sys/dev/cam/cam.c solved this divided by zero problem. Could you or mjacob MFC this to RELENG_6 and/or RELENG_6_2? Thanks, Rong-En Fan > > Scott > > From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 17:06:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F33A16A403 for ; Wed, 20 Dec 2006 17:06:44 +0000 (UTC) (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 2675E43CAF for ; Wed, 20 Dec 2006 17:06:41 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [127.0.0.1] (pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id kBKH6Y4u090561; Wed, 20 Dec 2006 10:06:40 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <45896D9A.4070204@samsco.org> Date: Wed, 20 Dec 2006 12:06:34 -0500 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.7) Gecko/20060910 SeaMonkey/1.0.5 MIME-Version: 1.0 To: Rong-en Fan References: <6eb82e0612181734n92e4a95l9d54aeb1edae87d1@mail.gmail.com> <4589518C.3070507@samsco.org> <6eb82e0612200716x4fcf6960t3c5fe5cab5fd0bcf@mail.gmail.com> <458955F0.4020102@samsco.org> <6eb82e0612200901i7a95ad49sd5b0ea66db72939b@mail.gmail.com> In-Reply-To: <6eb82e0612200901i7a95ad49sd5b0ea66db72939b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: FreeBSD Current , mjacob@freebsd.org Subject: Re: bigdisk and scsi_da X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2006 17:06:44 -0000 Rong-en Fan wrote: > On 12/20/06, Scott Long wrote: >> Rong-en Fan wrote: >> > On 12/20/06, Scott Long wrote: >> >> Rong-en Fan wrote: >> >> > It seems to me that scsi_da.c reports the wrong size: >> >> > >> >> > da1 at mpt0 bus 0 target 0 lun 0 >> >> > da1: Fixed Direct Access SCSI-5 device >> >> > da1: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged >> >> > Queueing Enabled >> >> > da1: 0MB (1 0 byte sectors: 0H 0S/T 0C) >> >> > >> >> > While geom shows the right one: >> >> > >> >> > Geom name: da1 >> >> > Providers: >> >> > 1. Name: da1 >> >> > Mediasize: 4991221760000 (4.5T) >> >> > Sectorsize: 512 >> >> > Mode: r0w0e0 >> >> > fwsectors: 63 >> >> > fwheads: 255 >> >> > >> >> > Speaking of bigdisk, can gpt modify on-disk table on-fly? >> >> > >> >> > Regards, >> >> > Rong-En Fan >> >> >> >> Just for reference, what version of FreeBSD is this? >> > >> > Ah, it's a 6.2-RC1. I thought I posted to stable@... >> > >> >> Ok, it makes a whole lot more sense now. 7-CURRENT has checks to >> prevent the divide-by-zero. I'm still looking into the actual >> bug, though. > > OK. Manually backports rev 1.10 of sys/dev/cam/cam.c solved this > divided by zero problem. Could you or mjacob MFC this to RELENG_6 > and/or RELENG_6_2? > > Thanks, > Rong-En Fan Does it just prevent the panic, or does it also fix the bogus display too? Scott From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 17:19:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EE66616A403 for ; Wed, 20 Dec 2006 17:19:34 +0000 (UTC) (envelope-from eculp@encontacto.net) Received: from farris.bafirst.com (adsl-065-081-102-002.sip.jan.bellsouth.net [65.81.102.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59BDD43CC1 for ; Wed, 20 Dec 2006 17:18:35 +0000 (GMT) (envelope-from eculp@encontacto.net) Received: from HOME.encontacto.net ([189.129.17.4]) by farris.bafirst.com with esmtp; Wed, 20 Dec 2006 11:18:34 -0600 id 0006D41C.4589706A.0000AF89 Received: from localhost (localhost [127.0.0.1]) (uid 80) by HOME.encontacto.net with local; Wed, 20 Dec 2006 11:18:32 -0600 id 0004AC25.45897068.000001FB Received: from dsl-189-129-17-4.prod-infinitum.com.mx (dsl-189-129-17-4.prod-infinitum.com.mx [189.129.17.4]) by correo.encontacto.net (Horde MIME library) with HTTP; Wed, 20 Dec 2006 11:18:32 -0600 Message-ID: <20061220111832.mcb8kj4veskgk0ck@correo.encontacto.net> X-Priority: 3 (Normal) Date: Wed, 20 Dec 2006 11:18:32 -0600 From: "eculp@encontacto.net" To: Scott Long References: <6eb82e0612181734n92e4a95l9d54aeb1edae87d1@mail.gmail.com> <4589518C.3070507@samsco.org> <6eb82e0612200716x4fcf6960t3c5fe5cab5fd0bcf@mail.gmail.com> <458955F0.4020102@samsco.org> <20061220095725.sna02itekgkk4kkw@correo.encontacto.net> <45896213.2020600@samsco.org> In-Reply-To: <45896213.2020600@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.2-cvs) Cc: freebsd-current@freebsd.org Subject: Re: Can the mpt0: be rebooted on 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: Wed, 20 Dec 2006 17:19:35 -0000 Quoting Scott Long : > eculp@encontacto.net wrote: >> The "bigdisk and scsi_da" thread reminded me of a problem that I =20 >> have had since July. I have a dell server with the LSILogic 1030 =20 >> Ultra4 Adapter that I haven't been able to reboot in current. I am =20 >> holding on to a Jun 16 06:09:11 CDT 2006 kernel and feel that I =20 >> should either install 6.2 over the old current installation or =20 >> build a new current kernel and reboot assuming that the driver is =20 >> working. >> >> The major problem is the some 4,000 km and a border between the the =20 >> machine and I. Any update on the status of the driver or a cool =20 >> solution would be appreciated. >> >> Thanks, >> >> ed >> > > Um, you forgot to say what the problem is that you're concerned about. Important point, Scott, thanks. a newer than the June 15th kernel that has been running without =20 problems causes or possibly now I will be able to say "caused" the mpt =20 driver to panic on boot. Here is so of the boot message copied from a laptop webcam : mpt1: [GIANT-LOCKED] mpt1: MPI Version=3D1.2.14.0 mpt1: mpt_wait_req(4) timed out mpt1: read_cfg_header timed out mpt1: mpt_wait_req(6) timed out mpt1: port 0 enable timed out mpt1: failed to enable port 0 then this repeats until the system hangs: mpt0: Address Reply: SCSI Target Command Buffer Reply @ 0xffffffffacc7a200 IOC Status Success IOCLogInfo 0x00000000 MsgLength 0x05 MsgFlags 0x00 MsgContext 0x0003005d mpt0: Reply Frame Ignored mpt0: Default Handler Called: req=3D0xffffffff80e49050:95 reply_descriptor=3Ddc913980 frame=3D0xffffffffacc7a300 mpt0: Address Reply: Thanks, ed From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 17:40:39 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8DBDC16A416 for ; Wed, 20 Dec 2006 17:40:39 +0000 (UTC) (envelope-from grafan@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66B5543CBF for ; Wed, 20 Dec 2006 17:40:25 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by an-out-0708.google.com with SMTP id c24so646097ana for ; Wed, 20 Dec 2006 09:40:25 -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=gRuOD8gqDpq7CB5gtnxwqbKhJekwDE2HBC3YCyxF38FN2MIJbggt4xLIJ7FY9K0nv201WFPh/f5f7WiEoxvfHHR6cgktjB5cGWQ1VP/vh2RRkGCDcWvRnQSZ1FCfvnJ3Uwv+WTQb/Dozfy8/qYtduvhnNPxkkEKBdMObdv+xRnY= Received: by 10.100.93.5 with SMTP id q5mr6030854anb.1166635998824; Wed, 20 Dec 2006 09:33:18 -0800 (PST) Received: by 10.100.136.16 with HTTP; Wed, 20 Dec 2006 09:33:18 -0800 (PST) Message-ID: <6eb82e0612200933n4a37f0e6k7e7c1d2bf5116c36@mail.gmail.com> Date: Thu, 21 Dec 2006 01:33:18 +0800 From: "Rong-en Fan" To: "Scott Long" In-Reply-To: <45896D9A.4070204@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <6eb82e0612181734n92e4a95l9d54aeb1edae87d1@mail.gmail.com> <4589518C.3070507@samsco.org> <6eb82e0612200716x4fcf6960t3c5fe5cab5fd0bcf@mail.gmail.com> <458955F0.4020102@samsco.org> <6eb82e0612200901i7a95ad49sd5b0ea66db72939b@mail.gmail.com> <45896D9A.4070204@samsco.org> Cc: FreeBSD Current , mjacob@freebsd.org Subject: Re: bigdisk and scsi_da X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2006 17:40:39 -0000 On 12/21/06, Scott Long wrote: > Rong-en Fan wrote: > > On 12/20/06, Scott Long wrote: > >> Rong-en Fan wrote: > >> > On 12/20/06, Scott Long wrote: > >> >> Rong-en Fan wrote: > >> >> > It seems to me that scsi_da.c reports the wrong size: > >> >> > > >> >> > da1 at mpt0 bus 0 target 0 lun 0 > >> >> > da1: Fixed Direct Access SCSI-5 device > >> >> > da1: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged > >> >> > Queueing Enabled > >> >> > da1: 0MB (1 0 byte sectors: 0H 0S/T 0C) > >> >> > > >> >> > While geom shows the right one: > >> >> > > >> >> > Geom name: da1 > >> >> > Providers: > >> >> > 1. Name: da1 > >> >> > Mediasize: 4991221760000 (4.5T) > >> >> > Sectorsize: 512 > >> >> > Mode: r0w0e0 > >> >> > fwsectors: 63 > >> >> > fwheads: 255 > >> >> > > >> >> > Speaking of bigdisk, can gpt modify on-disk table on-fly? > >> >> > > >> >> > Regards, > >> >> > Rong-En Fan > >> >> > >> >> Just for reference, what version of FreeBSD is this? > >> > > >> > Ah, it's a 6.2-RC1. I thought I posted to stable@... > >> > > >> > >> Ok, it makes a whole lot more sense now. 7-CURRENT has checks to > >> prevent the divide-by-zero. I'm still looking into the actual > >> bug, though. > > > > OK. Manually backports rev 1.10 of sys/dev/cam/cam.c solved this > > divided by zero problem. Could you or mjacob MFC this to RELENG_6 > > and/or RELENG_6_2? > > > > Thanks, > > Rong-En Fan > > Does it just prevent the panic, or does it also fix the bogus display too? > > Scott > > I think it just fixes the panic. It shows: da1: 0MB (9274165917825105921 0 byte sectors: 0H 0S/T 0C) While the real sectors should be 9748480000 (reported via geom disk). Thanks Rong-En Fan From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 20:05:13 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 62DFE16A40F for ; Wed, 20 Dec 2006 20:05:13 +0000 (UTC) (envelope-from infofarmer@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8736643CBA for ; Wed, 20 Dec 2006 20:02:06 +0000 (GMT) (envelope-from infofarmer@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so2032374uge for ; Wed, 20 Dec 2006 12:01: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:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=OytPaHmoRnN5OhR5t+dqUYWvcYMjN6bM6eY7fAUC1J+swsRP7c6bGtg2WeHA7IoyQFzWlwUdFxBbuYHyzunW32EcplFRiEvn5ESjMmzd0eSmMVkkuq6t/LbKmbCTTU+RMMmzySof77OorY1qNxpkSgJpvHy3Sqg/4FSeGEu1kUo= Received: by 10.78.142.14 with SMTP id p14mr40274hud.1166644918689; Wed, 20 Dec 2006 12:01:58 -0800 (PST) Received: by 10.78.167.16 with HTTP; Wed, 20 Dec 2006 12:01:58 -0800 (PST) Message-ID: Date: Wed, 20 Dec 2006 23:01:58 +0300 From: "Andrew Pantyukhin" Sender: infofarmer@gmail.com To: current@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: 962a96abb587bafa Cc: Subject: Re: Laptop display stays on with lid closed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2006 20:05:13 -0000 On 12/20/06, Andrew Pantyukhin wrote: > I only noticed this now, thought it is a hardware > glitch. My laptop display - and its backlight - > stay on when I close the lid. Shouldn't it be > turned off like in an OS-independent way?.. To answer my own question, I ended up using a cool app named radeontool (sysutils/). Clearly, I'm lucky to have a Radeon in my laptop. Now I just have to figure out how to call a script on lid open/close event. From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 20:28:00 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C9D6216A47C for ; Wed, 20 Dec 2006 20:28:00 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8EA6F43CA5 for ; Wed, 20 Dec 2006 20:27:58 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id kBKKRmiF003299; Wed, 20 Dec 2006 22:27:49 +0200 (EET) (envelope-from dmitry@atlantis.dp.ua) Date: Wed, 20 Dec 2006 22:27:48 +0200 (EET) From: Dmitry Pryanishnikov To: Kostik Belousov In-Reply-To: <20061220124032.GC23698@deviant.kiev.zoral.com.ua> Message-ID: <20061220215753.H53808@atlantis.atlantis.dp.ua> References: <20061219175917.L84683@atlantis.atlantis.dp.ua> <20061220130559.P54963@atlantis.atlantis.dp.ua> <20061220124032.GC23698@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Kip Macy Subject: Re: ddb(4) spoils kernel stack in CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Dec 2006 20:28:00 -0000 Hello! On Wed, 20 Dec 2006, Kostik Belousov wrote: >>> So it looks like a regression in CURRENT vs RELENG_6 (either ddb 'spoils' >>> the stack somehow, or kgdb fails to unwind it). > > Could you further localize the problem, i.e. try to backtrace CURRENT dump Good news: I've managed to localize the bug! I'm Feeling Lucky (TM) ;) just because CURRENT on my notebook was updated approx. at 17-Dec 00:00, and it didn't manifest such a behaviour! So it was easy to identify the regression - it comes with the following commit: ----------------------------------------------------------------------- Date: Sun, 17 Dec 2006 05:07:01 +0000 (UTC) From: Kip Macy To: src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org Subject: cvs commit: src/sys/i386/i386 apic_vector.s exception.s local_apic.c trap.c vm86.c vm86bios.s src/sys/i386/include apicvar.h src/sys/i386/isa atpic.c atpic_vector.s icu.h kmacy 2006-12-17 05:07:01 UTC FreeBSD src repository Modified files: sys/i386/i386 apic_vector.s exception.s local_apic.c trap.c vm86.c vm86bios.s sys/i386/include apicvar.h sys/i386/isa atpic.c atpic_vector.s icu.h Log: Evidently FreeBSD has long relied on the compiler to treat structures passed by value (trap frames) as if they were in fact being passed by reference. For better or worse, this incorrect behaviour is no longer present in gcc 4.1. In this patch I convert all trapframe arguments to be explicitly pass by reference. I also remove vm86_initflags, pushing the very little work that it actually does up into vm86_prepcall. ----------------------------------------------------------------------- So kernel built from sources as of date=2006.12.17.05.00.00 gives dump with analyzable backtrace, and kernel built from sources as of date=2006.12.17.05.10.00 (which include this commit) gives dump which confuses kgdb. I believe that commit itself is correct, but kgdb contains some workaround against the old (incorrect) behaviour of the kernel, so it's the kgdb that should be fixed. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 01:03:10 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from localhost.my.domain (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 5910E16A403 for ; Thu, 21 Dec 2006 01:03:09 +0000 (UTC) (envelope-from davidxu@freebsd.org) From: David Xu To: current@freebsd.org Date: Thu, 21 Dec 2006 09:03:06 +0800 User-Agent: KMail/1.8.2 MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200612210903.06956.davidxu@freebsd.org> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: Subject: kernel trap 0 on amd64 SMP X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2006 01:03:10 -0000 very fresh -CURRENT kernel code, when rebooting, the kernel panics with trap fault 0. t43# cu -l /dev/ttyU0 Connected 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...5 5 2 2 1 1 0 0 done All buffers synced. Uptime: 38s Rebooting... cpu_reset: Stopping other CPUs kernel trap 0 with interrupts disabled Fatal trap 0: while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0xc520:0x0 stack pointer = 0x10:0xffffffff8060c538 frame pointer = 0x10:0xffffffff8060c4c0 code segment = base 0xffffffffffff8048, limit 0xfe3c0, type 0x1f = DPL 3, pres 1, long 1, def32 1, gran 1 processor eflags = IOPL = 0 current process = 10 (idle: cpu1) kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x100000077 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff803fa2b3 stack pointer = 0x10:0xffffffffa03f8910 frame pointer = 0x10:0xffffffffa03f89e0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 1 (init) kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x100000077 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff803fa2b3 stack pointer = 0x10:0xffffffffa03fd820 frame pointer = 0x10:0xffffffffa03fd8f0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 10 (idle: cpu1) kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x100000077 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff803fa2b3 stack pointer = 0x10:0xffffffffa03f84d0 frame pointer = 0x10:0xffffffffa03f85a0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 1 (init) Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x100000077 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff803fa2b3 stack pointer = 0x10:0xffffffffa03fd3e0 frame pointer = 0x10:0xffffffffa03fd4b0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 10 (idle: cpu1) kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x100000077 Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x100000077 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff803fa2b3 stack pointer = 0x10:0xffffffffa03fcfa0 frame pointer = 0x10:0xffffffffa03fd070 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 10 (idle: cpu1) kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x100000077 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff803fa2b3 stack pointer = 0x10:0xffffffffa03f7c50 frame pointer = 0x10:0xffffffffa03f7d20 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 current process = 1 (init) kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x100000077 fault code = supervisor read data, page not present instruction pointer = 0x8:0xffffffff803fa2b3 stack pointer = 0x10:0xffffffffa03fcb60 frame pointer = 0x10:0xffffffffa03fcc30 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = resume, IOPL = 0 ... repeat, until get double fault. From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 11:15:33 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4420F16A403; Thu, 21 Dec 2006 11:15:33 +0000 (UTC) (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 0049313C449; Thu, 21 Dec 2006 11:15:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBL5HeDf074222; Thu, 21 Dec 2006 00:17:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBL5HdFO079816; Thu, 21 Dec 2006 00:17:40 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id AB92673034; Thu, 21 Dec 2006 00:17:39 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061221051739.AB92673034@freebsd-current.sentex.ca> Date: Thu, 21 Dec 2006 00:17:39 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2006 11:15:33 -0000 TB --- 2006-12-21 04:05:44 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-21 04:05:44 - starting HEAD tinderbox run for i386/i386 TB --- 2006-12-21 04:05:44 - cleaning the object tree TB --- 2006-12-21 04:06:13 - checking out the source tree TB --- 2006-12-21 04:06:13 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-12-21 04:06:13 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-21 04:13:19 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-21 04:13:19 - cd /src TB --- 2006-12-21 04:13:19 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 21 04:13:21 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Dec 21 05:05:44 UTC 2006 TB --- 2006-12-21 05:05:44 - generating LINT kernel config TB --- 2006-12-21 05:05:44 - cd /src/sys/i386/conf TB --- 2006-12-21 05:05:44 - /usr/bin/make -B LINT TB --- 2006-12-21 05:05:44 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-21 05:05:44 - cd /src TB --- 2006-12-21 05:05:44 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Dec 21 05:05:44 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_futex.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_getcwd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ioctl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ipc.c /src/sys/compat/linux/linux_ipc.c: In function `linux_msgctl': /src/sys/compat/linux/linux_ipc.c:647: error: `LINUX_MSG_INFO' undeclared (first use in this function) /src/sys/compat/linux/linux_ipc.c:647: error: (Each undeclared identifier is reported only once /src/sys/compat/linux/linux_ipc.c:647: error: for each function it appears in.) *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-21 05:17:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-21 05:17:39 - ERROR: failed to build lint kernel TB --- 2006-12-21 05:17:39 - tinderbox aborted TB --- 0.64 user 1.89 system 4315.47 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 11:15:38 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EEC0616A568 for ; Thu, 21 Dec 2006 11:15:38 +0000 (UTC) (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 5950E13C428 for ; Thu, 21 Dec 2006 11:15:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id kBL1tEpi078778; Wed, 20 Dec 2006 18:55:15 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 20 Dec 2006 18:55:14 -0700 (MST) Message-Id: <20061220.185514.-345500127.imp@bsdimp.com> To: youshi10@u.washington.edu From: "M. Warner Losh" In-Reply-To: <45889598.3030408@u.washington.edu> References: <45887A31.4050801@paradise.net.nz> <790a9fff0612191741r656fbbe0ic8660a9c59ba632b@mail.gmail.com> <45889598.3030408@u.washington.edu> X-Mailer: Mew version 4.2 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]); Wed, 20 Dec 2006 18:55:15 -0700 (MST) Cc: freebsd-current@freebsd.org Subject: Re: settimeofday function taking 24 - 30 minutes to complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2006 11:15:39 -0000 In message: <45889598.3030408@u.washington.edu> Garrett Cooper writes: : Scot Hetzel wrote: : > On 12/19/06, Mark Kirkwood wrote: : >> Mark Kirkwood wrote: : >> : >> > Just tried out this on 6-STABLE : >> : >> > I can't get the hang at all (with or without thee extra includes): : >> > : >> > # time ./settimetest : >> > INFO: Saved current time : >> > INFO: settimeofday completed sucessfully : >> > INFO: Reset time to original value : >> > 0.000u 0.002s 0:00.00 0.0% 0+0k 0+0io 0pf+0w : >> > : >> : >> Oops - thought I was reading -stable instead of -current list : >> (doh).. sorry! Well at least you know it can work on *some* version of : >> FreeBSD!....(I don't have any machines running -current at the moment to : >> test). : >> : > : > Here's the time for the test on FreeBSD/amd64 -CURRENT, update yesterday. : > : > hp010# date ; time ./t1 ; date : > Tue Dec 19 19:07:33 CST 2006 : > INFO: Saved current time : > INFO: settimeofday completed sucessfully : > INFO: Reset time to original value : > 0.000u 1469.241s 0:00.00 0.0% 5+175k 0+0io 0pf+0w : > Tue Dec 19 19:07:33 CST 2006 : > hp010# date 200612191933 : > Tue Dec 19 19:33:00 CST 2006 : > : > Scot : Well, I'll find a random unused machine, setup FreeBSD on it with vmware : and then try that out. Seems interesting that it takes 30 minutes to run : instead of being done almost instantaneously. It does run almost instantly if you use a time from 2000. The date command also causes the lockup if you say 'date 1970010100140' as well. Looks like there's a loop in the kernel to do division, but I can't quite find where it is. If you have a good test setup, maybe you can do a binary search in the settimeofday code to find why a large leap backwards causes problems. Warner From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 11:17:46 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3307916A412; Thu, 21 Dec 2006 11:17:46 +0000 (UTC) (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 E791313C475; Thu, 21 Dec 2006 11:17:45 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBLBHjTO041406; Thu, 21 Dec 2006 06:17:45 -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.8/8.13.8) with ESMTP id kBLBHjwu084024; Thu, 21 Dec 2006 06:17:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2D68E73034; Thu, 21 Dec 2006 06:17:45 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061221111745.2D68E73034@freebsd-current.sentex.ca> Date: Thu, 21 Dec 2006 06:17:45 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2006 11:17:46 -0000 TB --- 2006-12-21 10:05:52 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-21 10:05:52 - starting HEAD tinderbox run for i386/i386 TB --- 2006-12-21 10:05:52 - cleaning the object tree TB --- 2006-12-21 10:06:15 - checking out the source tree TB --- 2006-12-21 10:06:15 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-12-21 10:06:15 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-21 10:13:21 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-21 10:13:21 - cd /src TB --- 2006-12-21 10:13:21 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 21 10:13:22 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Dec 21 11:05:51 UTC 2006 TB --- 2006-12-21 11:05:51 - generating LINT kernel config TB --- 2006-12-21 11:05:51 - cd /src/sys/i386/conf TB --- 2006-12-21 11:05:51 - /usr/bin/make -B LINT TB --- 2006-12-21 11:05:51 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-21 11:05:51 - cd /src TB --- 2006-12-21 11:05:51 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Dec 21 11:05:51 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_futex.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_getcwd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ioctl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ipc.c /src/sys/compat/linux/linux_ipc.c: In function `linux_msgctl': /src/sys/compat/linux/linux_ipc.c:647: error: `LINUX_MSG_INFO' undeclared (first use in this function) /src/sys/compat/linux/linux_ipc.c:647: error: (Each undeclared identifier is reported only once /src/sys/compat/linux/linux_ipc.c:647: error: for each function it appears in.) *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-21 11:17:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-21 11:17:44 - ERROR: failed to build lint kernel TB --- 2006-12-21 11:17:44 - tinderbox aborted TB --- 0.56 user 1.95 system 4312.80 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 11:21:58 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 17E3116A5AB; Thu, 21 Dec 2006 11:21:58 +0000 (UTC) (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 E871513C488; Thu, 21 Dec 2006 11:21:57 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBL4bj4n061139; Wed, 20 Dec 2006 23:37:45 -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.8/8.13.8) with ESMTP id kBL4bjl8070046; Wed, 20 Dec 2006 23:37:45 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 0F26473034; Wed, 20 Dec 2006 23:37:44 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061221043745.0F26473034@freebsd-current.sentex.ca> Date: Wed, 20 Dec 2006 23:37:44 -0500 (EST) 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: Thu, 21 Dec 2006 11:21:58 -0000 TB --- 2006-12-21 03:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-21 03:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-12-21 03:00:00 - cleaning the object tree TB --- 2006-12-21 03:00:39 - checking out the source tree TB --- 2006-12-21 03:00:39 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-12-21 03:00:39 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-21 03:09:47 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-21 03:09:47 - cd /src TB --- 2006-12-21 03:09:47 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 21 03:09:48 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Dec 21 04:25:46 UTC 2006 TB --- 2006-12-21 04:25:46 - generating LINT kernel config TB --- 2006-12-21 04:25:46 - cd /src/sys/amd64/conf TB --- 2006-12-21 04:25:46 - /usr/bin/make -B LINT TB --- 2006-12-21 04:25:46 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-21 04:25:46 - cd /src TB --- 2006-12-21 04:25:46 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Dec 21 04:25:46 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_futex.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_getcwd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ioctl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ipc.c /src/sys/compat/linux/linux_ipc.c: In function `linux_msgctl': /src/sys/compat/linux/linux_ipc.c:647: error: `LINUX_MSG_INFO' undeclared (first use in this function) /src/sys/compat/linux/linux_ipc.c:647: error: (Each undeclared identifier is reported only once /src/sys/compat/linux/linux_ipc.c:647: error: for each function it appears in.) *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-21 04:37:44 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-21 04:37:44 - ERROR: failed to build lint kernel TB --- 2006-12-21 04:37:44 - tinderbox aborted TB --- 0.77 user 2.81 system 5864.21 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 11:23:48 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B5FA716AA0F for ; Thu, 21 Dec 2006 11:23:47 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.freebsd.org (Postfix) with ESMTP id D384F13C483 for ; Thu, 21 Dec 2006 11:23:09 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) by lexi.siliconlandmark.com (8.13.3/8.13.3) with ESMTP id kBL5HF99085882; Thu, 21 Dec 2006 00:17:15 -0500 (EST) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost) by lexi.siliconlandmark.com (8.13.3/8.13.3/Submit) with ESMTP id kBL5HFZN085879; Thu, 21 Dec 2006 00:17:15 -0500 (EST) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Thu, 21 Dec 2006 00:17:15 -0500 (EST) From: Andre Guibert de Bruet To: Randall Stewart In-Reply-To: <458960F2.9090703@cisco.com> Message-ID: <20061221001522.T84036@lexi.siliconlandmark.com> References: <45891FE9.4020700@cisco.com> <20061220040151.B88849@xorpc.icir.org> <4589288E.2070509@cisco.com> <45893F4D.9060104@cisco.com> <58281AA0-3738-490C-9EA8-7766033713A2@siliconlandmark.com> <458960F2.9090703@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: ClamAV 0.88.6/2363/Wed Dec 20 19:21:44 2006 on lexi.siliconlandmark.com X-Virus-Status: Clean X-Information: Please contact the ISP for more information X-SL-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-SL-SpamCheck: not spam, SpamAssassin (not cached, score=-2.543, required 6, autolearn=not spam, AWL 0.06, BAYES_00 -2.60, SPF_HELO_PASS -0.00, SPF_PASS -0.00) X-MailScanner-From: andy@siliconlandmark.com Cc: freebsd-current@freebsd.org Subject: Re: A stuck system X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2006 11:23:48 -0000 On Wed, 20 Dec 2006, Randall Stewart wrote: > Interesting.. I have actually been having > this problem for a while... can't remember > when I last updated.. its related to pounding > the network.. at least mine seems to be... (I > am pounding the loopback).. and it appears > that everything just "freezes". > > Is your machine a Gig-a-Byte motherboard? It has an Intel SE7520BD2V motherboard in it. The dmesg of a not-so-recent current can be found in http://bling.properkernel.com/freebsd/ . Andy /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ /* WWW: siliconlandmark.com * Tormenting bytes since 1980. */ From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 11:44:32 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7DC3C16A415; Thu, 21 Dec 2006 11:44:32 +0000 (UTC) (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 3C47213C464; Thu, 21 Dec 2006 11:44:32 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBKLQ9oK044634; Wed, 20 Dec 2006 16:26:09 -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.8/8.13.8) with ESMTP id kBKLQ9QO094705; Wed, 20 Dec 2006 16:26:09 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 2758473034; Wed, 20 Dec 2006 16:26:09 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061220212609.2758473034@freebsd-current.sentex.ca> Date: Wed, 20 Dec 2006 16:26:09 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2006 11:44:32 -0000 TB --- 2006-12-20 20:15:07 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-20 20:15:07 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2006-12-20 20:15:07 - cleaning the object tree TB --- 2006-12-20 20:15:32 - checking out the source tree TB --- 2006-12-20 20:15:32 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2006-12-20 20:15:32 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-20 20:20:11 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-20 20:20:11 - cd /src TB --- 2006-12-20 20:20:11 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 20 20:20:13 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Dec 20 21:14:40 UTC 2006 TB --- 2006-12-20 21:14:40 - generating LINT kernel config TB --- 2006-12-20 21:14:40 - cd /src/sys/sun4v/conf TB --- 2006-12-20 21:14:40 - /usr/bin/make -B LINT TB --- 2006-12-20 21:14:40 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-20 21:14:40 - cd /src TB --- 2006-12-20 21:14:40 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Dec 20 21:14:40 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/hvcons.c cc -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/hcall.S cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/hviommu.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/identcpu.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sparc64/sparc64/in_cksum.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/intr_machdep.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medany -msoft-float -ffreestanding -Werror /src/sys/sun4v/sun4v/machdep.c /src/sys/sun4v/sun4v/machdep.c:187: error: size of array `__assert187' is negative *** Error code 1 Stop in /obj/sun4v/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-20 21:26:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-20 21:26:08 - ERROR: failed to build lint kernel TB --- 2006-12-20 21:26:08 - tinderbox aborted TB --- 0.48 user 1.86 system 4261.40 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 11:44:51 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F286016A40F for ; Thu, 21 Dec 2006 11:44:51 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by mx1.freebsd.org (Postfix) with ESMTP id CF09C13C45F for ; Thu, 21 Dec 2006 11:44:51 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kBL3bute014020 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 20 Dec 2006 19:37:56 -0800 X-Auth-Received: from [192.168.0.101] (dsl254-013-145.sea1.dsl.speakeasy.net [216.254.13.145]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW06.09) with ESMTP id kBL3buX4015376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 20 Dec 2006 19:37:56 -0800 Message-ID: <458A0193.1040108@u.washington.edu> Date: Wed, 20 Dec 2006 19:37:55 -0800 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.8 (X11/20061220) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <45887A31.4050801@paradise.net.nz> <790a9fff0612191741r656fbbe0ic8660a9c59ba632b@mail.gmail.com> <45889598.3030408@u.washington.edu> <20061220.185514.-345500127.imp@bsdimp.com> In-Reply-To: <20061220.185514.-345500127.imp@bsdimp.com> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-PMX-Version: 5.2.2.285561, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2006.12.20.192433 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __LINES_OF_YELLING 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Re: settimeofday function taking 24 - 30 minutes to complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2006 11:44:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 M. Warner Losh wrote: > In message: <45889598.3030408@u.washington.edu> > Garrett Cooper writes: > : Scot Hetzel wrote: > : > On 12/19/06, Mark Kirkwood wrote: > : >> Mark Kirkwood wrote: > : >> > : >> > Just tried out this on 6-STABLE > : >> > : >> > I can't get the hang at all (with or without thee extra includes): > : >> > > : >> > # time ./settimetest > : >> > INFO: Saved current time > : >> > INFO: settimeofday completed sucessfully > : >> > INFO: Reset time to original value > : >> > 0.000u 0.002s 0:00.00 0.0% 0+0k 0+0io 0pf+0w > : >> > > : >> > : >> Oops - thought I was reading -stable instead of -current list > : >> (doh).. sorry! Well at least you know it can work on *some* version of > : >> FreeBSD!....(I don't have any machines running -current at the moment to > : >> test). > : >> > : > > : > Here's the time for the test on FreeBSD/amd64 -CURRENT, update yesterday. > : > > : > hp010# date ; time ./t1 ; date > : > Tue Dec 19 19:07:33 CST 2006 > : > INFO: Saved current time > : > INFO: settimeofday completed sucessfully > : > INFO: Reset time to original value > : > 0.000u 1469.241s 0:00.00 0.0% 5+175k 0+0io 0pf+0w > : > Tue Dec 19 19:07:33 CST 2006 > : > hp010# date 200612191933 > : > Tue Dec 19 19:33:00 CST 2006 > : > > : > Scot > : Well, I'll find a random unused machine, setup FreeBSD on it with vmware > : and then try that out. Seems interesting that it takes 30 minutes to run > : instead of being done almost instantaneously. > > It does run almost instantly if you use a time from 2000. The date > command also causes the lockup if you say 'date 1970010100140' as > well. Looks like there's a loop in the kernel to do division, but I > can't quite find where it is. > > If you have a good test setup, maybe you can do a binary search in the > settimeofday code to find why a large leap backwards causes problems. > > Warner Why not just enabling debugging in the kernel and your source, and step through a much as possible using gdb to find the problem? Finally got back to installing FBSD in a virtual machine, so I could figure out where you are in current :D. The only other problem is that I don't have a 64-bit box and you do.. - -Garrett -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFigGTEnKyINQw/HARAmy4AJ46UUe0d4czoqWn0o8nUSCgFQXhawCfV4pv lbsH583vT7zn9VGSUSa+9TI= =SCBA -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 11:52:10 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7591316A415; Thu, 21 Dec 2006 11:52:10 +0000 (UTC) (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 43F4013C447; Thu, 21 Dec 2006 11:52:10 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBL2I72f043083; Wed, 20 Dec 2006 21:18:07 -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.8/8.13.8) with ESMTP id kBL2I7cw025382; Wed, 20 Dec 2006 21:18:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8200173034; Wed, 20 Dec 2006 21:18:07 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061221021807.8200173034@freebsd-current.sentex.ca> Date: Wed, 20 Dec 2006 21:18:07 -0500 (EST) 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: Thu, 21 Dec 2006 11:52:10 -0000 TB --- 2006-12-21 01:19:36 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-21 01:19:36 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2006-12-21 01:19:36 - cleaning the object tree TB --- 2006-12-21 01:20:10 - checking out the source tree TB --- 2006-12-21 01:20:10 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2006-12-21 01:20:10 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-21 01:28:21 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-21 01:28:21 - cd /src TB --- 2006-12-21 01:28:21 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 21 01:28:23 UTC 2006 >>> 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 [...] /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c: In function `bridge_getinfo_bif_ports': /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c:1154: warning: cast increases required alignment of target type /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c: In function `bridge_update_memif': /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c:1208: warning: cast increases required alignment of target type /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c: In function `bridge_getinfo_bif_addrs': /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c:1343: warning: cast increases required alignment of target type /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c: In function `bridge_update_addrs': /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c:1373: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/bsnmpd/modules/snmp_bridge. *** Error code 1 Stop in /src/usr.sbin/bsnmpd/modules. *** Error code 1 Stop in /src/usr.sbin/bsnmpd. *** 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 --- 2006-12-21 02:18:07 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-21 02:18:07 - ERROR: failed to build world TB --- 2006-12-21 02:18:07 - tinderbox aborted TB --- 0.75 user 2.29 system 3511.18 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 11:56:20 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 638D516A416; Thu, 21 Dec 2006 11:56:20 +0000 (UTC) (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 1DBDA13C467; Thu, 21 Dec 2006 11:56:20 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBL2tUUw066044; Wed, 20 Dec 2006 21:55:30 -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.8/8.13.8) with ESMTP id kBL2tU7t019017; Wed, 20 Dec 2006 21:55:30 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7365A73034; Wed, 20 Dec 2006 21:55:30 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061221025530.7365A73034@freebsd-current.sentex.ca> Date: Wed, 20 Dec 2006 21:55:30 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sun4v X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2006 11:56:20 -0000 TB --- 2006-12-21 02:02:26 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-21 02:02:26 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2006-12-21 02:02:26 - cleaning the object tree TB --- 2006-12-21 02:02:52 - checking out the source tree TB --- 2006-12-21 02:02:52 - cd /tinderbox/HEAD/sparc64/sun4v TB --- 2006-12-21 02:02:52 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-21 02:10:50 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-21 02:10:50 - cd /src TB --- 2006-12-21 02:10:50 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 21 02:10:51 UTC 2006 >>> 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 [...] /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c: In function `bridge_getinfo_bif_ports': /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c:1154: warning: cast increases required alignment of target type /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c: In function `bridge_update_memif': /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c:1208: warning: cast increases required alignment of target type /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c: In function `bridge_getinfo_bif_addrs': /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c:1343: warning: cast increases required alignment of target type /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c: In function `bridge_update_addrs': /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c:1373: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/bsnmpd/modules/snmp_bridge. *** Error code 1 Stop in /src/usr.sbin/bsnmpd/modules. *** Error code 1 Stop in /src/usr.sbin/bsnmpd. *** 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 --- 2006-12-21 02:55:30 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-21 02:55:30 - ERROR: failed to build world TB --- 2006-12-21 02:55:30 - tinderbox aborted TB --- 0.51 user 1.88 system 3183.89 real http://tinderbox.des.no/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 12:01:12 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E25816A551; Thu, 21 Dec 2006 12:01:12 +0000 (UTC) (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 335D713C462; Thu, 21 Dec 2006 12:01:12 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBL1JafI036875; Wed, 20 Dec 2006 20:19:36 -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.8/8.13.8) with ESMTP id kBL1JaCM066472; Wed, 20 Dec 2006 20:19:36 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DECE973034; Wed, 20 Dec 2006 20:19:35 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061221011935.DECE973034@freebsd-current.sentex.ca> Date: Wed, 20 Dec 2006 20:19:35 -0500 (EST) Cc: Subject: [head tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2006 12:01:12 -0000 TB --- 2006-12-21 00:03:21 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-21 00:03:21 - starting HEAD tinderbox run for ia64/ia64 TB --- 2006-12-21 00:03:21 - cleaning the object tree TB --- 2006-12-21 00:03:51 - checking out the source tree TB --- 2006-12-21 00:03:51 - cd /tinderbox/HEAD/ia64/ia64 TB --- 2006-12-21 00:03:51 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-21 00:11:24 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-21 00:11:24 - cd /src TB --- 2006-12-21 00:11:24 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 21 00:11:26 UTC 2006 >>> 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 [...] /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c: In function `bridge_getinfo_bif_ports': /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c:1154: warning: cast increases required alignment of target type /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c: In function `bridge_update_memif': /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c:1208: warning: cast increases required alignment of target type /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c: In function `bridge_getinfo_bif_addrs': /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c:1343: warning: cast increases required alignment of target type /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c: In function `bridge_update_addrs': /src/usr.sbin/bsnmpd/modules/snmp_bridge/bridge_sys.c:1373: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.sbin/bsnmpd/modules/snmp_bridge. *** Error code 1 Stop in /src/usr.sbin/bsnmpd/modules. *** Error code 1 Stop in /src/usr.sbin/bsnmpd. *** 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 --- 2006-12-21 01:19:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-21 01:19:35 - ERROR: failed to build world TB --- 2006-12-21 01:19:35 - tinderbox aborted TB --- 0.62 user 2.49 system 4574.46 real http://tinderbox.des.no/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 12:05:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7686616A403; Thu, 21 Dec 2006 12:05:44 +0000 (UTC) (envelope-from Danovitsch@vitsch.net) Received: from amsfep20-int.chello.nl (amsfep20-int.chello.nl [62.179.120.15]) by mx1.freebsd.org (Postfix) with ESMTP id 8A2BB13C45D; Thu, 21 Dec 2006 12:05:43 +0000 (UTC) (envelope-from Danovitsch@vitsch.net) Received: from Tuinhuisje.Vitsch.net ([62.195.87.223]) by amsfep11-int.chello.nl (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20061221091142.KRGQ23162.amsfep11-int.chello.nl@Tuinhuisje.Vitsch.net>; Thu, 21 Dec 2006 10:11:42 +0100 Received: from self (f187184.upc-f.chello.nl [80.56.187.184]) (authenticated bits=0) by Tuinhuisje.Vitsch.net (8.13.1/8.13.1) with ESMTP id kBL9BbhT008301; Thu, 21 Dec 2006 10:11:38 +0100 (CET) (envelope-from Danovitsch@vitsch.net) From: "Daan Vreeken [PA4DAN]" Organization: Vitsch Electronics To: "Andrew Pantyukhin" Date: Thu, 21 Dec 2006 10:11:39 +0100 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200612211011.40063.Danovitsch@vitsch.net> Cc: freebsd-current@freebsd.org Subject: Re: Laptop display stays on with lid closed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2006 12:05:44 -0000 Hi Andrew, On Wednesday 20 December 2006 21:01, Andrew Pantyukhin wrote: > On 12/20/06, Andrew Pantyukhin wrote: > > I only noticed this now, thought it is a hardware > > glitch. My laptop display - and its backlight - > > stay on when I close the lid. Shouldn't it be > > turned off like in an OS-independent way?.. > > To answer my own question, I ended up using a cool > app named radeontool (sysutils/). Clearly, I'm > lucky to have a Radeon in my laptop. Now I just > have to figure out how to call a script on lid > open/close event. Have a look at /etc/devd.conf . You should be able to add an event to it with system="ACPI" and subsystem="Lid". -- Daan From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 12:07:26 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2E1516A407; Thu, 21 Dec 2006 12:07:25 +0000 (UTC) (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 B69AB13C447; Thu, 21 Dec 2006 12:07:25 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBL5mDwb010741; Thu, 21 Dec 2006 00:48:13 -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.8/8.13.8) with ESMTP id kBL5mD06061602; Thu, 21 Dec 2006 00:48:13 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8986673034; Thu, 21 Dec 2006 00:48:13 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061221054813.8986673034@freebsd-current.sentex.ca> Date: Thu, 21 Dec 2006 00:48:13 -0500 (EST) 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: Thu, 21 Dec 2006 12:07:26 -0000 TB --- 2006-12-21 04:37:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-21 04:37:45 - starting HEAD tinderbox run for i386/pc98 TB --- 2006-12-21 04:37:45 - cleaning the object tree TB --- 2006-12-21 04:38:13 - checking out the source tree TB --- 2006-12-21 04:38:13 - cd /tinderbox/HEAD/i386/pc98 TB --- 2006-12-21 04:38:13 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-21 04:46:04 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-21 04:46:04 - cd /src TB --- 2006-12-21 04:46:04 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 21 04:46:05 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Dec 21 05:37:49 UTC 2006 TB --- 2006-12-21 05:37:49 - generating LINT kernel config TB --- 2006-12-21 05:37:49 - cd /src/sys/pc98/conf TB --- 2006-12-21 05:37:49 - /usr/bin/make -B LINT TB --- 2006-12-21 05:37:49 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-21 05:37:49 - cd /src TB --- 2006-12-21 05:37:49 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Dec 21 05:37:50 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_futex.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_getcwd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ioctl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ipc.c /src/sys/compat/linux/linux_ipc.c: In function `linux_msgctl': /src/sys/compat/linux/linux_ipc.c:647: error: `LINUX_MSG_INFO' undeclared (first use in this function) /src/sys/compat/linux/linux_ipc.c:647: error: (Each undeclared identifier is reported only once /src/sys/compat/linux/linux_ipc.c:647: error: for each function it appears in.) *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-21 05:48:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-21 05:48:13 - ERROR: failed to build lint kernel TB --- 2006-12-21 05:48:13 - tinderbox aborted TB --- 0.62 user 2.13 system 4228.11 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 12:11:55 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F75916A47B; Thu, 21 Dec 2006 12:11:55 +0000 (UTC) (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 C027913C45E; Thu, 21 Dec 2006 12:11:52 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBLAbLpa036208; Thu, 21 Dec 2006 05:37:22 -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.8/8.13.8) with ESMTP id kBLAbLZk042366; Thu, 21 Dec 2006 05:37:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8156273034; Thu, 21 Dec 2006 05:37:21 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061221103721.8156273034@freebsd-current.sentex.ca> Date: Thu, 21 Dec 2006 05:37:21 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Status: Clean 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: Thu, 21 Dec 2006 12:11:55 -0000 TB --- 2006-12-21 09:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-21 09:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-12-21 09:00:00 - cleaning the object tree TB --- 2006-12-21 09:00:43 - checking out the source tree TB --- 2006-12-21 09:00:43 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-12-21 09:00:43 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-21 09:09:59 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-21 09:09:59 - cd /src TB --- 2006-12-21 09:09:59 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 21 09:10:01 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Dec 21 10:25:19 UTC 2006 TB --- 2006-12-21 10:25:19 - generating LINT kernel config TB --- 2006-12-21 10:25:19 - cd /src/sys/amd64/conf TB --- 2006-12-21 10:25:19 - /usr/bin/make -B LINT TB --- 2006-12-21 10:25:19 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-21 10:25:19 - cd /src TB --- 2006-12-21 10:25:19 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Dec 21 10:25:19 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_futex.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_getcwd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ioctl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ipc.c /src/sys/compat/linux/linux_ipc.c: In function `linux_msgctl': /src/sys/compat/linux/linux_ipc.c:647: error: `LINUX_MSG_INFO' undeclared (first use in this function) /src/sys/compat/linux/linux_ipc.c:647: error: (Each undeclared identifier is reported only once /src/sys/compat/linux/linux_ipc.c:647: error: for each function it appears in.) *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-21 10:37:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-21 10:37:21 - ERROR: failed to build lint kernel TB --- 2006-12-21 10:37:21 - tinderbox aborted TB --- 0.79 user 2.79 system 5840.72 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 12:18:30 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8E03B16A4AB; Thu, 21 Dec 2006 12:18:30 +0000 (UTC) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.freebsd.org (Postfix) with ESMTP id 152E713C46A; Thu, 21 Dec 2006 12:18:29 +0000 (UTC) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 21281) id 5014C1CC2F; Thu, 21 Dec 2006 07:18:29 -0500 (EST) Date: Thu, 21 Dec 2006 07:18:29 -0500 From: Adam McDougall To: Andrew Pantyukhin Message-ID: <20061221121828.GE98504@egr.msu.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@freebsd.org Subject: Re: Laptop display stays on with lid closed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2006 12:18:30 -0000 On Wed, Dec 20, 2006 at 11:01:58PM +0300, Andrew Pantyukhin wrote: On 12/20/06, Andrew Pantyukhin wrote: >I only noticed this now, thought it is a hardware >glitch. My laptop display - and its backlight - >stay on when I close the lid. Shouldn't it be >turned off like in an OS-independent way?.. To answer my own question, I ended up using a cool app named radeontool (sysutils/). Clearly, I'm lucky to have a Radeon in my laptop. Now I just have to figure out how to call a script on lid open/close event. put into /etc/devd.conf and reload devd: notify 10 { match "system" "ACPI"; match "subsystem" "Lid"; action "/etc/rc.lid $notify"; }; Then in /etc/rc.lid: #!/bin/sh STAT=$1 if [ $STAT = 0x00 ]; then logger -t Lid $STAT Close at `date +'%Y%m%d %H:%M:%S'` # do something for lid close event here else logger -t Lid $STAT Open at `date +'%Y%m%d %H:%M:%S'` # do something for lid open event here fi From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 12:21:22 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8D3916A47C for ; Thu, 21 Dec 2006 12:21:22 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from mail1a.your-server.co.za (mail1a.your-server.co.za [196.7.18.227]) by mx1.freebsd.org (Postfix) with ESMTP id 43BF013C462 for ; Thu, 21 Dec 2006 12:21:22 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from [192.168.2.25] (helo=hetzner.co.za) by mail1a.your-server.co.za with esmtpa (Exim 4.63) (envelope-from ) id 1GxHa0-00077H-Mn for current@freebsd.org; Thu, 21 Dec 2006 08:39:00 +0200 Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GxHZx-0000SS-5h for current@freebsd.org; Thu, 21 Dec 2006 08:38:57 +0200 From: Ian FREISLICH In-Reply-To: Message from Ian FREISLICH of "Wed, 20 Dec 2006 12:22:54 +0200." X-Attribution: BOFH Date: Thu, 21 Dec 2006 08:38:57 +0200 Message-Id: X-Authenticated-Sender: if@hetzner.co.za X-Virus-Scanned: Clear (ClamAV 0.88.4/2363/Thu Dec 21 02:21:44 2006) Cc: current@freebsd.org Subject: Re: packets duplicated *massively* on transmit. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2006 12:21:22 -0000 Ian FREISLICH wrote: > Hi > > I have two FreeBSD routers: > > In two reasonably busy datacenters. We're seeing packet loss that > we traced to a packet ariving on the world-facing interface being > retransmitted approximately every 10 microseconds or so for 1 to 5 > seconds out of the interface the client is on. Someone has responded in private mail, but re-reading this it's possible that I didn't explain the situation too well. One packet arrives on the uplink interface. This packet is then repeated between 60000 and 1500000 times out of the other interface to the exclusion of all other traffic. It doesn't do this for every packet, just once every 500000 or so. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 12:21:23 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 988E316A40F for ; Thu, 21 Dec 2006 12:21:23 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from mail1a.your-server.co.za (mail1a.your-server.co.za [196.7.18.227]) by mx1.freebsd.org (Postfix) with ESMTP id 21E9A13C45C for ; Thu, 21 Dec 2006 12:21:23 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from [192.168.2.25] (helo=hetzner.co.za) by mail1a.your-server.co.za with esmtpa (Exim 4.63) (envelope-from ) id 1GxM1J-0007Oj-5b for current@freebsd.org; Thu, 21 Dec 2006 13:23:29 +0200 Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 4.63 (FreeBSD)) (envelope-from ) id 1GxM1I-0000sq-Py for current@freebsd.org; Thu, 21 Dec 2006 13:23:28 +0200 To: current@freebsd.org From: Ian FREISLICH X-Attribution: BOFH Date: Thu, 21 Dec 2006 13:23:28 +0200 Message-Id: X-Authenticated-Sender: if@hetzner.co.za X-Virus-Scanned: Clear (ClamAV 0.88.4/2365/Thu Dec 21 11:39:44 2006) Cc: Subject: Polling bug (was Re: packets duplicated *massively* on transmit.) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2006 12:21:23 -0000 Ian FREISLICH wrote: > Hi > > I have two FreeBSD routers: > > In two reasonably busy datacenters. We're seeing packet loss that > we traced to a packet ariving on the world-facing interface being > retransmitted approximately every 10 microseconds or so for 1 to 5 > seconds out of the interface the client is on. Someone has responded in private mail, but re-reading this it's possible that I didn't explain the situation too well. One packet arrives on the uplink interface. This packet is then repeated between 60000 and 1500000 times out of the other interface to the exclusion of all other traffic. It doesn't do this for every packet, just once every 500000 or so. I've discovered that turning polling off on the interfaces stops these retransmission storms. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 12:25:42 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7053616A416; Thu, 21 Dec 2006 12:25:42 +0000 (UTC) (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 0E9CA13C447; Thu, 21 Dec 2006 12:25:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBL0WNr6057178; Wed, 20 Dec 2006 19:32:23 -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.8/8.13.8) with ESMTP id kBL0WNSp077482; Wed, 20 Dec 2006 19:32:23 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 95DE473034; Wed, 20 Dec 2006 19:32:23 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061221003223.95DE473034@freebsd-current.sentex.ca> Date: Wed, 20 Dec 2006 19:32:23 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Status: Clean 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: Thu, 21 Dec 2006 12:25:42 -0000 TB --- 2006-12-20 23:22:07 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-20 23:22:07 - starting HEAD tinderbox run for i386/pc98 TB --- 2006-12-20 23:22:07 - cleaning the object tree TB --- 2006-12-20 23:22:44 - checking out the source tree TB --- 2006-12-20 23:22:44 - cd /tinderbox/HEAD/i386/pc98 TB --- 2006-12-20 23:22:44 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-20 23:30:39 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-20 23:30:39 - cd /src TB --- 2006-12-20 23:30:39 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 20 23:30:40 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Dec 21 00:22:12 UTC 2006 TB --- 2006-12-21 00:22:12 - generating LINT kernel config TB --- 2006-12-21 00:22:12 - cd /src/sys/pc98/conf TB --- 2006-12-21 00:22:12 - /usr/bin/make -B LINT TB --- 2006-12-21 00:22:12 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-21 00:22:12 - cd /src TB --- 2006-12-21 00:22:12 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Dec 21 00:22:12 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_futex.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_getcwd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ioctl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ipc.c /src/sys/compat/linux/linux_ipc.c: In function `linux_msgctl': /src/sys/compat/linux/linux_ipc.c:647: error: `LINUX_MSG_INFO' undeclared (first use in this function) /src/sys/compat/linux/linux_ipc.c:647: error: (Each undeclared identifier is reported only once /src/sys/compat/linux/linux_ipc.c:647: error: for each function it appears in.) *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-21 00:32:23 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-21 00:32:23 - ERROR: failed to build lint kernel TB --- 2006-12-21 00:32:23 - tinderbox aborted TB --- 0.90 user 2.72 system 4216.34 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Dec 20 17:54:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4361E16A47E for ; Wed, 20 Dec 2006 17:54:29 +0000 (UTC) (envelope-from y.pankov@irbis.net.ru) Received: from mail.irbis.net.ru (mail.irbis.net.ru [194.186.18.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4C2D43CAB for ; Wed, 20 Dec 2006 17:54:27 +0000 (GMT) (envelope-from y.pankov@irbis.net.ru) Received: from [192.168.0.64] (dial01.irbis.net.ru [192.168.0.64]) by mail.irbis.net.ru (Postfix) with ESMTP id 8B0DC62D437; Wed, 20 Dec 2006 20:41:08 +0300 (MSK) Message-ID: <458975B2.5070702@irbis.net.ru> Date: Wed, 20 Dec 2006 20:41:06 +0300 From: Yuri Pankov Organization: Irbis Telecommunications, JSC User-Agent: Thunderbird 1.5.0.8 (X11/20061220) MIME-Version: 1.0 To: Scot Hetzel References: <790a9fff0612190915va75678at895efa0bc93ac3a1@mail.gmail.com> <458843B8.1060704@u.washington.edu> <45887857.903@paradise.net.nz> <45887A31.4050801@paradise.net.nz> <790a9fff0612191741r656fbbe0ic8660a9c59ba632b@mail.gmail.com> In-Reply-To: <790a9fff0612191741r656fbbe0ic8660a9c59ba632b@mail.gmail.com> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.88.7/2361/Wed Dec 20 18:30:05 2006 on mail.irbis.net.ru X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (mail.irbis.net.ru [194.186.18.2]); Wed, 20 Dec 2006 20:41:09 +0300 (MSK) X-Mailman-Approved-At: Thu, 21 Dec 2006 12:32:38 +0000 Cc: freebsd-current@freebsd.org Subject: Re: settimeofday function taking 24 - 30 minutes to complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 20 Dec 2006 17:54:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Scot Hetzel wrote: > On 12/19/06, Mark Kirkwood wrote: >> Mark Kirkwood wrote: >> >> > Just tried out this on 6-STABLE >> >> > I can't get the hang at all (with or without thee extra includes): >> > >> > # time ./settimetest >> > INFO: Saved current time >> > INFO: settimeofday completed sucessfully >> > INFO: Reset time to original value >> > 0.000u 0.002s 0:00.00 0.0% 0+0k 0+0io 0pf+0w >> > >> >> Oops - thought I was reading -stable instead of -current list >> (doh).. sorry! Well at least you know it can work on *some* version of >> FreeBSD!....(I don't have any machines running -current at the moment to >> test). >> > > Here's the time for the test on FreeBSD/amd64 -CURRENT, update yesterday. > > hp010# date ; time ./t1 ; date > Tue Dec 19 19:07:33 CST 2006 > INFO: Saved current time > INFO: settimeofday completed sucessfully > INFO: Reset time to original value > 0.000u 1469.241s 0:00.00 0.0% 5+175k 0+0io 0pf+0w > Tue Dec 19 19:07:33 CST 2006 > hp010# date 200612191933 > Tue Dec 19 19:33:00 CST 2006 > > Scot Just tested it on FreeBSD 7.0-CURRENT/amd64 GENERIC kernel (updated Dec 16): # gcc -o t1 test.c # date ; time ./t1 ; date Wed Dec 20 20:37:26 MSK 2006 INFO: Saved current time INFO: settimeofday completed sucessfully INFO: Reset time to original value 0.002u 0.000s 0:00.00 0.0% 0+0k 0+0io 0pf+0w Wed Dec 20 20:37:26 MSK 2006 # Am I missing something? HTH, Yuri -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFiXWy/qujdvYJO6ERAiAaAKCj/kUAsFaFDMYwjIn/0kE4iEwvPQCggyqn mhxGDHZ0uJZz51uYKJaCenc= =Fmlt -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 12:33:18 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 283CA16A503; Thu, 21 Dec 2006 12:33:18 +0000 (UTC) (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 DBEA913C45C; Thu, 21 Dec 2006 12:33:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBL03LQH055496; Wed, 20 Dec 2006 19:03:21 -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.8/8.13.8) with ESMTP id kBL03LwU053745; Wed, 20 Dec 2006 19:03:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 15CFC73034; Wed, 20 Dec 2006 19:03:21 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061221000321.15CFC73034@freebsd-current.sentex.ca> Date: Wed, 20 Dec 2006 19:03:21 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner3 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2006 12:33:18 -0000 TB --- 2006-12-20 22:50:52 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-20 22:50:52 - starting HEAD tinderbox run for i386/i386 TB --- 2006-12-20 22:50:52 - cleaning the object tree TB --- 2006-12-20 22:51:24 - checking out the source tree TB --- 2006-12-20 22:51:24 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-12-20 22:51:24 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-20 22:58:33 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-20 22:58:33 - cd /src TB --- 2006-12-20 22:58:33 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 20 22:58:34 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Dec 20 23:51:23 UTC 2006 TB --- 2006-12-20 23:51:23 - generating LINT kernel config TB --- 2006-12-20 23:51:23 - cd /src/sys/i386/conf TB --- 2006-12-20 23:51:23 - /usr/bin/make -B LINT TB --- 2006-12-20 23:51:23 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-20 23:51:23 - cd /src TB --- 2006-12-20 23:51:23 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Dec 20 23:51:24 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_futex.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_getcwd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ioctl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ipc.c /src/sys/compat/linux/linux_ipc.c: In function `linux_msgctl': /src/sys/compat/linux/linux_ipc.c:647: error: `LINUX_MSG_INFO' undeclared (first use in this function) /src/sys/compat/linux/linux_ipc.c:647: error: (Each undeclared identifier is reported only once /src/sys/compat/linux/linux_ipc.c:647: error: for each function it appears in.) *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-21 00:03:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-21 00:03:20 - ERROR: failed to build lint kernel TB --- 2006-12-21 00:03:20 - tinderbox aborted TB --- 0.92 user 2.66 system 4348.53 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 12:33:21 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D66A416A508; Thu, 21 Dec 2006 12:33:21 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id C458513C45D; Thu, 21 Dec 2006 12:33:17 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id kBL4n0Xq063518; Thu, 21 Dec 2006 07:49:00 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id kBL4mxA5063517; Thu, 21 Dec 2006 07:49:00 +0300 (MSK) (envelope-from yar) Date: Thu, 21 Dec 2006 07:48:59 +0300 From: Yar Tikhiy To: Coleman Kane Message-ID: <20061221044859.GB63112@comp.chem.msu.su> References: <20061218153906.GA6910@ramen.coleyandcheryl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061218153906.GA6910@ramen.coleyandcheryl> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: UFS_GJOURNAL and ufs.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2006 12:33:21 -0000 On Mon, Dec 18, 2006 at 03:39:06PM +0000, Coleman Kane wrote: > Hello, > > I have noticed (since adding UFS journal support) that the > UFS_GJOURNAL option hasn't been added to the ufs.ko kernel > module. I've been using this (out of an effort to test as > much as possible as KLDs) and every time I upgrade my kernel > I must manually add -DUFS_GJOURNAL to the CFLAGS line in > its Makefile. > > Is there any specific reason why this can't be committed? > So far, my experience with GJOURNAL has been great testing > it both with journal+fs on the same device as well as on > two seperate devices. > > It looks like an oversight to me, but I don't want to jump > the gun on it if there is some reasonable argument to keep > it out "by default". If I understand you right, you run a custom kernel w/o UFS and load the latter as a module, don't you? If so, just add "options UFS_GJOURNAL" to your kernel config file, and the module should pick up the setting from the kernel build directory then, granted you build modules with the kernel, not with the world. IMHO CFLAGS should go away from ufs.ko's Makefile because the module should get SOFTUPDATES and UFS_DIRHASH from the kernel configuration, too. -- Yar From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 12:35:51 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2180716A640; Thu, 21 Dec 2006 12:35:51 +0000 (UTC) (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 E9B1713C442; Thu, 21 Dec 2006 12:35:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBKNM7WA053594; Wed, 20 Dec 2006 18:22:07 -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.8/8.13.8) with ESMTP id kBKNM7e3057278; Wed, 20 Dec 2006 18:22:07 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id E049E73034; Wed, 20 Dec 2006 18:22:06 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061220232206.E049E73034@freebsd-current.sentex.ca> Date: Wed, 20 Dec 2006 18:22:06 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Status: Clean 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: Thu, 21 Dec 2006 12:35:51 -0000 TB --- 2006-12-20 21:45:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-20 21:45:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-12-20 21:45:01 - cleaning the object tree TB --- 2006-12-20 21:45:47 - checking out the source tree TB --- 2006-12-20 21:45:47 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-12-20 21:45:47 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-20 21:54:55 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-20 21:54:55 - cd /src TB --- 2006-12-20 21:54:55 - /usr/bin/make -B buildworld >>> World build started on Wed Dec 20 21:54:57 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Dec 20 23:10:03 UTC 2006 TB --- 2006-12-20 23:10:03 - generating LINT kernel config TB --- 2006-12-20 23:10:03 - cd /src/sys/amd64/conf TB --- 2006-12-20 23:10:03 - /usr/bin/make -B LINT TB --- 2006-12-20 23:10:03 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-20 23:10:03 - cd /src TB --- 2006-12-20 23:10:03 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Dec 20 23:10:03 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_futex.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_getcwd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ioctl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ipc.c /src/sys/compat/linux/linux_ipc.c: In function `linux_msgctl': /src/sys/compat/linux/linux_ipc.c:647: error: `LINUX_MSG_INFO' undeclared (first use in this function) /src/sys/compat/linux/linux_ipc.c:647: error: (Each undeclared identifier is reported only once /src/sys/compat/linux/linux_ipc.c:647: error: for each function it appears in.) *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-20 23:22:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-20 23:22:06 - ERROR: failed to build lint kernel TB --- 2006-12-20 23:22:06 - tinderbox aborted TB --- 0.91 user 3.41 system 5825.44 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 12:42:02 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 787D916A415 for ; Thu, 21 Dec 2006 12:42:02 +0000 (UTC) (envelope-from toxahost@gmail.com) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by mx1.freebsd.org (Postfix) with ESMTP id 396F613C44C for ; Thu, 21 Dec 2006 12:42:02 +0000 (UTC) (envelope-from toxahost@gmail.com) Received: by an-out-0708.google.com with SMTP id b36so737556ana for ; Thu, 21 Dec 2006 04:42:01 -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:references; b=WkksWKDsWhNK+cyIHIEmUugkTCoICZNajt0bwsvaIHA8B78VCkO9+tDSQMi7h98OviwQ+NyX90aQWjBVsTrPUHsIZaYwLyfIbCsGvfTQ3eGbOOveDkOMbIc1eWmrwO5Ao2CX7su1y7j5L+cOYcCrm8TnPnR+LAw/1Ikr21+4Sc0= Received: by 10.100.31.2 with SMTP id e2mr6639867ane.1166691831979; Thu, 21 Dec 2006 01:03:51 -0800 (PST) Received: by 10.100.138.7 with HTTP; Thu, 21 Dec 2006 01:03:51 -0800 (PST) Message-ID: Date: Thu, 21 Dec 2006 12:03:51 +0300 From: "Anton Karpov" To: "Andrew Pantyukhin" In-Reply-To: MIME-Version: 1.0 References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: Laptop display stays on with lid closed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2006 12:42:02 -0000 > lucky to have a Radeon in my laptop. Now I just > have to figure out how to call a script on lid > open/close event. > > Maybe devd(8) is a right solution for this From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 13:13:08 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 659D616A504; Thu, 21 Dec 2006 13:13:08 +0000 (UTC) (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 AA7E113C460; Thu, 21 Dec 2006 13:13:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBLBmMNm046537; Thu, 21 Dec 2006 06:48:22 -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.8/8.13.8) with ESMTP id kBLBmLMB017607; Thu, 21 Dec 2006 06:48:21 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id BA22C73034; Thu, 21 Dec 2006 06:48:21 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061221114821.BA22C73034@freebsd-current.sentex.ca> Date: Thu, 21 Dec 2006 06:48:21 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Status: Clean 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: Thu, 21 Dec 2006 13:13:08 -0000 TB --- 2006-12-21 10:37:21 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-21 10:37:21 - starting HEAD tinderbox run for i386/pc98 TB --- 2006-12-21 10:37:21 - cleaning the object tree TB --- 2006-12-21 10:37:54 - checking out the source tree TB --- 2006-12-21 10:37:54 - cd /tinderbox/HEAD/i386/pc98 TB --- 2006-12-21 10:37:54 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-21 10:45:55 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-21 10:45:55 - cd /src TB --- 2006-12-21 10:45:55 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 21 10:45:56 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Dec 21 11:37:51 UTC 2006 TB --- 2006-12-21 11:37:51 - generating LINT kernel config TB --- 2006-12-21 11:37:51 - cd /src/sys/pc98/conf TB --- 2006-12-21 11:37:51 - /usr/bin/make -B LINT TB --- 2006-12-21 11:37:51 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-21 11:37:51 - cd /src TB --- 2006-12-21 11:37:51 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Dec 21 11:37:51 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_futex.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_getcwd.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ioctl.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/compat/linux/linux_ipc.c /src/sys/compat/linux/linux_ipc.c: In function `linux_msgctl': /src/sys/compat/linux/linux_ipc.c:647: error: `LINUX_MSG_INFO' undeclared (first use in this function) /src/sys/compat/linux/linux_ipc.c:647: error: (Each undeclared identifier is reported only once /src/sys/compat/linux/linux_ipc.c:647: error: for each function it appears in.) *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-21 11:48:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-21 11:48:21 - ERROR: failed to build lint kernel TB --- 2006-12-21 11:48:21 - tinderbox aborted TB --- 0.61 user 2.00 system 4259.75 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 13:32:50 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E94A916A53E for ; Thu, 21 Dec 2006 13:32:50 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id EB5AF13C501 for ; Thu, 21 Dec 2006 13:32:39 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5D6C7.dip.t-dialin.net [84.165.214.199]) by redbull.bpaserver.net (Postfix) with ESMTP id 5DF6D2E206 for ; Thu, 21 Dec 2006 14:13:33 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 5E5575B480D for ; Thu, 21 Dec 2006 14:12:42 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id kBLDCgTV050439 for freebsd-current@freebsd.org; Thu, 21 Dec 2006 14:12:42 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Thu, 21 Dec 2006 14:12:42 +0100 Message-ID: <20061221141242.uqg8blba4gkgoosk@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 21 Dec 2006 14:12:42 +0100 From: Alexander Leidinger To: freebsd-current@freebsd.org References: <20061221003223.95DE473034@freebsd-current.sentex.ca> In-Reply-To: <20061221003223.95DE473034@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.864, required 6, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Subject: Re: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2006 13:32:51 -0000 Quoting FreeBSD Tinderbox (from Wed, 20 Dec 2006 19:32:23 -0500 (EST)): > /src/sys/compat/linux/linux_ipc.c: In function `linux_msgctl': > /src/sys/compat/linux/linux_ipc.c:647: error: `LINUX_MSG_INFO' > undeclared (first use in this function) Fix committed. Bye, Alexander. -- It's amazing how much better you feel once you've given up hope. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 13:41:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 55BBF16A4CE for ; Thu, 21 Dec 2006 13:41:52 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.freebsd.org (Postfix) with ESMTP id E58B513C465 for ; Thu, 21 Dec 2006 13:41:51 +0000 (UTC) (envelope-from almarrie@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so2274719uge for ; Thu, 21 Dec 2006 05:41:51 -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=fIPhjkbhcr4/i9TCSKPwFSYoelyWHZMU8oVFqS2by/cuyCW4bPRiA0XNSYqxS8ft3SCkc94RMzk4lXnZiCLMnreiDUJKo+CdE9B97HEIUlyRfA0waqTtn2ZEIST1UBVgU7EOSxVyHpWRQryFi2JmlBGp2Oiqie73tvvp6n7M3io= Received: by 10.67.27.3 with SMTP id e3mr11851315ugj.1166685241269; Wed, 20 Dec 2006 23:14:01 -0800 (PST) Received: by 10.67.27.15 with HTTP; Wed, 20 Dec 2006 23:14:01 -0800 (PST) Message-ID: <499c70c0612202314s8b20f14q7093e8bb069d85@mail.gmail.com> Date: Thu, 21 Dec 2006 10:14:01 +0300 From: "Abdullah Al-Marrie" To: "Scot Hetzel" In-Reply-To: <790a9fff0612201531q7b07dd75p1929ae6a9b825521@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <499c70c0612201209j7ec014av3ec161a077633a2b@mail.gmail.com> <790a9fff0612201531q7b07dd75p1929ae6a9b825521@mail.gmail.com> Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: Acer Aspire 5102 WLMi with Turion 64 X2 dual-core TL-50 1.6 GHz on FreeBSD 6.2 ACPI problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2006 13:41:52 -0000 On 12/21/06, Scot Hetzel wrote: > On 12/20/06, Abdullah Al-Marrie wrote: > > Hello guys, > > > > I have problem with my new laptop Acer Aspire 5102 WLMi which has AMD > > Turion=99 64 X2 dual-core TL-50 1.6 GHz with 1.5 GB of ram. > > > > I'm running i386 6.2-RC1 upgraded to 6.2-PRELEASE via RELENG6 tag > > since I don't have more than 4 GB of ram. > > > > 1. The FreeBSD can't detect the builtin wlan chip which is Broadcom > > BCM 4318 Rev 2. > > > You need to use the Windows NDIS driver to use the Broadcom Wireless adap= ter. > > You just need to download the driver from Acer's web site, and then > use ndisgen to build the kernel module. > > Scot I tried that it's still not detected, as I mentioned before, I use linksys wpc54g pcmcia to use the wlan in home till this issue with Acer ACPI get sorted out. Thank you, -Abdullah From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 13:51:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3D99116A494 for ; Thu, 21 Dec 2006 13:51:36 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.freebsd.org (Postfix) with ESMTP id 6D6DA13C462 for ; Thu, 21 Dec 2006 13:51:35 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by ug-out-1314.google.com with SMTP id o2so2277233uge for ; Thu, 21 Dec 2006 05:51:34 -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:references; b=usNd6G22InR1I0fYHUiOQn3WcJP13cqAV/DYvMwbFvX6Qp+rGexvWnHZ7zYYOjDfbH+uUhojg2gpa+TvGTf8b2ZqLs4xFMlHuTFBsPcrd8teK+ZNmo72qnMGiMZvO93LaXN6CixBUQ16RS4pbQLn9/XoHGWzEdxtQ1Ya8aEooKg= Received: by 10.82.113.6 with SMTP id l6mr1809330buc.1166647307910; Wed, 20 Dec 2006 12:41:47 -0800 (PST) Received: by 10.82.191.16 with HTTP; Wed, 20 Dec 2006 12:41:47 -0800 (PST) Message-ID: Date: Wed, 20 Dec 2006 12:41:47 -0800 From: "Kip Macy" To: "Dmitry Pryanishnikov" In-Reply-To: <20061220215753.H53808@atlantis.atlantis.dp.ua> MIME-Version: 1.0 References: <20061219175917.L84683@atlantis.atlantis.dp.ua> <20061220130559.P54963@atlantis.atlantis.dp.ua> <20061220124032.GC23698@deviant.kiev.zoral.com.ua> <20061220215753.H53808@atlantis.atlantis.dp.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Kostik Belousov , freebsd-current@freebsd.org, Kip Macy Subject: Re: ddb(4) spoils kernel stack in CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2006 13:51:36 -0000 I worried that gdb probably had workaround for the large stack argument. I'll have to dig it up, thanks for the heads up. -Kip On 12/20/06, Dmitry Pryanishnikov wrote: > > > Hello! > > On Wed, 20 Dec 2006, Kostik Belousov wrote: > >>> So it looks like a regression in CURRENT vs RELENG_6 (either ddb > 'spoils' > >>> the stack somehow, or kgdb fails to unwind it). > > > > Could you further localize the problem, i.e. try to backtrace CURRENT > dump > > Good news: I've managed to localize the bug! I'm Feeling Lucky (TM) ;) > just because CURRENT on my notebook was updated approx. at 17-Dec 00:00, > and it didn't manifest such a behaviour! So it was easy to identify the > regression - it comes with the following commit: > > ----------------------------------------------------------------------- > > Date: Sun, 17 Dec 2006 05:07:01 +0000 (UTC) > From: Kip Macy > To: src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org > Subject: cvs commit: src/sys/i386/i386 apic_vector.s exception.slocal_apic.c > trap.c vm86.c vm86bios.s src/sys/i386/include apicvar.h > src/sys/i386/isa atpic.c atpic_vector.s icu.h > > kmacy 2006-12-17 05:07:01 UTC > > FreeBSD src repository > > Modified files: > sys/i386/i386 apic_vector.s exception.s local_apic.c > trap.c vm86.c vm86bios.s > sys/i386/include apicvar.h > sys/i386/isa atpic.c atpic_vector.s icu.h > Log: > Evidently FreeBSD has long relied on the compiler to treat structures > passed by value (trap frames) as if they were in fact being passed by > reference. For better or worse, this incorrect behaviour is no longer > present in gcc 4.1. In this patch I convert all trapframe arguments to > be explicitly pass by reference. I also remove vm86_initflags, pushing > the very little work that it actually does up into vm86_prepcall. > > ----------------------------------------------------------------------- > > So kernel built from sources as of date=2006.12.17.05.00.00 gives dump > with analyzable backtrace, and kernel built from sources as of > date=2006.12.17.05.10.00 (which include this commit) gives dump > which confuses kgdb. I believe that commit itself is correct, > but kgdb contains some workaround against the old (incorrect) behaviour > of the kernel, so it's the kgdb that should be fixed. > > Sincerely, Dmitry > -- > Atlantis ISP, System Administrator > e-mail: dmitry@atlantis.dp.ua > nic-hdl: LYNX-RIPE > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 13:53:04 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 06DBA16A407 for ; Thu, 21 Dec 2006 13:53:04 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.225]) by mx1.freebsd.org (Postfix) with ESMTP id BC18A13C45D for ; Thu, 21 Dec 2006 13:53:03 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by wx-out-0506.google.com with SMTP id s18so2314173wxc for ; Thu, 21 Dec 2006 05:53:03 -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=Df3kkmeKc0887PVq2B0V2PFkCy+3+YkODtD+e4OHh7YhJSxym3vUkbf+b2Cjy1vmEZml1QBOse7eDnxbVTmDIw5uDLfF9F9GznM33VW8MRBp8Cvl/opfwEBZZqPQL7TTrNcM5ggLQzceXV6abXBQKbFJCsLR37/fRr77x7afhDY= Received: by 10.70.40.1 with SMTP id n1mr13058969wxn.1166655499799; Wed, 20 Dec 2006 14:58:19 -0800 (PST) Received: by 10.65.61.1 with HTTP; Wed, 20 Dec 2006 14:58:19 -0800 (PST) Message-ID: <790a9fff0612201458h2ef5b88hc664c242e7993a3c@mail.gmail.com> Date: Wed, 20 Dec 2006 14:58:19 -0800 From: "Scot Hetzel" To: "Yuri Pankov" In-Reply-To: <458975B2.5070702@irbis.net.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <790a9fff0612190915va75678at895efa0bc93ac3a1@mail.gmail.com> <458843B8.1060704@u.washington.edu> <45887857.903@paradise.net.nz> <45887A31.4050801@paradise.net.nz> <790a9fff0612191741r656fbbe0ic8660a9c59ba632b@mail.gmail.com> <458975B2.5070702@irbis.net.ru> Cc: freebsd-current@freebsd.org Subject: Re: settimeofday function taking 24 - 30 minutes to complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2006 13:53:04 -0000 On 12/20/06, Yuri Pankov wrote: > Just tested it on FreeBSD 7.0-CURRENT/amd64 GENERIC kernel (updated Dec 16): > > # gcc -o t1 test.c > # date ; time ./t1 ; date > Wed Dec 20 20:37:26 MSK 2006 > INFO: Saved current time > INFO: settimeofday completed sucessfully > INFO: Reset time to original value > 0.002u 0.000s 0:00.00 0.0% 0+0k 0+0io 0pf+0w > Wed Dec 20 20:37:26 MSK 2006 > # > > Am I missing something? > Interesting, now I have to find out what is broken on my system, as I had tried a Nov 28th kernel, as well as several kernels from the past couple of days. Currently, I'm running a GENERIC kernel with the only the addition of atpic (System wouldn't boot without it on RELENG_6). I'm going to try without atpic and see if it will boot, and fixes this problem. Also going to move my make.conf and src.conf out of the way. Scot From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 14:25:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A0DC916A5AD for ; Thu, 21 Dec 2006 14:25:29 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.189]) by mx1.freebsd.org (Postfix) with ESMTP id A8BF713C428 for ; Thu, 21 Dec 2006 14:25:11 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: by nf-out-0910.google.com with SMTP id x37so2868298nfc for ; Thu, 21 Dec 2006 06:25:10 -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:references; b=RuNX70cHIqJXd+VWYQrl0mp50IQmu0A8DO5uOYH9XfyXpAPpr/P/cYeVQvnXDI9QnxtAt1O+f9m2KlTWVUEnPfMLQbsjmSUczx0phbYgseMoLBOrP4dQW1Za7gfy2w1NcIvpt21DwdbHHZK/MtOKMqZmYg2zlMxeA1qJt0S65pQ= Received: by 10.82.135.13 with SMTP id i13mr1800385bud.1166647922987; Wed, 20 Dec 2006 12:52:02 -0800 (PST) Received: by 10.82.191.16 with HTTP; Wed, 20 Dec 2006 12:52:02 -0800 (PST) Message-ID: Date: Wed, 20 Dec 2006 12:52:02 -0800 From: "Kip Macy" To: "Dmitry Pryanishnikov" In-Reply-To: MIME-Version: 1.0 References: <20061219175917.L84683@atlantis.atlantis.dp.ua> <20061220130559.P54963@atlantis.atlantis.dp.ua> <20061220124032.GC23698@deviant.kiev.zoral.com.ua> <20061220215753.H53808@atlantis.atlantis.dp.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Kostik Belousov , freebsd-current@freebsd.org, Kip Macy Subject: Re: ddb(4) spoils kernel stack in CURRENT? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2006 14:25:29 -0000 I've identified the workaround code in DDB. I'll commit a fix as soon as I have some time to test my changes. -Kip On 12/20/06, Kip Macy wrote: > > I worried that gdb probably had workaround for the large stack argument. > I'll have to dig it up, thanks for the heads up. > > -Kip > > On 12/20/06, Dmitry Pryanishnikov wrote: > > > > > > Hello! > > > > On Wed, 20 Dec 2006, Kostik Belousov wrote: > > >>> So it looks like a regression in CURRENT vs RELENG_6 (either ddb > > 'spoils' > > >>> the stack somehow, or kgdb fails to unwind it). > > > > > > Could you further localize the problem, i.e. try to backtrace CURRENT > > dump > > > > Good news: I've managed to localize the bug! I'm Feeling Lucky (TM) > > ;) > > just because CURRENT on my notebook was updated approx. at 17-Dec 00:00, > > > > and it didn't manifest such a behaviour! So it was easy to identify the > > regression - it comes with the following commit: > > > > ----------------------------------------------------------------------- > > > > Date: Sun, 17 Dec 2006 05:07:01 +0000 (UTC) > > From: Kip Macy > > To: src-committers@freebsd.org, cvs-src@freebsd.org , > > cvs-all@freebsd.org > > Subject: cvs commit: src/sys/i386/i386 apic_vector.s exception.slocal_apic.c > > trap.c vm86.c vm86bios.s src/sys/i386/include apicvar.h > > src/sys/i386/isa atpic.c atpic_vector.s icu.h > > > > kmacy 2006-12-17 05:07:01 UTC > > > > FreeBSD src repository > > > > Modified files: > > sys/i386/i386 apic_vector.s exception.s local_apic.c > > trap.c vm86.c vm86bios.s > > sys/i386/include apicvar.h > > sys/i386/isa atpic.c atpic_vector.s icu.h > > Log: > > Evidently FreeBSD has long relied on the compiler to treat structures > > passed by value (trap frames) as if they were in fact being passed by > > > > reference. For better or worse, this incorrect behaviour is no longer > > present in gcc 4.1. In this patch I convert all trapframe arguments > > to > > be explicitly pass by reference. I also remove vm86_initflags, > > pushing > > the very little work that it actually does up into vm86_prepcall. > > > > ----------------------------------------------------------------------- > > > > So kernel built from sources as of date=2006.12.17.05.00.00 gives dump > > with analyzable backtrace, and kernel built from sources as of > > date=2006.12.17.05.10.00 (which include this commit) gives dump > > which confuses kgdb. I believe that commit itself is correct, > > but kgdb contains some workaround against the old (incorrect) behaviour > > of the kernel, so it's the kgdb that should be fixed. > > > > Sincerely, Dmitry > > -- > > Atlantis ISP, System Administrator > > e-mail: dmitry@atlantis.dp.ua > > nic-hdl: LYNX-RIPE > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > > freebsd-current-unsubscribe@freebsd.org" > > > > From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 14:42:24 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A1C1716A417 for ; Thu, 21 Dec 2006 14:42:24 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from mx.gfk.ru (mx.gfk.ru [84.21.231.130]) by mx1.freebsd.org (Postfix) with ESMTP id 2088513C466 for ; Thu, 21 Dec 2006 14:42:23 +0000 (UTC) (envelope-from Yuriy.Tsibizov@gfk.ru) Received: from ex.hhp.local by mx.gfk.ru (MDaemon PRO v9.5.3) with ESMTP id md50000796751.msg for ; Thu, 21 Dec 2006 17:42:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Dec 2006 17:42:12 +0300 Message-ID: <78664C02FF341B4FAC63E561846E3BCC035109@ex.hhp.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: building kernel with lang/gcc41 (or lang/gcc42) thread-index: AcclDjOszOWAf3mqQEaHES8ZaZ1lJg== From: "Yuriy Tsibizov" To: X-Spam-Processed: mx.gfk.ru, Thu, 21 Dec 2006 17:42:18 +0300 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.30 X-Return-Path: Yuriy.Tsibizov@gfk.ru X-Envelope-From: Yuriy.Tsibizov@gfk.ru X-MDaemon-Deliver-To: freebsd-current@freebsd.org X-MDAV-Processed: mx.gfk.ru, Thu, 21 Dec 2006 17:42:20 +0300 Subject: building kernel with lang/gcc41 (or lang/gcc42) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2006 14:42:24 -0000 Are there any ways to build kernel with GCC from ports without patching FreeBSD sources? I'm mostly interested in syntax checks, not a working kernel / modules. I have to use patch below, because - it does not like -fformat-extentions and -mno-align-long-strings - it does not define __FreeBSD_cc_version. Index: sys/conf/kern.mk =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/conf/kern.mk,v retrieving revision 1.50 diff -u -r1.50 kern.mk --- sys/conf/kern.mk 26 Nov 2006 23:16:46 -0000 1.50 +++ sys/conf/kern.mk 20 Dec 2006 05:20:15 -0000 @@ -12,7 +12,7 @@ .else CWARNFLAGS?=3D -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \ -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \ - ${_wundef} -fformat-extensions + ${_wundef} .if !defined(NO_UNDEF) _wundef=3D -Wundef .endif @@ -33,7 +33,7 @@ # reserved for user applications. # .if ${MACHINE_ARCH} =3D=3D "i386" && ${CC} !=3D "icc" -CFLAGS+=3D -mno-align-long-strings -mpreferred-stack-boundary=3D2 \ +CFLAGS+=3D -mpreferred-stack-boundary=3D2 \ -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 INLINE_LIMIT?=3D 8000 .endif Index: sys/sys/cdefs.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sys/sys/cdefs.h,v retrieving revision 1.93 diff -u -r1.93 cdefs.h --- sys/sys/cdefs.h 21 Sep 2006 01:38:58 -0000 1.93 +++ sys/sys/cdefs.h 20 Dec 2006 17:29:42 -0000 @@ -338,6 +338,10 @@ #endif /* Compiler-dependent macros that rely on FreeBSD-specific extensions. */ +#ifndef __FreeBSD_cc_version +#define __FreeBSD_cc_version 0 +#endif + #if __FreeBSD_cc_version >=3D 300001 && defined(__GNUC__) && !defined(__INTEL_COMPILER) #define __printf0like(fmtarg, firstvararg) \ __attribute__((__format__ (__printf0__, fmtarg, firstvararg))) Yuriy From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 21:22:04 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9323916A403 for ; Thu, 21 Dec 2006 21:22:04 +0000 (UTC) (envelope-from mjacob@FreeBSD.org) Received: from ns1.feral.com (ns1.feral.com [192.67.166.1]) by mx1.freebsd.org (Postfix) with ESMTP id 89E0613C43E for ; Thu, 21 Dec 2006 21:22:03 +0000 (UTC) (envelope-from mjacob@FreeBSD.org) Received: from ns1.feral.com (localhost [127.0.0.1]) by ns1.feral.com (8.13.8/8.13.8) with ESMTP id kBLJnE24069357; Thu, 21 Dec 2006 11:49:24 -0800 (PST) (envelope-from mjacob@freebsd.org) Received: from localhost (mjacob@localhost) by ns1.feral.com (8.13.8/8.13.8/Submit) with ESMTP id kBLJnDZc069354; Thu, 21 Dec 2006 11:49:14 -0800 (PST) (envelope-from mjacob@freebsd.org) X-Authentication-Warning: ns1.feral.com: mjacob owned process doing -bs Date: Thu, 21 Dec 2006 11:49:13 -0800 (PST) From: mjacob@FreeBSD.org X-X-Sender: mjacob@ns1.feral.com To: Rong-en Fan In-Reply-To: <6eb82e0612200901i7a95ad49sd5b0ea66db72939b@mail.gmail.com> Message-ID: <20061221114852.P69280@ns1.feral.com> References: <6eb82e0612181734n92e4a95l9d54aeb1edae87d1@mail.gmail.com> <4589518C.3070507@samsco.org> <6eb82e0612200716x4fcf6960t3c5fe5cab5fd0bcf@mail.gmail.com> <458955F0.4020102@samsco.org> <6eb82e0612200901i7a95ad49sd5b0ea66db72939b@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: FreeBSD Current Subject: Re: bigdisk and scsi_da X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mjacob@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: Thu, 21 Dec 2006 21:22:04 -0000 >> Ok, it makes a whole lot more sense now. 7-CURRENT has checks to >> prevent the divide-by-zero. I'm still looking into the actual >> bug, though. > > OK. Manually backports rev 1.10 of sys/dev/cam/cam.c solved this > divided by zero problem. Could you or mjacob MFC this to RELENG_6 > and/or RELENG_6_2? > I'll take care of at least part of this. From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 21:27:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4292F16A416; Thu, 21 Dec 2006 21:27:01 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id A9FF113C455; Thu, 21 Dec 2006 21:27:00 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.3) with ESMTP id kBLLQuAa083536; Fri, 22 Dec 2006 00:26:56 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.3/Submit) id kBLLQu9d083535; Fri, 22 Dec 2006 00:26:56 +0300 (MSK) (envelope-from yar) Date: Fri, 22 Dec 2006 00:26:55 +0300 From: Yar Tikhiy To: Coleman Kane Message-ID: <20061221212655.GI65478@comp.chem.msu.su> References: <20061218153906.GA6910@ramen.coleyandcheryl> <20061221044859.GB63112@comp.chem.msu.su> <20061221155915.GA28845@ramen.coleyandcheryl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061221155915.GA28845@ramen.coleyandcheryl> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, Coleman Kane Subject: Re: UFS_GJOURNAL and ufs.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2006 21:27:01 -0000 On Thu, Dec 21, 2006 at 03:59:15PM +0000, Coleman Kane wrote: > I seem to remember that not working properly for me in this case... > > but I'll give it another try and let you know. According to my tests, it should work. At least, "options UFS_GJOURNAL" does affect ufs.ko built. > On Thu, Dec 21, 2006 at 07:48:59AM +0300, Yar Tikhiy wrote, and it was proclaimed: > > On Mon, Dec 18, 2006 at 03:39:06PM +0000, Coleman Kane wrote: > > > Hello, > > > > > > I have noticed (since adding UFS journal support) that the > > > UFS_GJOURNAL option hasn't been added to the ufs.ko kernel > > > module. I've been using this (out of an effort to test as > > > much as possible as KLDs) and every time I upgrade my kernel > > > I must manually add -DUFS_GJOURNAL to the CFLAGS line in > > > its Makefile. > > > > > > Is there any specific reason why this can't be committed? > > > So far, my experience with GJOURNAL has been great testing > > > it both with journal+fs on the same device as well as on > > > two seperate devices. > > > > > > It looks like an oversight to me, but I don't want to jump > > > the gun on it if there is some reasonable argument to keep > > > it out "by default". > > > > If I understand you right, you run a custom kernel w/o UFS and load > > the latter as a module, don't you? If so, just add "options > > UFS_GJOURNAL" to your kernel config file, and the module should > > pick up the setting from the kernel build directory then, granted > > you build modules with the kernel, not with the world. > > > > IMHO CFLAGS should go away from ufs.ko's Makefile because the module > > should get SOFTUPDATES and UFS_DIRHASH from the kernel configuration, > > too. > > > > -- > > Yar -- Yar From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 22:59:39 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 46EB616A500; Thu, 21 Dec 2006 22:59:39 +0000 (UTC) (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 0310413C46A; Thu, 21 Dec 2006 22:59:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBLMxcqF060368; Thu, 21 Dec 2006 17:59: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.8/8.13.8) with ESMTP id kBLMxcHv037595; Thu, 21 Dec 2006 17:59:38 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id DFC2D73034; Thu, 21 Dec 2006 17:59:37 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061221225937.DFC2D73034@freebsd-current.sentex.ca> Date: Thu, 21 Dec 2006 17:59:37 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner1 X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner2 X-Virus-Status: Clean 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: Thu, 21 Dec 2006 22:59:39 -0000 TB --- 2006-12-21 21:30:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-21 21:30:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-12-21 21:30:00 - cleaning the object tree TB --- 2006-12-21 21:30:48 - checking out the source tree TB --- 2006-12-21 21:30:48 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-12-21 21:30:48 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-21 21:39:51 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-21 21:39:51 - cd /src TB --- 2006-12-21 21:39:51 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 21 21:39:53 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Dec 21 22:56:14 UTC 2006 TB --- 2006-12-21 22:56:14 - generating LINT kernel config TB --- 2006-12-21 22:56:14 - cd /src/sys/amd64/conf TB --- 2006-12-21 22:56:14 - /usr/bin/make -B LINT TB --- 2006-12-21 22:56:14 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-21 22:56:14 - cd /src TB --- 2006-12-21 22:56:14 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Dec 21 22:56:14 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/cam/cam_periph.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/cam/cam_queue.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/cam/cam_sim.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror -pg -mprofiler-epilogue /src/sys/cam/cam_xpt.c /src/sys/cam/cam_xpt.c: In function `xpt_init': /src/sys/cam/cam_xpt.c:1450: error: syntax error before ';' token /src/sys/cam/cam_xpt.c:1451: warning: left-hand operand of comma expression has no effect /src/sys/cam/cam_xpt.c:1451: error: syntax error before ')' token *** Error code 1 Stop in /obj/amd64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-21 22:59:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-21 22:59:37 - ERROR: failed to build lint kernel TB --- 2006-12-21 22:59:37 - tinderbox aborted TB --- 0.88 user 3.49 system 5377.04 real http://tinderbox.des.no/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 23:41:10 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2F5CE16A40F; Thu, 21 Dec 2006 23:41:10 +0000 (UTC) (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 E2B0413C463; Thu, 21 Dec 2006 23:41:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBLNf981066027; Thu, 21 Dec 2006 18:41:09 -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.8/8.13.8) with ESMTP id kBLNf8ZQ042078; Thu, 21 Dec 2006 18:41:08 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A726573034; Thu, 21 Dec 2006 18:41:08 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061221234108.A726573034@freebsd-current.sentex.ca> Date: Thu, 21 Dec 2006 18:41:08 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2006 23:41:10 -0000 TB --- 2006-12-21 22:36:27 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-21 22:36:27 - starting HEAD tinderbox run for i386/i386 TB --- 2006-12-21 22:36:27 - cleaning the object tree TB --- 2006-12-21 22:36:58 - checking out the source tree TB --- 2006-12-21 22:36:58 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-12-21 22:36:58 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-21 22:44:30 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-21 22:44:30 - cd /src TB --- 2006-12-21 22:44:30 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 21 22:44:31 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Thu Dec 21 23:37:30 UTC 2006 TB --- 2006-12-21 23:37:30 - generating LINT kernel config TB --- 2006-12-21 23:37:30 - cd /src/sys/i386/conf TB --- 2006-12-21 23:37:30 - /usr/bin/make -B LINT TB --- 2006-12-21 23:37:31 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-21 23:37:31 - cd /src TB --- 2006-12-21 23:37:31 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Dec 21 23:37:31 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/cam/cam_periph.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/cam/cam_queue.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/cam/cam_sim.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/cam/cam_xpt.c /src/sys/cam/cam_xpt.c: In function `xpt_init': /src/sys/cam/cam_xpt.c:1450: error: syntax error before ';' token /src/sys/cam/cam_xpt.c:1451: warning: left-hand operand of comma expression has no effect /src/sys/cam/cam_xpt.c:1451: error: syntax error before ')' token *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-21 23:41:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-21 23:41:08 - ERROR: failed to build lint kernel TB --- 2006-12-21 23:41:08 - tinderbox aborted TB --- 0.88 user 2.72 system 3881.02 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 23:55:22 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BFE2816A492; Thu, 21 Dec 2006 23:55:22 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.freebsd.org (Postfix) with ESMTP id 3BA4013C45E; Thu, 21 Dec 2006 23:55:21 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id kBLNcusM095613; Fri, 22 Dec 2006 02:38:56 +0300 (MSK) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id kBLNcuU1095612; Fri, 22 Dec 2006 02:38:56 +0300 (MSK) (envelope-from ache) Date: Fri, 22 Dec 2006 02:38:55 +0300 From: Andrey Chernov To: Robert Watson , current@FreeBSD.org Message-ID: <20061221233855.GA95581@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Robert Watson , current@FreeBSD.org References: <20061216055903.GA2712@nagual.pp.ru> <20061216111656.GA7501@nagual.pp.ru> <20061216112117.P72986@fledge.watson.org> <20061216114426.GA7735@nagual.pp.ru> <20061216120746.E72986@fledge.watson.org> <20061216125136.GA1094@nagual.pp.ru> <20061216125419.J72986@fledge.watson.org> <20061217153914.GA30048@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061217153914.GA30048@nagual.pp.ru> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in -current) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Dec 2006 23:55:22 -0000 On Sun, Dec 17, 2006 at 06:39:14PM +0300, Andrey Chernov wrote: > On Sat, Dec 16, 2006 at 01:00:56PM +0000, Robert Watson wrote: > > As I said, this is something that I hope to revisit in the next few days. > > However, it would be helpful if you could tell me the arguments and call > > path to the ipcperm() function instance that's generating the improper > > failure. It could be that both a bug in ipcperm() and a big in shmget() > > This is kernel debug running test from t-shm.c which fails (from root). Is > it what you need? > > acc_mode 0x1b0 > owner > obj_mode 0x9b0 > dac_granted 0x1180 > priv_granted 0x0 > EACCES Any reaction? -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Fri Dec 22 00:03:42 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 928AA16A415; Fri, 22 Dec 2006 00:03:42 +0000 (UTC) (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 5397B13C45D; Fri, 22 Dec 2006 00:03:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id kBM03fbd067228; Thu, 21 Dec 2006 19:03:41 -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.8/8.13.8) with ESMTP id kBM03f3T014428; Thu, 21 Dec 2006 19:03:41 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 7A36573034; Thu, 21 Dec 2006 19:03:41 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061222000341.7A36573034@freebsd-current.sentex.ca> Date: Thu, 21 Dec 2006 19:03:41 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on clamscanner1 X-Virus-Status: Clean 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, 22 Dec 2006 00:03:42 -0000 TB --- 2006-12-21 22:59:38 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-21 22:59:38 - starting HEAD tinderbox run for i386/pc98 TB --- 2006-12-21 22:59:38 - cleaning the object tree TB --- 2006-12-21 23:00:07 - checking out the source tree TB --- 2006-12-21 23:00:07 - cd /tinderbox/HEAD/i386/pc98 TB --- 2006-12-21 23:00:07 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-21 23:07:31 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-21 23:07:31 - cd /src TB --- 2006-12-21 23:07:31 - /usr/bin/make -B buildworld >>> World build started on Thu Dec 21 23:07:32 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Fri Dec 22 00:00:19 UTC 2006 TB --- 2006-12-22 00:00:20 - generating LINT kernel config TB --- 2006-12-22 00:00:20 - cd /src/sys/pc98/conf TB --- 2006-12-22 00:00:20 - /usr/bin/make -B LINT TB --- 2006-12-22 00:00:20 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2006-12-22 00:00:20 - cd /src TB --- 2006-12-22 00:00:20 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Dec 22 00:00:20 UTC 2006 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/cam/cam_periph.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/cam/cam_queue.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/cam/cam_sim.c cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -fformat-extensions -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 -pg -mprofiler-epilogue /src/sys/cam/cam_xpt.c /src/sys/cam/cam_xpt.c: In function `xpt_init': /src/sys/cam/cam_xpt.c:1450: error: syntax error before ';' token /src/sys/cam/cam_xpt.c:1451: warning: left-hand operand of comma expression has no effect /src/sys/cam/cam_xpt.c:1451: error: syntax error before ')' token *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-22 00:03:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-22 00:03:41 - ERROR: failed to build lint kernel TB --- 2006-12-22 00:03:41 - tinderbox aborted TB --- 0.69 user 2.82 system 3843.20 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Fri Dec 22 08:22:37 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F05C16A417; Fri, 22 Dec 2006 08:22:37 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id C78C713C442; Fri, 22 Dec 2006 08:22:36 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 8F99E60B8; Fri, 22 Dec 2006 11:02:22 +0300 (MSK) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 6DCD5608D; Fri, 22 Dec 2006 11:02:22 +0300 (MSK) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id kBM82226077874; Fri, 22 Dec 2006 11:02:02 +0300 (MSK) (envelope-from ru) Date: Fri, 22 Dec 2006 11:02:02 +0300 From: Ruslan Ermilov To: Kris Kennaway Message-ID: <20061222080202.GB77429@rambler-co.ru> References: <20061217205249.GA73132@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U+BazGySraz5kW0T" Content-Disposition: inline In-Reply-To: <20061217205249.GA73132@xor.obsecurity.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: Andrew Pantyukhin , current@FreeBSD.org, David Xu Subject: Re: vge(4) bad checksum X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2006 08:22:37 -0000 --U+BazGySraz5kW0T Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Sun, Dec 17, 2006 at 03:52:49PM -0500, Kris Kennaway wrote: > On Sun, Dec 17, 2006 at 11:46:24PM +0300, Andrew Pantyukhin wrote: > > I'm not sure what it's all about, but with today's > > current whatever goes out my vge interface (icmp/ > > tcp/udp) has bad checksum: >=20 > This is a FAQ; it's probably using hardware checksum offloading. >=20 > Since the packet passed down to the NIC does not yet have the checksum > computed, it looks to tcpdump like the checksum is incorrect. However > if you look at the packet actually transmitted by the NIC > (e.g. tcpdump on another host), you'll see that it has the correct > checksum. >=20 Kris, you probably missed a commit by csjp@ where it was fixed. : revision 1.220 : date: 2006/11/18 23:17:22; author: csjp; state: Exp; lines: +40 -0 : Currently, drivers that support hardware offload of VLAN tag : processing are forced to toggle this functionality when the card : is put in and out of promiscuous mode. The main reason for this : is because the hardware strips the VLAN tag, making it impossible : for the tag information to show up in network diagnostic tools like : tcpdump(1). : [...] Andrey, have you been able to narrow your problem down to either this commit, my vge(4) commit (though you tested it as well before it was committed), or to FAST_IPSEC? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --U+BazGySraz5kW0T Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFi5D6qRfpzJluFF4RApBgAJwNSB6+rE9oy72GaIjggMx4my42GACfRJSp piJ+Lc+vrJumSVbBGUCzqbU= =Pewx -----END PGP SIGNATURE----- --U+BazGySraz5kW0T-- From owner-freebsd-current@FreeBSD.ORG Fri Dec 22 11:58:18 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2976116A403 for ; Fri, 22 Dec 2006 11:58:18 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.freebsd.org (Postfix) with ESMTP id D5D2413C45D for ; Fri, 22 Dec 2006 11:58:17 +0000 (UTC) (envelope-from andy@siliconlandmark.com) Received: from [10.0.1.9] (cpe-24-33-245-212.twmi.res.rr.com [24.33.245.212]) by lexi.siliconlandmark.com (8.13.3/8.13.3) with ESMTP id kBMBlYZ5024406; Fri, 22 Dec 2006 06:47:34 -0500 (EST) (envelope-from andy@siliconlandmark.com) In-Reply-To: <20061221121828.GE98504@egr.msu.edu> References: <20061221121828.GE98504@egr.msu.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andre Guibert de Bruet Date: Fri, 22 Dec 2006 06:47:33 -0500 To: current@freebsd.org X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV 0.88.6/2367/Thu Dec 21 11:35:52 2006 on lexi.siliconlandmark.com X-Virus-Status: Clean X-Information: Please contact the ISP for more information X-SL-MailScanner: Not scanned: please contact your Internet E-Mail Service Provider for details X-SL-SpamCheck: not spam, SpamAssassin (not cached, score=0.479, required 6, AWL -0.11, BAYES_00 -2.60, RCVD_IN_SORBS_DUL 2.05, SPF_FAIL 1.14) X-MailScanner-From: andy@siliconlandmark.com Cc: Adam McDougall Subject: Re: Laptop display stays on with lid closed X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 22 Dec 2006 11:58:18 -0000 On Dec 21, 2006, at 7:18 AM, Adam McDougall wrote: > On Wed, Dec 20, 2006 at 11:01:58PM +0300, Andrew Pantyukhin wrote: > > put into /etc/devd.conf and reload devd: > > notify 10 { > match "system" "ACPI"; > match "subsystem" "Lid"; > action "/etc/rc.lid $notify"; > }; > > Then in /etc/rc.lid: > > #!/bin/sh > STAT=$1 > > if [ $STAT = 0x00 ]; then > logger -t Lid $STAT Close at `date +'%Y%m%d %H:%M:%S'` > # do something for lid close event here > else > logger -t Lid $STAT Open at `date +'%Y%m%d %H:%M:%S'` > # do something for lid open event here > fi Would it be possible to see such a script added to /usr/share/ examples/etc? Cheers, /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ /* WWW: siliconlandmark.com * C/C++, Java, Perl, PHP, SQL, XHTML, XML */ From owner-freebsd-current@FreeBSD.ORG Fri Dec 22 21:08:12 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0E67716A403; Fri, 22 Dec 2006 21:08:12 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id CC0A013C459; Fri, 22 Dec 2006 21:08:11 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id ACB964711F; Fri, 22 Dec 2006 15:51:05 -0500 (EST) Date: Fri, 22 Dec 2006 20:51:05 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andrey Chernov In-Reply-To: <20061221233855.GA95581@nagual.pp.ru> Message-ID: <20061222204908.C65423@fledge.watson.org> References: <20061216055903.GA2712@nagual.pp.ru> <20061216111656.GA7501@nagual.pp.ru> <20061216112117.P72986@fledge.watson.org> <20061216114426.GA7735@nagual.pp.ru> <20061216120746.E72986@fledge.watson.org> <20061216125136.GA1094@nagual.pp.ru> <20061216125419.J72986@fledge.watson.org> <20061217153914.GA30048@nagual.pp.ru> <20061221233855.GA95581@nagual.pp.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: sysv_ipc.c broken in v1.30 (was Re: sysvshm appearse broken in -current) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Dec 2006 21:08:12 -0000 On Fri, 22 Dec 2006, Andrey Chernov wrote: > On Sun, Dec 17, 2006 at 06:39:14PM +0300, Andrey Chernov wrote: >> On Sat, Dec 16, 2006 at 01:00:56PM +0000, Robert Watson wrote: >>> As I said, this is something that I hope to revisit in the next few days. >>> However, it would be helpful if you could tell me the arguments and call >>> path to the ipcperm() function instance that's generating the improper >>> failure. It could be that both a bug in ipcperm() and a big in shmget() >> >> This is kernel debug running test from t-shm.c which fails (from root). Is >> it what you need? >> >> acc_mode 0x1b0 >> owner >> obj_mode 0x9b0 >> dac_granted 0x1180 >> priv_granted 0x0 >> EACCES > > Any reaction? Yes -- it looks like the call to ipcperm() in shmget_existing() is a bug; the flags argument should be ignored for access control purposes when shmget() is accessing an existing object rather than creating a new one. I've done a bit of reading of Solaris and Linux code and need to write some tests to confirm my understanding and make sure we're behaving consistently. I hope to get a chance to do this next week some time after I return from Oxford. If you want, you can try removing the ipcperm() call from shmget_existing() and restore the sysv_ipc.c change and see how that works for you? Thanks, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Sat Dec 23 06:45:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 60C6C16A403 for ; Sat, 23 Dec 2006 06:45:58 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.237]) by mx1.freebsd.org (Postfix) with ESMTP id 2459F13C442 for ; Sat, 23 Dec 2006 06:45:58 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so1310601nzh for ; Fri, 22 Dec 2006 22:45:57 -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=IvGMVL2iFDyP5oBkUbdZrY8CogBIHaf5jfez2ET/SJwSYr/7QzM2kZLYvABfJzMuCQW2DqK9sFgaWmy9TlGTPhAP6At7LCnDtNBo/+fS+toDUKTj8i78tGr1dULkub0GGaTCwgGGZja+nCyk2M8bZW4L+BEsIr8otHQyFElkpUk= Received: by 10.65.194.13 with SMTP id w13mr2016298qbp.1166856357452; Fri, 22 Dec 2006 22:45:57 -0800 (PST) Received: by 10.65.61.1 with HTTP; Fri, 22 Dec 2006 22:45:57 -0800 (PST) Message-ID: <790a9fff0612222245n70994662y49aebed77c8eb45b@mail.gmail.com> Date: Sat, 23 Dec 2006 00:45:57 -0600 From: "Scot Hetzel" To: "M. Warner Losh" In-Reply-To: <20061220.185514.-345500127.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45887A31.4050801@paradise.net.nz> <790a9fff0612191741r656fbbe0ic8660a9c59ba632b@mail.gmail.com> <45889598.3030408@u.washington.edu> <20061220.185514.-345500127.imp@bsdimp.com> Cc: youshi10@u.washington.edu, freebsd-current@freebsd.org Subject: Re: settimeofday function taking 24 - 30 minutes to complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2006 06:45:58 -0000 On 12/20/06, M. Warner Losh wrote: > It does run almost instantly if you use a time from 2000. The date > command also causes the lockup if you say 'date 1970010100140' as > well. Looks like there's a loop in the kernel to do division, but I > can't quite find where it is. > > If you have a good test setup, maybe you can do a binary search in the > settimeofday code to find why a large leap backwards causes problems. > Found the source of the problem by following the code in kern_settimeofday (sys/kern/kern_time.c), settime (sys/kern/kern_time.c), and finally in resettodr (sys/amd64/isa/clock.c). /* * Write system time back to RTC */ void resettodr() { : s = splclock(); tm = time_second; splx(s); : /* Calculate local time to put in RTC */ tm -= utc_offset(); : /* We have now the days since 01-01-1970 in tm */ writertc(RTC_WDAY, (tm + 4) % 7 + 1); /* Write back Weekday */ for (y = 1970, m = DAYSPERYEAR + LEAPYEAR(y); tm >= m; y++, m = DAYSPERYEAR + LEAPYEAR(y)) tm -= m; : } After adding some printf's to the resettodor, I was able to get some interesting results: hp010# ./t1 INFO: test running as root INFO: Saved current time settime: delta.tv_sec = - 1166842289 resettodr: tm = 100 resettodr: tm = -21500, utc_offset = 21600 <- value after subtracting utc_offset() resettodr: tm= 229, y = 426495804 <- the hang occurs in the calculation for year. INFO: settimeofday completed successfully settime: delta.tv_sec = 1166840819 resettodr: tm = 1166842388 resettodr: tm = 1166820788 resettodr: tm = 355, y = 2006 INFO: Reset time to original value By making the following change, the test program no longer hangs the system: /* * Calculate local time to put in RTC * Ignore UTC offset, if it would cause the time < Jan 1, 1970 00:00. */ if (tm >= utc_offset()) tm -= utc_offset(); else printf("resettodr: utc_offset > tm"); We probably need to change all the locations that use utc_offset(), to have a similar "if (x >= utc_offset()) x -= utc_offset();". Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-current@FreeBSD.ORG Sat Dec 23 07:40:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8789516A412 for ; Sat, 23 Dec 2006 07:40:15 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.237]) by mx1.freebsd.org (Postfix) with ESMTP id 44CD113C458 for ; Sat, 23 Dec 2006 07:40:15 +0000 (UTC) (envelope-from swhetzel@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so1313395nzh for ; Fri, 22 Dec 2006 23:40:14 -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:references; b=ujzXgGphEmXLplSfajhnsGaN/SesPJjt7Jx7IN4TKat1j5Y1pkrW17e1IhFNHMKJzYtoMFIS3GsEQPbqswiG4Pa+67/C9vPEN39DalctpZDAcNRIiZTu/spHwyemr/ShcwMTpiRakYqFXEgOFvDfKdBAyAQ1wXNd0ReI0O6lsYU= Received: by 10.65.237.1 with SMTP id o1mr12144965qbr.1166859614646; Fri, 22 Dec 2006 23:40:14 -0800 (PST) Received: by 10.65.61.1 with HTTP; Fri, 22 Dec 2006 23:40:14 -0800 (PST) Message-ID: <790a9fff0612222340n7ccfc050ldb260bf0ef63c548@mail.gmail.com> Date: Sat, 23 Dec 2006 01:40:14 -0600 From: "Scot Hetzel" To: "M. Warner Losh" In-Reply-To: <790a9fff0612222245n70994662y49aebed77c8eb45b@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_31044_23325724.1166859614558" References: <45887A31.4050801@paradise.net.nz> <790a9fff0612191741r656fbbe0ic8660a9c59ba632b@mail.gmail.com> <45889598.3030408@u.washington.edu> <20061220.185514.-345500127.imp@bsdimp.com> <790a9fff0612222245n70994662y49aebed77c8eb45b@mail.gmail.com> Cc: youshi10@u.washington.edu, freebsd-current@freebsd.org Subject: Re: settimeofday function taking 24 - 30 minutes to complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2006 07:40:15 -0000 ------=_Part_31044_23325724.1166859614558 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 12/23/06, Scot Hetzel wrote: > By making the following change, the test program no longer hangs the system: > > /* > * Calculate local time to put in RTC > * Ignore UTC offset, if it would cause the time < Jan 1, 1970 00:00. > */ > if (tm >= utc_offset()) > tm -= utc_offset(); > else > printf("resettodr: utc_offset > tm"); > > We probably need to change all the locations that use utc_offset(), to > have a similar "if (x >= utc_offset()) x -= utc_offset();". > Attached is a patch that fixes most of the x -= utc_offset(); cases in the kernel. The only one that's not fixed is in sys/dev/twa/tw_osl_inline.h. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. ------=_Part_31044_23325724.1166859614558 Content-Type: text/plain; name=utc_offset.fix; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: f_ew1q2gan Content-Disposition: attachment; filename="utc_offset.fix" SW5kZXg6IGFtZDY0L2lzYS9jbG9jay5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9ob21lL25jdnMv c3JjL3N5cy9hbWQ2NC9pc2EvY2xvY2suYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4yMjgKZGlm ZiAtdSAtcjEuMjI4IGNsb2NrLmMKLS0tIGFtZDY0L2lzYS9jbG9jay5jCTMgRGVjIDIwMDYgMDM6 NDk6MjggLTAwMDAJMS4yMjgKKysrIGFtZDY0L2lzYS9jbG9jay5jCTIzIERlYyAyMDA2IDA0OjE1 OjQ2IC0wMDAwCkBAIC03MDYsOCArNzA2LDcgQEAKIAl3cml0ZXJ0YyhSVENfU1RBVFVTQiwgUlRD U0JfSEFMVCB8IFJUQ1NCXzI0SFIpOwogCiAJLyogQ2FsY3VsYXRlIGxvY2FsIHRpbWUgdG8gcHV0 IGluIFJUQyAqLwotCi0JdG0gLT0gdXRjX29mZnNldCgpOworCVVUQ19PRkZTRVQodG0pOwogCiAJ d3JpdGVydGMoUlRDX1NFQywgYmluMmJjZCh0bSU2MCkpOyB0bSAvPSA2MDsJLyogV3JpdGUgYmFj ayBTZWNvbmRzICovCiAJd3JpdGVydGMoUlRDX01JTiwgYmluMmJjZCh0bSU2MCkpOyB0bSAvPSA2 MDsJLyogV3JpdGUgYmFjayBNaW51dGVzICovCkluZGV4OiBmcy9ud2ZzL253ZnNfc3Vici5jCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9mcy9ud2ZzL253ZnNfc3Vici5j LHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjE3CmRpZmYgLXUgLXIxLjE3IG53ZnNfc3Vici5jCi0t LSBmcy9ud2ZzL253ZnNfc3Vici5jCTI0IE9jdCAyMDA2IDExOjQzOjQxIC0wMDAwCTEuMTcKKysr IGZzL253ZnMvbndmc19zdWJyLmMJMjMgRGVjIDIwMDYgMDQ6MTk6NTggLTAwMDAKQEAgLTU0Myw3 ICs1NDMsOCBAQAogCiAJdCA9ICp0c3A7CiAJCi0JdC50dl9zZWMgPSAtIHR6b2ZmICogNjAgLSB1 dGNfb2Zmc2V0KCk7CisJdC50dl9zZWMgPSAtIHR6b2ZmICogNjA7CisJVVRDX09GRlNFVCh0LnR2 X3NlYyk7CiAJdGltZXNwZWMyZmF0dGltZSgmdCwgMSwgZGRwLCBkdHAsIGRocCk7CiB9CiAKSW5k ZXg6IGkzODYvaXNhL2Nsb2NrLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMv c3lzL2kzODYvaXNhL2Nsb2NrLmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjMxCmRpZmYgLXUg LXIxLjIzMSBjbG9jay5jCi0tLSBpMzg2L2lzYS9jbG9jay5jCTMgRGVjIDIwMDYgMDM6NDk6Mjgg LTAwMDAJMS4yMzEKKysrIGkzODYvaXNhL2Nsb2NrLmMJMjMgRGVjIDIwMDYgMDQ6MjA6NTggLTAw MDAKQEAgLTcxOSw3ICs3MTksNyBAQAogCQlyZXR1cm47CiAKIAlnZXRuYW5vdGltZSgmdHMpOwot CXRzLnR2X3NlYyAtPSB1dGNfb2Zmc2V0KCk7CisJVVRDX09GRlNFVCh0cy50dl9zZWMpOwogCWNs b2NrX3RzX3RvX2N0KCZ0cywgJmN0KTsKIAogCS8qIERpc2FibGUgUlRDIHVwZGF0ZXMgYW5kIGlu dGVycnVwdHMuICovCkluZGV4OiBpYTY0L2lhNjQvY2xvY2suYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxl OiAvaG9tZS9uY3ZzL3NyYy9zeXMvaWE2NC9pYTY0L2Nsb2NrLmMsdgpyZXRyaWV2aW5nIHJldmlz aW9uIDEuMzAKZGlmZiAtdSAtcjEuMzAgY2xvY2suYwotLS0gaWE2NC9pYTY0L2Nsb2NrLmMJMTkg T2N0IDIwMDYgMDA6NTM6MzUgLTAwMDAJMS4zMAorKysgaWE2NC9pYTY0L2Nsb2NrLmMJMjMgRGVj IDIwMDYgMDQ6MjI6MTUgLTAwMDAKQEAgLTE4NCw3ICsxODQsNyBAQAogCiAJZWZpX2dldF90aW1l KCZ0bSk7CiAJZ2V0bmFub3RpbWUoJnRzKTsKLQl0cy50dl9zZWMgLT0gdXRjX29mZnNldCgpOwor CVVUQ19PRkZTRVQodHMudHZfc2VjKTsKIAljbG9ja190c190b19jdCgmdHMsICZjdCk7CiAKIAl0 bS50bV9uc2VjID0gdHMudHZfbnNlYzsKSW5kZXg6IGtlcm4vc3Vicl9mYXR0aW1lLmMKPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL2tlcm4vc3Vicl9mYXR0aW1lLmMsdgpy ZXRyaWV2aW5nIHJldmlzaW9uIDEuMgpkaWZmIC11IC1yMS4yIHN1YnJfZmF0dGltZS5jCi0tLSBr ZXJuL3N1YnJfZmF0dGltZS5jCTI0IE9jdCAyMDA2IDEwOjI3OjIzIC0wMDAwCTEuMgorKysga2Vy bi9zdWJyX2ZhdHRpbWUuYwkyMyBEZWMgMjAwNiAwNDoxMzoyMSAtMDAwMApAQCAtMTQyLDcgKzE0 Miw3IEBACiAKIAl0MSA9IHRzcC0+dHZfc2VjOwogCWlmICghdXRjKQotCQl0MSAtPSB1dGNfb2Zm c2V0KCk7CisJCVVUQ19PRkZTRVQodDEpOwogCiAJaWYgKGRocCAhPSBOVUxMKQogCQkqZGhwID0g KHRzcC0+dHZfc2VjICYgMSkgKiAxMDAgKyB0c3AtPnR2X25zZWMgLyAxMDAwMDAwMDsKSW5kZXg6 IGtlcm4vc3Vicl9ydGMuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMv a2Vybi9zdWJyX3J0Yy5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjkKZGlmZiAtdSAtcjEuOSBz dWJyX3J0Yy5jCi0tLSBrZXJuL3N1YnJfcnRjLmMJMiBPY3QgMjAwNiAxODoyMzozNyAtMDAwMAkx LjkKKysrIGtlcm4vc3Vicl9ydGMuYwkyMyBEZWMgMjAwNiAwNDoxNDoyNSAtMDAwMApAQCAtMTU3 LDcgKzE1Nyw3IEBACiAJCXJldHVybjsKIAogCWdldG5hbm90aW1lKCZ0cyk7Ci0JdHMudHZfc2Vj IC09IHV0Y19vZmZzZXQoKTsKKwlVVENfT0ZGU0VUKHRzLnR2X3NlYyk7CiAJaWYgKChlcnJvciA9 IENMT0NLX1NFVFRJTUUoY2xvY2tfZGV2LCAmdHMpKSAhPSAwKSB7CiAJCXByaW50Zigid2Fybmlu ZzogY2xvY2tfc2V0dGltZSBmYWlsZWQgKCVkKSwgdGltZS1vZi1kYXkgY2xvY2sgIgogCQkgICAg Im5vdCBhZGp1c3RlZCB0byBzeXN0ZW0gdGltZVxuIiwgZXJyb3IpOwpJbmRleDogcGM5OC9jYnVz L2Nsb2NrLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL3BjOTgvY2J1 cy9jbG9jay5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjE1NApkaWZmIC11IC1yMS4xNTQgY2xv Y2suYwotLS0gcGM5OC9jYnVzL2Nsb2NrLmMJMiBPY3QgMjAwNiAxNjoyMToxNiAtMDAwMAkxLjE1 NAorKysgcGM5OC9jYnVzL2Nsb2NrLmMJMjMgRGVjIDIwMDYgMDQ6MjM6MTkgLTAwMDAKQEAgLTY2 OCw3ICs2NjgsNyBAQAogCQlyZXR1cm47CiAKIAlnZXRuYW5vdGltZSgmdHMpOwotCXRzLnR2X3Nl YyAtPSB1dGNfb2Zmc2V0KCk7CisJVVRDX09GRlNFVCh0cy50dl9zZWMpOwogCWNsb2NrX3RzX3Rv X2N0KCZ0cywgJmN0KTsKIAogCXJ0Y19zZXJpYWxjb20oMHgwMSk7CS8qIFJlZ2lzdGVyIHNoaWZ0 IGNvbW1hbmQuICovCkluZGV4OiBzeXMvY2xvY2suaAo9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvaG9t ZS9uY3ZzL3NyYy9zeXMvc3lzL2Nsb2NrLmgsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNwpkaWZm IC11IC1yMS43IGNsb2NrLmgKLS0tIHN5cy9jbG9jay5oCTI0IE9jdCAyMDA2IDEwOjI3OjIzIC0w MDAwCTEuNworKysgc3lzL2Nsb2NrLmgJMjMgRGVjIDIwMDYgMDQ6Mjk6MTQgLTAwMDAKQEAgLTYx LDYgKzYxLDExIEBACiBpbnQgdXRjX29mZnNldCh2b2lkKTsKIAogLyoKKyAqIFByZXZlbnQgdGlt ZSBmcm9tIGJlaW5nIDwgSmFuIDEsIDE5NzAgMDA6MDAgVVRDCisgKi8KKyNkZWZpbmUgVVRDX09G RlNFVCh0bSkgaWYgKHRtID49IHV0Y19vZmZzZXQoKSkgdG0gLT0gdXRjX29mZnNldCgpCisKKy8q CiAgKiBTdHJ1Y3R1cmUgdG8gaG9sZCB0aGUgdmFsdWVzIHR5cGljYWxseSByZXBvcnRlZCBieSB0 aW1lLW9mLWRheSBjbG9ja3MuCiAgKiBUaGlzIGNhbiBiZSBwYXNzZWQgdG8gdGhlIGdlbmVyaWMg Y29udmVyc2lvbiBmdW5jdGlvbnMgdG8gYmUgY29udmVydGVkCiAgKiB0byBhIHN0cnVjdCB0aW1l c3BlYy4K ------=_Part_31044_23325724.1166859614558-- From owner-freebsd-current@FreeBSD.ORG Sat Dec 23 08:41:06 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B2CCA16A412; Sat, 23 Dec 2006 08:41:06 +0000 (UTC) (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 5F48E13C45C; Sat, 23 Dec 2006 08:41:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id kBN8f59T007596; Sat, 23 Dec 2006 03:41: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.8/8.13.8) with ESMTP id kBN8f5KM034564; Sat, 23 Dec 2006 03:41:05 -0500 (EST) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EF48973034; Sat, 23 Dec 2006 03:41:04 -0500 (EST) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20061223084104.EF48973034@freebsd-current.sentex.ca> Date: Sat, 23 Dec 2006 03:41:04 -0500 (EST) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Status: Clean 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: Sat, 23 Dec 2006 08:41:06 -0000 TB --- 2006-12-23 07:44:22 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-12-23 07:44:22 - starting HEAD tinderbox run for i386/pc98 TB --- 2006-12-23 07:44:22 - cleaning the object tree TB --- 2006-12-23 07:44:51 - checking out the source tree TB --- 2006-12-23 07:44:51 - cd /tinderbox/HEAD/i386/pc98 TB --- 2006-12-23 07:44:51 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-12-23 07:52:58 - building world (CFLAGS=-O2 -pipe) TB --- 2006-12-23 07:52:58 - cd /src TB --- 2006-12-23 07:52:58 - /usr/bin/make -B buildworld >>> World build started on Sat Dec 23 07:52:59 UTC 2006 >>> 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 [...] yacc -d -o getdate.c /src/usr.bin/tar/getdate.y yacc: 8 shift/reduce conflicts rm -f .depend mkdep -f .depend -a -DPACKAGE_VERSION=\"1.2.53\" -I/src/usr.bin/tar -DRESCUE /src/usr.bin/tar/bsdtar.c getdate.c /src/usr.bin/tar/matching.c /src/usr.bin/tar/read.c /src/usr.bin/tar/tree.c /src/usr.bin/tar/util.c /src/usr.bin/tar/write.c echo bsdtar: /obj/pc98/src/tmp/usr/lib/libc.a /obj/pc98/src/tmp/usr/lib/libarchive.a /obj/pc98/src/tmp/usr/lib/libbz2.a /obj/pc98/src/tmp/usr/lib/libz.a >> .depend cc -O2 -pipe -DPACKAGE_VERSION=\"1.2.53\" -I/src/usr.bin/tar -DRESCUE -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 -c /src/usr.bin/tar/bsdtar.c /src/usr.bin/tar/bsdtar.c: In function `main': /src/usr.bin/tar/bsdtar.c:536: error: too few arguments to function `only_mode' *** Error code 1 Stop in /src/usr.bin/tar. *** Error code 1 Stop in /obj/pc98/src/rescue/rescue. *** Error code 1 Stop in /src/rescue/rescue. *** Error code 1 Stop in /src/rescue. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-12-23 08:41:04 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-12-23 08:41:04 - ERROR: failed to build world TB --- 2006-12-23 08:41:04 - tinderbox aborted TB --- 0.74 user 2.68 system 3401.11 real http://tinderbox.des.no/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Sat Dec 23 09:00:12 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9204716A403 for ; Sat, 23 Dec 2006 09:00:12 +0000 (UTC) (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 E12A713C41A for ; Sat, 23 Dec 2006 09:00:09 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id E58351747B; Sat, 23 Dec 2006 08:28:40 +0000 (UTC) To: "Scot Hetzel" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Sat, 23 Dec 2006 01:40:14 CST." <790a9fff0612222340n7ccfc050ldb260bf0ef63c548@mail.gmail.com> Date: Sat, 23 Dec 2006 08:28:35 +0000 Message-ID: <23336.1166862515@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: youshi10@u.washington.edu, freebsd-current@freebsd.org, "M. Warner Losh" Subject: Re: settimeofday function taking 24 - 30 minutes to complete X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2006 09:00:12 -0000 I'll take care of this one. Poul-Henning In message <790a9fff0612222340n7ccfc050ldb260bf0ef63c548@mail.gmail.com>, "Scot Hetzel" writes: >------=_Part_31044_23325724.1166859614558 >Content-Type: text/plain; charset=ISO-8859-1; format=flowed >Content-Transfer-Encoding: 7bit >Content-Disposition: inline > >On 12/23/06, Scot Hetzel wrote: >> By making the following change, the test program no longer hangs the system: >> >> /* >> * Calculate local time to put in RTC >> * Ignore UTC offset, if it would cause the time < Jan 1, 1970 00:00. >> */ >> if (tm >= utc_offset()) >> tm -= utc_offset(); >> else >> printf("resettodr: utc_offset > tm"); >> >> We probably need to change all the locations that use utc_offset(), to >> have a similar "if (x >= utc_offset()) x -= utc_offset();". >> >Attached is a patch that fixes most of the x -= utc_offset(); cases in >the kernel. > >The only one that's not fixed is in sys/dev/twa/tw_osl_inline.h. > >Scot > >-- >DISCLAIMER: >No electrons were mamed while sending this message. Only slightly bruised. > >------=_Part_31044_23325724.1166859614558 >Content-Type: text/plain; name=utc_offset.fix; charset=ANSI_X3.4-1968 >Content-Transfer-Encoding: base64 >X-Attachment-Id: f_ew1q2gan >Content-Disposition: attachment; filename="utc_offset.fix" > >SW5kZXg6IGFtZDY0L2lzYS9jbG9jay5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 >PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KUkNTIGZpbGU6IC9ob21lL25jdnMv >c3JjL3N5cy9hbWQ2NC9pc2EvY2xvY2suYyx2CnJldHJpZXZpbmcgcmV2aXNpb24gMS4yMjgKZGlm >ZiAtdSAtcjEuMjI4IGNsb2NrLmMKLS0tIGFtZDY0L2lzYS9jbG9jay5jCTMgRGVjIDIwMDYgMDM6 >NDk6MjggLTAwMDAJMS4yMjgKKysrIGFtZDY0L2lzYS9jbG9jay5jCTIzIERlYyAyMDA2IDA0OjE1 >OjQ2IC0wMDAwCkBAIC03MDYsOCArNzA2LDcgQEAKIAl3cml0ZXJ0YyhSVENfU1RBVFVTQiwgUlRD >U0JfSEFMVCB8IFJUQ1NCXzI0SFIpOwogCiAJLyogQ2FsY3VsYXRlIGxvY2FsIHRpbWUgdG8gcHV0 >IGluIFJUQyAqLwotCi0JdG0gLT0gdXRjX29mZnNldCgpOworCVVUQ19PRkZTRVQodG0pOwogCiAJ >d3JpdGVydGMoUlRDX1NFQywgYmluMmJjZCh0bSU2MCkpOyB0bSAvPSA2MDsJLyogV3JpdGUgYmFj >ayBTZWNvbmRzICovCiAJd3JpdGVydGMoUlRDX01JTiwgYmluMmJjZCh0bSU2MCkpOyB0bSAvPSA2 >MDsJLyogV3JpdGUgYmFjayBNaW51dGVzICovCkluZGV4OiBmcy9ud2ZzL253ZnNfc3Vici5jCj09 >PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 >PT09PT09PT0KUkNTIGZpbGU6IC9ob21lL25jdnMvc3JjL3N5cy9mcy9ud2ZzL253ZnNfc3Vici5j >LHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjE3CmRpZmYgLXUgLXIxLjE3IG53ZnNfc3Vici5jCi0t >LSBmcy9ud2ZzL253ZnNfc3Vici5jCTI0IE9jdCAyMDA2IDExOjQzOjQxIC0wMDAwCTEuMTcKKysr >IGZzL253ZnMvbndmc19zdWJyLmMJMjMgRGVjIDIwMDYgMDQ6MTk6NTggLTAwMDAKQEAgLTU0Myw3 >ICs1NDMsOCBAQAogCiAJdCA9ICp0c3A7CiAJCi0JdC50dl9zZWMgPSAtIHR6b2ZmICogNjAgLSB1 >dGNfb2Zmc2V0KCk7CisJdC50dl9zZWMgPSAtIHR6b2ZmICogNjA7CisJVVRDX09GRlNFVCh0LnR2 >X3NlYyk7CiAJdGltZXNwZWMyZmF0dGltZSgmdCwgMSwgZGRwLCBkdHAsIGRocCk7CiB9CiAKSW5k >ZXg6IGkzODYvaXNhL2Nsb2NrLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 >PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMv >c3lzL2kzODYvaXNhL2Nsb2NrLmMsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuMjMxCmRpZmYgLXUg >LXIxLjIzMSBjbG9jay5jCi0tLSBpMzg2L2lzYS9jbG9jay5jCTMgRGVjIDIwMDYgMDM6NDk6Mjgg >LTAwMDAJMS4yMzEKKysrIGkzODYvaXNhL2Nsb2NrLmMJMjMgRGVjIDIwMDYgMDQ6MjA6NTggLTAw >MDAKQEAgLTcxOSw3ICs3MTksNyBAQAogCQlyZXR1cm47CiAKIAlnZXRuYW5vdGltZSgmdHMpOwot >CXRzLnR2X3NlYyAtPSB1dGNfb2Zmc2V0KCk7CisJVVRDX09GRlNFVCh0cy50dl9zZWMpOwogCWNs >b2NrX3RzX3RvX2N0KCZ0cywgJmN0KTsKIAogCS8qIERpc2FibGUgUlRDIHVwZGF0ZXMgYW5kIGlu >dGVycnVwdHMuICovCkluZGV4OiBpYTY0L2lhNjQvY2xvY2suYwo9PT09PT09PT09PT09PT09PT09 >PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxl >OiAvaG9tZS9uY3ZzL3NyYy9zeXMvaWE2NC9pYTY0L2Nsb2NrLmMsdgpyZXRyaWV2aW5nIHJldmlz >aW9uIDEuMzAKZGlmZiAtdSAtcjEuMzAgY2xvY2suYwotLS0gaWE2NC9pYTY0L2Nsb2NrLmMJMTkg >T2N0IDIwMDYgMDA6NTM6MzUgLTAwMDAJMS4zMAorKysgaWE2NC9pYTY0L2Nsb2NrLmMJMjMgRGVj >IDIwMDYgMDQ6MjI6MTUgLTAwMDAKQEAgLTE4NCw3ICsxODQsNyBAQAogCiAJZWZpX2dldF90aW1l >KCZ0bSk7CiAJZ2V0bmFub3RpbWUoJnRzKTsKLQl0cy50dl9zZWMgLT0gdXRjX29mZnNldCgpOwor >CVVUQ19PRkZTRVQodHMudHZfc2VjKTsKIAljbG9ja190c190b19jdCgmdHMsICZjdCk7CiAKIAl0 >bS50bV9uc2VjID0gdHMudHZfbnNlYzsKSW5kZXg6IGtlcm4vc3Vicl9mYXR0aW1lLmMKPT09PT09 >PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 >PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL2tlcm4vc3Vicl9mYXR0aW1lLmMsdgpy >ZXRyaWV2aW5nIHJldmlzaW9uIDEuMgpkaWZmIC11IC1yMS4yIHN1YnJfZmF0dGltZS5jCi0tLSBr >ZXJuL3N1YnJfZmF0dGltZS5jCTI0IE9jdCAyMDA2IDEwOjI3OjIzIC0wMDAwCTEuMgorKysga2Vy >bi9zdWJyX2ZhdHRpbWUuYwkyMyBEZWMgMjAwNiAwNDoxMzoyMSAtMDAwMApAQCAtMTQyLDcgKzE0 >Miw3IEBACiAKIAl0MSA9IHRzcC0+dHZfc2VjOwogCWlmICghdXRjKQotCQl0MSAtPSB1dGNfb2Zm >c2V0KCk7CisJCVVUQ19PRkZTRVQodDEpOwogCiAJaWYgKGRocCAhPSBOVUxMKQogCQkqZGhwID0g >KHRzcC0+dHZfc2VjICYgMSkgKiAxMDAgKyB0c3AtPnR2X25zZWMgLyAxMDAwMDAwMDsKSW5kZXg6 >IGtlcm4vc3Vicl9ydGMuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 >PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvaG9tZS9uY3ZzL3NyYy9zeXMv >a2Vybi9zdWJyX3J0Yy5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjkKZGlmZiAtdSAtcjEuOSBz >dWJyX3J0Yy5jCi0tLSBrZXJuL3N1YnJfcnRjLmMJMiBPY3QgMjAwNiAxODoyMzozNyAtMDAwMAkx >LjkKKysrIGtlcm4vc3Vicl9ydGMuYwkyMyBEZWMgMjAwNiAwNDoxNDoyNSAtMDAwMApAQCAtMTU3 >LDcgKzE1Nyw3IEBACiAJCXJldHVybjsKIAogCWdldG5hbm90aW1lKCZ0cyk7Ci0JdHMudHZfc2Vj >IC09IHV0Y19vZmZzZXQoKTsKKwlVVENfT0ZGU0VUKHRzLnR2X3NlYyk7CiAJaWYgKChlcnJvciA9 >IENMT0NLX1NFVFRJTUUoY2xvY2tfZGV2LCAmdHMpKSAhPSAwKSB7CiAJCXByaW50Zigid2Fybmlu >ZzogY2xvY2tfc2V0dGltZSBmYWlsZWQgKCVkKSwgdGltZS1vZi1kYXkgY2xvY2sgIgogCQkgICAg >Im5vdCBhZGp1c3RlZCB0byBzeXN0ZW0gdGltZVxuIiwgZXJyb3IpOwpJbmRleDogcGM5OC9jYnVz >L2Nsb2NrLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 >PT09PT09PT09PT09PT09PT09PQpSQ1MgZmlsZTogL2hvbWUvbmN2cy9zcmMvc3lzL3BjOTgvY2J1 >cy9jbG9jay5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAxLjE1NApkaWZmIC11IC1yMS4xNTQgY2xv >Y2suYwotLS0gcGM5OC9jYnVzL2Nsb2NrLmMJMiBPY3QgMjAwNiAxNjoyMToxNiAtMDAwMAkxLjE1 >NAorKysgcGM5OC9jYnVzL2Nsb2NrLmMJMjMgRGVjIDIwMDYgMDQ6MjM6MTkgLTAwMDAKQEAgLTY2 >OCw3ICs2NjgsNyBAQAogCQlyZXR1cm47CiAKIAlnZXRuYW5vdGltZSgmdHMpOwotCXRzLnR2X3Nl >YyAtPSB1dGNfb2Zmc2V0KCk7CisJVVRDX09GRlNFVCh0cy50dl9zZWMpOwogCWNsb2NrX3RzX3Rv >X2N0KCZ0cywgJmN0KTsKIAogCXJ0Y19zZXJpYWxjb20oMHgwMSk7CS8qIFJlZ2lzdGVyIHNoaWZ0 >IGNvbW1hbmQuICovCkluZGV4OiBzeXMvY2xvY2suaAo9PT09PT09PT09PT09PT09PT09PT09PT09 >PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClJDUyBmaWxlOiAvaG9t >ZS9uY3ZzL3NyYy9zeXMvc3lzL2Nsb2NrLmgsdgpyZXRyaWV2aW5nIHJldmlzaW9uIDEuNwpkaWZm >IC11IC1yMS43IGNsb2NrLmgKLS0tIHN5cy9jbG9jay5oCTI0IE9jdCAyMDA2IDEwOjI3OjIzIC0w >MDAwCTEuNworKysgc3lzL2Nsb2NrLmgJMjMgRGVjIDIwMDYgMDQ6Mjk6MTQgLTAwMDAKQEAgLTYx >LDYgKzYxLDExIEBACiBpbnQgdXRjX29mZnNldCh2b2lkKTsKIAogLyoKKyAqIFByZXZlbnQgdGlt >ZSBmcm9tIGJlaW5nIDwgSmFuIDEsIDE5NzAgMDA6MDAgVVRDCisgKi8KKyNkZWZpbmUgVVRDX09G >RlNFVCh0bSkgaWYgKHRtID49IHV0Y19vZmZzZXQoKSkgdG0gLT0gdXRjX29mZnNldCgpCisKKy8q >CiAgKiBTdHJ1Y3R1cmUgdG8gaG9sZCB0aGUgdmFsdWVzIHR5cGljYWxseSByZXBvcnRlZCBieSB0 >aW1lLW9mLWRheSBjbG9ja3MuCiAgKiBUaGlzIGNhbiBiZSBwYXNzZWQgdG8gdGhlIGdlbmVyaWMg >Y29udmVyc2lvbiBmdW5jdGlvbnMgdG8gYmUgY29udmVydGVkCiAgKiB0byBhIHN0cnVjdCB0aW1l >c3BlYy4K >------=_Part_31044_23325724.1166859614558 >Content-Type: text/plain; charset="us-ascii" >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >Content-Disposition: inline > >_______________________________________________ >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" >------=_Part_31044_23325724.1166859614558-- > -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Thu Dec 21 16:39:19 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0FD0316A403 for ; Thu, 21 Dec 2006 16:39:19 +0000 (UTC) (envelope-from cokane@mail.cokane.org) Received: from ms-smtp-02.texas.rr.com (ms-smtp-02.texas.rr.com [24.93.47.41]) by mx1.freebsd.org (Postfix) with ESMTP id DABA113C44C for ; Thu, 21 Dec 2006 16:39:18 +0000 (UTC) (envelope-from cokane@mail.cokane.org) Received: from ramen.cokane.org (rrcs-24-153-184-158.sw.biz.rr.com [24.153.184.158]) by ms-smtp-02.texas.rr.com (8.13.6/8.13.6) with SMTP id kBLFx5iF024042 for ; Thu, 21 Dec 2006 09:59:06 -0600 (CST) Received: (qmail 28865 invoked by uid 1001); 21 Dec 2006 15:59:15 -0000 Date: Thu, 21 Dec 2006 15:59:15 +0000 From: Coleman Kane To: Yar Tikhiy Message-ID: <20061221155915.GA28845@ramen.coleyandcheryl> References: <20061218153906.GA6910@ramen.coleyandcheryl> <20061221044859.GB63112@comp.chem.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061221044859.GB63112@comp.chem.msu.su> User-Agent: Mutt/1.4.1i X-Virus-Scanned: Symantec AntiVirus Scan Engine X-Mailman-Approved-At: Sat, 23 Dec 2006 12:26:54 +0000 Cc: freebsd-current@freebsd.org, Coleman Kane Subject: Re: UFS_GJOURNAL and ufs.ko X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 21 Dec 2006 16:39:19 -0000 I seem to remember that not working properly for me in this case... but I'll give it another try and let you know. On Thu, Dec 21, 2006 at 07:48:59AM +0300, Yar Tikhiy wrote, and it was proclaimed: > On Mon, Dec 18, 2006 at 03:39:06PM +0000, Coleman Kane wrote: > > Hello, > > > > I have noticed (since adding UFS journal support) that the > > UFS_GJOURNAL option hasn't been added to the ufs.ko kernel > > module. I've been using this (out of an effort to test as > > much as possible as KLDs) and every time I upgrade my kernel > > I must manually add -DUFS_GJOURNAL to the CFLAGS line in > > its Makefile. > > > > Is there any specific reason why this can't be committed? > > So far, my experience with GJOURNAL has been great testing > > it both with journal+fs on the same device as well as on > > two seperate devices. > > > > It looks like an oversight to me, but I don't want to jump > > the gun on it if there is some reasonable argument to keep > > it out "by default". > > If I understand you right, you run a custom kernel w/o UFS and load > the latter as a module, don't you? If so, just add "options > UFS_GJOURNAL" to your kernel config file, and the module should > pick up the setting from the kernel build directory then, granted > you build modules with the kernel, not with the world. > > IMHO CFLAGS should go away from ufs.ko's Makefile because the module > should get SOFTUPDATES and UFS_DIRHASH from the kernel configuration, > too. > > -- > Yar From owner-freebsd-current@FreeBSD.ORG Sat Dec 23 15:37:18 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 55B0916A403 for ; Sat, 23 Dec 2006 15:37:18 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 1B91A13C434 for ; Sat, 23 Dec 2006 15:37:18 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 22CDA200532 for ; Sat, 23 Dec 2006 16:20:12 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id 7C956200530; Sat, 23 Dec 2006 16:20:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 3FCB9444885 for ; Sat, 23 Dec 2006 15:15:38 +0000 (UTC) Date: Sat, 23 Dec 2006 15:15:38 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: FreeBSD current mailing list Message-ID: <20061223151140.I91892@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: Subject: double trap on reboot (kernel trap 0 with interrupts disabled) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2006 15:37:18 -0000 Hi, I started to randomly get those on reboot after I updated my HEAD on 21st Dec. The last kernel was a day or two days old. There is one change (which might or might not be the cause) I added puc(4) to sys/amd64/GENERIC. am64 dual opteron system. In case anyone has an idea I am willing to test patches. Uptime: 23m14s bge0: link DOWN psmcpnp0: wake_prep disabled wake for \_SB_.PCI0.SIO_.PS2M (S5) atkbdc0: wake_prep disabled wake for \_SB_.PCI0.SIO_.PS2K (S5) sio0: wake_prep disabled wake for \_SB_.PCI0.SIO_.COM1 (S5) sio1: wake_prep disabled wake for \_SB_.PCI0.SIO_.COM2 (S5) unknown: wake_prep disabled wake for \_SB_.PCI0.USB0 (S5) unknown: wake_prep disabled wake for \_SB_.PCI0.USB2 (S5) Rebooting... cpu_reset: Stopping other CPUs kernel trap 0 with interrupts disabled Fatal trap 0: while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0xb580:0x0 stack pointer = 0x10:0xffffffff8093b598 frame pointer = 0x10:0xffffffff8093b520 code segment = base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, long 0, def32 0, gran 0 processor eflags = IOPL = 0 current process = 10 (idle: cpu1) kernel trap 2017143325 with interrupts disabled Fatal trap 2017143325: UNKNOWN while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x0:0xffffff00783b2b24 stack pointer = 0x10:0xffffff00783b28b0 frame pointer = 0x10:0xffffff00784d1000 code segment = base 0x0, limit 0x0, type 0x0 = DPL 0, pres 0, long 0, def32 0, gran 0 processor eflags = IOPL = 0 current process = 1026 (reboot) -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Sat Dec 23 19:35:14 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4BD7B16A407 for ; Sat, 23 Dec 2006 19:35:14 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.freebsd.org (Postfix) with ESMTP id 0ED0913C441 for ; Sat, 23 Dec 2006 19:35:13 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 6E023200512 for ; Sat, 23 Dec 2006 20:35:12 +0100 (CET) Received: by transport.cksoft.de (Postfix, from userid 66) id ADFC920055B; Sat, 23 Dec 2006 20:35:05 +0100 (CET) Received: from maildrop.int.zabbadoz.net (maildrop.int.zabbadoz.net [10.111.66.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.int.zabbadoz.net (Postfix) with ESMTP id 5D1AB444AB1 for ; Sat, 23 Dec 2006 19:34:02 +0000 (UTC) Date: Sat, 23 Dec 2006 19:34:01 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@maildrop.int.zabbadoz.net To: FreeBSD current mailing list In-Reply-To: <20061223151140.I91892@maildrop.int.zabbadoz.net> Message-ID: <20061223193254.M91892@maildrop.int.zabbadoz.net> References: <20061223151140.I91892@maildrop.int.zabbadoz.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de Cc: Subject: Re: double trap on reboot (kernel trap 0 with interrupts disabled) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2006 19:35:14 -0000 On Sat, 23 Dec 2006, Bjoern A. Zeeb wrote: Hi, > I started to randomly get those on reboot after I updated my HEAD > on 21st Dec. The last kernel was a day or two days old. There is > one change (which might or might not be the cause) I added puc(4) > to sys/amd64/GENERIC. am64 dual opteron system. > > In case anyone has an idea I am willing to test patches. ... > Rebooting... > cpu_reset: Stopping other CPUs > kernel trap 0 with interrupts disabled ... ok, David Xu's commit 1.129 +1 -0 src/sys/amd64/amd64/exception.S fixed this. Thanks to those telling me:-) -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT From owner-freebsd-current@FreeBSD.ORG Sat Dec 23 22:18:38 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 10A8F16A412 for ; Sat, 23 Dec 2006 22:18:38 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out4.smtp.messagingengine.com (out4.smtp.messagingengine.com [66.111.4.28]) by mx1.freebsd.org (Postfix) with ESMTP id AC3A813C425 for ; Sat, 23 Dec 2006 22:18:37 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.internal (unknown [10.202.2.149]) by out1.messagingengine.com (Postfix) with ESMTP id 97DDA58F45 for ; Sat, 23 Dec 2006 16:54:43 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by out1.internal (MEProxy); Sat, 23 Dec 2006 16:54:43 -0500 X-Sasl-enc: +w8SGOeSe5TwJEqF+4EfQPRV2A4XkRc4GhJfPWxqCdY/ 1166910882 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id C058C10CFB for ; Sat, 23 Dec 2006 16:54:42 -0500 (EST) Message-ID: <458DA5B2.3030906@FreeBSD.org> Date: Sat, 23 Dec 2006 21:54:58 +0000 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20060926002916.GA5975@cdnetworks.co.kr> <20061129013052.GC71523@cdnetworks.co.kr> <457DF011.9010701@FreeBSD.org> <20061212020023.GA9698@cdnetworks.co.kr> <6BC2A5CB-AC24-4EB3-8C6C-A4D0A5EA7183@siliconlandmark.com> <20061212124428.GB9698@cdnetworks.co.kr> <20061213023325.P56950@lexi.siliconlandmark.com> <20061213081134.GB13506@cdnetworks.co.kr> <20061213041018.I56950@lexi.siliconlandmark.com> <20061213123235.GC13506@cdnetworks.co.kr> In-Reply-To: <20061213123235.GC13506@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Enabling MSI on the Asus Vintage AH-1 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 23 Dec 2006 22:18:38 -0000 Hi, It looks like MSI was detected, but not used by the msk(4) driver on the Asus Vintage AH-1. This is a uniprocessor Athlon64 system. The PCI bridges on this system aren't in the MSI blacklist, however, there are several odd messages regarding a non-default MSI window. Looking at the code suggests it expects to see the MSI window at 0xfee00000. BTW: This system's on-board SATA controller stopped working with 6.2-RC, so I'm using an add-on PCI-e card for SATA to connect the root disk. pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x1002, dev=0x5950, revid=0x10 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0006, statreg=0x2220, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) pcib0: HT Bridge at 0:1:0 has non-default MSI window 0x0 found-> vendor=0x1002, dev=0x5a3f, revid=0x00 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0230, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x0a (2500 ns), maxlat=0x00 (0 ns) pcib0: HT Bridge at 0:6:0 has non-default MSI window 0x0 found-> vendor=0x1002, dev=0x5a38, revid=0x00 bus=0, slot=6, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 1 message pcib0: HT Bridge at 0:7:0 has non-default MSI window 0x0 found-> vendor=0x1002, dev=0x5a39, revid=0x00 bus=0, slot=7, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) powerspec 3 supports D0 D3 current D0 MSI supports 1 message 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) pcib0: HT Bridge at 0:25:0 has non-default MSI window 0x0 found-> vendor=0x10b9, dev=0x5249, revid=0x00 bus=0, slot=25, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x6010, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x07 (1750 ns), maxlat=0x00 (0 ns) found-> vendor=0x10b9, dev=0x5237, revid=0x03 bus=0, slot=28, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0117, statreg=0x02a8, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns) intpin=a, irq=11 map[10]: type 1, range 32, base 0xfebfc000, size 12, enabled pcib0: matched entry for 0.28.INTA pcib0: slot 28 INTA hardwired to IRQ 17 found-> vendor=0x10b9, dev=0x5237, revid=0x03 bus=0, slot=28, func=1 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0117, statreg=0x02a8, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns) intpin=b, irq=5 map[10]: type 1, range 32, base 0xfebfd000, size 12, enabled pcib0: matched entry for 0.28.INTB pcib0: slot 28 INTB hardwired to IRQ 18 found-> vendor=0x10b9, dev=0x5237, revid=0x03 bus=0, slot=28, func=2 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0117, statreg=0x02a8, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns) intpin=c, irq=3 map[10]: type 1, range 32, base 0xfebfe000, size 12, enabled pcib0: matched entry for 0.28.INTC pcib0: slot 28 INTC hardwired to IRQ 19 found-> vendor=0x10b9, dev=0x5239, revid=0x01 bus=0, slot=28, func=3 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0116, statreg=0x02b0, cachelnsz=16 (dwords) lattimer=0x40 (1920 ns), mingnt=0x10 (4000 ns), maxlat=0x20 (8000 ns) intpin=d, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base 0xfebffc00, size 8, enabled pcib0: matched entry for 0.28.INTD pcib0: slot 28 INTD hardwired to IRQ 23 found-> vendor=0x10b9, dev=0x5461, revid=0x00 bus=0, slot=29, func=0 class=04-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x10 (4000 ns), maxlat=0x50 (20000 ns) intpin=c, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 64, base 0xfebf8000, size 14, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 22 found-> vendor=0x10b9, dev=0x1573, revid=0x31 bus=0, slot=30, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x01 (250 ns), maxlat=0x18 (6000 ns) found-> vendor=0x10b9, dev=0x7101, revid=0x00 bus=0, slot=30, func=1 class=06-80-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10b9, dev=0x5229, revid=0xc7 bus=0, slot=31, func=0 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x02b0, 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 0xff00, size 4, enabled pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xb000-0xbfff pcib1: memory decode 0xfdb00000-0xfe3fffff pcib1: prefetched decode 0xf5a00000-0xfd9fffff pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x1002, dev=0x5974, revid=0x00 bus=1, slot=5, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x02b0, 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 3, range 32, base 0xf8000000, size 26, enabled pcib1: requested memory range 0xf8000000-0xfbffffff: good map[14]: type 4, range 32, base 0xb800, size 8, enabled pcib1: requested I/O range 0xb800-0xb8ff: in range map[18]: type 1, range 32, base 0xfe000000, size 16, enabled pcib1: requested memory range 0xfe000000-0xfe00ffff: good pcib1: matched entry for 1.5.INTA pcib1: slot 5 INTA hardwired to IRQ 17 vgapci0: port 0xb800-0xb8ff mem 0xf8000000-0xfbffffff,0xfe000000-0xfe00ffff irq 17 at device 5.0 on pci1 pcib2: at device 6.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xc000-0xcfff pcib2: memory decode 0xfe400000-0xfe4fffff pcib2: no prefetched decode pci2: on pcib2 pci2: physical bus=2 found-> vendor=0x11ab, dev=0x4362, revid=0x19 bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0107, statreg=0x4010, cachelnsz=16 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 VPD Ident: Marvell Yukon 88E8053 Gigabit Ethernet Controller PN: Yukon 88E8053 EC: Rev. 1.9 MN: Marvell SN: AbCdEfG32a88a CP: id 1, BAR16, off 0x3cc RV: 0x24 MSI supports 2 messages, 64 bit map[10]: type 1, range 64, base 0xfe4fc000, size 14, enabled pcib2: requested memory range 0xfe4fc000-0xfe4fffff: good map[18]: type 4, range 32, base 0xc800, size 8, enabled pcib2: requested I/O range 0xc800-0xc8ff: in range pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 mskc0: port 0xc800-0xc8ff mem 0xfe4fc000-0xfe4fffff irq 18 at device 0.0 on pci2 mskc0: MSI count : 2 mskc0: Reserved 0x4000 bytes for rid 0x10 type 3 at 0xfe4fc000 mskc0: RAM buffer size : 48KB mskc0: Port 0 : Rx Queue 32KB(0x00000000:0x00007fff) mskc0: Port 0 : Tx Queue 16KB(0x00008000:0x0000bfff) msk0: on mskc0 msk0: bpf attached msk0: Ethernet address: 00:15:f2:32:a8:8a miibus0: on msk0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto ioapic0: routing intpin 18 (PCI IRQ 18) to vector 49 mskc0: [MPSAFE] mskc0: [FAST] Any ideas? Regards, BMS