From owner-freebsd-current@FreeBSD.ORG Sun Mar 28 11:24:11 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D3445106566C for ; Sun, 28 Mar 2010 11:24:11 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 5B7D78FC15 for ; Sun, 28 Mar 2010 11:24:10 +0000 (UTC) Received: by bwz8 with SMTP id 8so4090901bwz.3 for ; Sun, 28 Mar 2010 04:24:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=CveY117R447KXCbJgvTkzdKPXiLUJzkcnVFvIqgSmg0=; b=I0chkVtjvKbNCCoaL0dGcYwEa5RhUXFNCewiATuw82AY/DzB4bROT48FUxiWBNSpqI rJ+rTVpxHeYqmEknl6e8JqYc+3FVxJv/U7CObXtaug8LVUNUtOi6/MCgYJPoO8s6mAuD Lfy3wakNrqNCcJX2MjjwMf+2BYzQQQMEjXuBY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=b+TsluNsHE1I0JGNMPhtGlu9tppKRTSZuiedpCEOouS2v5tHDapb3k4n1lRACBPB6K h60cVi0qi/4Iahnn80r3NJeYWWA1lCXOioakxDM53U6Qre2T8OHSRUTHNVPyBbLIiMgJ Uqx6+mzgiFAS7jxEmDeBjaAoRJXIWGgqoPdgQ= Received: by 10.204.156.217 with SMTP id y25mr1433918bkw.2.1269775450207; Sun, 28 Mar 2010 04:24:10 -0700 (PDT) Received: from [10.0.10.2] (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 24sm27180805bkr.6.2010.03.28.04.24.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 28 Mar 2010 04:24:09 -0700 (PDT) Sender: Rui Paulo Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: <20100327211200.GA36060@office.redwerk.com> Date: Sun, 28 Mar 2010 12:24:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9D7A21BF-4E8F-4A87-937A-6FA71D5140B6@freebsd.org> References: <20100324202639.GA3194@localhost> <20100327122015.GA31437@office.redwerk.com> <20100327211200.GA36060@office.redwerk.com> To: Eugene Dzhurinsky X-Mailer: Apple Mail (2.1077) Cc: freebsd-current@freebsd.org Subject: Re: wpa_supplicant, Atheros AR9285 and FreeBSD 8.0 issue -> wpa_supplicant hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Mar 2010 11:24:12 -0000 On 27 Mar 2010, at 21:12, Eugene Dzhurinsky wrote: > On Sat, Mar 27, 2010 at 02:20:15PM +0200, Eugene Dzhurinsky wrote: >> On Wed, Mar 24, 2010 at 10:26:39PM +0200, Eugeny N Dzhurinsky wrote: >>=20 >> I realized that it fails after group rekeying completes. If is set = rekeying to >> occur in 30 minutes on AP host - for 30 minutes I am not getting any = issue. >>=20 >> With my DLink WiFi USB stick powered by if_rum driver such problem = does not >> appear. >>=20 >> If I should provide some additional information to help someone = understand and >> fix this issue - please let me know :) >=20 > Finally I was able to find out the case which makes my wifi to stop = working. > The problem is easily reproducible if second laptop is associated with = AP. >=20 > My AP configuration (PC with FreeBSD 7.2) is listed below: >=20 > interface=3Dral0 > debug=3D2 > ctrl_interface=3D/var/run/hostapd > ctrl_interface_group=3Dwheel > ssid=3Dfreebsdap > wpa=3D1 > wpa_passphrase=3D************* > wpa_key_mgmt=3DWPA-PSK > wpa_group_rekey=3D1800 > wpa_pairwise=3DCCMP TKIP >=20 > local wpa_supplicant.conf is like below: >=20 > ctrl_interface=3D/var/run/wpa_supplicant > ctrl_interface_group=3Dwheel > fast_reauth=3D0 > eapol_version=3D2 > network=3D{ > ssid=3D"freebsdap" > key_mgmt=3DWPA-PSK > auth_alg=3DOPEN > psk=3D"*************" > scan_ssid=3D1 > } >=20 > My primary laptop is ASUS K40IN with wifi card on AR9285 chipset, = another > laptop is ASUS K40IJ with wifi card on AR9285 chipset too. >=20 > And once second laptop gets associated with AP - my one stops to = recognize > wifi connection. But it's still listed as associated in ifconfig = output. And=20 >=20 > wpa_cli reassociate >=20 > doesn't solve the problem - I have to restart wpa_supplicant. >=20 > Does this make any sense? Should I submit PR or there is some > misconfiguration? You can try with a more simple config. Just: network=3D{ ssid=3D"freebsdap" psk=3D"..." scan_ssid=3D1 } If this doesn't work you should send-pr. -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Sun Mar 28 15:24:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 497D4106564A for ; Sun, 28 Mar 2010 15:24:51 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.30]) by mx1.freebsd.org (Postfix) with ESMTP id CEAE28FC2E for ; Sun, 28 Mar 2010 15:24:50 +0000 (UTC) Received: from [78.34.185.47] (helo=r500.local) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1NvuM5-0007Zo-2V for freebsd-current@freebsd.org; Sun, 28 Mar 2010 17:24:49 +0200 Date: Sun, 28 Mar 2010 17:25:37 +0200 From: Fabian Keil To: freebsd-current@freebsd.org Message-ID: <20100328172537.501ed3d1@r500.local> In-Reply-To: <4BAA30CB.1070707@icyb.net.ua> References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <3a142e751003191021p141af009m6acf7d160c890cbb@mail.gmail.com> <20100319191133.46fe271c@r500.local> <3a142e751003191126j331e525fwb9e5573bbf6f7d58@mail.gmail.com> <4BAA30CB.1070707@icyb.net.ua> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/zeEE/DXAIkZ3i4GvR6nbrxb"; protocol="application/pgp-signature" X-Df-Sender: 775067 Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Mar 2010 15:24:51 -0000 --Sig_/zeEE/DXAIkZ3i4GvR6nbrxb Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andriy Gapon wrote: > on 19/03/2010 20:26 Paul B Mahol said the following: > > On Fri, Mar 19, 2010 at 7:11 PM, Fabian Keil > > wrote: > >> Paul B Mahol wrote: > >> > >>> FreeBSD 9.0 CURRENT panics when mounting file system created via > >>> newfs_msdos on DVD-RAM disc. > >>> Something to do about divide by zero. > >> I recently had a similar problem with a 16GB iPod. I still haven't > >> managed to actually mount it, but the patch below at least works > >> around the panic. > >> > >> Does it work for you, too? > >=20 > > Obviously it will fix panic, but will not allow to mount. Zero value > > should be handled > > already much before. It looks the real bug is in newfs_msdos. > >=20 >=20 > Looking at the code in mountmsdosfs(), it seems that SecPerClust can > have zero value at the place of the crash only if pm_BlkPerSec is zero. > See this line and the check above it: > SecPerClust *=3D pmp->pm_BlkPerSec; > But that is impossible because of the same if statement. >=20 > In my opinion, the only possible explanation is an overflow of a > SecPerClust value. Given that its type is u_int8_t, it seems plausible. That seems to be indeed the case. Adding a printf before SecPerClust *=3D pmp->pm_BlkPerSec; Results in: Multiplying 64 with 8 Using an unsigned int for SecPerClust allows to mount the file system and df -h correctly shows its size, but cd'ing into it and running ls -l leads to another panic: fk@r500 /usr/crash $kgdb kernel.1/kernel.symbols vmcore.1 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain condition= s. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: panic: getblk: size(262144) > MAXBSIZE(65536) cpuid =3D 0 KDB: enter: panic panic: from debugger cpuid =3D 0 Uptime: 4m44s Dumping 1992 MB (5 chunks) chunk 0: 1MB (155 pages) ... ok chunk 1: 1990MB (509345 pages) 1974 [...] ... ok chunk 2: 2MB (273 pages) ... ok chunk 3: 1MB (184 pages) Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kerne= l/zfs.ko.symbols...done. [...] #0 doadump () at pcpu.h:223 223 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:223 #1 0xffffffff803be9ef in boot (howto=3D260) at /usr/src/sys/kern/kern_shut= down.c:416 #2 0xffffffff803bedec in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xffffffff801f58f7 in db_panic (addr=3DVariable "addr" is not available. ) at /usr/src/sys/ddb/db_command.c:478 #4 0xffffffff801f5d01 in db_command (last_cmdp=3D0xffffffff808a93c0, cmd_t= able=3DVariable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #5 0xffffffff801f5f50 in db_command_loop () at /usr/src/sys/ddb/db_command= .c:498 #6 0xffffffff801f7ea9 in db_trap (type=3DVariable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #7 0xffffffff803ed545 in kdb_trap (type=3D3, code=3D0, tf=3D0xffffff803e71= c480) at /usr/src/sys/kern/subr_kdb.c:535 #8 0xffffffff80619e28 in trap (frame=3D0xffffff803e71c480) at /usr/src/sys= /amd64/amd64/trap.c:621 #9 0xffffffff80600af3 in calltrap () at /usr/src/sys/amd64/amd64/exception= .S:224 #10 0xffffffff803ed71d in kdb_enter (why=3D0xffffffff806be028 "panic", msg= =3D0xa
) at cpufunc.h:63 #11 0xffffffff803bedfb in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:562 #12 0xffffffff8042ecde in getblk (vp=3D0xffffff006dbfad20, blkno=3D992, siz= e=3D262144, slpflag=3D0, slptimeo=3DVariable "slptimeo" is not available. ) at /usr/src/sys/kern/vfs_bio.c:2523 #13 0xffffffff8042f12f in breadn (vp=3D0xffffff006dbfad20, blkno=3DVariable= "blkno" is not available. ) at /usr/src/sys/kern/vfs_bio.c:800 #14 0xffffffff8042f24e in bread (vp=3DVariable "vp" is not available. ) at /usr/src/sys/kern/vfs_bio.c:748 #15 0xffffffff8035efc2 in msdosfs_readdir (ap=3D0xffffff803e71ca60) at /usr= /src/sys/fs/msdosfs/msdosfs_vnops.c:1641 #16 0xffffffff8044b33d in kern_getdirentries (td=3D0xffffff006db6d3b0, fd= =3DVariable "fd" is not available. ) at vnode_if.h:758 #17 0xffffffff8044b5f3 in getdirentries (td=3DVariable "td" is not availabl= e. ) at /usr/src/sys/kern/vfs_syscalls.c:4066 #18 0xffffffff806199ed in syscall (frame=3D0xffffff803e71cc80) at /usr/src/= sys/amd64/amd64/trap.c:1026 #19 0xffffffff80600dd1 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exce= ption.S:373 #20 0x000000080091916c in ?? () Previous frame inner to this frame (corrupt stack?) Fabian --Sig_/zeEE/DXAIkZ3i4GvR6nbrxb Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuvdPYACgkQBYqIVf93VJ19eQCfUrGwWsdPNH/CqXdqA4bejpOi cGwAoId8vtfZQzE6CKqDPlL6J39mWOip =NGej -----END PGP SIGNATURE----- --Sig_/zeEE/DXAIkZ3i4GvR6nbrxb-- From owner-freebsd-current@FreeBSD.ORG Sun Mar 28 15:29:27 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E2931065724 for ; Sun, 28 Mar 2010 15:29:27 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay2.uni-muenster.de (ZIVM-RELAY2.UNI-MUENSTER.DE [128.176.192.13]) by mx1.freebsd.org (Postfix) with ESMTP id E31CB8FC0C for ; Sun, 28 Mar 2010 15:29:26 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.51,323,1267398000"; d="scan'208";a="240285203" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay2.uni-muenster.de with ESMTP; 28 Mar 2010 17:29:24 +0200 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 960861B0768; Sun, 28 Mar 2010 17:29:24 +0200 (CEST) Date: Sun, 28 Mar 2010 17:29:24 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Rui Paulo Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: atheros card with lots of Ierrs in `netstat -i` X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Mar 2010 15:29:27 -0000 Rui Paulo schrieb am 2010-03-26: > On 26 Mar 2010, at 17:24, Alexander Best wrote: > > hi there, > > `netstat -i` reports: > > Name Mtu Network Address Ipkts Ierrs Idrop > > Opkts > > Oerrs Coll > > ath0 2290 00:0f:b5:82:07:c8 6046435 691159 0 > > 654080 > > 0 0 > > lo0 16384 1280796 0 0 > > 1280796 > > 0 0 > > lo0 16384 your-net localhost.otaku 1280796 - - > > 1280796 > > - - > > wlan0 1500 00:0f:b5:82:07:c8 821650 0 0 > > 635461 > > 20 0 > > wlan0 1500 192.168.1.0 localhost.otaku 821223 - - > > 635140 > > - - > > are the Ierrs for ath0 normal or is this something to worry about? > > i'm running > > HEAD (r205561) on amd64. this is my card: > > ath0@pci0:5:1:0: class=0x020000 card=0x5a001385 > > chip=0x0013168c > > rev=0x01 hdr=0x00 > > vendor = 'Atheros Communications Inc.' > > device = '802.11a/b/g Wireless Adapter (AR2312)' > > class = network > > subclass = ethernet > You have a 9% error rate, which can be common on some scenarios. If > you're not experiencing connection problems, there's no need to > worry. ok. :) thanks for the info. > -- > Rui Paulo -- Alexander Best From owner-freebsd-current@FreeBSD.ORG Sun Mar 28 16:28:28 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2FEE106566B; Sun, 28 Mar 2010 16:28:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 8A9638FC15; Sun, 28 Mar 2010 16:28:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2SGSRxj011359; Sun, 28 Mar 2010 12:28:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2SGSRMg011358; Sun, 28 Mar 2010 16:28:27 GMT (envelope-from tinderbox@freebsd.org) Date: Sun, 28 Mar 2010 16:28:27 GMT Message-Id: <201003281628.o2SGSRMg011358@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Sun, 28 Mar 2010 16:28:28 -0000 TB --- 2010-03-28 15:03:54 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-28 15:03:54 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-03-28 15:03:54 - cleaning the object tree TB --- 2010-03-28 15:04:19 - cvsupping the source tree TB --- 2010-03-28 15:04:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-03-28 15:04:34 - building world TB --- 2010-03-28 15:04:34 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-28 15:04:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-28 15:04:34 - TARGET=sparc64 TB --- 2010-03-28 15:04:34 - TARGET_ARCH=sparc64 TB --- 2010-03-28 15:04:34 - TZ=UTC TB --- 2010-03-28 15:04:34 - __MAKE_CONF=/dev/null TB --- 2010-03-28 15:04:34 - cd /src TB --- 2010-03-28 15:04:34 - /usr/bin/make -B buildworld >>> World build started on Sun Mar 28 15:04:34 UTC 2010 >>> 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 Sun Mar 28 16:01:00 UTC 2010 TB --- 2010-03-28 16:01:00 - generating LINT kernel config TB --- 2010-03-28 16:01:00 - cd /src/sys/sparc64/conf TB --- 2010-03-28 16:01:00 - /usr/bin/make -B LINT TB --- 2010-03-28 16:01:00 - building LINT kernel TB --- 2010-03-28 16:01:00 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-28 16:01:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-28 16:01:00 - TARGET=sparc64 TB --- 2010-03-28 16:01:00 - TARGET_ARCH=sparc64 TB --- 2010-03-28 16:01:00 - TZ=UTC TB --- 2010-03-28 16:01:00 - __MAKE_CONF=/dev/null TB --- 2010-03-28 16:01:00 - cd /src TB --- 2010-03-28 16:01:00 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Mar 28 16:01:00 UTC 2010 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Sun Mar 28 16:21:01 UTC 2010 TB --- 2010-03-28 16:21:01 - building GENERIC kernel TB --- 2010-03-28 16:21:01 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-28 16:21:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-28 16:21:01 - TARGET=sparc64 TB --- 2010-03-28 16:21:01 - TARGET_ARCH=sparc64 TB --- 2010-03-28 16:21:01 - TZ=UTC TB --- 2010-03-28 16:21:01 - __MAKE_CONF=/dev/null TB --- 2010-03-28 16:21:01 - cd /src TB --- 2010-03-28 16:21:01 - /usr/bin/make -B buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Mar 28 16:21:01 UTC 2010 >>> 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 [...] objcopy --strip-debug --add-gnu-debuglink=firmware.ko.symbols firmware.ko.debug firmware.ko ===> fxp (all) cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /obj/sparc64/src/sys/GENERIC/opt_global.h -I. -I@ -I@/contrib/altq -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-common -g -I/obj/sparc64/src/sys/GENERIC -mcmodel=medany -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /src/sys/modules/fxp/../../dev/fxp/if_fxp.c /src/sys/modules/fxp/../../dev/fxp/if_fxp.c: In function 'fxp_start_body': /src/sys/modules/fxp/../../dev/fxp/if_fxp.c:1321: internal compiler error: in var_ann, at tree-flow-inline.h:128 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /src/sys/modules/fxp. *** Error code 1 Stop in /src/sys/modules. *** Error code 1 Stop in /obj/sparc64/src/sys/GENERIC. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-28 16:28:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-28 16:28:27 - ERROR: failed to build GENERIC kernel TB --- 2010-03-28 16:28:27 - 4030.64 user 695.44 system 5073.50 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Sun Mar 28 19:46:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6E8D106566C for ; Sun, 28 Mar 2010 19:46:12 +0000 (UTC) (envelope-from bofh@redwerk.com) Received: from redwerk.com (redwerk.com [89.105.196.9]) by mx1.freebsd.org (Postfix) with ESMTP id A66888FC1B for ; Sun, 28 Mar 2010 19:46:12 +0000 (UTC) Received: from [192.168.250.5] (helo=office.redwerk.com) by redwerk.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71) (envelope-from ) id 1NvyR1-0002Hk-6z for freebsd-current@freebsd.org; Sun, 28 Mar 2010 21:46:11 +0200 Received: from bofh by office.redwerk.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NvyR0-000CRQ-Bn for freebsd-current@freebsd.org; Sun, 28 Mar 2010 22:46:10 +0300 Date: Sun, 28 Mar 2010 22:46:10 +0300 From: Eugene Dzhurinsky To: freebsd-current@freebsd.org Message-ID: <20100328194610.GA47783@office.redwerk.com> Mail-Followup-To: freebsd-current@freebsd.org References: <20100324202639.GA3194@localhost> <20100327122015.GA31437@office.redwerk.com> <20100327211200.GA36060@office.redwerk.com> <9D7A21BF-4E8F-4A87-937A-6FA71D5140B6@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gBBFr7Ir9EOA20Yy" Content-Disposition: inline In-Reply-To: <9D7A21BF-4E8F-4A87-937A-6FA71D5140B6@freebsd.org> Subject: Re: wpa_supplicant, Atheros AR9285 and FreeBSD 8.0 issue -> wpa_supplicant hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Mar 2010 19:46:13 -0000 --gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 28, 2010 at 12:24:07PM +0100, Rui Paulo wrote: > You can try with a more simple config. Just: > network=3D{ > ssid=3D"freebsdap" > psk=3D"..." > scan_ssid=3D1 > } >=20 > If this doesn't work you should send-pr. Okay, with simplified config things didn't change, so I submitted=20 PR: kern/145123 --=20 Eugene N Dzhurinsky --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuvsf4ACgkQy/i/DoZLbHznmQCeKG3kTerXrXK9ECag7YEUf15D mq0An00Nm9T74ng6H9lqZaLiBYvxSLgg =dSkq -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 29 10:39:56 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 594B61065673; Mon, 29 Mar 2010 10:39:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 04F458FC0A; Mon, 29 Mar 2010 10:39:55 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2TAdtSC065217; Mon, 29 Mar 2010 06:39:55 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2TAdtBm065210; Mon, 29 Mar 2010 10:39:55 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 29 Mar 2010 10:39:55 GMT Message-Id: <201003291039.o2TAdtBm065210@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Mon, 29 Mar 2010 10:39:56 -0000 TB --- 2010-03-29 09:45:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-29 09:45:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-03-29 09:45:00 - cleaning the object tree TB --- 2010-03-29 09:45:30 - cvsupping the source tree TB --- 2010-03-29 09:45:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-03-29 09:46:19 - building world TB --- 2010-03-29 09:46:19 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-29 09:46:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-29 09:46:19 - TARGET=amd64 TB --- 2010-03-29 09:46:19 - TARGET_ARCH=amd64 TB --- 2010-03-29 09:46:19 - TZ=UTC TB --- 2010-03-29 09:46:19 - __MAKE_CONF=/dev/null TB --- 2010-03-29 09:46:19 - cd /src TB --- 2010-03-29 09:46:19 - /usr/bin/make -B buildworld >>> World build started on Mon Mar 29 09:46:19 UTC 2010 >>> 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.bin/calendar/parsedata.c:194: warning: passing argument 2 of 'checkmonth' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:194: warning: passing argument 3 of 'checkmonth' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:195: warning: passing argument 2 of 'checkmonth' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:195: warning: passing argument 3 of 'checkmonth' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:212: warning: passing argument 2 of 'checkdayofweek' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:212: warning: passing argument 3 of 'checkdayofweek' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:242: warning: passing argument 2 of 'checkdayofweek' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:242: warning: passing argument 3 of 'checkdayofweek' from incompatible pointer type *** Error code 1 Stop in /src/usr.bin/calendar. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-29 10:39:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-29 10:39:55 - ERROR: failed to build world TB --- 2010-03-29 10:39:55 - 2430.70 user 510.41 system 3294.34 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Mon Mar 29 11:40:06 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8BC21065670; Mon, 29 Mar 2010 11:40:06 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 783D28FC19; Mon, 29 Mar 2010 11:40:06 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2TBe5F1018116; Mon, 29 Mar 2010 07:40:05 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2TBe53R018104; Mon, 29 Mar 2010 11:40:05 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 29 Mar 2010 11:40:05 GMT Message-Id: <201003291140.o2TBe53R018104@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Mon, 29 Mar 2010 11:40:06 -0000 TB --- 2010-03-29 10:34:35 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-29 10:34:35 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-03-29 10:34:35 - cleaning the object tree TB --- 2010-03-29 10:34:54 - cvsupping the source tree TB --- 2010-03-29 10:34:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-03-29 10:35:43 - building world TB --- 2010-03-29 10:35:43 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-29 10:35:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-29 10:35:43 - TARGET=ia64 TB --- 2010-03-29 10:35:43 - TARGET_ARCH=ia64 TB --- 2010-03-29 10:35:43 - TZ=UTC TB --- 2010-03-29 10:35:43 - __MAKE_CONF=/dev/null TB --- 2010-03-29 10:35:43 - cd /src TB --- 2010-03-29 10:35:43 - /usr/bin/make -B buildworld >>> World build started on Mon Mar 29 10:35:44 UTC 2010 >>> 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.bin/calendar/parsedata.c:194: warning: passing argument 2 of 'checkmonth' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:194: warning: passing argument 3 of 'checkmonth' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:195: warning: passing argument 2 of 'checkmonth' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:195: warning: passing argument 3 of 'checkmonth' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:212: warning: passing argument 2 of 'checkdayofweek' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:212: warning: passing argument 3 of 'checkdayofweek' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:242: warning: passing argument 2 of 'checkdayofweek' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:242: warning: passing argument 3 of 'checkdayofweek' from incompatible pointer type *** Error code 1 Stop in /src/usr.bin/calendar. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-29 11:40:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-29 11:40:05 - ERROR: failed to build world TB --- 2010-03-29 11:40:05 - 3044.61 user 499.83 system 3930.58 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full From owner-freebsd-current@FreeBSD.ORG Mon Mar 29 12:18:38 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F5FA1065670; Mon, 29 Mar 2010 12:18:38 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 4E6898FC0C; Mon, 29 Mar 2010 12:18:38 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2TCIbX0058207; Mon, 29 Mar 2010 08:18:37 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2TCIbKk058200; Mon, 29 Mar 2010 12:18:37 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 29 Mar 2010 12:18:37 GMT Message-Id: <201003291218.o2TCIbKk058200@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Mon, 29 Mar 2010 12:18:38 -0000 TB --- 2010-03-29 11:29:49 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-29 11:29:49 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2010-03-29 11:29:49 - cleaning the object tree TB --- 2010-03-29 11:30:08 - cvsupping the source tree TB --- 2010-03-29 11:30:08 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2010-03-29 11:31:01 - building world TB --- 2010-03-29 11:31:01 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-29 11:31:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-29 11:31:01 - TARGET=sparc64 TB --- 2010-03-29 11:31:01 - TARGET_ARCH=sparc64 TB --- 2010-03-29 11:31:01 - TZ=UTC TB --- 2010-03-29 11:31:01 - __MAKE_CONF=/dev/null TB --- 2010-03-29 11:31:01 - cd /src TB --- 2010-03-29 11:31:01 - /usr/bin/make -B buildworld >>> World build started on Mon Mar 29 11:31:02 UTC 2010 >>> 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.bin/calendar/parsedata.c:194: warning: passing argument 2 of 'checkmonth' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:194: warning: passing argument 3 of 'checkmonth' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:195: warning: passing argument 2 of 'checkmonth' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:195: warning: passing argument 3 of 'checkmonth' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:212: warning: passing argument 2 of 'checkdayofweek' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:212: warning: passing argument 3 of 'checkdayofweek' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:242: warning: passing argument 2 of 'checkdayofweek' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:242: warning: passing argument 3 of 'checkdayofweek' from incompatible pointer type *** Error code 1 Stop in /src/usr.bin/calendar. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-29 12:18:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-29 12:18:37 - ERROR: failed to build world TB --- 2010-03-29 12:18:37 - 2287.98 user 467.62 system 2928.45 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full From owner-freebsd-current@FreeBSD.ORG Mon Mar 29 12:24:50 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0561D1065675; Mon, 29 Mar 2010 12:24:50 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A7F928FC0C; Mon, 29 Mar 2010 12:24:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2TCOn90090205; Mon, 29 Mar 2010 08:24:49 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2TCOmOj090204; Mon, 29 Mar 2010 12:24:49 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 29 Mar 2010 12:24:49 GMT Message-Id: <201003291224.o2TCOmOj090204@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Mon, 29 Mar 2010 12:24:50 -0000 TB --- 2010-03-29 11:37:24 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-29 11:37:24 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-03-29 11:37:24 - cleaning the object tree TB --- 2010-03-29 11:37:36 - cvsupping the source tree TB --- 2010-03-29 11:37:36 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-03-29 11:38:06 - building world TB --- 2010-03-29 11:38:06 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-29 11:38:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-29 11:38:06 - TARGET=sun4v TB --- 2010-03-29 11:38:06 - TARGET_ARCH=sparc64 TB --- 2010-03-29 11:38:06 - TZ=UTC TB --- 2010-03-29 11:38:06 - __MAKE_CONF=/dev/null TB --- 2010-03-29 11:38:06 - cd /src TB --- 2010-03-29 11:38:06 - /usr/bin/make -B buildworld >>> World build started on Mon Mar 29 11:38:06 UTC 2010 >>> 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.bin/calendar/parsedata.c:194: warning: passing argument 2 of 'checkmonth' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:194: warning: passing argument 3 of 'checkmonth' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:195: warning: passing argument 2 of 'checkmonth' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:195: warning: passing argument 3 of 'checkmonth' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:212: warning: passing argument 2 of 'checkdayofweek' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:212: warning: passing argument 3 of 'checkdayofweek' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:242: warning: passing argument 2 of 'checkdayofweek' from incompatible pointer type /src/usr.bin/calendar/parsedata.c:242: warning: passing argument 3 of 'checkdayofweek' from incompatible pointer type *** Error code 1 Stop in /src/usr.bin/calendar. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-29 12:24:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-29 12:24:48 - ERROR: failed to build world TB --- 2010-03-29 12:24:48 - 2280.19 user 460.89 system 2844.75 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full From owner-freebsd-current@FreeBSD.ORG Mon Mar 29 12:43:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 743C7106566B for ; Mon, 29 Mar 2010 12:43:04 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 99DE88FC17 for ; Mon, 29 Mar 2010 12:43:03 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA27219; Mon, 29 Mar 2010 15:42:59 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4BB0A053.9060007@freebsd.org> Date: Mon, 29 Mar 2010 15:42:59 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: Fabian Keil References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <3a142e751003191021p141af009m6acf7d160c890cbb@mail.gmail.com> <20100319191133.46fe271c@r500.local> <3a142e751003191126j331e525fwb9e5573bbf6f7d58@mail.gmail.com> <4BAA30CB.1070707@icyb.net.ua> <20100328172537.501ed3d1@r500.local> In-Reply-To: <20100328172537.501ed3d1@r500.local> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Mar 2010 12:43:04 -0000 If you want to make sure that I see your reply please include me into recipient list. FreeBSD mailing lists sometimes have high volume and it's easy to miss a followup even if you are interested in reading it. on 28/03/2010 18:25 Fabian Keil said the following: > Andriy Gapon wrote: >> Looking at the code in mountmsdosfs(), it seems that SecPerClust can >> have zero value at the place of the crash only if pm_BlkPerSec is zero. >> See this line and the check above it: >> SecPerClust *= pmp->pm_BlkPerSec; >> But that is impossible because of the same if statement. >> >> In my opinion, the only possible explanation is an overflow of a >> SecPerClust value. Given that its type is u_int8_t, it seems plausible. > > That seems to be indeed the case. Adding a printf before > SecPerClust *= pmp->pm_BlkPerSec; > > Results in: Multiplying 64 with 8 Interesting. See below. > Using an unsigned int for SecPerClust allows to mount the file > system and df -h correctly shows its size, but cd'ing into it > and running ls -l leads to another panic: I that this local workaround cures only one local symptom and pushes the problem further in the code. The panic you got is a symptom of a deeper issue. Could you please remind us in what way was the filesystem created? Was it FreeBSD newfs_msdos? I am not a FAT expert and I know to take Wikipedia with a grain of salt. But please take a look at this: http://en.wikipedia.org/wiki/File_Allocation_Table#Boot_Sector In our formula: SecPerClust *= pmp->pm_BlkPerSec; we have the following parameters: SecPerClust[in] - sectors per cluster pm_BlkPerSec - bytes per sector divided by 512 (pm_BytesPerSec / DEV_BSIZE) SecPerClust[out] - bytes per cluster divided by 512 So we have: sectors per cluster: 64 bytes per sector: 4096 That Wikipedia article says: "However, the value must not be such that the number of bytes per cluster becomes greater than 32 KB." But in our case it's 256K, the same value that is passed as 'size' parameter to bread() in the crash stack trace below. By the way, that 32KB limit means that value of SecPerClust[out] should never be greater than 64 and SecPerClust[in] is limited to 128, so its current must be of sufficient size to hold all allowed values. Thus, clearly, it is a fault of a tool that formatted the media for FAT. It should have picked correct values, or rejected incorrect values if those were provided as overrides via command line options. > fk@r500 /usr/crash $kgdb kernel.1/kernel.symbols vmcore.1 [snip] > Unread portion of the kernel message buffer: > panic: getblk: size(262144) > MAXBSIZE(65536) [snip] > #11 0xffffffff803bedfb in panic (fmt=Variable "fmt" is not available. > ) at /usr/src/sys/kern/kern_shutdown.c:562 > #12 0xffffffff8042ecde in getblk (vp=0xffffff006dbfad20, blkno=992, size=262144, slpflag=0, slptimeo=Variable "slptimeo" is not available. > ) at /usr/src/sys/kern/vfs_bio.c:2523 > #13 0xffffffff8042f12f in breadn (vp=0xffffff006dbfad20, blkno=Variable "blkno" is not available. > ) at /usr/src/sys/kern/vfs_bio.c:800 > #14 0xffffffff8042f24e in bread (vp=Variable "vp" is not available. > ) at /usr/src/sys/kern/vfs_bio.c:748 > #15 0xffffffff8035efc2 in msdosfs_readdir (ap=0xffffff803e71ca60) at /usr/src/sys/fs/msdosfs/msdosfs_vnops.c:1641 [snip] -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Mar 29 16:16:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E1911065675 for ; Mon, 29 Mar 2010 16:16:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1DF158FC1B for ; Mon, 29 Mar 2010 16:16:47 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id C1A2D46BA4; Mon, 29 Mar 2010 12:16:46 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id D3B158A01F; Mon, 29 Mar 2010 12:16:45 -0400 (EDT) From: John Baldwin To: freebsd-current@freebsd.org Date: Mon, 29 Mar 2010 12:16:23 -0400 User-Agent: KMail/1.12.1 (FreeBSD/7.3-CBSD-20100217; KDE/4.3.1; amd64; ; ) References: <20100326162406.GA43912@fit.vutbr.cz> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201003291216.23887.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Mon, 29 Mar 2010 12:16:45 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.7 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Petr Lampa , Rick Macklem Subject: Re: Possible error in nfs_nfsdserv.c? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 16:16:47 -0000 On Saturday 27 March 2010 9:49:23 am Rick Macklem wrote: > > On Fri, 26 Mar 2010, Petr Lampa wrote: > > > > > I've got several "panic: nfsrelpath", see attached photo. I've found > > one place where it could probably happen, please, can you look at this? > > > > First name buffer is initialized in nfsrvd_link() with: > > NFSNAMEICNDSET(&named.ni_cnd, nd->nd_cred, CREATE, LOCKPARENT); > > > > Then: > > nd->nd_repstat = nfsvno_namei(nd, &named, dp, 0, &tnes, > > p, &dirp); > > > > and > > nd->nd_repstat = nfsvno_link(&named, vp, nd->nd_cred, p, exp); > > > > is called. The nfsvno_link() calls nfsvno_relpathbuf() unconditionally, > > this is the place where the panic happened. The only place where buffer can > > be released in no error case is in the nfsvno_namei(). There is a call > > > > if ((cnp->cn_flags & (SAVENAME | SAVESTART)) == 0) > > nfsvno_relpathbuf(ndp); > > > > there and no SAVENAME|SAVESTART is set in NFSNAMEICNDSET(). But if > > buffer is alwyas released at this place, then link would be panicing also > > always (and it isn't). So probably I'm missing something here. Other > > For ufs, ufs_lookup() sets SAVENAME for the CREATE case, which is why > I don't see such a panic. I had thought that all file systems would do > this for VOP_LOOKUP() for CREATE. It sounds like you've found a case > where that isn't happening. Could you please tell us what file system > type is being accessed when this panic occurs? > > I've cc'd freebsd-current, so that anyone conversant with the FreeBSD > VFS can jump in here. Am I right to assume that VOP_LOOKUP() for CREATE > will set SAVENAME when returning error == 0? No, the caller has to set that flag. Some filesystems set it internally to force the name to be saved (e.g. the NFS client), but there is nothing in the VFS layer itself that sets it that I can see. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Mon Mar 29 19:07:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 904F71065670 for ; Mon, 29 Mar 2010 19:07:29 +0000 (UTC) (envelope-from bofh@redwerk.com) Received: from redwerk.com (redwerk.com [89.105.196.9]) by mx1.freebsd.org (Postfix) with ESMTP id 4ECCD8FC2E for ; Mon, 29 Mar 2010 19:07:28 +0000 (UTC) Received: from [192.168.250.5] (helo=office.redwerk.com) by redwerk.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71) (envelope-from ) id 1NwKJ5-0006eS-1d for freebsd-current@freebsd.org; Mon, 29 Mar 2010 21:07:27 +0200 Received: from bofh by office.redwerk.com with local (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NwKJ4-0003qi-Cu for freebsd-current@freebsd.org; Mon, 29 Mar 2010 22:07:26 +0300 Date: Mon, 29 Mar 2010 22:07:26 +0300 From: Eugene Dzhurinsky To: freebsd-current@freebsd.org Message-ID: <20100329190726.GA14773@office.redwerk.com> Mail-Followup-To: freebsd-current@freebsd.org References: <20100324202639.GA3194@localhost> <20100327122015.GA31437@office.redwerk.com> <20100327211200.GA36060@office.redwerk.com> <9D7A21BF-4E8F-4A87-937A-6FA71D5140B6@freebsd.org> <20100328194610.GA47783@office.redwerk.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: <20100328194610.GA47783@office.redwerk.com> Subject: Re: wpa_supplicant, Atheros AR9285 and FreeBSD 8.0 issue -> wpa_supplicant hangs X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Mar 2010 19:07:29 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 28, 2010 at 10:46:10PM +0300, Eugene Dzhurinsky wrote: > Okay, with simplified config things didn't change, so I submitted=20 > PR: kern/145123 Sometimes I'm felling like being an idiot. I just realized that I had configured both laptops to use same IP address, which was noticed on logs at AP host. If I'd look at log files, even dmesg - I will find the cause immediately, but instead I started to post to mailing lists and send PR-s. Anyway, the problem is already resolved, and I asked to close the PR. Sorry about that :( --=20 Eugene N Dzhurinsky --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuw+m0ACgkQy/i/DoZLbHz4sACaA06/zvdCxdaQsXi3H+lJE4gL ymQAoJVLm1GXdcByliotw4XJqEG9WG33 =6u3Z -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 29 20:29:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 86DBA106566B for ; Mon, 29 Mar 2010 20:29:28 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.44]) by mx1.freebsd.org (Postfix) with ESMTP id 157D38FC12 for ; Mon, 29 Mar 2010 20:29:27 +0000 (UTC) Received: from [87.78.61.127] (helo=r500.local) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1NwLaQ-0006G1-C1; Mon, 29 Mar 2010 22:29:26 +0200 Date: Mon, 29 Mar 2010 22:29:20 +0200 From: Fabian Keil To: Andriy Gapon Message-ID: <20100329222920.5eef6395@r500.local> In-Reply-To: <4BB0A053.9060007@freebsd.org> References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <3a142e751003191021p141af009m6acf7d160c890cbb@mail.gmail.com> <20100319191133.46fe271c@r500.local> <3a142e751003191126j331e525fwb9e5573bbf6f7d58@mail.gmail.com> <4BAA30CB.1070707@icyb.net.ua> <20100328172537.501ed3d1@r500.local> <4BB0A053.9060007@freebsd.org> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/emhDCmx8++AioJ8XdIT49uL"; protocol="application/pgp-signature" X-Df-Sender: 775067 Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Mar 2010 20:29:28 -0000 --Sig_/emhDCmx8++AioJ8XdIT49uL Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andriy Gapon wrote: > on 28/03/2010 18:25 Fabian Keil said the following: > > Andriy Gapon wrote: > >> Looking at the code in mountmsdosfs(), it seems that SecPerClust can > >> have zero value at the place of the crash only if pm_BlkPerSec is > >> zero. See this line and the check above it: > >> SecPerClust *=3D pmp->pm_BlkPerSec; > >> But that is impossible because of the same if statement. > >> > >> In my opinion, the only possible explanation is an overflow of a > >> SecPerClust value. Given that its type is u_int8_t, it seems > >> plausible. > >=20 > > That seems to be indeed the case. Adding a printf before > > SecPerClust *=3D pmp->pm_BlkPerSec; > >=20 > > Results in: Multiplying 64 with 8 >=20 > Interesting. See below. >=20 > > Using an unsigned int for SecPerClust allows to mount the file > > system and df -h correctly shows its size, but cd'ing into it > > and running ls -l leads to another panic: >=20 > I that this local workaround cures only one local symptom and pushes the > problem further in the code. The panic you got is a symptom of a deeper > issue. >=20 > Could you please remind us in what way was the filesystem created? > Was it FreeBSD newfs_msdos? Yes. I no longer have the sudo log to see how exactly, but I usually use -F 32 as only option. I no longer have access to the device in question either, but I took an image of the partition and can reproduce the mount issue using mdconfig. Trying to recreate a file system that shows the problem on a file-backed device failed so far. For the dump of the file system with the problem, file says: x86 boot sector, code offset 0x58, OEM-ID "BSD 4.4", Bytes/sector 4096, sectors/cluster 64, heads 255, sectors = =20 3901275 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 60, Backup boot sector 2, serial number 0xc1171b12, unlabeled For the one that doesn't it's: x86 boot sector, code offset 0x58, OEM-ID "BSD4.4 ", sectors/cluster 64, heads 255, sectors 31210200 (volumes > 32 MB) , FAT (32 bit), sectors/FAT 3809, Backup boot sector 2, serial number 0x2e7e19ee, label: "NO_NAME " > I am not a FAT expert and I know to take Wikipedia with a grain of salt. > But please take a look at this: > http://en.wikipedia.org/wiki/File_Allocation_Table#Boot_Sector >=20 > In our formula: > SecPerClust *=3D pmp->pm_BlkPerSec; > we have the following parameters: > SecPerClust[in] - sectors per cluster > pm_BlkPerSec - bytes per sector divided by 512 (pm_BytesPerSec / > DEV_BSIZE) SecPerClust[out] - bytes per cluster divided by 512 >=20 > So we have: > sectors per cluster: 64 > bytes per sector: 4096 file seems to agree. =20 > That Wikipedia article says: "However, the value must not be such that > the number of bytes per cluster becomes greater than 32 KB." > But in our case it's 256K, the same value that is passed as 'size' > parameter to bread() in the crash stack trace below. >=20 > By the way, that 32KB limit means that value of SecPerClust[out] should > never be greater than 64 and SecPerClust[in] is limited to 128, so its > current must be of sufficient size to hold all allowed values. >=20 > Thus, clearly, it is a fault of a tool that formatted the media for FAT. > It should have picked correct values, or rejected incorrect values if > those were provided as overrides via command line options. The kernel still shouldn't panic, though. Fabian --Sig_/emhDCmx8++AioJ8XdIT49uL Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuxDaQACgkQBYqIVf93VJ3PCQCgrGxNNiEURbF6JB1X/UWHSMGn 3ncAnR+FoKlHHFAkRoEcAoWCg7RX812K =1HJV -----END PGP SIGNATURE----- --Sig_/emhDCmx8++AioJ8XdIT49uL-- From owner-freebsd-current@FreeBSD.ORG Mon Mar 29 20:47:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A071106564A for ; Mon, 29 Mar 2010 20:47:22 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C7EF98FC16 for ; Mon, 29 Mar 2010 20:47:21 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id XAA08768; Mon, 29 Mar 2010 23:47:18 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NwLrh-000GaJ-Pr; Mon, 29 Mar 2010 23:47:17 +0300 Message-ID: <4BB111D4.8060809@freebsd.org> Date: Mon, 29 Mar 2010 23:47:16 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Fabian Keil References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <3a142e751003191021p141af009m6acf7d160c890cbb@mail.gmail.com> <20100319191133.46fe271c@r500.local> <3a142e751003191126j331e525fwb9e5573bbf6f7d58@mail.gmail.com> <4BAA30CB.1070707@icyb.net.ua> <20100328172537.501ed3d1@r500.local> <4BB0A053.9060007@freebsd.org> <20100329222920.5eef6395@r500.local> In-Reply-To: <20100329222920.5eef6395@r500.local> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Mar 2010 20:47:22 -0000 on 29/03/2010 23:29 Fabian Keil said the following: > Andriy Gapon wrote: >> Thus, clearly, it is a fault of a tool that formatted the media for FAT. >> It should have picked correct values, or rejected incorrect values if >> those were provided as overrides via command line options. > > The kernel still shouldn't panic, though. A quick reply to this point only - yes, I completely agree. But remember that the panic happened only after the sources were modified :) Jokes aside, mountmsdosfs() should reject incorrect combination of bytes/sector and sectors/cluster and should produce proper diagnostics for that. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon Mar 29 22:05:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D3EF106564A; Mon, 29 Mar 2010 22:05:14 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id CBBB88FC08; Mon, 29 Mar 2010 22:05:13 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHTAsEuDaFvI/2dsb2JhbACbJ3HAEIUBBA X-IronPort-AV: E=Sophos;i="4.51,330,1267419600"; d="scan'208";a="70402685" Received: from darling.cs.uoguelph.ca ([131.104.91.200]) by esa-jnhn-pri.mail.uoguelph.ca with ESMTP; 29 Mar 2010 18:05:13 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id 194519400EA; Mon, 29 Mar 2010 18:05:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at darling.cs.uoguelph.ca Received: from darling.cs.uoguelph.ca ([127.0.0.1]) by localhost (darling.cs.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akz6Sy4odI47; Mon, 29 Mar 2010 18:05:12 -0400 (EDT) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by darling.cs.uoguelph.ca (Postfix) with ESMTP id A36E59400DA; Mon, 29 Mar 2010 18:05:12 -0400 (EDT) Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id o2TMIS316443; Mon, 29 Mar 2010 18:18:28 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Mon, 29 Mar 2010 18:18:28 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: John Baldwin In-Reply-To: <201003291216.23887.jhb@freebsd.org> Message-ID: References: <20100326162406.GA43912@fit.vutbr.cz> <201003291216.23887.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Petr Lampa , freebsd-current@freebsd.org Subject: Re: Possible error in nfs_nfsdserv.c? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 22:05:14 -0000 On Mon, 29 Mar 2010, John Baldwin wrote: >> >> I've cc'd freebsd-current, so that anyone conversant with the FreeBSD >> VFS can jump in here. Am I right to assume that VOP_LOOKUP() for CREATE >> will set SAVENAME when returning error == 0? > > No, the caller has to set that flag. Some filesystems set it internally to > force the name to be saved (e.g. the NFS client), but there is nothing in the > VFS layer itself that sets it that I can see. > Thanks John. I spotted the comment in vfs_lookup.c that basically said that, this morning. I'll fix up the experimental server soon, although it seems that ufs and zfs usually set SAVENAME for the CREATE cases, which is why I've never seen the panic. rick From owner-freebsd-current@FreeBSD.ORG Mon Mar 29 22:11:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B5D4E106566B for ; Mon, 29 Mar 2010 22:11:07 +0000 (UTC) (envelope-from a_best01@uni-muenster.de) Received: from zivm-relay3.uni-muenster.de (ZIVM-RELAY3.UNI-MUENSTER.DE [128.176.192.19]) by mx1.freebsd.org (Postfix) with ESMTP id 4A74F8FC15 for ; Mon, 29 Mar 2010 22:11:06 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.51,330,1267398000"; d="scan'208";a="29672091" Received: from zivmaildisp1.uni-muenster.de (HELO ZIVMAILUSER01.UNI-MUENSTER.DE) ([128.176.188.85]) by zivm-relay3.uni-muenster.de with ESMTP; 30 Mar 2010 00:11:05 +0200 Received: by ZIVMAILUSER01.UNI-MUENSTER.DE (Postfix, from userid 149459) id 310B51B0768; Tue, 30 Mar 2010 00:11:05 +0200 (CEST) Date: Tue, 30 Mar 2010 00:11:04 +0200 (CEST) From: Alexander Best Sender: Organization: Westfaelische Wilhelms-Universitaet Muenster To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: fsck unable to read disk sectors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Mar 2010 22:11:07 -0000 hi there, when doing fsck on my / fs i get this error: "Cannot Read BLK. 471617640" and "The Following Disk Sectors could not be read: 471617643". after this message the partition gets marked dirty. i performed the following steps to verify the problem: 1) dd if=/dev/ada0 of=/dev/null bs=1m 2) fsck / under freebsd 7 3) mount -u -o snapshot /.snap/snapshot1 / && fsck_ffs /.snap/snapshot1 all three steps showed no problem with that harddrive whatsoever. also smartd doesn't complain about anything. i'm running HEAD (r205860) on amd64. this is the output of `dmesg -a|grep ada0`: ada0 at ahcich2 bus 0 scbus3 target 0 lun 0 ada0: ATA-7 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 238474MB (488395055 512 byte sectors: 16H 63S/T 16383C) -- Alexander Best From owner-freebsd-current@FreeBSD.ORG Tue Mar 30 00:08:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF0C71065670 for ; Tue, 30 Mar 2010 00:08:53 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by mx1.freebsd.org (Postfix) with ESMTP id 3FC1B8FC14 for ; Tue, 30 Mar 2010 00:08:52 +0000 (UTC) Received: by ey-out-2122.google.com with SMTP id d26so847034eyd.9 for ; Mon, 29 Mar 2010 17:08:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=RLsR9g9s1YNxCkORVXhKpYXATuRFed+XN7rKrUcG40E=; b=pQQgL7G7uOYmFK9fWwiHOS85eM/XAaT3zTNoWi3uDOTaxbD9iasF1FL1eEBcXUDdE7 cth8uuFP+U7Vnvfrkgx2VH+K08LTs/jmZgCDBg4LV8cPDjBsEX+KhjJX9FWqDttg3K2q yMaxybZKbLtUz531is9xEaZ7V9Ub2DnNpCMsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Lsr57bj0u+60f4XaCryWEHDWoGX/xDqRCb+jh8ybWkF7ZHHFT7/WrB23iQF5OLLHtt B1pBxubVTowCw2XPQV02vNcpUt4Ym2R3iSFICPqGWDMwQfRnD94ISLLzgmyV0SypARAY jgdiQo+vZIZXdoRGYKBtIDWg9/E0vgwjNPDNY= MIME-Version: 1.0 Received: by 10.216.13.82 with HTTP; Mon, 29 Mar 2010 17:08:51 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Mar 2010 00:08:51 +0000 Received: by 10.216.87.204 with SMTP id y54mr1726706wee.193.1269907731376; Mon, 29 Mar 2010 17:08:51 -0700 (PDT) Message-ID: <3a142e751003291708nc3e110bjca1789cc807f61a2@mail.gmail.com> From: Paul B Mahol To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-current@freebsd.org Subject: Re: fsck unable to read disk sectors X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Mar 2010 00:08:53 -0000 On 3/29/10, Alexander Best wrote: > hi there, > > when doing fsck on my / fs i get this error: > > "Cannot Read BLK. 471617640" and "The Following Disk Sectors could not be > read: 471617643". after this message the partition gets marked dirty. > > i performed the following steps to verify the problem: > > 1) dd if=/dev/ada0 of=/dev/null bs=1m > 2) fsck / under freebsd 7 > 3) mount -u -o snapshot /.snap/snapshot1 / && fsck_ffs /.snap/snapshot1 > > all three steps showed no problem with that harddrive whatsoever. also > smartd > doesn't complain about anything. > > i'm running HEAD (r205860) on amd64. > > this is the output of `dmesg -a|grep ada0`: > > ada0 at ahcich2 bus 0 scbus3 target 0 lun 0 > ada0: ATA-7 SATA 2.x device > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > ada0: Command Queueing enabled > ada0: 238474MB (488395055 512 byte sectors: 16H 63S/T 16383C) Last time I tried ahci on dead disk it did not complained at all (usually I get dead LBA listed on console). From owner-freebsd-current@FreeBSD.ORG Mon Mar 29 23:40:16 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83CCE106566C; Mon, 29 Mar 2010 23:40:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id 159E08FC08; Mon, 29 Mar 2010 23:40:15 +0000 (UTC) Received: from c122-106-158-90.carlnfd1.nsw.optusnet.com.au (c122-106-158-90.carlnfd1.nsw.optusnet.com.au [122.106.158.90]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id o2TNe7jv001070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Mar 2010 10:40:08 +1100 Date: Tue, 30 Mar 2010 10:40:07 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Andriy Gapon In-Reply-To: <4BB0A053.9060007@freebsd.org> Message-ID: <20100330101734.R5158@delplex.bde.org> References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <3a142e751003191021p141af009m6acf7d160c890cbb@mail.gmail.com> <20100319191133.46fe271c@r500.local> <3a142e751003191126j331e525fwb9e5573bbf6f7d58@mail.gmail.com> <4BAA30CB.1070707@icyb.net.ua> <20100328172537.501ed3d1@r500.local> <4BB0A053.9060007@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Tue, 30 Mar 2010 02:00:57 +0000 Cc: Kostik Belousov , freebsd-current@freebsd.org, Bruce Evans , Andriy Gapon Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Mar 2010 23:40:16 -0000 On Mon, 29 Mar 2010, Andriy Gapon wrote: > ... > I am not a FAT expert and I know to take Wikipedia with a grain of salt. > But please take a look at this: > http://en.wikipedia.org/wiki/File_Allocation_Table#Boot_Sector > > In our formula: > SecPerClust *= pmp->pm_BlkPerSec; > we have the following parameters: > SecPerClust[in] - sectors per cluster > pm_BlkPerSec - bytes per sector divided by 512 (pm_BytesPerSec / DEV_BSIZE) > SecPerClust[out] - bytes per cluster divided by 512 > > So we have: > sectors per cluster: 64 > bytes per sector: 4096 > > That Wikipedia article says: "However, the value must not be such that the number > of bytes per cluster becomes greater than 32 KB." 64K works under FreeBSD, and I often do performance tests with it (it gives very bad performance). It should be avoided for portability too. > But in our case it's 256K, the same value that is passed as 'size' parameter to > bread() in the crash stack trace below. This error should be detected more cleanly. ffs fails the mount if the block size exceeds 64K. ffs can handle larger block sizes, and it is unfortunate that it is limited by the non-ffs parameter MAXBSIZE, but MAXBSIZE has been 64K and non-fuzzy for so long that the portability considerations for using larger values are even clearer -- larger sizes shouldn't be used, but 64K works almost everywhere. I used to often do performance tests with block size 64K for ffs. It gives very bad performance, and since theire are more combinations of block sizes to test for ffs than for msdosfs, I stopped testing block size 64K for ffs long ago. msdosfs has lots more sanity tests for its BPB than does ffs for its superblock. Some of these were considered insane and removed, and there never seems to have been one for this. > By the way, that 32KB limit means that value of SecPerClust[out] should never be > greater than 64 and SecPerClust[in] is limited to 128, so its current must be of > sufficient size to hold all allowed values. > > Thus, clearly, it is a fault of a tool that formatted the media for FAT. > It should have picked correct values, or rejected incorrect values if those were > provided as overrides via command line options. If 256K works under WinDOS, then we should try to support it too. mav@ wants to increase MAXPHYS. I don't really believe in this, but if MAXPHYS is increased then it would be reasonable to increase MAXPHYS too, but probably not to more than 128K. >> fk@r500 /usr/crash $kgdb kernel.1/kernel.symbols vmcore.1 > [snip] >> Unread portion of the kernel message buffer: >> panic: getblk: size(262144) > MAXBSIZE(65536) > [snip] >> #11 0xffffffff803bedfb in panic (fmt=Variable "fmt" is not available. >> ) at /usr/src/sys/kern/kern_shutdown.c:562 BTW, why can't gdb find any variables? They are just stack variables whose address is easy to find. >> ... >> #14 0xffffffff8042f24e in bread (vp=Variable "vp" is not available. >> ) at /usr/src/sys/kern/vfs_bio.c:748 ... and isn't vp a variable? Maybe the bad default -O2 is destroying debugging. Kernels intended for being debugged (and that is almost all kernels) shouldn't be compiled with many optimizations. Post-gcc-3, -O2 breaks even backtraces by inlining static functions that are called only once. Bruce From owner-freebsd-current@FreeBSD.ORG Tue Mar 30 03:29:44 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8EEA6106567A for ; Tue, 30 Mar 2010 03:29:44 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id E77C18FC19 for ; Tue, 30 Mar 2010 03:29:43 +0000 (UTC) Received: by ewy24 with SMTP id 24so1626675ewy.33 for ; Mon, 29 Mar 2010 20:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=oRyKSoiCvcPqNunhEzy8unwZih86Sz2URlV6dgZmJjg=; b=nuNonIOTpxY7ApoouHUbPr5UevGmrP+v7/ffNZJYFthFbBGCiv8+HjwDLtYhGuX0UX y7p5Fr2EbPLbOwfqoviWKYIiwpzpIFsDTMNSj9NcjL58c07pAne0Lw0QVFKm5xJOSD6N gZ5eyH+PBSS4nYZvneKX9L7vH5Be0wsplGBf8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rJVskAV/fPfcfFNTcpoxlgnH3GLPhyl+SbuMwZhN4mCmTWPaqZYzfsWZjQ95tcXjl2 7Rsnxa2npet1v6joBON8KGz1RwSDVHd216nRcDTSQbeO4Ckalk6y+dbLAV68Zh4REAw9 vwqQ++Zh7pC87fzfMdhnHqdcrnqAmXDbfF4gc= MIME-Version: 1.0 Received: by 10.213.9.20 with HTTP; Mon, 29 Mar 2010 20:29:42 -0700 (PDT) In-Reply-To: <20100330101734.R5158@delplex.bde.org> References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <3a142e751003191021p141af009m6acf7d160c890cbb@mail.gmail.com> <20100319191133.46fe271c@r500.local> <3a142e751003191126j331e525fwb9e5573bbf6f7d58@mail.gmail.com> <4BAA30CB.1070707@icyb.net.ua> <20100328172537.501ed3d1@r500.local> <4BB0A053.9060007@freebsd.org> <20100330101734.R5158@delplex.bde.org> Date: Mon, 29 Mar 2010 23:29:42 -0400 Received: by 10.213.78.141 with SMTP id l13mr3027296ebk.21.1269919782905; Mon, 29 Mar 2010 20:29:42 -0700 (PDT) Message-ID: From: Ryan Stone To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Kostik Belousov , freebsd-current@freebsd.org, Bruce Evans , Andriy Gapon , Andriy Gapon Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Mar 2010 03:29:44 -0000 > > BTW, why can't gdb find any variables? They are just stack variables whose > address is easy to find. > > ... >>> >>> #14 0xffffffff8042f24e in bread (vp=Variable "vp" is not available. >>> ) at /usr/src/sys/kern/vfs_bio.c:748 >>> >> > ... and isn't vp a variable? Maybe the bad default -O2 is destroying > debugging. Kernels intended for being debugged (and that is almost all > kernels) shouldn't be compiled with many optimizations. Post-gcc-3, -O2 > breaks even backtraces by inlining static functions that are called only > once. > > On amd64 those parameters aren't stack variables. They're passed in registers, and gdb is horrible at figuring things out from there. I'm not sure if the problem actually exists in gdb or if the debug info provided by gcc is incomplete. Sometimes gdb is unable to print the value of the parameter because the register has been reused and the argument's value has been lost. From owner-freebsd-current@FreeBSD.ORG Tue Mar 30 06:59:59 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 121AC106567A; Tue, 30 Mar 2010 06:59:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id DD40A8FC1E; Tue, 30 Mar 2010 06:59:58 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2U6xw9Z070273; Tue, 30 Mar 2010 02:59:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2U6xwAq070269; Tue, 30 Mar 2010 06:59:58 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 30 Mar 2010 06:59:58 GMT Message-Id: <201003300659.o2U6xwAq070269@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 06:59:59 -0000 TB --- 2010-03-30 05:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-30 05:55:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-03-30 05:55:00 - cleaning the object tree TB --- 2010-03-30 05:55:20 - cvsupping the source tree TB --- 2010-03-30 05:55:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-03-30 05:56:04 - building world TB --- 2010-03-30 05:56:04 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-30 05:56:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-30 05:56:04 - TARGET=pc98 TB --- 2010-03-30 05:56:04 - TARGET_ARCH=i386 TB --- 2010-03-30 05:56:04 - TZ=UTC TB --- 2010-03-30 05:56:04 - __MAKE_CONF=/dev/null TB --- 2010-03-30 05:56:04 - cd /src TB --- 2010-03-30 05:56:04 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 30 05:56:05 UTC 2010 >>> 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 Tue Mar 30 06:54:52 UTC 2010 TB --- 2010-03-30 06:54:52 - generating LINT kernel config TB --- 2010-03-30 06:54:52 - cd /src/sys/pc98/conf TB --- 2010-03-30 06:54:52 - /usr/bin/make -B LINT TB --- 2010-03-30 06:54:52 - building LINT kernel TB --- 2010-03-30 06:54:52 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-30 06:54:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-30 06:54:52 - TARGET=pc98 TB --- 2010-03-30 06:54:52 - TARGET_ARCH=i386 TB --- 2010-03-30 06:54:52 - TZ=UTC TB --- 2010-03-30 06:54:52 - __MAKE_CONF=/dev/null TB --- 2010-03-30 06:54:52 - cd /src TB --- 2010-03-30 06:54:52 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Mar 30 06:54:52 UTC 2010 >>> 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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_rtl80x9.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pccard.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_print_debug_info': /src/sys/dev/e1000/if_em.c:4833: warning: format '%ld' expects type 'long int', but argument 3 has type 'u64' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-30 06:59:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-30 06:59:58 - ERROR: failed to build lint kernel TB --- 2010-03-30 06:59:58 - 2863.57 user 642.07 system 3897.32 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 30 07:01:28 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A2111065670; Tue, 30 Mar 2010 07:01:28 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 443B28FC1D; Tue, 30 Mar 2010 07:01:28 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2U71RBw082213; Tue, 30 Mar 2010 03:01:27 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2U71R4A082147; Tue, 30 Mar 2010 07:01:27 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 30 Mar 2010 07:01:27 GMT Message-Id: <201003300701.o2U71R4A082147@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Tue, 30 Mar 2010 07:01:28 -0000 TB --- 2010-03-30 05:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-30 05:55:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-03-30 05:55:00 - cleaning the object tree TB --- 2010-03-30 05:55:22 - cvsupping the source tree TB --- 2010-03-30 05:55:22 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-03-30 05:56:04 - building world TB --- 2010-03-30 05:56:04 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-30 05:56:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-30 05:56:04 - TARGET=i386 TB --- 2010-03-30 05:56:04 - TARGET_ARCH=i386 TB --- 2010-03-30 05:56:04 - TZ=UTC TB --- 2010-03-30 05:56:04 - __MAKE_CONF=/dev/null TB --- 2010-03-30 05:56:04 - cd /src TB --- 2010-03-30 05:56:04 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 30 05:56:05 UTC 2010 >>> 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 Tue Mar 30 06:55:05 UTC 2010 TB --- 2010-03-30 06:55:05 - generating LINT kernel config TB --- 2010-03-30 06:55:05 - cd /src/sys/i386/conf TB --- 2010-03-30 06:55:05 - /usr/bin/make -B LINT TB --- 2010-03-30 06:55:05 - building LINT kernel TB --- 2010-03-30 06:55:05 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-30 06:55:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-30 06:55:05 - TARGET=i386 TB --- 2010-03-30 06:55:05 - TARGET_ARCH=i386 TB --- 2010-03-30 06:55:05 - TZ=UTC TB --- 2010-03-30 06:55:05 - __MAKE_CONF=/dev/null TB --- 2010-03-30 06:55:05 - cd /src TB --- 2010-03-30 06:55:05 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Mar 30 06:55:05 UTC 2010 >>> 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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pccard.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/eisa/eisaconf.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_print_debug_info': /src/sys/dev/e1000/if_em.c:4833: warning: format '%ld' expects type 'long int', but argument 3 has type 'u64' *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-30 07:01:27 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-30 07:01:27 - ERROR: failed to build lint kernel TB --- 2010-03-30 07:01:27 - 2951.62 user 625.50 system 3986.65 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 30 07:28:01 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E6821065680; Tue, 30 Mar 2010 07:28:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id ED2D68FC15; Tue, 30 Mar 2010 07:28:00 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2U7S0GS013164; Tue, 30 Mar 2010 03:28:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2U7S0Rj013160; Tue, 30 Mar 2010 07:28:00 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 30 Mar 2010 07:28:00 GMT Message-Id: <201003300728.o2U7S0Rj013160@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Tue, 30 Mar 2010 07:28:01 -0000 TB --- 2010-03-30 05:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-30 05:55:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-03-30 05:55:00 - cleaning the object tree TB --- 2010-03-30 05:55:24 - cvsupping the source tree TB --- 2010-03-30 05:55:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-03-30 05:56:04 - building world TB --- 2010-03-30 05:56:04 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-30 05:56:04 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-30 05:56:04 - TARGET=amd64 TB --- 2010-03-30 05:56:04 - TARGET_ARCH=amd64 TB --- 2010-03-30 05:56:04 - TZ=UTC TB --- 2010-03-30 05:56:04 - __MAKE_CONF=/dev/null TB --- 2010-03-30 05:56:04 - cd /src TB --- 2010-03-30 05:56:04 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 30 05:56:05 UTC 2010 >>> 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 Tue Mar 30 07:22:05 UTC 2010 TB --- 2010-03-30 07:22:05 - generating LINT kernel config TB --- 2010-03-30 07:22:05 - cd /src/sys/amd64/conf TB --- 2010-03-30 07:22:05 - /usr/bin/make -B LINT TB --- 2010-03-30 07:22:05 - building LINT kernel TB --- 2010-03-30 07:22:05 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-30 07:22:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-30 07:22:05 - TARGET=amd64 TB --- 2010-03-30 07:22:05 - TARGET_ARCH=amd64 TB --- 2010-03-30 07:22:05 - TZ=UTC TB --- 2010-03-30 07:22:05 - __MAKE_CONF=/dev/null TB --- 2010-03-30 07:22:05 - cd /src TB --- 2010-03-30 07:22:05 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Mar 30 07:22:05 UTC 2010 >>> 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 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_lem.c -I/src/sys/dev/e1000 /src/sys/dev/e1000/if_lem.c: In function 'lem_ioctl': /src/sys/dev/e1000/if_lem.c:1125: error: 'lem_poll' undeclared (first use in this function) /src/sys/dev/e1000/if_lem.c:1125: error: (Each undeclared identifier is reported only once /src/sys/dev/e1000/if_lem.c:1125: 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 --- 2010-03-30 07:28:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-30 07:28:00 - ERROR: failed to build lint kernel TB --- 2010-03-30 07:28:00 - 4119.18 user 892.62 system 5579.44 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 30 08:05:41 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FCF0106566C; Tue, 30 Mar 2010 08:05:41 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7A8178FC12; Tue, 30 Mar 2010 08:05:41 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2U85eQF067103; Tue, 30 Mar 2010 04:05:40 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2U85eMw067099; Tue, 30 Mar 2010 08:05:40 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 30 Mar 2010 08:05:40 GMT Message-Id: <201003300805.o2U85eMw067099@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 08:05:41 -0000 TB --- 2010-03-30 07:01:28 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-30 07:01:28 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-03-30 07:01:28 - cleaning the object tree TB --- 2010-03-30 07:01:46 - cvsupping the source tree TB --- 2010-03-30 07:01:46 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-03-30 07:02:00 - building world TB --- 2010-03-30 07:02:00 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-30 07:02:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-30 07:02:00 - TARGET=powerpc TB --- 2010-03-30 07:02:00 - TARGET_ARCH=powerpc TB --- 2010-03-30 07:02:00 - TZ=UTC TB --- 2010-03-30 07:02:00 - __MAKE_CONF=/dev/null TB --- 2010-03-30 07:02:00 - cd /src TB --- 2010-03-30 07:02:00 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 30 07:02:05 UTC 2010 >>> 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 Tue Mar 30 08:01:19 UTC 2010 TB --- 2010-03-30 08:01:19 - generating LINT kernel config TB --- 2010-03-30 08:01:19 - cd /src/sys/powerpc/conf TB --- 2010-03-30 08:01:19 - /usr/bin/make -B LINT TB --- 2010-03-30 08:01:19 - building LINT kernel TB --- 2010-03-30 08:01:19 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-30 08:01:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-30 08:01:19 - TARGET=powerpc TB --- 2010-03-30 08:01:19 - TARGET_ARCH=powerpc TB --- 2010-03-30 08:01:19 - TZ=UTC TB --- 2010-03-30 08:01:19 - __MAKE_CONF=/dev/null TB --- 2010-03-30 08:01:19 - cd /src TB --- 2010-03-30 08:01:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Mar 30 08:01:19 UTC 2010 >>> 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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/de/if_de.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/dpt/dpt_pci.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/dpt/dpt_scsi.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror eisa_if.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_print_debug_info': /src/sys/dev/e1000/if_em.c:4833: warning: format '%ld' expects type 'long int', but argument 3 has type 'u64' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-30 08:05:40 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-30 08:05:40 - ERROR: failed to build lint kernel TB --- 2010-03-30 08:05:40 - 2946.27 user 581.66 system 3852.75 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 30 08:09:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8694C106564A; Tue, 30 Mar 2010 08:09:56 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1D45E8FC1B; Tue, 30 Mar 2010 08:09:55 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id o2U89Ixw070989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Mar 2010 11:09:18 +0300 (EEST) (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.14.4/8.14.4) with ESMTP id o2U89Iod077156; Tue, 30 Mar 2010 11:09:18 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id o2U89GFB077155; Tue, 30 Mar 2010 11:09:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 30 Mar 2010 11:09:16 +0300 From: Kostik Belousov To: Bruce Evans Message-ID: <20100330080916.GI2415@deviant.kiev.zoral.com.ua> References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <3a142e751003191021p141af009m6acf7d160c890cbb@mail.gmail.com> <20100319191133.46fe271c@r500.local> <3a142e751003191126j331e525fwb9e5573bbf6f7d58@mail.gmail.com> <4BAA30CB.1070707@icyb.net.ua> <20100328172537.501ed3d1@r500.local> <4BB0A053.9060007@freebsd.org> <20100330101734.R5158@delplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/KyuVX2Jeo6C4NIo" Content-Disposition: inline In-Reply-To: <20100330101734.R5158@delplex.bde.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_50, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Bruce Evans , Andriy Gapon , freebsd-current@freebsd.org, Andriy Gapon , Kostik Belousov Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Mar 2010 08:09:56 -0000 --/KyuVX2Jeo6C4NIo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 30, 2010 at 10:40:07AM +1100, Bruce Evans wrote: > On Mon, 29 Mar 2010, Andriy Gapon wrote: >=20 > >... > >I am not a FAT expert and I know to take Wikipedia with a grain of salt. > >But please take a look at this: > >http://en.wikipedia.org/wiki/File_Allocation_Table#Boot_Sector > > > >In our formula: > >SecPerClust *=3D pmp->pm_BlkPerSec; > >we have the following parameters: > >SecPerClust[in] - sectors per cluster > >pm_BlkPerSec - bytes per sector divided by 512 (pm_BytesPerSec / DEV_BSI= ZE) > >SecPerClust[out] - bytes per cluster divided by 512 > > > >So we have: > >sectors per cluster: 64 > >bytes per sector: 4096 > > > >That Wikipedia article says: "However, the value must not be such that t= he=20 > >number > >of bytes per cluster becomes greater than 32 KB." >=20 > 64K works under FreeBSD, and I often do performance tests with it (it giv= es > very bad performance). It should be avoided for portability too. >=20 > >But in our case it's 256K, the same value that is passed as 'size'=20 > >parameter to > >bread() in the crash stack trace below. >=20 > This error should be detected more cleanly. ffs fails the mount if the > block size exceeds 64K. ffs can handle larger block sizes, and it is > unfortunate that it is limited by the non-ffs parameter MAXBSIZE, but > MAXBSIZE has been 64K and non-fuzzy for so long that the portability > considerations for using larger values are even clearer -- larger sizes > shouldn't be used, but 64K works almost everywhere. I used to often do > performance tests with block size 64K for ffs. It gives very bad > performance, and since theire are more combinations of block sizes to > test for ffs than for msdosfs, I stopped testing block size 64K for ffs > long ago. >=20 > msdosfs has lots more sanity tests for its BPB than does ffs for its > superblock. Some of these were considered insane and removed, and there > never seems to have been one for this. >=20 > >By the way, that 32KB limit means that value of SecPerClust[out] should= =20 > >never be > >greater than 64 and SecPerClust[in] is limited to 128, so its current mu= st=20 > >be of > >sufficient size to hold all allowed values. > > > >Thus, clearly, it is a fault of a tool that formatted the media for FAT. > >It should have picked correct values, or rejected incorrect values if=20 > >those were > >provided as overrides via command line options. >=20 > If 256K works under WinDOS, then we should try to support it too. mav@ > wants to increase MAXPHYS. I don't really believe in this, but if MAXPHYS > is increased then it would be reasonable to increase MAXPHYS too, but > probably not to more than 128K. >=20 > >>fk@r500 /usr/crash $kgdb kernel.1/kernel.symbols vmcore.1 > >[snip] > >>Unread portion of the kernel message buffer: > >>panic: getblk: size(262144) > MAXBSIZE(65536) > >[snip] > >>#11 0xffffffff803bedfb in panic (fmt=3DVariable "fmt" is not available. > >>) at /usr/src/sys/kern/kern_shutdown.c:562 >=20 > BTW, why can't gdb find any variables? They are just stack variables who= se > address is easy to find. >=20 > >>... > >>#14 0xffffffff8042f24e in bread (vp=3DVariable "vp" is not available. > >>) at /usr/src/sys/kern/vfs_bio.c:748 >=20 > ... and isn't vp a variable? Maybe the bad default -O2 is destroying > debugging. Kernels intended for being debugged (and that is almost all > kernels) shouldn't be compiled with many optimizations. Post-gcc-3, -O2 > breaks even backtraces by inlining static functions that are called only > once. Dwarf interpreter in the very old gdb 6.1.1 that is provided in our tree is same old and buggy. I found that latest gdbs, like 6.8, 7.1 etc work much better even with slightly newer gcc 4.2.1 from the tree. amd64 calling conventions do not make this easier. --/KyuVX2Jeo6C4NIo Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkuxsawACgkQC3+MBN1Mb4idRgCg3JrETuvFBCdbyMY3M9/ytnwc ZI0AnR+UT4aBlMdk+rXGHjlYSW2r8Et5 =2+ap -----END PGP SIGNATURE----- --/KyuVX2Jeo6C4NIo-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 30 09:57:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2AF6C1065679 for ; Tue, 30 Mar 2010 09:57:34 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from web51803.mail.re2.yahoo.com (web51803.mail.re2.yahoo.com [206.190.38.234]) by mx1.freebsd.org (Postfix) with SMTP id BC02E8FC29 for ; Tue, 30 Mar 2010 09:57:33 +0000 (UTC) Received: (qmail 37137 invoked by uid 60001); 30 Mar 2010 09:57:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1269943052; bh=0RzB9Z5roKzbQtpC314H6b5COfTONWp64vj7XAXAFNk=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=tLdxFVVb8nXrlBhkyx/Bv7Gs6JEiICLhj1R2tdUZJfti+AeF4NfrLBijM+HKDO0vNt2gqGhbhUlBS4Ns7cw2DSahQNSZDjHorvexQ/8ee+l0OkHGS45a+UCNHGQixbx+r+H0AvxZ+sCQR/Tfi0IwmyxSsq7vKGfnJEDeC1O0uIU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=AHz8Vbgu9TbYrdUK+yiWScSEkYFh5asY4D9Mu+xf6srT9jYzzFIkLUl0XSWksNLpClda9lZNFIJvoakijMZ/jGeFwClq8Q034jO9gqw3/Lji9eicrkSVJjhIFDqZ+kdb1ZdphHT2XetZYVDRNMct9HhvLFrOm2UqShHLqaMWNcU=; Message-ID: <623907.37074.qm@web51803.mail.re2.yahoo.com> X-YMail-OSG: rmorCYUVM1lG.9ZbsXbxCmgm_Jww96lJEr0pzd6yg8Fr4bmzyQ7yIEIca5zWbSh5wt1UbP1X4vO1IQ_.w.x2PZ36Sn02Tj5d7Jt934dj0Vm5nMJOtOwwYPoLQK2cl9uu3b8NxpBtgphbk4RaVxnslMf2l1HU.QjJkfVwNcyPE0Bpq8Bbx4YolkR5qR5Nu_Q4cehUVBEqkO3KxPDY5XyeFTUiubOF5yhBJOdmG9WHbVL8IpT9nsQTY70VweAPBCAfFYvdqEYv7MDM9Eci64mw.WAlhzCTiFHfQwuj2DEk5l4sIh7e0d7dM2M6mjufBuOGzXReWwZparbpIXWkUCu9WZ_6mbGsEZXOWBLRRiNBrIWi2iLl0oJUpA-- Received: from [173.183.132.20] by web51803.mail.re2.yahoo.com via HTTP; Tue, 30 Mar 2010 02:57:32 PDT X-Mailer: YahooMailRC/324.3 YahooMailWebService/0.8.100.260964 References: <16641.96608.qm@web51806.mail.re2.yahoo.com> <4B9FA3E0.4050702@micom.mng.net> <633929.41041.qm@web51802.mail.re2.yahoo.com> <4BA22B8D.9030700@micom.mng.net> <375331.74876.qm@web51804.mail.re2.yahoo.com> <4BA38B26.6050208@micom.mng.net> <989377.89740.qm@web51802.mail.re2.yahoo.com> <4BAE01AC.7000509@gmail.com> Date: Tue, 30 Mar 2010 02:57:32 -0700 (PDT) From: PseudoCylon To: Ganbold In-Reply-To: <4BAE01AC.7000509@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Mar 2010 09:57:34 -0000 ----- Original Message ---- > From: Ganbold > To: PseudoCylon > Cc: freebsd-current@freebsd.org > Sent: Sat, March 27, 2010 7:01:32 AM > Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > > JFYI, I have just tested if_run and works fine on HEAD (i386). > But on RouterStation Pro it still has problem with your patch. > Ganbold Thank you for taking extra time to test the driver. Yes, it works on x86. It's hard to find bugs if everything is working on my computers (core2 and atom 330). Here is patch. http://dev.nasreddine.com/gitweb/?p=run.git;a=tree;f=dev/usb/wlan;h=695689599706b01ed9ef0f1be8dfc5790076e1ae;hb=bdc7558bfbd4f3b1c4491cb56853de24580a5434 Please download if_run.c and if_runvar.h (click "raw" to download) It will print out lots of messages. Please show me last 5 or so messages if it still panics. Does stock run(4) still works on RouterStation? There were some update (r205042). Yours (r205084) has it. AK __________________________________________________________________ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. From owner-freebsd-current@FreeBSD.ORG Tue Mar 30 15:36:44 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07CB6106564A; Tue, 30 Mar 2010 15:36:44 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.29.24]) by mx1.freebsd.org (Postfix) with ESMTP id 800878FC16; Tue, 30 Mar 2010 15:36:43 +0000 (UTC) Received: from [78.34.168.82] (helo=r500.local) by smtprelay02.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1NwdUf-0006I3-Tq; Tue, 30 Mar 2010 17:36:42 +0200 Date: Tue, 30 Mar 2010 17:36:37 +0200 From: Fabian Keil To: Andriy Gapon Message-ID: <20100330173637.202b4b1e@r500.local> In-Reply-To: <4BB111D4.8060809@freebsd.org> References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <3a142e751003191021p141af009m6acf7d160c890cbb@mail.gmail.com> <20100319191133.46fe271c@r500.local> <3a142e751003191126j331e525fwb9e5573bbf6f7d58@mail.gmail.com> <4BAA30CB.1070707@icyb.net.ua> <20100328172537.501ed3d1@r500.local> <4BB0A053.9060007@freebsd.org> <20100329222920.5eef6395@r500.local> <4BB111D4.8060809@freebsd.org> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/v5fqwvQ_RHXzLJFnNNln84F"; protocol="application/pgp-signature" X-Df-Sender: 775067 Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Mar 2010 15:36:44 -0000 --Sig_/v5fqwvQ_RHXzLJFnNNln84F Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andriy Gapon wrote: > on 29/03/2010 23:29 Fabian Keil said the following: > > Andriy Gapon wrote: > >> Thus, clearly, it is a fault of a tool that formatted the media for FA= T. > >> It should have picked correct values, or rejected incorrect values if > >> those were provided as overrides via command line options. > >=20 > > The kernel still shouldn't panic, though. >=20 > A quick reply to this point only - yes, I completely agree. > But remember that the panic happened only after the sources were modified= :) It wasn't clear from my message, but I was mainly referring to the division-by-zero panic mentioned at the beginning of the thread, for which I posted a work-around in <20100319191133.46fe271c@r500.local>. I think no backtrace has been posted yet, so here's the one I got with mostly vanilla sources from around 2010-02-14: Fatal trap 18: integer divide fault while in kernel mode cpuid =3D 0; apic id =3D 00 =20 instruction pointer =3D 0x20:0xffffffff803590b8 stack pointer =3D 0x28:0xffffff803e845620 frame pointer =3D 0x28:0xffffff803e845790 code segment =3D base 0x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 2877 (mount_msdosfs) panic: from debugger =20 cpuid =3D 0 =20 Uptime: 22m14s =20 Dumping 1992 MB (5 chunks) =20 chunk 0: 1MB (155 pages) ... ok chunk 1: 1990MB (509345 pages) 1974 [...] 6 ... ok chunk 2: 2MB (273 pages) ... ok chunk 3: 1MB (184 pages) [...] (kgdb) where #0 doadump () at pcpu.h:223 #1 0xffffffff803babdf in boot (howto=3D260) at /usr/src/sys/kern/kern_shut= down.c:416 #2 0xffffffff803bafdc in panic (fmt=3DVariable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xffffffff801f4eb7 in db_panic (addr=3DVariable "addr" is not available. ) at /usr/src/sys/ddb/db_command.c:478 #4 0xffffffff801f52c1 in db_command (last_cmdp=3D0xffffffff808a07c0, cmd_t= able=3DVariable "cmd_table" is not available. ) at /usr/src/sys/ddb/db_command.c:445 #5 0xffffffff801f5510 in db_command_loop () at /usr/src/sys/ddb/db_command= .c:498 #6 0xffffffff801f7469 in db_trap (type=3DVariable "type" is not available. ) at /usr/src/sys/ddb/db_main.c:229 #7 0xffffffff803e9945 in kdb_trap (type=3D18, code=3D0, tf=3D0xffffff803e8= 45570) at /usr/src/sys/kern/subr_kdb.c:535 #8 0xffffffff806129fd in trap_fatal (frame=3D0xffffff803e845570, eva=3DVar= iable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:853 #9 0xffffffff80613252 in trap (frame=3D0xffffff803e845570) at /usr/src/sys= /amd64/amd64/trap.c:647 #10 0xffffffff805fa4a3 in calltrap () at /usr/src/sys/amd64/amd64/exception= .S:224 #11 0xffffffff803590b8 in msdosfs_mount (mp=3D0xffffff003cba25f0) at /usr/s= rc/sys/fs/msdosfs/msdosfs_vfsops.c:610 #12 0xffffffff80436db0 in vfs_donmount (td=3DVariable "td" is not available. ) at /usr/src/sys/kern/vfs_mount.c:988 #13 0xffffffff804377b3 in nmount (td=3D0xffffff004a6d03b0, uap=3D0xffffff80= 3e845bf0) at /usr/src/sys/kern/vfs_mount.c:424 #14 0xffffffff80612e7d in syscall (frame=3D0xffffff803e845c80) at /usr/src/= sys/amd64/amd64/trap.c:1026 #15 0xffffffff805fa781 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exce= ption.S:373 #16 0x00000008007a292c in ?? () Previous frame inner to this frame (corrupt stack?) Fabian --Sig_/v5fqwvQ_RHXzLJFnNNln84F Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkuyGokACgkQBYqIVf93VJ01FQCgzTCOXx/348ZmuP86acLUZnqg WUIAoLqMebBMHm1832bU9/j3gdU+3Cgo =mdPO -----END PGP SIGNATURE----- --Sig_/v5fqwvQ_RHXzLJFnNNln84F-- From owner-freebsd-current@FreeBSD.ORG Tue Mar 30 15:41:51 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E324106566C for ; Tue, 30 Mar 2010 15:41:51 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7DE678FC12 for ; Tue, 30 Mar 2010 15:41:50 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA27971; Tue, 30 Mar 2010 18:41:47 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4BB21BBA.7030407@freebsd.org> Date: Tue, 30 Mar 2010 18:41:46 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: Fabian Keil References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <3a142e751003191021p141af009m6acf7d160c890cbb@mail.gmail.com> <20100319191133.46fe271c@r500.local> <3a142e751003191126j331e525fwb9e5573bbf6f7d58@mail.gmail.com> <4BAA30CB.1070707@icyb.net.ua> <20100328172537.501ed3d1@r500.local> <4BB0A053.9060007@freebsd.org> <20100329222920.5eef6395@r500.local> <4BB111D4.8060809@freebsd.org> <20100330173637.202b4b1e@r500.local> In-Reply-To: <20100330173637.202b4b1e@r500.local> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-current@freebsd.org Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Mar 2010 15:41:51 -0000 on 30/03/2010 18:36 Fabian Keil said the following: > Andriy Gapon wrote: > >> on 29/03/2010 23:29 Fabian Keil said the following: >>> Andriy Gapon wrote: >>>> Thus, clearly, it is a fault of a tool that formatted the media for FAT. >>>> It should have picked correct values, or rejected incorrect values if >>>> those were provided as overrides via command line options. >>> The kernel still shouldn't panic, though. >> A quick reply to this point only - yes, I completely agree. >> But remember that the panic happened only after the sources were modified :) > > It wasn't clear from my message, but I was mainly referring to the > division-by-zero panic mentioned at the beginning of the thread, > for which I posted a work-around in <20100319191133.46fe271c@r500.local>. Oh, yes, right. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Tue Mar 30 17:04:42 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DF76106564A; Tue, 30 Mar 2010 17:04:42 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 56B588FC08; Tue, 30 Mar 2010 17:04:42 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2UH4fN2033963; Tue, 30 Mar 2010 13:04:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2UH4faU033958; Tue, 30 Mar 2010 17:04:41 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 30 Mar 2010 17:04:41 GMT Message-Id: <201003301704.o2UH4faU033958@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 17:04:42 -0000 TB --- 2010-03-30 16:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-30 16:00:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-03-30 16:00:00 - cleaning the object tree TB --- 2010-03-30 16:00:14 - cvsupping the source tree TB --- 2010-03-30 16:00:14 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-03-30 16:00:47 - building world TB --- 2010-03-30 16:00:47 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-30 16:00:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-30 16:00:47 - TARGET=pc98 TB --- 2010-03-30 16:00:47 - TARGET_ARCH=i386 TB --- 2010-03-30 16:00:47 - TZ=UTC TB --- 2010-03-30 16:00:47 - __MAKE_CONF=/dev/null TB --- 2010-03-30 16:00:47 - cd /src TB --- 2010-03-30 16:00:47 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 30 16:00:48 UTC 2010 >>> 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 Tue Mar 30 16:59:39 UTC 2010 TB --- 2010-03-30 16:59:39 - generating LINT kernel config TB --- 2010-03-30 16:59:39 - cd /src/sys/pc98/conf TB --- 2010-03-30 16:59:39 - /usr/bin/make -B LINT TB --- 2010-03-30 16:59:39 - building LINT kernel TB --- 2010-03-30 16:59:39 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-30 16:59:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-30 16:59:39 - TARGET=pc98 TB --- 2010-03-30 16:59:39 - TARGET_ARCH=i386 TB --- 2010-03-30 16:59:39 - TZ=UTC TB --- 2010-03-30 16:59:39 - __MAKE_CONF=/dev/null TB --- 2010-03-30 16:59:39 - cd /src TB --- 2010-03-30 16:59:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Mar 30 16:59:39 UTC 2010 >>> 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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_rtl80x9.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pccard.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_print_debug_info': /src/sys/dev/e1000/if_em.c:4833: warning: format '%ld' expects type 'long int', but argument 3 has type 'u64' *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-30 17:04:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-30 17:04:41 - ERROR: failed to build lint kernel TB --- 2010-03-30 17:04:41 - 2867.13 user 636.50 system 3880.67 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 30 17:06:03 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 781371065688; Tue, 30 Mar 2010 17:06:03 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 505918FC1E; Tue, 30 Mar 2010 17:06:03 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2UH62aN045596; Tue, 30 Mar 2010 13:06:02 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2UH62Za045585; Tue, 30 Mar 2010 17:06:02 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 30 Mar 2010 17:06:02 GMT Message-Id: <201003301706.o2UH62Za045585@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Tue, 30 Mar 2010 17:06:03 -0000 TB --- 2010-03-30 16:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-30 16:00:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-03-30 16:00:00 - cleaning the object tree TB --- 2010-03-30 16:00:14 - cvsupping the source tree TB --- 2010-03-30 16:00:14 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-03-30 16:00:47 - building world TB --- 2010-03-30 16:00:47 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-30 16:00:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-30 16:00:47 - TARGET=i386 TB --- 2010-03-30 16:00:47 - TARGET_ARCH=i386 TB --- 2010-03-30 16:00:47 - TZ=UTC TB --- 2010-03-30 16:00:47 - __MAKE_CONF=/dev/null TB --- 2010-03-30 16:00:47 - cd /src TB --- 2010-03-30 16:00:47 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 30 16:00:48 UTC 2010 >>> 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 Tue Mar 30 16:59:49 UTC 2010 TB --- 2010-03-30 16:59:49 - generating LINT kernel config TB --- 2010-03-30 16:59:49 - cd /src/sys/i386/conf TB --- 2010-03-30 16:59:49 - /usr/bin/make -B LINT TB --- 2010-03-30 16:59:49 - building LINT kernel TB --- 2010-03-30 16:59:49 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-30 16:59:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-30 16:59:49 - TARGET=i386 TB --- 2010-03-30 16:59:49 - TARGET_ARCH=i386 TB --- 2010-03-30 16:59:49 - TZ=UTC TB --- 2010-03-30 16:59:49 - __MAKE_CONF=/dev/null TB --- 2010-03-30 16:59:49 - cd /src TB --- 2010-03-30 16:59:49 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Mar 30 16:59:49 UTC 2010 >>> 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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pccard.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/eisa/eisaconf.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_print_debug_info': /src/sys/dev/e1000/if_em.c:4833: warning: format '%ld' expects type 'long int', but argument 3 has type 'u64' *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-30 17:06:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-30 17:06:02 - ERROR: failed to build lint kernel TB --- 2010-03-30 17:06:02 - 2952.61 user 620.50 system 3961.82 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 30 17:32:02 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3963C106566C; Tue, 30 Mar 2010 17:32:02 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 099408FC0A; Tue, 30 Mar 2010 17:32:01 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2UHW1EI078209; Tue, 30 Mar 2010 13:32:01 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2UHW1wd078207; Tue, 30 Mar 2010 17:32:01 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 30 Mar 2010 17:32:01 GMT Message-Id: <201003301732.o2UHW1wd078207@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Tue, 30 Mar 2010 17:32:02 -0000 TB --- 2010-03-30 16:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-30 16:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-03-30 16:00:00 - cleaning the object tree TB --- 2010-03-30 16:00:26 - cvsupping the source tree TB --- 2010-03-30 16:00:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-03-30 16:00:47 - building world TB --- 2010-03-30 16:00:47 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-30 16:00:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-30 16:00:47 - TARGET=amd64 TB --- 2010-03-30 16:00:47 - TARGET_ARCH=amd64 TB --- 2010-03-30 16:00:47 - TZ=UTC TB --- 2010-03-30 16:00:47 - __MAKE_CONF=/dev/null TB --- 2010-03-30 16:00:47 - cd /src TB --- 2010-03-30 16:00:47 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 30 16:00:48 UTC 2010 >>> 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 Tue Mar 30 17:26:13 UTC 2010 TB --- 2010-03-30 17:26:13 - generating LINT kernel config TB --- 2010-03-30 17:26:13 - cd /src/sys/amd64/conf TB --- 2010-03-30 17:26:13 - /usr/bin/make -B LINT TB --- 2010-03-30 17:26:13 - building LINT kernel TB --- 2010-03-30 17:26:13 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-30 17:26:13 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-30 17:26:13 - TARGET=amd64 TB --- 2010-03-30 17:26:13 - TARGET_ARCH=amd64 TB --- 2010-03-30 17:26:13 - TZ=UTC TB --- 2010-03-30 17:26:13 - __MAKE_CONF=/dev/null TB --- 2010-03-30 17:26:13 - cd /src TB --- 2010-03-30 17:26:13 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Mar 30 17:26:13 UTC 2010 >>> 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 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_lem.c -I/src/sys/dev/e1000 /src/sys/dev/e1000/if_lem.c: In function 'lem_ioctl': /src/sys/dev/e1000/if_lem.c:1125: error: 'lem_poll' undeclared (first use in this function) /src/sys/dev/e1000/if_lem.c:1125: error: (Each undeclared identifier is reported only once /src/sys/dev/e1000/if_lem.c:1125: 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 --- 2010-03-30 17:32:01 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-30 17:32:01 - ERROR: failed to build lint kernel TB --- 2010-03-30 17:32:01 - 4114.09 user 884.90 system 5520.43 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 30 18:11:14 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBBEF1065670; Tue, 30 Mar 2010 18:11:14 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 9A1818FC0C; Tue, 30 Mar 2010 18:11:14 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2UIBDTg077735; Tue, 30 Mar 2010 14:11:13 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2UIBDPx077728; Tue, 30 Mar 2010 18:11:13 GMT (envelope-from tinderbox@freebsd.org) Date: Tue, 30 Mar 2010 18:11:13 GMT Message-Id: <201003301811.o2UIBDPx077728@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on powerpc/powerpc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 18:11:15 -0000 TB --- 2010-03-30 17:06:02 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-30 17:06:02 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2010-03-30 17:06:02 - cleaning the object tree TB --- 2010-03-30 17:06:12 - cvsupping the source tree TB --- 2010-03-30 17:06:12 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2010-03-30 17:06:39 - building world TB --- 2010-03-30 17:06:39 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-30 17:06:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-30 17:06:39 - TARGET=powerpc TB --- 2010-03-30 17:06:39 - TARGET_ARCH=powerpc TB --- 2010-03-30 17:06:39 - TZ=UTC TB --- 2010-03-30 17:06:39 - __MAKE_CONF=/dev/null TB --- 2010-03-30 17:06:39 - cd /src TB --- 2010-03-30 17:06:39 - /usr/bin/make -B buildworld >>> World build started on Tue Mar 30 17:06:39 UTC 2010 >>> 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 Tue Mar 30 18:06:50 UTC 2010 TB --- 2010-03-30 18:06:50 - generating LINT kernel config TB --- 2010-03-30 18:06:50 - cd /src/sys/powerpc/conf TB --- 2010-03-30 18:06:50 - /usr/bin/make -B LINT TB --- 2010-03-30 18:06:50 - building LINT kernel TB --- 2010-03-30 18:06:50 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-30 18:06:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-30 18:06:50 - TARGET=powerpc TB --- 2010-03-30 18:06:50 - TARGET_ARCH=powerpc TB --- 2010-03-30 18:06:50 - TZ=UTC TB --- 2010-03-30 18:06:50 - __MAKE_CONF=/dev/null TB --- 2010-03-30 18:06:50 - cd /src TB --- 2010-03-30 18:06:50 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Mar 30 18:06:50 UTC 2010 >>> 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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/de/if_de.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/dpt/dpt_pci.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/dpt/dpt_scsi.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror eisa_if.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -msoft-float -fno-omit-frame-pointer -msoft-float -mno-altivec -ffreestanding -fstack-protector -Werror /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors /src/sys/dev/e1000/if_em.c: In function 'em_print_debug_info': /src/sys/dev/e1000/if_em.c:4833: warning: format '%ld' expects type 'long int', but argument 3 has type 'u64' *** Error code 1 Stop in /obj/powerpc/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-30 18:11:13 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-30 18:11:13 - ERROR: failed to build lint kernel TB --- 2010-03-30 18:11:13 - 2958.38 user 575.52 system 3910.98 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full From owner-freebsd-current@FreeBSD.ORG Tue Mar 30 18:01:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E7B2106564A for ; Tue, 30 Mar 2010 18:01:46 +0000 (UTC) (envelope-from drbaud@yahoo.com) Received: from web65613.mail.ac4.yahoo.com (web65613.mail.ac4.yahoo.com [76.13.9.81]) by mx1.freebsd.org (Postfix) with SMTP id D4ED48FC08 for ; Tue, 30 Mar 2010 18:01:45 +0000 (UTC) Received: (qmail 2347 invoked by uid 60001); 30 Mar 2010 17:35:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1269970504; bh=sTp0a5HH6YlGoM3nQ2gR6BwLZRy2zUyh3yE9JkPL6fQ=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=5DCzrpcmUCnF9P7AxK80ehPkHBOSBtkZXyBNp6hxufoHaMBSIGX3FobUjV1TRgqpb5WlmvnHbssmqu/zitGYGrl8BrhFu52Ksc1V2serMJaOK814bb4oo1md0Dwmk0hjgW+isn2/ePYs/zh5bjll3Yk5X2ZLk2PQFebB8FiyBsg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=rMdIHGM7e/aK+wJ28cch8pg1Nqje1pi+D/8tahjoPsBwye4RRfEJ5wM0VdfoAeTOGY+k3SD/W1cEcGoGmlqd820V1+OZCxUI5xTqSDlzMUYHLFGymIkB7DjLdgl/vnOsfwk3gxl6Sc7xxmHyW1YqQ7CQPlDLafV9juMUUxGtEgw=; Message-ID: <745921.1949.qm@web65613.mail.ac4.yahoo.com> X-YMail-OSG: vCLmAzoVM1lwSiGAPTv4Dvg9qyaPe3hQSlvgS7pqUZtMOgK 00UyeVyDW3giZIXIkCAbRG6wBQJFtXK.KDB3Po9C4ZrckuxqNaFw75ciDoW5 XF33gXW33k776dkc4v1hBYG8Yt_Jq5r6HTQaZ8FKW8i0kFXKku3j5ypqFtl1 f7aOuDkZ1PPoMY0f9mnZfxKdd0Em3q_gAaFi18GOXAVUZpL.9jsRbFfKuDeb ePyukRXncPIVQtdWTanuE6e9AkyyFaiVhH7zFybMcfGXlBdwtii2dwdhJLnB 06JGiZBzX8EHGqQCqzSCRtPA2NaVDQBkeDkG.DVOuSezqxo_.qOCsKA-- Received: from [64.238.244.146] by web65613.mail.ac4.yahoo.com via HTTP; Tue, 30 Mar 2010 10:35:04 PDT X-Mailer: YahooMailClassic/10.0.8 YahooMailWebService/0.8.100.260964 Date: Tue, 30 Mar 2010 10:35:04 -0700 (PDT) From: "Dr. Baud" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Tue, 30 Mar 2010 18:11:22 +0000 Subject: pmap_extract question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Mar 2010 18:01:46 -0000 Say I have a kernel module that allocates a contiguous chunk of kernel physical memory (note that a call to vtophys() reports a non-zero value): memory_chunk = contigmalloc( memory_chunk_length, NULL, M_NOWAIT, 0UL, ~0UL, PAGE_SIZE, 0); The kernel virtual address returned from contigmalloc is passed to a user application which maps the chunk to the virtual address space of the application: fd = open("/dev/mem", O_RDWR); mapped_memory_chunk = mmap( NULL, memory_chunk_length, PROT_READ | PROT_WRITE, MAP_SHARED, fd, (off_t) memory_chunk); Now consider that the mapped memory chunk address is then passed back to the kernel module. My question is; shouldn't pmap_extract(9) be able to determine the physical address? struct thread *td = curthread; pmap_t pmap = &td->td_proc->p_vmspace->vm_pmap; physical_address = pmap_extract(pmap, mapped_memory_chunk); In this example pmap_extract returns 0. Note also that /proc//map indicates the page(s) associated with the virtual addresses are not resident, e.g.: 0x801731000 0x801732000 0 0 0xffffff01d1ecd360 rw- 10 0 0x1000 NCOW NNC device - The first two values shown are the start (address returned from mmap above) and end addresses. The third, in this case zero, is intended to represent whether the pages are in resident. This value is simply the result of a call to pmap_extract. Is this to be expected? Should mmap(2) serve up a virtual address which pmap_extract cannot determine the physical address? Or is there a flaw in this logic? Thanks in advance...... Dr From owner-freebsd-current@FreeBSD.ORG Tue Mar 30 18:29:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 31BCE106564A for ; Tue, 30 Mar 2010 18:29:07 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id B872A8FC0A for ; Tue, 30 Mar 2010 18:29:06 +0000 (UTC) Received: by ewy24 with SMTP id 24so2127275ewy.33 for ; Tue, 30 Mar 2010 11:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=U1Qzxlws15q4/q1KjvTu6WzNbxZtMNpu6Ki2aT0LxOM=; b=mZ+7ufZhPdVX26UcJrM92u/zYe/it9H8U1sO/MToCNSMXTO7MPqPriFNIDQGaoVAxo FJreIxXIyNlWkMIV6AqFrIRJ2VBDiEPIBZ4Y8Hn5KOol74vWoqyxnULxg8njL9RnG+zv OqROr+nciJYQP4fJ+2UOlMx2fCA/Kt0gObwQQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WP0VUXKh3yiUvxb4DA2nsnA84+yEKPZfhQle6iIXyUWsMuNFUe53m+dWSr8bsB3wEG cdaYbDDftx9EIJOPv9IjIQy059/uE67M8tRWQeYHlSQ8g/sG76nTYjCda5AfJP/dz/lq 93vHJNSoueSsUR9TKNImYTODge1+e1jDdCLpY= MIME-Version: 1.0 Received: by 10.213.9.20 with HTTP; Tue, 30 Mar 2010 11:29:04 -0700 (PDT) In-Reply-To: <745921.1949.qm@web65613.mail.ac4.yahoo.com> References: <745921.1949.qm@web65613.mail.ac4.yahoo.com> Date: Tue, 30 Mar 2010 14:29:04 -0400 Received: by 10.213.48.13 with SMTP id p13mr2914155ebf.18.1269973745021; Tue, 30 Mar 2010 11:29:05 -0700 (PDT) Message-ID: From: Ryan Stone To: "Dr. Baud" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: pmap_extract question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Mar 2010 18:29:07 -0000 Assuming that you're using the right pmap(it looks like you are, but it depends on the thread context in which you're running), that will only work if the userland application has touched the page and faulted it in. If it's never tried to access the page it will never be mapped into the process's page tables. From owner-freebsd-current@FreeBSD.ORG Tue Mar 30 18:28:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B9B8106564A for ; Tue, 30 Mar 2010 18:28:33 +0000 (UTC) (envelope-from drbaud@yahoo.com) Received: from web65606.mail.ac4.yahoo.com (web65606.mail.ac4.yahoo.com [76.13.9.74]) by mx1.freebsd.org (Postfix) with SMTP id C24E98FC0A for ; Tue, 30 Mar 2010 18:28:32 +0000 (UTC) Received: (qmail 22867 invoked by uid 60001); 30 Mar 2010 18:28:32 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1269973711; bh=6GDyafb90DLxMzcUuaLLnczPN6YTYDB28SPw9IdvvCc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ltPoWwJxIakqUI1YUWNfomz1HEuhw8fKAJeEgxbLKDuaiyDV+dEl9eJtpzmR6HTf2deGmOIbzZSrBAuiQvCDcUA6eGl96cYbrDnsVrjkuH3ZL9yJ6QDVpuUryMuXLe5l2IDs7NF8WM9aQ/VoP2swFW+XuFY8uGMiKX155f/Mm1o= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=URWqgDIios/l8afKNMqruhWpNQZT5Z/7LXk7oojf9UK8c4RUhOj8237vjfHyrc9b99ndrMY13B2PS+IeQdBghCehR4IRwKEsX9PKCnlQGH/fDEqKLYzUpDet2hGWGgJvt4h6i9GztrZIPoXbC7Co16Gyq43nPmOz6G9RfgWDZzQ=; Message-ID: <925011.22864.qm@web65606.mail.ac4.yahoo.com> X-YMail-OSG: wm5L3CUVM1kjQUj0SmLMU_jtoOoPNOCYPI800N4HA1cpWt2 ofldpV5FBkLtcNWWPO3e7moCDl4RU78Qn4Uie0.pTotgeI44QZuZhcDY0eY0 GMtWB5LypZJgg6FQKyZ5dJn4NpstZ.puCJijfJxpdptGeZyzGAgIGaeio4YV SIAkq6hUN5d8iQ69tfEqrdFnLs.CyBGapzskl0NV1231gNHDkTfDL98tKT0H Q8VkFkU9uOekLsl6CnNfUoy.ZWY6.VatxlgcyKiUrEBUrCseKEkg6eLRaTmL 2NjtcPmQcw.NrwhbQjd2pwaOSxJsZX.s6gqoyFjhoKA9Fq2SmAStC4BiUsOH k Received: from [64.238.244.146] by web65606.mail.ac4.yahoo.com via HTTP; Tue, 30 Mar 2010 11:28:31 PDT X-Mailer: YahooMailClassic/10.0.8 YahooMailWebService/0.8.100.260964 Date: Tue, 30 Mar 2010 11:28:31 -0700 (PDT) From: "Dr. Baud" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 30 Mar 2010 18:31:50 +0000 Subject: Re: pmap_extract question X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Mar 2010 18:28:33 -0000 =0A It was pointed out that you need to pass physical address to mmap. A = step was missed in posted recipe. Consider that the return from vtophys(mem= ory_chunk) was passed at the offset parameter. Sorry for the confusion.=0A= =0A--- On Tue, 3/30/10, Dr. Baud wrote:=0A=0A> From: Dr.= Baud =0A> Subject: pmap_extract question=0A> To: freebsd= -current@freebsd.org=0A> Date: Tuesday, March 30, 2010, 12:35 PM=0A> =0A> = =A0 =A0 Say I have a kernel module that allocates a=0A> contiguous chunk of= kernel physical memory (note that a call=0A> to vtophys() reports a non-ze= ro value):=0A> =0A> memory_chunk =3D contigmalloc(=A0 =A0=0A> memory_chunk_= length,=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0=0A> NULL,=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0=0A> M_NOWAIT,=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0=0A> 0UL,=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> ~0UL,=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> PAGE_SIZE,=0A> =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 0);=0A> =0A> =A0 =A0 Th= e kernel virtual address returned from=0A> contigmalloc is passed to a user= application which maps the=0A> chunk to the virtual address space of the a= pplication:=0A> =0A> fd =3D open("/dev/mem", O_RDWR);=0A> mapped_memory_chu= nk =3D mmap( NULL,=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 = =A0 =A0=0A> memory_chunk_length,=0A> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> = =A0 =A0 =A0 =A0 =A0 =A0 PROT_READ |=0A> PROT_WRITE,=0A> =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0 MAP_SHARED,=0A> =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0 fd,=0A> =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0=0A> =A0 =A0 =A0 =A0 =A0 =A0 (off_t)=0A> memory_chunk);=0A> =0A> = =A0 =A0 Now consider that the mapped memory chunk=0A> address is then passe= d back to the kernel module. My=0A> question is; shouldn't pmap_extract(9) = be able to determine=0A> the physical address?=0A> =0A> struct thread *td = =3D curthread;=0A> pmap_t pmap =3D=0A> &td->td_proc->p_vmspace->vm_pmap;=0A= > physical_address =3D pmap_extract(pmap,=0A> mapped_memory_chunk);=0A> =0A= > =A0 =A0 In this example pmap_extract returns 0. Note=0A> also that /proc/= /map indicates the page(s)=0A> associated with the virtual addresses a= re not resident,=0A> e.g.:=0A> =0A> 0x801731000 0x801732000 0 0 0xffffff01d= 1ecd360 rw- 10 0=0A> 0x1000 NCOW NNC device -=0A> =0A> =A0 =A0 The first tw= o values shown are the start=0A> (address returned from mmap above) and end= addresses. The=0A> third, in this case zero, is intended to represent whet= her=0A> the pages are in resident. This value is simply the result=0A> of a= call to pmap_extract.=0A> =0A> =A0 =A0 Is this to be expected? Should mmap= (2) serve=0A> up a virtual address which pmap_extract cannot determine the= =0A> physical address? Or is there a flaw in this logic?=0A> =0A> =A0 =A0 T= hanks in advance......=0A> =0A> =A0 =A0 Dr=0A> =0A> =0A> =0A> =0A> =0A> =A0= =A0 =A0 =0A> =0A=0A=0A From owner-freebsd-current@FreeBSD.ORG Wed Mar 31 02:59:47 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9DCD9106564A; Wed, 31 Mar 2010 02:59:47 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6658B8FC0A; Wed, 31 Mar 2010 02:59:47 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2V2xk3u097189; Tue, 30 Mar 2010 22:59:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2V2xkBR097158; Wed, 31 Mar 2010 02:59:46 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 31 Mar 2010 02:59:46 GMT Message-Id: <201003310259.o2V2xkBR097158@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Wed, 31 Mar 2010 02:59:47 -0000 TB --- 2010-03-31 01:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-31 01:55:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-03-31 01:55:00 - cleaning the object tree TB --- 2010-03-31 01:55:19 - cvsupping the source tree TB --- 2010-03-31 01:55:19 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-03-31 01:55:50 - building world TB --- 2010-03-31 01:55:50 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-31 01:55:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-31 01:55:50 - TARGET=pc98 TB --- 2010-03-31 01:55:50 - TARGET_ARCH=i386 TB --- 2010-03-31 01:55:50 - TZ=UTC TB --- 2010-03-31 01:55:50 - __MAKE_CONF=/dev/null TB --- 2010-03-31 01:55:50 - cd /src TB --- 2010-03-31 01:55:50 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 31 01:55:50 UTC 2010 >>> 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 Mar 31 02:54:42 UTC 2010 TB --- 2010-03-31 02:54:42 - generating LINT kernel config TB --- 2010-03-31 02:54:42 - cd /src/sys/pc98/conf TB --- 2010-03-31 02:54:42 - /usr/bin/make -B LINT TB --- 2010-03-31 02:54:42 - building LINT kernel TB --- 2010-03-31 02:54:42 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-31 02:54:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-31 02:54:42 - TARGET=pc98 TB --- 2010-03-31 02:54:42 - TARGET_ARCH=i386 TB --- 2010-03-31 02:54:42 - TZ=UTC TB --- 2010-03-31 02:54:42 - __MAKE_CONF=/dev/null TB --- 2010-03-31 02:54:42 - cd /src TB --- 2010-03-31 02:54:42 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 31 02:54:42 UTC 2010 >>> 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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_lem.c -I/src/sys/dev/e1000 /src/sys/dev/e1000/if_lem.c: In function 'lem_ioctl': /src/sys/dev/e1000/if_lem.c:1125: error: 'lem_poll' undeclared (first use in this function) /src/sys/dev/e1000/if_lem.c:1125: error: (Each undeclared identifier is reported only once /src/sys/dev/e1000/if_lem.c:1125: 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 --- 2010-03-31 02:59:46 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-31 02:59:46 - ERROR: failed to build lint kernel TB --- 2010-03-31 02:59:46 - 2865.23 user 640.34 system 3885.76 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 31 03:01:18 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60F86106566C; Wed, 31 Mar 2010 03:01:18 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 399FD8FC15; Wed, 31 Mar 2010 03:01:18 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2V31H5W013373; Tue, 30 Mar 2010 23:01:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2V31HI7013361; Wed, 31 Mar 2010 03:01:17 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 31 Mar 2010 03:01:17 GMT Message-Id: <201003310301.o2V31HI7013361@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Wed, 31 Mar 2010 03:01:18 -0000 TB --- 2010-03-31 01:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-31 01:55:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-03-31 01:55:00 - cleaning the object tree TB --- 2010-03-31 01:55:20 - cvsupping the source tree TB --- 2010-03-31 01:55:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-03-31 01:55:50 - building world TB --- 2010-03-31 01:55:50 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-31 01:55:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-31 01:55:50 - TARGET=i386 TB --- 2010-03-31 01:55:50 - TARGET_ARCH=i386 TB --- 2010-03-31 01:55:50 - TZ=UTC TB --- 2010-03-31 01:55:50 - __MAKE_CONF=/dev/null TB --- 2010-03-31 01:55:50 - cd /src TB --- 2010-03-31 01:55:50 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 31 01:55:50 UTC 2010 >>> 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 Mar 31 02:55:03 UTC 2010 TB --- 2010-03-31 02:55:03 - generating LINT kernel config TB --- 2010-03-31 02:55:03 - cd /src/sys/i386/conf TB --- 2010-03-31 02:55:03 - /usr/bin/make -B LINT TB --- 2010-03-31 02:55:03 - building LINT kernel TB --- 2010-03-31 02:55:03 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-31 02:55:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-31 02:55:03 - TARGET=i386 TB --- 2010-03-31 02:55:03 - TARGET_ARCH=i386 TB --- 2010-03-31 02:55:03 - TZ=UTC TB --- 2010-03-31 02:55:03 - __MAKE_CONF=/dev/null TB --- 2010-03-31 02:55:03 - cd /src TB --- 2010-03-31 02:55:03 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 31 02:55:03 UTC 2010 >>> 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/eisa/eisaconf.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_lem.c -I/src/sys/dev/e1000 /src/sys/dev/e1000/if_lem.c: In function 'lem_ioctl': /src/sys/dev/e1000/if_lem.c:1125: error: 'lem_poll' undeclared (first use in this function) /src/sys/dev/e1000/if_lem.c:1125: error: (Each undeclared identifier is reported only once /src/sys/dev/e1000/if_lem.c:1125: error: for each function it appears in.) *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-31 03:01:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-31 03:01:17 - ERROR: failed to build lint kernel TB --- 2010-03-31 03:01:17 - 2953.71 user 623.42 system 3976.86 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 31 03:27:21 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4081C1065673; Wed, 31 Mar 2010 03:27:21 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 193B38FC16; Wed, 31 Mar 2010 03:27:20 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2V3RKaa044150; Tue, 30 Mar 2010 23:27:20 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2V3RKoe044149; Wed, 31 Mar 2010 03:27:20 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 31 Mar 2010 03:27:20 GMT Message-Id: <201003310327.o2V3RKoe044149@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 03:27:21 -0000 TB --- 2010-03-31 01:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-31 01:55:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-03-31 01:55:00 - cleaning the object tree TB --- 2010-03-31 01:55:25 - cvsupping the source tree TB --- 2010-03-31 01:55:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-03-31 01:55:50 - building world TB --- 2010-03-31 01:55:50 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-31 01:55:50 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-31 01:55:50 - TARGET=amd64 TB --- 2010-03-31 01:55:50 - TARGET_ARCH=amd64 TB --- 2010-03-31 01:55:50 - TZ=UTC TB --- 2010-03-31 01:55:50 - __MAKE_CONF=/dev/null TB --- 2010-03-31 01:55:50 - cd /src TB --- 2010-03-31 01:55:50 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 31 01:55:50 UTC 2010 >>> 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 Mar 31 03:21:27 UTC 2010 TB --- 2010-03-31 03:21:27 - generating LINT kernel config TB --- 2010-03-31 03:21:27 - cd /src/sys/amd64/conf TB --- 2010-03-31 03:21:27 - /usr/bin/make -B LINT TB --- 2010-03-31 03:21:27 - building LINT kernel TB --- 2010-03-31 03:21:27 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-31 03:21:27 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-31 03:21:27 - TARGET=amd64 TB --- 2010-03-31 03:21:27 - TARGET_ARCH=amd64 TB --- 2010-03-31 03:21:27 - TZ=UTC TB --- 2010-03-31 03:21:27 - __MAKE_CONF=/dev/null TB --- 2010-03-31 03:21:27 - cd /src TB --- 2010-03-31 03:21:27 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 31 03:21:27 UTC 2010 >>> 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 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_lem.c -I/src/sys/dev/e1000 /src/sys/dev/e1000/if_lem.c: In function 'lem_ioctl': /src/sys/dev/e1000/if_lem.c:1125: error: 'lem_poll' undeclared (first use in this function) /src/sys/dev/e1000/if_lem.c:1125: error: (Each undeclared identifier is reported only once /src/sys/dev/e1000/if_lem.c:1125: 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 --- 2010-03-31 03:27:20 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-31 03:27:20 - ERROR: failed to build lint kernel TB --- 2010-03-31 03:27:20 - 4113.03 user 887.34 system 5539.50 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 31 07:25:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8AF93106566C; Wed, 31 Mar 2010 07:25:43 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by mx1.freebsd.org (Postfix) with ESMTP id B9B9E8FC17; Wed, 31 Mar 2010 07:25:42 +0000 (UTC) Received: by fxm25 with SMTP id 25so229645fxm.3 for ; Wed, 31 Mar 2010 00:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=tt83/8X7/YebasZfTxnk+h3SXjse3clL7domvKAf1TI=; b=L0Bo/V/gOGeqIMvGdC0/ogySAT8akd4MRzOyyDwXyqYNYKz2X1XvlWda3RgZM25QX0 Q8hNxkcbRZAnzy2yWq1m1bzzenAJOSHQOHBMGcAuAgJV6VXvzD5EiivLisvK1i7a4kke sZCYzNxnZIjAQLhCwX4iZW8UG6UCcR+KTzuK4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=CuPTcaCvFtIJGszPTqG5vz/xGYau/nUVgzBF7fp3KLoHw5ly+7iLax4AFV4Zt8UhYq XvfnmCrXBEdfybDY2ld4BcJcq2tCD2PRPjd7Slzx3RB462R9sjXrVvQrgNcidp7FVmEU Yc/UavfgSdJiBJZZ3Y+gqEBpqBKbz1++RDYQc= Received: by 10.223.28.133 with SMTP id m5mr7527543fac.37.1270020341413; Wed, 31 Mar 2010 00:25:41 -0700 (PDT) Received: from mavbook.mavhome.dp.ua (pc.mavhome.dp.ua [212.86.226.226]) by mx.google.com with ESMTPS id 15sm4600919fxm.7.2010.03.31.00.25.39 (version=SSLv3 cipher=RC4-MD5); Wed, 31 Mar 2010 00:25:40 -0700 (PDT) Sender: Alexander Motin Message-ID: <4BB2F8F2.1020502@FreeBSD.org> Date: Wed, 31 Mar 2010 10:25:38 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.23 (X11/20091212) MIME-Version: 1.0 To: Norikatsu Shigemura References: <1266441783.00220803.1266429001@10.7.7.3> In-Reply-To: <1266441783.00220803.1266429001@10.7.7.3> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, freebsd-current@freebsd.org Subject: Re: ATA_CAM-ed mvsata(4) on OpenRD-client X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Mar 2010 07:25:43 -0000 Hi. Norikatsu Shigemura wrote: > I got a OpenRD-client (Marvell 88F6281 SoC), and I'm tring to > make mvsata(4) ATA_CAM, like following: > > But I got following panic, my I help you? > In this time, I attached no devices to SATA/eSATA port. > - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > ata1: on sata0 > ata1: [MPSAFE] > ata1: [ITHREAD] > spin lock 0xc3766680 (fvH) held by 0xc3613b48 (tid -1061308344) too long > panic: spin lock held too long > KDB: enter: panic > [ thread pid 0 tid 100000 ] > Stopped at 0xc09dcb50 = kdb_enter+0x48: ldrb r15, [r15, r15, ror r15]! > db> Fixed at SVN r205967. -- Alexander Motin From owner-freebsd-current@FreeBSD.ORG Wed Mar 31 09:18:22 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DBED1065673 for ; Wed, 31 Mar 2010 09:18:22 +0000 (UTC) (envelope-from matpockuh@gmail.com) Received: from mail-fx0-f225.google.com (mail-fx0-f225.google.com [209.85.220.225]) by mx1.freebsd.org (Postfix) with ESMTP id 016808FC12 for ; Wed, 31 Mar 2010 09:18:21 +0000 (UTC) Received: by fxm25 with SMTP id 25so21782fxm.3 for ; Wed, 31 Mar 2010 02:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=TNBEYT5DefRRWYgd7l2kSvolape6mL8NCv922W/tedA=; b=S8/XE2Nt4hpappmnJQJwSeZebg+u7uzjuQT7nabKQZl2FF9vI29rnr6JEPz0Lz/kL1 DDiLhO21lv32E/WlQY8K1XVkR80QUePgLiJ3vgfTzGJ/tskRDojpFX2VR6ekj5We1pPg Lxf3lb0Zw4l/a9ODTN9Fx9C4NjeNiZ6neQtXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=AkvKCn9JqtuNdzQzt7LNhSSLvGO3XpHsO6v5EvN4p7w8qJVW7h2jwQTZx3irShzzcF E6Btwd3YLpC9g4gQ3wxRV5l7fIexXXpiqzT95iKHdwwzYGYzmqW0NuBuqQcyo9H+qqTM UpJa0A0f5PlRo4guQNKdq0WsvqQ3PzGqxXu6Q= MIME-Version: 1.0 Received: by 10.239.153.206 with HTTP; Wed, 31 Mar 2010 02:18:20 -0700 (PDT) Date: Wed, 31 Mar 2010 12:18:20 +0300 Received: by 10.239.185.129 with SMTP id c1mr683551hbh.167.1270027100839; Wed, 31 Mar 2010 02:18:20 -0700 (PDT) Message-ID: From: KOT MATPOCKuH To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: On fresh current zvol with org.freebsd:swap=on crashes zfs list (PR:145234) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Mar 2010 09:18:22 -0000 On fresh freebsd-current automatic swap configuration on zvol with org.freebsd:swap=on by /etc/rc.d/zvol doesn't work because zfs list -H -o org.freebsd:swap,name -t volume fails with bus error. To repeat a problem try: # zfs create -V 128m rpool/test # zfs list rpool/test NAME USED AVAIL REFER MOUNTPOINT rpool/test 128M 55.9G 16K - # zfs set org.freebsd:swap=on rpool/test # zfs list rpool/test Segmentation fault (core dumped) # zfs list Segmentation fault (core dumped) # zfs inherit org.freebsd:swap rpool/test # zfs list rpool/test NAME USED AVAIL REFER MOUNTPOINT rpool/test 128M 55.9G 16K - PR:bin/145234 registered for this problem. -- MATPOCKuH From owner-freebsd-current@FreeBSD.ORG Wed Mar 31 13:04:49 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E4E50106566B; Wed, 31 Mar 2010 13:04:49 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id A957C8FC12; Wed, 31 Mar 2010 13:04:49 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2VD4moj099176; Wed, 31 Mar 2010 09:04:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2VD4m80099175; Wed, 31 Mar 2010 13:04:48 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 31 Mar 2010 13:04:48 GMT Message-Id: <201003311304.o2VD4m80099175@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Wed, 31 Mar 2010 13:04:50 -0000 TB --- 2010-03-31 12:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-31 12:00:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-03-31 12:00:00 - cleaning the object tree TB --- 2010-03-31 12:00:14 - cvsupping the source tree TB --- 2010-03-31 12:00:14 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-03-31 12:00:44 - building world TB --- 2010-03-31 12:00:44 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-31 12:00:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-31 12:00:44 - TARGET=pc98 TB --- 2010-03-31 12:00:44 - TARGET_ARCH=i386 TB --- 2010-03-31 12:00:44 - TZ=UTC TB --- 2010-03-31 12:00:44 - __MAKE_CONF=/dev/null TB --- 2010-03-31 12:00:44 - cd /src TB --- 2010-03-31 12:00:44 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 31 12:00:44 UTC 2010 >>> 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 Mar 31 12:59:39 UTC 2010 TB --- 2010-03-31 12:59:39 - generating LINT kernel config TB --- 2010-03-31 12:59:39 - cd /src/sys/pc98/conf TB --- 2010-03-31 12:59:39 - /usr/bin/make -B LINT TB --- 2010-03-31 12:59:39 - building LINT kernel TB --- 2010-03-31 12:59:39 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-31 12:59:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-31 12:59:39 - TARGET=pc98 TB --- 2010-03-31 12:59:39 - TARGET_ARCH=i386 TB --- 2010-03-31 12:59:39 - TZ=UTC TB --- 2010-03-31 12:59:39 - __MAKE_CONF=/dev/null TB --- 2010-03-31 12:59:39 - cd /src TB --- 2010-03-31 12:59:39 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 31 12:59:39 UTC 2010 >>> 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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_lem.c -I/src/sys/dev/e1000 /src/sys/dev/e1000/if_lem.c: In function 'lem_ioctl': /src/sys/dev/e1000/if_lem.c:1125: error: 'lem_poll' undeclared (first use in this function) /src/sys/dev/e1000/if_lem.c:1125: error: (Each undeclared identifier is reported only once /src/sys/dev/e1000/if_lem.c:1125: 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 --- 2010-03-31 13:04:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-31 13:04:48 - ERROR: failed to build lint kernel TB --- 2010-03-31 13:04:48 - 2865.55 user 639.74 system 3888.61 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 31 13:06:09 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95EDE10656EF; Wed, 31 Mar 2010 13:06:09 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 6ABD68FC17; Wed, 31 Mar 2010 13:06:09 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2VD68Et010017; Wed, 31 Mar 2010 09:06:08 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2VD688B009997; Wed, 31 Mar 2010 13:06:08 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 31 Mar 2010 13:06:08 GMT Message-Id: <201003311306.o2VD688B009997@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Wed, 31 Mar 2010 13:06:09 -0000 TB --- 2010-03-31 12:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-31 12:00:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-03-31 12:00:00 - cleaning the object tree TB --- 2010-03-31 12:00:14 - cvsupping the source tree TB --- 2010-03-31 12:00:14 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-03-31 12:00:44 - building world TB --- 2010-03-31 12:00:44 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-31 12:00:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-31 12:00:44 - TARGET=i386 TB --- 2010-03-31 12:00:44 - TARGET_ARCH=i386 TB --- 2010-03-31 12:00:44 - TZ=UTC TB --- 2010-03-31 12:00:44 - __MAKE_CONF=/dev/null TB --- 2010-03-31 12:00:44 - cd /src TB --- 2010-03-31 12:00:44 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 31 12:00:44 UTC 2010 >>> 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 Mar 31 12:59:45 UTC 2010 TB --- 2010-03-31 12:59:45 - generating LINT kernel config TB --- 2010-03-31 12:59:45 - cd /src/sys/i386/conf TB --- 2010-03-31 12:59:45 - /usr/bin/make -B LINT TB --- 2010-03-31 12:59:45 - building LINT kernel TB --- 2010-03-31 12:59:45 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-31 12:59:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-31 12:59:45 - TARGET=i386 TB --- 2010-03-31 12:59:45 - TARGET_ARCH=i386 TB --- 2010-03-31 12:59:45 - TZ=UTC TB --- 2010-03-31 12:59:45 - __MAKE_CONF=/dev/null TB --- 2010-03-31 12:59:45 - cd /src TB --- 2010-03-31 12:59:45 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 31 12:59:45 UTC 2010 >>> 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/eisa/eisaconf.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_lem.c -I/src/sys/dev/e1000 /src/sys/dev/e1000/if_lem.c: In function 'lem_ioctl': /src/sys/dev/e1000/if_lem.c:1125: error: 'lem_poll' undeclared (first use in this function) /src/sys/dev/e1000/if_lem.c:1125: error: (Each undeclared identifier is reported only once /src/sys/dev/e1000/if_lem.c:1125: error: for each function it appears in.) *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-31 13:06:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-31 13:06:08 - ERROR: failed to build lint kernel TB --- 2010-03-31 13:06:08 - 2951.22 user 624.80 system 3968.66 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 31 13:32:13 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 566A11065674; Wed, 31 Mar 2010 13:32:13 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2FBE88FC08; Wed, 31 Mar 2010 13:32:12 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2VDWCwa042241; Wed, 31 Mar 2010 09:32:12 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2VDWC2w042238; Wed, 31 Mar 2010 13:32:12 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 31 Mar 2010 13:32:12 GMT Message-Id: <201003311332.o2VDWC2w042238@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 13:32:13 -0000 TB --- 2010-03-31 12:00:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-31 12:00:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-03-31 12:00:00 - cleaning the object tree TB --- 2010-03-31 12:00:18 - cvsupping the source tree TB --- 2010-03-31 12:00:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-03-31 12:00:44 - building world TB --- 2010-03-31 12:00:44 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-31 12:00:44 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-31 12:00:44 - TARGET=amd64 TB --- 2010-03-31 12:00:44 - TARGET_ARCH=amd64 TB --- 2010-03-31 12:00:44 - TZ=UTC TB --- 2010-03-31 12:00:44 - __MAKE_CONF=/dev/null TB --- 2010-03-31 12:00:44 - cd /src TB --- 2010-03-31 12:00:44 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 31 12:00:44 UTC 2010 >>> 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 Mar 31 13:26:19 UTC 2010 TB --- 2010-03-31 13:26:19 - generating LINT kernel config TB --- 2010-03-31 13:26:19 - cd /src/sys/amd64/conf TB --- 2010-03-31 13:26:19 - /usr/bin/make -B LINT TB --- 2010-03-31 13:26:19 - building LINT kernel TB --- 2010-03-31 13:26:19 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-31 13:26:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-31 13:26:19 - TARGET=amd64 TB --- 2010-03-31 13:26:19 - TARGET_ARCH=amd64 TB --- 2010-03-31 13:26:19 - TZ=UTC TB --- 2010-03-31 13:26:19 - __MAKE_CONF=/dev/null TB --- 2010-03-31 13:26:19 - cd /src TB --- 2010-03-31 13:26:19 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 31 13:26:19 UTC 2010 >>> 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 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_lem.c -I/src/sys/dev/e1000 /src/sys/dev/e1000/if_lem.c: In function 'lem_ioctl': /src/sys/dev/e1000/if_lem.c:1125: error: 'lem_poll' undeclared (first use in this function) /src/sys/dev/e1000/if_lem.c:1125: error: (Each undeclared identifier is reported only once /src/sys/dev/e1000/if_lem.c:1125: 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 --- 2010-03-31 13:32:12 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-31 13:32:12 - ERROR: failed to build lint kernel TB --- 2010-03-31 13:32:12 - 4112.46 user 886.23 system 5532.30 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 31 13:59:46 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 75FCF1065670 for ; Wed, 31 Mar 2010 13:59:46 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1D7738FC0A for ; Wed, 31 Mar 2010 13:59:45 +0000 (UTC) Received: by gyh3 with SMTP id 3so59478gyh.13 for ; Wed, 31 Mar 2010 06:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=3XUp2p5O/ECp0Jb3ZXNeckUJrSoWZ5aYJNl0ekpU25o=; b=jcRtb6PKU6tjLP2c9t2JZisE079O0KZTYQBcQZDzP+NUV10ftoOSz915Hjz1QqV764 ahZXNp0P2HdIyQQTKdkDCgd59V8z1DS9nGXUtKJY/WI3a1GbIZ9FN9MR6kZCf/i1/12h YRayuIf5ilf+9E+4DVOvf8kADF05fIR2+4oEw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=xUPbEWfY0Ag9S7DBdVuNSo3LBBfrqnavafpyyPHcMCeB2wog1qp6GUtvTs9rVGO5aS l2yAM78iMSNnamkNd4dwXnHf73rwNQ4P2xLqYv1DRcU/ddQ2z0SSLP5dt6barVZJLSjJ Guf8ozGAqbNSOCj3wFIqUJv2T9FzFiUIrP8EM= Received: by 10.91.143.16 with SMTP id v16mr157745agn.10.1270043984932; Wed, 31 Mar 2010 06:59:44 -0700 (PDT) Received: from beastie.micom.mng.net ([202.179.21.135]) by mx.google.com with ESMTPS id 14sm4327941gxk.3.2010.03.31.06.59.38 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 31 Mar 2010 06:59:43 -0700 (PDT) Message-ID: <4BB35539.10401@gmail.com> Date: Wed, 31 Mar 2010 21:59:21 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.23 (X11/20091011) MIME-Version: 1.0 To: PseudoCylon References: <16641.96608.qm@web51806.mail.re2.yahoo.com> <4B9FA3E0.4050702@micom.mng.net> <633929.41041.qm@web51802.mail.re2.yahoo.com> <4BA22B8D.9030700@micom.mng.net> <375331.74876.qm@web51804.mail.re2.yahoo.com> <4BA38B26.6050208@micom.mng.net> <989377.89740.qm@web51802.mail.re2.yahoo.com> <4BAE01AC.7000509@gmail.com> <623907.37074.qm@web51803.mail.re2.yahoo.com> In-Reply-To: <623907.37074.qm@web51803.mail.re2.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Mar 2010 13:59:46 -0000 PseudoCylon wrote: > ----- Original Message ---- > > >> From: Ganbold >> To: PseudoCylon >> Cc: freebsd-current@freebsd.org >> Sent: Sat, March 27, 2010 7:01:32 AM >> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless >> >> JFYI, I have just tested if_run and works fine on HEAD (i386). >> But on RouterStation Pro it still has problem with your patch. >> > > >> Ganbold >> > > Thank you for taking extra time to test the driver. > > Yes, it works on x86. It's hard to find bugs if everything is working on my computers (core2 and atom 330). > > Here is patch. > http://dev.nasreddine.com/gitweb/?p=run.git;a=tree;f=dev/usb/wlan;h=695689599706b01ed9ef0f1be8dfc5790076e1ae;hb=bdc7558bfbd4f3b1c4491cb56853de24580a5434 > Please download if_run.c and if_runvar.h (click "raw" to download) > > It will print out lots of messages. Please show me last 5 or so messages if it still panics. > > Ok, here it is: rspro# ifconfig wlan0 up run_stop: All Tx cleared run_set_rx_antenna: called run_rt3070_set_chan: called run_bulk_rx_callback: called run_newstate: INIT -> SCAN run_scan_start: called run_set_bssid: called run_set_channel: called run_rt3070_set_chan: called rspro# Trap cause = 5 (address error (store) - kernel mode) [ thread pid 0 tid 100068 ] Stopped at ieee80211_radiotap_vdetach+0x70: sh v1,0(a0) db> > Does stock run(4) still works on RouterStation? There were some update (r205042). Yours (r205084) has it. > Stock version worked when issued ifconfig wlan0 up once I tried. wlan0: flags=8802 metric 0 mtu 1500 ether 00:22:cf:03:e0:30 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 1 (2412 MHz 11b) regdomain FCC country US authmode OPEN privacy OFF txpower 30 bmiss 7 scanvalid 60 wme bintval 0 rspro# ifconfig wlan0 up run_stop: All Tx cleared run_newstate: INIT -> SCAN rspro# ifconfig -a run0: flags=8843 metric 0 mtu 2290 ether 00:22:cf:03:e0:30 media: IEEE 802.11 Wireless Ethernet autoselect mode 11g status: associated wlan0: flags=8843 metric 0 mtu 1500 ether 00:22:cf:03:e0:30 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect) status: no carrier ssid "" channel 11 (2462 MHz 11g) regdomain FCC country US authmode OPEN privacy OFF txpower 30 bmiss 7 scanvalid 60 protmode CTS wme bintval 0 Ganbold > AK > > > __________________________________________________________________ > Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now > http://ca.toolbar.yahoo.com. > > -- Oprah Winfrey has an incredible talent for getting the wierdest people to talk to. And you just HAVE to watch it. "Blind, masochistic minority, crippled, depressed, government latrine diggers, and the women who love them too much on the next Oprah Winfrey." From owner-freebsd-current@FreeBSD.ORG Wed Mar 31 14:07:18 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82CC71065672 for ; Wed, 31 Mar 2010 14:07:18 +0000 (UTC) (envelope-from pluknet@gmail.com) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id 0F4728FC27 for ; Wed, 31 Mar 2010 14:07:17 +0000 (UTC) Received: by bwz8 with SMTP id 8so104940bwz.3 for ; Wed, 31 Mar 2010 07:07:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hQ8GUqYTKLAWbP6U3rH+XWI/nZ04RIqU0hZzuL88ZEw=; b=vG3RFeKIYB1EjLM4q2mr9Bsn1zouSdbk2ak4vo46+bHxnDwznkAbk0WEdt4tXFG+aR /sJg/+sFjRugUAWiiKXqYbR6+kq+SmizjD2hnc7rEis8ez8TWLYOZOs3zglRZPtis7ew PATO3CxXcNhGPXkWKs/Xm7aQx9/YM9IiR2GqE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vKnNPmjF09VRuf9ff+Vzr2nL8yf2QhZiXH1SCdZFyrY+3ToDoRCccZ8SFYq8mNfxe7 cJU0yM9FiOBoA8QlXvz8cu9mc0zkatQBvQ9CQjhnDAULBqn4DIErE8HhADCoClwFqrx0 tHBoU0U2pvS8G+gES37p/2w5w1rQsYCD9FLqA= MIME-Version: 1.0 Received: by 10.204.47.232 with HTTP; Wed, 31 Mar 2010 07:07:14 -0700 (PDT) In-Reply-To: <201003311332.o2VDWC2w042238@freebsd-current.sentex.ca> References: <201003311332.o2VDWC2w042238@freebsd-current.sentex.ca> Date: Wed, 31 Mar 2010 18:07:14 +0400 Received: by 10.204.39.204 with SMTP id h12mr1732807bke.196.1270044434923; Wed, 31 Mar 2010 07:07:14 -0700 (PDT) Message-ID: From: pluknet To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: amd64@freebsd.org, current@freebsd.org Subject: Re: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Mar 2010 14:07:18 -0000 > cc -c -O2 -frename-registers -pipe -fno-strict-aliasing =A0-std=3Dc99 =A0= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes =A0-Wmissing-p= rototypes -Wpointer-arith -Winline -Wcast-qual =A0-Wundef -Wno-pointer-sign= -fformat-extensions -nostdinc =A0-I. -I/src/sys -I/src/sys/contrib/altq -D= _KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -fin= line-limit=3D8000 --param inline-unit-growth=3D100 --param large-function-g= rowth=3D1000 -DGPROF -falign-functions=3D16 -DGPROF4 -DGUPROF -fno-builtin = -fno-omit-frame-pointer -mcmodel=3Dkernel -mno-red-zone =A0-mfpmath=3D387 -= mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow =A0-msoft-float -fno-asynch= ronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofile= r-epilogue /src/sys/dev/e1000/if_lem.c -I/src/sys/dev/e1000 > /src/sys/dev/e1000/if_lem.c: In function 'lem_ioctl': > /src/sys/dev/e1000/if_lem.c:1125: error: 'lem_poll' undeclared (first use= in this function) > /src/sys/dev/e1000/if_lem.c:1125: error: (Each undeclared identifier is r= eported only once > /src/sys/dev/e1000/if_lem.c:1125: error: for each function it appears in.= ) > *** Error code 1 I guess it should fix error. --- src/sys/dev/e1000/if_lem.c.orig 2010-03-31 18:02:30.000000000 +0400 +++ src/sys/dev/e1000/if_lem.c 2010-03-31 18:03:29.000000000 +0400 @@ -269,7 +269,7 @@ #endif /* ~EM_LEGACY_IRQ */ #ifdef DEVICE_POLLING -static poll_handler_t em_poll; +static poll_handler_t lem_poll; #endif /* POLLING */ /********************************************************************* --=20 wbr, pluknet From owner-freebsd-current@FreeBSD.ORG Wed Mar 31 14:08:48 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1968A1065679 for ; Wed, 31 Mar 2010 14:08:48 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id BC57F8FC20 for ; Wed, 31 Mar 2010 14:08:47 +0000 (UTC) Received: by qyk11 with SMTP id 11so131347qyk.13 for ; Wed, 31 Mar 2010 07:08:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=5jqSpMNnW44mc98YcWepEMS9arW7wgptvk7zFTpLoCE=; b=vV75wOKgpYShvGirkuPmM3Gk+JXrnk95D6ybRW+wYoAql/AQ85o/6tGoGK+DEfKQp6 X2B5oOO+CSCEMKhOmQ+7yXk7GiVGY1xlWohwOGCUfnS3R/H1P48uUf/uAndAmB8JbNIN HVz98l8a9toww9QlLJSAqTam/Tchr/Aq6Dmdc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=deBkN2tpoJmJFSUhix2ACmpO59y9iAxo8/5aRBnehLdVI2SUMOwkF3DpFpDcqKdwW7 BD18PirGVPbbFVMg4KiNpW6CDy6XW7zAkLZlhfTPetyocikuxJqPVGY2rCRB92sEWfE1 Sf/OLAnkoRDxn0abIMRSNzMwNJbHk8XJrUMm4= Received: by 10.229.14.157 with SMTP id g29mr1314130qca.57.1270044526834; Wed, 31 Mar 2010 07:08:46 -0700 (PDT) Received: from beastie.micom.mng.net ([202.179.21.135]) by mx.google.com with ESMTPS id 22sm3235390qyk.2.2010.03.31.07.08.40 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 31 Mar 2010 07:08:46 -0700 (PDT) Message-ID: <4BB3575D.4040506@gmail.com> Date: Wed, 31 Mar 2010 22:08:29 +0800 From: Ganbold User-Agent: Thunderbird 2.0.0.23 (X11/20091011) MIME-Version: 1.0 To: PseudoCylon References: <16641.96608.qm@web51806.mail.re2.yahoo.com> <4B9FA3E0.4050702@micom.mng.net> <633929.41041.qm@web51802.mail.re2.yahoo.com> <4BA22B8D.9030700@micom.mng.net> <375331.74876.qm@web51804.mail.re2.yahoo.com> <4BA38B26.6050208@micom.mng.net> <989377.89740.qm@web51802.mail.re2.yahoo.com> <4BAE01AC.7000509@gmail.com> <623907.37074.qm@web51803.mail.re2.yahoo.com> In-Reply-To: <623907.37074.qm@web51803.mail.re2.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Mar 2010 14:08:48 -0000 PseudoCylon wrote: > ----- Original Message ---- > > >> From: Ganbold >> To: PseudoCylon >> Cc: freebsd-current@freebsd.org >> Sent: Sat, March 27, 2010 7:01:32 AM >> Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless >> >> JFYI, I have just tested if_run and works fine on HEAD (i386). >> But on RouterStation Pro it still has problem with your patch. >> > > >> Ganbold >> > > Thank you for taking extra time to test the driver. > > Yes, it works on x86. It's hard to find bugs if everything is working on my computers (core2 and atom 330). > > Here is patch. > http://dev.nasreddine.com/gitweb/?p=run.git;a=tree;f=dev/usb/wlan;h=695689599706b01ed9ef0f1be8dfc5790076e1ae;hb=bdc7558bfbd4f3b1c4491cb56853de24580a5434 > Please download if_run.c and if_runvar.h (click "raw" to download) > > It will print out lots of messages. Please show me last 5 or so messages if it still panics. > > Does stock run(4) still works on RouterStation? There were some update (r205042). Yours (r205084) has it. > Does stock run(4) support hostap mode yet? rspro# sysctl net.wlan.debug=1 net.wlan.debug: 0 -> 1 rspro# ifconfig wlan0 create wlandev run0 wlanmode hostap ssid bsd mode 11g wlan0: Ethernet address: 00:22:cf:03:e0:30 Trap cause = 2 (TLB miss (load or instr. fetch) - kernel mode) [ thread pid 1213 tid 100051 ] Stopped at strlcpy+0x14: lb v0,0(a1) db> bt Tracing pid 1213 tid 100051 td 0xc0f1d720 db_trace_thread+30 (?,?,?,?) ra 80071160 sp c7ed7450 sz 24 80071044+11c (0,?,ffffffff,?) ra 80070b54 sp c7ed7468 sz 32 800707c0+394 (?,?,?,?) ra 80070ce4 sp c7ed7488 sz 168 db_command_loop+78 (?,?,?,?) ra 800733b8 sp c7ed7530 sz 24 800732b0+108 (?,?,?,?) ra 801d8d4c sp c7ed7548 sz 424 kdb_trap+10c (?,?,?,?) ra 803c37f0 sp c7ed76f0 sz 32 trap+134c (?,?,?,?) ra 803baa58 sp c7ed7710 sz 176 MipsKernGenException+10c (c7ed7a66,0,8,c7ed7a54) ra 8025e6e4 sp c7ed77c0 sz 200 strlcpy+14 (?,?,?,?) ra 0 sp c7ed7888 sz 0 pid 1213 db> Ganbold > AK > > > __________________________________________________________________ > Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now > http://ca.toolbar.yahoo.com. > > -- The temperature of Heaven can be rather accurately computed from available data. Our authority is Isaiah 30:26, "Moreover, the light of the Moon shall be as the light of the Sun and the light of the Sun shall be sevenfold, as the light of seven days." Thus Heaven receives from the Moon as much radiation as we do from the Sun, and in addition seven times seven (49) times as much as the Earth does from the Sun, or fifty times in all. The light we receive from the Moon is one ten-thousandth of the light we receive from the Sun, so we can ignore that. With these data we can compute the temperature of Heaven. The radiation falling on Heaven will heat it to the point where the heat lost by radiation is just equal to the heat received by radiation, i.e., Heaven loses fifty times as much heat as the Earth by radiation. Using the Stefan-Boltzmann law for radiation, (H/E)^4 = 50, where E is the absolute temperature of the earth (~300K), gives H as 798K (525C). The exact temperature of Hell cannot be computed, but it must be less than 444.6C, the temperature at which brimstone or sulphur changes from a liquid to a gas. Revelations 21:8 says "But the fearful, and unbelieving ... shall have their part in the lake which burneth with fire and brimstone." A lake of molten brimstone means that its temperature must be at or below the boiling point, or 444.6C (Above this point it would be a vapor, not a lake.) We have, then, that Heaven, at 525C is hotter than Hell at 445C. -- "Applied Optics", vol. 11, A14, 1972 From owner-freebsd-current@FreeBSD.ORG Wed Mar 31 14:48:07 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 504FA106566B for ; Wed, 31 Mar 2010 14:48:07 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8EE498FC13 for ; Wed, 31 Mar 2010 14:48:06 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA21360; Wed, 31 Mar 2010 17:48:02 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4BB360A1.7020309@freebsd.org> Date: Wed, 31 Mar 2010 17:48:01 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: Fabian Keil References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <3a142e751003191021p141af009m6acf7d160c890cbb@mail.gmail.com> <20100319191133.46fe271c@r500.local> <3a142e751003191126j331e525fwb9e5573bbf6f7d58@mail.gmail.com> <4BAA30CB.1070707@icyb.net.ua> <20100328172537.501ed3d1@r500.local> <4BB0A053.9060007@freebsd.org> <20100329222920.5eef6395@r500.local> <4BB111D4.8060809@freebsd.org> <20100330173637.202b4b1e@r500.local> <4BB21BBA.7030407@freebsd.org> In-Reply-To: <4BB21BBA.7030407@freebsd.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-current@freebsd.org, Bruce Evans Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Mar 2010 14:48:07 -0000 on 30/03/2010 18:41 Andriy Gapon said the following: > on 30/03/2010 18:36 Fabian Keil said the following: >> Andriy Gapon wrote: >> >>> on 29/03/2010 23:29 Fabian Keil said the following: >>>> Andriy Gapon wrote: >>>>> Thus, clearly, it is a fault of a tool that formatted the media for FAT. >>>>> It should have picked correct values, or rejected incorrect values if >>>>> those were provided as overrides via command line options. >>>> The kernel still shouldn't panic, though. >>> A quick reply to this point only - yes, I completely agree. >>> But remember that the panic happened only after the sources were modified :) >> It wasn't clear from my message, but I was mainly referring to the >> division-by-zero panic mentioned at the beginning of the thread, >> for which I posted a work-around in <20100319191133.46fe271c@r500.local>. > > Oh, yes, right. To clarify - I already forgot that the original problem was division by zero panic and for some reason thought that it was EINVAL. Anyways, here is a patch that I would use. Unfortunately, ENOTIME to understand newfs_msdos code and fix it too, --- a/sys/fs/msdosfs/msdosfs_vfsops.c +++ b/sys/fs/msdosfs/msdosfs_vfsops.c @@ -580,6 +580,7 @@ mountmsdosfs(struct vnode *devvp, struct mount *mp) || (pmp->pm_BytesPerSec & (pmp->pm_BytesPerSec - 1)) || (pmp->pm_HugeSectors == 0) || (pmp->pm_FATsecs == 0) + || (SecPerClust * pmp->pm_BlkPerSec > MAXBSIZE / DEV_BSIZE) ) { error = EINVAL; goto error_exit; -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Mar 31 20:56:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0C48E106566C; Wed, 31 Mar 2010 20:56:09 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id BFEC68FC16; Wed, 31 Mar 2010 20:56:08 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1Nx4xL-0000er-ER; Wed, 31 Mar 2010 21:56:07 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1Nx4xL-0002Ex-6h; Wed, 31 Mar 2010 21:56:07 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4) with ESMTP id o2VKu6wH001616; Wed, 31 Mar 2010 21:56:06 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4/Submit) id o2VKu6li001615; Wed, 31 Mar 2010 21:56:06 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Wed, 31 Mar 2010 21:56:06 +0100 From: Anton Shterenlikht To: freebsd-ia64@freebsd.org, freebsd-current@freebsd.org Message-ID: <20100331205606.GA1581@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: Subject: ia64 -> panic: ffs_blkfree: freeing free frag X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 31 Mar 2010 20:56:09 -0000 on r205976M ia64 with gmirror, see dmesg here: http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2600/tzav/dmesg.boot I got this panic: ) at syscall+0x3b0 epc_syscall_return() at epc_syscall_return Mar 31 19:51:51 mech-cluster241 su: mexas to root on /dev/pts/9 dev = mirror/usr, block = 15150194, fs = /usr panic: ffs_blkfree: freeing free frag cpuid = 1 KDB: enter: panic [ thread pid 19 tid 100054 ] Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe1e628,gp ;; db> bt Tracing pid 19 tid 100054 td 0xe000000011105880 kdb_enter(0xe000000004783670, 0xe000000004783670, 0xe00000000439bb40, 0x793) at kdb_enter+0x92 panic(0xe0000000047abda8, 0xe0000000115c96e0, 0xe72c72, 0xe0000000115888d4, 0xe0000000046382a0, 0xa1a) at panic+0x2f0 ffs_blkfree(0xe0000000115c9200, 0xe000000011588800, 0xe00000001168e000, 0xe72c72, 0x800, 0xa00000009a952c28) at ffs_blkfree+0xbc0 handle_workitem_freeblocks(0xe00000001c9d6e00, 0x0, 0x800, 0xe00000001c9d6e48, 0x0) at handle_workitem_freeblocks+0x4e0 process_worklist_item(0xe00000001c9d6e1a, 0xe0000000115c92c4, 0xe00000001c9d6e00, 0x0) at process_worklist_item+0x440 softdep_process_worklist(0xe0000000116982f8, 0xe0000000048cbeb8, 0xe0000000048cf030, 0x1, 0x0) at softdep_process_worklist+0xe0 softdep_flush(0xe0000000116982f8, 0xe000000011698000, 0x0, 0xe0000000047acf70) at softdep_flush+0x430 fork_exit(0xe0000000047c41c0, 0x0, 0xa0000000bd435550) at fork_exit+0x110 enter_userland() at enter_userland db> After fixing all filsytem inconsitensies with fsck I got this panic: # shutdown -r now Shutdown NOW! shutdown: [pid 89] # /usr/bin/wall: not found Mar 31 22:47:28 shutdown: reboot by root: System shutdown time has arrived Writing entropy file:/etc/rc.shutdown: WARNING: write failed (read-only fs?) Terminated . GEOM_MIRROR: Device usr: rebuilding provider da0p6 stopped. GEOM_MIRROR: Device tmp: provider mirror/tmp destroyed. GEOM_MIRROR: Device usr: provider mirror/usr destroyed. fatal kernel trap (cpu 1): trap vector = 0x14 (Page Not Present) cr.iip = 0xe000000004380960 cr.ipsr = 0x1210080a6018 (ac,mfl,ic,i,dt,dfh,rt,cpl=0,it,ri=1,bn) cr.isr = 0xa0400000000 (code=0,vector=0,r,ei=1,ed) cr.ifa = 0x98 curthread = 0xe000000010caa380 pid = 3, comm = g_up [ thread pid 3 tid 100009 ] Stopped at _mtx_lock_flags+0x51: [M1] ld8.acq r14=[r14] db> db> bt Tracing pid 3 tid 100009 td 0xe000000010caa380 _mtx_lock_flags(0x80, 0x0, 0xe000000004bb9668, 0x3e3) at _mtx_lock_flags+0x51 g_mirror_sync_done(0xe00000001158d878, 0x0, 0x80, 0xe000000004493190) at g_mirror_sync_done+0xa0 biodone(0xe00000001158d878, 0xe00000001087a810, 0xe0000000048453f0, 0xe0000000047927a8, 0xe0000000042eb530) at biodone+0x130 g_io_schedule_up(0x100, 0xe00000001158d878, 0xe0000000048dd6c8, 0xe0000000048dd700) at g_io_schedule_up+0x280 g_up_procbody(0xe0000000047788f0, 0xe000000010caa380, 0xe00000000434bdd0, 0x40c) at g_up_procbody+0xc0 fork_exit(0xe0000000047c2bf0, 0x0, 0xa0000000bcbf9550) at fork_exit+0x110 enter_userland() at enter_userland db> -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Wed Mar 31 22:59:56 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B74571065670; Wed, 31 Mar 2010 22:59:56 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 7F0658FC0A; Wed, 31 Mar 2010 22:59:55 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2VMxsd4099505; Wed, 31 Mar 2010 18:59:54 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2VMxsLu099501; Wed, 31 Mar 2010 22:59:54 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 31 Mar 2010 22:59:54 GMT Message-Id: <201003312259.o2VMxsLu099501@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Wed, 31 Mar 2010 22:59:56 -0000 TB --- 2010-03-31 21:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-31 21:55:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-03-31 21:55:00 - cleaning the object tree TB --- 2010-03-31 21:55:21 - cvsupping the source tree TB --- 2010-03-31 21:55:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-03-31 21:55:52 - building world TB --- 2010-03-31 21:55:52 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-31 21:55:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-31 21:55:52 - TARGET=pc98 TB --- 2010-03-31 21:55:52 - TARGET_ARCH=i386 TB --- 2010-03-31 21:55:52 - TZ=UTC TB --- 2010-03-31 21:55:52 - __MAKE_CONF=/dev/null TB --- 2010-03-31 21:55:52 - cd /src TB --- 2010-03-31 21:55:52 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 31 21:55:52 UTC 2010 >>> 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 Mar 31 22:54:47 UTC 2010 TB --- 2010-03-31 22:54:47 - generating LINT kernel config TB --- 2010-03-31 22:54:47 - cd /src/sys/pc98/conf TB --- 2010-03-31 22:54:47 - /usr/bin/make -B LINT TB --- 2010-03-31 22:54:47 - building LINT kernel TB --- 2010-03-31 22:54:47 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-31 22:54:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-31 22:54:47 - TARGET=pc98 TB --- 2010-03-31 22:54:47 - TARGET_ARCH=i386 TB --- 2010-03-31 22:54:47 - TZ=UTC TB --- 2010-03-31 22:54:47 - __MAKE_CONF=/dev/null TB --- 2010-03-31 22:54:47 - cd /src TB --- 2010-03-31 22:54:47 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 31 22:54:47 UTC 2010 >>> 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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_lem.c -I/src/sys/dev/e1000 cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_igb.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors /src/sys/dev/e1000/if_igb.c: In function 'igb_poll': /src/sys/dev/e1000/if_igb.c:1356: warning: passing argument 1 of 'igb_rxeof' from incompatible pointer type *** Error code 1 Stop in /obj/pc98/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-31 22:59:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-31 22:59:54 - ERROR: failed to build lint kernel TB --- 2010-03-31 22:59:54 - 2870.28 user 635.70 system 3894.54 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 31 23:01:19 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AE9F4106567D; Wed, 31 Mar 2010 23:01:19 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id 87A478FC1C; Wed, 31 Mar 2010 23:01:19 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2VN1Jmr010047; Wed, 31 Mar 2010 19:01:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2VN1J6d010031; Wed, 31 Mar 2010 23:01:19 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 31 Mar 2010 23:01:19 GMT Message-Id: <201003312301.o2VN1J6d010031@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk 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: Wed, 31 Mar 2010 23:01:19 -0000 TB --- 2010-03-31 21:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-31 21:55:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-03-31 21:55:00 - cleaning the object tree TB --- 2010-03-31 21:55:21 - cvsupping the source tree TB --- 2010-03-31 21:55:21 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-03-31 21:55:52 - building world TB --- 2010-03-31 21:55:52 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-31 21:55:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-31 21:55:52 - TARGET=i386 TB --- 2010-03-31 21:55:52 - TARGET_ARCH=i386 TB --- 2010-03-31 21:55:52 - TZ=UTC TB --- 2010-03-31 21:55:52 - __MAKE_CONF=/dev/null TB --- 2010-03-31 21:55:52 - cd /src TB --- 2010-03-31 21:55:52 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 31 21:55:52 UTC 2010 >>> 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 Mar 31 22:54:58 UTC 2010 TB --- 2010-03-31 22:54:58 - generating LINT kernel config TB --- 2010-03-31 22:54:58 - cd /src/sys/i386/conf TB --- 2010-03-31 22:54:58 - /usr/bin/make -B LINT TB --- 2010-03-31 22:54:58 - building LINT kernel TB --- 2010-03-31 22:54:58 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-31 22:54:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-31 22:54:58 - TARGET=i386 TB --- 2010-03-31 22:54:58 - TARGET_ARCH=i386 TB --- 2010-03-31 22:54:58 - TZ=UTC TB --- 2010-03-31 22:54:58 - __MAKE_CONF=/dev/null TB --- 2010-03-31 22:54:58 - cd /src TB --- 2010-03-31 22:54:58 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 31 22:54:58 UTC 2010 >>> 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 [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/eisa/eisaconf.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 -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_lem.c -I/src/sys/dev/e1000 cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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 -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_igb.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors /src/sys/dev/e1000/if_igb.c: In function 'igb_poll': /src/sys/dev/e1000/if_igb.c:1356: warning: passing argument 1 of 'igb_rxeof' from incompatible pointer type *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-31 23:01:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-31 23:01:19 - ERROR: failed to build lint kernel TB --- 2010-03-31 23:01:19 - 2955.06 user 622.74 system 3978.86 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full From owner-freebsd-current@FreeBSD.ORG Wed Mar 31 23:27:17 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6583106564A; Wed, 31 Mar 2010 23:27:17 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by mx1.freebsd.org (Postfix) with ESMTP id BF1C98FC16; Wed, 31 Mar 2010 23:27:17 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.4/8.14.3) with ESMTP id o2VNRHJ7040369; Wed, 31 Mar 2010 19:27:17 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.4/8.14.3/Submit) id o2VNRHHR040366; Wed, 31 Mar 2010 23:27:17 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 31 Mar 2010 23:27:17 GMT Message-Id: <201003312327.o2VNRHHR040366@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 23:27:18 -0000 TB --- 2010-03-31 21:55:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-03-31 21:55:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2010-03-31 21:55:00 - cleaning the object tree TB --- 2010-03-31 21:55:26 - cvsupping the source tree TB --- 2010-03-31 21:55:26 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2010-03-31 21:55:52 - building world TB --- 2010-03-31 21:55:52 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-31 21:55:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-31 21:55:52 - TARGET=amd64 TB --- 2010-03-31 21:55:52 - TARGET_ARCH=amd64 TB --- 2010-03-31 21:55:52 - TZ=UTC TB --- 2010-03-31 21:55:52 - __MAKE_CONF=/dev/null TB --- 2010-03-31 21:55:52 - cd /src TB --- 2010-03-31 21:55:52 - /usr/bin/make -B buildworld >>> World build started on Wed Mar 31 21:55:52 UTC 2010 >>> 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 Mar 31 23:21:18 UTC 2010 TB --- 2010-03-31 23:21:18 - generating LINT kernel config TB --- 2010-03-31 23:21:18 - cd /src/sys/amd64/conf TB --- 2010-03-31 23:21:18 - /usr/bin/make -B LINT TB --- 2010-03-31 23:21:18 - building LINT kernel TB --- 2010-03-31 23:21:18 - MAKEOBJDIRPREFIX=/obj TB --- 2010-03-31 23:21:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-03-31 23:21:18 - TARGET=amd64 TB --- 2010-03-31 23:21:18 - TARGET_ARCH=amd64 TB --- 2010-03-31 23:21:18 - TZ=UTC TB --- 2010-03-31 23:21:18 - __MAKE_CONF=/dev/null TB --- 2010-03-31 23:21:18 - cd /src TB --- 2010-03-31 23:21:18 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Mar 31 23:21:18 UTC 2010 >>> 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 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/ed/if_ed_pci.c awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/eisa/eisa_if.m -c ; cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue eisa_if.c cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_em.c -I/src/sys/dev/e1000 cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_lem.c -I/src/sys/dev/e1000 cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -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-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_igb.c -I/src/sys/dev/e1000 cc1: warnings being treated as errors /src/sys/dev/e1000/if_igb.c: In function 'igb_poll': /src/sys/dev/e1000/if_igb.c:1356: warning: passing argument 1 of 'igb_rxeof' from incompatible pointer type *** Error code 1 Stop in /obj/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-03-31 23:27:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-03-31 23:27:17 - ERROR: failed to build lint kernel TB --- 2010-03-31 23:27:17 - 4114.09 user 887.56 system 5536.86 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 01:56:54 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CB501106566C for ; Thu, 1 Apr 2010 01:56:54 +0000 (UTC) (envelope-from tom@uffner.com) Received: from eris.uffner.com (uffner.com [66.208.243.25]) by mx1.freebsd.org (Postfix) with ESMTP id 6F0B88FC08 for ; Thu, 1 Apr 2010 01:56:53 +0000 (UTC) Received: from xiombarg.uffner.com (static-71-162-143-94.phlapa.fios.verizon.net [71.162.143.94]) (authenticated bits=0) by eris.uffner.com (8.14.3/8.14.3) with ESMTP id o311x8Gb060409 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=FAIL) for ; Wed, 31 Mar 2010 21:59:15 -0400 (EDT) (envelope-from tom@uffner.com) Message-ID: <4BB3FD5D.9070600@uffner.com> Date: Wed, 31 Mar 2010 21:56:45 -0400 From: Tom Uffner User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.8) Gecko/20100330 SeaMonkey/2.0.3 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <4BA7E0B8.3080406@delphij.net> <4BAE2B4F.6060005@protected-networks.net> In-Reply-To: <4BAE2B4F.6060005@protected-networks.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Apr 2010 01:56:54 -0000 Michael Butler wrote: > This breaks most (if not all) of the QT4-dependent ports for the lack of > a definition of "off64_t". it also breaks multimedia/mplayer, graphics/ImageMagick, and print/ghostscript8 & everything that depends on it. From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 03:51:59 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23521106564A for ; Thu, 1 Apr 2010 03:51:59 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id EAD378FC13 for ; Thu, 1 Apr 2010 03:51:58 +0000 (UTC) Received: by pwi9 with SMTP id 9so782350pwi.13 for ; Wed, 31 Mar 2010 20:51:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=/cGQ6C8uoBbyKN+MW/MiTIZ0lwbJHKoM5IYHHrZXE9U=; b=INCUNoCogsLilQN7TgemJAyruoCqogsPebbYK2k9zhS0hrPhNRTGsn0kt9euvIELDw cHGrZGg0xU37QT4WZDVmQf/b/T9LxgjSfNdhj172QloTjvP9MZ7zCF7EJM0cY8lgC99P IbqWLJYjgnOMwSmyR9bvYtleO3QHp3Zi5ZdZ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wTefHbFpUaOD9a2YyAgoYdkhTmsgkadWwU8dHbmrh8TXW23Iwy4HStTpiUQ8keXl5K aRvYQohsiel9gqFg1xPe51xYuLC1OfKoxjQ68QibJlR3Yc0HzK5nNiHjPsfj/xv5ZJCC ss5wA5b3lHwbPKFMRT95g0Y0b9aQ2h9dlZaT8= MIME-Version: 1.0 Received: by 10.140.127.14 with HTTP; Wed, 31 Mar 2010 20:51:58 -0700 (PDT) In-Reply-To: <4BB3FD5D.9070600@uffner.com> References: <4BA7E0B8.3080406@delphij.net> <4BAE2B4F.6060005@protected-networks.net> <4BB3FD5D.9070600@uffner.com> Date: Wed, 31 Mar 2010 20:51:58 -0700 Received: by 10.141.214.7 with SMTP id r7mr6665320rvq.27.1270093918304; Wed, 31 Mar 2010 20:51:58 -0700 (PDT) Message-ID: From: Xin LI To: Tom Uffner Content-Type: text/plain; charset=UTF-8 Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Apr 2010 03:51:59 -0000 On Wed, Mar 31, 2010 at 6:56 PM, Tom Uffner wrote: > Michael Butler wrote: > >> This breaks most (if not all) of the QT4-dependent ports for the lack of >> a definition of "off64_t". > > it also breaks multimedia/mplayer, graphics/ImageMagick, and > print/ghostscript8 & everything that depends on it. Just because they used to compile DOES NOT mean they were right. It's NOT right to define _LARGEFILE64_SOURCE on FreeBSD, see: http://www.delorie.com/gnu/docs/glibc/libc_13.html Cheers, -- Xin LI http://www.delphij.net From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 06:29:43 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D97CC1065672 for ; Thu, 1 Apr 2010 06:29:43 +0000 (UTC) (envelope-from ehrmann@gmail.com) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by mx1.freebsd.org (Postfix) with ESMTP id B531F8FC14 for ; Thu, 1 Apr 2010 06:29:43 +0000 (UTC) Received: from [10.0.0.24] (unknown [64.9.238.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E811E22E1F1 for ; Thu, 1 Apr 2010 02:29:41 -0400 (EDT) Message-ID: <4BB43D4B.7060507@gmail.com> Date: Wed, 31 Mar 2010 23:29:31 -0700 From: David Ehrmann User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Intel H55 and em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Apr 2010 06:29:43 -0000 I recently picked up a H55-based motherboard, and the ethernet interface isn't autodetected. dmesg lists it as the following: pci0: at device 25.0 (no driver attached) And pciconf lists this: none1@pci0:0:25:0: class=0x020000 card=0x00008086 chip=0x10ef8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' class = network subclass = ethernet I'm actually not sure it's an em device, but it's definitely gigabit, and googling suggests that others have recently run into the same issue. Since I'll probably have to recompile, is this currently working in recent builds of 8.0? This was just a vanilla 8.0 release image. Would some simple change tell the driver to recognize this card? Thanks in advance. From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 06:39:13 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45A20106566B for ; Thu, 1 Apr 2010 06:39:13 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id CD6048FC15 for ; Thu, 1 Apr 2010 06:39:12 +0000 (UTC) Received: by wwb24 with SMTP id 24so573917wwb.13 for ; Wed, 31 Mar 2010 23:39:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=rpYTrbtdjIMMtOobtWeukRREZMgbkEEvXcqQmXXykOY=; b=ldIvNbnGwenUq/ia3qPNruL7v6MAt602iOLzjGuybIIv9kNrXYicZ3OP/3HRFhaKLE 3kKHZsY3hgp2v599ZkNbhfcGqd0ziMK1V6wlXg3ydVV0BnidNsbpdhxfoGVZkIDK6Igm XAJy1Jcw1UuZa01mArCuGgbGALQpHtwhd1Phc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kvWOxp9IbRQZpVOEqFYrJH/MuQRXdY18NoWByLNlFh8eayxn2q3DrumJ8kml5Hs0nq OaglqvNioo7aOnQOmZpdWQ96u78zTbfGI6i6AT44SmTZkV1DRzpTIoTtTHvulPGCYC9E HqjjYb1mHR8qO41TynswZ27+eMCb6g6gniISA= MIME-Version: 1.0 Received: by 10.216.7.146 with HTTP; Wed, 31 Mar 2010 23:39:11 -0700 (PDT) In-Reply-To: <4BB43D4B.7060507@gmail.com> References: <4BB43D4B.7060507@gmail.com> Date: Wed, 31 Mar 2010 23:39:11 -0700 Received: by 10.216.85.136 with SMTP id u8mr186804wee.122.1270103951746; Wed, 31 Mar 2010 23:39:11 -0700 (PDT) Message-ID: From: Jack Vogel To: David Ehrmann Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Intel H55 and em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Apr 2010 06:39:13 -0000 The device subfamily on those motherboards is called PCH, and its only in the em driver as of last December, The CVS delta of if_em is 1.27. You can either update to STABLE/8 or CURRENT. If you wish to just pull the e1000 driver directory it should work fine in 8.0 RELEASE also. Cheers, Jack On Wed, Mar 31, 2010 at 11:29 PM, David Ehrmann wrote: > I recently picked up a H55-based motherboard, and the ethernet interface > isn't autodetected. dmesg lists it as the following: > > pci0: at device 25.0 (no driver attached) > > And pciconf lists this: > > none1@pci0:0:25:0: class=0x020000 card=0x00008086 chip=0x10ef8086 > rev=0x06 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > > > I'm actually not sure it's an em device, but it's definitely gigabit, and > googling suggests that others have recently run into the same issue. > > Since I'll probably have to recompile, is this currently working in recent > builds of 8.0? This was just a vanilla 8.0 release image. Would some > simple change tell the driver to recognize this card? > > Thanks in advance. > _______________________________________________ > 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 Apr 1 06:44:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 393031065673 for ; Thu, 1 Apr 2010 06:44:03 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id C0CFC8FC0C for ; Thu, 1 Apr 2010 06:44:02 +0000 (UTC) Received: by wyb33 with SMTP id 33so382259wyb.13 for ; Wed, 31 Mar 2010 23:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=WjQ2cBcoA3r6FJzxxAFhgcH9cwFAHxV55HvkOB4BiKE=; b=qbNH5y2dZTrhtnnB378UFXmrJTDNAvhkzS6zSBs8scxnyJ28oAvzRDTiREJV3GC+kJ mAvTHFYNdL9Nq1++GMd1BMxN3qyNYC6fxLpzUIaT7V2YfzAjvc6+pmb9wrT1y6CMq0Kx t0wjZR8zcDGnlnPQF3+YNtsrva8dXkgtb45UY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KqgNmp8EaUctjxetXGrY+UBPjID0n11DB3o0CoChTxExCC1I0zOF9eRJDa/DmdWhMr ghFVGFjgAITY7R9vF7B4GJByWPO36XmWmnc3XXyPzYzlt0PAP47pqKNB38bI9eV44Ry5 a3iQlIfRWccYx4QvOQCtF2MDC9ztQnLBU3vBc= MIME-Version: 1.0 Received: by 10.216.7.146 with HTTP; Wed, 31 Mar 2010 23:43:39 -0700 (PDT) In-Reply-To: References: <4BB43D4B.7060507@gmail.com> Date: Wed, 31 Mar 2010 23:43:39 -0700 Received: by 10.216.87.79 with SMTP id x57mr205412wee.83.1270104219817; Wed, 31 Mar 2010 23:43:39 -0700 (PDT) Message-ID: From: Jack Vogel To: David Ehrmann Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org Subject: Re: Intel H55 and em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Apr 2010 06:44:03 -0000 OH, as to my last statement, the code in CURRENT will NOT work on 8.0 RELEASE, it would require a change to sys/conf/files, and it also has a fix in the stack that is not in RELEASE. SO taking the latest would require you take the whole tree. Jack On Wed, Mar 31, 2010 at 11:39 PM, Jack Vogel wrote: > The device subfamily on those motherboards is called PCH, and its only in > the em driver as of > last December, The CVS delta of if_em is 1.27. You can either update to > STABLE/8 or CURRENT. > If you wish to just pull the e1000 driver directory it should work fine in > 8.0 RELEASE also. > > Cheers, > > Jack > > > > On Wed, Mar 31, 2010 at 11:29 PM, David Ehrmann wrote: > >> I recently picked up a H55-based motherboard, and the ethernet interface >> isn't autodetected. dmesg lists it as the following: >> >> pci0: at device 25.0 (no driver attached) >> >> And pciconf lists this: >> >> none1@pci0:0:25:0: class=0x020000 card=0x00008086 chip=0x10ef8086 >> rev=0x06 hdr=0x00 >> vendor = 'Intel Corporation' >> class = network >> subclass = ethernet >> >> >> I'm actually not sure it's an em device, but it's definitely gigabit, and >> googling suggests that others have recently run into the same issue. >> >> Since I'll probably have to recompile, is this currently working in recent >> builds of 8.0? This was just a vanilla 8.0 release image. Would some >> simple change tell the driver to recognize this card? >> >> Thanks in advance. >> _______________________________________________ >> 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 Apr 1 10:47:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A300106566B for ; Thu, 1 Apr 2010 10:47:28 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from web51804.mail.re2.yahoo.com (web51804.mail.re2.yahoo.com [206.190.38.235]) by mx1.freebsd.org (Postfix) with SMTP id BE0B28FC08 for ; Thu, 1 Apr 2010 10:47:27 +0000 (UTC) Received: (qmail 80011 invoked by uid 60001); 1 Apr 2010 10:47:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1270118846; bh=oro+lZQvNACf+4WaxdnLd4NnGcGirbYBm7a7jHh9bI4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=1IDq76WUZd1GFD4LqtJ0BEP+ilk6X2S3MOP2A76igdScXSk7RVmYxGRmwjudQei4i91d7iaA/Fz/cCZ8we70VTXQq+f/qth/ktl6YUE5XEuxKiyQdOBsfO5k8HjhdfvZkFgIveXl1uNR+dELmU20RwgSma5g7Q44VogvdwOhvgU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.ca; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=BpZgicfF9kGhzfC8Ga8vtQ5Limva/J+yau1rb57U4oiDxVv9JgIeKnYEqtcDnJpEW9SaqbDzn84ygDurIa6JdLHkhvc+5TEUMEBuAU1Ktthn4wIsXF2H0hgomFBDgN64tS28i1/8rF4qkohugwwOuUB7ZTrJJni4hG1GYMpyT9g=; Message-ID: <87836.79143.qm@web51804.mail.re2.yahoo.com> X-YMail-OSG: UpDJ4LcVM1kqdZTfVYjPOnkQlvMJ6QOTuLmEq2mGcKMkZ_v3B9y98cDusEsWb6_3JVO52NHBM8Xcv8zlqra0O6uaGvFUqMT7iT5Wz_vvlgGRyV6iStx5NV4H69UzzuLNN3MinkE98D_dx1Xg5FezXS6OPzOfpBG_Fn4Aa2ALpI_OW883oPMKUZoPzQJ0YTdMvo9igWF6jBegmuj0HzMQj_NXomz_sKsROJOohR9SgIfzHp8PbQif1wham4KhJR9OBEjfiiQfcH5XPW48LlWVgCsLg5wb8sSIHJAPr4qBHx59EcsfBl3LwQeIkbtbIQGpBMMIFa8FBcc0Mn93wC238BG907RY1ZvqKdZgXtSk13rOKhNRFroOIJmR6w-- Received: from [173.183.132.20] by web51804.mail.re2.yahoo.com via HTTP; Thu, 01 Apr 2010 03:47:26 PDT X-Mailer: YahooMailRC/324.3 YahooMailWebService/0.8.100.260964 References: <16641.96608.qm@web51806.mail.re2.yahoo.com> <4B9FA3E0.4050702@micom.mng.net> <633929.41041.qm@web51802.mail.re2.yahoo.com> <4BA22B8D.9030700@micom.mng.net> <375331.74876.qm@web51804.mail.re2.yahoo.com> <4BA38B26.6050208@micom.mng.net> <989377.89740.qm@web51802.mail.re2.yahoo.com> <4BAE01AC.7000509@gmail.com> <623907.37074.qm@web51803.mail.re2.yahoo.com> <4BB3575D.4040506@gmail.com> Date: Thu, 1 Apr 2010 03:47:26 -0700 (PDT) From: PseudoCylon To: Ganbold In-Reply-To: <4BB3575D.4040506@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Apr 2010 10:47:28 -0000 ----- Original Message ---- > From: Ganbold > To: PseudoCylon > Cc: freebsd-current@freebsd.org > Sent: Wed, March 31, 2010 8:08:29 AM > Subject: Re: CALL for TEST [HOSTAP] run(4) ralink usb wireless > > Does stock run(4) support hostap mode yet? No. There were some bugs and I thought I fixed them. So, I called for test. It seems the driver is working on x86, but not on mips. hostap mode should work on your other computer with i386. I'm still working on patch. It panics where there wasn't any changes made. Strange... AK __________________________________________________________________ Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now http://ca.toolbar.yahoo.com. From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 13:41:03 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0245D106564A; Thu, 1 Apr 2010 13:41:03 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 443C38FC0A; Thu, 1 Apr 2010 13:41:02 +0000 (UTC) Received: from mb01.admin.lan.kkip.pl ([10.66.3.254]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxKMZ-000Cps-Mx; Thu, 01 Apr 2010 15:23:19 +0200 Message-ID: <4BB49E3F.7070506@it4pro.pl> Date: Thu, 01 Apr 2010 15:23:11 +0200 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.9.1.8) Gecko/20100227 Lightning/1.0b1 Thunderbird/3.0.3 MIME-Version: 1.0 To: freebsd-current@freebsd.org, freebsd-fs@freebsd.org X-Stationery: 0.5.1 X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -7.0 X-Spam-Score-Int: -69 X-Exim-Version: 4.71 (build at 02-Feb-2010 20:10:28) X-Date: 2010-04-01 15:23:19 X-Connected-IP: 10.66.3.254:2203 X-Message-Linecount: 172 X-Body-Linecount: 159 X-Message-Size: 7504 X-Body-Size: 6932 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 X-Mailman-Approved-At: Thu, 01 Apr 2010 13:49:56 +0000 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: gpart failing with no such geom after gpt corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 13:41:03 -0000 Hello ZFS and GPT hackers :) I'm sending this message to both freebsd-current and freebsd-fs because it doesn't seems to be a CURRENT-specific issue. Yesterday I tried to migrate my mixed UFS/RAIDZ config to clean RAIDZ with GPT boot. I've following mostly this guide: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1 I'm using CURRENT on 3x40GB HDDs (ad0-ad3) and additional 250GB HDD has been used for data migration (ad4). Data was copied form RAIDZ to 250GB HDD, GPT sheme was created on 40GB HDDs, then new zpool on them, and finally data went back to RAIDZ. Booting from RAIDZ was succesful, so far so good. After a while I've noticed some SMART errors on ad1, so I've booted machine with seatools for dos and made long test. One bad sector was found and reallocated, nothing to worry about. As I was in seatools already, I've decided to adjust LBA size on that disk (seatools can do that), because it was about 30MB larger than the other two, and because of that I had to adjust size of freebsd-zfs partition on that disk to match exact size of others (otherwise 'zpool create' will complain). So LBA was adjusted and system rebooted. Yes, I was aware that changing disk size probably end with corrupted GPT and data loss, but it doesn't seem to be a big deal for me as far as 2/3 of zpool is alive, because I can always recreate gpt and resilver ad1. Unfortunately it wasn't so easy. First of all system booted, and as I expected kernel message shows GPT error on ad1. Zpool was degraded but alive and kicking. However, when I tried to execute any gpart command on ad1, it return: ad1: no such geom ad1 was present under /dev, and it could be accessed by sysinstall/fdisk, but no with gpart. I've created bsd slice with sysinstall on ad1 and rebooted, with hope that after reboot I could acces ad1 with gpart and recreate GPT scheme. Another surprise - system didn't boot at all, rebooting after couple of seconds in loader (changing boot device didn't make a difference). Only way I could boot system at this moment was connecting 250GB HDD which fortunately still had data from zpool migration and boot from it. Another surprise - kernel was still complaining about GPT corruption on ad1. I had no other ideas so I ran dd if=/dev/zero of=/dev/ad1 bs=512 count=512 to clear beginning of the hdd. After that disk was still unaccesible fromt gpart, so I tried sysinstall/fdisk againt to create standard BSD partitioning scheme and rebooted system. After that finally gpart started to talk with ad1 and GPT scheme and zpool has been recreated and work as it supposed to. Still, how can we clear broken GPT data after it got corrupted? Why gpart has been showing "ad1: no such geom", and how can we deal with this problem? Finally, why gptzfsboot failed with GPT corrupted on other disk after trying to fix it, while it booted at first place? Or maybe changing LBA size of already partitioned HDD is extreme case, and the only way these problems could be triggered ;)? Cheers! -- Bartosz Stec From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 15:02:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23DDA106566B for ; Thu, 1 Apr 2010 15:02:35 +0000 (UTC) (envelope-from ehrmann@gmail.com) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by mx1.freebsd.org (Postfix) with ESMTP id A63B58FC1A for ; Thu, 1 Apr 2010 15:02:34 +0000 (UTC) Received: from [10.0.0.24] (unknown [64.9.238.177]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id F12AD22E1F3; Thu, 1 Apr 2010 11:02:32 -0400 (EDT) Message-ID: <4BB4B583.60803@gmail.com> Date: Thu, 01 Apr 2010 08:02:27 -0700 From: David Ehrmann User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Jack Vogel References: <4BB43D4B.7060507@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Intel H55 and em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Apr 2010 15:02:35 -0000 Thanks. I'll give STABLE/8 a try. Jack Vogel wrote: > OH, as to my last statement, the code in CURRENT will NOT work on 8.0 > RELEASE, > it would require a change to sys/conf/files, and it also has a fix in > the stack that is not > in RELEASE. SO taking the latest would require you take the whole tree. > > Jack > > > On Wed, Mar 31, 2010 at 11:39 PM, Jack Vogel > wrote: > > The device subfamily on those motherboards is called PCH, and its > only in the em driver as of > last December, The CVS delta of if_em is 1.27. You can either > update to STABLE/8 or CURRENT. > If you wish to just pull the e1000 driver directory it should work > fine in 8.0 RELEASE also. > > Cheers, > > Jack > > > > On Wed, Mar 31, 2010 at 11:29 PM, David Ehrmann > wrote: > > I recently picked up a H55-based motherboard, and the ethernet > interface isn't autodetected. dmesg lists it as the following: > > pci0: at device 25.0 (no driver attached) > > And pciconf lists this: > > none1@pci0:0:25:0: class=0x020000 card=0x00008086 > chip=0x10ef8086 rev=0x06 hdr=0x00 > vendor = 'Intel Corporation' > class = network > subclass = ethernet > > > I'm actually not sure it's an em device, but it's definitely > gigabit, and googling suggests that others have recently run > into the same issue. > > Since I'll probably have to recompile, is this currently > working in recent builds of 8.0? This was just a vanilla 8.0 > release image. Would some simple change tell the driver to > recognize this card? > > Thanks in advance. > _______________________________________________ > 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 Apr 1 15:57:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46BE0106566B for ; Thu, 1 Apr 2010 15:57:24 +0000 (UTC) (envelope-from Thomas.Gellekum@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id 8BABD8FC17 for ; Thu, 1 Apr 2010 15:57:23 +0000 (UTC) Received: (qmail 20385 invoked by uid 0); 1 Apr 2010 15:30:42 -0000 Received: from 87.79.166.70 by www160.gmx.net with HTTP; Thu, 01 Apr 2010 17:30:39 +0200 (CEST) Content-Type: text/plain; charset="us-ascii" Date: Thu, 01 Apr 2010 17:30:39 +0200 From: "Thomas Gellekum" In-Reply-To: Message-ID: <20100401153039.207980@gmx.net> MIME-Version: 1.0 References: <4BB43D4B.7060507@gmail.com> To: Jack Vogel , ehrmann@gmail.com X-Authenticated: #18235045 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX18WF/9Dyu0WQ7euadKawfwEWML2USKbUbTj5MJCFS llNC4k9wTAdIK+Is6PbXuJej8MYFwDK7a87w== Content-Transfer-Encoding: 7bit X-GMX-UID: TMjRO1YwZCEEQ8tEc20hJVx4IGhpZUYJ X-FuHaFi: 0.57999999999999996 Cc: freebsd-current@freebsd.org Subject: Re: Intel H55 and em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Apr 2010 15:57:24 -0000 Jack Vogel wrote: > The device subfamily on those motherboards is called PCH, and its only in > the em driver as of > last December, The CVS delta of if_em is 1.27. You can either update to > STABLE/8 or CURRENT. > If you wish to just pull the e1000 driver directory it should work fine in > 8.0 RELEASE also. 8-STABLE doesn't work for me. The ethernet device is not recognized, and I get warnings about interrupt storms on irq19 (atapci1), which I don't see with 8-RELEASE. That might be a matter of missing diagnostics in the release kernel (the numbers from 'vmstat -i' seem to suggest this). The board is an Intel DH55HC with an i3-530. Sources for -STABLE checked out this morning; I simply built a GENERIC kernel. tg -- Sicherer, schneller und einfacher. Die aktuellen Internet-Browser - jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/chbrowser From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 16:36:47 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66428106566B; Thu, 1 Apr 2010 16:36:46 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id C82C28FC19; Thu, 1 Apr 2010 16:36:45 +0000 (UTC) Received: by bwz8 with SMTP id 8so1033345bwz.3 for ; Thu, 01 Apr 2010 09:36:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.6.76 with HTTP; Thu, 1 Apr 2010 09:36:43 -0700 (PDT) In-Reply-To: <4BB49E3F.7070506@it4pro.pl> References: <4BB49E3F.7070506@it4pro.pl> Date: Thu, 1 Apr 2010 18:36:43 +0200 Received: by 10.204.140.18 with SMTP id g18mr1706507bku.47.1270139803349; Thu, 01 Apr 2010 09:36:43 -0700 (PDT) Message-ID: From: Olivier Smedts To: Bartosz Stec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: gpart failing with no such geom after gpt corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 16:36:47 -0000 2010/4/1 Bartosz Stec : > Hello ZFS and GPT hackers :) > > I'm sending this message to both freebsd-current and freebsd-fs because i= t > doesn't seems to be a CURRENT-specific issue. > > Yesterday I tried to migrate my mixed UFS/RAIDZ config to clean RAIDZ wit= h > GPT boot. I've following mostly this guide: > http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1 > I'm using CURRENT on 3x40GB HDDs (ad0-ad3) and additional 250GB HDD has b= een > used for data migration (ad4). > > Data was copied form RAIDZ to 250GB HDD, GPT sheme was created on =A040GB > HDDs, then new zpool on them, and finally data went back to RAIDZ. Bootin= g > from RAIDZ was succesful, so far so good. > > After a while I've =A0noticed some SMART errors on ad1, so I've booted ma= chine > with seatools for dos and made long test. One bad sector was found and > reallocated, nothing to worry about. > As I was in seatools already, I've decided to adjust LBA size on that dis= k > (seatools can do that), because it was about 30MB larger than the other t= wo, > and because of that I had to adjust size of freebsd-zfs partition on that > disk to match exact size of others (otherwise 'zpool create' will complai= n). > So LBA was adjusted and system rebooted. > > Yes, I was aware that changing disk size probably end with corrupted GPT = and > data loss, but it doesn't seem to be a big deal for me as far as 2/3 of > zpool is alive, because I can always recreate gpt and resilver ad1. > > Unfortunately it wasn't so easy. First of all system booted, and as I > expected kernel message shows GPT error on ad1. Zpool was degraded but al= ive > and kicking. However, when I tried to execute any gpart command on ad1, i= t > return: > > =A0 ad1: no such geom Are you sure you created a partition scheme with gpart on ad1 before issuing partition-related gpart commands ? > > ad1 was present under /dev, and it could be accessed by sysinstall/fdisk, > but no with gpart. I've created bsd slice with sysinstall on ad1 and > rebooted, with hope that after reboot I could acces ad1 with gpart and > recreate GPT scheme. Another surprise - system didn't boot at all, reboot= ing > after couple of seconds in loader (changing boot device didn't make a > difference). > > Only way I could boot system at this moment was connecting 250GB HDD whic= h > fortunately still had data from zpool migration and boot from it. Another > surprise - kernel was still complaining about GPT corruption on ad1. I ha= d > no other ideas so I ran > > =A0 dd if=3D/dev/zero of=3D/dev/ad1 bs=3D512 count=3D512 > > to clear beginning of the hdd. After that disk was still unaccesible from= t > gpart, so I tried sysinstall/fdisk againt to create standard BSD > partitioning scheme and rebooted system. > After that finally gpart started to talk with ad1 and GPT scheme and zpoo= l > has been recreated and work as it supposed to. > > Still, how can we clear broken GPT data after it got corrupted? > Why gpart has been showing "ad1: no such geom", and how can we deal with > this problem? > Finally, why gptzfsboot failed with GPT corrupted on other disk after try= ing > to fix it, while it booted at first place? > > Or maybe changing LBA size of already partitioned HDD is extreme case, an= d > the only way these problems could be triggered ;)? > > Cheers! > > -- > Bartosz Stec > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > --=20 Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 16:38:29 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAA31106564A for ; Thu, 1 Apr 2010 16:38:29 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4B5058FC1C for ; Thu, 1 Apr 2010 16:38:28 +0000 (UTC) Received: by wwb24 with SMTP id 24so907250wwb.13 for ; Thu, 01 Apr 2010 09:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=IVfh4esZXsbzdBSBD/dIooqZisazWZ/eUM6qTDi1N7k=; b=GGpfa8YcUEtmH0OUVQl4jvRrkq/qVwFPotp7jpKFJFesIwAifaWLj3drXzQN175uHt ZxW2URN4cqQw7KHu6GppShp5WRqyKzbraldpzrZMvlxnzHbqt1wCLfw31GH5NOXmu67Q PkrygG6rks8hH8BpmqqesldN1SyPLVQj6cr8k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=evRVsjEFDM31Edzd7bFWVm4Z+z3IGL+ihzba3RchMNJhKoyynM4HEkRUKVMRMCw1rr dK9OUl1QjZNPjRqXKSWvcVA4QjaAmIgBSrEy05TnECfx6DFMESSP5zX/UqjkJyqx4MM0 Xx4iHjJ8UH17D7NaFVZ37AA1kIONFaT5HAWa0= MIME-Version: 1.0 Received: by 10.216.7.146 with HTTP; Thu, 1 Apr 2010 09:38:27 -0700 (PDT) In-Reply-To: <4BB4C5A1.8050706@janh.de> References: <4BB43D4B.7060507@gmail.com> <4BB4C5A1.8050706@janh.de> Date: Thu, 1 Apr 2010 09:38:27 -0700 Received: by 10.216.89.195 with SMTP id c45mr530481wef.98.1270139908171; Thu, 01 Apr 2010 09:38:28 -0700 (PDT) Message-ID: From: Jack Vogel To: Jan Henrik Sylvester Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Thomas Gellekum , David Ehrmann , current-list freebsd Subject: Re: Re: Intel H55 and em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Apr 2010 16:38:29 -0000 Yup, gonna MFC the code from CURRENT to STABLE/8 first thing next week, at least that's my plan. Sorry, I thought STABLE/8 already had PCH in it, my bad. I checked and the ALTQ fix is in the tree, so pulling the directory from HEAD and adding it to STABLE/8 should work fine. MFC will be coming first thing Monday. Jack On Thu, Apr 1, 2010 at 9:11 AM, Jan Henrik Sylvester wrote: > On 01/-10/-28163 20:59, Jack Vogel wrote: > >> OH, as to my last statement, the code in CURRENT will NOT work on 8.0 >> RELEASE, >> it would require a change to sys/conf/files, and it also has a fix in the >> stack that is not >> in RELEASE. SO taking the latest would require you take the whole tree. >> >> Jack >> >> >> On Wed, Mar 31, 2010 at 11:39 PM, Jack Vogel wrote: >> >> The device subfamily on those motherboards is called PCH, and its only in >>> the em driver as of >>> last December, The CVS delta of if_em is 1.27. You can either update to >>> STABLE/8 or CURRENT. >>> If you wish to just pull the e1000 driver directory it should work fine >>> in >>> 8.0 RELEASE also. >>> >>> Cheers, >>> >>> Jack >>> >> > In your correction, you did not really mention 8-STABLE, you only warn > about putting e1000 from CURRENT to 8.0-RELEASE. > > I got the same problem: > http://lists.freebsd.org/pipermail/freebsd-mobile/2010-March/011952.html > > Since I did not get a reply, I put the whole e1000 directory from CURRENT > into 8-STABLE. > > Is there any problem with that? (It _seems_ to work so far.) > > Are you going to MFC the PCH devices to 8-STABLE any time soon? > > Thanks, > Jan Henrik > From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 17:02:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B57AE1065672 for ; Thu, 1 Apr 2010 17:02:23 +0000 (UTC) (envelope-from nathan.j.mates@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 88C1A8FC0C for ; Thu, 1 Apr 2010 17:02:23 +0000 (UTC) Received: by pvc7 with SMTP id 7so571491pvc.13 for ; Thu, 01 Apr 2010 10:02:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=UYcDLf56QfgiVJ//0qj5TINX9c8eJOYY6/8qpgyb+lo=; b=GWpkZ3pe01lEWIzB4OHBn3+8w2g9mGmUy4e/Gahw8iAg58vfUROCu0YqDiikHTXVcQ fTIMEuNR5nDrWkliMphSTB3ZOZ9kOiExavBuZdFTkViT9Bffkv6l+/NMr8JbaZQbM7xh RYbYnzfRZ95yeIvNoVmT3pBwAR+TpxbzQOWoE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SZ75GHuLuZiHF+7qbknM6SGwIcv7T1zlKYP5MrDoV9ud8fD3M4+PdRCU7Fbc5o9U/R h4nsdcyyNYzpYxb/S5v4vbyVqQjIXktKX93Makf6/Qht/VwbRRV0X0NLltPG+vx39XIa OS9cFw2BpJic7q5Sv1PBKo4OVc4y36i2Rz/JA= MIME-Version: 1.0 Received: by 10.142.125.3 with HTTP; Thu, 1 Apr 2010 09:39:23 -0700 (PDT) In-Reply-To: <20100401153039.207980@gmx.net> References: <4BB43D4B.7060507@gmail.com> <20100401153039.207980@gmx.net> Date: Thu, 1 Apr 2010 11:39:23 -0500 Received: by 10.143.84.6 with SMTP id m6mr368573wfl.8.1270139963702; Thu, 01 Apr 2010 09:39:23 -0700 (PDT) Message-ID: From: Nathan Mates To: Thomas Gellekum Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ehrmann@gmail.com, Jack Vogel , freebsd-current@freebsd.org Subject: Re: Intel H55 and em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Apr 2010 17:02:23 -0000 On Thu, Apr 1, 2010 at 10:30 AM, Thomas Gellekum w= rote: > > Jack Vogel wrote: > > The device subfamily on those motherboards is called PCH, and its only = in > > the em driver as of > > last December, The CVS delta of if_em is 1.27. You can either update to > > STABLE/8 or CURRENT. > > If you wish to just pull the e1000 driver directory it should work fine= in > > 8.0 RELEASE also. > > 8-STABLE doesn't work for me. The ethernet device is not recognized, and = I get warnings about interrupt storms on irq19 (atapci1), which I don't see= with 8-RELEASE. That might be a matter of missing diagnostics in the relea= se kernel (the numbers from 'vmstat -i' seem to suggest this). Ditto. I have a Intel BOXDH55TC MB w/ a Core i3-530, 8GB RAM. Grabbed RELENG_8 , which http://www.freebsd.org/doc/handbook/cvs-tags.html says is stable.8. Compiled an amd64 GENERIC kernel. Could not recognize the ethernet. Had to go to CURRENT to get it working. Nathan Mates From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 17:34:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 464E51065672 for ; Thu, 1 Apr 2010 17:34:28 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout027.mac.com (asmtpout027.mac.com [17.148.16.102]) by mx1.freebsd.org (Postfix) with ESMTP id 2FBE68FC18 for ; Thu, 1 Apr 2010 17:34:27 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from macbook-pro.jnpr.net (natint3.juniper.net [66.129.224.36]) by asmtp027.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0L0700EGUKTC8790@asmtp027.mac.com>; Thu, 01 Apr 2010 10:34:26 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004010164 From: Marcel Moolenaar In-reply-to: <4BB49E3F.7070506@it4pro.pl> Date: Thu, 01 Apr 2010 10:34:23 -0700 Message-id: <4D9CB47F-5571-444D-A30B-0227BA01D6E9@mac.com> References: <4BB49E3F.7070506@it4pro.pl> To: Bartosz Stec X-Mailer: Apple Mail (2.1078) Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: gpart failing with no such geom after gpt corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 17:34:28 -0000 On Apr 1, 2010, at 6:23 AM, Bartosz Stec wrote: > Unfortunately it wasn't so easy. First of all system booted, and as I expected kernel message shows GPT error on ad1. Zpool was degraded but alive and kicking. However, when I tried to execute any gpart command on ad1, it return: > > ad1: no such geom If the GPT is rejected, no GEOM is created in the kernel. It's the GEOM that gpart(8) talks to, so the error indicates that the GPT is not accepted after you changed the disk size. For all practical purposes ad1 doesn't have a partitioning. The only gpart command you can use is: gpart create -s gpt ad1 This creates a new GPT on the disk, wiping out whatever was there... -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 18:15:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51402106566C; Thu, 1 Apr 2010 18:15:24 +0000 (UTC) (envelope-from olivier@gid0.org) Received: from mail-bw0-f216.google.com (mail-bw0-f216.google.com [209.85.218.216]) by mx1.freebsd.org (Postfix) with ESMTP id B26B58FC0A; Thu, 1 Apr 2010 18:15:23 +0000 (UTC) Received: by bwz8 with SMTP id 8so1106207bwz.3 for ; Thu, 01 Apr 2010 11:15:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.6.76 with HTTP; Thu, 1 Apr 2010 11:15:22 -0700 (PDT) In-Reply-To: <4BB49E3F.7070506@it4pro.pl> References: <4BB49E3F.7070506@it4pro.pl> Date: Thu, 1 Apr 2010 20:15:22 +0200 Received: by 10.204.32.196 with SMTP id e4mr1816408bkd.131.1270145722089; Thu, 01 Apr 2010 11:15:22 -0700 (PDT) Message-ID: From: Olivier Smedts To: Bartosz Stec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: gpart failing with no such geom after gpt corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 18:15:24 -0000 2010/4/1 Bartosz Stec : > Hello ZFS and GPT hackers :) > > I'm sending this message to both freebsd-current and freebsd-fs because i= t > doesn't seems to be a CURRENT-specific issue. > > Yesterday I tried to migrate my mixed UFS/RAIDZ config to clean RAIDZ wit= h > GPT boot. I've following mostly this guide: > http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1 > I'm using CURRENT on 3x40GB HDDs (ad0-ad3) and additional 250GB HDD has b= een > used for data migration (ad4). > > Data was copied form RAIDZ to 250GB HDD, GPT sheme was created on =A040GB > HDDs, then new zpool on them, and finally data went back to RAIDZ. Bootin= g > from RAIDZ was succesful, so far so good. > > After a while I've =A0noticed some SMART errors on ad1, so I've booted ma= chine > with seatools for dos and made long test. One bad sector was found and > reallocated, nothing to worry about. > As I was in seatools already, I've decided to adjust LBA size on that dis= k > (seatools can do that), because it was about 30MB larger than the other t= wo, > and because of that I had to adjust size of freebsd-zfs partition on that > disk to match exact size of others (otherwise 'zpool create' will complai= n). > So LBA was adjusted and system rebooted. I don't understand why you adjusted LBA. You're using GPT partitions, so, couldn't you just make the zfs partition the same size on all disks by adjusting it to the smallest disk, and let free space at the end of the bigger ones ? Cheers, Olivier > Yes, I was aware that changing disk size probably end with corrupted GPT = and > data loss, but it doesn't seem to be a big deal for me as far as 2/3 of > zpool is alive, because I can always recreate gpt and resilver ad1. > > Unfortunately it wasn't so easy. First of all system booted, and as I > expected kernel message shows GPT error on ad1. Zpool was degraded but al= ive > and kicking. However, when I tried to execute any gpart command on ad1, i= t > return: > > =A0 ad1: no such geom > > ad1 was present under /dev, and it could be accessed by sysinstall/fdisk, > but no with gpart. I've created bsd slice with sysinstall on ad1 and > rebooted, with hope that after reboot I could acces ad1 with gpart and > recreate GPT scheme. Another surprise - system didn't boot at all, reboot= ing > after couple of seconds in loader (changing boot device didn't make a > difference). > > Only way I could boot system at this moment was connecting 250GB HDD whic= h > fortunately still had data from zpool migration and boot from it. Another > surprise - kernel was still complaining about GPT corruption on ad1. I ha= d > no other ideas so I ran > > =A0 dd if=3D/dev/zero of=3D/dev/ad1 bs=3D512 count=3D512 > > to clear beginning of the hdd. After that disk was still unaccesible from= t > gpart, so I tried sysinstall/fdisk againt to create standard BSD > partitioning scheme and rebooted system. > After that finally gpart started to talk with ad1 and GPT scheme and zpoo= l > has been recreated and work as it supposed to. > > Still, how can we clear broken GPT data after it got corrupted? > Why gpart has been showing "ad1: no such geom", and how can we deal with > this problem? > Finally, why gptzfsboot failed with GPT corrupted on other disk after try= ing > to fix it, while it booted at first place? > > Or maybe changing LBA size of already partitioned HDD is extreme case, an= d > the only way these problems could be triggered ;)? > > Cheers! > > -- > Bartosz Stec > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > --=20 Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: olivier@gid0.org - against HTML email & vCards X www: http://www.gid0.org - against proprietary attachments / \ "Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas." From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 16:29:33 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8BAD3106564A for ; Thu, 1 Apr 2010 16:29:33 +0000 (UTC) (envelope-from me@janh.de) Received: from mailhost.uni-hamburg.de (mailhost.uni-hamburg.de [134.100.32.155]) by mx1.freebsd.org (Postfix) with ESMTP id 3F2A58FC0A for ; Thu, 1 Apr 2010 16:29:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mailhost.uni-hamburg.de (Postfix) with ESMTP id AAD4B9010C; Thu, 1 Apr 2010 18:10:29 +0200 (CEST) X-Virus-Scanned: by University of Hamburg (RRZ/mailhost) Received: from mailhost.uni-hamburg.de ([127.0.0.1]) by localhost (mailhost.uni-hamburg.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id gR+RJ2H8KzMz; Thu, 1 Apr 2010 18:10:29 +0200 (CEST) Received: from pc861.math.uni-hamburg.de (pc861.math.uni-hamburg.de [134.100.222.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: fmjv004) by mailhost.uni-hamburg.de (Postfix) with ESMTPSA id 8B3A59005C; Thu, 1 Apr 2010 18:10:29 +0200 (CEST) Message-ID: <4BB4C5A1.8050706@janh.de> Date: Thu, 01 Apr 2010 18:11:13 +0200 From: Jan Henrik Sylvester User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: Jack Vogel References: <4BB43D4B.7060507@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 01 Apr 2010 18:48:06 +0000 Cc: Thomas Gellekum , David Ehrmann , current-list freebsd Subject: Re: Re: Intel H55 and em0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Apr 2010 16:29:33 -0000 On 01/-10/-28163 20:59, Jack Vogel wrote: > OH, as to my last statement, the code in CURRENT will NOT work on 8.0 > RELEASE, > it would require a change to sys/conf/files, and it also has a fix in the > stack that is not > in RELEASE. SO taking the latest would require you take the whole tree. > > Jack > > > On Wed, Mar 31, 2010 at 11:39 PM, Jack Vogel wrote: > >> The device subfamily on those motherboards is called PCH, and its only in >> the em driver as of >> last December, The CVS delta of if_em is 1.27. You can either update to >> STABLE/8 or CURRENT. >> If you wish to just pull the e1000 driver directory it should work fine in >> 8.0 RELEASE also. >> >> Cheers, >> >> Jack In your correction, you did not really mention 8-STABLE, you only warn about putting e1000 from CURRENT to 8.0-RELEASE. I got the same problem: http://lists.freebsd.org/pipermail/freebsd-mobile/2010-March/011952.html Since I did not get a reply, I put the whole e1000 directory from CURRENT into 8-STABLE. Is there any problem with that? (It _seems_ to work so far.) Are you going to MFC the PCH devices to 8-STABLE any time soon? Thanks, Jan Henrik From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 19:02:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0738106566B; Thu, 1 Apr 2010 19:02:41 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 9ABAC8FC17; Thu, 1 Apr 2010 19:02:41 +0000 (UTC) Received: from [10.170.20.44] (nat-170-141-177-44.tn.gov [170.141.177.44]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o31J2cpe040938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Apr 2010 15:02:39 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) Message-ID: <4BB4EDC9.2050507@FreeBSD.org> Date: Thu, 01 Apr 2010 14:02:33 -0500 From: Robert Noland Organization: FreeBSD User-Agent: Thunderbird 2.0.0.19 (X11/20090218) MIME-Version: 1.0 To: Olivier Smedts References: <4BB49E3F.7070506@it4pro.pl> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=1.8 required=5.0 tests=AWL, BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Bartosz Stec , freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: gpart failing with no such geom after gpt corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 19:02:42 -0000 Olivier Smedts wrote: > 2010/4/1 Bartosz Stec : >> Hello ZFS and GPT hackers :) >> >> I'm sending this message to both freebsd-current and freebsd-fs because it >> doesn't seems to be a CURRENT-specific issue. >> >> Yesterday I tried to migrate my mixed UFS/RAIDZ config to clean RAIDZ with >> GPT boot. I've following mostly this guide: >> http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1 >> I'm using CURRENT on 3x40GB HDDs (ad0-ad3) and additional 250GB HDD has been >> used for data migration (ad4). >> >> Data was copied form RAIDZ to 250GB HDD, GPT sheme was created on 40GB >> HDDs, then new zpool on them, and finally data went back to RAIDZ. Booting >> from RAIDZ was succesful, so far so good. >> >> After a while I've noticed some SMART errors on ad1, so I've booted machine >> with seatools for dos and made long test. One bad sector was found and >> reallocated, nothing to worry about. >> As I was in seatools already, I've decided to adjust LBA size on that disk >> (seatools can do that), because it was about 30MB larger than the other two, >> and because of that I had to adjust size of freebsd-zfs partition on that >> disk to match exact size of others (otherwise 'zpool create' will complain). >> So LBA was adjusted and system rebooted. > > I don't understand why you adjusted LBA. You're using GPT partitions, > so, couldn't you just make the zfs partition the same size on all > disks by adjusting it to the smallest disk, and let free space at the > end of the bigger ones ? For that matter, my understanding is that ZFS just doesn't care. If you have disks of different sized in a raidz, the pool size will be limited by the size of the smallest device. If those devices are replaced with larger ones, then the pool just grows to take advantage of the additional available space. robert. > Cheers, > Olivier > >> Yes, I was aware that changing disk size probably end with corrupted GPT and >> data loss, but it doesn't seem to be a big deal for me as far as 2/3 of >> zpool is alive, because I can always recreate gpt and resilver ad1. >> >> Unfortunately it wasn't so easy. First of all system booted, and as I >> expected kernel message shows GPT error on ad1. Zpool was degraded but alive >> and kicking. However, when I tried to execute any gpart command on ad1, it >> return: >> >> ad1: no such geom >> >> ad1 was present under /dev, and it could be accessed by sysinstall/fdisk, >> but no with gpart. I've created bsd slice with sysinstall on ad1 and >> rebooted, with hope that after reboot I could acces ad1 with gpart and >> recreate GPT scheme. Another surprise - system didn't boot at all, rebooting >> after couple of seconds in loader (changing boot device didn't make a >> difference). >> >> Only way I could boot system at this moment was connecting 250GB HDD which >> fortunately still had data from zpool migration and boot from it. Another >> surprise - kernel was still complaining about GPT corruption on ad1. I had >> no other ideas so I ran >> >> dd if=/dev/zero of=/dev/ad1 bs=512 count=512 >> >> to clear beginning of the hdd. After that disk was still unaccesible fromt >> gpart, so I tried sysinstall/fdisk againt to create standard BSD >> partitioning scheme and rebooted system. >> After that finally gpart started to talk with ad1 and GPT scheme and zpool >> has been recreated and work as it supposed to. >> >> Still, how can we clear broken GPT data after it got corrupted? >> Why gpart has been showing "ad1: no such geom", and how can we deal with >> this problem? >> Finally, why gptzfsboot failed with GPT corrupted on other disk after trying >> to fix it, while it booted at first place? >> >> Or maybe changing LBA size of already partitioned HDD is extreme case, and >> the only way these problems could be triggered ;)? >> >> Cheers! >> >> -- >> Bartosz Stec >> >> >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> > > > From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 19:10:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 81F28106564A for ; Thu, 1 Apr 2010 19:10:10 +0000 (UTC) (envelope-from paul@fletchermoorland.co.uk) Received: from hydra.fletchermoorland.co.uk (hydra.fletchermoorland.co.uk [78.33.209.59]) by mx1.freebsd.org (Postfix) with ESMTP id 0DD7B8FC1D for ; Thu, 1 Apr 2010 19:10:09 +0000 (UTC) Received: from demophon.fletchermoorland.co.uk (demophon.fletchermoorland.co.uk [192.168.0.154]) by hydra.fletchermoorland.co.uk (8.14.3/8.14.3) with ESMTP id o31JA5K6097605; Thu, 1 Apr 2010 20:10:05 +0100 (BST) (envelope-from paul@fletchermoorland.co.uk) Message-ID: <4BB4EF8D.9090809@fletchermoorland.co.uk> Date: Thu, 01 Apr 2010 19:10:05 +0000 From: Paul Wootton User-Agent: Thunderbird 2.0.0.23 (X11/20091217) MIME-Version: 1.0 To: Bartosz Stec References: <4BB49E3F.7070506@it4pro.pl> In-Reply-To: <4BB49E3F.7070506@it4pro.pl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=4.5 required=10.0 tests=ALL_TRUSTED,BAYES_80, DNS_FROM_OPENWHOIS,FH_DATE_PAST_20XX autolearn=no version=3.2.5 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on hydra.fletchermoorland.co.uk Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: gpart failing with no such geom after gpt corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 19:10:10 -0000 Bartosz, One thing to remember is that GPT stores it's header and entry tables at both the start and end of the disk for redundancy. As far as I understand it, by making the disk physically smaller, the GPT primary header and entry data would have become invalid as the last partition would now be ending past the end of the disk Partition table format Offset Length Content 0 8 Signature ("EFI PART", 45 46 49 20 50 41 52 54) ... 24 8 Current LBA (location of this header copy) 32 8 Backup LBA (location of the other header copy) 40 8 First usable LBA for partitions (primary partition table last LBA + 1) 48 8 Last usable LBA (secondary partition table first LBA - 1) ... GUID partition entry format Offset Length Content 0 16 Partition type GUID ... 32 8 First LBA (little-endian) 40 8 Last LBA (inclusive, usually odd) ... See http://en.wikipedia.org/wiki/GUID_Partition_Table From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 19:34:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5891D1065675; Thu, 1 Apr 2010 19:34:25 +0000 (UTC) (envelope-from rnoland@FreeBSD.org) Received: from gizmo.2hip.net (gizmo.2hip.net [64.74.207.195]) by mx1.freebsd.org (Postfix) with ESMTP id 15C3E8FC19; Thu, 1 Apr 2010 19:34:24 +0000 (UTC) Received: from [10.170.20.44] (nat-170-141-177-44.tn.gov [170.141.177.44]) (authenticated bits=0) by gizmo.2hip.net (8.14.3/8.14.3) with ESMTP id o31JYMqm041104 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Apr 2010 15:34:23 -0400 (EDT) (envelope-from rnoland@FreeBSD.org) Message-ID: <4BB4F539.1070204@FreeBSD.org> Date: Thu, 01 Apr 2010 14:34:17 -0500 From: Robert Noland Organization: FreeBSD User-Agent: Thunderbird 2.0.0.19 (X11/20090218) MIME-Version: 1.0 To: Olivier Smedts References: <4BB49E3F.7070506@it4pro.pl> <4BB4EDC9.2050507@FreeBSD.org> In-Reply-To: <4BB4EDC9.2050507@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=1.3 required=5.0 tests=AWL, BAYES_00, FH_DATE_PAST_20XX, RDNS_DYNAMIC,SPF_SOFTFAIL autolearn=no version=3.2.5 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gizmo.2hip.net Cc: Bartosz Stec , freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: gpart failing with no such geom after gpt corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 19:34:25 -0000 Robert Noland wrote: > > > Olivier Smedts wrote: >> 2010/4/1 Bartosz Stec : >>> Hello ZFS and GPT hackers :) >>> >>> I'm sending this message to both freebsd-current and freebsd-fs >>> because it >>> doesn't seems to be a CURRENT-specific issue. >>> >>> Yesterday I tried to migrate my mixed UFS/RAIDZ config to clean RAIDZ >>> with >>> GPT boot. I've following mostly this guide: >>> http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/RAIDZ1 >>> I'm using CURRENT on 3x40GB HDDs (ad0-ad3) and additional 250GB HDD >>> has been >>> used for data migration (ad4). >>> >>> Data was copied form RAIDZ to 250GB HDD, GPT sheme was created on 40GB >>> HDDs, then new zpool on them, and finally data went back to RAIDZ. >>> Booting >>> from RAIDZ was succesful, so far so good. >>> >>> After a while I've noticed some SMART errors on ad1, so I've booted >>> machine >>> with seatools for dos and made long test. One bad sector was found and >>> reallocated, nothing to worry about. >>> As I was in seatools already, I've decided to adjust LBA size on that >>> disk >>> (seatools can do that), because it was about 30MB larger than the >>> other two, >>> and because of that I had to adjust size of freebsd-zfs partition on >>> that >>> disk to match exact size of others (otherwise 'zpool create' will >>> complain). >>> So LBA was adjusted and system rebooted. >> >> I don't understand why you adjusted LBA. You're using GPT partitions, >> so, couldn't you just make the zfs partition the same size on all >> disks by adjusting it to the smallest disk, and let free space at the >> end of the bigger ones ? > > For that matter, my understanding is that ZFS just doesn't care. If you > have disks of different sized in a raidz, the pool size will be limited > by the size of the smallest device. If those devices are replaced with > larger ones, then the pool just grows to take advantage of the > additional available space. balrog% gpart show => 34 2097085 md0 GPT (1.0G) 34 128 1 freebsd-boot (64K) 162 2096957 2 freebsd-zfs (1.0G) => 34 2097085 md1 GPT (1.0G) 34 128 1 freebsd-boot (64K) 162 2096957 2 freebsd-zfs (1.0G) => 34 4194237 md2 GPT (2.0G) 34 128 1 freebsd-boot (64K) 162 4194109 2 freebsd-zfs (2.0G) balrog% zpool status pool: test state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM test ONLINE 0 0 0 raidz1 ONLINE 0 0 0 md0p2 ONLINE 0 0 0 md1p2 ONLINE 0 0 0 md2p2 ONLINE 0 0 0 errors: No known data errors balrog% zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT test 2.98G 141K 2.98G 0% ONLINE - robert. > robert. > >> Cheers, >> Olivier >> >>> Yes, I was aware that changing disk size probably end with corrupted >>> GPT and >>> data loss, but it doesn't seem to be a big deal for me as far as 2/3 of >>> zpool is alive, because I can always recreate gpt and resilver ad1. >>> >>> Unfortunately it wasn't so easy. First of all system booted, and as I >>> expected kernel message shows GPT error on ad1. Zpool was degraded >>> but alive >>> and kicking. However, when I tried to execute any gpart command on >>> ad1, it >>> return: >>> >>> ad1: no such geom >>> >>> ad1 was present under /dev, and it could be accessed by >>> sysinstall/fdisk, >>> but no with gpart. I've created bsd slice with sysinstall on ad1 and >>> rebooted, with hope that after reboot I could acces ad1 with gpart and >>> recreate GPT scheme. Another surprise - system didn't boot at all, >>> rebooting >>> after couple of seconds in loader (changing boot device didn't make a >>> difference). >>> >>> Only way I could boot system at this moment was connecting 250GB HDD >>> which >>> fortunately still had data from zpool migration and boot from it. >>> Another >>> surprise - kernel was still complaining about GPT corruption on ad1. >>> I had >>> no other ideas so I ran >>> >>> dd if=/dev/zero of=/dev/ad1 bs=512 count=512 >>> >>> to clear beginning of the hdd. After that disk was still unaccesible >>> fromt >>> gpart, so I tried sysinstall/fdisk againt to create standard BSD >>> partitioning scheme and rebooted system. >>> After that finally gpart started to talk with ad1 and GPT scheme and >>> zpool >>> has been recreated and work as it supposed to. >>> >>> Still, how can we clear broken GPT data after it got corrupted? >>> Why gpart has been showing "ad1: no such geom", and how can we deal with >>> this problem? >>> Finally, why gptzfsboot failed with GPT corrupted on other disk after >>> trying >>> to fix it, while it booted at first place? >>> >>> Or maybe changing LBA size of already partitioned HDD is extreme >>> case, and >>> the only way these problems could be triggered ;)? >>> >>> Cheers! >>> >>> -- >>> Bartosz Stec >>> >>> >>> _______________________________________________ >>> freebsd-fs@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >>> >> >> >> > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 19:59:52 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 921411065674 for ; Thu, 1 Apr 2010 19:59:52 +0000 (UTC) (envelope-from tom@uffner.com) Received: from eris.uffner.com (uffner.com [66.208.243.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4E7948FC16 for ; Thu, 1 Apr 2010 19:59:51 +0000 (UTC) Received: from xiombarg.uffner.com (static-71-162-143-94.phlapa.fios.verizon.net [71.162.143.94]) (authenticated bits=0) by eris.uffner.com (8.14.3/8.14.3) with ESMTP id o31K2C6V043037 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=FAIL); Thu, 1 Apr 2010 16:02:13 -0400 (EDT) (envelope-from tom@uffner.com) Message-ID: <4BB4FB35.2040703@uffner.com> Date: Thu, 01 Apr 2010 15:59:49 -0400 From: Tom Uffner User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.8) Gecko/20100330 SeaMonkey/2.0.3 MIME-Version: 1.0 To: Xin LI References: <4BA7E0B8.3080406@delphij.net> <4BAE2B4F.6060005@protected-networks.net> <4BB3FD5D.9070600@uffner.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Apr 2010 19:59:52 -0000 Xin LI wrote: > On Wed, Mar 31, 2010 at 6:56 PM, Tom Uffner wrote: >> Michael Butler wrote: >> >>> This breaks most (if not all) of the QT4-dependent ports for the lack of >>> a definition of "off64_t". >> >> it also breaks multimedia/mplayer, graphics/ImageMagick, and >> print/ghostscript8 & everything that depends on it. > > Just because they used to compile DOES NOT mean they were right. It's > NOT right to define _LARGEFILE64_SOURCE on FreeBSD, see: > > http://www.delorie.com/gnu/docs/glibc/libc_13.html i realize this. i was just adding to the list of ports that no longer build after this change. ghostscript is kind of important for print support. i doubt this is "right" either, but it is a quick & dirty way to make mplayer compile again: --- configure.orig 2010-04-01 15:49:37.000000000 -0400 +++ configure 2010-04-01 15:50:50.000000000 -0400 @@ -5337,7 +5337,7 @@ #include int main(void) { return 0; } EOF - cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE \ + cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 \ -ldvdread $_ld_dl && _dvdread=yes && _res_comment="external" fi fi @@ -7412,8 +7412,6 @@ if test "$_largefiles" = yes || freebsd ; then CFLAGS="$CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" if test "$_dvdread" = yes || test "$_libdvdcss_internal" = yes ; then - # dvdread support requires this (for off64_t) - CFLAGS="$CFLAGS -D_LARGEFILE64_SOURCE" cygwin && CFLAGS="$CFLAGS -DSYS_CYGWIN" fi fi From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 20:02:54 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 988AE106566C for ; Thu, 1 Apr 2010 20:02:54 +0000 (UTC) (envelope-from admin@kkip.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 0EBD18FC1E for ; Thu, 1 Apr 2010 20:02:53 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74] helo=[192.168.0.2]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxQbA-000E3y-PS; Thu, 01 Apr 2010 22:02:53 +0200 Message-ID: <4BB4FBDD.5030709@kkip.pl> Date: Thu, 01 Apr 2010 22:02:37 +0200 From: Bartosz Stec User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100306 Shredder/3.0.3 MIME-Version: 1.0 References: <4BB49E3F.7070506@it4pro.pl> <4D9CB47F-5571-444D-A30B-0227BA01D6E9@mac.com> In-Reply-To: <4D9CB47F-5571-444D-A30B-0227BA01D6E9@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: admin@kkip.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -6.2 X-Spam-Score-Int: -61 X-Exim-Version: 4.71 (build at 02-Feb-2010 20:10:28) X-Date: 2010-04-01 22:02:53 X-Connected-IP: 78.8.144.74:60671 X-Message-Linecount: 42 X-Body-Linecount: 30 X-Message-Size: 1868 X-Body-Size: 1273 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: gpart failing with no such geom after gpt corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 20:02:54 -0000 On 2010-04-01 19:34, Marcel Moolenaar wrote: > On Apr 1, 2010, at 6:23 AM, Bartosz Stec wrote: > > >> Unfortunately it wasn't so easy. First of all system booted, and as I expected kernel message shows GPT error on ad1. Zpool was degraded but alive and kicking. However, when I tried to execute any gpart command on ad1, it return: >> >> ad1: no such geom >> > If the GPT is rejected, no GEOM is created in the kernel. It's the GEOM > that gpart(8) talks to, so the error indicates that the GPT is not accepted > after you changed the disk size. For all practical purposes ad1 doesn't have > a partitioning. > > The only gpart command you can use is: > gpart create -s gpt ad1 > > This creates a new GPT on the disk, wiping out whatever was there... > > It was a middle of night when I played with that, so I'm not remember clearly if I tried it simpliest way like above or not. Maybe not, and all noise I made was pointless and caused by my inexperience with gpart. Probably I just expected output from "gpart show ad1" be more like "no valid partitioning scheme on device" or "error in GPT table, please recreate partition scheme" in place of mystic geom message ;) Sorry for noise, thanks for a hint and happy easter everyone :) -- Bartosz Stec From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 20:07:25 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1E397106564A for ; Thu, 1 Apr 2010 20:07:25 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id E4DFB8FC08 for ; Thu, 1 Apr 2010 20:07:24 +0000 (UTC) Received: by pwi9 with SMTP id 9so1472804pwi.13 for ; Thu, 01 Apr 2010 13:07:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=zeBG70kRt5IipRzKyXQCmW4UHa8hFrrZAvOZMB94q70=; b=JwrxbfAKomfX7KVTa3vE2nlKncC3xGwyN0VdhW6NHcQBTz2okpPb8k7V/VqfD2dhuq zaH9wwsNagmKblwU6hDzcsyO8/JgOhBqHdxL9Dggd+Ug3Ii5ZN0jJpIry6dio+h46zFt AXGeiMNqgkFozEQPmGfrZq/HyusTs6677ab50= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=e6cb/qVUALlsTravaeCWAnvInHNdxi9uGLHkMRMD1UVTzsjwdRcPFrAXu6011BiiEP VMh8S/ub0RaC9tcFvRZavMnn/f68a9reawX1upILuOnMVtnk5MqceL7udl/16JiLULBU 8dL4PITB0/ZAypqDbdueYkkdsNzTXl200l5lU= MIME-Version: 1.0 Received: by 10.140.127.14 with HTTP; Thu, 1 Apr 2010 13:07:24 -0700 (PDT) In-Reply-To: <4BB4FB35.2040703@uffner.com> References: <4BA7E0B8.3080406@delphij.net> <4BAE2B4F.6060005@protected-networks.net> <4BB3FD5D.9070600@uffner.com> <4BB4FB35.2040703@uffner.com> Date: Thu, 1 Apr 2010 13:07:24 -0700 Received: by 10.141.3.1 with SMTP id f1mr744187rvi.26.1270152444475; Thu, 01 Apr 2010 13:07:24 -0700 (PDT) Message-ID: From: Xin LI To: Tom Uffner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Apr 2010 20:07:25 -0000 On Thu, Apr 1, 2010 at 12:59 PM, Tom Uffner wrote: > Xin LI wrote: >> >> On Wed, Mar 31, 2010 at 6:56 PM, Tom Uffner =C2=A0wrote: >>> >>> Michael Butler wrote: >>> >>>> This breaks most (if not all) of the QT4-dependent ports for the lack = of >>>> a definition of "off64_t". >>> >>> it also breaks multimedia/mplayer, graphics/ImageMagick, and >>> print/ghostscript8 & everything that depends on it. >> >> Just because they used to compile DOES NOT mean they were right. =C2=A0I= t's >> NOT right to define _LARGEFILE64_SOURCE on FreeBSD, see: >> >> http://www.delorie.com/gnu/docs/glibc/libc_13.html > > i realize this. i was just adding to the list of ports that no longer > build after this change. ghostscript is kind of important for print > support. > > i doubt this is "right" either, but it is a quick & dirty way to > make mplayer compile again: > > --- configure.orig =C2=A0 =C2=A0 =C2=A02010-04-01 15:49:37.000000000 -040= 0 > +++ configure =C2=A0 2010-04-01 15:50:50.000000000 -0400 > @@ -5337,7 +5337,7 @@ > =C2=A0#include > =C2=A0int main(void) { return 0; } > =C2=A0EOF > - =C2=A0 =C2=A0cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=3D64 > -D_LARGEFILE64_SOURCE \ > + =C2=A0 =C2=A0cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=3D64 \ > =C2=A0 =C2=A0 =C2=A0 -ldvdread $_ld_dl && _dvdread=3Dyes && _res_comment= =3D"external" > =C2=A0 fi > =C2=A0fi > @@ -7412,8 +7412,6 @@ > =C2=A0if test "$_largefiles" =3D yes || freebsd ; then > =C2=A0 CFLAGS=3D"$CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=3D64" > =C2=A0 if test "$_dvdread" =3D yes || test "$_libdvdcss_internal" =3D yes= ; then > - =C2=A0 =C2=A0# dvdread support requires this (for off64_t) > - =C2=A0 =C2=A0CFLAGS=3D"$CFLAGS -D_LARGEFILE64_SOURCE" > =C2=A0 =C2=A0 cygwin && CFLAGS=3D"$CFLAGS -DSYS_CYGWIN" > =C2=A0 fi > =C2=A0fi I think the latest (1.2.4.1) zlib has a bug that prevents using -D_LARGEFILE64_SOURCE at all, and expects -D_LARGEFILE64_SOURCE=3D1. I'll submit a patch to upstream :( Cheers, --=20 Xin LI http://www.delphij.net From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 19:42:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1CF24106566C; Thu, 1 Apr 2010 19:42:35 +0000 (UTC) (envelope-from bartosz.stec@it4pro.pl) Received: from mainframe.kkip.pl (kkip.pl [87.105.164.78]) by mx1.freebsd.org (Postfix) with ESMTP id 615EB8FC16; Thu, 1 Apr 2010 19:42:33 +0000 (UTC) Received: from static-78-8-144-74.ssp.dialog.net.pl ([78.8.144.74] helo=[192.168.0.2]) by mainframe.kkip.pl with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxQHZ-000Dy8-4P; Thu, 01 Apr 2010 21:42:32 +0200 Message-ID: <4BB4F71D.5030105@it4pro.pl> Date: Thu, 01 Apr 2010 21:42:21 +0200 From: Bartosz Stec Organization: IT4Pro User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100306 Shredder/3.0.3 MIME-Version: 1.0 References: <4BB49E3F.7070506@it4pro.pl> <4BB4EDC9.2050507@FreeBSD.org> In-Reply-To: <4BB4EDC9.2050507@FreeBSD.org> X-Authenticated-User: bartosz.stec@it4pro.pl X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -7.6 X-Spam-Score-Int: -75 X-Exim-Version: 4.71 (build at 02-Feb-2010 20:10:28) X-Date: 2010-04-01 21:42:32 X-Connected-IP: 78.8.144.74:60774 X-Message-Linecount: 205 X-Body-Linecount: 192 X-Message-Size: 7880 X-Body-Size: 7226 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 X-Mailman-Approved-At: Thu, 01 Apr 2010 20:28:39 +0000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org Subject: Re: gpart failing with no such geom after gpt corruption X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 19:42:35 -0000 On 2010-04-01 21:02, Robert Noland wrote: >>> >>> After a while I've noticed some SMART errors on ad1, so I've booted >>> machine >>> with seatools for dos and made long test. One bad sector was found and >>> reallocated, nothing to worry about. >>> As I was in seatools already, I've decided to adjust LBA size on >>> that disk >>> (seatools can do that), because it was about 30MB larger than the >>> other two, >>> and because of that I had to adjust size of freebsd-zfs partition on >>> that >>> disk to match exact size of others (otherwise 'zpool create' will >>> complain). >>> So LBA was adjusted and system rebooted. >> >> I don't understand why you adjusted LBA. You're using GPT partitions, >> so, couldn't you just make the zfs partition the same size on all >> disks by adjusting it to the smallest disk, and let free space at the >> end of the bigger ones ? > Well yes, I could indeed, and this is exactly what I did at the first time (before LBA count adjusting). But while I was already using software which could adjust LBA to make all HDD appear to be same size, I've decided to do it to never have to remember about it while partitioning ;) At least 'gpart show' isn't showing any unused (wasted) space now ;) : # gpart show => 34 78165293 ad0 GPT (37G) 34 128 1 freebsd-boot (64K) 162 2097152 2 freebsd-swap (1.0G) 2097314 76068013 3 freebsd-zfs (36G) => 34 78165293 ad1 GPT (37G) 34 128 1 freebsd-boot (64K) 162 2097152 2 freebsd-swap (1.0G) 2097314 76068013 3 freebsd-zfs (36G) => 34 78165293 ad2 GPT (37G) 34 128 1 freebsd-boot (64K) 162 2097152 2 freebsd-swap (1.0G) 2097314 76068013 3 freebsd-zfs (36G) > > For that matter, my understanding is that ZFS just doesn't care. If > you have disks of different sized in a raidz, the pool size will be > limited by the size of the smallest device. If those devices are > replaced with larger ones, then the pool just grows to take advantage > of the additional available space. > > robert. > Well, here's what man zpool says about zpool create: "(...) The use of differently sized devices within a single raidz or mirror group is also flagged as an error unless -f is specified." I know I could force it, I just didn't know if I should. After all it's just easier to type 3 times: gpt add -t freebsd-zfs -l diskN to use all free space on device than checking numbers on other disks and type gpt add -b 2097314 -s 76068013 -t freebsd-zfs -l diskN and that's why all story begins :) -- Bartosz Stec From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 21:22:44 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3AF51065673 for ; Thu, 1 Apr 2010 21:22:44 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 840418FC20 for ; Thu, 1 Apr 2010 21:22:44 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id D1D1D1FFC5D; Thu, 1 Apr 2010 21:22:42 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 1B92F846E2; Thu, 1 Apr 2010 15:30:47 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Xin LI References: <4BA7E0B8.3080406@delphij.net> <4BAE2B4F.6060005@protected-networks.net> <4BB3FD5D.9070600@uffner.com> Date: Thu, 01 Apr 2010 15:30:47 +0200 In-Reply-To: (Xin LI's message of "Wed, 31 Mar 2010 20:51:58 -0700") Message-ID: <86tyrvs3js.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Apr 2010 21:22:44 -0000 Xin LI writes: > Tom Uffner writes: > > Michael Butler writes: > > > This breaks most (if not all) of the QT4-dependent ports for the > > > lack of a definition of "off64_t". > > it also breaks multimedia/mplayer, graphics/ImageMagick, and > > print/ghostscript8 & everything that depends on it. > Just because they used to compile DOES NOT mean they were right. It's > NOT right to define _LARGEFILE64_SOURCE on FreeBSD, see: > > http://www.delorie.com/gnu/docs/glibc/libc_13.html Nor is it correct on Linux. As the above link says, _LARGEFILE64_SOURCE is a hack that was introduced to ease the transition from 32-bit off_t to 64-bit off_t. The correct idiom is to define _FILE_OFFSET_BITS to 64 before including and . http://www.delorie.com/gnu/docs/glibc/libc_13.html That was *fourteen years ago*, almost to the day. There is *no* excuse for using this hack today. *Especially* in software that was written long after that document was published. *Especially* when all you need to do to get it right is add AC_SYS_LARGEFILE to configure.ac and use off_t, struct stat and stat() / lstat() (without the "64" suffix) as if none of this had ever happened. And yes, I *will* keep harping on this until people Get It. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 22:17:02 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A6CD71065673 for ; Thu, 1 Apr 2010 22:17:02 +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 ESMTP id 522E98FC08 for ; Thu, 1 Apr 2010 22:17:01 +0000 (UTC) Received: (qmail 13426 invoked by uid 399); 1 Apr 2010 22:17:01 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 1 Apr 2010 22:17:01 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BB51B5B.1050606@FreeBSD.org> Date: Thu, 01 Apr 2010 15:16:59 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Apr 2010 22:17:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Greetings, SUMMARY On February 21 I sent a message to freebsd-arch@FreeBSD.org detailing the current state of BIND on FreeBSD, and plans for the future. You can see that message here: http://lists.freebsd.org/pipermail/freebsd-arch/2010-February/009908.html In that message I asked for feedback on my plans for dealing with BIND in the base. There wasn't much response on the lists, however I did receive a great deal of response privately, all more or less to the effect of, "Do we really need to continue having BIND in the base at all?" After careful consideration and private discussion about this issue the conclusion has been reached that the answer to this question is, "No." Therefore we will be removing BIND from the FreeBSD base. BACKGROUND "Back in the day" when the FreeBSD project started there was really only one show in the DNS town, BIND. In the last 10 years several truly viable, first-class DNS options have been developed, in both the authoritative and resolving server spaces. There are ports available for each of these options, and many FreeBSD users take advantage of them. There are of course also ports available for all supported BIND versions, as well as dns/bind9 for BIND version 9.3 which has been EOL'ed by ISC but is still in FreeBSD version 6. This also leads to the issue mentioned in the post above, the desynchronization between FreeBSD and ISC release schedules. While FreeBSD 6 is scheduled to EOL in November of this year, it contains BIND version 9.3.6-P1, which has long been EOL. There are a number of problems related to upgrading the version of BIND in a release branch of FreeBSD. Given the ease with which FreeBSD users can upgrade BIND with the ports tree, and given the characteristics of the vulnerabilities that have come to light with BIND 9.3.x to date, this hasn't been a problem. There is no guarantee that this will continue to be the case. This problem will reappear again in FreeBSD version 7 with BIND 9.4, and FreeBSD version 8 with BIND 9.6. PROS This change will have several advantages. 1) Users of all FreeBSD versions will be able to have easy access to the latest versions of BIND, and an easy upgrade path that does not involve a full OS upgrade. 2) The release synchronization problem mentioned above will no longer be a problem. 3) Users of other DNS solutions will no longer need to customize their build using the various WITH/WITHOUT_BIND* knobs. CONS Of course this change will have some costs. Users of named who rely on the current defaults will have some change management to deal with, however the costs will be minimal. The one area that has come up repeatedly in previous discussions about this topic is that users like having access to the command line tools dig, host, and nslookup. To deal with that issue I will be creating a bind-tools port so that those who want just those tools can easily add them, without the overhead of the rest of the BIND suite. If anyone has suggestions for other BIND tools that should be included in the port, please let me know. IMPLEMENTATION TIMELINE I will be removing BIND from HEAD today. Removal from the other branches will occur far enough in advance of their upcoming releases to ensure that the users have a chance to shake things out first. I'll also be committing the bind-tools and bind-config ports today so that users will continue to have easy access to the work I've done on named.conf, rc.d/named, etc. I have been maintaining BIND in the base for almost 8 years now, and while it's been challenging in a lot of ways, it's also been a great privilege to be able to help the FreeBSD community in this way. I can't say that I'll miss the drama of src updates though. :) Many happy returns of the day, Doug - -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEAREDAAYFAku1G1sACgkQyIakK9Wy8PuPgQCfdrhgscMQ+KPLcoRXx66f4f6M T8wAniZqULdwM+4oRsbOkFSDZIceWn0u =Syor -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Apr 1 22:57:01 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22D9C1065677 for ; Thu, 1 Apr 2010 22:57:01 +0000 (UTC) (envelope-from peter.thoenen@yahoo.com) Received: from web111402.mail.gq1.yahoo.com (web111402.mail.gq1.yahoo.com [67.195.15.138]) by mx1.freebsd.org (Postfix) with SMTP id CF2F18FC22 for ; Thu, 1 Apr 2010 22:57:00 +0000 (UTC) Received: (qmail 28762 invoked by uid 60001); 1 Apr 2010 22:30:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1270161020; bh=ft+a1KCdZIWgKEX1ROlb97tzeOFJ+/rZff2vCH7aXHE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=beZgE3kalXA/J1QyC7dPII3e1+k/6yoEVzQ3WXD3+TTA7AWkDCPolpoD72F6adFNxTUAtT1jkp/jrdhr1yT5UNu+lGjbIC97Dj51/YP6Kb7MAldJaeNJ4CZm/l6w/zVUOOc7EInuRJIgtvt/xRxYp4bA6w5g/OUvVnOcxa1cYXY= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=dUmpew0tmEXPzRsm52AmhRc2OwD1HsSjQTYjKpaLwMpjRdrBsCpiN2FO4MU+dX6QgKtCfaokufhZ7ItHiGBFMYh/4HF9as07q9cyHjlLDsSud2c0pWJ0TZRtWB0CdzaSPHjfAXEF5T0pn9RZEaB6UG2d0UU8rg2JEVA9JHKC75I=; Message-ID: <328862.28246.qm@web111402.mail.gq1.yahoo.com> X-YMail-OSG: 4qxas0wVM1lJq9WpN3Ztg8xbTKaxpQe3H7ifpCqKg1PPqc_ rvupGziQkTT8LC.TfbpDFZnyUS_4.pDxSL1rddcWVv7MqQzolfVXPDzPEmI9 NYmMdw5VjP4Sfzpaaa9UaeS0vI2bjqvpWNQpe52gkEei4KMhR0Wm_kcKtKZc ghJvL72co_69N4eoL9LRSB9thrkajibCeAZ_KKpnPCDQO3i3HpZRyWxmaaK9 j1Hr4nEvsIPZk13JEW5A47zdL9zWGqYlv03yHsg10VLPsLswRbXyKUuOAfj1 H3NFuAopXf8cV_rwXkyp8EOZBXapmVhqbHlFOnwk- Received: from [140.90.201.103] by web111402.mail.gq1.yahoo.com via HTTP; Thu, 01 Apr 2010 15:30:20 PDT X-Mailer: YahooMailClassic/10.0.8 YahooMailWebService/0.8.100.260964 Date: Thu, 1 Apr 2010 15:30:20 -0700 (PDT) From: Peter Thoenen To: freebsd-arch@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, Doug Barton In-Reply-To: <4BB51B5B.1050606@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Thu, 01 Apr 2010 23:08:24 +0000 Cc: Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 01 Apr 2010 22:57:01 -0000 May I only hope this is legit and not a April Fool's joke :) From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 03:35:28 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7CF71065670; Fri, 2 Apr 2010 03:35:28 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id AECFF8FC0C; Fri, 2 Apr 2010 03:35:28 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxXfL-000Ppn-VS; Fri, 02 Apr 2010 03:35:28 +0000 Date: Fri, 02 Apr 2010 12:35:24 +0900 Message-ID: From: Randy Bush To: freebsd-net , FreeBSD Current User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Subject: bridged wlan/ether still the same X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 03:35:28 -0000 i have a year old 8 soekris system i am about to upgrade. it is pppoe externally, and has a bridged natted wireless/ether internal net. .----------------. | | | b --wlan0| | r | 192.168.0.0/24 ext iij | i --- vr1| LAN hosts, PPP/NAT ---|vr0--- d | DHCP Clients WAN | g --- vr2| ... | e | | 0 --- vr3| | | `----------------' /etc/rc.conf ppp_enable=YES ppp_mode=dedicated ppp_nat=YES ppp_profile=iij hostapd_enable=YES wlans_ath0=wlan0 create_args_wlan0="wlanmode ap mode 11g channel 11 up" cloned_interfaces=bridge0 ifconfig_bridge0="192.168.0.1 addm vr1 addm vr2 addm vr3 addm wlan0 addm wlan1 up" ifconfig_vr1=up ifconfig_vr2=up ifconfig_vr3=up /etc/hostap.conf interface=wlan0 ctrl_interface=/var/run/hostapd logger_syslog=-1 logger_syslog_level=0 ssid=rgnet-crypt country_code=JP hw_mode=g wpa=2 wpa_key_mgmt=WPA-PSK wpa_passphrase=notreally wpa_pairwise=CCMP TKIP /etc/ppp/ppp.conf entry iij: set device PPPoE:vr0 set MRU 1454 # NTT suggests this value set MTU 1454 accept CHAP enable lqr add default HISADDR nat enable yes set authname nope set authkey peon is this still gonna work? is this a reasonable way to do this? i ask because, if it does not, i will not have usable connectivity to get help fixing it :) randy From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 03:48:42 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C3972106564A; Fri, 2 Apr 2010 03:48:42 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id AB7108FC08; Fri, 2 Apr 2010 03:48:42 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxXs8-000PsQ-Bp; Fri, 02 Apr 2010 03:48:40 +0000 Date: Fri, 02 Apr 2010 12:48:36 +0900 Message-ID: From: Randy Bush To: Peter Thoenen In-Reply-To: <328862.28246.qm@web111402.mail.gq1.yahoo.com> References: <4BB51B5B.1050606@FreeBSD.org> <328862.28246.qm@web111402.mail.gq1.yahoo.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Doug Barton , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 03:48:42 -0000 > May I only hope this is legit and not a April Fool's joke :) actually, as an unbound user, i would be quite happy to have bind removed. bloated, ever-buggy, config religion, ... randy From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 04:28:35 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 654CF106566C; Fri, 2 Apr 2010 04:28:35 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id B68018FC17; Fri, 2 Apr 2010 04:28:34 +0000 (UTC) Received: by gwaa20 with SMTP id a20so414236gwa.13 for ; Thu, 01 Apr 2010 21:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=cOkDSYpQKgb3Y35jZiCv3qFqOnUI6zT5VXY4qxkQ2hI=; b=NbkLBz7+2Hq4UkYV7JbNHvZ4e/ZLxqTEAPORRz3UyC36m/YLqYtEuprnWW58G/Pq3U D50AzolTQ5EvaMaYNDDn86ngmvMNKpnJO/2J9ZpeNJ9KYEXU+I0HQvBP/pkfObq3SFr9 XkfGFVmnnfyEkwMeISAP9H2KGVpcnPDw0149c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=g6DRsp3Xsf7u37im0kNtAoNa5PcSSFvop0rhQEwf5MUfojPCEBeMuke46vFaEngrAv HHjMrvygBEdsY55yyw8GRMsNwj/6m1C7aE/FV5HO5VF5YluDhmT+rGopdS+mBfdB9nVP 05vevPJX/Dj3Q4uY5tcDyLLJ15ZOEnXUgHwuA= Received: by 10.150.128.39 with SMTP id a39mr2099971ybd.257.1270182514035; Thu, 01 Apr 2010 21:28:34 -0700 (PDT) Received: from centel.dataix.local (adsl-99-181-143-247.dsl.klmzmi.sbcglobal.net [99.181.143.247]) by mx.google.com with ESMTPS id 21sm1437950iwn.11.2010.04.01.21.28.28 (version=SSLv3 cipher=RC4-MD5); Thu, 01 Apr 2010 21:28:32 -0700 (PDT) Sender: "J. Hellenthal" Message-ID: <4BB5724D.7080906@dataix.net> Date: Fri, 02 Apr 2010 00:27:57 -0400 From: jhell User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100331 Thunderbird/3.0.4 MIME-Version: 1.0 To: Randy Bush References: <4BB51B5B.1050606@FreeBSD.org> <328862.28246.qm@web111402.mail.gq1.yahoo.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Peter Thoenen , freebsd-arch@freebsd.org, Doug Barton , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 04:28:35 -0000 On 04/01/2010 23:48, Randy Bush wrote: >> May I only hope this is legit and not a April Fool's joke :) > > actually, as an unbound user, i would be quite happy to have bind > removed. bloated, ever-buggy, config religion, ... > > randy At least I hope that this will be removed and added to the distribution as a package upon release time. -- jhell From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 04:30:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0D831065678 for ; Fri, 2 Apr 2010 04:30:56 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 82B8B8FC1D for ; Fri, 2 Apr 2010 04:30:56 +0000 (UTC) Received: by pwi9 with SMTP id 9so1676562pwi.13 for ; Thu, 01 Apr 2010 21:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=toaziNlgzjDCLiXbIWdpvloRD98RjxLXhhOTHmGjrKw=; b=IneV/zKxRojhTFsWW7n9DUVyEIaQiwKNvdZHAHLqfcyZHvwrtTk9kq9U2094IzJjhe ijpACX2nLerkJ2M7fLcC/ITY8JJOdIcMYYjZsizHO+CGdmmSty+q3TYGycZ507NJN4aW z301QhUEIgywUoHVOyg1IaWtXmxh1RoKABSoM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=cF5gOSCsXttQC7J275p+71in7OSJSuswE2WuRUfUZb6MQbyoANpLhfo7P4f4TOg9Cf DpCdRRWXycA9bmKfHQqmZ5I1YT4f7xlkq2jWyHX8QbY63De0xMMWcbifYdMTmb62DuZI 8aewc7BMVYaawkyONhiML4LbOjwn5BJ+DgdQ8= MIME-Version: 1.0 Received: by 10.140.127.14 with HTTP; Thu, 1 Apr 2010 21:30:55 -0700 (PDT) In-Reply-To: <4BB4FB35.2040703@uffner.com> References: <4BA7E0B8.3080406@delphij.net> <4BAE2B4F.6060005@protected-networks.net> <4BB3FD5D.9070600@uffner.com> <4BB4FB35.2040703@uffner.com> Date: Thu, 1 Apr 2010 21:30:55 -0700 Received: by 10.141.213.23 with SMTP id p23mr1284582rvq.159.1270182655949; Thu, 01 Apr 2010 21:30:55 -0700 (PDT) Message-ID: From: Xin LI To: Tom Uffner Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 04:30:56 -0000 Hi, Tom, On Thu, Apr 1, 2010 at 12:59 PM, Tom Uffner wrote: [...] > i realize this. i was just adding to the list of ports that no longer > build after this change. ghostscript is kind of important for print > support. > > i doubt this is "right" either, but it is a quick & dirty way to > make mplayer compile again: > > --- configure.orig =C2=A0 =C2=A0 =C2=A02010-04-01 15:49:37.000000000 -040= 0 > +++ configure =C2=A0 2010-04-01 15:50:50.000000000 -0400 > @@ -5337,7 +5337,7 @@ > =C2=A0#include > =C2=A0int main(void) { return 0; } > =C2=A0EOF > - =C2=A0 =C2=A0cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=3D64 > -D_LARGEFILE64_SOURCE \ > + =C2=A0 =C2=A0cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=3D64 \ > =C2=A0 =C2=A0 =C2=A0 -ldvdread $_ld_dl && _dvdread=3Dyes && _res_comment= =3D"external" > =C2=A0 fi > =C2=A0fi > @@ -7412,8 +7412,6 @@ > =C2=A0if test "$_largefiles" =3D yes || freebsd ; then > =C2=A0 CFLAGS=3D"$CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=3D64" > =C2=A0 if test "$_dvdread" =3D yes || test "$_libdvdcss_internal" =3D yes= ; then > - =C2=A0 =C2=A0# dvdread support requires this (for off64_t) > - =C2=A0 =C2=A0CFLAGS=3D"$CFLAGS -D_LARGEFILE64_SOURCE" > =C2=A0 =C2=A0 cygwin && CFLAGS=3D"$CFLAGS -DSYS_CYGWIN" > =C2=A0 fi > =C2=A0fi Specifying -DFOO basically means in C code one have: %%% #define FOO 1 %%% This would not cause problem for zlib, at least not for zlib 1.2.4.1. However, defining it do cause *64 interfaces being included, the assumption doesn't seem right, according to my understanding of GNU libc's manual. I was wrong in a previous e-mail that it's not -D_LARGEFILE64_SOURCE itself being broken, but #define _LARGEFILE64_SOURCE broken if it's not defined as '1'. GNU libc seems to test whether this is defined, rather than testing it against '1' (zlib do this). So in conclusion: a) We actually face two different types of problems, one is defining _LARGEFILE64_SOURCE on FreeBSD, this is not right. It should not be defined at all; another is to have "#define _LARGEFILE64_SOURCE" instead of "#define _LARGEFILE64_SOURCE 1", this type would break not only on FreeBSD but perhaps some other platforms, unfortunately this seems to be common. Should one hit either case, please have it fixed by upstream developers, as it would benefit not only FreeBSD but also other platforms. b) For now I have implemented a temporary solution on -HEAD by unifdef'ing _LARGEFILE64_SOURCE, _LFS64_SOURCE on zlib.h and zconf.h, so ports may appear as "fixed". This is not ideal since it makes us to diverge away from zlib. A better solution is under discussion and this situation MAY change in the next import. Cheers, --=20 Xin LI http://www.delphij.net From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 05:24:13 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B6465106566B; Fri, 2 Apr 2010 05:24:13 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 356828FC08; Fri, 2 Apr 2010 05:24:13 +0000 (UTC) Received: from orion.SpringDaemons.com (unknown [99.48.191.9]) by mx0.deglitch.com (Postfix) with ESMTPA id 15E638FC4E; Fri, 2 Apr 2010 09:24:11 +0400 (MSD) Received: from orion (localhost [127.0.0.1]) by orion.SpringDaemons.com (Postfix) with SMTP id C8D423985D; Thu, 1 Apr 2010 22:24:09 -0700 (PDT) Date: Thu, 1 Apr 2010 22:24:04 -0700 From: Stanislav Sedov To: Doug Barton Message-Id: <20100401222404.77a14a02.stas@FreeBSD.org> In-Reply-To: <4BB51B5B.1050606@FreeBSD.org> References: <4BB51B5B.1050606@FreeBSD.org> Organization: The FreeBSD Project X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Thu__1_Apr_2010_22_24_04_-0700_JeELB8c2KyR9N.sP" Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 05:24:13 -0000 --Signature=_Thu__1_Apr_2010_22_24_04_-0700_JeELB8c2KyR9N.sP Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 01 Apr 2010 15:16:59 -0700 Doug Barton mentioned: >=20 > Of course this change will have some costs. Users of named who rely on > the current defaults will have some change management to deal with, > however the costs will be minimal. The one area that has come up > repeatedly in previous discussions about this topic is that users like > having access to the command line tools dig, host, and nslookup. To deal > with that issue I will be creating a bind-tools port so that those who > want just those tools can easily add them, without the overhead of the > rest of the BIND suite. If anyone has suggestions for other BIND tools > that should be included in the port, please let me know. Hey, Doug! While it certainly might make sense to drop BIND out of the base, I'm not sure dropping bind tools as well from it is the best decision. How hard it will be to continue maintaining bind tools inside the base (so the=20 critical ones like dig and nslookup still will be available), while moving the rest of it (the server itself and supporting tools) to the port? --=20 Stanislav Sedov ST4096-RIPE --Signature=_Thu__1_Apr_2010_22_24_04_-0700_JeELB8c2KyR9N.sP Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJLtX95AAoJEL8lojEJL9nwbJgQALOXVTF3xaj0lDVAsXtgFSWJ nYYts36/Msoe9AE8lTWoFnXsXfkLPaaqkcLOu7mGwBOIbbJ7ZfSY/KgTiUdEuha+ dXglF6dWmPfVO+ROZNtwE3MgCKdWR4o8/X/iAfyTKEf7L1exoRHdObLBUXQuYtmn 5mzORU84C6PkAyuJ6NIAs2A56yCmQv7L5fd3shDErkj5yMmF43dobnXBIeFPg8h2 Jo61HA6EhnZ4fvxcgPe9pkEAk2k2XQQYwY+aXVXGLHzuBI1P2WSFG48eB1eNG8cp 6rWMSirJrhKG7PzHSzVgUZ0PDWfQl9syRCJupNyAXHmP+f3dFguecvCmDADtnn3W js79ZkftYSHo++okUC1nXImh4ow8Z0RZ5xYAl4NYbgkAq7Pe3rMr5UADD/GwTM5w O/QRPRU4cPjBMAAANPyZXXSliuIk21CDbSL1Li/jI44Z+PJK/qSCGQxvZRsjgEnC C6HC4/dXT90NzHkNYUATlD9JjqCP92B89qikBA7nbbiq4uhcTUuvOMTcI8apAhj6 xT/Rr14BzCXTj1Ojr2HA4aCYc1PNdH4nVWDogiy9yIfopwEtTcUnz76UJRZXq8RA 2pWekU5uHjtk6IDfxfGXnDTM1HPKDk3mmiZU3nmojEnuG/0lvPHZ6suzEIE3X6fa 6A4HEP9NuTKm+ckCl+rj =J0FH -----END PGP SIGNATURE----- --Signature=_Thu__1_Apr_2010_22_24_04_-0700_JeELB8c2KyR9N.sP-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 06:24:55 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B96B31065678; Fri, 2 Apr 2010 06:24:55 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward4.mail.yandex.net (forward4.mail.yandex.net [77.88.46.9]) by mx1.freebsd.org (Postfix) with ESMTP id 65A3B8FC15; Fri, 2 Apr 2010 06:24:55 +0000 (UTC) Received: from smtp1.mail.yandex.net (smtp1.mail.yandex.net [77.88.46.101]) by forward4.mail.yandex.net (Yandex) with ESMTP id 586F36AD8D06; Fri, 2 Apr 2010 10:11:51 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1270188711; bh=38x1M9+CLJ3qnCE+MxigENr+80WlFwQlNSbQbiXm/00=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=rTaZxsKudMWs2bwQLDbjXD8HjKhmnvO5D+Yk5kyMT/WBstL6FDfl2Av4rTpa6IDAY 3MWKZQR3lcSKwMnzEfxZk5OFX8ZIr7RMWDQwGQz/JwQIDQj8ncL2Xq9SO15JtMLP0E yvJjmjSdxY7sjIwczWxuW0IS7hHdTHM2M/s1yuYY= Received: from [127.0.0.1] (ns.kirov.so-cdu.ru [77.72.136.145]) by smtp1.mail.yandex.net (Yandex) with ESMTPSA id 1002AE6006E; Fri, 2 Apr 2010 10:11:51 +0400 (MSD) Message-ID: <4BB58AA6.1040600@yandex.ru> Date: Fri, 02 Apr 2010 10:11:50 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Stanislav Sedov References: <4BB51B5B.1050606@FreeBSD.org> <20100401222404.77a14a02.stas@FreeBSD.org> In-Reply-To: <20100401222404.77a14a02.stas@FreeBSD.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit X-Yandex-TimeMark: 1270188711 X-Yandex-Spam: 1 X-Yandex-Front: smtp1.mail.yandex.net Cc: freebsd-current@FreeBSD.org, Doug Barton , freebsd-stable@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 06:24:55 -0000 On 02.04.2010 9:24, Stanislav Sedov wrote: > While it certainly might make sense to drop BIND out of the base, I'm not > sure dropping bind tools as well from it is the best decision. How hard > it will be to continue maintaining bind tools inside the base (so the > critical ones like dig and nslookup still will be available), while moving > the rest of it (the server itself and supporting tools) to the port? Hi, All. I'm agree with Stas. If it is not so hard to maintain "bind-tools" in the base, It is very useful to still having them in base system. -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 06:57:42 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4641D106566B for ; Fri, 2 Apr 2010 06:57:42 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id E68A88FC0A for ; Fri, 2 Apr 2010 06:57:41 +0000 (UTC) Received: from outgoing.leidinger.net (pD9E2CC21.dip.t-dialin.net [217.226.204.33]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id 896318442CC for ; Fri, 2 Apr 2010 08:57:37 +0200 (CEST) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 46FB75076 for ; Fri, 2 Apr 2010 08:57:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1270191454; bh=Y+Bh2AgXr4s8LTuw24XEct5gVlewVMvSZ2v9MzV6lrs=; h=Message-ID:Date:From:To:Subject:MIME-Version:Content-Type: Content-Transfer-Encoding; b=ZrOPCUxhb/XxAOo9ACazOrfHzngONfhrnMuF5M0QWwgnNUlUIIDCgSqLbFhdDGcd8 +ihNm8Jda32DNFrUePdcmjUqjd30uwIkapNHQ6bjnl295UZHLpsf5MnN0lVf3cMk6Z VawvBG3N8kFoQPapc1TBhhaAcJ0UDca3bGLHoV6pXwRF9/E6Fnt+fJWVTT34dgFK8P wOlzZjt6GPCaxbzalomw1bo1XzuznvtvumgXmmeDcRQle1qwgEnHvJlyG8w+n7NP4L 7Od8HNmGhGGmf9WJQEscfOy1PMuXV3T6+nR2U8+gbOOL95V6dQT+zxcLdqjz/nWbhX Vt6PYY7l9cs7A== Received: (from www@localhost) by webmail.leidinger.net (8.14.3/8.13.8/Submit) id o326vXxU075799 for current@FreeBSD.org; Fri, 2 Apr 2010 08:57:34 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 02 Apr 2010 08:57:33 +0200 Message-ID: <20100402085733.14716rpxuoqulxwc@webmail.leidinger.net> Date: Fri, 02 Apr 2010 08:57:33 +0200 From: Alexander Leidinger To: current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.4) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: 896318442CC.9642D X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.44, required 6, autolearn=disabled, ALL_TRUSTED -1.44, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1270796257.80242@mndMhi+TPdJYOjUadJamLw X-EBL-Spam-Status: No Cc: Subject: HEADS-UP: WITH_CTF now picked up from src.conf/make.conf/kernel-config X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 06:57:42 -0000 Hi, from r206082 on: $Subject Make sure to read UPDATING (short: make sure there is no WITH_CTF in src.conf or make.conf). Bye, Alexander. -- You will save yourself a lot of needless worry if you don't burn your bridges until you come to them. 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 Fri Apr 2 07:20:14 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F82F106564A for ; Fri, 2 Apr 2010 07:20:14 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 12F358FC14 for ; Fri, 2 Apr 2010 07:20:13 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so637951qwe.7 for ; Fri, 02 Apr 2010 00:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lF85M8ydz05fN131jFLp74/vx7wivYtI/ac9EZVqYdo=; b=ghjTR48+2reEscYtWks5KSkkF1x17Wp1YbBtclSnKBIL89UpK24Pd2szERskYuNoVD sjcAO48soEApUa4jCgA04+MNvajcQ0jLy2LY7qoCpFes76y3tthDJRSTVMpSun9xIvt1 FNcaS/C75HCnnBEvSIYnxNF+YfA+Ox9Hg2f6E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=AO1oRX0Qo4k58R7KNFQSBwP9qeJVu6tZOjfRVJlaKYwHH2NCiNgPFhd4AEUobeuAKG gNSPr+8Sf3YtX7fprRa6/B+ca1GUwFzp/6nYe7WGOWBUW+lItgYC2Nb5fgoLi5Y/4MDi 5vwpenKZB/AmBdD9dTsdMCQvg+ZdYziTTpB08= MIME-Version: 1.0 Received: by 10.229.33.72 with HTTP; Fri, 2 Apr 2010 00:20:12 -0700 (PDT) In-Reply-To: References: <4BA7E0B8.3080406@delphij.net> <4BAE2B4F.6060005@protected-networks.net> <4BB3FD5D.9070600@uffner.com> <4BB4FB35.2040703@uffner.com> Date: Fri, 2 Apr 2010 00:20:12 -0700 Received: by 10.229.221.78 with SMTP id ib14mr3119239qcb.28.1270192812805; Fri, 02 Apr 2010 00:20:12 -0700 (PDT) Message-ID: From: Garrett Cooper To: Xin LI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 07:20:14 -0000 On Thu, Apr 1, 2010 at 9:30 PM, Xin LI wrote: > Hi, Tom, > > On Thu, Apr 1, 2010 at 12:59 PM, Tom Uffner wrote: > [...] >> i realize this. i was just adding to the list of ports that no longer >> build after this change. ghostscript is kind of important for print >> support. >> >> i doubt this is "right" either, but it is a quick & dirty way to >> make mplayer compile again: >> >> --- configure.orig =A0 =A0 =A02010-04-01 15:49:37.000000000 -0400 >> +++ configure =A0 2010-04-01 15:50:50.000000000 -0400 >> @@ -5337,7 +5337,7 @@ >> =A0#include >> =A0int main(void) { return 0; } >> =A0EOF >> - =A0 =A0cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=3D64 >> -D_LARGEFILE64_SOURCE \ >> + =A0 =A0cc_check -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=3D64 \ >> =A0 =A0 =A0 -ldvdread $_ld_dl && _dvdread=3Dyes && _res_comment=3D"exter= nal" >> =A0 fi >> =A0fi >> @@ -7412,8 +7412,6 @@ >> =A0if test "$_largefiles" =3D yes || freebsd ; then >> =A0 CFLAGS=3D"$CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=3D64" >> =A0 if test "$_dvdread" =3D yes || test "$_libdvdcss_internal" =3D yes ;= then >> - =A0 =A0# dvdread support requires this (for off64_t) >> - =A0 =A0CFLAGS=3D"$CFLAGS -D_LARGEFILE64_SOURCE" >> =A0 =A0 cygwin && CFLAGS=3D"$CFLAGS -DSYS_CYGWIN" >> =A0 fi >> =A0fi > > Specifying -DFOO basically means in C code one have: > > %%% > #define FOO 1 > %%% Actually, `CFLAGS +=3D -DFOO=3D1' is different from `CFLAGS +=3D -DFOO' (I think Xin Li meant to state the former format). $ for i in -DBAR -DFOO -DFOO=3D1 -DFOO=3D2; do echo "$i"; cc -c $i test_defined.c; done -DBAR -DFOO test_defined.c:2:2: warning: #warning FOO is defined test_defined.c:6:2: warning: #warning FOO is 1 test_defined.c:10:2: warning: #warning FOO is non-zero -DFOO=3D1 test_defined.c:2:2: warning: #warning FOO is defined test_defined.c:6:2: warning: #warning FOO is 1 test_defined.c:10:2: warning: #warning FOO is non-zero -DFOO=3D2 test_defined.c:2:2: warning: #warning FOO is defined test_defined.c:10:2: warning: #warning FOO is non-zero $ cat test_defined.c #ifdef FOO #warning FOO is defined #endif #if FOO =3D=3D 1 #warning FOO is 1 #endif #if FOO #warning FOO is non-zero #endif [...] Thanks, -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 07:29:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2F4F106564A for ; Fri, 2 Apr 2010 07:29:57 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from mail-qy0-f199.google.com (mail-qy0-f199.google.com [209.85.221.199]) by mx1.freebsd.org (Postfix) with ESMTP id 8039F8FC14 for ; Fri, 2 Apr 2010 07:29:57 +0000 (UTC) Received: by qyk37 with SMTP id 37so2041788qyk.8 for ; Fri, 02 Apr 2010 00:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=h7oIDY+1UdMvDwnsJbgYTYHVccfpq1M8MW0HSHmkRzw=; b=PCMJxJ7lt7rFquep7Q0/kZshzyCLVZoc+J7xcw4ayxry4l9k6BUjTYVjLV5wdMH7oE QcC6KHffhm/sxNPIddvpm3VWKRrVDgBUMBW1aB7mzAo8Ep5HBN8sqQt7zVAabkYNNZte itrkLMHH/GjjN3qNjnukLnJE0Xo/2SSVaZZJo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=R6yAUUck+0cP6r2EVT8gG6M33XHpbzNmfznhnYwGN6Zu2nUc3Te0+vmCupJlfMHXfJ CPOdg3/Ib+mqRYH31vV/We9T0MM+SNx9nXIH21Is4vq8bmNx3MtLKBopBlR/+53VH9nk 1blsm/vNqoZUjbrokPicYHGmtjtxN+19zUoi4= Received: by 10.229.212.146 with SMTP id gs18mr3191105qcb.90.1270193396433; Fri, 02 Apr 2010 00:29:56 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id f5sm634743qcg.20.2010.04.02.00.29.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 00:29:55 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BB59CFC.90101@elischer.org> Date: Fri, 02 Apr 2010 00:30:04 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Randy Bush References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net , FreeBSD Current Subject: Re: bridged wlan/ether still the same X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 07:29:57 -0000 On 4/1/10 8:35 PM, Randy Bush wrote: > i have a year old 8 soekris system i am about to upgrade. it is pppoe > externally, and has a bridged natted wireless/ether internal net. > > .----------------. > | | > | b --wlan0| > | r | 192.168.0.0/24 > ext iij | i --- vr1| LAN hosts, > PPP/NAT ---|vr0--- d | DHCP Clients > WAN | g --- vr2| ... > | e | > | 0 --- vr3| > | | > `----------------' ok this is similar to my setup in some ways. but the picture is wrong, remember that vr0 is not (or at least should not be) part of the bridge. the real picture is: > .----------------------------------. > | | > | b --wlan0| > | r | 192.168.0.0/24 > ext iij | i --- vr1| LAN hosts, > PPP/NAT ---|vr0[PPPoE][ppp]tun0--[R]-d | DHCP Clients > WAN | g --- vr2| ... > | e | > | 0 --- vr3| > | | > `----------------------------------' where [R] is the IP forwarding code (i.e routing not bridging) > > /etc/rc.conf > > ppp_enable=YES > ppp_mode=dedicated > ppp_nat=YES > ppp_profile=iij my profile is pppoe which is shown below It's not completely different from yours but seems to work > hostapd_enable=YES > wlans_ath0=wlan0 > create_args_wlan0="wlanmode ap mode 11g channel 11 up" > cloned_interfaces=bridge0 > ifconfig_bridge0="192.168.0.1 addm vr1 addm vr2 addm vr3 addm wlan0 addm wlan1 up" I can't help you withthe bridge part but it should be ok I think. > ifconfig_vr1=up > ifconfig_vr2=up > ifconfig_vr3=up > > /etc/hostap.conf > > interface=wlan0 > ctrl_interface=/var/run/hostapd > logger_syslog=-1 > logger_syslog_level=0 > ssid=rgnet-crypt > country_code=JP > hw_mode=g > wpa=2 > wpa_key_mgmt=WPA-PSK > wpa_passphrase=notreally > wpa_pairwise=CCMP TKIP > > /etc/ppp/ppp.conf entry > > iij: > set device PPPoE:vr0 > set MRU 1454 # NTT suggests this value > set MTU 1454 > accept CHAP > enable lqr > add default HISADDR > nat enable yes > set authname nope > set authkey peon pppoe: set device PPPoE:vr1 set redial 10.3 10000 set speed 115200 #not really intersting set timeout 0 # Never time out disable dns disable ipv6cp disable sroutes set authname heyitsme set authkey really? set login enable lqr set ifaddr X.X.X.X/32 0.0.0.0/0 255.255.255.255 0.0.0.0 add default HISADDR # Add a (sticky) default route set cd 5 > > is this still gonna work? is this a reasonable way to do this? i ask > because, if it does not, i will not have usable connectivity to get help > fixing it :) > > randy > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 07:45:57 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 06BF01065672; Fri, 2 Apr 2010 07:45:57 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id E480B8FC13; Fri, 2 Apr 2010 07:45:56 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxbZj-0000S0-I3; Fri, 02 Apr 2010 07:45:55 +0000 Date: Fri, 02 Apr 2010 16:45:54 +0900 Message-ID: From: Randy Bush To: Julian Elischer In-Reply-To: <4BB59CFC.90101@elischer.org> References: <4BB59CFC.90101@elischer.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: FreeBSD Net , FreeBSD Current Subject: Re: bridged wlan/ether still the same X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 07:45:57 -0000 thanks! yep, i understood the stacks in from vr0 to the bridge. but yes, short-cutting the diagram was a bad. thanks for the fix. it's the bridge that worries me. took me a while to make it work randy From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 08:26:14 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB9FC106566C; Fri, 2 Apr 2010 08:26:14 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by mx1.freebsd.org (Postfix) with ESMTP id BE06F8FC16; Fri, 2 Apr 2010 08:26:14 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=rmac.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1NxcCk-0000YN-Gq; Fri, 02 Apr 2010 08:26:14 +0000 Date: Fri, 02 Apr 2010 17:26:13 +0900 Message-ID: From: Randy Bush To: Stanislav Sedov In-Reply-To: <20100401222404.77a14a02.stas@FreeBSD.org> References: <4BB51B5B.1050606@FreeBSD.org> <20100401222404.77a14a02.stas@FreeBSD.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: freebsd-current@FreeBSD.org, Doug Barton , freebsd-stable@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 08:26:15 -0000 > While it certainly might make sense to drop BIND out of the base, I'm not > sure dropping bind tools as well from it is the best decision. How hard > it will be to continue maintaining bind tools inside the base (so the > critical ones like dig and nslookup still will be available), while moving > the rest of it (the server itself and supporting tools) to the port? i don't mind if dig, doc, et alia are not in base, as long as they are a separate port from the bind hippo. randy From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 08:32:30 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4CF811065717; Fri, 2 Apr 2010 08:32:30 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 886228FC1D; Fri, 2 Apr 2010 08:32:29 +0000 (UTC) Received: from sputnik.SpringDaemons.com (c-67-188-12-68.hsd1.ca.comcast.net [67.188.12.68]) by mx0.deglitch.com (Postfix) with ESMTPA id 7F7708FC4E; Fri, 2 Apr 2010 12:32:26 +0400 (MSD) Received: from sputnik.SpringDaemons.com (localhost [127.0.0.1]) by sputnik.SpringDaemons.com (Postfix) with SMTP id 53E76B874; Fri, 2 Apr 2010 01:33:54 -0700 (PDT) Date: Fri, 2 Apr 2010 01:33:53 -0700 From: Stanislav Sedov To: Randy Bush Message-Id: <20100402013353.f544e8ad.stas@FreeBSD.org> In-Reply-To: References: <4BB51B5B.1050606@FreeBSD.org> <20100401222404.77a14a02.stas@FreeBSD.org> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprin: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Doug Barton , freebsd-stable@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 08:32:30 -0000 On Fri, 02 Apr 2010 17:26:13 +0900 Randy Bush mentioned: > > i don't mind if dig, doc, et alia are not in base, as long as they are a > separate port from the bind hippo. > The major benefit of having them in the base is the ability to cross-compile them when building the distribution for another platform. Ports doesn't support cross-compilation yet, and it would be a pity to find yourself bootstrapping another tiny arm platform and having to use ports to have a usable system. -- Stanislav Sedov ST4096-RIPE From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 08:46:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB7E0106564A for ; Fri, 2 Apr 2010 08:46:41 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (lefty.soaustin.net [66.135.55.46]) by mx1.freebsd.org (Postfix) with ESMTP id 8AEBC8FC19 for ; Fri, 2 Apr 2010 08:46:41 +0000 (UTC) Received: by mail.soaustin.net (Postfix, from userid 502) id D82B58C0B4; Fri, 2 Apr 2010 03:46:40 -0500 (CDT) Date: Fri, 2 Apr 2010 03:46:40 -0500 From: Mark Linimon To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20100402084640.GB19647@lonesome.com> References: <4BA7E0B8.3080406@delphij.net> <4BAE2B4F.6060005@protected-networks.net> <4BB3FD5D.9070600@uffner.com> <86tyrvs3js.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <86tyrvs3js.fsf@ds4.des.no> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 08:46:41 -0000 On Thu, Apr 01, 2010 at 03:30:47PM +0200, Dag-Erling Smørgrav wrote: > And yes, I *will* keep harping on this until people Get It. You're harping at the wrong people. Complain to the application authors, not to the poor slobs trying to maintain the ports collection. There's a lot of crap code out there on the internet. If we want to insist that all the application authors both a) write good code and that b) understands how FreeBSD does things, well, we can do that, but it's not going to have much effect. Probably 75%+ of the application authors neither know nor care that their code is being run on anything other than Linux. In extreme cases we've enountered authors who outright refuse to accept our patches, either due to philosophical disagreement or just due to the xtra hassle. I'd just be happy if we could keep what we have working, without "surprise" regressions. I'm not going to get in the business of trying to preach to the application authors. Feel free. mcl From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 08:55:10 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 53193106566C; Fri, 2 Apr 2010 08:55:10 +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 F33668FC1A; Fri, 2 Apr 2010 08:55:08 +0000 (UTC) Received: from critter.freebsd.dk (critter-phk.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id C5C28647F; Fri, 2 Apr 2010 08:55:07 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id o328t7dA011352; Fri, 2 Apr 2010 08:55:07 GMT (envelope-from phk@critter.freebsd.dk) To: Stanislav Sedov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 02 Apr 2010 01:33:53 MST." <20100402013353.f544e8ad.stas@FreeBSD.org> Date: Fri, 02 Apr 2010 08:55:07 +0000 Message-ID: <11351.1270198507@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Randy Bush , freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org, Doug Barton , freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 08:55:10 -0000 In message <20100402013353.f544e8ad.stas@FreeBSD.org>, Stanislav Sedov writes: >On Fri, 02 Apr 2010 17:26:13 +0900 >Randy Bush mentioned: >Ports doesn't support cross-compilation yet, >and it would be a pity to find yourself >bootstrapping another tiny arm platform and >having to use ports to have a usable system. The result of the RFC was that bind is not a mandatory component to make "a usable system", so you argument suffers from bad logic. The fact that you want BIND on your arm, is no different from somebody else wanting postfix on a MIPS. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 09:15:50 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 905391065674; Fri, 2 Apr 2010 09:15:50 +0000 (UTC) (envelope-from stas@FreeBSD.org) Received: from mx0.deglitch.com (backbone.deglitch.com [IPv6:2001:16d8:fffb:4::abba]) by mx1.freebsd.org (Postfix) with ESMTP id 42CDC8FC0C; Fri, 2 Apr 2010 09:15:50 +0000 (UTC) Received: from sputnik.SpringDaemons.com (c-67-188-12-68.hsd1.ca.comcast.net [67.188.12.68]) by mx0.deglitch.com (Postfix) with ESMTPA id 639EF8FC4E; Fri, 2 Apr 2010 13:15:48 +0400 (MSD) Received: from sputnik.SpringDaemons.com (localhost [127.0.0.1]) by sputnik.SpringDaemons.com (Postfix) with SMTP id 0FE17B874; Fri, 2 Apr 2010 02:17:16 -0700 (PDT) Date: Fri, 2 Apr 2010 02:17:15 -0700 From: Stanislav Sedov To: "Poul-Henning Kamp" Message-Id: <20100402021715.669838e0.stas@FreeBSD.org> In-Reply-To: <11351.1270198507@critter.freebsd.dk> References: <20100402013353.f544e8ad.stas@FreeBSD.org> <11351.1270198507@critter.freebsd.dk> Organization: The FreeBSD Project X-XMPP: ssedov@jabber.ru X-Voice: +7 916 849 20 23 X-PGP-Fingerprin: F21E D6CC 5626 9609 6CE2 A385 2BF5 5993 EB26 9581 X-Mailer: carrier-pigeon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Randy Bush , freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org, Doug Barton , freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 09:15:50 -0000 On Fri, 02 Apr 2010 08:55:07 +0000 "Poul-Henning Kamp" mentioned: > In message <20100402013353.f544e8ad.stas@FreeBSD.org>, Stanislav Sedov writes: > >On Fri, 02 Apr 2010 17:26:13 +0900 > >Randy Bush mentioned: > > >Ports doesn't support cross-compilation yet, > >and it would be a pity to find yourself > >bootstrapping another tiny arm platform and > >having to use ports to have a usable system. > > The result of the RFC was that bind is not a mandatory component > to make "a usable system", so you argument suffers from bad logic. > > The fact that you want BIND on your arm, is no different from > somebody else wanting postfix on a MIPS. Sorry, I think I was not clear enough. What I actually want is to have a couple of the important tools in the base while moving everything also in ports. By important tools I mean nslookup (and maybe dig), and at least the first one is cruicial for the system bringup. That one is also nice to have on the livecd, which currently includes (I believe) only the base system. -- Stanislav Sedov ST4096-RIPE From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 09:24:53 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5668106566B; Fri, 2 Apr 2010 09:24:53 +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 91DF48FC19; Fri, 2 Apr 2010 09:24:53 +0000 (UTC) Received: from critter.freebsd.dk (critter-phk.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 57D5C6445; Fri, 2 Apr 2010 09:24:52 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.3/8.14.3) with ESMTP id o329OpiN011598; Fri, 2 Apr 2010 09:24:52 GMT (envelope-from phk@critter.freebsd.dk) To: Stanislav Sedov From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 02 Apr 2010 02:17:15 MST." <20100402021715.669838e0.stas@FreeBSD.org> Date: Fri, 02 Apr 2010 09:24:51 +0000 Message-ID: <11597.1270200291@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Randy Bush , freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, Doug Barton , freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 09:24:53 -0000 In message <20100402021715.669838e0.stas@FreeBSD.org>, Stanislav Sedov writes: >On Fri, 02 Apr 2010 08:55:07 +0000 >"Poul-Henning Kamp" mentioned: >Sorry, I think I was not clear enough. Sorry for misunderstanding. Yes, the case can certainly be made that DNS query tool belongs in the base system. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 10:47:17 2010 Return-Path: Delivered-To: current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4EB54106564A for ; Fri, 2 Apr 2010 10:47:17 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 293328FC0A for ; Fri, 2 Apr 2010 10:47:17 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id BB10646B03; Fri, 2 Apr 2010 06:47:16 -0400 (EDT) Date: Fri, 2 Apr 2010 11:47:16 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Leidinger In-Reply-To: <20100402085733.14716rpxuoqulxwc@webmail.leidinger.net> Message-ID: References: <20100402085733.14716rpxuoqulxwc@webmail.leidinger.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: HEADS-UP: WITH_CTF now picked up from src.conf/make.conf/kernel-config X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 10:47:17 -0000 On Fri, 2 Apr 2010, Alexander Leidinger wrote: > from r206082 on: $Subject > > Make sure to read UPDATING (short: make sure there is no WITH_CTF in > src.conf or make.conf). Once any fallout from this has sorted itself out, assuming no serious objections, and pending appropriate make universe foo, I think a reasonable plan would be to enable options KDTRACE_HOOKS and WITH_CTF for GENERIC in mid-April. While there are known issues with DTrace completeness and stability, providing automatic access to it on supported architectures would make it much more accessible, as well as encourage the writing and use of monitoring and debugging tools that depend on its availability. If anyone has serious concerns about this idea, drop me an e-mail. Robert From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 10:52:21 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EE2C10656C1; Fri, 2 Apr 2010 10:52:21 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id EBBBD8FC13; Fri, 2 Apr 2010 10:52:20 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 857C646B2C; Fri, 2 Apr 2010 06:52:20 -0400 (EDT) Date: Fri, 2 Apr 2010 11:52:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Poul-Henning Kamp In-Reply-To: <11351.1270198507@critter.freebsd.dk> Message-ID: References: <11351.1270198507@critter.freebsd.dk> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Randy Bush , Doug Barton , freebsd-stable@FreeBSD.org, Stanislav Sedov , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 10:52:21 -0000 On Fri, 2 Apr 2010, Poul-Henning Kamp wrote: > The result of the RFC was that bind is not a mandatory component to make "a > usable system", so you argument suffers from bad logic. With an eye on the date of Doug's suggestive e-mail, I actually am concerned that we maintain support for DNSSEC validation in the base system. If this can be accomplished by keeping DNS debugging tools and the lightweight resolver in the base, then I'm fine with that world view. However, if we can't do DNSSEC record validation without installing the BIND package, then that worries me. As we go forward, DNSSEC is going to become increasingly important, and being unable to bootstrap a system will be a problem, and it will become an increasingly critical part of the security bootstrap process for networked systems. While some DNSSEC folk consider it anathema ("DNS is not a directory service!"), the ability to securely distribute keying material via an existing network service has enourmous value: for example, early DNSSEC prototypes in the late 1990's/early 2000's included SSH key distribution via cert records in DNSSEC. Similarly, as proposals to tie DHCP security and mobility security to DNSSEC expand, any decision to require a package to do DNSSEC would mean any component depending on that also has to be outside our base. If all requirements along these lines are met by the lightweight resolver, then this is less of a concern. Robert From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 10:54:45 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6043A1065673 for ; Fri, 2 Apr 2010 10:54:45 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-qy0-f199.google.com (mail-qy0-f199.google.com [209.85.221.199]) by mx1.freebsd.org (Postfix) with ESMTP id 15B528FC17 for ; Fri, 2 Apr 2010 10:54:44 +0000 (UTC) Received: by qyk37 with SMTP id 37so2130897qyk.8 for ; Fri, 02 Apr 2010 03:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:x-mailer:subject :mime-version:date; bh=3lj+V0EoBgrhV/XZd8lTdHPn1zcYwyDKklOAXog+/EE=; b=IpVagN76StlGGoCssosVrzzLueJTiTlWsFfE95yfN1cel5WCtwc5UN5+KJJAFD3jjS 0O2VWffX99hm2KKj39XffxIgXmJUsOqGb4uNGkjRv7/qCEg/X5/RUama/lxXnnkD23ue 9zRp5Jj0F0hl1lU3DHIrjQFjte2ko/LfN4BMk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding:x-mailer :subject:mime-version:date; b=ZlJN4x4qZTIqkT+gCIpurKpW1bbxPjDonifl8n7U9sWChLqUTA6XBopQyl3DXnUrST wF+fj6Dfox4FzmYOhBpqV/q941O4+EGyiQsdtioH9s3+Br1BCVDZc4qp0BeK8CT6whEI 0KH+hN5FsDRQsEn4DAohK/bHRwX1rWtrmueBk= Received: by 10.229.225.73 with SMTP id ir9mr3348694qcb.22.1270204143275; Fri, 02 Apr 2010 03:29:03 -0700 (PDT) Received: from [192.168.0.7] ([72.14.241.36]) by mx.google.com with ESMTPS id 20sm4788919qyk.12.2010.04.02.03.29.01 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 03:29:02 -0700 (PDT) Message-Id: From: Arseny Nasokin To: FreeBSD Mail Lists Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Fri, 2 Apr 2010 14:29:03 +0400 Subject: eeemon(4) 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, 02 Apr 2010 10:54:45 -0000 Will be this device in current ? Or there is alternative for it? Svn path repo: http://svn.freebsd.org/base/user/rpaulo/eeemon/ -- Arseny From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 10:55:18 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55E4810656A9 for ; Fri, 2 Apr 2010 10:55:18 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id 84EE68FC1E for ; Fri, 2 Apr 2010 10:55:17 +0000 (UTC) Received: (qmail 8369 invoked from network); 2 Apr 2010 10:28:36 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 2 Apr 2010 10:28:36 -0000 Date: Fri, 02 Apr 2010 12:28:36 +0200 (CEST) Message-Id: <20100402.122836.41723967.sthaug@nethelp.no> To: freebsd@jdc.parodius.com From: sthaug@nethelp.no In-Reply-To: <20100402101454.GA62089@icarus.home.lan> References: <20100402021715.669838e0.stas@FreeBSD.org> <11597.1270200291@critter.freebsd.dk> <20100402101454.GA62089@icarus.home.lan> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: stas@FreeBSD.org, dougb@FreeBSD.org, freebsd-stable@FreeBSD.org, randy@psg.com, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 10:55:18 -0000 > [1]: FreeBSD really needs to move away from the "base system" as a > concept, as I've ranted about in the past. Strongly disagree. > Or if it cannot, the "base > system" needs to start using pkg_* (somehow) for use, and src.conf > WITHOUT_xxx (where xxx = some software) removed. Concept being: "I > don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; > pkg_delete base-lib32". Beautiful concept, hard to implement due to > libraries being yanked out from underneathe binaries that are linked to > them. But you get the idea. This *might* be workable. However, in general - a large part of the reason why I use FreeBSD is that the FreeBSD base system gives me most of what I want, in *one* well defined chunk, *without* having to install a zillion extra packages, and without umpteen different versions of config files and locations for the important information. So please don't destroy this. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 10:57:34 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB7241065672; Fri, 2 Apr 2010 10:57:34 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.31.28]) by mx1.freebsd.org (Postfix) with ESMTP id 76EC08FC2A; Fri, 2 Apr 2010 10:57:34 +0000 (UTC) Received: from [78.34.138.217] (helo=r500.local) by smtprelay01.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1NxeZ8-0000LQ-4F; Fri, 02 Apr 2010 12:57:30 +0200 Date: Fri, 2 Apr 2010 12:57:21 +0200 From: Fabian Keil To: Andriy Gapon Message-ID: <20100402125721.50b3ba4f@r500.local> In-Reply-To: <4BB360A1.7020309@freebsd.org> References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <3a142e751003191021p141af009m6acf7d160c890cbb@mail.gmail.com> <20100319191133.46fe271c@r500.local> <3a142e751003191126j331e525fwb9e5573bbf6f7d58@mail.gmail.com> <4BAA30CB.1070707@icyb.net.ua> <20100328172537.501ed3d1@r500.local> <4BB0A053.9060007@freebsd.org> <20100329222920.5eef6395@r500.local> <4BB111D4.8060809@freebsd.org> <20100330173637.202b4b1e@r500.local> <4BB21BBA.7030407@freebsd.org> <4BB360A1.7020309@freebsd.org> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/o/kR2pAzI.De4I0myI6/YxS"; protocol="application/pgp-signature" X-Df-Sender: 775067 Cc: Kostik Belousov , freebsd-current@freebsd.org, Bruce Evans Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 10:57:35 -0000 --Sig_/o/kR2pAzI.De4I0myI6/YxS Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Andriy Gapon wrote: > on 30/03/2010 18:41 Andriy Gapon said the following: > > on 30/03/2010 18:36 Fabian Keil said the following: > >> Andriy Gapon wrote: > >> > >>> on 29/03/2010 23:29 Fabian Keil said the following: > >>>> Andriy Gapon wrote: > >>>>> Thus, clearly, it is a fault of a tool that formatted the media > >>>>> for FAT. It should have picked correct values, or rejected > >>>>> incorrect values if those were provided as overrides via command > >>>>> line options. > >>>> The kernel still shouldn't panic, though. > >>> A quick reply to this point only - yes, I completely agree. > >>> But remember that the panic happened only after the sources were > >>> modified :) > >> It wasn't clear from my message, but I was mainly referring to the > >> division-by-zero panic mentioned at the beginning of the thread, > >> for which I posted a work-around in > >> <20100319191133.46fe271c@r500.local>. > >=20 > > Oh, yes, right. >=20 > To clarify - I already forgot that the original problem was division by > zero panic and for some reason thought that it was EINVAL. >=20 > Anyways, here is a patch that I would use. > Unfortunately, ENOTIME to understand newfs_msdos code and fix it too, >=20 > --- a/sys/fs/msdosfs/msdosfs_vfsops.c > +++ b/sys/fs/msdosfs/msdosfs_vfsops.c > @@ -580,6 +580,7 @@ mountmsdosfs(struct vnode *devvp, struct mount *mp) > || (pmp->pm_BytesPerSec & (pmp->pm_BytesPerSec - 1)) > || (pmp->pm_HugeSectors =3D=3D 0) > || (pmp->pm_FATsecs =3D=3D 0) > + || (SecPerClust * pmp->pm_BlkPerSec > MAXBSIZE / DEV_BSIZE) > ) { > error =3D EINVAL; > goto error_exit; That works, too: fk@r500 ~ $sudo mdconfig -a -t vnode -f /tank/ipod-image-formatiert md0 fk@r500 ~ $sudo mount_msdosfs /dev/md0 /mnt/ mount_msdosfs: /dev/md0: Invalid argument Is there a chance that this, or some other workaround, could be committed? Fabian --Sig_/o/kR2pAzI.De4I0myI6/YxS Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAku1zZkACgkQBYqIVf93VJ0rngCfW1moJAdVxsBXDk/MqvoaPVMk hAUAnjlIrt+LWKhTO0PHnclwp/oBfQYD =L5dg -----END PGP SIGNATURE----- --Sig_/o/kR2pAzI.De4I0myI6/YxS-- From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 11:09:36 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5E274106564A for ; Fri, 2 Apr 2010 11:09:36 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 9B17B8FC1C for ; Fri, 2 Apr 2010 11:09:35 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA29231; Fri, 02 Apr 2010 14:09:33 +0300 (EEST) (envelope-from avg@freebsd.org) Message-ID: <4BB5D06C.8080902@freebsd.org> Date: Fri, 02 Apr 2010 14:09:32 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: Fabian Keil References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <3a142e751003191021p141af009m6acf7d160c890cbb@mail.gmail.com> <20100319191133.46fe271c@r500.local> <3a142e751003191126j331e525fwb9e5573bbf6f7d58@mail.gmail.com> <4BAA30CB.1070707@icyb.net.ua> <20100328172537.501ed3d1@r500.local> <4BB0A053.9060007@freebsd.org> <20100329222920.5eef6395@r500.local> <4BB111D4.8060809@freebsd.org> <20100330173637.202b4b1e@r500.local> <4BB21BBA.7030407@freebsd.org> <4BB360A1.7020309@freebsd.org> <20100402125721.50b3ba4f@r500.local> In-Reply-To: <20100402125721.50b3ba4f@r500.local> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-current@freebsd.org, Bruce Evans Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 11:09:36 -0000 on 02/04/2010 13:57 Fabian Keil said the following: > Andriy Gapon wrote: >> Anyways, here is a patch that I would use. >> Unfortunately, ENOTIME to understand newfs_msdos code and fix it too, >> >> --- a/sys/fs/msdosfs/msdosfs_vfsops.c >> +++ b/sys/fs/msdosfs/msdosfs_vfsops.c >> @@ -580,6 +580,7 @@ mountmsdosfs(struct vnode *devvp, struct mount *mp) >> || (pmp->pm_BytesPerSec & (pmp->pm_BytesPerSec - 1)) >> || (pmp->pm_HugeSectors == 0) >> || (pmp->pm_FATsecs == 0) >> + || (SecPerClust * pmp->pm_BlkPerSec > MAXBSIZE / DEV_BSIZE) >> ) { >> error = EINVAL; >> goto error_exit; > > That works, too: > > fk@r500 ~ $sudo mdconfig -a -t vnode -f /tank/ipod-image-formatiert > md0 > fk@r500 ~ $sudo mount_msdosfs /dev/md0 /mnt/ > mount_msdosfs: /dev/md0: Invalid argument > > Is there a chance that this, or some other workaround, could be committed? Yes, there is 99.99% chance of this happening :-) Now, if someone could fix newfs_msdos issue too. I could easily reproduce it this way: $ truncate -s 5G test.img $ mdconfig -a -t vnode -f test.img -S 2048 -u 0 $ newfs_msdos -F 32 /dev/md0 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 11:14:53 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2245B1065677 for ; Fri, 2 Apr 2010 11:14:53 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id D613F8FC12 for ; Fri, 2 Apr 2010 11:14:52 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id E6CA81FFC22; Fri, 2 Apr 2010 11:14:51 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id A31A8844A8; Fri, 2 Apr 2010 13:14:51 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mark Linimon References: <4BA7E0B8.3080406@delphij.net> <4BAE2B4F.6060005@protected-networks.net> <4BB3FD5D.9070600@uffner.com> <86tyrvs3js.fsf@ds4.des.no> <20100402084640.GB19647@lonesome.com> Date: Fri, 02 Apr 2010 13:14:51 +0200 In-Reply-To: <20100402084640.GB19647@lonesome.com> (Mark Linimon's message of "Fri, 2 Apr 2010 03:46:40 -0500") Message-ID: <86r5myp0lw.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 11:14:53 -0000 Mark Linimon writes: > Probably 75%+ of the application authors neither know nor care that > their code is being run on anything other than Linux. I think you missed the bit where what they're doing is wrong on Linux, too. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 11:15:49 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C4A871065676 for ; Fri, 2 Apr 2010 11:15:49 +0000 (UTC) (envelope-from erikt@midgard.homeip.net) Received: from ch-smtp03.sth.basefarm.net (ch-smtp03.sth.basefarm.net [80.76.149.214]) by mx1.freebsd.org (Postfix) with ESMTP id 78C7A8FC0A for ; Fri, 2 Apr 2010 11:15:49 +0000 (UTC) Received: from c83-255-48-78.bredband.comhem.se ([83.255.48.78]:63529 helo=falcon.midgard.homeip.net) by ch-smtp03.sth.basefarm.net with esmtp (Exim 4.68) (envelope-from ) id 1Nxepb-0000Dw-Az for freebsd-current@FreeBSD.org; Fri, 02 Apr 2010 13:14:33 +0200 Received: (qmail 54994 invoked from network); 2 Apr 2010 13:14:30 +0200 Received: from owl.midgard.homeip.net (10.1.5.7) by falcon.midgard.homeip.net with ESMTP; 2 Apr 2010 13:14:30 +0200 Received: (qmail 1743 invoked by uid 1001); 2 Apr 2010 13:14:30 +0200 Date: Fri, 2 Apr 2010 13:14:30 +0200 From: Erik Trulsson To: Jeremy Chadwick Message-ID: <20100402111430.GA1706@owl.midgard.homeip.net> References: <20100402021715.669838e0.stas@FreeBSD.org> <11597.1270200291@critter.freebsd.dk> <20100402101454.GA62089@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100402101454.GA62089@icarus.home.lan> User-Agent: Mutt/1.5.20 (2009-06-14) X-Originating-IP: 83.255.48.78 X-Scan-Result: No virus found in message 1Nxepb-0000Dw-Az. X-Scan-Signature: ch-smtp03.sth.basefarm.net 1Nxepb-0000Dw-Az fecd120a8970fb6f7ff4c27ed7384b55 Cc: Stanislav Sedov , Doug Barton , freebsd-stable@FreeBSD.org, Randy Bush , Poul-Henning Kamp , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 11:15:49 -0000 On Fri, Apr 02, 2010 at 03:14:54AM -0700, Jeremy Chadwick wrote: > > [1]: FreeBSD really needs to move away from the "base system" as a > concept, as I've ranted about in the past. Or if it cannot, the "base > system" needs to start using pkg_* (somehow) No, it does not need to do that. It might be a good idea (but I am far from convinced of it), but there most certainly is no *need* to move in that direction. -- Erik Trulsson ertr1013@student.uu.se From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 11:16:57 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 45F5F1065677; Fri, 2 Apr 2010 11:16:57 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from www.liukuma.net (www.liukuma.net [62.220.235.15]) by mx1.freebsd.org (Postfix) with ESMTP id E95B98FC29; Fri, 2 Apr 2010 11:16:56 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by www.liukuma.net (Postfix) with ESMTP id B4FC11CC60; Fri, 2 Apr 2010 14:01:48 +0300 (EEST) X-Virus-Scanned: amavisd-new at liukuma.net Received: from www.liukuma.net ([127.0.0.1]) by localhost (www.liukuma.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id TOrv0FCxeh39; Fri, 2 Apr 2010 14:01:46 +0300 (EEST) Received: from rivendell (a91-155-174-194.elisa-laajakaista.fi [91.155.174.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ignatz@www.liukuma.net) by www.liukuma.net (Postfix) with ESMTPSA id 256391CC5D; Fri, 2 Apr 2010 14:01:44 +0300 (EEST) Message-ID: From: "Reko Turja" To: References: <20100402021715.669838e0.stas@FreeBSD.org><11597.1270200291@critter.freebsd.dk><20100402101454.GA62089@icarus.home.lan> <20100402.122836.41723967.sthaug@nethelp.no> In-Reply-To: <20100402.122836.41723967.sthaug@nethelp.no> Date: Fri, 2 Apr 2010 14:01:57 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-7"; reply-type=original Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: freebsd-current@FreeBSD.org, dougb@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 11:16:57 -0000 +AD4- Strongly disagree. +AD4- +AD4APg- Or if it cannot, the +ACI-base +AD4APg- system+ACI- needs to start using pkg+AF8AKg- (somehow) for use, = and src.conf +AD4APg- WITHOUT+AF8-xxx (where xxx +AD0- some software) removed. = Concept being: +ACI-I +AD4APg- don't need Kerberos+ADs- pkg+AF8-delete base-krb5. I also = don't need=20 +AD4APg- lib32+ADs- +AD4APg- pkg+AF8-delete base-lib32+ACI-. Beautiful concept, hard to = implement due=20 +AD4APg- to +AD4APg- libraries being yanked out from underneathe binaries that are=20 +AD4APg- linked to +AD4APg- them. But you get the idea. +AD4- +AD4- This +ACo-might+ACo- be workable. However, in general - a large = part of the +AD4- reason why I use FreeBSD is that the FreeBSD base system gives me +AD4- most of what I want, in +ACo-one+ACo- well defined chunk, = +ACo-without+ACo- having +AD4- to install a zillion extra packages, and without umpteen different +AD4- versions of config files and locations for the important=20 +AD4- information. me +-1 If I wanted to go Gnu/BSD (or Loonix) route, I'd already installed=20 either thank you. Funny though that BIND which is pretty=20 straightforward as configuration goes and as much essential system=20 component as Sendmail is getting the axe. I thought one of the main=20 philosophies in FreeBSD always was being a system in itself, rather=20 than kernel with some haphazardly thrown in components added. -Reko=20 From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 10:28:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB4DF1065672 for ; Fri, 2 Apr 2010 10:28:06 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 905C68FC1A for ; Fri, 2 Apr 2010 10:28:06 +0000 (UTC) Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51]) by qmta01.emeryville.ca.mail.comcast.net with comcast id 0aDM1e00116AWCUA1aEwxk; Fri, 02 Apr 2010 10:14:56 +0000 Received: from koitsu.dyndns.org ([98.248.46.159]) by omta06.emeryville.ca.mail.comcast.net with comcast id 0aEv1e0013S48mS8SaEvne; Fri, 02 Apr 2010 10:14:56 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 5436B9B419; Fri, 2 Apr 2010 03:14:54 -0700 (PDT) Date: Fri, 2 Apr 2010 03:14:54 -0700 From: Jeremy Chadwick To: Poul-Henning Kamp Message-ID: <20100402101454.GA62089@icarus.home.lan> References: <20100402021715.669838e0.stas@FreeBSD.org> <11597.1270200291@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11597.1270200291@critter.freebsd.dk> User-Agent: Mutt/1.5.20 (2009-06-14) X-Mailman-Approved-At: Fri, 02 Apr 2010 11:18:55 +0000 Cc: Randy Bush , Doug Barton , freebsd-stable@FreeBSD.org, Stanislav Sedov , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 10:28:06 -0000 On Fri, Apr 02, 2010 at 09:24:51AM +0000, Poul-Henning Kamp wrote: > In message <20100402021715.669838e0.stas@FreeBSD.org>, Stanislav Sedov writes: > >On Fri, 02 Apr 2010 08:55:07 +0000 > >"Poul-Henning Kamp" mentioned: > > >Sorry, I think I was not clear enough. > > Sorry for misunderstanding. > > Yes, the case can certainly be made that DNS query tool belongs in the > base system. I disagree (so what else is new?) It should be kept out of the base system. KISS: Doug pulling BIND out of the base system / going ports-only = excellent. Doug making a separate port for BIND-esque DNS query/maintenance tools = excellent. Both of the above can be made into packages. Vendors who use FreeBSD can incorporate said package(s) into their build infrastructure. Folks who do not have Internet connections (yet for some reason want said DNS tools) can install the package(s) from CD/DVD/USB. I want the bikeshed to be black. :-) [1]: FreeBSD really needs to move away from the "base system" as a concept, as I've ranted about in the past. Or if it cannot, the "base system" needs to start using pkg_* (somehow) for use, and src.conf WITHOUT_xxx (where xxx = some software) removed. Concept being: "I don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; pkg_delete base-lib32". Beautiful concept, hard to implement due to libraries being yanked out from underneathe binaries that are linked to them. But you get the idea. -- | Jeremy Chadwick jdc@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 11:45:48 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7BF94106564A; Fri, 2 Apr 2010 11:45:48 +0000 (UTC) (envelope-from dennylin93@hs.ntnu.edu.tw) Received: from mail.hs.ntnu.edu.tw (mail.hs.ntnu.edu.tw [140.131.149.3]) by mx1.freebsd.org (Postfix) with ESMTP id 483628FC16; Fri, 2 Apr 2010 11:45:48 +0000 (UTC) Received: by mail.hs.ntnu.edu.tw (Postfix, from userid 1001) id 0BD964B7826; Fri, 2 Apr 2010 19:27:37 +0800 (CST) Date: Fri, 2 Apr 2010 19:27:36 +0800 From: Denny Lin To: "Andrey V. Elsukov" Message-ID: <20100402112736.GB4611@mail.hs.ntnu.edu.tw> References: <4BB51B5B.1050606@FreeBSD.org> <20100401222404.77a14a02.stas@FreeBSD.org> <4BB58AA6.1040600@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4BB58AA6.1040600@yandex.ru> User-Agent: Mutt/1.4.2.3i Cc: dougb@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 11:45:48 -0000 On Fri, Apr 02, 2010 at 10:11:50AM +0400, Andrey V. Elsukov wrote: > On 02.04.2010 9:24, Stanislav Sedov wrote: > >While it certainly might make sense to drop BIND out of the base, I'm not > >sure dropping bind tools as well from it is the best decision. How hard > >it will be to continue maintaining bind tools inside the base (so the > >critical ones like dig and nslookup still will be available), while moving > >the rest of it (the server itself and supporting tools) to the port? > > Hi, All. > > I'm agree with Stas. If it is not so hard to maintain "bind-tools" in the > base, > It is very useful to still having them in base system. +1 here. Dig and some of the other tools are extremely useful and important, so it would be nice if they were in the base system instead of a separate port. -- Denny Lin From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 12:46:44 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9458C106564A; Fri, 2 Apr 2010 12:46:44 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from megatron.madpilot.net (megatron.madpilot.net [88.149.173.206]) by mx1.freebsd.org (Postfix) with ESMTP id 20A2A8FC0C; Fri, 2 Apr 2010 12:46:42 +0000 (UTC) Received: from megatron.madpilot.net (localhost [127.0.0.1]) by megatron.madpilot.net (Postfix) with ESMTP id 80A871524; Fri, 2 Apr 2010 14:46:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= user-agent:in-reply-to:content-disposition:content-type :content-type:mime-version:references:message-id:subject:subject :from:from:date:date:received:received; s=mail; t=1270212394; x= 1272026794; bh=dX7cSJqfY7+OzHOJQOzznR5L2UkzMdbZWA7UpZYArGU=; b=S BywgMh8jE8vZ/9iopC41z9cdmovbmfGTKHLYyl4iNTqD5F/xTZMZNwagZeM9NhHu Fhw9sNjiIoCfs5JUNxMe3FjJfezMM06xJWNiug/6p8Lpruf1M+GDpHQuocZVTZ4J PLaoJW17b/Cwc7T0mge0PdbtvKbJNTQ0ciGN5l45AI= X-Virus-Scanned: amavisd-new at madpilot.net Received: from megatron.madpilot.net ([127.0.0.1]) by megatron.madpilot.net (megatron.madpilot.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id sU75wPeBSBud; Fri, 2 Apr 2010 14:46:34 +0200 (CEST) Received: by megatron.madpilot.net (Postfix, from userid 1000) id 35A52151C; Fri, 2 Apr 2010 14:46:34 +0200 (CEST) Date: Fri, 2 Apr 2010 14:46:34 +0200 From: Guido Falsi To: sthaug@nethelp.no Message-ID: <20100402124633.GC33426@megatron.madpilot.net> References: <20100402021715.669838e0.stas@FreeBSD.org> <11597.1270200291@critter.freebsd.dk> <20100402101454.GA62089@icarus.home.lan> <20100402.122836.41723967.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100402.122836.41723967.sthaug@nethelp.no> X-Operating-System: FreeBSD 8.0-STABLE User-Agent: Mutt/1.5.20 (2009-06-14) Cc: randy@psg.com, dougb@FreeBSD.org, freebsd-stable@FreeBSD.org, stas@FreeBSD.org, phk@phk.freebsd.dk, freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org, freebsd@jdc.parodius.com Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 12:46:44 -0000 On Fri, Apr 02, 2010 at 12:28:36PM +0200, sthaug@nethelp.no wrote: > > [1]: FreeBSD really needs to move away from the "base system" as a > > concept, as I've ranted about in the past. > > Strongly disagree. I'm with you! > > > Or if it cannot, the "base > > system" needs to start using pkg_* (somehow) for use, and src.conf > > WITHOUT_xxx (where xxx = some software) removed. Concept being: "I > > don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; > > pkg_delete base-lib32". Beautiful concept, hard to implement due to > > libraries being yanked out from underneathe binaries that are linked to > > them. But you get the idea. > > This *might* be workable. However, in general - a large part of the > reason why I use FreeBSD is that the FreeBSD base system gives me > most of what I want, in *one* well defined chunk, *without* having > to install a zillion extra packages, and without umpteen different > versions of config files and locations for the important information. > Also, more than that, won't splitting the "base system" in many smaller pieces moving around by themselves make every single part of freeBSD a moving target? What I mean is that what may look like a way to simplify things could make matters worse with incompatibilities in between the base packages. having everythign in the base system guarantees much more control. I'm also thinking about the nightmares this kind of splitting could cause to release engineering. This is not pure speculation. Such problems do appear in many other known open source OSes with such a split base system. In fact, if I wanted such a thing I'd install that other open source OS. I did in fact, and observed many annoying things about not having a rich base system like ours(like wasting time figuring which packet contained commands I'm used to see in the base system on any unix. > So please don't destroy this. I hope not. Another good reason not to destroy this is again that there are already many alternative OSes doing it, and I think FreebSD has a strong point in being different, not a weak spot. -- Guido Falsi From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 16:50:07 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 852D11065692; Fri, 2 Apr 2010 16:50:07 +0000 (UTC) (envelope-from oberman@es.net) Received: from mailgw.es.net (mail1.es.net [IPv6:2001:400:201:1::2]) by mx1.freebsd.org (Postfix) with ESMTP id 25BB98FC0C; Fri, 2 Apr 2010 16:50:07 +0000 (UTC) Received: from ptavv.es.net (ptavv.es.net [IPv6:2001:400:910::29]) by mailgw.es.net (8.14.3/8.14.3) with ESMTP id o32Go28M009288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 2 Apr 2010 09:50:02 -0700 Received: from ptavv.es.net (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 71A8B1CC09; Fri, 2 Apr 2010 09:50:02 -0700 (PDT) To: Jeremy Chadwick In-reply-to: Your message of "Fri, 02 Apr 2010 03:14:54 PDT." <20100402101454.GA62089@icarus.home.lan> Date: Fri, 02 Apr 2010 09:50:02 -0700 From: "Kevin Oberman" Message-Id: <20100402165002.71A8B1CC09@ptavv.es.net> X-Proofpoint-Virus-Version: vendor=fsecure engine=1.12.8161:2.4.5, 1.2.40, 4.0.166 definitions=2010-04-02_11:2010-02-06, 2010-04-02, 2010-04-02 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004020135 Cc: Stanislav Sedov , Doug Barton , freebsd-stable@FreeBSD.org, Randy Bush , Poul-Henning Kamp , freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 16:50:08 -0000 > Date: Fri, 2 Apr 2010 03:14:54 -0700 > From: Jeremy Chadwick > Sender: owner-freebsd-stable@freebsd.org > > On Fri, Apr 02, 2010 at 09:24:51AM +0000, Poul-Henning Kamp wrote: > > In message <20100402021715.669838e0.stas@FreeBSD.org>, Stanislav Sedov writes: > > >On Fri, 02 Apr 2010 08:55:07 +0000 > > >"Poul-Henning Kamp" mentioned: > > > > >Sorry, I think I was not clear enough. > > > > Sorry for misunderstanding. > > > > Yes, the case can certainly be made that DNS query tool belongs in the > > base system. > > I disagree (so what else is new?) It should be kept out of the base > system. KISS: > > Doug pulling BIND out of the base system / going ports-only = excellent. > > Doug making a separate port for BIND-esque DNS query/maintenance tools = > excellent. > > Both of the above can be made into packages. Vendors who use FreeBSD > can incorporate said package(s) into their build infrastructure. Folks > who do not have Internet connections (yet for some reason want said DNS > tools) can install the package(s) from CD/DVD/USB. > > I want the bikeshed to be black. :-) I have very mixed feelings on this. I agree with arguments I have seen on both sides. I like being able to install FreeBSD and have a well integrated system with all of the basic tools installed for basic use. Things play together well. I don't use many of the base system tools. I use cups, postfix, customized ssh, and the ports version of BIND. I don't build the stuff I don't need (src.conf) and I don't mind them being there. On the other hand, for complex, heavy duty ports, keeping up to date with externally maintains tools (contrib) is a pain and the base system can get stuck with rather out of date tools as a result. (Remember perl?) Unless there is very strong support for a contributed tools, it's hopeless and, if the tool is evolving rapidly, as BIND is with DNSSEC, it's still hopeless. I have seen suggestions that some tools be kept in the base system. nslookup (an evil tool that I think should be put out of its misery) and dig (a good tool that not enough people understand how to use) have been explicitly mentioned. The problem is that dig needs to be in reasonable feature sync with the resolver or it can have problems. Finally, what about a stub resolver? This really MUST be in the base system and, it should understand DNSSEC soon, which just complicates things. I prefer my bikeshed in green. Black is too goth and too hot for my tastes. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 15:06:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B8780106564A for ; Fri, 2 Apr 2010 15:06:23 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from mail-fx0-f209.google.com (mail-fx0-f209.google.com [209.85.220.209]) by mx1.freebsd.org (Postfix) with ESMTP id 422EC8FC0C for ; Fri, 2 Apr 2010 15:06:22 +0000 (UTC) Received: by fxm1 with SMTP id 1so1479430fxm.13 for ; Fri, 02 Apr 2010 08:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=d/RbA2K3IWLj8vP6v0NXdOT3VPy7e/C3UMXHl6MB+04=; b=IEH9tBJTUovPMwgXrBlSoDux2mtWATAceNmWhSzXC4/54dRVDBJDvl3uEmTC24KBEj oQWBzQFlmxwsufV6aitK/pW/6qotMzFQRLSpA2Be9wF1hWm4Di0JR8xGdKpRg4Lwfo8e VB5QFifo56D603yT7VSafWEv5y+6J1fm1li2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=a3/dSoQvSnTCALmQFuFTri7iDvXJHrJLh9S7cG1xpyuoYejHdBE2W6mMcG+oCOtUar u66dQzjdplktF59ZUdydr/A4U3K0kE7MAJ/5tQbx+se6SST1YuEAT/yNt0Bn/MO1oPKS a2+oIcxY5B0YDhdT4moTjof+Oykq3Vb0jnCco= Received: by 10.223.5.70 with SMTP id 6mr2117660fau.18.1270220782045; Fri, 02 Apr 2010 08:06:22 -0700 (PDT) Received: from [10.0.10.2] (54.81.54.77.rev.vodafone.pt [77.54.81.54]) by mx.google.com with ESMTPS id 16sm6412799fxm.4.2010.04.02.08.06.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 08:06:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Rui Paulo In-Reply-To: Date: Fri, 2 Apr 2010 16:06:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <674841CD-0CD8-4ED0-92A3-E44CF355547F@gmail.com> References: To: Arseny Nasokin X-Mailer: Apple Mail (2.1078) X-Mailman-Approved-At: Fri, 02 Apr 2010 16:59:29 +0000 Cc: FreeBSD Mail Lists Subject: Re: eeemon(4) 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, 02 Apr 2010 15:06:23 -0000 On 2 Apr 2010, at 11:29, Arseny Nasokin wrote: > Will be this device in current ? Or there is alternative for it? >=20 > Svn path repo: http://svn.freebsd.org/base/user/rpaulo/eeemon/ I wasn't planning on committing it because it's one of those drivers = that can seriously damage your hardware if you don't know what you're = doing. Also, the driver only supports older models. Regards, -- Rui Paulo From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 17:22:14 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9581D1065672; Fri, 2 Apr 2010 17:22:14 +0000 (UTC) (envelope-from reko.turja@liukuma.net) Received: from www.liukuma.net (www.liukuma.net [62.220.235.15]) by mx1.freebsd.org (Postfix) with ESMTP id 476108FC17; Fri, 2 Apr 2010 17:22:14 +0000 (UTC) Received: from localhost (unknown [127.0.0.1]) by www.liukuma.net (Postfix) with ESMTP id 4256F1CC60; Fri, 2 Apr 2010 20:22:06 +0300 (EEST) X-Virus-Scanned: amavisd-new at liukuma.net Received: from www.liukuma.net ([127.0.0.1]) by localhost (www.liukuma.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yZsC45uKhR7e; Fri, 2 Apr 2010 20:22:04 +0300 (EEST) Received: from rivendell (a91-155-174-194.elisa-laajakaista.fi [91.155.174.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: ignatz@www.liukuma.net) by www.liukuma.net (Postfix) with ESMTPSA id 86B101CC5D; Fri, 2 Apr 2010 20:22:04 +0300 (EEST) Message-ID: <77FCD9C7615944DBBD3369EC4E5A5C94@rivendell> From: "Reko Turja" To: "freebsd-current+AEA-FreeBSD.ORG" References: <20100402165002.71A8B1CC09@ptavv.es.net> In-Reply-To: <20100402165002.71A8B1CC09@ptavv.es.net> Date: Fri, 2 Apr 2010 20:22:19 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-7"; reply-type=original Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 Cc: freebsd-stable@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 17:22:14 -0000 Based on the inspection of the source tree, I want my bikeshed mauve.=20 I've not been had by AFD jokes in a while but Doug pulled this one=20 off... -Reko=20 From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 18:29:32 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 385D1106564A; Fri, 2 Apr 2010 18:29:32 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id CA1D68FC0A; Fri, 2 Apr 2010 18:29:31 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.4/8.14.4/NETPLEX) with ESMTP id o32ITQQg013377; Fri, 2 Apr 2010 14:29:26 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.2.2 (mail.netplex.net [204.213.176.10]); Fri, 02 Apr 2010 14:29:27 -0400 (EDT) Date: Fri, 2 Apr 2010 14:29:26 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Kevin Oberman In-Reply-To: <20100402165002.71A8B1CC09@ptavv.es.net> Message-ID: References: <20100402165002.71A8B1CC09@ptavv.es.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Randy Bush , Doug Barton , freebsd-stable@freebsd.org, Stanislav Sedov , Poul-Henning Kamp , freebsd-current@freebsd.org, freebsd-arch@freebsd.org, Jeremy Chadwick Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 18:29:32 -0000 On Fri, 2 Apr 2010, Kevin Oberman wrote: >> Date: Fri, 2 Apr 2010 03:14:54 -0700 >> From: Jeremy Chadwick >> Sender: owner-freebsd-stable@freebsd.org >> >> I disagree (so what else is new?) It should be kept out of the base >> system. KISS: >> >> Doug pulling BIND out of the base system / going ports-only = excellent. >> >> Doug making a separate port for BIND-esque DNS query/maintenance tools = >> excellent. >> >> Both of the above can be made into packages. Vendors who use FreeBSD >> can incorporate said package(s) into their build infrastructure. Folks >> who do not have Internet connections (yet for some reason want said DNS >> tools) can install the package(s) from CD/DVD/USB. >> >> I want the bikeshed to be black. :-) > > I have very mixed feelings on this. I agree with arguments I have seen > on both sides. I like being able to install FreeBSD and have a well > integrated system with all of the basic tools installed for basic > use. Things play together well. > > I don't use many of the base system tools. I use cups, postfix, > customized ssh, and the ports version of BIND. I don't build the stuff I > don't need (src.conf) and I don't mind them being there. > > On the other hand, for complex, heavy duty ports, keeping up to date > with externally maintains tools (contrib) is a pain and the base system > can get stuck with rather out of date tools as a result. (Remember > perl?) Unless there is very strong support for a contributed tools, it's > hopeless and, if the tool is evolving rapidly, as BIND is with DNSSEC, > it's still hopeless. I really dread having to update my ports. I hate all the bloated dependencies that a lot of ports have. It's sometimes a hit or miss situtation; you never know whether your ports are going to build (update) fully or not. And it takes forever. Our ports team does a fantastic job, so no diss intended. But I am concerned about moving BIND into ports, even if there is a tools-only port. With BIND in base, I don't have to worry about updating or when to update - someone else decides when to update/patch the base BIND and I am happy with that. All I have to do is buildworld, which I do much more often than update ports. If there is already a WITHOUT_BIND knob, then I really don't see what advantage there is in moving BIND out of base. Anyone that wants to use a different resolver can already do that, with the only limitation that they have to buildworld to remove the base bind. -- DE From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 19:07:55 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FF6E1065670 for ; Fri, 2 Apr 2010 19:07:55 +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 ESMTP id 07FE08FC1B for ; Fri, 2 Apr 2010 19:07:54 +0000 (UTC) Received: (qmail 29978 invoked by uid 399); 2 Apr 2010 19:07:54 -0000 Received: from localhost (HELO ?192.168.0.145?) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 2 Apr 2010 19:07:54 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BB64088.8030003@FreeBSD.org> Date: Fri, 02 Apr 2010 12:07:52 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org References: <11351.1270198507@critter.freebsd.dk> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 19:07:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 So first of all, yes Virginia, this was an April Fool's Day joke. To both those for whom this post created a false sense of despair, and (perhaps more importantly) to those for whom it created a false sense of joy, my apologies. :) And for the record, everything from here on is "just the facts." I have always said that I will remove BIND from the base when there is clear community consensus to do so, and I stand by that. However the discussion always seems to go along the lines that this thread did. A vocal group who say, "YES!" and then a lot of people who want the resolution tools (dig, host, nslookup) to stay, and the other end of the bell-shaped curve with those who like having the whole thing in the base. Toss in a few choruses of "The whole base should be more modular," (a viewpoint with which I have a great deal of sympathy btw) and the soup is pretty well complete. In regard to the tools issue, the problem is that you need a pretty good majority of the code in order to build them. They require the libraries to be built, and once you've done that, you might as well do the rest. :) Total size of code in: contrib/bind9: 14.0M contrib/bind9/lib: 7.6M contrib/bind9/bin: 2.5M contrib/bind9/bin/dig: 0.4M The last is the directory that has the code for all 3 resolution tools, FYI. Therefore I think that the status quo of having it all in there, and knobs to turn off the bits you don't want is a good one since it seems to please the majority of our users. I will continue to maintain the bind-tools port though, that's something that's been requested often, and I think it's a good thing to have for those who want a different DNS solution but still want access to those tools in a fairly painless manner. And of course the ability to easily change/upgrade/manage what version of BIND you use via the ports will continue to be a key component of how we deal with this going forward. Of course, the release synchronization problems I described in both the original post and the AFD post are real, so stay tuned. :) Answers to DNSSEC concerns below. On 4/2/2010 3:52 AM, Robert Watson wrote: > With an eye on the date of Doug's suggestive e-mail, I actually am concerned > that we maintain support for DNSSEC validation in the base system. If this > can be accomplished by keeping DNS debugging tools and the lightweight > resolver in the base, then I'm fine with that world view. However, if we > can't do DNSSEC record validation without installing the BIND package, then > that worries me. Unfortunately this answer is more complicated than I'd like it to be. In general, DNS resolution requires 4 components (and yes, this is pretty well simplified, but I think the illustration serves to clarify my point): 1. An end-user application that makes a request 2. A stub resolver located on the local system 3. A resolving name server 4. An authoritative name server At this time the DNSSEC protocol only clearly addresses the behavior of 4, and partially addresses the behavior of 3. There is no protocol specification for 1 or 2. So in general if you want to be able to validate DNSSEC signatures on the local system the only option available to you is to run a local validating resolver. It doesn't have to be BIND, unbound is also a good candidate, but you have to run something locally to be sure that the response(s) you've received are valid. Now that said, if you have a special purpose in mind to validate records in a specific domain (or specific few domains) for which you are prepared to individually manage trust anchors (the generic term of art for DNSSEC keys) then you could do that using dig alone. However that solution would not scale well, and I wouldn't recommend it for a critical piece of the base or ports. > As we go forward, DNSSEC is going to become increasingly important, and being > unable to bootstrap a system will be a problem, and it will become an > increasingly critical part of the security bootstrap process for networked > systems. Since your description above is generic, I will generically agree with you. :) I think as time goes on and more intelligence about DNSSEC is pushed to the edges I think it will be possible to have a validating stub resolver, and on a trusted network reasonable to rely on an external validating resolving name server. However there's an awful lot of supposition there, and as I said above, the spec doesn't even exist yet, never mind the code. > While some DNSSEC folk consider it anathema ("DNS is not a directory > service!"), the ability to securely distribute keying material via an existing > network service has enourmous value: for example, early DNSSEC prototypes in > the late 1990's/early 2000's included SSH key distribution via cert records in > DNSSEC. The CERT record still exists, although not for ssh. See http://tools.ietf.org/html/rfc4398. For ssh fingerprints there is the SSHFP record, http://tools.ietf.org/html/rfc4255. And there are always TXT records. :) Now all THAT said, there is an element of DNSSEC that I am rather strongly leaning toward putting in the ports, trust anchor configuration. Currently you have essentially 2 choices for DNSSEC validation, manually configure trust anchors, or use a DNS Lookaside Validation (DLV) service, of which the most popular is ISC's. Both options have their benefits and their drawbacks, which are outside the scope of this post. OTOH, if things continue going according to plan the root zone will be signed with real DNSSEC keys in July. That will make it possible to do "regular" DNSSEC validation for those zones that are signed from the root down by only configuring one trust anchor, the root zone key. (If you need to validate something on a "secure island," i.e., one or more parent zones is not signed, you are back to the first 2 choices, but once again, out of scope.) In the ideal world the root zone trust anchor would function like the root.hints file does now. It is stable (not updated often) and failure to update it in a timely manner would not be catastrophic. Unfortunately, the first is not guaranteed, and the latter is the opposite of the truth. There has already been on incident where an OS distribution had shipped with trust anchors manually configured and when they became outdated hilarity ensued. I would like to avoid that for our users. At this time my plan is to add hooks for "easy" incorporation of DNSSEC validation into the base named.conf, with instructions for how to install the port/package, the importance of keeping it up to date, etc. Before I make any changes I'll be seeking input from experts in the DNSSEC community and posting something a little more focused on -arch at least. If the release engineer or security officer teams have "something" in mind for FreeBSD that will require DNSSEC, we'll have to coordinate efforts on this, but I don't imagine it will be too difficult even with a bind-dnssec-config port. hth, Doug - -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (MingW32) iEYEAREDAAYFAku2QIgACgkQyIakK9Wy8PvMtQCeIu/32RGMIC/798V15aO/sjP3 788AoPf53oxsgutXPriuLOszcp2DBKc1 =hUnq -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 19:26:09 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11E86106566C for ; Fri, 2 Apr 2010 19:26:09 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4949F8FC08 for ; Fri, 2 Apr 2010 19:26:07 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA03919; Fri, 02 Apr 2010 22:26:04 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1NxmVH-0004oW-Pc; Fri, 02 Apr 2010 22:26:03 +0300 Message-ID: <4BB644CA.4000807@freebsd.org> Date: Fri, 02 Apr 2010 22:26:02 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Fabian Keil References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <3a142e751003191021p141af009m6acf7d160c890cbb@mail.gmail.com> <20100319191133.46fe271c@r500.local> <3a142e751003191126j331e525fwb9e5573bbf6f7d58@mail.gmail.com> <4BAA30CB.1070707@icyb.net.ua> <20100328172537.501ed3d1@r500.local> <4BB0A053.9060007@freebsd.org> <20100329222920.5eef6395@r500.local> <4BB111D4.8060809@freebsd.org> <20100330173637.202b4b1e@r500.local> <4BB21BBA.7030407@freebsd.org> <4BB360A1.7020309@freebsd.org> <20100402125721.50b3ba4f@r500.local> <4BB5D06C.8080902@freebsd.org> In-Reply-To: <4BB5D06C.8080902@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-current@freebsd.org, Bruce Evans Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 19:26:09 -0000 on 02/04/2010 14:09 Andriy Gapon said the following: > on 02/04/2010 13:57 Fabian Keil said the following: >> Andriy Gapon wrote: >>> Anyways, here is a patch that I would use. >>> Unfortunately, ENOTIME to understand newfs_msdos code and fix it too, >>> >>> --- a/sys/fs/msdosfs/msdosfs_vfsops.c >>> +++ b/sys/fs/msdosfs/msdosfs_vfsops.c >>> @@ -580,6 +580,7 @@ mountmsdosfs(struct vnode *devvp, struct mount *mp) >>> || (pmp->pm_BytesPerSec & (pmp->pm_BytesPerSec - 1)) >>> || (pmp->pm_HugeSectors == 0) >>> || (pmp->pm_FATsecs == 0) >>> + || (SecPerClust * pmp->pm_BlkPerSec > MAXBSIZE / DEV_BSIZE) >>> ) { >>> error = EINVAL; >>> goto error_exit; >> That works, too: >> >> fk@r500 ~ $sudo mdconfig -a -t vnode -f /tank/ipod-image-formatiert >> md0 >> fk@r500 ~ $sudo mount_msdosfs /dev/md0 /mnt/ >> mount_msdosfs: /dev/md0: Invalid argument >> >> Is there a chance that this, or some other workaround, could be committed? > > Yes, there is 99.99% chance of this happening :-) > Now, if someone could fix newfs_msdos issue too. > I could easily reproduce it this way: > > $ truncate -s 5G test.img > $ mdconfig -a -t vnode -f test.img -S 2048 -u 0 > $ newfs_msdos -F 32 /dev/md0 > OK, I did it again. I tested the below patch using the scenario described above. Could you please review and/or test this patch? If you like it and it works, I can commit it. Thanks! --- a/sbin/newfs_msdos/newfs_msdos.c +++ b/sbin/newfs_msdos/newfs_msdos.c @@ -427,6 +427,9 @@ main(int argc, char *argv[]) if (bpb.bpbBytesPerSec < MINBPS) errx(1, "bytes/sector (%u) is too small; minimum is %u", bpb.bpbBytesPerSec, MINBPS); + bpb.bpbSecPerClust /= (bpb.bpbBytesPerSec / MINBPS); + if (bpb.bpbSecPerClust == 0) + bpb.bpbSecPerClust = 1; if (!(fat = opt_F)) { if (opt_f) fat = 12; -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 19:31:37 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 306FD1065677 for ; Fri, 2 Apr 2010 19:31:37 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 689EA8FC1C for ; Fri, 2 Apr 2010 19:31:35 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA03959; Fri, 02 Apr 2010 22:31:34 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Nxmab-0004os-RL; Fri, 02 Apr 2010 22:31:33 +0300 Message-ID: <4BB64615.9060601@freebsd.org> Date: Fri, 02 Apr 2010 22:31:33 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Fabian Keil References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <3a142e751003191021p141af009m6acf7d160c890cbb@mail.gmail.com> <20100319191133.46fe271c@r500.local> <3a142e751003191126j331e525fwb9e5573bbf6f7d58@mail.gmail.com> <4BAA30CB.1070707@icyb.net.ua> <20100328172537.501ed3d1@r500.local> <4BB0A053.9060007@freebsd.org> <20100329222920.5eef6395@r500.local> <4BB111D4.8060809@freebsd.org> <20100330173637.202b4b1e@r500.local> <4BB21BBA.7030407@freebsd.org> <4BB360A1.7020309@freebsd.org> <20100402125721.50b3ba4f@r500.local> <4BB5D06C.8080902@freebsd.org> <4BB644CA.4000807@freebsd.org> In-Reply-To: <4BB644CA.4000807@freebsd.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , freebsd-current@freebsd.org, Bruce Evans Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 19:31:37 -0000 on 02/04/2010 22:26 Andriy Gapon said the following: > > OK, I did it again. > I tested the below patch using the scenario described above. > Could you please review and/or test this patch? > If you like it and it works, I can commit it. > Thanks! > > --- a/sbin/newfs_msdos/newfs_msdos.c > +++ b/sbin/newfs_msdos/newfs_msdos.c > @@ -427,6 +427,9 @@ main(int argc, char *argv[]) > if (bpb.bpbBytesPerSec < MINBPS) > errx(1, "bytes/sector (%u) is too small; minimum is %u", > bpb.bpbBytesPerSec, MINBPS); > + bpb.bpbSecPerClust /= (bpb.bpbBytesPerSec / MINBPS); > + if (bpb.bpbSecPerClust == 0) > + bpb.bpbSecPerClust = 1; > if (!(fat = opt_F)) { > if (opt_f) > fat = 12; > And here is a safer one (in case of a huge sector size > 32KB). I will appreciate any testing with real media that you might have. diff --git a/sbin/newfs_msdos/newfs_msdos.c b/sbin/newfs_msdos/newfs_msdos.c index 955c3a5..3f2778d 100644 --- a/sbin/newfs_msdos/newfs_msdos.c +++ b/sbin/newfs_msdos/newfs_msdos.c @@ -427,6 +427,12 @@ main(int argc, char *argv[]) if (bpb.bpbBytesPerSec < MINBPS) errx(1, "bytes/sector (%u) is too small; minimum is %u", bpb.bpbBytesPerSec, MINBPS); + bpb.bpbSecPerClust /= (bpb.bpbBytesPerSec / MINBPS); + if (bpb.bpbSecPerClust == 0) + bpb.bpbSecPerClust = 1; + if (bpb.bpbSecPerClust * bpb.bpbBytesPerSec > 32 * 1024) + errx(1, "bytes per sector (%u) is greater than 32k", + bpb.bpbSecPerClust * bpb.bpbBytesPerSec); if (!(fat = opt_F)) { if (opt_f) fat = 12; -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 18:10:23 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A6391065674; Fri, 2 Apr 2010 18:10:23 +0000 (UTC) (envelope-from bc979@lafn.org) Received: from zoom.lafn.org (zoom.lafn.ORG [206.117.18.8]) by mx1.freebsd.org (Postfix) with ESMTP id 63B1A8FC12; Fri, 2 Apr 2010 18:10:23 +0000 (UTC) Received: from [10.0.1.4] (pool-71-109-144-133.lsanca.dsl-w.verizon.net [71.109.144.133]) (authenticated bits=0) by zoom.lafn.org (8.14.3/8.14.2) with ESMTP id o32HdrCG096893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Apr 2010 10:39:54 -0700 (PDT) (envelope-from bc979@lafn.org) References: <4BB51B5B.1050606@FreeBSD.org> <20100401222404.77a14a02.stas@FreeBSD.org> <4BB58AA6.1040600@yandex.ru> <20100402112736.GB4611@mail.hs.ntnu.edu.tw> In-Reply-To: <20100402112736.GB4611@mail.hs.ntnu.edu.tw> Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Message-Id: <6E191581-F8EB-4B85-9F1D-8D2FE6DAAF10@lafn.org> Content-Transfer-Encoding: quoted-printable From: Doug Hardie Date: Fri, 2 Apr 2010 10:39:53 -0700 To: FreeBSD Current , FreeBSD-STABLE Mailing List , freebsd-arch@freebsd.org X-Mailer: Apple Mail (2.1078) X-Virus-Scanned: clamav-milter 0.95.3 at zoom.lafn.org X-Virus-Status: Clean X-Mailman-Approved-At: Fri, 02 Apr 2010 19:58:34 +0000 Cc: Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 18:10:23 -0000 On 2 April 2010, at 04:27, Denny Lin wrote: > On Fri, Apr 02, 2010 at 10:11:50AM +0400, Andrey V. Elsukov wrote: >> On 02.04.2010 9:24, Stanislav Sedov wrote: >>> While it certainly might make sense to drop BIND out of the base, = I'm not >>> sure dropping bind tools as well from it is the best decision. How = hard >>> it will be to continue maintaining bind tools inside the base (so = the >>> critical ones like dig and nslookup still will be available), while = moving >>> the rest of it (the server itself and supporting tools) to the port? >>=20 >> Hi, All. >>=20 >> I'm agree with Stas. If it is not so hard to maintain "bind-tools" in = the=20 >> base, >> It is very useful to still having them in base system. >=20 > +1 here. Dig and some of the other tools are extremely useful and > important, so it would be nice if they were in the base system instead > of a separate port. The reason dig and nslookup are used is because you have a problem with = the internet connection. Thats a bit late to say "you need to install = the DNS tools". If you could, you wouldn't need them. Not everyone = will create a ports CD. =20= From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 20:11:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D200106566B for ; Fri, 2 Apr 2010 20:11:10 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.27]) by mx1.freebsd.org (Postfix) with ESMTP id 4E3278FC08 for ; Fri, 2 Apr 2010 20:11:10 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so799574qwe.7 for ; Fri, 02 Apr 2010 13:11:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:x-mailer :subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc; bh=ZugOM/yEMGQkOhF3wyu9YqyVrFSZEzKvIfSZnCL0D58=; b=jrntSwRpsqbuW4nE2otQvSGikmZGOteJL1WjXlc9ttRKCvpGjBMkpn6KJ/IvCLkgUu X6f82A/yO9Pl2iM+GK4yIHXvWoua7TEHBftQ5SKuvG3SwjyRJLTNNUe8q9Jc4y74IEQo ukp/IxENvwGpUGMIiX6ti68EpjSfDZLG4HWvk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:x-mailer:subject:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc; b=QZKJjhzx+mGQg1x1kMYNQj1cODaUSni7v13dyCmiBm5xD/fIPoQ80mte3kbZmPLw3r ENuTs2PDUFdPJgy/eL3AFSP47zhCdI//CVXPj4nPzBsMmQHwZPGX3U0u+vaRw1D443oK els3MIaOR7AQ9eXwDTnLkegX8prwnk+jIjnyU= Received: by 10.224.72.132 with SMTP id m4mr842122qaj.145.1270239069529; Fri, 02 Apr 2010 13:11:09 -0700 (PDT) Received: from [192.168.0.7] ([72.14.241.38]) by mx.google.com with ESMTPS id 20sm5122240qyk.8.2010.04.02.13.11.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 13:11:08 -0700 (PDT) From: Arseny Nasokin To: Rui Paulo In-Reply-To: <674841CD-0CD8-4ED0-92A3-E44CF355547F@gmail.com> X-Mailer: iPhone Mail (7D11) References: <674841CD-0CD8-4ED0-92A3-E44CF355547F@gmail.com> Message-Id: Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7D11) Date: Sat, 3 Apr 2010 00:11:05 +0400 Cc: FreeBSD Mail Lists Subject: Re: eeemon(4) 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, 02 Apr 2010 20:11:10 -0000 On 2 Apr 2010, at 19:06, Rui Paulo wrote: > On 2 Apr 2010, at 11:29, Arseny Nasokin wrote: > >> Will be this device in current ? Or there is alternative for it? >> >> Svn path repo: http://svn.freebsd.org/base/user/rpaulo/eeemon/ > > I wasn't planning on committing it because it's one of those drivers > that can seriously damage your hardware if you don't know what > you're doing. > > Also, the driver only supports older models. I use only CPU fan control, it's very useful. Voltage is always 0 on my Asus EEE PC 900. I won't try to modify it due possible damage. And you can write disclaimer about. > > Regards, > -- > Rui Paulo > From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 18:35:20 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8EFB1065670 for ; Fri, 2 Apr 2010 18:35:20 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 86A668FC15 for ; Fri, 2 Apr 2010 18:35:19 +0000 (UTC) Received: (qmail 28759 invoked by uid 0); 2 Apr 2010 18:08:38 -0000 Received: from unknown (HELO ?10.82.15.178?) (spork@166.198.238.83) by smtp.bway.net with (AES128-SHA encrypted) SMTP; 2 Apr 2010 18:08:38 -0000 References: <20100402165002.71A8B1CC09@ptavv.es.net> <77FCD9C7615944DBBD3369EC4E5A5C94@rivendell> Message-Id: <2972DD89-7D7D-4869-9280-305BACBFEC5A@bway.net> From: Charles Sprickman To: Reko Turja In-Reply-To: <77FCD9C7615944DBBD3369EC4E5A5C94@rivendell> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Mailer: iPhone Mail (7D11) Mime-Version: 1.0 (iPhone Mail 7D11) Date: Fri, 2 Apr 2010 14:08:27 -0400 X-Mailman-Approved-At: Fri, 02 Apr 2010 20:32:21 +0000 Cc: "freebsd-current+AEA-FreeBSD.ORG" , "freebsd-stable@FreeBSD.org" , "freebsd-arch@FreeBSD.org" Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 18:35:21 -0000 Can we do sendmail next April 1? Sent from a device with a tiny keyboard On Apr 2, 2010, at 1:22 PM, "Reko Turja" wrote: > Based on the inspection of the source tree, I want my bikeshed > mauve. I've not been had by AFD jokes in a while but Doug pulled > this one off... > > -Reko > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 21:08:26 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 41052106564A; Fri, 2 Apr 2010 21:08:26 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-gx0-f210.google.com (mail-gx0-f210.google.com [209.85.217.210]) by mx1.freebsd.org (Postfix) with ESMTP id BB63D8FC17; Fri, 2 Apr 2010 21:08:25 +0000 (UTC) Received: by gxk2 with SMTP id 2so1824846gxk.3 for ; Fri, 02 Apr 2010 14:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:content-type; bh=NQEnIzp56YO99tH7XEY7pwcAu4XgAWsVZnfYCnnkDiY=; b=JX+TuD9wADavAaF+G+2By5Z2jFC/HTEWJC3jiW94wCz4EjMtpL2Kelo4kScETyXZNN aMVnubIKDGtmpaqDnBujfiwXMVFUbSrA/mDvSn4B1G7AzrtfQXpJ5dLMeH22sNHQczCy gUh/ghmwoKCRi9kyMIOQfuoAL4xeQXIfpCWTE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=Mhhbz6Mq9Hz7eIpHBjSFi5BOi0FGt8l+jKFvv9Nay7ZXV8zCM6WtkNiDu1j7KCYEmW aQzVllVP7HNtqAXgxX8Ic/XPXyRMoxS30tf4MQgnr4bYPUPtCepCbcAYQcf7X7fJDyI0 ToShjH1qecj+yKNc9AGlj298nldsbjVofdsuQ= MIME-Version: 1.0 Received: by 10.231.35.203 with HTTP; Fri, 2 Apr 2010 14:08:24 -0700 (PDT) In-Reply-To: <20100402101454.GA62089@icarus.home.lan> References: <20100402021715.669838e0.stas@FreeBSD.org> <11597.1270200291@critter.freebsd.dk> <20100402101454.GA62089@icarus.home.lan> Date: Fri, 2 Apr 2010 14:08:24 -0700 Received: by 10.100.26.37 with SMTP id 37mr4633359anz.72.1270242504924; Fri, 02 Apr 2010 14:08:24 -0700 (PDT) Message-ID: From: Freddie Cash To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org, freebsd-arch@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 21:08:26 -0000 On Fri, Apr 2, 2010 at 3:14 AM, Jeremy Chadwick wrote: > [1]: FreeBSD really needs to move away from the "base system" as a > concept, as I've ranted about in the past. Or if it cannot, the "base > system" needs to start using pkg_* (somehow) for use, and src.conf > WITHOUT_xxx (where xxx = some software) removed. Concept being: "I > don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; > pkg_delete base-lib32". Beautiful concept, hard to implement due to > libraries being yanked out from underneathe binaries that are linked to > them. But you get the idea. > Maybe I'm just a lowly sysadmin and ex-port maintainer, but ... No, no, no, definitely no, no, and no!! The greatest thing about FreeBSD is that there is a clear separation between the "base OS" and everything else (ports, local installs, etc). You get a nice, clearly defined, base to build on. You get a stable base that changes infrequently, that you can add software to on whatever schedule you want. The worst thing about Linux distros is the lack of this clear separation between the base and third-party apps. If you want to install an updated version of Apache, you either have to update the whole damned distro, go searching for some unsupported backports repos, or compile everything by hand defeating the whole point of binary packages. Making the tools do deal with the base could be interesting, but please, please, please don't shove everything into the pkg_tools and turning FreeBSD into "just a random collection of packages that kind of work together". IOW, don't go down the distro path. Keep the base OS separate from third-party apps. Keep the tools to deal with them separate. -- Freddie Cash fjwcash@gmail.com From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 21:32:31 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 758F6106566C for ; Fri, 2 Apr 2010 21:32:31 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by mx1.freebsd.org (Postfix) with ESMTP id 298F58FC0A for ; Fri, 2 Apr 2010 21:32:30 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so817930qwe.7 for ; Fri, 02 Apr 2010 14:32:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=A8BfTA4++mioJswtN5kg8rtLB3PikQtPFIWu0aqikXU=; b=kjFhWUTfReXHBgeJKtv1uHSmYsSS7lw5pCwPIoyFIjTXlII58n+mx3isvRJAHhMtWB CZCfkt2RrME4Up8i5gp/rXb8OSWR4vhKW/iU5s8uc+eB2wj4WlpGgYTY5J28YhoLQkrB 4j23jw5WKftQEoC21VpIouHlWavCmlHZXJM+A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=e2Rri8veXpuOiA4tm3YFD/LcVw9osOCgA0wp1HpHivgNWbnVoRZBWn2/NvtC2eyykZ dUjSZo7FOCnC4kYBl3EfRk/sCpgKb2lpn36eL6m2udcZ+92rywSAYTaKZjtt4H/6y4Wo bQW91CM6JRkLWzgLTG0pceBCUauW62KNrKqvs= MIME-Version: 1.0 Received: by 10.229.33.72 with HTTP; Fri, 2 Apr 2010 14:32:29 -0700 (PDT) In-Reply-To: <20100402084640.GB19647@lonesome.com> References: <4BA7E0B8.3080406@delphij.net> <4BAE2B4F.6060005@protected-networks.net> <4BB3FD5D.9070600@uffner.com> <86tyrvs3js.fsf@ds4.des.no> <20100402084640.GB19647@lonesome.com> Date: Fri, 2 Apr 2010 14:32:29 -0700 Received: by 10.229.91.11 with SMTP id k11mr2600748qcm.50.1270243950025; Fri, 02 Apr 2010 14:32:30 -0700 (PDT) Message-ID: From: Garrett Cooper To: Mark Linimon Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: =?ISO-8859-1?Q?Dag=2DErling_Sm=F8rgrav?= , freebsd-current@freebsd.org Subject: Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 21:32:31 -0000 2010/4/2 Mark Linimon : > On Thu, Apr 01, 2010 at 03:30:47PM +0200, Dag-Erling Sm=F8rgrav wrote: >> And yes, I *will* keep harping on this until people Get It. > > You're harping at the wrong people. =A0Complain to the application author= s, > not to the poor slobs trying to maintain the ports collection. > > There's a lot of crap code out there on the internet. =A0If we want to > insist that all the application authors both a) write good code and that > b) understands how FreeBSD does things, well, we can do that, but it's > not going to have much effect. > > Probably 75%+ of the application authors neither know nor care that > their code is being run on anything other than Linux. =A0In extreme > cases we've enountered authors who outright refuse to accept our > patches, either due to philosophical disagreement or just due to the > xtra hassle. The problem actually was most likely the fact that the functionality wasn't properly documented or that people didn't thoroughly read or understand the documentation before implementing the feature. If there's anything that I've learned from cleaning up messes in the past (to be fair, some which I've created as well), it's that a lot of incorrect logic is created by misunderstanding things and/or making false assumptions on how things should work. But yes, zlib is buggy w.r.t. the item Xin Li mentioned and needed to be fixed. Too many folks try to resolve application porting issues by using inline: #ifndef SOME_LARGELY_USED_CONSTANT_INTRODUCED_IN_VERSION_B /* #define a constant or typedef a feature */ #endif This generally quasi-works in versions A (assuming the application runs and the developer upstream did their testing on version A's software... heh) or version C (typically a Linux) developer decided that they wanted to change the definition and dashed the consequences about backwards compatibility in their code. kernel.org sources are riddled with this kind of `decision making'. But I digress... -Garrett From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 21:46:10 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5D4E2106566B for ; Fri, 2 Apr 2010 21:46:10 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [IPv6:2001:470:a803::1]) by mx1.freebsd.org (Postfix) with ESMTP id 88CED8FC17 for ; Fri, 2 Apr 2010 21:46:09 +0000 (UTC) Received: from mail.geekcn.org (tarsier.geekcn.org [211.166.10.233]) by tarsier.geekcn.org (Postfix) with ESMTP id 5EF27A5DD8B; Sat, 3 Apr 2010 05:46:08 +0800 (CST) X-Virus-Scanned: amavisd-new at geekcn.org Received: from tarsier.geekcn.org ([211.166.10.233]) by mail.geekcn.org (mail.geekcn.org [211.166.10.233]) (amavisd-new, port 10024) with LMTP id kgqjwjf0B54g; Sat, 3 Apr 2010 05:46:01 +0800 (CST) Received: from delta.delphij.net (drawbridge.ixsystems.com [206.40.55.65]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTPSA id 4A64BA5DD68; Sat, 3 Apr 2010 05:45:58 +0800 (CST) DomainKey-Signature: a=rsa-sha1; s=default; d=delphij.net; c=nofws; q=dns; h=message-id:date:from:reply-to:organization:user-agent: mime-version:to:cc:subject:references:in-reply-to: x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=kE5eD+5rvI9k9oJvqRqUypWONS80PHPQ2c0F5CcPIyTv8x7KpIQn6l8Us00jGVhUt 5QTo7+owjkbMC7tkoMrKg== Message-ID: <4BB66593.3020804@delphij.net> Date: Fri, 02 Apr 2010 14:45:55 -0700 From: Xin LI Organization: The Geek China Organization User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.8) Gecko/20100304 Thunderbird/3.0.3 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: Garrett Cooper References: <4BA7E0B8.3080406@delphij.net> <4BAE2B4F.6060005@protected-networks.net> <4BB3FD5D.9070600@uffner.com> <86tyrvs3js.fsf@ds4.des.no> <20100402084640.GB19647@lonesome.com> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: id=3FCA37C1; url=http://www.delphij.net/delphij.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Mark Linimon , freebsd-current@freebsd.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8?=, =?ISO-8859-1?Q?rgrav?= Subject: Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: d@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 21:46:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, On 2010/04/02 14:32, Garrett Cooper wrote: > 2010/4/2 Mark Linimon : >> On Thu, Apr 01, 2010 at 03:30:47PM +0200, Dag-Erling Smørgrav wrote: >>> And yes, I *will* keep harping on this until people Get It. >> >> You're harping at the wrong people. Complain to the application authors, >> not to the poor slobs trying to maintain the ports collection. >> >> There's a lot of crap code out there on the internet. If we want to >> insist that all the application authors both a) write good code and that >> b) understands how FreeBSD does things, well, we can do that, but it's >> not going to have much effect. >> >> Probably 75%+ of the application authors neither know nor care that >> their code is being run on anything other than Linux. In extreme >> cases we've enountered authors who outright refuse to accept our >> patches, either due to philosophical disagreement or just due to the >> xtra hassle. > > The problem actually was most likely the fact that the functionality > wasn't properly documented or that people didn't thoroughly read or > understand the documentation before implementing the feature. If > there's anything that I've learned from cleaning up messes in the past > (to be fair, some which I've created as well), it's that a lot of > incorrect logic is created by misunderstanding things and/or making > false assumptions on how things should work. To be fair, the usage of _LARGEFILE64_SOURCE IS documented, people just don't pay enough attention. GNU headers choose to use #ifdef _LARGEFILE64_SOURCE instead of #if _LARGEFILE64_SOURCE == 1, to be pedantic, the latter form is correct. [1] > But yes, zlib is buggy w.r.t. the item Xin Li mentioned and needed to > be fixed. Too many folks try to resolve application porting issues by > using inline: If we use Large File Summit's documentation, it's not at all zlib's issue. > #ifndef SOME_LARGELY_USED_CONSTANT_INTRODUCED_IN_VERSION_B > /* #define a constant or typedef a feature */ > #endif > > This generally quasi-works in versions A (assuming the application > runs and the developer upstream did their testing on version A's > software... heh) or version C (typically a Linux) developer decided > that they wanted to change the definition and dashed the consequences > about backwards compatibility in their code. kernel.org sources are > riddled with this kind of `decision making'. Applications aiming to be portable should not define _LARGEFILE64_SOURCE at all, on any *BSD platforms. And, if they really want to do that, they should either use - -D_LARGEFILE64_SOURCE or #define _LARGEFILE64_SOURCE 1 in the first place. No, it's not zlib's fault. We may workaround the application bug on FreeBSD by removing all these checks in zlib.h and zconf.h, as they doesn't affect FreeBSD's base system's headers at all, HOWEVER, it's still the application's bug and should be fixed upstream. [1] http://www.unix.org/version2/whatsnew/lfs20mar.html Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iQEcBAEBAgAGBQJLtmWTAAoJEATO+BI/yjfBrwIH/Ap0FEtDRJ02ZKnTuUfjj25C c9n3QGH+26mhrzO1KP7pVyvW28zQCgH7RgOAdyXz6llWNbonSAg4/yN/80tWDk9w juIb/PfLxs8us/PbmUqkp0ZQATaUhmQO4Jw45LpBD0X7PYce7VhvednjWcFtNeLP v3f5MZ9inbDUPF6Bb7ErwJ2BGnFG2FGekCnKwgIAPN0DC61BrJ5PFVQm5lP1YVs3 WOJS3wU39xanzy87ZEv5Gh8SCtIgxcUa4A5G/+a1pStVXOcqL+DOd5nZQqCjlvPt r5+dLoFFpQNJAEeQwIXlgWQkjYfdCHTqNsPs4mGWEaEn8wMSKdknyuA/5X+R1Kk= =Uqae -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 21:49:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 73372106566C; Fri, 2 Apr 2010 21:49:58 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.26]) by mx1.freebsd.org (Postfix) with ESMTP id F332C8FC08; Fri, 2 Apr 2010 21:49:57 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so821674qwe.7 for ; Fri, 02 Apr 2010 14:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=Lt5IxyS8Yi6cSAa0aNmVyRM1OdzSbhUc8ODjPKd0mjE=; b=TrYOSVjZIP3ob36/D8VRfRdrlWix16YNCgIceSN5RXZIXJW7n90SDsHtkFvuPJdMVA 3DReMmaZSSIW39OX6u807QzX53BpNQnpqdAFg2OJ9Ps9oSb0454SH5OtO7oRMsZnGSKW XxcSrQ7G4/ZIkAzw7g/YEusxUiO+NompZBqQ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=W4oa7QWQGUgyemE+Kj1EAvmFLrQN2fV/zLWt1uZuNSjmLLk95xuRaULjgUyEwyqLEz dVIelCLrQTBcSC6QL7rjElA2wZhlTst46ER4AA8wDDbshfbJ+D7SJwvtsJ5J7smpt4dm aYrYSPsbQfNGf3QX9H7EgMMb7lSquUKsEfuIE= MIME-Version: 1.0 Received: by 10.229.82.14 with HTTP; Fri, 2 Apr 2010 14:49:54 -0700 (PDT) In-Reply-To: References: <20100402021715.669838e0.stas@FreeBSD.org> <11597.1270200291@critter.freebsd.dk> <20100402101454.GA62089@icarus.home.lan> Date: Fri, 2 Apr 2010 15:49:54 -0600 Received: by 10.229.215.11 with SMTP id hc11mr4410504qcb.45.1270244994361; Fri, 02 Apr 2010 14:49:54 -0700 (PDT) Message-ID: From: Adam Vande More To: Freddie Cash Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 21:49:58 -0000 On Fri, Apr 2, 2010 at 3:08 PM, Freddie Cash wrote: > Maybe I'm just a lowly sysadmin and ex-port maintainer, but ... > > No, no, no, definitely no, no, and no!! > > The greatest thing about FreeBSD is that there is a clear separation > between > the "base OS" and everything else (ports, local installs, etc). You get a > nice, clearly defined, base to build on. You get a stable base that > changes > infrequently, that you can add software to on whatever schedule you want. > > The worst thing about Linux distros is the lack of this clear separation > between the base and third-party apps. If you want to install an updated > version of Apache, you either have to update the whole damned distro, go > searching for some unsupported backports repos, or compile everything by > hand defeating the whole point of binary packages. > > Making the tools do deal with the base could be interesting, but please, > please, please don't shove everything into the pkg_tools and turning > FreeBSD > into "just a random collection of packages that kind of work together". > IOW, don't go down the distro path. > > Keep the base OS separate from third-party apps. Keep the tools to deal > with them separate. > True word, brother! If we wanted to run linux there are options for it. debs suck, rpms really suck. Those types of systems are sometimes faster to get up and rolling as long as you want vanilla apps, but they are a major PITA for many types of customizations which are a breeze with the ports tree. You'd be killing of one of the more elegant approaches in FreeBSD. Sure there are problem with it, but IMO adopting more severe problems isn't a good answer. Maybe that was a 4/1 too though. If so, good work. -- Adam Vande More From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 22:10:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 40F5C106564A for ; Fri, 2 Apr 2010 22:10:04 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id EF4E58FC08 for ; Fri, 2 Apr 2010 22:10:02 +0000 (UTC) Received: from ds4.des.no (des.no [84.49.246.2]) by smtp.des.no (Postfix) with ESMTP id 090071FFC22; Fri, 2 Apr 2010 22:10:02 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id DE3BD84463; Sat, 3 Apr 2010 00:10:01 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: d@delphij.net References: <4BA7E0B8.3080406@delphij.net> <4BAE2B4F.6060005@protected-networks.net> <4BB3FD5D.9070600@uffner.com> <86tyrvs3js.fsf@ds4.des.no> <20100402084640.GB19647@lonesome.com> <4BB66593.3020804@delphij.net> Date: Sat, 03 Apr 2010 00:10:01 +0200 In-Reply-To: <4BB66593.3020804@delphij.net> (Xin LI's message of "Fri, 02 Apr 2010 14:45:55 -0700") Message-ID: <86eiixpkue.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.95 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Garrett Cooper , freebsd-current@freebsd.org, Mark Linimon Subject: Re: HEADSUP: zlib updated [svn commit: r205471 - in head: . lib/libz lib/libz/contrib lib/libz/doc sys/sys] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 22:10:04 -0000 Xin LI writes: > Applications aiming to be portable should not define _LARGEFILE64_SOURCE > at all, on any *BSD platforms. nor on Linux. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 22:55:05 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E561F1065670; Fri, 2 Apr 2010 22:55:04 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 9C0DE8FC08; Fri, 2 Apr 2010 22:55:04 +0000 (UTC) Received: from ncsd.bris.ac.uk ([137.222.10.59] helo=ncs.bris.ac.uk) by dirg.bris.ac.uk with esmtp (Exim 4.69) (envelope-from ) id 1NxplX-0005jh-9U; Fri, 02 Apr 2010 23:55:03 +0100 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NxplW-0005To-Uu; Fri, 02 Apr 2010 23:55:03 +0100 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4) with ESMTP id o32Mt2YJ001865; Fri, 2 Apr 2010 23:55:02 +0100 (BST) (envelope-from mexas@bristol.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.4/8.14.4/Submit) id o32Mt27E001864; Fri, 2 Apr 2010 23:55:02 +0100 (BST) (envelope-from mexas@bristol.ac.uk) X-Authentication-Warning: mech-cluster241.men.bris.ac.uk: mexas set sender to mexas@bristol.ac.uk using -f Date: Fri, 2 Apr 2010 23:55:02 +0100 From: Anton Shterenlikht To: xcllnt@mac.com Message-ID: <20100402225502.GA1835@mech-cluster241.men.bris.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: ia64 -> panic: deadlkres: possible deadlock detected for 0xe00000001187d880, blocked for 1801437 ticks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 22:55:05 -0000 Hi Marcel I got this panic while trying to build some port on -current (csup'ed on 1-APR-2010) panic: deadlkres: possible deadlock detected for 0xe00000001187d880, blocked for 1801437 ticks cpuid = 1 KDB: enter: panic [ thread pid 0 tid 100046 ] Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe1fbf0,gp ;; db> db> bt Tracing pid 0 tid 100046 td 0xe000000010d4f500 kdb_enter(0xe000000004853640, 0xe000000004853640, 0xe00000000439d170, 0x793) at kdb_enter+0x92 panic(0xe00000000484b490, 0xe00000000484b6d0, 0xe00000001187d880, 0x1b7cdd) at panic+0x2f0 deadlkres(0xa00000007ebca2d8, 0xe00000001187d880, 0xe00000000484b410, 0x1b7cdd) at deadlkres+0x470 fork_exit(0xe000000004893250, 0x0, 0xa0000000bd3db550) at fork_exit+0x110 enter_userland() at enter_userland db> The panic followed a long freeze, of a sort that I've seen a lot on ia64 in the last couple of weeks. Do I get the panic (as opposed to a seemingly endless freeze) because of a recently added options DEADLKRES in my kernel config? Anyway, I think a deadlock would explain the freezes I've had recently with "make installworld". Or perhaps also the freeze I get when installing from 9.0 snapshot CD. Below is a fragment of the top(1) output somewhere close to the panic: last pid: 1458; load averages: 0.00, 0.03, 0.06 up 0+00:13:28 00:58:54 92 processes: 3 running, 73 sleeping, 16 waiting CPU 0: 0.0% user, 0.0% nice, 0.1% system, 0.0% interrupt, 99.9% idle CPU 1: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 28M Active, 21M Inact, 160M Wired, 216K Cache, 92M Buf, 9830M Free Swap: 32G Total, 32G Free PID UID THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 10 0 2 171 ki31 0K 64K RUN 0 25:21 200.00% idle 11 0 16 -48 - 0K 512K WAIT 0 0:01 0.00% intr 1452 0 1 47 0 15696K 4320K biowr 0 0:01 0.00% bsdtar 1278 1001 1 44 0 12800K 4016K CPU0 0 0:00 0.00% top 0 0 10 -16 0 0K 320K deadlk 0 0:00 0.00% kernel 4 0 1 -8 - 0K 32K - 1 0:00 0.00% g_down 3 0 1 -8 - 0K 32K - 1 0:00 0.00% g_up 2 0 1 -8 - 0K 32K - 0 0:00 0.00% g_event 1354 0 1 76 0 8392K 2296K wait 0 0:00 0.00% make 12 0 1 -16 - 0K 32K - 1 0:00 0.00% yarrow Not sure if relevant, but some disk operations seem very slow, e.g. "rm -rf /usr/src" or "rm -rf /usr/obj" take over 10 min to complete. Accoding to du(1) there was only ~600M and ~1G data respectively. gstat(8) shows disk writes at about 2MB/s, which is rougly the same as dd(1) writes. But I'd imagine rm(1) should be much faster as it only unlinks inodes? I apologise if I'm talking nonsense here. The disks use mpt(4). I've since updated to the latest -current via svn. Here are the kernel config and dmesg: http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2600/tzav/TZAV http://seis.bris.ac.uk/~mexas/freebsd/ia64/rx2600/tzav/dmesg.boot many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 From owner-freebsd-current@FreeBSD.ORG Fri Apr 2 23:10:58 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CACE1106564A; Fri, 2 Apr 2010 23:10:58 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from asmtpout027.mac.com (asmtpout027.mac.com [17.148.16.102]) by mx1.freebsd.org (Postfix) with ESMTP id 0737B8FC0C; Fri, 2 Apr 2010 23:10:57 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=us-ascii Received: from [172.24.241.149] (natint3.juniper.net [66.129.224.36]) by asmtp027.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0L09002O6V26J890@asmtp027.mac.com>; Fri, 02 Apr 2010 16:10:57 -0700 (PDT) X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004020238 From: Marcel Moolenaar In-reply-to: <20100402225502.GA1835@mech-cluster241.men.bris.ac.uk> Date: Fri, 02 Apr 2010 16:10:53 -0700 Message-id: <3B66ECFA-2A16-44E2-A94A-0C9AA57B4153@mac.com> References: <20100402225502.GA1835@mech-cluster241.men.bris.ac.uk> To: Anton Shterenlikht X-Mailer: Apple Mail (2.1078) Cc: freebsd-current@freebsd.org, freebsd-ia64@freebsd.org Subject: Re: ia64 -> panic: deadlkres: possible deadlock detected for 0xe00000001187d880, blocked for 1801437 ticks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 02 Apr 2010 23:10:59 -0000 On Apr 2, 2010, at 3:55 PM, Anton Shterenlikht wrote: > Hi Marcel > > I got this panic while trying to build some port > on -current (csup'ed on 1-APR-2010) > > panic: deadlkres: possible deadlock detected for 0xe00000001187d880, blocked for 1801437 ticks > > cpuid = 1 > KDB: enter: panic > [ thread pid 0 tid 100046 ] > Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe1fbf0,gp ;; > db> > db> bt > Tracing pid 0 tid 100046 td 0xe000000010d4f500 > kdb_enter(0xe000000004853640, 0xe000000004853640, 0xe00000000439d170, 0x793) at kdb_enter+0x92 > panic(0xe00000000484b490, 0xe00000000484b6d0, 0xe00000001187d880, 0x1b7cdd) at panic+0x2f0 > deadlkres(0xa00000007ebca2d8, 0xe00000001187d880, 0xe00000000484b410, 0x1b7cdd) at deadlkres+0x470 > fork_exit(0xe000000004893250, 0x0, 0xa0000000bd3db550) at fork_exit+0x110 > enter_userland() at enter_userland > db> > > The panic followed a long freeze, of a sort that > I've seen a lot on ia64 in the last couple of weeks. > Do I get the panic (as opposed to a seemingly endless freeze) > because of a recently added > > options DEADLKRES > > in my kernel config? Yes, exactly. At the db> prompt, can you type: db> show thread 0xe00000001187d880 This should give you something like: Thread 100001 at 0xe00000001187d880: proc (pid 1): 0xe00000301220c000 name: kernel stack: 0xa00000021afd2000-0xa00000021afd9fff flags: 0x10005 pflags: 0 state: RUNNING (CPU 0) priority: 52 container lock: sched lock 0 (0xe000003400ad5080) With the thread ID, 100001 in the example above, type: db> thread 100001 This should give you something like: [ thread pid 1 tid 100001 ] kdb_enter+0x92: [I2] addl r14=0xffffffffffe279b8,gp ;; Then type the following for a backtrace: db> bt FYI, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-current@FreeBSD.ORG Sat Apr 3 04:10:41 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2563F106566B; Sat, 3 Apr 2010 04:10:41 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 82F808FC17; Sat, 3 Apr 2010 04:10:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o333vIQW064868; Sat, 3 Apr 2010 14:57:18 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 3 Apr 2010 14:57:18 +1100 (EST) From: Ian Smith To: Doug Barton In-Reply-To: <4BB64088.8030003@FreeBSD.org> Message-ID: <20100403143804.M35463@sola.nimnet.asn.au> References: <11351.1270198507@critter.freebsd.dk> <4BB64088.8030003@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Mailman-Approved-At: Sat, 03 Apr 2010 04:56:19 +0000 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-arch@freebsd.org Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2010 04:10:41 -0000 On Fri, 2 Apr 2010, Doug Barton wrote: > So first of all, yes Virginia, this was an April Fool's Day joke. To > both those for whom this post created a false sense of despair, and > (perhaps more importantly) to those for whom it created a false sense of > joy, my apologies. :) And for the record, everything from here on is > "just the facts." You're a proper bastard, Doug - in the strictly affectionate Aussie sense of the term. Talk about stirring the possum! Had me fired up to figure out how to add a choice menu to sysinstall .. Good to hear the DNSSEC stuff is coming along, however ponderously. KUTGW, Ian From owner-freebsd-current@FreeBSD.ORG Sat Apr 3 06:42:48 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1B2C11065673; Sat, 3 Apr 2010 06:42:48 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by mx1.freebsd.org (Postfix) with ESMTP id 8156E8FC21; Sat, 3 Apr 2010 06:42:47 +0000 (UTC) Received: by qw-out-2122.google.com with SMTP id 3so910772qwe.7 for ; Fri, 02 Apr 2010 23:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:x-mailer :subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc; bh=0/zXFXIwFGd/89S946cC8du1WDsVaxpLCMP44n3djfg=; b=FM3lONotc0ScvWRqCYXr4EyoS1H0pPQAPROzqTETEEjG6EwiLsnNH5ofuxVO3kp7KK upbCO9nclJbFuJnMwO5zZ/WIGU3/lDyKYfUMBxX0ZG5vukRQBFk2rj6dTCKyc1eD5qbg tryHC0IKk1x9CVyAry8DKi6JFem609M2Yk58o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:x-mailer:subject:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc; b=dtmRjvNZGfDJaZzX5Q6HzYT0Gi/ksOGch/eDTtkIAqBh4kVM7pAmfIkGvTYF6R0z3Y wK+aNqACMK5/LYh1tdN8TQYs3IroRIGnE/dKEuf0xlp8J/+RgG6Cdr9qFaJU/QLAHjTV 3hm5igiuXI+tSF1e75D8TjKJWk13mtS9qYaiI= Received: by 10.224.71.130 with SMTP id h2mr1025528qaj.246.1270276966765; Fri, 02 Apr 2010 23:42:46 -0700 (PDT) Received: from [192.168.0.7] ([72.14.241.40]) by mx.google.com with ESMTPS id 7sm901679qwf.44.2010.04.02.23.42.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 23:42:45 -0700 (PDT) From: Arseny Nasokin To: Doug Barton In-Reply-To: <4BB64088.8030003@FreeBSD.org> X-Mailer: iPhone Mail (7D11) References: <11351.1270198507@critter.freebsd.dk> <4BB64088.8030003@FreeBSD.org> Message-Id: <22D22D6D-8976-4EBD-9351-965A33544013@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7D11) Date: Sat, 3 Apr 2010 10:42:40 +0400 Cc: "freebsd-current@FreeBSD.org" , "freebsd-stable@FreeBSD.org" , "freebsd-arch@FreeBSD.org" Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2010 06:42:48 -0000 On 2 Apr 2010, at 23:07, Doug Barton wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > So first of all, yes Virginia, this was an April Fool's Day joke. To > both those for whom this post created a false sense of despair, and > (perhaps more importantly) to those for whom it created a false > sense of > joy, my apologies. :) And for the record, everything from here on is > "just the facts." > > I have always said that I will remove BIND from the base when there is > clear community consensus to do so, and I stand by that. However the > discussion always seems to go along the lines that this thread did. A > vocal group who say, "YES!" and then a lot of people who want the > resolution tools (dig, host, nslookup) to stay, and the other end of > the > bell-shaped curve with those who like having the whole thing in the > base. Toss in a few choruses of "The whole base should be more > modular," > (a viewpoint with which I have a great deal of sympathy btw) and the > soup is pretty well complete. > > In regard to the tools issue, the problem is that you need a pretty > good > majority of the code in order to build them. They require the > libraries > to be built, and once you've done that, you might as well do the > rest. :) > > Total size of code in: > contrib/bind9: 14.0M > contrib/bind9/lib: 7.6M > contrib/bind9/bin: 2.5M > contrib/bind9/bin/dig: 0.4M > > The last is the directory that has the code for all 3 resolution > tools, > FYI. > > Therefore I think that the status quo of having it all in there, and > knobs to turn off the bits you don't want is a good one since it seems > to please the majority of our users. I will continue to maintain the > bind-tools port though, that's something that's been requested often, > and I think it's a good thing to have for those who want a different > DNS > solution but still want access to those tools in a fairly painless > manner. And of course the ability to easily change/upgrade/manage what > version of BIND you use via the ports will continue to be a key > component of how we deal with this going forward. > > Of course, the release synchronization problems I described in both > the > original post and the AFD post are real, so stay tuned. :) > > Answers to DNSSEC concerns below. > > On 4/2/2010 3:52 AM, Robert Watson wrote: >> With an eye on the date of Doug's suggestive e-mail, I actually am >> concerned >> that we maintain support for DNSSEC validation in the base system. >> If this >> can be accomplished by keeping DNS debugging tools and the >> lightweight >> resolver in the base, then I'm fine with that world view. However, >> if we >> can't do DNSSEC record validation without installing the BIND >> package, then >> that worries me. > > Unfortunately this answer is more complicated than I'd like it to > be. In > general, DNS resolution requires 4 components (and yes, this is pretty > well simplified, but I think the illustration serves to clarify my > point): > 1. An end-user application that makes a request > 2. A stub resolver located on the local system > 3. A resolving name server > 4. An authoritative name server > > At this time the DNSSEC protocol only clearly addresses the behavior > of > 4, and partially addresses the behavior of 3. There is no protocol > specification for 1 or 2. So in general if you want to be able to > validate DNSSEC signatures on the local system the only option > available > to you is to run a local validating resolver. It doesn't have to be > BIND, unbound is also a good candidate, but you have to run something > locally to be sure that the response(s) you've received are valid. > > Now that said, if you have a special purpose in mind to validate > records > in a specific domain (or specific few domains) for which you are > prepared to individually manage trust anchors (the generic term of art > for DNSSEC keys) then you could do that using dig alone. However that > solution would not scale well, and I wouldn't recommend it for a > critical piece of the base or ports. > >> As we go forward, DNSSEC is going to become increasingly important, >> and being >> unable to bootstrap a system will be a problem, and it will become an >> increasingly critical part of the security bootstrap process for >> networked >> systems. > > Since your description above is generic, I will generically agree with > you. :) I think as time goes on and more intelligence about DNSSEC is > pushed to the edges I think it will be possible to have a validating > stub resolver, and on a trusted network reasonable to rely on an > external validating resolving name server. However there's an awful > lot > of supposition there, and as I said above, the spec doesn't even exist > yet, never mind the code. > >> While some DNSSEC folk consider it anathema ("DNS is not a directory >> service!"), the ability to securely distribute keying material via >> an existing >> network service has enourmous value: for example, early DNSSEC >> prototypes in >> the late 1990's/early 2000's included SSH key distribution via cert >> records in >> DNSSEC. > > The CERT record still exists, although not for ssh. See > http://tools.ietf.org/html/rfc4398. For ssh fingerprints there is the > SSHFP record, http://tools.ietf.org/html/rfc4255. And there are always > TXT records. :) > > Now all THAT said, there is an element of DNSSEC that I am rather > strongly leaning toward putting in the ports, trust anchor > configuration. Currently you have essentially 2 choices for DNSSEC > validation, manually configure trust anchors, or use a DNS Lookaside > Validation (DLV) service, of which the most popular is ISC's. Both > options have their benefits and their drawbacks, which are outside the > scope of this post. OTOH, if things continue going according to plan > the > root zone will be signed with real DNSSEC keys in July. That will make > it possible to do "regular" DNSSEC validation for those zones that are > signed from the root down by only configuring one trust anchor, the > root > zone key. (If you need to validate something on a "secure island," > i.e., > one or more parent zones is not signed, you are back to the first 2 > choices, but once again, out of scope.) > > In the ideal world the root zone trust anchor would function like the > root.hints file does now. It is stable (not updated often) and failure > to update it in a timely manner would not be catastrophic. > Unfortunately, the first is not guaranteed, and the latter is the > opposite of the truth. There has already been on incident where an OS > distribution had shipped with trust anchors manually configured and > when > they became outdated hilarity ensued. I would like to avoid that for > our > users. > > At this time my plan is to add hooks for "easy" incorporation of > DNSSEC > validation into the base named.conf, with instructions for how to > install the port/package, the importance of keeping it up to date, > etc. > Before I make any changes I'll be seeking input from experts in the > DNSSEC community and posting something a little more focused on - > arch at > least. If the release engineer or security officer teams have > "something" in mind for FreeBSD that will require DNSSEC, we'll have > to > coordinate efforts on this, but I don't imagine it will be too > difficult > even with a bind-dnssec-config port. > > > hth, > > Doug > > - -- > > ... and that's just a little bit of history repeating. > -- Propellerheads > > Improve the effectiveness of your Internet presence with > a domain name makeover! http://SupersetSolutions.com/ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.12 (MingW32) > > iEYEAREDAAYFAku2QIgACgkQyIakK9Wy8PvMtQCeIu/32RGMIC/798V15aO/sjP3 > 788AoPf53oxsgutXPriuLOszcp2DBKc1 > =hUnq > -----END PGP SIGNATURE----- > _______________________________________________ > 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 Sat Apr 3 06:54:49 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F88F106564A; Sat, 3 Apr 2010 06:54:49 +0000 (UTC) (envelope-from eirnym@gmail.com) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.221.181]) by mx1.freebsd.org (Postfix) with ESMTP id A7A1D8FC08; Sat, 3 Apr 2010 06:54:48 +0000 (UTC) Received: by qyk11 with SMTP id 11so2676644qyk.13 for ; Fri, 02 Apr 2010 23:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:in-reply-to:x-mailer :subject:references:message-id:content-type :content-transfer-encoding:mime-version:date:cc; bh=ulJG/R22WjaY0f5rjSU15JsA2bUEeuaKjpX99z4/ZAg=; b=Pta3Dklre2x8oFIWDzEEhYR3+ZxZ+ZKUW+G0gi1C3C7oxnZRypElO/6mUXObQ0N8q9 SFpdZV/NqAxIulNFmgj2OQqwwHrBQf55T0q17+dHIxb7Fv+pZHnZo36K/yVjbTSm5QRT jLgPu760rZe78kZe+nKaoLAysIpIEg2Lp35tw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:in-reply-to:x-mailer:subject:references:message-id :content-type:content-transfer-encoding:mime-version:date:cc; b=azEpEqvkmnJcy9PODwjpqCE8fLA6TdTW5bNBQ4uzQaQrT8h6ZIfFdaPuSqD7iZQAdi ThTeIfBPPtB6vUf/dXor74V0nuXPPf3A6+ANKEAMV03ZimuagUzY+3zXlxAU74yLVkpo rbWTUUZeiFvT2/Xokfjamhmbhq+/6qOdTXUVM= Received: by 10.224.55.65 with SMTP id t1mr1029004qag.313.1270277687954; Fri, 02 Apr 2010 23:54:47 -0700 (PDT) Received: from [192.168.0.7] ([72.14.241.33]) by mx.google.com with ESMTPS id 6sm10714940qwd.27.2010.04.02.23.54.45 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 23:54:46 -0700 (PDT) From: Arseny Nasokin To: Doug Barton In-Reply-To: <4BB64088.8030003@FreeBSD.org> X-Mailer: iPhone Mail (7D11) References: <11351.1270198507@critter.freebsd.dk> <4BB64088.8030003@FreeBSD.org> Message-Id: <741A5195-385B-42A1-90FE-3B6EBC6956A3@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 7D11) Date: Sat, 3 Apr 2010 10:54:44 +0400 Cc: "freebsd-current@FreeBSD.org" , "freebsd-stable@FreeBSD.org" , "freebsd-arch@FreeBSD.org" Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2010 06:54:49 -0000 On 2 Apr 2010, at 23:07, Doug Barton wrote: > > Therefore I think that the status quo of having it all in there, and > knobs to turn off the bits you don't want is a good one since it seems > to please the majority of our users. I will continue to maintain the > bind-tools port though, that's something that's been requested often, > and I think it's a good thing to have for those who want a different > DNS > solution but still want access to those tools in a fairly painless > manner. And of course the ability to easily change/upgrade/manage what > version of BIND you use via the ports will continue to be a key > component of how we deal with this going forward. > > Of course, the release synchronization problems I described in both > the > original post and the AFD post are real, so stay tuned. :) > Some about BIND and XML support via port. As I know, world is enough to build everything in it, but support build something in world, which depends on some port is not good idea. Yes, it useful option, but I think it should be in port(which has much more flexibility), not in world. > > hth, > > Doug > > - -- > > ... and that's just a little bit of history repeating. > -- Propellerheads > > Improve the effectiveness of your Internet presence with > a domain name makeover! http://SupersetSolutions.com/ > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.12 (MingW32) > > iEYEAREDAAYFAku2QIgACgkQyIakK9Wy8PvMtQCeIu/32RGMIC/798V15aO/sjP3 > 788AoPf53oxsgutXPriuLOszcp2DBKc1 > =hUnq > -----END PGP SIGNATURE----- > _______________________________________________ > 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 Sat Apr 3 09:45:05 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3590F106566C for ; Sat, 3 Apr 2010 09:45:05 +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 ESMTP id D7CDD8FC1C for ; Sat, 3 Apr 2010 09:45:04 +0000 (UTC) Received: (qmail 15967 invoked by uid 399); 3 Apr 2010 09:45:03 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 3 Apr 2010 09:45:03 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BB70E1E.3090102@FreeBSD.org> Date: Sat, 03 Apr 2010 02:45:02 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2010 09:45:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 hrs@ has been doing some great work on bringing IPv6 support up to par with IPv4, and deserves a lot of credit for that work. Included in those changes were changes to the traditional semantics of how ipv6_enable works. That variable was previously overloaded to allow general IPv6 configuration support, rtsol autoconfiguration, and preference of IPv6 vs. IPv4. The ipv6_prefer variable was introduced to handle the first and third functions, and ipv6_enable was deprecated. In previous discussions on various lists (including this one) there seems to have been general consensus on the following ideas: 1. There should be an ipv6_enable knob to easily turn IPv6 configuration on and off when INET6 is in the kernel. I think the value of this kind of knob is obvious, but I'd be happy to elaborate if that is necessary. 2. ipv6_network_interfaces should be set to AUTO, the same way that it is for IPv4. 3. Each IPv6 interface (other than lo0) should be configured with rtsol by default, but manual configuration should still be possible. The first question is, are the defaults listed above reasonable? I'd like to see some sort of consensus on this before we proceed with any changes. Next, I have a patch that implements the defaults suggested above that I want to offer for testing and review: http://people.freebsd.org/~dougb/v6-enable.diff The patch has several features in addition to changing the defaults. The network.subr changes in particular are difficult to visualize via the diff, it's probably easier to apply it in a test tree and review it that way. 1. Clean up and optimize the following functions: ifconfig_up (the ipv6 elements) noafif ipv6if ipv6_autoconfif The general concepts of the cleanups were to move the "easy" tests earlier in the functions, consolidate duplicate code, and of course to make things work with the above-listed defaults. 2. Convert noafif() to use is_wired_interface() instead of listing wireless interfaces explicitly. 3. In rc.d/netoptions, add code for an ipv6_privacy option to use RFC 4193 style privacy addresses (this is what windows does by default, FYI). 4. In /etc/defaults/rc.conf: Add ipv6_enable back, default to off. If a user has INET6 in the kernel (which it does by default) no external interfaces will be configured unless the user enables it. The lo0 interface is always configured if INET6 is in the kernel. Set ipv6_network_interfaces to AUTO. Switch ipv6_prefer to YES. If ipv6_enable is not set this will have no effect. 5. Document all of this in rc.conf.5. Enjoy, Doug - -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEAREDAAYFAku3Dh4ACgkQyIakK9Wy8Pur8ACg9du7VjeEy5nxfeP1/Ij6RDQc nqgAoLfOdoOGY48MzW7OOZMWRsBKMe+g =S8zx -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Sat Apr 3 10:15:56 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAD4A1065670; Sat, 3 Apr 2010 10:15:56 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [212.12.50.234]) by mx1.freebsd.org (Postfix) with ESMTP id 81D8F8FC0C; Sat, 3 Apr 2010 10:15:56 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id BE5A159C48; Sat, 3 Apr 2010 12:15:54 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Stefan Bethke In-Reply-To: Date: Sat, 3 Apr 2010 12:15:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3175D5A3-B013-4E86-A46A-461D70BD9762@lassitu.de> References: <4BB59CFC.90101@elischer.org> To: Randy Bush X-Mailer: Apple Mail (2.1078) Cc: FreeBSD Net , FreeBSD Current Subject: Re: bridged wlan/ether still the same X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2010 10:15:56 -0000 Am 02.04.2010 um 09:45 schrieb Randy Bush: > it's the bridge that worries me. took me a while to make it work It looks sane to me. Here's my slightly more convoluted setup = (8-stable): cloned_interfaces=3D"bridge0 tap0 vlan1 vlan2 vlan3 gif0" ifconfig_bridge0=3D"ether 02:00:00:00:00:01 addm tap0 addm vlan1" ifconfig_bridge0_alias0=3D"inet 44.128.65.1/26" ifconfig_em0=3D"up" ifconfig_vlan1=3D"vlandev em0 vlan 1" ifconfig_vlan2=3D"44.128.65.249/29 vlandev em0 vlan 2" ifconfig_vlan3=3D"172.23.54.1/24 vlandev em0 vlan 3" ifconfig_tap0=3D"up" I've set bridge0's MAC address to avoid sillyness with a cheap desktop = switch that would get confused on reboots. HTH, Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-current@FreeBSD.ORG Sat Apr 3 11:52:40 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 35A2B106564A; Sat, 3 Apr 2010 11:52:40 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper-int.allbsd.org [IPv6:2001:2f0:104:e002::2]) by mx1.freebsd.org (Postfix) with ESMTP id C9A8E8FC16; Sat, 3 Apr 2010 11:52:39 +0000 (UTC) Received: from delta.allbsd.org (p3177-ipbf416funabasi.chiba.ocn.ne.jp [123.225.92.177]) (authenticated bits=128) by mail.allbsd.org (8.14.3/8.14.3) with ESMTP id o33BqEUo073585; Sat, 3 Apr 2010 20:52:25 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (alph.allbsd.org [192.168.0.10]) (authenticated bits=0) by delta.allbsd.org (8.13.4/8.13.4) with ESMTP id o33BqA9e007299; Sat, 3 Apr 2010 20:52:13 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sat, 03 Apr 2010 20:51:40 +0900 (JST) Message-Id: <20100403.205140.26884732.hrs@allbsd.org> To: dougb@FreeBSD.org From: Hiroki Sato In-Reply-To: <4BB70E1E.3090102@FreeBSD.org> References: <4BB70E1E.3090102@FreeBSD.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sat_Apr__3_20_51_40_2010_788)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.95.3 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.3 (mail.allbsd.org [133.31.130.32]); Sat, 03 Apr 2010 20:52:31 +0900 (JST) X-Spam-Status: No, score=0.4 required=13.0 tests=AWL,CONTENT_TYPE_PRESENT, SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on gatekeeper.allbsd.org Cc: freebsd-current@FreeBSD.org Subject: Re: ipv6_enable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2010 11:52:40 -0000 ----Security_Multipart(Sat_Apr__3_20_51_40_2010_788)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Doug Barton wrote in <4BB70E1E.3090102@FreeBSD.org>: do> 1. There should be an ipv6_enable knob to easily turn IPv6 configuration do> on and off when INET6 is in the kernel. I think the value of this kind do> of knob is obvious, but I'd be happy to elaborate if that is necessary. There were reasons related to technical difficulty and inconsistency (and a bit my preference) to drop $ipv6_enable. First, we are overly abusing $xxx_enable knob even when no corresponding rc.d/xxx file. I think $xxx_enable knob should be used only for rc.d/xxx whenever possible. It is intuitive, and what the original design of rc.d scripts intended. Although this would be another topic, it was one of the motivation for me to remove the knob. Second, if people need a way to disable IPv6 protocol, they have already the way; no IPv6 configuration in /etc/rc.conf. If you need a handy way for on-and-off, separating the IPv6 configuration from rc.conf to rc.conf.ipv6 and putting a line ". /etc/rc.conf.ipv6" into /etc/rc.conf should be enough, for example. After all, protocols cannot be disabled only by using rc.d scripts. If we really need the way to do that, we have to have kernel-level knobs like sysctl or ifconfig flag. Also, we should not consider IPv6 as special. Why we have to have $ipv6_enable while we don't have $ipv4_enable? I am using INET6-only machines for years and the process removing the IPv4 dependency in the userland was really hard, but I believe "no line for the protocol in /etc/rc.conf means no configuration" is a policy which can be implemented and can work fine even there. do> 2. ipv6_network_interfaces should be set to AUTO, the same way that it do> is for IPv4. I agree with this change, but I am still not sure if we should have $ipv6_network_interfaces itself. The current implementation is equivalent to always AUTO while the default value is set NONE (see ipv6if()). The reason I changed it to NONE simply because we need to extend list_net_interfaces() for per-AF listing first. While I added some support for SLAAC, it is still not enough and not used yet. Setting $ipv6_network_interfaces (or $network_interfaces) to non-AUTO value is for narrowing down the interface list which the rc.d scripts handle, but I think this should be okay with non-AF-specific one only for the same reason as not having $ipv6_enable. Anyway, the current one is incomplete. Changing to "AUTO" is harmless unless we do not use list_net_interfaces() to list interfaces for some kind of automatic configuration. do> 3. Each IPv6 interface (other than lo0) should be configured with rtsol do> by default, but manual configuration should still be possible. Why accepting RA and sending RS by default? I object this because it is too problematic. The KAME implementation does not care about receiving RAs from multiple networks and we cannot control the accept-or-not. My patch for per-IF ACCEPT_RTADV handling was the first step, but still I can imagine cases which cause surprising results for sysadmins. My opinion is: receiving RA must be enabled only when explicitly specified. If the box is a "host" with only one physical interface and there is no network configuration it might be good to send RS for SLAAC as the last resort, but it is still risky. For IPv4 we do not invoke dhclient by default. This is not so simple. A network interface can appears by cloning or adding a new NIC into the system, and then devd(8) invokes rc.d/netif via /etc/pccard_ether asynchronously. If the kernel accepts RAs by default, these dynamically-added ones will also become RA-receiving interfaces. Pseudo ifconfig flags like NORTADV don't work for them. Unconditionally accepting RAs is harmful, but we still have limited countermeasures. While I recently added DEFROUTE_RTADV flag in my private branch /user/hrs/ipv6 as another step for that, I believe the disadvantages outweigh the positives at this moment. -- Hiroki ----Security_Multipart(Sat_Apr__3_20_51_40_2010_788)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEABECAAYFAku3K8wACgkQTyzT2CeTzy35pQCgpn2TK0AL7ecJRN6Iq2NYe3Uz nEUAnAkTCr3NHgdN4A3wg6vqIax06zGq =Whzt -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Apr__3_20_51_40_2010_788)---- From owner-freebsd-current@FreeBSD.ORG Sat Apr 3 13:57:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 483451065674; Sat, 3 Apr 2010 13:57:12 +0000 (UTC) (envelope-from mail25@bzerk.org) Received: from ei.bzerk.org (tunnel490.ipv6.xs4all.nl [IPv6:2001:888:10:1ea::2]) by mx1.freebsd.org (Postfix) with ESMTP id C66B38FC1C; Sat, 3 Apr 2010 13:57:11 +0000 (UTC) Received: from ei.bzerk.org (BOFH@localhost [127.0.0.1]) by ei.bzerk.org (8.14.3/8.14.3) with ESMTP id o33Dv3kY063317; Sat, 3 Apr 2010 15:57:04 +0200 (CEST) (envelope-from mail25@bzerk.org) Received: (from bulk@localhost) by ei.bzerk.org (8.14.3/8.14.3/Submit) id o33Dv3OW063316; Sat, 3 Apr 2010 15:57:03 +0200 (CEST) (envelope-from mail25@bzerk.org) Date: Sat, 3 Apr 2010 15:57:03 +0200 From: Ruben de Groot To: Charles Sprickman Message-ID: <20100403135703.GA63262@ei.bzerk.org> Mail-Followup-To: Ruben de Groot , Charles Sprickman , Reko Turja , "freebsd-current+AEA-FreeBSD.ORG" , "freebsd-stable@FreeBSD.org" , "freebsd-arch@FreeBSD.org" References: <20100402165002.71A8B1CC09@ptavv.es.net> <77FCD9C7615944DBBD3369EC4E5A5C94@rivendell> <2972DD89-7D7D-4869-9280-305BACBFEC5A@bway.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2972DD89-7D7D-4869-9280-305BACBFEC5A@bway.net> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on ei.bzerk.org X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (ei.bzerk.org [127.0.0.1]); Sat, 03 Apr 2010 15:57:08 +0200 (CEST) Cc: Reko Turja , "freebsd-current+AEA-FreeBSD.ORG" , "freebsd-stable@FreeBSD.org" , "freebsd-arch@FreeBSD.org" Subject: Re: Results of BIND RFC X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2010 13:57:12 -0000 On Fri, Apr 02, 2010 at 02:08:27PM -0400, Charles Sprickman typed: > Can we do sendmail next April 1? Better yet, defer all questions about moving out of the base system by referring to the Grand Discussion that'll take place *next year* on the first of april. From owner-freebsd-current@FreeBSD.ORG Sat Apr 3 14:17:12 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 122C5106564A for ; Sat, 3 Apr 2010 14:17:11 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3953E8FC15 for ; Sat, 3 Apr 2010 14:17:10 +0000 (UTC) Received: by wwb24 with SMTP id 24so1804136wwb.13 for ; Sat, 03 Apr 2010 07:17:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=UVoyCZViL8V12VNSpOyrbXcWdpPzZxQIq6hjnxJ3T44=; b=P1cqSlw7o0nmCfXkg6SFKKPjagynPo3P3zz5SwMdo7SPzUueQBmqRYDkEN9JG9twxu DIVsrKt2CTMmSL/Af8i6Ro+sNUzp+sP+pnF7oHBU+bhm8SW0gEkfE++twnEC52KLT8BS dF/VmBfXzwsZ3nkgEc22pVQoiivacyabAfofs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OLLSQ7nUB8AYiGBNsvvL4ehC6skSzAnND6eK8YJtNoygak9g0Bs5NsCoYovyAFWUFS t+vUh+ZsO8PQbeUrIuqG7RMkE1RtEHcbd6CbftfUl3xDIbz7+Fm7miLba5TdfiU/qLE+ Bnz1NNbqT5flbe8P8F54UYmkbDRfp7X7/t1D0= MIME-Version: 1.0 Received: by 10.216.1.70 with HTTP; Sat, 3 Apr 2010 07:17:09 -0700 (PDT) In-Reply-To: <4BB64615.9060601@freebsd.org> References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <20100329222920.5eef6395@r500.local> <4BB111D4.8060809@freebsd.org> <20100330173637.202b4b1e@r500.local> <4BB21BBA.7030407@freebsd.org> <4BB360A1.7020309@freebsd.org> <20100402125721.50b3ba4f@r500.local> <4BB5D06C.8080902@freebsd.org> <4BB644CA.4000807@freebsd.org> <4BB64615.9060601@freebsd.org> Date: Sat, 3 Apr 2010 14:17:09 +0000 Received: by 10.216.93.79 with SMTP id k57mr2035081wef.161.1270304230055; Sat, 03 Apr 2010 07:17:10 -0700 (PDT) Message-ID: From: Paul B Mahol To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 Cc: Kostik Belousov , freebsd-current@freebsd.org, Bruce Evans Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2010 14:17:12 -0000 On 4/2/10, Andriy Gapon wrote: > on 02/04/2010 22:26 Andriy Gapon said the following: >> >> OK, I did it again. >> I tested the below patch using the scenario described above. >> Could you please review and/or test this patch? >> If you like it and it works, I can commit it. >> Thanks! >> >> --- a/sbin/newfs_msdos/newfs_msdos.c >> +++ b/sbin/newfs_msdos/newfs_msdos.c >> @@ -427,6 +427,9 @@ main(int argc, char *argv[]) >> if (bpb.bpbBytesPerSec < MINBPS) >> errx(1, "bytes/sector (%u) is too small; minimum is %u", >> bpb.bpbBytesPerSec, MINBPS); >> + bpb.bpbSecPerClust /= (bpb.bpbBytesPerSec / MINBPS); >> + if (bpb.bpbSecPerClust == 0) >> + bpb.bpbSecPerClust = 1; >> if (!(fat = opt_F)) { >> if (opt_f) >> fat = 12; >> > > And here is a safer one (in case of a huge sector size > 32KB). > I will appreciate any testing with real media that you might have. > > diff --git a/sbin/newfs_msdos/newfs_msdos.c b/sbin/newfs_msdos/newfs_msdos.c > index 955c3a5..3f2778d 100644 > --- a/sbin/newfs_msdos/newfs_msdos.c > +++ b/sbin/newfs_msdos/newfs_msdos.c > @@ -427,6 +427,12 @@ main(int argc, char *argv[]) > if (bpb.bpbBytesPerSec < MINBPS) > errx(1, "bytes/sector (%u) is too small; minimum is %u", > bpb.bpbBytesPerSec, MINBPS); > + bpb.bpbSecPerClust /= (bpb.bpbBytesPerSec / MINBPS); > + if (bpb.bpbSecPerClust == 0) > + bpb.bpbSecPerClust = 1; > + if (bpb.bpbSecPerClust * bpb.bpbBytesPerSec > 32 * 1024) > + errx(1, "bytes per sector (%u) is greater than 32k", > + bpb.bpbSecPerClust * bpb.bpbBytesPerSec); > if (!(fat = opt_F)) { > if (opt_f) > fat = 12; Works for me, thanks! (I will test compatibility with winXP later) From owner-freebsd-current@FreeBSD.ORG Sat Apr 3 15:07:38 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B94EB1065670 for ; Sat, 3 Apr 2010 15:07:38 +0000 (UTC) (envelope-from tijl@coosemans.org) Received: from mailrelay006.isp.belgacom.be (mailrelay006.isp.belgacom.be [195.238.6.172]) by mx1.freebsd.org (Postfix) with ESMTP id 55E768FC14 for ; Sat, 3 Apr 2010 15:07:37 +0000 (UTC) X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkQGAOv2tkvZiCNZ/2dsb2JhbACDEYxCi3dypiCPPIErgm5uBA Received: from 89.35-136-217.adsl-dyn.isp.belgacom.be (HELO kalimero.tijl.coosemans.org) ([217.136.35.89]) by relay.skynet.be with ESMTP; 03 Apr 2010 17:07:36 +0200 Received: from kalimero.tijl.coosemans.org (kalimero.tijl.coosemans.org [127.0.0.1]) by kalimero.tijl.coosemans.org (8.14.3/8.14.3) with ESMTP id o33F7Zdl004149; Sat, 3 Apr 2010 17:07:35 +0200 (CEST) (envelope-from tijl@coosemans.org) From: Tijl Coosemans To: freebsd-current@freebsd.org Date: Sat, 3 Apr 2010 17:07:33 +0200 User-Agent: KMail/1.9.10 References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <4BB644CA.4000807@freebsd.org> <4BB64615.9060601@freebsd.org> In-Reply-To: <4BB64615.9060601@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <201004031707.34650.tijl@coosemans.org> Cc: Kostik Belousov , Bruce Evans , Andriy Gapon Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2010 15:07:38 -0000 On Friday 02 April 2010 21:31:33 Andriy Gapon wrote: > on 02/04/2010 22:26 Andriy Gapon said the following: >> OK, I did it again. >> I tested the below patch using the scenario described above. >> Could you please review and/or test this patch? >> If you like it and it works, I can commit it. >> Thanks! >> >> --- a/sbin/newfs_msdos/newfs_msdos.c >> +++ b/sbin/newfs_msdos/newfs_msdos.c >> @@ -427,6 +427,9 @@ main(int argc, char *argv[]) >> if (bpb.bpbBytesPerSec < MINBPS) >> errx(1, "bytes/sector (%u) is too small; minimum is %u", >> bpb.bpbBytesPerSec, MINBPS); >> + bpb.bpbSecPerClust /= (bpb.bpbBytesPerSec / MINBPS); >> + if (bpb.bpbSecPerClust == 0) >> + bpb.bpbSecPerClust = 1; >> if (!(fat = opt_F)) { >> if (opt_f) >> fat = 12; >> > > And here is a safer one (in case of a huge sector size > 32KB). > I will appreciate any testing with real media that you might have. > > diff --git a/sbin/newfs_msdos/newfs_msdos.c b/sbin/newfs_msdos/newfs_msdos.c > index 955c3a5..3f2778d 100644 > --- a/sbin/newfs_msdos/newfs_msdos.c > +++ b/sbin/newfs_msdos/newfs_msdos.c > @@ -427,6 +427,12 @@ main(int argc, char *argv[]) > if (bpb.bpbBytesPerSec < MINBPS) > errx(1, "bytes/sector (%u) is too small; minimum is %u", > bpb.bpbBytesPerSec, MINBPS); > + bpb.bpbSecPerClust /= (bpb.bpbBytesPerSec / MINBPS); > + if (bpb.bpbSecPerClust == 0) > + bpb.bpbSecPerClust = 1; > + if (bpb.bpbSecPerClust * bpb.bpbBytesPerSec > 32 * 1024) > + errx(1, "bytes per sector (%u) is greater than 32k", > + bpb.bpbSecPerClust * bpb.bpbBytesPerSec); > if (!(fat = opt_F)) { > if (opt_f) > fat = 12; Wikipedia's article on FAT has this to say about the maximum size of clusters: "The limit on partition size was dictated by the 8-bit signed count of sectors per cluster, which had a maximum power-of-two value of 64. With the standard hard disk sector size of 512 bytes, this gives a maximum of 32 KB clusters, thereby fixing the "definitive" limit for the FAT16 partition size at 2 gigabytes. On magneto-optical media, which can have 1 or 2 KB sectors instead of 1/2 KB, this size limit is proportionally larger. Much later, Windows NT increased the maximum cluster size to 64 KB by considering the sectors-per-cluster count as unsigned. However, the resulting format was not compatible with any other FAT implementation of the time, and it generated greater internal fragmentation. Windows 98 also supported reading and writing this variant, but its disk utilities did not work with it." I'm not sure the second paragraph is worth supporting, but the first seems to say that 32k limit you have in your patch only applies to disks with 512 byte sectors. For disks with larger sectors it would be proportionally larger. From owner-freebsd-current@FreeBSD.ORG Sat Apr 3 15:27:20 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B56941065672 for ; Sat, 3 Apr 2010 15:27:20 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 03B728FC0C for ; Sat, 3 Apr 2010 15:27:19 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA14768; Sat, 03 Apr 2010 18:27:17 +0300 (EEST) (envelope-from avg@icyb.net.ua) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ny5Fk-0008yV-Oh; Sat, 03 Apr 2010 18:27:16 +0300 Message-ID: <4BB75E54.4080405@icyb.net.ua> Date: Sat, 03 Apr 2010 18:27:16 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Tijl Coosemans References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <4BB644CA.4000807@freebsd.org> <4BB64615.9060601@freebsd.org> <201004031707.34650.tijl@coosemans.org> In-Reply-To: <201004031707.34650.tijl@coosemans.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2010 15:27:20 -0000 on 03/04/2010 18:07 Tijl Coosemans said the following: > > I'm not sure the second paragraph is worth supporting, but the first > seems to say that 32k limit you have in your patch only applies to > disks with 512 byte sectors. For disks with larger sectors it would > be proportionally larger. Last sentence is your own conclusion I guess? Please read this whole thread to see why it doesn't work that way in practice. At least for present FreeBSD. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Apr 3 15:47:24 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB2131065677; Sat, 3 Apr 2010 15:47:24 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id E76818FC13; Sat, 3 Apr 2010 15:47:23 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA14943; Sat, 03 Apr 2010 18:47:21 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ny5ZA-000906-S6; Sat, 03 Apr 2010 18:47:20 +0300 Message-ID: <4BB76308.6010309@freebsd.org> Date: Sat, 03 Apr 2010 18:47:20 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100321) MIME-Version: 1.0 To: Tijl Coosemans References: <3a142e751003190508x6a06868ene2e8fd9ddd977f66@mail.gmail.com> <4BB644CA.4000807@freebsd.org> <4BB64615.9060601@freebsd.org> <201004031707.34650.tijl@coosemans.org> <4BB75E54.4080405@icyb.net.ua> In-Reply-To: <4BB75E54.4080405@icyb.net.ua> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Konstantin Belousov , Bruce Evans Subject: Re: newfs_msdos and DVD-RAM X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2010 15:47:24 -0000 on 03/04/2010 18:27 Andriy Gapon said the following: > on 03/04/2010 18:07 Tijl Coosemans said the following: >> I'm not sure the second paragraph is worth supporting, but the first >> seems to say that 32k limit you have in your patch only applies to >> disks with 512 byte sectors. For disks with larger sectors it would >> be proportionally larger. > > Last sentence is your own conclusion I guess? > Please read this whole thread to see why it doesn't work that way in practice. > At least for present FreeBSD. OTOH, perhaps you are right and we should consider either bumping MAXBSIZE or retiring it. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Sat Apr 3 21:08:04 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF5121065761 for ; Sat, 3 Apr 2010 21:08:04 +0000 (UTC) (envelope-from akirchhoff135014@comcast.net) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by mx1.freebsd.org (Postfix) with ESMTP id 919658FC08 for ; Sat, 3 Apr 2010 21:08:04 +0000 (UTC) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta03.westchester.pa.mail.comcast.net with comcast id 18dn1e0051HzFnQ538upye; Sat, 03 Apr 2010 20:54:49 +0000 Received: from scroll.ashke.com ([68.45.22.62]) by omta14.westchester.pa.mail.comcast.net with comcast id 18up1e0011LNQfY3a8upYh; Sat, 03 Apr 2010 20:54:49 +0000 Date: Sat, 3 Apr 2010 16:54:47 -0400 From: Adam K Kirchhoff To: freebsd-current@freebsd.org Message-ID: <20100403165447.73c9d370@scroll.ashke.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; i386-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: iwi problems on -CURRENT (Apr 4. 2010) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2010 21:08:05 -0000 I'm having some problems with iwi on -CURRENT. FreeBSD scroll.ashke.com 9.0-CURRENT FreeBSD 9.0-CURRENT #1: Sat Apr 3 EDT 2010 root@scroll.ashke.com:/usr/obj/usr/src/sys/SCROLL i386 SCROLL is simply GENERIC without INVARIANTS, INVARIANT_SUPPORT, WITNESS, and WITNESS_SKIPSPIN. In loader.conf I have: if_iwi_load="YES" iwi_bss_load="YES" legal.intel_iwi.license_ack=1 In /etc/rc.conf I have: wlans_iwi0="wlan0" ifconfig_wlan0="DHCP wpa" Upon bootup, iwi fails to work with: iwi0: at device 3.0 on pci3 iwi0: [ITHREAD] iwi0: parity error iwi0: timeout waiting for iwi_bss firmware initialization to complete iwi0: could not load boot firmware iwi_bss iwi0: timeout waiting for master According to the iwi man page, "could not load boot firmware" "should not happen" :-) Any thoughts on how to get this working? For what it's worth, I installed FreeBSD on this machine earlier this week, immediately upgraded to -CURRENT (previous installations from the 8-STABLE series on this laptop refused to let any wireless driver connect to the APs at work, so I specifically wanted to see if this had been fixed in -CURRENT), and iwi worked fine for a few days. Then it stopped, though I did not change anything on the system. I updated -CURRENT today to see if doing so would get iwi working again, but it did not. Adam From owner-freebsd-current@FreeBSD.ORG Sat Apr 3 21:15:37 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 12B8E106564A for ; Sat, 3 Apr 2010 21:15:37 +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 ESMTP id 7D1EF8FC0A for ; Sat, 3 Apr 2010 21:15:36 +0000 (UTC) Received: (qmail 29082 invoked by uid 399); 3 Apr 2010 21:15:34 -0000 Received: from localhost (HELO foreign.dougb.net) (dougb@dougbarton.us@127.0.0.1) by localhost with ESMTPAM; 3 Apr 2010 21:15:34 -0000 X-Originating-IP: 127.0.0.1 X-Sender: dougb@dougbarton.us Message-ID: <4BB7AFF7.6010503@FreeBSD.org> Date: Sat, 03 Apr 2010 14:15:35 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.1.9) Gecko/20100330 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-current@FreeBSD.org X-Enigmail-Version: 1.0.1 OpenPGP: id=D5B2F0FB Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: panic: vm_fault: fault on nofault entry, addr: c3dce000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 03 Apr 2010 21:15:37 -0000 This is happening at boot time, but not every time. Yesterday's -current, r206116. core.txt.3 is in freefall:~dougb. #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc05f754f in boot (howto=260) at /usr/local/src/sys/kern/kern_shutdown.c:416 #2 0xc05f7832 in panic (fmt=Variable "fmt" is not available. ) at /usr/local/src/sys/kern/kern_shutdown.c:579 #3 0xc0810598 in vm_fault (map=0xc19b6000, vaddr=3286032384, fault_type=Variable "fault_type" is not available. ) at /usr/local/src/sys/vm/vm_fault.c:255 #4 0xc0866903 in trap_pfault (frame=0xd9bbaa38, usermode=0, eva=3286033576) at /usr/local/src/sys/i386/i386/trap.c:842 #5 0xc08671c3 in trap (frame=0xd9bbaa38) at /usr/local/src/sys/i386/i386/trap.c:533 #6 0xc08498cb in calltrap () at /usr/local/src/sys/i386/i386/exception.s:165 #7 0xc0828ce2 in vm_reserv_alloc_page (object=0xc19a33b8, pindex=3073) at /usr/local/src/sys/vm/vm_reserv.c:320 #8 0xc082220e in vm_page_alloc (object=0xc19a33b8, pindex=3073, req=64) at /usr/local/src/sys/vm/vm_page.c:1086 #9 0xc08109e5 in vm_fault (map=0xc593ae80, vaddr=679325696, fault_type=2 '\002', fault_flags=Variable "fault_flags" is not available. ) at /usr/local/src/sys/vm/vm_fault.c:399 #10 0xc086688e in trap_pfault (frame=0xd9bbad38, usermode=1, eva=679325760) at /usr/local/src/sys/i386/i386/trap.c:832 #11 0xc086700e in trap (frame=0xd9bbad38) at /usr/local/src/sys/i386/i386/trap.c:401 #12 0xc08498cb in calltrap () at /usr/local/src/sys/i386/i386/exception.s:165 #13 0x2a3d02ac in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover! http://SupersetSolutions.com/