From owner-freebsd-current@FreeBSD.ORG Sun Sep 24 01:41:11 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E264616A40F for ; Sun, 24 Sep 2006 01:41:10 +0000 (UTC) (envelope-from fcash@ocis.net) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 875D943D46 for ; Sun, 24 Sep 2006 01:41:10 +0000 (GMT) (envelope-from fcash@ocis.net) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id 021398A01FA for ; Sat, 23 Sep 2006 18:41:08 -0700 (PDT) Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 67389-33 for ; Sat, 23 Sep 2006 18:41:05 -0700 (PDT) Received: from webmail.sd73.bc.ca (unknown [10.10.10.17]) by smtp.sd73.bc.ca (Postfix) with ESMTP id B6CB08A01F2 for ; Sat, 23 Sep 2006 18:41:05 -0700 (PDT) Received: from 24.71.118.34 (SquirrelMail authenticated user fcash) by webmail.sd73.bc.ca with HTTP; Sat, 23 Sep 2006 18:41:05 -0700 (PDT) Message-ID: <60092.24.71.118.34.1159062065.squirrel@webmail.sd73.bc.ca> In-Reply-To: <45030928.6000605@errno.com> References: <45030928.6000605@errno.com> Date: Sat, 23 Sep 2006 18:41:05 -0700 (PDT) From: "Freddie Cash" To: current@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new using ClamAV at sd73.bc.ca Cc: Subject: Re: CFT: ath hal 0.9.18.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2006 01:41:11 -0000 On Sat, September 9, 2006 11:34 am, Sam Leffler wrote: > You can find a new ath hal at: > http://people.freebsd.org/~sam/ath_hal-20060909.tgz > > It's gone through basic testing but not the more extensive testing I > do before a release. > To make use of the new tkip mic keycache support you need to patch > the driver with this diff: > http://people.freebsd.org/~sam/keycache.patch > Should work on both HEAD and RELENG_6 w/o any driver mods. It's most likely that I'm missing something simple in the process, but I can't get this new HAL to work with my 6.1-RELEASE system. If it's as simple as "It only works with RELENG_6 not RELENG_6_1" then I guess I'll wait. Otherwise, here's what happens when I try to use it: - copy /usr/src/sys/contrib/dev/ath to ath.orig - untar and rename the new HAL directory to /usr/src/sys/contrib/dev/ath - run "patch -p0 < keycache.diff" in /usr/src/sys/dev/ath/ - "make clean; make depend; make; make install" in /usr/src/sys/modules/ath gives rm -f export_syms if_ath.ko if_ath.kld if_ath.o if_ath_pci.o @ machine opt_inet.h opt_ath.h pci_if.h bus_if.h device_if.h @ -> /usr/src/sys machine -> /usr/src/sys/i386/include awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h touch opt_inet.h echo > opt_ath.h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I/usr/src/sys/modules/ath/../../contrib/dev/ath/freebsd -I/usr/src/sys/modules/ath/../../contrib/dev/ath -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include /usr/src/sys/modules/ath/../../dev/ath/if_ath.c /usr/src/sys/modules/ath/../../dev/ath/if_ath_pci.c Warning: Object directory not changed from original /usr/src/sys/modules/ath cc -O2 -fno-strict-aliasing -pipe -march=pentium4 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I/usr/src/sys/modules/ath/../../contrib/dev/ath/freebsd -I/usr/src/sys/modules/ath/../../contrib/dev/ath -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/modules/ath/../../dev/ath/if_ath.c /usr/src/sys/modules/ath/../../dev/ath/if_ath.c: In function `ath_attach': /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:296: warning: passing arg 3 of `ath_hal_attach' makes pointer from integer without a cast /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:296: warning: passing arg 4 of `ath_hal_attach' makes pointer from integer without a cast *** Error code 1 Stop in /usr/src/sys/modules/ath. - building the ath_hal module works correctly, althought trying to use it with a stock if_ath module gives ath_hal: 0.9.18.0 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xd0010000-0xd001ffff irq 17 at device 4.0 on pci2 ath0: HAL ABI mismatch detected (HAL:0x6090700 != driver:0x5122200) device_attach: ath0 attach returned 6 Warning: memory type ath_hal leaked memory on destroy (5 allocations, 25984 bytes leaked). warning: KLD '/boot/kernel/if_ath.ko' is newer than the linker.hints file warning: KLD '/boot/kernel/ath_rate.ko' is newer than the linker.hints file warning: KLD '/boot/kernel/ath_hal.ko' is newer than the linker.hints file ---- Freddie Cash fcash@ocis.net From owner-freebsd-current@FreeBSD.ORG Sun Sep 24 01:41:15 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6900316A584 for ; Sun, 24 Sep 2006 01:41:15 +0000 (UTC) (envelope-from fcash@ocis.net) Received: from smtp.sd73.bc.ca (mailtest.sd73.bc.ca [142.24.13.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DE5F43D46 for ; Sun, 24 Sep 2006 01:41:14 +0000 (GMT) (envelope-from fcash@ocis.net) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id A89B78A01F2 for ; Sat, 23 Sep 2006 18:41:14 -0700 (PDT) Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 73796-06 for ; Sat, 23 Sep 2006 18:41:14 -0700 (PDT) Received: from webmail.sd73.bc.ca (unknown [10.10.10.17]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 5A8738A01F4 for ; Sat, 23 Sep 2006 18:41:14 -0700 (PDT) Received: from 24.71.118.34 (SquirrelMail authenticated user fcash) by webmail.sd73.bc.ca with HTTP; Sat, 23 Sep 2006 18:41:14 -0700 (PDT) Message-ID: <60092.24.71.118.34.1159062074.squirrel@webmail.sd73.bc.ca> In-Reply-To: <45030928.6000605@errno.com> References: <45030928.6000605@errno.com> Date: Sat, 23 Sep 2006 18:41:14 -0700 (PDT) From: "Freddie Cash" To: current@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new using ClamAV at sd73.bc.ca Cc: Subject: Re: CFT: ath hal 0.9.18.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2006 01:41:15 -0000 On Sat, September 9, 2006 11:34 am, Sam Leffler wrote: > You can find a new ath hal at: > http://people.freebsd.org/~sam/ath_hal-20060909.tgz > > It's gone through basic testing but not the more extensive testing I > do before a release. > To make use of the new tkip mic keycache support you need to patch > the driver with this diff: > http://people.freebsd.org/~sam/keycache.patch > Should work on both HEAD and RELENG_6 w/o any driver mods. It's most likely that I'm missing something simple in the process, but I can't get this new HAL to work with my 6.1-RELEASE system. If it's as simple as "It only works with RELENG_6 not RELENG_6_1" then I guess I'll wait. Otherwise, here's what happens when I try to use it: - copy /usr/src/sys/contrib/dev/ath to ath.orig - untar and rename the new HAL directory to /usr/src/sys/contrib/dev/ath - run "patch -p0 < keycache.diff" in /usr/src/sys/dev/ath/ - "make clean; make depend; make; make install" in /usr/src/sys/modules/ath gives rm -f export_syms if_ath.ko if_ath.kld if_ath.o if_ath_pci.o @ machine opt_inet.h opt_ath.h pci_if.h bus_if.h device_if.h @ -> /usr/src/sys machine -> /usr/src/sys/i386/include awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h touch opt_inet.h echo > opt_ath.h rm -f .depend mkdep -f .depend -a -nostdinc -D_KERNEL -DKLD_MODULE -I- -I. -I/usr/src/sys/modules/ath/../../contrib/dev/ath/freebsd -I/usr/src/sys/modules/ath/../../contrib/dev/ath -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include /usr/src/sys/modules/ath/../../dev/ath/if_ath.c /usr/src/sys/modules/ath/../../dev/ath/if_ath_pci.c Warning: Object directory not changed from original /usr/src/sys/modules/ath cc -O2 -fno-strict-aliasing -pipe -march=pentium4 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I/usr/src/sys/modules/ath/../../contrib/dev/ath/freebsd -I/usr/src/sys/modules/ath/../../contrib/dev/ath -I. -I@ -I@/contrib/altq -I@/../include -finline-limit=8000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /usr/src/sys/modules/ath/../../dev/ath/if_ath.c /usr/src/sys/modules/ath/../../dev/ath/if_ath.c: In function `ath_attach': /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:296: warning: passing arg 3 of `ath_hal_attach' makes pointer from integer without a cast /usr/src/sys/modules/ath/../../dev/ath/if_ath.c:296: warning: passing arg 4 of `ath_hal_attach' makes pointer from integer without a cast *** Error code 1 Stop in /usr/src/sys/modules/ath. - building the ath_hal module works correctly, althought trying to use it with a stock if_ath module gives ath_hal: 0.9.18.0 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) ath0: mem 0xd0010000-0xd001ffff irq 17 at device 4.0 on pci2 ath0: HAL ABI mismatch detected (HAL:0x6090700 != driver:0x5122200) device_attach: ath0 attach returned 6 Warning: memory type ath_hal leaked memory on destroy (5 allocations, 25984 bytes leaked). warning: KLD '/boot/kernel/if_ath.ko' is newer than the linker.hints file warning: KLD '/boot/kernel/ath_rate.ko' is newer than the linker.hints file warning: KLD '/boot/kernel/ath_hal.ko' is newer than the linker.hints file ---- Freddie Cash fcash@ocis.net From owner-freebsd-current@FreeBSD.ORG Sun Sep 24 04:43:27 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AD5C16A412 for ; Sun, 24 Sep 2006 04:43:27 +0000 (UTC) (envelope-from cms01@tampabay.rr.com) Received: from ms-smtp-03.tampabay.rr.com (ms-smtp-03.tampabay.rr.com [65.32.5.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACB9943D45 for ; Sun, 24 Sep 2006 04:43:26 +0000 (GMT) (envelope-from cms01@tampabay.rr.com) Received: from [192.168.0.100] (2492160hfc76.tampabay.res.rr.com [24.92.160.76]) by ms-smtp-03.tampabay.rr.com (8.13.6/8.13.6) with ESMTP id k8O4hMon013771 for ; Sun, 24 Sep 2006 00:43:24 -0400 (EDT) From: Richard To: current@freebsd.org Date: Sun, 24 Sep 2006 00:43:23 -0400 User-Agent: KMail/1.9.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609240043.23583.cms01@tampabay.rr.com> X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: Subject: FreeBSD ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Sep 2006 04:43:27 -0000 thinking about trying freebsd, how are the driver issues? for the latest laptop wireless networking..etc how about software upgrades, are they self updating ? or does one need to compile his own. what is the best distro of freebsd PC-BSD or Desktop-BSD Thanks - Rich From owner-freebsd-current@FreeBSD.ORG Sun Sep 24 04:52:15 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 96BBF16A417; Sun, 24 Sep 2006 04:52:15 +0000 (UTC) (envelope-from kris@obsecurity.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD59343D46; Sun, 24 Sep 2006 04:52:14 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (elvis.mu.org [192.203.228.196]) by elvis.mu.org (Postfix) with ESMTP id A93D01A4D8B; Sat, 23 Sep 2006 21:52:14 -0700 (PDT) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id A768E514DF; Sun, 24 Sep 2006 00:52:13 -0400 (EDT) Date: Sun, 24 Sep 2006 00:52:13 -0400 From: Kris Kennaway To: Tim Kientzle Message-ID: <20060924045213.GA17506@xor.obsecurity.org> References: <200609150804.k8F84O1H056038@repoman.freebsd.org> <20060915155912.GA71796@xor.obsecurity.org> <450AD508.10608@freebsd.org> <20060915180315.GB74735@xor.obsecurity.org> <450C30ED.7090901@freebsd.org> <20060916192437.GA15425@xor.obsecurity.org> <45156E4E.6040806@kientzle.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wac7ysb48OaltWcw" Content-Disposition: inline In-Reply-To: <45156E4E.6040806@kientzle.com> User-Agent: Mutt/1.4.2.2i Cc: Tim Kientzle , Andre Oppermann , current@FreeBSD.org, Kris Kennaway Subject: Re: bsdtar vs gtar performance X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Sep 2006 04:52:15 -0000 --wac7ysb48OaltWcw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Moving to current@ where it's on-topic] On Sat, Sep 23, 2006 at 10:26:38AM -0700, Tim Kientzle wrote: > Kris and Ruslan were recently discussing the performance of bsdtar > relative to gtar, which prompted me to do some measurements > of my own. I used /usr/ports as my test, because it stresses > file and directory creation over extracting large files. >=20 > Here are some initial results, based on ten runs of each test on a > quiescent system, comparing results with PHK's "ministat": >=20 > * Creating uncompressed archives: bsdtar and gtar showed > no difference in total time. >=20 > * Extracting gzip-compressed archives: bsdtar and gtar showed > no difference in total time. >=20 > * Extracting uncompressed archives: gtar is about 13% faster > than bsdtar in my test. Interestingly (to me), this was the same > with or without -m. (I've long suspected dir timestamp restores > as a contributor; this shows otherwise.) With 10 repetitions of an extraction of the ports tree to a swap-backed md (newfs'ed in between tests, mounted async), I get a much bigger difference in favour of gtar: x gtar-data + bsdtar-data +------------------------------------------------------------+ |x + | |x + | |xx + | |xx ++ | |xx ++ | |xx ++++| |A| A| | +------------------------------------------------------------+ N Min Max Median Avg Stddev x 10 34.9 35.2 34.985 35.008 0.095893459 + 11 48.95 49.68 49.21 49.249091 0.19216943 Difference at 95.0% confidence 14.2411 +/- 0.141059 40.6795% +/- 0.402932% (Student's t, pooled s =3D 0.154247) I suspect you were measuring extraction on real disk hardware, in which case you're mostly measuring overhead from the disk I/O, which is going to make up most of the real time in both cases. Kris --wac7ysb48OaltWcw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFFg79Wry0BWjoQKURAvwCAJ0RZWyFmN7fD5GIVMi4WegoQM+u6QCfXKbP f1drVqPi6Nz2sBaWJqMfcFE= =+Ir/ -----END PGP SIGNATURE----- --wac7ysb48OaltWcw-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 24 06:09:49 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A343716A40F for ; Sun, 24 Sep 2006 06:09:49 +0000 (UTC) (envelope-from jamesfrancistoy@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7A2443D46 for ; Sun, 24 Sep 2006 06:09:48 +0000 (GMT) (envelope-from jamesfrancistoy@gmail.com) Received: by wx-out-0506.google.com with SMTP id s6so1767226wxc for ; Sat, 23 Sep 2006 23:09:48 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:reply-to:references:in-reply-to:sensitivity:importance:to:subject:from:date:content-type:mime-version; b=Z7ohqeiPNzht148jMJsG4VIMBjameGrtPe6XEN1U/VT+IRNRf3YANSaxWW91pkt+CPy2NM7iFLTymjofmgwtmhwvZR+ptLZlg0VZx+ImfvjA9qz5HH2UFYJnn9T4BGBFQJudC8k++7Nd8liENYxb2b777ZRc1EkDSclU0EEj6IA= Received: by 10.70.83.4 with SMTP id g4mr4556160wxb; Sat, 23 Sep 2006 23:09:48 -0700 (PDT) Received: from bda106-cell01.bisx.prod.on.blackberry ( [216.9.249.106]) by mx.gmail.com with ESMTP id 43sm1201176wri.2006.09.23.23.09.47; Sat, 23 Sep 2006 23:09:47 -0700 (PDT) Message-ID: <498534138-1159078186-cardhu_blackberry.rim.net-978295626-@bxe038-cell01.bisx.prod.on.blackberry> References: <200609240043.23583.cms01@tampabay.rr.com> In-Reply-To: <200609240043.23583.cms01@tampabay.rr.com> Sensitivity: Normal Importance: Normal To: "Richard" , owner-freebsd-current@freebsd.org, current@freebsd.org From: jamesfrancistoy@gmail.com Date: Sun, 24 Sep 2006 06:09:07 +0000 Content-type: text/plain MIME-Version: 1.0 Cc: Subject: Re: FreeBSD ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jamesfrancistoy@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2006 06:09:49 -0000 Freebsd is an entirely separate operating system from pc-bsd and desktop-bsd ... You will have to compile your own upgrades...and the drivers are specific meaning it depends on which chipset / logic board you are trying to support Sent via BlackBerry from Cingular Wireless -----Original Message----- From: Richard Date: Sun, 24 Sep 2006 00:43:23 To:current@freebsd.org Subject: FreeBSD ? thinking about trying freebsd, how are the driver issues? for the latest laptop wireless networking..etc how about software upgrades, are they self updating ? or does one need to compile his own. what is the best distro of freebsd PC-BSD or Desktop-BSD Thanks - Rich _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun Sep 24 07:16:04 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2966D16A415 for ; Sun, 24 Sep 2006 07:16:04 +0000 (UTC) (envelope-from qhwt+fbsd@les.ath.cx) Received: from les.ath.cx (15.61.205.61.west.global.alpha-net.ne.jp [61.205.61.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACF0943D4C for ; Sun, 24 Sep 2006 07:16:03 +0000 (GMT) (envelope-from qhwt+fbsd@les.ath.cx) Received: by les.ath.cx (Postfix, from userid 1000) id CAA0486618; Sun, 24 Sep 2006 16:16:01 +0900 (JST) Date: Sun, 24 Sep 2006 16:16:01 +0900 From: YONETANI Tomokazu To: freebsd-current@freebsd.org Message-ID: <20060924071601.GA1080@les.ath.cx> References: <1157154024.835.6.camel@atomizer.opensourcebeef.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1157154024.835.6.camel@atomizer.opensourcebeef.net> User-Agent: Mutt/1.5.11 Subject: Re: LSI 1030 mpt doesn't work if I build a new kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Sep 2006 07:16:04 -0000 Hi, Recently I tried installing FreeBSD 5.4-RELEASE on an IBM X335 in my office and tried to upgrade to 6.2-PRERELEASE, and found that although it doesn't hang or panic during boot, running I/O intensive applications (including buildworld) ends up in an I/O error, and eventually panicked and rebooted. So I tried earlier versions to find out when the problem started to occur, and found that it started as early as 5.5-STABLE. I noticed that new mpt driver has been MFC after 5.4-RELEASE, so maybe that's something to do with this issue. Kernels other than 5.4 are all built on 5.4-RELEASE system using GENERIC file without any optimization flags. I haven't tried CURRENT yet because buildworld didn't finish on 5.4-RELEASE, but is it worth trying CURRENT and the patch posted to this thread(in other words: does my problem look like the similar one that people are discussing in this thread)? Here's `dmesg | grep ^mpt' output: mpt0: port 0x2300-0x23ff mem 0xfbfe0000-0xfbfeffff,0xfbff0000-0xfbffffff irq 22 at device 1.0 on pci1 mpt0: MPI Version=1.2.6.0 mpt0: Capabilities: ( RAID-1 SAFTE ) mpt0: 1 Active Volume (1 Max) mpt0: 2 Hidden Drive Members (3 Max) I found a PR with "LSI1030" in the single-line description, but it doesn't seem to be related to my problem: kern/96040 Any suggestions are welcome. Regards. 5.4-RELEASE: OK 5.5-STABLE: panic after showing the following messages: handle_workitem_freeblocks: block count initiate_write_filepage: already started 6.0-RELEASE-p12, 6.2-PRERELEASE: panic after showing bunch of the message as follows: g_vfs_done():da0s1g[WRITE(offset=3287388160, length=2048)]error = 5 From owner-freebsd-current@FreeBSD.ORG Sun Sep 24 08:16:14 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 90DC016A412 for ; Sun, 24 Sep 2006 08:16:14 +0000 (UTC) (envelope-from Peter.Ross@alumni.tu-berlin.de) Received: from omta04sl.mx.bigpond.com (omta04sl.mx.bigpond.com [144.140.93.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FA2E43D4C for ; Sun, 24 Sep 2006 08:16:12 +0000 (GMT) (envelope-from Peter.Ross@alumni.tu-berlin.de) Received: from klein.bigpond.com ([60.230.110.183]) by omta04sl.mx.bigpond.com with ESMTP id <20060924081610.DORS11279.omta04sl.mx.bigpond.com@klein.bigpond.com>; Sun, 24 Sep 2006 08:16:10 +0000 Received: from klein.bigpond.com (localhost [127.0.0.1]) by klein.bigpond.com (8.13.8/8.13.8) with ESMTP id k8O8G1US001599; Sun, 24 Sep 2006 18:16:03 +1000 (EST) (envelope-from Peter.Ross@alumni.tu-berlin.de) Received: from localhost (petros@localhost) by klein.bigpond.com (8.13.8/8.13.8/Submit) with ESMTP id k8O8FjXS001596; Sun, 24 Sep 2006 18:15:59 +1000 (EST) (envelope-from Peter.Ross@alumni.tu-berlin.de) X-Authentication-Warning: klein.bigpond.com: petros owned process doing -bs Date: Sun, 24 Sep 2006 18:15:44 +1000 (EST) From: Peter Ross X-X-Sender: petros@localhost To: "jamesfrancistoy@gmail.com" In-Reply-To: <498534138-1159078186-cardhu_blackberry.rim.net-978295626-@bxe038-cell01.bisx.prod.on.blackberry> Message-ID: <20060924175053.M722@localhost> References: <200609240043.23583.cms01@tampabay.rr.com> <498534138-1159078186-cardhu_blackberry.rim.net-978295626-@bxe038-cell01.bisx.prod.on.blackberry> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "current@freebsd.org" , Richard Subject: Re: FreeBSD ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Sep 2006 08:16:14 -0000 Hi, while not sure where to move this question (-questions may be the appropriate list?) I think this isn't true: On Sun, 24 Sep 2006, jamesfrancistoy@gmail.com wrote: > Freebsd is an entirely separate operating system from pc-bsd and > desktop-bsd ... You will have to compile your own upgrades...and the > drivers are specific meaning it depends on which chipset / logic board > you are trying to support Both projects are based on FreeBSD, and AFAIK they do not change anything "near" the kernel (e.g. no drivers). While PC-BSD is based on FreeBSD 6-stable, Desktop-BSD is still using 5.5. Both projects are dedicated to the desktop users. Desktop-BSD adds some management tools so basic configuration becomes easier but uses the same ports/packages structure "normal" FreeBSD uses. PC-BSD adds an graphical install tool and has its own package format. Usually both projects do not require "compiling your own upgrades". Honestly, as a systems engineer I am not the right person to recommend desktop systems. My laptop (a Latitude X1) runs FreeBSD-current but it is not even fully utilised yet. I just use it as a ssh terminal switch, mail reader, webbrowser and to compile stuff.. so I install the x11/gnome2 metaport. Regards Peter From owner-freebsd-current@FreeBSD.ORG Sun Sep 24 11:32:23 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C467D16A403; Sun, 24 Sep 2006 11:32:23 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from camay.yandex.ru (camay.yandex.ru [213.180.200.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8176743D53; Sun, 24 Sep 2006 11:32:22 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from YAMAIL (camay.yandex.ru) by mail.yandex.ru id ; Sun, 24 Sep 2006 15:32:04 +0400 Received: from [82.211.152.12] ([82.211.152.12]) by mail.yandex.ru with HTTP; Sun, 24 Sep 2006 15:32:04 +0400 (MSD) Date: Sun, 24 Sep 2006 15:32:04 +0400 (MSD) From: "Andrey V. Elsukov" Sender: bu7cher@yandex.ru Message-Id: <45166CB4.000004.01220@camay.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: bu7cher@yandex.ru To: freebsd-current@freebsd.org, freebsd-usb@freebsd.org X-Source-Ip: 82.211.152.12 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_GDH3PWYXFQQMYJ0CCJD0" Cc: Subject: Problems with USB on CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bu7cher@yandex.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2006 11:32:24 -0000 --------------Boundary-00=_GDH3PWYXFQQMYJ0CCJD0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, All! I have notebook Maxselect Mission GT3000. A hardware configuration description (russian): http://www.maxselect.ru/catalog/models.html?id=4024&template=normal o Mobile AMD Sempron o NVIDIA C51MV+MCP51M o PCI Express nVidia Geforce Go 6100 o Realtek HDA I have several problems. One is with USB. When i attach USB Flash disk it's not work. usbd_new_device: addr=2, getting first desc failed uhub_explore: usb_new_device failed, error=IOERROR uhub1: device problem (IOERROR), disabling port 4 http://butcher.heavennet.ru/dmesg.txt http://butcher.heavennet.ru/pciconf.txt I've attached dmesg and pciconf. Any suggestions? -- WBR, Andrey V. Elsukov --------------Boundary-00=_GDH3PWYXFQQMYJ0CCJD0 Content-Disposition: attachment; Filename="dmesg.txt" Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: base64 Q29weXJpZ2h0IChjKSAxOTkyLTIwMDYgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0IChj KSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAxOTkzLCAx OTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmln aHRzIHJlc2VydmVkLgpGcmVlQlNEIDcuMC1DVVJSRU5UICMyOiBTdW4gU2VwIDI0IDE1OjAzOjAy IE1TRCAyMDA2CiAgICBidXRjaGVyQGJ0ci1uYi5wcm9wZXJsYW4ubmV0Oi91c3Ivb2JqL3Vzci9z cmMvc3lzL0JUUgpQcmVsb2FkZWQgZWxmIGtlcm5lbCAiL2Jvb3Qva2VybmVsL2tlcm5lbCIgYXQg MHhjMGRhZTAwMC4KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tlcm5lbC9saW51eC5rbyIg YXQgMHhjMGRhZTFjNC4KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L21vZHVsZXMvbnZpZGlh LmtvIiBhdCAweGMwZGFlMjcwLgpQcmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL2Fj cGkua28iIGF0IDB4YzBkYWUzMWMuCkNhbGlicmF0aW5nIGNsb2NrKHMpIC4uLiBpODI1NCBjbG9j azogMTE5MzIxNiBIegpDTEtfVVNFX0k4MjU0X0NBTElCUkFUSU9OIG5vdCBzcGVjaWZpZWQgLSB1 c2luZyBkZWZhdWx0IGZyZXF1ZW5jeQpUaW1lY291bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkz MTgyIEh6IHF1YWxpdHkgMApDYWxpYnJhdGluZyBUU0MgY2xvY2sgLi4uIFRTQyBjbG9jazogMTYw NzMyNTEyMSBIegpDUFU6IE1vYmlsZSBBTUQgU2VtcHJvbih0bSkgUHJvY2Vzc29yIDI2MDArICgx NjA3LjMzLU1IeiA2ODYtY2xhc3MgQ1BVKQogIE9yaWdpbiA9ICJBdXRoZW50aWNBTUQiICBJZCA9 IDB4ZjgyICBTdGVwcGluZyA9IDIKICBGZWF0dXJlcz0weDc4YmZiZmY8RlBVLFZNRSxERSxQU0Us VFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQsUFNFMzYs Q0xGTFVTSCxNTVgsRlhTUixTU0UsU1NFMj4KICBBTUQgRmVhdHVyZXM9MHhjMDUwMDgwMDxTWVND QUxMLE5YLE1NWCssM0ROb3chKywzRE5vdyE+CkRhdGEgVExCOiAzMiBlbnRyaWVzLCBmdWxseSBh c3NvY2lhdGl2ZQpJbnN0cnVjdGlvbiBUTEI6IDMyIGVudHJpZXMsIGZ1bGx5IGFzc29jaWF0aXZl CkwxIGRhdGEgY2FjaGU6IDY0IGtieXRlcywgNjQgYnl0ZXMvbGluZSwgMSBsaW5lcy90YWcsIDIt d2F5IGFzc29jaWF0aXZlCkwxIGluc3RydWN0aW9uIGNhY2hlOiA2NCBrYnl0ZXMsIDY0IGJ5dGVz L2xpbmUsIDEgbGluZXMvdGFnLCAyLXdheSBhc3NvY2lhdGl2ZQpMMiBpbnRlcm5hbCBjYWNoZTog MTI4IGtieXRlcywgNjQgYnl0ZXMvbGluZSwgMSBsaW5lcy90YWcsIDgtd2F5IGFzc29jaWF0aXZl CnJlYWwgbWVtb3J5ICA9IDQ2ODg0NDU0NCAoNDQ3IE1CKQpQaHlzaWNhbCBtZW1vcnkgY2h1bmso cyk6CjB4MDAwMDAwMDAwMDAwMTAwMCAtIDB4MDAwMDAwMDAwMDA5ZGZmZiwgNjQzMDcyIGJ5dGVz ICgxNTcgcGFnZXMpCjB4MDAwMDAwMDAwMDEwMDAwMCAtIDB4MDAwMDAwMDAwMDNmZmZmZiwgMzE0 NTcyOCBieXRlcyAoNzY4IHBhZ2VzKQoweDAwMDAwMDAwMDEwMjUwMDAgLSAweDAwMDAwMDAwMWI2 ZmZmZmYsIDQ0MzM5NjA5NiBieXRlcyAoMTA4MjUxIHBhZ2VzKQphdmFpbCBtZW1vcnkgPSA0NDUx MjA1MTIgKDQyNCBNQikKYmlvczMyOiBGb3VuZCBCSU9TMzIgU2VydmljZSBEaXJlY3RvcnkgaGVh ZGVyIGF0IDB4YzAwZjgzOTAKYmlvczMyOiBFbnRyeSA9IDB4ZmRjZTQgKGMwMGZkY2U0KSAgUmV2 ID0gMCAgTGVuID0gMQpwY2liaW9zOiBQQ0kgQklPUyBlbnRyeSBhdCAweGZkY2UwKzB4MApwbnBi aW9zOiBGb3VuZCBQblAgQklPUyBkYXRhIGF0IDB4YzAwZjg0MjAKcG5wYmlvczogRW50cnkgPSBl OWNkOjg2YWYgIFJldiA9IDEuMApPdGhlciBCSU9TIHNpZ25hdHVyZXMgZm91bmQ6CmF0aF9yYXRl OiB2ZXJzaW9uIDEuMiA8U2FtcGxlUmF0ZSBiaXQtcmF0ZSBzZWxlY3Rpb24gYWxnb3JpdGhtPgp3 bGFuOiA8ODAyLjExIExpbmsgTGF5ZXI+Cm5mc2xvY2s6IHBzZXVkby1kZXZpY2UKa2JkOiBuZXcg YXJyYXkgc2l6ZSA0CmtiZDEgYXQga2JkbXV4MAptZW06IDxtZW1vcnk+ClBlbnRpdW0gUHJvIE1U UlIgc3VwcG9ydCBlbmFibGVkCmlvOiA8SS9PPgpudWxsOiA8bnVsbCBkZXZpY2UsIHplcm8gZGV2 aWNlPgpyYW5kb206IDxlbnRyb3B5IHNvdXJjZSwgU29mdHdhcmUsIFlhcnJvdz4KYXRoX2hhbDog MC45LjE3LjIgKEFSNTIxMCwgQVI1MjExLCBBUjUyMTIsIFJGNTExMSwgUkY1MTEyLCBSRjI0MTMs IFJGNTQxMykKbnB4MDogSU5UIDE2IGludGVyZmFjZQphY3BpMDogPFBUTFREICAgUlNEVD4gb24g bW90aGVyYm9hcmQKYWNwaTA6IFtNUFNBRkVdCnBjaV9vcGVuKDEpOgltb2RlIDEgYWRkciBwb3J0 ICgweDBjZjgpIGlzIDB4ODAwMDcwMDQKcGNpX29wZW4oMWEpOgltb2RlMXJlcz0weDgwMDAwMDAw ICgweDgwMDAwMDAwKQpwY2lfY2ZnY2hlY2s6CWRldmljZSAwIFtjbGFzcz0wNTAwMDBdIFtoZHI9 ODBdIGlzIHRoZXJlIChpZD0wMmYzMTBkZSkKcGNpYmlvczogQklPU19QUkVTRU5UIGNhbGwgZmFp bGVkCmFjcGlfYnVzX251bWJlcjogcm9vdCBidXMgaGFzIG5vIF9CQk4sIGFzc3VtaW5nIDAKQWNw aU9zRGVyaXZlUGNpSWQ6IGJ1cyAwIGRldiAxMCBmdW5jIDAKYWNwaTA6IFBvd2VyIEJ1dHRvbiAo Zml4ZWQpCmFjcGkwOiB3YWtldXAgY29kZSB2YSAweGNiM2M0MDAwIHBhIDB4OWQwMDAKYXRwaWM6 IFByb2dyYW1taW5nIElSUTkgYXMgbGV2ZWwvbG93CmFjcGlfYnVzX251bWJlcjogcm9vdCBidXMg aGFzIG5vIF9CQk4sIGFzc3VtaW5nIDAKQWNwaU9zRGVyaXZlUGNpSWQ6IGJ1cyAwIGRldiAxMCBm dW5jIDAKYWNwaV9idXNfbnVtYmVyOiByb290IGJ1cyBoYXMgbm8gX0JCTiwgYXNzdW1pbmcgMApB Y3BpT3NEZXJpdmVQY2lJZDogYnVzIDAgZGV2IDEwIGZ1bmMgMAphY3BpX2J1c19udW1iZXI6IHJv b3QgYnVzIGhhcyBubyBfQkJOLCBhc3N1bWluZyAwCkFjcGlPc0Rlcml2ZVBjaUlkOiBidXMgMCBk ZXYgMTAgZnVuYyAwCmFjcGlfYnVzX251bWJlcjogcm9vdCBidXMgaGFzIG5vIF9CQk4sIGFzc3Vt aW5nIDAKQWNwaU9zRGVyaXZlUGNpSWQ6IGJ1cyAwIGRldiAxMCBmdW5jIDAKYWNwaV9idXNfbnVt YmVyOiByb290IGJ1cyBoYXMgbm8gX0JCTiwgYXNzdW1pbmcgMApBY3BpT3NEZXJpdmVQY2lJZDog YnVzIDAgZGV2IDEwIGZ1bmMgMQphY3BpX2J1c19udW1iZXI6IHJvb3QgYnVzIGhhcyBubyBfQkJO LCBhc3N1bWluZyAwCkFjcGlPc0Rlcml2ZVBjaUlkOiBidXMgMCBkZXYgMTAgZnVuYyAxCmFjcGlf YnVzX251bWJlcjogcm9vdCBidXMgaGFzIG5vIF9CQk4sIGFzc3VtaW5nIDAKQWNwaU9zRGVyaXZl UGNpSWQ6IGJ1cyAwIGRldiAxMCBmdW5jIDEKQUNQSSB0aW1lcjogMS8yIDEvMiAxLzIgMS8xIDEv MSAxLzIgMS8xIDEvMiAxLzEgMS8xIC0+IDEwClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1 ZW5jeSAzNTc5NTQ1IEh6IHF1YWxpdHkgMTAwMAphY3BpX3RpbWVyMDogPDI0LWJpdCB0aW1lciBh dCAzLjU3OTU0NU1Iej4gcG9ydCAweDEwMDgtMHgxMDBiIG9uIGFjcGkwCmFjcGlfZWMwOiA8RW1i ZWRkZWQgQ29udHJvbGxlcjogR1BFIDB4MTA+IHBvcnQgMHg2MiwweDY2IG9uIGFjcGkwCnBjaV9s aW5rMDogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElS UXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDExIDE0IDE1CnBjaV9saW5rMDogTGlua3Mg YWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAg MCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTEgMTQgMTUKcGNpX2xpbmswOiBMaW5rcyBhZnRlciBk aXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAg NSA3IDkgMTEgMTQgMTUKcGNpX2xpbmsxOiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRl eCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgIDExICAgTiAgICAgMCAgNSA3IDkgMTEgMTQg MTUKcGNpX2xpbmsxOiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEg IFJ0ZCAgUmVmICBJUlFzCiAgICAwICAgMTEgICBOICAgICAwICA1IDcgOSAxMSAxNCAxNQpwY2lf bGluazE6IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAg ICAwICAyNTUgICBOICAgICAwICA1IDcgOSAxMSAxNCAxNQpwY2lfbGluazI6IExpbmtzIGFmdGVy IGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBO ICAgICAwICA1IDcgOSAxMSAxNCAxNQpwY2lfbGluazI6IExpbmtzIGFmdGVyIGluaXRpYWwgdmFs aWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAg IDUgNyA5IDExIDE0IDE1CnBjaV9saW5rMjogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5kZXggIElS USAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDExIDE0IDE1CnBj aV9saW5rMzogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYg IElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDExIDE0IDE1CnBjaV9saW5rMzogTGlu a3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwog ICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTEgMTQgMTUKcGNpX2xpbmszOiBMaW5rcyBhZnRl ciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAg MCAgNSA3IDkgMTEgMTQgMTUKcGNpX2xpbms0OiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJ bmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTEg MTQgMTUKcGNpX2xpbms0OiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJ UlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICA1IDcgOSAxMSAxNCAxNQpw Y2lfbGluazQ6IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFz CiAgICAwICAyNTUgICBOICAgICAwICA1IDcgOSAxMSAxNCAxNQpwY2lfbGluazU6IExpbmtzIGFm dGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUg ICBOICAgICAwICA1IDcgOSAxMSAxNCAxNQpwY2lfbGluazU6IExpbmtzIGFmdGVyIGluaXRpYWwg dmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAg IDAgIDUgNyA5IDExIDE0IDE1CnBjaV9saW5rNTogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5kZXgg IElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDExIDE0IDE1 CnBjaV9saW5rNjogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBS ZWYgIElSUXMKICAgIDAgICAgNSAgIE4gICAgIDAgIDUgNyA5IDExIDE0IDE1CnBjaV9saW5rNjog TGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJR cwogICAgMCAgICA1ICAgTiAgICAgMCAgNSA3IDkgMTEgMTQgMTUKcGNpX2xpbms2OiBMaW5rcyBh ZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAg ICAgMCAgNSA3IDkgMTEgMTQgMTUKcGNpX2xpbms3OiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2Jl OgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkg MTEgMTQgMTUKcGNpX2xpbms3OiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4 ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICA1IDcgOSAxMSAxNCAx NQpwY2lfbGluazc6IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJ UlFzCiAgICAwICAyNTUgICBOICAgICAwICA1IDcgOSAxMSAxNCAxNQpwY2lfbGluazg6IExpbmtz IGFmdGVyIGluaXRpYWwgcHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAg MTAgICBOICAgICAwICA1IDcgOSAxMSAxNCAxNQpwY2lfbGluazg6IExpbmtzIGFmdGVyIGluaXRp YWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4g ICAgIDAgIDUgNyA5IDExIDE0IDE1CnBjaV9saW5rODogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5k ZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDExIDE0 IDE1CnBjaV9saW5rOTogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRk ICBSZWYgIElSUXMKICAgIDAgICAxMSAgIE4gICAgIDAgIDUgNyA5IDExIDE0IDE1CnBjaV9saW5r OTogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAg SVJRcwogICAgMCAgIDExICAgTiAgICAgMCAgNSA3IDkgMTEgMTQgMTUKcGNpX2xpbms5OiBMaW5r cyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAg TiAgICAgMCAgNSA3IDkgMTEgMTQgMTUKcGNpX2xpbmsxMDogTGlua3MgYWZ0ZXIgaW5pdGlhbCBw cm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgICAxMCAgIE4gICAgIDAgIDUg NyA5IDExIDE0IDE1CnBjaV9saW5rMTA6IExpbmtzIGFmdGVyIGluaXRpYWwgdmFsaWRhdGlvbjoK SW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDEx IDE0IDE1CnBjaV9saW5rMTA6IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAg UmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICA1IDcgOSAxMSAxNCAxNQpwY2lfbGluazEx OiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwog ICAgMCAgIDEwICAgTiAgICAgMCAgNSA3IDkgMTEgMTQgMTUKcGNpX2xpbmsxMTogTGlua3MgYWZ0 ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAg MjU1ICAgTiAgICAgMCAgNSA3IDkgMTEgMTQgMTUKcGNpX2xpbmsxMTogTGlua3MgYWZ0ZXIgZGlz YWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAgIDAgIDUg NyA5IDExIDE0IDE1CnBjaV9saW5rMTI6IExpbmtzIGFmdGVyIGluaXRpYWwgcHJvYmU6CkluZGV4 ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICA1IDcgOSAxMSAxNCAx NQpwY2lfbGluazEyOiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246CkluZGV4ICBJUlEg IFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICA1IDcgOSAxMSAxNCAxNQpwY2lf bGluazEyOiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcwog ICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTEgMTQgMTUKcGNpX2xpbmsxMzogTGlua3MgYWZ0 ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAg IE4gICAgIDAgIDUgNyA5IDExIDE0IDE1CnBjaV9saW5rMTM6IExpbmtzIGFmdGVyIGluaXRpYWwg dmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAgIE4gICAg IDAgIDUgNyA5IDExIDE0IDE1CnBjaV9saW5rMTM6IExpbmtzIGFmdGVyIGRpc2FibGU6CkluZGV4 ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICA1IDcgOSAxMSAxNCAx NQpwY2lfbGluazE0OiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRleCAgSVJRICBSdGQg IFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTEgMTQgMTUKcGNpX2xpbmsx NDogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJRICBSdGQgIFJlZiAg SVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTEgMTQgMTUKcGNpX2xpbmsxNDogTGlu a3MgYWZ0ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAgIDI1NSAg IE4gICAgIDAgIDUgNyA5IDExIDE0IDE1CnBjaV9saW5rMTU6IExpbmtzIGFmdGVyIGluaXRpYWwg cHJvYmU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICA1 IDcgOSAxMSAxNCAxNQpwY2lfbGluazE1OiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246 CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICA1IDcgOSAx MSAxNCAxNQpwY2lfbGluazE1OiBMaW5rcyBhZnRlciBkaXNhYmxlOgpJbmRleCAgSVJRICBSdGQg IFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTEgMTQgMTUKcGNpX2xpbmsx NjogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMK ICAgIDAgICAgNyAgIE4gICAgIDAgIDUgNyA5IDExIDE0IDE1CnBjaV9saW5rMTY6IExpbmtzIGFm dGVyIGluaXRpYWwgdmFsaWRhdGlvbjoKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMKICAgIDAg ICAgNyAgIE4gICAgIDAgIDUgNyA5IDExIDE0IDE1CnBjaV9saW5rMTY6IExpbmtzIGFmdGVyIGRp c2FibGU6CkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzCiAgICAwICAyNTUgICBOICAgICAwICA1 IDcgOSAxMSAxNCAxNQpwY2lfbGluazE3OiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOgpJbmRl eCAgSVJRICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTEgMTQg MTUKcGNpX2xpbmsxNzogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOgpJbmRleCAgSVJR ICBSdGQgIFJlZiAgSVJRcwogICAgMCAgMjU1ICAgTiAgICAgMCAgNSA3IDkgMTEgMTQgMTUKcGNp X2xpbmsxNzogTGlua3MgYWZ0ZXIgZGlzYWJsZToKSW5kZXggIElSUSAgUnRkICBSZWYgIElSUXMK ICAgIDAgIDI1NSAgIE4gICAgIDAgIDUgNyA5IDExIDE0IDE1CmNwdTA6IDxBQ1BJIENQVT4gb24g YWNwaTAKcG93ZXJub3cwOiA8UG93ZXJOb3chIEs4PiBvbiBjcHUwCmFjcGlfYnV0dG9uMDogPFBv d2VyIEJ1dHRvbj4gb24gYWNwaTAKYWNwaV9idXR0b24xOiA8U2xlZXAgQnV0dG9uPiBvbiBhY3Bp MAphY3BpX2FjYWQwOiA8QUMgQWRhcHRlcj4gb24gYWNwaTAKYmF0dGVyeTA6IDxBQ1BJIENvbnRy b2wgTWV0aG9kIEJhdHRlcnk+IG9uIGFjcGkwCmFjcGlfbGlkMDogPENvbnRyb2wgTWV0aG9kIExp ZCBTd2l0Y2g+IG9uIGFjcGkwCnBjaWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhj ZjgtMHhjZmYgb24gYWNwaTAKQUNQSTogRm91bmQgbWF0Y2hpbmcgcGluIGZvciAwLjEwLklOVEEg YXQgZnVuYyAxOiAxMApwY2lfbGluazg6IEJJT1MgSVJRIDEwIGZvciAwLjEwLklOVEEgaXMgaW52 YWxpZApBQ1BJOiBGb3VuZCBtYXRjaGluZyBwaW4gZm9yIDAuMTEuSU5UQSBhdCBmdW5jIDA6IDEx CkFDUEk6IEZvdW5kIG1hdGNoaW5nIHBpbiBmb3IgMC4xMS5JTlRCIGF0IGZ1bmMgMTogMTAKcGNp X2xpbmsxMDogQklPUyBJUlEgMTAgZm9yIDAuMTEuSU5UQiBpcyBpbnZhbGlkCkFDUEk6IEZvdW5k IG1hdGNoaW5nIHBpbiBmb3IgMC4yMC5JTlRBIGF0IGZ1bmMgMDogMTAKcGNpX2xpbmsxMTogQklP UyBJUlEgMTAgZm9yIDAuMjAuSU5UQSBpcyBpbnZhbGlkCkFDUEk6IEZvdW5kIG1hdGNoaW5nIHBp biBmb3IgMC4xNi5JTlRCIGF0IGZ1bmMgMTogMTEKQUNQSTogRm91bmQgbWF0Y2hpbmcgcGluIGZv ciAwLjE0LklOVEEgYXQgZnVuYyAwOiA3CkFDUEk6IEZvdW5kIG1hdGNoaW5nIHBpbiBmb3IgMC41 LklOVEEgYXQgZnVuYyAwOiA1CnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwCnBjaTA6IHBo eXNpY2FsIGJ1cz0wCmZvdW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDJmMywgcmV2aWQ9MHhh MgoJYnVzPTAsIHNsb3Q9MCwgZnVuYz0wCgljbGFzcz0wNS0wMC0wMCwgaGRydHlwZT0weDAwLCBt ZmRldj0xCgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDBiMCwgY2FjaGVsbnN6PTAgKGR3b3Jk cykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAw ICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAyZmEsIHJldmlkPTB4YTIKCWJ1 cz0wLCBzbG90PTAsIGZ1bmM9MQoJY2xhc3M9MDUtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MQoJY21kcmVnPTB4MDEwMCwgc3RhdHJlZz0weDQwMjAsIGNhY2hlbG5zej0wIChkd29yZHMpCgls YXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBu cykKZm91bmQtPgl2ZW5kb3I9MHgxMGRlLCBkZXY9MHgwMmZlLCByZXZpZD0weGEyCglidXM9MCwg c2xvdD0wLCBmdW5jPTIKCWNsYXNzPTA1LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNt ZHJlZz0weDAwMDAsIHN0YXRyZWc9MHgwMDIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGlt ZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZv dW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDJmOCwgcmV2aWQ9MHhhMgoJYnVzPTAsIHNsb3Q9 MCwgZnVuYz0zCgljbGFzcz0wNS0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9 MHgwMDAwLCBzdGF0cmVnPTB4MDBhMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4 MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+ CXZlbmRvcj0weDEwZGUsIGRldj0weDAyZjksIHJldmlkPTB4YTIKCWJ1cz0wLCBzbG90PTAsIGZ1 bmM9NAoJY2xhc3M9MDUtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21kcmVnPTB4MDAw Niwgc3RhdHJlZz0weDAwYTAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5k b3I9MHgxMGRlLCBkZXY9MHgwMmZmLCByZXZpZD0weGEyCglidXM9MCwgc2xvdD0wLCBmdW5jPTUK CWNsYXNzPTA1LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDYsIHN0 YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyks IG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9yPTB4 MTBkZSwgZGV2PTB4MDI3ZiwgcmV2aWQ9MHhhMgoJYnVzPTAsIHNsb3Q9MCwgZnVuYz02CgljbGFz cz0wNS0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMTAwLCBzdGF0cmVn PTB4MDAyMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5n bnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZlbmRvcj0weDEwZGUs IGRldj0weDAyN2UsIHJldmlkPTB4YTIKCWJ1cz0wLCBzbG90PTAsIGZ1bmM9NwoJY2xhc3M9MDUt MDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3RhdHJlZz0weDAw MjAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4 MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMGRlLCBkZXY9 MHgwMjQ3LCByZXZpZD0weGEyCglidXM9MCwgc2xvdD01LCBmdW5jPTAKCWNsYXNzPTAzLTAwLTAw LCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMGIwLCBj YWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglpbnRwaW49YSwgaXJxPTUKCXBvd2Vyc3BlYyAyICBz dXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMAoJTVNJIHN1cHBvcnRzIDEgbWVzc2FnZSwgNjQgYml0 CgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGMyMDAwMDAwLCBzaXplIDI0LCBlbmFi bGVkCgltYXBbMTRdOiB0eXBlIDMsIHJhbmdlIDY0LCBiYXNlIGQwMDAwMDAwLCBzaXplIDI4LCBl bmFibGVkCgltYXBbMWNdOiB0eXBlIDEsIHJhbmdlIDY0LCBiYXNlIGMxMDAwMDAwLCBzaXplIDI0 LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjUuSU5UQSAoc3JjIFxcX1NCXy5Q Q0kwLkxLM0U6MCkKcGNpYjA6IHNsb3QgNSBJTlRBIHJvdXRlZCB0byBpcnEgNSB2aWEgXFxfU0Jf LlBDSTAuTEszRQpmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAyNzAsIHJldmlkPTB4YTIK CWJ1cz0wLCBzbG90PTksIGZ1bmM9MAoJY2xhc3M9MDUtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZk ZXY9MAoJY21kcmVnPTB4MDAwNiwgc3RhdHJlZz0weDAwYjAsIGNhY2hlbG5zej0wIChkd29yZHMp CglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAo MCBucykKZm91bmQtPgl2ZW5kb3I9MHgxMGRlLCBkZXY9MHgwMjYwLCByZXZpZD0weGEzCglidXM9 MCwgc2xvdD0xMCwgZnVuYz0wCgljbGFzcz0wNi0wMS0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0x CgljbWRyZWc9MHgwMDBmLCBzdGF0cmVnPTB4MDBhMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxh dHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5z KQpmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAyNjQsIHJldmlkPTB4YTMKCWJ1cz0wLCBz bG90PTEwLCBmdW5jPTEKCWNsYXNzPTBjLTA1LTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNt ZHJlZz0weDAwMDEsIHN0YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGlt ZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCglp bnRwaW49YSwgaXJxPTEwCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAK CW1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDMwNDAsIHNpemUgIDYsIGVuYWJs ZWQKCW1hcFsyNF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDMwMDAsIHNpemUgIDYsIGVu YWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMTAuSU5UQSAoc3JjIFxcX1NCXy5QQ0kw LkxTTUI6MCkKcGNpX2xpbms4OiBQaWNrZWQgSVJRIDcgd2l0aCB3ZWlnaHQgMApwY2liMDogc2xv dCAxMCBJTlRBIHJvdXRlZCB0byBpcnEgNyB2aWEgXFxfU0JfLlBDSTAuTFNNQgpmb3VuZC0+CXZl bmRvcj0weDEwZGUsIGRldj0weDAyNmQsIHJldmlkPTB4YTMKCWJ1cz0wLCBzbG90PTExLCBmdW5j PTAKCWNsYXNzPTBjLTAzLTEwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDcs IHN0YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBu cyksIG1pbmdudD0weDAzICg3NTAgbnMpLCBtYXhsYXQ9MHgwMSAoMjUwIG5zKQoJaW50cGluPWEs IGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCglt YXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGMwMDA0MDAwLCBzaXplIDEyLCBlbmFibGVk CnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjExLklOVEEgKHNyYyBcXF9TQl8uUENJMC5MVVMw OjApCnBjaWIwOiBzbG90IDExIElOVEEgcm91dGVkIHRvIGlycSAxMSB2aWEgXFxfU0JfLlBDSTAu TFVTMApmb3VuZC0+CXZlbmRvcj0weDEwZGUsIGRldj0weDAyNmUsIHJldmlkPTB4YTMKCWJ1cz0w LCBzbG90PTExLCBmdW5jPTEKCWNsYXNzPTBjLTAzLTIwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEK CWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgwMGIwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0 dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMpLCBtYXhsYXQ9MHgwMSAoMjUw IG5zKQoJaW50cGluPWIsIGlycT0xMAoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQz ICBjdXJyZW50IEQwCgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGMwMDA1MDAwLCBz aXplICA4LCBlbmFibGVkCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjExLklOVEIgKHNyYyBc XF9TQl8uUENJMC5MVVMyOjApCnBjaV9saW5rMTA6IFBpY2tlZCBJUlEgOSB3aXRoIHdlaWdodCAw CnBjaWIwOiBzbG90IDExIElOVEIgcm91dGVkIHRvIGlycSA5IHZpYSBcXF9TQl8uUENJMC5MVVMy CmZvdW5kLT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDI2NSwgcmV2aWQ9MHhhMQoJYnVzPTAsIHNs b3Q9MTMsIGZ1bmM9MAoJY2xhc3M9MDEtMDEtOGEsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAoJY21k cmVnPTB4MDAwNSwgc3RhdHJlZz0weDAwYjAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1l cj0weDAwICgwIG5zKSwgbWluZ250PTB4MDMgKDc1MCBucyksIG1heGxhdD0weDAxICgyNTAgbnMp Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKCW1hcFsyMF06IHR5cGUg NCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDMwODAsIHNpemUgIDQsIGVuYWJsZWQKZm91bmQtPgl2ZW5k b3I9MHgxMGRlLCBkZXY9MHgwMjY2LCByZXZpZD0weGExCglidXM9MCwgc2xvdD0xNCwgZnVuYz0w CgljbGFzcz0wMS0wMS04NSwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgwMDA1LCBz dGF0cmVnPTB4MDBiMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMp LCBtaW5nbnQ9MHgwMyAoNzUwIG5zKSwgbWF4bGF0PTB4MDEgKDI1MCBucykKCWludHBpbj1hLCBp cnE9NwoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglNU0kgc3VwcG9y dHMgNCBtZXNzYWdlcywgNjQgYml0CgltYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAw MDAzMGIwLCBzaXplICAzLCBlbmFibGVkCgltYXBbMTRdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNl IDAwMDAzMGE0LCBzaXplICAyLCBlbmFibGVkCgltYXBbMThdOiB0eXBlIDQsIHJhbmdlIDMyLCBi YXNlIDAwMDAzMGE4LCBzaXplICAzLCBlbmFibGVkCgltYXBbMWNdOiB0eXBlIDQsIHJhbmdlIDMy LCBiYXNlIDAwMDAzMGEwLCBzaXplICAyLCBlbmFibGVkCgltYXBbMjBdOiB0eXBlIDQsIHJhbmdl IDMyLCBiYXNlIDAwMDAzMDkwLCBzaXplICA0LCBlbmFibGVkCgltYXBbMjRdOiB0eXBlIDEsIHJh bmdlIDMyLCBiYXNlIGMwMDA2MDAwLCBzaXplIDEyLCBtZW1vcnkgZGlzYWJsZWQKcGNpYjA6IG1h dGNoZWQgZW50cnkgZm9yIDAuMTQuSU5UQSAoc3JjIFxcX1NCXy5QQ0kwLkxUSUQ6MCkKcGNpYjA6 IHNsb3QgMTQgSU5UQSByb3V0ZWQgdG8gaXJxIDcgdmlhIFxcX1NCXy5QQ0kwLkxUSUQKZm91bmQt Pgl2ZW5kb3I9MHgxMGRlLCBkZXY9MHgwMjZmLCByZXZpZD0weGEyCglidXM9MCwgc2xvdD0xNiwg ZnVuYz0wCgljbGFzcz0wNi0wNC0wMSwgaGRydHlwZT0weDAxLCBtZmRldj0xCgljbWRyZWc9MHgw MTA3LCBzdGF0cmVnPTB4MDBiMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAg KDAgbnMpLCBtaW5nbnQ9MHgwNCAoMTAwMCBucyksIG1heGxhdD0weDAyICg1MDAgbnMpCmZvdW5k LT4JdmVuZG9yPTB4MTBkZSwgZGV2PTB4MDI2YywgcmV2aWQ9MHhhMgoJYnVzPTAsIHNsb3Q9MTYs IGZ1bmM9MQoJY2xhc3M9MDQtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4 MDAwNiwgc3RhdHJlZz0weDAwYjAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAw ICgwIG5zKSwgbWluZ250PTB4MDIgKDUwMCBucyksIG1heGxhdD0weDA1ICgxMjUwIG5zKQoJaW50 cGluPWIsIGlycT0xMQoJcG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQzICBjdXJyZW50IEQwCglN U0kgc3VwcG9ydHMgMSBtZXNzYWdlLCA2NCBiaXQsIHZlY3RvciBtYXNrcwoJbWFwWzEwXTogdHlw ZSAxLCByYW5nZSAzMiwgYmFzZSBjMDAwMDAwMCwgc2l6ZSAxNCwgZW5hYmxlZApwY2liMDogbWF0 Y2hlZCBlbnRyeSBmb3IgMC4xNi5JTlRCIChzcmMgXFxfU0JfLlBDSTAuTEFaQTowKQpwY2liMDog c2xvdCAxNiBJTlRCIHJvdXRlZCB0byBpcnEgMTEgdmlhIFxcX1NCXy5QQ0kwLkxBWkEKZm91bmQt Pgl2ZW5kb3I9MHgxMGRlLCBkZXY9MHgwMjY5LCByZXZpZD0weGEzCglidXM9MCwgc2xvdD0yMCwg ZnVuYz0wCgljbGFzcz0wNi04MC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCgljbWRyZWc9MHgw MDA3LCBzdGF0cmVnPTB4MDBiMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAg KDAgbnMpLCBtaW5nbnQ9MHgwMSAoMjUwIG5zKSwgbWF4bGF0PTB4MTQgKDUwMDAgbnMpCglpbnRw aW49YSwgaXJxPTEwCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQg RDAKCW1hcFsxMF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgYzAwMDcwMDAsIHNpemUgMTIsIGVu YWJsZWQKCW1hcFsxNF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDMwYjgsIHNpemUgIDMs IGVuYWJsZWQKcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjAuSU5UQSAoc3JjIFxcX1NCXy5Q Q0kwLkxNQUM6MCkKcGNpX2xpbmsxMTogUGlja2VkIElSUSA1IHdpdGggd2VpZ2h0IDEKcGNpYjA6 IHNsb3QgMjAgSU5UQSByb3V0ZWQgdG8gaXJxIDUgdmlhIFxcX1NCXy5QQ0kwLkxNQUMKZm91bmQt Pgl2ZW5kb3I9MHgxMDIyLCBkZXY9MHgxMTAwLCByZXZpZD0weDAwCglidXM9MCwgc2xvdD0yNCwg ZnVuYz0wCgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgw MDAwLCBzdGF0cmVnPTB4MDAxMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAg KDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpmb3VuZC0+CXZl bmRvcj0weDEwMjIsIGRldj0weDExMDEsIHJldmlkPTB4MDAKCWJ1cz0wLCBzbG90PTI0LCBmdW5j PTEKCWNsYXNzPTA2LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAwMDAs IHN0YXRyZWc9MHgwMDAwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQoJbGF0dGltZXI9MHgwMCAoMCBu cyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4JdmVuZG9y PTB4MTAyMiwgZGV2PTB4MTEwMiwgcmV2aWQ9MHgwMAoJYnVzPTAsIHNsb3Q9MjQsIGZ1bmM9MgoJ Y2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQoJY21kcmVnPTB4MDAwMCwgc3Rh dHJlZz0weDAwMDAsIGNhY2hlbG5zej0wIChkd29yZHMpCglsYXR0aW1lcj0weDAwICgwIG5zKSwg bWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKZm91bmQtPgl2ZW5kb3I9MHgx MDIyLCBkZXY9MHgxMTAzLCByZXZpZD0weDAwCglidXM9MCwgc2xvdD0yNCwgZnVuYz0zCgljbGFz cz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMDAwLCBzdGF0cmVn PTB4MDAwMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5n bnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpwY2kwOiA8bWVtb3J5LCBSQU0+IGF0 IGRldmljZSAwLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPG1lbW9yeSwgUkFNPiBhdCBk ZXZpY2UgMC4xIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxtZW1vcnksIFJBTT4gYXQgZGV2 aWNlIDAuMiAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8bWVtb3J5LCBSQU0+IGF0IGRldmlj ZSAwLjMgKG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPG1lbW9yeSwgUkFNPiBhdCBkZXZpY2Ug MC40IChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxtZW1vcnksIFJBTT4gYXQgZGV2aWNlIDAu NSAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2kwOiA8bWVtb3J5LCBSQU0+IGF0IGRldmljZSAwLjYg KG5vIGRyaXZlciBhdHRhY2hlZCkKcGNpMDogPG1lbW9yeSwgUkFNPiBhdCBkZXZpY2UgMC43IChu byBkcml2ZXIgYXR0YWNoZWQpCm52aWRpYTA6IDxHZUZvcmNlIEdvIDYxMDA+IG1lbSAweGMyMDAw MDAwLTB4YzJmZmZmZmYsMHhkMDAwMDAwMC0weGRmZmZmZmZmLDB4YzEwMDAwMDAtMHhjMWZmZmZm ZiBpcnEgNSBhdCBkZXZpY2UgNS4wIG9uIHBjaTAKbnZpZGlhMDogUmVzZXJ2ZWQgMHgxMDAwMDAw IGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhjMjAwMDAwMApudmlkaWEwOiBSZXNlcnZl ZCAweDEwMDAwMDAwIGJ5dGVzIGZvciByaWQgMHgxNCB0eXBlIDMgYXQgMHhkMDAwMDAwMApudmlk aWEwOiBSZXNlcnZlZCAweDEwMDAwMDAgYnl0ZXMgZm9yIHJpZCAweDFjIHR5cGUgMyBhdCAweGMx MDAwMDAwCm52aWRpYTA6IFtHSUFOVC1MT0NLRURdCnBjaTA6IDxtZW1vcnksIFJBTT4gYXQgZGV2 aWNlIDkuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBk ZXZpY2UgMTAuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMApuZnNtYjA6IDxuRm9y Y2UyLzMvNCBNQ1AgU01CdXMgQ29udHJvbGxlcj4gcG9ydCAweDMwNDAtMHgzMDdmLDB4MzAwMC0w eDMwM2YgaXJxIDcgYXQgZGV2aWNlIDEwLjEgb24gcGNpMApuZnNtYjA6IFJlc2VydmVkIDB4NDAg Ynl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweDMwNDAKc21idXMwOiA8U3lzdGVtIE1hbmFn ZW1lbnQgQnVzPiBvbiBuZnNtYjAKc21iMDogPFNNQnVzIGdlbmVyaWMgSS9PPiBvbiBzbWJ1czAK bmZzbWIxOiA8bkZvcmNlMi8zLzQgTUNQIFNNQnVzIENvbnRyb2xsZXI+IG9uIG5mc21iMApuZnNt YjA6IFJlc2VydmVkIDB4NDAgYnl0ZXMgZm9yIHJpZCAweDI0IHR5cGUgNCBhdCAweDMwMDAKc21i dXMxOiA8U3lzdGVtIE1hbmFnZW1lbnQgQnVzPiBvbiBuZnNtYjEKc21iMTogPFNNQnVzIGdlbmVy aWMgSS9PPiBvbiBzbWJ1czEKb2hjaTA6IDxPSENJIChnZW5lcmljKSBVU0IgY29udHJvbGxlcj4g bWVtIDB4YzAwMDQwMDAtMHhjMDAwNGZmZiBpcnEgMTEgYXQgZGV2aWNlIDExLjAgb24gcGNpMApv aGNpMDogUmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhjMDAw NDAwMApvaGNpMDogW0dJQU5ULUxPQ0tFRF0KdXNiMDogT0hDSSB2ZXJzaW9uIDEuMCwgbGVnYWN5 IHN1cHBvcnQKdXNiMDogU01NIGRvZXMgbm90IHJlc3BvbmQsIHJlc2V0dGluZwp1c2IwOiA8T0hD SSAoZ2VuZXJpYykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kwCnVzYjA6IFVTQiByZXZpc2lvbiAx LjAKdXNiZF9nZXRfc3RyaW5nOiBnZXR0aW5nIGxhbmcgZmFpbGVkLCB1c2luZyAwCnVodWIwOiA8 blZpZGlhIE9IQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBv biB1c2IwCnVodWIwOiA4IHBvcnRzIHdpdGggOCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAplaGNp MDogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4YzAwMDUwMDAtMHhj MDAwNTBmZiBpcnEgOSBhdCBkZXZpY2UgMTEuMSBvbiBwY2kwCmVoY2kwOiBSZXNlcnZlZCAweDEw MCBieXRlcyBmb3IgcmlkIDB4MTAgdHlwZSAzIGF0IDB4YzAwMDUwMDAKZWhjaTA6IFtHSUFOVC1M T0NLRURdCnVzYjE6IEVIQ0kgdmVyc2lvbiAxLjAKdXNiMTogY29tcGFuaW9uIGNvbnRyb2xsZXIs IDggcG9ydHMgZWFjaDogdXNiMAp1c2IxOiA8RUhDSSAoZ2VuZXJpYykgVVNCIDIuMCBjb250cm9s bGVyPiBvbiBlaGNpMAp1c2IxOiBVU0IgcmV2aXNpb24gMi4wCnVodWIxOiA8blZpZGlhIEVIQ0kg cm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2IxCnVodWIx OiA4IHBvcnRzIHdpdGggOCByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1c2JkX25ld19kZXZpY2U6 IGFkZHI9MiwgZ2V0dGluZyBmaXJzdCBkZXNjIGZhaWxlZAp1aHViX2V4cGxvcmU6IHVzYl9uZXdf ZGV2aWNlIGZhaWxlZCwgZXJyb3I9SU9FUlJPUgp1aHViMTogZGV2aWNlIHByb2JsZW0gKElPRVJS T1IpLCBkaXNhYmxpbmcgcG9ydCA4CmF0YXBjaTA6IDxuVmlkaWEgbkZvcmNlIE1DUDUxIFVETUEx MzMgY29udHJvbGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNmNiwweDE3MC0weDE3NywweDM3Niww eDMwODAtMHgzMDhmIGF0IGRldmljZSAxMy4wIG9uIHBjaTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHgx MCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4MzA4MAphdGEwOiA8QVRBIGNoYW5uZWwg MD4gb24gYXRhcGNpMAphdGFwY2kwOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDEwIHR5 cGUgNCBhdCAweDFmMAphdGFwY2kwOiBSZXNlcnZlZCAweDEgYnl0ZXMgZm9yIHJpZCAweDE0IHR5 cGUgNCBhdCAweDNmNgphdGEwOiByZXNldCB0cDEgbWFzaz0wMCBvc3RhdDA9ZmYgb3N0YXQxPWZm CmF0YTA6IFtNUFNBRkVdCmF0YTE6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwCmF0YXBjaTA6 IFJlc2VydmVkIDB4OCBieXRlcyBmb3IgcmlkIDB4MTggdHlwZSA0IGF0IDB4MTcwCmF0YXBjaTA6 IFJlc2VydmVkIDB4MSBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4Mzc2CmF0YTE6IHJl c2V0IHRwMSBtYXNrPTAzIG9zdGF0MD01MCBvc3RhdDE9MDEKYXRhMTogc3RhdDA9MHgxMCBlcnI9 MHgwMSBsc2I9MHgxNCBtc2I9MHhlYgphdGExOiBzdGF0MT0weDAxIGVycj0weDA0IGxzYj0weDAw IG1zYj0weDAwCmF0YTE6IHJlc2V0IHRwMiBzdGF0MD0xMCBzdGF0MT0wMSBkZXZpY2VzPTB4NDxB VEFQSV9NQVNURVI+CmF0YTE6IFtNUFNBRkVdCmF0YXBjaTE6IDxuVmlkaWEgbkZvcmNlIE1DUDUx IFNBVEEzMDAgY29udHJvbGxlcj4gcG9ydCAweDMwYjAtMHgzMGI3LDB4MzBhNC0weDMwYTcsMHgz MGE4LTB4MzBhZiwweDMwYTAtMHgzMGEzLDB4MzA5MC0weDMwOWYgbWVtIDB4YzAwMDYwMDAtMHhj MDAwNmZmZiBpcnEgNyBhdCBkZXZpY2UgMTQuMCBvbiBwY2kwCmF0YXBjaTE6IFJlc2VydmVkIDB4 MTAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweDMwOTAKYXRhcGNpMTogW01QU0FGRV0K YXRhcGNpMTogUmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZvciByaWQgMHgyNCB0eXBlIDMgYXQgMHhj MDAwNjAwMAphdGEyOiA8QVRBIGNoYW5uZWwgMD4gb24gYXRhcGNpMQphdGFwY2kxOiBSZXNlcnZl ZCAweDggYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweDMwYjAKYXRhcGNpMTogUmVzZXJ2 ZWQgMHg0IGJ5dGVzIGZvciByaWQgMHgxNCB0eXBlIDQgYXQgMHgzMGE0CmF0YTI6IFNBVEEgY29u bmVjdCByZWFkeSB0aW1lPTBtcwphdGEyOiBzYXRhX2Nvbm5lY3QgZGV2aWNlcz0weDE8QVRBX01B U1RFUj4KYXRhMjogW01QU0FGRV0KYXRhMzogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTEKYXRh cGNpMTogUmVzZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQgMHgxOCB0eXBlIDQgYXQgMHgzMGE4CmF0 YXBjaTE6IFJlc2VydmVkIDB4NCBieXRlcyBmb3IgcmlkIDB4MWMgdHlwZSA0IGF0IDB4MzBhMAph dGEzOiBTQVRBIGNvbm5lY3Qgc3RhdHVzPTAwMDAwMDAwCmF0YTM6IFtNUFNBRkVdCnBjaWIxOiA8 QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDE2LjAgb24gcGNpMApwY2liMTogICBzZWNv bmRhcnkgYnVzICAgICA0CnBjaWIxOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDUKcGNpYjE6ICAgSS9P IGRlY29kZSAgICAgICAgMHhmMDAwLTB4ZmZmCnBjaWIxOiAgIG1lbW9yeSBkZWNvZGUgICAgIDB4 YzMwMDAwMDAtMHhjMzBmZmZmZgpwY2liMTogICBwcmVmZXRjaGVkIGRlY29kZSAweGZmZjAwMDAw LTB4ZmZmZmYKcGNpYjE6ICAgU3VidHJhY3RpdmVseSBkZWNvZGVkIGJyaWRnZS4KQUNQSTogRm91 bmQgbWF0Y2hpbmcgcGluIGZvciA0LjcuSU5UQSBhdCBmdW5jIDA6IDEwCnBjaV9saW5rMDogQklP UyBJUlEgMTAgZm9yIDQuNy5JTlRBIGlzIGludmFsaWQKQUNQSTogRm91bmQgbWF0Y2hpbmcgcGlu IGZvciA0LjcuSU5UQiBhdCBmdW5jIDE6IDExCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIx CnBjaTQ6IHBoeXNpY2FsIGJ1cz00CmZvdW5kLT4JdmVuZG9yPTB4MTUyNCwgZGV2PTB4MTQxMiwg cmV2aWQ9MHgxMAoJYnVzPTQsIHNsb3Q9NywgZnVuYz0wCgljbGFzcz0wNi0wNy0wMCwgaGRydHlw ZT0weDAyLCBtZmRldj0xCgljbWRyZWc9MHgwMTA0LCBzdGF0cmVnPTB4MDIxMCwgY2FjaGVsbnN6 PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4NDQgKDE3MDAw IG5zKSwgbWF4bGF0PTB4MDMgKDc1MCBucykKCWludHBpbj1hLCBpcnE9MTAKCXBvd2Vyc3BlYyAx ICBzdXBwb3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMAoJbWFwWzEwXTogdHlwZSAxLCByYW5n ZSAzMiwgYmFzZSBjMzAwMDAwMCwgc2l6ZSAxMiwgbWVtb3J5IGRpc2FibGVkCnBjaWIxOiAobnVs bCkgcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGMzMDAwMDAwLTB4YzMwMDBmZmY6IGdvb2QKcGNp YjE6IG1hdGNoZWQgZW50cnkgZm9yIDQuNy5JTlRBIChzcmMgXFxfU0JfLlBDSTAuTE5LMTowKQpw Y2lfbGluazA6IFBpY2tlZCBJUlEgOSB3aXRoIHdlaWdodCAxCnBjaWIxOiBzbG90IDcgSU5UQSBy b3V0ZWQgdG8gaXJxIDkgdmlhIFxcX1NCXy5QQ0kwLkxOSzEKZm91bmQtPgl2ZW5kb3I9MHgxNTI0 LCBkZXY9MHgwNTMwLCByZXZpZD0weDAxCglidXM9NCwgc2xvdD03LCBmdW5jPTEKCWNsYXNzPTA1 LTAxLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTEKCWNtZHJlZz0weDAxMDYsIHN0YXRyZWc9MHgw MjEwLCBjYWNoZWxuc3o9MTYgKGR3b3JkcykKCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5n bnQ9MHgwMSAoMjUwIG5zKSwgbWF4bGF0PTB4MDQgKDEwMDAgbnMpCglpbnRwaW49YiwgaXJxPTEx Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEgRDIgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06 IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgYzMwMDEwMDAsIHNpemUgIDcsIGVuYWJsZWQKcGNpYjE6 IChudWxsKSByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4YzMwMDEwMDAtMHhjMzAwMTA3ZjogZ29v ZApwY2liMTogbWF0Y2hlZCBlbnRyeSBmb3IgNC43LklOVEIgKHNyYyBcXF9TQl8uUENJMC5MTksy OjApCnBjaWIxOiBzbG90IDcgSU5UQiByb3V0ZWQgdG8gaXJxIDExIHZpYSBcXF9TQl8uUENJMC5M TksyCmZvdW5kLT4JdmVuZG9yPTB4MTUyNCwgZGV2PTB4MDU1MCwgcmV2aWQ9MHgwMQoJYnVzPTQs IHNsb3Q9NywgZnVuYz0yCgljbGFzcz0wOC0wNS0wMSwgaGRydHlwZT0weDAwLCBtZmRldj0xCglj bWRyZWc9MHgwMTA2LCBzdGF0cmVnPTB4MDIxMCwgY2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0 aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MjAgKDgwMDAgbnMpLCBtYXhsYXQ9MHg0OCAo MTgwMDAgbnMpCglpbnRwaW49YiwgaXJxPTExCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEg RDIgRDMgIGN1cnJlbnQgRDAKCW1hcFsxMF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgYzMwMDE0 MDAsIHNpemUgIDgsIGVuYWJsZWQKcGNpYjE6IChudWxsKSByZXF1ZXN0ZWQgbWVtb3J5IHJhbmdl IDB4YzMwMDE0MDAtMHhjMzAwMTRmZjogZ29vZApwY2liMTogbWF0Y2hlZCBlbnRyeSBmb3IgNC43 LklOVEIgKHNyYyBcXF9TQl8uUENJMC5MTksyOjApCnBjaWIxOiBzbG90IDcgSU5UQiByb3V0ZWQg dG8gaXJxIDExIHZpYSBcXF9TQl8uUENJMC5MTksyCmZvdW5kLT4JdmVuZG9yPTB4MTUyNCwgZGV2 PTB4MDU1MSwgcmV2aWQ9MHgwMQoJYnVzPTQsIHNsb3Q9NywgZnVuYz00CgljbGFzcz0wNS0wMS0w MCwgaGRydHlwZT0weDAwLCBtZmRldj0xCgljbWRyZWc9MHgwMTA0LCBzdGF0cmVnPTB4MDIxMCwg Y2FjaGVsbnN6PTE2IChkd29yZHMpCglsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4 MjAgKDgwMDAgbnMpLCBtYXhsYXQ9MHg0OCAoMTgwMDAgbnMpCglpbnRwaW49YiwgaXJxPTI1NQoJ cG93ZXJzcGVjIDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwCgltYXBbMTBdOiB0 eXBlIDEsIHJhbmdlIDMyLCBiYXNlIDAwMDAwMDAwLCBzaXplICA4LCBtZW1vcnkgZGlzYWJsZWQK Y2JiMDogPFBDSS1DYXJkQnVzIEJyaWRnZT4gbWVtIDB4YzMwMDAwMDAtMHhjMzAwMGZmZiBpcnEg OSBhdCBkZXZpY2UgNy4wIG9uIHBjaTQKY2JiMDogUmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZvciBy aWQgMHgxMCB0eXBlIDMgYXQgMHhjMzAwMDAwMApjYXJkYnVzMDogPENhcmRCdXMgYnVzPiBvbiBj YmIwCnBjY2FyZDA6IDwxNi1iaXQgUENDYXJkIGJ1cz4gb24gY2JiMApjYmIwOiBbTVBTQUZFXQpj YmIwOiBQQ0kgQ29uZmlndXJhdGlvbiBzcGFjZToKICAweDAwOiAweDE0MTIxNTI0IDB4MDIxMDAx MDcgMHgwNjA3MDAxMCAweDAwODI0MDEwIAogIDB4MTA6IDB4YzMwMDAwMDAgMHgwMjAwMDBhMCAw eDIwMDUwNTA0IDB4ZmZmZmYwMDAgCiAgMHgyMDogMHgwMDAwMDAwMCAweGZmZmZmMDAwIDB4MDAw MDAwMDAgMHhmZmZmZmZmYyAKICAweDMwOiAweDAwMDAwMDAwIDB4ZmZmZmZmZmMgMHgwMDAwMDAw MCAweDA3NDQwMTA5IAogIDB4NDA6IDB4NTQwMzE1NTggMHgwMDAwMDAwMSAweDAwMDAwMDAwIDB4 MDAwMDAwMDAgCiAgMHg1MDogMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAw MDAwMCAKICAweDYwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAw IAogIDB4NzA6IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAg MHg4MDogMHgwMDQwZDAyMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMWQxMTIyMiAKICAweDkw OiAweDYwNDQwMGMwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIAogIDB4YTA6IDB4 ZmUwMTAwMDEgMHgwMGMwMDAwMCAweDAwMDAwMDE4IDB4MDAwMDAwMDcgCiAgMHhiMDogMHgwMDAw MDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweGMwOiAweDAwMDAxMDAz IDB4MDA4MDAwODAgMHgxMDA4MDcwMCAweDAwMDAwN2ZlIAogIDB4ZDA6IDB4MDAwMDAwMjAgMHgw MDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDAwMDAgCiAgMHhlMDogMHgwMDAwMDAwMCAweDAwMDAw MDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAKICAweGYwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAg MHgwMDAwMDAwMCAweDAwMDAwMDAwIApwY2k0OiA8bWVtb3J5LCBmbGFzaD4gYXQgZGV2aWNlIDcu MSAobm8gZHJpdmVyIGF0dGFjaGVkKQpwY2k0OiA8YmFzZSBwZXJpcGhlcmFsPiBhdCBkZXZpY2Ug Ny4yIChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTQ6IDxtZW1vcnksIGZsYXNoPiBhdCBkZXZpY2Ug Ny40IChubyBkcml2ZXIgYXR0YWNoZWQpCnBjaTA6IDxtdWx0aW1lZGlhPiBhdCBkZXZpY2UgMTYu MSAobm8gZHJpdmVyIGF0dGFjaGVkKQpudmUwOiA8TlZJRElBIG5Gb3JjZSBNQ1AxMyBOZXR3b3Jr aW5nIEFkYXB0ZXI+IHBvcnQgMHgzMGI4LTB4MzBiZiBtZW0gMHhjMDAwNzAwMC0weGMwMDA3ZmZm IGlycSA1IGF0IGRldmljZSAyMC4wIG9uIHBjaTAKbnZlMDogbnZlbmV0bGliLm8gdmVyc2lvbiAx LjAtMTMKbnZlMDogUmVzZXJ2ZWQgMHgxMDAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQg MHhjMDAwNzAwMApudmUwOiBFdGhlcm5ldCBhZGRyZXNzIDAwOjkwOmY1OjRmOjE4OjFiCm1paWJ1 czA6IDxNSUkgYnVzPiBvbiBudmUwCnJscGh5MDogPFJUTDgyMDFMIDEwLzEwMCBtZWRpYSBpbnRl cmZhY2U+IG9uIG1paWJ1czAKcmxwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJhc2VU WCwgMTAwYmFzZVRYLUZEWCwgYXV0bwpudmUwOiBicGYgYXR0YWNoZWQKbnZlMDogRXRoZXJuZXQg YWRkcmVzczogMDA6OTA6ZjU6NGY6MTg6MWIKbnZlMDogW01QU0FGRV0KYWNwaV90ejA6IDxUaGVy bWFsIFpvbmU+IG9uIGFjcGkwCmFjcGlfdHowOiBfQ1JUIHZhbHVlIGlzIGFic3VyZCwgaWdub3Jl ZCAoMTU0LjhDKQphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4 NjAsMHg2NCBpcnEgMSBvbiBhY3BpMAphdGtiZDA6IDxBVCBLZXlib2FyZD4gaXJxIDEgb24gYXRr YmRjMAphdGtiZDogdGhlIGN1cnJlbnQga2JkIGNvbnRyb2xsZXIgY29tbWFuZCBieXRlIDAwNDcK YXRrYmQ6IGtleWJvYXJkIElEIDB4NDFhYiAoMikKa2JkMCBhdCBhdGtiZDAKa2JkMDogYXRrYmQw LCBBVCAxMDEvMTAyICgyKSwgY29uZmlnOjB4MCwgZmxhZ3M6MHgzZDAwMDAKYXRrYmQwOiBbR0lB TlQtTE9DS0VEXQpwc20wOiB1bmFibGUgdG8gYWxsb2NhdGUgSVJRCnBzbWNwbnAwOiA8UFMvMiBt b3VzZSBwb3J0PiBpcnEgMTIgb24gYWNwaTAKcHNtMDogY3VycmVudCBjb21tYW5kIGJ5dGU6MDA0 Nwpwc20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9uIGF0a2JkYzAKcHNtMDogW0dJQU5ULUxPQ0tF RF0KcHNtMDogbW9kZWwgSW50ZWxsaU1vdXNlLCBkZXZpY2UgSUQgMy0wMCwgMyBidXR0b25zCnBz bTA6IGNvbmZpZzowMDAwMDAwMCwgZmxhZ3M6MDAwMDAwMDgsIHBhY2tldCBzaXplOjQKcHNtMDog c3luY21hc2s6MDgsIHN5bmNiaXRzOjAwCnNpbzA6IGlycSBtYXBzOiAweGUwMSAweGUxMSAweGUw MSAweGUwMQpzaW8wOiBpcnEgbWFwczogMHhlMDEgMHhlMTEgMHhlMDEgMHhlMDEKc2lvMDogPDE2 NTUwQS1jb21wYXRpYmxlIENPTSBwb3J0PiBwb3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4 MTAgb24gYWNwaTAKc2lvMDogdHlwZSAxNjU1MEEKc2lvMDogW0ZBU1RdCmF0YTogYXRhMCBhbHJl YWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKYXRhOiBhdGExIGFscmVhZHkgZXhpc3RzOyBza2lwcGlu ZyBpdAphdGtiZGM6IGF0a2JkYzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CnNpbzogc2lv MCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Q b3J0IGF0IDIwMwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMjQzCnBucF9pZGVu dGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAyODMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Q b3J0IGF0IDJjMwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMzAzCnBucF9pZGVu dGlmeTogVHJ5aW5nIFJlYWRfUG9ydCBhdCAzNDMKcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Q b3J0IGF0IDM4MwpwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgM2MzClBOUCBJZGVu dGlmeSBjb21wbGV0ZQpzYzogc2MwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdAp2Z2E6IHZn YTAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CmlzYV9wcm9iZV9jaGlsZHJlbjogZGlzYWJs aW5nIFBuUCBkZXZpY2VzCmlzYV9wcm9iZV9jaGlsZHJlbjogcHJvYmluZyBub24tUG5QIGRldmlj ZXMKcG10aW1lcjAgb24gaXNhMApvcm0wOiA8SVNBIE9wdGlvbiBST01zPiBhdCBpb21lbSAweGMw MDAwLTB4Y2VmZmYsMHhjZjAwMC0weGQwN2ZmIHBucGlkIE9STTAwMDAgb24gaXNhMAphZHYwOiBu b3QgcHJvYmVkIChkaXNhYmxlZCkKYWhhMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmFpYzA6IG5v dCBwcm9iZWQgKGRpc2FibGVkKQpidDA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpjczA6IG5vdCBw cm9iZWQgKGRpc2FibGVkKQplZDA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQpmZGMwIGZhaWxlZCB0 byBwcm9iZSBhdCBwb3J0IDB4M2YwIGlycSA2IGRycSAyIG9uIGlzYTAKZmUwOiBub3QgcHJvYmVk IChkaXNhYmxlZCkKaWUwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKbGUwOiBub3QgcHJvYmVkIChk aXNhYmxlZCkKcHBjMCBmYWlsZWQgdG8gcHJvYmUgYXQgaXJxIDcgb24gaXNhMApzYzA6IDxTeXN0 ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMApzYzA6IFZHQSA8MTYgdmlydHVhbCBj b25zb2xlcywgZmxhZ3M9MHgzMDA+CnNjMDogZmIwLCBrYmQxLCB0ZXJtaW5hbCBlbXVsYXRvcjog c2MgKHN5c2NvbnMgdGVybWluYWwpCnNpbzE6IGNvbmZpZ3VyZWQgaXJxIDMgbm90IGluIGJpdG1h cCBvZiBwcm9iZWQgaXJxcyAwCnNpbzE6IHBvcnQgbWF5IG5vdCBiZSBlbmFibGVkCnNpbzE6IGly cSBtYXBzOiAweGUwMSAweGUwMSAweGUwMSAweGUwMQpzaW8xOiBwcm9iZSBmYWlsZWQgdGVzdChz KTogMCAxIDIgNCA2IDcgOQpzaW8xIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4MmY4LTB4MmZm IGlycSAzIG9uIGlzYTAKc2lvMjogbm90IHByb2JlZCAoZGlzYWJsZWQpCnNpbzM6IG5vdCBwcm9i ZWQgKGRpc2FibGVkKQpzbjA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQp2Z2EwOiA8R2VuZXJpYyBJ U0EgVkdBPiBhdCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2Ew CnZ0MDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmlzYV9wcm9iZV9jaGlsZHJlbjogcHJvYmluZyBQ blAgZGV2aWNlcwpEZXZpY2UgY29uZmlndXJhdGlvbiBmaW5pc2hlZC4KcHJvY2ZzIHJlZ2lzdGVy ZWQKVGltZWNvdW50ZXIgIlRTQyIgZnJlcXVlbmN5IDE2MDczMjUxMjEgSHogcXVhbGl0eSA4MDAK VGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYwpMaW51eCBFTEYgZXhlYyBoYW5kbGVy IGluc3RhbGxlZApsbzA6IGJwZiBhdHRhY2hlZAphY3BpX3R6MDogX0NSVCB2YWx1ZSBpcyBhYnN1 cmQsIGlnbm9yZWQgKDE1NC44QykKYWNwaV9hY2FkMDogYWNsaW5lIGluaXRpYWxpemF0aW9uIHN0 YXJ0CmFjcGlfYWNhZDA6IE9uIExpbmUKYWNwaV9hY2FkMDogYWNsaW5lIGluaXRpYWxpemF0aW9u IGRvbmUsIHRyaWVkIDEgdGltZXMKYmF0dGVyeTA6IGJhdHRlcnkgaW5pdGlhbGl6YXRpb24gc3Rh cnQKYmF0dGVyeTA6IGJhdHRlcnkgaW5pdGlhbGl6YXRpb24gZG9uZSwgdHJpZWQgMSB0aW1lcwph dGExLW1hc3RlcjogcGlvPVBJTzQgd2RtYT1XRE1BMiB1ZG1hPVVETUEzMyBjYWJsZT00MCB3aXJl CmFjZDA6IHNldHRpbmcgUElPNCBvbiBuRm9yY2UgTUNQNTEgY2hpcAphY2QwOiBzZXR0aW5nIFVE TUEzMyBvbiBuRm9yY2UgTUNQNTEgY2hpcAphY2QwOiA8VFNTVGNvcnBDRC9EVkRXIFNOLVMwODJE L1NTMDA+IERWRFIgZHJpdmUgYXQgYXRhMSBhcyBtYXN0ZXIKYWNkMDogcmVhZCA0MTM0S0IvcyAo NDEzNEtCL3MpIHdyaXRlIDE3MktCL3MgKDQxMzRLQi9zKSwgMjA0OEtCIGJ1ZmZlciwgVURNQTMz CmFjZDA6IFJlYWRzOiBDRFIsIENEUlcsIENEREEgc3RyZWFtLCBEVkRST00sIERWRFIsIERWRFJB TSwgcGFja2V0CmFjZDA6IFdyaXRlczogQ0RSLCBDRFJXLCBEVkRSLCBEVkRSQU0sIHRlc3Qgd3Jp dGUsIGJ1cm5wcm9vZgphY2QwOiBBdWRpbzogcGxheSwgMjU2IHZvbHVtZSBsZXZlbHMKYWNkMDog TWVjaGFuaXNtOiBlamVjdGFibGUgdHJheSwgdW5sb2NrZWQKYWNkMDogTWVkaXVtOiBuby9ibGFu ayBkaXNjCmF0YTItbWFzdGVyOiBwaW89UElPNCB3ZG1hPVdETUEyIHVkbWE9VURNQTEwMCBjYWJs ZT00MCB3aXJlCmFkNDogNzYzMTlNQiA8RlVKSVRTVSBNSFYyMDgwQkggMDAwMDAwMjg+IGF0IGF0 YTItbWFzdGVyIFNBVEExNTAKYWQ0OiAxNTYzMDE0ODggc2VjdG9ycyBbMTU1MDYxQy8xNkgvNjNT XSAxNiBzZWN0b3JzL2ludGVycnVwdCAxIGRlcHRoIHF1ZXVlCkdFT006IG5ldyBkaXNrIGFkNAph ZDQ6IG5WaWRpYSBjaGVjazEgZmFpbGVkCmFkNDogQWRhcHRlYyBjaGVjazEgZmFpbGVkCmFkNDog TFNJICh2MykgY2hlY2sxIGZhaWxlZAphZDQ6IExTSSAodjIpIGNoZWNrMSBmYWlsZWQKYWQ0OiBG cmVlQlNEIGNoZWNrMSBmYWlsZWQKQVRBIFBzZXVkb1JBSUQgbG9hZGVkClRyeWluZyB0byBtb3Vu dCByb290IGZyb20gdWZzOi9kZXYvYWQ0czFhCnN0YXJ0X2luaXQ6IHRyeWluZyAvc2Jpbi9pbml0 CmxpbnByb2NmcyByZWdpc3RlcmVkCmFjcGlfdHowOiBfQ1JUIHZhbHVlIGlzIGFic3VyZCwgaWdu b3JlZCAoMTU0LjhDKQphY3BpX3R6MDogX0NSVCB2YWx1ZSBpcyBhYnN1cmQsIGlnbm9yZWQgKDE1 NC44QykKdXNiZF9uZXdfZGV2aWNlOiBhZGRyPTIsIGdldHRpbmcgZmlyc3QgZGVzYyBmYWlsZWQK dWh1Yl9leHBsb3JlOiB1c2JfbmV3X2RldmljZSBmYWlsZWQsIGVycm9yPUlPRVJST1IKdWh1YjE6 IGRldmljZSBwcm9ibGVtIChJT0VSUk9SKSwgZGlzYWJsaW5nIHBvcnQgNAo= --------------Boundary-00=_GDH3PWYXFQQMYJ0CCJD0 Content-Disposition: attachment; Filename="pciconf.txt" Content-Type: text/plain; name="pciconf.txt" Content-Transfer-Encoding: base64 bm9uZTBAcGNpMDowOjA6CWNsYXNzPTB4MDUwMDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MDJm MzEwZGUgcmV2PTB4YTIgaGRyPTB4MDAKICAgIHZlbmRvciAgID0gJ05WSURJQSBDb3Jwb3JhdGlv bicKICAgIGNsYXNzICAgID0gbWVtb3J5CiAgICBzdWJjbGFzcyA9IFJBTQpub25lMUBwY2kwOjA6 MToJY2xhc3M9MHgwNTAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgwMmZhMTBkZSByZXY9MHhh MiBoZHI9MHgwMAogICAgdmVuZG9yICAgPSAnTlZJRElBIENvcnBvcmF0aW9uJwogICAgY2xhc3Mg ICAgPSBtZW1vcnkKICAgIHN1YmNsYXNzID0gUkFNCm5vbmUyQHBjaTA6MDoyOgljbGFzcz0weDA1 MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDAyZmUxMGRlIHJldj0weGEyIGhkcj0weDAwCiAg ICB2ZW5kb3IgICA9ICdOVklESUEgQ29ycG9yYXRpb24nCiAgICBjbGFzcyAgICA9IG1lbW9yeQog ICAgc3ViY2xhc3MgPSBSQU0Kbm9uZTNAcGNpMDowOjM6CWNsYXNzPTB4MDUwMDAwIGNhcmQ9MHgw MDAwMDAwMCBjaGlwPTB4MDJmODEwZGUgcmV2PTB4YTIgaGRyPTB4MDAKICAgIHZlbmRvciAgID0g J05WSURJQSBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgID0gbWVtb3J5CiAgICBzdWJjbGFzcyA9 IFJBTQpub25lNEBwY2kwOjA6NDoJY2xhc3M9MHgwNTAwMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9 MHgwMmY5MTBkZSByZXY9MHhhMiBoZHI9MHgwMAogICAgdmVuZG9yICAgPSAnTlZJRElBIENvcnBv cmF0aW9uJwogICAgY2xhc3MgICAgPSBtZW1vcnkKICAgIHN1YmNsYXNzID0gUkFNCm5vbmU1QHBj aTA6MDo1OgljbGFzcz0weDA1MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDAyZmYxMGRlIHJl dj0weGEyIGhkcj0weDAwCiAgICB2ZW5kb3IgICA9ICdOVklESUEgQ29ycG9yYXRpb24nCiAgICBj bGFzcyAgICA9IG1lbW9yeQogICAgc3ViY2xhc3MgPSBSQU0Kbm9uZTZAcGNpMDowOjY6CWNsYXNz PTB4MDUwMDAwIGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MDI3ZjEwZGUgcmV2PTB4YTIgaGRyPTB4 MDAKICAgIHZlbmRvciAgID0gJ05WSURJQSBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgID0gbWVt b3J5CiAgICBzdWJjbGFzcyA9IFJBTQpub25lN0BwY2kwOjA6NzoJY2xhc3M9MHgwNTAwMDAgY2Fy ZD0weDAwMDAwMDAwIGNoaXA9MHgwMjdlMTBkZSByZXY9MHhhMiBoZHI9MHgwMAogICAgdmVuZG9y ICAgPSAnTlZJRElBIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAgPSBtZW1vcnkKICAgIHN1YmNs YXNzID0gUkFNCm52aWRpYTBAcGNpMDo1OjA6CWNsYXNzPTB4MDMwMDAwIGNhcmQ9MHg1NDAzMTU1 OCBjaGlwPTB4MDI0NzEwZGUgcmV2PTB4YTIgaGRyPTB4MDAKICAgIHZlbmRvciAgID0gJ05WSURJ QSBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgID0gZGlzcGxheQogICAgc3ViY2xhc3MgPSBWR0EK bm9uZThAcGNpMDo5OjA6CWNsYXNzPTB4MDUwMDAwIGNhcmQ9MHhjYjg0MTBkZSBjaGlwPTB4MDI3 MDEwZGUgcmV2PTB4YTIgaGRyPTB4MDAKICAgIHZlbmRvciAgID0gJ05WSURJQSBDb3Jwb3JhdGlv bicKICAgIGNsYXNzICAgID0gbWVtb3J5CiAgICBzdWJjbGFzcyA9IFJBTQppc2FiMEBwY2kwOjEw OjA6CWNsYXNzPTB4MDYwMTAwIGNhcmQ9MHg1NDAzMTU1OCBjaGlwPTB4MDI2MDEwZGUgcmV2PTB4 YTMgaGRyPTB4MDAKICAgIHZlbmRvciAgID0gJ05WSURJQSBDb3Jwb3JhdGlvbicKICAgIGNsYXNz ICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyA9IFBDSS1JU0EKbmZzbWIwQHBjaTA6MTA6MToJY2xh c3M9MHgwYzA1MDAgY2FyZD0weDU0MDMxNTU4IGNoaXA9MHgwMjY0MTBkZSByZXY9MHhhMyBoZHI9 MHgwMAogICAgdmVuZG9yICAgPSAnTlZJRElBIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAgPSBz ZXJpYWwgYnVzCiAgICBzdWJjbGFzcyA9IFNNQnVzCm9oY2kwQHBjaTA6MTE6MDoJY2xhc3M9MHgw YzAzMTAgY2FyZD0weDU0MDMxNTU4IGNoaXA9MHgwMjZkMTBkZSByZXY9MHhhMyBoZHI9MHgwMAog ICAgdmVuZG9yICAgPSAnTlZJRElBIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAgPSBzZXJpYWwg YnVzCiAgICBzdWJjbGFzcyA9IFVTQgplaGNpMEBwY2kwOjExOjE6CWNsYXNzPTB4MGMwMzIwIGNh cmQ9MHg1NDAzMTU1OCBjaGlwPTB4MDI2ZTEwZGUgcmV2PTB4YTMgaGRyPTB4MDAKICAgIHZlbmRv ciAgID0gJ05WSURJQSBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgID0gc2VyaWFsIGJ1cwogICAg c3ViY2xhc3MgPSBVU0IKYXRhcGNpMEBwY2kwOjEzOjA6CWNsYXNzPTB4MDEwMThhIGNhcmQ9MHg1 NDAzMTU1OCBjaGlwPTB4MDI2NTEwZGUgcmV2PTB4YTEgaGRyPTB4MDAKICAgIHZlbmRvciAgID0g J05WSURJQSBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgID0gbWFzcyBzdG9yYWdlCiAgICBzdWJj bGFzcyA9IEFUQQphdGFwY2kxQHBjaTA6MTQ6MDoJY2xhc3M9MHgwMTAxODUgY2FyZD0weDU0MDMx NTU4IGNoaXA9MHgwMjY2MTBkZSByZXY9MHhhMSBoZHI9MHgwMAogICAgdmVuZG9yICAgPSAnTlZJ RElBIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAgPSBtYXNzIHN0b3JhZ2UKICAgIHN1YmNsYXNz ID0gQVRBCnBjaWIxQHBjaTA6MTY6MDoJY2xhc3M9MHgwNjA0MDEgY2FyZD0weDAwMDAwMGI4IGNo aXA9MHgwMjZmMTBkZSByZXY9MHhhMiBoZHI9MHgwMQogICAgdmVuZG9yICAgPSAnTlZJRElBIENv cnBvcmF0aW9uJwogICAgY2xhc3MgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzID0gUENJLVBDSQpw Y20wQHBjaTA6MTY6MToJY2xhc3M9MHgwNDAzMDAgY2FyZD0weDU0MDMxNTU4IGNoaXA9MHgwMjZj MTBkZSByZXY9MHhhMiBoZHI9MHgwMAogICAgdmVuZG9yICAgPSAnTlZJRElBIENvcnBvcmF0aW9u JwogICAgY2xhc3MgICAgPSBtdWx0aW1lZGlhCm52ZTBAcGNpMDoyMDowOgljbGFzcz0weDA2ODAw MCBjYXJkPTB4NTQwMzE1NTggY2hpcD0weDAyNjkxMGRlIHJldj0weGEzIGhkcj0weDAwCiAgICB2 ZW5kb3IgICA9ICdOVklESUEgQ29ycG9yYXRpb24nCiAgICBjbGFzcyAgICA9IGJyaWRnZQpob3N0 YjBAcGNpMDoyNDowOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4MDAwMDAwMDAgY2hpcD0weDExMDAx MDIyIHJldj0weDAwIGhkcj0weDAwCiAgICB2ZW5kb3IgICA9ICdBZHZhbmNlZCBNaWNybyBEZXZp Y2VzIChBTUQpJwogICAgZGV2aWNlICAgPSAnQXRobG9uIDY0IC8gT3B0ZXJvbiBIeXBlclRyYW5z cG9ydCBUZWNobm9sb2d5IENvbmZpZ3VyYXRpb24nCiAgICBjbGFzcyAgICA9IGJyaWRnZQogICAg c3ViY2xhc3MgPSBIT1NULVBDSQpob3N0YjFAcGNpMDoyNDoxOgljbGFzcz0weDA2MDAwMCBjYXJk PTB4MDAwMDAwMDAgY2hpcD0weDExMDExMDIyIHJldj0weDAwIGhkcj0weDAwCiAgICB2ZW5kb3Ig ICA9ICdBZHZhbmNlZCBNaWNybyBEZXZpY2VzIChBTUQpJwogICAgZGV2aWNlICAgPSAnQXRobG9u IDY0IC8gT3B0ZXJvbiBBZGRyZXNzIE1hcCcKICAgIGNsYXNzICAgID0gYnJpZGdlCiAgICBzdWJj bGFzcyA9IEhPU1QtUENJCmhvc3RiMkBwY2kwOjI0OjI6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHgw MDAwMDAwMCBjaGlwPTB4MTEwMjEwMjIgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRvciAgID0g J0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCknCiAgICBkZXZpY2UgICA9ICdBdGhsb24gNjQg LyBPcHRlcm9uIERSQU0gQ29udHJvbGxlcicKICAgIGNsYXNzICAgID0gYnJpZGdlCiAgICBzdWJj bGFzcyA9IEhPU1QtUENJCmhvc3RiM0BwY2kwOjI0OjM6CWNsYXNzPTB4MDYwMDAwIGNhcmQ9MHgw MDAwMDAwMCBjaGlwPTB4MTEwMzEwMjIgcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRvciAgID0g J0FkdmFuY2VkIE1pY3JvIERldmljZXMgKEFNRCknCiAgICBkZXZpY2UgICA9ICdBdGhsb24gNjQg LyBPcHRlcm9uIE1pc2NlbGxhbmVvdXMgQ29udHJvbCcKICAgIGNsYXNzICAgID0gYnJpZGdlCiAg ICBzdWJjbGFzcyA9IEhPU1QtUENJCmNiYjBAcGNpNDo3OjA6CWNsYXNzPTB4MDYwNzAwIGNhcmQ9 MHg1NDAzMTU1OCBjaGlwPTB4MTQxMjE1MjQgcmV2PTB4MTAgaGRyPTB4MDIKICAgIHZlbmRvciAg ID0gJ0VORSBUZWNobm9sb2d5IEluYycKICAgIGRldmljZSAgID0gJ0NCLTcxMi83MTQgQ2FyZEJ1 cyBDb250cm9sbGVyJwogICAgY2xhc3MgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzID0gUENJLUNh cmRCdXMKbm9uZTlAcGNpNDo3OjE6CWNsYXNzPTB4MDUwMTAwIGNhcmQ9MHg1NDAzMTU1OCBjaGlw PTB4MDUzMDE1MjQgcmV2PTB4MDEgaGRyPTB4MDAKICAgIHZlbmRvciAgID0gJ0VORSBUZWNobm9s b2d5IEluYycKICAgIGNsYXNzICAgID0gbWVtb3J5CiAgICBzdWJjbGFzcyA9IGZsYXNoCm5vbmUx MEBwY2k0Ojc6MjoJY2xhc3M9MHgwODA1MDEgY2FyZD0weDU0MDMxNTU4IGNoaXA9MHgwNTUwMTUy NCByZXY9MHgwMSBoZHI9MHgwMAogICAgdmVuZG9yICAgPSAnRU5FIFRlY2hub2xvZ3kgSW5jJwog ICAgY2xhc3MgICAgPSBiYXNlIHBlcmlwaGVyYWwKbm9uZTExQHBjaTQ6Nzo0OgljbGFzcz0weDA1 MDEwMCBjYXJkPTB4NTQwMzE1NTggY2hpcD0weDA1NTExNTI0IHJldj0weDAxIGhkcj0weDAwCiAg ICB2ZW5kb3IgICA9ICdFTkUgVGVjaG5vbG9neSBJbmMnCiAgICBjbGFzcyAgICA9IG1lbW9yeQog ICAgc3ViY2xhc3MgPSBmbGFzaAo= --------------Boundary-00=_GDH3PWYXFQQMYJ0CCJD0-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 24 12:52:16 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA33B16A407; Sun, 24 Sep 2006 12:52:16 +0000 (UTC) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from ms-dienst.rz.rwth-aachen.de (ms-1.rz.RWTH-Aachen.DE [134.130.3.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41B0143D49; Sun, 24 Sep 2006 12:52:15 +0000 (GMT) (envelope-from chris@hitnet.RWTH-Aachen.DE) Received: from circe (circe.rz.RWTH-Aachen.DE [134.130.3.36]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0J6300DEIL3130@ms-dienst.rz.rwth-aachen.de>; Sun, 24 Sep 2006 14:52:14 +0200 (MEST) Received: from talos.rz.RWTH-Aachen.DE ([134.130.3.22]) by circe (MailMonitor for SMTP v1.2.2 ) ; Sun, 24 Sep 2006 14:52:13 +0200 (MEST) Received: from bigboss.hitnet.rwth-aachen.de (bigspace.hitnet.RWTH-Aachen.DE [137.226.181.2]) by smarthost.rwth-aachen.de (8.13.7/8.13.1/1) with ESMTP id k8OCqCtY022642; Sun, 24 Sep 2006 14:52:12 +0200 Received: from haakonia.hitnet.rwth-aachen.de ([137.226.181.92]) by bigboss.hitnet.rwth-aachen.de with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.50) id 1GRTSu-0003SV-Vp; Sun, 24 Sep 2006 14:52:13 +0200 Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id 87B863F40B; Sun, 24 Sep 2006 09:23:25 +0200 (CEST) Date: Sun, 24 Sep 2006 09:23:25 +0200 From: Christian Brueffer In-reply-to: <4512E9D1.5020703@freebsd.org> To: Andre Oppermann Message-id: <20060924072325.GA1902@haakonia.hitnet.RWTH-Aachen.DE> MIME-version: 1.0 Content-type: multipart/signed; boundary="lrZ03NoBR/3+SXJZ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.5.11 X-Operating-System: FreeBSD 6.2-PRERELEASE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <4512E9D1.5020703@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: [Fwd: cvs commit: src/sys/dev/em if_em.c] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2006 12:52:16 -0000 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 21, 2006 at 09:36:49PM +0200, Andre Oppermann wrote: > This should fix the TSO problems people have seen with various > em(4) network cards. It was an initialization ordering issue > in the driver. >=20 I can confirm that this fixed the problems I had. Thanks! - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFFjJtbHYXjKDtmC0RAjN9AKCGR8zSp918hpXmmNC1Rh0uxD/GKwCbBDvH qnOBU7Tzke6yjE1qxKLWMmc= =HufV -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 24 15:36:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73DAD16A415; Sun, 24 Sep 2006 15:36:25 +0000 (UTC) (envelope-from freebsd.ruomad@free.fr) Received: from smtp2-g19.free.fr (smtp2-g19.free.fr [212.27.42.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id A900843D45; Sun, 24 Sep 2006 15:36:24 +0000 (GMT) (envelope-from freebsd.ruomad@free.fr) Received: from [192.168.0.100] (vln78-1-82-238-160-33.fbx.proxad.net [82.238.160.33]) by smtp2-g19.free.fr (Postfix) with ESMTP id A6767757AD; Sun, 24 Sep 2006 17:36:21 +0200 (CEST) Message-ID: <4516A5F3.4080105@free.fr> Date: Sun, 24 Sep 2006 17:36:19 +0200 From: Bruno Damour User-Agent: Thunderbird 1.5.0.7 (X11/20060916) MIME-Version: 1.0 To: bu7cher@yandex.ru References: <45166CB4.000004.01220@camay.yandex.ru> In-Reply-To: <45166CB4.000004.01220@camay.yandex.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Problems with USB on CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2006 15:36:25 -0000 Andrey V. Elsukov wrote: > Hi, All! > > I have notebook Maxselect Mission GT3000. > A hardware configuration description (russian): > http://www.maxselect.ru/catalog/models.html?id=4024&template=normal > > o Mobile AMD Sempron > o NVIDIA C51MV+MCP51M > o PCI Express nVidia Geforce Go 6100 > o Realtek HDA > > I have several problems. One is with USB. > When i attach USB Flash disk it's not work. > > usbd_new_device: addr=2, getting first desc failed > uhub_explore: usb_new_device failed, error=IOERROR > uhub1: device problem (IOERROR), disabling port 4 > > http://butcher.heavennet.ru/dmesg.txt > http://butcher.heavennet.ru/pciconf.txt > I've attached dmesg and pciconf. > Any suggestions? > > ------------------------------------------------------------------------ > > Copyright (c) 1992-2006 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 7.0-CURRENT #2: Sun Sep 24 15:03:02 MSD 2006 > butcher@btr-nb.properlan.net:/usr/obj/usr/src/sys/BTR > Preloaded elf kernel "/boot/kernel/kernel" at 0xc0dae000. > Preloaded elf module "/boot/kernel/linux.ko" at 0xc0dae1c4. > Preloaded elf module "/boot/modules/nvidia.ko" at 0xc0dae270. > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0dae31c. > Calibrating clock(s) ... i8254 clock: 1193216 Hz > CLK_USE_I8254_CALIBRATION not specified - using default frequency > Timecounter "i8254" frequency 1193182 Hz quality 0 > Calibrating TSC clock ... TSC clock: 1607325121 Hz > CPU: Mobile AMD Sempron(tm) Processor 2600+ (1607.33-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0xf82 Stepping = 2 > Features=0x78bfbff > AMD Features=0xc0500800 > Data TLB: 32 entries, fully associative > Instruction TLB: 32 entries, fully associative > L1 data cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative > L1 instruction cache: 64 kbytes, 64 bytes/line, 1 lines/tag, 2-way associative > L2 internal cache: 128 kbytes, 64 bytes/line, 1 lines/tag, 8-way associative > real memory = 468844544 (447 MB) > Physical memory chunk(s): > 0x0000000000001000 - 0x000000000009dfff, 643072 bytes (157 pages) > 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) > 0x0000000001025000 - 0x000000001b6fffff, 443396096 bytes (108251 pages) > avail memory = 445120512 (424 MB) > bios32: Found BIOS32 Service Directory header at 0xc00f8390 > bios32: Entry = 0xfdce4 (c00fdce4) Rev = 0 Len = 1 > pcibios: PCI BIOS entry at 0xfdce0+0x0 > pnpbios: Found PnP BIOS data at 0xc00f8420 > pnpbios: Entry = e9cd:86af Rev = 1.0 > Other BIOS signatures found: > ath_rate: version 1.2 > wlan: <802.11 Link Layer> > nfslock: pseudo-device > kbd: new array size 4 > kbd1 at kbdmux0 > mem: > Pentium Pro MTRR support enabled > io: > null: > random: > ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > npx0: INT 16 interface > acpi0: on motherboard > acpi0: [MPSAFE] > pci_open(1): mode 1 addr port (0x0cf8) is 0x80007004 > pci_open(1a): mode1res=0x80000000 (0x80000000) > pci_cfgcheck: device 0 [class=050000] [hdr=80] is there (id=02f310de) > pcibios: BIOS_PRESENT call failed > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: bus 0 dev 10 func 0 > acpi0: Power Button (fixed) > acpi0: wakeup code va 0xcb3c4000 pa 0x9d000 > atpic: Programming IRQ9 as level/low > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: bus 0 dev 10 func 0 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: bus 0 dev 10 func 0 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: bus 0 dev 10 func 0 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: bus 0 dev 10 func 0 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: bus 0 dev 10 func 1 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: bus 0 dev 10 func 1 > acpi_bus_number: root bus has no _BBN, assuming 0 > AcpiOsDerivePciId: bus 0 dev 10 func 1 > ACPI timer: 1/2 1/2 1/2 1/1 1/1 1/2 1/1 1/2 1/1 1/1 -> 10 > Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 > acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 > acpi_ec0: port 0x62,0x66 on acpi0 > pci_link0: Links after initial probe: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link0: Links after initial validation: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link0: Links after disable: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link1: Links after initial probe: > Index IRQ Rtd Ref IRQs > 0 11 N 0 5 7 9 11 14 15 > pci_link1: Links after initial validation: > Index IRQ Rtd Ref IRQs > 0 11 N 0 5 7 9 11 14 15 > pci_link1: Links after disable: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link2: Links after initial probe: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link2: Links after initial validation: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link2: Links after disable: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link3: Links after initial probe: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link3: Links after initial validation: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link3: Links after disable: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link4: Links after initial probe: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link4: Links after initial validation: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link4: Links after disable: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link5: Links after initial probe: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link5: Links after initial validation: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link5: Links after disable: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link6: Links after initial probe: > Index IRQ Rtd Ref IRQs > 0 5 N 0 5 7 9 11 14 15 > pci_link6: Links after initial validation: > Index IRQ Rtd Ref IRQs > 0 5 N 0 5 7 9 11 14 15 > pci_link6: Links after disable: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link7: Links after initial probe: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link7: Links after initial validation: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link7: Links after disable: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link8: Links after initial probe: > Index IRQ Rtd Ref IRQs > 0 10 N 0 5 7 9 11 14 15 > pci_link8: Links after initial validation: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link8: Links after disable: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link9: Links after initial probe: > Index IRQ Rtd Ref IRQs > 0 11 N 0 5 7 9 11 14 15 > pci_link9: Links after initial validation: > Index IRQ Rtd Ref IRQs > 0 11 N 0 5 7 9 11 14 15 > pci_link9: Links after disable: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link10: Links after initial probe: > Index IRQ Rtd Ref IRQs > 0 10 N 0 5 7 9 11 14 15 > pci_link10: Links after initial validation: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link10: Links after disable: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link11: Links after initial probe: > Index IRQ Rtd Ref IRQs > 0 10 N 0 5 7 9 11 14 15 > pci_link11: Links after initial validation: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link11: Links after disable: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link12: Links after initial probe: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link12: Links after initial validation: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link12: Links after disable: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link13: Links after initial probe: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link13: Links after initial validation: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link13: Links after disable: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link14: Links after initial probe: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link14: Links after initial validation: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link14: Links after disable: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link15: Links after initial probe: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link15: Links after initial validation: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link15: Links after disable: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link16: Links after initial probe: > Index IRQ Rtd Ref IRQs > 0 7 N 0 5 7 9 11 14 15 > pci_link16: Links after initial validation: > Index IRQ Rtd Ref IRQs > 0 7 N 0 5 7 9 11 14 15 > pci_link16: Links after disable: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link17: Links after initial probe: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link17: Links after initial validation: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > pci_link17: Links after disable: > Index IRQ Rtd Ref IRQs > 0 255 N 0 5 7 9 11 14 15 > cpu0: on acpi0 > powernow0: on cpu0 > acpi_button0: on acpi0 > acpi_button1: on acpi0 > acpi_acad0: on acpi0 > battery0: on acpi0 > acpi_lid0: on acpi0 > pcib0: port 0xcf8-0xcff on acpi0 > ACPI: Found matching pin for 0.10.INTA at func 1: 10 > pci_link8: BIOS IRQ 10 for 0.10.INTA is invalid > ACPI: Found matching pin for 0.11.INTA at func 0: 11 > ACPI: Found matching pin for 0.11.INTB at func 1: 10 > pci_link10: BIOS IRQ 10 for 0.11.INTB is invalid > ACPI: Found matching pin for 0.20.INTA at func 0: 10 > pci_link11: BIOS IRQ 10 for 0.20.INTA is invalid > ACPI: Found matching pin for 0.16.INTB at func 1: 11 > ACPI: Found matching pin for 0.14.INTA at func 0: 7 > ACPI: Found matching pin for 0.5.INTA at func 0: 5 > pci0: on pcib0 > pci0: physical bus=0 > found-> vendor=0x10de, dev=0x02f3, revid=0xa2 > bus=0, slot=0, func=0 > class=05-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x10de, dev=0x02fa, revid=0xa2 > bus=0, slot=0, func=1 > class=05-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0100, statreg=0x4020, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x10de, dev=0x02fe, revid=0xa2 > bus=0, slot=0, func=2 > class=05-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x10de, dev=0x02f8, revid=0xa2 > bus=0, slot=0, func=3 > class=05-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x00a0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x10de, dev=0x02f9, revid=0xa2 > bus=0, slot=0, func=4 > class=05-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x00a0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x10de, dev=0x02ff, revid=0xa2 > bus=0, slot=0, func=5 > class=05-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x10de, dev=0x027f, revid=0xa2 > bus=0, slot=0, func=6 > class=05-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0100, statreg=0x0020, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x10de, dev=0x027e, revid=0xa2 > bus=0, slot=0, func=7 > class=05-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x10de, dev=0x0247, revid=0xa2 > bus=0, slot=5, func=0 > class=03-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=5 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit > map[10]: type 1, range 32, base c2000000, size 24, enabled > map[14]: type 3, range 64, base d0000000, size 28, enabled > map[1c]: type 1, range 64, base c1000000, size 24, enabled > pcib0: matched entry for 0.5.INTA (src \\_SB_.PCI0.LK3E:0) > pcib0: slot 5 INTA routed to irq 5 via \\_SB_.PCI0.LK3E > found-> vendor=0x10de, dev=0x0270, revid=0xa2 > bus=0, slot=9, func=0 > class=05-00-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x10de, dev=0x0260, revid=0xa3 > bus=0, slot=10, func=0 > class=06-01-00, hdrtype=0x00, mfdev=1 > cmdreg=0x000f, statreg=0x00a0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x10de, dev=0x0264, revid=0xa3 > bus=0, slot=10, func=1 > class=0c-05-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0001, statreg=0x00b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D3 current D0 > map[20]: type 4, range 32, base 00003040, size 6, enabled > map[24]: type 4, range 32, base 00003000, size 6, enabled > pcib0: matched entry for 0.10.INTA (src \\_SB_.PCI0.LSMB:0) > pci_link8: Picked IRQ 7 with weight 0 > pcib0: slot 10 INTA routed to irq 7 via \\_SB_.PCI0.LSMB > found-> vendor=0x10de, dev=0x026d, revid=0xa3 > bus=0, slot=11, func=0 > class=0c-03-10, hdrtype=0x00, mfdev=1 > cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) > intpin=a, irq=11 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type 1, range 32, base c0004000, size 12, enabled > pcib0: matched entry for 0.11.INTA (src \\_SB_.PCI0.LUS0:0) > pcib0: slot 11 INTA routed to irq 11 via \\_SB_.PCI0.LUS0 > found-> vendor=0x10de, dev=0x026e, revid=0xa3 > bus=0, slot=11, func=1 > class=0c-03-20, hdrtype=0x00, mfdev=1 > cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) > intpin=b, irq=10 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type 1, range 32, base c0005000, size 8, enabled > pcib0: matched entry for 0.11.INTB (src \\_SB_.PCI0.LUS2:0) > pci_link10: Picked IRQ 9 with weight 0 > pcib0: slot 11 INTB routed to irq 9 via \\_SB_.PCI0.LUS2 > found-> vendor=0x10de, dev=0x0265, revid=0xa1 > bus=0, slot=13, func=0 > class=01-01-8a, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) > powerspec 2 supports D0 D3 current D0 > map[20]: type 4, range 32, base 00003080, size 4, enabled > found-> vendor=0x10de, dev=0x0266, revid=0xa1 > bus=0, slot=14, func=0 > class=01-01-85, hdrtype=0x00, mfdev=0 > cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) > intpin=a, irq=7 > powerspec 2 supports D0 D3 current D0 > MSI supports 4 messages, 64 bit > map[10]: type 4, range 32, base 000030b0, size 3, enabled > map[14]: type 4, range 32, base 000030a4, size 2, enabled > map[18]: type 4, range 32, base 000030a8, size 3, enabled > map[1c]: type 4, range 32, base 000030a0, size 2, enabled > map[20]: type 4, range 32, base 00003090, size 4, enabled > map[24]: type 1, range 32, base c0006000, size 12, memory disabled > pcib0: matched entry for 0.14.INTA (src \\_SB_.PCI0.LTID:0) > pcib0: slot 14 INTA routed to irq 7 via \\_SB_.PCI0.LTID > found-> vendor=0x10de, dev=0x026f, revid=0xa2 > bus=0, slot=16, func=0 > class=06-04-01, hdrtype=0x01, mfdev=1 > cmdreg=0x0107, statreg=0x00b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x04 (1000 ns), maxlat=0x02 (500 ns) > found-> vendor=0x10de, dev=0x026c, revid=0xa2 > bus=0, slot=16, func=1 > class=04-03-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x05 (1250 ns) > intpin=b, irq=11 > powerspec 2 supports D0 D3 current D0 > MSI supports 1 message, 64 bit, vector masks > map[10]: type 1, range 32, base c0000000, size 14, enabled > pcib0: matched entry for 0.16.INTB (src \\_SB_.PCI0.LAZA:0) > pcib0: slot 16 INTB routed to irq 11 via \\_SB_.PCI0.LAZA > found-> vendor=0x10de, dev=0x0269, revid=0xa3 > bus=0, slot=20, func=0 > class=06-80-00, hdrtype=0x00, mfdev=0 > cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x01 (250 ns), maxlat=0x14 (5000 ns) > intpin=a, irq=10 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type 1, range 32, base c0007000, size 12, enabled > map[14]: type 4, range 32, base 000030b8, size 3, enabled > pcib0: matched entry for 0.20.INTA (src \\_SB_.PCI0.LMAC:0) > pci_link11: Picked IRQ 5 with weight 1 > pcib0: slot 20 INTA routed to irq 5 via \\_SB_.PCI0.LMAC > found-> vendor=0x1022, dev=0x1100, revid=0x00 > bus=0, slot=24, func=0 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0010, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1022, dev=0x1101, revid=0x00 > bus=0, slot=24, func=1 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1022, dev=0x1102, revid=0x00 > bus=0, slot=24, func=2 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > found-> vendor=0x1022, dev=0x1103, revid=0x00 > bus=0, slot=24, func=3 > class=06-00-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords) > lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) > pci0: at device 0.0 (no driver attached) > pci0: at device 0.1 (no driver attached) > pci0: at device 0.2 (no driver attached) > pci0: at device 0.3 (no driver attached) > pci0: at device 0.4 (no driver attached) > pci0: at device 0.5 (no driver attached) > pci0: at device 0.6 (no driver attached) > pci0: at device 0.7 (no driver attached) > nvidia0: mem 0xc2000000-0xc2ffffff,0xd0000000-0xdfffffff,0xc1000000-0xc1ffffff irq 5 at device 5.0 on pci0 > nvidia0: Reserved 0x1000000 bytes for rid 0x10 type 3 at 0xc2000000 > nvidia0: Reserved 0x10000000 bytes for rid 0x14 type 3 at 0xd0000000 > nvidia0: Reserved 0x1000000 bytes for rid 0x1c type 3 at 0xc1000000 > nvidia0: [GIANT-LOCKED] > pci0: at device 9.0 (no driver attached) > isab0: at device 10.0 on pci0 > isa0: on isab0 > nfsmb0: port 0x3040-0x307f,0x3000-0x303f irq 7 at device 10.1 on pci0 > nfsmb0: Reserved 0x40 bytes for rid 0x20 type 4 at 0x3040 > smbus0: on nfsmb0 > smb0: on smbus0 > nfsmb1: on nfsmb0 > nfsmb0: Reserved 0x40 bytes for rid 0x24 type 4 at 0x3000 > smbus1: on nfsmb1 > smb1: on smbus1 > ohci0: mem 0xc0004000-0xc0004fff irq 11 at device 11.0 on pci0 > ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0004000 > ohci0: [GIANT-LOCKED] > usb0: OHCI version 1.0, legacy support > usb0: SMM does not respond, resetting > usb0: on ohci0 > usb0: USB revision 1.0 > usbd_get_string: getting lang failed, using 0 > uhub0: on usb0 > uhub0: 8 ports with 8 removable, self powered > ehci0: mem 0xc0005000-0xc00050ff irq 9 at device 11.1 on pci0 > ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xc0005000 > ehci0: [GIANT-LOCKED] > usb1: EHCI version 1.0 > usb1: companion controller, 8 ports each: usb0 > usb1: on ehci0 > usb1: USB revision 2.0 > uhub1: on usb1 > uhub1: 8 ports with 8 removable, self powered > usbd_new_device: addr=2, getting first desc failed > uhub_explore: usb_new_device failed, error=IOERROR > uhub1: device problem (IOERROR), disabling port 8 > atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x3080-0x308f at device 13.0 on pci0 > atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x3080 > ata0: on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 > atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 > ata0: reset tp1 mask=00 ostat0=ff ostat1=ff > ata0: [MPSAFE] > ata1: on atapci0 > atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 > atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 > ata1: reset tp1 mask=03 ostat0=50 ostat1=01 > ata1: stat0=0x10 err=0x01 lsb=0x14 msb=0xeb > ata1: stat1=0x01 err=0x04 lsb=0x00 msb=0x00 > ata1: reset tp2 stat0=10 stat1=01 devices=0x4 > ata1: [MPSAFE] > atapci1: port 0x30b0-0x30b7,0x30a4-0x30a7,0x30a8-0x30af,0x30a0-0x30a3,0x3090-0x309f mem 0xc0006000-0xc0006fff irq 7 at device 14.0 on pci0 > atapci1: Reserved 0x10 bytes for rid 0x20 type 4 at 0x3090 > atapci1: [MPSAFE] > atapci1: Reserved 0x1000 bytes for rid 0x24 type 3 at 0xc0006000 > ata2: on atapci1 > atapci1: Reserved 0x8 bytes for rid 0x10 type 4 at 0x30b0 > atapci1: Reserved 0x4 bytes for rid 0x14 type 4 at 0x30a4 > ata2: SATA connect ready time=0ms > ata2: sata_connect devices=0x1 > ata2: [MPSAFE] > ata3: on atapci1 > atapci1: Reserved 0x8 bytes for rid 0x18 type 4 at 0x30a8 > atapci1: Reserved 0x4 bytes for rid 0x1c type 4 at 0x30a0 > ata3: SATA connect status=00000000 > ata3: [MPSAFE] > pcib1: at device 16.0 on pci0 > pcib1: secondary bus 4 > pcib1: subordinate bus 5 > pcib1: I/O decode 0xf000-0xfff > pcib1: memory decode 0xc3000000-0xc30fffff > pcib1: prefetched decode 0xfff00000-0xfffff > pcib1: Subtractively decoded bridge. > ACPI: Found matching pin for 4.7.INTA at func 0: 10 > pci_link0: BIOS IRQ 10 for 4.7.INTA is invalid > ACPI: Found matching pin for 4.7.INTB at func 1: 11 > pci4: on pcib1 > pci4: physical bus=4 > found-> vendor=0x1524, dev=0x1412, revid=0x10 > bus=4, slot=7, func=0 > class=06-07-00, hdrtype=0x02, mfdev=1 > cmdreg=0x0104, statreg=0x0210, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x44 (17000 ns), maxlat=0x03 (750 ns) > intpin=a, irq=10 > powerspec 1 supports D0 D1 D2 D3 current D0 > map[10]: type 1, range 32, base c3000000, size 12, memory disabled > pcib1: (null) requested memory range 0xc3000000-0xc3000fff: good > pcib1: matched entry for 4.7.INTA (src \\_SB_.PCI0.LNK1:0) > pci_link0: Picked IRQ 9 with weight 1 > pcib1: slot 7 INTA routed to irq 9 via \\_SB_.PCI0.LNK1 > found-> vendor=0x1524, dev=0x0530, revid=0x01 > bus=4, slot=7, func=1 > class=05-01-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0106, statreg=0x0210, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x01 (250 ns), maxlat=0x04 (1000 ns) > intpin=b, irq=11 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type 1, range 32, base c3001000, size 7, enabled > pcib1: (null) requested memory range 0xc3001000-0xc300107f: good > pcib1: matched entry for 4.7.INTB (src \\_SB_.PCI0.LNK2:0) > pcib1: slot 7 INTB routed to irq 11 via \\_SB_.PCI0.LNK2 > found-> vendor=0x1524, dev=0x0550, revid=0x01 > bus=4, slot=7, func=2 > class=08-05-01, hdrtype=0x00, mfdev=1 > cmdreg=0x0106, statreg=0x0210, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x48 (18000 ns) > intpin=b, irq=11 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type 1, range 32, base c3001400, size 8, enabled > pcib1: (null) requested memory range 0xc3001400-0xc30014ff: good > pcib1: matched entry for 4.7.INTB (src \\_SB_.PCI0.LNK2:0) > pcib1: slot 7 INTB routed to irq 11 via \\_SB_.PCI0.LNK2 > found-> vendor=0x1524, dev=0x0551, revid=0x01 > bus=4, slot=7, func=4 > class=05-01-00, hdrtype=0x00, mfdev=1 > cmdreg=0x0104, statreg=0x0210, cachelnsz=16 (dwords) > lattimer=0x40 (1920 ns), mingnt=0x20 (8000 ns), maxlat=0x48 (18000 ns) > intpin=b, irq=255 > powerspec 2 supports D0 D1 D2 D3 current D0 > map[10]: type 1, range 32, base 00000000, size 8, memory disabled > cbb0: mem 0xc3000000-0xc3000fff irq 9 at device 7.0 on pci4 > cbb0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc3000000 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > cbb0: [MPSAFE] > cbb0: PCI Configuration space: > 0x00: 0x14121524 0x02100107 0x06070010 0x00824010 > 0x10: 0xc3000000 0x020000a0 0x20050504 0xfffff000 > 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc > 0x30: 0x00000000 0xfffffffc 0x00000000 0x07440109 > 0x40: 0x54031558 0x00000001 0x00000000 0x00000000 > 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 > 0x80: 0x0040d020 0x00000000 0x00000000 0x01d11222 > 0x90: 0x604400c0 0x00000000 0x00000000 0x00000000 > 0xa0: 0xfe010001 0x00c00000 0x00000018 0x00000007 > 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xc0: 0x00001003 0x00800080 0x10080700 0x000007fe > 0xd0: 0x00000020 0x00000000 0x00000000 0x00000000 > 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 > 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 > pci4: at device 7.1 (no driver attached) > pci4: at device 7.2 (no driver attached) > pci4: at device 7.4 (no driver attached) > pci0: at device 16.1 (no driver attached) > nve0: port 0x30b8-0x30bf mem 0xc0007000-0xc0007fff irq 5 at device 20.0 on pci0 > nve0: nvenetlib.o version 1.0-13 > nve0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xc0007000 > nve0: Ethernet address 00:90:f5:4f:18:1b > miibus0: on nve0 > rlphy0: on miibus0 > rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > nve0: bpf attached > nve0: Ethernet address: 00:90:f5:4f:18:1b > nve0: [MPSAFE] > acpi_tz0: on acpi0 > acpi_tz0: _CRT value is absurd, ignored (154.8C) > atkbdc0: port 0x60,0x64 irq 1 on acpi0 > atkbd0: irq 1 on atkbdc0 > atkbd: the current kbd controller command byte 0047 > atkbd: keyboard ID 0x41ab (2) > kbd0 at atkbd0 > kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 > atkbd0: [GIANT-LOCKED] > psm0: unable to allocate IRQ > psmcpnp0: irq 12 on acpi0 > psm0: current command byte:0047 > psm0: irq 12 on atkbdc0 > psm0: [GIANT-LOCKED] > psm0: model IntelliMouse, device ID 3-00, 3 buttons > psm0: config:00000000, flags:00000008, packet size:4 > psm0: syncmask:08, syncbits:00 > sio0: irq maps: 0xe01 0xe11 0xe01 0xe01 > sio0: irq maps: 0xe01 0xe11 0xe01 0xe01 > sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > sio0: type 16550A > sio0: [FAST] > ata: ata0 already exists; skipping it > ata: ata1 already exists; skipping it > atkbdc: atkbdc0 already exists; skipping it > sio: sio0 already exists; skipping it > pnp_identify: Trying Read_Port at 203 > pnp_identify: Trying Read_Port at 243 > pnp_identify: Trying Read_Port at 283 > pnp_identify: Trying Read_Port at 2c3 > pnp_identify: Trying Read_Port at 303 > pnp_identify: Trying Read_Port at 343 > pnp_identify: Trying Read_Port at 383 > pnp_identify: Trying Read_Port at 3c3 > PNP Identify complete > sc: sc0 already exists; skipping it > vga: vga0 already exists; skipping it > isa_probe_children: disabling PnP devices > isa_probe_children: probing non-PnP devices > pmtimer0 on isa0 > orm0: at iomem 0xc0000-0xcefff,0xcf000-0xd07ff pnpid ORM0000 on isa0 > adv0: not probed (disabled) > aha0: not probed (disabled) > aic0: not probed (disabled) > bt0: not probed (disabled) > cs0: not probed (disabled) > ed0: not probed (disabled) > fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 > fe0: not probed (disabled) > ie0: not probed (disabled) > le0: not probed (disabled) > ppc0 failed to probe at irq 7 on isa0 > sc0: at flags 0x100 on isa0 > sc0: VGA <16 virtual consoles, flags=0x300> > sc0: fb0, kbd1, terminal emulator: sc (syscons terminal) > sio1: configured irq 3 not in bitmap of probed irqs 0 > sio1: port may not be enabled > sio1: irq maps: 0xe01 0xe01 0xe01 0xe01 > sio1: probe failed test(s): 0 1 2 4 6 7 9 > sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 > sio2: not probed (disabled) > sio3: not probed (disabled) > sn0: not probed (disabled) > vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > vt0: not probed (disabled) > isa_probe_children: probing PnP devices > Device configuration finished. > procfs registered > Timecounter "TSC" frequency 1607325121 Hz quality 800 > Timecounters tick every 1.000 msec > Linux ELF exec handler installed > lo0: bpf attached > acpi_tz0: _CRT value is absurd, ignored (154.8C) > acpi_acad0: acline initialization start > acpi_acad0: On Line > acpi_acad0: acline initialization done, tried 1 times > battery0: battery initialization start > battery0: battery initialization done, tried 1 times > ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire > acd0: setting PIO4 on nForce MCP51 chip > acd0: setting UDMA33 on nForce MCP51 chip > acd0: DVDR drive at ata1 as master > acd0: read 4134KB/s (4134KB/s) write 172KB/s (4134KB/s), 2048KB buffer, UDMA33 > acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet > acd0: Writes: CDR, CDRW, DVDR, DVDRAM, test write, burnproof > acd0: Audio: play, 256 volume levels > acd0: Mechanism: ejectable tray, unlocked > acd0: Medium: no/blank disc > ata2-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=40 wire > ad4: 76319MB at ata2-master SATA150 > ad4: 156301488 sectors [155061C/16H/63S] 16 sectors/interrupt 1 depth queue > GEOM: new disk ad4 > ad4: nVidia check1 failed > ad4: Adaptec check1 failed > ad4: LSI (v3) check1 failed > ad4: LSI (v2) check1 failed > ad4: FreeBSD check1 failed > ATA PseudoRAID loaded > Trying to mount root from ufs:/dev/ad4s1a > start_init: trying /sbin/init > linprocfs registered > acpi_tz0: _CRT value is absurd, ignored (154.8C) > acpi_tz0: _CRT value is absurd, ignored (154.8C) > usbd_new_device: addr=2, getting first desc failed > uhub_explore: usb_new_device failed, error=IOERROR > uhub1: device problem (IOERROR), disabling port 4 > > ------------------------------------------------------------------------ > > none0@pci0:0:0: class=0x050000 card=0x00000000 chip=0x02f310de rev=0xa2 hdr=0x00 > vendor = 'NVIDIA Corporation' > class = memory > subclass = RAM > none1@pci0:0:1: class=0x050000 card=0x00000000 chip=0x02fa10de rev=0xa2 hdr=0x00 > vendor = 'NVIDIA Corporation' > class = memory > subclass = RAM > none2@pci0:0:2: class=0x050000 card=0x00000000 chip=0x02fe10de rev=0xa2 hdr=0x00 > vendor = 'NVIDIA Corporation' > class = memory > subclass = RAM > none3@pci0:0:3: class=0x050000 card=0x00000000 chip=0x02f810de rev=0xa2 hdr=0x00 > vendor = 'NVIDIA Corporation' > class = memory > subclass = RAM > none4@pci0:0:4: class=0x050000 card=0x00000000 chip=0x02f910de rev=0xa2 hdr=0x00 > vendor = 'NVIDIA Corporation' > class = memory > subclass = RAM > none5@pci0:0:5: class=0x050000 card=0x00000000 chip=0x02ff10de rev=0xa2 hdr=0x00 > vendor = 'NVIDIA Corporation' > class = memory > subclass = RAM > none6@pci0:0:6: class=0x050000 card=0x00000000 chip=0x027f10de rev=0xa2 hdr=0x00 > vendor = 'NVIDIA Corporation' > class = memory > subclass = RAM > none7@pci0:0:7: class=0x050000 card=0x00000000 chip=0x027e10de rev=0xa2 hdr=0x00 > vendor = 'NVIDIA Corporation' > class = memory > subclass = RAM > nvidia0@pci0:5:0: class=0x030000 card=0x54031558 chip=0x024710de rev=0xa2 hdr=0x00 > vendor = 'NVIDIA Corporation' > class = display > subclass = VGA > none8@pci0:9:0: class=0x050000 card=0xcb8410de chip=0x027010de rev=0xa2 hdr=0x00 > vendor = 'NVIDIA Corporation' > class = memory > subclass = RAM > isab0@pci0:10:0: class=0x060100 card=0x54031558 chip=0x026010de rev=0xa3 hdr=0x00 > vendor = 'NVIDIA Corporation' > class = bridge > subclass = PCI-ISA > nfsmb0@pci0:10:1: class=0x0c0500 card=0x54031558 chip=0x026410de rev=0xa3 hdr=0x00 > vendor = 'NVIDIA Corporation' > class = serial bus > subclass = SMBus > ohci0@pci0:11:0: class=0x0c0310 card=0x54031558 chip=0x026d10de rev=0xa3 hdr=0x00 > vendor = 'NVIDIA Corporation' > class = serial bus > subclass = USB > ehci0@pci0:11:1: class=0x0c0320 card=0x54031558 chip=0x026e10de rev=0xa3 hdr=0x00 > vendor = 'NVIDIA Corporation' > class = serial bus > subclass = USB > atapci0@pci0:13:0: class=0x01018a card=0x54031558 chip=0x026510de rev=0xa1 hdr=0x00 > vendor = 'NVIDIA Corporation' > class = mass storage > subclass = ATA > atapci1@pci0:14:0: class=0x010185 card=0x54031558 chip=0x026610de rev=0xa1 hdr=0x00 > vendor = 'NVIDIA Corporation' > class = mass storage > subclass = ATA > pcib1@pci0:16:0: class=0x060401 card=0x000000b8 chip=0x026f10de rev=0xa2 hdr=0x01 > vendor = 'NVIDIA Corporation' > class = bridge > subclass = PCI-PCI > pcm0@pci0:16:1: class=0x040300 card=0x54031558 chip=0x026c10de rev=0xa2 hdr=0x00 > vendor = 'NVIDIA Corporation' > class = multimedia > nve0@pci0:20:0: class=0x068000 card=0x54031558 chip=0x026910de rev=0xa3 hdr=0x00 > vendor = 'NVIDIA Corporation' > class = bridge > hostb0@pci0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > device = 'Athlon 64 / Opteron HyperTransport Technology Configuration' > class = bridge > subclass = HOST-PCI > hostb1@pci0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > device = 'Athlon 64 / Opteron Address Map' > class = bridge > subclass = HOST-PCI > hostb2@pci0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > device = 'Athlon 64 / Opteron DRAM Controller' > class = bridge > subclass = HOST-PCI > hostb3@pci0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 > vendor = 'Advanced Micro Devices (AMD)' > device = 'Athlon 64 / Opteron Miscellaneous Control' > class = bridge > subclass = HOST-PCI > cbb0@pci4:7:0: class=0x060700 card=0x54031558 chip=0x14121524 rev=0x10 hdr=0x02 > vendor = 'ENE Technology Inc' > device = 'CB-712/714 CardBus Controller' > class = bridge > subclass = PCI-CardBus > none9@pci4:7:1: class=0x050100 card=0x54031558 chip=0x05301524 rev=0x01 hdr=0x00 > vendor = 'ENE Technology Inc' > class = memory > subclass = flash > none10@pci4:7:2: class=0x080501 card=0x54031558 chip=0x05501524 rev=0x01 hdr=0x00 > vendor = 'ENE Technology Inc' > class = base peripheral > none11@pci4:7:4: class=0x050100 card=0x54031558 chip=0x05511524 rev=0x01 hdr=0x00 > vendor = 'ENE Technology Inc' > class = memory > subclass = flash > > ------------------------------------------------------------------------ > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" I have the same problem, I reported it earlier but none seemed to have any clue. I'm running freebsd-current and an Asus MN2PV-VM (Nforce430+GeForce 6150 integrated chipset) Bruno From owner-freebsd-current@FreeBSD.ORG Sun Sep 24 17:07:48 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D4F8516A415; Sun, 24 Sep 2006 17:07:48 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42E6743D55; Sun, 24 Sep 2006 17:07:48 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id k8OH7lrw021585; Sun, 24 Sep 2006 10:07:47 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id k8OH7l9g021584; Sun, 24 Sep 2006 10:07:47 -0700 (PDT) (envelope-from david) Date: Sun, 24 Sep 2006 10:07:47 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20060924170747.GM698@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org, netchild@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Jxom2kD0UhQdW59L" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: netchild@freebsd.org Subject: [PATCH] Problem with src/sys/dev/sound/pcm/mixer.c rev. 1.50 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Sep 2006 17:07:49 -0000 --Jxom2kD0UhQdW59L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable During today's CURRENT build, I encountered: >>> stage 3.2: building everything =2E.. cc -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -Wst= rict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual = -Wundef -fformat-extensions -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/s= ys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.= h -fno-common -finline-limit=3D8000 --param inline-unit-growth=3D100 --para= m large-function-growth=3D1000 -mno-align-long-strings -mpreferred-stack-b= oundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestandin= g -Werror /usr/src/sys/dev/sound/pcm/feeder_volume.c cc -c -O -pipe -std=3Dc99 -g -Wall -Wredundant-decls -Wnested-externs -Wst= rict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual = -Wundef -fformat-extensions -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/s= ys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.= h -fno-common -finline-limit=3D8000 --param inline-unit-growth=3D100 --para= m large-function-growth=3D1000 -mno-align-long-strings -mpreferred-stack-b= oundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestandin= g -Werror /usr/src/sys/dev/sound/pcm/mixer.c /usr/src/sys/dev/sound/pcm/mixer.c: In function `mixer_oss_mixerinfo': /usr/src/sys/dev/sound/pcm/mixer.c:761: warning: 'd' might be used uninitia= lized in this function *** Error code 1 Stop in /common/S4/obj/usr/src/sys/LAPTOP_30W. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. This was with rev. 1.50 of src/sys/dev/sound/pcm/mixer.c. I'm not sure the following patch is correct, but making this change did allow the kernel to build, install, and boot, which seemed an improvement at the time: Index: sys/dev/sound/pcm/mixer.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /cvs/freebsd/src/sys/dev/sound/pcm/mixer.c,v retrieving revision 1.50 diff -u -r1.50 mixer.c --- sys/dev/sound/pcm/mixer.c 23 Sep 2006 20:45:47 -0000 1.50 +++ sys/dev/sound/pcm/mixer.c 24 Sep 2006 16:38:54 -0000 @@ -770,6 +770,7 @@ if ((mi->dev =3D=3D -1) && (i_dev->si_devsw !=3D &mixer_cdevsw)) return EINVAL; =20 + d =3D NULL; m =3D NULL; t_cdev =3D NULL; nmix =3D 0; Peace, david --=20 David H. Wolfskill david@catwhisker.org Believe SORBS at your own risk: 63.193.123.122 has been static since Aug 19= 99. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --Jxom2kD0UhQdW59L Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkUWu2IACgkQmprOCmdXAD1e3wCeJZZ0e1Ppt9CahfiHYd9eYyzB g4UAn1g4C3fRBNTYNHebbkNDCbTlMal9 =ykpH -----END PGP SIGNATURE----- --Jxom2kD0UhQdW59L-- From owner-freebsd-current@FreeBSD.ORG Sun Sep 24 17:39:07 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 935E416A407 for ; Sun, 24 Sep 2006 17:39:07 +0000 (UTC) (envelope-from netchild@FreeBSD.org) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3C1A43D4C for ; Sun, 24 Sep 2006 17:39:06 +0000 (GMT) (envelope-from netchild@FreeBSD.org) Received: from Andro-Beta.Leidinger.net (p54A5CF73.dip.t-dialin.net [84.165.207.115]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k8OHEfQe047743; Sun, 24 Sep 2006 19:14:42 +0200 (CEST) (envelope-from netchild@FreeBSD.org) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k8OHcrk5070579; Sun, 24 Sep 2006 19:38:54 +0200 (CEST) (envelope-from netchild@FreeBSD.org) Date: Sun, 24 Sep 2006 19:39:35 +0200 From: Alexander Leidinger To: David Wolfskill Message-ID: <20060924193935.56c6d22d@Magellan.Leidinger.net> In-Reply-To: <20060924170747.GM698@bunrab.catwhisker.org> References: <20060924170747.GM698@bunrab.catwhisker.org> Organization: FreeBSD X-Mailer: Sylpheed-Claws 2.4.0 (GTK+ 2.8.20; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Cc: current@FreeBSD.org Subject: Re: [PATCH] Problem with src/sys/dev/sound/pcm/mixer.c rev. 1.50 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Sep 2006 17:39:07 -0000 Quoting David Wolfskill (Sun, 24 Sep 2006 10:07:47 -0700): > I'm not sure the following patch is correct, but making this change did > allow the kernel to build, install, and boot, which seemed an improvement > at the time: Committed. Thanks, Alexander. -- ...and that is how we know the Earth to be banana-shaped. 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 Sun Sep 24 19:29:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 21B1E16A47B for ; Sun, 24 Sep 2006 19:29:25 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E7CA43D5C for ; Sun, 24 Sep 2006 19:29:17 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so1616038wxd for ; Sun, 24 Sep 2006 12:29:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SzP5eYS6ZhD5lC1JqXSfrYdKd3/kBAAmHtggx4QrN+aN90Cd2pS6iJfgDkQUbdTyBeVQ3F9nFFUBLXYyst17wAK6Ft0XL8uXsKIbiGQl8bRaqdZdf5GDJ6K46wUFtT9ANAmtqQvRRIwsHqiH/f76JM6ePnincQ4pnosoREtIfdg= Received: by 10.90.81.14 with SMTP id e14mr1112335agb; Sun, 24 Sep 2006 12:29:03 -0700 (PDT) Received: by 10.90.70.6 with HTTP; Sun, 24 Sep 2006 12:29:03 -0700 (PDT) Message-ID: <7579f7fb0609241229v105d16fagb985655dadc2d3e8@mail.gmail.com> Date: Sun, 24 Sep 2006 12:29:03 -0700 From: "Matthew Jacob" To: "YONETANI Tomokazu" In-Reply-To: <20060924071601.GA1080@les.ath.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1157154024.835.6.camel@atomizer.opensourcebeef.net> <20060924071601.GA1080@les.ath.cx> Cc: freebsd-current@freebsd.org Subject: Re: LSI 1030 mpt doesn't work if I build a new kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Sep 2006 19:29:25 -0000 I see no I/O related errors in your message that could definitely isolate it to the 1030. On 9/24/06, YONETANI Tomokazu wrote: > Hi, > Recently I tried installing FreeBSD 5.4-RELEASE on an IBM X335 in my > office and tried to upgrade to 6.2-PRERELEASE, and found that although > it doesn't hang or panic during boot, running I/O intensive applications > (including buildworld) ends up in an I/O error, and eventually panicked and > rebooted. So I tried earlier versions to find out when the problem started > to occur, and found that it started as early as 5.5-STABLE. I noticed that > new mpt driver has been MFC after 5.4-RELEASE, so maybe that's something > to do with this issue. > Kernels other than 5.4 are all built on 5.4-RELEASE system using GENERIC file > without any optimization flags. I haven't tried CURRENT yet because > buildworld didn't finish on 5.4-RELEASE, but is it worth trying CURRENT > and the patch posted to this thread(in other words: does my problem look like > the similar one that people are discussing in this thread)? > > Here's `dmesg | grep ^mpt' output: > mpt0: port 0x2300-0x23ff mem 0xfbfe0000-0xfbfeffff,0xfbff0000-0xfbffffff irq 22 at device 1.0 on pci1 > mpt0: MPI Version=1.2.6.0 > mpt0: Capabilities: ( RAID-1 SAFTE ) > mpt0: 1 Active Volume (1 Max) > mpt0: 2 Hidden Drive Members (3 Max) > > I found a PR with "LSI1030" in the single-line description, but it doesn't > seem to be related to my problem: kern/96040 > > Any suggestions are welcome. > Regards. > > > 5.4-RELEASE: > OK > > 5.5-STABLE: > > panic after showing the following messages: > handle_workitem_freeblocks: block count > initiate_write_filepage: already started > > 6.0-RELEASE-p12, 6.2-PRERELEASE: > panic after showing bunch of the message as follows: > g_vfs_done():da0s1g[WRITE(offset=3287388160, length=2048)]error = 5 > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Sun Sep 24 20:54:02 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E310116A403; Sun, 24 Sep 2006 20:54:02 +0000 (UTC) (envelope-from Wolfram.Fenske@Student.Uni-Magdeburg.DE) Received: from mail.uni-magdeburg.de (mail.uni-magdeburg.de [141.44.1.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F97143D45; Sun, 24 Sep 2006 20:54:01 +0000 (GMT) (envelope-from Wolfram.Fenske@Student.Uni-Magdeburg.DE) Received: from sunny.urz.uni-magdeburg.de ([141.44.8.7]) by mail.uni-magdeburg.de with esmtp (EXIM Version 4.62) id 1GRaz5-0000rj-R1; Sun, 24 Sep 2006 22:54:01 +0200 Received: from hondo. (pD9515BC5.dip0.t-ipconnect.de [217.81.91.197]) (authenticated bits=0) by sunny.urz.uni-magdeburg.de (8.12.10/8.12.10) with ESMTP id k8OKrnSX031424 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 24 Sep 2006 22:53:50 +0200 To: Bruno Damour References: <45166CB4.000004.01220@camay.yandex.ru> <4516A5F3.4080105@free.fr> From: Wolfram Fenske Mail-Followup-To: Bruno Damour , bu7cher@yandex.ru, freebsd-current@freebsd.org, freebsd-usb@freebsd.org Date: Sun, 24 Sep 2006 22:50:03 +0200 In-Reply-To: <4516A5F3.4080105@free.fr> (Bruno Damour's message of "Sun, 24 Sep 2006 17:36:19 +0200") Message-ID: <86irjdrnus.fsf@student.uni-magdeburg.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.5 (--) X-Spam-Report: ---- Start SpamAssassin results -2.5 points, 5.0 required; -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.1 AWL AWL: From: address is in the auto white-list ---- End of SpamAssassin results X-Scan-Signature: 104acc21b19de3e095c9b5614e49f903 Cc: bu7cher@yandex.ru, freebsd-usb@freebsd.org, freebsd-current@freebsd.org Subject: Re: Problems with USB on CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2006 20:54:03 -0000 Bruno Damour schreibt: > Andrey V. Elsukov wrote: >> Hi, All! >> >> I have notebook Maxselect Mission GT3000. >> A hardware configuration description (russian): >> http://www.maxselect.ru/catalog/models.html?id=4024&template=normal >> >> o Mobile AMD Sempron >> o NVIDIA C51MV+MCP51M >> o PCI Express nVidia Geforce Go 6100 >> o Realtek HDA >> >> I have several problems. One is with USB. When i attach USB Flash >> disk it's not work. >> >> usbd_new_device: addr=2, getting first desc failed >> uhub_explore: usb_new_device failed, error=IOERROR >> uhub1: device problem (IOERROR), disabling port 4 >> >> http://butcher.heavennet.ru/dmesg.txt >> http://butcher.heavennet.ru/pciconf.txt >> I've attached dmesg and pciconf. >> Any suggestions? [...] > I have the same problem, I reported it earlier but none seemed to have > any clue. > > I'm running freebsd-current and an Asus MN2PV-VM (Nforce430+GeForce > 6150 integrated chipset) I saw the same error message on -current with my USB key. With 6.1 RELEASE and older it works. The motherboard is an ASUS A8N, Nvidia nv4 chipset. Wolfram From owner-freebsd-current@FreeBSD.ORG Sun Sep 24 20:59:05 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A59BC16A403 for ; Sun, 24 Sep 2006 20:59:05 +0000 (UTC) (envelope-from brucegb@realtime.net) Received: from ruth.realtime.net (mercury.realtime.net [205.238.132.86]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3047F43D49 for ; Sun, 24 Sep 2006 20:59:05 +0000 (GMT) (envelope-from brucegb@realtime.net) Received: from tigerfish2.my.domain (cpe-70-112-156-125.austin.res.rr.com [70.112.156.125]) by realtime.net (Realtime Communications Advanced E-Mail Services V9.2) with ESMTP id 17190897-1817707 for ; Sun, 24 Sep 2006 15:59:04 -0500 Received: from tigerfish2.my.domain (localhost [127.0.0.1]) by tigerfish2.my.domain (8.13.8/8.13.8) with ESMTP id k8OKx3Fm046491 for ; Sun, 24 Sep 2006 15:59:03 -0500 (CDT) (envelope-from brucegb@tigerfish2.my.domain) Received: (from brucegb@localhost) by tigerfish2.my.domain (8.13.8/8.13.8/Submit) id k8OKx33Q046490 for freebsd-current@freebsd.org; Sun, 24 Sep 2006 15:59:03 -0500 (CDT) (envelope-from brucegb) Date: Sun, 24 Sep 2006 15:59:03 -0500 From: Bruce Burden To: freebsd-current@freebsd.org Message-ID: <20060924205903.GY1045@tigerfish2.my.domain> References: <1157154024.835.6.camel@atomizer.opensourcebeef.net> <20060924071601.GA1080@les.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060924071601.GA1080@les.ath.cx> User-Agent: Mutt/1.4.2.2i Subject: Re: LSI 1030 mpt doesn't work if I build a new kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Sep 2006 20:59:05 -0000 On Sun, Sep 24, 2006 at 04:16:01PM +0900, YONETANI Tomokazu wrote: > > Recently I tried installing FreeBSD 5.4-RELEASE on an IBM X335 in my > office and tried to upgrade to 6.2-PRERELEASE, and found that although > it doesn't hang or panic during boot, running I/O intensive applications > (including buildworld) ends up in an I/O error, and eventually panicked and > rebooted. > This would be best on -STABLE, which the 6x thread is. Anyway, I have: [root@tigerfish2 ~]# camcontrol devlist -v scbus0 on sbp0 bus 0: < > at scbus0 target -1 lun -1 () scbus1 on mpt0 bus 0: at scbus1 target 0 lun 0 (sa0,pass0) at scbus1 target 4 lun 0 (pass1,cd0) at scbus1 target 5 lun 0 (da0,pass2) < > at scbus1 target -1 lun -1 () scbus2 on mpt1 bus 0: at scbus2 target 6 lun 0 (da1,pass3) < > at scbus2 target -1 lun -1 () scbus3 on asr0 bus 0: at scbus3 target 1 lun 0 (da2,pass4) at scbus3 target 5 lun 0 (da3,pass5) at scbus3 target 6 lun 0 (ses0,pass6) < > at scbus3 target -1 lun -1 () scbus4 on asr0 bus 1: < > at scbus4 target -1 lun -1 () scbus5 on ata0 bus 0: at scbus5 target 0 lun 0 (pass7,cd1) < > at scbus5 target -1 lun -1 () scbus6 on ata1 bus 0: < > at scbus6 target -1 lun -1 () scbus-1 on xpt0 bus 0: < > mpt0@pci10:6:0: class=0x010000 card=0x289510f1 chip=0x00301000 rev=0x07 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'LSI53C1020/1030 PCI-X to Ultra320 SCSI Controller' class = mass storage subclass = SCSI mpt1@pci10:6:1: class=0x010000 card=0x289510f1 chip=0x00301000 rev=0x07 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'LSI53C1020/1030 PCI-X to Ultra320 SCSI Controller' class = mass storage subclass = SCSI FreeBSD tigerfish2.my.domain 6.1-STABLE FreeBSD 6.1-STABLE #6: Sun Aug 27 11:03:43 CDT 2006 and have not had any problems with the mpt device. The controller is built into the Tyan S2895/Thunder K8WE board. I am not using the Seagate drive - it will be used to hold the AMD64 installation when I get around to doing that, while the IBM drive will continue to hold the i386 install if I need to switch back. The RAID holds user data, and is not an issue when performing kernel builds. Have you tried to install the 6.1 release from CD/DVD? Bruce -- ------------------------------------------------------------------------ "I like bad!" Bruce Burden Austin, TX. - Thuganlitha The Power and the Prophet Robert Don Hughes From owner-freebsd-current@FreeBSD.ORG Sun Sep 24 22:04:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5F9016A407 for ; Sun, 24 Sep 2006 22:04:10 +0000 (UTC) (envelope-from neshort@yahoo.com) Received: from web56512.mail.re3.yahoo.com (web56512.mail.re3.yahoo.com [66.196.97.41]) by mx1.FreeBSD.org (Postfix) with SMTP id C2E5143D6D for ; Sun, 24 Sep 2006 22:04:08 +0000 (GMT) (envelope-from neshort@yahoo.com) Received: (qmail 41558 invoked by uid 60001); 24 Sep 2006 22:04:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=obXY/CrcVDFD+y7XhVtvUcruadHqUQ3t2cuaJXYgnBBlf0G8e2tGhOzS8eOnr3psO49xTtcbQROzYBifblVtQXACNG7kBZJukQbbazjMz/VKx9i1NHKxN8sg9wynfb3oOTZ1GCwn5ByJrNqkeu/vGUDr/4ZbBGZrou65Dc7bL6Y= ; Message-ID: <20060924220408.41556.qmail@web56512.mail.re3.yahoo.com> Received: from [216.142.36.2] by web56512.mail.re3.yahoo.com via HTTP; Sun, 24 Sep 2006 15:04:08 PDT Date: Sun, 24 Sep 2006 15:04:08 -0700 (PDT) From: Neil Short To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sun, 24 Sep 2006 22:22:28 +0000 Subject: RE: Problems with USB on CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2006 22:04:11 -0000 Just to add to this statistic - I have the same problem on two of my desktop computers. Each has a recent NVidia mobo. One is a Gateway brand (E-Machine) and the other was hand-built by me. Each runs current and each has bizarre problems with usb stuff (Scanner, umass devices, printer) although the wireless usb keyboard/mouse works fine on both. ====== Now I, Nebuchadnezzar, praise and extol and honor the King of heaven, for all his works are truth, and his ways are justice; and he is able to bring low those who walk in pride. Daniel 4:37 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-current@FreeBSD.ORG Sun Sep 24 22:34:20 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D217316A416; Sun, 24 Sep 2006 22:34:20 +0000 (UTC) (envelope-from mbsd@pacbell.net) Received: from ylpvm12.prodigy.net (ylpvm12-ext.prodigy.net [207.115.57.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3780443DA9; Sun, 24 Sep 2006 22:34:15 +0000 (GMT) (envelope-from mbsd@pacbell.net) X-ORBL: [71.139.16.119] Received: from antec (ppp-71-139-16-119.dsl.snfc21.pacbell.net [71.139.16.119]) by ylpvm12.prodigy.net (8.13.7 out spool5000 dk/8.13.7) with ESMTP id k8OMXNtb003002; Sun, 24 Sep 2006 18:33:23 -0400 Date: Sun, 24 Sep 2006 15:34:13 -0700 (PDT) From: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= X-X-Sender: mikko@antec.home To: scottl@freebsd.org Message-ID: <20060924151759.D788@antec.home> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: i386/busmda_machdep.c 1.81 broke if_bfe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 24 Sep 2006 22:34:20 -0000 Hi, It seems to me that with version 1.81 of i386/busdma_machdep.c devices that need bounce buffers, but do not use a filter function, will no longer work. The run_filter() function contains the logic to detect if a bounce buffer is needed also when there is no filter function, so I believe it has to be called for devices that are marked as BUS_DMA_COULD_BOUNCE as well as for those that provide a filter function. For example, this makes my bfe0 interface work again: Index: busdma_machdep.c =================================================================== RCS file: /net/cvs/home/ncvs/src/sys/i386/i386/busdma_machdep.c,v retrieving revision 1.83 diff -u -b -r1.83 busdma_machdep.c --- busdma_machdep.c 24 Sep 2006 19:24:26 -0000 1.83 +++ busdma_machdep.c 24 Sep 2006 21:45:39 -0000 @@ -286,7 +286,7 @@ if (newtag->lowaddr < ptoa((vm_paddr_t)Maxmem) || newtag->alignment > 1) - newtag->flags |= BUS_DMA_COULD_BOUNCE; + newtag->flags |= BUS_DMA_COULD_BOUNCE | BUS_DMA_USE_FILTER; if (((newtag->flags & BUS_DMA_COULD_BOUNCE) != 0) && (flags & BUS_DMA_ALLOCNOW) != 0) { $.02, /Mikko From owner-freebsd-current@FreeBSD.ORG Sun Sep 24 23:49:16 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3A0516A403; Sun, 24 Sep 2006 23:49:15 +0000 (UTC) (envelope-from vkushnir@i.kiev.ua) Received: from horse.iptelecom.net.ua (horse.iptelecom.net.ua [212.9.224.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C1D143D70; Sun, 24 Sep 2006 23:49:10 +0000 (GMT) (envelope-from vkushnir@i.kiev.ua) Received: from h54.246.159.dialup.iptcom.net ([213.159.246.54]:39141 "EHLO kushnir1.kiev.ua" ident: "SOCKFAULT1" whoson: "vkushnir") by horse.iptelecom.net.ua with ESMTP id S1221822AbWIXXtJ (ORCPT + 1 other); Mon, 25 Sep 2006 02:49:09 +0300 Received: from kushnir1.kiev.ua (kushnir1.kiev.ua [10.0.0.1]) by kushnir1.kiev.ua (8.13.8/8.13.8) with ESMTP id k8ONn2W3002829; Mon, 25 Sep 2006 02:49:02 +0300 (EEST) (envelope-from vkushnir@i.kiev.ua) Date: Mon, 25 Sep 2006 02:49:02 +0300 (EEST) From: Vladimir Kushnir X-X-Sender: vkushnir@kushnir1.kiev.ua To: "Andrey V. Elsukov" In-Reply-To: <45166CB4.000004.01220@camay.yandex.ru> Message-ID: <20060925014415.S1442@kushnir1.kiev.ua> References: <45166CB4.000004.01220@camay.yandex.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, freebsd-usb@freebsd.org Subject: Re: Problems with USB on CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Sep 2006 23:49:16 -0000 Hi, All! On Sun, 24 Sep 2006, Andrey V. Elsukov wrote: > Hi, All! > > I have notebook Maxselect Mission GT3000. > A hardware configuration description (russian): > http://www.maxselect.ru/catalog/models.html?id=4024&template=normal > > o Mobile AMD Sempron > o NVIDIA C51MV+MCP51M > o PCI Express nVidia Geforce Go 6100 > o Realtek HDA > > I have several problems. One is with USB. > When i attach USB Flash disk it's not work. > > usbd_new_device: addr=2, getting first desc failed > uhub_explore: usb_new_device failed, error=IOERROR > uhub1: device problem (IOERROR), disabling port 4 > > http://butcher.heavennet.ru/dmesg.txt > http://butcher.heavennet.ru/pciconf.txt > I've attached dmesg and pciconf. > Any suggestions? > -- > WBR, Andrey V. Elsukov > I had precisely the same problem with USB-2 flash (both old USB-1.1 flash and digital camera - Kodak C340, uses ugen) work perfectly all right. MB: Asus A8N (nForce4 based). The problem went away with retrying to get device descriptor in usbd_new_device (see patch below). I've submitted PR (usb/103167) but so far there's been no reaction at all :-( Hope this helps, Vladimir /* ----------- patch begins here -------------- */ *** dev/usb/usb_subr.c.orig Mon Sep 11 19:28:35 2006 --- dev/usb/usb_subr.c Mon Sep 11 20:05:38 2006 *************** *** 1112,1118 **** dd = &dev->ddesc; /* Get the first 8 bytes of the device descriptor. */ ! err = usbd_get_desc(dev, UDESC_DEVICE, 0, USB_MAX_IPACKET, dd); if (err) { DPRINTFN(-1, ("usbd_new_device: addr=%d, getting first desc " "failed\n", addr)); --- 1112,1123 ---- dd = &dev->ddesc; /* Get the first 8 bytes of the device descriptor. */ ! for (i = 0; i < 3; i++) { ! err = usbd_get_desc(dev, UDESC_DEVICE, 0, USB_MAX_IPACKET, dd); ! if (!err) ! break; ! usbd_delay_ms(dev, USB_SET_ADDRESS_SETTLE); ! } if (err) { DPRINTFN(-1, ("usbd_new_device: addr=%d, getting first desc " "failed\n", addr)); /* -------------- end ----------------- */ From owner-freebsd-current@FreeBSD.ORG Mon Sep 25 01:14:58 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6C8E16A4B3 for ; Mon, 25 Sep 2006 01:14:58 +0000 (UTC) (envelope-from alex.kovalenko@verizon.net) Received: from vms046pub.verizon.net (vms046pub.verizon.net [206.46.252.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7036843D6A for ; Mon, 25 Sep 2006 01:14:52 +0000 (GMT) (envelope-from alex.kovalenko@verizon.net) Received: from RabbitsDen ([70.21.206.89]) by vms046.mailsrvcs.net (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPA id <0J640016EJGQQLE7@vms046.mailsrvcs.net> for current@freebsd.org; Sun, 24 Sep 2006 20:14:51 -0500 (CDT) Date: Sun, 24 Sep 2006 21:14:48 -0400 From: "Alexandre \"Sunny\" Kovalenko" To: current@freebsd.org Message-id: <1159146888.92313.6.camel@RabbitsDen.RabbitsLawn.verizon.net> MIME-version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Content-type: multipart/mixed; boundary="Boundary_(ID_SSwUc7p4vsN0N10isZrd2w)" Cc: Subject: Intel 945GM and /dev/agpgart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Sep 2006 01:14:58 -0000 --Boundary_(ID_SSwUc7p4vsN0N10isZrd2w) Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: 8BIT Attached patch is the 7.0-CURRENT (September 23) adaptation of http://marcus.grupos.com.br:8080/patch/agp_i810.c.patch which gives me /dev/agpgart and allows me to use Xv extension on my ThinkPad X60. Still no direct rendering, though. Posting here just in case someone running -CURRENT on that chipset wants to watch full screen movies ;) -- Alexandre "Sunny" Kovalenko (п·п╩п╣п╨я│п╟п╫п╢я─ п п╬п╡п╟п╩п╣п╫п╨п╬) --Boundary_(ID_SSwUc7p4vsN0N10isZrd2w) Content-type: text/x-patch; name=agp_i810.c.patch; charset=UTF-8 Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=agp_i810.c.patch --- /usr/src/sys/pci/agp_i810.c.ORIG Sun Sep 24 17:00:54 2006 +++ /usr/src/sys/pci/agp_i810.c Sun Sep 24 19:47:09 2006 @@ -121,14 +121,14 @@ "Intel 82915G (915G GMCH) SVGA controller"}, {0x25928086, CHIP_I915, 0x00020000, "Intel 82915GM (915GM GMCH) SVGA controller"}, + {0x27A28086, CHIP_I915, 0x00020000, + "Intel 82945GM (945GM GMCH) SVGA controller"}, /* XXX: I believe these chipsets should work, but they haven't been * tested yet. */ /* {0x27728086, CHIP_I915, 0x00020000, "Intel 82945G (945G GMCH) SVGA controller"}, - {0x27A28086, CHIP_I915, 0x00020000, - "Intel 82945GM (945GM GMCH) SVGA controller"}, */ {0, 0, 0, NULL} }; @@ -510,9 +510,8 @@ case CHIP_I855: return 128 * 1024 * 1024; case CHIP_I915: - temp = pci_read_config(dev, AGP_I915_MSAC, 1); - if ((temp & AGP_I915_MSAC_GMASIZE) == - AGP_I915_MSAC_GMASIZE_128) { + temp = pci_read_config(dev, AGP_I915_GMADR, 1); + if (temp & 1<<27) { return 128 * 1024 * 1024; } else { return 256 * 1024 * 1024; --Boundary_(ID_SSwUc7p4vsN0N10isZrd2w)-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 25 01:26:15 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from [IPv6:::1] (hub.freebsd.org [216.136.204.18]) by hub.freebsd.org (Postfix) with ESMTP id 9D34616A403; Mon, 25 Sep 2006 01:26:14 +0000 (UTC) (envelope-from mnag@FreeBSD.org) Message-ID: <45173035.30207@FreeBSD.org> Date: Sun, 24 Sep 2006 22:26:13 -0300 From: Marcus Alves Grando Organization: FreeBSD.org User-Agent: Thunderbird 1.5.0.7 (X11/20060919) MIME-Version: 1.0 To: "Alexandre \"Sunny\" Kovalenko" References: <1159146888.92313.6.camel@RabbitsDen.RabbitsLawn.verizon.net> In-Reply-To: <1159146888.92313.6.camel@RabbitsDen.RabbitsLawn.verizon.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: Intel 945GM and /dev/agpgart X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Sep 2006 01:26:15 -0000 Alexandre "Sunny" Kovalenko wrote: > Attached patch is the 7.0-CURRENT (September 23) adaptation of > > http://marcus.grupos.com.br:8080/patch/agp_i810.c.patch > > which gives me /dev/agpgart and allows me to use Xv extension on my > ThinkPad X60. Still no direct rendering, though. > > Posting here just in case someone running -CURRENT on that chipset wants > to watch full screen movies ;) PR related: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/103079 Regards -- Marcus Alves Grando marcus(at)corp.grupos.com.br | Grupos Internet S/A mnag(at)FreeBSD.org | FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Sep 25 03:31:19 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88B2616A40F for ; Mon, 25 Sep 2006 03:31:19 +0000 (UTC) (envelope-from qhwt+fbsd@les.ath.cx) Received: from les.ath.cx (15.61.205.61.west.global.alpha-net.ne.jp [61.205.61.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 189E343D49 for ; Mon, 25 Sep 2006 03:31:18 +0000 (GMT) (envelope-from qhwt+fbsd@les.ath.cx) Received: by les.ath.cx (Postfix, from userid 1000) id B067086618; Mon, 25 Sep 2006 12:31:17 +0900 (JST) Date: Mon, 25 Sep 2006 12:31:17 +0900 From: YONETANI Tomokazu To: freebsd-current@freebsd.org Message-ID: <20060925033117.GB1080@les.ath.cx> References: <1157154024.835.6.camel@atomizer.opensourcebeef.net> <20060924071601.GA1080@les.ath.cx> <7579f7fb0609241229v105d16fagb985655dadc2d3e8@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7579f7fb0609241229v105d16fagb985655dadc2d3e8@mail.gmail.com> User-Agent: Mutt/1.5.11 Subject: Re: LSI 1030 mpt doesn't work if I build a new kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Sep 2006 03:31:19 -0000 On Sun, Sep 24, 2006 at 12:29:03PM -0700, Matthew Jacob wrote: > I see no I/O related errors in your message that could definitely > isolate it to the 1030. Sorry, I didn't boot with -v flag. I'll try -CURRENT kernel anyway. Cheers. From owner-freebsd-current@FreeBSD.ORG Mon Sep 25 09:36:13 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D461416A47C; Mon, 25 Sep 2006 09:36:13 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mx18.yandex.ru (smtp2.yandex.ru [213.180.200.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD7FF43D78; Mon, 25 Sep 2006 09:35:55 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from ns.kirov.so-cdu.ru ([81.18.142.225]:11535 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S3376744AbWIYJfj (ORCPT + 2 others); Mon, 25 Sep 2006 13:35:39 +0400 X-Comment: RFC 2476 MSA function at smtp2.yandex.ru logged sender identity as: bu7cher Message-ID: <4517A2E8.2010002@yandex.ru> Date: Mon, 25 Sep 2006 13:35:36 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 References: <4501A921.000002.29363@mfront8.yandex.ru> In-Reply-To: <4501A921.000002.29363@mfront8.yandex.ru> Content-Type: multipart/mixed; boundary="------------030102040200060207040700" To: unlisted-recipients:; (no To-header on input) Cc: freebsd-current@freebsd.org, scottl@freebsd.org, az@freebsd.org Subject: Re: aac(4) update request X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Sep 2006 09:36:14 -0000 This is a multi-part message in MIME format. --------------030102040200060207040700 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Andrey V. Elsukov wrote: > Can you update FreeBSD aac(4) driver to a current > adaptec driver that available on the site? > As i found last driver is b9114. This driver support > IBM ServeRAID 8K, I and L adapters. > But this driver available only for FreeBSD 5.4. :( Thanks to Andrew Jemerya for pointing to new aacu(4) driver for FreeBSD 6.0. http://www.adaptec.com/en-US/downloads/unix/freebsd?productId=AAR-2820SA http://www.adaptec.com/en-US/speed/raid/aac/linux/aacraid_drv_freebsd6_v9179_tar_gz.htm I've merged some changes from this driver to RELENG_6 sources. I've created a custom FreeBSD 6.2-BETA1 ISO image with a my patch to aac(4). Now i've successfully installed FreeBSD to my new IBM x3650 with an IBM ServeRAID-8k controller. I think that this patch can be successfully applied to CURRENT sources. Patch and dmesg.boot is attached. -- WBR, Andrey V. Elsukov --------------030102040200060207040700 Content-Type: text/plain; name="aac-RELENG_6.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="aac-RELENG_6.txt" --- sys/dev/aac.orig/aac.c Mon Jan 30 00:00:00 2006 +++ sys/dev/aac/aac.c Fri Sep 22 12:51:24 2006 @@ -33,7 +33,7 @@ /* * Driver for the Adaptec 'FSA' family of PCI/SCSI RAID adapters. */ -#define AAC_DRIVER_VERSION 0x02000000 +#define AAC_DRIVER_VERSION 0x02000001 #define AAC_DRIVERNAME "aac" #include "opt_aac.h" @@ -1668,14 +1668,12 @@ sc->aac_max_sectors = 128; /* 64KB */ if (sc->flags & AAC_FLAGS_SG_64BIT) sc->aac_sg_tablesize = (AAC_FIB_DATASIZE - - sizeof(struct aac_blockwrite64) - + sizeof(struct aac_sg_table64)) - / sizeof(struct aac_sg_table64); + - sizeof(struct aac_blockwrite64)) + / sizeof(struct aac_sg_entry64); else sc->aac_sg_tablesize = (AAC_FIB_DATASIZE - - sizeof(struct aac_blockwrite) - + sizeof(struct aac_sg_table)) - / sizeof(struct aac_sg_table); + - sizeof(struct aac_blockwrite)) + / sizeof(struct aac_sg_entry); if (!aac_sync_command(sc, AAC_MONKER_GETCOMMPREF, 0, 0, 0, 0, NULL)) { options = AAC_GET_MAILBOX(sc, 1); @@ -3220,7 +3218,7 @@ mtx_lock(&sc->aac_aifq_lock); next = (sc->aac_aifq_head + 1) % AAC_AIFQ_LENGTH; if (next != sc->aac_aifq_tail) { - bcopy(aif, &sc->aac_aifq[next], sizeof(struct aac_aif_command)); + bcopy(fib, &sc->aac_aifq[next], sizeof(struct aac_fib)); sc->aac_aifq_head = next; /* On the off chance that someone is sleeping for an aif... */ @@ -3327,7 +3325,7 @@ next = (sc->aac_aifq_tail + 1) % AAC_AIFQ_LENGTH; error = copyout(&sc->aac_aifq[next], uptr, - sizeof(struct aac_aif_command)); + sizeof(struct aac_fib)); if (error) device_printf(sc->aac_dev, "aac_return_aif: copyout returned %d\n", error); --- sys/dev/aac.orig/aac_pci.c Thu Jun 22 09:01:00 2006 +++ sys/dev/aac/aac_pci.c Fri Sep 22 12:52:45 2006 @@ -126,13 +126,13 @@ {0x9005, 0x0285, 0x9005, 0x0286, AAC_HWIF_I960RX, AAC_FLAGS_NO4GB | AAC_FLAGS_256FIBS, "Adaptec SCSI RAID 2120S"}, {0x9005, 0x0285, 0x9005, 0x0290, AAC_HWIF_I960RX, AAC_FLAGS_NO4GB, - "Adaptec SATA RAID 2410SA"}, + "Adaptec SCSI RAID 2410SA"}, {0x9005, 0x0285, 0x1028, 0x0291, AAC_HWIF_I960RX, AAC_FLAGS_NO4GB, "Dell CERC SATA RAID 2"}, {0x9005, 0x0285, 0x9005, 0x0292, AAC_HWIF_I960RX, AAC_FLAGS_NO4GB, - "Adaptec SATA RAID 2810SA"}, + "Adaptec SCSI RAID 2810SA"}, {0x9005, 0x0285, 0x9005, 0x0293, AAC_HWIF_I960RX, AAC_FLAGS_NO4GB, - "Adaptec SATA RAID 21610SA"}, + "Adaptec SCSI RAID 21610SA"}, {0x9005, 0x0285, 0x103c, 0x3227, AAC_HWIF_I960RX, AAC_FLAGS_NO4GB, "HP ML110 G2 (Adaptec 2610SA)"}, {0x9005, 0x0286, 0x9005, 0x028c, AAC_HWIF_RKT, 0, @@ -161,19 +161,19 @@ {0x9005, 0x0286, 0x9005, 0x029d, AAC_HWIF_RKT, 0, "Adaptec SATA RAID 2420SA"}, {0x9005, 0x0286, 0x9005, 0x029e, AAC_HWIF_RKT, 0, - "ICP ICP9024RO SCSI RAID"}, + "ICP9024RO SATA RAID"}, {0x9005, 0x0286, 0x9005, 0x029f, AAC_HWIF_RKT, 0, - "ICP ICP9014RO SCSI RAID"}, + "ICP9014RO SATA RAID"}, {0x9005, 0x0285, 0x9005, 0x0294, AAC_HWIF_I960RX, 0, "Adaptec SATA RAID 2026ZCR"}, - {0x9005, 0x0285, 0x103c, 0x3227, AAC_HWIF_I960RX, 0, - "Adaptec SATA RAID 2610SA"}, {0x9005, 0x0285, 0x9005, 0x0296, AAC_HWIF_I960RX, 0, "Adaptec SCSI RAID 2240S"}, {0x9005, 0x0285, 0x9005, 0x0297, AAC_HWIF_I960RX, 0, "Adaptec SAS RAID 4005SAS"}, {0x9005, 0x0285, 0x1014, 0x02f2, AAC_HWIF_I960RX, 0, "IBM ServeRAID 8i"}, + {0x9005, 0x0285, 0x1014, 0x0312, AAC_HWIF_I960RX, 0, + "IBM ServeRAID 8i"}, {0x9005, 0x0285, 0x9005, 0x0298, AAC_HWIF_I960RX, 0, "Adaptec SAS RAID 4000SAS"}, {0x9005, 0x0285, 0x9005, 0x0299, AAC_HWIF_I960RX, 0, @@ -185,45 +185,53 @@ {0x9005, 0x0285, 0x9005, 0x028f, AAC_HWIF_I960RX, 0, "Adaptec SATA RAID 2025SA ZCR"}, {0x9005, 0x0285, 0x9005, 0x02a4, AAC_HWIF_I960RX, 0, - "ICP ICP9085LI SAS RAID"}, + "ICP 9085LI SAS RAID"}, {0x9005, 0x0285, 0x9005, 0x02a5, AAC_HWIF_I960RX, 0, - "ICP ICP5085BR SAS RAID"}, + "ICP 5085BR SAS RAID"}, {0x9005, 0x0286, 0x9005, 0x02a0, AAC_HWIF_RKT, 0, - "ICP ICP9047MA SATA RAID"}, + "ICP9047MA SATA RAID"}, {0x9005, 0x0286, 0x9005, 0x02a1, AAC_HWIF_RKT, 0, - "ICP ICP9087MA SATA RAID"}, + "ICP9087MA SATA RAID"}, + {0x9005, 0x0286, 0x9005, 0x02a2, AAC_HWIF_RKT, 0, + "Adaptec SAS RAID 3800SAS"}, + {0x9005, 0x0286, 0x9005, 0x02a3, AAC_HWIF_RKT, 0, + "ICP5445AU SAS RAID"}, + {0x9005, 0x0286, 0x9005, 0x02a6, AAC_HWIF_RKT, 0, + "ICP9067MA SATA RAID"}, + {0x9005, 0x0286, 0x9005, 0x02a7, AAC_HWIF_RKT, 0, + "Adaptec SAS RAID 3805SAS"}, + {0x9005, 0x0286, 0x9005, 0x02a9, AAC_HWIF_RKT, 0, + "ICP5085AU SAS RAID"}, + {0x9005, 0x0286, 0x9005, 0x02ac, AAC_HWIF_RKT, 0, + "Adaptec SAS RAID 1800SAS"}, + {0x9005, 0x0286, 0x1014, 0x9580, AAC_HWIF_RKT, 0, + "IBM ServeRAID 8k"}, + {0x9005, 0x0286, 0x1014, 0x9540, AAC_HWIF_RKT, 0, + "IBM ServeRAID 8L"}, {0, 0, 0, 0, 0, 0, 0} }; -static struct aac_ident * -aac_find_ident(device_t dev) -{ - struct aac_ident *m; - - for (m = aac_identifiers; m->vendor != 0; m++) { - if ((m->vendor == pci_get_vendor(dev)) && - (m->device == pci_get_device(dev)) && - (m->subvendor == pci_get_subvendor(dev)) && - (m->subdevice == pci_get_subdevice(dev))) - return (m); - } - - return (NULL); -} - /* * Determine whether this is one of our supported adapters. */ static int aac_pci_probe(device_t dev) { - struct aac_ident *id; + struct aac_ident *m; debug_called(1); - if ((id = aac_find_ident(dev)) != NULL) { - device_set_desc(dev, id->desc); - return(BUS_PROBE_DEFAULT); + for (m = aac_identifiers; m->vendor != 0; m++) { + if ((m->vendor == pci_get_vendor(dev)) && + (m->device == pci_get_device(dev)) && + ((m->subvendor == 0) || (m->subvendor == + pci_get_subvendor(dev))) && + ((m->subdevice == 0) || ((m->subdevice == + pci_get_subdevice(dev))))) { + + device_set_desc(dev, m->desc); + return(BUS_PROBE_SPECIFIC); + } } return(ENXIO); } @@ -235,8 +243,7 @@ aac_pci_attach(device_t dev) { struct aac_softc *sc; - struct aac_ident *id; - int error; + int i, error; u_int32_t command; debug_called(1); @@ -310,8 +317,12 @@ * Detect the hardware interface version, set up the bus interface * indirection. */ - id = aac_find_ident(dev); - sc->aac_hwif = id->hwif; + for (i = 0; aac_identifiers[i].vendor != 0; i++) { + if ((aac_identifiers[i].vendor == pci_get_vendor(dev)) && + (aac_identifiers[i].device == pci_get_device(dev)) && + (aac_identifiers[i].subvendor == pci_get_subvendor(dev)) && + (aac_identifiers[i].subdevice == pci_get_subdevice(dev))) { + sc->aac_hwif = aac_identifiers[i].hwif; switch(sc->aac_hwif) { case AAC_HWIF_I960RX: debug(2, "set hardware up for i960Rx"); @@ -331,13 +342,21 @@ break; default: sc->aac_hwif = AAC_HWIF_UNKNOWN; + break; + } + + /* Set up quirks */ + sc->flags = aac_identifiers[i].quirks; + + break; + } + } + if (sc->aac_hwif == AAC_HWIF_UNKNOWN) { device_printf(sc->aac_dev, "unknown hardware type\n"); error = ENXIO; goto out; } - /* Set up quirks */ - sc->flags = id->quirks; /* * Do bus-independent initialisation. --- sys/dev/aac.orig/aacvar.h Sun Oct 9 00:00:00 2005 +++ sys/dev/aac/aacvar.h Fri Sep 22 12:52:56 2006 @@ -356,7 +356,7 @@ /* management interface */ struct cdev *aac_dev_t; struct mtx aac_aifq_lock; - struct aac_aif_command aac_aifq[AAC_AIFQ_LENGTH]; + struct aac_fib aac_aifq[AAC_AIFQ_LENGTH]; int aac_aifq_head; int aac_aifq_tail; struct selinfo rcv_select; --------------030102040200060207040700 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.txt" Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 6.2-20060924-SNAP #0: Sat Sep 23 23:29:41 UTC 2006 root@bridge.hostel4.hvn:/usr/obj/usr/src/sys/SMP acpi_alloc_wakeup_handler: can't alloc wake memory Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 3.00GHz (3000.13-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf64 Stepping = 4 Features=0xbfebfbff Features2=0xe4bd,> AMD Features=0x20000000 AMD Features2=0x1 Cores per package: 2 Logical CPUs per core: 2 real memory = 3221008384 (3071 MB) avail memory = 3150974976 (3005 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x588-0x58b on acpi0 cpu0: on acpi0 acpi_perf0: on cpu0 acpi_throttle0: on cpu0 cpu1: on acpi0 acpi_throttle1: on cpu1 acpi_throttle1: failed to attach P_CNT device_attach: acpi_throttle1 attach returned 6 cpu2: on acpi0 acpi_throttle2: on cpu2 acpi_throttle2: failed to attach P_CNT device_attach: acpi_throttle2 attach returned 6 cpu3: on acpi0 acpi_throttle3: on cpu3 acpi_throttle3: failed to attach P_CNT device_attach: acpi_throttle3 attach returned 6 cpu4: on acpi0 acpi_throttle4: on cpu4 acpi_throttle4: failed to attach P_CNT device_attach: acpi_throttle4 attach returned 6 cpu5: on acpi0 acpi_throttle5: on cpu5 acpi_throttle5: failed to attach P_CNT device_attach: acpi_throttle5 attach returned 6 cpu6: on acpi0 acpi_throttle6: on cpu6 acpi_throttle6: failed to attach P_CNT device_attach: acpi_throttle6 attach returned 6 cpu7: on acpi0 acpi_throttle7: on cpu7 acpi_throttle7: failed to attach P_CNT device_attach: acpi_throttle7 attach returned 6 pcib0: on acpi0 pci0: on pcib0 pcib1: at device 2.0 on pci0 pci26: on pcib1 pcib2: at device 0.0 on pci26 pci27: on pcib2 pcib3: at device 0.0 on pci27 pci28: on pcib3 pcib4: at device 1.0 on pci27 pci36: on pcib4 pcib5: at device 0.3 on pci26 pci37: on pcib5 pcib6: at device 3.0 on pci0 pci4: on pcib6 aac0: port 0x5000-0x50ff mem 0xc9e00000-0xc9ffffff,0xc7fe0000-0xc7ffffff irq 17 at device 0.0 on pci4 aac0: New comm. interface enabled aac0: Adaptec Raid Controller 2.0.1-1 pcib7: at device 4.0 on pci0 pci16: on pcib7 pcib8: at device 5.0 on pci0 pci69: on pcib8 pcib9: at device 6.0 on pci0 pci7: on pcib9 pcib10: at device 7.0 on pci0 pci68: on pcib10 pci0: at device 8.0 (no driver attached) pcib11: at device 28.0 on pci0 pci2: on pcib11 pcib12: at device 0.0 on pci2 pci3: on pcib12 bce0: mem 0xce000000-0xcfffffff irq 16 at device 0.0 on pci3 bce0: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz miibus0: on bce0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bce0: Ethernet address: 00:14:5e:18:16:72 pcib13: at device 28.1 on pci0 pci5: on pcib13 pcib14: at device 0.0 on pci5 pci6: on pcib14 bce1: mem 0xca000000-0xcbffffff irq 17 at device 0.0 on pci6 bce1: ASIC ID 0x57081010; Revision (B1); PCI-X 64-bit 133MHz miibus1: on bce1 brgphy1: on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bce1: Ethernet address: 00:14:5e:18:16:74 uhci0: port 0x2200-0x221f irq 23 at device 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x2600-0x261f irq 22 at device 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x2a00-0x2a1f irq 23 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x2e00-0x2e1f irq 22 at device 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xf9000000-0xf90003ff irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib15: at device 30.0 on pci0 pci1: on pcib15 pci1: at device 6.0 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x480-0x48f at device 31.2 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcafff,0xcb000-0xcc7ff,0xcc800-0xcdfff,0xce000-0xd2fff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ukbd0: CHICONY HP Basic USB Keyboard, rev 1.10/3.00, addr 2, iclass 3/1 kbd2 at ukbd0 ukbd1: vendor 0x10d5 UKU-M02 1.7, rev 1.10/0.00, addr 2, iclass 3/1 kbd3 at ukbd1 ums0: vendor 0x10d5 UKU-M02 1.7, rev 1.10/0.00, addr 2, iclass 3/1 ums0: 5 buttons and Z dir. Timecounters tick every 1.000 msec acd0: CDRW at ata1-master UDMA33 aacd0: on aac0 aacd0: 69890MB (143134720 sectors) aacd1: on aac0 aacd1: 139788MB (286285824 sectors) SMP: AP CPU #2 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #5 Launched! Trying to mount root from ufs:/dev/aacd0s1a --------------030102040200060207040700-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 25 09:57:57 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3C75C16A407; Mon, 25 Sep 2006 09:57:57 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FE1843D88; Mon, 25 Sep 2006 09:57:45 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (3t55est8alq91ii9@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k8P9vjEQ087117; Mon, 25 Sep 2006 02:57:45 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k8P9vjVV087116; Mon, 25 Sep 2006 02:57:45 -0700 (PDT) (envelope-from jmg) Date: Mon, 25 Sep 2006 02:57:45 -0700 From: John-Mark Gurney To: current@FreeBSD.org, net@FreeBSD.org Message-ID: <20060925095745.GA80527@funkthat.com> Mail-Followup-To: current@FreeBSD.org, net@FreeBSD.org, Andre Oppermann , mohans@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: Andre Oppermann , mohans@FreeBSD.org Subject: odd TCP rtt/retransmit timeout issue... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2006 09:57:57 -0000 I was brining up another interface that I just added to /etc/rc.conf and ran the command /etc/rc.d/netif start to initalize it... But then my connection never came back.... I found that the shell was still active as I could type commands like sleep 5, and another session's w would see sleep 5 run on the session... even filling up the send-q w/ 32k of data didn't get the HEAD box to send any data to the client... With the help of silby, I managed to find that the t_rxtcur value in the tcpcb was getting a very large value. The session that hung had a retransmit timeout of 19 days... This led us to find that the TCPT_RANGESET macro was letting very large tvmin values override the more sane tvmax values due to an extra else. I have added that so we shouldn't see any more multi day timeouts, but we still apparently have a problem where the rtt value calculated is wildly incorrect... It appears that each connection will get a different "random" rtt values... From a few connections to my machine: (kgdb) print ((struct tcpcb *)0xc3a34af8)->t_rxtcur $3 = 64000 (kgdb) print ((struct tcpcb *)0xc3a3457c)->t_rxtcur $6 = 1662654093 (kgdb) print ((struct tcpcb *)0xc3a343a8)->t_rxtcur $12 = 1358 (kgdb) print ((struct tcpcb *)0xc3a9e1d4)->t_rxtcur $17 = 203 (kgdb) print ((struct tcpcb *)0xc3a9e000)->t_rxtcur $19 = 284155863 most connections are stable around the "picked" value, though I have seen some connections oscillate between 64000 and a really large value.. I was trying to track this down, and a kernel as of 9/17 exhibits the problem, but I managed to track it down to a RELENG_6 commit (which obviously would effect HEAD) when I realized that each connection got a different value, and my older tests I was getting lucky in not having a bad timeout... To obtain these values, I used kgdb kernel /dev/mem, and put the value returned by netstat -Aanfinet's first column in as the tcpcb pointer above.. (Why is the columned named Socket, when it's the control block struct and not the socket struct?) Anyone want to track down why we are getting such large values in there? I'll try to back track farther to see how old this issue is.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Mon Sep 25 10:58:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FADE16A403 for ; Mon, 25 Sep 2006 10:58:52 +0000 (UTC) (envelope-from qhwt+fbsd@les.ath.cx) Received: from les.ath.cx (15.61.205.61.west.global.alpha-net.ne.jp [61.205.61.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41F9243D86 for ; Mon, 25 Sep 2006 10:58:44 +0000 (GMT) (envelope-from qhwt+fbsd@les.ath.cx) Received: by les.ath.cx (Postfix, from userid 1000) id 73D2A86618; Mon, 25 Sep 2006 19:58:43 +0900 (JST) Date: Mon, 25 Sep 2006 19:58:43 +0900 From: YONETANI Tomokazu To: freebsd-current@freebsd.org Message-ID: <20060925105843.GC1080@les.ath.cx> References: <1157154024.835.6.camel@atomizer.opensourcebeef.net> <20060924071601.GA1080@les.ath.cx> <7579f7fb0609241229v105d16fagb985655dadc2d3e8@mail.gmail.com> <20060925033117.GB1080@les.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060925033117.GB1080@les.ath.cx> User-Agent: Mutt/1.5.11 Subject: Re: LSI 1030 mpt doesn't work if I build a new kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Sep 2006 10:58:52 -0000 On Mon, Sep 25, 2006 at 12:31:17PM +0900, YONETANI Tomokazu wrote: > On Sun, Sep 24, 2006 at 12:29:03PM -0700, Matthew Jacob wrote: > > I see no I/O related errors in your message that could definitely > > isolate it to the 1030. > > Sorry, I didn't boot with -v flag. I'll try -CURRENT kernel anyway. Since I couldn't find the recent snapshot on ftp.freebsd.org, I decided to try 5-STABLE kernel with mpt driver from 5.5-RELEASE first, and that didn't have the problem (5-STABLE already has MFC'ed mpt driver, and it has the I/O error problem). I did find a snapshot from September 5th, and it still has the same problem. So I'm sure it's something in the new driver, but at the moment I don't have a clue on how to investigate any further. FWIW, I tried to collect some information and put them here: http://les.ath.cx/FreeBSD/mpt/ I'll try to get some more debugging information the newer mpt driver later. Best regards. From owner-freebsd-current@FreeBSD.ORG Mon Sep 25 11:10:49 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1BB416A47E for ; Mon, 25 Sep 2006 11:10:49 +0000 (UTC) (envelope-from qhwt+fbsd@les.ath.cx) Received: from les.ath.cx (15.61.205.61.west.global.alpha-net.ne.jp [61.205.61.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76C5743D55 for ; Mon, 25 Sep 2006 11:10:49 +0000 (GMT) (envelope-from qhwt+fbsd@les.ath.cx) Received: by les.ath.cx (Postfix, from userid 1000) id 7478B86618; Mon, 25 Sep 2006 20:10:48 +0900 (JST) Date: Mon, 25 Sep 2006 20:10:48 +0900 From: YONETANI Tomokazu To: freebsd-current@freebsd.org Message-ID: <20060925111048.GD1080@les.ath.cx> References: <1157154024.835.6.camel@atomizer.opensourcebeef.net> <20060924071601.GA1080@les.ath.cx> <20060924205903.GY1045@tigerfish2.my.domain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060924205903.GY1045@tigerfish2.my.domain> User-Agent: Mutt/1.5.11 Subject: Re: LSI 1030 mpt doesn't work if I build a new kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Sep 2006 11:10:49 -0000 On Sun, Sep 24, 2006 at 03:59:03PM -0500, Bruce Burden wrote: > On Sun, Sep 24, 2006 at 04:16:01PM +0900, YONETANI Tomokazu wrote: > > > > Recently I tried installing FreeBSD 5.4-RELEASE on an IBM X335 in my > > office and tried to upgrade to 6.2-PRERELEASE, and found that although > > it doesn't hang or panic during boot, running I/O intensive applications > > (including buildworld) ends up in an I/O error, and eventually panicked and > > rebooted. > > > This would be best on -STABLE, which the 6x thread is. Anyway, But I found that the snapshot from September 5 still has the similar issue, so I'd imagine that the driver in -CURRENT still has the problem, though I'm speaking without knowing how much changes have been made since the last MFC. I need to set up a machine which can build current -CURRENT to be sure. > I have: [snip] > FreeBSD tigerfish2.my.domain 6.1-STABLE FreeBSD 6.1-STABLE #6: Sun Aug 27 11:03:43 CDT 2006 Thanks for the suggestion, I put mine at http://les.ath.cx/FreeBSD/mpt/ > and have not had any problems with the mpt device. The controller is > built into the Tyan S2895/Thunder K8WE board. > > I am not using the Seagate drive - it will be used to hold the > AMD64 installation when I get around to doing that, while the IBM > drive will continue to hold the i386 install if I need to switch > back. The RAID holds user data, and is not an issue when performing > kernel builds. > > Have you tried to install the 6.1 release from CD/DVD? Not yet, but I doubt it'll make it through to the end because of the I/O error issue. Cheers. From owner-freebsd-current@FreeBSD.ORG Mon Sep 25 15:47:05 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8581516A416; Mon, 25 Sep 2006 15:47:05 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C01843D7D; Mon, 25 Sep 2006 15:47:00 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.6/8.13.6) id k8PFkxMn093354; Mon, 25 Sep 2006 10:46:59 -0500 (CDT) (envelope-from dan) Date: Mon, 25 Sep 2006 10:46:59 -0500 From: Dan Nelson To: current@FreeBSD.org, net@FreeBSD.org, Andre Oppermann , mohans@FreeBSD.org Message-ID: <20060925154659.GE73717@dan.emsphone.com> References: <20060925095745.GA80527@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060925095745.GA80527@funkthat.com> X-OS: FreeBSD 6.1-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.13 (2006-08-11) Cc: Subject: Re: odd TCP rtt/retransmit timeout issue... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2006 15:47:05 -0000 In the last episode (Sep 25), John-Mark Gurney said: > I was brining up another interface that I just added to /etc/rc.conf > and ran the command /etc/rc.d/netif start to initalize it... But > then my connection never came back.... I found that the shell was > still active as I could type commands like sleep 5, and another > session's w would see sleep 5 run on the session... even filling up > the send-q w/ 32k of data didn't get the HEAD box to send any data to > the client... > > With the help of silby, I managed to find that the t_rxtcur value in > the tcpcb was getting a very large value. The session that hung had > a retransmit timeout of 19 days... This led us to find that the > TCPT_RANGESET macro was letting very large tvmin values override the > more sane tvmax values due to an extra else. I have added that so we > shouldn't see any more multi day timeouts, but we still apparently > have a problem where the rtt value calculated is wildly incorrect... > > It appears that each connection will get a different "random" rtt > values... From a few connections to my machine: > (kgdb) print ((struct tcpcb *)0xc3a34af8)->t_rxtcur > $3 = 64000 > (kgdb) print ((struct tcpcb *)0xc3a3457c)->t_rxtcur > $6 = 1662654093 > (kgdb) print ((struct tcpcb *)0xc3a343a8)->t_rxtcur > $12 = 1358 > (kgdb) print ((struct tcpcb *)0xc3a9e1d4)->t_rxtcur > $17 = 203 > (kgdb) print ((struct tcpcb *)0xc3a9e000)->t_rxtcur > $19 = 284155863 Do you have net.inet.tcp.inflight.enable=1 ? You might be hitting something related to kern/75122. You'll want to pull the raw gnats repository file to read it; the query-pr.cgi web interface doesn't parse the file right and it loses all the replies. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-current@FreeBSD.ORG Mon Sep 25 15:57:06 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACA2416A412; Mon, 25 Sep 2006 15:57:06 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A00543D5C; Mon, 25 Sep 2006 15:57:04 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (r3g7vgsxq9i7sknu@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k8PFuw6g094553; Mon, 25 Sep 2006 08:56:59 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k8PFuw1h094552; Mon, 25 Sep 2006 08:56:58 -0700 (PDT) (envelope-from jmg) Date: Mon, 25 Sep 2006 08:56:58 -0700 From: John-Mark Gurney To: Dan Nelson Message-ID: <20060925155658.GB80527@funkthat.com> Mail-Followup-To: Dan Nelson , current@FreeBSD.org, net@FreeBSD.org, Andre Oppermann , mohans@FreeBSD.org References: <20060925095745.GA80527@funkthat.com> <20060925154659.GE73717@dan.emsphone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060925154659.GE73717@dan.emsphone.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: mohans@FreeBSD.org, Andre Oppermann , current@FreeBSD.org, net@FreeBSD.org Subject: Re: odd TCP rtt/retransmit timeout issue... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2006 15:57:06 -0000 Dan Nelson wrote this message on Mon, Sep 25, 2006 at 10:46 -0500: > In the last episode (Sep 25), John-Mark Gurney said: > > I was brining up another interface that I just added to /etc/rc.conf > > and ran the command /etc/rc.d/netif start to initalize it... But > > then my connection never came back.... I found that the shell was > > still active as I could type commands like sleep 5, and another > > session's w would see sleep 5 run on the session... even filling up > > the send-q w/ 32k of data didn't get the HEAD box to send any data to > > the client... > > > > With the help of silby, I managed to find that the t_rxtcur value in > > the tcpcb was getting a very large value. The session that hung had > > a retransmit timeout of 19 days... This led us to find that the > > TCPT_RANGESET macro was letting very large tvmin values override the > > more sane tvmax values due to an extra else. I have added that so we > > shouldn't see any more multi day timeouts, but we still apparently > > have a problem where the rtt value calculated is wildly incorrect... > > > > It appears that each connection will get a different "random" rtt > > values... From a few connections to my machine: > > (kgdb) print ((struct tcpcb *)0xc3a34af8)->t_rxtcur > > $3 = 64000 > > (kgdb) print ((struct tcpcb *)0xc3a3457c)->t_rxtcur > > $6 = 1662654093 > > (kgdb) print ((struct tcpcb *)0xc3a343a8)->t_rxtcur > > $12 = 1358 > > (kgdb) print ((struct tcpcb *)0xc3a9e1d4)->t_rxtcur > > $17 = 203 > > (kgdb) print ((struct tcpcb *)0xc3a9e000)->t_rxtcur > > $19 = 284155863 > > Do you have net.inet.tcp.inflight.enable=1 ? You might be hitting Yes. > something related to kern/75122. You'll want to pull the raw gnats > repository file to read it; the query-pr.cgi web interface doesn't > parse the file right and it loses all the replies. Doesn't look like it... I just disabled inflight, and my first connection got: (kgdb) print ((struct tcpcb *)0xc3a4857c)->t_rxtcur $1 = 921479340 -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Mon Sep 25 17:42:48 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C640316A47E for ; Mon, 25 Sep 2006 17:42:48 +0000 (UTC) (envelope-from nullpt@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE91F43D64 for ; Mon, 25 Sep 2006 17:42:44 +0000 (GMT) (envelope-from nullpt@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so460298uge for ; Mon, 25 Sep 2006 10:42:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=VMz24kTIOf+UrNizoZc0r7taTPZLuvAYhmQXQewOaMovk9+7kqfKJRgjJEoCTwENz7gkrwQWdOdMWHDQCV6goL7JI5EdVXAnj+AmIkGJ7G3AqM+lmPxfwwFvC84VPTjm90N++wvgtQfuhiiGSRO8XJarR8bHPNL25q2IC6dMiZM= Received: by 10.67.100.17 with SMTP id c17mr3601504ugm; Mon, 25 Sep 2006 10:42:43 -0700 (PDT) Received: by 10.66.237.20 with HTTP; Mon, 25 Sep 2006 10:42:43 -0700 (PDT) Message-ID: <755cb9fc0609251042h163ff7f1l4e96369ed7bd0106@mail.gmail.com> Date: Mon, 25 Sep 2006 18:42:43 +0100 From: "Alexandre Vieira" To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_44229_20100486.1159206163566" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Acer Aspire 1644WLMi -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2006 17:42:48 -0000 ------=_Part_44229_20100486.1159206163566 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello folks, I just went -CURRENT for the first time and everything seems fairly equal to 6.1-STABLE. I have an Acer Aspire 1644WLMi. ACPI doesn't seem to work very well. I have many messages in dmesg complaining about acpi. I had kde working but since the upgrade it's broken. I've tried to recompile it but im having troubles compiling some ports (altough it seems application specific,, i.e pilot-link/libmal) . I did no change to my 6-stable kernel. Is there anything I have to take in consideration in -CURRENT regarding compilations? Also, does anyone know if an intel high definition audio driver exists in -CURRENT? Nothing seems to grab the sound card and I cant find a suitable module for it. I'm sorry for any eventual dumminess coming out of my fingers and thank you very much for your itme. Regards, -- Alexandre Vieira - nullpt@gmail.com ------=_Part_44229_20100486.1159206163566 Content-Type: text/plain; name=kern.txt; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: f_esj5a46i Content-Disposition: attachment; filename="kern.txt" Iw0KIyBHRU5FUklDIC0tIEdlbmVyaWMga2VybmVsIGNvbmZpZ3VyYXRpb24gZmlsZSBmb3IgRnJl ZUJTRC9pMzg2DQojDQojIEZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHRoaXMgZmlsZSwgcGxlYXNl IHJlYWQgdGhlIGhhbmRib29rIHNlY3Rpb24gb24NCiMgS2VybmVsIENvbmZpZ3VyYXRpb24gRmls ZXM6DQojDQojICAgIGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcvZG9jL2VuX1VTLklTTzg4NTktMS9i b29rcy9oYW5kYm9vay9rZXJuZWxjb25maWctY29uZmlnLmh0bWwNCiMNCiMgVGhlIGhhbmRib29r IGlzIGFsc28gYXZhaWxhYmxlIGxvY2FsbHkgaW4gL3Vzci9zaGFyZS9kb2MvaGFuZGJvb2sNCiMg aWYgeW91J3ZlIGluc3RhbGxlZCB0aGUgZG9jIGRpc3RyaWJ1dGlvbiwgb3RoZXJ3aXNlIGFsd2F5 cyBzZWUgdGhlDQojIEZyZWVCU0QgV29ybGQgV2lkZSBXZWIgc2VydmVyIChodHRwOi8vd3d3LkZy ZWVCU0Qub3JnLykgZm9yIHRoZQ0KIyBsYXRlc3QgaW5mb3JtYXRpb24uDQojDQojIEFuIGV4aGF1 c3RpdmUgbGlzdCBvZiBvcHRpb25zIGFuZCBtb3JlIGRldGFpbGVkIGV4cGxhbmF0aW9ucyBvZiB0 aGUNCiMgZGV2aWNlIGxpbmVzIGlzIGFsc28gcHJlc2VudCBpbiB0aGUgLi4vLi4vY29uZi9OT1RF UyBhbmQgTk9URVMgZmlsZXMuDQojIElmIHlvdSBhcmUgaW4gZG91YnQgYXMgdG8gdGhlIHB1cnBv c2Ugb3IgbmVjZXNzaXR5IG9mIGEgbGluZSwgY2hlY2sgZmlyc3QNCiMgaW4gTk9URVMuDQojDQoj ICRGcmVlQlNEOiBzcmMvc3lzL2kzODYvY29uZi9HRU5FUklDLHYgMS40MjkuMi4xMSAyMDA2LzA3 LzEzIDA4OjExOjQ2IGRlbHBoaWogRXhwICQNCg0KbWFjaGluZSAgICAgICAgIGkzODYNCmNwdSAg ICAgICAgICAgICBJNjg2X0NQVQ0KaWRlbnQgICAgICAgICAgIEdFTkVSSUMNCg0KIyBUbyBzdGF0 aWNhbGx5IGNvbXBpbGUgaW4gZGV2aWNlIHdpcmluZyBpbnN0ZWFkIG9mIC9ib290L2RldmljZS5o aW50cw0KI2hpbnRzICAgICAgICAgICJHRU5FUklDLmhpbnRzIiAgICAgICAgICMgRGVmYXVsdCBw bGFjZXMgdG8gbG9vayBmb3IgZGV2aWNlcy4NCg0KbWFrZW9wdGlvbnMgICAgIERFQlVHPS1nICAg ICAgICAgICAgICAgICMgQnVpbGQga2VybmVsIHdpdGggZ2RiKDEpIGRlYnVnIHN5bWJvbHMNCg0K b3B0aW9ucyAgICAgICAgIERFVklDRV9QT0xMSU5HDQpvcHRpb25zICAgICAgICAgSFo9MTAwMA0K b3B0aW9ucyAgICAgICAgIFNDSEVEX1VMRSAgICAgICAgICAgICAgICMgVUxFIHNjaGVkdWxlcg0K I29wdGlvbnMgICAgICAgIFNDSEVEXzRCU0QgICAgICAgICAgICAgICMgNEJTRCBzY2hlZHVsZXIN Cm9wdGlvbnMgICAgICAgICBQUkVFTVBUSU9OICAgICAgICAgICAgICAjIEVuYWJsZSBrZXJuZWwg dGhyZWFkIHByZWVtcHRpb24NCm9wdGlvbnMgICAgICAgICBJTkVUICAgICAgICAgICAgICAgICAg ICAjIEludGVyTkVUd29ya2luZw0Kb3B0aW9ucyAgICAgICAgIElORVQ2ICAgICAgICAgICAgICAg ICAgICMgSVB2NiBjb21tdW5pY2F0aW9ucyBwcm90b2NvbHMNCm9wdGlvbnMgICAgICAgICBGRlMg ICAgICAgICAgICAgICAgICAgICAjIEJlcmtlbGV5IEZhc3QgRmlsZXN5c3RlbQ0Kb3B0aW9ucyAg ICAgICAgIFNPRlRVUERBVEVTICAgICAgICAgICAgICMgRW5hYmxlIEZGUyBzb2Z0IHVwZGF0ZXMg c3VwcG9ydA0Kb3B0aW9ucyAgICAgICAgIFVGU19BQ0wgICAgICAgICAgICAgICAgICMgU3VwcG9y dCBmb3IgYWNjZXNzIGNvbnRyb2wgbGlzdHMNCm9wdGlvbnMgICAgICAgICBVRlNfRElSSEFTSCAg ICAgICAgICAgICAjIEltcHJvdmUgcGVyZm9ybWFuY2Ugb24gYmlnIGRpcmVjdG9yaWVzDQpvcHRp b25zICAgICAgICAgTURfUk9PVCAgICAgICAgICAgICAgICAgIyBNRCBpcyBhIHBvdGVudGlhbCBy b290IGRldmljZQ0Kb3B0aW9ucyAgICAgICAgIE5GU0NMSUVOVCAgICAgICAgICAgICAgICMgTmV0 d29yayBGaWxlc3lzdGVtIENsaWVudA0Kb3B0aW9ucyAgICAgICAgIE5GU1NFUlZFUiAgICAgICAg ICAgICAgICMgTmV0d29yayBGaWxlc3lzdGVtIFNlcnZlcg0Kb3B0aW9ucyAgICAgICAgIE5GU19S T09UICAgICAgICAgICAgICAgICMgTkZTIHVzYWJsZSBhcyAvLCByZXF1aXJlcyBORlNDTElFTlQN Cm9wdGlvbnMgICAgICAgICBNU0RPU0ZTICAgICAgICAgICAgICAgICAjIE1TRE9TIEZpbGVzeXN0 ZW0NCm9wdGlvbnMgICAgICAgICBDRDk2NjAgICAgICAgICAgICAgICAgICAjIElTTyA5NjYwIEZp bGVzeXN0ZW0NCm9wdGlvbnMgICAgICAgICBQUk9DRlMgICAgICAgICAgICAgICAgICAjIFByb2Nl c3MgZmlsZXN5c3RlbSAocmVxdWlyZXMgUFNFVURPRlMpDQpvcHRpb25zICAgICAgICAgUFNFVURP RlMgICAgICAgICAgICAgICAgIyBQc2V1ZG8tZmlsZXN5c3RlbSBmcmFtZXdvcmsNCm9wdGlvbnMg ICAgICAgICBHRU9NX0dQVCAgICAgICAgICAgICAgICAjIEdVSUQgUGFydGl0aW9uIFRhYmxlcy4N Cm9wdGlvbnMgICAgICAgICBDT01QQVRfNDMgICAgICAgICAgICAgICAjIENvbXBhdGlibGUgd2l0 aCBCU0QgNC4zIFtLRUVQIFRISVMhXQ0Kb3B0aW9ucyAgICAgICAgIENPTVBBVF9GUkVFQlNENCAg ICAgICAgICMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q0DQpvcHRpb25zICAgICAgICAgQ09NUEFU X0ZSRUVCU0Q1ICAgICAgICAgIyBDb21wYXRpYmxlIHdpdGggRnJlZUJTRDUNCm9wdGlvbnMgICAg ICAgICBTQ1NJX0RFTEFZPTUwMDAgICAgICAgICAjIERlbGF5IChpbiBtcykgYmVmb3JlIHByb2Jp bmcgU0NTSQ0Kb3B0aW9ucyAgICAgICAgIEtUUkFDRSAgICAgICAgICAgICAgICAgICMga3RyYWNl KDEpIHN1cHBvcnQNCm9wdGlvbnMgICAgICAgICBTWVNWU0hNICAgICAgICAgICAgICAgICAjIFNZ U1Ytc3R5bGUgc2hhcmVkIG1lbW9yeQ0Kb3B0aW9ucyAgICAgICAgIFNZU1ZNU0cgICAgICAgICAg ICAgICAgICMgU1lTVi1zdHlsZSBtZXNzYWdlIHF1ZXVlcw0Kb3B0aW9ucyAgICAgICAgIFNZU1ZT RU0gICAgICAgICAgICAgICAgICMgU1lTVi1zdHlsZSBzZW1hcGhvcmVzDQpvcHRpb25zICAgICAg ICAgX0tQT1NJWF9QUklPUklUWV9TQ0hFRFVMSU5HICMgUE9TSVggUDEwMDNfMUIgcmVhbC10aW1l IGV4dGVuc2lvbnMNCm9wdGlvbnMgICAgICAgICBLQkRfSU5TVEFMTF9DREVWICAgICAgICAjIGlu c3RhbGwgYSBDREVWIGVudHJ5IGluIC9kZXYNCm9wdGlvbnMgICAgICAgICBBREFQVElWRV9HSUFO VCAgICAgICAgICAjIEdpYW50IG11dGV4IGlzIGFkYXB0aXZlLg0KZGV2aWNlICAgICAgICAgIGFw aWMgICAgICAgICAgICAgICAgICAgICMgSS9PIEFQSUMNCg0KIyBCdXMgc3VwcG9ydC4NCmRldmlj ZSAgICAgICAgICBlaXNhDQpkZXZpY2UgICAgICAgICAgcGNpDQoNCiMgRmxvcHB5IGRyaXZlcw0K I2RldmljZSAgICAgICAgIGZkYw0KDQojIEFUQSBhbmQgQVRBUEkgZGV2aWNlcw0KZGV2aWNlICAg ICAgICAgIGF0YQ0KZGV2aWNlICAgICAgICAgIGF0YWRpc2sgICAgICAgICAjIEFUQSBkaXNrIGRy aXZlcw0KZGV2aWNlICAgICAgICAgIGF0YXJhaWQgICAgICAgICAjIEFUQSBSQUlEIGRyaXZlcw0K ZGV2aWNlICAgICAgICAgIGF0YXBpY2QgICAgICAgICAjIEFUQVBJIENEUk9NIGRyaXZlcw0KZGV2 aWNlICAgICAgICAgIGF0YXBpZmQgICAgICAgICAjIEFUQVBJIGZsb3BweSBkcml2ZXMNCmRldmlj ZSAgICAgICAgICBhdGFwaXN0ICAgICAgICAgIyBBVEFQSSB0YXBlIGRyaXZlcw0Kb3B0aW9ucyAg ICAgICAgIEFUQV9TVEFUSUNfSUQgICAjIFN0YXRpYyBkZXZpY2UgbnVtYmVyaW5nDQoNCiMgU0NT SSBDb250cm9sbGVycw0KZGV2aWNlICAgICAgICAgIGFoYiAgICAgICAgICAgICAjIEVJU0EgQUhB MTc0MiBmYW1pbHkNCmRldmljZSAgICAgICAgICBhaGMgICAgICAgICAgICAgIyBBSEEyOTQwIGFu ZCBvbmJvYXJkIEFJQzd4eHggZGV2aWNlcw0Kb3B0aW9ucyAgICAgICAgIEFIQ19SRUdfUFJFVFRZ X1BSSU5UICAgICMgUHJpbnQgcmVnaXN0ZXIgYml0ZmllbGRzIGluIGRlYnVnDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIyBvdXRwdXQuICBBZGRzIH4xMjhrIHRvIGRy aXZlci4NCmRldmljZSAgICAgICAgICBhaGQgICAgICAgICAgICAgIyBBSEEzOTMyMC8yOTMyMCBh bmQgb25ib2FyZCBBSUM3OXh4IGRldmljZXMNCm9wdGlvbnMgICAgICAgICBBSERfUkVHX1BSRVRU WV9QUklOVCAgICAjIFByaW50IHJlZ2lzdGVyIGJpdGZpZWxkcyBpbiBkZWJ1Zw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICMgb3V0cHV0LiAgQWRkcyB+MjE1ayB0byBk cml2ZXIuDQpkZXZpY2UgICAgICAgICAgYW1kICAgICAgICAgICAgICMgQU1EIDUzQzk3NCAoVGVr cmFtIERDLTM5MChUKSkNCmRldmljZSAgICAgICAgICBpc3AgICAgICAgICAgICAgIyBRbG9naWMg ZmFtaWx5DQojZGV2aWNlICAgICAgICAgaXNwZncgICAgICAgICAgICMgRmlybXdhcmUgZm9yIFFM b2dpYyBIQkFzLSBub3JtYWxseSBhIG1vZHVsZQ0KZGV2aWNlICAgICAgICAgIG1wdCAgICAgICAg ICAgICAjIExTSS1Mb2dpYyBNUFQtRnVzaW9uDQojZGV2aWNlICAgICAgICAgbmNyICAgICAgICAg ICAgICMgTkNSL1N5bWJpb3MgTG9naWMNCmRldmljZSAgICAgICAgICBzeW0gICAgICAgICAgICAg IyBOQ1IvU3ltYmlvcyBMb2dpYyAobmV3ZXIgY2hpcHNldHMgKyB0aG9zZSBvZiBgbmNyJykNCmRl dmljZSAgICAgICAgICB0cm0gICAgICAgICAgICAgIyBUZWtyYW0gREMzOTVVL1VXL0YgREMzMTVV IGFkYXB0ZXJzDQoNCmRldmljZSAgICAgICAgICBhZHYgICAgICAgICAgICAgIyBBZHZhbnN5cyBT Q1NJIGFkYXB0ZXJzDQpkZXZpY2UgICAgICAgICAgYWR3ICAgICAgICAgICAgICMgQWR2YW5zeXMg d2lkZSBTQ1NJIGFkYXB0ZXJzDQpkZXZpY2UgICAgICAgICAgYWhhICAgICAgICAgICAgICMgQWRh cHRlYyAxNTR4IFNDU0kgYWRhcHRlcnMNCmRldmljZSAgICAgICAgICBhaWMgICAgICAgICAgICAg IyBBZGFwdGVjIDE1WzAxMl14IFNDU0kgYWRhcHRlcnMsIEFJQy02WzIzXTYwLg0KZGV2aWNlICAg ICAgICAgIGJ0ICAgICAgICAgICAgICAjIEJ1c2xvZ2ljL015bGV4IE11bHRpTWFzdGVyIFNDU0kg YWRhcHRlcnMNCg0KZGV2aWNlICAgICAgICAgIG5jdiAgICAgICAgICAgICAjIE5DUiA1M0M1MDAN CmRldmljZSAgICAgICAgICBuc3AgICAgICAgICAgICAgIyBXb3JrYml0IE5pbmphIFNDU0ktMw0K ZGV2aWNlICAgICAgICAgIHN0ZyAgICAgICAgICAgICAjIFRNQyAxOEMzMC8xOEM1MA0KDQojIFND U0kgcGVyaXBoZXJhbHMNCmRldmljZSAgICAgICAgICBzY2J1cyAgICAgICAgICAgIyBTQ1NJIGJ1 cyAocmVxdWlyZWQgZm9yIFNDU0kpDQpkZXZpY2UgICAgICAgICAgY2ggICAgICAgICAgICAgICMg U0NTSSBtZWRpYSBjaGFuZ2Vycw0KZGV2aWNlICAgICAgICAgIGRhICAgICAgICAgICAgICAjIERp cmVjdCBBY2Nlc3MgKGRpc2tzKQ0KZGV2aWNlICAgICAgICAgIHNhICAgICAgICAgICAgICAjIFNl cXVlbnRpYWwgQWNjZXNzICh0YXBlIGV0YykNCmRldmljZSAgICAgICAgICBjZCAgICAgICAgICAg ICAgIyBDRA0KZGV2aWNlICAgICAgICAgIHBhc3MgICAgICAgICAgICAjIFBhc3N0aHJvdWdoIGRl dmljZSAoZGlyZWN0IFNDU0kgYWNjZXNzKQ0KZGV2aWNlICAgICAgICAgIHNlcyAgICAgICAgICAg ICAjIFNDU0kgRW52aXJvbm1lbnRhbCBTZXJ2aWNlcyAoYW5kIFNBRi1URSkNCg0KIyBSQUlEIGNv bnRyb2xsZXJzIGludGVyZmFjZWQgdG8gdGhlIFNDU0kgc3Vic3lzdGVtDQpkZXZpY2UgICAgICAg ICAgYW1yICAgICAgICAgICAgICMgQU1JIE1lZ2FSQUlEDQpkZXZpY2UgICAgICAgICAgYXJjbXNy ICAgICAgICAgICMgQXJlY2EgU0FUQSBJSSBSQUlEDQpkZXZpY2UgICAgICAgICAgYXNyICAgICAg ICAgICAgICMgRFBUIFNtYXJ0UkFJRCBWLCBWSSBhbmQgQWRhcHRlYyBTQ1NJIFJBSUQNCmRldmlj ZSAgICAgICAgICBjaXNzICAgICAgICAgICAgIyBDb21wYXEgU21hcnQgUkFJRCA1Kg0KZGV2aWNl ICAgICAgICAgIGRwdCAgICAgICAgICAgICAjIERQVCBTbWFydGNhY2hlIElJSSwgSVYgLSBTZWUg Tk9URVMgZm9yIG9wdGlvbnMNCmRldmljZSAgICAgICAgICBocHRtdiAgICAgICAgICAgIyBIaWdo cG9pbnQgUm9ja2V0UkFJRCAxODJ4DQpkZXZpY2UgICAgICAgICAgcnIyMzJ4ICAgICAgICAgICMg SGlnaHBvaW50IFJvY2tldFJBSUQgMjMyeA0KZGV2aWNlICAgICAgICAgIGlpciAgICAgICAgICAg ICAjIEludGVsIEludGVncmF0ZWQgUkFJRA0KZGV2aWNlICAgICAgICAgIGlwcyAgICAgICAgICAg ICAjIElCTSAoQWRhcHRlYykgU2VydmVSQUlEDQpkZXZpY2UgICAgICAgICAgbWx5ICAgICAgICAg ICAgICMgTXlsZXggQWNjZWxlUkFJRC9lWHRyZW1lUkFJRA0KZGV2aWNlICAgICAgICAgIHR3YSAg ICAgICAgICAgICAjIDN3YXJlIDkwMDAgc2VyaWVzIFBBVEEvU0FUQSBSQUlEDQoNCiMgUkFJRCBj b250cm9sbGVycw0KZGV2aWNlICAgICAgICAgIGFhYyAgICAgICAgICAgICAjIEFkYXB0ZWMgRlNB IFJBSUQNCmRldmljZSAgICAgICAgICBhYWNwICAgICAgICAgICAgIyBTQ1NJIHBhc3N0aHJvdWdo IGZvciBhYWMgKHJlcXVpcmVzIENBTSkNCmRldmljZSAgICAgICAgICBpZGEgICAgICAgICAgICAg IyBDb21wYXEgU21hcnQgUkFJRA0KZGV2aWNlICAgICAgICAgIG1maSAgICAgICAgICAgICAjIExT SSBNZWdhUkFJRCBTQVMNCmRldmljZSAgICAgICAgICBtbHggICAgICAgICAgICAgIyBNeWxleCBE QUM5NjAgZmFtaWx5DQpkZXZpY2UgICAgICAgICAgcHN0ICAgICAgICAgICAgICMgUHJvbWlzZSBT dXBlcnRyYWsgU1g2MDAwDQpkZXZpY2UgICAgICAgICAgdHdlICAgICAgICAgICAgICMgM3dhcmUg QVRBIFJBSUQNCg0KIyBhdGtiZGMwIGNvbnRyb2xzIGJvdGggdGhlIGtleWJvYXJkIGFuZCB0aGUg UFMvMiBtb3VzZQ0KZGV2aWNlICAgICAgICAgIGF0a2JkYyAgICAgICAgICAjIEFUIGtleWJvYXJk IGNvbnRyb2xsZXINCmRldmljZSAgICAgICAgICBhdGtiZCAgICAgICAgICAgIyBBVCBrZXlib2Fy ZA0KZGV2aWNlICAgICAgICAgIHBzbSAgICAgICAgICAgICAjIFBTLzIgbW91c2UNCg0KZGV2aWNl ICAgICAgICAgIGtiZG11eCAgICAgICAgICAjIGtleWJvYXJkIG11bHRpcGxleGVyDQoNCmRldmlj ZSAgICAgICAgICB2Z2EgICAgICAgICAgICAgIyBWR0EgdmlkZW8gY2FyZCBkcml2ZXINCg0KZGV2 aWNlICAgICAgICAgIHNwbGFzaCAgICAgICAgICAjIFNwbGFzaCBzY3JlZW4gYW5kIHNjcmVlbiBz YXZlciBzdXBwb3J0DQoNCiMgc3lzY29ucyBpcyB0aGUgZGVmYXVsdCBjb25zb2xlIGRyaXZlciwg cmVzZW1ibGluZyBhbiBTQ08gY29uc29sZQ0KZGV2aWNlICAgICAgICAgIHNjDQoNCiMgRW5hYmxl IHRoaXMgZm9yIHRoZSBwY3Z0IChWVDIyMCBjb21wYXRpYmxlKSBjb25zb2xlIGRyaXZlcg0KI2Rl dmljZSAgICAgICAgIHZ0DQojb3B0aW9ucyAgICAgICAgWFNFUlZFUiAgICAgICAgICMgc3VwcG9y dCBmb3IgWCBzZXJ2ZXIgb24gYSB2dCBjb25zb2xlDQojb3B0aW9ucyAgICAgICAgRkFUX0NVUlNP UiAgICAgICMgc3RhcnQgd2l0aCBibG9jayBjdXJzb3INCg0KZGV2aWNlICAgICAgICAgIGFncCAg ICAgICAgICAgICAjIHN1cHBvcnQgc2V2ZXJhbCBBR1AgY2hpcHNldHMNCg0KIyBQb3dlciBtYW5h Z2VtZW50IHN1cHBvcnQgKHNlZSBOT1RFUyBmb3IgbW9yZSBvcHRpb25zKQ0KI2RldmljZSAgICAg ICAgIGFwbQ0KIyBBZGQgc3VzcGVuZC9yZXN1bWUgc3VwcG9ydCBmb3IgdGhlIGk4MjU0Lg0KZGV2 aWNlICAgICAgICAgIHBtdGltZXINCg0KIyBQQ0NBUkQgKFBDTUNJQSkgc3VwcG9ydA0KIyBQQ01D SUEgYW5kIGNhcmRidXMgYnJpZGdlIHN1cHBvcnQNCmRldmljZSAgICAgICAgICBjYmIgICAgICAg ICAgICAgIyBjYXJkYnVzICh5ZW50YSkgYnJpZGdlDQpkZXZpY2UgICAgICAgICAgcGNjYXJkICAg ICAgICAgICMgUEMgQ2FyZCAoMTYtYml0KSBidXMNCmRldmljZSAgICAgICAgICBjYXJkYnVzICAg ICAgICAgIyBDYXJkQnVzICgzMi1iaXQpIGJ1cw0KDQojIFNlcmlhbCAoQ09NKSBwb3J0cw0KZGV2 aWNlICAgICAgICAgIHNpbyAgICAgICAgICAgICAjIDgyNTAsIDE2WzQ1XTUwIGJhc2VkIHNlcmlh bCBwb3J0cw0KDQojIFBhcmFsbGVsIHBvcnQNCmRldmljZSAgICAgICAgICBwcGMNCmRldmljZSAg ICAgICAgICBwcGJ1cyAgICAgICAgICAgIyBQYXJhbGxlbCBwb3J0IGJ1cyAocmVxdWlyZWQpDQpk ZXZpY2UgICAgICAgICAgbHB0ICAgICAgICAgICAgICMgUHJpbnRlcg0KZGV2aWNlICAgICAgICAg IHBsaXAgICAgICAgICAgICAjIFRDUC9JUCBvdmVyIHBhcmFsbGVsDQpkZXZpY2UgICAgICAgICAg cHBpICAgICAgICAgICAgICMgUGFyYWxsZWwgcG9ydCBpbnRlcmZhY2UgZGV2aWNlDQojZGV2aWNl ICAgICAgICAgdnBvICAgICAgICAgICAgICMgUmVxdWlyZXMgc2NidXMgYW5kIGRhDQoNCiMgSWYg eW91J3ZlIGdvdCBhICJkdW1iIiBzZXJpYWwgb3IgcGFyYWxsZWwgUENJIGNhcmQgdGhhdCBpcw0K IyBzdXBwb3J0ZWQgYnkgdGhlIHB1Yyg0KSBnbHVlIGRyaXZlciwgdW5jb21tZW50IHRoZSBmb2xs b3dpbmcNCiMgbGluZSB0byBlbmFibGUgaXQgKGNvbm5lY3RzIHRvIHRoZSBzaW8gYW5kL29yIHBw YyBkcml2ZXJzKToNCiNkZXZpY2UgICAgICAgICBwdWMNCiMgUENJIEV0aGVybmV0IE5JQ3MuDQpk ZXZpY2UgICAgICAgICAgZGUgICAgICAgICAgICAgICMgREVDL0ludGVsIERDMjF4NHggKGBgVHVs aXAnJykNCmRldmljZSAgICAgICAgICBlbSAgICAgICAgICAgICAgIyBJbnRlbCBQUk8vMTAwMCBh ZGFwdGVyIEdpZ2FiaXQgRXRoZXJuZXQgQ2FyZA0KZGV2aWNlICAgICAgICAgIGl4Z2IgICAgICAg ICAgICAjIEludGVsIFBSTy8xMEdiRSBFdGhlcm5ldCBDYXJkDQpkZXZpY2UgICAgICAgICAgdHhw ICAgICAgICAgICAgICMgM0NvbSAzY1I5OTAgKGBgVHlwaG9vbicnKQ0KZGV2aWNlICAgICAgICAg IHZ4ICAgICAgICAgICAgICAjIDNDb20gM2M1OTAsIDNjNTk1IChgYFZvcnRleCcnKQ0KDQojIFBD SSBFdGhlcm5ldCBOSUNzIHRoYXQgdXNlIHRoZSBjb21tb24gTUlJIGJ1cyBjb250cm9sbGVyIGNv ZGUuDQojIE5PVEU6IEJlIHN1cmUgdG8ga2VlcCB0aGUgJ2RldmljZSBtaWlidXMnIGxpbmUgaW4g b3JkZXIgdG8gdXNlIHRoZXNlIE5JQ3MhDQpkZXZpY2UgICAgICAgICAgbWlpYnVzICAgICAgICAg ICMgTUlJIGJ1cyBzdXBwb3J0DQpkZXZpY2UgICAgICAgICAgYmNlICAgICAgICAgICAgICMgQnJv YWRjb20gQkNNNTcwNi9CQ001NzA4IEdpZ2FiaXQgRXRoZXJuZXQNCmRldmljZSAgICAgICAgICBi ZmUgICAgICAgICAgICAgIyBCcm9hZGNvbSBCQ000NDB4IDEwLzEwMCBFdGhlcm5ldA0KZGV2aWNl ICAgICAgICAgIGJnZSAgICAgICAgICAgICAjIEJyb2FkY29tIEJDTTU3MHh4IEdpZ2FiaXQgRXRo ZXJuZXQNCmRldmljZSAgICAgICAgICBkYyAgICAgICAgICAgICAgIyBERUMvSW50ZWwgMjExNDMg YW5kIHZhcmlvdXMgd29ya2FsaWtlcw0KZGV2aWNlICAgICAgICAgIGZ4cCAgICAgICAgICAgICAj IEludGVsIEV0aGVyRXhwcmVzcyBQUk8vMTAwQiAoODI1NTcsIDgyNTU4KQ0KZGV2aWNlICAgICAg ICAgIGxnZSAgICAgICAgICAgICAjIExldmVsIDEgTFhUMTAwMSBnaWdhYml0IEV0aGVybmV0DQpk ZXZpY2UgICAgICAgICAgbmdlICAgICAgICAgICAgICMgTmF0U2VtaSBEUDgzODIwIGdpZ2FiaXQg RXRoZXJuZXQNCmRldmljZSAgICAgICAgICBudmUgICAgICAgICAgICAgIyBuVmlkaWEgbkZvcmNl IE1DUCBvbi1ib2FyZCBFdGhlcm5ldCBOZXR3b3JraW5nDQpkZXZpY2UgICAgICAgICAgcGNuICAg ICAgICAgICAgICMgQU1EIEFtNzlDOTd4IFBDSSAxMC8xMDAocHJlY2VkZW5jZSBvdmVyICdsbmMn KQ0KZGV2aWNlICAgICAgICAgIHJlICAgICAgICAgICAgICAjIFJlYWxUZWsgODEzOUMrLzgxNjkv ODE2OVMvODExMFMNCmRldmljZSAgICAgICAgICBybCAgICAgICAgICAgICAgIyBSZWFsVGVrIDgx MjkvODEzOQ0KZGV2aWNlICAgICAgICAgIHNmICAgICAgICAgICAgICAjIEFkYXB0ZWMgQUlDLTY5 MTUgKGBgU3RhcmZpcmUnJykNCmRldmljZSAgICAgICAgICBzaXMgICAgICAgICAgICAgIyBTaWxp Y29uIEludGVncmF0ZWQgU3lzdGVtcyBTaVMgOTAwL1NpUyA3MDE2DQpkZXZpY2UgICAgICAgICAg c2sgICAgICAgICAgICAgICMgU3lzS29ubmVjdCBTSy05ODR4ICYgU0stOTgyeCBnaWdhYml0IEV0 aGVybmV0DQpkZXZpY2UgICAgICAgICAgc3RlICAgICAgICAgICAgICMgU3VuZGFuY2UgU1QyMDEg KEQtTGluayBERkUtNTUwVFgpDQpkZXZpY2UgICAgICAgICAgdGkgICAgICAgICAgICAgICMgQWx0 ZW9uIE5ldHdvcmtzIFRpZ29uIEkvSUkgZ2lnYWJpdCBFdGhlcm5ldA0KZGV2aWNlICAgICAgICAg IHRsICAgICAgICAgICAgICAjIFRleGFzIEluc3RydW1lbnRzIFRodW5kZXJMQU4NCmRldmljZSAg ICAgICAgICB0eCAgICAgICAgICAgICAgIyBTTUMgRXRoZXJQb3dlciBJSSAoODNjMTcwIGBgRVBJ QycnKQ0KZGV2aWNlICAgICAgICAgIHZnZSAgICAgICAgICAgICAjIFZJQSBWVDYxMnggZ2lnYWJp dCBFdGhlcm5ldA0KZGV2aWNlICAgICAgICAgIHZyICAgICAgICAgICAgICAjIFZJQSBSaGluZSwg UmhpbmUgSUkNCmRldmljZSAgICAgICAgICB3YiAgICAgICAgICAgICAgIyBXaW5ib25kIFc4OUM4 NDBGDQpkZXZpY2UgICAgICAgICAgeGwgICAgICAgICAgICAgICMgM0NvbSAzYzkweCAoYGBCb29t ZXJhbmcnJywgYGBDeWNsb25lJycpDQoNCiMgSVNBIEV0aGVybmV0IE5JQ3MuICBwY2NhcmQgTklD cyBpbmNsdWRlZC4NCmRldmljZSAgICAgICAgICBjcyAgICAgICAgICAgICAgIyBDcnlzdGFsIFNl bWljb25kdWN0b3IgQ1M4OXgwIE5JQw0KIyAnZGV2aWNlIGVkJyByZXF1aXJlcyAnZGV2aWNlIG1p aWJ1cycNCmRldmljZSAgICAgICAgICBlZCAgICAgICAgICAgICAgIyBORVsxMl0wMDAsIFNNQyBV bHRyYSwgM2M1MDMsIERTODM5MCBjYXJkcw0KZGV2aWNlICAgICAgICAgIGV4ICAgICAgICAgICAg ICAjIEludGVsIEV0aGVyRXhwcmVzcyBQcm8vMTAgYW5kIFByby8xMCsNCmRldmljZSAgICAgICAg ICBlcCAgICAgICAgICAgICAgIyBFdGhlcmxpbmsgSUlJIGJhc2VkIGNhcmRzDQpkZXZpY2UgICAg ICAgICAgZmUgICAgICAgICAgICAgICMgRnVqaXRzdSBNQjg2OTZ4IGJhc2VkIGNhcmRzDQpkZXZp Y2UgICAgICAgICAgaWUgICAgICAgICAgICAgICMgRXRoZXJFeHByZXNzIDgvMTYsIDNDNTA3LCBT dGFyTEFOIDEwIGV0Yy4NCmRldmljZSAgICAgICAgICBzbiAgICAgICAgICAgICAgIyBTTUMncyA5 MDAwIHNlcmllcyBvZiBFdGhlcm5ldCBjaGlwcw0KZGV2aWNlICAgICAgICAgIHhlICAgICAgICAg ICAgICAjIFhpcmNvbSBwY2NhcmQgRXRoZXJuZXQNCg0KIyBXaXJlbGVzcyBOSUMgY2FyZHMNCmRl dmljZSAgICAgICAgICB3bGFuICAgICAgICAgICAgIyA4MDIuMTEgc3VwcG9ydA0KZGV2aWNlICAg ICAgICAgIHdsYW5fd2VwICAgICAgICAjIDgwMi4xMSBXRVAgc3VwcG9ydA0KZGV2aWNlICAgICAg ICAgIHdsYW5fY2NtcCAgICAgICAjIDgwMi4xMSBDQ01QIHN1cHBvcnQNCmRldmljZSAgICAgICAg ICB3bGFuX3RraXAgICAgICAgIyA4MDIuMTEgVEtJUCBzdXBwb3J0DQpkZXZpY2UgICAgICAgICAg YW4gICAgICAgICAgICAgICMgQWlyb25ldCA0NTAwLzQ4MDAgODAyLjExIHdpcmVsZXNzIE5JQ3Mu DQpkZXZpY2UgICAgICAgICAgYXRoICAgICAgICAgICAgICMgQXRoZXJvcyBwY2kvY2FyZGJ1cyBO SUMncw0KZGV2aWNlICAgICAgICAgIGF0aF9oYWwgICAgICAgICAjIEF0aGVyb3MgSEFMIChIYXJk d2FyZSBBY2Nlc3MgTGF5ZXIpDQpkZXZpY2UgICAgICAgICAgYXRoX3JhdGVfc2FtcGxlICMgU2Ft cGxlUmF0ZSB0eCByYXRlIGNvbnRyb2wgZm9yIGF0aA0KZGV2aWNlICAgICAgICAgIGF3aSAgICAg ICAgICAgICAjIEJheVN0YWNrIDY2MCBhbmQgb3RoZXJzDQpkZXZpY2UgICAgICAgICAgcmFsICAg ICAgICAgICAgICMgUmFsaW5rIFRlY2hub2xvZ3kgUlQyNTAwIHdpcmVsZXNzIE5JQ3MuDQpkZXZp Y2UgICAgICAgICAgd2kgICAgICAgICAgICAgICMgV2F2ZUxBTi9JbnRlcnNpbC9TeW1ib2wgODAy LjExIHdpcmVsZXNzIE5JQ3MuDQojZGV2aWNlICAgICAgICAgd2wgICAgICAgICAgICAgICMgT2xk ZXIgbm9uIDgwMi4xMSBXYXZlbGFuIHdpcmVsZXNzIE5JQy4NCg0KIyBQc2V1ZG8gZGV2aWNlcy4N CmRldmljZSAgICAgICAgICBsb29wICAgICAgICAgICAgIyBOZXR3b3JrIGxvb3BiYWNrDQpkZXZp Y2UgICAgICAgICAgcmFuZG9tICAgICAgICAgICMgRW50cm9weSBkZXZpY2UNCmRldmljZSAgICAg ICAgICBldGhlciAgICAgICAgICAgIyBFdGhlcm5ldCBzdXBwb3J0DQpkZXZpY2UgICAgICAgICAg c2wgICAgICAgICAgICAgICMgS2VybmVsIFNMSVANCmRldmljZSAgICAgICAgICBwcHAgICAgICAg ICAgICAgIyBLZXJuZWwgUFBQDQpkZXZpY2UgICAgICAgICAgdHVuICAgICAgICAgICAgICMgUGFj a2V0IHR1bm5lbC4NCmRldmljZSAgICAgICAgICBwdHkgICAgICAgICAgICAgIyBQc2V1ZG8tdHR5 cyAodGVsbmV0IGV0YykNCmRldmljZSAgICAgICAgICBtZCAgICAgICAgICAgICAgIyBNZW1vcnkg ImRpc2tzIg0KZGV2aWNlICAgICAgICAgIGdpZiAgICAgICAgICAgICAjIElQdjYgYW5kIElQdjQg dHVubmVsaW5nDQpkZXZpY2UgICAgICAgICAgZmFpdGggICAgICAgICAgICMgSVB2Ni10by1JUHY0 IHJlbGF5aW5nICh0cmFuc2xhdGlvbikNCg0KIyBUaGUgYGJwZicgZGV2aWNlIGVuYWJsZXMgdGhl IEJlcmtlbGV5IFBhY2tldCBGaWx0ZXIuDQojIEJlIGF3YXJlIG9mIHRoZSBhZG1pbmlzdHJhdGl2 ZSBjb25zZXF1ZW5jZXMgb2YgZW5hYmxpbmcgdGhpcyENCiMgTm90ZSB0aGF0ICdicGYnIGlzIHJl cXVpcmVkIGZvciBESENQLg0KZGV2aWNlICAgICAgICAgIGJwZiAgICAgICAgICAgICAjIEJlcmtl bGV5IHBhY2tldCBmaWx0ZXINCg0KIyBVU0Igc3VwcG9ydA0KZGV2aWNlICAgICAgICAgIHVoY2kg ICAgICAgICAgICAjIFVIQ0kgUENJLT5VU0IgaW50ZXJmYWNlDQpkZXZpY2UgICAgICAgICAgb2hj aSAgICAgICAgICAgICMgT0hDSSBQQ0ktPlVTQiBpbnRlcmZhY2UNCmRldmljZSAgICAgICAgICBl aGNpICAgICAgICAgICAgIyBFSENJIFBDSS0+VVNCIGludGVyZmFjZSAoVVNCIDIuMCkNCmRldmlj ZSAgICAgICAgICB1c2IgICAgICAgICAgICAgIyBVU0IgQnVzIChyZXF1aXJlZCkNCiNkZXZpY2Ug ICAgICAgICB1ZGJwICAgICAgICAgICAgIyBVU0IgRG91YmxlIEJ1bGsgUGlwZSBkZXZpY2VzDQpk ZXZpY2UgICAgICAgICAgdWdlbiAgICAgICAgICAgICMgR2VuZXJpYw0KZGV2aWNlICAgICAgICAg IHVoaWQgICAgICAgICAgICAjICJIdW1hbiBJbnRlcmZhY2UgRGV2aWNlcyINCmRldmljZSAgICAg ICAgICB1a2JkICAgICAgICAgICAgIyBLZXlib2FyZA0KZGV2aWNlICAgICAgICAgIHVscHQgICAg ICAgICAgICAjIFByaW50ZXINCmRldmljZSAgICAgICAgICB1bWFzcyAgICAgICAgICAgIyBEaXNr cy9NYXNzIHN0b3JhZ2UgLSBSZXF1aXJlcyBzY2J1cyBhbmQgZGENCmRldmljZSAgICAgICAgICB1 bXMgICAgICAgICAgICAgIyBNb3VzZQ0KZGV2aWNlICAgICAgICAgIHVyYWwgICAgICAgICAgICAj IFJhbGluayBUZWNobm9sb2d5IFJUMjUwMFVTQiB3aXJlbGVzcyBOSUNzDQpkZXZpY2UgICAgICAg ICAgdXJpbyAgICAgICAgICAgICMgRGlhbW9uZCBSaW8gNTAwIE1QMyBwbGF5ZXINCmRldmljZSAg ICAgICAgICB1c2Nhbm5lciAgICAgICAgIyBTY2FubmVycw0KIyBVU0IgRXRoZXJuZXQsIHJlcXVp cmVzIG1paWJ1cw0KZGV2aWNlICAgICAgICAgIGF1ZSAgICAgICAgICAgICAjIEFETXRlayBVU0Ig RXRoZXJuZXQNCmRldmljZSAgICAgICAgICBheGUgICAgICAgICAgICAgIyBBU0lYIEVsZWN0cm9u aWNzIFVTQiBFdGhlcm5ldA0KZGV2aWNlICAgICAgICAgIGNkY2UgICAgICAgICAgICAjIEdlbmVy aWMgVVNCIG92ZXIgRXRoZXJuZXQNCmRldmljZSAgICAgICAgICBjdWUgICAgICAgICAgICAgIyBD QVRDIFVTQiBFdGhlcm5ldA0KZGV2aWNlICAgICAgICAgIGt1ZSAgICAgICAgICAgICAjIEthd2Fz YWtpIExTSSBVU0IgRXRoZXJuZXQNCmRldmljZSAgICAgICAgICBydWUgICAgICAgICAgICAgIyBS ZWFsVGVrIFJUTDgxNTAgVVNCIEV0aGVybmV0DQoNCiMgRmlyZVdpcmUgc3VwcG9ydA0KZGV2aWNl ICAgICAgICAgIGZpcmV3aXJlICAgICAgICAjIEZpcmVXaXJlIGJ1cyBjb2RlDQpkZXZpY2UgICAg ICAgICAgc2JwICAgICAgICAgICAgICMgU0NTSSBvdmVyIEZpcmVXaXJlIChSZXF1aXJlcyBzY2J1 cyBhbmQgZGEpDQpkZXZpY2UgICAgICAgICAgZndlICAgICAgICAgICAgICMgRXRoZXJuZXQgb3Zl ciBGaXJlV2lyZSAobm9uLXN0YW5kYXJkISkNCg0KZGV2aWNlIGl3aQ0KZGV2aWNlIGZpcm13YXJl DQo= ------=_Part_44229_20100486.1159206163566 Content-Type: text/plain; name=pciconf.txt; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: f_esj5awil Content-Disposition: attachment; filename="pciconf.txt" aG9zdGIwQHBjaTA6MDowOiAgICAgICAgY2xhc3M9MHgwNjAwMDAgY2FyZD0weDAwOGYxMDI1IGNo aXA9MHgyNTkwODA4NiByZXY9MHgwMyBoZHI9MHgwMA0KICAgIHZlbmRvciAgID0gJ0ludGVsIENv cnBvcmF0aW9uJw0KICAgIGRldmljZSAgID0gJzgyOTE1UE0vR00vR01TLCA4MjkxMEdNTCBIb3N0 IEJyaWRnZScNCiAgICBjbGFzcyAgICA9IGJyaWRnZQ0KICAgIHN1YmNsYXNzID0gSE9TVC1QQ0kN CnZnYXBjaTBAcGNpMDoyOjA6ICAgICAgIGNsYXNzPTB4MDMwMDAwIGNhcmQ9MHgwMDhmMTAyNSBj aGlwPTB4MjU5MjgwODYgcmV2PTB4MDMgaGRyPTB4MDANCiAgICB2ZW5kb3IgICA9ICdJbnRlbCBD b3Jwb3JhdGlvbicNCiAgICBkZXZpY2UgICA9ICc4MjkxNUdNL0dNUywgODI5MTBHTUwgSW50ZWdy YXRlZCBHcmFwaGljcyBEZXZpY2UnDQogICAgY2xhc3MgICAgPSBkaXNwbGF5DQogICAgc3ViY2xh c3MgPSBWR0ENCnZnYXBjaTFAcGNpMDoyOjE6ICAgICAgIGNsYXNzPTB4MDM4MDAwIGNhcmQ9MHgw MDhmMTAyNSBjaGlwPTB4Mjc5MjgwODYgcmV2PTB4MDMgaGRyPTB4MDANCiAgICB2ZW5kb3IgICA9 ICdJbnRlbCBDb3Jwb3JhdGlvbicNCiAgICBkZXZpY2UgICA9ICc4MjkxNUdNL0dNUyw4MjkxMEdN TCBNb2JpbGUgRXhwcmVzcyBGYW1pbHkgR3JhcGhpY3MgQ29udHJvbGxlciAoPz8pJw0KICAgIGNs YXNzICAgID0gZGlzcGxheQ0Kbm9uZTBAcGNpMDoyNzowOiAgICAgICAgY2xhc3M9MHgwNDAzMDAg Y2FyZD0weDAwOGYxMDI1IGNoaXA9MHgyNjY4ODA4NiByZXY9MHgwNCBoZHI9MHgwMA0KICAgIHZl bmRvciAgID0gJ0ludGVsIENvcnBvcmF0aW9uJw0KICAgIGRldmljZSAgID0gJzgyODAxRkIvRlIv RlcvRlJXIEludGVsIEhpZ2ggRGVmaU5pdGlvbiBBdWRpbyBDb250cm9sbGVyJw0KICAgIGNsYXNz ICAgID0gbXVsdGltZWRpYQ0KcGNpYjFAcGNpMDoyODowOiAgICAgICAgY2xhc3M9MHgwNjA0MDAg Y2FyZD0weDAwMDAwMDQwIGNoaXA9MHgyNjYwODA4NiByZXY9MHgwNCBoZHI9MHgwMQ0KICAgIHZl bmRvciAgID0gJ0ludGVsIENvcnBvcmF0aW9uJw0KICAgIGRldmljZSAgID0gJzgyODAxRkIvRlIv RlcvRlJXIFBDSSBFeHByZXNzIFBvcnQgMScNCiAgICBjbGFzcyAgICA9IGJyaWRnZQ0KICAgIHN1 YmNsYXNzID0gUENJLVBDSQ0KcGNpYjJAcGNpMDoyODoxOiAgICAgICAgY2xhc3M9MHgwNjA0MDAg Y2FyZD0weDAwMDAwMDQwIGNoaXA9MHgyNjYyODA4NiByZXY9MHgwNCBoZHI9MHgwMQ0KICAgIHZl bmRvciAgID0gJ0ludGVsIENvcnBvcmF0aW9uJw0KICAgIGRldmljZSAgID0gJzgyODAxRkIvRlIv RlcvRlJXIFBDSSBFeHByZXNzIFBvcnQgMicNCiAgICBjbGFzcyAgICA9IGJyaWRnZQ0KICAgIHN1 YmNsYXNzID0gUENJLVBDSQ0KcGNpYjNAcGNpMDoyODoyOiAgICAgICAgY2xhc3M9MHgwNjA0MDAg Y2FyZD0weDAwMDAwMDQwIGNoaXA9MHgyNjY0ODA4NiByZXY9MHgwNCBoZHI9MHgwMQ0KICAgIHZl bmRvciAgID0gJ0ludGVsIENvcnBvcmF0aW9uJw0KICAgIGRldmljZSAgID0gJzgyODAxRkIvRlIv RlcvRlJXIFBDSSBFeHByZXNzIFBvcnQgMycNCiAgICBjbGFzcyAgICA9IGJyaWRnZQ0KICAgIHN1 YmNsYXNzID0gUENJLVBDSQ0KdWhjaTBAcGNpMDoyOTowOiAgICAgICAgY2xhc3M9MHgwYzAzMDAg Y2FyZD0weDAwOGYxMDI1IGNoaXA9MHgyNjU4ODA4NiByZXY9MHgwNCBoZHI9MHgwMA0KICAgIHZl bmRvciAgID0gJ0ludGVsIENvcnBvcmF0aW9uJw0KICAgIGRldmljZSAgID0gJzgyODAxRkIvRlIv RlcvRlJXIFVTQiBVSENJIENvbnRyb2xsZXInDQogICAgY2xhc3MgICAgPSBzZXJpYWwgYnVzDQog ICAgc3ViY2xhc3MgPSBVU0INCnVoY2kxQHBjaTA6Mjk6MTogICAgICAgIGNsYXNzPTB4MGMwMzAw IGNhcmQ9MHgwMDhmMTAyNSBjaGlwPTB4MjY1OTgwODYgcmV2PTB4MDQgaGRyPTB4MDANCiAgICB2 ZW5kb3IgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicNCiAgICBkZXZpY2UgICA9ICc4MjgwMUZCL0ZS L0ZXL0ZSVyBVU0IgVUhDSSBDb250cm9sbGVyJw0KICAgIGNsYXNzICAgID0gc2VyaWFsIGJ1cw0K ICAgIHN1YmNsYXNzID0gVVNCDQp1aGNpMkBwY2kwOjI5OjI6ICAgICAgICBjbGFzcz0weDBjMDMw MCBjYXJkPTB4MDA4ZjEwMjUgY2hpcD0weDI2NWE4MDg2IHJldj0weDA0IGhkcj0weDAwDQogICAg dmVuZG9yICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nDQogICAgZGV2aWNlICAgPSAnODI4MDFGQi9G Ui9GVy9GUlcgVVNCIFVIQ0kgQ29udHJvbGxlcicNCiAgICBjbGFzcyAgICA9IHNlcmlhbCBidXMN CiAgICBzdWJjbGFzcyA9IFVTQg0KdWhjaTNAcGNpMDoyOTozOiAgICAgICAgY2xhc3M9MHgwYzAz MDAgY2FyZD0weDAwOGYxMDI1IGNoaXA9MHgyNjViODA4NiByZXY9MHgwNCBoZHI9MHgwMA0KICAg IHZlbmRvciAgID0gJ0ludGVsIENvcnBvcmF0aW9uJw0KICAgIGRldmljZSAgID0gJzgyODAxRkIv RlIvRlcvRlJXIFVTQiBVSENJIENvbnRyb2xsZXInDQogICAgY2xhc3MgICAgPSBzZXJpYWwgYnVz DQogICAgc3ViY2xhc3MgPSBVU0INCmVoY2kwQHBjaTA6Mjk6NzogICAgICAgIGNsYXNzPTB4MGMw MzIwIGNhcmQ9MHgwMDhmMTAyNSBjaGlwPTB4MjY1YzgwODYgcmV2PTB4MDQgaGRyPTB4MDANCiAg ICB2ZW5kb3IgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicNCiAgICBkZXZpY2UgICA9ICc4MjgwMUZC L0ZSL0ZXL0ZSVyBVU0IgMi4wIEVIQ0kgQ29udHJvbGxlcicNCiAgICBjbGFzcyAgICA9IHNlcmlh bCBidXMNCiAgICBzdWJjbGFzcyA9IFVTQg0KcGNpYjRAcGNpMDozMDowOiAgICAgICAgY2xhc3M9 MHgwNjA0MDEgY2FyZD0weDAwMDAwMDUwIGNoaXA9MHgyNDQ4ODA4NiByZXY9MHhkNCBoZHI9MHgw MQ0KICAgIHZlbmRvciAgID0gJ0ludGVsIENvcnBvcmF0aW9uJw0KICAgIGRldmljZSAgID0gJzgy ODAxQkFNL0NBTS9EQk0gKElDSDItTS8zLU0vNC1NKSBIdWIgSW50ZXJmYWNlIHRvIFBDSSBCcmlk Z2UnDQogICAgY2xhc3MgICAgPSBicmlkZ2UNCiAgICBzdWJjbGFzcyA9IFBDSS1QQ0kNCmlzYWIw QHBjaTA6MzE6MDogICAgICAgIGNsYXNzPTB4MDYwMTAwIGNhcmQ9MHgwMDhmMTAyNSBjaGlwPTB4 MjY0MTgwODYgcmV2PTB4MDQgaGRyPTB4MDANCiAgICB2ZW5kb3IgICA9ICdJbnRlbCBDb3Jwb3Jh dGlvbicNCiAgICBkZXZpY2UgICA9ICc4MjgwMUZCTSBJQ0g2TSBMUEMgSW50ZXJmYWNlIEJyaWRn ZScNCiAgICBjbGFzcyAgICA9IGJyaWRnZQ0KICAgIHN1YmNsYXNzID0gUENJLUlTQQ0KYXRhcGNp MEBwY2kwOjMxOjE6ICAgICAgY2xhc3M9MHgwMTAxOGEgY2FyZD0weDAwOGYxMDI1IGNoaXA9MHgy NjZmODA4NiByZXY9MHgwNCBoZHI9MHgwMA0KICAgIHZlbmRvciAgID0gJ0ludGVsIENvcnBvcmF0 aW9uJw0KICAgIGRldmljZSAgID0gJzgyODAxRkIvRkJNIFVsdHJhIEFUQSBTdG9yYWdlIENvbnRy b2xsZXJzIC0gMjY2RicNCiAgICBjbGFzcyAgICA9IG1hc3Mgc3RvcmFnZQ0KICAgIHN1YmNsYXNz ID0gQVRBDQpub25lMUBwY2kwOjMxOjM6ICAgICAgICBjbGFzcz0weDBjMDUwMCBjYXJkPTB4MDA4 ZjEwMjUgY2hpcD0weDI2NmE4MDg2IHJldj0weDA0IGhkcj0weDAwDQogICAgdmVuZG9yICAgPSAn SW50ZWwgQ29ycG9yYXRpb24nDQogICAgZGV2aWNlICAgPSAnODI4MDFGQi9GUi9GVy9GUlcgU01C dXMgQ29udHJvbGxlcicNCiAgICBjbGFzcyAgICA9IHNlcmlhbCBidXMNCiAgICBzdWJjbGFzcyA9 IFNNQnVzDQpjYmIwQHBjaTY6MTowOiAgY2xhc3M9MHgwNjA3MDAgY2FyZD0weDAwOGYxMDI1IGNo aXA9MHhhYzU2MTA0YyByZXY9MHgwMCBoZHI9MHgwMg0KICAgIHZlbmRvciAgID0gJ1RleGFzIElu c3RydW1lbnRzIChUSSknDQogICAgZGV2aWNlICAgPSAnUENJMTUxMCBQQyBDYXJkIENhcmRCdXMg Q29udHJvbGxlcicNCiAgICBjbGFzcyAgICA9IGJyaWRnZQ0KICAgIHN1YmNsYXNzID0gUENJLUNh cmRCdXMNCml3aTBAcGNpNjo0OjA6ICBjbGFzcz0weDAyODAwMCBjYXJkPTB4MjcwMTgwODYgY2hp cD0weDQyMjA4MDg2IHJldj0weDA1IGhkcj0weDAwDQogICAgdmVuZG9yICAgPSAnSW50ZWwgQ29y cG9yYXRpb24nDQogICAgZGV2aWNlICAgPSAnUFJPL1dpcmVsZXNzIDIyMDBCRyBOZXR3b3JrIENv bm5lY3Rpb24nDQogICAgY2xhc3MgICAgPSBuZXR3b3JrDQpybDBAcGNpNjo4OjA6ICAgY2xhc3M9 MHgwMjAwMDAgY2FyZD0weGZmMzExMTc5IGNoaXA9MHg4MTM5MTBlYyByZXY9MHgxMCBoZHI9MHgw MA0KICAgIHZlbmRvciAgID0gJ1JlYWx0ZWsgU2VtaWNvbmR1Y3RvcicNCiAgICBkZXZpY2UgICA9 ICdSVDgxMzkgKEEvQi9DLzgxMHgvODEzeC9DKykgRmFzdCBFdGhlcm5ldCBBZGFwdGVyJw0KICAg IGNsYXNzICAgID0gbmV0d29yaw0KICAgIHN1YmNsYXNzID0gZXRoZXJuZXQNCg== ------=_Part_44229_20100486.1159206163566 Content-Type: text/plain; name=dmesg.txt; charset=ANSI_X3.4-1968 Content-Transfer-Encoding: base64 X-Attachment-Id: f_esj5b6sk Content-Disposition: attachment; filename="dmesg.txt" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDYgVGhlIEZyZWVCU0QgUHJvamVjdC4NCkNvcHlyaWdodCAo YykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5Mywg MTk5NA0KICAgICAgICBUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlh LiBBbGwgcmlnaHRzIHJlc2VydmVkLg0KRnJlZUJTRCA3LjAtQ1VSUkVOVCAjMTogTW9uIFNlcCAy NSAwMDozNzo0MiBXRVNUIDIwMDYNCiAgICByb290QGJsYWNrcGVhcmw6L3Vzci9vYmovdXNyL3Ny Yy9zeXMvYmxhY2twZWFybA0KVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBI eiBxdWFsaXR5IDANCkNQVTogSW50ZWwoUikgUGVudGl1bShSKSBNIHByb2Nlc3NvciAyLjAwR0h6 ICgyMDAwLjA4LU1IeiA2ODYtY2xhc3MgQ1BVKQ0KICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAg SWQgPSAweDZkOCAgU3RlcHBpbmcgPSA4DQogIEZlYXR1cmVzPTB4YWZlOWZiZmY8RlBVLFZNRSxE RSxQU0UsVFNDLE1TUixQQUUsTUNFLENYOCxBUElDLFNFUCxNVFJSLFBHRSxNQ0EsQ01PVixQQVQs Q0xGTFVTSCxEVFMsQUNQSSxNTVgsRlhTUixTU0UsU1NFMixTUyxUTSxQQkU+DQogIEZlYXR1cmVz Mj0weDE4MDxFU1QsVE0yPg0KICBBTUQgRmVhdHVyZXM9MHgxMDAwMDA8Tlg+DQpyZWFsIG1lbW9y eSAgPSAxMDYzNzgwMzUyICgxMDE0IE1CKQ0KYXZhaWwgbWVtb3J5ID0gMTAyNzY5NDU5MiAoOTgw IE1CKQ0KQUNQSSBBUElDIFRhYmxlOiA8SU5URUwgIEFMVklTTyAgPg0KaW9hcGljMDogQ2hhbmdp bmcgQVBJQyBJRCB0byAxDQppb2FwaWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzIG9uIG1vdGhl cmJvYXJkDQprYmQxIGF0IGtiZG11eDANCmF0aF9oYWw6IDAuOS4xNy4yIChBUjUyMTAsIEFSNTIx MSwgQVI1MjEyLCBSRjUxMTEsIFJGNTExMiwgUkYyNDEzLCBSRjU0MTMpDQphY3BpMDogPFBUTFRE ICAgUlNEVD4gb24gbW90aGVyYm9hcmQNCiAgICBBQ1BJLTA0NDg6ICoqKiBFcnJvcjogTG9va2lu ZyB1cCBbWjAwQV0gaW4gbmFtZXNwYWNlLCBBRV9OT1RfRk9VTkQNClNlYXJjaE5vZGUgMHhjMzdm YjRhMCBTdGFydE5vZGUgMHhjMzdmYjRhMCBSZXR1cm5Ob2RlIDANCmFjcGlfYnVzX251bWJlcjog Y2FuJ3QgZ2V0IF9BRFINCmFjcGlfYnVzX251bWJlcjogY2FuJ3QgZ2V0IF9BRFINCmFjcGlfYnVz X251bWJlcjogY2FuJ3QgZ2V0IF9BRFINCmFjcGlfYnVzX251bWJlcjogY2FuJ3QgZ2V0IF9BRFIN CmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQ0KdW5rbm93bjogSS9PIHJhbmdlIG5vdCBzdXBw b3J0ZWQNClRpbWVjb3VudGVyICJBQ1BJLWZhc3QiIGZyZXF1ZW5jeSAzNTc5NTQ1IEh6IHF1YWxp dHkgMTAwMA0KYWNwaV90aW1lcjA6IDwyNC1iaXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQg MHgxMDA4LTB4MTAwYiBvbiBhY3BpMA0KYWNwaV9lYzA6IDxFbWJlZGRlZCBDb250cm9sbGVyOiBH UEUgMHgxZD4gcG9ydCAweDYyLDB4NjYgb24gYWNwaTANCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNw aTANCmFjcGlfcGVyZjA6IDxBQ1BJIENQVSBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MA0KYWNw aV9wZXJmMDogZmFpbGVkIGluIFBFUkZfU1RBVFVTIGF0dGFjaA0KZGV2aWNlX2F0dGFjaDogYWNw aV9wZXJmMCBhdHRhY2ggcmV0dXJuZWQgNg0KYWNwaV9wZXJmMDogPEFDUEkgQ1BVIEZyZXF1ZW5j eSBDb250cm9sPiBvbiBjcHUwDQphY3BpX3BlcmYwOiBmYWlsZWQgaW4gUEVSRl9TVEFUVVMgYXR0 YWNoDQpkZXZpY2VfYXR0YWNoOiBhY3BpX3BlcmYwIGF0dGFjaCByZXR1cm5lZCA2DQphY3BpX3Ro cm90dGxlMDogPEFDUEkgQ1BVIFRocm90dGxpbmc+IG9uIGNwdTANCnBjaWIwOiA8QUNQSSBIb3N0 LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTANCnBjaTA6IDxBQ1BJIFBDSSBi dXM+IG9uIHBjaWIwDQp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUgZGlzcGxheT4gcG9ydCAweDE4 MDAtMHgxODA3IG1lbSAweGIwMDgwMDAwLTB4YjAwZmZmZmYsMHhjMDAwMDAwMC0weGNmZmZmZmZm LDB4YjAwMDAwMDAtMHhiMDAzZmZmZiBpcnEgMTYgYXQgZGV2aWNlIDIuMCBvbiBwY2kwDQphZ3Aw OiA8SW50ZWwgODI5MTVHTSAoOTE1R00gR01DSCkgU1ZHQSBjb250cm9sbGVyPiBvbiB2Z2FwY2kw DQphZ3AwOiBkZXRlY3RlZCA3OTMyayBzdG9sZW4gbWVtb3J5DQphZ3AwOiBhcGVydHVyZSBzaXpl IGlzIDI1Nk0NCnZnYXBjaTE6IDxWR0EtY29tcGF0aWJsZSBkaXNwbGF5PiBhdCBkZXZpY2UgMi4x IG9uIHBjaTANCnBjaTA6IDxtdWx0aW1lZGlhPiBhdCBkZXZpY2UgMjcuMCAobm8gZHJpdmVyIGF0 dGFjaGVkKQ0KcGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTcgYXQgZGV2aWNlIDI4 LjAgb24gcGNpMA0KcGNpOTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjENCnBjaWIyOiA8QUNQSSBQ Q0ktUENJIGJyaWRnZT4gaXJxIDE2IGF0IGRldmljZSAyOC4xIG9uIHBjaTANCnBjaTEwOiA8QUNQ SSBQQ0kgYnVzPiBvbiBwY2liMg0KcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBpcnEgMTgg YXQgZGV2aWNlIDI4LjIgb24gcGNpMA0KcGNpMjogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjMNCnVo Y2kwOiA8SW50ZWwgODI4MDFGQi9GUi9GVy9GUlcgKElDSDYpIFVTQiBjb250cm9sbGVyIFVTQi1B PiBwb3J0IDB4MTgyMC0weDE4M2YgaXJxIDIzIGF0IGRldmljZSAyOS4wIG9uIHBjaTANCnVoY2kw OiBbR0lBTlQtTE9DS0VEXQ0KdXNiMDogPEludGVsIDgyODAxRkIvRlIvRlcvRlJXIChJQ0g2KSBV U0IgY29udHJvbGxlciBVU0ItQT4gb24gdWhjaTANCnVzYjA6IFVTQiByZXZpc2lvbiAxLjANCnVo dWIwOiA8SW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRy IDE+IG9uIHVzYjANCnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJl ZA0KdWhjaTE6IDxJbnRlbCA4MjgwMUZCL0ZSL0ZXL0ZSVyAoSUNINikgVVNCIGNvbnRyb2xsZXIg VVNCLUI+IHBvcnQgMHgxODQwLTB4MTg1ZiBpcnEgMTkgYXQgZGV2aWNlIDI5LjEgb24gcGNpMA0K dWhjaTE6IFtHSUFOVC1MT0NLRURdDQp1c2IxOiA8SW50ZWwgODI4MDFGQi9GUi9GVy9GUlcgKElD SDYpIFVTQiBjb250cm9sbGVyIFVTQi1CPiBvbiB1aGNpMQ0KdXNiMTogVVNCIHJldmlzaW9uIDEu MA0KdWh1YjE6IDxJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAs IGFkZHIgMT4gb24gdXNiMQ0KdWh1YjE6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBw b3dlcmVkDQp1aGNpMjogPEludGVsIDgyODAxRkIvRlIvRlcvRlJXIChJQ0g2KSBVU0IgY29udHJv bGxlciBVU0ItQz4gcG9ydCAweDE4NjAtMHgxODdmIGlycSAxOCBhdCBkZXZpY2UgMjkuMiBvbiBw Y2kwDQp1aGNpMjogW0dJQU5ULUxPQ0tFRF0NCnVzYjI6IDxJbnRlbCA4MjgwMUZCL0ZSL0ZXL0ZS VyAoSUNINikgVVNCIGNvbnRyb2xsZXIgVVNCLUM+IG9uIHVoY2kyDQp1c2IyOiBVU0IgcmV2aXNp b24gMS4wDQp1aHViMjogPEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAv MS4wMCwgYWRkciAxPiBvbiB1c2IyDQp1aHViMjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBz ZWxmIHBvd2VyZWQNCnVoY2kzOiA8SW50ZWwgODI4MDFGQi9GUi9GVy9GUlcgKElDSDYpIFVTQiBj b250cm9sbGVyIFVTQi1EPiBwb3J0IDB4MTg4MC0weDE4OWYgaXJxIDE2IGF0IGRldmljZSAyOS4z IG9uIHBjaTANCnVoY2kzOiBbR0lBTlQtTE9DS0VEXQ0KdXNiMzogPEludGVsIDgyODAxRkIvRlIv RlcvRlJXIChJQ0g2KSBVU0IgY29udHJvbGxlciBVU0ItRD4gb24gdWhjaTMNCnVzYjM6IFVTQiBy ZXZpc2lvbiAxLjANCnVodWIzOiA8SW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYg MS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYjMNCnVodWIzOiAyIHBvcnRzIHdpdGggMiByZW1vdmFi bGUsIHNlbGYgcG93ZXJlZA0KZWhjaTA6IDxJbnRlbCA4MjgwMUZCIChJQ0g2KSBVU0IgMi4wIGNv bnRyb2xsZXI+IG1lbSAweGIwMDQwMDAwLTB4YjAwNDAzZmYgaXJxIDIzIGF0IGRldmljZSAyOS43 IG9uIHBjaTANCmVoY2kwOiBbR0lBTlQtTE9DS0VEXQ0KdXNiNDogRUhDSSB2ZXJzaW9uIDEuMA0K dXNiNDogY29tcGFuaW9uIGNvbnRyb2xsZXJzLCAyIHBvcnRzIGVhY2g6IHVzYjAgdXNiMSB1c2Iy IHVzYjMNCnVzYjQ6IDxJbnRlbCA4MjgwMUZCIChJQ0g2KSBVU0IgMi4wIGNvbnRyb2xsZXI+IG9u IGVoY2kwDQp1c2I0OiBVU0IgcmV2aXNpb24gMi4wDQp1aHViNDogPEludGVsIEVIQ0kgcm9vdCBo dWIsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2I0DQp1aHViNDogOCBw b3J0cyB3aXRoIDggcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNCnBjaWI0OiA8QUNQSSBQQ0ktUENJ IGJyaWRnZT4gYXQgZGV2aWNlIDMwLjAgb24gcGNpMA0KcGNpNjogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjQNCmNiYjA6IDxUSTE1MTAgUENJLUNhcmRCdXMgQnJpZGdlPiBtZW0gMHhiMDEwMDAwMC0w eGIwMTAwZmZmIGlycSAxOCBhdCBkZXZpY2UgMS4wIG9uIHBjaTYNCmNhcmRidXMwOiA8Q2FyZEJ1 cyBidXM+IG9uIGNiYjANCnBjY2FyZDA6IDwxNi1iaXQgUENDYXJkIGJ1cz4gb24gY2JiMA0KaXdp MDogPEludGVsKFIpIFBSTy9XaXJlbGVzcyAyMjAwQkc+IG1lbSAweGIwMTAxMDAwLTB4YjAxMDFm ZmYgaXJxIDE3IGF0IGRldmljZSA0LjAgb24gcGNpNg0KaXdpMDogRXRoZXJuZXQgYWRkcmVzczog MDA6MTM6Y2U6Mjg6OGI6NWINCnJsMDogPFJlYWxUZWsgODEzOSAxMC8xMDBCYXNlVFg+IHBvcnQg MHgyMDAwLTB4MjBmZiBtZW0gMHhiMDEwMjAwMC0weGIwMTAyMGZmIGlycSAxNiBhdCBkZXZpY2Ug OC4wIG9uIHBjaTYNCm1paWJ1czA6IDxNSUkgYnVzPiBvbiBybDANCnJscGh5MDogPFJlYWxUZWsg aW50ZXJuYWwgbWVkaWEgaW50ZXJmYWNlPiBvbiBtaWlidXMwDQpybHBoeTA6ICAxMGJhc2VULCAx MGJhc2VULUZEWCwgMTAwYmFzZVRYLCAxMDBiYXNlVFgtRkRYLCBhdXRvDQpybDA6IEV0aGVybmV0 IGFkZHJlc3M6IDAwOmMwOjlmOmQzOjE4Ojk3DQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBk ZXZpY2UgMzEuMCBvbiBwY2kwDQppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjANCmF0YXBjaTA6IDxJ bnRlbCBJQ0g2IFVETUExMDAgY29udHJvbGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNmNiwweDE3 MC0weDE3NywweDM3NiwweDE4MTAtMHgxODFmIGF0IGRldmljZSAzMS4xIG9uIHBjaTANCmF0YTA6 IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwDQphdGExOiA8QVRBIGNoYW5uZWwgMT4gb24gYXRh cGNpMA0KcGNpMDogPHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMzEuMyAobm8gZHJpdmVy IGF0dGFjaGVkKQ0KYWNwaV9hY2FkMDogPEFDIEFkYXB0ZXI+IG9uIGFjcGkwDQpiYXR0ZXJ5MDog PEFDUEkgQ29udHJvbCBNZXRob2QgQmF0dGVyeT4gb24gYWNwaTANCmFjcGlfbGlkMDogPENvbnRy b2wgTWV0aG9kIExpZCBTd2l0Y2g+IG9uIGFjcGkwDQphY3BpX2J1dHRvbjA6IDxQb3dlciBCdXR0 b24+IG9uIGFjcGkwDQphY3BpX2J1dHRvbjE6IDxTbGVlcCBCdXR0b24+IG9uIGFjcGkwDQphY3Bp X3R6MDogPFRoZXJtYWwgWm9uZT4gb24gYWNwaTANCmFjcGlfaHBldDA6IDxIaWdoIFByZWNpc2lv biBFdmVudCBUaW1lcj4gaW9tZW0gMHhmZWQwMDAwMC0weGZlZDAwM2ZmIGlycSAwLDggb24gYWNw aTANClRpbWVjb3VudGVyICJIUEVUIiBmcmVxdWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSAyMDAw DQphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjAsMHg2NCBp cnEgMSBvbiBhY3BpMA0KYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzANCmti ZDAgYXQgYXRrYmQwDQphdGtiZDA6IFtHSUFOVC1MT0NLRURdDQpwc20wOiA8UFMvMiBNb3VzZT4g aXJxIDEyIG9uIGF0a2JkYzANCnBzbTA6IFtHSUFOVC1MT0NLRURdDQpwc20wOiBtb2RlbCBHZW5l cmljIFBTLzIgbW91c2UsIGRldmljZSBJRCAwDQpwbXRpbWVyMCBvbiBpc2EwDQpvcm0wOiA8SVNB IE9wdGlvbiBST01zPiBhdCBpb21lbSAweGNmODAwLTB4ZDA3ZmYsMHhlMDAwMC0weGUxN2ZmIHBu cGlkIE9STTAwMDAgb24gaXNhMA0KcHBjMDogcGFyYWxsZWwgcG9ydCBub3QgZm91bmQuDQpzYzA6 IDxTeXN0ZW0gY29uc29sZT4gYXQgZmxhZ3MgMHgxMDAgb24gaXNhMA0Kc2MwOiBWR0EgPDE2IHZp cnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MzAwPg0Kc2lvMDogY29uZmlndXJlZCBpcnEgNCBub3Qg aW4gYml0bWFwIG9mIHByb2JlZCBpcnFzIDANCnNpbzA6IHBvcnQgbWF5IG5vdCBiZSBlbmFibGVk DQpzaW8wOiBjb25maWd1cmVkIGlycSA0IG5vdCBpbiBiaXRtYXAgb2YgcHJvYmVkIGlycXMgMA0K c2lvMDogcG9ydCBtYXkgbm90IGJlIGVuYWJsZWQNCnNpbzAgYXQgcG9ydCAweDNmOC0weDNmZiBp cnEgNCBmbGFncyAweDEwIG9uIGlzYTANCnNpbzA6IHR5cGUgODI1MCBvciBub3QgcmVzcG9uZGlu Zw0Kc2lvMDogW0ZBU1RdDQpzaW8xOiBjb25maWd1cmVkIGlycSAzIG5vdCBpbiBiaXRtYXAgb2Yg cHJvYmVkIGlycXMgMA0Kc2lvMTogcG9ydCBtYXkgbm90IGJlIGVuYWJsZWQNCnZnYTA6IDxHZW5l cmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZmIG9u IGlzYTANClRpbWVjb3VudGVyICJUU0MiIGZyZXF1ZW5jeSAyMDAwMDgyMjYzIEh6IHF1YWxpdHkg ODAwDQpUaW1lY291bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjDQphZDA6IDk1Mzk2TUIgPFNl YWdhdGUgU1Q5MTAwODIyQSAzLjAxPiBhdCBhdGEwLW1hc3RlciBVRE1BMTAwDQphY2QwOiBEVkRS IDxITC1EVC1TVCBEVkQtUlcgR1dBLTQwODJOL0NQMDM+IGF0IGF0YTAtc2xhdmUgVURNQTMzDQpU cnlpbmcgdG8gbW91bnQgcm9vdCBmcm9tIHVmczovZGV2L2FkMHMzYQ0KICAgIEFDUEktMDQ0ODog KioqIEVycm9yOiBMb29raW5nIHVwIFtaMDBBXSBpbiBuYW1lc3BhY2UsIEFFX05PVF9GT1VORA0K U2VhcmNoTm9kZSAweGMzN2ZiNGEwIFN0YXJ0Tm9kZSAweGMzN2ZiNGEwIFJldHVybk5vZGUgMA0K ICAgIEFDUEktMDYxMDogKioqIEVycm9yOiBNZXRob2QgZXhlY3V0aW9uIGZhaWxlZCBbXFxfU0Jf LkJBVDEuX0JTVF0gKE5vZGUgMHhjMzdmYjNhMCksIEFFX05PVF9GT1VORA0KICAgIEFDUEktMDQ0 ODogKioqIEVycm9yOiBMb29raW5nIHVwIFtaMDBBXSBpbiBuYW1lc3BhY2UsIEFFX05PVF9GT1VO RA0KU2VhcmNoTm9kZSAweGMzN2ZiNGEwIFN0YXJ0Tm9kZSAweGMzN2ZiNGEwIFJldHVybk5vZGUg MA0KICAgIEFDUEktMDYxMDogKioqIEVycm9yOiBNZXRob2QgZXhlY3V0aW9uIGZhaWxlZCBbXFxf U0JfLkJBVDEuX0JTVF0gKE5vZGUgMHhjMzdmYjNhMCksIEFFX05PVF9GT1VORA0KICAgIEFDUEkt MDQ0ODogKioqIEVycm9yOiBMb29raW5nIHVwIFtaMDBBXSBpbiBuYW1lc3BhY2UsIEFFX05PVF9G T1VORA0KU2VhcmNoTm9kZSAweGMzN2ZiNGEwIFN0YXJ0Tm9kZSAweGMzN2ZiNGEwIFJldHVybk5v ZGUgMA0KICAgIEFDUEktMDYxMDogKioqIEVycm9yOiBNZXRob2QgZXhlY3V0aW9uIGZhaWxlZCBb XFxfU0JfLkJBVDEuX0JTVF0gKE5vZGUgMHhjMzdmYjNhMCksIEFFX05PVF9GT1VORA0KICAgIEFD UEktMDQ0ODogKioqIEVycm9yOiBMb29raW5nIHVwIFtaMDBBXSBpbiBuYW1lc3BhY2UsIEFFX05P VF9GT1VORA0KU2VhcmNoTm9kZSAweGMzN2ZiNGEwIFN0YXJ0Tm9kZSAweGMzN2ZiNGEwIFJldHVy bk5vZGUgMA0KICAgIEFDUEktMDYxMDogKioqIEVycm9yOiBNZXRob2QgZXhlY3V0aW9uIGZhaWxl ZCBbXFxfU0JfLkJBVDEuX0JTVF0gKE5vZGUgMHhjMzdmYjNhMCksIEFFX05PVF9GT1VORA0KICAg IEFDUEktMDQ0ODogKioqIEVycm9yOiBMb29raW5nIHVwIFtaMDBBXSBpbiBuYW1lc3BhY2UsIEFF X05PVF9GT1VORA0KU2VhcmNoTm9kZSAweGMzN2ZiNGEwIFN0YXJ0Tm9kZSAweGMzN2ZiNGEwIFJl dHVybk5vZGUgMA0KICAgIEFDUEktMDYxMDogKioqIEVycm9yOiBNZXRob2QgZXhlY3V0aW9uIGZh aWxlZCBbXFxfU0JfLkJBVDEuX0JTVF0gKE5vZGUgMHhjMzdmYjNhMCksIEFFX05PVF9GT1VORA0K ICAgIEFDUEktMDQ0ODogKioqIEVycm9yOiBMb29raW5nIHVwIFtaMDBBXSBpbiBuYW1lc3BhY2Us IEFFX05PVF9GT1VORA0KU2VhcmNoTm9kZSAweGMzN2ZiNGEwIFN0YXJ0Tm9kZSAweGMzN2ZiNGEw IFJldHVybk5vZGUgMA0KICAgIEFDUEktMDYxMDogKioqIEVycm9yOiBNZXRob2QgZXhlY3V0aW9u IGZhaWxlZCBbXFxfU0JfLkJBVDEuX0JTVF0gKE5vZGUgMHhjMzdmYjNhMCksIEFFX05PVF9GT1VO RA0K ------=_Part_44229_20100486.1159206163566-- From owner-freebsd-current@FreeBSD.ORG Mon Sep 25 18:03:30 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3D2F16A407 for ; Mon, 25 Sep 2006 18:03:30 +0000 (UTC) (envelope-from joel@FreeBSD.org) Received: from av12-2-sn2.hy.skanova.net (av12-2-sn2.hy.skanova.net [81.228.8.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6692943D76 for ; Mon, 25 Sep 2006 18:03:30 +0000 (GMT) (envelope-from joel@FreeBSD.org) Received: by av12-2-sn2.hy.skanova.net (Postfix, from userid 502) id 131F337F9E; Mon, 25 Sep 2006 20:03:29 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av12-2-sn2.hy.skanova.net (Postfix) with ESMTP id 0647137F70; Mon, 25 Sep 2006 20:03:29 +0200 (CEST) Received: from dude.automatvapen.se (81-229-112-193-no21.tbcn.telia.com [81.229.112.193]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id DB6FE37E47; Mon, 25 Sep 2006 20:03:28 +0200 (CEST) From: Joel Dahl To: Alexandre Vieira In-Reply-To: <755cb9fc0609251042h163ff7f1l4e96369ed7bd0106@mail.gmail.com> References: <755cb9fc0609251042h163ff7f1l4e96369ed7bd0106@mail.gmail.com> Content-Type: text/plain Date: Mon, 25 Sep 2006 20:03:31 +0200 Message-Id: <1159207411.670.3.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Acer Aspire 1644WLMi -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2006 18:03:30 -0000 On Mon, 2006-09-25 at 18:42 +0100, Alexandre Vieira wrote: > Hello folks, > > I just went -CURRENT for the first time and everything seems fairly equal to > 6.1-STABLE. > > I have an Acer Aspire 1644WLMi. > > ACPI doesn't seem to work very well. I have many messages in dmesg > complaining about acpi. > > I had kde working but since the upgrade it's broken. I've tried to recompile > it but im having troubles compiling some ports (altough it seems application > specific,, i.e pilot-link/libmal) . I did no change to my 6-stable kernel. > > Is there anything I have to take in consideration in -CURRENT regarding > compilations? > > Also, does anyone know if an intel high definition audio driver exists in > -CURRENT? Nothing seems to grab the sound card and I cant find a suitable > module for it. http://people.freebsd.org/~ariff/HDA/ Also, read the multimedia@ archives and report bugs to ariff@. #freebsd-azalia @ freenode is a nice channel for everything related to HDA in FreeBSD -- Joel From owner-freebsd-current@FreeBSD.ORG Mon Sep 25 21:05:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C2E9E16A403; Mon, 25 Sep 2006 21:05:27 +0000 (UTC) (envelope-from freebsd.ruomad@free.fr) Received: from smtp1-g19.free.fr (smtp1-g19.free.fr [212.27.42.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12E3743D76; Mon, 25 Sep 2006 21:05:24 +0000 (GMT) (envelope-from freebsd.ruomad@free.fr) Received: from [192.168.0.100] (vln78-1-82-238-160-33.fbx.proxad.net [82.238.160.33]) by smtp1-g19.free.fr (Postfix) with ESMTP id 202AF10584; Mon, 25 Sep 2006 23:05:23 +0200 (CEST) Message-ID: <45184486.3080906@free.fr> Date: Mon, 25 Sep 2006 23:05:10 +0200 From: Bruno Damour User-Agent: Thunderbird 1.5.0.7 (X11/20060916) MIME-Version: 1.0 To: Vladimir Kushnir References: <45166CB4.000004.01220@camay.yandex.ru> <20060925014415.S1442@kushnir1.kiev.ua> In-Reply-To: <20060925014415.S1442@kushnir1.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Andrey V. Elsukov" , freebsd-usb@freebsd.org, freebsd-current@freebsd.org Subject: Re: Problems with USB on CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2006 21:05:27 -0000 Vladimir Kushnir wrote: > Hi, All! > > On Sun, 24 Sep 2006, Andrey V. Elsukov wrote: > >> Hi, All! >> >> I have notebook Maxselect Mission GT3000. >> A hardware configuration description (russian): >> http://www.maxselect.ru/catalog/models.html?id=4024&template=normal >> >> o Mobile AMD Sempron >> o NVIDIA C51MV+MCP51M >> o PCI Express nVidia Geforce Go 6100 >> o Realtek HDA >> >> I have several problems. One is with USB. >> When i attach USB Flash disk it's not work. >> >> usbd_new_device: addr=2, getting first desc failed >> uhub_explore: usb_new_device failed, error=IOERROR >> uhub1: device problem (IOERROR), disabling port 4 >> >> http://butcher.heavennet.ru/dmesg.txt >> http://butcher.heavennet.ru/pciconf.txt >> I've attached dmesg and pciconf. >> Any suggestions? >> -- >> WBR, Andrey V. Elsukov >> > > I had precisely the same problem with USB-2 flash (both old USB-1.1 > flash and digital camera - Kodak C340, uses ugen) work perfectly all > right. MB: Asus A8N (nForce4 based). The problem went away with > retrying to get device descriptor in usbd_new_device (see patch below). > I've submitted PR (usb/103167) but so far there's been no reaction at > all :-( > > Hope this helps, > Vladimir > > /* ----------- patch begins here -------------- */ > > *** dev/usb/usb_subr.c.orig Mon Sep 11 19:28:35 2006 > --- dev/usb/usb_subr.c Mon Sep 11 20:05:38 2006 > *************** > *** 1112,1118 **** > > dd = &dev->ddesc; > /* Get the first 8 bytes of the device descriptor. */ > ! err = usbd_get_desc(dev, UDESC_DEVICE, 0, USB_MAX_IPACKET, dd); > if (err) { > DPRINTFN(-1, ("usbd_new_device: addr=%d, getting first desc " > "failed\n", addr)); > --- 1112,1123 ---- > > dd = &dev->ddesc; > /* Get the first 8 bytes of the device descriptor. */ > ! for (i = 0; i < 3; i++) { > ! err = usbd_get_desc(dev, UDESC_DEVICE, 0, USB_MAX_IPACKET, dd); > ! if (!err) > ! break; > ! usbd_delay_ms(dev, USB_SET_ADDRESS_SETTLE); > ! } > if (err) { > DPRINTFN(-1, ("usbd_new_device: addr=%d, getting first desc " > "failed\n", addr)); > > /* -------------- end ----------------- */ > _______________________________________________ > 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" Well, it _WORKS_ !! After applying your patch and recompiling my kernel, I plug my usb key and it works ! umass creates /dev/da0 and I'm able to mount my disk and work... Thank you very much !! I still have an error in dmesg though, but it might be something else. This patch should be discussed and tested ASAP with other hardware. Bruno PS : see my dmesg : Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 7.0-CURRENT #4: Mon Sep 25 22:27:26 CEST 2006 root@vil1.ruomad.net:/usr/obj/usr/src/sys/VIL1 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Sempron(tm) Processor 2800+ (1607.42-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x40ff2 Stepping = 2 Features=0x78bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x19 real memory = 1039073280 (990 MB) avail memory = 1007489024 (960 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) pci0: at device 0.6 (no driver attached) pci0: at device 0.7 (no driver attached) pcib1: at device 2.0 on pci0 pci1: on pcib1 pcib2: at device 3.0 on pci0 pci2: on pcib2 pcib3: at device 4.0 on pci0 pci3: on pcib3 vgapci0: mem 0xfc000000-0xfcffffff,0xe0000000-0xefffffff,0xfb000000-0xfbffffff irq 16 at device 5.0 on pci0 pci0: at device 9.0 (no driver attached) isab0: at device 10.0 on pci0 isa0: on isab0 pci0: at device 10.1 (no driver attached) pci0: at device 10.2 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 11.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 8 ports with 8 removable, self powered ehci0: mem 0xfe02e000-0xfe02e0ff irq 22 at device 11.1 on pci0 ehci0: [GIANT-LOCKED] usb1: EHCI version 1.0 usb1: companion controller, 8 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 8 ports with 8 removable, self powered atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfd00-0xfd0f at device 13.0 on pci0 ata0: on atapci0 ata1: on atapci0 atapci1: port 0x9f0-0x9f7,0xbf0-0xbf3,0x970-0x977,0xb70-0xb73,0xf800-0xf80f mem 0xfe02d000-0xfe02dfff irq 23 at device 14.0 on pci0 ata2: on atapci1 ata3: on atapci1 atapci2: port 0x9e0-0x9e7,0xbe0-0xbe3,0x960-0x967,0xb60-0xb63,0xf300-0xf30f mem 0xfe02c000-0xfe02cfff irq 20 at device 15.0 on pci0 ata4: on atapci2 ata5: on atapci2 pcib4: at device 16.0 on pci0 pci4: on pcib4 fwohci0: mem 0xfdbff000-0xfdbff7ff,0xfdbf8000-0xfdbfbfff irq 19 at device 5.0 on pci4 fwohci0: OHCI version 1.10 (ROM=1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:11:d8:00:00:bc:4e:88 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 sbp0: on firewire0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:11:d8:bc:4e:88 fwe0: Ethernet address: 02:11:d8:bc:4e:88 fwe0: if_start running deferred for Giant fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) ndis0: mem 0xfdbfc000-0xfdbfdfff irq 17 at device 9.0 on pci4 ndis0: NDIS API version: 5.0 ndis0: Ethernet address: 00:0c:41:64:3c:2a pcm0: mem 0xfe024000-0xfe027fff irq 21 at device 16.1 on pci0 nfe0: port 0xf200-0xf207 mem 0xfe02b000-0xfe02bfff irq 22 at device 20.0 on pci0 miibus0: on nfe0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto nfe0: Ethernet address: 00:17:31:d8:c7:55 acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FAST] sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A sio1: [FAST] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] pmtimer0 on isa0 orm0: at iomem 0xd0000-0xd3fff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 ppc0: [GIANT-LOCKED] ums0: on uhub0 ums0: 3 buttons and Z dir. uhub0: device problem (SET_ADDR_FAILED), disabling port 6 Timecounter "TSC" frequency 1607419447 Hz quality 800 Timecounters tick every 1.000 msec acd0: DMA limited to UDMA33, device found non-ATA66 cable acd0: DVDR at ata1-master UDMA33 ad4: 238475MB at ata2-master SATA300 ad8: 238475MB at ata4-master SATA150 ad10: 238475MB at ata5-master SATA150 pcm0: pcm0: ar0: 238475MB status: READY ar0: disk0 READY (master) using ad10 at ata5-master ar0: disk1 READY (mirror) using ad8 at ata4-master Trying to mount root from ufs:/dev/ad4s2a plip0: [GIANT-LOCKED] fuse4bsd: version 0.3.0, FUSE ABI 7.5 umass0: on uhub1 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 967MB (1981440 512 byte sectors: 64H 32S/T 967C) From owner-freebsd-current@FreeBSD.ORG Mon Sep 25 22:55:18 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E936C16A403 for ; Mon, 25 Sep 2006 22:55:18 +0000 (UTC) (envelope-from stucchi@willystudios.com) Received: from hoover.willystudios.com (hoover.willystudios.com [89.186.67.104]) by mx1.FreeBSD.org (Postfix) with SMTP id 0945E43D49 for ; Mon, 25 Sep 2006 22:55:17 +0000 (GMT) (envelope-from stucchi@willystudios.com) Received: (qmail 78136 invoked from network); 25 Sep 2006 22:56:33 -0000 Received: from max.willystudios.com (193.25.178.163) by hoover.willystudios.com with SMTP; 25 Sep 2006 22:56:33 -0000 Received: by max.willystudios.com (Postfix, from userid 1000) id 3028EAC5; Tue, 26 Sep 2006 00:57:05 +0200 (CEST) Date: Tue, 26 Sep 2006 00:57:05 +0200 From: Massimiliano Stucchi To: annunci@gufi.org, openlabs-ml@openlabs.it, ml@milug.org, current@freebsd.org, misc@openbsd.org, current-users@netbsd.org, users@dragonflybsd.org, ml@openbeer.it, aiplist@aipnet.it Message-ID: <20060925225705.GX32178@willystudios.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD 4.10-STABLE X-URL: http://www.willystudios.com/max/ X-Organization: WillyStudios.com User-Agent: Mutt/1.5.6i Cc: Subject: EuroBSDCon registration Open X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stucchi@willystudios.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Sep 2006 22:55:19 -0000 Hi all, we finally made it, the registration for EuroBSDCon 2006 - Milan is now open to everybody. Please register as soon as possible to ensure a seat for you at the event ! go to http://www.eurobsdcon.org/register/ and complete the registration process. It is also possible to book a room for the conference hotel. We hope to meet you all in Milan ! Ciao -- Massimiliano Stucchi stucchi@eurobsdcon.org From owner-freebsd-current@FreeBSD.ORG Mon Sep 25 23:06:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3254916A40F for ; Mon, 25 Sep 2006 23:06:15 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC36F43D4C for ; Mon, 25 Sep 2006 23:06:14 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by wr-out-0506.google.com with SMTP id 71so779585wri for ; Mon, 25 Sep 2006 16:06:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=J+xt7scOCPDmyV5fJhwf/5AumpjrlrKBumzk3eTQPJFWfeZ+zS3HEg11vs8rtPbhItJFK2QgXK4xZrE36y97/kSRXlTPhVLI56E7hfwBHs02i8Oa6IXHatTr+gK+OsB/c3ncILCLenGzVswzn4dcWMr7FNYTGpPuDGYsmTAnOxU= Received: by 10.90.63.16 with SMTP id l16mr10633aga; Mon, 25 Sep 2006 16:06:12 -0700 (PDT) Received: by 10.90.70.6 with HTTP; Mon, 25 Sep 2006 16:06:11 -0700 (PDT) Message-ID: <7579f7fb0609251606t2913858boaa2e6d71914d0fa6@mail.gmail.com> Date: Mon, 25 Sep 2006 16:06:11 -0700 From: "Matthew Jacob" To: "YONETANI Tomokazu" In-Reply-To: <20060925111048.GD1080@les.ath.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1157154024.835.6.camel@atomizer.opensourcebeef.net> <20060924071601.GA1080@les.ath.cx> <20060924205903.GY1045@tigerfish2.my.domain> <20060925111048.GD1080@les.ath.cx> Cc: freebsd-current@freebsd.org Subject: Re: LSI 1030 mpt doesn't work if I build a new kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 25 Sep 2006 23:06:15 -0000 Um- I'm still trying to find a real error here. The bootverbose simply lists selection failures for devices that don't exist. Other than that, I cannot see what you are claiming is an error. On 9/25/06, YONETANI Tomokazu wrote: > On Sun, Sep 24, 2006 at 03:59:03PM -0500, Bruce Burden wrote: > > On Sun, Sep 24, 2006 at 04:16:01PM +0900, YONETANI Tomokazu wrote: > > > > > > Recently I tried installing FreeBSD 5.4-RELEASE on an IBM X335 in my > > > office and tried to upgrade to 6.2-PRERELEASE, and found that although > > > it doesn't hang or panic during boot, running I/O intensive applications > > > (including buildworld) ends up in an I/O error, and eventually panicked and > > > rebooted. > > > > > This would be best on -STABLE, which the 6x thread is. Anyway, > > But I found that the snapshot from September 5 still has the similar > issue, so I'd imagine that the driver in -CURRENT still has the problem, > though I'm speaking without knowing how much changes have been made since > the last MFC. I need to set up a machine which can build current -CURRENT > to be sure. > > > I have: > [snip] > > FreeBSD tigerfish2.my.domain 6.1-STABLE FreeBSD 6.1-STABLE #6: Sun Aug 27 11:03:43 CDT 2006 > > Thanks for the suggestion, I put mine at > http://les.ath.cx/FreeBSD/mpt/ > > > and have not had any problems with the mpt device. The controller is > > built into the Tyan S2895/Thunder K8WE board. > > > > I am not using the Seagate drive - it will be used to hold the > > AMD64 installation when I get around to doing that, while the IBM > > drive will continue to hold the i386 install if I need to switch > > back. The RAID holds user data, and is not an issue when performing > > kernel builds. > > > > Have you tried to install the 6.1 release from CD/DVD? > > Not yet, but I doubt it'll make it through to the end because of the > I/O error issue. > > Cheers. > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 00:29:28 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECC8916A417 for ; Tue, 26 Sep 2006 00:29:27 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87B8743D83 for ; Tue, 26 Sep 2006 00:29:09 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so2673997pye for ; Mon, 25 Sep 2006 17:29:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:subject:message-id:reply-to:mime-version:content-type:content-disposition:user-agent; b=SqUOLXqSoNn/xaOclJWKKBaIWQsj9pcZF55ZrM7Grbyxunk82RZ4daj7v5os1/ckgN4RiPFkhN7dePgAyeEMbayurN5T3oJ6J+F1tB574RulfDgsMZr66CcHBFvXe7PJ+ApAywPRMcjBNPjmP1ptPZ+2ioA4gDYJPEGbL/nFJtE= Received: by 10.35.54.1 with SMTP id g1mr235763pyk; Mon, 25 Sep 2006 17:29:08 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 12sm3064656nzn.2006.09.25.17.29.07; Mon, 25 Sep 2006 17:29:08 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k8Q0THQO006519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 26 Sep 2006 09:29:17 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k8Q0THTk006518 for freebsd-current@FreeBSD.org; Tue, 26 Sep 2006 09:29:17 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 26 Sep 2006 09:29:16 +0900 From: Pyun YongHyeon To: freebsd-current@FreeBSD.org Message-ID: <20060926002916.GA5975@cdnetworks.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2006 00:29:28 -0000 Hi, I've written a driver for Marvell/SysKonnect Yukon II Gigabit Ethernet controller. It supports the following GigE adapters. o SysKonnect SK-9Sxx Yukon Gigabit Ethernet o SysKonnect SK-9Exx Yukon Gigabit Ethernet o Marvell Yukon 88E8021CU Gigabit Ethernet o Marvell Yukon 88E8021 SX/LX Gigabit Ethernet o Marvell Yukon 88E8022CU Gigabit Ethernet o Marvell Yukon 88E8022 SX/LX Gigabit Ethernet o Marvell Yukon 88E8061CU Gigabit Ethernet o Marvell Yukon 88E8061 SX/LX Gigabit Ethernet o Marvell Yukon 88E8062CU Gigabit Ethernet o Marvell Yukon 88E8062 SX/LX Gigabit Ethernet o Marvell Yukon 88E8035 Gigabit Ethernet o Marvell Yukon 88E8036 Gigabit Ethernet o Marvell Yukon 88E8038 Gigabit Ethernet o Marvell Yukon 88E8050 Gigabit Ethernet o Marvell Yukon 88E8052 Gigabit Ethernet o Marvell Yukon 88E8053 Gigabit Ethernet o Marvell Yukon 88E8055 Gigabit Ethernet o D-Link 560T Yukon Gigabit Ethernet Due to lack of documentation, this driver is based on the code from sk(4) and Marvell's myk(4) driver for FreeBSD 5.x/6.x. I've also adopted the OpenBSD interface name, msk(4) in order to reduce naming differences between BSDs. After many trial and errors I now managed to work it on i386 box. At the moment IP/TCP/UDP checksum offload for transmit and IP checksum offload for receive is supported. Hardware VLAN tag insertion/stripping is also supported. JUMBO frame support code is present but was not tested at all and it may have bugs. The driver was tested on on-board 88E8053 PCI Express NIC and I'd like to hear success/failure reports on other architectures such as amd64. I don't have adapters that have TBI transceivers or dual MAC configuration so I'd also like to know whether it works on those adapters too. ** Be ware, this driver is not for production use. It may even damage your hardware. ** You can get the latest msk(4) driver from the following URL. http://people.freebsd.org/~yongari/msk/msk.HEAD.diff You should add "device msk" in your kernel configuration file and rebuild/reboot or build kernel module if_msk.ko. You need latest CURRENT to apply this diff. TODO: Automatic crossover support(e1000phy(4)). Yukon FE(Fast Ethernet) support(e1000phy(4)). Performance tuning. Rx TCP/UDP checksum offload. TSO support. 64bit DMA(DAC) support. Thanks. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 01:35:22 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 762D516A492; Tue, 26 Sep 2006 01:35:22 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1AC343D58; Tue, 26 Sep 2006 01:35:21 +0000 (GMT) (envelope-from ota@j.email.ne.jp) Received: from p600-freebsd.advok.com (pool-151-197-182-152.phil.east.verizon.net [151.197.182.152]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 2FA4616E7A; Tue, 26 Sep 2006 10:35:18 +0900 (JST) Date: Mon, 25 Sep 2006 21:35:22 -0500 From: Yoshihiro Ota To: Ivan Voras Message-Id: <20060925213522.4c9eacb7.ota@j.email.ne.jp> In-Reply-To: <44EF12F6.3000806@fer.hr> References: <44EF12F6.3000806@fer.hr> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: geom@freebsd.org, current@freebsd.org Subject: Re: Announcing: gvirstor X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 01:35:22 -0000 Hi. I gave a shot at this but it didn't work. I downloaded gvirstor-beta3.tbz. I have a coupe of questions. 1. Is this -current only? I tried on 6.1 and 6-stable(currently 6.2-RERELEASE) 2. Have you made any changes since you posted the orginal e-mail? 3. If so, how do you check out fro "Perforce (under the name \\gvirstor)"? Here is some output I got afer # make ; make so Thanks, Hiro # make install install -o root -g wheel -m 555 geom_virstor.ko /boot/kernel kldxref /boot/kernel # ./gvirstor label -v -s 500 test md2 md3 Unknown command: label usage: gvirstor help gvirstor list [name ...] gvirstor status [-s] [name ...] gvirstor load [-v] gvirstor unload [-v]` # grep label *c g_virstor.c:/* Declare malloc(9) label */ geom_virstor.c: {"label", G_FLAG_VERBOSE | G_FLAG_LOADKLD, virstor_main, geom_virstor.c:static void virstor_label(struct gctl_req *req); geom_virstor.c: if (strcmp(name, "label") == 0) geom_virstor.c: virstor_label(req); geom_virstor.c:virstor_label(struct gctl_req *req) On Fri, 25 Aug 2006 17:10:46 +0200 Ivan Voras wrote: > I'm glad to announce availability of GEOM virtual storage class, > (currently) named "gvirstor". The purpose of this class is to enable > creation of huge virtual providers (for example: many terabytes) backed > by limited physical storage, with the expectation that more physical > storage will be added later. This is a part of a logical volume manager, > and provides functionality up to now not available as a native GEOM > class. > > gvirstor is currently available either from Perforce (under the name > \\gvirstor) or at http://wiki.freebsd.org/gvirstor in a convenient tbz > archive with appropriate Makefile. Please read the README file packaged > in the archive for instructions on how to build and run gvirstor. From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 02:17:31 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 258EA16A501; Tue, 26 Sep 2006 02:17:31 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAAE843D58; Tue, 26 Sep 2006 02:17:30 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (40k502h2yaiwryjm@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k8Q2HU4C006489; Mon, 25 Sep 2006 19:17:30 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k8Q2HUve006488; Mon, 25 Sep 2006 19:17:30 -0700 (PDT) (envelope-from jmg) Date: Mon, 25 Sep 2006 19:17:29 -0700 From: John-Mark Gurney To: current@FreeBSD.org, net@FreeBSD.org, Andre Oppermann , mohans@FreeBSD.org Message-ID: <20060926021729.GD80527@funkthat.com> Mail-Followup-To: current@FreeBSD.org, net@FreeBSD.org, Andre Oppermann , mohans@FreeBSD.org References: <20060925095745.GA80527@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060925095745.GA80527@funkthat.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: Subject: Re: odd TCP rtt/retransmit timeout issue... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2006 02:17:31 -0000 John-Mark Gurney wrote this message on Mon, Sep 25, 2006 at 02:57 -0700: > Anyone want to track down why we are getting such large values in > there? I'll try to back track farther to see how old this issue is.. Managed to track it down: jmg 2006-09-26 01:21:47 UTC FreeBSD src repository Modified files: sys/netinet tcp_input.c Log: fix calculating to_tsecr... This prevents the rtt calculations from going all wonky... Revision Changes Path 1.309 +1 -1 src/sys/netinet/tcp_input.c ~12 days old for those who need to figure out if they need to upgrade or not... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 04:02:02 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4871E16A403 for ; Tue, 26 Sep 2006 04:02:02 +0000 (UTC) (envelope-from qhwt+fbsd@les.ath.cx) Received: from les.ath.cx (15.61.205.61.west.global.alpha-net.ne.jp [61.205.61.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE24043D49 for ; Tue, 26 Sep 2006 04:02:01 +0000 (GMT) (envelope-from qhwt+fbsd@les.ath.cx) Received: by les.ath.cx (Postfix, from userid 1000) id 0945986618; Tue, 26 Sep 2006 13:01:59 +0900 (JST) Date: Tue, 26 Sep 2006 13:01:59 +0900 From: YONETANI Tomokazu To: freebsd-current@freebsd.org Message-ID: <20060926040159.GE1080@les.ath.cx> References: <1157154024.835.6.camel@atomizer.opensourcebeef.net> <20060924071601.GA1080@les.ath.cx> <20060924205903.GY1045@tigerfish2.my.domain> <20060925111048.GD1080@les.ath.cx> <7579f7fb0609251606t2913858boaa2e6d71914d0fa6@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7579f7fb0609251606t2913858boaa2e6d71914d0fa6@mail.gmail.com> User-Agent: Mutt/1.5.11 Subject: Re: LSI 1030 mpt doesn't work if I build a new kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 04:02:02 -0000 On Mon, Sep 25, 2006 at 04:06:11PM -0700, Matthew Jacob wrote: > Um- I'm still trying to find a real error here. The bootverbose simply > lists selection failures for devices that don't exist. Other than > that, I cannot see what you are claiming is an error. No, they don't contain error message, they're just there to hopefully give you hints about our hardware (and I couldn't find a way to include the real error message in the dmesg output without hitting the panic at that time :). The real visible problems are: - random I/O errors during disk activity; buildworld almost immediately terminates because of the error. sometimes it leads to a panic in softupdates code. - error messages to the console: (da0:mpt0:0:0:0): CAM Status 0x34 (da0:mpt0:0:0:0): Retrying Command (da0:mpt0:0:0:0): CAM Status 0x34 (da0:mpt0:0:0:0): Retrying Command (da0:mpt0:0:0:0): error 5 (da0:mpt0:0:0:0): Retries Exhausted (da0:mpt0:0:0:0): error 5 (da0:mpt0:0:0:0): Retries Exhausted (da0:mpt0:0:0:0): error 5 If I raise dev.mpt.0.debug from 4(the default) to a higher value than 5, the above errors stop popping up, although it spams the message buffer. Changing it to 5 doesn't seem to change the amount of the message the driver spews. Regards. > On 9/25/06, YONETANI Tomokazu wrote: > >On Sun, Sep 24, 2006 at 03:59:03PM -0500, Bruce Burden wrote: > >> On Sun, Sep 24, 2006 at 04:16:01PM +0900, YONETANI Tomokazu wrote: > >> > > >> > Recently I tried installing FreeBSD 5.4-RELEASE on an IBM X335 in my > >> > office and tried to upgrade to 6.2-PRERELEASE, and found that although > >> > it doesn't hang or panic during boot, running I/O intensive > >applications > >> > (including buildworld) ends up in an I/O error, and eventually > >panicked and > >> > rebooted. > >> > > >> This would be best on -STABLE, which the 6x thread is. Anyway, > > > >But I found that the snapshot from September 5 still has the similar > >issue, so I'd imagine that the driver in -CURRENT still has the problem, > >though I'm speaking without knowing how much changes have been made since > >the last MFC. I need to set up a machine which can build current -CURRENT > >to be sure. > > > >> I have: > >[snip] > >> FreeBSD tigerfish2.my.domain 6.1-STABLE FreeBSD 6.1-STABLE #6: Sun Aug > >27 11:03:43 CDT 2006 > > > >Thanks for the suggestion, I put mine at > > http://les.ath.cx/FreeBSD/mpt/ > > > >> and have not had any problems with the mpt device. The controller is > >> built into the Tyan S2895/Thunder K8WE board. > >> > >> I am not using the Seagate drive - it will be used to hold the > >> AMD64 installation when I get around to doing that, while the IBM > >> drive will continue to hold the i386 install if I need to switch > >> back. The RAID holds user data, and is not an issue when performing > >> kernel builds. > >> > >> Have you tried to install the 6.1 release from CD/DVD? > > > >Not yet, but I doubt it'll make it through to the end because of the > >I/O error issue. > > > >Cheers. > >_______________________________________________ > >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" > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 06:38:39 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 74E3816A407 for ; Tue, 26 Sep 2006 06:38:39 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from hetzner.co.za (office.cpt2.host-h.net [196.7.147.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF63943D77 for ; Tue, 26 Sep 2006 06:38:38 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GS6aP-0007pm-Fy; Tue, 26 Sep 2006 08:38:33 +0200 To: Randall Stewart From: Ian FREISLICH In-Reply-To: Message from Randall Stewart of "Fri, 22 Sep 2006 13:54:26 -0400." <45142352.2060600@cisco.com> X-Attribution: BOFH Date: Tue, 26 Sep 2006 08:38:33 +0200 Message-Id: Cc: freebsd-current@freebsd.org Subject: Re: Anyone play with divert sockets lately? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 06:38:39 -0000 Randall Stewart wrote: > Hi all: > > Due to something I need to do at I had to bring > up a couple of daemon's that use DIVERT sockets. > So I grabbed my two test machines.. one runs > 6.1 the other 7.0... > > I had not updated in a while... (the 7.0 machine). > So anyway, I got everything configured.. started > my router with the proper VRF's.. setup the > tunnels ... > > the 6.1 machine came up fine.. > > The 7.0 could not write into the tunnel... it > is sending to addr.sin_addr.s_addr = 0 and getting > error EACCESS back.. > > So I cvsup to current as of today.. rebuild.. > > and I get a bunch of: > > error's from the divert code.. and then a > crash in kern_exec/kern_proc.c I'm using divert sockets extensively for some tunnel/vpn software I wrote _way_ back. It's running fine on -CURRENT (Tue Sep 19 08:33:01 SAST 2006), 4.11-STABLE, and just about everything in between. I've not had to change the code substantially to make it work on newer BSDs. All our VoIP goes through this piece of code: memset(&from, '\0', sizeof from); from.sin_addr.s_addr = INADDR_ANY; from.sin_port = config.tuns[config.tun].fw_rule; while (tot + ntohs(hdr->length) <= (p - buf + in)) { out = sendto(config.tuns[config.tun].div_fd, buf + tot, ntohs(hdr->length), 0, (struct sockaddr *)&from, sizeof(addr)); ... So, I'm not sure where you're going wrong. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 07:04:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97D1E16A47B for ; Tue, 26 Sep 2006 07:04:22 +0000 (UTC) (envelope-from ari@suutari.iki.fi) Received: from espresso2.syncrontech.com (sync-old.syncrontech.com [213.28.98.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id C037D43D5E for ; Tue, 26 Sep 2006 07:04:18 +0000 (GMT) (envelope-from ari@suutari.iki.fi) Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.57]) by espresso2.syncrontech.com (8.13.1/8.13.1) with ESMTP id k8Q74GWJ070522 for ; Tue, 26 Sep 2006 10:04:16 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Received: from [127.0.0.1] (coffee.syncrontech.com [192.168.5.102]) by guinness.syncrontech.com (8.13.4/8.13.4) with ESMTP id k8Q74EKo002429 for ; Tue, 26 Sep 2006 10:04:15 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Message-ID: <4518D0EA.9070709@suutari.iki.fi> Date: Tue, 26 Sep 2006 10:04:10 +0300 From: Ari Suutari User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Will Xen 3.0 support (at least domU) be available ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 07:04:22 -0000 Hi, I have been playing with Xen 3.0 lately (with NetBSD & debian), but as FreeBSD user, I would like to use FreeBSD with Xen. I found web page which shows some results from google SoC project, there are two DomU kernels downloadable from there. Currently, I would be perfectly happy with just DomU support, but the the Xen changes are not available in FreeBSD cvs yet, I think ? This would mean that I'm stuck with the versions provided on SoC page. It would be nice if someone could give more information about future of FreeBSD's xen, are there plans to put the code into some future version. Ari S. From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 08:01:49 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8723D16A40F; Tue, 26 Sep 2006 08:01:49 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from lara.cc.fer.hr (lara.cc.fer.hr [161.53.72.113]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC5C343D45; Tue, 26 Sep 2006 08:01:48 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from [IPv6:::1] (localhost.cc.fer.hr [IPv6:::1]) by lara.cc.fer.hr (8.13.8/8.13.4) with ESMTP id k8Q81Nqj092322; Tue, 26 Sep 2006 10:01:24 +0200 (CEST) (envelope-from ivoras@fer.hr) Message-ID: <4518DE53.9070101@fer.hr> Date: Tue, 26 Sep 2006 10:01:23 +0200 From: Ivan Voras User-Agent: Thunderbird 1.5.0.4 (X11/20060625) MIME-Version: 1.0 To: Yoshihiro Ota References: <44EF12F6.3000806@fer.hr> <20060925213522.4c9eacb7.ota@j.email.ne.jp> In-Reply-To: <20060925213522.4c9eacb7.ota@j.email.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: geom@freebsd.org, current@freebsd.org Subject: Re: Announcing: gvirstor X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 08:01:49 -0000 Ota wrote: > 1. Is this -current only? > I tried on 6.1 and 6-stable(currently 6.2-RERELEASE) No, it's for RELENG_6. I'm interested in people testing it before it's committed to -current! > 2. Have you made any changes since you posted the orginal e-mail? Not significantly. > Here is some output I got afer # make ; make so > install -o root -g wheel -m 555 geom_virstor.ko /boot/kernel > kldxref /boot/kernel You may need to 'kldload geom_virstor'. > # ./gvirstor label -v -s 500 test md2 md3 > Unknown command: label This means the .so file has not been found. I see now what's going on: I've forgot to add a step to the README: make a symlink of geom_virstor.so in your /lib/geom directory: /lib/geom# ln -s /path_to_gvirstor/geom_virstor.so Also, take care to remove CFLAGS line from Makefile if you don't have a kernel with INVARIANTS and WITNESS. I hope to hear about your experience with it. From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 08:12:38 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 70E2B16A40F for ; Tue, 26 Sep 2006 08:12:38 +0000 (UTC) (envelope-from ari@suutari.iki.fi) Received: from espresso2.syncrontech.com (sync-old.syncrontech.com [213.28.98.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 08A5C43D46 for ; Tue, 26 Sep 2006 08:12:34 +0000 (GMT) (envelope-from ari@suutari.iki.fi) Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.57]) by espresso2.syncrontech.com (8.13.1/8.13.1) with ESMTP id k8Q8C7kP070771; Tue, 26 Sep 2006 11:12:08 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Received: from [127.0.0.1] (coffee.syncrontech.com [192.168.5.102]) by guinness.syncrontech.com (8.13.4/8.13.4) with ESMTP id k8Q8C5m1003897; Tue, 26 Sep 2006 11:12:07 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Message-ID: <4518E0D1.2030903@suutari.iki.fi> Date: Tue, 26 Sep 2006 11:12:01 +0300 From: Ari Suutari User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Yuan, Jue" References: <4518D321.8050604@delphij.net> <51584f840609260101m7dc0a1e1iffaccc8621df3783@mail.gmail.com> In-Reply-To: <51584f840609260101m7dc0a1e1iffaccc8621df3783@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, LI Xin Subject: Re: [Fwd: Will Xen 3.0 support (at least domU) be available ?] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 08:12:38 -0000 Hi, Yuan, Jue wrote: > Hi there, > > I am the Summer of Code student who is responsible for porting Xen to > FreeBSD. Currently we have got two domU kernels, one for installation, > the other for running. And the dom0 support is on its way :-) Yes, I tried these kernels under NetBSD-current running as dom0, using Xen 3.0.2-2. I couldn't get freebsd-XENU_INSTALL kernel to boot, it crashes like this: (XEN) domain_crash_sync called from entry.S (ff149655) (XEN) Domain 16 (vcpu#0) crashed on cpu#0: (XEN) ----[ Xen-3.0.2-2 Not tainted ]---- (XEN) CPU: 0 (XEN) EIP: e019:[] (XEN) EFLAGS: 00000206 CONTEXT: guest (XEN) eax: 00000000 ebx: 00000000 ecx: 00100000 edx: c0759000 (XEN) esi: 00000003 edi: c0800000 ebp: c075fff4 esp: c075ff5c (XEN) cr0: 8005003b cr3: 06763000 (XEN) ds: e021 es: e021 fs: e021 gs: e021 ss: e021 cs: e019 (XEN) Guest stack trace from esp=c075ff5c: (XEN) 00000002 c01f8d77 0001e019 00010006 00000000 c0205923 c0766000 0049a000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 c0766000 00000766 00000000 00000000 00000000 00000000 00000000 (XEN) 00000000 00000000 00000000 00000000 c0759000 00000000 00000000 c00314c6 (XEN) c0759000 The freebsd-XENU kernel boots, but I cannot mount root: Using config file "freebsd1". Started domain freebsd1 WARNING: loader(8) metadata is missing! KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 7.0-CURRENT #2: Sat Aug 26 00:02:36 CST 2006 YuanJue@www.yuanjue.org:/usr/home/YuanJue/Develop/SVN_work/xen3/sys/i386-xen/compile/XENCONF-STD WARNING: DIAGNOSTIC option enabled, expect reduced performance. Xen reported: 863.864 MHz processor. Timecounter "ixen" frequency 1000000000 Hz quality 0 CPU: Intel Pentium III (863.86-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x68a Stepping = 10 Features=0x383f9ff real memory = 63266816 (60 MB) avail memory = 57602048 (54 MB) xc0: on motherboard cpu0 on motherboard Timecounters tick every 10.000 msec [XEN] Initialising virtual ethernet driver. xn0: Ethernet address: aa:00:00:50:03:e1 [XEN] Trying to mount root from ufs:/dev/xbd769a Mount point / had 1 dangling refs Manual root filesystem specification: : Mount using filesystem eg. ufs:da0s1a ? List valid disk boot devices Abort manual input The root filesystem is file based and has been created on another FreeBSD machine, so it should be ok. What is that number "769" in xbd device ? Is it same for all installations ? If there are any suggestions I could try please let me know. Ari S. > > > On 9/26/06, LI Xin wrote: >> FYI, >> >> -- >> Xin LI http://www.delphij.net/ >> FreeBSD - The Power to Serve! >> >> >> >> ---------- Forwarded message ---------- >> From: Ari Suutari >> To: freebsd-current@freebsd.org >> Date: Tue, 26 Sep 2006 10:04:10 +0300 >> Subject: Will Xen 3.0 support (at least domU) be available ? >> Hi, >> >> I have been playing with Xen 3.0 lately (with NetBSD & debian), but >> as FreeBSD user, I would like to use FreeBSD with Xen. I found >> web page which shows some results from google SoC project, there are >> two DomU kernels downloadable from there. >> >> Currently, I would be perfectly happy with just DomU support, but >> the the Xen changes are not available in FreeBSD cvs yet, I think ? >> This would mean that I'm stuck with the versions provided on SoC page. >> >> It would be nice if someone could give more information about >> future of FreeBSD's xen, are there plans to put the code into >> some future version. >> > From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 08:28:07 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BEEF916A417 for ; Tue, 26 Sep 2006 08:28:07 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9607C43D67 for ; Tue, 26 Sep 2006 08:28:01 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 44270 invoked from network); 26 Sep 2006 08:29:52 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 26 Sep 2006 08:29:52 -0000 Message-ID: <4518E491.5060008@freebsd.org> Date: Tue, 26 Sep 2006 10:28:01 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: sivakumar.subramani@wipro.com References: <956E7FA2615F3B4595FC5F22870A72210C56FF@blr-m3-msg.wipro.com> In-Reply-To: <956E7FA2615F3B4595FC5F22870A72210C56FF@blr-m3-msg.wipro.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, jfvogel@gmail.com Subject: Re: TSO patch for current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2006 08:28:07 -0000 sivakumar.subramani@wipro.com wrote: > Is the TSO patch is checked in to the current? Yes, but a different one. -- Andre > Thanks, > ~Siva > > -----Original Message----- > From: owner-freebsd-net@freebsd.org > [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Jack Vogel > Sent: Saturday, September 02, 2006 4:21 AM > To: freebsd-net; freebsd-current > Subject: RFC: TSO patch for current > > This is a patch for the stack and the em driver to enable TSO > on CURRENT. Previously I had problems getting it to work, but > this is functional. > > I should note that CURRENT is being a pain right now, when > I comment out em in the config the kernel panics coming up, > so I had to substitute this code into the tree. Rather bizarre :) > > I have this functionality running on a 6.1 based system, and > our test group is already testing against that driver, so far > things are looking good. > > I have designed it so the driver can continue to be built > without support. There is also a sysctl in the stack code > so you can set net.inet.tcp.tso_enable on or off and > compare. > > I know there may be some refinements to add in, but I > would like to get this into CURRENT as a start. > > Comments? > > Jack > > > The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. > > > WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. > > > www.wipro.com > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 08:38:36 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1347516A492 for ; Tue, 26 Sep 2006 08:38:36 +0000 (UTC) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 295B743D62 for ; Tue, 26 Sep 2006 08:38:31 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1GS8SS-0000ED-00; Tue, 26 Sep 2006 10:38:28 +0200 Date: Tue, 26 Sep 2006 10:38:28 +0200 To: Alexandre Vieira Message-ID: <20060926083828.GZ4945@poupinou.org> References: <755cb9fc0609251042h163ff7f1l4e96369ed7bd0106@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <755cb9fc0609251042h163ff7f1l4e96369ed7bd0106@mail.gmail.com> User-Agent: Mutt/1.5.9i From: Bruno Ducrot Cc: freebsd-current@freebsd.org Subject: Re: Acer Aspire 1644WLMi -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2006 08:38:36 -0000 On Mon, Sep 25, 2006 at 06:42:43PM +0100, Alexandre Vieira wrote: > Hello folks, > > I just went -CURRENT for the first time and everything seems fairly equal to > 6.1-STABLE. > > I have an Acer Aspire 1644WLMi. > > ACPI doesn't seem to work very well. I have many messages in dmesg > complaining about acpi. Could you please run acpidump -t -d > Acer_Aspire_1644WLMi.asl and give a link to this file somewhere on the web? This problem is well known, and I think FreeBSD will support your laptop in the near future. In the meantime we can workaround this problem by modifiying a little the AML of the DSDT. > I had kde working but since the upgrade it's broken. I've tried to recompile > it but im having troubles compiling some ports (altough it seems application > specific,, i.e pilot-link/libmal) . I did no change to my 6-stable kernel. > > Is there anything I have to take in consideration in -CURRENT regarding > compilations? > > Also, does anyone know if an intel high definition audio driver exists in > -CURRENT? Nothing seems to grab the sound card and I cant find a suitable > module for it. I've heard there is one in developpment, but I let other to answer since I don't know so much. > > > I'm sorry for any eventual dumminess coming out of my fingers and thank you > very much for your itme. > > Regards, > -- > Alexandre Vieira - nullpt@gmail.com -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 08:48:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E03B816A40F for ; Tue, 26 Sep 2006 08:48:59 +0000 (UTC) (envelope-from ari@suutari.iki.fi) Received: from espresso2.syncrontech.com (sync-old.syncrontech.com [213.28.98.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A22443D53 for ; Tue, 26 Sep 2006 08:48:58 +0000 (GMT) (envelope-from ari@suutari.iki.fi) Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.57]) by espresso2.syncrontech.com (8.13.1/8.13.1) with ESMTP id k8Q8mvhC070875; Tue, 26 Sep 2006 11:48:57 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Received: from [127.0.0.1] (coffee.syncrontech.com [192.168.5.102]) by guinness.syncrontech.com (8.13.4/8.13.4) with ESMTP id k8Q8muK5004382; Tue, 26 Sep 2006 11:48:57 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Message-ID: <4518E973.6010004@suutari.iki.fi> Date: Tue, 26 Sep 2006 11:48:51 +0300 From: Ari Suutari User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Yuan, Jue" References: <4518D321.8050604@delphij.net> <51584f840609260101m7dc0a1e1iffaccc8621df3783@mail.gmail.com> <4518E0D1.2030903@suutari.iki.fi> <51584f840609260134v1c2dbcd4y23ab0830a198c43d@mail.gmail.com> In-Reply-To: <51584f840609260134v1c2dbcd4y23ab0830a198c43d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kip Macy , freebsd-current@freebsd.org Subject: Re: [Fwd: Will Xen 3.0 support (at least domU) be available ?] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 08:49:00 -0000 Hi, Yuan, Jue wrote: > > I tested freebsd-XENU_INSTALL under kubuntu 6.0.6 as dom0. don't know > why this happens. I will check this issue later :-) OK, I can consider running debian as dom0 if that is needed (but I would like to stick in the bsd family :-) > >> Trying to mount root from ufs:/dev/xbd769a >> Mount point / had 1 dangling refs >> >> >> The root filesystem is file based and has been created on another >> FreeBSD machine, so it should be ok. What is that number "769" in >> xbd device ? Is it same for all installations ? >> > > the magic number here is due to the major and minor device number of > Linux. maybe this is not the case while you are using NetBSD. Anyway, > the first thing you should check is the fstab file in your file-backed > image. It is not looking at fstab yet, this is the mount specified by extra += ",vfs.root.mountfrom=ufs:/dev/xbd.... in xen config file. I tried guessing the number, but had no luck :-( > More details could be found at > http://www.yuanjue.net/xen/howto.html Yes, I have read this. Actually, after reading this I started experimenting with Xen + FreeBSD again. Nice work anyway, I'm sure things will eventually start working... Ari S. From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 08:57:38 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E76616A412 for ; Tue, 26 Sep 2006 08:57:38 +0000 (UTC) (envelope-from ari@suutari.iki.fi) Received: from espresso2.syncrontech.com (sync-old.syncrontech.com [213.28.98.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id A698B43D55 for ; Tue, 26 Sep 2006 08:57:37 +0000 (GMT) (envelope-from ari@suutari.iki.fi) Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.57]) by espresso2.syncrontech.com (8.13.1/8.13.1) with ESMTP id k8Q8vaj9070905; Tue, 26 Sep 2006 11:57:36 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Received: from [127.0.0.1] (coffee.syncrontech.com [192.168.5.102]) by guinness.syncrontech.com (8.13.4/8.13.4) with ESMTP id k8Q8vZol004485; Tue, 26 Sep 2006 11:57:36 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Message-ID: <4518EB7B.5010802@suutari.iki.fi> Date: Tue, 26 Sep 2006 11:57:31 +0300 From: Ari Suutari User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Yuan, Jue" References: <4518D321.8050604@delphij.net> <51584f840609260101m7dc0a1e1iffaccc8621df3783@mail.gmail.com> <4518E0D1.2030903@suutari.iki.fi> <51584f840609260134v1c2dbcd4y23ab0830a198c43d@mail.gmail.com> <4518E973.6010004@suutari.iki.fi> <51584f840609260153k6ec100cdhebdaad111666f46c@mail.gmail.com> In-Reply-To: <51584f840609260153k6ec100cdhebdaad111666f46c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kip Macy , freebsd-current@freebsd.org Subject: Re: [Fwd: Will Xen 3.0 support (at least domU) be available ?] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 08:57:38 -0000 Hi, Yuan, Jue wrote: >> It is not looking at fstab yet, this is the mount specified >> by extra += ",vfs.root.mountfrom=ufs:/dev/xbd.... in xen >> config file. >> >> I tried guessing the number, but had no luck :-( >> > the "vfs.root.mountfrom=ufs:/dev/xbd769a" thing must be matched with > what's in fstab of your image file in order to get it working :-) > Really ? Is this Xen stuff then different from FreeBSD usually works ? I thought that since /etc/fstab is on root file system the kernel (or nothing else) has no access to it before root is actually mounted (I thought that the vfs.root.mountfrom parameter is just for that). But ok, I'll update the fstab to say "/dev/xbd769a /". Ari S. From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 09:34:07 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3558716A417 for ; Tue, 26 Sep 2006 09:34:07 +0000 (UTC) (envelope-from mb@imp.ch) Received: from pop.imp.ch (mx2.imp.ch [157.161.9.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id A66CC43D76 for ; Tue, 26 Sep 2006 09:34:06 +0000 (GMT) (envelope-from mb@imp.ch) Received: from godot.imp.ch (godot.imp.ch [157.161.4.8]) by pop.imp.ch (8.13.8/8.13.8/Submit_imp) with ESMTP id k8Q9XxuU057584 for ; Tue, 26 Sep 2006 11:34:04 +0200 (CEST) (envelope-from mb@imp.ch) Date: Tue, 26 Sep 2006 11:33:59 +0200 (CEST) From: Martin Blapp To: current@freebsd.org Message-ID: <20060926111452.J91466@godot.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.57 on 157.161.9.65 Cc: Subject: What do you think ?: How should pseundo terminals behave ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 09:34:07 -0000 ... if there is no slave and master anymore, both sides are closed (for example after we did type exit in our term) and we open a slave and write something to the closed pty ? What we currently do: If we have no slave and master ttypX ttytX anymore and we try to write to the ttypX like: echo "BLUBBER" > /dev/ttypX We get currently blocked in ptsopen(). That's ok so far. But after we ssh into the box again, THE SAME ! tty gets opened too, leading to a tty livelock for 5 minutes. Sometimes we gets then EOPNOTSUPP when the writer gets aborted, sometimes we get two ptsclose(). After we exit this pty the refcounts are off by one, we make one ttyrel() too much so the tty structure gets completly freed in ttyrel() and the next ptsopen/ptcopen panics our box this is FreeBSD6 behaviour. With my fixes CURRENT doesn not panic anymore, but it leaks ptys. So how should ptys behave ? 1.) Block until the tty is really opened again and there is a master available again. Then write to the freshly opened pty. (not easy to do) 2.) Block forever since the tty will not be reopened anymore since we leak ptys. 3.) Detect that there is no master around anymore and return ENXIO: # echo "BLUBBER" > /dev/ttypX # /dev/ttypX: Device not configured (easy to do, i've got a fix. IMHO this is the best thing to do. This allows fast error recovery in case the master has been gone away) 4.) Keep the current behaviour, leak terminals or panic. (the simplest thing to do. Let's keep the bugs) Please vote for any of those choice. Thank you for your participation. Martin Martin Blapp, ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 09:34:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C17E16A51B for ; Tue, 26 Sep 2006 09:34:22 +0000 (UTC) (envelope-from ari@suutari.iki.fi) Received: from espresso2.syncrontech.com (sync-old.syncrontech.com [213.28.98.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id E882043D6D for ; Tue, 26 Sep 2006 09:34:14 +0000 (GMT) (envelope-from ari@suutari.iki.fi) Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.57]) by espresso2.syncrontech.com (8.13.1/8.13.1) with ESMTP id k8Q9YDuf071049; Tue, 26 Sep 2006 12:34:13 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Received: from [127.0.0.1] (coffee.syncrontech.com [192.168.5.102]) by guinness.syncrontech.com (8.13.4/8.13.4) with ESMTP id k8Q9YBY8005109; Tue, 26 Sep 2006 12:34:13 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Message-ID: <4518F40F.3050703@suutari.iki.fi> Date: Tue, 26 Sep 2006 12:34:07 +0300 From: Ari Suutari User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Yuan, Jue" References: <4518D321.8050604@delphij.net> <51584f840609260101m7dc0a1e1iffaccc8621df3783@mail.gmail.com> <4518E0D1.2030903@suutari.iki.fi> <51584f840609260134v1c2dbcd4y23ab0830a198c43d@mail.gmail.com> <4518E973.6010004@suutari.iki.fi> <51584f840609260153k6ec100cdhebdaad111666f46c@mail.gmail.com> <4518EB7B.5010802@suutari.iki.fi> In-Reply-To: <4518EB7B.5010802@suutari.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kip Macy , freebsd-current@freebsd.org Subject: Re: [Fwd: Will Xen 3.0 support (at least domU) be available ?] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 09:34:22 -0000 Hi, Ari Suutari wrote: > But ok, I'll update the fstab to say "/dev/xbd769a /". It didn't help. Kernel still cannot mount root. I guess the device name must different then. Ari S. From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 10:04:08 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83E7016A415 for ; Tue, 26 Sep 2006 10:04:08 +0000 (UTC) (envelope-from ari@suutari.iki.fi) Received: from espresso2.syncrontech.com (sync-old.syncrontech.com [213.28.98.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9E4C43D6B for ; Tue, 26 Sep 2006 10:04:01 +0000 (GMT) (envelope-from ari@suutari.iki.fi) Received: from guinness.syncrontech.com (guinness.syncrontech.com [62.71.8.57]) by espresso2.syncrontech.com (8.13.1/8.13.1) with ESMTP id k8QA40ta071179; Tue, 26 Sep 2006 13:04:00 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Received: from [127.0.0.1] (coffee.syncrontech.com [192.168.5.102]) by guinness.syncrontech.com (8.13.4/8.13.4) with ESMTP id k8QA3xe6005536; Tue, 26 Sep 2006 13:04:00 +0300 (EEST) (envelope-from ari@suutari.iki.fi) Message-ID: <4518FB0B.4030306@suutari.iki.fi> Date: Tue, 26 Sep 2006 13:03:55 +0300 From: Ari Suutari User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Yuan, Jue" References: <4518D321.8050604@delphij.net> <51584f840609260101m7dc0a1e1iffaccc8621df3783@mail.gmail.com> <4518E0D1.2030903@suutari.iki.fi> <51584f840609260134v1c2dbcd4y23ab0830a198c43d@mail.gmail.com> <4518E973.6010004@suutari.iki.fi> <51584f840609260153k6ec100cdhebdaad111666f46c@mail.gmail.com> <4518EB7B.5010802@suutari.iki.fi> <4518F40F.3050703@suutari.iki.fi> <51584f840609260257x5b1eaf3bg2d20a735f95a3f52@mail.gmail.com> In-Reply-To: <51584f840609260257x5b1eaf3bg2d20a735f95a3f52@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kip Macy , freebsd-current@freebsd.org Subject: Re: [Fwd: Will Xen 3.0 support (at least domU) be available ?] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 10:04:08 -0000 Hi, Yuan, Jue wrote: > Hi Ari, > > On 9/26/06, Ari Suutari wrote: >> Hi, >> >> Ari Suutari wrote: >> > But ok, I'll update the fstab to say "/dev/xbd769a /". >> >> It didn't help. Kernel still cannot mount root. I guess >> the device name must different then. > > This might due to how you create the image file system. It could be > /dev/xbd769c instead. :-) > > could you please mount that image as a md device and show me the > result of invoking *bsdlabel*? I guess you didn't create slice a in > this case. mdconfig -a -t vnode -f /opt/freebsd.img -u 4 disklabel -r md4 # /dev/md4: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 7191984 16 4.2BSD 2048 16384 28552 b: 1000000 7192000 swap c: 8192000 0 unused 0 0 # "raw" part, don't edit mount /dev/md4a /mnt ls /mnt .snap boot etc libexec mnt rescue sbin tmp var bin dev lib media proc root sys usr Ari S. From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 10:28:21 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A751916A416 for ; Tue, 26 Sep 2006 10:28:21 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6962943D5C for ; Tue, 26 Sep 2006 10:27:16 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 26 Sep 2006 03:27:16 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8QARGvn020906; Tue, 26 Sep 2006 03:27:16 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8QARF1E021404; Tue, 26 Sep 2006 03:27:15 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 03:27:14 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 03:27:14 -0700 Message-ID: <45190062.6090306@cisco.com> Date: Tue, 26 Sep 2006 06:26:42 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian FREISLICH References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2006 10:27:14.0528 (UTC) FILETIME=[558B7E00:01C6E156] DKIM-Signature: a=rsa-sha1; q=dns; l=1120; t=1159266436; x=1160130436; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20Anyone=20play=20with=20divert=20sockets=20lately?; X=v=3Dcisco.com=3B=20h=3D501uzIGYshBKoQ9c94cTaL/zwjI=3D; b=t63pGjjowAO5WYazaaTADgDRBRurf8RC5jFJg5VRbeMi2lhEtFvk/PBihCgMztLObk5ravA1 hd2vAl8DtHSJoNyiJrVmEI2z510Gd3HxWjTNZz2AdnkRoha9u0l3RMxU; Authentication-Results: sj-dkim-3.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-current@freebsd.org Subject: Re: Anyone play with divert sockets lately? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 10:28:21 -0000 Ian FREISLICH wrote: > > > I'm using divert sockets extensively for some tunnel/vpn software > I wrote _way_ back. It's running fine on -CURRENT (Tue Sep 19 > 08:33:01 SAST 2006), 4.11-STABLE, and just about everything in > between. I've not had to change the code substantially to make it > work on newer BSDs. All our VoIP goes through this piece of code: > > memset(&from, '\0', sizeof from); > from.sin_addr.s_addr = INADDR_ANY; > from.sin_port = config.tuns[config.tun].fw_rule; > while (tot + ntohs(hdr->length) <= (p - buf + in)) { > out = sendto(config.tuns[config.tun].div_fd, buf + tot, > ntohs(hdr->length), 0, (struct sockaddr *)&from, > sizeof(addr)); > ... > > Well, its interesting ... 6.1 appears to work.. but 7.0 does not.. Now I don't think the code we have does anything with setting the sin_port like you do (to config.tuns[]...) Maybe thats the issue... Not sure... I will have to go back and look at the code :-0 R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 10:40:10 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6269816A415 for ; Tue, 26 Sep 2006 10:40:10 +0000 (UTC) (envelope-from if@hetzner.co.za) Received: from hetzner.co.za (office.cpt2.host-h.net [196.7.147.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB99C43D70 for ; Tue, 26 Sep 2006 10:40:07 +0000 (GMT) (envelope-from if@hetzner.co.za) Received: from localhost ([127.0.0.1]) by hetzner.co.za with esmtp (Exim 4.62 (FreeBSD)) (envelope-from ) id 1GSAM8-0008Vk-JO; Tue, 26 Sep 2006 12:40:04 +0200 To: Randall Stewart From: Ian FREISLICH In-Reply-To: Message from Randall Stewart of "Tue, 26 Sep 2006 06:26:42 -0400." <45190062.6090306@cisco.com> X-Attribution: BOFH Date: Tue, 26 Sep 2006 12:40:04 +0200 Message-Id: Cc: freebsd-current@freebsd.org Subject: Re: Anyone play with divert sockets lately? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 10:40:10 -0000 Randall Stewart wrote: > Ian FREISLICH wrote: > > > > > > > I'm using divert sockets extensively for some tunnel/vpn software > > I wrote _way_ back. It's running fine on -CURRENT (Tue Sep 19 > > 08:33:01 SAST 2006), 4.11-STABLE, and just about everything in > > between. I've not had to change the code substantially to make it > > work on newer BSDs. All our VoIP goes through this piece of code: > > > > memset(&from, '\0', sizeof from); > > from.sin_addr.s_addr = INADDR_ANY; > > from.sin_port = config.tuns[config.tun].fw_rule; > > while (tot + ntohs(hdr->length) <= (p - buf + in)) { > > out = sendto(config.tuns[config.tun].div_fd, buf + tot, > > ntohs(hdr->length), 0, (struct sockaddr *)&from, > > sizeof(addr)); > > ... > > > > > Well, its interesting ... 6.1 appears to work.. but 7.0 does not.. > > Now I don't think the code we have does anything with setting the > sin_port like you do (to config.tuns[]...) All that does is tell the divert socket which (ipfw) rule to inject the packet after. If you read from the divert socket, do stuff(tm) and write back to the divert socket, preserve the struct sockaddr *from from the recvfrom() call and use that same data in the sendto() call unless you want processing in the stack to start afresh for the packet. (I'm sure others will correct that statement, but that's my poor-man's understanding) I've found that not zeroing these network structures before use confounds things, because you might not initialise all the elements. If my memory serves correctly, I think that these structures have changed size between 6 and 7, but take my saying so with a pinch of salt because I haven't checked recently. Ian -- Ian Freislich From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 10:42:38 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1634016A49E for ; Tue, 26 Sep 2006 10:42:38 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04FC543D55 for ; Tue, 26 Sep 2006 10:42:30 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 26 Sep 2006 03:42:31 -0700 X-IronPort-AV: i="4.09,219,1157353200"; d="scan'208"; a="325332757:sNHT33578988" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8QAgURp006474; Tue, 26 Sep 2006 03:42:30 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k8QAgTML019904; Tue, 26 Sep 2006 03:42:30 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 03:42:29 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 03:42:28 -0700 Message-ID: <451903F5.20001@cisco.com> Date: Tue, 26 Sep 2006 06:41:57 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian FREISLICH References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Sep 2006 10:42:29.0065 (UTC) FILETIME=[76A6C390:01C6E158] DKIM-Signature: a=rsa-sha1; q=dns; l=2429; t=1159267350; x=1160131350; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20Anyone=20play=20with=20divert=20sockets=20lately?; X=v=3Dcisco.com=3B=20h=3D501uzIGYshBKoQ9c94cTaL/zwjI=3D; b=fQjeYe36Xw/PLmvtwGWBGFIcHsiU+Yg45R6DyHY1e0ZG0CQ1vsN83MTnsw/JMMElZ45zW5Pw DgyMqumQNpln0irhsBYUSAJjrLladWlGWpa5DMJ6UzaiiHV5EmehLwww; Authentication-Results: sj-dkim-6.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-current@freebsd.org Subject: Re: Anyone play with divert sockets lately? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 10:42:38 -0000 Ian FREISLICH wrote: > Randall Stewart wrote: > >>Ian FREISLICH wrote: >> >> >>> >>>I'm using divert sockets extensively for some tunnel/vpn software >>>I wrote _way_ back. It's running fine on -CURRENT (Tue Sep 19 >>>08:33:01 SAST 2006), 4.11-STABLE, and just about everything in >>>between. I've not had to change the code substantially to make it >>>work on newer BSDs. All our VoIP goes through this piece of code: >>> >>> memset(&from, '\0', sizeof from); >>> from.sin_addr.s_addr = INADDR_ANY; >>> from.sin_port = config.tuns[config.tun].fw_rule; >>> while (tot + ntohs(hdr->length) <= (p - buf + in)) { >>> out = sendto(config.tuns[config.tun].div_fd, buf + > > tot, > >>> ntohs(hdr->length), 0, (struct sockaddr *)&from, >>> sizeof(addr)); >>> ... >>> >>> >> >>Well, its interesting ... 6.1 appears to work.. but 7.0 does not.. >> >>Now I don't think the code we have does anything with setting the >>sin_port like you do (to config.tuns[]...) > > > All that does is tell the divert socket which (ipfw) rule to inject > the packet after. If you read from the divert socket, do stuff(tm) > and write back to the divert socket, preserve the struct sockaddr > *from from the recvfrom() call and use that same data in the sendto() > call unless you want processing in the stack to start afresh for > the packet. (I'm sure others will correct that statement, but > that's my poor-man's understanding) Well.. looking at the code, I think we leave this untouched from the recv... that way it re-injects (in theory) at the same place it came out.. (which is what we want).. > > I've found that not zeroing these network structures before use > confounds things, because you might not initialise all the elements. > If my memory serves correctly, I think that these structures have > changed size between 6 and 7, but take my saying so with a pinch > of salt because I haven't checked recently. I will go poke around some more when I have time.. I was able to finish my needed UnitTest without the second tunnel up... so I am ok for now.. but I do want to circle back and see if its truely an app bug.. or a problem with the divert code... Very interesting in any case :-) R > > Ian > > -- > Ian Freislich > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 07:13:42 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63FD516A412; Tue, 26 Sep 2006 07:13:42 +0000 (UTC) (envelope-from sivakumar.subramani@wipro.com) Received: from wip-ectls-mx3.wipro.com (wip-ectls-mx3.wipro.com [203.91.193.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 86CAA43D79; Tue, 26 Sep 2006 07:13:27 +0000 (GMT) (envelope-from sivakumar.subramani@wipro.com) Received: from wip-ectls-mx3.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id BA1DC224512; Tue, 26 Sep 2006 12:43:25 +0530 (IST) Received: from blr-ec-bh02.wipro.com (blr-ec-bh02.wipro.com [10.201.50.92]) by wip-ectls-mx3.wipro.com (Postfix) with ESMTP id ADBCD22401A; Tue, 26 Sep 2006 12:43:25 +0530 (IST) Received: from blr-m3-msg.wipro.com ([10.114.50.99]) by blr-ec-bh02.wipro.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 26 Sep 2006 12:43:25 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 26 Sep 2006 12:43:31 +0530 Message-ID: <956E7FA2615F3B4595FC5F22870A72210C56FF@blr-m3-msg.wipro.com> In-Reply-To: <2a41acea0609011551v40338539u4eef48d091dd12ab@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TSO patch for current Thread-Index: AcbOGRNQM5pSEkCVTd6avle0S8tfTQTIh5og From: To: , , X-OriginalArrivalTime: 26 Sep 2006 07:13:25.0602 (UTC) FILETIME=[422A3420:01C6E13B] X-Mailman-Approved-At: Tue, 26 Sep 2006 11:30:44 +0000 Cc: Subject: RE: TSO patch for current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2006 07:13:42 -0000 Is the TSO patch is checked in to the current? Thanks, ~Siva -----Original Message----- From: owner-freebsd-net@freebsd.org [mailto:owner-freebsd-net@freebsd.org] On Behalf Of Jack Vogel Sent: Saturday, September 02, 2006 4:21 AM To: freebsd-net; freebsd-current Subject: RFC: TSO patch for current This is a patch for the stack and the em driver to enable TSO on CURRENT. Previously I had problems getting it to work, but this is functional. I should note that CURRENT is being a pain right now, when I comment out em in the config the kernel panics coming up, so I had to substitute this code into the tree. Rather bizarre :) I have this functionality running on a 6.1 based system, and our test group is already testing against that driver, so far things are looking good. I have designed it so the driver can continue to be built without support. There is also a sysctl in the stack code so you can set net.inet.tcp.tso_enable on or off and compare. I know there may be some refinements to add in, but I would like to get this into CURRENT as a start. Comments? Jack The information contained in this electronic message and any attachments to= this message are intended for the exclusive use of the addressee(s) and= may contain proprietary, confidential or privileged information. If you= are not the intended recipient, you should not disseminate, distribute or= copy this e-mail. Please notify the sender immediately and destroy all= copies of this message and any attachments.=0D WARNING: Computer viruses can be transmitted via email. The recipient= should check this email and any attachments for the presence of viruses.= The company accepts no liability for any damage caused by any virus= transmitted by this email. =0D www.wipro.com From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 08:01:16 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C31616A403 for ; Tue, 26 Sep 2006 08:01:16 +0000 (UTC) (envelope-from yuanjue02@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id E20F643D58 for ; Tue, 26 Sep 2006 08:01:14 +0000 (GMT) (envelope-from yuanjue02@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so2150626wxd for ; Tue, 26 Sep 2006 01:01:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aIh8YwPr8zNC2zZms5U4+/cvPonPOIyXv15HKId0KYhlmEUkcmt024YHbfV/ovWf9V7sNa8cPsPnSgkxb4DxCWsj1gBc1BYnp/g7vIBhSJcQ/UKEvZzRiUDo7DbOamRDNDoSQtiTPJlYxn5C5hh2oRi5qRtBS9P5ReqSMGSGX70= Received: by 10.90.79.6 with SMTP id c6mr665355agb; Tue, 26 Sep 2006 01:01:13 -0700 (PDT) Received: by 10.90.83.20 with HTTP; Tue, 26 Sep 2006 01:01:13 -0700 (PDT) Message-ID: <51584f840609260101m7dc0a1e1iffaccc8621df3783@mail.gmail.com> Date: Tue, 26 Sep 2006 16:01:13 +0800 From: "Yuan, Jue" To: "LI Xin" , "Ari Suutari" In-Reply-To: <4518D321.8050604@delphij.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4518D321.8050604@delphij.net> X-Mailman-Approved-At: Tue, 26 Sep 2006 11:31:13 +0000 Cc: freebsd-current@freebsd.org Subject: Re: [Fwd: Will Xen 3.0 support (at least domU) be available ?] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 08:01:16 -0000 Hi there, I am the Summer of Code student who is responsible for porting Xen to FreeBSD. Currently we have got two domU kernels, one for installation, the other for running. And the dom0 support is on its way :-) The domU kernels I provide could at least run with Xen 3.0.2-2. I think it will probably comfort with the latest stable Xen version, which I believe is 3.0.2-3 (correct me if I am wrong). If there is anything wrong, please feel free to let me know. BTW: I am not in this list, so CC me if contacting is needed. On 9/26/06, LI Xin wrote: > FYI, > > -- > Xin LI http://www.delphij.net/ > FreeBSD - The Power to Serve! > > > > ---------- Forwarded message ---------- > From: Ari Suutari > To: freebsd-current@freebsd.org > Date: Tue, 26 Sep 2006 10:04:10 +0300 > Subject: Will Xen 3.0 support (at least domU) be available ? > Hi, > > I have been playing with Xen 3.0 lately (with NetBSD & debian), but > as FreeBSD user, I would like to use FreeBSD with Xen. I found > web page which shows some results from google SoC project, there are > two DomU kernels downloadable from there. > > Currently, I would be perfectly happy with just DomU support, but > the the Xen changes are not available in FreeBSD cvs yet, I think ? > This would mean that I'm stuck with the versions provided on SoC page. > > It would be nice if someone could give more information about > future of FreeBSD's xen, are there plans to put the code into > some future version. > -- Best Regards Yuan, Jue @ http://www.yuanjue.net From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 08:34:28 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0017616A416 for ; Tue, 26 Sep 2006 08:34:27 +0000 (UTC) (envelope-from yuanjue02@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.236]) by mx1.FreeBSD.org (Postfix) with ESMTP id 578FC43D7C for ; Tue, 26 Sep 2006 08:34:10 +0000 (GMT) (envelope-from yuanjue02@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so2158743wxd for ; Tue, 26 Sep 2006 01:34:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Vaef5TxgiwF8TU20UGYu0b/E5ujjChHqvY2M1/tb/VMcjc0ly9Mpkq4qE0zlRFnQ1it3ayDkwBfl6Trz80oyqSfyIxYXFhaBgyUKcb72S/06lFQME+wCs/AzbR37vhzv4Y2V1NXUQX3aAlqSebqXdwX5pOLiKY004BtvRvMQX/A= Received: by 10.90.25.7 with SMTP id 7mr675443agy; Tue, 26 Sep 2006 01:34:09 -0700 (PDT) Received: by 10.90.83.20 with HTTP; Tue, 26 Sep 2006 01:34:09 -0700 (PDT) Message-ID: <51584f840609260134v1c2dbcd4y23ab0830a198c43d@mail.gmail.com> Date: Tue, 26 Sep 2006 16:34:09 +0800 From: "Yuan, Jue" To: "Ari Suutari" In-Reply-To: <4518E0D1.2030903@suutari.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4518D321.8050604@delphij.net> <51584f840609260101m7dc0a1e1iffaccc8621df3783@mail.gmail.com> <4518E0D1.2030903@suutari.iki.fi> X-Mailman-Approved-At: Tue, 26 Sep 2006 11:31:28 +0000 Cc: Kip Macy , freebsd-current@freebsd.org Subject: Re: [Fwd: Will Xen 3.0 support (at least domU) be available ?] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 08:34:28 -0000 Hi Ari, On 9/26/06, Ari Suutari wrote: > Hi, > > Yuan, Jue wrote: > > Hi there, > > > > I am the Summer of Code student who is responsible for porting Xen to > > FreeBSD. Currently we have got two domU kernels, one for installation, > > the other for running. And the dom0 support is on its way :-) > > Yes, I tried these kernels under NetBSD-current running as > dom0, using Xen 3.0.2-2. I couldn't get freebsd-XENU_INSTALL > kernel to boot, it crashes like this: > > (XEN) domain_crash_sync called from entry.S (ff149655) > (XEN) Domain 16 (vcpu#0) crashed on cpu#0: > (XEN) ----[ Xen-3.0.2-2 Not tainted ]---- > (XEN) CPU: 0 > (XEN) EIP: e019:[] > (XEN) EFLAGS: 00000206 CONTEXT: guest > (XEN) eax: 00000000 ebx: 00000000 ecx: 00100000 edx: c0759000 > (XEN) esi: 00000003 edi: c0800000 ebp: c075fff4 esp: c075ff5c > (XEN) cr0: 8005003b cr3: 06763000 > (XEN) ds: e021 es: e021 fs: e021 gs: e021 ss: e021 cs: e019 > (XEN) Guest stack trace from esp=c075ff5c: > (XEN) 00000002 c01f8d77 0001e019 00010006 00000000 c0205923 c0766000 0049a000 > (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > (XEN) 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 > (XEN) 00000000 c0766000 00000766 00000000 00000000 00000000 00000000 00000000 > (XEN) 00000000 00000000 00000000 00000000 c0759000 00000000 00000000 c00314c6 > (XEN) c0759000 > I tested freebsd-XENU_INSTALL under kubuntu 6.0.6 as dom0. don't know why this happens. I will check this issue later :-) > The freebsd-XENU kernel boots, but I cannot mount root: > > Using config file "freebsd1". > Started domain freebsd1 > WARNING: loader(8) metadata is missing! > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2006 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD 7.0-CURRENT #2: Sat Aug 26 00:02:36 CST 2006 > YuanJue@www.yuanjue.org:/usr/home/YuanJue/Develop/SVN_work/xen3/sys/i386-xen/compile/XENCONF-STD > WARNING: DIAGNOSTIC option enabled, expect reduced performance. > Xen reported: 863.864 MHz processor. > Timecounter "ixen" frequency 1000000000 Hz quality 0 > CPU: Intel Pentium III (863.86-MHz 686-class CPU) > Origin = "GenuineIntel" Id = 0x68a Stepping = 10 > Features=0x383f9ff > real memory = 63266816 (60 MB) > avail memory = 57602048 (54 MB) > xc0: on motherboard > cpu0 on motherboard > Timecounters tick every 10.000 msec > [XEN] Initialising virtual ethernet driver. > xn0: Ethernet address: aa:00:00:50:03:e1 > [XEN] > Trying to mount root from ufs:/dev/xbd769a > Mount point / had 1 dangling refs > > Manual root filesystem specification: > : Mount using filesystem > eg. ufs:da0s1a > ? List valid disk boot devices > Abort manual input > > > The root filesystem is file based and has been created on another > FreeBSD machine, so it should be ok. What is that number "769" in > xbd device ? Is it same for all installations ? > the magic number here is due to the major and minor device number of Linux. maybe this is not the case while you are using NetBSD. Anyway, the first thing you should check is the fstab file in your file-backed image. More details could be found at http://www.yuanjue.net/xen/howto.html HTH -- Best Regards Yuan, Jue @ http://www.yuanjue.net From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 08:53:55 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AF5F716A40F for ; Tue, 26 Sep 2006 08:53:55 +0000 (UTC) (envelope-from yuanjue02@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6869243D46 for ; Tue, 26 Sep 2006 08:53:50 +0000 (GMT) (envelope-from yuanjue02@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so2163817wxd for ; Tue, 26 Sep 2006 01:53:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oDIED/HvOjD4DefwmifxP2ZBve+yuV5aRTo9eNod49l6BKcHgs3OlmkBAxvuIJYZtUHjySKHLCpF4cTVSAV1NpCn6UABM9qkoztEGOw7GyqBisTQXk8SJ8NPoIwUeWADrnUpLPAvthfkt9hd2YkkNuBb7ESARl3GVXAXlE1Vy0I= Received: by 10.90.84.17 with SMTP id h17mr664321agb; Tue, 26 Sep 2006 01:53:49 -0700 (PDT) Received: by 10.90.83.20 with HTTP; Tue, 26 Sep 2006 01:53:49 -0700 (PDT) Message-ID: <51584f840609260153k6ec100cdhebdaad111666f46c@mail.gmail.com> Date: Tue, 26 Sep 2006 16:53:49 +0800 From: "Yuan, Jue" To: "Ari Suutari" In-Reply-To: <4518E973.6010004@suutari.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4518D321.8050604@delphij.net> <51584f840609260101m7dc0a1e1iffaccc8621df3783@mail.gmail.com> <4518E0D1.2030903@suutari.iki.fi> <51584f840609260134v1c2dbcd4y23ab0830a198c43d@mail.gmail.com> <4518E973.6010004@suutari.iki.fi> X-Mailman-Approved-At: Tue, 26 Sep 2006 11:31:38 +0000 Cc: Kip Macy , freebsd-current@freebsd.org Subject: Re: [Fwd: Will Xen 3.0 support (at least domU) be available ?] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 08:53:55 -0000 Hi Ari, On 9/26/06, Ari Suutari wrote: > Hi, > > Yuan, Jue wrote: > > > > I tested freebsd-XENU_INSTALL under kubuntu 6.0.6 as dom0. don't know > > why this happens. I will check this issue later :-) > > OK, I can consider running debian as dom0 if that is needed > (but I would like to stick in the bsd family :-) > > > >> Trying to mount root from ufs:/dev/xbd769a > >> Mount point / had 1 dangling refs > >> > >> > >> The root filesystem is file based and has been created on another > >> FreeBSD machine, so it should be ok. What is that number "769" in > >> xbd device ? Is it same for all installations ? > >> > > > > the magic number here is due to the major and minor device number of > > Linux. maybe this is not the case while you are using NetBSD. Anyway, > > the first thing you should check is the fstab file in your file-backed > > image. > > It is not looking at fstab yet, this is the mount specified > by extra += ",vfs.root.mountfrom=ufs:/dev/xbd.... in xen config file. > > I tried guessing the number, but had no luck :-( > the "vfs.root.mountfrom=ufs:/dev/xbd769a" thing must be matched with what's in fstab of your image file in order to get it working :-) -- Best Regards Yuan, Jue @ http://www.yuanjue.net From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 09:57:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BB2E16A5BA for ; Tue, 26 Sep 2006 09:57:29 +0000 (UTC) (envelope-from yuanjue02@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2220143D55 for ; Tue, 26 Sep 2006 09:57:25 +0000 (GMT) (envelope-from yuanjue02@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so2180039wxd for ; Tue, 26 Sep 2006 02:57:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LWvNSr2cEBNw9o3LVzdm0DmIOU/XQWUmZClgyJIRvIgYGwBqe1efTzK/LttYypClXNcwQqPPIvy7V5JEvEYM7EIqBBFDvSgGJLk5SxjP6ufB+VE9IaQ57dEMQmNZ+3Ce92A9+ixvBjksYSSCbuPvjDfpc3irb6/U6gHrUvX5pYM= Received: by 10.90.52.18 with SMTP id z18mr676975agz; Tue, 26 Sep 2006 02:57:24 -0700 (PDT) Received: by 10.90.83.20 with HTTP; Tue, 26 Sep 2006 02:57:24 -0700 (PDT) Message-ID: <51584f840609260257x5b1eaf3bg2d20a735f95a3f52@mail.gmail.com> Date: Tue, 26 Sep 2006 17:57:24 +0800 From: "Yuan, Jue" To: "Ari Suutari" In-Reply-To: <4518F40F.3050703@suutari.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4518D321.8050604@delphij.net> <51584f840609260101m7dc0a1e1iffaccc8621df3783@mail.gmail.com> <4518E0D1.2030903@suutari.iki.fi> <51584f840609260134v1c2dbcd4y23ab0830a198c43d@mail.gmail.com> <4518E973.6010004@suutari.iki.fi> <51584f840609260153k6ec100cdhebdaad111666f46c@mail.gmail.com> <4518EB7B.5010802@suutari.iki.fi> <4518F40F.3050703@suutari.iki.fi> X-Mailman-Approved-At: Tue, 26 Sep 2006 11:31:45 +0000 Cc: Kip Macy , freebsd-current@freebsd.org Subject: Re: [Fwd: Will Xen 3.0 support (at least domU) be available ?] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 09:57:29 -0000 Hi Ari, On 9/26/06, Ari Suutari wrote: > Hi, > > Ari Suutari wrote: > > But ok, I'll update the fstab to say "/dev/xbd769a /". > > It didn't help. Kernel still cannot mount root. I guess > the device name must different then. This might due to how you create the image file system. It could be /dev/xbd769c instead. :-) could you please mount that image as a md device and show me the result of invoking *bsdlabel*? I guess you didn't create slice a in this case. -- Best Regards Yuan, Jue @ http://www.yuanjue.net From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 10:16:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0CF0916A407 for ; Tue, 26 Sep 2006 10:16:44 +0000 (UTC) (envelope-from yuanjue02@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7528543D4C for ; Tue, 26 Sep 2006 10:16:43 +0000 (GMT) (envelope-from yuanjue02@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so2185112wxd for ; Tue, 26 Sep 2006 03:16:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LxXNWgo/eDXc+GqP4JtpdM5o4Gwx3yVGg6UqXQ5ChG8mWHhjj8VMyKBUW5g27vJeLcMB+dthqnaFtPKhiAfv5C+u2/uuxOTuI8iu6FgF+B7qrxASewEBZbyMUfiuhiSfWkwQLQde5I5RxP/T4c0DYVuqvftmWjbNS3ezUYg1xsI= Received: by 10.90.78.9 with SMTP id a9mr684602agb; Tue, 26 Sep 2006 03:16:42 -0700 (PDT) Received: by 10.90.83.20 with HTTP; Tue, 26 Sep 2006 03:16:42 -0700 (PDT) Message-ID: <51584f840609260316u6ddbf9ebn2edbfb48cb258802@mail.gmail.com> Date: Tue, 26 Sep 2006 18:16:42 +0800 From: "Yuan, Jue" To: "Ari Suutari" In-Reply-To: <4518FB0B.4030306@suutari.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4518D321.8050604@delphij.net> <51584f840609260101m7dc0a1e1iffaccc8621df3783@mail.gmail.com> <4518E0D1.2030903@suutari.iki.fi> <51584f840609260134v1c2dbcd4y23ab0830a198c43d@mail.gmail.com> <4518E973.6010004@suutari.iki.fi> <51584f840609260153k6ec100cdhebdaad111666f46c@mail.gmail.com> <4518EB7B.5010802@suutari.iki.fi> <4518F40F.3050703@suutari.iki.fi> <51584f840609260257x5b1eaf3bg2d20a735f95a3f52@mail.gmail.com> <4518FB0B.4030306@suutari.iki.fi> X-Mailman-Approved-At: Tue, 26 Sep 2006 11:31:55 +0000 Cc: Kip Macy , freebsd-current@freebsd.org Subject: Re: [Fwd: Will Xen 3.0 support (at least domU) be available ?] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 10:16:44 -0000 Hi Ari, On 9/26/06, Ari Suutari wrote: > Hi, > > Yuan, Jue wrote: > > Hi Ari, > > > > On 9/26/06, Ari Suutari wrote: > >> Hi, > >> > >> Ari Suutari wrote: > >> > But ok, I'll update the fstab to say "/dev/xbd769a /". > >> > >> It didn't help. Kernel still cannot mount root. I guess > >> the device name must different then. > > > > This might due to how you create the image file system. It could be > > /dev/xbd769c instead. :-) > > > > could you please mount that image as a md device and show me the > > result of invoking *bsdlabel*? I guess you didn't create slice a in > > this case. > > mdconfig -a -t vnode -f /opt/freebsd.img -u 4 > disklabel -r md4 > # /dev/md4: > 8 partitions: > # size offset fstype [fsize bsize bps/cpg] > a: 7191984 16 4.2BSD 2048 16384 28552 > b: 1000000 7192000 swap > c: 8192000 0 unused 0 0 # "raw" part, don't edit > > mount /dev/md4a /mnt > ls /mnt > .snap boot etc libexec mnt rescue sbin tmp var > bin dev lib media proc root sys usr > hmm, don't know why here. seems your configuration is fine. Maybe some special modifications are needed in NetBSD situation, say, the device number. -- Best Regards Yuan, Jue @ http://www.yuanjue.net From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 11:39:18 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93A0D16A412 for ; Tue, 26 Sep 2006 11:39:18 +0000 (UTC) (envelope-from jrh29@alumni.cwru.edu) Received: from eastrmmtao05.cox.net (eastrmmtao05.cox.net [68.230.240.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4705743DAD for ; Tue, 26 Sep 2006 11:39:13 +0000 (GMT) (envelope-from jrh29@alumni.cwru.edu) Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao05.cox.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20060926113912.GIGQ7951.eastrmmtao05.cox.net@eastrmimpo01.cox.net> for ; Tue, 26 Sep 2006 07:39:12 -0400 Received: from [192.168.1.100] ([68.98.142.45]) by eastrmimpo01.cox.net with bizsmtp id Szf81V00E0yyTD80000000 Tue, 26 Sep 2006 07:39:08 -0400 Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <20060926111452.J91466@godot.imp.ch> References: <20060926111452.J91466@godot.imp.ch> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0C4B0125-11AA-4BDB-A4E3-163A6194AB68@alumni.cwru.edu> Content-Transfer-Encoding: 7bit From: Justin Hibbits Date: Tue, 26 Sep 2006 07:39:11 -0400 To: current@freebsd.org X-Mailer: Apple Mail (2.750) Cc: Subject: Re: What do you think ?: How should pseundo terminals behave ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 11:39:18 -0000 On Sep 26, 2006, at 05:33 , Martin Blapp wrote: > So how should ptys behave ? > > 1.) Block until the tty is really opened again and there is > a master available again. Then write to the freshly opened > pty. (not easy to do) > > 2.) Block forever since the tty will not be reopened anymore since > we leak ptys. > > 3.) Detect that there is no master around anymore and > return ENXIO: > > # echo "BLUBBER" > /dev/ttypX > # /dev/ttypX: Device not configured > > (easy to do, i've got a fix. IMHO this is the best thing to > do. This allows fast error recovery in case the master > has been gone away) > > 4.) Keep the current behaviour, leak terminals or panic. > > (the simplest thing to do. Let's keep the bugs) > > Please vote for any of those choice. Thank you for your > participation. > > Martin I vote #3, it makes the most sense. - Justin From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 12:00:24 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3627616A47B for ; Tue, 26 Sep 2006 12:00:24 +0000 (UTC) (envelope-from shigeru@iij.ad.jp) Received: from otm-mgo01.iij.ad.jp (otm-mgo01.iij.ad.jp [210.138.20.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8ABD043D49 for ; Tue, 26 Sep 2006 12:00:12 +0000 (GMT) (envelope-from shigeru@iij.ad.jp) Received: OTM-MO(otm-mgo01) id k8QC0BY0059387; Tue, 26 Sep 2006 21:00:11 +0900 (JST) DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=iij.ad.jp; s=omgo0; t=1159272011; bh=1qkOLI5s5cUD38BQDfHcsjZeteo=; h=Received:Received: Date:Message-Id:To:Cc:Subject:From:In-Reply-To:References:X-Mailer: Mime-Version:Content-Type:Content-Transfer-Encoding; b=HTfaHiuirw9q h3Xm31CnoPKZUXFmP6yUEJmrRboWTxUjVhyEykGV2b4U0ZCmGL6aUyKpSMlZrbH5MhT mm8VzIpoCMVbe7WBF/56HwZ7WTjnaxmGFhyzUH1hq5U5x01z0a+8XDOKoA0TSKH2YWM gALXn9E0r85947Qh12I7iShfc= Received: OTM-MIX(otm-mix01) id k8QC0Atd075107; Tue, 26 Sep 2006 21:00:10 +0900 (JST) Received: from localhost (mercury.iij.ad.jp [192.168.184.90]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp) id k8QC0ABY025487 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Tue, 26 Sep 2006 21:00:10 +0900 (JST) Date: Tue, 26 Sep 2006 21:00:09 +0900 (JST) Message-Id: <20060926.210009.34729196.shigeru@iij.ad.jp> To: pyunyh@gmail.com From: YAMAMOTO Shigeru In-Reply-To: <20060926002916.GA5975@cdnetworks.co.kr> References: <20060926002916.GA5975@cdnetworks.co.kr> X-Mailer: Mew version 5.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 12:00:24 -0000 Hi, all, I test new msk driver patch at my PC. But I can't compile msk driver at making modules. /usr/src/sys/modules/msk/../../dev/msk/if_msk.c: In function `msk_jfree': /usr/src/sys/modules/msk/../../dev/msk/if_msk.c:2417: error: `MSK_JSOLTS' undeclared (first use in this function) /usr/src/sys/modules/msk/../../dev/msk/if_msk.c:2417: error: (Each undeclared identifier is reported only once /usr/src/sys/modules/msk/../../dev/msk/if_msk.c:2417: error: for each function it appears in.) /usr/src/sys/modules/msk/../../dev/msk/if_msk.c: In function `msk_txeof': /usr/src/sys/modules/msk/../../dev/msk/if_msk.c:3027: error: `nsegs' undeclared (first use in this function) /usr/src/sys/modules/msk/../../dev/msk/if_msk.c:3027: warning: too many arguments for format *** Error code 1 Stop in /usr/src/sys/modules/msk. 'MSK_JSLTS' is not defined in this patch. Thanks, ------- YAMAMOTO Shigeru From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 12:17:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 803FB16A40F for ; Tue, 26 Sep 2006 12:17:01 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id EAF2F43D7C for ; Tue, 26 Sep 2006 12:16:53 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so2903977pye for ; Tue, 26 Sep 2006 05:16:53 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=SaF89xnjfP88ERHIryKWuetesJmvspM/OIQDGwEF5kMFrilw6Zz7AgxhqnfdHyQ5vzlLj5Y8tzLrN3d/cnsXFaZXAyir8AnzA3f8eTEPirstZVxat8Ighpe/v3AGOKtS1fhBOmfPohBUiv7k3KRDolnwQgMGhXJyYPhW1fW1i/I= Received: by 10.35.121.12 with SMTP id y12mr688233pym; Tue, 26 Sep 2006 05:16:53 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 8sm1232254nzn.2006.09.26.05.16.51; Tue, 26 Sep 2006 05:16:52 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k8QCH7UB008740 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Sep 2006 21:17:08 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k8QCH79r008739; Tue, 26 Sep 2006 21:17:07 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Tue, 26 Sep 2006 21:17:07 +0900 From: Pyun YongHyeon To: YAMAMOTO Shigeru Message-ID: <20060926121707.GC5975@cdnetworks.co.kr> References: <20060926002916.GA5975@cdnetworks.co.kr> <20060926.210009.34729196.shigeru@iij.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060926.210009.34729196.shigeru@iij.ad.jp> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2006 12:17:01 -0000 On Tue, Sep 26, 2006 at 09:00:09PM +0900, YAMAMOTO Shigeru wrote: > > Hi, all, > > I test new msk driver patch at my PC. > But I can't compile msk driver at making modules. > > /usr/src/sys/modules/msk/../../dev/msk/if_msk.c: In function `msk_jfree': > /usr/src/sys/modules/msk/../../dev/msk/if_msk.c:2417: error: `MSK_JSOLTS' undeclared (first use in this function) > /usr/src/sys/modules/msk/../../dev/msk/if_msk.c:2417: error: (Each undeclared identifier is reported only once > /usr/src/sys/modules/msk/../../dev/msk/if_msk.c:2417: error: for each function it appears in.) > /usr/src/sys/modules/msk/../../dev/msk/if_msk.c: In function `msk_txeof': > /usr/src/sys/modules/msk/../../dev/msk/if_msk.c:3027: error: `nsegs' undeclared (first use in this function) > /usr/src/sys/modules/msk/../../dev/msk/if_msk.c:3027: warning: too many arguments for format > *** Error code 1 > > Stop in /usr/src/sys/modules/msk. > > 'MSK_JSLTS' is not defined in this patch. > > Thanks, Oops! It should be fixed now. Please try again. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 16:58:47 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 095EE16A412 for ; Tue, 26 Sep 2006 16:58:47 +0000 (UTC) (envelope-from allbery@ece.cmu.edu) Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EFE543D49 for ; Tue, 26 Sep 2006 16:58:46 +0000 (GMT) (envelope-from allbery@ece.cmu.edu) Received: by bache.ece.cmu.edu (Postfix, from userid 953) id 18CF0A8; Tue, 26 Sep 2006 12:58:45 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on filt2.ece.cmu.edu X-Spam-Level: X-Spam-Status: No, score=0.0 required=6.0 tests=BAYES_50 autolearn=no version=3.1.4 Received: from [10.9.204.128] (dsl093-061-215.pit1.dsl.speakeasy.net [66.93.61.215]) by bache.ece.cmu.edu (Postfix) with ESMTP id 7884EA5; Tue, 26 Sep 2006 12:58:42 -0400 (EDT) In-Reply-To: <0C4B0125-11AA-4BDB-A4E3-163A6194AB68@alumni.cwru.edu> References: <20060926111452.J91466@godot.imp.ch> <0C4B0125-11AA-4BDB-A4E3-163A6194AB68@alumni.cwru.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <98FD6058-7220-48DB-AC24-F989FCB2AE11@ece.cmu.edu> Content-Transfer-Encoding: 7bit From: "Brandon S. Allbery KF8NH" Date: Tue, 26 Sep 2006 12:58:39 -0400 To: Justin Hibbits X-Mailer: Apple Mail (2.752.2) Cc: current@freebsd.org Subject: Re: What do you think ?: How should pseundo terminals behave ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 16:58:47 -0000 On Sep 26, 2006, at 7:39 , Justin Hibbits wrote: > > On Sep 26, 2006, at 05:33 , Martin Blapp wrote: >> 3.) Detect that there is no master around anymore and >> return ENXIO: >> >> # echo "BLUBBER" > /dev/ttypX >> # /dev/ttypX: Device not configured >> >> (easy to do, i've got a fix. IMHO this is the best thing to >> do. This allows fast error recovery in case the master >> has been gone away) 3a) Hangup all processes attached to the client and switch them to some kind of "dead" inode (which could be a fixed entity since all operations on it except close() fail). (Don't real ttys do this?) Dunno how easy this would be. -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 17:18:59 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31F0A16A4C8 for ; Tue, 26 Sep 2006 17:18:59 +0000 (UTC) (envelope-from bmr@google.com) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id CCA7F43D7D for ; Tue, 26 Sep 2006 17:18:07 +0000 (GMT) (envelope-from bmr@google.com) Received: from zps75.corp.google.com (zps75.corp.google.com [172.25.146.75]) by smtp-out.google.com with ESMTP id k8QHHxTb009676 for ; Tue, 26 Sep 2006 10:17:59 -0700 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=iyGWbuYfOLk4WI+JVW9IfaBgV1tJnXTGdSoi8o5bnPd6hdN5R0HaUF3o0lvd5H2ww TFc9F9PZKzJ04TuZ7US0A== Received: from smtp-out2.google.com (fpr16.prod.google.com [10.253.18.16]) by zps75.corp.google.com with ESMTP id k8QE07kR027917 for ; Tue, 26 Sep 2006 10:17:55 -0700 Received: by smtp-out2.google.com with SMTP id 16so251234fpr for ; Tue, 26 Sep 2006 10:17:55 -0700 (PDT) Received: by 10.253.16.13 with SMTP id 13mr866165fpp; Tue, 26 Sep 2006 10:17:55 -0700 (PDT) Received: by 10.253.14.15 with HTTP; Tue, 26 Sep 2006 10:17:55 -0700 (PDT) Message-ID: <4f674ca50609261017j780788b0o5672914c2b511b84@mail.google.com> Date: Tue, 26 Sep 2006 19:17:55 +0200 From: "Magnus Ringman" To: current@freebsd.org In-Reply-To: <0C4B0125-11AA-4BDB-A4E3-163A6194AB68@alumni.cwru.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060926111452.J91466@godot.imp.ch> <0C4B0125-11AA-4BDB-A4E3-163A6194AB68@alumni.cwru.edu> Cc: Subject: Re: What do you think ?: How should pseundo terminals behave ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 17:18:59 -0000 On 9/26/06, Justin Hibbits wrote: > On Sep 26, 2006, at 05:33 , Martin Blapp wrote: > > So how should ptys behave ? > > 3.) Detect that there is no master around anymore and > > return ENXIO: > > > > # echo "BLUBBER" > /dev/ttypX > > # /dev/ttypX: Device not configured > > > > (easy to do, i've got a fix. IMHO this is the best thing to > > do. This allows fast error recovery in case the master > > has been gone away) > > Martin > > I vote #3, it makes the most sense. +1. Magnus From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 17:28:20 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9390916A407 for ; Tue, 26 Sep 2006 17:28:20 +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 315D243D46 for ; Tue, 26 Sep 2006 17:28:20 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (critter.freebsd.dk [192.168.48.2]) by phk.freebsd.dk (Postfix) with ESMTP id 09DBF170C5; Tue, 26 Sep 2006 17:28:19 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.8/8.13.8) with ESMTP id k8QHSGF4005319; Tue, 26 Sep 2006 17:28:16 GMT (envelope-from phk@critter.freebsd.dk) To: "Magnus Ringman" From: "Poul-Henning Kamp" In-Reply-To: Your message of "Tue, 26 Sep 2006 19:17:55 +0200." <4f674ca50609261017j780788b0o5672914c2b511b84@mail.google.com> Date: Tue, 26 Sep 2006 17:28:15 +0000 Message-ID: <5318.1159291695@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: current@freebsd.org Subject: Re: What do you think ?: How should pseundo terminals behave ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 17:28:20 -0000 In message <4f674ca50609261017j780788b0o5672914c2b511b84@mail.google.com>, "Mag nus Ringman" writes: >> > 3.) Detect that there is no master around anymore and >> > return ENXIO: This is the only way that makes any sense. -- 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 Tue Sep 26 17:29:13 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 784DF16A407 for ; Tue, 26 Sep 2006 17:29:13 +0000 (UTC) (envelope-from bmr@google.com) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id CAD8443D5D for ; Tue, 26 Sep 2006 17:29:08 +0000 (GMT) (envelope-from bmr@google.com) Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id k8QHT5Bx015826 for ; Tue, 26 Sep 2006 10:29:05 -0700 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=H7o4zYI1no5jw3wUs3i04A76u1Qx+/rG2cBs40j4uaubJDL6e0WcOjjbpEVL0BzA3 sRCus1zM9B0Lcxu6argrA== Received: from smtp-out2.google.com (fpr16.prod.google.com [10.253.18.16]) by zps38.corp.google.com with ESMTP id k8QHOaI3001121 for ; Tue, 26 Sep 2006 10:29:03 -0700 Received: by smtp-out2.google.com with SMTP id 16so275724fpr for ; Tue, 26 Sep 2006 10:29:03 -0700 (PDT) Received: by 10.253.31.16 with SMTP id e16mr870868fpe; Tue, 26 Sep 2006 10:29:02 -0700 (PDT) Received: by 10.253.14.15 with HTTP; Tue, 26 Sep 2006 10:29:02 -0700 (PDT) Message-ID: <4f674ca50609261029s76432971yfc15171a3e89cb72@mail.google.com> Date: Tue, 26 Sep 2006 19:29:02 +0200 From: "Magnus Ringman" To: current@freebsd.org In-Reply-To: <98FD6058-7220-48DB-AC24-F989FCB2AE11@ece.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060926111452.J91466@godot.imp.ch> <0C4B0125-11AA-4BDB-A4E3-163A6194AB68@alumni.cwru.edu> <98FD6058-7220-48DB-AC24-F989FCB2AE11@ece.cmu.edu> Cc: Justin Hibbits Subject: Re: What do you think ?: How should pseundo terminals behave ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 17:29:13 -0000 On 9/26/06, Brandon S. Allbery KF8NH wrote: > > 3a) Hangup all processes attached to the client and switch them to > some kind of "dead" inode (which could be a fixed entity since all > operations on it except close() fail). (Don't real ttys do this?) -1. Yes and no. ttys do that on an actual hangup (when a hardware hangup happens), however PTYs are intended to allow emulating the full terminal line semantics, including hangup. Imo the case of "pty master side disappearing" is equivalent to "backing device (hardware) no longer exists", not "remote end hung up". Some OSes have a vhangup(2) call, which when called on an open device will send a hangup to all controlled processes, possibly also substituting a dead fd. One idea might be to allow pty pairs a "generation" concept, and have slave side lose the fd when the master side is close Magnus From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 17:33:31 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 285D616A416 for ; Tue, 26 Sep 2006 17:33:31 +0000 (UTC) (envelope-from allbery@ece.cmu.edu) Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 81D0D43D46 for ; Tue, 26 Sep 2006 17:33:30 +0000 (GMT) (envelope-from allbery@ece.cmu.edu) Received: by bache.ece.cmu.edu (Postfix, from userid 953) id DC080A5; Tue, 26 Sep 2006 13:33:29 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on filt1.ece.cmu.edu X-Spam-Level: X-Spam-Status: No, score=0.0 required=6.0 tests=BAYES_50 autolearn=no version=3.1.4 Received: from [10.9.204.128] (dsl093-061-215.pit1.dsl.speakeasy.net [66.93.61.215]) by bache.ece.cmu.edu (Postfix) with ESMTP id 4E5E49E; Tue, 26 Sep 2006 13:33:27 -0400 (EDT) In-Reply-To: <4f674ca50609261029s76432971yfc15171a3e89cb72@mail.google.com> References: <20060926111452.J91466@godot.imp.ch> <0C4B0125-11AA-4BDB-A4E3-163A6194AB68@alumni.cwru.edu> <98FD6058-7220-48DB-AC24-F989FCB2AE11@ece.cmu.edu> <4f674ca50609261029s76432971yfc15171a3e89cb72@mail.google.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8EECEF0C-8C94-4A7C-862A-633F67D3D229@ece.cmu.edu> Content-Transfer-Encoding: 7bit From: "Brandon S. Allbery KF8NH" Date: Tue, 26 Sep 2006 13:33:24 -0400 To: "Magnus Ringman" X-Mailer: Apple Mail (2.752.2) Cc: current@freebsd.org, Justin Hibbits Subject: Re: What do you think ?: How should pseundo terminals behave ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 17:33:31 -0000 On Sep 26, 2006, at 13:29 , Magnus Ringman wrote: > On 9/26/06, Brandon S. Allbery KF8NH wrote: >> >> 3a) Hangup all processes attached to the client and switch them to >> some kind of "dead" inode (which could be a fixed entity since all >> operations on it except close() fail). (Don't real ttys do this?) > > -1. > Yes and no. ttys do that on an actual hangup (when a hardware hangup > happens), however PTYs are intended to allow emulating the full > terminal line semantics, including hangup. Imo the case of "pty > master side disappearing" is equivalent to "backing device (hardware) > no longer exists", not "remote end hung up". I think that in many circumstances (and, as you note, implemented in other OSes), the correct behavior *is* to treat hangup as "backing device no longer exists" --- an older session should not leak into a newer one, it is a potential security hole and certainly a potential source of confusion. And if hardware ttys do it, I should think virtual ones should also do so for consistency. -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 17:37:05 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78D5C16A403 for ; Tue, 26 Sep 2006 17:37:05 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2738D43D49 for ; Tue, 26 Sep 2006 17:37:05 +0000 (GMT) (envelope-from bms@FreeBSD.org) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id AD6E6DA98F4; Tue, 26 Sep 2006 13:37:03 -0400 (EDT) Received: from heartbeat2.internal ([10.202.2.161]) by frontend3.internal (MEProxy); Tue, 26 Sep 2006 13:37:06 -0400 X-Sasl-enc: qf9Aiy8aSYboW/Qgfkb+RSDBS/zeaGx9ycah/3DHKr7U 1159292226 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id CEF2FAF84; Tue, 26 Sep 2006 13:37:05 -0400 (EDT) Message-ID: <4519653D.5030103@FreeBSD.org> Date: Tue, 26 Sep 2006 18:37:01 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: pyunyh@gmail.com References: <20060926002916.GA5975@cdnetworks.co.kr> In-Reply-To: <20060926002916.GA5975@cdnetworks.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 17:37:05 -0000 I have the 88E8035 in an amd64 box at home. I'll try to test this as soon as Real Life(tm) permits. BMS From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 18:09:33 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 745FD16A403 for ; Tue, 26 Sep 2006 18:09:33 +0000 (UTC) (envelope-from bmr@google.com) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7F9043D7D for ; Tue, 26 Sep 2006 18:09:29 +0000 (GMT) (envelope-from bmr@google.com) Received: from zps78.corp.google.com (zps78.corp.google.com [172.25.146.78]) by smtp-out.google.com with ESMTP id k8QI9Mv9013627 for ; Tue, 26 Sep 2006 11:09:22 -0700 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=MOxnNHLC9+4bkyUWX8eOEg7tTIuoK6AxGXNSdmGVoYF2rgAs7hTYr+Jh/w+vpxgtj DjtT/2p42hGVd7SJB6HGg== Received: from smtp-out2.google.com (fpr7.prod.google.com [10.253.18.7]) by zps78.corp.google.com with ESMTP id k8QCYhud020257 for ; Tue, 26 Sep 2006 11:09:19 -0700 Received: by smtp-out2.google.com with SMTP id 7so247525fpr for ; Tue, 26 Sep 2006 11:09:19 -0700 (PDT) Received: by 10.253.195.13 with SMTP id s13mr886322fpf; Tue, 26 Sep 2006 11:09:19 -0700 (PDT) Received: by 10.253.14.15 with HTTP; Tue, 26 Sep 2006 11:09:19 -0700 (PDT) Message-ID: <4f674ca50609261109s78a26d3dh1dd0a6dc8c112ca2@mail.google.com> Date: Tue, 26 Sep 2006 20:09:19 +0200 From: "Magnus Ringman" To: "Brandon S. Allbery KF8NH" In-Reply-To: <8EECEF0C-8C94-4A7C-862A-633F67D3D229@ece.cmu.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060926111452.J91466@godot.imp.ch> <0C4B0125-11AA-4BDB-A4E3-163A6194AB68@alumni.cwru.edu> <98FD6058-7220-48DB-AC24-F989FCB2AE11@ece.cmu.edu> <4f674ca50609261029s76432971yfc15171a3e89cb72@mail.google.com> <8EECEF0C-8C94-4A7C-862A-633F67D3D229@ece.cmu.edu> Cc: current@freebsd.org Subject: Re: What do you think ?: How should pseundo terminals behave ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 18:09:33 -0000 On 9/26/06, Brandon S. Allbery KF8NH wrote: > > On Sep 26, 2006, at 13:29 , Magnus Ringman wrote: > > > On 9/26/06, Brandon S. Allbery KF8NH wrote: > >> > >> 3a) Hangup all processes attached to the client and switch them to > >> some kind of "dead" inode (which could be a fixed entity since all > >> operations on it except close() fail). (Don't real ttys do this?) > > > > -1. > > Yes and no. ttys do that on an actual hangup (when a hardware hangup > > happens), however PTYs are intended to allow emulating the full > > terminal line semantics, including hangup. Imo the case of "pty > > master side disappearing" is equivalent to "backing device (hardware) > > no longer exists", not "remote end hung up". > > I think that in many circumstances (and, as you note, implemented in > other OSes), the correct behavior *is* to treat hangup as "backing > device no longer exists" --- an older session should not leak into a > newer one, it is a potential security hole and certainly a potential > source of confusion. And if hardware ttys do it, I should think > virtual ones should also do so for consistency. Methinks Sir has it the wrong way around! Hangup on a hardware device -doesn't- void a program's access to the device. It just (optionally) sends the process a SIGHUP. That is why somebody (iirc, for SunOS < 5) invented vhangup(2) as a means for a new session owner to insure it was the only process using the terminal. With ptys, we have a different problem, namely non-persistent "hardware" (xterms, remote connections, "screen" sessions etc.) that when they are instantiated are absolutely interested in (1) insuring that the slave-side program is just the one intended, and (2) in some cases, the ability to send terminal-flavored signals to the process without voiding its file descriptor. B From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 18:13:24 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89D6916A403 for ; Tue, 26 Sep 2006 18:13:24 +0000 (UTC) (envelope-from allbery@ece.cmu.edu) Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 24C1A43D49 for ; Tue, 26 Sep 2006 18:13:24 +0000 (GMT) (envelope-from allbery@ece.cmu.edu) Received: by bache.ece.cmu.edu (Postfix, from userid 953) id 6BB4FA5; Tue, 26 Sep 2006 14:13:23 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on filt2.ece.cmu.edu X-Spam-Level: * X-Spam-Status: No, score=1.0 required=6.0 tests=BAYES_60 autolearn=no version=3.1.4 Received: from [10.9.204.128] (dsl093-061-215.pit1.dsl.speakeasy.net [66.93.61.215]) by bache.ece.cmu.edu (Postfix) with ESMTP id 46CA69E; Tue, 26 Sep 2006 14:13:21 -0400 (EDT) In-Reply-To: <4f674ca50609261109s78a26d3dh1dd0a6dc8c112ca2@mail.google.com> References: <20060926111452.J91466@godot.imp.ch> <0C4B0125-11AA-4BDB-A4E3-163A6194AB68@alumni.cwru.edu> <98FD6058-7220-48DB-AC24-F989FCB2AE11@ece.cmu.edu> <4f674ca50609261029s76432971yfc15171a3e89cb72@mail.google.com> <8EECEF0C-8C94-4A7C-862A-633F67D3D229@ece.cmu.edu> <4f674ca50609261109s78a26d3dh1dd0a6dc8c112ca2@mail.google.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Brandon S. Allbery KF8NH" Date: Tue, 26 Sep 2006 14:13:18 -0400 To: "Magnus Ringman" X-Mailer: Apple Mail (2.752.2) Cc: current@freebsd.org Subject: Re: What do you think ?: How should pseundo terminals behave ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 18:13:24 -0000 On Sep 26, 2006, at 14:09 , Magnus Ringman wrote: > On 9/26/06, Brandon S. Allbery KF8NH wrote: >> I think that in many circumstances (and, as you note, implemented in >> other OSes), the correct behavior *is* to treat hangup as "backing >> device no longer exists" --- an older session should not leak into a >> newer one, it is a potential security hole and certainly a potential >> source of confusion. And if hardware ttys do it, I should think >> virtual ones should also do so for consistency. > > Methinks Sir has it the wrong way around! > Hangup on a hardware device -doesn't- void a program's access to the > device. It just (optionally) sends the process a SIGHUP. That is why > somebody (iirc, for SunOS < 5) invented vhangup(2) as a means for a > new session owner to insure it was the only process using the > terminal. I think you misunderstood: yes, physically you do not lose access, but for security reasons *logically you should*, and that is why vhangup() was invented. And, this being done, it is also a reasonable --- and, more to the point, consistent --- model for what happens when a pty slave loses its master (which *is* equivalent to physically losing access). -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 18:21:27 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B2BF16A519 for ; Tue, 26 Sep 2006 18:21:27 +0000 (UTC) (envelope-from bmr@google.com) Received: from smtp-out.google.com (smtp-out.google.com [216.239.45.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id F030743D4C for ; Tue, 26 Sep 2006 18:21:26 +0000 (GMT) (envelope-from bmr@google.com) Received: from zps37.corp.google.com (zps37.corp.google.com [172.25.146.37]) by smtp-out.google.com with ESMTP id k8QILQRs004272 for ; Tue, 26 Sep 2006 11:21:26 -0700 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=gDQjtI4gxQK0G9OwAd04jQTD7s8gTXjky740tGkefABQhLyuxUZhkysborqHPqwSA aMxoikITwS/ABn55A4sJA== Received: from smtp-out2.google.com (fpr16.prod.google.com [10.253.18.16]) by zps37.corp.google.com with ESMTP id k8QI4NeP000939 for ; Tue, 26 Sep 2006 11:21:22 -0700 Received: by smtp-out2.google.com with SMTP id 16so243080fpr for ; Tue, 26 Sep 2006 11:21:22 -0700 (PDT) Received: by 10.253.16.13 with SMTP id 13mr892296fpp; Tue, 26 Sep 2006 11:21:22 -0700 (PDT) Received: by 10.253.14.15 with HTTP; Tue, 26 Sep 2006 11:21:17 -0700 (PDT) Message-ID: <4f674ca50609261121v5ed0b2dalad3607634c965271@mail.google.com> Date: Tue, 26 Sep 2006 20:21:17 +0200 From: "Magnus Ringman" To: "Brandon S. Allbery KF8NH" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060926111452.J91466@godot.imp.ch> <0C4B0125-11AA-4BDB-A4E3-163A6194AB68@alumni.cwru.edu> <98FD6058-7220-48DB-AC24-F989FCB2AE11@ece.cmu.edu> <4f674ca50609261029s76432971yfc15171a3e89cb72@mail.google.com> <8EECEF0C-8C94-4A7C-862A-633F67D3D229@ece.cmu.edu> <4f674ca50609261109s78a26d3dh1dd0a6dc8c112ca2@mail.google.com> Cc: current@freebsd.org Subject: Re: What do you think ?: How should pseundo terminals behave ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 18:21:27 -0000 On 9/26/06, Brandon S. Allbery KF8NH wrote: > > On Sep 26, 2006, at 14:09 , Magnus Ringman wrote: > > > Methinks Sir has it the wrong way around! > > Hangup on a hardware device -doesn't- void a program's access to the > > device. It just (optionally) sends the process a SIGHUP. That is why > > somebody (iirc, for SunOS < 5) invented vhangup(2) as a means for a > > new session owner to insure it was the only process using the > > terminal. > > I think you misunderstood: yes, physically you do not lose access, > but for security reasons *logically you should*, and that is why > vhangup() was invented. And, this being done, it is also a > reasonable --- and, more to the point, consistent --- model for what > happens when a pty slave loses its master (which *is* equivalent to > physically losing access). Ah, yes - my bad. We agree! My poor brain stem objected to the use of SIGHUP for losing master, on grounds that a hangup is a perfetly valid terminal event. Invalidating the fd is the important point. Magnus From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 17:02:58 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA7DF16A407; Tue, 26 Sep 2006 17:02:58 +0000 (UTC) (envelope-from mi+mx@aldan.algebra.com) Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2BA643D99; Tue, 26 Sep 2006 17:02:47 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from [172.21.130.86] (mx-broadway [38.98.68.18]) by corbulon.video-collage.com (8.13.6/8.13.6) with ESMTP id k8QH2kB7084419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Sep 2006 13:02:46 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) From: Mikhail Teterin Organization: Virtual Estates, Inc. To: Andrey Chernov Date: Tue, 26 Sep 2006 13:02:40 -0400 User-Agent: KMail/1.9.1 References: <200609202304.25537@aldan> <20060921154412.GA59729@nagual.pp.ru> In-Reply-To: <20060921154412.GA59729@nagual.pp.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200609261302.40964.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV 0.88.4/1946/Tue Sep 26 09:18:37 2006 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 X-Mailman-Approved-At: Tue, 26 Sep 2006 18:23:21 +0000 Cc: current@freebsd.org, tjr@freebsd.org Subject: Re: replacing FreeBSD's -lgnuregex with GNUlib's version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 17:02:58 -0000 Any news on this? -mi четвер 21 вересень 2006 11:44, Andrey Chernov написав: > On Wed, Sep 20, 2006 at 11:04:24PM -0400, Mikhail Teterin wrote: > > A recent discussion on the gm4 and gnulib mailing lists over the merits > > of gm4's bundling of its own regex implementation has produced the > > suggestion, that we replace our src/gnu/lib/libregex (which is currently > > obtained from fedora-glibc-2_3_4-21) with gnulib's implementation. > > > > The latter is claimed to be more actively maintained and with more bug > > fixes, than glibc people have managed to incorporate. > > > > Does anyone have a strong preference for fedora/glibc implementation > > currently in use, or should we follow this advice (source -- regex' > > maintainer for gnulib -- CC-ed) and switch over? > > Please point to gnulib's regex sources to compare with. From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 18:23:45 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D51C16A580 for ; Tue, 26 Sep 2006 18:23:45 +0000 (UTC) (envelope-from allbery@ece.cmu.edu) Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1427E43D53 for ; Tue, 26 Sep 2006 18:23:45 +0000 (GMT) (envelope-from allbery@ece.cmu.edu) Received: by bache.ece.cmu.edu (Postfix, from userid 953) id 65987A5; Tue, 26 Sep 2006 14:23:44 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on filt1.ece.cmu.edu X-Spam-Level: X-Spam-Status: No, score=0.0 required=6.0 tests=BAYES_50 autolearn=no version=3.1.4 Received: from [10.9.204.128] (dsl093-061-215.pit1.dsl.speakeasy.net [66.93.61.215]) by bache.ece.cmu.edu (Postfix) with ESMTP id 5C2B2A4; Tue, 26 Sep 2006 14:23:42 -0400 (EDT) In-Reply-To: <4f674ca50609261121v5ed0b2dalad3607634c965271@mail.google.com> References: <20060926111452.J91466@godot.imp.ch> <0C4B0125-11AA-4BDB-A4E3-163A6194AB68@alumni.cwru.edu> <98FD6058-7220-48DB-AC24-F989FCB2AE11@ece.cmu.edu> <4f674ca50609261029s76432971yfc15171a3e89cb72@mail.google.com> <8EECEF0C-8C94-4A7C-862A-633F67D3D229@ece.cmu.edu> <4f674ca50609261109s78a26d3dh1dd0a6dc8c112ca2@mail.google.com> <4f674ca50609261121v5ed0b2dalad3607634c965271@mail.google.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Brandon S. Allbery KF8NH" Date: Tue, 26 Sep 2006 14:23:38 -0400 To: "Magnus Ringman" X-Mailer: Apple Mail (2.752.2) Cc: current@freebsd.org Subject: Re: What do you think ?: How should pseundo terminals behave ... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 18:23:45 -0000 On Sep 26, 2006, at 14:21 , Magnus Ringman wrote: > Ah, yes - my bad. We agree! > My poor brain stem objected to the use of SIGHUP for losing master, on > grounds that a hangup is a perfetly valid terminal event. > Invalidating the fd is the important point. Yeh, I was unclear: I said "hangup", intending not SIGHUP but vhangup () (but recalling that freebsd doesn't do vhangup() so not calling it such). -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 18:30:08 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B7D4116A518; Tue, 26 Sep 2006 18:30:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96D4543D5E; Tue, 26 Sep 2006 18:29:47 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k8QITYwW050196; Tue, 26 Sep 2006 14:29:35 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 26 Sep 2006 14:19:51 -0400 User-Agent: KMail/1.9.1 References: <4511B9B1.2000903@freebsd.org> <17683.63162.919620.114649@grasshopper.cs.duke.edu> In-Reply-To: <17683.63162.919620.114649@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609261419.52303.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 26 Sep 2006 14:29:35 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1946/Tue Sep 26 09:18:37 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: alc@freebsd.org, freebsd-net@freebsd.org, Andre Oppermann , Andrew Gallatin , tegge@freebsd.org Subject: Re: Much improved sendfile(2) kernel implementation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 18:30:08 -0000 On Friday 22 September 2006 10:44, Andrew Gallatin wrote: > > Between TSO and your sendfile changes, things are looking up! > > Here are some Myri10GbE 1500 byte results from a 1.8GHz UP > FreeBSD/amd64 machine (AMD Athlon(tm) 64 Processor 3000+) sending to a > 2.0GHz SMP Linux/x86_64 machine (AMD Athlon(tm) 64 X2 Dual Core Processor > 3800+) running 26.17.7smp and our 1.1.0 Myri10GE driver (with LRO). > I used a linux receiver because LRO is the only way to receive > standard frames at line rate (without a TOE). > > These tests are all for sendfile of a 10MB file in /var/tmp: > > % netperf242 -Hrome-my -tTCP_SENDFILE -F /var//tmp/zot -T,1 -c -C -- -s393216 > > The -T,1 is required to force the netserver to use a different core > than the interrupt handler is bound to on the linux machine. BTW, > it would be really nice if FreeBSD supported CPU affinity for processes > and interrupt handlers.. You can get some of that with www.freebsd.org/~jhb/patches/intr_bind.patch That binds interrupt threads to the CPUs the IDT vector is bound to and adds a sysarch() so you can move them around. I had a simple test program to do that but don't have access to it currently. I've tested this on i386 and amd64, but haven't benchmarked it. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 18:45:24 2006 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBE0816A523; Tue, 26 Sep 2006 18:45:06 +0000 (UTC) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (nagual.pp.ru [194.87.13.69]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28A7343D8C; Tue, 26 Sep 2006 18:45:01 +0000 (GMT) (envelope-from ache@nagual.pp.ru) Received: from nagual.pp.ru (ache@localhost [127.0.0.1]) by nagual.pp.ru (8.13.8/8.13.8) with ESMTP id k8QIil5s017944; Tue, 26 Sep 2006 22:44:47 +0400 (MSD) (envelope-from ache@nagual.pp.ru) Received: (from ache@localhost) by nagual.pp.ru (8.13.8/8.13.8/Submit) id k8QIilxX017943; Tue, 26 Sep 2006 22:44:47 +0400 (MSD) (envelope-from ache) Date: Tue, 26 Sep 2006 22:44:47 +0400 From: Andrey Chernov To: Mikhail Teterin Message-ID: <20060926184447.GA17862@nagual.pp.ru> Mail-Followup-To: Andrey Chernov , Mikhail Teterin , current@FreeBSD.ORG, tjr@FreeBSD.ORG References: <200609202304.25537@aldan> <20060921154412.GA59729@nagual.pp.ru> <200609261302.40964.mi+mx@aldan.algebra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200609261302.40964.mi+mx@aldan.algebra.com> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: current@FreeBSD.ORG, tjr@FreeBSD.ORG Subject: Re: replacing FreeBSD's -lgnuregex with GNUlib's version X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 18:45:24 -0000 On Tue, Sep 26, 2006 at 01:02:40PM -0400, Mikhail Teterin wrote: > Any news on this? I basically look at locale stuff, they sypport multibyte which is good. Someone must test its compatibility with GNU regex and understand in details nature of their changes/fixes/differences. Without this work we can't blindly replace stable code with unknown one just for reason it is actively maintained. > > On Wed, Sep 20, 2006 at 11:04:24PM -0400, Mikhail Teterin wrote: > > > A recent discussion on the gm4 and gnulib mailing lists over the merits > > > of gm4's bundling of its own regex implementation has produced the > > > suggestion, that we replace our src/gnu/lib/libregex (which is currently > > > obtained from fedora-glibc-2_3_4-21) with gnulib's implementation. > > > > > > The latter is claimed to be more actively maintained and with more bug > > > fixes, than glibc people have managed to incorporate. > > > > > > Does anyone have a strong preference for fedora/glibc implementation > > > currently in use, or should we follow this advice (source -- regex' > > > maintainer for gnulib -- CC-ed) and switch over? > > > > Please point to gnulib's regex sources to compare with. -- http://ache.pp.ru/ From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 22:24:04 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFAA116A40F for ; Tue, 26 Sep 2006 22:24:04 +0000 (UTC) (envelope-from nullpt@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id D060143D45 for ; Tue, 26 Sep 2006 22:24:03 +0000 (GMT) (envelope-from nullpt@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so597772uge for ; Tue, 26 Sep 2006 15:24:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=DYzltk7rdpq2b9UX5/6EzzSp63HFY4tLWkBO8l+P68XYYyiflBBAL14EhKOtGHGJZqbAHKm+VTXtagPm5ES/BLHMXcur41GtMnYq8TzQ3P5YBrtma0Sd9CZnnNKtqDyhSqOOrCulbby99aB1Sxn+0ZCWK0m587LAjMmN0HGm/mg= Received: by 10.67.100.17 with SMTP id c17mr1148595ugm; Tue, 26 Sep 2006 15:24:02 -0700 (PDT) Received: by 10.66.237.20 with HTTP; Tue, 26 Sep 2006 15:24:02 -0700 (PDT) Message-ID: <755cb9fc0609261524k15b096afofa06f40a4002cd49@mail.gmail.com> Date: Tue, 26 Sep 2006 23:24:02 +0100 From: "Alexandre Vieira" To: freebsd-current@freebsd.org In-Reply-To: <20060926083828.GZ4945@poupinou.org> MIME-Version: 1.0 References: <755cb9fc0609251042h163ff7f1l4e96369ed7bd0106@mail.gmail.com> <20060926083828.GZ4945@poupinou.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Acer Aspire 1644WLMi -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2006 22:24:04 -0000 Hello, Thanks for your reply. You can find the .asl here: http://nullpt.googlepages.com/Acer_Aspire_1644WLMi.asl Regards, On 9/26/06, Bruno Ducrot wrote: > > On Mon, Sep 25, 2006 at 06:42:43PM +0100, Alexandre Vieira wrote: > > Hello folks, > > > > I just went -CURRENT for the first time and everything seems fairly > equal to > > 6.1-STABLE. > > > > I have an Acer Aspire 1644WLMi. > > > > ACPI doesn't seem to work very well. I have many messages in dmesg > > complaining about acpi. > > Could you please run > acpidump -t -d > Acer_Aspire_1644WLMi.asl > and give a link to this file somewhere on the web? > > This problem is well known, and I think FreeBSD will support your > laptop in the near future. In the meantime we can workaround this > problem by modifiying a little the AML of the DSDT. > > > I had kde working but since the upgrade it's broken. I've tried to > recompile > > it but im having troubles compiling some ports (altough it seems > application > > specific,, i.e pilot-link/libmal) . I did no change to my 6-stable > kernel. > > > > Is there anything I have to take in consideration in -CURRENT regarding > > compilations? > > > > Also, does anyone know if an intel high definition audio driver exists > in > > -CURRENT? Nothing seems to grab the sound card and I cant find a > suitable > > module for it. > > I've heard there is one in developpment, but I let other to answer since > I don't know so much. > > > > > > > I'm sorry for any eventual dumminess coming out of my fingers and thank > you > > very much for your itme. > > > > Regards, > > -- > > Alexandre Vieira - nullpt@gmail.com > > > -- > Bruno Ducrot > > -- Which is worse: ignorance or apathy? > -- Don't know. Don't care. > -- Alexandre Vieira - nullpt@gmail.com From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 22:27:43 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2BE8316A403 for ; Tue, 26 Sep 2006 22:27:43 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id 592B843D5A for ; Tue, 26 Sep 2006 22:27:42 +0000 (GMT) (envelope-from lars@e.0x20.net) Received: by mail.0x20.net (Postfix, from userid 1002) id C001833E8E; Wed, 27 Sep 2006 00:27:40 +0200 (CEST) Date: Wed, 27 Sep 2006 00:27:40 +0200 From: Lars Engels To: current@freebsd.org Message-ID: <20060926222740.GF6216@e.0x20.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gneEPciiIl/aKvOT" Content-Disposition: inline X-Editor: VIM - Vi IMproved 7.0 User-Agent: Mutt/1.5.11 Cc: Subject: Atheros PCCard recognized, IRQ Problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 22:27:43 -0000 --gneEPciiIl/aKvOT Content-Type: multipart/mixed; boundary="8vCeF2GUdMpe9ZbK" Content-Disposition: inline --8vCeF2GUdMpe9ZbK Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, when I insert a Netgear WAG511 Atheros-based PCCard into my notebook, the speakers crackle two times and nothing else happens. dmesg does not show anything. The card itself is works in Windows and used to work in another FreeBSD notebook. The PCCard Bus is also functioning, a wi(4) card is recognized and can be used. Searching the web and mailing list archives didn't show a similar issue. Could it be an IRQ or ACPI issue? I use a current with today's sources and attached you find the output of dmesg with the atheros card inserted, as well as vmstat -i output and pciconf -lv. Any help is appreciated. Thank you in advance! --=20 Lars Engels E-Mail: lars.engels@0x20.net =09 Mobil: +49 172 266 72 73 --8vCeF2GUdMpe9ZbK Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: attachment; filename="dmesg.boot" Content-Transfer-Encoding: quoted-printable Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #7: Tue Sep 26 18:00:51 CEST 2006 lars@maggie.bsd-geek.de:/usr/obj/usr/src/sys/MAGGIE WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. ACPI APIC Table: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Genuine Intel(R) CPU T2300 @ 1.66GHz (1662.51-MHz 686-class= CPU) Origin =3D "GenuineIntel" Id =3D 0x6e8 Stepping =3D 8 Features=3D0xbfe9fbff Features2=3D0xc189> AMD Features=3D0x100000 Cores per package: 2 real memory =3D 1063845888 (1014 MB) avail memory =3D 1031749632 (983 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ACPI-0390: *** Info: Table [SSDT] replaced by host OS ACPI: overriding DSDT/SSDT with custom table ACPI-0390: *** Info: Table [DSDT] replaced by host OS ioapic0: Changing APIC ID to 1 ioapic0 irqs 0-23 on motherboard wlan: mac acl policy registered kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_ec0: port 0x62,0x66 on acpi0 cpu0: on acpi0 est0: on cpu0 p4tcc0: on cpu0 cpu1: on acpi0 est1: on cpu1 p4tcc1: on cpu1 acpi_acad0: on acpi0 battery0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0x1800-0x1807 mem 0xd8100000-0xd817f= fff,0xc0000000-0xcfffffff,0xd8200000-0xd823ffff irq 16 at device 2.0 on pci0 drm0: on vgapci0 error: [drm:pid0:drm_load] *ERROR* Card isn't AGP, or couldn't initialize A= GP. device_attach: drm0 attach returned 12 vgapci1: mem 0xd8180000-0xd81fffff at device 2.1 o= n pci0 pci0: at device 27.0 (no driver attached) pcib1: irq 17 at device 28.0 on pci0 pci2: on pcib1 wpi0: mem 0xd4000000-0xd4000fff irq 16 at d= evice 0.0 on pci2 channel 1 pwr1 0x0060 pwr2 0x005e channel 2 pwr1 0x0068 pwr2 0x0064 channel 3 pwr1 0x0099 pwr2 0x009a channel 4 pwr1 0x0092 pwr2 0x0096 channel 5 pwr1 0x0000 pwr2 0x0000 channel 6 pwr1 0x0082 pwr2 0x0082 channel 7 pwr1 0x0082 pwr2 0x0083 channel 8 pwr1 0x007d pwr2 0x007d channel 9 pwr1 0x007d pwr2 0x007d channel 10 pwr1 0x0000 pwr2 0x0000 channel 11 pwr1 0xfffb pwr2 0xfffb channel 12 pwr1 0x0001 pwr2 0x0001 channel 13 pwr1 0xfffb pwr2 0xfffb channel 14 pwr1 0x0001 pwr2 0x0001 wpi0: Ethernet address: 00:13:02:3f:0d:e4 wpi0: [GIANT-LOCKED] pcib2: irq 16 at device 28.1 on pci0 pci3: on pcib2 uhci0: port 0x1820-0x183f irq 23 at device = 29.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 2 ports with 2 removable, self powered uhci1: port 0x1840-0x185f irq 19 at device = 29.1 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: on usb1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1860-0x187f irq 18 at device = 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: on usb2 uhub2: 2 ports with 2 removable, self powered uhci3: port 0x1880-0x189f irq 16 at device = 29.3 on pci0 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: on usb3 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xd8444000-0xd84443f= f irq 23 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: on usb4 uhub4: 8 ports with 8 removable, self powered usb4: handing over full speed device on port 5 to usb2 uhub4: port 5, device disappeared after reset pcib3: at device 30.0 on pci0 pci5: on pcib3 bfe0: mem 0xd8000000-0xd8001fff irq 22 = at device 5.0 on pci5 miibus0: on bfe0 bmtphy0: on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: Ethernet address: 00:00:f0:7f:da:00 bfe0: [GIANT-LOCKED] cbb0: at device 9.0 on pci5 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 fwohci0: mem 0xd8002000-0xd80027ff at device 9.1 on pci5 fwohci0: [GIANT-LOCKED] fwohci0: OHCI version 1.0 (ROM=3D1) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 00:00:f0:41:20:0f:ab:79 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 02:00:f0:0f:ab:79 fwe0: Ethernet address: 02:00:f0:0f:ab:79 sbp0: on firewire0 fwohci0: Initiate bus reset fwohci0: node_id=3D0xc800ffc0, gen=3D1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <=3D 0, cable IRM =3D 0 (me) firewire0: bus manager 0 (me) pci5: at device 9.2 (no driver attached) pci5: at device 9.3 (no driver attached) pci5: at device 9.4 (no driver attached) pci5: at device 9.5 (no driver attached) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177= ,0x376,0x1810-0x181f at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pci0: at device 31.3 (no driver attached) acpi_tz0: on acpi0 acpi_tz1: on acpi0 acpi_hpet0: iomem 0xfed00000-0xfed003ff on acp= i0 Timecounter "HPET" frequency 14318180 Hz quality 2000 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 pmtimer0 on isa0 orm0: at iomem 0xdc000-0xdffff pnpid ORM0000 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 ppc0: parallel port not found. sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 8250 or not responding sio0: [FAST] sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled ugen0: on uhub2 Timecounters tick every 1.000 msec IPsec: Initialized Security Association Processing. ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding enabled, = default to accept, logging disabled ad0: 69042MB at ata0-master UDMA100 acd0: DVDR at ata0-slave UDMA33 SMP: AP CPU #1 Launched! cd0 at ata0 bus 0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device=20 cd0: 33.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - t= ray closed Trying to mount root from ufs:/dev/ad0s3a setting h/w config 1200 microcode alive notification version 10d00 alive 1 temperature -192 scan finished rx tail flags error 702 scan finished wpi0: fatal firmware error wpi0: timeout resetting Rx ring setting h/w config 1200 microcode alive notification version 10d00 alive 1 temperature -195 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 rx tail flags error 702 --8vCeF2GUdMpe9ZbK Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: attachment; filename=vmstat-i interrupt total rate irq1: atkbd0 3360 2 irq9: acpi0 1296 0 irq12: psm0 16636 12 irq14: ata0 8030 5 irq16: wpi0 uhci3 32488 23 irq18: uhci2 1 0 irq20: cbb0 4 0 irq21: fwohci0 1 0 irq22: pcm0 bfe0 2 0 irq23: uhci0 ehci0 1 0 cpu0: timer 2733760 1999 cpu1: timer 2723846 1992 Total 5519425 4037 --8vCeF2GUdMpe9ZbK Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: attachment; filename=pciconf-lv hostb0@pci0:0:0: class=0x060000 card=0xc504144d chip=0x27a08086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = bridge subclass = HOST-PCI vgapci0@pci0:2:0: class=0x030000 card=0xc504144d chip=0x27a28086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = display subclass = VGA vgapci1@pci0:2:1: class=0x038000 card=0xc504144d chip=0x27a68086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' class = display pcm0@pci0:27:0: class=0x040300 card=0xc504144d chip=0x27d88086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) High Definition Audio' class = multimedia pcib1@pci0:28:0: class=0x060400 card=0x00000040 chip=0x27d08086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCI Express Root Port' class = bridge subclass = PCI-PCI pcib2@pci0:28:1: class=0x060400 card=0x00000040 chip=0x27d28086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) PCI Express Root Port' class = bridge subclass = PCI-PCI uhci0@pci0:29:0: class=0x0c0300 card=0xc504144d chip=0x27c88086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci1@pci0:29:1: class=0x0c0300 card=0xc504144d chip=0x27c98086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci2@pci0:29:2: class=0x0c0300 card=0xc504144d chip=0x27ca8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB uhci3@pci0:29:3: class=0x0c0300 card=0xc504144d chip=0x27cb8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB Universal Host Controller' class = serial bus subclass = USB ehci0@pci0:29:7: class=0x0c0320 card=0xc504144d chip=0x27cc8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) USB 2.0 Enhanced Host Controller' class = serial bus subclass = USB pcib3@pci0:30:0: class=0x060401 card=0x00000050 chip=0x24488086 rev=0xe2 hdr=0x01 vendor = 'Intel Corporation' device = '82801BAM/CAM/DBM (ICH2-M/3-M/4-M) Hub Interface to PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:31:0: class=0x060100 card=0xc504144d chip=0x27b98086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801GBM (ICH7-M) LPC Interface Controller' class = bridge subclass = PCI-ISA atapci0@pci0:31:1: class=0x01018a card=0xc504144d chip=0x27df8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) Ultra ATA Storage Controller' class = mass storage subclass = ATA none0@pci0:31:3: class=0x0c0500 card=0xc504144d chip=0x27da8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801G (ICH7 Family) SMBus Controller' class = serial bus subclass = SMBus wpi0@pci2:0:0: class=0x028000 card=0x10018086 chip=0x42228086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' class = network bfe0@pci5:5:0: class=0x020000 card=0xc504144d chip=0x170c14e4 rev=0x02 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM440x 100Base-TX Fast Ethernet' class = network subclass = ethernet cbb0@pci5:9:0: class=0x060700 card=0xc504144d chip=0x04761180 rev=0xb4 hdr=0x02 vendor = 'Ricoh Co Ltd' device = 'RL5c476 CardBus Controller' class = bridge subclass = PCI-CardBus fwohci0@pci5:9:1: class=0x0c0010 card=0xc024144d chip=0x05521180 rev=0x09 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'RL5c552 IEEE-1394 Controller' class = serial bus subclass = FireWire none1@pci5:9:2: class=0x080500 card=0xc024144d chip=0x08221180 rev=0x18 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'SD Bus Host Adapter' class = base peripheral none2@pci5:9:3: class=0x088000 card=0xc024144d chip=0x08431180 rev=0x00 hdr=0x00 vendor = 'Ricoh Co Ltd' class = base peripheral none3@pci5:9:4: class=0x088000 card=0xc024144d chip=0x05921180 rev=0x09 hdr=0x00 vendor = 'Ricoh Co Ltd' device = 'Memory Stick Bus Host Adapter' class = base peripheral none4@pci5:9:5: class=0x088000 card=0xc024144d chip=0x08521180 rev=0x04 hdr=0x00 vendor = 'Ricoh Co Ltd' class = base peripheral --8vCeF2GUdMpe9ZbK-- --gneEPciiIl/aKvOT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFGalcKc512sD3afgRAopGAKC0neigHv1slK+vpYGH4JByHV47dACcDHZW 5/6yNDDsM97Ne4yp3E0n9DU= =pcu/ -----END PGP SIGNATURE----- --gneEPciiIl/aKvOT-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 22:42:55 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 50FC416A403 for ; Tue, 26 Sep 2006 22:42:55 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE8E443D45 for ; Tue, 26 Sep 2006 22:42:54 +0000 (GMT) (envelope-from lars@e.0x20.net) Received: by mail.0x20.net (Postfix, from userid 1002) id F24F533F56; Wed, 27 Sep 2006 00:42:53 +0200 (CEST) Date: Wed, 27 Sep 2006 00:42:53 +0200 From: Lars Engels To: current@freebsd.org Message-ID: <20060926224253.GG6216@e.0x20.net> References: <20060926222740.GF6216@e.0x20.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="APlYHCtpeOhspHkB" Content-Disposition: inline In-Reply-To: <20060926222740.GF6216@e.0x20.net> X-Editor: VIM - Vi IMproved 7.0 User-Agent: Mutt/1.5.11 Cc: Subject: Re: Atheros PCCard _not_ recognized, IRQ Problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 22:42:55 -0000 --APlYHCtpeOhspHkB Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Sorry, I forgot one little word in the subject... --APlYHCtpeOhspHkB Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFGaztKc512sD3afgRAtEKAJ0e8q9VOHq0aXS4Al4zpkhgquwuagCeKWc7 NTDgxBI7r590eK4JDvkMvuo= =3tQc -----END PGP SIGNATURE----- --APlYHCtpeOhspHkB-- From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 22:51:30 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F12EE16A415 for ; Tue, 26 Sep 2006 22:51:30 +0000 (UTC) (envelope-from nullpt@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D92E43D49 for ; Tue, 26 Sep 2006 22:51:29 +0000 (GMT) (envelope-from nullpt@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so599497uge for ; Tue, 26 Sep 2006 15:51:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=md9tvSHDbCxKMT67YgZJYVeaOWpOFWjVI4T4OUiAPAJ/2TL8a/Kaomr2bK+QXwjZWNLG9W0xRKY56jyD/KUdzn99hrSiLbfkqBhzv64vYxowiek35XniyCEMyQppxSaPaXuXzcq7n8VnfoE2V42gUZw+l9qK2H1GoXpTu2kZkvQ= Received: by 10.67.105.19 with SMTP id h19mr18690ugm; Tue, 26 Sep 2006 15:51:28 -0700 (PDT) Received: by 10.66.237.20 with HTTP; Tue, 26 Sep 2006 15:51:27 -0700 (PDT) Message-ID: <755cb9fc0609261551g6a97bdd2s64b4b2fada65cb03@mail.gmail.com> Date: Tue, 26 Sep 2006 23:51:27 +0100 From: "Alexandre Vieira" To: freebsd-current@freebsd.org, freebsd-multimedia@freebsd.org In-Reply-To: <1159207411.670.3.camel@localhost> MIME-Version: 1.0 References: <755cb9fc0609251042h163ff7f1l4e96369ed7bd0106@mail.gmail.com> <1159207411.670.3.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Acer Aspire 1644WLMi -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2006 22:51:31 -0000 Hello, I downloaded the latest hdac driver from Ariff's and i'm unable to play any sound :( When I load the module: pcm0: mem 0xd000c000-0xd000ffff at device 27.0 on pci0 pcm0: pcm0: Mixer: Mixer vol is currently set to 100:100 Mixer pcm is currently set to 100:100 Recording source: mic /dev/sndstat Installed devices: pcm0: at memory 0xd000c000 irq 16 kld snd_hda [20060924_023] (1p/0r/1v channels default) pciconf -lv http://nullpt.googlepages.com/pciconf.txt I set it to 100 and plugged in an headset but can't hear anything. Is there any low level way I can test this? I'm afraid that there might be some trick with this laptop (key combination or smth) that im missing. Thanks in advance :) On 9/25/06, Joel Dahl wrote: > > On Mon, 2006-09-25 at 18:42 +0100, Alexandre Vieira wrote: > > Hello folks, > > > > I just went -CURRENT for the first time and everything seems fairly > equal to > > 6.1-STABLE. > > > > I have an Acer Aspire 1644WLMi. > > > > ACPI doesn't seem to work very well. I have many messages in dmesg > > complaining about acpi. > > > > I had kde working but since the upgrade it's broken. I've tried to > recompile > > it but im having troubles compiling some ports (altough it seems > application > > specific,, i.e pilot-link/libmal) . I did no change to my 6-stable > kernel. > > > > Is there anything I have to take in consideration in -CURRENT regarding > > compilations? > > > > Also, does anyone know if an intel high definition audio driver exists > in > > -CURRENT? Nothing seems to grab the sound card and I cant find a > suitable > > module for it. > > http://people.freebsd.org/~ariff/HDA/ > > Also, read the multimedia@ archives and report bugs to ariff@. > #freebsd-azalia @ freenode is a nice channel for everything related to > HDA in FreeBSD > > -- > Joel > > -- Alexandre Vieira - nullpt@gmail.com From owner-freebsd-current@FreeBSD.ORG Tue Sep 26 23:17:20 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7547616A403 for ; Tue, 26 Sep 2006 23:17:20 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11D7543D68 for ; Tue, 26 Sep 2006 23:17:17 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([165.236.175.187]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k8QNH9Vs015216; Tue, 26 Sep 2006 17:17:15 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4519B4EF.401@samsco.org> Date: Tue, 26 Sep 2006 17:17:03 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Mikko_Ty=F6l=E4j=E4rvi?= References: <20060924151759.D788@antec.home> In-Reply-To: <20060924151759.D788@antec.home> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: current@freebsd.org Subject: Re: i386/busmda_machdep.c 1.81 broke if_bfe X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 26 Sep 2006 23:17:20 -0000 I just committed a fix for this. Thanks for bringing up the problem. Scott Mikko TyЖlДjДrvi wrote: > Hi, > > It seems to me that with version 1.81 of i386/busdma_machdep.c devices > that need bounce buffers, but do not use a filter function, will no > longer work. > > The run_filter() function contains the logic to detect if a bounce > buffer is needed also when there is no filter function, so I believe > it has to be called for devices that are marked as BUS_DMA_COULD_BOUNCE > as well as for those that provide a filter function. > > For example, this makes my bfe0 interface work again: > > Index: busdma_machdep.c > =================================================================== > RCS file: /net/cvs/home/ncvs/src/sys/i386/i386/busdma_machdep.c,v > retrieving revision 1.83 > diff -u -b -r1.83 busdma_machdep.c > --- busdma_machdep.c 24 Sep 2006 19:24:26 -0000 1.83 > +++ busdma_machdep.c 24 Sep 2006 21:45:39 -0000 > @@ -286,7 +286,7 @@ > > if (newtag->lowaddr < ptoa((vm_paddr_t)Maxmem) > || newtag->alignment > 1) > - newtag->flags |= BUS_DMA_COULD_BOUNCE; > + newtag->flags |= BUS_DMA_COULD_BOUNCE | BUS_DMA_USE_FILTER; > > if (((newtag->flags & BUS_DMA_COULD_BOUNCE) != 0) && > (flags & BUS_DMA_ALLOCNOW) != 0) { > > > $.02, > /Mikko > From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 00:12:19 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3832F16A47E; Wed, 27 Sep 2006 00:12:19 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBB4543D53; Wed, 27 Sep 2006 00:12:18 +0000 (GMT) (envelope-from ariff@FreeBSD.org) Received: from misaki (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with SMTP id k8R0CG9o007606; Wed, 27 Sep 2006 00:12:17 GMT (envelope-from ariff@FreeBSD.org) Date: Wed, 27 Sep 2006 08:10:41 +0800 From: Ariff Abdullah To: "Alexandre Vieira" Message-Id: <20060927081041.3c2f7023.ariff@FreeBSD.org> In-Reply-To: <755cb9fc0609261551g6a97bdd2s64b4b2fada65cb03@mail.gmail.com> References: <755cb9fc0609251042h163ff7f1l4e96369ed7bd0106@mail.gmail.com> <1159207411.670.3.camel@localhost> <755cb9fc0609261551g6a97bdd2s64b4b2fada65cb03@mail.gmail.com> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Wed__27_Sep_2006_08_10_41_+0800_Aw.s1/6d+waSgwcB" Cc: freebsd-multimedia@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: Acer Aspire 1644WLMi -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2006 00:12:19 -0000 --Signature=_Wed__27_Sep_2006_08_10_41_+0800_Aw.s1/6d+waSgwcB Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, 26 Sep 2006 23:51:27 +0100 "Alexandre Vieira" wrote: > Hello, >=20 > I downloaded the latest hdac driver from Ariff's and i'm unable to > play any sound :( >=20 > When I load the module: >=20 > pcm0: mem > 0xd000c000-0xd000ffff at device 27.0 on pci0 > pcm0: > pcm0: >=20 > Mixer: >=20 > Mixer vol is currently set to 100:100 > Mixer pcm is currently set to 100:100 > Recording source: mic >=20 Verbose dmesg, please. -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ --Signature=_Wed__27_Sep_2006_08_10_41_+0800_Aw.s1/6d+waSgwcB Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFGcGDlr+deMUwTNoRApzgAJ9nDZ1DG6xz/43d0AwJnOtXR+IQJACfeylS eUgltqbTKdf6pEpxkSZOg20= =dX/i -----END PGP SIGNATURE----- --Signature=_Wed__27_Sep_2006_08_10_41_+0800_Aw.s1/6d+waSgwcB-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 00:23:04 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09DB016A407 for ; Wed, 27 Sep 2006 00:23:04 +0000 (UTC) (envelope-from fcash@ocis.net) Received: from smtp.sd73.bc.ca (mailtest.sd73.bc.ca [142.24.13.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC0B943D45 for ; Wed, 27 Sep 2006 00:22:59 +0000 (GMT) (envelope-from fcash@ocis.net) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id 5F2B18A0052 for ; Tue, 26 Sep 2006 17:22:59 -0700 (PDT) Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 60388-17 for ; Tue, 26 Sep 2006 17:22:57 -0700 (PDT) Received: from webmail.sd73.bc.ca (unknown [10.10.10.17]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 4E08F8A006D for ; Tue, 26 Sep 2006 17:22:57 -0700 (PDT) Received: from 24.71.118.34 (SquirrelMail authenticated user fcash) by webmail.sd73.bc.ca with HTTP; Tue, 26 Sep 2006 17:22:57 -0700 (PDT) Message-ID: <62230.24.71.118.34.1159316577.squirrel@webmail.sd73.bc.ca> In-Reply-To: <20060926222740.GF6216@e.0x20.net> References: <20060926222740.GF6216@e.0x20.net> Date: Tue, 26 Sep 2006 17:22:57 -0700 (PDT) From: "Freddie Cash" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: by amavisd-new using ClamAV at sd73.bc.ca Subject: Re: Atheros PCCard recognized, IRQ Problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 00:23:04 -0000 On Tue, September 26, 2006 3:27 pm, Lars Engels wrote: > when I insert a Netgear WAG511 Atheros-based PCCard into my notebook, > the speakers crackle two times and nothing else happens. The GENERIC kernel that ships with FreeBSD does not include the Atheros drivers. You need to manually load: if_ath wlan_wep wlan_tkip wlan_ccmp Any needed modules will be auto-loaded by the above. Once those are loaded, you will be able to use the card. If you want to compile the drivers into the kernel, you will need: wlan wlan_wep wlan_tkip wlan_ccmp ath ath_hal ath_rate_sample ---- Freddie Cash fcash@ocis.net From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 00:55:57 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6B0516A403 for ; Wed, 27 Sep 2006 00:55:57 +0000 (UTC) (envelope-from nullpt@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA07E43D53 for ; Wed, 27 Sep 2006 00:55:56 +0000 (GMT) (envelope-from nullpt@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so4501uge for ; Tue, 26 Sep 2006 17:55:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=H5NJsuvLvPQ00V01GgMNOHDuC0eDpj2aYvtCTNE2kqPH2CtwHlOGRxbDpPRr7vjU4oNE90Rig5SZjW60ak5qmP3YEEhcO0CEtHEcOEbvApkfkT7DfJmAUZMM2aTHHrW4gxSTSHSSdf5Yit/Y5TEMkSzc/4RwgihPU7Gku8vZW1Q= Received: by 10.66.244.11 with SMTP id r11mr105675ugh; Tue, 26 Sep 2006 17:55:55 -0700 (PDT) Received: by 10.66.237.20 with HTTP; Tue, 26 Sep 2006 17:55:55 -0700 (PDT) Message-ID: <755cb9fc0609261755h686dfca3qe0c91973b151cce0@mail.gmail.com> Date: Wed, 27 Sep 2006 01:55:55 +0100 From: "Alexandre Vieira" To: freebsd-current@freebsd.org, freebsd-multimedia@freebsd.org In-Reply-To: <20060927081041.3c2f7023.ariff@FreeBSD.org> MIME-Version: 1.0 References: <755cb9fc0609251042h163ff7f1l4e96369ed7bd0106@mail.gmail.com> <1159207411.670.3.camel@localhost> <755cb9fc0609261551g6a97bdd2s64b4b2fada65cb03@mail.gmail.com> <20060927081041.3c2f7023.ariff@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: Acer Aspire 1644WLMi -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2006 00:55:57 -0000 Hello, You can find the verbose dmesg here: http://nullpt.googlepages.com/vdmesg.txt Thanks On 9/27/06, Ariff Abdullah wrote: > > On Tue, 26 Sep 2006 23:51:27 +0100 > "Alexandre Vieira" wrote: > > Hello, > > > > I downloaded the latest hdac driver from Ariff's and i'm unable to > > play any sound :( > > > > When I load the module: > > > > pcm0: mem > > 0xd000c000-0xd000ffff at device 27.0 on pci0 > > pcm0: > > pcm0: > > > > Mixer: > > > > Mixer vol is currently set to 100:100 > > Mixer pcm is currently set to 100:100 > > Recording source: mic > > > > Verbose dmesg, please. > > > -- > Ariff Abdullah > FreeBSD > > ... Recording in stereo is obviously too advanced > and confusing for us idiot ***** users :P ........ > > > -- Alexandre Vieira - nullpt@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 01:17:41 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C45916A412 for ; Wed, 27 Sep 2006 01:17:41 +0000 (UTC) (envelope-from dandee@hellteam.net) Received: from pipa.vshosting.cz (pipa.vshosting.cz [81.0.201.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id E144F43D6A for ; Wed, 27 Sep 2006 01:17:35 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from localhost (localhost [127.0.0.1]) by pipa.vshosting.cz (Postfix) with ESMTP id 040AB4E734; Wed, 27 Sep 2006 03:17:36 +0200 (CEST) Received: from pipa.vshosting.cz ([127.0.0.1]) by localhost (pipa [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17088-09; Wed, 27 Sep 2006 03:17:34 +0200 (CEST) Received: from gandalf (unknown [81.0.245.205]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by pipa.vshosting.cz (Postfix) with ESMTP id 811E24E705; Wed, 27 Sep 2006 03:17:33 +0200 (CEST) From: =?iso-8859-2?Q?Daniel_Dvo=F8=E1k?= To: "'Freddie Cash'" , Date: Wed, 27 Sep 2006 03:17:28 +0200 Message-ID: <002801c6e1d2$b483dc00$6508280a@tocnet28.jspoj.czf> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <62230.24.71.118.34.1159316577.squirrel@webmail.sd73.bc.ca> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbhyyrX2v/JquLNRN25xck1o6Tl5wABeLEg X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at profix.cz Cc: Subject: RE: Atheros PCCard recognized, IRQ Problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 01:17:41 -0000 Hi Freddie, maybe I didn=B4t catch something in this thread, but these modules were = added to generic releng_6 kernel here: Revision 1.429.2.10 / (download) - annotate - [select for diffs] , Tue = Jul 11 16:35:07 2006 UTC (2 months, 2 weeks ago) by sam Branch: RELENG_6 Changes since 1.429.2.9: +6 -0 lines Diff to previous 1.429.2.9 to branchpoint 1.429 MFC: add ath and related code So of course, with 6.1-Release (...kernel that ships with...) there are = not these stuff compiled in kernel, so "cvsuping", please. Daniel > -----Original Message----- > From: owner-freebsd-current@freebsd.org=20 > [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Freddie Cash > Sent: Wednesday, September 27, 2006 2:23 AM > To: freebsd-current@freebsd.org > Subject: Re: Atheros PCCard recognized, IRQ Problem? >=20 > On Tue, September 26, 2006 3:27 pm, Lars Engels wrote: > > when I insert a Netgear WAG511 Atheros-based PCCard into my=20 > notebook, =20 > > the speakers crackle two times and nothing else happens. >=20 > The GENERIC kernel that ships with FreeBSD does not include=20 > the Atheros drivers. You need to manually load: > if_ath > wlan_wep > wlan_tkip > wlan_ccmp >=20 > Any needed modules will be auto-loaded by the above. Once=20 > those are loaded, you will be able to use the card. >=20 > If you want to compile the drivers into the kernel, you will need: > wlan > wlan_wep > wlan_tkip > wlan_ccmp > ath > ath_hal > ath_rate_sample >=20 > ---- > Freddie Cash > fcash@ocis.net >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list=20 > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to=20 > "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 01:21:43 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACA8916A415; Wed, 27 Sep 2006 01:21:43 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBA3043D68; Wed, 27 Sep 2006 01:21:42 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k8R1LghQ034190; Tue, 26 Sep 2006 21:21:42 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id k8R1LfTR022837; Tue, 26 Sep 2006 21:21:41 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id D25907302F; Tue, 26 Sep 2006 21:21:41 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060927012141.D25907302F@freebsd-current.sentex.ca> Date: Tue, 26 Sep 2006 21:21:41 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2006 01:21:43 -0000 TB --- 2006-09-27 00:49:24 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-09-27 00:49:24 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-09-27 00:49:24 - cleaning the object tree TB --- 2006-09-27 00:50:04 - checking out the source tree TB --- 2006-09-27 00:50:04 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-09-27 00:50:04 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-09-27 00:56:58 - building world (CFLAGS=-O2 -pipe) TB --- 2006-09-27 00:56:58 - cd /src TB --- 2006-09-27 00:56:58 - /usr/bin/make -B buildworld >>> World build started on Wed Sep 27 00:57:00 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ===> lib/libalias/libalias (all) cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_db.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_proxy.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_util.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_old.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_mod.c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_mod.c:27: error: syntax error before string constant *** Error code 1 Stop in /src/lib/libalias/libalias. *** Error code 1 Stop in /src/lib/libalias. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-09-27 01:21:41 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-09-27 01:21:41 - ERROR: failed to build world TB --- 2006-09-27 01:21:41 - tinderbox aborted TB --- 1.55 user 7.13 system 1937.13 real From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 01:52:45 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC67316A415; Wed, 27 Sep 2006 01:52:44 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 932FA43D6A; Wed, 27 Sep 2006 01:52:44 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id k8R1qiPl076193; Tue, 26 Sep 2006 21:52:44 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id k8R1qh5C097158; Tue, 26 Sep 2006 21:52:43 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 205867302F; Tue, 26 Sep 2006 21:52:43 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060927015243.205867302F@freebsd-current.sentex.ca> Date: Tue, 26 Sep 2006 21:52:43 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2006 01:52:45 -0000 TB --- 2006-09-27 01:21:42 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-09-27 01:21:42 - starting HEAD tinderbox run for i386/i386 TB --- 2006-09-27 01:21:42 - cleaning the object tree TB --- 2006-09-27 01:22:10 - checking out the source tree TB --- 2006-09-27 01:22:10 - cd /tinderbox/HEAD/i386/i386 TB --- 2006-09-27 01:22:10 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-09-27 01:28:15 - building world (CFLAGS=-O2 -pipe) TB --- 2006-09-27 01:28:15 - cd /src TB --- 2006-09-27 01:28:15 - /usr/bin/make -B buildworld >>> World build started on Wed Sep 27 01:28:17 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ===> lib/libalias/libalias (all) cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_db.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_proxy.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_util.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_old.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_mod.c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_mod.c:27: error: syntax error before string constant *** Error code 1 Stop in /src/lib/libalias/libalias. *** Error code 1 Stop in /src/lib/libalias. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-09-27 01:52:42 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-09-27 01:52:42 - ERROR: failed to build world TB --- 2006-09-27 01:52:42 - tinderbox aborted TB --- 1.21 user 5.88 system 1860.89 real From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 02:16:00 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5151416A403; Wed, 27 Sep 2006 02:16:00 +0000 (UTC) (envelope-from ota@j.email.ne.jp) Received: from mail.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id F160443D55; Wed, 27 Sep 2006 02:15:59 +0000 (GMT) (envelope-from ota@j.email.ne.jp) Received: from dynabook.advok.com (pool-151-197-36-163.phil.east.verizon.net [151.197.36.163]) by mail.asahi-net.or.jp (Postfix) with ESMTP id 1854A18E2C; Wed, 27 Sep 2006 11:15:56 +0900 (JST) Date: Tue, 26 Sep 2006 22:15:47 -0500 From: Yoshihiro Ota To: Ivan Voras Message-Id: <20060926221547.1ae6f72a.ota@j.email.ne.jp> In-Reply-To: <4518DE53.9070101@fer.hr> References: <44EF12F6.3000806@fer.hr> <20060925213522.4c9eacb7.ota@j.email.ne.jp> <4518DE53.9070101@fer.hr> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: geom@freebsd.org, current@freebsd.org Subject: Re: Announcing: gvirstor X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 02:16:00 -0000 On Tue, 26 Sep 2006 10:01:23 +0200 Ivan Voras wrote: > Ota wrote: > > > > # ./gvirstor label -v -s 500 test md2 md3 > > Unknown command: label > > This means the .so file has not been found. > > I see now what's going on: I've forgot to add a step to the README: make > a symlink of geom_virstor.so in your /lib/geom directory: > > /lib/geom# ln -s /path_to_gvirstor/geom_virstor.so Indeed, this was the problem, and now: # ./gvirstor label -v -s 5000 test md2 /dev/md3 Resizing virtual size to fit virstor structures New virtual size: 5120 MB (30 new chunks) Total virtual chunks: 1280 (4 MB each), 5120 MB total virtual size. Clearing metadata on md2 /dev/md3. Writing allocation table to md2... (0 MB, 1 chunks) Storing metadata on md2 (250 chunks) /dev/md3 (250 chunks) Done. # newfs -U /dev/virstor/test /dev/virstor/test: 5120.0MB (10485760 sectors) block size 16384, fragment size 2048 using 28 cylinder groups of 183.77MB, 11761 blks, 23552 inodes. with soft updates super-block backups (for fsck -b #) at: 160, 376512, 752864, 1129216, 1505568, 1881920, 2258272, 2634624, 3010976, 3387328, 3763680, 4140032, 4516384, 4892736, 5269088, 5645440, 6021792, 6398144, 6774496, 7150848, 7527200, 7903552, 8279904, 8656256, 9032608, 9408960, 9785312, 10161664 > Also, take care to remove CFLAGS line from Makefile if you don't have a > kernel with INVARIANTS and WITNESS. "-g" option was required in "CFLAGS"; otherwise, kldload failed. > I hope to hear about your experience with it. Reading "gvirstor implementation details", it is not intended to remove components, is it? If not, it will a grate benefit to allow "take-off" components as some device may go bad while other devices are still functioning when a virstor is created with multiple devices. I tried it anyway. It seemed that I was able to detach md3 and then add md4. Md3 was not used at all when I removed; status only displaed md2 but I was not sure if it was removed perfectly in gvirstor as no mention in the document. Later, I was not able to add md3 back again. These are the command lines I tried # mount /dev/virstor/test /mnt/tmp # tar xf ports.tar.bz -C /mnt/tmp & # ./gvirstor remove test md3 # ./gvirstor add test md4 # ./gvirstor status test # ./gvirstor add test md3 Kernel paniced after a while. Many things were going so it was not sure that gvirstor was the cause of the problem. I will try as time permitts. Thanks, Hiro From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 02:23:04 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E74816A407; Wed, 27 Sep 2006 02:23:04 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D565F43D46; Wed, 27 Sep 2006 02:23:03 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id k8R2N3QP077859; Tue, 26 Sep 2006 22:23:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id k8R2N3pL085390; Tue, 26 Sep 2006 22:23:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 049C27302F; Tue, 26 Sep 2006 22:23:02 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060927022303.049C27302F@freebsd-current.sentex.ca> Date: Tue, 26 Sep 2006 22:23:02 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2006 02:23:04 -0000 TB --- 2006-09-27 01:52:43 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-09-27 01:52:43 - starting HEAD tinderbox run for i386/pc98 TB --- 2006-09-27 01:52:43 - cleaning the object tree TB --- 2006-09-27 01:53:09 - checking out the source tree TB --- 2006-09-27 01:53:09 - cd /tinderbox/HEAD/i386/pc98 TB --- 2006-09-27 01:53:09 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-09-27 01:58:54 - building world (CFLAGS=-O2 -pipe) TB --- 2006-09-27 01:58:54 - cd /src TB --- 2006-09-27 01:58:54 - /usr/bin/make -B buildworld >>> World build started on Wed Sep 27 01:58:56 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ===> lib/libalias/libalias (all) cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_db.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_proxy.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_util.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_old.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_mod.c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_mod.c:27: error: syntax error before string constant *** Error code 1 Stop in /src/lib/libalias/libalias. *** Error code 1 Stop in /src/lib/libalias. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-09-27 02:23:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-09-27 02:23:02 - ERROR: failed to build world TB --- 2006-09-27 02:23:02 - tinderbox aborted TB --- 1.04 user 5.89 system 1819.20 real From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 02:25:29 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C27CD16A407; Wed, 27 Sep 2006 02:25:29 +0000 (UTC) (envelope-from flag@newluxor.wired.org) Received: from mail.oltrelinux.com (krisma.oltrelinux.com [194.242.226.43]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5888D43D45; Wed, 27 Sep 2006 02:25:29 +0000 (GMT) (envelope-from flag@newluxor.wired.org) Received: from newluxor.wired.org (ip-64-88.sn2.eutelia.it [83.211.64.88]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.oltrelinux.com (Postfix) with ESMTP id E873E11B1C8; Wed, 27 Sep 2006 04:25:29 +0200 (CEST) Received: (from flag@localhost) by newluxor.wired.org (8.13.8/8.13.8/Submit) id k8R2PDc7063840; Wed, 27 Sep 2006 04:25:13 +0200 (CEST) (envelope-from flag) Date: Wed, 27 Sep 2006 04:25:08 +0200 From: Paolo Pisati To: FreeBSD Tinderbox Message-ID: <20060927022508.GD62281@tin.it> References: <20060927015243.205867302F@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060927015243.205867302F@freebsd-current.sentex.ca> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at krisma.oltrelinux.com Cc: current@freebsd.org, i386@freebsd.org Subject: Re: [head tinderbox] failure on i386/i386 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2006 02:25:29 -0000 On Tue, Sep 26, 2006 at 09:52:43PM -0400, FreeBSD Tinderbox wrote: > cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_mod.c > /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_mod.c:27: error: syntax error before string constant > *** Error code 1 > Forgot to add sys/cdefs.h after i added __FBSDID() just before committing: should be fixed now. bye -- Paolo Piso's first law: nothing works as expected! From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 02:54:01 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2B61616A403; Wed, 27 Sep 2006 02:54:01 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1C7843D45; Wed, 27 Sep 2006 02:54:00 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.6/8.13.6) with ESMTP id k8R2rxKw037688; Tue, 26 Sep 2006 22:53:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id k8R2rxr4071338; Tue, 26 Sep 2006 22:53:59 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 93C617302F; Tue, 26 Sep 2006 22:53:59 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060927025359.93C617302F@freebsd-current.sentex.ca> Date: Tue, 26 Sep 2006 22:53:59 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.3, clamav-milter version 0.88.3 on clamscanner2 X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner4 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2006 02:54:01 -0000 TB --- 2006-09-27 02:23:03 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-09-27 02:23:03 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2006-09-27 02:23:03 - cleaning the object tree TB --- 2006-09-27 02:23:32 - checking out the source tree TB --- 2006-09-27 02:23:32 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2006-09-27 02:23:32 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-09-27 02:30:03 - building world (CFLAGS=-O2 -pipe) TB --- 2006-09-27 02:30:03 - cd /src TB --- 2006-09-27 02:30:03 - /usr/bin/make -B buildworld >>> World build started on Wed Sep 27 02:30:04 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries [...] ===> lib/libalias (all) ===> lib/libalias/libalias (all) cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_db.c cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunused-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_proxy.c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_proxy.c: In function `ProxyEncodeIpHeader': /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_proxy.c:524: warning: cast increases required alignment of target type /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_proxy.c:529: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/lib/libalias/libalias. *** Error code 1 Stop in /src/lib/libalias. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-09-27 02:53:59 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-09-27 02:53:59 - ERROR: failed to build world TB --- 2006-09-27 02:53:59 - tinderbox aborted TB --- 1.00 user 5.18 system 1856.30 real From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 05:16:26 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7686F16A407 for ; Wed, 27 Sep 2006 05:16:26 +0000 (UTC) (envelope-from shigeru@iij.ad.jp) Received: from otm-mgo00.iij.ad.jp (otm-mgo00.iij.ad.jp [210.138.20.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2D1D43D6D for ; Wed, 27 Sep 2006 05:16:25 +0000 (GMT) (envelope-from shigeru@iij.ad.jp) Received: OTM-MO(otm-mgo00) id k8R5GOmp083348; Wed, 27 Sep 2006 14:16:24 +0900 (JST) DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=iij.ad.jp; s=omgo0; t=1159334184; bh=2mBh0zAEAo2c1oHDdtFTqW3ozlE=; h=Received:Received: Date:Message-Id:To:Cc:Subject:From:In-Reply-To:References:X-Mailer: Mime-Version:Content-Type:Content-Transfer-Encoding; b=GYyFVsJ9duSO qGTj46PYzFI+q0ti/dMi0Oj/NcAVcjiytot/jJpQ5pJ4SyEi8FM9mq5A/SJ0W719xvP 8BSZ8urRgSg12c/Cy5XZVqACv50QQiO1lvEFCmdCK50DvXMC05cm1kxlI/x5EF6G03W 9bWx444Wi/8ABFbnfdTC48ZsA= Received: OTM-MIX(otm-mix01) id k8R5GOHN077936; Wed, 27 Sep 2006 14:16:24 +0900 (JST) Received: from localhost (mercury.iij.ad.jp [192.168.184.90]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp) id k8R5GMdp006155 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 27 Sep 2006 14:16:23 +0900 (JST) Date: Wed, 27 Sep 2006 14:16:21 +0900 (JST) Message-Id: <20060927.141621.78040393.shigeru@iij.ad.jp> To: pyunyh@gmail.com From: YAMAMOTO Shigeru In-Reply-To: <20060926121707.GC5975@cdnetworks.co.kr> References: <20060926002916.GA5975@cdnetworks.co.kr> <20060926.210009.34729196.shigeru@iij.ad.jp> <20060926121707.GC5975@cdnetworks.co.kr> X-Mailer: Mew version 5.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 05:16:26 -0000 >>>>> "Pyun" == Pyun YongHyeon writes: >> 'MSK_JSLTS' is not defined in this patch. >> >> Thanks, Pyun> Oops! It should be fixed now. Please try again. I get new patch and try again. I test "Marvell 88E8053" on amd64. It work fine. Thanks, bash-2.05b# uname -a FreeBSD venus.iij.ad.jp 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Wed Sep 27 12:40:16 JST 2006 root@venus.iij.ad.jp:/usr/src/sys/amd64/compile/VENUS amd64 bash-2.05b# pciconf -l -v pci2:0:0 ... mskc0@pci2:0:0: class=0x020000 card=0x81421043 chip=0x436211ab rev=0x15 hdr=0x00 vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' device = '88E8053 Yukon PCI-E Gigabit Ethernet Controller (copper)' class = network subclass = ethernet bash-2.05b# ifconfig msk0 msk0: flags=8843 mtu 1500 options=9b inet6 fe80::213:d4ff:fefa:428a%msk0 prefixlen 64 scopeid 0x5 ether 00:13:d4:fa:42:8a media: Ethernet autoselect (100baseTX ) status: active ------- YAMAMOTO Shigeru From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 05:24:50 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D750416A407 for ; Wed, 27 Sep 2006 05:24:50 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C44B43D49 for ; Wed, 27 Sep 2006 05:24:50 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so109828pye for ; Tue, 26 Sep 2006 22:24:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=auO1k7pbSezClsxIBBDbCCWokGdSqK3vpa3t1FPphqq4ZASnVlqMoYLU+oLeH4e0aVjnF3TCudltz9nrf8V/R99qpczBrIuaa7mUlsowz0rc6bxV054iV4nwHMJZF6IFhQUuf1MJafFmT7xM2g050KTWjf1GdlSoUvDmQNfDKdc= Received: by 10.35.51.13 with SMTP id d13mr681316pyk; Tue, 26 Sep 2006 22:24:49 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 38sm453836nzk.2006.09.26.22.24.47; Tue, 26 Sep 2006 22:24:48 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k8R5PDZx012132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Sep 2006 14:25:13 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k8R5PCEw012131; Wed, 27 Sep 2006 14:25:12 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 27 Sep 2006 14:25:12 +0900 From: Pyun YongHyeon To: YAMAMOTO Shigeru Message-ID: <20060927052512.GG5975@cdnetworks.co.kr> References: <20060926002916.GA5975@cdnetworks.co.kr> <20060926.210009.34729196.shigeru@iij.ad.jp> <20060926121707.GC5975@cdnetworks.co.kr> <20060927.141621.78040393.shigeru@iij.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060927.141621.78040393.shigeru@iij.ad.jp> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2006 05:24:50 -0000 On Wed, Sep 27, 2006 at 02:16:21PM +0900, YAMAMOTO Shigeru wrote: > > >>>>> "Pyun" == Pyun YongHyeon writes: > >> 'MSK_JSLTS' is not defined in this patch. > >> > >> Thanks, > Pyun> Oops! It should be fixed now. Please try again. > > I get new patch and try again. > I test "Marvell 88E8053" on amd64. > It work fine. > > Thanks, > > bash-2.05b# uname -a > FreeBSD venus.iij.ad.jp 7.0-CURRENT FreeBSD 7.0-CURRENT #0: Wed Sep 27 12:40:16 JST 2006 root@venus.iij.ad.jp:/usr/src/sys/amd64/compile/VENUS amd64 > bash-2.05b# pciconf -l -v pci2:0:0 > ... > mskc0@pci2:0:0: class=0x020000 card=0x81421043 chip=0x436211ab rev=0x15 hdr=0x00 > vendor = 'Marvell Semiconductor (Was: Galileo Technology Ltd)' > device = '88E8053 Yukon PCI-E Gigabit Ethernet Controller (copper)' > class = network > subclass = ethernet > > bash-2.05b# ifconfig msk0 > msk0: flags=8843 mtu 1500 > options=9b > inet6 fe80::213:d4ff:fefa:428a%msk0 prefixlen 64 scopeid 0x5 > ether 00:13:d4:fa:42:8a > media: Ethernet autoselect (100baseTX ) > status: active > Thanks a lot. Would you let me know what PHY driver was attached to your NIC? If ukphy(4) was used for the NIC I'd like to know PHY model number. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 05:56:09 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F25916A40F for ; Wed, 27 Sep 2006 05:56:09 +0000 (UTC) (envelope-from shigeru@iij.ad.jp) Received: from otm-mgo00.iij.ad.jp (otm-mgo00.iij.ad.jp [210.138.20.174]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F09543D45 for ; Wed, 27 Sep 2006 05:56:04 +0000 (GMT) (envelope-from shigeru@iij.ad.jp) Received: OTM-MO(otm-mgo00) id k8R5u32f084399; Wed, 27 Sep 2006 14:56:03 +0900 (JST) DKIM-Signature: a=rsa-sha1; c=relaxed/simple; d=iij.ad.jp; s=omgo0; t=1159336563; bh=Egi4g6+9mZlnUrOYguNxrjOW7DY=; h=Received:Received: Date:Message-Id:To:Cc:Subject:From:In-Reply-To:References:X-Mailer: Mime-Version:Content-Type:Content-Transfer-Encoding; b=RSJJisB+/GQ8 KLfm8Hw3XibfqZlfRp/lf66ITzpDiEgUX1yGqnZeF6v0zNTa6HVohDMj+RLrLV1C/TR hH9BxyERxjs3IQdGfvFvrH+WJXLsp8GyFYDoatyOwec2HCmi7FimzB4tz8CuhZXN5Rp JFGqwjgxYbxpm2AcbLwbDl7ek= Received: OTM-MIX(otm-mix01) id k8R5u32w082767; Wed, 27 Sep 2006 14:56:03 +0900 (JST) Received: from localhost (mercury.iij.ad.jp [192.168.184.90]) by rsmtp.iij.ad.jp (OTM-MR/rsmtp) id k8R5u1s6006912 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 27 Sep 2006 14:56:03 +0900 (JST) Date: Wed, 27 Sep 2006 14:56:00 +0900 (JST) Message-Id: <20060927.145600.127212419.shigeru@iij.ad.jp> To: pyunyh@gmail.com From: YAMAMOTO Shigeru In-Reply-To: <20060927052512.GG5975@cdnetworks.co.kr> References: <20060926121707.GC5975@cdnetworks.co.kr> <20060927.141621.78040393.shigeru@iij.ad.jp> <20060927052512.GG5975@cdnetworks.co.kr> X-Mailer: Mew version 5.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 05:56:09 -0000 >>>>> "Pyun" == Pyun YongHyeon writes: Pyun> Thanks a lot. Would you let me know what PHY driver was attached to Pyun> your NIC? If ukphy(4) was used for the NIC I'd like to know PHY model Pyun> number. On my PC, e1000phy is used, not ukphy. I send a part of dmesg. mskc0: port 0xd800-0xd8ff mem 0xdfdfc000-0xdfdfffff irq 17 at device 0.0 on pci2 msk0: on mskc0 msk0: Ethernet address: 00:13:d4:fa:42:8a miibus1: on msk0 e1000phy1: on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto mskc0: [FAST] msk0: link state changed to DOWN msk0: link state changed to UP Thanks, ------- YAMAMOTO Shigeru From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 06:03:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A48116A407 for ; Wed, 27 Sep 2006 06:03:59 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id E18B243D5D for ; Wed, 27 Sep 2006 06:03:54 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so122646pye for ; Tue, 26 Sep 2006 23:03:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=miD2UmBa+EtRw80Nn2V70uACyUkUUKFYeio3wj/4jjbeHfbmjpCdsoGT5mVYoPpy9dBqq7km1FDdYtd9kKYQdaN0P74jkM4TT/2A3zmEwHgL3gm5UyleDDy8dH0pzvSLoadbyS06iBrde9a0P9Q9srr7KMmMYFB9qabg7Hh88cU= Received: by 10.35.126.7 with SMTP id d7mr126583pyn; Tue, 26 Sep 2006 23:03:53 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id c12sm577165nzc.2006.09.26.23.03.52; Tue, 26 Sep 2006 23:03:53 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k8R64IxL012241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Sep 2006 15:04:18 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k8R64HvM012240; Wed, 27 Sep 2006 15:04:17 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Wed, 27 Sep 2006 15:04:17 +0900 From: Pyun YongHyeon To: YAMAMOTO Shigeru Message-ID: <20060927060417.GH5975@cdnetworks.co.kr> References: <20060926121707.GC5975@cdnetworks.co.kr> <20060927.141621.78040393.shigeru@iij.ad.jp> <20060927052512.GG5975@cdnetworks.co.kr> <20060927.145600.127212419.shigeru@iij.ad.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060927.145600.127212419.shigeru@iij.ad.jp> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2006 06:03:59 -0000 On Wed, Sep 27, 2006 at 02:56:00PM +0900, YAMAMOTO Shigeru wrote: > > >>>>> "Pyun" == Pyun YongHyeon writes: > Pyun> Thanks a lot. Would you let me know what PHY driver was attached to > Pyun> your NIC? If ukphy(4) was used for the NIC I'd like to know PHY model > Pyun> number. > > On my PC, e1000phy is used, not ukphy. > > I send a part of dmesg. > > mskc0: port 0xd800-0xd8ff mem 0xdfdfc000-0xdfdfffff irq 17 at device 0.0 on pci2 > msk0: on mskc0 > msk0: Ethernet address: 00:13:d4:fa:42:8a > miibus1: on msk0 > e1000phy1: on miibus1 > e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto > mskc0: [FAST] > msk0: link state changed to DOWN > msk0: link state changed to UP > It looks ok. Thanks again for reporting. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 07:19:17 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C1E716A47B; Wed, 27 Sep 2006 07:19:17 +0000 (UTC) (envelope-from ivoras@fer.hr) Received: from ls405.htnet.hr (ls405.t-com.hr [195.29.150.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B2D043D77; Wed, 27 Sep 2006 07:19:07 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from ls422.t-com.hr (ls422.t-com.hr [195.29.150.237]) by ls405.htnet.hr (Postfix) with ESMTP id F34F3143C0D; Wed, 27 Sep 2006 09:19:05 +0200 (CEST) Received: from ls422.t-com.hr (localhost.localdomain [127.0.0.1]) by ls422.t-com.hr (Qmlai) with ESMTP id E63FCC9004A; Wed, 27 Sep 2006 09:19:05 +0200 (CEST) X-Envelope-Sender: ivoras@fer.hr Received: from [89.172.53.253] (89-172-53-253.adsl.net.t-com.hr [89.172.53.253])by ls422.t-com.hr (Qmlai) with ESMTP id 565671308075; Wed, 27 Sep 2006 09:19:04 +0200 (CEST) Message-ID: <451A25F2.6050106@fer.hr> Date: Wed, 27 Sep 2006 09:19:14 +0200 From: Ivan Voras User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Yoshihiro Ota References: <44EF12F6.3000806@fer.hr> <20060925213522.4c9eacb7.ota@j.email.n e.jp> <4518DE53.9070101@fer.hr> <20060926221547.1ae6f72a.ota@j.email.ne.jp> In-Reply-To: <20060926221547.1ae6f72a.ota@j.email.ne.jp> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-imss-version: 2.042 X-imss-result: Passed X-imss-scores: Clean:60.30964 C:2 M:4 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Cc: geom@freebsd.org, current@freebsd.org Subject: Re: Announcing: gvirstor X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 07:19:17 -0000 Yoshihiro Ota wrote: > Reading "gvirstor implementation details", it is not intended to remove components, is it? If not, it will a grate benefit to allow "take-off" components as some device may go bad while other devices are still functioning when a virstor is created with multiple devices. If it's a much requested feature, I'll implement it; as it is currently done, only unused components at the end of the list of components can be removed. > I tried it anyway. It seemed that I was able to detach md3 and then add md4. Md3 was not used at all when I removed; status only displaed md2 but I was not sure if it was removed perfectly in gvirstor as no mention in the document. Later, I was not able to add md3 back again. > > These are the command lines I tried > # mount /dev/virstor/test /mnt/tmp > # tar xf ports.tar.bz -C /mnt/tmp & > # ./gvirstor remove test md3 Ok, I'll try this situation at my development machine. > # ./gvirstor add test md4 > # ./gvirstor status test > # ./gvirstor add test md3 > > Kernel paniced after a while. Many things were going so it was not sure that gvirstor was the cause of the problem. Kernel panic message may tell you what system panicked. > I will try as time permitts. Thank you. From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 08:00:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E173116A47E for ; Wed, 27 Sep 2006 08:00:26 +0000 (UTC) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C3AA43D58 for ; Wed, 27 Sep 2006 08:00:21 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1GSUL4-0004Ew-00; Wed, 27 Sep 2006 10:00:18 +0200 Date: Wed, 27 Sep 2006 10:00:18 +0200 To: Alexandre Vieira Message-ID: <20060927080017.GA4945@poupinou.org> References: <755cb9fc0609251042h163ff7f1l4e96369ed7bd0106@mail.gmail.com> <20060926083828.GZ4945@poupinou.org> <755cb9fc0609261524k15b096afofa06f40a4002cd49@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <755cb9fc0609261524k15b096afofa06f40a4002cd49@mail.gmail.com> User-Agent: Mutt/1.5.9i From: Bruno Ducrot Cc: freebsd-current@freebsd.org Subject: Re: Acer Aspire 1644WLMi -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2006 08:00:27 -0000 On Tue, Sep 26, 2006 at 11:24:02PM +0100, Alexandre Vieira wrote: > Hello, > > Thanks for your reply. > > You can find the .asl here: > > http://nullpt.googlepages.com/Acer_Aspire_1644WLMi.asl > A diff is now available at http://www.poupinou.org/Acer_Aspire_1644WLMi.asl.diff It correct those errors: - The two missing 'Z00A' are replaced by 'Ones' (note that you won't need it when ACPICA will be upgraded to the latest version, this won't happens in -stable in the short term, though). - Eliminate all the ResourceSourceIndex when there is no ResourceSource onto a Ressource descriptor. This one actually is not a real issue, but it's more clean now. Ok now do that: 1- patch your Acer_Aspire_1644WLMi.asl, 2- invoke iasl Acer_Aspire_1644WLMi.asl That will create a DSDT.aml file. 3- copy this DSDT.aml to /boot 4- add those lines to your /boot/loader.conf: acpi_dsdt_load="YES" acpi_dsdt_name="/boot/DSDT.aml" reboot, and now you should be able to see the battery via sysctl hw.acpi Also look at 11.16.5.3 "Overriding the Default AML" in the handbook for more details about this procedure: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 10:14:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 905C516A415 for ; Wed, 27 Sep 2006 10:14:46 +0000 (UTC) (envelope-from lars@e.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.67.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF21543D4C for ; Wed, 27 Sep 2006 10:14:45 +0000 (GMT) (envelope-from lars@e.0x20.net) Received: by mail.0x20.net (Postfix, from userid 1002) id B358E34B36; Wed, 27 Sep 2006 12:14:44 +0200 (CEST) Date: Wed, 27 Sep 2006 12:14:44 +0200 From: Lars Engels To: Freddie Cash Message-ID: <20060927101444.GI6216@e.0x20.net> Mail-Followup-To: Lars Engels , Freddie Cash , freebsd-current@freebsd.org References: <20060926222740.GF6216@e.0x20.net> <62230.24.71.118.34.1159316577.squirrel@webmail.sd73.bc.ca> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="it/zdz3K1bH9Y8/E" Content-Disposition: inline In-Reply-To: <62230.24.71.118.34.1159316577.squirrel@webmail.sd73.bc.ca> X-Editor: VIM - Vi IMproved 7.0 User-Agent: Mutt/1.5.11 Cc: freebsd-current@freebsd.org Subject: Re: Atheros PCCard recognized, IRQ Problem? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 10:14:46 -0000 --it/zdz3K1bH9Y8/E Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Sep 26, 2006 at 05:22:57PM -0700, Freddie Cash wrote: > On Tue, September 26, 2006 3:27 pm, Lars Engels wrote: > > when I insert a Netgear WAG511 Atheros-based PCCard into my notebook, > > the speakers crackle two times and nothing else happens. >=20 > The GENERIC kernel that ships with FreeBSD does not include the > Atheros drivers. You need to manually load: > if_ath > wlan_wep > wlan_tkip > wlan_ccmp >=20 > Any needed modules will be auto-loaded by the above. Once those are > loaded, you will be able to use the card. >=20 > If you want to compile the drivers into the kernel, you will need: > wlan > wlan_wep > wlan_tkip > wlan_ccmp > ath > ath_hal > ath_rate_sample >=20 Hi Freddie, the devices are already compiled into the kernel, so the card should be recognized. What I forgot to tell is that I use current on this machine for two months now and up to about four weeks ago I got this message on inserting the card (without any crackles from the speakers): cbb alloc res fail cardbus0: at device 0.0 (no driver attached) I did some searches on the net for this message, and some people could get their card recognized, when they disabled ACPI on boot. However this did not work for me. Lars --it/zdz3K1bH9Y8/E Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFGk8UKc512sD3afgRAh6QAJ9wPlKZ7qu0xRDLiKqH4FP1AeuZ6ACdE/WP 4pYy/xGJApVvw6JD0eIhkUM= =Sn13 -----END PGP SIGNATURE----- --it/zdz3K1bH9Y8/E-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 10:32:58 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9E6EF16A416; Wed, 27 Sep 2006 10:32:58 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44CCF43D5D; Wed, 27 Sep 2006 10:32:57 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id EA5C95E63; Wed, 27 Sep 2006 14:32:55 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id C72E15E28; Wed, 27 Sep 2006 14:32:55 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k8RAWvhU006311; Wed, 27 Sep 2006 14:32:57 +0400 (MSD) (envelope-from ru) Date: Wed, 27 Sep 2006 14:32:57 +0400 From: Ruslan Ermilov To: piso@FreeBSD.org Message-ID: <20060927103257.GA4598@rambler-co.ru> References: <20060927025359.93C617302F@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <20060927025359.93C617302F@freebsd-current.sentex.ca> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: current@FreeBSD.org, sparc64@FreeBSD.org Subject: Re: [head tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2006 10:32:58 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Should be "fixed" now, by adding NO_WERROR=3D back to libalias/Makefile. On Tue, Sep 26, 2006 at 10:53:59PM -0400, FreeBSD Tinderbox wrote: > TB --- 2006-09-27 02:23:03 - tinderbox 2.3 running on freebsd-current.sen= tex.ca > TB --- 2006-09-27 02:23:03 - starting HEAD tinderbox run for sparc64/spar= c64 > TB --- 2006-09-27 02:23:03 - cleaning the object tree > TB --- 2006-09-27 02:23:32 - checking out the source tree > TB --- 2006-09-27 02:23:32 - cd /tinderbox/HEAD/sparc64/sparc64 > TB --- 2006-09-27 02:23:32 - /usr/bin/cvs -f -R -q -d/home/ncvs update -P= d -A src > TB --- 2006-09-27 02:30:03 - building world (CFLAGS=3D-O2 -pipe) > TB --- 2006-09-27 02:30:03 - cd /src > TB --- 2006-09-27 02:30:03 - /usr/bin/make -B buildworld > >>> World build started on Wed Sep 27 02:30:04 UTC 2006 > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > [...] > =3D=3D=3D> lib/libalias (all) > =3D=3D=3D> lib/libalias/libalias (all) > cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unus= ed-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wret= urn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunuse= d-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -= c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias.c > cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unus= ed-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wret= urn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunuse= d-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -= c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_db.c > cc -O2 -pipe -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unus= ed-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wret= urn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wunuse= d-parameter -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -= c /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_proxy.c > /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_proxy.c: I= n function `ProxyEncodeIpHeader': > /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_proxy.c:52= 4: warning: cast increases required alignment of target type > /src/lib/libalias/libalias/../../../sys/netinet/libalias/alias_proxy.c:52= 9: warning: cast increases required alignment of target type > *** Error code 1 >=20 > Stop in /src/lib/libalias/libalias. > *** Error code 1 >=20 > Stop in /src/lib/libalias. > *** Error code 1 >=20 > Stop in /src/lib. > *** Error code 1 >=20 > Stop in /src. > *** Error code 1 >=20 > Stop in /src. > *** Error code 1 >=20 > Stop in /src. > *** Error code 1 >=20 > Stop in /src. > TB --- 2006-09-27 02:53:59 - WARNING: /usr/bin/make returned exit code 1= =20 > TB --- 2006-09-27 02:53:59 - ERROR: failed to build world > TB --- 2006-09-27 02:53:59 - tinderbox aborted > TB --- 1.00 user 5.18 system 1856.30 real --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFGlNZqRfpzJluFF4RAo/KAKCXBEZntHTGxEUxeC3pD+ku/FwTsgCghyyn /W2w97LNRuH8zMO8VglQmX0= =96sl -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 12:23:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A8F116A407; Wed, 27 Sep 2006 12:23:26 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 993A543D5C; Wed, 27 Sep 2006 12:23:25 +0000 (GMT) (envelope-from max@love2party.net) Received: from [88.64.177.224] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1GSYRf3e6A-0004RA; Wed, 27 Sep 2006 14:23:24 +0200 From: Max Laier Organization: FreeBSD To: freebsd-hackers@freebsd.org Date: Wed, 27 Sep 2006 14:23:17 +0200 User-Agent: KMail/1.9.4 X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<%}*_BD U_or=\mOZf764&nYj=JYbR1PW0ud>|!~, , CPC.1-D$FG@0h3#'5"k{V]a~. X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-current@freebsd.org Subject: Call for Status Reports: Oct 6 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: monthly@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2006 12:23:26 -0000 --nextPart37427511.YMaSj71Kfd Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, it almost slipped my mind to remind you that it's that time again. We are= =20 collecting Status Reports for the third quarter of 2006. I know that=20 most of you are wrapped in the preparation for FreeBSD 6.2. It would be=20 great if you could still find some time to write about all the goodies=20 that where MFCed and newly appeared in CURRENT between June and now. We would also like to hear from our Google Summer of Code participants how= =20 their projects turned out - you may copy and paste or redirect to=20 your "official" documentation ;) Just let's make sure your work gets the=20 attention it deserves! Submissions are due by 6 October, 2006. Submission details can be found=20 on http://www.freebsd.org/news/status/ As always, this is by no means limited to FreeBSD committers, but a call=20 to report news and status about any FreeBSD related project. Looking forward to reading your reports. See you at EuroBSDCon 2006 in Milan: http://www.eurobsdcon.org/ =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart37427511.YMaSj71Kfd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQBFGm06XyyEoT62BG0RApCBAJ0QEn7YGJmuqtPOzvevVjUa8pmjlwCbBzzz +a3P/mFrAijFVZkx0fezzFk= =u9Qo -----END PGP SIGNATURE----- --nextPart37427511.YMaSj71Kfd-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 13:03:45 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F221A16A403 for ; Wed, 27 Sep 2006 13:03:45 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 171B043D46 for ; Wed, 27 Sep 2006 13:03:44 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from atlantis.dp.ua (localhost [127.0.0.1]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k8RD3asb043931; Wed, 27 Sep 2006 16:03:36 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Received: from localhost (dmitry@localhost) by atlantis.dp.ua (8.13.1/8.13.1/Submit) with ESMTP id k8RD3amZ043928; Wed, 27 Sep 2006 16:03:36 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Wed, 27 Sep 2006 16:03:36 +0300 (EEST) From: Dmitry Pryanishnikov To: Pyun YongHyeon In-Reply-To: <20060926002916.GA5975@cdnetworks.co.kr> Message-ID: <20060927155600.M40914@atlantis.atlantis.dp.ua> References: <20060926002916.GA5975@cdnetworks.co.kr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 13:03:46 -0000 Hello! On Tue, 26 Sep 2006, Pyun YongHyeon wrote: > I've written a driver for Marvell/SysKonnect Yukon II Gigabit > Ethernet controller. It supports the following GigE adapters. > > The driver was tested on on-board 88E8053 PCI Express NIC and I'd Thank you very much! Driver works for me (i386, ASUS P5W DH Mobo with 2 built-in 88E8053 chips): pcib3: irq 19 at device 28.3 on pci0 pci4: on pcib3 mskc0: port 0xc800-0xc8ff mem 0xff8fc000-0xff8fffff irq 19 at device 0.0 on pci4 msk0: on mskc0 msk0: Ethernet address: 00:17:31:ee:d8:7f miibus0: on msk0 e1000phy0: on miibus0 e1000phy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto mskc0: [FAST] pcib4: irq 16 at device 28.4 on pci0 pci3: on pcib4 mskc1: port 0xb800-0xb8ff mem 0xff7fc000-0xff7fffff irq 16 at device 0.0 on pci3 msk1: on mskc1 msk1: Ethernet address: 00:17:31:ee:d1:aa miibus1: on msk1 e1000phy1: on miibus1 e1000phy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX-FDX, auto mskc1: [FAST] I'm a bit curious about the following: test2# ifconfig -a msk0: flags=8843 mtu 1500 options=9b inet 193.108.47.148 netmask 0xfffffff8 broadcast 193.108.47.151 ether 00:17:31:ee:d8:7f media: Ethernet autoselect (10baseT/UTP ) status: active What does "flag0,flag1" mean? And the main question is: how difficilt would it be to port this driver to RELENG_6? Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 13:09:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB4D316A494 for ; Wed, 27 Sep 2006 13:09:52 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83AA143D45 for ; Wed, 27 Sep 2006 13:09:52 +0000 (GMT) (envelope-from bms@incunabulum.net) Received: from frontend3.internal (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 48A74DA92FC; Wed, 27 Sep 2006 09:09:51 -0400 (EDT) Received: from heartbeat2.internal ([10.202.2.161]) by frontend3.internal (MEProxy); Wed, 27 Sep 2006 09:09:54 -0400 X-Sasl-enc: FK4TwdvTST7NQ2JYjk3idn9IjH1uIReeqTq4GGSd9q+f 1159362593 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id 6DEEAB046; Wed, 27 Sep 2006 09:09:52 -0400 (EDT) Message-ID: <451A781D.1010805@incunabulum.net> Date: Wed, 27 Sep 2006 14:09:49 +0100 From: Bruce M Simpson User-Agent: Thunderbird 1.5.0.5 (X11/20060825) MIME-Version: 1.0 To: Dmitry Pryanishnikov References: <20060926002916.GA5975@cdnetworks.co.kr> <20060927155600.M40914@atlantis.atlantis.dp.ua> In-Reply-To: <20060927155600.M40914@atlantis.atlantis.dp.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Pyun YongHyeon , freebsd-current@freebsd.org Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 13:09:52 -0000 Dmitry Pryanishnikov wrote: > What does "flag0,flag1" mean? Code inspection suggests "RX flow control" and "TX flow control" enabled in the GMAC respectively. > > And the main question is: how difficilt would it be to port this > driver to > RELENG_6? > I tried working on this yesterday but various pieces to do with PCI-X, PCIe and changes in NEWBUS would also need to be backported; there's no ETA on this. Regards, BMS From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 13:57:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CB4016A403 for ; Wed, 27 Sep 2006 13:57:27 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0F8143D67 for ; Wed, 27 Sep 2006 13:57:24 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from atlantis.dp.ua (localhost [127.0.0.1]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k8RDvHU4003214 for ; Wed, 27 Sep 2006 16:57:19 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Received: from localhost (dmitry@localhost) by atlantis.dp.ua (8.13.1/8.13.1/Submit) with ESMTP id k8RDvHYK003211 for ; Wed, 27 Sep 2006 16:57:17 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Wed, 27 Sep 2006 16:57:17 +0300 (EEST) From: Dmitry Pryanishnikov To: freebsd-current@freebsd.org Message-ID: <20060927164323.S40914@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: mount -a doesn't obey "ro" in /etc/fstab X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 13:57:27 -0000 Hello! In order to test the new shiny msk driver, I've installed 6.2-PREPELEASE and then upgraded it to the CURRENT as of date=2006.09.26.00.00.00 (to overcome recent libalias breakage, and also to make sure that msk.HEAD.diff will apply cleanly). I've noticed the something very new (and annoying) after the upgrade: all filesystems listed in /etc/fstab with "ro" are still mounted as R/W. Here is my /etc/fstab: # Device Mountpoint FStype Options Dump Pass# /dev/ad0s3b none swap sw 0 0 /dev/ad0s4a / ufs rw,sync 0 1 /dev/ad0s4e /usr ufs rw 0 2 /dev/ad0s3a /mnt3 ufs ro 0 0 /dev/ad0s3d /mnt3/usr ufs ro 0 0 and here is 'mount' output: $ mount /dev/ad0s4a on / (ufs, local, synchronous) devfs on /dev (devfs, local) /dev/ad0s4e on /usr (ufs, local, soft-updates) /dev/ad0s3a on /mnt3 (ufs, local) /dev/ad0s3d on /mnt3/usr (ufs, local, soft-updates) I also can write under /mnt3, so 'mount' correctly shows FS status. mount _does_ obey 'mount -ur /mnt3', it just ignores "ro" in /etc/fstab. Booting into the single-user mode and making 'mount -a' has the same effect. Is this breakage well-known, or something new? Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 14:02:28 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8A3516A403 for ; Wed, 27 Sep 2006 14:02:28 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59F7243D46 for ; Wed, 27 Sep 2006 14:02:23 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5F6F9.dip.t-dialin.net [84.165.246.249]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k8RDbV61068029 for ; Wed, 27 Sep 2006 15:37:32 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (webmail.Leidinger.net [192.168.1.102]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k8RE2H7p049567 for ; Wed, 27 Sep 2006 16:02:17 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from psbru.cec.eu.int (psbru.cec.eu.int [158.169.131.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Wed, 27 Sep 2006 16:01:45 +0200 Message-ID: <20060927160145.vl5ls2dz44ccscwo@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Wed, 27 Sep 2006 16:01:45 +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: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-Virus-Scanned: by amavisd-new Cc: Subject: "recursive lock for object" & "unlocking unheld lock" in smb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 14:02:29 -0000 Hi, yesterday I rsynced a smb share from a samba-3.0.x server (FreeBSD 4) =20 via a smb mount (current from Sep 23) "locally" (mount -t smbfs from =20 the samba server and rsync a/ b/; most easy solution to convert some =20 ISO-8859-1 filenames to UTF-8 ("dos charset =3D UTF8" in smb.conf!) =20 while moving to another system). Today I noticed the following in the daily mail on the -current system: +++ /tmp/security.w9S5FGBa=09Wed Sep 27 03:02:41 2006 +netsmb_dev: loaded +smb_co_lock: recursive lock for object 1 +lockmgr: thread 0xc3d6fbd0 unlocking unheld lock +KDB: stack backtrace: +lockmgr(c79a9c08,2006,c79a9c2c,c3d6fbd0,e5a38b9c,...) at lockmgr+0x529 +smb_co_put(c79a9c00,e5a38b9c,c3d6fbd0,c34a7c00,c79a9c00,...) at =20 smb_co_put+0x6e +smb_sm_lookup(e5a38b28,e5a38b08,e5a38b9c,e5a38b04,c3654a00,...) at =20 smb_sm_lookup+0x10d +smb_usr_lookup(c32cb800,e5a38b9c,e5a38b98,e5a38b94,0,...) at =20 smb_usr_lookup+0x6c +nsmb_dev_ioctl(c3d65200,82fc6e6a,c32cb800,3,c3d6fbd0) at nsmb_dev_ioctl+0x2= d5 +giant_ioctl(c3d65200,82fc6e6a,c32cb800,3,c3d6fbd0,...) at giant_ioctl+0x51 +devfs_ioctl_f(c3b57558,82fc6e6a,c32cb800,c3e36a80,c3d6fbd0) at =20 devfs_ioctl_f+0x9d +kern_ioctl(c3d6fbd0,3,82fc6e6a,c32cb800) at kern_ioctl+0x286 +ioctl(c3d6fbd0) at ioctl+0xca +syscall(3b,3b,3b,bfbfe91c,bfbfe444,...) at syscall+0x28f +Xint0x80_syscall() at Xint0x80_syscall+0x1f +--- syscall (54, FreeBSD ELF32, ioctl), eip =3D 0x28138e43, esp =3D =20 0xbfbfe434, ebp =3D 0xbfbfe750 --- +smb_co_lock: recursive lock for object 1 +lockmgr: thread 0xc3aa8870 unlocking unheld lock +KDB: stack backtrace: +lockmgr(c449dc08,2006,c449dc2c,c3aa8870,e59edb9c,...) at lockmgr+0x529 +smb_co_put(c449dc00,e59edb9c,c3aa8870,c7499700,c449dc00,...) at =20 smb_co_put+0x6e +smb_sm_lookup(e59edb28,e59edb08,e59edb9c,e59edb04,c3654a00,...) at =20 smb_sm_lookup+0x10d +smb_usr_lookup(c30cc800,e59edb9c,e59edb98,e59edb94,0,...) at =20 smb_usr_lookup+0x6c +nsmb_dev_ioctl(c76b4100,82fc6e6a,c30cc800,3,c3aa8870) at nsmb_dev_ioctl+0x2= d5 +giant_ioctl(c76b4100,82fc6e6a,c30cc800,3,c3aa8870,...) at giant_ioctl+0x51 +devfs_ioctl_f(c44d6360,82fc6e6a,c30cc800,c3e36a80,c3aa8870) at =20 devfs_ioctl_f+0x9d +kern_ioctl(c3aa8870,3,82fc6e6a,c30cc800) at kern_ioctl+0x286 +ioctl(c3aa8870) at ioctl+0xca +syscall(bfbf003b,bfbf003b,e59e003b,bfbfe91c,bfbfe444,...) at syscall+0x28f +Xint0x80_syscall() at Xint0x80_syscall+0x1f +--- syscall (54, FreeBSD ELF32, ioctl), eip =3D 0x28138e43, esp =3D =20 0xbfbfe434, ebp =3D 0xbfbfe750 --- To reproduce this it should be enough to setup samba, export something =20 from it and mount it somewhere on a FreeBSD system. I had one file =20 which was not owned by the user I used to authenticate to the samba =20 server and this file was not readable by enyone except the owner =20 itself (root). I tried to rsync twice before having a look at the file =20 at the source system. Maybe this is needed to reproduce this. Bye, Alexander. --=20 Out of the crooked timber of humanity no straight thing can ever be made. =09=09-- Immanuel Kant http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 15:45:13 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8A7416A4D1 for ; Wed, 27 Sep 2006 15:45:13 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15BAD43DB0 for ; Wed, 27 Sep 2006 15:44:29 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k8RFiON7058877; Wed, 27 Sep 2006 11:44:24 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 27 Sep 2006 11:44:23 -0400 User-Agent: KMail/1.9.1 References: <20060927160145.vl5ls2dz44ccscwo@webmail.leidinger.net> In-Reply-To: <20060927160145.vl5ls2dz44ccscwo@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609271144.23681.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 27 Sep 2006 11:44:25 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1947/Tue Sep 26 20:46:56 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Alexander Leidinger Subject: Re: "recursive lock for object" & "unlocking unheld lock" in smb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 15:45:14 -0000 On Wednesday 27 September 2006 10:01, Alexander Leidinger wrote: > Hi, > > yesterday I rsynced a smb share from a samba-3.0.x server (FreeBSD 4) > via a smb mount (current from Sep 23) "locally" (mount -t smbfs from > the samba server and rsync a/ b/; most easy solution to convert some > ISO-8859-1 filenames to UTF-8 ("dos charset = UTF8" in smb.conf!) > while moving to another system). > > Today I noticed the following in the daily mail on the -current system: If you are willing to panic your box, can you try the patch below and get a crashdump when it panics? Then, send me the stack trace from the panic (and keep the crashdump around). Thanks. Index: smb_conn.c =================================================================== RCS file: /usr/cvs/src/sys/netsmb/smb_conn.c,v retrieving revision 1.17 diff -u -r1.17 smb_conn.c --- smb_conn.c 17 Jul 2006 16:12:59 -0000 1.17 +++ smb_conn.c 27 Sep 2006 15:42:35 -0000 @@ -350,6 +350,7 @@ if (smb_co_lockstatus(cp, td) == LK_EXCLUSIVE && (flags & LK_CANRECURSE) == 0) { SMBERROR("recursive lock for object %d\n", cp->co_level); + panic("rescursive lock for object %p", cp); return 0; } return lockmgr(&cp->co_lock, flags, &cp->co_interlock, td); -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 16:16:53 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F153F16A407; Wed, 27 Sep 2006 16:16:53 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from yam.park.rambler.ru (yam.park.rambler.ru [81.19.64.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id D320D43D70; Wed, 27 Sep 2006 16:16:52 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by yam.park.rambler.ru (8.13.6/8.13.3) with ESMTP id k8RGGjbt083499; Wed, 27 Sep 2006 20:16:45 +0400 (MSD) (envelope-from is@rambler-co.ru) Date: Wed, 27 Sep 2006 20:16:45 +0400 (MSD) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: John-Mark Gurney In-Reply-To: <20060923185727.GW23915@funkthat.com> Message-ID: <20060927200042.N4274@is.park.rambler.ru> References: <20060917210426.GI9421@funkthat.com> <20060922171542.G17859@is.park.rambler.ru> <20060922165848.GS23915@funkthat.com> <20060923105426.B20782@is.park.rambler.ru> <20060923185727.GW23915@funkthat.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1588627711-1159373805=:4274" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: kqueue disable on delivery... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 16:16:54 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1588627711-1159373805=:4274 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Sat, 23 Sep 2006, John-Mark Gurney wrote: > Igor Sysoev wrote this message on Sat, Sep 23, 2006 at 11:40 +0400: >> On Fri, 22 Sep 2006, John-Mark Gurney wrote: >> >>> Igor Sysoev wrote this message on Fri, Sep 22, 2006 at 17:25 +0400: >>>> On Sun, 17 Sep 2006, John-Mark Gurney wrote: >>>> >>>>> I have implemented a couple additional features to kqueue. These allow >>>>> kqueue to be a multithreaded event delivery system that can guarantee >>>>> that the event will only be active in one thread at any time. >>>>> >>>>> The first is EV_DOD, aka disable on delivery. When the event will be >>>>> delivered to userland, the knote is marked disabled so we don't >>>>> have to go through the expense of reallocing the knote each time. >>>>> (Reallocation of the knote is also lock intensive, and disabling is >>>>> cheap.) >>>> >>>> In my opinion, it's too implementation specific flag. >>> >>> How else are you doing to solve having multiple threads servicing >>> the same queue at the same time? Also, Apple is planing on having >>> a similar flag to EV_DOD, but I don't know what they are naming it.. >>> I've tried for a while to find out, but haven't been able to... >> >> As I understand EV_DOD or EV_CLEAR|EV_DOD are like simple EV_ONESHOT, >> except the filter is not deleted on delivery, but is disabled skipping >> some in-kernel lock overhead. That's I'd named it too implementation >> specific. >> >> Yes, the EV_CLEAR|EV_DOD guarantees that the event will be active >> in one thread only at any time. But in my practice I saw there is >> necessity to guarantee that the socket (both events - EVFILT_READ >> and EVFILT_WRITE) will be active in one thread only at any time. >> It seems that is the reason why heavy threaded Solaris 10 event ports >> use the oneshot only model where a socket is deleted from port on delivery. > > Only if you need to both read and write active on the socket at once... > In some/many servers, you only need one or the other, such as file > transfer servers like http and ftp... I thought about you flags and believe it would be usefull. Also I think that the cheapness of EV_DISABLE and EV_DOD should be documented. >>>>> Even though this means that the event will only ever be active in a >>>>> thread at a time, (when you're done handling the event, you reenable >>>>> it), removing the event from the queue outside the event handler (say >>>>> a timeout handler for the connection) poses to be a problem. If you >>>>> simply close the socket, the event disappears, but then there is a >>>>> race between another event being created with the same socket, and >>>>> notification of the handler that you want the event to stop. >>>>> >>>>> In order to handle that situation, I have come up w/ EV_FORCEOS, aka >>>>> FORCE ONE_SHOT. EV_ONESHOT events have the advantage that once queued, >>>>> they don't care if they have been activated or not, they will be returned >>>>> the next round. This means that the timeout handler can safely set >>>>> EV_FORCEOS on the handler, and either if it's _DISABLED (handler running >>>>> and will reenable it), or it's _ENABLED, it will get dispatched, allowing >>>>> the handler to detect the EV_FORCEOS flag and teardown the connection. >>>> >>>> I think it should be EVFILT_USER event, allowing to >>>> EV_SET(&kev, fd, EVFILT_USER, 0, 0, 0, udata); >>>> and the event should automatically sets the EV_ONESHOT flag internally. >>> >>> I'll agree EV_FORCEOS is open for discussion, but you did see how much >>> code it adds right? I was surprised at how small the patch was for the >>> additional functionality.. >> >> Yes, EV_FORCEOS is small patch. However, EVFILT_USER is more generic >> (by the way, Solaris 10 event ports allow to send user-specific >> PORT_SOURCE_USER notification). > > I agree EVFILT_USER would be a useful thing, but it is still different > from EV_FORCEOS... Would you like to contribute some the to > EVFILT_USER? I'll look at integrating it... Here is patch and test program. The patch is against 6.2-PRERELEASE. On 7.0 the EVFILT_LIO should be taked into account. test program should show oneshot user event: >./t n: 1, id: 0x55, filt: -10, fl: 0x0010, ff:0, data:0x0, udata: 0x5678 n: 0, id: 0x0, filt: 0, fl: 0x0000, ff:0, data:0x0, udata: 0x0 >> Two years ago I was implementing threads for my server nginx >> on FreeBSD 4.x, using rfork(). In the absence of EVFILT_USER I made >> the condition variables using kill() and EV_SIGNAL and this user-level >> code may panic kernel. > > Does it still? It seems it was fixed in 1.80, 1.79.2.1, and 1.2.2.11 revisions of src/sys/kern/kern_event.c, but there is report that is not so: http://freebsd.rambler.ru/bsdmail/cvs-src_2005/msg04709.html Currently nginx has threads disabled, so I could not test it. Igor Sysoev http://sysoev.ru/en/ --0-1588627711-1159373805=:4274 Content-Type: TEXT/plain; charset=US-ASCII; name="patch.evfilt_user.txt" Content-Transfer-Encoding: BASE64 Content-ID: <20060927201645.D4274@is.park.rambler.ru> Content-Description: Content-Disposition: attachment; filename="patch.evfilt_user.txt" LS0tIHNyYy9zeXMvc3lzL2V2ZW50LmgJRnJpIEp1bCAgMSAyMDoyODozMiAy MDA1DQorKysgc3JjL3N5cy9zeXMvZXZlbnQuaAlXZWQgU2VwIDI3IDE3OjM1 OjA5IDIwMDYNCkBAIC0zOCw4ICszOCw5IEBADQogI2RlZmluZSBFVkZJTFRf VElNRVIJCSgtNykJLyogdGltZXJzICovDQogI2RlZmluZSBFVkZJTFRfTkVU REVWCQkoLTgpCS8qIG5ldHdvcmsgZGV2aWNlcyAqLw0KICNkZWZpbmUgRVZG SUxUX0ZTCQkoLTkpCS8qIGZpbGVzeXN0ZW0gZXZlbnRzICovDQorI2RlZmlu ZSBFVkZJTFRfVVNFUgkJKC0xMCkJLyogdXNlciBldmVudHMgKi8NCiANCi0j ZGVmaW5lIEVWRklMVF9TWVNDT1VOVAkJOQ0KKyNkZWZpbmUgRVZGSUxUX1NZ U0NPVU5UCQkxMA0KIA0KICNkZWZpbmUgRVZfU0VUKGtldnBfLCBhLCBiLCBj LCBkLCBlLCBmKSBkbyB7CVwNCiAJc3RydWN0IGtldmVudCAqa2V2cCA9IChr ZXZwXyk7CQlcDQotLS0gc3JjL3N5cy9rZXJuL2tlcm5fZXZlbnQuYwlNb24g U2VwICA0IDIxOjE3OjI1IDIwMDYNCisrKyBzcmMvc3lzL2tlcm4va2Vybl9l dmVudC5jCVdlZCBTZXAgMjcgMTg6NTM6MjUgMjAwNg0KQEAgLTEzMiw2ICsx MzIsOSBAQA0KIHN0YXRpYyBpbnQJZmlsdF90aW1lcmF0dGFjaChzdHJ1Y3Qg a25vdGUgKmtuKTsNCiBzdGF0aWMgdm9pZAlmaWx0X3RpbWVyZGV0YWNoKHN0 cnVjdCBrbm90ZSAqa24pOw0KIHN0YXRpYyBpbnQJZmlsdF90aW1lcihzdHJ1 Y3Qga25vdGUgKmtuLCBsb25nIGhpbnQpOw0KK3N0YXRpYyBpbnQJZmlsdF91 c2VyYXR0YWNoKHN0cnVjdCBrbm90ZSAqa24pOw0KK3N0YXRpYyB2b2lkCWZp bHRfdXNlcmRldGFjaChzdHJ1Y3Qga25vdGUgKmtuKTsNCitzdGF0aWMgaW50 CWZpbHRfdXNlcihzdHJ1Y3Qga25vdGUgKmtuLCBsb25nIGhpbnQpOw0KIA0K IHN0YXRpYyBzdHJ1Y3QgZmlsdGVyb3BzIGZpbGVfZmlsdG9wcyA9DQogCXsg MSwgZmlsdF9maWxlYXR0YWNoLCBOVUxMLCBOVUxMIH07DQpAQCAtMTQyLDYg KzE0NSw4IEBADQogCXsgMCwgZmlsdF9wcm9jYXR0YWNoLCBmaWx0X3Byb2Nk ZXRhY2gsIGZpbHRfcHJvYyB9Ow0KIHN0YXRpYyBzdHJ1Y3QgZmlsdGVyb3Bz IHRpbWVyX2ZpbHRvcHMgPQ0KIAl7IDAsIGZpbHRfdGltZXJhdHRhY2gsIGZp bHRfdGltZXJkZXRhY2gsIGZpbHRfdGltZXIgfTsNCitzdGF0aWMgc3RydWN0 IGZpbHRlcm9wcyB1c2VyX2ZpbHRvcHMgPQ0KKwl7IDAsIGZpbHRfdXNlcmF0 dGFjaCwgZmlsdF91c2VyZGV0YWNoLCBmaWx0X3VzZXIgfTsNCiANCiBzdGF0 aWMgdW1hX3pvbmVfdAlrbm90ZV96b25lOw0KIHN0YXRpYyBpbnQgCQlrcV9u Y2FsbG91dHMgPSAwOw0KQEAgLTI0Nyw2ICsyNTIsNyBAQA0KIAl7ICZ0aW1l cl9maWx0b3BzIH0sCQkJLyogRVZGSUxUX1RJTUVSICovDQogCXsgJmZpbGVf ZmlsdG9wcyB9LAkJCS8qIEVWRklMVF9ORVRERVYgKi8NCiAJeyAmZnNfZmls dG9wcyB9LAkJCS8qIEVWRklMVF9GUyAqLw0KKwl7ICZ1c2VyX2ZpbHRvcHMg fSwJCQkvKiBFVkZJTFRfVVNFUiAqLw0KIH07DQogDQogLyoNCkBAIC00OTUs NiArNTAxLDI3IEBADQogew0KIA0KIAlyZXR1cm4gKGtuLT5rbl9kYXRhICE9 IDApOw0KK30NCisNCitzdGF0aWMgaW50DQorZmlsdF91c2VyYXR0YWNoKHN0 cnVjdCBrbm90ZSAqa24pDQorew0KKwlrbi0+a25fZmxhZ3MgfD0gRVZfT05F U0hPVDsJCS8qIGF1dG9tYXRpY2FsbHkgc2V0ICovDQorCWtuLT5rbl9zdGF0 dXMgJj0gfktOX0RFVEFDSEVEOwkJLyoga25saXN0X2FkZCB1c3VhbGx5IHNl dHMgaXQgKi8NCisJcmV0dXJuICgwKTsNCit9DQorDQorc3RhdGljIHZvaWQN CitmaWx0X3VzZXJkZXRhY2goc3RydWN0IGtub3RlICprbikNCit7DQorCWtu LT5rbl9zdGF0dXMgfD0gS05fREVUQUNIRUQ7CS8qIGtubGlzdF9yZW1vdmUg dXN1YWxseSBjbGVhcnMgaXQgKi8NCit9DQorDQorc3RhdGljIGludA0KK2Zp bHRfdXNlcihzdHJ1Y3Qga25vdGUgKmtuLCBsb25nIGhpbnQpDQorew0KKw0K KwlyZXR1cm4gKDEpOw0KIH0NCiANCiAvKg0K --0-1588627711-1159373805=:4274-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 16:28:08 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB8BE16A403 for ; Wed, 27 Sep 2006 16:28:08 +0000 (UTC) (envelope-from rnsanchez@gmail.com) Received: from nz-out-0102.google.com (nz-out-0102.google.com [64.233.162.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id E62D443D5A for ; Wed, 27 Sep 2006 16:28:01 +0000 (GMT) (envelope-from rnsanchez@gmail.com) Received: by nz-out-0102.google.com with SMTP id v1so113871nzb for ; Wed, 27 Sep 2006 09:28:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:in-reply-to:references:x-mailer:mime-version:content-type:content-transfer-encoding; b=Xr6QNmg3iSknat48W1sakh9TelAg4TuLXGi2wa8lsu9B8SGgtGbAz7B/8LQxczOnNjFXmFfIU7kqHYzR7cfLo2zqcnqEkLugKs5jv5E2FgOeIkGudoeIkXepU5PaLV7AzfUxbt0VKIZT0350dx9W97OZ1BH+gdDrBPwhOYqmoeg= Received: by 10.64.156.3 with SMTP id d3mr227153qbe; Wed, 27 Sep 2006 09:28:00 -0700 (PDT) Received: from sauron.lan.box ( [200.203.20.184]) by mx.gmail.com with ESMTP id f17sm976366qba.2006.09.27.09.27.59; Wed, 27 Sep 2006 09:28:00 -0700 (PDT) Date: Wed, 27 Sep 2006 13:27:55 -0300 From: Ricardo Nabinger Sanchez To: freebsd-current@freebsd.org Message-Id: <20060927132755.d7da16d9.rnsanchez@gmail.com> In-Reply-To: <20060927164323.S40914@atlantis.atlantis.dp.ua> References: <20060927164323.S40914@atlantis.atlantis.dp.ua> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386-portbld-freebsd6.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Dmitry Pryanishnikov Subject: Re: mount -a doesn't obey "ro" in /etc/fstab X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 16:28:08 -0000 On Wed, 27 Sep 2006 16:57:17 +0300 (EEST) Dmitry Pryanishnikov wrote: > I also can write under /mnt3, so 'mount' correctly shows FS status. mount > _does_ obey 'mount -ur /mnt3', it just ignores "ro" in /etc/fstab. Booting > into the single-user mode and making 'mount -a' has the same effect. > Is this breakage well-known, or something new? Perhaps this is UFS-specific, as I have an ext2 fs mounted as RO: % mount /dev/ad1s3a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad1s2d on /home (ufs, local, soft-updates) /dev/ad1s3d on /tmp (ufs, local, soft-updates) /dev/ad1s1 on /mnt/Audio (ext2fs, local, read-only) % cat /etc/fstab # Device Mountpoint FStype Options Dump Pass# /dev/ad1s3b none swap sw 0 0 /dev/ad1s3a / ufs rw 1 1 /dev/ad1s2d /home ufs rw 2 2 /dev/ad1s3d /tmp ufs rw 2 2 /dev/acd0 /cdrom cd9660 ro,noauto 0 0 /dev/ad1s1 /mnt/Audio ext2fs ro 0 2 /dev/da0s1 /mnt/floppy msdosfs rw,noauto 0 0 /dev/da0s2 /mnt/ipod msdosfs rw,noauto 0 0 -- Ricardo Nabinger Sanchez Powered by FreeBSD "Left to themselves, things tend to go from bad to worse." From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 17:15:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5108716A403 for ; Wed, 27 Sep 2006 17:15:27 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BB2E43D55 for ; Wed, 27 Sep 2006 17:15:18 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from atlantis.dp.ua (localhost [127.0.0.1]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k8RHF9mT015428 for ; Wed, 27 Sep 2006 20:15:09 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Received: from localhost (dmitry@localhost) by atlantis.dp.ua (8.13.1/8.13.1/Submit) with ESMTP id k8RHF9K5015423 for ; Wed, 27 Sep 2006 20:15:09 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Wed, 27 Sep 2006 20:15:09 +0300 (EEST) From: Dmitry Pryanishnikov To: freebsd-current@freebsd.org In-Reply-To: <20060927164323.S40914@atlantis.atlantis.dp.ua> Message-ID: <20060927201233.L79847@atlantis.atlantis.dp.ua> References: <20060927164323.S40914@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: mount -a doesn't obey "ro" in /etc/fstab X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 17:15:27 -0000 On Wed, 27 Sep 2006, Dmitry Pryanishnikov wrote: > will apply cleanly). I've noticed the something very new (and annoying) after > the upgrade: all filesystems listed in /etc/fstab with "ro" are still mounted > as R/W. Here is my /etc/fstab: > > # Device Mountpoint FStype Options Dump Pass# > /dev/ad0s3b none swap sw 0 0 > /dev/ad0s4a / ufs rw,sync 0 1 > /dev/ad0s4e /usr ufs rw 0 2 > /dev/ad0s3a /mnt3 ufs ro 0 0 > /dev/ad0s3d /mnt3/usr ufs ro 0 0 > Is this breakage well-known, or something new? I can confirm that this bug isn't brand new: CURRENT as of 20-Aug on my notebook already has it. So it's kinda "mature" (; Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 17:31:03 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D2CF16A403 for ; Wed, 27 Sep 2006 17:31:03 +0000 (UTC) (envelope-from freebsd@orchid.homeunix.org) Received: from orchid.homeunix.org (aux93.neoplus.adsl.tpnet.pl [83.27.31.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16F6F43D77 for ; Wed, 27 Sep 2006 17:30:59 +0000 (GMT) (envelope-from freebsd@orchid.homeunix.org) Received: from [192.168.1.66] (blackacidevil.orchid.homeunix.org [192.168.1.66]) (authenticated bits=0) by orchid.homeunix.org (8.13.6/8.13.6) with ESMTP id k8RHTrWr010598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 Sep 2006 19:30:02 +0200 (CEST) (envelope-from freebsd@orchid.homeunix.org) Message-ID: <451AB50A.2000007@orchid.homeunix.org> Date: Wed, 27 Sep 2006 19:29:46 +0200 From: Karol Kwiatkowski User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20060927164323.S40914@atlantis.atlantis.dp.ua> <20060927201233.L79847@atlantis.atlantis.dp.ua> In-Reply-To: <20060927201233.L79847@atlantis.atlantis.dp.ua> X-Enigmail-Version: 0.94.1.0 OpenPGP: id=06E09309; url=http://www.orchid.homeunix.org/carlos/gpg/0x06E09309.asc Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------enigF0E020CF46376980ABD28CE6" X-Virus-Scanned: ClamAV 0.88.4/1948/Wed Sep 27 18:03:03 2006 on orchid.homeunix.org X-Virus-Status: Clean Cc: Dmitry Pryanishnikov Subject: Re: mount -a doesn't obey "ro" in /etc/fstab X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd@orchid.homeunix.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2006 17:31:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF0E020CF46376980ABD28CE6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 27/09/2006 19:15, Dmitry Pryanishnikov wrote: > On Wed, 27 Sep 2006, Dmitry Pryanishnikov wrote: >> will apply cleanly). I've noticed the something very new (and >> annoying) after the upgrade: all filesystems listed in /etc/fstab with= >> "ro" are still mounted as R/W. Here is my /etc/fstab: >> >> # Device Mountpoint FStype Options =20 >> Dump Pass# >> /dev/ad0s3b none swap sw 0 = 0 >> /dev/ad0s4a / ufs rw,sync 0 = 1 >> /dev/ad0s4e /usr ufs rw 0 = 2 >> /dev/ad0s3a /mnt3 ufs ro 0 = 0 >> /dev/ad0s3d /mnt3/usr ufs ro 0 = 0 >> Is this breakage well-known, or something new? >=20 > I can confirm that this bug isn't brand new: CURRENT as of 20-Aug on = my > notebook already has it. So it's kinda "mature" (; For what it's worth, it works on 6.1-R: $ uname -sr FreeBSD 6.1-RELEASE $ cat /etc/fstab # Device Mountpoint FStype Options Dump Pass#= /dev/ad0s1b none swap sw 0 0 /dev/ad0s1a / ufs ro 1 1 [...] $ mount /dev/ad0s1a on / (ufs, local, read-only) devfs on /dev (devfs, local) [...] Karol --=20 Karol Kwiatkowski OpenPGP: http://www.orchid.homeunix.org/carlos/gpg/0x06E09309.asc --------------enigF0E020CF46376980ABD28CE6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFGrURezeoPAwGIYsRCIIqAKCYeIF9ZQ6LxRW66JUBibIruKqFxQCgmlvb um1BjjvCWk67w/X0GLxVYIA= =1x/8 -----END PGP SIGNATURE----- --------------enigF0E020CF46376980ABD28CE6-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 18:34:38 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9445116A417; Wed, 27 Sep 2006 18:34:38 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27A6943D81; Wed, 27 Sep 2006 18:34:13 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5F6F9.dip.t-dialin.net [84.165.246.249]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k8RI99OS069035; Wed, 27 Sep 2006 20:09:09 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k8RIXuOI087745; Wed, 27 Sep 2006 20:33:57 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Wed, 27 Sep 2006 20:34:38 +0200 From: Alexander Leidinger To: John Baldwin Message-ID: <20060927203438.1ca77bf0@Magellan.Leidinger.net> In-Reply-To: <200609271144.23681.jhb@freebsd.org> References: <20060927160145.vl5ls2dz44ccscwo@webmail.leidinger.net> <200609271144.23681.jhb@freebsd.org> X-Mailer: Sylpheed-Claws 2.5.2 (GTK+ 2.8.20; i386-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new Cc: freebsd-current@freebsd.org Subject: Re: "recursive lock for object" & "unlocking unheld lock" in smb X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 18:34:38 -0000 Quoting John Baldwin (Wed, 27 Sep 2006 11:44:23 -0400): > On Wednesday 27 September 2006 10:01, Alexander Leidinger wrote: > > Hi, > > > > yesterday I rsynced a smb share from a samba-3.0.x server (FreeBSD 4) > > via a smb mount (current from Sep 23) "locally" (mount -t smbfs from > > the samba server and rsync a/ b/; most easy solution to convert some > > ISO-8859-1 filenames to UTF-8 ("dos charset = UTF8" in smb.conf!) > > while moving to another system). > > > > Today I noticed the following in the daily mail on the -current system: > > If you are willing to panic your box, can you try the patch below and get a Not this one. But I try to reproduce it with another one later this week (not today and not tomorrow). Bye, Alexander. -- Program load too heavy for processor to lift. 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 Wed Sep 27 19:26:44 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6180916A416; Wed, 27 Sep 2006 19:26:44 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from yam.park.rambler.ru (yam.park.rambler.ru [81.19.64.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAC7443D70; Wed, 27 Sep 2006 19:26:37 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by yam.park.rambler.ru (8.13.6/8.13.3) with ESMTP id k8RJQZc2098529; Wed, 27 Sep 2006 23:26:35 +0400 (MSD) (envelope-from is@rambler-co.ru) Date: Wed, 27 Sep 2006 23:26:35 +0400 (MSD) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: John-Mark Gurney In-Reply-To: <20060927200042.N4274@is.park.rambler.ru> Message-ID: <20060927232543.D4722@is.park.rambler.ru> References: <20060917210426.GI9421@funkthat.com> <20060922171542.G17859@is.park.rambler.ru> <20060922165848.GS23915@funkthat.com> <20060923105426.B20782@is.park.rambler.ru> <20060923185727.GW23915@funkthat.com> <20060927200042.N4274@is.park.rambler.ru> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1143742451-1159385195=:4722" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: kqueue disable on delivery... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 19:26:44 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1143742451-1159385195=:4722 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Wed, 27 Sep 2006, Igor Sysoev wrote: > Here is patch and test program. The patch is against 6.2-PRERELEASE. > On 7.0 the EVFILT_LIO should be taked into account. > > test program should show oneshot user event: >> ./t > n: 1, id: 0x55, filt: -10, fl: 0x0010, ff:0, data:0x0, udata: 0x5678 > n: 0, id: 0x0, filt: 0, fl: 0x0000, ff:0, data:0x0, udata: 0x0 Sorry, I missed to attach the test program. Igor Sysoev http://sysoev.ru/en/ --0-1143742451-1159385195=:4722-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 19:29:21 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2186916A40F for ; Wed, 27 Sep 2006 19:29:21 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6651843D4C for ; Wed, 27 Sep 2006 19:29:20 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from atlantis.dp.ua (localhost [127.0.0.1]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k8RJT1Fo054579; Wed, 27 Sep 2006 22:29:11 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Received: from localhost (dmitry@localhost) by atlantis.dp.ua (8.13.1/8.13.1/Submit) with ESMTP id k8RJT1g8054575; Wed, 27 Sep 2006 22:29:01 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Wed, 27 Sep 2006 22:29:01 +0300 (EEST) From: Dmitry Pryanishnikov To: Karol Kwiatkowski In-Reply-To: <451AB50A.2000007@orchid.homeunix.org> Message-ID: <20060927204226.F79847@atlantis.atlantis.dp.ua> References: <20060927164323.S40914@atlantis.atlantis.dp.ua> <20060927201233.L79847@atlantis.atlantis.dp.ua> <451AB50A.2000007@orchid.homeunix.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: mount -a doesn't obey "ro" in /etc/fstab X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 19:29:21 -0000 On Wed, 27 Sep 2006, Karol Kwiatkowski wrote: >> I can confirm that this bug isn't brand new: CURRENT as of 20-Aug on my >> notebook already has it. So it's kinda "mature" (; > > For what it's worth, it works on 6.1-R: > > $ uname -sr > FreeBSD 6.1-RELEASE Yes, I've just checked today's RELENG_6 - bug isn't there, it's CURRENT-specific. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 20:16:35 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3124E16A40F for ; Wed, 27 Sep 2006 20:16:35 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C725443D49 for ; Wed, 27 Sep 2006 20:16:34 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id k8RKGYFx045312 for ; Wed, 27 Sep 2006 15:16:34 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <451ADC21.50206@centtech.com> Date: Wed, 27 Sep 2006 15:16:33 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.7 (X11/20060923) MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1948/Wed Sep 27 11:03:03 2006 on mh1.centtech.com X-Virus-Status: Clean Subject: isofs/cd9660 -> relocate to fs/isofs/cd9660? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 20:16:35 -0000 I noticed that cd9660 file system is in sys/isofs/cd9660 instead of what seems more logical: sys/fs/cd9660. Is there any reason not to move it? Curious mostly.. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 20:43:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 445C216A47C for ; Wed, 27 Sep 2006 20:43:59 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF2A343D49 for ; Wed, 27 Sep 2006 20:43:58 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([165.236.175.187]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k8RKhoGQ020633; Wed, 27 Sep 2006 14:43:55 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <451AE27F.3010506@samsco.org> Date: Wed, 27 Sep 2006 14:43:43 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anderson References: <451ADC21.50206@centtech.com> In-Reply-To: <451ADC21.50206@centtech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: isofs/cd9660 -> relocate to fs/isofs/cd9660? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 20:43:59 -0000 Eric Anderson wrote: > I noticed that cd9660 file system is in sys/isofs/cd9660 instead of what > seems more logical: sys/fs/cd9660. Is there any reason not to move it? > Curious mostly.. > > Eric > > Inertia, mostly. And if you move cd9660, do you also move ufs? Let the bi-yearly debate begin..... Btw, this is a topic that is easily searched on, as it gets brought up fairly regularly. We were a bit late on the schedule this time, though, so thanks for giving it a kickstart. Scott From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 20:50:20 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEBF316A403 for ; Wed, 27 Sep 2006 20:50:20 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 802E243D4C for ; Wed, 27 Sep 2006 20:50:20 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id k8RKoJrF090653; Wed, 27 Sep 2006 15:50:20 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <451AE40A.60109@centtech.com> Date: Wed, 27 Sep 2006 15:50:18 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.7 (X11/20060923) MIME-Version: 1.0 To: Scott Long References: <451ADC21.50206@centtech.com> <451AE27F.3010506@samsco.org> In-Reply-To: <451AE27F.3010506@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1948/Wed Sep 27 11:03:03 2006 on mh2.centtech.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: isofs/cd9660 -> relocate to fs/isofs/cd9660? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 20:50:20 -0000 On 09/27/06 15:43, Scott Long wrote: > Eric Anderson wrote: >> I noticed that cd9660 file system is in sys/isofs/cd9660 instead of what >> seems more logical: sys/fs/cd9660. Is there any reason not to move it? >> Curious mostly.. >> >> Eric >> >> > > Inertia, mostly. And if you move cd9660, do you also move ufs? Let the > bi-yearly debate begin..... > > Btw, this is a topic that is easily searched on, as it gets brought up > fairly regularly. We were a bit late on the schedule this time, though, > so thanks for giving it a kickstart. > > Scott Oh. Ok. Nevermind then. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 21:00:05 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B6DE16A412 for ; Wed, 27 Sep 2006 21:00:05 +0000 (UTC) (envelope-from nullpt@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7ACCB43D72 for ; Wed, 27 Sep 2006 20:59:40 +0000 (GMT) (envelope-from nullpt@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so87539uge for ; Wed, 27 Sep 2006 13:59:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=PpMqq3nw6pwVjaGvoFZOGpKoYlOKKI+pI4JRRLip1zf5VEC5j9q/fVFLlQQl/TzH2jx9RszXRjt2398Zsodbm5bleNNVwLQo0abnuWfhyokoNFbhRcUBKRj90tORVGEV5vXiP0nNBRabJopdbq/T/7mdjPd8orGYZzIW1YzPh9s= Received: by 10.66.220.17 with SMTP id s17mr987103ugg; Wed, 27 Sep 2006 13:59:39 -0700 (PDT) Received: by 10.66.237.20 with HTTP; Wed, 27 Sep 2006 13:59:38 -0700 (PDT) Message-ID: <755cb9fc0609271359u50adfd0es5245a87791126fad@mail.gmail.com> Date: Wed, 27 Sep 2006 21:59:38 +0100 From: "Alexandre Vieira" To: freebsd-current@freebsd.org In-Reply-To: <20060927080017.GA4945@poupinou.org> MIME-Version: 1.0 References: <755cb9fc0609251042h163ff7f1l4e96369ed7bd0106@mail.gmail.com> <20060926083828.GZ4945@poupinou.org> <755cb9fc0609261524k15b096afofa06f40a4002cd49@mail.gmail.com> <20060927080017.GA4945@poupinou.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Acer Aspire 1644WLMi -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Sep 2006 21:00:05 -0000 On 9/27/06, Bruno Ducrot wrote: > > On Tue, Sep 26, 2006 at 11:24:02PM +0100, Alexandre Vieira wrote: > > Hello, > > > > Thanks for your reply. > > > > You can find the .asl here: > > > > http://nullpt.googlepages.com/Acer_Aspire_1644WLMi.asl > > > > A diff is now available at > http://www.poupinou.org/Acer_Aspire_1644WLMi.asl.diff > > It correct those errors: > - The two missing 'Z00A' are replaced by 'Ones' (note that you won't > need it when ACPICA will be upgraded to the latest version, this won't > happens in -stable in the short term, though). > - Eliminate all the ResourceSourceIndex when there is no ResourceSource > onto a Ressource descriptor. This one actually is not a real issue, > but it's more clean now. > > > Ok now do that: > 1- patch your Acer_Aspire_1644WLMi.asl, > 2- invoke > iasl Acer_Aspire_1644WLMi.asl > That will create a DSDT.aml file. > 3- copy this DSDT.aml to /boot > 4- add those lines to your /boot/loader.conf: > > acpi_dsdt_load="YES" > acpi_dsdt_name="/boot/DSDT.aml" > > reboot, and now you should be able to see the battery via > sysctl hw.acpi > > Also look at 11.16.5.3 "Overriding the Default AML" in the handbook > for more details about this procedure: > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/acpi-debug.html > > Cheers, > > -- > Bruno Ducrot > > -- Which is worse: ignorance or apathy? > -- Don't know. Don't care. > Hello, Thanks for the tip, It worked (not sure if it's 100% tough). Here is the output of the isl loading the new .asl: Intel ACPI Component Architecture ASL Optimizing Compiler version 20051021 [Sep 25 2006] Copyright (C) 2000 - 2005 Intel Corporation Supports ACPI Specification Revision 3.0 Acer_Aspire_1644WLMi.asl 410: Store (0x99, P80H) Warning 2098 - Statement is unreachable ^ ASL Input: Acer_Aspire_1644WLMi.asl - 5848 lines, 194483 bytes, 2109 keywords AML Output: DSDT.aml - 19339 bytes 526 named objects 1583 executable opcodes Compilation complete. 0 Errors, 1 Warnings, 0 Remarks, 676 Optimizations dmesg: http://nullpt.googlepages.com/dmesg.txt It has one or two pending acpi errors. I've been testing powerd and is working flawessly. I had to add cpufreq_load to loader.conf in order to powerd work, isn't there a way to include it in the kernel? Also my sound (HDA) card works fine with a new driver at multimedia@ . In terms of hardware it seems almost "supported" :) Thanks in advance. Regards, -- Alexandre Vieira - nullpt@gmail.com From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 21:00:40 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D9F6F16A58D; Wed, 27 Sep 2006 21:00:39 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from yam.park.rambler.ru (yam.park.rambler.ru [81.19.64.116]) by mx1.FreeBSD.org (Postfix) with ESMTP id C747143D81; Wed, 27 Sep 2006 21:00:35 +0000 (GMT) (envelope-from is@rambler-co.ru) Received: from is.park.rambler.ru (is.park.rambler.ru [81.19.64.102]) by yam.park.rambler.ru (8.13.6/8.13.3) with ESMTP id k8RL0YxV006393; Thu, 28 Sep 2006 01:00:34 +0400 (MSD) (envelope-from is@rambler-co.ru) Date: Thu, 28 Sep 2006 01:00:34 +0400 (MSD) From: Igor Sysoev X-X-Sender: is@is.park.rambler.ru To: John-Mark Gurney In-Reply-To: <20060927232543.D4722@is.park.rambler.ru> Message-ID: <20060928005941.O4722@is.park.rambler.ru> References: <20060917210426.GI9421@funkthat.com> <20060922171542.G17859@is.park.rambler.ru> <20060922165848.GS23915@funkthat.com> <20060923105426.B20782@is.park.rambler.ru> <20060923185727.GW23915@funkthat.com> <20060927200042.N4274@is.park.rambler.ru> <20060927232543.D4722@is.park.rambler.ru> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-963167271-1159390834=:4722" Cc: freebsd-current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: kqueue disable on delivery... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 21:00:40 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-963167271-1159390834=:4722 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Wed, 27 Sep 2006, Igor Sysoev wrote: > On Wed, 27 Sep 2006, Igor Sysoev wrote: > >> Here is patch and test program. The patch is against 6.2-PRERELEASE. >> On 7.0 the EVFILT_LIO should be taked into account. >> >> test program should show oneshot user event: >>> ./t >> n: 1, id: 0x55, filt: -10, fl: 0x0010, ff:0, data:0x0, udata: 0x5678 >> n: 0, id: 0x0, filt: 0, fl: 0x0000, ff:0, data:0x0, udata: 0x0 > > Sorry, I missed to attach the test program. Sorry, the pine ignored my attach again. Igor Sysoev http://sysoev.ru/en/ --0-963167271-1159390834=:4722 Content-Type: TEXT/plain; charset=US-ASCII; name="t.c.txt" Content-Transfer-Encoding: BASE64 Content-ID: <20060928010034.R4722@is.park.rambler.ru> Content-Description: Content-Disposition: attachment; filename="t.c.txt" I2luY2x1ZGUgPHN5cy90eXBlcy5oPg0KI2luY2x1ZGUgPHN5cy9ldmVudC5o Pg0KI2luY2x1ZGUgPHN5cy90aW1lLmg+DQojaW5jbHVkZSA8dW5pc3RkLmg+ DQojaW5jbHVkZSA8ZXJybm8uaD4NCg0KaW50DQptYWluKCkNCnsNCiAgICBp bnQgICAgICAgICAgICAgIGtxLCBuOw0KICAgIHN0cnVjdCBrZXZlbnQgICAg a2V2Ow0KICAgIHN0cnVjdCB0aW1lc3BlYyAgdG87DQoNCiAgICBrcSA9IGtx dWV1ZSgpOw0KICAgIGlmIChrcSA9PSAtMSkgew0KICAgICAgICBwcmludGYo ImtxdWV1ZSgpIGZhaWxlZDogKCVkKSVzXG4iLCBlcnJubywgc3RyZXJyb3Io ZXJybm8pKTsNCiAgICAgICAgZXhpdCgxKTsNCiAgICB9DQoNCiAgICBFVl9T RVQoJmtldiwgMHg1NSwgRVZGSUxUX1VTRVIsIEVWX0FERCwgMCwgMHgxMjM0 LCAodm9pZCAqKSAweDU2NzgpOw0KICAgIHRvLnR2X3NlYyA9IDA7DQogICAg dG8udHZfbnNlYyA9IDA7IA0KDQogICAgaWYgKGtldmVudChrcSwgJmtldiwg MSwgTlVMTCwgMCwgJnRvKSA9PSAtMSkgew0KICAgICAgICBwcmludGYoIjFz dCBrZXZlbnQoKSBmYWlsZWQ6ICglZCklc1xuIiwgZXJybm8sIHN0cmVycm9y KGVycm5vKSk7DQogICAgICAgIGV4aXQoMSk7DQogICAgfQ0KDQogICAgbWVt c2V0KCZrZXYsIDAsIHNpemVvZihzdHJ1Y3Qga2V2ZW50KSk7DQoNCiAgICBp ZiAoKG4gPSBrZXZlbnQoa3EsIE5VTEwsIDAsICZrZXYsIDEsICZ0bykpID09 IC0xKSB7DQogICAgICAgIHByaW50ZigiMm5kIGtldmVudCgpIGZhaWxlZDog KCVkKSVzXG4iLCBlcnJubywgc3RyZXJyb3IoZXJybm8pKTsNCiAgICAgICAg ZXhpdCgxKTsNCiAgICB9DQoNCiAgICBwcmludGYoIm46ICVkLCBpZDogJXAs IGZpbHQ6ICVkLCBmbDogMHglMDRYLCBmZjoldSwgZGF0YTolcCwgdWRhdGE6 ICVwXG4iLA0KICAgICAgICAgICBuLCBrZXYuaWRlbnQsIGtldi5maWx0ZXIs IGtldi5mbGFncywga2V2LmZmbGFncywga2V2LmRhdGEsIGtldi51ZGF0YSk7 DQoNCiAgICBtZW1zZXQoJmtldiwgMCwgc2l6ZW9mKHN0cnVjdCBrZXZlbnQp KTsNCg0KICAgIGlmICgobiA9IGtldmVudChrcSwgTlVMTCwgMCwgJmtldiwg MSwgJnRvKSkgPT0gLTEpIHsNCiAgICAgICAgcHJpbnRmKCIzcmQga2V2ZW50 KCkgZmFpbGVkOiAoJWQpJXNcbiIsIGVycm5vLCBzdHJlcnJvcihlcnJubykp Ow0KICAgICAgICBleGl0KDEpOw0KICAgIH0NCg0KICAgIHByaW50Zigibjog JWQsIGlkOiAlcCwgZmlsdDogJWQsIGZsOiAweCUwNFgsIGZmOiV1LCBkYXRh OiVwLCB1ZGF0YTogJXBcbiIsDQogICAgICAgICAgIG4sIGtldi5pZGVudCwg a2V2LmZpbHRlciwga2V2LmZsYWdzLCBrZXYuZmZsYWdzLCBrZXYuZGF0YSwg a2V2LnVkYXRhKTsNCg0KICAgIHJldHVybiAwOw0KfQ0K --0-963167271-1159390834=:4722-- From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 21:52:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BACDB16A40F for ; Wed, 27 Sep 2006 21:52:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6029743D7D for ; Wed, 27 Sep 2006 21:52:54 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k8RLqn4Y061525; Wed, 27 Sep 2006 17:52:49 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Wed, 27 Sep 2006 17:27:29 -0400 User-Agent: KMail/1.9.1 References: <451ADC21.50206@centtech.com> <451AE27F.3010506@samsco.org> In-Reply-To: <451AE27F.3010506@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609271727.29775.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Wed, 27 Sep 2006 17:52:50 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1948/Wed Sep 27 12:03:03 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Subject: Re: isofs/cd9660 -> relocate to fs/isofs/cd9660? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 21:52:59 -0000 On Wednesday 27 September 2006 16:43, Scott Long wrote: > Eric Anderson wrote: > > I noticed that cd9660 file system is in sys/isofs/cd9660 instead of what > > seems more logical: sys/fs/cd9660. Is there any reason not to move it? > > Curious mostly.. > > > > Eric > > > > > > Inertia, mostly. And if you move cd9660, do you also move ufs? Let the > bi-yearly debate begin..... > > Btw, this is a topic that is easily searched on, as it gets brought up > fairly regularly. We were a bit late on the schedule this time, though, > so thanks for giving it a kickstart. We've actually moved most of the filesystems into sys/fs in the past. Only cd9660, nfs, and ufs are in the top-level. I'd still say leave nfs and ufs alone, but sys/isofs/cd9660 -> sys/fs/cd9660 (I wouldn't keep the extra isofs directory) probably wouldn't be but so painful at this point. -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 22:35:03 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FC2E16A47C for ; Wed, 27 Sep 2006 22:35:03 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.228]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1FDB43D7C for ; Wed, 27 Sep 2006 22:33:25 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by wr-out-0506.google.com with SMTP id 71so136379wri for ; Wed, 27 Sep 2006 15:33:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=SoeP63KTR7h65bv3g77zhZ7z1Us4Zobiq6jYNxR+gTObkDd1Iih35KcnP5b+4ZEEVofqODZRhe3JVfJRsdab1+7bmpuSbtwzq83ztTFl4qy1sdQwGP17WReZGaVoWPzvVvAPjIhK1aEXqE/mZoGKXKtRXDEayL5+exsR/MgvYuw= Received: by 10.90.65.11 with SMTP id n11mr620845aga; Wed, 27 Sep 2006 15:33:25 -0700 (PDT) Received: by 10.90.70.6 with HTTP; Wed, 27 Sep 2006 15:33:24 -0700 (PDT) Message-ID: <7579f7fb0609271533v53e66056o45ab633615d6be1b@mail.gmail.com> Date: Wed, 27 Sep 2006 15:33:25 -0700 From: "Matthew Jacob" To: "Oleg Bulyzhin" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: David Christensen , LI Xin , "Simon L. Nielsen" , freebsd-current@freebsd.org Subject: Speaking of BGE(4)- followup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 22:35:03 -0000 FWIW- the PHY problems I was having with BGE still haven't gone away. Not only that, I now have to have my own patched version of 1.140 so that it can compile with all the VLAN changes. Any clue to help here? It's only one AMD system, but one I use a lot. Trying to mount root from nfs:172.16.1.79:/home/FreeBSD/diskless/amd64_7 bge0: PHY read timed out bge0: PHY read timed out bge0: PHY read timed out bge0: PHY read timed out bge0: PHY read timed out bge0: PHY read timed out bge0: PHY read timed out bge0: RX CPU self-diagnostics failed! bge0: flow-through queue init failed bge0: initialization failure bge0: PHY read timed out bge0: PHY read timed out bge0: PHY read timed out bge0: PHY read timed out bge0: PHY read timed out bge0: PHY read timed out bge0: PHY read timed out bge0: RX CPU self-diagnostics failed! bge0: flow-through queue init failed bge0: initialization failure From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 23:06:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1C43816A47C; Wed, 27 Sep 2006 23:06:06 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2B8443D64; Wed, 27 Sep 2006 23:06:04 +0000 (GMT) (envelope-from davidch@broadcom.com) Received: from 10.10.64.154 by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.2.0)); Wed, 27 Sep 2006 16:05:55 -0700 X-Server-Uuid: F962EFE0-448C-40EE-8100-87DF498ED0EA Received: by mail-irva-10.broadcom.com (Postfix, from userid 47) id B97322AF; Wed, 27 Sep 2006 16:05:55 -0700 (PDT) Received: from mail-irva-8.broadcom.com (mail-irva-8 [10.10.64.221]) by mail-irva-10.broadcom.com (Postfix) with ESMTP id 908F42AE; Wed, 27 Sep 2006 16:05:55 -0700 (PDT) Received: from mail-irva-12.broadcom.com (mail-irva-12.broadcom.com [10.10.64.146]) by mail-irva-8.broadcom.com (MOS 3.7.5a-GA) with ESMTP id EGA39214; Wed, 27 Sep 2006 16:05:51 -0700 (PDT) Received: from NT-IRVA-0750.brcm.ad.broadcom.com (nt-irva-0750 [10.8.194.64]) by mail-irva-12.broadcom.com (Postfix) with ESMTP id 1C41769CA3; Wed, 27 Sep 2006 16:05:51 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 27 Sep 2006 16:05:48 -0700 Message-ID: <09BFF2FA5EAB4A45B6655E151BBDD90302084F1B@NT-IRVA-0750.brcm.ad.broadcom.com> In-Reply-To: <7579f7fb0609271533v53e66056o45ab633615d6be1b@mail.gmail.com> Thread-Topic: Speaking of BGE(4)- followup Thread-Index: AcbihPlkxkIlbSjFR0yQX6zWzDbrxQABEBVQ From: "David Christensen" To: "Matthew Jacob" , "Oleg Bulyzhin" X-TMWD-Spam-Summary: SEV=1.1; DFV=A2006092709; IFV=2.0.6,4.0-7; RPD=4.00.0004; RPDID=303030312E30413031303230322E34353142303142332E303030362D412D; ENG=IBF; TS=20060927230556; CAT=NONE; CON=NONE; X-MMS-Spam-Filter-ID: A2006092709_4.00.0004_2.0.6,4.0-7 X-WSS-ID: 6905DC593L0542917-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, LI Xin , "Simon L. Nielsen" Subject: RE: Speaking of BGE(4)- followup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 23:06:06 -0000 > FWIW- the PHY problems I was having with BGE still haven't gone away. > Not only that, I now have to have my own patched version of 1.140 so > that it can compile with all the VLAN changes. >=20 > Any clue to help here? It's only one AMD system, but one I use a lot. Are you saying you have multiple 57XX systems but only this one fails with this error? >=20 > Trying to mount root from=20 > nfs:172.16.1.79:/home/FreeBSD/diskless/amd64_7 > bge0: PHY read timed out > bge0: PHY read timed out > bge0: PHY read timed out > bge0: PHY read timed out > bge0: PHY read timed out > bge0: PHY read timed out > bge0: PHY read timed out > bge0: RX CPU self-diagnostics failed! > bge0: flow-through queue init failed > bge0: initialization failure > bge0: PHY read timed out > bge0: PHY read timed out > bge0: PHY read timed out > bge0: PHY read timed out > bge0: PHY read timed out > bge0: PHY read timed out > bge0: PHY read timed out > bge0: RX CPU self-diagnostics failed! > bge0: flow-through queue init failed > bge0: initialization failure >=20 > Dave=20 From owner-freebsd-current@FreeBSD.ORG Wed Sep 27 23:20:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B0AB16A412; Wed, 27 Sep 2006 23:20:27 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0308F43D78; Wed, 27 Sep 2006 23:20:22 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([165.236.175.187]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k8RNK0Zi021402; Wed, 27 Sep 2006 17:20:06 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <451B0719.9020706@samsco.org> Date: Wed, 27 Sep 2006 17:19:53 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Jacob References: <7579f7fb0609271533v53e66056o45ab633615d6be1b@mail.gmail.com> In-Reply-To: <7579f7fb0609271533v53e66056o45ab633615d6be1b@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: LI Xin , David Christensen , Oleg Bulyzhin , "Simon L. Nielsen" , freebsd-current@freebsd.org Subject: Re: Speaking of BGE(4)- followup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 27 Sep 2006 23:20:27 -0000 Did you try the TUNABLE that I added a few days ago? Scott Matthew Jacob wrote: > FWIW- the PHY problems I was having with BGE still haven't gone away. > Not only that, I now have to have my own patched version of 1.140 so > that it can compile with all the VLAN changes. > > Any clue to help here? It's only one AMD system, but one I use a lot. > > Trying to mount root from nfs:172.16.1.79:/home/FreeBSD/diskless/amd64_7 > bge0: PHY read timed out > bge0: PHY read timed out > bge0: PHY read timed out > bge0: PHY read timed out > bge0: PHY read timed out > bge0: PHY read timed out > bge0: PHY read timed out > bge0: RX CPU self-diagnostics failed! > bge0: flow-through queue init failed > bge0: initialization failure > bge0: PHY read timed out > bge0: PHY read timed out > bge0: PHY read timed out > bge0: PHY read timed out > bge0: PHY read timed out > bge0: PHY read timed out > bge0: PHY read timed out > bge0: RX CPU self-diagnostics failed! > bge0: flow-through queue init failed > bge0: initialization failure > _______________________________________________ > 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 Sep 28 00:10:30 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B25016A415; Thu, 28 Sep 2006 00:10:30 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE6F043D49; Thu, 28 Sep 2006 00:10:29 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id k8S0ASEX086844; Wed, 27 Sep 2006 20:10:28 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id k8S0AT5t062125; Wed, 27 Sep 2006 20:10:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id A6D907302F; Wed, 27 Sep 2006 20:10:28 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060928001028.A6D907302F@freebsd-current.sentex.ca> Date: Wed, 27 Sep 2006 20:10:28 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner2 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on amd64/amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2006 00:10:30 -0000 TB --- 2006-09-27 23:02:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-09-27 23:02:01 - starting HEAD tinderbox run for amd64/amd64 TB --- 2006-09-27 23:02:01 - cleaning the object tree TB --- 2006-09-27 23:02:11 - checking out the source tree TB --- 2006-09-27 23:02:11 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2006-09-27 23:02:11 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-09-27 23:08:59 - building world (CFLAGS=-O2 -pipe) TB --- 2006-09-27 23:08:59 - cd /src TB --- 2006-09-27 23:08:59 - /usr/bin/make -B buildworld >>> World build started on Wed Sep 27 23:09:02 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] cc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/src/sys/boot/i386/boot2/../../common -I/src/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -c /src/sys/boot/i386/boot2/sio.S ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o boot2.out /obj/amd64/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /obj/amd64/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.01 size=7d0 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=152d text=0 data=0 bss=0 entry=0 output: fmt=bin size=1e11 text=114 data=1cfd org=0 entry=0 -17 bytes available *** Error code 1 Stop in /src/sys/boot/i386/boot2. *** Error code 1 Stop in /src/sys/boot/i386. *** Error code 1 Stop in /src/sys/boot. *** Error code 1 Stop in /src/sys. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-09-28 00:10:28 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-09-28 00:10:28 - ERROR: failed to build world TB --- 2006-09-28 00:10:28 - tinderbox aborted TB --- 0.34 user 1.27 system 4107.23 real From owner-freebsd-current@FreeBSD.ORG Thu Sep 28 06:27:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F149C16A416; Thu, 28 Sep 2006 06:27:29 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 282DD43D4C; Thu, 28 Sep 2006 06:27:28 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5D3A9.dip.t-dialin.net [84.165.211.169]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k8S62SXd079142; Thu, 28 Sep 2006 08:02:29 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (webmail.Leidinger.net [192.168.1.102]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k8S6RMWe088518; Thu, 28 Sep 2006 08:27:22 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from psbru.cec.eu.int (psbru.cec.eu.int [158.169.131.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Thu, 28 Sep 2006 08:26:51 +0200 Message-ID: <20060928082651.b6xp2ayu9wg40wok@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 28 Sep 2006 08:26:51 +0200 From: Alexander Leidinger To: John Baldwin References: <451ADC21.50206@centtech.com> <451AE27F.3010506@samsco.org> <200609271727.29775.jhb@freebsd.org> In-Reply-To: <200609271727.29775.jhb@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: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-Virus-Scanned: by amavisd-new Cc: freebsd-current@freebsd.org Subject: Re: isofs/cd9660 -> relocate to fs/isofs/cd9660? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Sep 2006 06:27:30 -0000 Quoting John Baldwin (from Wed, 27 Sep 2006 17:27:29 -0400): > We've actually moved most of the filesystems into sys/fs in the past. Only > cd9660, nfs, and ufs are in the top-level. I'd still say leave nfs and ufs > alone, but sys/isofs/cd9660 -> sys/fs/cd9660 (I wouldn't keep the extra isofs > directory) probably wouldn't be but so painful at this point. I expect a lot of moves when we switch to a VCS where moves are cheap... but on the other hand, maybe this is another bikeshed. Bye, Alexander. -- Vegeterians beware! You are what you eat. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 From owner-freebsd-current@FreeBSD.ORG Thu Sep 28 07:19:40 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05DD316A416 for ; Thu, 28 Sep 2006 07:19:40 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B28F43D7B for ; Thu, 28 Sep 2006 07:19:34 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so480483wxd for ; Thu, 28 Sep 2006 00:19:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=h1S1ecHan3DNg61llo1wz8hUxUz6Hk069+7EUESu+CcaLc/G/+MVLU1xT3aPn9QTiz0MtvtYcE0gLO6ovZe+pV7fwLEoWJQOE1lPsXQXVcOV4lKPZ7JABgXUkYQWJ64vNruV5rFDVjWLzilz0wCpzSUglI37fG1c31ZG24NWxAQ= Received: by 10.90.105.19 with SMTP id d19mr666116agc; Thu, 28 Sep 2006 00:19:34 -0700 (PDT) Received: by 10.90.70.6 with HTTP; Thu, 28 Sep 2006 00:19:34 -0700 (PDT) Message-ID: <7579f7fb0609280019v73c7c5cdtce9f21aee0ecfdc9@mail.gmail.com> Date: Thu, 28 Sep 2006 00:19:34 -0700 From: "Matthew Jacob" To: "David Christensen" In-Reply-To: <09BFF2FA5EAB4A45B6655E151BBDD90302084F1B@NT-IRVA-0750.brcm.ad.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7579f7fb0609271533v53e66056o45ab633615d6be1b@mail.gmail.com> <09BFF2FA5EAB4A45B6655E151BBDD90302084F1B@NT-IRVA-0750.brcm.ad.broadcom.com> Cc: LI Xin , freebsd-current@freebsd.org, Oleg Bulyzhin , "Simon L. Nielsen" Subject: Re: Speaking of BGE(4)- followup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Sep 2006 07:19:40 -0000 On 9/27/06, David Christensen wrote: > > FWIW- the PHY problems I was having with BGE still haven't gone away. > > Not only that, I now have to have my own patched version of 1.140 so > > that it can compile with all the VLAN changes. > > > > Any clue to help here? It's only one AMD system, but one I use a lot. > > Are you saying you have multiple 57XX systems but only this one fails > with this error? No- sorry- that was unclear. This is my only BGE based system. The others all were spazzed out for the last two weeks because they're em(4) based. From owner-freebsd-current@FreeBSD.ORG Thu Sep 28 07:20:14 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 559E816A4A0 for ; Thu, 28 Sep 2006 07:20:14 +0000 (UTC) (envelope-from lydianconcepts@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68D9D43D58 for ; Thu, 28 Sep 2006 07:20:13 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so480641wxd for ; Thu, 28 Sep 2006 00:20:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Mzbwp9D+8u56LW29xy+/lBELR6v5oyi1/Q0On42VIE/vDo+DkAYI2f5lchi3yJH8QXKCDEUO/s3QwP7IbTK0YFfev6e3vNUgI4vjqoXxII3P+x11FYoUI988KI2W2JBgafgEFgwQ2fnxvGJytejdNq+EtKbn/5o7BA/x5KZj1Ww= Received: by 10.90.80.8 with SMTP id d8mr662351agb; Thu, 28 Sep 2006 00:20:12 -0700 (PDT) Received: by 10.90.70.6 with HTTP; Thu, 28 Sep 2006 00:20:12 -0700 (PDT) Message-ID: <7579f7fb0609280020s6a540b20ybe9071c2c48707fa@mail.gmail.com> Date: Thu, 28 Sep 2006 00:20:12 -0700 From: "Matthew Jacob" To: "Scott Long" In-Reply-To: <451B0719.9020706@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <7579f7fb0609271533v53e66056o45ab633615d6be1b@mail.gmail.com> <451B0719.9020706@samsco.org> Cc: LI Xin , David Christensen , Oleg Bulyzhin , "Simon L. Nielsen" , freebsd-current@freebsd.org Subject: Re: Speaking of BGE(4)- followup X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Sep 2006 07:20:14 -0000 > Did you try the TUNABLE that I added a few days ago? Yes. I don't understand what it does, but I did set the value to other than the default. From owner-freebsd-current@FreeBSD.ORG Thu Sep 28 10:16:07 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9C09B16A407; Thu, 28 Sep 2006 10:16:07 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7D85543D83; Thu, 28 Sep 2006 10:15:37 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id CC60B61DB; Thu, 28 Sep 2006 14:15:35 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 92B2261FE; Thu, 28 Sep 2006 14:15:35 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k8SAFZhQ038050; Thu, 28 Sep 2006 14:15:35 +0400 (MSD) (envelope-from ru) Date: Thu, 28 Sep 2006 14:15:35 +0400 From: Ruslan Ermilov To: John Baldwin Message-ID: <20060928101535.GB4708@rambler-co.ru> References: <20060928001028.A6D907302F@freebsd-current.sentex.ca> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="neYutvxvOLaeuPCA" Content-Disposition: inline In-Reply-To: <20060928001028.A6D907302F@freebsd-current.sentex.ca> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found 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: Thu, 28 Sep 2006 10:16:07 -0000 --neYutvxvOLaeuPCA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 27, 2006 at 08:10:28PM -0400, FreeBSD Tinderbox wrote: > TB --- 2006-09-27 23:02:01 - starting HEAD tinderbox run for amd64/amd64 [...] > >>> World build started on Wed Sep 27 23:09:02 UTC 2006 [...] > >>> stage 4.4: building everything > [...] > cc -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at= -a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-= sse2 -mno-sse3 -DUFS1_AND_UFS2 -DFLAGS=3D0x80 -DSIOPRT=3D0x3f8 -DSIOFMT= =3D0x3 -DSIOSPD=3D9600 -I/src/sys/boot/i386/boot2/../../common -I/src/sy= s/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-c= ast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-exte= rns -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -ffreesta= nding -mpreferred-stack-boundary=3D2 -mno-mmx -mno-3dnow -mno-sse -mno-sse= 2 -mno-sse3 -m32 -c /src/sys/boot/i386/boot2/sio.S > ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o b= oot2.out /obj/amd64/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o > objcopy -S -O binary boot2.out boot2.bin > btxld -v -E 0x2000 -f bin -b /obj/amd64/src/sys/boot/i386/boot2/../btx/bt= x/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin > kernel: ver=3D1.01 size=3D7d0 load=3D9000 entry=3D9010 map=3D16M pgctl=3D= 1:1 > client: fmt=3Dbin size=3D152d text=3D0 data=3D0 bss=3D0 entry=3D0 > output: fmt=3Dbin size=3D1e11 text=3D114 data=3D1cfd org=3D0 entry=3D0 > -17 bytes available > *** Error code 1 >=20 > Stop in /src/sys/boot/i386/boot2. > *** Error code 1 >=20 Should be fixed now. After John's commit to btx.S, boot2 build on amd64 broke but not on i386. I added -march=3Di386 to CFLAGS when MACHINE_ARCH is amd64, and got the same object code that i386 would produce (modulo the timestamps). Here's the difference between ``cpp -m32 -dM /dev/null'' and ``cpp -m32 -march=3Di386 -dM /dev/null'' outputs, on amd64: 33a34 > #define __tune_i386__ 1 63d63 < #define __tune_k8__ 1 I.e., by default, -m32 on amd64 still tunes for k8. I don't know what others think about it (perhaps it would still be a good idea to tune for k8 on amd64 even in the boot code), but for now this looked a good work-around to me, and it definitely takes less bytes than the k8-tuned version. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --neYutvxvOLaeuPCA Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFG6DHqRfpzJluFF4RAtQeAJ48t7xrcI8OQIWAUggihnw6lZNc/wCcDwS1 9fQuhsZaXYm8pkN538B0AG4= =M6Zu -----END PGP SIGNATURE----- --neYutvxvOLaeuPCA-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 28 11:09:08 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 71F9216A415 for ; Thu, 28 Sep 2006 11:09:08 +0000 (UTC) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7B0243D45 for ; Thu, 28 Sep 2006 11:09:07 +0000 (GMT) (envelope-from michiel@boland.org) Received: from brakkenstein.nijmegen.internl.net by neerbosch.nijmegen.internl.net via brakkenstein.nijmegen.internl.net [217.149.193.41] with ESMTP for id k8SB96u2017867 (8.13.4/1.4); Thu, 28 Sep 2006 13:09:06 +0200 (MEST) Received: from localhost by brakkenstein.nijmegen.internl.net via mboland@localhost with ESMTP for id k8SB965m029508 (8.13.2/2.02); Thu, 28 Sep 2006 13:09:06 +0200 (MEST) X-Authentication-Warning: brakkenstein.nijmegen.internl.net: mboland owned process doing -bs Date: Thu, 28 Sep 2006 13:09:05 +0200 (MEST) From: Michiel Boland To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: panic in em_txeof X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Sep 2006 11:09:08 -0000 -CURRENT from 25 Sept. (if_em.c has rev 1.147) em, connected to cisco 2950 at 100 Mb full/duplex with TSO disabled. At high load, the card stopped passing network traffic. After I ifconfig-ed the interface down and up again, I got this panic. Obviously neither the network card malfunction or the panic are any good. I hope someone can figure out what's going on. Cheers Michiel Fatal trap 12: page fault while in kernel mode fault virtual address = 0x568 fault code = supervisor read, page not present instruction pointer = 0x20:0xc0464d9a stack pointer = 0x28:0xd3358c50 frame pointer = 0x28:0xd3358c64 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 11 (swi4: clock sio) trap number = 12 panic: page fault KDB: stack backtrace: kdb_backtrace(100,c20736c0,28,d3358c10,c,...) at kdb_backtrace+0x29 panic(c063a952,c065b591,0,0,fffff,...) at panic+0xa8 trap_fatal(d3358c10,568,c20736c0,c069d0a0,0,...) at trap_fatal+0x2b6 trap_pfault(d3358c10,0,568) at trap_pfault+0x1cb trap(d3350008,c04f0028,c2150028,568,ad,...) at trap+0x38d calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc0464d9a, esp = 0xd3358c50, ebp = 0xd3358c64 --- em_txeof(c20f1000) at em_txeof+0x86 em_watchdog(c2131000) at em_watchdog+0xa6 if_slowtimo(0) at if_slowtimo+0x66 softclock(0) at softclock+0x252 ithread_execute_handlers(c2072b04,c2070500) at ithread_execute_handlers+0x125 ithread_loop(c20426c0,d3358d38) at ithread_loop+0x54 fork_exit(c04cea10,c20426c0,d3358d38) at fork_exit+0x7a fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd3358d6c, ebp = 0 --- Uptime: 2d23h21m50s Physical memory: 505 MB Dumping 117 MB: 102 86 (CTRL-C to abort) 70 54 38 22 (CTRL-C to abort) (CTRL-C to abort) 6 #0 doadump () at pcpu.h:166 166 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); (kgdb) bt #0 doadump () at pcpu.h:166 #1 0xc04e3ca4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc04e3f6c in panic (fmt=0xc063a952 "%s") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc0616d0a in trap_fatal (frame=0xd3358c10, eva=1384) at /usr/src/sys/i386/i386/trap.c:867 #4 0xc0616a2b in trap_pfault (frame=0xd3358c10, usermode=0, eva=1384) at /usr/src/sys/i386/i386/trap.c:776 #5 0xc0616625 in trap (frame= {tf_fs = -751501304, tf_es = -1068564440, tf_ds = -1038811096, tf_edi = 1384, tf_esi = 173, tf_ebp = -751465372, tf_isp = -751465412, tf_ebx = -1038800176, tf_edx = -1039200256, tf_ecx = -865996036, tf_eax = 2768, tf_trapno = 12, tf_err = 0, tf_eip = -1069134438, tf_cs = 32, tf_eflags = 66054, tf_esp = -1038938112, tf_ss = 231}) at /usr/src/sys/i386/i386/trap.c:461 #6 0xc060759a in calltrap () at /usr/src/sys/i386/i386/exception.s:138 #7 0xc0464d9a in em_txeof (adapter=0xc20f1000) at /usr/src/sys/dev/em/if_em.c:2956 #8 0xc0461ace in em_watchdog (ifp=0xc2131000) at /usr/src/sys/dev/em/if_em.c:963 #9 0xc05576de in if_slowtimo (arg=0x0) at /usr/src/sys/net/if.c:1415 #10 0xc04f1ac2 in softclock (dummy=0x0) at /usr/src/sys/kern/kern_timeout.c:271 #11 0xc04ce955 in ithread_execute_handlers (p=0xc2072b04, ie=0xc2070500) at /usr/src/sys/kern/kern_intr.c:662 #12 0xc04cea64 in ithread_loop (arg=0xc20426c0) at /usr/src/sys/kern/kern_intr.c:745 #13 0xc04cd8b6 in fork_exit (callout=0xc04cea10 , arg=0xc20426c0, frame=0xd3358d38) at /usr/src/sys/kern/kern_fork.c:818 #14 0xc06075fc in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:199 (kgdb) f 7 #7 0xc0464d9a in em_txeof (adapter=0xc20f1000) at /usr/src/sys/dev/em/if_em.c:2956 2956 num_avail++; (kgdb) info locals i = 173 num_avail = 231 tx_buffer = (struct em_buffer *) 0x568 tx_desc = (struct em_tx_desc *) 0xc2152ad0 ifp = (struct ifnet *) 0xc2131000 From owner-freebsd-current@FreeBSD.ORG Thu Sep 28 06:46:50 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F0DF816A412 for ; Thu, 28 Sep 2006 06:46:50 +0000 (UTC) (envelope-from gw-bsd-current@news.kiev.sovam.com) Received: from news.kiev.sovam.com (news.kiev.sovam.com [212.109.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4747043D53 for ; Thu, 28 Sep 2006 06:46:50 +0000 (GMT) (envelope-from gw-bsd-current@news.kiev.sovam.com) Received: from mail by news.kiev.sovam.com with local (Exim 3.36 #5) id 1GSpfU-000Iyh-00 for freebsd-current@freebsd.org; Thu, 28 Sep 2006 09:46:48 +0300 From: Ivan Synyeokov To: freebsd-current@freebsd.org Date: Thu, 28 Sep 2006 09:46:52 +0300 Message-ID: References: X-Organization: Svit Online (post does not reflect views of Golden Telecom) X-Gated-By: news2list v1.4, (c) Vladimir Litovka X-Gated-Date: Thu Sep 28 06:46:48 2006 GMT X-Mailman-Approved-At: Thu, 28 Sep 2006 11:56:03 +0000 Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ivan Synyeokov List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2006 06:46:51 -0000 This is a multi-part message in MIME format. --------------030701050508000202080506 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 26.09.2006 03:30 Pyun YongHyeon wrote: > Hi, > > I've written a driver for Marvell/SysKonnect Yukon II Gigabit > Ethernet controller. It supports the following GigE adapters. > o SysKonnect SK-9Sxx Yukon Gigabit Ethernet > o SysKonnect SK-9Exx Yukon Gigabit Ethernet > o Marvell Yukon 88E8021CU Gigabit Ethernet > o Marvell Yukon 88E8021 SX/LX Gigabit Ethernet > o Marvell Yukon 88E8022CU Gigabit Ethernet > o Marvell Yukon 88E8022 SX/LX Gigabit Ethernet > o Marvell Yukon 88E8061CU Gigabit Ethernet > o Marvell Yukon 88E8061 SX/LX Gigabit Ethernet > o Marvell Yukon 88E8062CU Gigabit Ethernet > o Marvell Yukon 88E8062 SX/LX Gigabit Ethernet > o Marvell Yukon 88E8035 Gigabit Ethernet > o Marvell Yukon 88E8036 Gigabit Ethernet > o Marvell Yukon 88E8038 Gigabit Ethernet > o Marvell Yukon 88E8050 Gigabit Ethernet > o Marvell Yukon 88E8052 Gigabit Ethernet > o Marvell Yukon 88E8053 Gigabit Ethernet > o Marvell Yukon 88E8055 Gigabit Ethernet > o D-Link 560T Yukon Gigabit Ethernet > I have Epox EP-MF570 MB with two Marvell 88E1116, but unfortunately even pciconf -lv doesn't show anything related to network (on Win LAN is working with native drivers), so I'd like to ask is it possible to make 'em work on your drivers with a little hacking? Unfortunately I'm not a kernel hacker, so it's difficult to me find out what's the problem. Also I tried NDIS, but with no luck too. But nevertheless I really appreciate your work, hope it would be merged into RELENG_6 soon :) P.S. I added dmesg and pciconf, maybe for someone it would be useful. -- Johnny --------------030701050508000202080506 Content-Type: text/plain; name="dmesg.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="dmesg.txt" Copyright (c) 1992-2006 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 7.0-CURRENT #0: Tue Sep 26 20:56:15 EEST 2006 root@localhost:/usr/obj/usr/src.current/sys/current Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3600+ (2009.28-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x40fb2 Stepping = 2 Features=0x178bfbff Features2=0x2001 AMD Features=0xea500800 AMD Features2=0x1f Cores per package: 2 real memory = 1073676288 (1023 MB) avail memory = 1041403904 (993 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) acpi0: on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: reservation of fff00000, 400f0000 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: at device 0.0 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0: at device 1.2 (no driver attached) ohci0: mem 0xfe02f000-0xfe02ffff irq 21 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: SMM does not respond, resetting usb0: on ohci0 usb0: USB revision 1.0 uhub0: on usb0 uhub0: 10 ports with 10 removable, self powered ehci0: mem 0xfe02e000-0xfe02e0ff irq 22 at device 2.1 on pci0 ehci0: [GIANT-LOCKED] usb1: waiting for BIOS to give up control usb1: timed out waiting for BIOS usb1: EHCI version 1.0 usb1: companion controller, 10 ports each: usb0 usb1: on ehci0 usb1: USB revision 2.0 uhub1: on usb1 uhub1: 10 ports with 10 removable, self powered atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf400-0xf40f at device 4.0 on pci0 ata0: on atapci0 ata1: on atapci0 pcib1: at device 6.0 on pci0 pci1: on pcib1 vgapci0: mem 0xfcfc0000-0xfcfdffff,0xfb800000-0xfbffffff,0xfc000000-0xfc7fffff irq 16 at device 4.0 on pci1 pcm0: mem 0xfe024000-0xfe027fff irq 23 at device 6.1 on pci0 pci0: at device 8.0 (no driver attached) pcib2: at device 10.0 on pci0 pci2: on pcib2 pcib3: at device 11.0 on pci0 pci3: on pcib3 atapci1: port 0xcc00-0xcc07,0xc800-0xc803,0xc400-0xc407,0xc000-0xc003,0xbc00-0xbc0f mem 0xfdbfe000-0xfdbfffff irq 16 at device 0.0 on pci3 atapci1: AHCI Version 01.00 controller with 2 ports detected ata2: on atapci1 ata3: on atapci1 ata4: on atapci1 pcib4: at device 13.0 on pci0 pci4: on pcib4 pcib5: at device 14.0 on pci0 pci5: on pcib5 pcib6: at device 15.0 on pci0 pci6: on pcib6 acpi_tz0: on acpi0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio0: [FAST] atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xc7fff,0xc8000-0xcbfff,0xcc000-0xcd7ff,0xce000-0xd07ff pnpid ORM0000 on isa0 ppc0: parallel port not found. sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Timecounters tick every 1.000 msec ad0: 190782MB at ata0-master UDMA100 acd0: CDROM at ata0-slave PIO4 pcm0: pcm0: SMP: AP CPU #1 Launched! Trying to mount root from ufs:/dev/ad0s2a --------------030701050508000202080506 Content-Type: text/plain; name="pciconf.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="pciconf.txt" none0@pci0:0:0: class=0x050000 card=0x10261695 chip=0x036910de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = memory subclass = RAM isab0@pci0:1:0: class=0x060100 card=0x10261695 chip=0x036010de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-ISA none1@pci0:1:1: class=0x0c0500 card=0x10261695 chip=0x036810de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = serial bus subclass = SMBus none2@pci0:1:2: class=0x050000 card=0x10261695 chip=0x036a10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = memory subclass = RAM ohci0@pci0:2:0: class=0x0c0310 card=0x10261695 chip=0x036c10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = serial bus subclass = USB ehci0@pci0:2:1: class=0x0c0320 card=0x10261695 chip=0x036d10de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = serial bus subclass = USB atapci0@pci0:4:0: class=0x01018a card=0x10261695 chip=0x036e10de rev=0xa1 hdr=0x00 vendor = 'NVIDIA Corporation' class = mass storage subclass = ATA pcib1@pci0:6:0: class=0x060401 card=0x000000b8 chip=0x037010de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-PCI pcm0@pci0:6:1: class=0x040300 card=0x10261695 chip=0x037110de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = multimedia none3@pci0:8:0: class=0x068000 card=0x10261695 chip=0x037310de rev=0xa2 hdr=0x00 vendor = 'NVIDIA Corporation' class = bridge pcib2@pci0:10:0: class=0x060400 card=0x00000040 chip=0x037610de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-PCI pcib3@pci0:11:0: class=0x060400 card=0x00000040 chip=0x037410de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-PCI pcib4@pci0:13:0: class=0x060400 card=0x00000040 chip=0x037810de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-PCI pcib5@pci0:14:0: class=0x060400 card=0x00000040 chip=0x037510de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-PCI pcib6@pci0:15:0: class=0x060400 card=0x00000040 chip=0x037710de rev=0xa2 hdr=0x01 vendor = 'NVIDIA Corporation' class = bridge subclass = PCI-PCI hostb0@pci0:24:0: class=0x060000 card=0x00000000 chip=0x11001022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron HyperTransport Technology Configuration' class = bridge subclass = HOST-PCI hostb1@pci0:24:1: class=0x060000 card=0x00000000 chip=0x11011022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron Address Map' class = bridge subclass = HOST-PCI hostb2@pci0:24:2: class=0x060000 card=0x00000000 chip=0x11021022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron DRAM Controller' class = bridge subclass = HOST-PCI hostb3@pci0:24:3: class=0x060000 card=0x00000000 chip=0x11031022 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices (AMD)' device = 'Athlon 64 / Opteron Miscellaneous Control' class = bridge subclass = HOST-PCI vgapci0@pci1:4:0: class=0x030000 card=0x100f1102 chip=0x3d07104c rev=0x01 hdr=0x00 vendor = 'Texas Instruments (TI)' device = 'TVP4020 AGP Permedia 2' class = display subclass = VGA atapci1@pci3:0:0: class=0x010400 card=0x2363197b chip=0x2363197b rev=0x02 hdr=0x00 class = mass storage subclass = RAID --------------030701050508000202080506-- From owner-freebsd-current@FreeBSD.ORG Thu Sep 28 12:13:48 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 93AE716A416 for ; Thu, 28 Sep 2006 12:13:48 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 899FF43D73 for ; Thu, 28 Sep 2006 12:13:45 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so691399pye for ; Thu, 28 Sep 2006 05:13:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=M+8ALmMODQb832Fnv6w8ocGrvYtIn1yl2U8oiQUgMf8qr8YgPkc2kyVvCruyiTfSMsM1hQX6BSZPsV6if2UiSMo4U03zBKMVEHwC4NE/0nu8xN6DbA76s/Iu2VtXIf8vHN1omiplDEjdWM9/+Bo48Qz9C7UPAKlC+lEIksf3f40= Received: by 10.35.46.11 with SMTP id y11mr159541pyj; Thu, 28 Sep 2006 05:13:43 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 15sm1066018nzo.2006.09.28.05.13.41; Thu, 28 Sep 2006 05:13:42 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k8SCELZs025157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Sep 2006 21:14:21 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k8SCEIPM025156; Thu, 28 Sep 2006 21:14:18 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Thu, 28 Sep 2006 21:14:18 +0900 From: Pyun YongHyeon To: Ivan Synyeokov Message-ID: <20060928121418.GD16898@cdnetworks.co.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2006 12:13:48 -0000 On Thu, Sep 28, 2006 at 09:46:52AM +0300, Ivan Synyeokov wrote: > This is a multi-part message in MIME format. > --------------030701050508000202080506 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > > On 26.09.2006 03:30 Pyun YongHyeon wrote: > > Hi, > > > > I've written a driver for Marvell/SysKonnect Yukon II Gigabit > > Ethernet controller. It supports the following GigE adapters. > > o SysKonnect SK-9Sxx Yukon Gigabit Ethernet > > o SysKonnect SK-9Exx Yukon Gigabit Ethernet > > o Marvell Yukon 88E8021CU Gigabit Ethernet > > o Marvell Yukon 88E8021 SX/LX Gigabit Ethernet > > o Marvell Yukon 88E8022CU Gigabit Ethernet > > o Marvell Yukon 88E8022 SX/LX Gigabit Ethernet > > o Marvell Yukon 88E8061CU Gigabit Ethernet > > o Marvell Yukon 88E8061 SX/LX Gigabit Ethernet > > o Marvell Yukon 88E8062CU Gigabit Ethernet > > o Marvell Yukon 88E8062 SX/LX Gigabit Ethernet > > o Marvell Yukon 88E8035 Gigabit Ethernet > > o Marvell Yukon 88E8036 Gigabit Ethernet > > o Marvell Yukon 88E8038 Gigabit Ethernet > > o Marvell Yukon 88E8050 Gigabit Ethernet > > o Marvell Yukon 88E8052 Gigabit Ethernet > > o Marvell Yukon 88E8053 Gigabit Ethernet > > o Marvell Yukon 88E8055 Gigabit Ethernet > > o D-Link 560T Yukon Gigabit Ethernet > > > > > I have Epox EP-MF570 MB with two Marvell 88E1116, but unfortunately even > pciconf -lv doesn't show anything related to network (on Win LAN is > working with native drivers), so I'd like to ask is it possible to make > 'em work on your drivers with a little hacking? > Unfortunately I'm not a kernel hacker, so it's difficult to me find out > what's the problem. Also I tried NDIS, but with no luck too. > > But nevertheless I really appreciate your work, hope it would be merged > into RELENG_6 soon :) > > P.S. I added dmesg and pciconf, maybe for someone it would be useful. > I'm not sure but 88E1116 seems to Gigabit PHY not ethernet controller. Have you tried nve(4) or nfe(4) on CURRENT? -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Thu Sep 28 12:46:09 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 016BF16A415 for ; Thu, 28 Sep 2006 12:46:09 +0000 (UTC) (envelope-from joao@matik.com.br) Received: from msrv.matik.com.br (msrv.matik.com.br [200.152.83.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFB3F43D5C for ; Thu, 28 Sep 2006 12:46:04 +0000 (GMT) (envelope-from joao@matik.com.br) Received: from ap-h.matik.com.br (ap-h.matik.com.br [200.152.83.36]) by msrv.matik.com.br (8.13.8/8.13.1) with ESMTP id k8SCk2FA003215; Thu, 28 Sep 2006 09:46:02 -0300 (BRT) (envelope-from joao@matik.com.br) From: JoaoBR Organization: Infomatik To: freebsd-current@freebsd.org, Ivan Synyeokov Date: Thu, 28 Sep 2006 09:46:05 -0300 User-Agent: KMail/1.9.3 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200609280946.05893.joao@matik.com.br> X-Virus-Scanned: ClamAV version 0.88.4, clamav-milter version 0.88.4 on msrv.matik.com.br X-Virus-Status: Clean Cc: Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Sep 2006 12:46:09 -0000 On Thursday 28 September 2006 03:46, Ivan Synyeokov wrote: > I have Epox EP-MF570 MB with two Marvell 88E1116, but unfortunately even > pciconf -lv doesn't show anything related to network (on Win LAN is > working with native drivers), so I'd like to ask is it possible to make > 'em work on your drivers with a little hacking? Hi probably you find here what you need: http://www.se.hiroshima-u.ac.jp/~shigeaki/software/freebsd-nfe.html =2D-=20 Jo=E3o A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura. Service fornecido pelo Datacenter Matik https://datacenter.matik.com.br From owner-freebsd-current@FreeBSD.ORG Thu Sep 28 14:04:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB5E116A403 for ; Thu, 28 Sep 2006 14:04:34 +0000 (UTC) (envelope-from pbliss@mechno.com) Received: from helix.fantasyland.com (helix.fantasyland.com [216.238.193.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id B990143D5E for ; Thu, 28 Sep 2006 14:04:17 +0000 (GMT) (envelope-from pbliss@mechno.com) Received: from helix.fantasyland.com (localhost [127.0.0.1]) by helix.fantasyland.com (Postfix) with ESMTP id DB1141CC83 for ; Thu, 28 Sep 2006 10:04:16 -0400 (EDT) Received: from localhost (pbliss@localhost) by helix.fantasyland.com (8.13.6/8.13.6/Submit) with ESMTP id k8SE4GvZ021159 for ; Thu, 28 Sep 2006 10:04:16 -0400 (EDT) (envelope-from pbliss@mechno.com) X-Authentication-Warning: helix.fantasyland.com: pbliss owned process doing -bs Date: Thu, 28 Sep 2006 10:04:16 -0400 (EDT) From: Paul Bliss X-X-Sender: pbliss@helix.fantasyland.com To: freebsd-current@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Sata controller headache X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Sep 2006 14:04:34 -0000 Hello all, I recently rebuilt my server and made a few upgrades. I'm running 6.1 RELEASE and I've been having very annoying crashes that I think are related to my SATA Controller. I'm using the Promise FastTrak TX2300 controller with a Western Digital WD2500KS. The problem I'm having is that when I execute a command that hits the disc too hard, such an "ls -laR /foo" /var/log messages is giving me errors that look like this: Sep 28 01:23:19 helix kernel: ad4: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=310114239 Sep 28 01:23:19 helix kernel: ad4: WARNING - READ_DMA48 UDMA ICRC error (retrying request) LBA=310114239 Sep 28 01:23:28 helix kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Sep 28 01:23:44 helix kernel: ad4: WARNING - SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Sep 28 01:23:44 helix kernel: ad4: WARNING - SETFEATURES ENABLE RCACHE taskqueue timeout - completing request directly Sep 28 01:23:44 helix kernel: ad4: WARNING - SETFEATURES ENABLE WCACHE taskqueue timeout - completing request directly Sep 28 01:23:44 helix kernel: ad4: WARNING - SET_MULTI taskqueue timeout - completing request directly Sep 28 01:23:44 helix kernel: ad4: FAILURE - READ_DMA48 timed out LBA=310114239 Sep 28 01:23:44 helix kernel: g_vfs_done():ad4s1f[READ(offset=42109632512, length=131072)]error = 5 Has anyone else seen this? Any suggestions? I'm tempted to use atacontrol to change the mode, but I figured I'd ask the list first. TIA for the help! -Paul P.S. Output of "smartctl -a /dev/ad4/ smartctl version 5.36 [i386-portbld-freebsd6.1] Copyright (C) 2002-6 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Device Model: WDC WD2500KS-00MJB0 Serial Number: WD-WCANK3148169 Firmware Version: 02.01C03 User Capacity: 250,059,350,016 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 7 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Thu Sep 28 09:58:50 2006 EDT SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED See vendor-specific Attribute list for marginal Attributes. General SMART Values: Offline data collection status: (0x84) Offline data collection activity was suspended by an interrupting command from host. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: (7080) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 83) minutes. Conveyance self-test routine recommended polling time: ( 6) minutes. SMART Attributes Data Structure revision number: 16 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 200 200 051 Pre-fail Always - 0 3 Spin_Up_Time 0x0003 217 217 021 Pre-fail Always - 4125 4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 29 5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 200 200 051 Pre-fail Always - 0 9 Power_On_Hours 0x0032 093 093 000 Old_age Always - 5117 10 Spin_Retry_Count 0x0013 100 253 051 Pre-fail Always - 0 11 Calibration_Retry_Count 0x0012 100 253 051 Old_age Always - 0 12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 28 190 Unknown_Attribute 0x0022 038 026 045 Old_age Always FAILING_NOW 62 194 Temperature_Celsius 0x0022 088 076 000 Old_age Always - 62 196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0 197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 200 200 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 9 200 Multi_Zone_Error_Rate 0x0009 200 200 051 Pre-fail Offline - 0 SMART Error Log Version: 1 No Errors Logged SMART Self-test log structure revision number 1 No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. From owner-freebsd-current@FreeBSD.ORG Thu Sep 28 18:00:39 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B272916A561 for ; Thu, 28 Sep 2006 18:00:39 +0000 (UTC) (envelope-from mb@imp.ch) Received: from pop.imp.ch (mx2.imp.ch [157.161.9.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5951C43D8A for ; Thu, 28 Sep 2006 18:00:15 +0000 (GMT) (envelope-from mb@imp.ch) Received: from godot.imp.ch (godot.imp.ch [157.161.4.8]) by pop.imp.ch (8.13.8/8.13.8/Submit_imp) with ESMTP id k8SI0C20078571 for ; Thu, 28 Sep 2006 20:00:13 +0200 (CEST) (envelope-from mb@imp.ch) Date: Thu, 28 Sep 2006 20:00:12 +0200 (CEST) From: Martin Blapp To: current@freebsd.org Message-ID: <20060928195536.Y91466@godot.imp.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.57 on 157.161.9.65 Cc: Subject: CURRENT unusable again, too many panics X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Sep 2006 18:00:39 -0000 Hi all, In 9 from 10 boots I get the panic below. If I remove everything from /tmp/vi.recover the box is bootable again. It looks like vi.recover triggers a bug in the vm_system. Anybody has some idea ? A kernel from June works fine. RELENG_6 works fine. A fresh kernel from today shows: Unread portion of the kernel message buffer: <118>Configuring syscons: <118> keymap panic: vm_page_free_toq: freeing mapped page 0xc2eb1eb8 cpuid = 0 KDB: enter: panic panic: from debugger cpuid = 0 Uptime: 42s Physical memory: 2035 MB Dumping 78 MB: 63 47 31 15 (kgdb) where #0 doadump () at pcpu.h:166 #1 0xc06a15b0 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc06a18c5 in panic (fmt=0xc08e884b "from debugger") at /usr/src/sys/kern/kern_shutdown.c:565 #3 0xc0475ee6 in db_panic (addr=-1066666149, have_addr=0, count=-1, modif=0xe539d7c8 "") at /usr/src/sys/ddb/db_command.c:428 #4 0xc0475e7f in db_command (last_cmdp=0xc09fc3e4, cmd_table=0x0) at /usr/src/sys/ddb/db_command.c:396 #5 0xc0475f3a in db_command_loop () at /usr/src/sys/ddb/db_command.c:448 #6 0xc0477b39 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221 #7 0xc06bfa34 in kdb_trap (type=3, code=0, tf=0xe539d958) at /usr/src/sys/kern/subr_kdb.c:502 #8 0xc08a0fb4 in trap (frame= {tf_fs = -449249272, tf_es = -1066663896, tf_ds = -1064173528, tf_edi = -1064023194, tf_esi = 1, tf_ebp = -449193576, tf_isp = -449193596, tf_ebx = -449193532, tf_edx = 0, tf_ecx = -1052561408, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1066666149, tf_cs = 32, tf_eflags = 642, tf_esp = -449193544, tf_ss = -1066788745}) at /usr/src/sys/i386/i386/trap.c:620 #9 0xc088be3a in calltrap () at /usr/src/sys/i386/i386/exception.s:138 #10 0xc06bf75b in kdb_enter (msg=0x12
) at cpufunc.h:60 #11 0xc06a1877 in panic (fmt=0xc0944b66 "vm_page_free_toq: freeing mapped page %p") at /usr/src/sys/kern/kern_shutdown.c:549 #12 0xc0805402 in vm_page_free_toq (m=0xc2eb1eb8) at /usr/src/sys/vm/vm_page.c:1087 #13 0xc08048e1 in vm_page_free (m=0xc2eb1eb8) at /usr/src/sys/vm/vm_page.c:470 #14 0xc08020ad in vm_object_terminate (object=0xc53a2a50) at /usr/src/sys/vm/vm_object.c:657 #15 0xc0801f85 in vm_object_deallocate (object=0xc53a2a50) at /usr/src/sys/vm/vm_object.c:590 #16 0xc07feb4c in vm_map_entry_delete (map=0xc14650a8, entry=0xc53750cc) at /usr/src/sys/vm/vm_map.c:2283 #17 0xc07fec80 in vm_map_delete (map=0xc14650a8, start=3242610856, end=3792687104) at /usr/src/sys/vm/vm_map.c:2372 #18 0xc07fc3a8 in kmem_free_wakeup (map=0xc14650a8, addr=3792416768, size=18) at /usr/src/sys/vm/vm_kern.c:467 #19 0xc0689126 in exec_free_args (args=0xe539dc60) at /usr/src/sys/kern/kern_exec.c:1055 #20 0xc0688ad7 in do_execve (td=0xc50fdd80, args=0xe539dc60, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:795 #21 0xc0687ee0 in kern_execve (td=0xc50fdd80, args=0xe539dc60, mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:258 #22 0xc0687e4b in execve (td=0xc50fdd80, uap=0x12) at /usr/src/sys/kern/kern_exec.c:188 #23 0xc08a1802 in syscall (frame= {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 0, tf_esi = 0, tf_ebp = 0, tf_isp = 0, tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax = 0, tf_trapno = 0, tf_err = 0, tf_eip = 671410388, tf_cs = 51, tf_eflags = 514, tf_esp = -1077940784, tf_ss = 59}) at /usr/src/sys/i386/i386/trap.c:1006 #24 0xc088be8f in Xint0x80_syscall () at /usr/src/sys/i386/i386/exception.s:191 Martin Blapp, ------------------------------------------------------------------ ImproWare AG, UNIXSP & ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 61 826 93 00 Fax: +41 61 826 93 01 PGP: PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E ------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu Sep 28 17:28:00 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C09F316A416; Thu, 28 Sep 2006 17:28:00 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E74C43D76; Thu, 28 Sep 2006 17:27:53 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 8085961FF79; Fri, 29 Sep 2006 03:27:51 +1000 (EST) Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id k8SHRnj7010287; Fri, 29 Sep 2006 03:27:50 +1000 Date: Fri, 29 Sep 2006 01:55:59 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: Ruslan Ermilov In-Reply-To: <20060928101535.GB4708@rambler-co.ru> Message-ID: <20060929014648.T2802@epsplex.bde.org> References: <20060928001028.A6D907302F@freebsd-current.sentex.ca> <20060928101535.GB4708@rambler-co.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Thu, 28 Sep 2006 19:17:13 +0000 Cc: amd64@FreeBSD.org, current@FreeBSD.org, John Baldwin 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: Thu, 28 Sep 2006 17:28:00 -0000 On Thu, 28 Sep 2006, Ruslan Ermilov wrote: > I.e., by default, -m32 on amd64 still tunes for k8. I don't > know what others think about it (perhaps it would still be > a good idea to tune for k8 on amd64 even in the boot code), No, speed is unimportant and tuning for Athlons generally gives larger code (though it probably shouldn't with -Os). However, tuning for i386 might not give smallest code. amd64 can also execute non-i386 instructions so it could use "arch"ing instead of tuning for Athlons. At least bswap would be smaller (probably not enough other instructions to matter). I don't know how to use non-i386 instructions without losing tuning for i386's. > but for now this looked a good work-around to me, and it > definitely takes less bytes than the k8-tuned version. Bruce From owner-freebsd-current@FreeBSD.ORG Thu Sep 28 19:48:46 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4DE1616A4A0 for ; Thu, 28 Sep 2006 19:48:46 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (cell.sick.ru [217.72.144.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9789543D69 for ; Thu, 28 Sep 2006 19:48:38 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.4/8.13.3) with ESMTP id k8SJmVOB083083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Sep 2006 23:48:32 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.4/8.13.1/Submit) id k8SJmVWq083082; Thu, 28 Sep 2006 23:48:31 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 28 Sep 2006 23:48:31 +0400 From: Gleb Smirnoff To: Michiel Boland Message-ID: <20060928194831.GF59833@FreeBSD.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Cc: freebsd-current@FreeBSD.org Subject: Re: panic in em_txeof X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Sep 2006 19:48:46 -0000 On Thu, Sep 28, 2006 at 01:09:05PM +0200, Michiel Boland wrote: M> -CURRENT from 25 Sept. (if_em.c has rev 1.147) M> M> em, connected to cisco 2950 at 100 Mb full/duplex with TSO disabled. M> M> At high load, the card stopped passing network traffic. After I M> ifconfig-ed the interface down and up again, I got this panic. M> M> Obviously neither the network card malfunction or the panic are any good. M> I hope someone can figure out what's going on. M> M> Cheers M> Michiel M> M> Fatal trap 12: page fault while in kernel mode M> fault virtual address = 0x568 M> fault code = supervisor read, page not present M> instruction pointer = 0x20:0xc0464d9a M> stack pointer = 0x28:0xd3358c50 M> frame pointer = 0x28:0xd3358c64 M> code segment = base 0x0, limit 0xfffff, type 0x1b M> = DPL 0, pres 1, def32 1, gran 1 M> processor eflags = interrupt enabled, resume, IOPL = 0 M> current process = 11 (swi4: clock sio) M> trap number = 12 M> panic: page fault M> KDB: stack backtrace: M> kdb_backtrace(100,c20736c0,28,d3358c10,c,...) at kdb_backtrace+0x29 M> panic(c063a952,c065b591,0,0,fffff,...) at panic+0xa8 M> trap_fatal(d3358c10,568,c20736c0,c069d0a0,0,...) at trap_fatal+0x2b6 M> trap_pfault(d3358c10,0,568) at trap_pfault+0x1cb M> trap(d3350008,c04f0028,c2150028,568,ad,...) at trap+0x38d M> calltrap() at calltrap+0x5 M> --- trap 0xc, eip = 0xc0464d9a, esp = 0xd3358c50, ebp = 0xd3358c64 --- M> em_txeof(c20f1000) at em_txeof+0x86 M> em_watchdog(c2131000) at em_watchdog+0xa6 M> if_slowtimo(0) at if_slowtimo+0x66 M> softclock(0) at softclock+0x252 M> ithread_execute_handlers(c2072b04,c2070500) at M> ithread_execute_handlers+0x125 M> ithread_loop(c20426c0,d3358d38) at ithread_loop+0x54 M> fork_exit(c04cea10,c20426c0,d3358d38) at fork_exit+0x7a M> fork_trampoline() at fork_trampoline+0x8 M> --- trap 0x1, eip = 0, esp = 0xd3358d6c, ebp = 0 --- M> Uptime: 2d23h21m50s M> Physical memory: 505 MB M> Dumping 117 MB: 102 86 (CTRL-C to abort) 70 54 38 22 (CTRL-C to abort) M> (CTRL-C to abort) 6 M> M> #0 doadump () at pcpu.h:166 M> 166 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); M> (kgdb) bt M> #0 doadump () at pcpu.h:166 M> #1 0xc04e3ca4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 M> #2 0xc04e3f6c in panic (fmt=0xc063a952 "%s") at M> /usr/src/sys/kern/kern_shutdown.c:565 M> #3 0xc0616d0a in trap_fatal (frame=0xd3358c10, eva=1384) at M> /usr/src/sys/i386/i386/trap.c:867 M> #4 0xc0616a2b in trap_pfault (frame=0xd3358c10, usermode=0, eva=1384) at M> /usr/src/sys/i386/i386/trap.c:776 M> #5 0xc0616625 in trap (frame= M> {tf_fs = -751501304, tf_es = -1068564440, tf_ds = -1038811096, tf_edi M> = 1384, tf_esi = 173, tf_ebp = -751465372, tf_isp = -751465412, M> tf_ebx = -1038800176, tf_edx = -1039200256, tf_ecx = -865996036, M> tf_eax = 2768, tf_trapno = 12, tf_err = 0, tf_eip = -1069134438, M> tf_cs = 32, tf_eflags = 66054, tf_esp = -1038938112, tf_ss = 231}) at M> /usr/src/sys/i386/i386/trap.c:461 M> #6 0xc060759a in calltrap () at /usr/src/sys/i386/i386/exception.s:138 M> #7 0xc0464d9a in em_txeof (adapter=0xc20f1000) at M> /usr/src/sys/dev/em/if_em.c:2956 M> #8 0xc0461ace in em_watchdog (ifp=0xc2131000) at M> /usr/src/sys/dev/em/if_em.c:963 M> #9 0xc05576de in if_slowtimo (arg=0x0) at /usr/src/sys/net/if.c:1415 M> #10 0xc04f1ac2 in softclock (dummy=0x0) at M> /usr/src/sys/kern/kern_timeout.c:271 M> #11 0xc04ce955 in ithread_execute_handlers (p=0xc2072b04, ie=0xc2070500) at M> /usr/src/sys/kern/kern_intr.c:662 M> #12 0xc04cea64 in ithread_loop (arg=0xc20426c0) at M> /usr/src/sys/kern/kern_intr.c:745 M> #13 0xc04cd8b6 in fork_exit (callout=0xc04cea10 , M> arg=0xc20426c0, frame=0xd3358d38) at /usr/src/sys/kern/kern_fork.c:818 M> #14 0xc06075fc in fork_trampoline () at M> /usr/src/sys/i386/i386/exception.s:199 M> (kgdb) f 7 M> #7 0xc0464d9a in em_txeof (adapter=0xc20f1000) at M> /usr/src/sys/dev/em/if_em.c:2956 M> 2956 num_avail++; M> (kgdb) info locals M> i = 173 M> num_avail = 231 M> tx_buffer = (struct em_buffer *) 0x568 M> tx_desc = (struct em_tx_desc *) 0xc2152ad0 M> ifp = (struct ifnet *) 0xc2131000 Yeah, looks like calling em_txeof() from watchdog wasn't a perfect idea. Anyway, this code is temporary and isn't merged to RELENG_6 and isn't planned to be merged. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Thu Sep 28 21:08:54 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0E66F16A416 for ; Thu, 28 Sep 2006 21:08:54 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23BD243D49 for ; Thu, 28 Sep 2006 21:08:52 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so865958pye for ; Thu, 28 Sep 2006 14:08:52 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Rux9oZfXqnOVcwLzyyXXqzJJzq9pJg9dPHN94XRDdNaSEkjbMN1RSm1l6YBt4ui25Pw/0zgnMN/Cuh5VKk9NvSL86XvitN1kSVGcDkQQ/6Q1cYVIdFBSqqB89PjAR2fQRvwm5I2TfYthLS85/memYH8HTvtb0kBuNxXVB9B8Wag= Received: by 10.35.93.15 with SMTP id v15mr4521171pyl; Thu, 28 Sep 2006 14:08:52 -0700 (PDT) Received: by 10.35.119.14 with HTTP; Thu, 28 Sep 2006 14:08:52 -0700 (PDT) Message-ID: <2a41acea0609281408k65fc2a3g35bffdb6712bb280@mail.gmail.com> Date: Thu, 28 Sep 2006 14:08:52 -0700 From: "Jack Vogel" To: "Gleb Smirnoff" In-Reply-To: <20060928194831.GF59833@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060928194831.GF59833@FreeBSD.org> Cc: Michiel Boland , freebsd-current@freebsd.org Subject: Re: panic in em_txeof X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Sep 2006 21:08:54 -0000 On 9/28/06, Gleb Smirnoff wrote: > On Thu, Sep 28, 2006 at 01:09:05PM +0200, Michiel Boland wrote: > M> -CURRENT from 25 Sept. (if_em.c has rev 1.147) > M> > M> em, connected to cisco 2950 at 100 Mb full/duplex with TSO disabled. > M> > M> At high load, the card stopped passing network traffic. After I > M> ifconfig-ed the interface down and up again, I got this panic. > M> > M> Obviously neither the network card malfunction or the panic are any good. > M> I hope someone can figure out what's going on. > M> > M> Cheers > M> Michiel > M> > M> Fatal trap 12: page fault while in kernel mode > M> fault virtual address = 0x568 > M> fault code = supervisor read, page not present > M> instruction pointer = 0x20:0xc0464d9a > M> stack pointer = 0x28:0xd3358c50 > M> frame pointer = 0x28:0xd3358c64 > M> code segment = base 0x0, limit 0xfffff, type 0x1b > M> = DPL 0, pres 1, def32 1, gran 1 > M> processor eflags = interrupt enabled, resume, IOPL = 0 > M> current process = 11 (swi4: clock sio) > M> trap number = 12 > M> panic: page fault > M> KDB: stack backtrace: > M> kdb_backtrace(100,c20736c0,28,d3358c10,c,...) at kdb_backtrace+0x29 > M> panic(c063a952,c065b591,0,0,fffff,...) at panic+0xa8 > M> trap_fatal(d3358c10,568,c20736c0,c069d0a0,0,...) at trap_fatal+0x2b6 > M> trap_pfault(d3358c10,0,568) at trap_pfault+0x1cb > M> trap(d3350008,c04f0028,c2150028,568,ad,...) at trap+0x38d > M> calltrap() at calltrap+0x5 > M> --- trap 0xc, eip = 0xc0464d9a, esp = 0xd3358c50, ebp = 0xd3358c64 --- > M> em_txeof(c20f1000) at em_txeof+0x86 > M> em_watchdog(c2131000) at em_watchdog+0xa6 > M> if_slowtimo(0) at if_slowtimo+0x66 > M> softclock(0) at softclock+0x252 > M> ithread_execute_handlers(c2072b04,c2070500) at > M> ithread_execute_handlers+0x125 > M> ithread_loop(c20426c0,d3358d38) at ithread_loop+0x54 > M> fork_exit(c04cea10,c20426c0,d3358d38) at fork_exit+0x7a > M> fork_trampoline() at fork_trampoline+0x8 > M> --- trap 0x1, eip = 0, esp = 0xd3358d6c, ebp = 0 --- > M> Uptime: 2d23h21m50s > M> Physical memory: 505 MB > M> Dumping 117 MB: 102 86 (CTRL-C to abort) 70 54 38 22 (CTRL-C to abort) > M> (CTRL-C to abort) 6 > M> > M> #0 doadump () at pcpu.h:166 > M> 166 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > M> (kgdb) bt > M> #0 doadump () at pcpu.h:166 > M> #1 0xc04e3ca4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > M> #2 0xc04e3f6c in panic (fmt=0xc063a952 "%s") at > M> /usr/src/sys/kern/kern_shutdown.c:565 > M> #3 0xc0616d0a in trap_fatal (frame=0xd3358c10, eva=1384) at > M> /usr/src/sys/i386/i386/trap.c:867 > M> #4 0xc0616a2b in trap_pfault (frame=0xd3358c10, usermode=0, eva=1384) at > M> /usr/src/sys/i386/i386/trap.c:776 > M> #5 0xc0616625 in trap (frame= > M> {tf_fs = -751501304, tf_es = -1068564440, tf_ds = -1038811096, tf_edi > M> = 1384, tf_esi = 173, tf_ebp = -751465372, tf_isp = -751465412, > M> tf_ebx = -1038800176, tf_edx = -1039200256, tf_ecx = -865996036, > M> tf_eax = 2768, tf_trapno = 12, tf_err = 0, tf_eip = -1069134438, > M> tf_cs = 32, tf_eflags = 66054, tf_esp = -1038938112, tf_ss = 231}) at > M> /usr/src/sys/i386/i386/trap.c:461 > M> #6 0xc060759a in calltrap () at /usr/src/sys/i386/i386/exception.s:138 > M> #7 0xc0464d9a in em_txeof (adapter=0xc20f1000) at > M> /usr/src/sys/dev/em/if_em.c:2956 > M> #8 0xc0461ace in em_watchdog (ifp=0xc2131000) at > M> /usr/src/sys/dev/em/if_em.c:963 > M> #9 0xc05576de in if_slowtimo (arg=0x0) at /usr/src/sys/net/if.c:1415 > M> #10 0xc04f1ac2 in softclock (dummy=0x0) at > M> /usr/src/sys/kern/kern_timeout.c:271 > M> #11 0xc04ce955 in ithread_execute_handlers (p=0xc2072b04, ie=0xc2070500) at > M> /usr/src/sys/kern/kern_intr.c:662 > M> #12 0xc04cea64 in ithread_loop (arg=0xc20426c0) at > M> /usr/src/sys/kern/kern_intr.c:745 > M> #13 0xc04cd8b6 in fork_exit (callout=0xc04cea10 , > M> arg=0xc20426c0, frame=0xd3358d38) at /usr/src/sys/kern/kern_fork.c:818 > M> #14 0xc06075fc in fork_trampoline () at > M> /usr/src/sys/i386/i386/exception.s:199 > M> (kgdb) f 7 > M> #7 0xc0464d9a in em_txeof (adapter=0xc20f1000) at > M> /usr/src/sys/dev/em/if_em.c:2956 > M> 2956 num_avail++; > M> (kgdb) info locals > M> i = 173 > M> num_avail = 231 > M> tx_buffer = (struct em_buffer *) 0x568 > M> tx_desc = (struct em_tx_desc *) 0xc2152ad0 > M> ifp = (struct ifnet *) 0xc2131000 > > Yeah, looks like calling em_txeof() from watchdog wasn't a perfect idea. > Anyway, this code is temporary and isn't merged to RELENG_6 and isn't > planned to be merged. Ya, I've been staring at the code trying to understand how that tx_buffer pointer could get that obviously bogus content. So far I'm not sure... I would suggest taking the call to em_txeof() out of the watchdog code and see (I didnt know that got put in until now) if that makes things better. Jack From owner-freebsd-current@FreeBSD.ORG Thu Sep 28 22:10:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FE9216A407 for ; Thu, 28 Sep 2006 22:10:27 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19ECF43D46 for ; Thu, 28 Sep 2006 22:10:25 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 86885 invoked from network); 28 Sep 2006 22:11:47 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 28 Sep 2006 22:11:47 -0000 Message-ID: <451C4850.5030302@freebsd.org> Date: Fri, 29 Sep 2006 00:10:24 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, gallatin@cs.duke.edu Subject: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Sep 2006 22:10:27 -0000 The recent addition of TSO (TCP Segmentation Offload) has highlighted some shortcommings in our sosend_*() kernel implementation. The current code uses a sosend_copyin() function that loops over the supplied struct uio and does interleaved mbuf allocations and uiomove() calls. I have rewritten m_getm() to be simpler and to allocate PAGE_SIZE sized jumbo mbuf clusters (4k on most architectures) as well as m_uiotombuf() to use the new m_getm() to obtain all mbuf space in one go. It then loops over it an copies the data into the mbufs by using uiomove(). sosend_dgram() and sosend_generic() are change to use m_uiotombuf() instead of sosend_copyin(). Looking at the benchmarks we see some very nice improvements (95% confidence): 66% less cpu (or 2.9 times better) with new sosend vs. old sosend (non-TSO) 65% less cpu (or 2.8 times better) with new sosend vs. old sosend (TSO) The sender is an AMD Opteron 852 (2.6GHz) with em(4) PCI-X-133 interface and the receiver is a DELL Poweredge SC1425 P-IV Xeon 3.2GHz with em(4) LOM connected back to back at 1000Base-TX full duplex. The patch is available here: http://people.freebsd.org/~andre/sosend+m_uiotombuf-20060928.diff Any testing and heavy (code) beating and reviews welcome. -- Andre Here are the raw numbers (netperf at 95% confidence, +-2.5% error margin, the cpu load reported by netperf is different from the one reported by time(1), all performance references are made based on time(1) output, netperf 2.4.2 used): a) is old sosend kernel implementation b) is new sosend kernel implementation 1) time ./netperf -H192.168.2.2,4 -tTCP_STREAM -C -c -F 6.2-BETA1-i386-disc1.iso -- -s32K -S32K [non-TSO] 2) time ./netperf -H192.168.2.2,4 -tTCP_STREAM -C -c -F 6.2-BETA1-i386-disc1.iso -- -s32K -S32K [TSO] 3) time ./netperf -H192.168.2.2,4 -tTCP_STREAM -C -c -F 6.2-BETA1-i386-disc1.iso -- -s64K -S64K [non-TSO] 4) time ./netperf -H192.168.2.2,4 -tTCP_STREAM -C -c -F 6.2-BETA1-i386-disc1.iso -- -s64K -S64K [TSO] 5) time ./netperf -H192.168.2.2,4 -tTCP_STREAM -C -c -F 6.2-BETA1-i386-disc1.iso -- -s128K -S128K [non-TSO] 6) time ./netperf -H192.168.2.2,4 -tTCP_STREAM -C -c -F 6.2-BETA1-i386-disc1.iso -- -s128K -S128K [TSO] Recv Send Send Utilization Service Demand Socket Socket Message Elapsed Send Recv Send Recv Size Size Size Time Throughput local remote local remote bytes bytes bytes secs. 10^6bits/s % C % C us/KB us/KB 1a) 32768 32768 32768 10.00 921.28 28.42 32.48 2.527 2.888 0.007u 1.747s 0:10.00 17.4% 99+5252k 0+0io 0pf+0w 1b) 32768 32768 32768 10.00 921.39 24.51 31.50 2.179 2.801 0.028u 0.768s 0:10.00 7.8% 78+4210k 0+0io 0pf+0w 2a) 32768 32768 32768 10.00 897.63 24.29 37.74 2.216 3.445 0.000u 1.359s 0:10.02 13.4% 96+5152k 5+0io 3pf+0w 2b) 32768 32768 32768 10.00 919.71 15.64 33.01 1.393 2.940 0.008u 0.528s 0:10.00 5.2% 90+4830k 0+0io 0pf+0w 3a) 65536 65536 65536 10.00 941.60 30.90 32.01 2.689 2.785 0.000u 1.827s 0:10.00 18.2% 96+5180k 0+0io 0pf+0w 3b) 65536 65536 65536 10.00 941.59 26.39 32.03 2.296 2.787 0.014u 0.617s 0:10.00 6.2% 101+5362k 0+0io 0pf+0w 4a) 65536 65536 65536 10.00 921.98 26.09 39.47 2.318 3.507 0.000u 1.467s 0:10.02 14.5% 93+5028k 3+0io 0pf+0w 4b) 65536 65536 65536 10.00 938.44 16.24 34.29 1.418 2.993 0.000u 0.511s 0:10.00 5.1% 91+4851k 0+0io 0pf+0w 5a) 131072 131072 131072 10.00 941.62 33.81 33.68 2.941 2.930 0.000u 2.158s 0:10.00 21.5% 97+5247k 0+0io 0pf+0w 5b) 131072 131072 131072 10.00 941.60 28.55 31.65 2.484 2.754 0.000u 0.676s 0:10.00 6.7% 95+5132k 0+0io 0pf+0w 6a) 131072 131072 131072 10.00 922.92 28.72 40.80 2.549 3.621 0.000u 1.713s 0:10.00 17.1% 93+5016k 1+0io 0pf+0w 6b) 131072 131072 131072 10.00 939.14 18.20 34.44 1.587 3.004 0.000u 0.587s 0:10.00 5.8% 78+4197k 1+0io 0pf+0w From owner-freebsd-current@FreeBSD.ORG Thu Sep 28 22:42:03 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 081D216A407; Thu, 28 Sep 2006 22:42:03 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA57643D68; Thu, 28 Sep 2006 22:41:50 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.6/8.13.6) with ESMTP id k8SMflrN008859 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 28 Sep 2006 18:41:47 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k8SMff0N060572; Thu, 28 Sep 2006 18:41:41 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17692.20389.476272.588061@grasshopper.cs.duke.edu> Date: Thu, 28 Sep 2006 18:41:41 -0400 (EDT) To: Andre Oppermann In-Reply-To: <451C4850.5030302@freebsd.org> References: <451C4850.5030302@freebsd.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Sep 2006 22:42:03 -0000 Andre Oppermann writes: > I have rewritten m_getm() to be simpler and to allocate PAGE_SIZE sized > jumbo mbuf clusters (4k on most architectures) as well as m_uiotombuf() > to use the new m_getm() to obtain all mbuf space in one go. It then loops > over it an copies the data into the mbufs by using uiomove(). sosend_dgram() > and sosend_generic() are change to use m_uiotombuf() instead of sosend_copyin(). Hurray! Thank you for doing this. I'll try to check it out with mxge soon, but it might be until next week. Drew From owner-freebsd-current@FreeBSD.ORG Thu Sep 28 23:18:17 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C482116A518 for ; Thu, 28 Sep 2006 23:18:17 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 34E4B43D45 for ; Thu, 28 Sep 2006 23:18:17 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (3ipzfut4qge43fe6@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k8SNIGcQ000945 for ; Thu, 28 Sep 2006 16:18:16 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k8SNIGcO000944 for freebsd-current@FreeBSD.org; Thu, 28 Sep 2006 16:18:16 -0700 (PDT) (envelope-from jmg) Date: Thu, 28 Sep 2006 16:18:16 -0700 From: John-Mark Gurney To: freebsd-current@FreeBSD.org Message-ID: <20060928231816.GI80527@funkthat.com> Mail-Followup-To: freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: Subject: better way to build libraries.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2006 23:18:17 -0000 With the recent libcrypto upgrade, I found out that we can't build libraries (that have special headers) w/o doing a buildworld... This isn't very good as the latest SA requires people to do a buildworld to get the new library.. With a bit of advice from Kris Kennaway, I came up w/ the following patch: Index: Makefile =================================================================== RCS file: /home/ncvs/src/secure/lib/libcrypto/Makefile,v retrieving revision 1.69.2.2 diff -u -r1.69.2.2 Makefile --- Makefile 1 Mar 2005 16:47:38 -0000 1.69.2.2 +++ Makefile 28 Sep 2006 23:09:55 -0000 @@ -4,7 +4,9 @@ SHLIBDIR?= /lib SHLIB_MAJOR= 3 -NOLINT= +NO_LINT= + +CFLAGS+= -I${.OBJDIR}/usr/include .if exists(Makefile.man) .include "Makefile.man" @@ -396,3 +398,7 @@ ${LCRYPTO_SRC}/crypto/x509v3 \ ${LCRYPTO_SRC} \ ${.CURDIR}/man + +buildincs: + mkdir -p ${.OBJDIR}/${INCSDIR} + make includes DESTDIR=${.OBJDIR} INSTALL="sh ${.CURDIR}/../../../tools/install.sh" This builds includes in the OBJDIR so that it can be properly referenced w/o lots of extra work... It'd be good to make this more generic so that it could be integrated into bsd.lib.mk... This obviously won't solve the problem of upgrading two differnet libraries at the same time, but it does make it easier to upgrade your system, and brings the lib's more in line w/ utilities like pciconf that do -I../../sys so that they get the correct ioctl defines outside of a buildworld... The biggest issue I see is finding where tools/install.sh is as it is necessary to skip the owner parts so normal users can make use of it.. Comments? Improvements? /me is glad he didn't have to buidlworld to get the new libcrypto on his 5.4-R system. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Thu Sep 28 23:29:55 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C52116A40F for ; Thu, 28 Sep 2006 23:29:55 +0000 (UTC) (envelope-from silby@silby.com) Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by mx1.FreeBSD.org (Postfix) with SMTP id 2DA7543D70 for ; Thu, 28 Sep 2006 23:29:54 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 55573 invoked by uid 3193); 28 Sep 2006 23:29:53 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 28 Sep 2006 23:29:53 -0000 Date: Thu, 28 Sep 2006 19:29:52 -0400 (EDT) From: Mike Silbersack X-X-Sender: silby@niwun.pair.com To: Andre Oppermann In-Reply-To: <451C4850.5030302@freebsd.org> Message-ID: References: <451C4850.5030302@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 28 Sep 2006 23:29:55 -0000 On Fri, 29 Sep 2006, Andre Oppermann wrote: > over it an copies the data into the mbufs by using uiomove(). sosend_dgram() > and sosend_generic() are change to use m_uiotombuf() instead of sosend_copyin(). Can you do some UDP testing with 512b, 1K, 2K, 4K, 8K, and 16K packets to see if performance changes there as well? How about local sockets? Impressive improvements for TCP, in any case! Mike "Silby" Silbersack From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 00:06:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6F7D116A40F for ; Fri, 29 Sep 2006 00:06:34 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id C88A643D45 for ; Fri, 29 Sep 2006 00:06:33 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so921631pye for ; Thu, 28 Sep 2006 17:06:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=XqbVpR9A01oj9KQMosnHCjm7nWk4WggP+4OKYbVD62ho/9nRULbG8bx1MITlbrOh2W/xyJZ2vvcWOsQS4i8l/mindiV2kf+qYbRJZB5e6srlCy78z/+dHGpbZxIouKuiooxBR0C3jyWXA/pZu5Rv1kuZ/yOPr1q4WP2+wYjQQdg= Received: by 10.35.102.18 with SMTP id e18mr1307226pym; Thu, 28 Sep 2006 17:06:33 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 34sm2673714nza.2006.09.28.17.06.31; Thu, 28 Sep 2006 17:06:32 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k8T07IAa027962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Sep 2006 09:07:18 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k8T07Gg2027961; Fri, 29 Sep 2006 09:07:16 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Fri, 29 Sep 2006 09:07:16 +0900 From: Pyun YongHyeon To: Michiel Boland Message-ID: <20060929000716.GA27684@cdnetworks.co.kr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: panic in em_txeof X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2006 00:06:34 -0000 On Thu, Sep 28, 2006 at 01:09:05PM +0200, Michiel Boland wrote: > -CURRENT from 25 Sept. (if_em.c has rev 1.147) > > em, connected to cisco 2950 at 100 Mb full/duplex with TSO disabled. > > At high load, the card stopped passing network traffic. After I > ifconfig-ed the interface down and up again, I got this panic. > > Obviously neither the network card malfunction or the panic are any good. > I hope someone can figure out what's going on. > > Cheers > Michiel > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x568 > fault code = supervisor read, page not present > instruction pointer = 0x20:0xc0464d9a > stack pointer = 0x28:0xd3358c50 > frame pointer = 0x28:0xd3358c64 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 11 (swi4: clock sio) > trap number = 12 > panic: page fault > KDB: stack backtrace: > kdb_backtrace(100,c20736c0,28,d3358c10,c,...) at kdb_backtrace+0x29 > panic(c063a952,c065b591,0,0,fffff,...) at panic+0xa8 > trap_fatal(d3358c10,568,c20736c0,c069d0a0,0,...) at trap_fatal+0x2b6 > trap_pfault(d3358c10,0,568) at trap_pfault+0x1cb > trap(d3350008,c04f0028,c2150028,568,ad,...) at trap+0x38d > calltrap() at calltrap+0x5 > --- trap 0xc, eip = 0xc0464d9a, esp = 0xd3358c50, ebp = 0xd3358c64 --- > em_txeof(c20f1000) at em_txeof+0x86 > em_watchdog(c2131000) at em_watchdog+0xa6 > if_slowtimo(0) at if_slowtimo+0x66 > softclock(0) at softclock+0x252 > ithread_execute_handlers(c2072b04,c2070500) at > ithread_execute_handlers+0x125 > ithread_loop(c20426c0,d3358d38) at ithread_loop+0x54 > fork_exit(c04cea10,c20426c0,d3358d38) at fork_exit+0x7a > fork_trampoline() at fork_trampoline+0x8 > --- trap 0x1, eip = 0, esp = 0xd3358d6c, ebp = 0 --- > Uptime: 2d23h21m50s > Physical memory: 505 MB > Dumping 117 MB: 102 86 (CTRL-C to abort) 70 54 38 22 (CTRL-C to abort) > (CTRL-C to abort) 6 > > #0 doadump () at pcpu.h:166 > 166 __asm __volatile("movl %%fs:0,%0" : "=r" (td)); > (kgdb) bt > #0 doadump () at pcpu.h:166 > #1 0xc04e3ca4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 > #2 0xc04e3f6c in panic (fmt=0xc063a952 "%s") at > /usr/src/sys/kern/kern_shutdown.c:565 > #3 0xc0616d0a in trap_fatal (frame=0xd3358c10, eva=1384) at > /usr/src/sys/i386/i386/trap.c:867 > #4 0xc0616a2b in trap_pfault (frame=0xd3358c10, usermode=0, eva=1384) at > /usr/src/sys/i386/i386/trap.c:776 > #5 0xc0616625 in trap (frame= > {tf_fs = -751501304, tf_es = -1068564440, tf_ds = -1038811096, tf_edi > = 1384, tf_esi = 173, tf_ebp = -751465372, tf_isp = -751465412, > tf_ebx = -1038800176, tf_edx = -1039200256, tf_ecx = -865996036, > tf_eax = 2768, tf_trapno = 12, tf_err = 0, tf_eip = -1069134438, > tf_cs = 32, tf_eflags = 66054, tf_esp = -1038938112, tf_ss = 231}) at > /usr/src/sys/i386/i386/trap.c:461 > #6 0xc060759a in calltrap () at /usr/src/sys/i386/i386/exception.s:138 > #7 0xc0464d9a in em_txeof (adapter=0xc20f1000) at > /usr/src/sys/dev/em/if_em.c:2956 > #8 0xc0461ace in em_watchdog (ifp=0xc2131000) at > /usr/src/sys/dev/em/if_em.c:963 > #9 0xc05576de in if_slowtimo (arg=0x0) at /usr/src/sys/net/if.c:1415 > #10 0xc04f1ac2 in softclock (dummy=0x0) at > /usr/src/sys/kern/kern_timeout.c:271 > #11 0xc04ce955 in ithread_execute_handlers (p=0xc2072b04, ie=0xc2070500) at > /usr/src/sys/kern/kern_intr.c:662 > #12 0xc04cea64 in ithread_loop (arg=0xc20426c0) at > /usr/src/sys/kern/kern_intr.c:745 > #13 0xc04cd8b6 in fork_exit (callout=0xc04cea10 , > arg=0xc20426c0, frame=0xd3358d38) at /usr/src/sys/kern/kern_fork.c:818 > #14 0xc06075fc in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:199 > (kgdb) f 7 > #7 0xc0464d9a in em_txeof (adapter=0xc20f1000) at > /usr/src/sys/dev/em/if_em.c:2956 > 2956 num_avail++; > (kgdb) info locals > i = 173 > num_avail = 231 > tx_buffer = (struct em_buffer *) 0x568 > tx_desc = (struct em_tx_desc *) 0xc2152ad0 > ifp = (struct ifnet *) 0xc2131000 As Jack said I can't sure how tx_buffer can have bogus value. Since switching to adaptive polling on em(4) em_rxeof() runs without locks held. But if you force interface down while em_rxeof() is in prgoress it would corrupt softc/hardware. It's just vague guess since no other users reported this kind of issues. Removing em_txeof() in em_watchdog() may help for your case(eventually, em_watchdog() will reset hardware) but I don't think it's correct fix for root cause. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 03:07:53 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D0DF16A5C4; Fri, 29 Sep 2006 03:07:48 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [64.129.166.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4DEB43D45; Fri, 29 Sep 2006 03:07:47 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.23] (andersonbox3.centtech.com [192.168.42.23]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id k8T37kaW083479; Thu, 28 Sep 2006 22:07:46 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <451C8E00.500@centtech.com> Date: Thu, 28 Sep 2006 22:07:44 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.7 (X11/20060923) MIME-Version: 1.0 To: Alexander Leidinger References: <451ADC21.50206@centtech.com> <451AE27F.3010506@samsco.org> <200609271727.29775.jhb@freebsd.org> <20060928082651.b6xp2ayu9wg40wok@webmail.leidinger.net> In-Reply-To: <20060928082651.b6xp2ayu9wg40wok@webmail.leidinger.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1950/Thu Sep 28 09:11:54 2006 on mh2.centtech.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org Subject: Re: isofs/cd9660 -> relocate to fs/isofs/cd9660? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 03:07:53 -0000 On 09/28/06 01:26, Alexander Leidinger wrote: > Quoting John Baldwin (from Wed, 27 Sep 2006 17:27:29 -0400): > >> We've actually moved most of the filesystems into sys/fs in the past. Only >> cd9660, nfs, and ufs are in the top-level. I'd still say leave nfs and ufs >> alone, but sys/isofs/cd9660 -> sys/fs/cd9660 (I wouldn't keep the extra isofs >> directory) probably wouldn't be but so painful at this point. > > I expect a lot of moves when we switch to a VCS where moves are > cheap... but on the other hand, maybe this is another bikeshed. > > Bye, > Alexander. > When is that supposed to happen? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 04:51:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4F6C16A580; Fri, 29 Sep 2006 04:51:34 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4276043D49; Fri, 29 Sep 2006 04:51:33 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k8T4pQod028266; Thu, 28 Sep 2006 22:51:32 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <451CA64D.3050703@samsco.org> Date: Thu, 28 Sep 2006 22:51:25 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alexander Leidinger References: <451ADC21.50206@centtech.com> <451AE27F.3010506@samsco.org> <200609271727.29775.jhb@freebsd.org> <20060928082651.b6xp2ayu9wg40wok@webmail.leidinger.net> In-Reply-To: <20060928082651.b6xp2ayu9wg40wok@webmail.leidinger.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: isofs/cd9660 -> relocate to fs/isofs/cd9660? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 04:51:34 -0000 Alexander Leidinger wrote: > Quoting John Baldwin (from Wed, 27 Sep 2006 17:27:29 > -0400): > >> We've actually moved most of the filesystems into sys/fs in the past. >> Only >> cd9660, nfs, and ufs are in the top-level. I'd still say leave nfs >> and ufs >> alone, but sys/isofs/cd9660 -> sys/fs/cd9660 (I wouldn't keep the >> extra isofs >> directory) probably wouldn't be but so painful at this point. > > > I expect a lot of moves when we switch to a VCS where moves are > cheap... but on the other hand, maybe this is another bikeshed. > > Bye, > Alexander. > Moves in CVS are relatively easy too, it's just that they can only be performed by a special group of people, and that special group rarely responds to requests. So, it's a policy problem, not a technology problem. I would imagine than any new VCS that the project adopts would have similar policies in place, and moves will still be impossible. Scott From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 08:10:01 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0D4616A49E for ; Fri, 29 Sep 2006 08:10:01 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5375D43D46 for ; Fri, 29 Sep 2006 08:10:01 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 70A2260D4; Fri, 29 Sep 2006 12:10:00 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 4E64A609E; Fri, 29 Sep 2006 12:10:00 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k8T8A1qK086680; Fri, 29 Sep 2006 12:10:01 +0400 (MSD) (envelope-from ru) Date: Fri, 29 Sep 2006 12:10:00 +0400 From: Ruslan Ermilov To: Scott Long Message-ID: <20060929081000.GB86237@rambler-co.ru> References: <451ADC21.50206@centtech.com> <451AE27F.3010506@samsco.org> <200609271727.29775.jhb@freebsd.org> <20060928082651.b6xp2ayu9wg40wok@webmail.leidinger.net> <451CA64D.3050703@samsco.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H+4ONPRPur6+Ovig" Content-Disposition: inline In-Reply-To: <451CA64D.3050703@samsco.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: Alexander Leidinger , freebsd-current@FreeBSD.org Subject: Re: isofs/cd9660 -> relocate to fs/isofs/cd9660? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 08:10:02 -0000 --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Sep 28, 2006 at 10:51:25PM -0600, Scott Long wrote: [...] > Moves in CVS are relatively easy too, it's just that they can only > be performed by a special group of people, and that special group > rarely responds to requests. So, it's a policy problem, not a > technology problem. I would imagine than any new VCS that the project > adopts would have similar policies in place, and moves will still be > impossible. >=20 Why? For example with P4, branching saves all of the history, so everyone can do a move without loosing the history (the reason why we have invented the repocopy procedure for CVS). I cannot speak for other VCS'es. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --H+4ONPRPur6+Ovig Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFHNTYqRfpzJluFF4RAubIAJ9+zKe8hH5c7kO4XySzAFo6vUKoegCdHsdF JMBGbIx8LAkdDwAWD44kRyY= =qByC -----END PGP SIGNATURE----- --H+4ONPRPur6+Ovig-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 08:27:16 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5017316A416 for ; Fri, 29 Sep 2006 08:27:16 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id F155843D53 for ; Fri, 29 Sep 2006 08:27:13 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id C5C295D84 for ; Fri, 29 Sep 2006 12:27:12 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id A5F1D5D07 for ; Fri, 29 Sep 2006 12:27:12 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k8T8RDhF086902 for freebsd-current@FreeBSD.org; Fri, 29 Sep 2006 12:27:13 +0400 (MSD) (envelope-from ru) Date: Fri, 29 Sep 2006 12:27:13 +0400 From: Ruslan Ermilov To: freebsd-current@FreeBSD.org Message-ID: <20060929082713.GD86237@rambler-co.ru> References: <20060928231816.GI80527@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eheScQNz3K90DVRs" Content-Disposition: inline In-Reply-To: <20060928231816.GI80527@funkthat.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: Subject: Re: better way to build libraries.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 08:27:16 -0000 --eheScQNz3K90DVRs Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Thu, Sep 28, 2006 at 04:18:16PM -0700, John-Mark Gurney wrote: > With the recent libcrypto upgrade, I found out that we can't build > libraries (that have special headers) w/o doing a buildworld... This > isn't very good as the latest SA requires people to do a buildworld > to get the new library.. With a bit of advice from Kris Kennaway, > I came up w/ the following patch: >=20 Don't ever think about committing this! ;-) Try this instead (with unpatched sources): cd /usr/src/secure/lib/libcrypto make obj make includes make depend make all make install Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --eheScQNz3K90DVRs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFHNjhqRfpzJluFF4RAv9ZAJ9dEuxW/R6W00KCaJYA0UpraTRAEACcDCvP ltMbQ18LYUxEx0VvS4g8xOc= =cZF0 -----END PGP SIGNATURE----- --eheScQNz3K90DVRs-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 08:34:13 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AA4E16A407; Fri, 29 Sep 2006 08:34:13 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B92743D70; Fri, 29 Sep 2006 08:34:12 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5CDE3.dip.t-dialin.net [84.165.205.227]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k8T88vp9084898; Fri, 29 Sep 2006 10:08:57 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (webmail.Leidinger.net [192.168.1.102]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k8T8Y4K3009521; Fri, 29 Sep 2006 10:34:04 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from psbru.cec.eu.int (psbru.cec.eu.int [158.169.131.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Fri, 29 Sep 2006 10:33:33 +0200 Message-ID: <20060929103333.d4ydu2bb3swoks4g@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 29 Sep 2006 10:33:33 +0200 From: Alexander Leidinger To: Eric Anderson References: <451ADC21.50206@centtech.com> <451AE27F.3010506@samsco.org> <200609271727.29775.jhb@freebsd.org> <20060928082651.b6xp2ayu9wg40wok@webmail.leidinger.net> <451C8E00.500@centtech.com> In-Reply-To: <451C8E00.500@centtech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-Virus-Scanned: by amavisd-new Cc: freebsd-current@freebsd.org Subject: Re: isofs/cd9660 -> relocate to fs/isofs/cd9660? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 08:34:13 -0000 Quoting Eric Anderson (from Thu, 28 Sep 2006 =20 22:07:44 -0500): > On 09/28/06 01:26, Alexander Leidinger wrote: >> Quoting John Baldwin (from Wed, 27 Sep 2006 =20 >> 17:27:29 -0400): >> >>> We've actually moved most of the filesystems into sys/fs in the past. O= nly >>> cd9660, nfs, and ufs are in the top-level. I'd still say leave nfs and = ufs >>> alone, but sys/isofs/cd9660 -> sys/fs/cd9660 (I wouldn't keep the =20 >>> extra isofs >>> directory) probably wouldn't be but so painful at this point. >> >> I expect a lot of moves when we switch to a VCS where moves are =20 >> cheap... but on the other hand, maybe this is another bikeshed. When we have found a VCS which suits our needs... :-) Have a look at wiki.freebsd.org (may be incomplete ATM, we are not at =20 a position where we can make a judgement yet, we still add a lot of =20 stuff there) about our needs and which VCS we evaluate if they meet =20 the needs. It may be the case that currently no VCS fits our needs and =20 we decide to wait half a year and reevaluate then. Bye, Alexander. --=20 And I alone am returned to wag the tail. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 08:35:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 52CE216A403; Fri, 29 Sep 2006 08:35:32 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5419643D77; Fri, 29 Sep 2006 08:35:31 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id C4BBC46B04; Fri, 29 Sep 2006 04:35:25 -0400 (EDT) Date: Fri, 29 Sep 2006 09:35:25 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andre Oppermann In-Reply-To: <451C4850.5030302@freebsd.org> Message-ID: <20060929092813.U73166@fledge.watson.org> References: <451C4850.5030302@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 08:35:32 -0000 On Fri, 29 Sep 2006, Andre Oppermann wrote: > The patch is available here: > http://people.freebsd.org/~andre/sosend+m_uiotombuf-20060928.diff I like the concept of these changes in principle -- this is the reason I broke out sosend_copyin(), so that we could start plugging bits of the send routines more easily for optimization. However, I think we need to review this really carefully. A casual glance brought up one question, and I hope to get a chance to review this in detail in the next few days. The question is with regard to the 'space' variable. When breaking out sosend_copyin(), I originally simply passed space in as an argument, which is what you do currently. However, I found I had to change it to pass in the variable by reference so that it could be updated, as later portions of sosend() depend on it being updated in order to figure out what flags to pass to pru_send() with respect to PRUS_MORETOCOME, as well as for the (resid && space > 0) condition for the main loop. In your revised version, 'space' isn't updated in sosend() after calling m_uiotombuf(), which on a casual read, suggests that PRUS_MORETOCOME will no longer get set on the last pass into pru_send(), and that the loop may go an extra time and pass more data into TCP than there is room in the socket send buffer. I may be reading wrong, I've not had time to look in any detail, but that was my experience, so you may find you need to pass send by reference, as I do in sosend_copyin(), for the same reason. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 08:39:06 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1259416A407; Fri, 29 Sep 2006 08:39:06 +0000 (UTC) (envelope-from Alexander@Leidinger.net) Received: from www.ebusiness-leidinger.de (jojo.ms-net.de [84.16.236.246]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EB9D43D46; Fri, 29 Sep 2006 08:39:05 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from Andro-Beta.Leidinger.net (p54A5CDE3.dip.t-dialin.net [84.165.205.227]) (authenticated bits=0) by www.ebusiness-leidinger.de (8.13.6/8.13.6) with ESMTP id k8T8Dpkx084922; Fri, 29 Sep 2006 10:13:52 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from localhost (webmail.Leidinger.net [192.168.1.102]) by Andro-Beta.Leidinger.net (8.13.4/8.13.3) with ESMTP id k8T8cxIm010227; Fri, 29 Sep 2006 10:38:59 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from psbru.cec.eu.int (psbru.cec.eu.int [158.169.131.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Fri, 29 Sep 2006 10:38:27 +0200 Message-ID: <20060929103827.wpuy6ai3484o8kko@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Fri, 29 Sep 2006 10:38:27 +0200 From: Alexander Leidinger To: Scott Long References: <451ADC21.50206@centtech.com> <451AE27F.3010506@samsco.org> <200609271727.29775.jhb@freebsd.org> <20060928082651.b6xp2ayu9wg40wok@webmail.leidinger.net> <451CA64D.3050703@samsco.org> In-Reply-To: <451CA64D.3050703@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-Virus-Scanned: by amavisd-new Cc: freebsd-current@freebsd.org Subject: Re: isofs/cd9660 -> relocate to fs/isofs/cd9660? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 08:39:06 -0000 Quoting Scott Long (from Thu, 28 Sep 2006 22:51:25 -0600= ): > Moves in CVS are relatively easy too, it's just that they can only > be performed by a special group of people, and that special group > rarely responds to requests. So, it's a policy problem, not a > technology problem. I would imagine than any new VCS that the project > adopts would have similar policies in place, and moves will still be > impossible. ATM we get the repo copy when we request one. There's no approval =20 process I'm aware of. So I expect a lot of bikeshed discussions about =20 the right layout if someone moves parts of the tree. But the problem =20 you mentioned above is not a policy problem, it's a technical problem: =20 CVS has no official way to move while keeping the history. Because of =20 this we have to cheat. Cheating can harm the repo, so we only allow a =20 subset of the people to cheat. The policy we have ATM is the result of =20 a technical limitation, not a political decission in the first place. Bye, Alexander. --=20 Don't expect people to keep in step-- it's hard enough just staying in line. http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 09:49:38 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94D0F16A403 for ; Fri, 29 Sep 2006 09:49:38 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E1DC43D46 for ; Fri, 29 Sep 2006 09:49:37 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id BF8CE5EBB; Fri, 29 Sep 2006 13:49:35 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 9D5075D9E; Fri, 29 Sep 2006 13:49:35 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k8T9naQB003526; Fri, 29 Sep 2006 13:49:36 +0400 (MSD) (envelope-from ru) Date: Fri, 29 Sep 2006 13:49:36 +0400 From: Ruslan Ermilov To: John-Mark Gurney Message-ID: <20060929094936.GH86237@rambler-co.ru> References: <20060928231816.GI80527@funkthat.com> <20060929082713.GD86237@rambler-co.ru> <20060929083959.GG86237@rambler-co.ru> <20060929092233.GO80527@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TKYYegg/GYAC5JIZ" Content-Disposition: inline In-Reply-To: <20060929092233.GO80527@funkthat.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: current@FreeBSD.org Subject: Re: better way to build libraries.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 09:49:38 -0000 --TKYYegg/GYAC5JIZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 29, 2006 at 02:22:33AM -0700, John-Mark Gurney wrote: > So as I had a big argument w/ Kris about this, are you saying that > we should go ahead and remove all the -I../../sys in places like > pciconf because building standalone isn't supported? >=20 Yes, we've been doing this (removing them) for years now. pciconf is special -- it needs this because we don't install sys/dev/pci/pcireg.h into /usr/include. > My point is > that either we continue to attempt to support building things stand > alone, or we don't even pretend we attempt to... >=20 Removing -I's doesn't generally affect standalone building, but it does affect stanalone upgrading. That's the difference. If your sources match your installed bits, you can still chdir into a directory and type "make", and it will generally be built. Yes, we should stop pretending we support standalone upgrades -- because in this case you need to handle it properly: track dependencies, build and install dependencies (other headers and libraries, this library's headers if this is a library) in the correct order, etc. Some of them depend on the src.conf (or make.conf) options, there's a lot to track. > Everyone points that oh, buildworld does that prefectly fine, but no > one wants to expand support of being able to build FreeBSD piecemeal > on a system.... >=20 I think you misunderstand the difference between upgrades and standalone builds. > Take my 5.4-R box... I was unable to build libcrypto due to not > having done a make includes... I could do a make includes, but then > if either a) I forget to make and install the library, or b) the > library fails to build, I now have a broken install... It is > much better to do a build the library, then install both the new > library and includes... >=20 This approach is doomed. You were lucky (or not, haven't actually checked) that this particular upgrade didn't update .h files. Because if it did, you'd still be forced to rebuild other bits that use an updated header -- other crypto libraries, other stuff that uses crypto, statically linked programs if there are any. Well, if you absolutely want to, you could installed the headers into a temporary location using DESTDIR, make includes DESTDIR=3D/foo then rebuilt the library with DEBUG_FLAGS=3D-I/foo. In any case, even this broken approach doesn't require modifications to makefiles. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --TKYYegg/GYAC5JIZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFHOwwqRfpzJluFF4RAsWBAJ9CaLOqQr1nlDsDL/5l5xE/WBp1yACfXo+l jms8raZKih37DnfNOhuawfo= =96Sw -----END PGP SIGNATURE----- --TKYYegg/GYAC5JIZ-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 10:12:47 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 589A116A407; Fri, 29 Sep 2006 10:12:47 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id D91A643D45; Fri, 29 Sep 2006 10:12:46 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (21l598hkozkzki8u@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k8TACkI6014751; Fri, 29 Sep 2006 03:12:46 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k8TACkT9014750; Fri, 29 Sep 2006 03:12:46 -0700 (PDT) (envelope-from jmg) Date: Fri, 29 Sep 2006 03:12:46 -0700 From: John-Mark Gurney To: Ruslan Ermilov Message-ID: <20060929101245.GP80527@funkthat.com> Mail-Followup-To: Ruslan Ermilov , current@FreeBSD.org References: <20060928231816.GI80527@funkthat.com> <20060929082713.GD86237@rambler-co.ru> <20060929083959.GG86237@rambler-co.ru> <20060929092233.GO80527@funkthat.com> <20060929094936.GH86237@rambler-co.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060929094936.GH86237@rambler-co.ru> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: current@FreeBSD.org Subject: Re: better way to build libraries.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2006 10:12:47 -0000 Ruslan Ermilov wrote this message on Fri, Sep 29, 2006 at 13:49 +0400: > On Fri, Sep 29, 2006 at 02:22:33AM -0700, John-Mark Gurney wrote: > > are you saying that > > we should go ahead and remove all the -I../../sys in places like > > pciconf because building standalone isn't supported? > > > Yes, we've been doing this (removing them) for years now. > pciconf is special -- it needs this because we don't install > sys/dev/pci/pcireg.h into /usr/include. Interesting, other people seem to think that they are suppose to stay around... I'll remeber to remove them when I see them from now on... > > My point is > > that either we continue to attempt to support building things stand > > alone, or we don't even pretend we attempt to... > > > Removing -I's doesn't generally affect standalone building, but > it does affect stanalone upgrading. That's the difference. If > your sources match your installed bits, you can still chdir into If my sources matched my installed bits, why'd I be building/upgrading in the first place? :) > a directory and type "make", and it will generally be built. > Yes, we should stop pretending we support standalone upgrades -- > because in this case you need to handle it properly: track > dependencies, build and install dependencies (other headers and > libraries, this library's headers if this is a library) in the > correct order, etc. Some of them depend on the src.conf (or > make.conf) options, there's a lot to track. not if you know only that one library changed... and for most security upgrades, it should be one or two components that are affected, and so is simple enough to manage the dependencies... > > Everyone points that oh, buildworld does that prefectly fine, but no > > one wants to expand support of being able to build FreeBSD piecemeal > > on a system.... > > > I think you misunderstand the difference between upgrades and > standalone builds. I understand the difference, I just think that standalone means not requiring /usr/include to be populated w/ files from the component you are building... I wonder how many people's build and commit errors would have been fixed by using a method like this... It built for me./Darn, I forgot to make includes so I wasn't building w/ the proper headers. Though I agree buildworld is good for testing, people don't have infinately fast disks and cpu's, and buildworld takes time. I would be very surprised if even 50% of commits are done w/ a proper buildworld let alone a universe before committing... It should work exactly how you build OpenSSL and other libraries that aren't part of FreeBSD... you build them and they automagicly use the includes that come w/ the package, and you install them all at once... Yes, they usually depend upon other headers that are part of the system, but as you said, dependencies are hard... If you're doing it by hand, you can track the dependencies by hand.. > > Take my 5.4-R box... I was unable to build libcrypto due to not > > having done a make includes... I could do a make includes, but then > > if either a) I forget to make and install the library, or b) the > > library fails to build, I now have a broken install... It is > > much better to do a build the library, then install both the new > > library and includes... > > > This approach is doomed. You were lucky (or not, haven't actually > checked) that this particular upgrade didn't update .h files. not.. it modified a few of the .h files... I wouldn't have known of this issue if it had left the .h files alone.. > Because if it did, you'd still be forced to rebuild other bits that > use an updated header -- other crypto libraries, other stuff > that uses crypto, statically linked programs if there are any. If we did update the .h file, and it did break the API, doesn't that mean we need to have bumped the major number?? > Well, if you absolutely want to, you could installed the headers > into a temporary location using DESTDIR, > > make includes DESTDIR=/foo > > then rebuilt the library with DEBUG_FLAGS=-I/foo. In any case, > even this broken approach doesn't require modifications to > makefiles. Which is exactly what my patch did... though your method requires root, which it shouldn't... (IMO this way is not broken, the the proper way to build a library)... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 10:19:04 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 832B516A403; Fri, 29 Sep 2006 10:19:04 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F55E43D4C; Fri, 29 Sep 2006 10:19:04 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (tx8lm6o5rkkyigji@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k8TAJ3hT014924; Fri, 29 Sep 2006 03:19:03 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k8TAJ2Wv014923; Fri, 29 Sep 2006 03:19:02 -0700 (PDT) (envelope-from jmg) Date: Fri, 29 Sep 2006 03:19:02 -0700 From: John-Mark Gurney To: Ruslan Ermilov Message-ID: <20060929101902.GQ80527@funkthat.com> Mail-Followup-To: Ruslan Ermilov , freebsd-current@FreeBSD.org References: <20060928231816.GI80527@funkthat.com> <20060929082713.GD86237@rambler-co.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060929082713.GD86237@rambler-co.ru> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-current@FreeBSD.org Subject: Re: better way to build libraries.. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2006 10:19:04 -0000 Ruslan Ermilov wrote this message on Fri, Sep 29, 2006 at 12:27 +0400: > On Thu, Sep 28, 2006 at 04:18:16PM -0700, John-Mark Gurney wrote: > > With the recent libcrypto upgrade, I found out that we can't build > > libraries (that have special headers) w/o doing a buildworld... This > > isn't very good as the latest SA requires people to do a buildworld > > to get the new library.. With a bit of advice from Kris Kennaway, > > I came up w/ the following patch: > > Don't ever think about committing this! ;-) I wasn't thinking of committing that patch, but thinking if there was enough interest of making it part of bsd.lib.mk, and a standard part of building libraries... (Maybe my original message wasn't clear enough?) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 10:27:19 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC81216A492 for ; Fri, 29 Sep 2006 10:27:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EFAC43D46 for ; Fri, 29 Sep 2006 10:27:19 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 829EC46BE1; Fri, 29 Sep 2006 06:27:18 -0400 (EDT) Date: Fri, 29 Sep 2006 11:27:18 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Eric Anderson In-Reply-To: <451ADC21.50206@centtech.com> Message-ID: <20060929112610.S73166@fledge.watson.org> References: <451ADC21.50206@centtech.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: isofs/cd9660 -> relocate to fs/isofs/cd9660? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 10:27:19 -0000 On Wed, 27 Sep 2006, Eric Anderson wrote: > I noticed that cd9660 file system is in sys/isofs/cd9660 instead of what > seems more logical: sys/fs/cd9660. Is there any reason not to move it? > Curious mostly.. It's interesting that it was left behind in the last big rearrangement, which did successfully move most of the misc. file systems to the fs tree. One good reason not to move things around in the kernel tree is that it's not just kernel code that is affected -- userland code is also affected, and if there are third party apps that use kernel include files, they need to be updated. I'm not sure if that's true for the cd9660 file system, but it would be easy to imagine that being the case. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Thu Sep 28 20:45:44 2006 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1903C16A40F; Thu, 28 Sep 2006 20:45:44 +0000 (UTC) (envelope-from ariff@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id C448B43D46; Thu, 28 Sep 2006 20:45:43 +0000 (GMT) (envelope-from ariff@FreeBSD.org) Received: from misaki (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with SMTP id k8SKjevY086465; Thu, 28 Sep 2006 20:45:42 GMT (envelope-from ariff@FreeBSD.org) Date: Fri, 29 Sep 2006 04:44:01 +0800 From: Ariff Abdullah To: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org, freebsd-multimedia@FreeBSD.org Message-Id: <20060929044401.5c52bef3.ariff@FreeBSD.org> Organization: FreeBSD X-Mailer: /usr/local/lib/ruby/1.8/net/smtp.rb Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Fri__29_Sep_2006_04_44_01_+0800_QbWchVmgk_SsJxL8" X-Mailman-Approved-At: Fri, 29 Sep 2006 12:00:03 +0000 Cc: Subject: HEADS UP: Last call for snd_hda(4) testers - High Definition Audio driver X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Sep 2006 20:45:44 -0000 --Signature=_Fri__29_Sep_2006_04_44_01_+0800_QbWchVmgk_SsJxL8 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [ Please remove current@ and stable@ from your CC: . This mail serves only as an announcement (or a death threat, if you prefer that way). ] Allright folks, I've had enough. It is time to go gold. This driver is proven stable and works (mostly) after several weeks of testing and bug hunting, thanks to those unfortunate unpaid victims at #freebsd-azalia@freenode and few other unsung heroes. If you're using previous driver, please remove it, get a latest/pristine RELENG_6 or -CURRENT, and apply these patches: For RELENG_6: http://people.freebsd.org/~ariff/test/hda_releng6.diff For -CURRENT: http://people.freebsd.org/~ariff/test/hda_current.diff While applying these patches using patch(1), DO NOT forget about "-p0" argument. I'm getting tired with people reporting the same old "patch failed" or "compile failed" because of this. Stick this into your mind, forever, eternally. The proper way to apply it is like this: patch -d /usr/src -p0 < hda_yada.diff You don't have to buildworld, buildkernel or any other sacrificial ritual. Simply "cd /usr/src/sys/modules/sound/ && make clean cleandir && make && make install" should do the trick. Well, it is up to you, really :) Unfortunately, those who are still stuck with 6.1-RELEASE and earlier had to rely on the binary driver instead. Please grab both sound.ko and snd_hda.ko at http://people.freebsd.org/~ariff/HDA/kmod/ and replace whatever sound.ko you have there. HDA Driver Revision: 20060929_0025 <- see ? There are $((9999 - 25)) more iterations before it reach its equilibrium state. Issues: 1) SPDIF not working - I had to disable it, for now. 2) Multichannel/surround not working - The driver tries to output the sound to all possible path. If you have speakers attach to all of them, chances are it all works, but not in a true sense of multichannel/surround. There are few more works left to do on the upper layer of the sound driver to make it works properly. 3) Recording is broken on few hardwares - As far as I can tell, it should work flawlessly, but not to all. This is a bit tricky to handle, but I'm working on it. 4) Pluging in headset does not mute speakers - This is easy (read #5) 5) Nothing works at all - more like a null driver, isn't it? Please follow the instructions from http://people.freebsd.org/~ariff/HDA/ . The death threat is real :) 6) The driver cause panic, killing my first unborn child - nahh.. I don't believe this. If you're running -CURRENT, the issues are probably elsewhere :) As suggested by netchild@, please report your success or failure like this to freebsd-multimedia@FreeBSD.org: Success ------- Hardware/chipset: Compaq Presario V3000 series =20 http://h10025.www1.hp.com/ewfrf/wc/product?product=3D3190957&lc=3Den&cc=3Du= s&dlc=3Den&lang=3Den&cc=3Dus Playback: Works flawlessly Recording: Works flawlessly Specific Issues: None. It works out of the box, including analog CD. Special request: I want to die in peace. Verbose dmesg: pcm0: mem 0xc0000000-0xc0003fff irq 10 at device 16.1 on pci0 pcm0: pcm0: (optional, you don't have to include those boring and uneventfull kernel noises since the driver already works for you) Failure ------- Hardware/chipset: Karipap series http://www.karipap.com/ Playback: NONE! Recording: NONE! Specific Issues: I would rather amaze if this works since it is a food to begin with. Special request: I can donate this to you, but even so, you can buy it at the nearest food stall for an RM 0.50 Verbose dmesg: (please put your verbose dmesg here or I'll send another death threat to your first unborn child) -- Ariff Abdullah FreeBSD ... Recording in stereo is obviously too advanced and confusing for us idiot ***** users :P ........ --Signature=_Fri__29_Sep_2006_04_44_01_+0800_QbWchVmgk_SsJxL8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFHDQWlr+deMUwTNoRAsnXAJ4to4nUcdNhf0oCz/O+RPBvRivSmwCgvK3n zGsuHpHV3juw3m9YSs0Gd4o= =7THp -----END PGP SIGNATURE----- --Signature=_Fri__29_Sep_2006_04_44_01_+0800_QbWchVmgk_SsJxL8-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 09:26:52 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB10516A407 for ; Fri, 29 Sep 2006 09:26:52 +0000 (UTC) (envelope-from gw-bsd-current@news.kiev.sovam.com) Received: from news.kiev.sovam.com (news.kiev.sovam.com [212.109.32.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3EDA443D45 for ; Fri, 29 Sep 2006 09:26:52 +0000 (GMT) (envelope-from gw-bsd-current@news.kiev.sovam.com) Received: from mail by news.kiev.sovam.com with local (Exim 3.36 #5) id 1GTEdu-000MBh-00 for freebsd-current@freebsd.org; Fri, 29 Sep 2006 12:26:50 +0300 From: Ivan Synyeokov To: freebsd-current@freebsd.org Date: Fri, 29 Sep 2006 12:26:55 +0300 Message-ID: <451CE6DF.40708@johnny.kiev.ua> References: X-Organization: Svit Online (post does not reflect views of Golden Telecom) X-Gated-By: news2list v1.4, (c) Vladimir Litovka X-Gated-Date: Fri Sep 29 09:26:50 2006 GMT X-Mailman-Approved-At: Fri, 29 Sep 2006 12:00:44 +0000 Subject: Re: Call for Marvell/SysKonnect Yukon II Gigabit Ethernet testers. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ivan Synyeokov List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2006 09:26:52 -0000 On 28.09.2006 15:16 Pyun YongHyeon wrote: > On Thu, Sep 28, 2006 at 09:46:52AM +0300, Ivan Synyeokov wrote: > > I have Epox EP-MF570 MB with two Marvell 88E1116, but unfortunately even > > pciconf -lv doesn't show anything related to network (on Win LAN is > > working with native drivers), so I'd like to ask is it possible to make > > 'em work on your drivers with a little hacking? > > Unfortunately I'm not a kernel hacker, so it's difficult to me find out > > what's the problem. Also I tried NDIS, but with no luck too. > > > > But nevertheless I really appreciate your work, hope it would be merged > > into RELENG_6 soon :) > > > > P.S. I added dmesg and pciconf, maybe for someone it would be useful. > > > > I'm not sure but 88E1116 seems to Gigabit PHY not ethernet > controller. Have you tried nve(4) or nfe(4) on CURRENT? > Oh my! I strangely missed nfe, but no luck too :( Well, actually hardware is recognized (ukphy), but "watchdog timeout" makes it impossible to use it. I tried DHCP and got continious watchdog timeout mixed with UP/DOWN of card. On 28.09.2006 15:48 JoaoBR wrote: > On Thursday 28 September 2006 03:46, Ivan Synyeokov wrote: >> I have Epox EP-MF570 MB with two Marvell 88E1116, but unfortunately even >> pciconf -lv doesn't show anything related to network (on Win LAN is >> working with native drivers), so I'd like to ask is it possible to make >> 'em work on your drivers with a little hacking? > > > Hi > probably you find here what you need: > > http://www.se.hiroshima-u.ac.jp/~shigeaki/software/freebsd-nfe.html > Thanks a lot, but above I mentioned about problems. I also tried 6.1, also with no luck. So, please, can anybode give me some advice? I could make some testing on Monday. -- Johnny From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 12:32:53 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E729216A40F for ; Fri, 29 Sep 2006 12:32:53 +0000 (UTC) (envelope-from simon@zaphod.nitro.dk) Received: from mx.nitro.dk (zarniwoop.nitro.dk [83.92.207.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00E4843D6A for ; Fri, 29 Sep 2006 12:32:50 +0000 (GMT) (envelope-from simon@zaphod.nitro.dk) Received: from zaphod.nitro.dk (unknown [192.168.3.39]) by mx.nitro.dk (Postfix) with ESMTP id 34235386C1F; Fri, 29 Sep 2006 12:32:49 +0000 (UTC) Received: by zaphod.nitro.dk (Postfix, from userid 3000) id 7AA1711420; Fri, 29 Sep 2006 14:32:48 +0200 (CEST) Date: Fri, 29 Sep 2006 14:32:48 +0200 From: "Simon L. Nielsen" To: Scott Long Message-ID: <20060929123247.GF983@zaphod.nitro.dk> References: <451ADC21.50206@centtech.com> <451AE27F.3010506@samsco.org> <200609271727.29775.jhb@freebsd.org> <20060928082651.b6xp2ayu9wg40wok@webmail.leidinger.net> <451CA64D.3050703@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <451CA64D.3050703@samsco.org> User-Agent: Mutt/1.5.11 Cc: Alexander Leidinger , freebsd-current@freebsd.org Subject: Re: isofs/cd9660 -> relocate to fs/isofs/cd9660? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 12:32:54 -0000 On 2006.09.28 22:51:25 -0600, Scott Long wrote: > Moves in CVS are relatively easy too, it's just that they can only > be performed by a special group of people, and that special group > rarely responds to requests.[...] That might have the case in the past, but it's not now and hasn't been for the last 3 months; we just haven't recieved many requests in that period. -- Simon L. Nielsen Hat of the day: ncvs From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 13:01:20 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DC1616A4CA for ; Fri, 29 Sep 2006 13:01:20 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5B3843D53 for ; Fri, 29 Sep 2006 13:01:17 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 93219 invoked from network); 29 Sep 2006 13:02:32 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Sep 2006 13:02:32 -0000 Message-ID: <451D191C.2050307@freebsd.org> Date: Fri, 29 Sep 2006 15:01:16 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Robert Watson References: <451C4850.5030302@freebsd.org> <20060929092813.U73166@fledge.watson.org> In-Reply-To: <20060929092813.U73166@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 13:01:20 -0000 Robert Watson wrote: > > On Fri, 29 Sep 2006, Andre Oppermann wrote: > >> The patch is available here: >> http://people.freebsd.org/~andre/sosend+m_uiotombuf-20060928.diff > > I like the concept of these changes in principle -- this is the reason I > broke out sosend_copyin(), so that we could start plugging bits of the > send routines more easily for optimization. However, I think we need to > review this really carefully. A casual glance brought up one question, > and I hope to get a chance to review this in detail in the next few > days. The question is with regard to the 'space' variable. When > breaking out sosend_copyin(), I originally simply passed space in as an > argument, which is what you do currently. However, I found I had to > change it to pass in the variable by reference so that it could be > updated, as later portions of sosend() depend on it being updated in > order to figure out what flags to pass to pru_send() with respect to > PRUS_MORETOCOME, as well as for the (resid && space > 0) condition for > the main loop. In your revised version, 'space' isn't updated in > sosend() after calling m_uiotombuf(), which on a casual read, suggests > that PRUS_MORETOCOME will no longer get set on the last pass into > pru_send(), and that the loop may go an extra time and pass more data > into TCP than there is room in the socket send buffer. I may be reading > wrong, I've not had time to look in any detail, but that was my > experience, so you may find you need to pass send by reference, as I do > in sosend_copyin(), for the same reason. Your observation is correct. The variable 'space' is no longer updated with my changes. For sosend_dgram() this is of no consequence as PRUS_ MORETOCOME can't ever be true. For datagrams the uio must not contain more data than we have space left in the socket buffer. Otherwise we fail with EMSGSIZE. For sosend_generic() PRUS_MORETOCOME is no longer correctly set with my changes. For TCP this is of no consequence either as TCP doesn't care about it. For correctness I'll change my patch to update 'space' in sosend_generic() and remove the PRUS_MORETOCOME flag from sosend_dgram() completely. -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 13:07:27 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDBC716A40F; Fri, 29 Sep 2006 13:07:27 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B0D043D4C; Fri, 29 Sep 2006 13:07:27 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E391946D0B; Fri, 29 Sep 2006 09:07:26 -0400 (EDT) Date: Fri, 29 Sep 2006 14:07:26 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Andre Oppermann In-Reply-To: <451D191C.2050307@freebsd.org> Message-ID: <20060929140545.L66510@fledge.watson.org> References: <451C4850.5030302@freebsd.org> <20060929092813.U73166@fledge.watson.org> <451D191C.2050307@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 13:07:28 -0000 On Fri, 29 Sep 2006, Andre Oppermann wrote: >> I like the concept of these changes in principle -- this is the reason I >> broke out sosend_copyin(), so that we could start plugging bits of the send >> routines more easily for optimization. However, I think we need to review >> this really carefully. A casual glance brought up one question, and I hope >> to get a chance to review this in detail in the next few days. The >> question is with regard to the 'space' variable. When breaking out >> sosend_copyin(), I originally simply passed space in as an argument, which >> is what you do currently. However, I found I had to change it to pass in >> the variable by reference so that it could be updated, as later portions of >> sosend() depend on it being updated in order to figure out what flags to >> pass to pru_send() with respect to PRUS_MORETOCOME, as well as for the >> (resid && space > 0) condition for the main loop. In your revised version, >> 'space' isn't updated in sosend() after calling m_uiotombuf(), which on a >> casual read, suggests that PRUS_MORETOCOME will no longer get set on the >> last pass into pru_send(), and that the loop may go an extra time and pass >> more data into TCP than there is room in the socket send buffer. I may be >> reading wrong, I've not had time to look in any detail, but that was my >> experience, so you may find you need to pass send by reference, as I do in >> sosend_copyin(), for the same reason. > > Your observation is correct. The variable 'space' is no longer updated with > my changes. For sosend_dgram() this is of no consequence as PRUS_ > MORETOCOME can't ever be true. For datagrams the uio must not contain more > data than we have space left in the socket buffer. Otherwise we fail with > EMSGSIZE. For sosend_generic() PRUS_MORETOCOME is no longer correctly set > with my changes. For TCP this is of no consequence either as TCP doesn't > care about it. For correctness I'll change my patch to update 'space' in > sosend_generic() and remove the PRUS_MORETOCOME flag from sosend_dgram() > completely. Are you sure TCP doesn't care? I thought it used PRUS_MORETOCOME as a hint to determine whether to immediately output or wait for small segments, but admit to never having read the code in detail. Also, 'space' is not just about PRUS_MORETOCOME, it's also about the loop terminating at the right time. I'll try to give your revised patch a closer reading this weekend. Thanks, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 13:13:16 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EDED16A47C; Fri, 29 Sep 2006 13:13:16 +0000 (UTC) (envelope-from joe@tao.org.uk) Received: from mailhost.tao.org.uk (transwarp.tao.org.uk [87.74.4.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E2AF43D53; Fri, 29 Sep 2006 13:13:15 +0000 (GMT) (envelope-from joe@tao.org.uk) Received: from genius.tao.org.uk (genius.pact.cpes.susx.ac.uk [139.184.130.240]) by mailhost.tao.org.uk (Postfix) with ESMTP id 0161E5C68; Fri, 29 Sep 2006 14:13:14 +0100 (BST) Received: by genius.tao.org.uk (Postfix, from userid 100) id 3A92E4054; Fri, 29 Sep 2006 14:13:11 +0100 (BST) Date: Fri, 29 Sep 2006 14:13:11 +0100 From: Josef Karthauser To: Christian Brueffer Message-ID: <20060929131311.GA1407@genius.tao.org.uk> Mail-Followup-To: Josef Karthauser , Christian Brueffer , current@freebsd.org References: <20060915165351.GC2020@haakonia.hitnet.RWTH-Aachen.DE> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh" Content-Disposition: inline In-Reply-To: <20060915165351.GC2020@haakonia.hitnet.RWTH-Aachen.DE> User-Agent: Mutt/1.5.11 Cc: current@freebsd.org Subject: Re: em(4) interface wedges X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 13:13:16 -0000 --jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 15, 2006 at 06:53:51PM +0200, Christian Brueffer wrote: > Hi, >=20 > with the latest em(4) code in current (sans the printf/device_printf > change), my interface wedges every few hours. It can be resurrected > by bringing it down and up again. >=20 > The device in question is a E1000_DEV_ID_82540EP_LP built into my > Thinkpad. No, but I have a wedging problem on 6.2-PRERELEASE with em0. The machine locks solid 1 out of 3 times when dhclient first gets run against em0 in the boot process. :/. Joe --=20 Josef Karthauser (joe@tao.org.uk) http://www.josef-k.net/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An eclectic mix of fact an= d theory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iEYEARECAAYFAkUdG+YACgkQXVIcjOaxUBbanQCfVe+bGUUz4nCMs4YH3/xL4y5D FAUAoJLrwUqox1vybpRvhX5KVJgW6Jle =c2G/ -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 13:20:07 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EC9916A407; Fri, 29 Sep 2006 13:20:07 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD79443D64; Fri, 29 Sep 2006 13:20:06 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 5D73C46B82; Fri, 29 Sep 2006 09:20:06 -0400 (EDT) Date: Fri, 29 Sep 2006 14:20:06 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: ru@FreeBSD.org Message-ID: <20060929141709.E70454@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 13:20:07 -0000 > revision 1.72 > date: 2005/11/03 08:56:39; author: ru; state: Exp; lines: +1 -0 > Serialize access to the info/dir file; needed for parallel installs. > > Reported by: scottl > > I'm not very fond of using the non-standard lockf(1) here, but I > have no better idea at the moment. NetBSD uses ln(1) to create a > lock file, but this approach can result in a deadlock if make is > interrupted, leaving an orphaned lock file. I'm not sure why this suddenly showed up in my configuration, but this is preventing me from installing world on an NFS mounted file system without rpc.lockd running. I get the following: ===> lib/libcom_err/doc (install) lockf -k /usr/share/info/dir install-info --quiet --defsection="Programming & development tools." --defentry="* libcom_err: (com_err). A Common Error Description Library for UNIX." com_err.info /usr/share/info/dir lockf: cannot open /usr/share/info/dir: Operation not supported *** Error code 73 Stop in /zoo/rwatson/netperf/RELENG_6/src/lib/libcom_err/doc. *** Error code 1 Stop in /zoo/rwatson/netperf/RELENG_6/src/lib/libcom_err. *** Error code 1 I've noticed an increasing intolerance in our tools for system install and maintenance to locking not being implemented over the past few years. I no longer get working cron on boxes with neither rpc.lockd nor local locking enabled, for example. Installworld represents a bigger problem, since I don't want to have to depend on a completely working rpc chain in order to installworld, nor depend on running in what would effectively be multiuser mode. Surely there's a better fix for this than adding lockf use? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 13:46:28 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E80B616A4D4; Fri, 29 Sep 2006 13:46:27 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2CFE43FFF; Fri, 29 Sep 2006 13:43:37 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 830DA6052; Fri, 29 Sep 2006 17:43:31 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 635CB6010; Fri, 29 Sep 2006 17:43:31 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k8TDhWX7005023; Fri, 29 Sep 2006 17:43:32 +0400 (MSD) (envelope-from ru) Date: Fri, 29 Sep 2006 17:43:32 +0400 From: Ruslan Ermilov To: Robert Watson Message-ID: <20060929134332.GD4776@rambler-co.ru> References: <20060929141709.E70454@fledge.watson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Km1U/tdNT/EmXiR1" Content-Disposition: inline In-Reply-To: <20060929141709.E70454@fledge.watson.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: current@FreeBSD.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 13:46:28 -0000 --Km1U/tdNT/EmXiR1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 29, 2006 at 02:20:06PM +0100, Robert Watson wrote: >=20 > >revision 1.72 > >date: 2005/11/03 08:56:39; author: ru; state: Exp; lines: +1 -0 > >Serialize access to the info/dir file; needed for parallel installs. > > > >Reported by: scottl > > > >I'm not very fond of using the non-standard lockf(1) here, but I > >have no better idea at the moment. NetBSD uses ln(1) to create a > >lock file, but this approach can result in a deadlock if make is > >interrupted, leaving an orphaned lock file. >=20 > I'm not sure why this suddenly showed up in my configuration, but this is= =20 > preventing me from installing world on an NFS mounted file system without= =20 > rpc.lockd running. I get the following: >=20 > =3D=3D=3D> lib/libcom_err/doc (install) > lockf -k /usr/share/info/dir install-info --quiet =20 > --defsection=3D"Programming & > development tools." --defentry=3D"* libcom_err: (com_err). A Comm= on=20 > Error > Description Library for UNIX." com_err.info /usr/share/info/dir > lockf: cannot open /usr/share/info/dir: Operation not supported > *** Error code 73 >=20 > Stop in /zoo/rwatson/netperf/RELENG_6/src/lib/libcom_err/doc. > *** Error code 1 >=20 > Stop in /zoo/rwatson/netperf/RELENG_6/src/lib/libcom_err. > *** Error code 1 >=20 The necessity to run rpc.lockd is documented in the build(7) manpage. Quote: : installworld Install everything built by a preceding buildworld step : into the directory hierarchy pointed to by make(1) vari- : able DESTDIR. :=20 : If installing onto an NFS file system, make sure that : rpc.lockd(8) is running on both client and server. See : rc.conf(5) on how to make it start at boot time. > I've noticed an increasing intolerance in our tools for system install an= d=20 > maintenance to locking not being implemented over the past few years. I = no=20 > longer get working cron on boxes with neither rpc.lockd nor local locking= =20 > enabled, for example. Installworld represents a bigger problem, since I= =20 > don't want to have to depend on a completely working rpc chain in order t= o=20 > installworld, nor depend on running in what would effectively be multiuse= r=20 > mode. Surely there's a better fix for this than adding lockf use? >=20 I don't know of a better fix. Another approach is that mentioned in the commit log and used by NetBSD. I tried it, and it was very fragile -- it could easily leave the temporary file around, and that would stuck forever another instances. The problem at hand is that multiple instances of install-info(1) are attempting to write to the ${DESTDIR}/usr/share/info/dir file. If you have a better idea, don't hesitate to let me know. I'd very much like to get rid of that as well. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --Km1U/tdNT/EmXiR1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFHSMEqRfpzJluFF4RAsKRAKCZx4lQziJRibkA15786ZmqHsB+zgCeI77P SNAAg2xagRiUMTtwlr11gnY= =mXpp -----END PGP SIGNATURE----- --Km1U/tdNT/EmXiR1-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 13:50:08 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3EE0416A47E; Fri, 29 Sep 2006 13:50:08 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0115143D60; Fri, 29 Sep 2006 13:49:37 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 32D8146CFE; Fri, 29 Sep 2006 09:49:36 -0400 (EDT) Date: Fri, 29 Sep 2006 14:49:36 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ruslan Ermilov In-Reply-To: <20060929134332.GD4776@rambler-co.ru> Message-ID: <20060929144738.W70454@fledge.watson.org> References: <20060929141709.E70454@fledge.watson.org> <20060929134332.GD4776@rambler-co.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 13:50:08 -0000 On Fri, 29 Sep 2006, Ruslan Ermilov wrote: > The necessity to run rpc.lockd is documented in the build(7) manpage. > Quote: I think this is a bad idea. rpc.lockd is one of the most fragile and largely broken pieces of the operating system. Arguably we shouldn't even be shipping it. Making it required for installworld is asking for trouble. > : installworld Install everything built by a preceding buildworld step > : into the directory hierarchy pointed to by make(1) vari- > : able DESTDIR. > : > : If installing onto an NFS file system, make sure that > : rpc.lockd(8) is running on both client and server. See > : rc.conf(5) on how to make it start at boot time. > >> I've noticed an increasing intolerance in our tools for system install and >> maintenance to locking not being implemented over the past few years. I no >> longer get working cron on boxes with neither rpc.lockd nor local locking >> enabled, for example. Installworld represents a bigger problem, since I >> don't want to have to depend on a completely working rpc chain in order to >> installworld, nor depend on running in what would effectively be multiuser >> mode. Surely there's a better fix for this than adding lockf use? >> > I don't know of a better fix. Another approach is that mentioned in the > commit log and used by NetBSD. I tried it, and it was very fragile -- it > could easily leave the temporary file around, and that would stuck forever > another instances. > > The problem at hand is that multiple instances of install-info(1) are > attempting to write to the ${DESTDIR}/usr/share/info/dir file. If you have a > better idea, don't hesitate to let me know. I'd very much like to get rid > of that as well. The basic problem here is that install-info doesn't support parallelism. Sounds like we just need to accept that and therefore accept that we don't support doing installworld with the -j argument. A middle-ground solution would be to only use lockf if -j is used. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 14:07:37 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDC6616A40F for ; Fri, 29 Sep 2006 14:07:37 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF2BC43D64 for ; Fri, 29 Sep 2006 14:07:21 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: by ug-out-1314.google.com with SMTP id m2so258830uge for ; Fri, 29 Sep 2006 07:07:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=fdkqm3NIq/++LNsGA9DwoHEZUKLv3ruQPmJMadodtbdIur3u5dJtfxTsN7BHrS7Vipxv9eeFmRLXf2LmXOgSKin3QiZk/2omkUraneYcEAVTawVP8mlABhqUOAto4fDQG4DwefqrZo8TboO53vj6C4lT9cfqRgnSP+jWmM/ZZ8U= Received: by 10.67.119.5 with SMTP id w5mr68615ugm; Fri, 29 Sep 2006 07:07:20 -0700 (PDT) Received: by 10.70.118.3 with HTTP; Fri, 29 Sep 2006 07:07:19 -0700 (PDT) Message-ID: <2fd864e0609290707t7e7d6e17g61a09ff5aa10ff3f@mail.gmail.com> Date: Fri, 29 Sep 2006 09:07:19 -0500 From: Astrodog To: "Robert Watson" In-Reply-To: <20060929144738.W70454@fledge.watson.org> MIME-Version: 1.0 References: <20060929141709.E70454@fledge.watson.org> <20060929134332.GD4776@rambler-co.ru> <20060929144738.W70454@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 14:07:38 -0000 On 9/29/06, Robert Watson wrote: > > > On Fri, 29 Sep 2006, Ruslan Ermilov wrote: > > > The necessity to run rpc.lockd is documented in the build(7) manpage. > > Quote: > > I think this is a bad idea. rpc.lockd is one of the most fragile and > largely > broken pieces of the operating system. Arguably we shouldn't even be > shipping > it. Making it required for installworld is asking for trouble. > > > : installworld Install everything built by a preceding buildworld > step > > : into the directory hierarchy pointed to by make(1) > vari- > > : able DESTDIR. > > : > > : If installing onto an NFS file system, make sure that > > : rpc.lockd(8) is running on both client and > server. See > > : rc.conf(5) on how to make it start at boot time. > > > >> I've noticed an increasing intolerance in our tools for system install > and > >> maintenance to locking not being implemented over the past few > years. I no > >> longer get working cron on boxes with neither rpc.lockd nor local > locking > >> enabled, for example. Installworld represents a bigger problem, since > I > >> don't want to have to depend on a completely working rpc chain in order > to > >> installworld, nor depend on running in what would effectively be > multiuser > >> mode. Surely there's a better fix for this than adding lockf use? > >> > > I don't know of a better fix. Another approach is that mentioned in the > > commit log and used by NetBSD. I tried it, and it was very fragile -- > it > > could easily leave the temporary file around, and that would stuck > forever > > another instances. > > > > The problem at hand is that multiple instances of install-info(1) are > > attempting to write to the ${DESTDIR}/usr/share/info/dir file. If you > have a > > better idea, don't hesitate to let me know. I'd very much like to get > rid > > of that as well. > > The basic problem here is that install-info doesn't support parallelism. > Sounds like we just need to accept that and therefore accept that we don't > support doing installworld with the -j argument. A middle-ground solution > would be to only use lockf if -j is used. I'd be concerned that with this approach, we could see some rather hard to diagnose problems come up if rpc.lockd broke silently during the install, but the install continued. Personally, I find it much, much more important to be able to do an installworld from a "real" single user mode via NFS, than it is to support -j. I don't think I've ever had a circumstance where I really needed make installworld to finish quickly. Besides, if there's significant use of locks in installworld, -j doesn't get a whole lot of performance gain anyway. Another thought here, is that in my experience, installworld is disk, or network I/O bound, not CPU... Under those circumstances, we may find that there's reduced performance with -j anyway, in which case there's no reason to support it that I can see. For what its worth.... I'd go with just stopping support for -j in installworld, even if things are CPU bound. --- Harrison Grundy From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 14:08:06 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0425916A47C; Fri, 29 Sep 2006 14:08:06 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A20B43D6E; Fri, 29 Sep 2006 14:08:03 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id B042B5F4A; Fri, 29 Sep 2006 18:08:01 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 76C585F29; Fri, 29 Sep 2006 18:08:01 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k8TE82Sv005624; Fri, 29 Sep 2006 18:08:02 +0400 (MSD) (envelope-from ru) Date: Fri, 29 Sep 2006 18:08:02 +0400 From: Ruslan Ermilov To: Robert Watson Message-ID: <20060929140802.GH4776@rambler-co.ru> References: <20060929141709.E70454@fledge.watson.org> <20060929134332.GD4776@rambler-co.ru> <20060929144738.W70454@fledge.watson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+QwZB9vYiNIzNXIj" Content-Disposition: inline In-Reply-To: <20060929144738.W70454@fledge.watson.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: current@FreeBSD.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 14:08:06 -0000 --+QwZB9vYiNIzNXIj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 29, 2006 at 02:49:36PM +0100, Robert Watson wrote: >=20 > On Fri, 29 Sep 2006, Ruslan Ermilov wrote: >=20 > >The necessity to run rpc.lockd is documented in the build(7) manpage.=20 > >Quote: >=20 > I think this is a bad idea. rpc.lockd is one of the most fragile and=20 > largely broken pieces of the operating system. Arguably we shouldn't eve= n=20 > be shipping it. Making it required for installworld is asking for troubl= e. >=20 > >: installworld Install everything built by a preceding buildworld st= ep > >: into the directory hierarchy pointed to by make(1) va= ri- > >: able DESTDIR. > >: > >: If installing onto an NFS file system, make sure that > >: rpc.lockd(8) is running on both client and server. S= ee > >: rc.conf(5) on how to make it start at boot time. > > > >>I've noticed an increasing intolerance in our tools for system install= =20 > >>and maintenance to locking not being implemented over the past few year= s.=20 > >>I no longer get working cron on boxes with neither rpc.lockd nor local= =20 > >>locking enabled, for example. Installworld represents a bigger problem= ,=20 > >>since I don't want to have to depend on a completely working rpc chain = in=20 > >>order to installworld, nor depend on running in what would effectively = be=20 > >>multiuser mode. Surely there's a better fix for this than adding lockf= =20 > >>use? > >> > >I don't know of a better fix. Another approach is that mentioned in the= =20 > >commit log and used by NetBSD. I tried it, and it was very fragile -- i= t=20 > >could easily leave the temporary file around, and that would stuck forev= er=20 > >another instances. > > > >The problem at hand is that multiple instances of install-info(1) are=20 > >attempting to write to the ${DESTDIR}/usr/share/info/dir file. If you ha= ve=20 > >a better idea, don't hesitate to let me know. I'd very much like to get= =20 > >rid of that as well. >=20 > The basic problem here is that install-info doesn't support parallelism.= =20 > Sounds like we just need to accept that and therefore accept that we don'= t=20 > support doing installworld with the -j argument. A middle-ground solutio= n=20 > would be to only use lockf if -j is used. >=20 How could it support parallelism without using lockf(3) or equivalent? I'd be happy to hack install-info(1) if there's a way. A middle-ground solution was easy to implement, and I have a patch for it if a more clean solution couldn't be found. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --+QwZB9vYiNIzNXIj Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFHSjCqRfpzJluFF4RAvHtAKCV/esGthroxAdAt9Kkw68xpodkHgCdE1hi jOvAVArmctu87803OL5j6no= =TuK/ -----END PGP SIGNATURE----- --+QwZB9vYiNIzNXIj-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 14:19:53 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E9A6416A403; Fri, 29 Sep 2006 14:19:53 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C05A43D95; Fri, 29 Sep 2006 14:19:51 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E416046D33; Fri, 29 Sep 2006 10:19:50 -0400 (EDT) Date: Fri, 29 Sep 2006 15:19:50 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ruslan Ermilov In-Reply-To: <20060929140802.GH4776@rambler-co.ru> Message-ID: <20060929151750.Y74256@fledge.watson.org> References: <20060929141709.E70454@fledge.watson.org> <20060929134332.GD4776@rambler-co.ru> <20060929144738.W70454@fledge.watson.org> <20060929140802.GH4776@rambler-co.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@FreeBSD.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 14:19:54 -0000 On Fri, 29 Sep 2006, Ruslan Ermilov wrote: >>> I don't know of a better fix. Another approach is that mentioned in the >>> commit log and used by NetBSD. I tried it, and it was very fragile -- it >>> could easily leave the temporary file around, and that would stuck forever >>> another instances. >>> >>> The problem at hand is that multiple instances of install-info(1) are >>> attempting to write to the ${DESTDIR}/usr/share/info/dir file. If you have >>> a better idea, don't hesitate to let me know. I'd very much like to get >>> rid of that as well. >> >> The basic problem here is that install-info doesn't support parallelism. >> Sounds like we just need to accept that and therefore accept that we don't >> support doing installworld with the -j argument. A middle-ground solution >> would be to only use lockf if -j is used. >> > How could it support parallelism without using lockf(3) or equivalent? I'd > be happy to hack install-info(1) if there's a way. Yes, that's why it's the basic problem. :-) The problem is the way info works -- that it uses a shared file for a global table of contents, rather than constructing it from a set of independent files once. Is there any way to generate the entries in the directory incrementally in different files, then combine them all at the end once? I.e., like we do with the man page apropos database -- we build all the elements independently, which is parallelizable, and then once at the end once it's all done, we build the single central database. > A middle-ground solution was easy to implement, and I have a patch for it if > a more clean solution couldn't be found. I'd like to see that in the tree in the near future. If nothing else, it will speed up installworld in the non-j case, probably measurably (although I've not measured it :-). Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 14:24:11 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D276016A403; Fri, 29 Sep 2006 14:24:11 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DBB643D60; Fri, 29 Sep 2006 14:24:05 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id D82615EC1; Fri, 29 Sep 2006 18:24:04 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id B65545EB6; Fri, 29 Sep 2006 18:24:04 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k8TEO5YY005923; Fri, 29 Sep 2006 18:24:05 +0400 (MSD) (envelope-from ru) Date: Fri, 29 Sep 2006 18:24:05 +0400 From: Ruslan Ermilov To: Astrodog Message-ID: <20060929142405.GA5875@rambler-co.ru> References: <20060929141709.E70454@fledge.watson.org> <20060929134332.GD4776@rambler-co.ru> <20060929144738.W70454@fledge.watson.org> <2fd864e0609290707t7e7d6e17g61a09ff5aa10ff3f@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline In-Reply-To: <2fd864e0609290707t7e7d6e17g61a09ff5aa10ff3f@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: Robert Watson , current@freebsd.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 14:24:11 -0000 --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 29, 2006 at 09:07:19AM -0500, Astrodog wrote: > Personally, I find it much, much more important to be able to do an > installworld from a "real" single user mode via NFS, than it is to support > -j. I don't think I've ever had a circumstance where I really needed make > installworld to finish quickly. >=20 This doesn't mean it's unused. For example, our release engineers build releases on fast SMP machines, and "make release" can complete faster with -j on real SMP hardware. This is btw how this bug was found in the first place. > Besides, if there's significant use of > locks in installworld, -j doesn't get a whole lot of performance gain > anyway. >=20 No, it's insignificant. > Another thought here, is that in my experience, installworld is disk, or > network I/O bound, not CPU... Under those circumstances, we may find that > there's reduced performance with -j anyway, in which case there's no > reason to support it that I can see. >=20 Do you have numbers on real SMP hardware to share? Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --d6Gm4EdcadzBjdND Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFHSyFqRfpzJluFF4RAhARAJ4oDghEb1iDsQLrpweXflfWNY4AsACgnVZ6 x282oScTD5bgDPZHdDSaOyg= =2axT -----END PGP SIGNATURE----- --d6Gm4EdcadzBjdND-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 15:15:20 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6211116A4B3; Fri, 29 Sep 2006 15:15:20 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC3C243D96; Fri, 29 Sep 2006 15:14:58 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k8TFEEfx027158; Fri, 29 Sep 2006 09:14:14 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 29 Sep 2006 09:14:14 -0600 (MDT) Message-Id: <20060929.091414.74722768.imp@bsdimp.com> To: astrodog@gmail.com From: Warner Losh In-Reply-To: <2fd864e0609290707t7e7d6e17g61a09ff5aa10ff3f@mail.gmail.com> References: <20060929134332.GD4776@rambler-co.ru> <20060929144738.W70454@fledge.watson.org> <2fd864e0609290707t7e7d6e17g61a09ff5aa10ff3f@mail.gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 29 Sep 2006 09:14:15 -0600 (MDT) Cc: rwatson@freebsd.org, current@freebsd.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 15:15:20 -0000 > For what its worth.... I'd go with just stopping support for -j in > installworld, even if things are CPU bound. installworld should *NEVER* be done -j. Ever. That wasn't part of the installworld bargin when it was started. There's no point to it at all. As such, any support to make it work should be removed with extreme prejustice. Why on earth would you want to do installworld -j? Warner From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 15:17:27 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FDBA16A415 for ; Fri, 29 Sep 2006 15:17:27 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BF1C43D6B for ; Fri, 29 Sep 2006 15:16:39 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so960367wxd for ; Fri, 29 Sep 2006 08:16:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=PTN6vdQOWDomrAUU4cOAYh2AyXF65TIdBsynFfrVRrd6o/kqA7eQpTnqgOlQQyCuDMbKbfS3Rz/kH+9gid7sr64RRQ6h8XqjTL93OschhZEXCiTQykfX3qKfzkjR0oxFN7iFKPAdJDfxzyAQ7NkyV9bTp9DKJ2j9gTmMZRrPf0c= Received: by 10.70.113.15 with SMTP id l15mr5297665wxc; Fri, 29 Sep 2006 08:16:39 -0700 (PDT) Received: by 10.70.118.3 with HTTP; Fri, 29 Sep 2006 08:16:39 -0700 (PDT) Message-ID: <2fd864e0609290816v7692e678vcca8ff89d24bbdac@mail.gmail.com> Date: Fri, 29 Sep 2006 10:16:39 -0500 From: Astrodog To: "Warner Losh" In-Reply-To: <20060929.091414.74722768.imp@bsdimp.com> MIME-Version: 1.0 References: <20060929134332.GD4776@rambler-co.ru> <20060929144738.W70454@fledge.watson.org> <2fd864e0609290707t7e7d6e17g61a09ff5aa10ff3f@mail.gmail.com> <20060929.091414.74722768.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: current@freebsd.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 15:17:27 -0000 On 9/29/06, Warner Losh wrote: > > > For what its worth.... I'd go with just stopping support for -j in > > installworld, even if things are CPU bound. > > installworld should *NEVER* be done -j. Ever. That wasn't part of > the installworld bargin when it was started. There's no point to it > at all. As such, any support to make it work should be removed with > extreme prejustice. Why on earth would you want to do installworld > -j? That's kinda my thought. --- Harrison From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 15:40:28 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D79916A40F; Fri, 29 Sep 2006 15:40:28 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2262143D58; Fri, 29 Sep 2006 15:40:18 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 114D660EB; Fri, 29 Sep 2006 19:40:17 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id AC82B5C92; Fri, 29 Sep 2006 19:37:42 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k8TFbiJF006337; Fri, 29 Sep 2006 19:37:44 +0400 (MSD) (envelope-from ru) Date: Fri, 29 Sep 2006 19:37:44 +0400 From: Ruslan Ermilov To: Robert Watson Message-ID: <20060929153744.GA6227@rambler-co.ru> References: <20060929141709.E70454@fledge.watson.org> <20060929134332.GD4776@rambler-co.ru> <20060929144738.W70454@fledge.watson.org> <20060929140802.GH4776@rambler-co.ru> <20060929151750.Y74256@fledge.watson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline In-Reply-To: <20060929151750.Y74256@fledge.watson.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: current@freebsd.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 15:40:28 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 29, 2006 at 03:19:50PM +0100, Robert Watson wrote: > On Fri, 29 Sep 2006, Ruslan Ermilov wrote: > >How could it support parallelism without using lockf(3) or equivalent? I= 'd=20 > >be happy to hack install-info(1) if there's a way. >=20 > Yes, that's why it's the basic problem. :-) The problem is the way info= =20 > works -- that it uses a shared file for a global table of contents, rathe= r=20 > than constructing it from a set of independent files once. Is there any= =20 > way to generate the entries in the directory incrementally in different= =20 > files, then combine them all at the end once? I.e., like we do with the= =20 > man page apropos database -- we build all the elements independently, whi= ch=20 > is parallelizable, and then once at the end once it's all done, we build= =20 > the single central database. >=20 Nothing immediate comes to my mind, but I'll think about it more. > >A middle-ground solution was easy to implement, and I have a patch for i= t=20 > >if a more clean solution couldn't be found. >=20 > I'd like to see that in the tree in the near future. If nothing else, it= =20 > will speed up installworld in the non-j case, probably measurably (althou= gh=20 > I've not measured it :-). >=20 OK, committed to HEAD as bsd.info.mk,v 1.74. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --8t9RHnE3ZwKMSgU+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFHT3IqRfpzJluFF4RAi2IAJwNfVBac/gyTgKKaw2i3XQWBxPCdgCfQfqE aQ4sZQfFGLj29hQKg86Tddo= =psGa -----END PGP SIGNATURE----- --8t9RHnE3ZwKMSgU+-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 15:56:08 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 323C816A40F; Fri, 29 Sep 2006 15:56:08 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 279CC43D76; Fri, 29 Sep 2006 15:56:06 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 2765845CDA; Fri, 29 Sep 2006 17:56:05 +0200 (CEST) Received: from localhost (dka128.neoplus.adsl.tpnet.pl [83.24.4.128]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 8502C45B26; Fri, 29 Sep 2006 17:55:59 +0200 (CEST) Date: Fri, 29 Sep 2006 17:55:26 +0200 From: Pawel Jakub Dawidek To: Robert Watson Message-ID: <20060929155526.GA9194@garage.freebsd.pl> References: <20060929141709.E70454@fledge.watson.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <20060929141709.E70454@fledge.watson.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: ru@FreeBSD.org, current@FreeBSD.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 15:56:08 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 29, 2006 at 02:20:06PM +0100, Robert Watson wrote: > I've noticed an increasing intolerance in our tools for system install an= d maintenance to locking not being implemented over the past few years. I = no longer get working=20 > cron on boxes with neither rpc.lockd nor local locking enabled, for > example. [...] If you are refering to my change in which cron(8) started to use pidfile(3), then I'm sorry, but you're wrong. cron(8) from the very beginning was exiting when it had problems with creating a pidfile, please check function acquire_daemonlock() in: http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/cron/lib/misc.c?rev=3D1= =2E1&content-type=3Dtext/x-cvsweb-markup My pidfile(3) commit is here: http://lists.freebsd.org/pipermail/cvs-all/2005-August/132374.html Where I try to explain cron(8)'s behaviour. The way I prefer is to ignore errors other than EEXIST - you can check EXAMPLES section in the pidfile(3) manual page for more info. I just didn't wanted to change cron(8)'s original behaviour. I do agree, that this shouldn't be treated as critical error and I can change it if you like. --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --CE+1k2dSO48ffgeK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFFHUHuForvXbEpPzQRAptxAJwNKqMTFt6BdTBq0EHdO8ZLItZYVwCgxfQX HSA3kSX8MQ5HOvSaF9lPWeE= =qTCH -----END PGP SIGNATURE----- --CE+1k2dSO48ffgeK-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 16:18:06 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D559F16A412 for ; Fri, 29 Sep 2006 16:18:06 +0000 (UTC) (envelope-from vincent@xtra-net.org) Received: from ns1.xtra-net.be (ns1.xtra-net.be [195.162.200.90]) by mx1.FreeBSD.org (Postfix) with SMTP id 1537A43D70 for ; Fri, 29 Sep 2006 16:18:05 +0000 (GMT) (envelope-from vincent@xtra-net.org) Received: (qmail 32494 invoked from network); 29 Sep 2006 16:06:13 -0000 Received: from unknown (HELO sbepfkaa.srv.xtra-net.be) (172.16.66.66) by 0 with SMTP; 29 Sep 2006 16:06:13 -0000 Received: (qmail 5141 invoked from network); 29 Sep 2006 16:13:12 -0000 Received: from wbedllfs.intranet.xtra-net.be (HELO wbemfkaa.net.xtra-net.be) (172.16.66.1) by 0 with SMTP; 29 Sep 2006 16:13:12 -0000 From: Vincent Blondel To: current@freebsd.org Content-Type: text/plain Date: Fri, 29 Sep 2006 18:17:13 +0200 Message-Id: <1159546633.1883.4.camel@wbemfkaa.net.xtra-net.be> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Subject: linux flashplayer plugin status ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 16:18:06 -0000 Hello all, I am trying to install linux flash player plugin but I encounter this kind of error when compiling linuxpluginwrapper. root@wbemfkaa [/usr/ports/www/linuxpluginwrapper] $ make install ===> linuxpluginwrapper-20051113_5 doesn't support ELF symbol versioning, yet.. *** Error code 1 Stop in /usr/ports/www/linuxpluginwrapper. root@wbemfkaa [/usr/ports/www/linuxpluginwrapper] $ Can somebody give me the status for installing linux flashplayer plugin on freebsd-current system. I see lots of discussion on the net but no workaround to get it working. Thanks a lot for your help. Regards Vincent From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 16:22:22 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7769A16A40F; Fri, 29 Sep 2006 16:22:22 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE0C943D79; Fri, 29 Sep 2006 16:22:18 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id AD3C146CF0; Fri, 29 Sep 2006 12:22:09 -0400 (EDT) Date: Fri, 29 Sep 2006 17:22:09 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ruslan Ermilov In-Reply-To: <20060929153744.GA6227@rambler-co.ru> Message-ID: <20060929172051.O74256@fledge.watson.org> References: <20060929141709.E70454@fledge.watson.org> <20060929134332.GD4776@rambler-co.ru> <20060929144738.W70454@fledge.watson.org> <20060929140802.GH4776@rambler-co.ru> <20060929151750.Y74256@fledge.watson.org> <20060929153744.GA6227@rambler-co.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 16:22:22 -0000 On Fri, 29 Sep 2006, Ruslan Ermilov wrote: >>> A middle-ground solution was easy to implement, and I have a patch for it >>> if a more clean solution couldn't be found. >> >> I'd like to see that in the tree in the near future. If nothing else, it >> will speed up installworld in the non-j case, probably measurably (although >> I've not measured it :-). >> > OK, committed to HEAD as bsd.info.mk,v 1.74. Thanks greatly. I don't mean to disallow -j in the long term, but I do need installworld to work in the short term. :-) I guess I'll just reiterate, for the sake of rhetorical noise, that the problem appears to be the very concept of the info directory file, which is the one bit of the info install that can't be parallelized. If we can find a way to generate that directory in a single step, as with man page indexing, then that should fix the problem. Thanks again, Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 16:24:23 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACB2916A40F; Fri, 29 Sep 2006 16:24:23 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60C3D43D73; Fri, 29 Sep 2006 16:24:23 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 744BB46CAE; Fri, 29 Sep 2006 12:24:22 -0400 (EDT) Date: Fri, 29 Sep 2006 17:24:22 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Pawel Jakub Dawidek In-Reply-To: <20060929155526.GA9194@garage.freebsd.pl> Message-ID: <20060929172321.R74256@fledge.watson.org> References: <20060929141709.E70454@fledge.watson.org> <20060929155526.GA9194@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: ru@FreeBSD.org, current@FreeBSD.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 16:24:23 -0000 On Fri, 29 Sep 2006, Pawel Jakub Dawidek wrote: > On Fri, Sep 29, 2006 at 02:20:06PM +0100, Robert Watson wrote: >> I've noticed an increasing intolerance in our tools for system install and maintenance to locking not being implemented over the past few years. I no longer get working >> cron on boxes with neither rpc.lockd nor local locking enabled, for >> example. [...] > > If you are refering to my change in which cron(8) started to use pidfile(3), > then I'm sorry, but you're wrong. > > cron(8) from the very beginning was exiting when it had problems with > creating a pidfile, please check function acquire_daemonlock() in: Cron may have been a poor example, I picked it from the top of a list of a half dozen failed services, many of which used not to fail. Sorry about that. > The way I prefer is to ignore errors other than EEXIST - you can check > EXAMPLES section in the pidfile(3) manual page for more info. I just didn't > wanted to change cron(8)'s original behaviour. > > I do agree, that this shouldn't be treated as critical error and I can > change it if you like. I think if we get back EOPNOTSUPP from lock attempts in libpidfile, we should ignore it and hope for the best. In an ideal world, we wouldn't do this, but in an ideal world we also wouldn't need to. :-) Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 16:28:02 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5CE5B16A412 for ; Fri, 29 Sep 2006 16:28:02 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id D66D943D5A for ; Fri, 29 Sep 2006 16:28:01 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 57F0746CAE; Fri, 29 Sep 2006 12:27:47 -0400 (EDT) Date: Fri, 29 Sep 2006 17:27:47 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Warner Losh In-Reply-To: <20060929.091414.74722768.imp@bsdimp.com> Message-ID: <20060929172657.Q74256@fledge.watson.org> References: <20060929134332.GD4776@rambler-co.ru> <20060929144738.W70454@fledge.watson.org> <2fd864e0609290707t7e7d6e17g61a09ff5aa10ff3f@mail.gmail.com> <20060929.091414.74722768.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: astrodog@gmail.com, current@freebsd.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 16:28:02 -0000 On Fri, 29 Sep 2006, Warner Losh wrote: >> For what its worth.... I'd go with just stopping support for -j in >> installworld, even if things are CPU bound. > > installworld should *NEVER* be done -j. Ever. That wasn't part of the > installworld bargin when it was started. There's no point to it at all. > As such, any support to make it work should be removed with extreme > prejustice. Why on earth would you want to do installworld -j? I wouldn't doubt that it's at least marginally faster, possibly a bit faster, but I think I come down pretty firmly on the side of "let's make installworld as simple and reliable as possible" -- breaking in the middle of installworld can have messy consequences, and we should minimize the chances of that as much as possible. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 16:46:58 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 40E5516A4AB for ; Fri, 29 Sep 2006 16:46:58 +0000 (UTC) (envelope-from a.pirko@inode.at) Received: from mx.inode.at (lb01nat10.inode.at [62.99.145.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4034943D4C for ; Fri, 29 Sep 2006 16:35:30 +0000 (GMT) (envelope-from a.pirko@inode.at) Received: from [85.124.24.122] (port=10242 helo=[192.168.1.11]) by smartmx-10.inode.at with esmtp (Exim 4.50) id 1GTLKi-00023y-Vo; Fri, 29 Sep 2006 18:35:29 +0200 Message-ID: <451D4B4A.7090602@inode.at> Date: Fri, 29 Sep 2006 18:35:22 +0200 From: Armin Pirkovitsch User-Agent: Thunderbird 1.5.0.7 (X11/20060916) MIME-Version: 1.0 To: Vincent Blondel References: <1159546633.1883.4.camel@wbemfkaa.net.xtra-net.be> In-Reply-To: <1159546633.1883.4.camel@wbemfkaa.net.xtra-net.be> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: linux flashplayer plugin status ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 16:46:58 -0000 Vincent Blondel wrote: > Hello all, > > I am trying to install linux flash player plugin but I encounter this > kind of error when compiling linuxpluginwrapper. > > root@wbemfkaa [/usr/ports/www/linuxpluginwrapper] $ make install > ===> linuxpluginwrapper-20051113_5 doesn't support ELF symbol > versioning, yet.. > *** Error code 1 > > Stop in /usr/ports/www/linuxpluginwrapper. > root@wbemfkaa [/usr/ports/www/linuxpluginwrapper] $ > > Can somebody give me the status for installing linux flashplayer plugin > on freebsd-current system. > > I see lots of discussion on the net but no workaround to get it working. well the only workaround is imho to install a linux-binary browser and use the plugin there... -- Armin Pirkovitsch a.pirko@inode.at From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 16:54:05 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AFE7416A4E9; Fri, 29 Sep 2006 16:54:05 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 096934407C; Fri, 29 Sep 2006 16:41:16 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([165.236.175.187]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k8TGJQVQ031227; Fri, 29 Sep 2006 10:19:32 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <451D4787.4050309@samsco.org> Date: Fri, 29 Sep 2006 10:19:19 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <451ADC21.50206@centtech.com> <451AE27F.3010506@samsco.org> <200609271727.29775.jhb@freebsd.org> In-Reply-To: <200609271727.29775.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: freebsd-current@freebsd.org Subject: Re: isofs/cd9660 -> relocate to fs/isofs/cd9660? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 16:54:05 -0000 John Baldwin wrote: > On Wednesday 27 September 2006 16:43, Scott Long wrote: > >>Eric Anderson wrote: >> >>>I noticed that cd9660 file system is in sys/isofs/cd9660 instead of what >>>seems more logical: sys/fs/cd9660. Is there any reason not to move it? >>> Curious mostly.. >>> >>>Eric >>> >>> >> >>Inertia, mostly. And if you move cd9660, do you also move ufs? Let the >>bi-yearly debate begin..... >> >>Btw, this is a topic that is easily searched on, as it gets brought up >>fairly regularly. We were a bit late on the schedule this time, though, >>so thanks for giving it a kickstart. > > > We've actually moved most of the filesystems into sys/fs in the past. Only > cd9660, nfs, and ufs are in the top-level. I'd still say leave nfs and ufs > alone, but sys/isofs/cd9660 -> sys/fs/cd9660 (I wouldn't keep the extra isofs > directory) probably wouldn't be but so painful at this point. > What about moving all of the net* directories into /sys/net?. And don't forget putting i386 and friends into /sys/arch! Ah, I love the smell of fresh paint in the morning. Smells like.... napalm. Scott From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 17:12:16 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7297516A40F; Fri, 29 Sep 2006 17:12:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7038B43D73; Fri, 29 Sep 2006 17:12:05 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.13.4/8.13.4) with ESMTP id k8THAbwH028380; Fri, 29 Sep 2006 11:10:37 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 29 Sep 2006 11:09:42 -0600 (MDT) Message-Id: <20060929.110942.1723237142.imp@bsdimp.com> To: rwatson@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20060929172657.Q74256@fledge.watson.org> References: <2fd864e0609290707t7e7d6e17g61a09ff5aa10ff3f@mail.gmail.com> <20060929.091414.74722768.imp@bsdimp.com> <20060929172657.Q74256@fledge.watson.org> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Fri, 29 Sep 2006 11:10:38 -0600 (MDT) Cc: astrodog@gmail.com, current@FreeBSD.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 17:12:16 -0000 In message: <20060929172657.Q74256@fledge.watson.org> Robert Watson writes: : : On Fri, 29 Sep 2006, Warner Losh wrote: : : >> For what its worth.... I'd go with just stopping support for -j in : >> installworld, even if things are CPU bound. : > : > installworld should *NEVER* be done -j. Ever. That wasn't part of the : > installworld bargin when it was started. There's no point to it at all. : > As such, any support to make it work should be removed with extreme : > prejustice. Why on earth would you want to do installworld -j? : : I wouldn't doubt that it's at least marginally faster, possibly a : bit faster, but I think I come down pretty firmly on the side of : "let's make installworld as simple and reliable as possible" -- : breaking in the middle of installworld can have messy consequences, : and we should minimize the chances of that as much as possible. I tend to agree with that basic philosophy. From other items in the thread, it was clear this came up in the context of build release, which benefits from -j usually. The installworld phase in that should be as robust as possible as well, since otherwise we have issues with the actual release. Unless it is a big win (more than a few percent), I'd imagine the right fix is to the release target to not do a parallel installworld. I know that in the build scripts that I wrote in 3.x days and have ported forward since then I've never done a parallel install, due to it rarely working reliably in that (long) time span... Warner From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 17:18:50 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1683E16A49E for ; Fri, 29 Sep 2006 17:18:50 +0000 (UTC) (envelope-from vincent@xtra-net.org) Received: from ns1.xtra-net.be (ns1.xtra-net.be [195.162.200.90]) by mx1.FreeBSD.org (Postfix) with SMTP id 42A8443D78 for ; Fri, 29 Sep 2006 17:18:49 +0000 (GMT) (envelope-from vincent@xtra-net.org) Received: (qmail 32458 invoked from network); 29 Sep 2006 17:06:56 -0000 Received: from unknown (HELO sbepfkaa.srv.xtra-net.be) (172.16.66.66) by 0 with SMTP; 29 Sep 2006 17:06:56 -0000 Received: (qmail 6325 invoked from network); 29 Sep 2006 17:13:55 -0000 Received: from wbedllfs.intranet.xtra-net.be (HELO wbemfkaa.net.xtra-net.be) (172.16.66.1) by 0 with SMTP; 29 Sep 2006 17:13:55 -0000 From: Vincent Blondel To: current@freebsd.org In-Reply-To: <451D4B4A.7090602@inode.at> References: <1159546633.1883.4.camel@wbemfkaa.net.xtra-net.be> <451D4B4A.7090602@inode.at> Content-Type: text/plain Date: Fri, 29 Sep 2006 19:17:57 +0200 Message-Id: <1159550277.1883.6.camel@wbemfkaa.net.xtra-net.be> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Subject: Re: linux flashplayer plugin status ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 17:18:50 -0000 waiting another solution, I will use netscape for sites using flash technologies. thanks :-) On Fri, 2006-09-29 at 18:35 +0200, Armin Pirkovitsch wrote: > Vincent Blondel wrote: > > Hello all, > > > > I am trying to install linux flash player plugin but I encounter this > > kind of error when compiling linuxpluginwrapper. > > > > root@wbemfkaa [/usr/ports/www/linuxpluginwrapper] $ make install > > ===> linuxpluginwrapper-20051113_5 doesn't support ELF symbol > > versioning, yet.. > > *** Error code 1 > > > > Stop in /usr/ports/www/linuxpluginwrapper. > > root@wbemfkaa [/usr/ports/www/linuxpluginwrapper] $ > > > > Can somebody give me the status for installing linux flashplayer plugin > > on freebsd-current system. > > > > I see lots of discussion on the net but no workaround to get it working. > > well the only workaround is imho to install a linux-binary browser and > use the plugin there... > From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 17:26:54 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8333916A47C for ; Fri, 29 Sep 2006 17:26:54 +0000 (UTC) (envelope-from absorbb@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id D83CC43D6E for ; Fri, 29 Sep 2006 17:26:50 +0000 (GMT) (envelope-from absorbb@gmail.com) Received: by nf-out-0910.google.com with SMTP id n29so1072415nfc for ; Fri, 29 Sep 2006 10:26:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=dyq+7/DoCUWoeAydIj6Muwin7gqe+Ng8FDfQe0P43XZRnMsA7IEEoQrCR0WKEelKmjJJLoYwhAwzxG9zcHp+JDS1BwugxhB4dxr54yp6/9tHrO7z5jaskGyCGp1GZg75qEf3RRX89rrUze82WDuyJmWTEFVEVK8IUQZiRb9B4Eg= Received: by 10.78.201.8 with SMTP id y8mr2596129huf; Fri, 29 Sep 2006 10:26:49 -0700 (PDT) Received: from localhost ( [195.91.168.1]) by mx.gmail.com with ESMTP id 2sm2564891hue.2006.09.29.10.26.48; Fri, 29 Sep 2006 10:26:49 -0700 (PDT) From: =?koi8-r?b?6czYxMHSIO7V0snTzMHNz9c=?= To: freebsd-current@freebsd.org Date: Fri, 29 Sep 2006 21:26:17 +0400 User-Agent: KMail/1.9.4 References: <1159546633.1883.4.camel@wbemfkaa.net.xtra-net.be> <451D4B4A.7090602@inode.at> <1159550277.1883.6.camel@wbemfkaa.net.xtra-net.be> In-Reply-To: <1159550277.1883.6.camel@wbemfkaa.net.xtra-net.be> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609292126.17694.absorbb@gmail.com> Subject: Re: linux flashplayer plugin status ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 17:26:54 -0000 There is patch (tested on 6.1. May require little changes for 6.2) apply it and then do "make install clean" in "/usr/src/libexec" : --- libexec/rtld-elf/rtld.c.orig Fri Sep 24 08:04:52 2004 +++ libexec/rtld-elf/rtld.c Sun Oct 17 03:37:44 2004 @@ -129,6 +129,7 @@ static void unref_dag(Obj_Entry *); static void ref_dag(Obj_Entry *); +void *_dlsym(void *, const char *); void r_debug_state(struct r_debug*, struct link_map*); /* @@ -177,6 +178,7 @@ (func_ptr_type) &dlclose, (func_ptr_type) &dlerror, (func_ptr_type) &dlopen, + (func_ptr_type) &_dlsym, (func_ptr_type) &dlsym, (func_ptr_type) &dladdr, (func_ptr_type) &dllockinit, @@ -1736,6 +1738,12 @@ trace_loaded_objects(obj); wlock_release(rtld_bind_lock, lockstate); exit(0); +} + +void * +_dlsym(void *handle, const char *name) +{ + return dlsym(handle, name); } void * > waiting another solution, I will use netscape for sites using flash > technologies. > > thanks :-) > > On Fri, 2006-09-29 at 18:35 +0200, Armin Pirkovitsch wrote: > > Vincent Blondel wrote: > > > Hello all, > > > > > > I am trying to install linux flash player plugin but I encounter this > > > kind of error when compiling linuxpluginwrapper. > > > > > > root@wbemfkaa [/usr/ports/www/linuxpluginwrapper] $ make install > > > ===> linuxpluginwrapper-20051113_5 doesn't support ELF symbol > > > versioning, yet.. > > > *** Error code 1 > > > > > > Stop in /usr/ports/www/linuxpluginwrapper. > > > root@wbemfkaa [/usr/ports/www/linuxpluginwrapper] $ > > > > > > Can somebody give me the status for installing linux flashplayer plugin > > > on freebsd-current system. > > > > > > I see lots of discussion on the net but no workaround to get it > > > working. > > > > well the only workaround is imho to install a linux-binary browser and > > use the plugin there... > > _______________________________________________ > 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 Sep 29 17:30:26 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C6F116A5C1; Fri, 29 Sep 2006 17:30:26 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D47F43D6B; Fri, 29 Sep 2006 17:30:18 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 29 Sep 2006 10:30:18 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8THUIYr000491; Fri, 29 Sep 2006 10:30:18 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8THUHQX018464; Fri, 29 Sep 2006 10:30:17 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Sep 2006 10:30:17 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 10:30:16 -0700 Message-ID: <451D5801.8030504@cisco.com> Date: Fri, 29 Sep 2006 13:29:37 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Lei , Michael Tuexen Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2006 17:30:16.0676 (UTC) FILETIME=[EDB92A40:01C6E3EC] DKIM-Signature: a=rsa-sha1; q=dns; l=5220; t=1159551018; x=1160415018; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Some=20interesting=20plots; X=v=3Dcisco.com=3B=20h=3DiSgebo/BaR1EeNZmJoamL6mtx20=3D; b=fMT0u4OYvChim9cv9tl+b0sRZ34FOdguB5Vty9fkWzJylBkOW+pz9Or1mxpWXA1ofy5INPEr YB2Qs9SwvI59p3cqpcoFzW6VfdY8DDff78MgRWD+Y0StGNTrjLMzLqZD; Authentication-Results: sj-dkim-4.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: "George V. Neville-Neil" , freebsd-current@freebsd.org, Robert Watson Subject: Some interesting plots X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 17:30:26 -0000 All: As you all may know I have been working on getting SCTP into Current.. I have been, of late, trying to tweak things to get the BEST performance out of the implementation... I have moved my testing off between two 7.0 machines.. same code base on each updated Sep 25. One is a 2.8Gig Dell SC1600 Xeon.. (hyper threaded CPU). The other is a P4D (2.8Gig .. slightly faster, true dual processor machine). They are connected by two intel EM server cards like so: +----+ +----+ 1 | em1 <---------------------> em0 | 2 | em0 <-----locallan--------> msk0| | dc0 <-Direct Inet | +----+ +-----+ em1 has 10.1.2.12 em0 10.1.2.21 em0 has 10.1.1.12 msk0 10.1.1.21 Now I setup the association with a server on 1, the conversation goes something like this: gettimeofday() <---------------Send me N bytes in X byte records---- ------>send----> ------>send----> when N bytes are recieved gettimeofday()/close() ... close() calculate and announce b/w Now the SCTP implemenation has some interesting logging things that allow me to turn on various compile options that log into a 80,000 entry memory buffer that you can pull with specific commands. I have rigged the sender to log each sack in and tell on the sender side (1): a) How much data is queued to the peer b) Total flight size c) rwnd advertised d) the calulated rwnd. On the receiver side (2) on both exit and entry to the receiving function in the kernel: On entry: a) read request size (uio_resid) b) amount in queue on the sb to read c) if blocking is allowed d) How much has to be read total to get a window update sack out On exit: a) how much has been read since the last sack sent b) how much is left un-read c) the rwnd we are advertising d) how much is still on the sb. ------------------------------------------------------------ The logging is nicely light weight (as long as you don't roll the log). This is because I use some atomic functions to move forward so I have picked a size that won't roll it... I have then played a bit with GNU plot to generate some graphs of all this... fun fun ;-D Now I have placed the plots at: http://www.sctp.org/plots.tar.bz2 (they are about 2Meg.. and I have a 512k up link .. so patience is a must). So what will you see.. plots that say *plotall.ps give you the entire transfer. ones that say plot*.ps show everything: a) When things are read in red y axis is size unread b) what the sender has in flight in green c) what the a-rwnd is in blue d) send-q size in pink. There is always a plot for each 100ms so you can "zoom" in on things... Especially 1.4-1.5 seconds look interesting.. Now plots that have cntplot* Show a) flight b) arwnd c) outq and d) number of sacks every 400us (multiplied by 1000 so if you had 10 sacks in a 400us period you would show it at 40000). This too is interesting. Finally plots that have lcntplot* show only the flight size vs the number of sack's every 500us (multiplied by 1000)... The interesting thing that I have going on is: 1) The sender is running dry.. you can see this in the graphs when the flight crashes down to almost nothing at say 1.5 seconds or so... also seen whenever the blue line moves down to the green flight.. 2) Any time the send queue (blue line) is at the flight (green) this is bad since it means we have the danger of running dry. 3) The reader is completely keeping up... since it reads constantly and never has much of a sb_cc (the red line stays on the bottom of the page). Now whats strange about this is that I am only getting 760Megbits per second (or so).. and in that 760Mb I see processor <1> about running 60-70% idle.. and processor <2> running 70-80% idle. Now I am most puzzeled on how to make this run faster... a) what causes the spikes (ideas would be welcome) b) why can't I get more CPU.. I have seperate locks that the receiver and the sender use to make it so there is minimal contention between the network side of things and the queuing and or reading... In fact I just added the sender seperate lock in the last day or so.. This is because I was seeing not 2 or so but 8 dips before I did that in the "queue" One other note, I see TCP is only getting 250Meg or so on the same test (It can run either).. now it used to get close to the full pipe (Gigbit).. so is there some issue with the new code that was recently submitted? Have a look.. its interesting.. I am rather clueless though on how to grab that CPU that top tells me is there (if its accurate :-D) suggestions on where to look or tuning I could do would be welcome. Thanks R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 17:57:32 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5142F16A501 for ; Fri, 29 Sep 2006 17:57:32 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6232E43D5A for ; Fri, 29 Sep 2006 17:57:25 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 95749 invoked from network); 29 Sep 2006 17:58:37 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Sep 2006 17:58:37 -0000 Message-ID: <451D5E84.5060009@freebsd.org> Date: Fri, 29 Sep 2006 19:57:24 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Randall Stewart References: <451D5801.8030504@cisco.com> In-Reply-To: <451D5801.8030504@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Peter Lei , Michael Tuexen , Robert Watson , "George V. Neville-Neil" , freebsd-current@freebsd.org Subject: Re: Some interesting plots X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 17:57:32 -0000 Randall Stewart wrote: > All: > > As you all may know I have been working on getting SCTP > into Current.. > > I have been, of late, trying to tweak things to get > the BEST performance out of the implementation... Randall, get the code correct first, check. Then second get it into the tree. Third make it fast. Once it is in the tree we can work out kinks much easier. Testing gets easier too. I've got a lot of experience with socket buffer performance and interactions now and can help as soon as it is in the tree. It's just not necessary to have it absolutely perfect when it goes into the tree. FreeBSD-current has another 8 month to shake things out. -- Andre > I have moved my testing off between two 7.0 machines.. same > code base on each updated Sep 25. > > One is a 2.8Gig Dell SC1600 Xeon.. (hyper threaded CPU). > The other is a P4D (2.8Gig .. slightly faster, true dual > processor machine). > > They are connected by two intel EM server cards like so: > > > +----+ +----+ > 1 | em1 <---------------------> em0 | 2 > | em0 <-----locallan--------> msk0| > | dc0 <-Direct Inet | > +----+ +-----+ > > > em1 has 10.1.2.12 em0 10.1.2.21 > em0 has 10.1.1.12 msk0 10.1.1.21 > > > Now I setup the association with a server on 1, the > conversation goes something like this: > > gettimeofday() > <---------------Send me N bytes in X byte records---- > ------>send----> > ------>send----> when N bytes are recieved > gettimeofday()/close() > ... > close() > calculate and announce b/w > > Now the SCTP implemenation has some interesting logging things that > allow me to turn on various compile options that log into a 80,000 entry > memory buffer that you can pull with specific commands. > > I have rigged the sender to log each sack in and tell > on the sender side (1): > > a) How much data is queued to the peer > b) Total flight size > c) rwnd advertised > d) the calulated rwnd. > > On the receiver side (2) on both exit and entry > to the receiving function in the kernel: > On entry: > a) read request size (uio_resid) > b) amount in queue on the sb to read > c) if blocking is allowed > d) How much has to be read total to get a window > update sack out > On exit: > a) how much has been read since the last sack sent > b) how much is left un-read > c) the rwnd we are advertising > d) how much is still on the sb. > > ------------------------------------------------------------ > > The logging is nicely light weight (as long as you don't roll the > log). This is because I use some atomic functions to move forward > so I have picked a size that won't roll it... > > I have then played a bit with GNU plot to generate some > graphs of all this... fun fun ;-D > > Now I have placed the plots at: > > http://www.sctp.org/plots.tar.bz2 > > (they are about 2Meg.. and I have a 512k up link .. so patience is > a must). > > So what will you see.. > > plots that say *plotall.ps give you the entire transfer. > > ones that say > > plot*.ps show everything: > > a) When things are read in red y axis is size unread > b) what the sender has in flight in green > c) what the a-rwnd is in blue > d) send-q size in pink. > > There is always a plot for each 100ms so you > can "zoom" in on things... > Especially 1.4-1.5 seconds look interesting.. > > Now plots that have > cntplot* > > Show > > a) flight > b) arwnd > c) outq > and > d) number of sacks every 400us (multiplied by 1000 so > if you had 10 sacks in a 400us period you would show > it at 40000). > > This too is interesting. > > Finally plots that have lcntplot* > show only the flight size vs > the number of sack's every 500us (multiplied > by 1000)... > > The interesting thing that I have going on is: > > 1) The sender is running dry.. you can see this in the graphs > when the flight crashes down to almost nothing at say > 1.5 seconds or so... also seen whenever the blue line > moves down to the green flight.. > > 2) Any time the send queue (blue line) is at the flight (green) > this is bad since it means we have the danger of running dry. > > 3) The reader is completely keeping up... since it > reads constantly and never has much of a sb_cc (the > red line stays on the bottom of the page). > > Now whats strange about this is that I am only getting 760Megbits per > second (or so).. and in that 760Mb I see processor <1> about running > 60-70% idle.. and processor <2> running 70-80% idle. > > Now I am most puzzeled on how to make this run faster... > > a) what causes the spikes (ideas would be welcome) > b) why can't I get more CPU.. I have seperate locks that > the receiver and the sender use to make it so there is > minimal contention between the network side of things and > the queuing and or reading... In fact I just added the sender > seperate lock in the last day or so.. This is because > I was seeing not 2 or so but 8 dips before I did that in > the "queue" > > One other note, I see TCP is only getting 250Meg or so on the > same test (It can run either).. now it used to get close to > the full pipe (Gigbit).. so is there some issue with the new code > that was recently submitted? > > Have a look.. its interesting.. I am rather clueless > though on how to grab that CPU that top tells me is > there (if its accurate :-D) suggestions on where to look > or tuning I could do would be welcome. > > Thanks > > > R From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 18:20:53 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF0A016A492; Fri, 29 Sep 2006 18:20:53 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C96143D45; Fri, 29 Sep 2006 18:20:53 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 74612615C; Fri, 29 Sep 2006 22:20:52 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 523386119; Fri, 29 Sep 2006 22:20:52 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k8TIKrsR038019; Fri, 29 Sep 2006 22:20:53 +0400 (MSD) (envelope-from ru) Date: Fri, 29 Sep 2006 22:20:53 +0400 From: Ruslan Ermilov To: "M. Warner Losh" Message-ID: <20060929182053.GG37741@rambler-co.ru> References: <2fd864e0609290707t7e7d6e17g61a09ff5aa10ff3f@mail.gmail.com> <20060929.091414.74722768.imp@bsdimp.com> <20060929172657.Q74256@fledge.watson.org> <20060929.110942.1723237142.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4eRLI4hEmsdu6Npr" Content-Disposition: inline In-Reply-To: <20060929.110942.1723237142.imp@bsdimp.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: astrodog@gmail.com, rwatson@FreeBSD.org, current@FreeBSD.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 18:20:54 -0000 --4eRLI4hEmsdu6Npr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 29, 2006 at 11:09:42AM -0600, M. Warner Losh wrote: [...] > I tend to agree with that basic philosophy. From other items in the > thread, it was clear this came up in the context of build release, > which benefits from -j usually. The installworld phase in that should > be as robust as possible as well, since otherwise we have issues with > the actual release. Unless it is a big win (more than a few percent), > I'd imagine the right fix is to the release target to not do a > parallel installworld. I know that in the build scripts that I wrote > in 3.x days and have ported forward since then I've never done a > parallel install, due to it rarely working reliably in that (long) > time span... >=20 They are safe to do nowadays. I'll do some measurements on real SMP with the memory-based DESTDIR, and let you know the numbers. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --4eRLI4hEmsdu6Npr Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFHWQFqRfpzJluFF4RAjGJAJ4jmTPgYHLumVVSkoHI383OojOuPgCfYV+T cQbla159aPWj/k554MxrDyg= =LMLo -----END PGP SIGNATURE----- --4eRLI4hEmsdu6Npr-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 19:05:00 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F06C416A415 for ; Fri, 29 Sep 2006 19:04:59 +0000 (UTC) (envelope-from astrodog@gmail.com) Received: from wx-out-0506.google.com (wx-out-0506.google.com [66.249.82.234]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E48D43D5C for ; Fri, 29 Sep 2006 19:04:56 +0000 (GMT) (envelope-from astrodog@gmail.com) Received: by wx-out-0506.google.com with SMTP id i27so1020120wxd for ; Fri, 29 Sep 2006 12:04:55 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Btfm6VpTwieroPXITOUykCwsyV+jyN5zriJEs9OF4fRZ92D779YtBiYG4LRh9I8XINHnLQWrHww9SzW/9PWSKadoe/qQJFkwVG93LiFVrOaK5bNHqvZkA/M66aESlW73T8Fx37wkH3TPq2XTo+4I9OdcVegyTRz4Lb/g5NLzCJw= Received: by 10.70.67.4 with SMTP id p4mr3065964wxa; Fri, 29 Sep 2006 12:04:55 -0700 (PDT) Received: by 10.70.118.3 with HTTP; Fri, 29 Sep 2006 12:04:55 -0700 (PDT) Message-ID: <2fd864e0609291204gf8209e0i5b7975af7b780623@mail.gmail.com> Date: Fri, 29 Sep 2006 14:04:55 -0500 From: Astrodog To: "Ruslan Ermilov" In-Reply-To: <20060929182053.GG37741@rambler-co.ru> MIME-Version: 1.0 References: <2fd864e0609290707t7e7d6e17g61a09ff5aa10ff3f@mail.gmail.com> <20060929.091414.74722768.imp@bsdimp.com> <20060929172657.Q74256@fledge.watson.org> <20060929.110942.1723237142.imp@bsdimp.com> <20060929182053.GG37741@rambler-co.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: rwatson@freebsd.org, current@freebsd.org, "M. Warner Losh" Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 19:05:00 -0000 On 9/29/06, Ruslan Ermilov wrote: > > On Fri, Sep 29, 2006 at 11:09:42AM -0600, M. Warner Losh wrote: > [...] > > I tend to agree with that basic philosophy. From other items in the > > thread, it was clear this came up in the context of build release, > > which benefits from -j usually. The installworld phase in that should > > be as robust as possible as well, since otherwise we have issues with > > the actual release. Unless it is a big win (more than a few percent), > > I'd imagine the right fix is to the release target to not do a > > parallel installworld. I know that in the build scripts that I wrote > > in 3.x days and have ported forward since then I've never done a > > parallel install, due to it rarely working reliably in that (long) > > time span... > > > They are safe to do nowadays. I'll do some measurements on real > SMP with the memory-based DESTDIR, and let you know the numbers. I'd be interested in non-memory-based DESTDIR, too, since there's certainly the possibility, for install, to slow things down with -j because of additional HDD seeks and such. Cheers, > -- > Ruslan Ermilov > ru@FreeBSD.org > FreeBSD committer > > > From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 19:10:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B49016A407; Fri, 29 Sep 2006 19:10:34 +0000 (UTC) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr2.xs4all.nl (smtp-vbr2.xs4all.nl [194.109.24.22]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E4AA43D46; Fri, 29 Sep 2006 19:10:30 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr2.xs4all.nl (8.13.8/8.13.8) with ESMTP id k8TJARX1078248; Fri, 29 Sep 2006 21:10:28 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.6/8.13.3) with ESMTP id k8TJARND008225; Fri, 29 Sep 2006 21:10:27 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.6/8.13.6/Submit) id k8TJAQbc008224; Fri, 29 Sep 2006 21:10:26 +0200 (CEST) (envelope-from wb) Date: Fri, 29 Sep 2006 21:10:26 +0200 From: Wilko Bulte To: Scott Long Message-ID: <20060929191026.GA8206@freebie.xs4all.nl> References: <451ADC21.50206@centtech.com> <451AE27F.3010506@samsco.org> <200609271727.29775.jhb@freebsd.org> <451D4787.4050309@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <451D4787.4050309@samsco.org> User-Agent: Mutt/1.5.11 X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-current@freebsd.org Subject: Re: isofs/cd9660 -> relocate to fs/isofs/cd9660? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 19:10:34 -0000 On Fri, Sep 29, 2006 at 10:19:19AM -0600, Scott Long wrote.. > John Baldwin wrote: > >On Wednesday 27 September 2006 16:43, Scott Long wrote: > > > >>Eric Anderson wrote: > >> > >>>I noticed that cd9660 file system is in sys/isofs/cd9660 instead of what > >>>seems more logical: sys/fs/cd9660. Is there any reason not to move it? > >>> Curious mostly.. > >>> > >>>Eric > >>> > >>> > >> > >>Inertia, mostly. And if you move cd9660, do you also move ufs? Let the > >>bi-yearly debate begin..... > >> > >>Btw, this is a topic that is easily searched on, as it gets brought up > >>fairly regularly. We were a bit late on the schedule this time, though, > >>so thanks for giving it a kickstart. > > > > > >We've actually moved most of the filesystems into sys/fs in the past. > >Only cd9660, nfs, and ufs are in the top-level. I'd still say leave nfs > >and ufs alone, but sys/isofs/cd9660 -> sys/fs/cd9660 (I wouldn't keep the > >extra isofs directory) probably wouldn't be but so painful at this point. > > > > What about moving all of the net* directories into /sys/net?. And > don't forget putting i386 and friends into /sys/arch! Ah, I love the > smell of fresh paint in the morning. Smells like.... napalm. Now where is that Wagner MP3 again.. ?? -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 20:04:13 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5DD4516A40F; Fri, 29 Sep 2006 20:04:13 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B64643D77; Fri, 29 Sep 2006 20:04:01 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Sep 2006 13:04:01 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TK400c001086; Fri, 29 Sep 2006 13:04:00 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8TK3x1O013127; Fri, 29 Sep 2006 13:04:00 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 13:03:56 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 13:03:56 -0700 Message-ID: <451D7C08.4050706@cisco.com> Date: Fri, 29 Sep 2006 16:03:20 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <451D5801.8030504@cisco.com> <451D5E84.5060009@freebsd.org> In-Reply-To: <451D5E84.5060009@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2006 20:03:56.0194 (UTC) FILETIME=[64FBF820:01C6E402] DKIM-Signature: a=rsa-sha1; q=dns; l=896; t=1159560240; x=1160424240; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20Some=20interesting=20plots; X=v=3Dcisco.com=3B=20h=3DoYssKf/8Gf1y2Bt8H+IL8Am5Wf4=3D; b=Uwuz4RyhyW0r44X0NPEu9f5LDMHNk3cyZ7kZImWK0VSxh5gzBm2sDnF5GxYVZ+LuVB9l6gOZ mPNYAPFMpJ21ct3s9rBJwKYa8jMCnHBdKWtW1QBXgA+1krOGvj8TzxAw; Authentication-Results: sj-dkim-2.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: Peter Lei , Michael Tuexen , Robert Watson , "George V. Neville-Neil" , freebsd-current@freebsd.org Subject: Re: Some interesting plots X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 20:04:13 -0000 Andre Oppermann wrote: > Randall Stewart wrote: > > Randall, > > get the code correct first, check. Then second get it into the > tree. Third make it fast. Once it is in the tree we can work > out kinks much easier. Testing gets easier too. I've got a lot > of experience with socket buffer performance and interactions > now and can help as soon as it is in the tree. Cool... we will be putting it in to the tree shortly.. George and I will meet in Tokyo shortly.. and figure out the commit plan :-D > > It's just not necessary to have it absolutely perfect when it > goes into the tree. FreeBSD-current has another 8 month to shake > things out. > Well to tell the truth the code is pretty solid.. except where I go off and re-write to make things faster :-) R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 20:18:48 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91F1716A40F; Fri, 29 Sep 2006 20:18:48 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C60B43D5A; Fri, 29 Sep 2006 20:18:47 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 29 Sep 2006 16:18:27 -0400 X-IronPort-AV: i="4.09,238,1157342400"; d="scan'208"; a="105057629:sNHT2265008588" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TKIQXu018491; Fri, 29 Sep 2006 16:18:26 -0400 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8TKIPQZ021919; Fri, 29 Sep 2006 13:18:26 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 13:18:25 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 13:18:24 -0700 Message-ID: <451D7F6C.60904@cisco.com> Date: Fri, 29 Sep 2006 16:17:48 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randall Stewart References: <451D5801.8030504@cisco.com> <451D5E84.5060009@freebsd.org> <451D7C08.4050706@cisco.com> In-Reply-To: <451D7C08.4050706@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2006 20:18:24.0704 (UTC) FILETIME=[6AA81400:01C6E404] DKIM-Signature: a=rsa-sha1; q=dns; l=267; t=1159561106; x=1160425106; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20Some=20interesting=20plots |To:Randall=20Stewart=20; X=v=3Dcisco.com=3B=20h=3DoYssKf/8Gf1y2Bt8H+IL8Am5Wf4=3D; b=i8AdJ/vgwincgJr2t0Brh08l/y6mrGVqvp7YiVg53wLEH/Vm8ztAMK+/PbbA+O6sGdkMtDP4 gGO+CrLG/WGmp7M9DwwqMFSjX2eX7aW0MiVLryZMaiCnP3u0n/9zkyGL; Authentication-Results: rtp-dkim-2.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: Andre Oppermann , "George V. Neville-Neil" , Michael Tuexen , Peter Lei , freebsd-current@freebsd.org, Robert Watson Subject: Re: Some interesting plots X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 20:18:48 -0000 Randall: At Brad's suggestion (which was a good one too ).. You can find the plots also at: http://people.freebsd.org/~rrs/ Which might be a bit faster :-) R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 20:56:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7E19516A412; Fri, 29 Sep 2006 20:56:25 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91F9043D4C; Fri, 29 Sep 2006 20:56:23 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 29 Sep 2006 13:56:20 -0700 X-IronPort-AV: i="4.09,238,1157353200"; d="scan'208"; a="326731250:sNHT1277491074" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TKuKjs005208; Fri, 29 Sep 2006 13:56:20 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k8TKuKif028081; Fri, 29 Sep 2006 13:56:20 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 13:56:19 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 13:56:19 -0700 Message-ID: <451D884F.1030807@cisco.com> Date: Fri, 29 Sep 2006 16:55:43 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Silbersack References: <451C4850.5030302@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2006 20:56:19.0284 (UTC) FILETIME=[B6697140:01C6E409] DKIM-Signature: a=rsa-sha1; q=dns; l=1339; t=1159563380; x=1160427380; c=relaxed/relaxed; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20Much=20improved=20sosend_*()=20functions; X=v=3Dcisco.com=3B=20h=3DVUE9hWftOvPULvUJ9EhsWe/RDnk=3D; b=aBOdPqw/QULXevX7mWrz3kp1PRqkab5wHl0lALAfMFK5I6ttMWMfmqf9i5/cTmAWym5u0BJQ NpyNNks9qZ7sqJ3+0e/88PgaRxr/8H5K3IoEIo49tUgF/AWc/ZdWMv+d; Authentication-Results: sj-dkim-8.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann , gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 20:56:25 -0000 Mike Silbersack wrote: > On Fri, 29 Sep 2006, Andre Oppermann wrote: > > >>over it an copies the data into the mbufs by using uiomove(). sosend_dgram() >>and sosend_generic() are change to use m_uiotombuf() instead of sosend_copyin(). > > > Can you do some UDP testing with 512b, 1K, 2K, 4K, 8K, and 16K packets to > see if performance changes there as well? Hmm.. I would think 512b and 1K will not show any improvement.. since they would probably end up either in an mbuf chain.. or a single 2k (or maybe 4k) cluster.. ... quite a waste.. now if we had 512b and 1k clusters that would be cool... In fact I have always thought we should: a) have no data portion in an mbuf.. just pointers i.e. always an EXT b) Have a 256/512 and 1k cluster too.. This would allow copy by reference no matter what size si being sent... But of course .. thats just me :-) R > > How about local sockets? > > Impressive improvements for TCP, in any case! > > Mike "Silby" Silbersack > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 21:08:08 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6E1516A553 for ; Fri, 29 Sep 2006 21:08:08 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37F5943D68 for ; Fri, 29 Sep 2006 21:08:03 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 97450 invoked from network); 29 Sep 2006 21:09:14 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Sep 2006 21:09:14 -0000 Message-ID: <451D8B32.9010204@freebsd.org> Date: Fri, 29 Sep 2006 23:08:02 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Randall Stewart References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> In-Reply-To: <451D884F.1030807@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Mike Silbersack , freebsd-current@freebsd.org, gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 21:08:09 -0000 Randall Stewart wrote: > Mike Silbersack wrote: >> On Fri, 29 Sep 2006, Andre Oppermann wrote: >> >> >>> over it an copies the data into the mbufs by using uiomove(). >>> sosend_dgram() >>> and sosend_generic() are change to use m_uiotombuf() instead of >>> sosend_copyin(). >> >> Can you do some UDP testing with 512b, 1K, 2K, 4K, 8K, and 16K packets to >> see if performance changes there as well? > > Hmm.. I would think 512b and 1K will not show any > improvement.. since they would probably end up either > in an mbuf chain.. or a single 2k (or maybe 4k) cluster.. > ... quite a waste.. now if we had 512b and 1k clusters that > would be cool... > > In fact I have always thought we should: > > a) have no data portion in an mbuf.. just pointers i.e. always > an EXT > > b) Have a 256/512 and 1k cluster too.. > > This would allow copy by reference no matter what size si > being sent... > > But of course .. thats just me :-) Well, people tell me to "profile, not speculate". So I'm doing it now with quite some success. Lets file your little rant here into the same category. ;-) -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 21:16:01 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78C1C16A47B for ; Fri, 29 Sep 2006 21:16:01 +0000 (UTC) (envelope-from silby@silby.com) Received: from niwun.pair.com (niwun.pair.com [209.68.2.70]) by mx1.FreeBSD.org (Postfix) with SMTP id 636F143D53 for ; Fri, 29 Sep 2006 21:16:00 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 24239 invoked by uid 3193); 29 Sep 2006 21:15:59 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 Sep 2006 21:15:59 -0000 Date: Fri, 29 Sep 2006 17:15:58 -0400 (EDT) From: Mike Silbersack X-X-Sender: silby@niwun.pair.com To: Randall Stewart In-Reply-To: <451D884F.1030807@cisco.com> Message-ID: References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann , gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 21:16:01 -0000 On Fri, 29 Sep 2006, Randall Stewart wrote: > Hmm.. I would think 512b and 1K will not show any > improvement.. since they would probably end up either > in an mbuf chain.. or a single 2k (or maybe 4k) cluster.. I know, I just want to make sure that it doesn't somehow cause performance loss for those cases! > In fact I have always thought we should: > > a) have no data portion in an mbuf.. just pointers i.e. always > an EXT > > b) Have a 256/512 and 1k cluster too.. Implement and benchmark it. :) Mike "Silby" Silbersack From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 21:24:31 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF88716A7BF for ; Fri, 29 Sep 2006 21:24:31 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id A01FB43D4C for ; Fri, 29 Sep 2006 21:24:30 +0000 (GMT) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.6/8.13.6) with ESMTP id k8TLOFdY018701; Fri, 29 Sep 2006 17:24:27 -0400 (EDT) (envelope-from jhb@freebsd.org) From: John Baldwin To: Scott Long Date: Fri, 29 Sep 2006 16:18:09 -0400 User-Agent: KMail/1.9.1 References: <451ADC21.50206@centtech.com> <200609271727.29775.jhb@freebsd.org> <451D4787.4050309@samsco.org> In-Reply-To: <451D4787.4050309@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200609291618.09492.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Fri, 29 Sep 2006 17:24:27 -0400 (EDT) X-Virus-Scanned: ClamAV 0.88.3/1950/Thu Sep 28 10:11:54 2006 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: freebsd-current@freebsd.org Subject: Re: isofs/cd9660 -> relocate to fs/isofs/cd9660? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 21:24:31 -0000 On Friday 29 September 2006 12:19, Scott Long wrote: > John Baldwin wrote: > > On Wednesday 27 September 2006 16:43, Scott Long wrote: > > > >>Eric Anderson wrote: > >> > >>>I noticed that cd9660 file system is in sys/isofs/cd9660 instead of what > >>>seems more logical: sys/fs/cd9660. Is there any reason not to move it? > >>> Curious mostly.. > >>> > >>>Eric > >>> > >>> > >> > >>Inertia, mostly. And if you move cd9660, do you also move ufs? Let the > >>bi-yearly debate begin..... > >> > >>Btw, this is a topic that is easily searched on, as it gets brought up > >>fairly regularly. We were a bit late on the schedule this time, though, > >>so thanks for giving it a kickstart. > > > > > > We've actually moved most of the filesystems into sys/fs in the past. Only > > cd9660, nfs, and ufs are in the top-level. I'd still say leave nfs and ufs > > alone, but sys/isofs/cd9660 -> sys/fs/cd9660 (I wouldn't keep the extra isofs > > directory) probably wouldn't be but so painful at this point. > > > > What about moving all of the net* directories into /sys/net?. And > don't forget putting i386 and friends into /sys/arch! Ah, I love the > smell of fresh paint in the morning. Smells like.... napalm. Baby steps aren't hard. :) Back when I first made rumblings about this sort of thing we didn't have a sys/fs at all, but now we do and over time we've actually moved most of our filesystems into it. :) -- John Baldwin From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 21:32:56 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C47A16A415; Fri, 29 Sep 2006 21:32:56 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0467943D49; Fri, 29 Sep 2006 21:32:55 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 29 Sep 2006 14:32:56 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TLWt85001369; Fri, 29 Sep 2006 14:32:55 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k8TLWtQV009745; Fri, 29 Sep 2006 14:32:55 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 14:32:12 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 14:32:12 -0700 Message-ID: <451D90B8.8060202@cisco.com> Date: Fri, 29 Sep 2006 17:31:36 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Silbersack References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2006 21:32:12.0168 (UTC) FILETIME=[B9A17880:01C6E40E] DKIM-Signature: a=rsa-sha1; q=dns; l=832; t=1159565575; x=1160429575; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20Much=20improved=20sosend_*()=20functions; X=v=3Dcisco.com=3B=20h=3DVUE9hWftOvPULvUJ9EhsWe/RDnk=3D; b=jp58XQpYoGSn/hrJFXGDH1pe/l6EJL4OU6kK99w3v2ZBi0gAaaXOU2LoL1sWkb6PQ5Xt72mR 1lzszthHQmaSuygZPWTNB/SNH77RYN4vLwFKA41CgMebFuBGDTqTYRdt; Authentication-Results: sj-dkim-3.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann , gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 21:32:56 -0000 Mike Silbersack wrote: > On Fri, 29 Sep 2006, Randall Stewart wrote: > > >>Hmm.. I would think 512b and 1K will not show any >>improvement.. since they would probably end up either >>in an mbuf chain.. or a single 2k (or maybe 4k) cluster.. > > > I know, I just want to make sure that it doesn't somehow cause performance > loss for those cases! > > >>In fact I have always thought we should: >> >>a) have no data portion in an mbuf.. just pointers i.e. always >> an EXT >> >>b) Have a 256/512 and 1k cluster too.. Hmm.. I could do that.. maybe I will when my plate clears off a bit.. but then again.. that may be never :-0 R > > > Implement and benchmark it. :) > > Mike "Silby" Silbersack > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 21:37:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3731016A407; Fri, 29 Sep 2006 21:37:46 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 080A643D64; Fri, 29 Sep 2006 21:37:41 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (dcv25qxoqk31iw4t@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k8TLbQ7L035392; Fri, 29 Sep 2006 14:37:26 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k8TLbNJM035391; Fri, 29 Sep 2006 14:37:23 -0700 (PDT) (envelope-from jmg) Date: Fri, 29 Sep 2006 14:37:22 -0700 From: John-Mark Gurney To: Randall Stewart Message-ID: <20060929213722.GR80527@funkthat.com> Mail-Followup-To: Randall Stewart , Mike Silbersack , freebsd-net@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann , gallatin@cs.duke.edu References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <451D884F.1030807@cisco.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-net@freebsd.org, Mike Silbersack , freebsd-current@freebsd.org, Andre Oppermann , gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2006 21:37:46 -0000 Randall Stewart wrote this message on Fri, Sep 29, 2006 at 16:55 -0400: > Mike Silbersack wrote: > >On Fri, 29 Sep 2006, Andre Oppermann wrote: > > > > > >>over it an copies the data into the mbufs by using uiomove(). > >>sosend_dgram() > >>and sosend_generic() are change to use m_uiotombuf() instead of > >>sosend_copyin(). > > > > > >Can you do some UDP testing with 512b, 1K, 2K, 4K, 8K, and 16K packets to > >see if performance changes there as well? > > Hmm.. I would think 512b and 1K will not show any > improvement.. since they would probably end up either > in an mbuf chain.. or a single 2k (or maybe 4k) cluster.. > ... quite a waste.. now if we had 512b and 1k clusters that > would be cool... > > In fact I have always thought we should: > > a) have no data portion in an mbuf.. just pointers i.e. always > an EXT > > b) Have a 256/512 and 1k cluster too.. > > This would allow copy by reference no matter what size si > being sent... IMO it's quite a waste of memory the way we have thigns now, though w/ TSO it'll change things... w/ 512 byte mbuf and a 2k cluster just to store just 1514 bytes of data, that's only 60% effeciency wrt to memory usage... so, we currently waste 40% of memory allocated to mbufs+clusters... Even reducing mbufs back to 128 or 256 would be a big help, though IPSEC I believe would have issues... Hmmm.. If we switched clusters to 1536 bytes in size, we'd be able to fit 8 in 12k (though I guess for 8k page boxes we'd do 16 in 24k)... The only issue w/ that would be that a few of the clusters would possibly split page boundaries... How much this would effect performance would be an interesting question to answer... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 21:43:20 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4B95716A416; Fri, 29 Sep 2006 21:43:20 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 109CD43D9A; Fri, 29 Sep 2006 21:42:59 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 24B645D66; Sat, 30 Sep 2006 01:42:58 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 042075C89; Sat, 30 Sep 2006 01:42:58 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k8TLgswH063000; Sat, 30 Sep 2006 01:42:54 +0400 (MSD) (envelope-from ru) Date: Sat, 30 Sep 2006 01:42:54 +0400 From: Ruslan Ermilov To: "M. Warner Losh" Message-ID: <20060929214254.GA62950@rambler-co.ru> References: <2fd864e0609290707t7e7d6e17g61a09ff5aa10ff3f@mail.gmail.com> <20060929.091414.74722768.imp@bsdimp.com> <20060929172657.Q74256@fledge.watson.org> <20060929.110942.1723237142.imp@bsdimp.com> <20060929182053.GG37741@rambler-co.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <20060929182053.GG37741@rambler-co.ru> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: astrodog@gmail.com, rwatson@FreeBSD.org, current@FreeBSD.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 21:43:20 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 29, 2006 at 10:20:53PM +0400, Ruslan Ermilov wrote: > On Fri, Sep 29, 2006 at 11:09:42AM -0600, M. Warner Losh wrote: > [...] > > I tend to agree with that basic philosophy. From other items in the > > thread, it was clear this came up in the context of build release, > > which benefits from -j usually. The installworld phase in that should > > be as robust as possible as well, since otherwise we have issues with > > the actual release. Unless it is a big win (more than a few percent), > > I'd imagine the right fix is to the release target to not do a > > parallel installworld. I know that in the build scripts that I wrote > > in 3.x days and have ported forward since then I've never done a > > parallel install, due to it rarely working reliably in that (long) > > time span... > >=20 > They are safe to do nowadays. I'll do some measurements on real > SMP with the memory-based DESTDIR, and let you know the numbers. >=20 The data (real time seconds) was taken on the following system: CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ (1995.01-MHz K8-class C= PU) real memory =3D 4227792896 (4031 MB) avail memory =3D 4081033216 (3891 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Basically, doing installworld -jX doesn't make any sense. : x installworld-B : + installworld-j1 : +------------------------------------------------------------------------= --+ : |xxx + + = +| : ||A| |_MA__= _|| : +------------------------------------------------------------------------= --+ : N Min Max Median Avg Stdd= ev : x 3 40.21 40.82 40.53 40.52 0.305122= 93 : + 3 56.72 58.45 57.26 57.476667 0.885117= 69 : Difference at 95.0% confidence : 16.9567 +/- 1.50052 : 41.8476% +/- 3.70317% : (Student's t, pooled s =3D 0.662017) : x installworld-B : + installworld-j2 : +------------------------------------------------------------------------= --+ : |xx x + + = +| : ||A_| |___AM__= _|| : +------------------------------------------------------------------------= --+ : N Min Max Median Avg Stdd= ev : x 3 40.21 40.82 40.53 40.52 0.305122= 93 : + 3 55.17 57.29 56.44 56.3 1.06691= 14 : Difference at 95.0% confidence : 15.78 +/- 1.77852 : 38.9437% +/- 4.38924% : (Student's t, pooled s =3D 0.784666) : x installworld-B : + installworld-j4 : +------------------------------------------------------------------------= --+ : |xxx + + = + | : ||A| |_____A_M__= _|| : +------------------------------------------------------------------------= --+ : N Min Max Median Avg Stdd= ev : x 3 40.21 40.82 40.53 40.52 0.305122= 93 : + 3 59.44 63.28 62.18 61.633333 1.97750= 68 : Difference at 95.0% confidence : 21.1133 +/- 3.2069 : 52.106% +/- 7.91437% : (Student's t, pooled s =3D 1.41486) Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFHZNeqRfpzJluFF4RAkjKAKCBD+nABOJc+OHkilG+jGqwaLOQawCghyHz yyWr4+JmVyq6kXoHT6fn3dY= =G/Fr -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 21:45:24 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BB0C116A403; Fri, 29 Sep 2006 21:45:24 +0000 (UTC) (envelope-from prvs=julian=420c9c4b2@elischer.org) Received: from a50.ironport.com (a50.ironport.com [63.251.108.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 94C5E43D70; Fri, 29 Sep 2006 21:45:18 +0000 (GMT) (envelope-from prvs=julian=420c9c4b2@elischer.org) Received: from unknown (HELO [10.251.18.229]) ([10.251.18.229]) by a50.ironport.com with ESMTP; 29 Sep 2006 14:45:18 -0700 Message-ID: <451D93EE.9040309@elischer.org> Date: Fri, 29 Sep 2006 14:45:18 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.13) Gecko/20060414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <451ADC21.50206@centtech.com> <200609271727.29775.jhb@freebsd.org> <451D4787.4050309@samsco.org> <200609291618.09492.jhb@freebsd.org> In-Reply-To: <200609291618.09492.jhb@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: isofs/cd9660 -> relocate to fs/isofs/cd9660? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 21:45:24 -0000 John Baldwin wrote: >On Friday 29 September 2006 12:19, Scott Long wrote: > > >>John Baldwin wrote: >> >> >>>On Wednesday 27 September 2006 16:43, Scott Long wrote: >>> >>> >>> >>>>Eric Anderson wrote: >>>> >>>> >>>> >>>>>I noticed that cd9660 file system is in sys/isofs/cd9660 instead of what >>>>>seems more logical: sys/fs/cd9660. Is there any reason not to move it? >>>>> Curious mostly.. >>>>> >>>>>Eric >>>>> >>>>> >>>>> >>>>> >>>>Inertia, mostly. And if you move cd9660, do you also move ufs? Let the >>>>bi-yearly debate begin..... >>>> >>>>Btw, this is a topic that is easily searched on, as it gets brought up >>>>fairly regularly. We were a bit late on the schedule this time, though, >>>>so thanks for giving it a kickstart. >>>> >>>> >>>We've actually moved most of the filesystems into sys/fs in the past. >>> >>> >Only > > >>>cd9660, nfs, and ufs are in the top-level. I'd still say leave nfs and >>> >>> >ufs > > >>>alone, but sys/isofs/cd9660 -> sys/fs/cd9660 (I wouldn't keep the extra >>> >>> >isofs > > >>>directory) probably wouldn't be but so painful at this point. >>> >>> >>> >>What about moving all of the net* directories into /sys/net?. And >>don't forget putting i386 and friends into /sys/arch! Ah, I love the >>smell of fresh paint in the morning. Smells like.... napalm. >> >> > >Baby steps aren't hard. :) Back when I first made rumblings about this sort >of thing we didn't have a sys/fs at all, but now we do and over time we've >actually moved most of our filesystems into it. :) > > > there was a sys/miscfs which could have been used.. Matt Dillon took the oportunity to redo the tree in DF. I wonder how that's working out? From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 21:47:28 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 697E316A416; Fri, 29 Sep 2006 21:47:28 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 315B143D49; Fri, 29 Sep 2006 21:47:19 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 29 Sep 2006 14:47:19 -0700 X-IronPort-AV: i="4.09,238,1157353200"; d="scan'208"; a="326743810:sNHT2388261358" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TLlHt9022220; Fri, 29 Sep 2006 14:47:17 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k8TLlHid014772; Fri, 29 Sep 2006 14:47:17 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 29 Sep 2006 14:47:17 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 14:47:16 -0700 Message-ID: <451D9440.6060105@cisco.com> Date: Fri, 29 Sep 2006 17:46:40 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John-Mark Gurney References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> In-Reply-To: <20060929213722.GR80527@funkthat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2006 21:47:16.0995 (UTC) FILETIME=[D4F31D30:01C6E410] DKIM-Signature: a=rsa-sha1; q=dns; l=1747; t=1159566438; x=1160430438; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20Much=20improved=20sosend_*()=20functions; X=v=3Dcisco.com=3B=20h=3DVUE9hWftOvPULvUJ9EhsWe/RDnk=3D; b=LaxrvinT243oWFgRmCNNcaJnU63/9+vkyO8qPMShp04FDcO4ciaNtNfyJ+NnBwNYRYP2Yi8X sNWZBNVJFH4VKxKyig2ITr/Q1y+QeJGEys147anRqcLeOilrhJeyRfol; Authentication-Results: sj-dkim-5.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org, Mike Silbersack , freebsd-current@freebsd.org, Andre Oppermann , gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 21:47:28 -0000 John-Mark Gurney wrote: > IMO it's quite a waste of memory the way we have thigns now, though > w/ TSO it'll change things... > > w/ 512 byte mbuf and a 2k cluster just to store just 1514 bytes of data, I did not know we were at 512 byte mbufs.. I thought they were 256 bytes.. of course I have not checked recently :-0 > that's only 60% effeciency wrt to memory usage... so, we currently > waste 40% of memory allocated to mbufs+clusters... Even reducing > mbufs back to 128 or 256 would be a big help, though IPSEC I believe > would have issues... Ahh.. thats probably why they grew and I did not realize it.. Hmm. at 512 bytes it seems to me even more worthwhile to make everything an EXT.. but thats just me (its not a rant... at least I don't think so).. just something I think would be cool and MAY gain some efficency.. I know it would for SCTP.. not sure about TCP.. and UDP is not so big of deal since the packet is sent to driver land after copy anyway.. no need to retransmit ;-) > > Hmmm.. If we switched clusters to 1536 bytes in size, we'd be able to > fit 8 in 12k (though I guess for 8k page boxes we'd do 16 in 24k)... The > only issue w/ that would be that a few of the clusters would possibly > split page boundaries... How much this would effect performance would > be an interesting question to answer... That is a good point.. 1536 is a good size for network things...vs 2k... Of course 2 - 2k fits nicely in a page.. Maybe I will make some time shortly to play with this.. change 2k - 1536 and make and reshape mbufs to always have clusters... see what my box would do then ;-D R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 21:59:35 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D371116A412 for ; Fri, 29 Sep 2006 21:59:35 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6C0C43D88 for ; Fri, 29 Sep 2006 21:59:25 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 97872 invoked from network); 29 Sep 2006 22:00:36 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Sep 2006 22:00:36 -0000 Message-ID: <451D973C.8070004@freebsd.org> Date: Fri, 29 Sep 2006 23:59:24 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: John-Mark Gurney References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> In-Reply-To: <20060929213722.GR80527@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Randall Stewart , freebsd-current@freebsd.org, Mike Silbersack , gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 21:59:35 -0000 John-Mark Gurney wrote: > Randall Stewart wrote this message on Fri, Sep 29, 2006 at 16:55 -0400: > >>Mike Silbersack wrote: >> >>>On Fri, 29 Sep 2006, Andre Oppermann wrote: >>> >>> >>> >>>>over it an copies the data into the mbufs by using uiomove(). >>>>sosend_dgram() >>>>and sosend_generic() are change to use m_uiotombuf() instead of >>>>sosend_copyin(). >>> >>> >>>Can you do some UDP testing with 512b, 1K, 2K, 4K, 8K, and 16K packets to >>>see if performance changes there as well? >> >>Hmm.. I would think 512b and 1K will not show any >>improvement.. since they would probably end up either >>in an mbuf chain.. or a single 2k (or maybe 4k) cluster.. >>... quite a waste.. now if we had 512b and 1k clusters that >>would be cool... >> >>In fact I have always thought we should: >> >>a) have no data portion in an mbuf.. just pointers i.e. always >> an EXT >> >>b) Have a 256/512 and 1k cluster too.. >> >>This would allow copy by reference no matter what size si >>being sent... > > > IMO it's quite a waste of memory the way we have thigns now, though > w/ TSO it'll change things... Receive path != send path. > w/ 512 byte mbuf and a 2k cluster just to store just 1514 bytes of data, > that's only 60% effeciency wrt to memory usage... so, we currently > waste 40% of memory allocated to mbufs+clusters... Even reducing > mbufs back to 128 or 256 would be a big help, though IPSEC I believe > would have issues... mbufs are 256 bytes. > Hmmm.. If we switched clusters to 1536 bytes in size, we'd be able to > fit 8 in 12k (though I guess for 8k page boxes we'd do 16 in 24k)... The > only issue w/ that would be that a few of the clusters would possibly > split page boundaries... How much this would effect performance would > be an interesting question to answer... Splitting page boundaries is not an option as it may not be physically contigous. Just don't overengineer the stuff. Mbufs are only used temporarily and a bit theoretical waste is not much a problem (so far at least). -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 22:06:04 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C742316A40F; Fri, 29 Sep 2006 22:06:04 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7F2843D55; Fri, 29 Sep 2006 22:06:00 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.6/8.13.6) with ESMTP id k8TM60LP023391 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 29 Sep 2006 18:06:00 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k8TM5t7A061952; Fri, 29 Sep 2006 18:05:55 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17693.39106.950631.742167@grasshopper.cs.duke.edu> Date: Fri, 29 Sep 2006 18:05:54 -0400 (EDT) To: Andre Oppermann In-Reply-To: <451D9440.6060105@cisco.com> References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> <451D9440.6060105@cisco.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 22:06:04 -0000 Andre, I meant to ask: Did you try 16KB jumbos? Did they perform any better than page-sized jumbos? Also, if we're going to change how mbufs work, let's add something like Linux's skb_frag_t frags[MAX_SKB_FRAGS]; In FreeBSD parlence, this embeds something like an array of sf_bufs pointers in mbuf. The big difference to a chain of M_EXT mbufs is that you need to allocate only one mbuf wrapper, rather than one for each item in the list. Also, the reference is kept in the page (or sf_buf) itself, and the data offset is kept in the skbbuf (or mbuf). This allows us to do cool things like allocate a single page, and use both halves of it for 2 separate 1500 byte frames. This allows us to achieve *amazing* results in combination with LRO, because it allows us to do, on average, many fewer allocations per byte. Especially in combination with Linux's "high order" page allocations. Using order-2 allocations and LRO, I've actually seen 10GbE line rate receives on a wimpy 2.0GHz Athlon64. Drew From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 22:07:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 38E4216A407; Fri, 29 Sep 2006 22:07:46 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6027943D46; Fri, 29 Sep 2006 22:07:45 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 29 Sep 2006 15:07:45 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TM7jk0019611; Fri, 29 Sep 2006 15:07:45 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8TM7j1E001425; Fri, 29 Sep 2006 15:07:45 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 15:07:44 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 15:07:44 -0700 Message-ID: <451D990A.8080504@cisco.com> Date: Fri, 29 Sep 2006 18:07:06 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Oppermann References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> <451D973C.8070004@freebsd.org> In-Reply-To: <451D973C.8070004@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2006 22:07:44.0495 (UTC) FILETIME=[B098BFF0:01C6E413] DKIM-Signature: a=rsa-sha1; q=dns; l=1032; t=1159567665; x=1160431665; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20Much=20improved=20sosend_*()=20functions; X=v=3Dcisco.com=3B=20h=3DVUE9hWftOvPULvUJ9EhsWe/RDnk=3D; b=sATMwkUjdA/+tRHC9tK3MPk72tolcUkSM6GiE5w4O0dr+wG1HyYnNcqkWfE0DX2eX+c4NJYY Xm6ToVGPS50jnfbw1B7JOXygNW4sYWgN3xsDOqTXTlCwmQRb9Whzq9Cw; Authentication-Results: sj-dkim-1.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org, John-Mark Gurney , freebsd-current@freebsd.org, Mike Silbersack , gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 22:07:46 -0000 Andre Oppermann wrote: > John-Mark Gurney wrote: > > mbufs are 256 bytes. Thats what I had thought :-) > >> Hmmm.. If we switched clusters to 1536 bytes in size, we'd be able to >> fit 8 in 12k (though I guess for 8k page boxes we'd do 16 in 24k)... The >> only issue w/ that would be that a few of the clusters would possibly >> split page boundaries... How much this would effect performance would >> be an interesting question to answer... > > > Splitting page boundaries is not an option as it may not be physically > contigous. That can be rather hazardous :-) > > Just don't overengineer the stuff. Mbufs are only used temporarily and > a bit theoretical waste is not much a problem (so far at least). > Yes, but I think a combination of less copying and a bit better use of space could help overall.. but I guess as they say the "proof is in the pudding" so I will have to play a bit.. R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 22:29:48 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 484C216A412 for ; Fri, 29 Sep 2006 22:29:48 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C22C43D69 for ; Fri, 29 Sep 2006 22:29:47 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 98113 invoked from network); 29 Sep 2006 22:30:57 -0000 Received: from dotat.atdotat.at (HELO [62.48.0.47]) ([62.48.0.47]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Sep 2006 22:30:57 -0000 Message-ID: <451D9E59.9050000@freebsd.org> Date: Sat, 30 Sep 2006 00:29:45 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050217 MIME-Version: 1.0 To: Andrew Gallatin References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> <451D9440.6060105@cisco.com> <17693.39106.950631.742167@grasshopper.cs.duke.edu> In-Reply-To: <17693.39106.950631.742167@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 22:29:48 -0000 Andrew Gallatin wrote: > Andre, > > I meant to ask: Did you try 16KB jumbos? Did they perform > any better than page-sized jumbos? No, I didn't try 16K jumbos. The problem with anything larger than page size is that it may look contigous in kernel memory but isn't in physical memory. Thus you need the same number of descriptors for the network card as with page sized (4K) clusters. > Also, if we're going to change how mbufs work, let's add something > like Linux's skb_frag_t frags[MAX_SKB_FRAGS]; In FreeBSD parlence, > this embeds something like an array of sf_bufs pointers in mbuf. The > big difference to a chain of M_EXT mbufs is that you need to allocate > only one mbuf wrapper, rather than one for each item in the list. > Also, the reference is kept in the page (or sf_buf) itself, and the > data offset is kept in the skbbuf (or mbuf). We are not going to change how mbufs work. > This allows us to do cool things like allocate a single page, and use > both halves of it for 2 separate 1500 byte frames. This allows us to > achieve *amazing* results in combination with LRO, because it allows > us to do, on average, many fewer allocations per byte. Especially in > combination with Linux's "high order" page allocations. Using order-2 > allocations and LRO, I've actually seen 10GbE line rate receives on a > wimpy 2.0GHz Athlon64. I have just started tackling the receive path. Lets see what comes out of it first before we jump to conclusions. -- Andre From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 22:45:34 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D250D16A494; Fri, 29 Sep 2006 22:45:34 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id E059943D76; Fri, 29 Sep 2006 22:45:31 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.6/8.13.6) with ESMTP id k8TMjSLL000487 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 29 Sep 2006 18:45:28 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k8TMjNdL062030; Fri, 29 Sep 2006 18:45:23 -0400 (EDT) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17693.41475.778558.381395@grasshopper.cs.duke.edu> Date: Fri, 29 Sep 2006 18:45:23 -0400 (EDT) To: Andre Oppermann In-Reply-To: <451D9E59.9050000@freebsd.org> References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> <451D9440.6060105@cisco.com> <17693.39106.950631.742167@grasshopper.cs.duke.edu> <451D9E59.9050000@freebsd.org> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 22:45:34 -0000 Andre Oppermann writes: > Andrew Gallatin wrote: > > Andre, > > > > I meant to ask: Did you try 16KB jumbos? Did they perform > > any better than page-sized jumbos? > > No, I didn't try 16K jumbos. The problem with anything larger than > page size is that it may look contigous in kernel memory but isn't > in physical memory. Thus you need the same number of descriptors > for the network card as with page sized (4K) clusters. But it would allow you to do one copyin, rather than 4. I don't know how much this would help, but it might be worth looking at. > > Also, if we're going to change how mbufs work, let's add something > > like Linux's skb_frag_t frags[MAX_SKB_FRAGS]; In FreeBSD parlence, > > this embeds something like an array of sf_bufs pointers in mbuf. The > > big difference to a chain of M_EXT mbufs is that you need to allocate > > only one mbuf wrapper, rather than one for each item in the list. > > Also, the reference is kept in the page (or sf_buf) itself, and the > > data offset is kept in the skbbuf (or mbuf). > > We are not going to change how mbufs work. > > > This allows us to do cool things like allocate a single page, and use > > both halves of it for 2 separate 1500 byte frames. This allows us to > > achieve *amazing* results in combination with LRO, because it allows > > us to do, on average, many fewer allocations per byte. Especially in > > combination with Linux's "high order" page allocations. Using order-2 > > allocations and LRO, I've actually seen 10GbE line rate receives on a > > wimpy 2.0GHz Athlon64. > > I have just started tackling the receive path. Lets see what comes out > of it first before we jump to conclusions. It could be mbufs are cheaper to get than skbs and pages on linux, but I doubt it. FWIW, linux has an skb chaining mechanism (frag_list). My first LRO experiment was based on allocating "normal" skbs and chaining them. That maxed out at around 5.2Gb/s (on the same hardware I see line rate on). Drew From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 22:54:44 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0974116A403 for ; Fri, 29 Sep 2006 22:54:44 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6B2E43D94 for ; Fri, 29 Sep 2006 22:54:36 +0000 (GMT) (envelope-from jfvogel@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so1383539pye for ; Fri, 29 Sep 2006 15:54:36 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=f5ptTLcu8N51NGb5QMifqQmB9tvjPg7/sdvCRRDyhIWCKkoRCnjJHOFruK9ymtBZl/rVsELQtg1W+jXO18fNAHhmV9KkPIaCxFB5k0bCSt+SrZHSU0djReZWBAMFPAMLAjxqifTVJJJM+N4iXSd7eqxk0qDmF5rwH5Szevn7zcI= Received: by 10.35.103.1 with SMTP id f1mr1404059pym; Fri, 29 Sep 2006 15:54:35 -0700 (PDT) Received: by 10.35.119.14 with HTTP; Fri, 29 Sep 2006 15:54:35 -0700 (PDT) Message-ID: <2a41acea0609291554g528f83d1ofaf35f7a4ea5ac28@mail.gmail.com> Date: Fri, 29 Sep 2006 15:54:35 -0700 From: "Jack Vogel" To: "Andrew Gallatin" In-Reply-To: <17693.41475.778558.381395@grasshopper.cs.duke.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> <451D9440.6060105@cisco.com> <17693.39106.950631.742167@grasshopper.cs.duke.edu> <451D9E59.9050000@freebsd.org> <17693.41475.778558.381395@grasshopper.cs.duke.edu> Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 22:54:44 -0000 On 9/29/06, Andrew Gallatin wrote: > > Andre Oppermann writes: > > Andrew Gallatin wrote: > > > Andre, > > > > > > I meant to ask: Did you try 16KB jumbos? Did they perform > > > any better than page-sized jumbos? > > > > No, I didn't try 16K jumbos. The problem with anything larger than > > page size is that it may look contigous in kernel memory but isn't > > in physical memory. Thus you need the same number of descriptors > > for the network card as with page sized (4K) clusters. > > But it would allow you to do one copyin, rather than 4. I > don't know how much this would help, but it might be worth > looking at. There is another limitation, due to hardware FIFO size, TSO must never have more than 4K per descriptor. But as Andrew says, that needn't limit you up above, it will just get parceled up in the driver. Jack From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 22:55:59 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D13C16A403; Fri, 29 Sep 2006 22:55:59 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6A7443D4C; Fri, 29 Sep 2006 22:55:58 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 922AB46D27; Fri, 29 Sep 2006 18:55:57 -0400 (EDT) Date: Fri, 29 Sep 2006 23:55:57 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: John Baldwin In-Reply-To: <200609291618.09492.jhb@freebsd.org> Message-ID: <20060929235459.M73166@fledge.watson.org> References: <451ADC21.50206@centtech.com> <200609271727.29775.jhb@freebsd.org> <451D4787.4050309@samsco.org> <200609291618.09492.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: isofs/cd9660 -> relocate to fs/isofs/cd9660? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 22:55:59 -0000 On Fri, 29 Sep 2006, John Baldwin wrote: >>>> Btw, this is a topic that is easily searched on, as it gets brought up >>>> fairly regularly. We were a bit late on the schedule this time, though, >>>> so thanks for giving it a kickstart. >>> >>> We've actually moved most of the filesystems into sys/fs in the past. > Only >>> cd9660, nfs, and ufs are in the top-level. I'd still say leave nfs and > ufs >>> alone, but sys/isofs/cd9660 -> sys/fs/cd9660 (I wouldn't keep the extra > isofs >>> directory) probably wouldn't be but so painful at this point. >>> >> >> What about moving all of the net* directories into /sys/net?. And don't >> forget putting i386 and friends into /sys/arch! Ah, I love the smell of >> fresh paint in the morning. Smells like.... napalm. > > Baby steps aren't hard. :) Back when I first made rumblings about this sort > of thing we didn't have a sys/fs at all, but now we do and over time we've > actually moved most of our filesystems into it. :) The great thing about moving all the network subtrees around is how we can break the compile of all the existing applications that include net/*, netinet/*, netinet6/*, etc, all in one pass. :-) Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 22:59:15 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C41E416A403; Fri, 29 Sep 2006 22:59:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A52D43D7C; Fri, 29 Sep 2006 22:59:14 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E25FF46C05; Fri, 29 Sep 2006 18:59:13 -0400 (EDT) Date: Fri, 29 Sep 2006 23:59:13 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Julian Elischer In-Reply-To: <451D93EE.9040309@elischer.org> Message-ID: <20060929235659.J73166@fledge.watson.org> References: <451ADC21.50206@centtech.com> <200609271727.29775.jhb@freebsd.org> <451D4787.4050309@samsco.org> <200609291618.09492.jhb@freebsd.org> <451D93EE.9040309@elischer.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org Subject: Re: isofs/cd9660 -> relocate to fs/isofs/cd9660? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 22:59:15 -0000 On Fri, 29 Sep 2006, Julian Elischer wrote: >>> What about moving all of the net* directories into /sys/net?. And don't >>> forget putting i386 and friends into /sys/arch! Ah, I love the smell of >>> fresh paint in the morning. Smells like.... napalm. >> >> Baby steps aren't hard. :) Back when I first made rumblings about this >> sort of thing we didn't have a sys/fs at all, but now we do and over time >> we've actually moved most of our filesystems into it. :) > > there was a sys/miscfs which could have been used.. > > Matt Dillon took the oportunity to redo the tree in DF. I wonder how that's > working out? I think the best model for handling utterly gratuitous source tree rearrangements is to do them only in the context of the code finding a maintainer, and in the context of a larger piece of work. I.e., if a developer finds their location irksome, they can first agree to take responsibility for the code before randomly moving it around, rather than having it be a one-pass drive-by. For example, I recently had uipc_socket2.c renamed to uipc_sockbuf.c (mostly) as part of overall cleanup and work on the socket layer. I would not have dreamed about doing this if I hadn't already been working on the socket layer heavily. This is something along the lines of "you break it, you buy it", only it's a case of "You fix it, you avoid the bikeshed". :-) Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 23:10:22 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D86816A415; Fri, 29 Sep 2006 23:10:22 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA5CA43D70; Fri, 29 Sep 2006 23:10:11 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (1getp7ac4kr9olq0@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k8TNA8Nr037297; Fri, 29 Sep 2006 16:10:08 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k8TNA7i3037296; Fri, 29 Sep 2006 16:10:07 -0700 (PDT) (envelope-from jmg) Date: Fri, 29 Sep 2006 16:10:07 -0700 From: John-Mark Gurney To: Andre Oppermann Message-ID: <20060929231007.GS80527@funkthat.com> Mail-Followup-To: Andre Oppermann , freebsd-net@freebsd.org, Randall Stewart , freebsd-current@freebsd.org, Mike Silbersack , gallatin@cs.duke.edu References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> <451D973C.8070004@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <451D973C.8070004@freebsd.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: freebsd-net@freebsd.org, Randall Stewart , freebsd-current@freebsd.org, Mike Silbersack , gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2006 23:10:22 -0000 Andre Oppermann wrote this message on Fri, Sep 29, 2006 at 23:59 +0200: > >w/ 512 byte mbuf and a 2k cluster just to store just 1514 bytes of data, > >that's only 60% effeciency wrt to memory usage... so, we currently > >waste 40% of memory allocated to mbufs+clusters... Even reducing > >mbufs back to 128 or 256 would be a big help, though IPSEC I believe > >would have issues... > > mbufs are 256 bytes. Hmmm.. I keep getting this confused... maybe because there was discussion about increasing this a few years back... or maybe because NOTES has it as 512.. :) > >Hmmm.. If we switched clusters to 1536 bytes in size, we'd be able to > >fit 8 in 12k (though I guess for 8k page boxes we'd do 16 in 24k)... The > >only issue w/ that would be that a few of the clusters would possibly > >split page boundaries... How much this would effect performance would > >be an interesting question to answer... > > Splitting page boundaries is not an option as it may not be physically > contigous. unless we do something strange like allocate them contigously... though that introduces another set of issues.... > Just don't overengineer the stuff. Mbufs are only used temporarily and > a bit theoretical waste is not much a problem (so far at least). Well, I beg to differ... most gige cards grab mbuf+cluster for every single ring buffer they have.. which is usually 512... so every gige interface for the most part consumes 1meg of memory that is not reusable... because if we run out of mbuf+clusters to replace in the receive ring, we will not tap into the 1meg of mbuf+clusters available to us... so, if you have a quad gige, that's 4megs wasted, plus w/ the fact that we could only use ~65% of that memory, that's a lot of memory wasted... Yeh, everyone says you have gigs of memory, but do we really want to be known as the wasteful OS? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 23:11:02 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 187AB16A40F; Fri, 29 Sep 2006 23:11:02 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-1.cisco.com (sj-iport-1-in.cisco.com [171.71.176.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 953B443D6E; Fri, 29 Sep 2006 23:10:48 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 29 Sep 2006 16:10:49 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TNAmad020013; Fri, 29 Sep 2006 16:10:48 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8TNAm1E002493; Fri, 29 Sep 2006 16:10:48 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 16:10:48 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 16:10:47 -0700 Message-ID: <451DA7D4.8020609@cisco.com> Date: Fri, 29 Sep 2006 19:10:12 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Gallatin References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> <451D9440.6060105@cisco.com> <17693.39106.950631.742167@grasshopper.cs.duke.edu> <451D9E59.9050000@freebsd.org> <17693.41475.778558.381395@grasshopper.cs.duke.edu> In-Reply-To: <17693.41475.778558.381395@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2006 23:10:48.0047 (UTC) FILETIME=[7FC4F7F0:01C6E41C] DKIM-Signature: a=rsa-sha1; q=dns; l=3066; t=1159571448; x=1160435448; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20Much=20improved=20sosend_*()=20functions; X=v=3Dcisco.com=3B=20h=3DVUE9hWftOvPULvUJ9EhsWe/RDnk=3D; b=y+8iQMsAwHjX3/hVFa2gmkETnLnTAY9ShpyIHn8YCOwcn9AejGSfhIcaA83FYacAstz3KEtC IFScwUU92DBHV9hTg5VHjK37zPDFKXpJt1uGUxWQkPQ+ZZsXrrvJpk8V; Authentication-Results: sj-dkim-2.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org, Andre Oppermann Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 23:11:02 -0000 Andrew Gallatin wrote: > Andre Oppermann writes: > > Andrew Gallatin wrote: > > > Andre, > > > > > > I meant to ask: Did you try 16KB jumbos? Did they perform > > > any better than page-sized jumbos? > > > > No, I didn't try 16K jumbos. The problem with anything larger than > > page size is that it may look contigous in kernel memory but isn't > > in physical memory. Thus you need the same number of descriptors > > for the network card as with page sized (4K) clusters. > > But it would allow you to do one copyin, rather than 4. I > don't know how much this would help, but it might be worth > looking at. It helped the SCTP code quite a bit when I optimized it to use this... can't remember how much of a boost it got.. (I started using all the frames at one time).. and of course it only helps when the msg size being sent is > 9k... But it was a help... at least on the copy-in side for sending down.. > > > > Also, if we're going to change how mbufs work, let's add something > > > like Linux's skb_frag_t frags[MAX_SKB_FRAGS]; In FreeBSD parlence, > > > this embeds something like an array of sf_bufs pointers in mbuf. The > > > big difference to a chain of M_EXT mbufs is that you need to allocate > > > only one mbuf wrapper, rather than one for each item in the list. > > > Also, the reference is kept in the page (or sf_buf) itself, and the > > > data offset is kept in the skbbuf (or mbuf). > > > > We are not going to change how mbufs work. > > > > > This allows us to do cool things like allocate a single page, and use > > > both halves of it for 2 separate 1500 byte frames. This allows us to > > > achieve *amazing* results in combination with LRO, because it allows > > > us to do, on average, many fewer allocations per byte. Especially in > > > combination with Linux's "high order" page allocations. Using order-2 > > > allocations and LRO, I've actually seen 10GbE line rate receives on a > > > wimpy 2.0GHz Athlon64. > > > > I have just started tackling the receive path. Lets see what comes out > > of it first before we jump to conclusions. > > It could be mbufs are cheaper to get than skbs and pages on linux, > but I doubt it. FWIW, linux has an skb chaining mechanism > (frag_list). My first LRO experiment was based on allocating "normal" > skbs and chaining them. That maxed out at around 5.2Gb/s (on the same > hardware I see line rate on). This would be a drastic set of changes.. a bit more than the simple add a few more sizes and get rid of data inside the mbuf... which would shrink the mbuf size considerable... of course one would need always a data EXT... R > > Drew > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 23:12:46 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6214C16A407; Fri, 29 Sep 2006 23:12:46 +0000 (UTC) (envelope-from rrs@cisco.com) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8DF1E43D8A; Fri, 29 Sep 2006 23:12:36 +0000 (GMT) (envelope-from rrs@cisco.com) Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 29 Sep 2006 16:12:33 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k8TNCXCA029019; Fri, 29 Sep 2006 16:12:33 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k8TNCW1E003174; Fri, 29 Sep 2006 16:12:32 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 16:12:32 -0700 Received: from [127.0.0.1] ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Sep 2006 16:12:32 -0700 Message-ID: <451DA83C.4050808@cisco.com> Date: Fri, 29 Sep 2006 19:11:56 -0400 From: Randall Stewart User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John-Mark Gurney References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> <451D973C.8070004@freebsd.org> <20060929231007.GS80527@funkthat.com> In-Reply-To: <20060929231007.GS80527@funkthat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Sep 2006 23:12:32.0346 (UTC) FILETIME=[BDEFBBA0:01C6E41C] DKIM-Signature: a=rsa-sha1; q=dns; l=2158; t=1159571553; x=1160435553; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rrs@cisco.com; z=From:Randall=20Stewart=20 |Subject:Re=3A=20Much=20improved=20sosend_*()=20functions; X=v=3Dcisco.com=3B=20h=3DVUE9hWftOvPULvUJ9EhsWe/RDnk=3D; b=SW2mOXpPB6lMuG3nFobwJGfZ1GztAodblcNhw4PziNJ/rSBtM6mpmmCLwG/aZYCRcZ8V3n0Z OP7F12zIZrfjREa8RRRHyWwpQTBJxLqeZXpEOsXAs99RrtVUeXnpqKPa; Authentication-Results: sj-dkim-4.cisco.com; header.From=rrs@cisco.com; dkim=pass ( sig from cisco.com verified; ); Cc: freebsd-net@freebsd.org, Mike Silbersack , freebsd-current@freebsd.org, Andre Oppermann , gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 23:12:46 -0000 John-Mark Gurney wrote: > Andre Oppermann wrote this message on Fri, Sep 29, 2006 at 23:59 +0200: > >>>w/ 512 byte mbuf and a 2k cluster just to store just 1514 bytes of data, >>>that's only 60% effeciency wrt to memory usage... so, we currently >>>waste 40% of memory allocated to mbufs+clusters... Even reducing >>>mbufs back to 128 or 256 would be a big help, though IPSEC I believe >>>would have issues... >> >>mbufs are 256 bytes. > > > Hmmm.. I keep getting this confused... maybe because there was discussion > about increasing this a few years back... or maybe because NOTES has > it as 512.. :) > > >>>Hmmm.. If we switched clusters to 1536 bytes in size, we'd be able to >>>fit 8 in 12k (though I guess for 8k page boxes we'd do 16 in 24k)... The >>>only issue w/ that would be that a few of the clusters would possibly >>>split page boundaries... How much this would effect performance would >>>be an interesting question to answer... >> >>Splitting page boundaries is not an option as it may not be physically >>contigous. > > > unless we do something strange like allocate them contigously... though > that introduces another set of issues.... > > >>Just don't overengineer the stuff. Mbufs are only used temporarily and >>a bit theoretical waste is not much a problem (so far at least). > > > Well, I beg to differ... most gige cards grab mbuf+cluster for every > single ring buffer they have.. which is usually 512... so every gige > interface for the most part consumes 1meg of memory that is not > reusable... because if we run out of mbuf+clusters to replace in the > receive ring, we will not tap into the 1meg of mbuf+clusters available > to us... so, if you have a quad gige, that's 4megs wasted, plus w/ the > fact that we could only use ~65% of that memory, that's a lot of memory > wasted... > > Yeh, everyone says you have gigs of memory, but do we really want to > be known as the wasteful OS? > Let me try to find some cycles (somewhere) and play with this :-) R -- Randall Stewart NSSTG - Cisco Systems Inc. 803-345-0369 815-342-5222 (cell) From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 23:21:19 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB4DC16A403; Fri, 29 Sep 2006 23:21:19 +0000 (UTC) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6C1843D4C; Fri, 29 Sep 2006 23:21:16 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (q58bmqjvchspmfjz@localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.6/8.13.3) with ESMTP id k8TNLGDg037624; Fri, 29 Sep 2006 16:21:16 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.6/8.13.3/Submit) id k8TNLGqO037623; Fri, 29 Sep 2006 16:21:16 -0700 (PDT) (envelope-from jmg) Date: Fri, 29 Sep 2006 16:21:15 -0700 From: John-Mark Gurney To: Robert Watson Message-ID: <20060929232115.GT80527@funkthat.com> Mail-Followup-To: Robert Watson , Pawel Jakub Dawidek , ru@FreeBSD.org, current@FreeBSD.org References: <20060929141709.E70454@fledge.watson.org> <20060929155526.GA9194@garage.freebsd.pl> <20060929172321.R74256@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060929172321.R74256@fledge.watson.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p6 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: ru@FreeBSD.org, Pawel Jakub Dawidek , current@FreeBSD.org Subject: Re: lockf in installworld -- not a good idea X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Sep 2006 23:21:19 -0000 Robert Watson wrote this message on Fri, Sep 29, 2006 at 17:24 +0100: > > On Fri, 29 Sep 2006, Pawel Jakub Dawidek wrote: > > >On Fri, Sep 29, 2006 at 02:20:06PM +0100, Robert Watson wrote: > >>I've noticed an increasing intolerance in our tools for system install > >>and maintenance to locking not being implemented over the past few years. > >>I no longer get working > >>cron on boxes with neither rpc.lockd nor local locking enabled, for > >>example. [...] > > > >If you are refering to my change in which cron(8) started to use > >pidfile(3), then I'm sorry, but you're wrong. > > > >cron(8) from the very beginning was exiting when it had problems with > >creating a pidfile, please check function acquire_daemonlock() in: > > Cron may have been a poor example, I picked it from the top of a list of a > half dozen failed services, many of which used not to fail. Sorry about > that. > > >The way I prefer is to ignore errors other than EEXIST - you can check > >EXAMPLES section in the pidfile(3) manual page for more info. I just > >didn't wanted to change cron(8)'s original behaviour. > > > >I do agree, that this shouldn't be treated as critical error and I can > >change it if you like. > > I think if we get back EOPNOTSUPP from lock attempts in libpidfile, we > should ignore it and hope for the best. In an ideal world, we wouldn't do > this, but in an ideal world we also wouldn't need to. :-) Why not: -L Do not forward fcntl(2) locks over the wire. All locks will be local and not seen by the server and likewise not seen by other NFS clients. This removes the need to run the rpcbind(8) service and the rpc.statd(8) and rpc.lockd(8) servers on the client. Note that this option will only be honored when performing the initial mount, it will be silently ignored if used while updating the mount options. Seems like most of these cases -L makes the most sense... I don't see a reason you'd share var's between machines, and doubt that you'd be installing world to the same tree from two different machines... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@FreeBSD.ORG Fri Sep 29 23:30:29 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75AAF16A4E8 for ; Fri, 29 Sep 2006 23:30:29 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22DFA43D6E for ; Fri, 29 Sep 2006 23:30:24 +0000 (GMT) (envelope-from andre@freebsd.org) Received: (qmail 98644 invoked from network); 29 Sep 2006 23:31:35 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 29 Sep 2006 23:31:35 -0000 Message-ID: <451DAC8F.7030309@freebsd.org> Date: Sat, 30 Sep 2006 01:30:23 +0200 From: Andre Oppermann User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Andre Oppermann , freebsd-net@freebsd.org, Randall Stewart , freebsd-current@freebsd.org, Mike Silbersack , gallatin@cs.duke.edu References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> <451D973C.8070004@freebsd.org> <20060929231007.GS80527@funkthat.com> In-Reply-To: <20060929231007.GS80527@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 29 Sep 2006 23:30:29 -0000 John-Mark Gurney wrote: > Andre Oppermann wrote this message on Fri, Sep 29, 2006 at 23:59 +0200: >> Just don't overengineer the stuff. Mbufs are only used temporarily and >> a bit theoretical waste is not much a problem (so far at least). > > Well, I beg to differ... most gige cards grab mbuf+cluster for every > single ring buffer they have.. which is usually 512... so every gige > interface for the most part consumes 1meg of memory that is not > reusable... because if we run out of mbuf+clusters to replace in the > receive ring, we will not tap into the 1meg of mbuf+clusters available > to us... so, if you have a quad gige, that's 4megs wasted, plus w/ the > fact that we could only use ~65% of that memory, that's a lot of memory > wasted... The problem is the network cards again. Only a few allow different rx rings to be used (for example bge(4)) where you can have multiple mbuf (+cluster) sizes and the card choses the smallest fit at receive time. > Yeh, everyone says you have gigs of memory, but do we really want to > be known as the wasteful OS? -- Andre From owner-freebsd-current@FreeBSD.ORG Sat Sep 30 08:54:13 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B5E616A412 for ; Sat, 30 Sep 2006 08:54:13 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF03643D46 for ; Sat, 30 Sep 2006 08:54:11 +0000 (GMT) (envelope-from pyunyh@gmail.com) Received: by py-out-1112.google.com with SMTP id o67so1540635pye for ; Sat, 30 Sep 2006 01:54:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:date:from:to:cc:subject:message-id:reply-to:references:mime-version:content-type:content-disposition:in-reply-to:user-agent; b=KLO3h/HTgvTe9WXv+h+7xtVgj874EVmhZ7RIja+RQKNxLxPp0CZfSUwPNmz2NFJSDmMNeORVVj6GCgbTRQUc3bZHAaE2aWeJrs0NDBABTmOo0ncq/RzgeIHm5luAV2uZEe36HNUaPo/k4+Re5fKFcH/5dhC/SpW/r/hcs8a5z7w= Received: by 10.35.53.18 with SMTP id f18mr8034608pyk; Sat, 30 Sep 2006 01:54:11 -0700 (PDT) Received: from michelle.cdnetworks.co.kr ( [211.53.35.84]) by mx.gmail.com with ESMTP id 20sm1566019nzp.2006.09.30.01.54.08; Sat, 30 Sep 2006 01:54:10 -0700 (PDT) Received: from michelle.cdnetworks.co.kr (localhost.cdnetworks.co.kr [127.0.0.1]) by michelle.cdnetworks.co.kr (8.13.5/8.13.5) with ESMTP id k8U8tDgQ034643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Sep 2006 17:55:13 +0900 (KST) (envelope-from pyunyh@gmail.com) Received: (from yongari@localhost) by michelle.cdnetworks.co.kr (8.13.5/8.13.5/Submit) id k8U8t67w034642; Sat, 30 Sep 2006 17:55:06 +0900 (KST) (envelope-from pyunyh@gmail.com) Date: Sat, 30 Sep 2006 17:55:06 +0900 From: Pyun YongHyeon To: Randall Stewart Message-ID: <20060930085506.GA32513@cdnetworks.co.kr> References: <451D5801.8030504@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <451D5801.8030504@cisco.com> User-Agent: Mutt/1.4.2.1i Cc: Peter Lei , Michael Tuexen , Robert Watson , "George V. Neville-Neil" , freebsd-current@freebsd.org Subject: Re: Some interesting plots X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2006 08:54:13 -0000 On Fri, Sep 29, 2006 at 01:29:37PM -0400, Randall Stewart wrote: > All: > > As you all may know I have been working on getting SCTP > into Current.. > > I have been, of late, trying to tweak things to get > the BEST performance out of the implementation... > > I have moved my testing off between two 7.0 machines.. same > code base on each updated Sep 25. > > One is a 2.8Gig Dell SC1600 Xeon.. (hyper threaded CPU). > The other is a P4D (2.8Gig .. slightly faster, true dual > processor machine). > > They are connected by two intel EM server cards like so: > > > +----+ +----+ > 1 | em1 <---------------------> em0 | 2 > | em0 <-----locallan--------> msk0| > | dc0 <-Direct Inet | > +----+ +-----+ > > > em1 has 10.1.2.12 em0 10.1.2.21 > em0 has 10.1.1.12 msk0 10.1.1.21 > [...] > One other note, I see TCP is only getting 250Meg or so on the > same test (It can run either).. now it used to get close to > the full pipe (Gigbit).. so is there some issue with the new code > that was recently submitted? > I'm not sure but it seems that you've used experimental msk(4) on CURRENT. ATM msk(4) has Rx performance issue. So if you get very poor receive performance it would be msk(4) issue. -- Regards, Pyun YongHyeon From owner-freebsd-current@FreeBSD.ORG Sat Sep 30 11:41:51 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CC8416A412; Sat, 30 Sep 2006 11:41:51 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B9DD43D45; Sat, 30 Sep 2006 11:41:51 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2.sentex.ca [199.212.134.9]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id k8UBfoCl039913; Sat, 30 Sep 2006 07:41:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.8/8.13.8) with ESMTP id k8UBforg051272; Sat, 30 Sep 2006 07:41:50 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 41F857302F; Sat, 30 Sep 2006 07:41:50 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060930114150.41F857302F@freebsd-current.sentex.ca> Date: Sat, 30 Sep 2006 07:41:50 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner1 X-Virus-Status: Clean Cc: Subject: [head tinderbox] failure on i386/pc98 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Sep 2006 11:41:51 -0000 TB --- 2006-09-30 11:25:22 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-09-30 11:25:22 - starting HEAD tinderbox run for i386/pc98 TB --- 2006-09-30 11:25:22 - cleaning the object tree TB --- 2006-09-30 11:25:51 - checking out the source tree TB --- 2006-09-30 11:25:51 - cd /tinderbox/HEAD/i386/pc98 TB --- 2006-09-30 11:25:51 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-09-30 11:32:28 - building world (CFLAGS=-O2 -pipe) TB --- 2006-09-30 11:32:28 - cd /src TB --- 2006-09-30 11:32:28 - /usr/bin/make -B buildworld >>> World build started on Sat Sep 30 11:32:29 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes [...] ===> gnu/lib/libregex/doc (buildincludes) ===> gnu/lib/libreadline (buildincludes) ===> gnu/lib/libreadline/history (buildincludes) ===> gnu/lib/libreadline/history/doc (buildincludes) ===> gnu/lib/libreadline/readline (buildincludes) ===> gnu/lib/libreadline/readline/doc (buildincludes) ===> gnu/lib/libstdc++ (buildincludes) make: don't know how to make /src/gnu/lib/libstdc++/../../../contrib/libstdc++/include/ext/demangle.h. Stop *** Error code 2 Stop in /src/gnu/lib. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-09-30 11:41:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-09-30 11:41:50 - ERROR: failed to build world TB --- 2006-09-30 11:41:50 - tinderbox aborted TB --- 1.13 user 5.80 system 987.23 real From owner-freebsd-current@FreeBSD.ORG Sat Sep 30 11:57:34 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18ADA16A407; Sat, 30 Sep 2006 11:57:34 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from smarthost2.sentex.ca (smarthost2.sentex.ca [205.211.164.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 868CC43D55; Sat, 30 Sep 2006 11:57:33 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1.sentex.ca [199.212.134.4]) by smarthost2.sentex.ca (8.13.8/8.13.8) with ESMTP id k8UBvWbp040793; Sat, 30 Sep 2006 07:57:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.8/8.13.8) with ESMTP id k8UBvWXl098058; Sat, 30 Sep 2006 07:57:32 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 93DE17302F; Sat, 30 Sep 2006 07:57:32 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20060930115732.93DE17302F@freebsd-current.sentex.ca> Date: Sat, 30 Sep 2006 07:57:32 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.88.1, clamav-milter version 0.88.1 on clamscanner4 X-Virus-Status: Clean 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: Sat, 30 Sep 2006 11:57:34 -0000 TB --- 2006-09-30 11:41:50 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2006-09-30 11:41:50 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2006-09-30 11:41:50 - cleaning the object tree TB --- 2006-09-30 11:42:23 - checking out the source tree TB --- 2006-09-30 11:42:23 - cd /tinderbox/HEAD/sparc64/sparc64 TB --- 2006-09-30 11:42:23 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2006-09-30 11:48:50 - building world (CFLAGS=-O2 -pipe) TB --- 2006-09-30 11:48:50 - cd /src TB --- 2006-09-30 11:48:50 - /usr/bin/make -B buildworld >>> World build started on Sat Sep 30 11:48:51 UTC 2006 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes [...] ===> gnu/lib/libregex/doc (buildincludes) ===> gnu/lib/libreadline (buildincludes) ===> gnu/lib/libreadline/history (buildincludes) ===> gnu/lib/libreadline/history/doc (buildincludes) ===> gnu/lib/libreadline/readline (buildincludes) ===> gnu/lib/libreadline/readline/doc (buildincludes) ===> gnu/lib/libstdc++ (buildincludes) make: don't know how to make /src/gnu/lib/libstdc++/../../../contrib/libstdc++/include/ext/demangle.h. Stop *** Error code 2 Stop in /src/gnu/lib. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src/gnu. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2006-09-30 11:57:32 - WARNING: /usr/bin/make returned exit code 1 TB --- 2006-09-30 11:57:32 - ERROR: failed to build world TB --- 2006-09-30 11:57:32 - tinderbox aborted TB --- 1.06 user 5.28 system 942.01 real From owner-freebsd-current@FreeBSD.ORG Sat Sep 30 12:50:30 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A2DF616A403 for ; Sat, 30 Sep 2006 12:50:30 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1477343D5A for ; Sat, 30 Sep 2006 12:50:11 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from atlantis.dp.ua (localhost [127.0.0.1]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k8UCo1FU083412; Sat, 30 Sep 2006 15:50:03 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Received: from localhost (dmitry@localhost) by atlantis.dp.ua (8.13.1/8.13.1/Submit) with ESMTP id k8UCo1xj083397; Sat, 30 Sep 2006 15:50:01 +0300 (EEST) (envelope-from dmitry@atlantis.dp.ua) Date: Sat, 30 Sep 2006 15:50:01 +0300 (EEST) From: Dmitry Pryanishnikov To: =?koi8-r?b?6czYxMHSIO7V0snTzMHNz9c=?= In-Reply-To: <200609292126.17694.absorbb@gmail.com> Message-ID: <20060930153727.R17641@atlantis.atlantis.dp.ua> References: <1159546633.1883.4.camel@wbemfkaa.net.xtra-net.be> <451D4B4A.7090602@inode.at> <1159550277.1883.6.camel@wbemfkaa.net.xtra-net.be> <200609292126.17694.absorbb@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=koi8-u; format=flowed Content-Transfer-Encoding: 8BIT Cc: freebsd-current@freebsd.org Subject: Re: linux flashplayer plugin status ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Sep 2006 12:50:31 -0000 Hello! On Fri, 29 Sep 2006, Ильдар Нурисламов wrote: > There is patch (tested on 6.1. May require little changes for 6.2) > apply it and then do "make install clean" in "/usr/src/libexec" > : > > +} > + > +void * > +_dlsym(void *handle, const char *name) > +{ > + return dlsym(handle, name); > } There is a much shorter version which applies cleanly to modern RELENG_6 and works well: --- libexec/rtld-elf/rtld.c.orig Sat Dec 31 00:13:56 2005 +++ libexec/rtld-elf/rtld.c Fri Jun 16 20:57:00 2006 @@ -132,6 +132,8 @@ void r_debug_state(struct r_debug*, struct link_map*); +__weak_reference(dlsym, _dlsym); + /* * Data declarations. */ I don't understand why this simple patch isn't committed yet. But it seems that you've missed the point: it _doesn't_ solve the problem with the linuxpluginwrapper and ELF symbol versioning, which is the CURRENT-only problem. And no, I don't like running Linux-binary browsers w/flash either, because they give confusing look of the local filesystems in the file:// mode (remember how linuxulator maps FS-related Linux requests to the FreeBSD namespace)? And yes, I understand that native browser + linuxpluginwrapper is a hackish way, but we have not other way aroud the problem using native browsers (until we haven't convinced Macromedia to release FreeBSD-native Flash plugin). Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE From owner-freebsd-current@FreeBSD.ORG Sat Sep 30 13:56:57 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E564A16A403 for ; Sat, 30 Sep 2006 13:56:57 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by mx1.FreeBSD.org (Postfix) with SMTP id 5460043D79 for ; Sat, 30 Sep 2006 13:56:57 +0000 (GMT) (envelope-from pho@holm.cc) Received: (qmail 21540 invoked from network); 30 Sep 2006 13:56:55 -0000 Received: from unknown (HELO peter.osted.lan) (unknown) by unknown with SMTP; 30 Sep 2006 13:56:55 -0000 X-pair-Authenticated: 80.165.155.106 Received: from peter.osted.lan (localhost.osted.lan [127.0.0.1]) by peter.osted.lan (8.13.6/8.13.6) with ESMTP id k8UDut3F033948 for ; Sat, 30 Sep 2006 15:56:55 +0200 (CEST) (envelope-from pho@peter.osted.lan) Received: (from pho@localhost) by peter.osted.lan (8.13.6/8.13.6/Submit) id k8UDut0W033947 for current@freebsd.org; Sat, 30 Sep 2006 15:56:55 +0200 (CEST) (envelope-from pho) Date: Sat, 30 Sep 2006 15:56:54 +0200 From: Peter Holm To: current@freebsd.org Message-ID: <20060930135654.GA33708@peter.osted.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Page fault in ip_output (fnv_hash.h:27) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Sep 2006 13:56:58 -0000 http://people.freebsd.org/~pho/stress/log/cons212.html This panic is interesting because it is easy to reproduce and impossible to get a core dump from. Could it be related to the pty memory corruption problem? -- Peter Holm From owner-freebsd-current@FreeBSD.ORG Sat Sep 30 14:17:07 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 157E516A412; Sat, 30 Sep 2006 14:17:07 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FBBF43D6E; Sat, 30 Sep 2006 14:17:03 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id CCC172095; Sat, 30 Sep 2006 16:16:59 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.4 (2006-07-25) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by tim.des.no (Postfix) with ESMTP id 524C42091; Sat, 30 Sep 2006 16:16:59 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 29A43B80E; Sat, 30 Sep 2006 16:16:59 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Randall Stewart References: <451D5801.8030504@cisco.com> Date: Sat, 30 Sep 2006 16:16:58 +0200 In-Reply-To: <451D5801.8030504@cisco.com> (Randall Stewart's message of "Fri, 29 Sep 2006 13:29:37 -0400") Message-ID: <86r6xtjv6t.fsf@dwp.des.no> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Peter Lei , Michael Tuexen , Robert Watson , "George V. Neville-Neil" , freebsd-current@freebsd.org Subject: Re: Some interesting plots X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Sep 2006 14:17:07 -0000 Randall Stewart writes: > As you all may know I have been working on getting SCTP > into Current.. > > I have been, of late, trying to tweak things to get > the BEST performance out of the implementation... the first rule of software optimization: don't do it the second rule of software opimization (for experts only): don't do it yet DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Sep 30 11:56:16 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D85816A407; Sat, 30 Sep 2006 11:56:16 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout1.pacific.net.au (mailout1-3.pacific.net.au [61.8.2.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13F5943D46; Sat, 30 Sep 2006 11:56:16 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.2.162]) by mailout1.pacific.net.au (Postfix) with ESMTP id 679CC61FF88; Sat, 30 Sep 2006 21:56:15 +1000 (EST) Received: from epsplex.bde.org (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id k8UBuC9d012947; Sat, 30 Sep 2006 21:56:13 +1000 Date: Sat, 30 Sep 2006 21:56:11 +1000 (EST) From: Bruce Evans X-X-Sender: bde@epsplex.bde.org To: John-Mark Gurney In-Reply-To: <20060929231007.GS80527@funkthat.com> Message-ID: <20060930215218.V1683@epsplex.bde.org> References: <451C4850.5030302@freebsd.org> <451D884F.1030807@cisco.com> <20060929213722.GR80527@funkthat.com> <451D973C.8070004@freebsd.org> <20060929231007.GS80527@funkthat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Sat, 30 Sep 2006 14:28:10 +0000 Cc: freebsd-net@freebsd.org, Randall Stewart , freebsd-current@freebsd.org, Andre Oppermann , gallatin@cs.duke.edu Subject: Re: Much improved sosend_*() functions X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Sep 2006 11:56:16 -0000 On Fri, 29 Sep 2006, John-Mark Gurney wrote: > Andre Oppermann wrote this message on Fri, Sep 29, 2006 at 23:59 +0200: >> mbufs are 256 bytes. > > Hmmm.. I keep getting this confused... maybe because there was discussion > about increasing this a few years back... or maybe because NOTES has > it as 512.. :) It would be a bug if NOTES had the default size. Notes is supposed to alter defaults so that non-default code paths get tested. It often uses the default plus 1 or the default times 2 (the latter when the value must be a power of 2). Bruce From owner-freebsd-current@FreeBSD.ORG Sat Sep 30 20:09:12 2006 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF92B16A40F for ; Sat, 30 Sep 2006 20:09:12 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7AC7943D45 for ; Sat, 30 Sep 2006 20:09:12 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 9961F5E7B for ; Sun, 1 Oct 2006 00:09:11 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id 787185E7A for ; Sun, 1 Oct 2006 00:09:11 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k8UK9FDN060249 for current@FreeBSD.org; Sun, 1 Oct 2006 00:09:15 +0400 (MSD) (envelope-from ru) Date: Sun, 1 Oct 2006 00:09:15 +0400 From: Ruslan Ermilov To: current@FreeBSD.org Message-ID: <20060930200915.GB60100@rambler-co.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vGgW1X5XWziG23Ko" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: Subject: HEADS UP: add "options COMPAT_FREEBSD6" to your 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: Sat, 30 Sep 2006 20:09:13 -0000 --vGgW1X5XWziG23Ko Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable All, Make sure to add "options COMPAT_FREEBSD6" to your custom kernel config files, or things like X.Org will refuse to work with the new kernel that includes fixed ioctl(2) API. Recompiling the relevant ports is another option. ----- Forwarded message from Ruslan Ermilov ----- ru 2006-09-30 20:01:15 UTC FreeBSD src repository Modified files: . UPDATING=20 Log: The ioctl(2) API has changed, and some ioctl command codes too. Hint users to add "options COMPAT_FREEBSD6" to their kernel config files, so that X.Org and friends still work without recompiling. =20 Revision Changes Path 1.460 +7 -0 src/UPDATING ----- End forwarded message ----- Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --vGgW1X5XWziG23Ko Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFHs7rqRfpzJluFF4RAiQ+AJwIQ7PAPP8tJm3dT0QNhFWCk7sJSwCeNS6R nFCLPgX/ie1xg2qGnGOdluk= =lHkC -----END PGP SIGNATURE----- --vGgW1X5XWziG23Ko-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 30 21:39:13 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6A3416A40F; Sat, 30 Sep 2006 21:39:13 +0000 (UTC) (envelope-from morganw@chemikals.org) Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.25.9.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4570F43D45; Sat, 30 Sep 2006 21:39:13 +0000 (GMT) (envelope-from morganw@chemikals.org) Received: from volatile.chemikals.org (cpe-024-211-118-154.sc.res.rr.com [24.211.118.154]) by ms-smtp-02.southeast.rr.com (8.13.6/8.13.6) with ESMTP id k8ULd4Cw016028; Sat, 30 Sep 2006 17:39:09 -0400 (EDT) Received: from localhost (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.13.8/8.13.8) with ESMTP id k8ULd24l014265; Sat, 30 Sep 2006 17:39:02 -0400 (EDT) (envelope-from morganw@chemikals.org) Date: Sat, 30 Sep 2006 17:39:02 -0400 (EDT) From: Wesley Morgan To: Ruslan Ermilov In-Reply-To: <20060930200915.GB60100@rambler-co.ru> Message-ID: <20060930173826.D10056@volatile.chemikals.org> References: <20060930200915.GB60100@rambler-co.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: current@freebsd.org Subject: Re: HEADS UP: add "options COMPAT_FREEBSD6" to your 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: Sat, 30 Sep 2006 21:39:13 -0000 On Sun, 1 Oct 2006, Ruslan Ermilov wrote: > All, > > Make sure to add "options COMPAT_FREEBSD6" to your custom kernel > config files, or things like X.Org will refuse to work with the > new kernel that includes fixed ioctl(2) API. Recompiling the > relevant ports is another option. Other than X what else are we talking about here? > > ----- Forwarded message from Ruslan Ermilov ----- > > ru 2006-09-30 20:01:15 UTC > > FreeBSD src repository > > Modified files: > . UPDATING > Log: > The ioctl(2) API has changed, and some ioctl command codes too. > Hint users to add "options COMPAT_FREEBSD6" to their kernel config > files, so that X.Org and friends still work without recompiling. > > Revision Changes Path > 1.460 +7 -0 src/UPDATING > > ----- End forwarded message ----- > > > Cheers, > -- This .signature sanitized for your protection From owner-freebsd-current@FreeBSD.ORG Sat Sep 30 21:50:43 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8992416A403 for ; Sat, 30 Sep 2006 21:50:43 +0000 (UTC) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B8A543D46 for ; Sat, 30 Sep 2006 21:50:42 +0000 (GMT) (envelope-from ru@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id 202405F28; Sun, 1 Oct 2006 01:50:41 +0400 (MSD) Received: from edoofus.park.rambler.ru (unknown [81.19.65.108]) by relay0.rambler.ru (Postfix) with ESMTP id F3E0C5F05; Sun, 1 Oct 2006 01:50:40 +0400 (MSD) Received: (from ru@localhost) by edoofus.park.rambler.ru (8.13.8/8.13.8) id k8ULojxA025780; Sun, 1 Oct 2006 01:50:45 +0400 (MSD) (envelope-from ru) Date: Sun, 1 Oct 2006 01:50:45 +0400 From: Ruslan Ermilov To: Wesley Morgan Message-ID: <20060930215044.GA93298@rambler-co.ru> References: <20060930200915.GB60100@rambler-co.ru> <20060930173826.D10056@volatile.chemikals.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YiEDa0DAkWCtVeE4" Content-Disposition: inline In-Reply-To: <20060930173826.D10056@volatile.chemikals.org> User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: current@freebsd.org Subject: Re: HEADS UP: add "options COMPAT_FREEBSD6" to your 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: Sat, 30 Sep 2006 21:50:43 -0000 --YiEDa0DAkWCtVeE4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 30, 2006 at 05:39:02PM -0400, Wesley Morgan wrote: > On Sun, 1 Oct 2006, Ruslan Ermilov wrote: >=20 > >All, > > > >Make sure to add "options COMPAT_FREEBSD6" to your custom kernel > >config files, or things like X.Org will refuse to work with the > >new kernel that includes fixed ioctl(2) API. Recompiling the > >relevant ports is another option. >=20 > Other than X what else are we talking about here? >=20 Basically everything that's using the following ioctls: consio.h: KDSETMODE, KDSBORDER, CONS_SETWINORG, CONS_SETKBD, VT_RELDISP, VT_ACTIVATE, VT_WAITACTIVE kbio.h: KDSKBMODE, KDMKTONE, KDSETMODE, KDSBORDER, KDSKBSTATE, KIOCSOUND, KDSETRAD pioctl.h: PIOCBIS, PIOCBIC, PIOCSFL, PIOCCONT ttycom.h: TIOCSIG I don't see much point in recompiling ports except for testing; just doing it on the next occasion is OK. It's much easier to just recompile a kernel, given that COMPAT_FREEBSD6 is in the GENERIC config, and will certainly be needed for more things as we approach 7.0-RELEASE. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --YiEDa0DAkWCtVeE4 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFFHua0qRfpzJluFF4RAh15AKCLFUj2+wMur9q1ZBTbPeZ5xXd/+gCfZPtg r4bOrAv1W1uqxMrzrhwdVOE= =ekF1 -----END PGP SIGNATURE----- --YiEDa0DAkWCtVeE4-- From owner-freebsd-current@FreeBSD.ORG Sat Sep 30 22:55:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 165AC16A407 for ; Sat, 30 Sep 2006 22:55:25 +0000 (UTC) (envelope-from craig@xfoil.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFA9043D58 for ; Sat, 30 Sep 2006 22:55:24 +0000 (GMT) (envelope-from craig@xfoil.gank.org) Received: by ion.gank.org (Postfix, from userid 1001) id 68937111AD; Sat, 30 Sep 2006 17:55:24 -0500 (CDT) Date: Sat, 30 Sep 2006 17:55:22 -0500 From: Craig Boston To: Dmitry Pryanishnikov Message-ID: <20060930225522.GA77394@nowhere> Mail-Followup-To: Craig Boston , Dmitry Pryanishnikov , freebsd-current@freebsd.org References: <1159546633.1883.4.camel@wbemfkaa.net.xtra-net.be> <451D4B4A.7090602@inode.at> <1159550277.1883.6.camel@wbemfkaa.net.xtra-net.be> <200609292126.17694.absorbb@gmail.com> <20060930153727.R17641@atlantis.atlantis.dp.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060930153727.R17641@atlantis.atlantis.dp.ua> User-Agent: Mutt/1.4.2.2i Cc: freebsd-current@freebsd.org Subject: Re: linux flashplayer plugin status ? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: 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, 30 Sep 2006 22:55:25 -0000 On Sat, Sep 30, 2006 at 03:50:01PM +0300, Dmitry Pryanishnikov wrote: > (until we haven't convinced Macromedia to release FreeBSD-native Flash > plugin). Yes, and it sounds from the Adobe blog that the Linux Flash 9 plugin will be tightly bound to ALSA, so things may only get worse from here...